開発担当者が押さえるべきAgent Scriptの基本概念とハイブリッド推論の仕組み

開発担当者が押さえるべきAgent Scriptの基本概念とハイブリッド推論の仕組み

Salesforceが2025年のDreamforceで発表したAgent Scriptは、Agentforce上でAIエージェントの挙動を制御するために設計された新しいドメイン固有言語（DSL）です。従来のエージェント構築では、自然言語による指示文をLLMに渡して応答を生成させる方式が主流でしたが、この手法には応答のばらつきや制御不能な推論といった本質的な課題がありました。Agent Scriptは、決定論的なプログラムロジックとLLMの柔軟な推論を同一ファイル内で組み合わせる「ハイブリッド推論」を実現し、企業が業務クリティカルなプロセスにAIエージェントを組み込む際の信頼性を大幅に向上させます。本章では、この新言語の設計背景と基本構造、そしてAtlas Reasoning Engineとの連携の仕組みを解説します。

Agent ScriptがDSLとして設計された背景にあるLLM単体運用の3つの限界

LLMだけでエージェントを運用する場合、まず直面するのが応答の一貫性の欠如です。同一の入力に対しても、生成のたびに異なる応答が返される可能性があり、顧客対応や業務処理のように再現性が求められる場面では重大な問題となります。次に、LLMは入力コンテキストに依存するため、ビジネスルールの厳密な適用が保証されません。たとえば「10万円以上の案件は必ず上長承認を経由する」というルールを自然言語で指示しても、LLMがそのルールを100%遵守するとは限りません。3つ目の限界は、処理フローの可視性です。LLM単体では、なぜその応答に至ったのかを追跡することが困難であり、金融・医療・防衛など規制の厳しい業界ではコンプライアンス上の障壁となります。こうした3つの課題を解決するために、SalesforceはAgent Scriptを汎用プログラミング言語ではなく、エージェント制御に特化したDSLとして設計しました。人間が読みやすい宣言的構文を基盤としつつ、条件分岐やアクション呼び出しといった確定的処理を記述できる仕組みが、LLM単体運用の限界を補完しています。

決定論的ロジックとプロンプト生成を1ファイルで共存させる言語構造の特徴

Agent Scriptの最大の特徴は、1つのスクリプトファイル内でプログラムコードと自然言語プロンプトを明確に分離しつつ共存させる構文設計にあります。具体的には、アロー記法（->）で記述された行は決定論的に上から順に実行される手続き型ロジックとして処理され、パイプ記法（|）で記述された行はLLMに送信されるプロンプトテキストとして組み立てられます。この2つの記法をreasoning instructionsブロック内で交互に使うことで、「まず変数を確認し、条件を満たせば特定のアクションを実行し、その結果をプロンプトに含めてLLMに判断させる」といった複合的なフローを実現できます。また、Agent Scriptはコンパイル型言語であり、記述されたスクリプトは直接実行されるのではなく、Agent Graphと呼ばれる構造化された仕様にコンパイルされます。このAgent GraphをAtlas Reasoning Engineが解釈し実行するため、開発者が定義したロジックが忠実に反映される仕組みです。ポータブルJSON形式で出力されるため、バージョン管理やチーム間共有も容易に行えます。

Atlas Reasoning Engineが推論ステップごとに実行制御を切り替える処理フロー

Atlas Reasoning EngineはAgentforce 360の中核を担う推論エンジンであり、Agent Scriptによって構成可能（configurable）になったことが大きな進化です。エージェントがユーザーからメッセージを受信すると、まずstart_agentブロックが実行され、変数の初期化やトピックの振り分けが行われます。次に、該当するトピックブロック内のreasoning instructionsが上から順に処理されますが、このときアロー記法で書かれた部分はエンジンが決定論的に評価し、パイプ記法で書かれた部分はプロンプトとしてLLMに送信されます。つまり、推論ステップごとに「ここはプログラムが判断する」「ここはLLMが判断する」という切り替えが自動的に行われるのです。この処理が完了すると、エージェントは次のユーザー入力を待ち、再びstart_agentから処理サイクルが始まります。トピック遷移が発生した場合は@utils.transitionによって即座に別トピックへ移行し、元のトピックには自動的に戻らない一方向遷移が基本となります。この設計によって、処理の流れが予測可能かつデバッグしやすくなっています。

従来のAgentforce設定画面との違いを生むtopicブロック単位の設計思想

従来のAgentforce Agent Builderでは、エージェントの設定はGUIベースで行われ、トピックごとに自然言語の指示文を記入し、利用可能なアクション（FlowやApex）を選択するという流れでした。この方式はローコードで直感的に操作できる反面、条件分岐の粒度やアクション実行の順序を細かく制御するには限界がありました。Agent Scriptでは、topicブロックという単位でエージェントの全ロジックを構造化します。各topicブロック内にはdescription（トピックの説明）、scope（スコープ定義）、actions（実行可能なアクション群の宣言）、reasoning（推論ロジック）が含まれ、さらにreasoningの中にinstructions（実行順の指示）とactions（LLMに公開するツール）が配置されます。この階層構造により、アクションの定義と公開が明確に分離され、「定義しただけでは実行されない」という関数宣言に近い設計思想が貫かれています。従来のGUI設定で曖昧だった「どのアクションをいつ実行するか」という制御が、コードレベルで厳密に管理できるようになった点が最大の違いです。

ハイブリッド推論が不要なケースと導入判断を誤る典型的な失敗パターン

