こんにちは。エンジニアの和田です。
先週、SalesforceにDreamforceが開催されました。Main KeynoteではAgentforceを中心とした発表となり、Agentforceに対する力の入れようを実感できます。
今回はDreamforceで発表された機能の中でも、新しいAgentforce BuilderとAgent Scriptについて、現時点での情報をもとに解説します。
これらは、今後のAgent開発に大きな影響を与えるのではないかと考えています。これまでのAgentforceでの開発経験も踏まえながら、考察していきます。
新しいAgentforce Builder
Agentforce Builderがリニューアルされることが発表されました。ここでは、Dive into our Agentforce 360 Announcementsというページから閲覧できるAgentforce Builderの紹介ページの動画をベースに、Main KeynoteやAgentforce Keynoteの内容も踏まえて解説します。
なお、動画で表示されているAgentforce Builderはデモ用であり、GA（一般提供）される頃には仕様が変わる可能性もありますが、本記事では動画でわかる範囲の情報をお伝えします。
Explorer
まず、左側のパネルが目を引きます。ここは「Explorer」と呼ばれているようです。
一見目新しいのですが、よく見ると、従来のAgentforce Builderの構成（Agent全体の設定とTopicの設定）を踏襲し、拡張したものであることがわかります。Agentforce Builderの紹介ページの動画に映っていたExplorerの表示をもとに順に解説していきます。
Settings
ここは、Agent全体に関わる設定であり、従来は基本的にBuilderに入る前に設定するものでした。
従来のAgent設定画面の「Detail」に相当すると考えられます。Agentの名前や、どのようなAgentなのかといった概要を記述するようです。
従来のAgent設定画面の「System Messages」と同様、Agentに最初に接続した際に表示されるWelcome Messageや、エラー発生時に表示されるError Messageの文面を記述すると考えられます。
従来のAgent設定画面の「Language Settings」と同様、デフォルトの言語とトーン（Casual/Neutral/Formal）を設定するものと考えられます。この項目は、従来もBuilderで設定可能でした。
Topics
ここは、ユーザーの問いかけを分類して適切な行動を取れるようにするための機構で、それ自体は従来のBuilderと同じです。
各Topicは、Topic自体の説明、Instructions、Actionsで構成されているようです。
InstructionsとActionsがあるのは従来と同じですが、異なるのはTopic自体の説明の部分です。
従来は「Classification Description」と「Scope」に分かれていましたが、この区別がなくなったように見えます。
「Classification Description」はどのように分類するかを記述する項目で、「Scope」はこのTopicで何をするかを記述するものでした。
しかし、何をするかが決まれば自ずと分類の仕方も決まる側面があるため、両者は密接に関連しています。
両者をうまく書き分けるのが難しい場合もあったため、今回統合されたものと考えられます。
また、統合のもう一つの要因として、Topic間を遷移する機能の追加が考えられます。
後述しますが、Agent Scriptにより、Instructionsの中で別のTopicへ遷移させる指示を記述できるようになります。
これにより、どのような軸で分類すべきかというClassification Descriptionの重要性は薄れます。
Agentが最初に分類を判断する際には意義がないわけではないですが、Topicを遷移する際にはノイズになり得ます。
他にAgentforce Builderの紹介ページの動画で気になったのは、Topicsに「Off Topic」が存在することです。
Off Topicについては以前本ブログでも取り上げました。他のTopicに該当しない場合、Salesforceが定めた「Off Topic」というTopicが選択されていました。
しかし、このTopicはカスタマイズできなかったため、開発者が意図しない回答をするおそれがあるのでした。
従来のBuilderでは「Off Topic」の項目が明示されておらず、あくまで内部的な扱いだったためカスタマイズできませんでした。しかし、今回新しいBuilderに明示的に「Off Topic」が出てきたということは、カスタマイズできるようになったということでしょうか。以前本ブログで取り上げた際には、回避策としてOff Topicの代わりとなるTopicを作って誘導する方法を紹介しましたが、直接Off Topicを編集できればもちろんその方が良いです。
ただ、Main KeynoteのBuilder画面にはOff Topicがなかった点が気になります。これは、GA前で仕様が未確定だからなのか、デモ用に非表示にしているだけなのか、あるいはOff Topicを完全に削除できるようになったのか、どれなのでしょうか。最後の「完全に削除可能になった」という可能性に期待したいところです。
Topicにおける他の大きな見どころとしてはAgent Scriptへの対応が挙げられますが、これについては後述します。
Connections
ここは、ユーザーがAgentに接続するための接点となる設定のようです。
従来もConnectionsという設定項目はありましたが、Omni-Channelの設定か、Agent APIの接続に用いる設定のみでした。
動画では、Messaging、Voice、Slackの3つが確認できます。従来のOmni-ChannelやAgent APIの設定はMessagingに入り、VoiceとSlackが追加された形なのではないかと思います。
Voiceは今回のDreamforceで発表された目玉機能の一つ「Agentforce Voice」のことで、日本語対応が待たれます。
Slackは従来もAgentforce in Slackという形でSlackとの接続がありましたが、ここでどのような設定を行うのか気になります。
Resources
ここは、Agentがアクセスする情報を格納する部分のようです。
このうちData Librariesは従来からある機能で、簡便にVector DBを作成してRAGを可能にする機構です。
もう一つのMCP Resourcesが注目点です。MCPの仕様上、サーバー側のプリミティブの一つとしてResourcesがありますが、ToolsでもResourcesのような働きをさせているケースもあります。今回のMCP Resourcesは、厳密にプリミティブとしてのResourcesのみに対応したものなのか、Toolsなどにも対応しているのか気になります。
おそらくMCPの全ての接続をここに集約するわけではなく、例えばデータの登録といった作業はActionを通じて行うのではないかと思いますが、そのあたりの仕様も気になります。
Connected Agents
これは完全に新しく導入されたもので、いわゆるA2A（Agent2Agent）で接続された他のAIエージェントが並ぶようです。新しいAgentforce BuilderのGAと同時にA2Aの機能もGAとなるのか気になります。
Variables
従来はContext Variableとして、やりとりするユーザーのIDなどを格納していましたが、後述するAgent Scriptの様子を見る限り、プログラミングで通常使われるような一般的な意味での変数もここに含まれるようです。
Tests
Agentforce Testing Centerの機能がここに入るのかと思いますが、どこまで使えるようになるのか気になります。
Explorer以外の注目ポイント
何といっても、Builderの右側で、AgentのシミュレーションではなくAgentの編集に関する指示を行うようになった点が目新しいです。Main Keynoteで、突然この場所でAgentをこのように改善してと指示していて驚きました。この機能はAgentforce Builderの紹介ページを見る限り「Agentforce Assistant」と呼ぶようです。プロンプトを改善していく作業は手間がかかるため、AIの助けを借りて省力化できれば望ましいです。実際に触ってみてどの程度有効か確かめてみたいものです。
では従来のようなAgentのシミュレーションをするにはどうするかというと、中央左上の「Simulate」というボタンを押せば画面が開いて実行できるようです。
しかし、このUIには一長一短ありそうです。
Vibe Codingが一般的になってきた今、AIエージェントの構築にもAIを用いるというのは自然な発想であり、それがいつでもできるように、常に表示される位置に配置するというのは一つの方法だと思います。
一方、シミュレーションは少しやりづらくなったように感じます。従来であれば、右側でシミュレーション（プレビュー）し、中央でその経過が表示され、原因となっている具体的なTopicの設定を左側で確認するというやり方ができました。今回は、シミュレーション結果とTopicの設定を表示切り替えしながら見比べることになりそうで、やや使いづらい印象を受けます。慣れの問題もあるかもしれませんが。
Agent Script
ここからは、Agent Scriptについて見ていきます。
理念
Agent Scriptは、TopicのInstructionにおいて、従来の自然文だけでなくプログラミング的な処理を含められるようになったものです。従来のLLMによる推論を、（自然文のようにある程度あいまいさがあっても処理できる一方）毎回同じアウトプットが出るとは限らないという意味で「非決定論的」、プログラミング的な処理を、その反対に「決定論的」と呼ぶことがありますが、Agent Scriptはその両方を融合させたと位置づけられます。
LLMは非決定論的な推論ができるのが大きな特徴にもかかわらず、なぜここで決定論的な処理が導入されることになったのでしょうか。それはビジネス上の要請だと考えられます。
LLMのチャットで遊ぶだけであれば、非決定論的な推論だけで十分です。しかしビジネスとなると、「必ずこうすべき／こうすべきでない」というルールがあり、それが破られると大きな損害を被るおそれがあります。例えば、見せてはいけない情報をAIエージェントが開示してしまったら、損害は甚大です。こうした状況では、非決定論的な推論には大きな不安が残ります。
Keynoteの動画にも出てきますが、従来はこれを解消するためにInstructionに「ALWAYS 〜」といった記述を多用することになりました。
実際、弊社で使っているAIエージェントでも同様の傾向がありました。
しかし、これはあまり健全な姿とは言えません。
少しでも一貫性のないInstructionがあるとすぐに混乱した状態になるため、かなり慎重に記述する必要があります。
Salesforceのヘルプページでも「ALWAYS」という言葉の使い方には注意を払うよう呼びかけられていました。
これはSalesforce自身も腐心した部分なのではないかと思います。
それでいて、たとえ完璧に記述できたとしても、結局は非決定論的であるため、ルールがきちんと守られる保証はありませんでした。
「ALWAYS」と記述するような箇所は、本来プログラミング的処理を適用すべきです。
ビジネス上の要請で決定論的な処理が必要なら、LLMとは関係なく完全にプログラムを走らせるだけでよいのではないかというと、必ずしもそうとは言えません。
もちろん場合によってはLLMを使わない方が良いケースもあるでしょう。
しかし、例えばユーザーが入力した自然文を解釈したり、自然文で書かれたデータを要約したりといったことは、従来のプログラミングでは難しく、LLMの威力が発揮される場面です。今の時代、このLLMの能力を生かさないのはもったいないとも言えます。
というわけで、プログラムのような決定論的処理と、LLMの非決定論的処理を両立させたいという、ある種わがままな要求に応えるのがAgent Scriptの理念と言えそうです。
（先ほど引用した記事を含みますが）以前、本ブログで「AgentforceのAgent制御ノウハウ」という記事を2回にわたって執筆しました（第1弾、第2弾）。そこでは、ある意味、非決定論的な振る舞いをするAIエージェントに対し、少しでも決定論的な結果を生み出すための取り組みを紹介したと言えそうです。最初から決定論的な記述も可能であれば、その方が望ましいことは言うまでもありません。
機能
理念はわかりましたが、どのように非決定論的処理と決定論的処理を融合させているのか、その機能はどのようになっているのでしょうか。
非決定論的処理と決定論的処理の融合というと、ChatGPTを思い起こします。ChatGPTは通常非決定論的処理ですが、状況によりバックグラウンドでコードを実行し、決定論的に計算して答えを出すことがあります。
では、Agent Scriptではどうなっているのでしょうか。
動画を見ると、条件分岐や変数の利用、他のTopicや他のAgentへの遷移など、プログラミング的処理が書かれている中に、従来のプロンプトに相当する自然文が記述されています。「Script」表示にすると、両者が一体となっていることがわかります。
まずは自然文で書いてScriptに変換することもできますし、直接Scriptを記述することも可能なようです。
プログラミング的処理についてもう少し見てみます。
条件分岐は、ベーシックな機能ながら非常に重要です。これをLLMに対してプロンプトとして記述し、着実に実行させるのは手間がかかり、プロンプトに「ALWAYS」を多用する原因となっていましたが、Agent Scriptでこうした事態を回避できそうです。
動画にも出てきますが、例えば会員限定で情報を開示したい場合に、従来の非決定論的なアプローチでは非会員に情報を渡してしまう可能性を排除できませんでした。しかし、決定論的な条件分岐により、これを確実に防止できることになります。
変数利用は地味ですが、うまく使えば有用そうです。1つ目のActionの結果を2つ目のActionのインプットとしたい場合、従来だと同じ値が入力されないケースもありましたが、変数を使えばこれを防げそうです。また、変数にリテラルを代入したり、文字列を結合したりできるのかも気になります。これができれば、Actionのインプットを柔軟に制御したり、Agentが出力する文字列を生成したりできそうです。以前の記事で、特定の文字列をAgentに出力させたい場合にPrompt Injectionエラーとなる話を書きましたが、もし変数にリテラルを代入できれば、この問題も防げるかもしれません。
他のTopicや他のAgentへの遷移も注目すべき機能です。従来、Topicは一つしか選ばれませんでした。そこを他のTopicに遷移させられるとなると、開発の自由度が上がりそうです。これを決定論的に実行できるというのが重要です。おそらく、最初はA2Aによる他のAgentへの遷移を前提に設計され、その流れでTopicの遷移機能も追加されたようにも思えます。こう考えると、Agent ScriptはA2Aを効果的に実現するために不可欠な機能だったと言えるかもしれません。
仕組み
このようにAgent Scriptは便利そうですが、最初に見た時には決定論的記述と非決定論的記述が混然一体となっていることに正直驚きました。これを実際にどう処理しているのかが気になります。処理の仕方によって、Agent Scriptをどう使っていくべきかも変わりそうです。
考えられる処理方法の候補としては、以下が挙げられるでしょうか。
- 決定論的と謳ってはいるが、実は特定の文法の記述で特定の動きをするようシステムプロンプトで強く指示しているだけで、実態は全てLLMによる非決定論的推論である
- ユーザーが書いたScriptは一旦全てLLMの非決定論的推論により解釈され、その過程で決定論的アプローチが必要とLLMが判断した場合に、適宜プログラム的処理を呼び出す
- ユーザーが書いたScriptは、通常のプログラミング言語と同様に決定論的に字句解析・構文解析が行われ、特定の構文で書かれた箇所は全てプログラムとして動く。自然文で書かれた部分は適宜LLMを参照する
先ほどのChatGPTの例は2に相当します。では、Agent Scriptはどうなのでしょう。
実は、Salesforce Developers BlogにAgent Scriptの記事があり、そこには以下の記述があります。
Agent Script is a compiled language. When you write your agent, it doesn’t run directly; instead, it generates a structured specification – the Agent Graph – which is consumed by the Atlas Reasoning Engine.
https://developer.salesforce.com/blogs/2025/10/introducing-hybrid-reasoning-with-agent-script
Agent Scriptはコンパイル言語であると明記されており、字句解析・構文解析も行っているようなので、これを見る限りでは3である可能性が高そうです。
したがって、擬似的などではなく似的などではなく、本当に決定論的に動くと考えてよいように思えます。
この辺りは、実際に動作させてみて確認したいところです。
従来機能との比較
決定論的処理というと、Salesforceの機能として真っ先に浮かぶのはFlowやApexです。従来のAgentforceでも、AgentのActionとしてFlowやApexを紐づければ、非決定論的処理と決定論的処理を融合させることは可能でした。
では、今回のAgent Scriptは何が違うのでしょうか。
一番の違いは、非決定論的処理と決定論的処理をシームレスに記述できる点でしょう。Agent Scriptと同じことをFlowやApexで実現しようとすると、FlowやApexの中にさらにPrompt Templateを入れるなど、複雑な構成になります。Agent Scriptとして簡潔に記述できたほうが扱いやすく、Vibe Codingの観点からも作成しやすいでしょう。
Agentとして実行すべきActionの管理が明確化しやすいという利点もあります。Agent Scriptと同じことを従来のスタイルでやろうとすれば、例えば1つのTopicに1つのActionだけを紐づけ、そのActionはFlowやApexとし、その内部でPrompt Templateで判別させて本来のActionを呼ぶという形も不可能ではありません。しかし、そのAgentが結局何のActionを実行するのかが見えにくくなり、管理が煩雑になってしまいます。Agent Scriptという形で直接Actionを呼び出す方が、見通しはよくなります。
また、他のTopicに遷移するという機能は、従来のFlowやApexでは困難でしょう。A2Aについては全く不可能ではないかもしれませんが、かなりのカスタマイズが必要になりそうです。
もちろん、Agent ActionとしてFlowやApexを紐づけることが有用な場合もありますが、それだけではカバーできない力をAgent Scriptは持っていると言えそうです。
Agent Scriptに関連する他の期待
Agent Scriptそのものの話題ではありませんが、Agent Script導入にあわせて期待したいことがあります。
それは、Atlas推論エンジンの性能向上です。
もちろん、Agent Scriptに対応するようになるわけですから、決定論的処理ができる分だけ性能は高いと言えます。しかし、それだけでなく、非決定論的処理にもアップデートがあるのではないかと期待したいところです。
Atlas推論エンジンの非決定論的処理の核となるのはシステムプロンプトです。これは一度決めると、少し改修しただけで全体への影響が大きいため、なかなか変更しにくい事情もあったと推測します。しかし、今回はAgent Script導入ということで、システムプロンプトもおそらく大幅に変更せざるを得ないはずです。これを機に、よりプロンプトの意図を汲むようなシステムプロンプトに刷新されていることを期待したいです。
また、Atlas推論エンジンが用いるLLMのモデルもアップデートされることを期待したいです。
これまではAtlas推論エンジンが用いるモデルは基本的にGPT-4oでした。
最近になってAnthropic Claude Sonnet 4も選択肢に加わりましたが、なかなか使いどころが難しい状況のようです（参考: 弊社ブログ記事）。
GPT-4oは今となっては少し古いモデルですが、システムプロンプトがGPT-4oに最適化されているためか、LLMモデルの変更はなかなか難しい状況にあったのではないかと推察されます。
しかし、先述の通り、Agent Scriptの導入でおそらくシステムプロンプトを大幅に変更せざるを得ない状況のはずなので、LLMのモデルを変更するならば今が絶好の機会ではないでしょうか。
ちょうど、Atlas推論エンジンにGeminiモデルが使えるようになるという発表がありましたので、楽しみにしたいと思います。
https://www.salesforce.com/jp/news/press-releases/2025/10/17/google-gemini-agentforce-partnership-expansion-announcement/
個人的には、Geminiモデルではありませんが、エージェント型タスクに強いと言われているGPT-5が利用できるようになればと思いますが、どうなるでしょうか。
おわりに
以上、新しいAgentforce BuilderとAgent Scriptについて、現時点での情報をもとに考察してきました。
従来のTopic-Actionという構成は変わらないものの、そこをうまく拡張・発展させていると感じます。
「とりあえずAgent作成基盤を提供しました」という段階は終わり、ユーザー（Agent開発者）の意見を取り入れながら改良していくフェーズに入ったように思います。
今回記載した内容はあくまで現時点で得られる情報のみからの考察であるため、実際に機能が使えるようになったらぜひ試してみたいと思います。
AI技術の進展は凄まじく、今後も頻繁なアップデートがあると思いますが、常に最新情報をキャッチアップしていきたいと考えています。
最後までお読みいただきありがとうございました。