Agent Scriptの強力さに注目するあまり、すべてのエージェントに適用しようとするのは典型的な過剰設計です。たとえば、社内FAQに回答するだけのシンプルなナレッジベースエージェントや、定型的な挨拶・案内を行うだけのチャットボットであれば、従来のローコードCanvas設計で十分に機能します。ハイブリッド推論の恩恵が大きいのは、条件分岐が複数存在する業務プロセス、複数トピックをまたぐ複合的な対話、ミスが許されないコンプライアンス要件がある場面です。導入判断で陥りやすい失敗パターンとして、「スクリプトで全ロジックを決定論的に書いてしまい、LLMの柔軟性を活かせない」というケースがあります。本来LLMが得意とする自然な対話や文脈理解まで条件分岐で固定すると、ユーザー体験が硬直的になり、かえって満足度が低下します。逆に「ほぼすべてをLLMに任せてAgent Scriptの制御部分が形骸化している」場合は、導入コストに見合う効果を得られません。LLMに任せる領域と確定的に制御する領域の境界を事前に設計文書で定義し、その比率をテスト結果に基づいて調整するアプローチが現実的です。

LLMの創造性と業務ロジックを両立するハイブリッド推論エンジンの構造

ハイブリッド推論は、Agent ScriptとAtlas Reasoning Engineの連携によって実現される中核的なアーキテクチャです。LLMの持つ柔軟な言語理解力と、ビジネスルールの確実な実行を同一の処理フロー内で両立させることで、企業グレードのAIエージェントに必要な精度と適応性の両方を確保します。本章では、ハイブリッド推論を構成する具体的な記法と処理構造、そしてモデル選択による精度差異までを掘り下げます。

パイプ記法（|）で渡すプロンプト領域とアロー記法（→）で制御する確定領域の境界

Agent Script内で|（パイプ）と->（アロー）の2つの記法が担う役割は明確に異なります。パイプ記法で書かれたテキストは、実行時にプロンプトの一部としてLLMに送信されます。ここでは自然言語で指示を書くことができ、たとえば「顧客の質問に丁寧に回答してください」といった柔軟な対話指示を含められます。一方、アロー記法で書かれた行はAtlas Reasoning Engineが決定論的に処理するコードとして扱われ、条件分岐、変数の代入、アクションの呼び出しなどが上から順に確実に実行されます。重要なのは、この2つの記法がreasoning instructionsブロック内で交互に配置できる点です。たとえば、アロー記法で「顧客ランクがVIPかどうかを判定」し、その結果に基づいてパイプ記法で異なるプロンプトテキストをLLMに渡すといった処理が可能になります。これにより、LLMは「全情報を渡されて自力で判断する」のではなく「必要な情報だけを受け取って適切に応答する」形になり、ハルシネーションの抑制とコンテキスト精度の向上が期待できます。

条件分岐・変数代入・アクション呼び出しを決定論的に処理するinstructions層の役割

reasoning内のinstructionsブロックは、エージェントの挙動を制御するオーケストレーション層として機能します。ここに記述されたロジックは上から下へ順番に実行され、if/then形式の条件分岐でフローを分岐させることが可能です。たとえば、顧客の認証ステータスを格納した変数を評価し、未認証であれば認証トピックへ遷移させ、認証済みであれば注文照会アクションを呼び出すといった処理を記述できます。変数代入もアロー記法で行われ、アクションの出力結果を変数に格納して後続の処理で使用する流れが一般的です。重要な設計原則として、instructionsブロック内でアクションを「定義する」のと「公開する」のは別の操作です。topicブロック直下のactionsセクションでアクションの入出力仕様を宣言し、reasoningブロック内のactionsセクションでLLMに公開するアクションを指定します。この分離により、「宣言はしたがLLMには使わせたくないアクション」を制御でき、意図しないアクション実行を防ぐガードレールとして機能します。決定論的な実行保証とLLM公開範囲の制限を組み合わせることで、業務プロセスの安全性が確保される構造です。

LLMに渡すコンテキストを実行時に動的構築する{! }式テンプレートの実務効果

Agent Scriptでは、パイプ記法で書かれたプロンプトテキスト内に{! }というフォーミュラ構文を使って変数や式の値を埋め込むことができます。この機能は単なるテンプレート展開ではなく、コンテキストエンジニアリングのための重要な仕組みです。従来の自然言語指示方式では、エージェントに関連する情報をすべてプロンプトに含めてLLMに判断を委ねていたため、不要な情報がノイズとなって推論精度を下げるリスクがありました。{! }構文を使えば、条件分岐の結果に応じて「今この瞬間に必要な情報だけ」をプロンプトに含めることができます。たとえば、顧客の過去の問い合わせ履歴が3件以上ある場合のみ、直近の履歴サマリーをプロンプトに挿入するといった動的構築が可能です。実務上の効果として、プロンプトの肥大化を防ぎつつ応答精度を向上させるだけでなく、LLMのトークン消費を抑えることでAPI呼び出しコストの最適化にもつながります。特に1日に数千件の対話を処理するカスタマーサービス領域では、このコスト削減効果は無視できない規模になります。

推論ループやトピック遷移で発生しやすい無限ループ・意図ずれの回避策

Agent Scriptでは@utils.transitionを使ってトピック間を遷移できますが、この遷移は一方向であり、遷移先のトピック処理が完了しても自動的に元のトピックへ戻ることはありません。この仕様を理解せずに設計すると、「認証トピック→注文照会トピック→認証トピック→…」のような循環参照が発生し、実質的な無限ループに陥るリスクがあります。回避策の基本は、トピック間の遷移マップを設計段階で図示し、循環が発生しないことを確認することです。やむを得ず元のトピックに制御を返す必要がある場合は、トピック委任（Topic Delegation）パターンを利用します。また、意図ずれが発生しやすいもう1つの場面は、reasoningブロック内のinstructionsが長大になりすぎた場合です。20行を超える指示は、LLMが受け取るプロンプトの総量を増加させ、指示の優先度が曖昧になります。対策として、1トピックあたりの責務を単一目的に限定し、複雑なプロセスは複数トピックに分割してそれぞれの指示を短く保つ設計が推奨されます。Agentforce Builderのシミュレーション機能でトレースデータを確認し、各ステップの推論理由を検証する習慣が、意図ずれの早期発見に有効です。

Google Gemini・OpenAI・Anthropicの3モデル選択がエージェント精度に与える差異

Agentforce 360では、Atlas Reasoning Engineの推論基盤として複数のLLMモデルを選択できるようになりました。現時点で利用可能なのはGoogle Gemini、OpenAI、およびAmazon Bedrock上のAnthropicモデルの3系統です。モデル選択はエージェント全体の応答品質に直結するため、ユースケースに応じた検討が必要です。一般的な傾向として、長文の文脈理解や構造化されたドキュメント処理にはAnthropicモデルが安定した精度を示し、多言語対応やリアルタイム性が求められる場面ではGeminiが優位とされます。OpenAIモデルは幅広いタスクに対して高い汎用性を持つ一方、特定業務への最適化にはプロンプトチューニングが求められる傾向があります。ただし、モデルの性能は継続的にアップデートされるため、特定時点での比較結果が将来も維持されるとは限りません。Agentforce BuilderのテストセンターやObservability機能を活用し、同一シナリオを複数モデルで実行して応答精度・レイテンシ・コストを比較する方法が実務的な選定手順として有効です。Salesforceがモデル選択の柔軟性を確保した背景には、特定ベンダーへの依存を避け、企業の要件に最適なモデルを選べるようにする戦略的意図があります。

2つの編集ビューとAI支援で開発効率を変える新Agentforce Builderの特徴

2025年のDreamforceで発表された新しいAgentforce Builderは、従来の設定画面ベースのエージェント構築体験を根本から刷新するものです。最大の特徴は、設計・テスト・デプロイを単一のワークスペースに統合し、自然言語ベースのCanvasビューとコードベースのScriptビューをシームレスに切り替えられる点にあります。さらに、ビルダー内蔵のAIアシスタント「Agentforce Assistant」が会話形式でのエージェント構築を支援します。ローコードの管理者からプロコードの開発者まで、スキルレベルに応じた最適なインターフェースで作業でき、構築からテストまでの反復サイクルを大幅に短縮します。

ローコードCanvasとコードベースScriptの2ビュー＋AI支援の用途別使い分け基準

新Agentforce Builderでは、CanvasビューとScriptビューの2つの編集モードが提供され、さらにAgentforce Assistantによる会話型の構築支援が統合されています。Canvasビューは自然言語ベースのビジュアル編集環境であり、トピックやアクションの関連をドラッグ＆ドロップで構成しながら、自然言語でエージェントの挙動を記述できます。技術背景を持たないビジネスユーザーでもエージェントの初期設計を行えるよう意図されたモードです。Scriptビューは、Agent Scriptの構文をシンタックスハイライトやリアルタイムバリデーション付きで直接編集できる開発者向けモードです。Agentforce Assistantは、ビルダー内に常駐するAIアシスタントであり、「このエージェントに返品処理の機能を追加して」のような自然言語の指示を受けてAgent Scriptコードを自動生成します。プレビュー結果の分析やデバッグ支援も行えるため、構築・テスト・修正のサイクルを加速します。使い分けの基準として、初期のアイデア出しや要件定義段階ではCanvasビューまたはAgentforce Assistantとの対話で素早くプロトタイプを作り、フローの分岐が複雑化してきたらCanvasで全体構造を確認し、条件分岐やガードレールを厳密に定義する段階でScriptビューへ移行する流れが効率的です。CanvasとScriptの2つのビューは同一のエージェント定義を異なる形で表現しているため、切り替えてもデータは失われません。

ワンクリックシミュレーションとリアルタイムデバッグで削減できるテスト工数の実例

従来のエージェント開発では、構築・テスト・修正のサイクルが分離されていたため、1つの挙動を検証するのに画面を行き来する時間が大きなボトルネックでした。新Agentforce Builderでは、ワンクリックシミュレーション機能により、エージェントとの対話をリアルタイムでプレビューできます。さらに、デバッグパネルでは各ステップの推論理由、選択されたトピックとアクション、処理時間がステップバイステップで可視化されるため、問題箇所の特定が従来と比較して格段に速くなります。たとえば、あるカスタマーサービスエージェントで「注文ステータスの回答が誤ったトピックを経由している」という問題が発生した場合、トレースデータを確認するだけで、どのinstructionsの段階でトピック判定が誤ったかを即座に特定できます。修正後は同じシミュレーション画面ですぐに再テストできるため、従来のように別環境にデプロイしてから検証するプロセスが不要になりました。Salesforceの公式発表によると、この統合ワークスペースによってエージェント開発の反復速度が従来比で大幅に向上するとされており、特にプロトタイプ段階での工数削減効果が顕著です。

エージェント定義をポータブルJSONで管理するバージョニングと共有の運用フロー

Agent Scriptで記述されたエージェント定義は、コンパイル後にポータブルJSON形式のファイルとして出力されます。この設計は、エージェントの構成をコードとして扱い、Gitなどのバージョン管理システムで管理するDevOpsワークフローを可能にするものです。JSON形式であるため差分比較が容易で、チームメンバーが同一エージェントに対して並行して変更を加え、マージリクエストでレビューするという一般的な開発フローが適用できます。運用上の具体的なフローとして、開発者はAgentforce DXを使ってローカルのSalesforce DXプロジェクトにスクリプトファイルを取得し、Visual Studio CodeのAgentforce DX拡張機能でコード編集・構文チェックを行います。変更をコミットしてCI/CDパイプラインに組み込むことで、サンドボックス環境への自動デプロイとテスト実行が可能になります。複数の組織間でエージェント定義を共有する場合も、JSONファイルをインポートするだけで済むため、グループ企業間での標準エージェントの横展開や、パートナーが開発したエージェントテンプレートの導入が効率化されます。エンタープライズガバナンスの観点からも、変更履歴の追跡と承認フローの適用が容易です。

Agentforce Vibesによる自然言語からのLWC・Apex自動生成で変わる開発サイクル

Agentforce Vibesは、Visual Studio Code拡張機能として提供されるAI搭載の開発エージェントであり、自然言語の指示からLightning Web Components（LWC）やApexロジックを自動生成する機能を備えています。旧称「Agentforce for Developers」から進化したこのツールは、オープンソースのAIコーディングエージェントClineをベースに構築されており、Salesforce DX MCP Serverを通じて開発環境と連携します。他のAIコーディングツールとの最大の違いは、対象組織のメタデータを読み取って既存のコンポーネントや命名規則を理解した上でコードを生成する点です。たとえば「新入社員のオンボーディングタスクを確認してリマインダーを送るアシスタントを作成して」と指示すると、Vibesはその組織のカスタムオブジェクト構造やフロー定義を参照しながら、適切なコードを出力します。各組織には1日あたり50回のプレミアムモデル（執筆時点ではGPT-5）呼び出しが割り当てられ、上限に達した場合はSalesforceがホストするQwen 3.0モデルに自動フォールバックする仕様です。なお、新Agentforce Builder内にもAI支援機能「Agentforce Assistant」が組み込まれており、Builder上で自然言語によるエージェント構築・デバッグ支援を受けることが可能です。Vibesは主にVS Code上でのApex・LWC開発を、Agentforce AssistantはBuilder内でのエージェント設計をそれぞれ支援するという役割分担になっています。

旧Agent Builderからの移行時に発生するトピック再設計と設定互換の注意点

新Agentforce Builderはオープンベータとして提供されており、旧ビルダーで構築済みのエージェントも引き続きサポートされます。ただし、旧ビルダーから新ビルダーへ移行する際には、いくつかの注意点があります。まず、旧ビルダーで設定した自然言語のトピック指示は、新ビルダーのCanvas表現やScript表現に自動変換されますが、変換後の内容が元の意図を正確に反映しているかを手動で検証する必要があります。特に、旧ビルダーで「ネガティブスコープ（このトピックで扱わない内容）」として設定していた除外条件は、Agent Scriptの条件分岐として再記述することでより厳密な制御が可能になります。次に、旧ビルダーのアクション設定で使用していたFlow・Apex・Prompt Templateとの接続はそのまま引き継がれますが、Agent Scriptの型定義と既存アクションの入出力型が一致しているかの確認が推奨されます。新ビルダーはEnterprise、Performance、Unlimited、Developer Editionで利用可能であり、標準のAgentforceおよびGenerative AIクォータを消費する点も事前に把握しておく必要があります。段階的に移行する場合は、まず影響の小さいエージェントから新ビルダーで再構築し、本番投入前にテストセンターで十分なシナリオ検証を行うアプローチが安全です。

トピック定義から条件分岐まで実務で使うAgent Script構文の基礎知識

Agent Scriptの実務活用にあたっては、基本的な構文要素とその組み合わせ方を正確に理解することが不可欠です。エージェントの挙動はtopicブロック単位で定義され、各トピック内のreasoningブロックがオーケストレーション層として機能します。本章では、start_agentの役割からアクション呼び出しのパラメータ設計まで、開発者が最初に習得すべき構文パターンを実例とともに解説します。

start_agentブロックの役割と毎メッセージ冒頭で実行されるルーティング設計の要点

start_agentはAgent Scriptにおける特別なトピックで、ユーザーからのメッセージを受信するたびに最初に実行されるエントリーポイントです。会話の途中であっても、新しいメッセージが届くと必ずstart_agentから処理が再開されます。この仕様はステートレスなルーティング設計を意味しており、「現在どのトピックで会話しているか」という状態管理をstart_agent内の変数と条件分岐で明示的に行う必要があります。典型的な設計パターンとして、start_agentではまずグローバル変数の初期化を行い、次にユーザーの発話意図を判定して適切なトピックへ遷移させます。意図判定の部分はLLMに任せることもできますし、特定のキーワードや変数値に基づいて決定論的に分岐させることも可能です。注意すべき点として、start_agent内のロジックが複雑になりすぎると、すべてのメッセージ処理に遅延が生じるため、ルーティングロジックは必要最小限に抑え、詳細な処理は各トピックに委譲する設計が推奨されます。また、start_agentはすべてのトピックに共通する前処理を配置する場所としても活用でき、たとえば全会話に対する安全性チェックやユーザー認証状態の確認をここで行うことが一般的です。

topicブロック内のactions定義とreasoningブロックの公開層が果たす2つの機能

Agent Scriptのtopicブロック内では、actionsセクションとreasoningセクションが明確に分離された2層構造を形成します。topicブロック直下のactionsセクションは、そのトピックで利用可能なすべてのアクションを宣言する場所です。ここでは各アクションの名前、入力パラメータの型、出力の型を定義しますが、この段階ではアクションはまだ「定義されただけ」であり、LLMから呼び出すことはできません。アクションをLLMに使わせるには、reasoningブロック内のactionsセクションで明示的に公開する必要があります。この2段階の仕組みには重要な意味があります。たとえば、顧客情報の更新アクションを定義はするが、LLMが自律的に呼び出すのではなく、特定の条件を満たした場合にのみinstructions内のアロー記法で直接呼び出すという使い方が可能になります。つまり、actions定義層は「何ができるか」を宣言するカタログであり、reasoning内のactions公開層は「何をLLMに委ねるか」を制御するフィルターとして機能するのです。この分離により、機密性の高いアクションをLLMの判断から隔離しつつ、必要な場面では決定論的コードから安全に呼び出すというエンタープライズ向けのガバナンスが実現されます。

if/then条件分岐と@utils.transitionを組み合わせたトピック間遷移の書き方

Agent Scriptにおける条件分岐は、reasoningのinstructionsブロック内でアロー記法を使って記述します。基本的なif/then構文では、変数の値や式の評価結果に基づいて処理を分岐させ、特定の条件を満たした場合にアクション実行やトピック遷移を行います。トピック遷移には@utils.transitionを使用し、遷移先のトピック名を指定します。たとえば「顧客の認証が完了していなければ認証トピックへ遷移し、完了していれば注文照会トピックへ遷移する」というロジックは、instructionsブロック内で変数チェック→条件分岐→transition呼び出しという流れで記述します。ここで重要なのは、@utils.transitionによる遷移は即座に実行され、元のトピックの後続行は処理されないという点です。遷移後は遷移先トピックのreasoningが上から実行されるため、遷移前に必要な前処理がある場合はtransition呼び出しの前に完了させておく必要があります。また、複数の条件分岐が連続する場合は、条件の評価順序が上から下へ順番に行われるため、最も頻出する条件を上位に配置することで不要な評価処理を減らすことが実務上のパフォーマンス最適化につながります。

Apex・Flow・Prompt Templateの3種アクション呼び出しにおけるパラメータ設計例

Agent Scriptからは、Apex（カスタムコード）、Flow（宣言的自動化）、Prompt Template（プロンプトテンプレート）の3種類のアクションを呼び出すことができます。Apexアクションは、複雑なビジネスロジックやSOQLクエリ、外部API連携が必要な場面で使用し、Invocable Apexクラスとして実装する必要があります。たとえば、リードスコアリングのロジックをApexで実装し、Agent Scriptのtopicブロック内でアクションとして定義する場合、入力パラメータとしてleadId（String型）を受け取り、出力としてscore（Integer型）とpriority（String型）を返すように設計します。Flowアクションは、レコードの作成・更新・承認プロセスの起動など、Salesforce内のデータ操作を宣言的に行う場面に適しています。Prompt Templateアクションは、LLMに特定のフォーマットで応答を生成させたい場合に使用し、構造化レスポンス（HTMLやJSON形式）の出力指定が可能になっています。パラメータ設計の共通原則として、各アクションの入出力型はAgent Script内のtopicブロックで宣言した型と一致させる必要があり、型の不一致はコンパイル時にエラーとなります。初期段階では、1アクションあたりの入力パラメータを3つ以内に抑え、複雑な入力はオブジェクト型にまとめて渡す設計が保守性の面で推奨されます。

Agent Script Recipesの20超サンプルから学ぶ初学者向け実装パターン5選

Salesforceが公開しているAgent Script Recipesは、GitHubリポジトリで提供される20以上のサンプルコード集であり、Agent Scriptの学習に最適なリソースです。初学者がまず取り組むべき5つのパターンを紹介します。1つ目はAction Recipesで、Apex・Flow・Prompt Templateの各アクションをAgent Scriptから呼び出す基本パターンが網羅されています。2つ目はReasoning Recipesで、LLMに推論を委ねる領域と決定論的に制御する領域の切り分け方を、具体的なコード例とともに学べます。3つ目はArchitectural Recipesで、複数トピック間の状態管理やマルチエージェント構成のオーケストレーションなど、より高度な設計パターンが含まれています。4つ目は条件分岐とトピック遷移を組み合わせた顧客認証フローで、start_agentから認証トピック→業務トピックへの遷移と変数管理の全体像を把握できます。5つ目はトピック委任（Topic Delegation）パターンで、遷移先トピックから元のトピックへ制御を返す方法を学べます。各レシピには専用のREADMEが付属しており、フローの概要図・主要コンセプト・試行手順が記載されているため、コードを読む前に処理の全体像を理解できる構成になっています。Developer Editionやスクラッチ組織にデプロイして動作確認することが推奨されています。

自然言語指示だけの設計と比較したAgent Script導入で得られる制御性の違い

Agentforceの従来方式では、自然言語によるトピック指示とアクション選択のみでエージェントを構成していました。この方式は導入の敷居が低い反面、応答の再現性や業務ロジックの厳密な実行には限界があります。Agent Scriptによるハイブリッド推論を導入することで、どの程度の制御性向上が見込めるのかを、具体的な比較と業種別の採用実態から検証します。

自然言語プロンプトのみで運用した場合に起きる応答ばらつきの数値的傾向

自然言語指示だけでエージェントを運用した場合、同一の質問に対する応答の一貫性はLLMの確率的な生成プロセスに依存します。Salesforce Engineering Blogでは「LLM reasoning alone cannot carry enterprise load（LLM推論だけではエンタープライズの負荷に耐えられない）」と明言されており、複合的な判定条件が絡む場面では応答精度が大幅に低下するケースが報告されています。特に問題が顕著になるのは、複数の判定条件が絡む場面です。たとえば「返品期限内かつ未開封かつ購入金額が5,000円以上」のような複合条件を自然言語で指示した場合、LLMが3条件すべてを漏れなく評価する保証はなく、条件の一部を見落として不正確な判定を下す可能性があります。また、同じ指示を与えても日時やセッションによって応答のフォーマットが変化し、後続システムとの連携で予期しないエラーを引き起こすこともあります。こうした応答ばらつきは、小規模な社内利用では許容できても、顧客対応や金融取引の判定といった業務プロセスでは重大なリスク要因となります。Agent Scriptの決定論的制御を加えることで、判定条件の評価漏れを構造的に排除し、応答の再現性を大幅に向上させることが可能です。

決定論的ガードレールを加えた場合のハルシネーション抑制とコンプライアンス効果

Agent Scriptによる決定論的ガードレールは、LLMのハルシネーション（事実と異なる情報の生成）を構造的に抑制する手段として機能します。具体的には、アロー記法で「データベースから取得した情報のみをプロンプトに含める」という制約を記述すれば、LLMが自ら情報を生成する余地がなくなり、ソースに基づかない回答が発生するリスクが低減されます。コンプライアンス面では、規制対応が必要な処理ステップを決定論的ブロックとして実装することで、監査証跡としてのトレーサビリティが確保されます。たとえば、金融商品の推奨を行うエージェントの場合、「リスク許容度の確認→適合性判定→免責事項の表示」という一連のプロセスをアロー記法で固定し、LLMにはリスク許容度の聞き取り部分のみを委ねる設計が考えられます。この方式であれば、適合性判定のステップが飛ばされることはなく、免責事項の表示もプログラムで保証されます。コンプライアンス担当者が監査を行う際にも、Agent Scriptのソースコードとデバッグログを照合することで「このエージェントは規定のプロセスを必ず通過する」ことを技術的に証明できる点が大きな利点です。

医療・防衛・金融など誤分類が許容できない業種でのAgent Script採用事例

Agent Scriptの採用が特に進んでいるのは、応答の誤りが重大な結果を招く業種です。Salesforceは米国陸軍との56億ドル規模の契約を締結しており、防衛分野ではエージェントの判定ミスやハルシネーションが許容されないため、ハイブリッド推論による決定論的制御が不可欠な要件とされています。医療分野では、患者のトリアージ（緊急度判定）にエージェントを活用するケースで、症状の分類ルールを決定論的に定義し、判定結果に基づく対応手順もプログラムで固定する設計が検討されています。金融分野では、取引の異常検知やKYC（本人確認）プロセスにおいて、規制上必須のチェック項目をAgent Scriptの条件分岐で実装し、LLMには顧客とのコミュニケーション部分のみを委ねるハイブリッド構成が一般的です。これらの業種に共通するのは、「判定の根拠を後から説明できること」という説明責任の要件であり、Agent Scriptのトレースデータとデバッグログがその要件を技術的に満たす基盤として評価されています。一方で、誤分類のリスクが低い業種、たとえば社内の一般的な問い合わせ対応などでは、Agent Scriptの導入メリットよりも設計・保守の追加コストが上回る場合もあります。

ローコードCanvas設計で十分な業務と、Script記述が必要になる複雑度の判断基準

すべてのエージェントにAgent Scriptが必要なわけではなく、業務の複雑度に応じてローコードCanvasとScriptビューを使い分ける判断が重要です。ローコードCanvas設計で十分に対応できるのは、トピック数が3以下で条件分岐がほとんどなく、呼び出すアクションの種類も限られているシンプルなエージェントです。たとえば、FAQナレッジベースの検索と回答、単一プロセスの案内（パスワードリセット手順の説明など）、定型的な情報収集フォームの対話といったユースケースが該当します。一方、Script記述が必要になるのは以下の条件に該当する場合です。条件分岐が3段階以上にネストする、複数のトピックを横断する対話フローが存在する、アクションの実行順序が厳密に規定されている、特定の処理ステップの実行を監査上保証する必要がある、LLMに渡すコンテキストを動的に構築する要件がある、といった場面ではAgent Scriptの制御力が不可欠です。判断に迷う場合は、まずCanvasで構築してシミュレーションテストを繰り返し、応答のばらつきや制御の不足が確認された段階でScriptビューへ移行するアプローチが現実的です。この段階的アプローチは開発コストの最適化にもつながります。

段階的移行で失敗しないための既存トピック棚卸しと優先度付けの手順

既存のAgentforceエージェントをAgent Scriptへ移行する際、一度にすべてのトピックを書き換えるのはリスクが高く、段階的な移行が推奨されます。まず最初に行うべきは、既存のトピック棚卸しです。現在のエージェントが持つすべてのトピックを一覧化し、各トピックの対話件数、エスカレーション率、顧客満足度スコアを集計します。次に、各トピックを「Agent Script化の優先度」で3段階に分類します。優先度高は、エスカレーション率が高いまたはコンプライアンス要件があるトピックで、決定論的制御の恩恵が最も大きい領域です。優先度中は、条件分岐が複雑で応答ばらつきが確認されているトピックで、Script化によって精度改善が見込めます。優先度低は、現状のローコード設計で十分に機能しているトピックで、移行の必要性が低い領域です。移行作業では、優先度高のトピックから着手し、サンドボックス環境でAgent Scriptへの書き換えとテストを行った後、本番環境にデプロイします。各トピックの移行完了後は、Observabilityダッシュボードで移行前後の精度指標を比較し、改善が確認されてから次のトピックに進む流れが安全です。全トピックの移行完了を急がず、効果の高い領域から着実に成果を積み上げるアプローチが失敗を防ぐ鍵となります。

Enterprise以上で始めるAgentforce導入ステップとコスト構造の実態

Agentforceを活用するにはSalesforceのEnterprise Edition以上が必要であり、Agent Scriptと新Agentforce Builderの利用にも同等のエディション要件が適用されます。導入を検討する企業にとって、エディション選定・課金モデルの理解・実際のデプロイ手順・運用後の最適化までを見通すことが、投資対効果を最大化する鍵となります。

Enterprise・Performance・Unlimited・Developerの4エディション別に見る利用可能範囲

新Agentforce Builderは、Enterprise、Performance、Unlimited、Developer Editionで利用可能であり、利用時には標準のAgentforceおよびGenerative AIクォータが消費されます。各エディションごとに利用可能な機能範囲や制限が異なるため、組織の規模と要件に合わせた選定が重要です。

Developer Editionは無料でAgent Scriptの構文を試すことができるため、PoC（概念実証）段階での検証に適しています。ただし、本番運用にはEnterprise以上のライセンスとAgentforceアドオンまたはFlex Creditsの購入が必要です。Starter・Pro・Foundationsエディションではエージェント構築機能が制限されるため、Agentforceの本格活用を前提とする場合はEnterprise以上の契約を計画に含める必要があります。また、Data Cloud連携やObservability機能を最大限に活用するには、追加のData Cloudクレジットが必要になる場合もあるため、基盤ライセンスだけでなく関連サービスの費用も事前に把握しておくことが重要です。

Flex Credits課金・会話単価$2・ユーザー月額$125の3モデル比較と選定基準

Agentforceの課金モデルは2025年に大幅に整理され、現在は3つの選択肢が用意されています。それぞれの特性を理解し、自社のユースケースに最適なモデルを選定することが、コスト管理の第一歩です。

Flex Creditsは2025年5月に導入された比較的新しいモデルで、エージェントが実行する個別アクション（レコード更新、ケースサマリー生成、フロー実行など）ごとにクレジットを消費します。Pay-as-you-go、Pre-commit、Pre-purchaseの3つの契約形態があり、利用量の予測精度に応じて選べます。会話課金の$2/会話モデルは顧客向けチャットボットに適していますが、1会話内で多数のアクションを実行するケースではFlex Creditsのほうがコスト効率に優れます。ユーザー月額$125はエージェント利用が日常業務に組み込まれている場合に最もシンプルな選択であり、利用量を気にせず展開できる安心感があります。さらに包括的なAgentforce 1 Edition（$550/ユーザー/月）には、年間100万Flex Creditsと250万Data Cloudクレジットが含まれ、大規模導入での一括管理に適しています。

Data Cloudクレジットやプラットフォーム基盤費用を含めた初年度TCOの試算方法

Agentforceの総所有コスト（TCO）を正確に見積もるには、エージェント関連費用だけでなく、プラットフォーム基盤の費用も含めた包括的な計算が必要です。まず基盤コストとして、Salesforce Enterprise Editionのライセンス費用（1ユーザーあたり月額$175〜）が発生します。ここにAgentforceアドオン（月額$125/ユーザー）またはFlex Creditsの購入費用が加算されます。さらに、エージェントがData Cloudを活用してユーザーデータを参照する場合は、Data Cloudクレジットの消費量に応じた追加費用が発生します。無料枠として25万クレジットが含まれますが、大量のデータ処理を行う場合は追加購入が必要になる可能性があります。初年度には上記に加え、実装パートナーへの導入支援費用（基本的なQuickstartパッケージで$2,000〜$6,000程度/エージェント）、管理者・開発者のトレーニング費用、テスト期間中のサンドボックス環境費用も考慮すべきです。TCO試算の計算式は「基盤ライセンス＋Agentforceアドオン＋消費ベースクレジット＋導入支援＋トレーニング＋初年度メンテナンス」となります。試算段階ではFlex Creditsの消費量を正確に予測するのが難しいため、パイロット期間の実績データを基に3ヶ月分の平均消費量を算出し、年間コストを推定するアプローチが実務的です。

Agentforce Studioでのエージェント作成から本番デプロイまでの5ステップ手順

Agentforceエージェントの構築から本番環境へのデプロイまでは、以下の5つのステップで進行します。

1. Salesforce Setupの「Agentforce」を検索してAgentforceを有効化し、Einstein Agent Userプロファイルを設定する。Experience Cloud経由でデプロイする場合はサイトの公開準備も行う。
2. Agentforce Studioから「New Agent」をクリックし、エージェントタイプの選択（既存テンプレートまたはカスタム）→トピック定義→アクション追加→チャネル設定のガイド付きセットアップを完了する。
3. 新Agentforce Builderでトピックの指示文を記述し、必要に応じてAgent ScriptのScriptビューで条件分岐やアクション呼び出しを追加する。Canvas表現でフロー全体を確認し、整合性を検証する。
4. ワンクリックシミュレーションで想定シナリオをテストし、デバッグパネルでトレースデータを確認する。Agentforce Testing Centerでバッチテストも実施し、複数パターンでの応答精度を検証する。
5. テスト結果に問題がなければエージェントを有効化し、設定したチャネル（Webサイト、Slack、CRM画面）にデプロイする。本番環境での動作確認後、Observabilityダッシュボードで継続的にモニタリングを開始する。

各ステップの所要時間はエージェントの複雑さによって大きく異なりますが、単純なFAQエージェントであれば数時間、複数トピック・複数アクションを持つ業務エージェントであれば数日から数週間が目安です。本番デプロイ後も継続的な改善が前提であるため、初回デプロイ時点で完璧を目指すよりも、MVPとして素早くリリースし、実際の利用データに基づいて改善を重ねるアジャイルなアプローチが推奨されます。

Observabilityダッシュボードを使ったエージェント精度のKPI設計と改善サイクル

Agentforce Observabilityは2025年11月に一般提供が開始された分析・最適化機能であり、エージェントの本番運用後の継続的改善に不可欠なツールです。ダッシュボードでは、総セッション数、解決率（エスカレーションせずに完了した割合）、平均レイテンシ、会話品質に関する課題ポイントなどの主要指標が一覧表示されます。KPI設計にあたっては、まず解決率を最優先指標に設定することが推奨されます。解決率が低いトピックは、Agent Scriptの条件分岐の不備、LLMへの指示の曖昧さ、アクションの入出力設計の問題のいずれかに起因している可能性が高く、トレースデータの詳細分析によって原因を特定できます。次に平均レイテンシは、ユーザー体験に直結する指標であり、特定のアクション呼び出しに時間がかかっている場合はApexコードの最適化やFlowの簡素化を検討します。改善サイクルとしては、週次でObservabilityのデータをレビューし、解決率が低いトピックのtop3を抽出して改善計画を立て、サンドボックスで修正・テスト後に本番デプロイするという反復プロセスが効果的です。Data 360（旧Data Cloud）に蓄積された会話ログは、改善の根拠となる定量データの宝庫であり、定性的な印象に頼らないデータドリブンな最適化を可能にします。

顧客対応・業務自動化の精度を上げるAgent Script活用パターンと運用改善の着眼点

Agent Scriptの真価は、理論的な理解だけでなく、実際の業務シナリオに適用して初めて発揮されます。顧客対応の自動化、営業プロセスの効率化、マルチエージェント構成の安定化といった具体的なユースケースにおいて、Agent Scriptのハイブリッド推論がどのように機能し、運用開始後にどのような課題が発生しやすいかを把握することが、導入効果を最大化するための鍵です。

カスタマーサービス領域で注文照会・認証・エスカレーションを1スクリプトに統合する例

カスタマーサービスは、Agent Scriptのハイブリッド推論が最も効果を発揮する領域の1つです。典型的なユースケースとして、顧客が注文状況を問い合わせる対話フローを考えてみましょう。まずstart_agentで顧客の発話意図を判定し、注文関連であれば「Order Inquiry」トピックへ遷移します。このトピック内では、最初にアロー記法で認証状態を確認し、未認証であれば@utils.transitionで「Customer Authentication」トピックへ遷移させます。認証トピックではメールアドレスの入力を求め、Apexアクションで顧客情報をSalesforce上のレコードと照合する処理を決定論的に実行します。認証完了後は注文照会トピックへ戻り、Flowアクションで該当顧客の注文一覧を取得してパイプ記法でLLMに提示します。LLMは取得データに基づいて自然な言葉で注文状況を顧客に説明し、解決しない場合はアロー記法の条件分岐で人間のオペレーターへエスカレーションする処理が自動実行されます。このフローにおいて、認証・データ取得・エスカレーション判定はすべて決定論的に処理され、LLMが担うのは対話の自然さと顧客への説明部分に限定されます。

営業リード判定にApexスコアリングロジックを組み込む場合の変数設計と閾値設定

営業領域では、リードの質を自動判定するスコアリングエージェントにAgent Scriptを活用できます。具体的な変数設計として、まず入力変数にleadId（対象リードのID）、budget（予算額）、timeline（導入検討期間）、authority（意思決定権限の有無）を定義します。Apexアクションとして実装したLeadScoreCalculatorクラスがこれらの入力を受け取り、BANT基準に基づいて0〜100のスコアを算出します。Agent Scriptのinstructionsブロックでは、アロー記法で「スコアが80以上であればHot Lead、50〜79であればWarm Lead、50未満であればCold Lead」という閾値判定を決定論的に実行し、判定結果に応じてリードのステータスフィールドを更新するFlowアクションを呼び出します。この判定ロジックをLLMに任せるのではなく決定論的コードで固定することで、閾値の変更が必要になった場合もスクリプトの数値を書き換えるだけで済み、LLMの再調整が不要になります。パイプ記法では、判定結果を踏まえた営業担当者への通知メッセージをLLMに生成させ、リードの特徴を自然な文章でサマリーとして提示します。スコアリングの閾値は四半期ごとにObservabilityデータと実際の成約率を照合し、最適値を更新する運用が推奨されます。

マルチエージェント構成でトピック委任と復帰制御を安定させるアーキテクチャ設計

大規模なビジネスプロセスでは、単一のエージェントですべてを処理するのではなく、複数のエージェントが協調して動作するマルチエージェント構成が求められます。Agent Scriptでは、トピック遷移（@utils.transition）とトピック委任（Topic Delegation）の2つのメカニズムでこの構成を実現します。通常のトピック遷移は一方向であり、遷移先の処理が完了しても元のトピックには自動復帰しません。一方、トピック委任を使うと、委任先のトピックが処理を完了した後に元のトピックへ制御を返すことが可能です。たとえば、メインの受注処理エージェントが在庫確認のためにサブエージェントのトピックに処理を委任し、在庫情報を取得した後にメインの受注処理へ復帰するフローが実現できます。この設計で安定性を確保するためのポイントは3つあります。1つ目は委任先トピックの責務を単一目的に限定し、予測可能な出力を保証すること。2つ目は委任先での例外処理を明示的に定義し、タイムアウトやエラー時の挙動を決定論的に制御すること。3つ目は各エージェント間で共有する変数のスコープを最小限にし、意図しない変数の上書きを防ぐことです。Architectural Recipesのサンプルコードには、この構成パターンの実装例が含まれているため、参考にするとよいでしょう。

本番運用後に発覚しやすいプロンプト肥大化とレイテンシ悪化への対処パターン

Agent Scriptの本番運用を開始した後に頻出する問題として、プロンプトの肥大化に伴うレイテンシの悪化があります。開発段階では少数のテストケースで快適に動作していたエージェントが、本番環境で多様な顧客データを扱うようになると、{! }式テンプレートで動的に構築されるプロンプトのサイズが想定以上に膨らむケースがあります。たとえば、顧客の過去の問い合わせ履歴をすべてプロンプトに含める設計をしていた場合、履歴が数十件に及ぶ顧客に対してはプロンプトが数千トークンに達し、LLMの処理時間と消費クレジットの両方が増大します。対処パターンとして、まずプロンプトに含めるデータ量を条件分岐で制限することが基本です。直近5件の履歴のみを含める、または文字数の上限を設定してサマリー化するロジックをアロー記法で実装します。次に、Observabilityダッシュボードのレイテンシデータを分析し、処理時間が閾値を超えるトピックを特定して個別に最適化します。さらに、Apex側でSOQLクエリの結果を事前にフィルタリングし、エージェントに渡すデータ量そのものを削減するアプローチも有効です。定期的なプロンプトサイズの監視と、レイテンシのSLA（応答時間の目標値）に基づくアラート設定を運用プロセスに組み込むことで、問題の早期検知と迅速な対応が可能になります。

Agentforce Observabilityの会話ログ分析からトピック指示を改善した定量的成果の例

Agentforce Observabilityが提供する会話ログは、エージェントの改善機会を定量的に特定するための最も重要なデータソースです。Data 360に蓄積されたログには、各セッションのトピック遷移履歴、選択されたアクション、LLMの推論ステップ、顧客のフィードバック（エスカレーションの有無）が含まれています。実務的な分析手順として、まず解決率の低いトピックを抽出し、そのトピック内で最もエスカレーションが発生している対話パターンを特定します。次に、該当するセッションのトレースデータを確認し、LLMがどのステップで誤った判断を下しているかを調べます。たとえば、カスタマーサービスエージェントで「返品理由の分類」トピックの解決率が低迷している場合を想定しましょう。トレース分析の結果、LLMが「商品不良」と「サイズ違い」の2つの理由を混同していることが判明したとします。Agent Scriptの条件分岐に「返品理由カテゴリの明示的な選択肢提示」と「選択結果に基づく決定論的な分岐」を追加することで、LLMの曖昧な分類を排除し解決率の大幅な改善が期待できます。実際に、Salesforceの事例紹介では、1-800-Accountant社がObservabilityによる完全な可視化を通じてサービスリクエストの90%を自律的に処理する目標を掲げていると報告されています。このように、Observabilityのデータは「何が問題か」だけでなく「なぜ問題が起きているか」の根本原因を特定する手がかりを提供し、Agent Scriptの決定論的制御を追加することで定量的な改善を実現できます。改善効果の数値は、次の改善サイクルの優先度判断にも活用でき、データドリブンな運用改善の好循環を生み出します。