Agent Scriptとは｜Agentforceのハイブリッド推論を制御するDSLの構文と実装【2026年版】

Agent Scriptは、SalesforceがDreamforce 2025で発表した、Agentforce上でAIエージェントの挙動を制御するためのドメイン固有言語（DSL）です。自然言語の指示だけでLLMにエージェントを任せる従来方式は、応答のばらつきと業務ルールの遵守漏れという課題を抱えていました。Agent Scriptは、決定論的なプログラムロジックとLLMの推論を同一ファイルで組み合わせる「ハイブリッド推論」でこの課題を解き、業務クリティカルな処理にエージェントを組み込めるようにします。この記事では、開発者が最初に押さえるべきアロー記法・パイプ記法の構文、start_agent／subagentブロックの構造、Agent Script Recipes、エディションと課金、導入判断までを、実際のコード例とともに整理します。なお会話領域を定義するブロックは現在subagentで、旧称のtopicから改称されています（概念を指す際は本文でも「トピック」と表記します）。

まとめ：Agent Scriptの要点

• 正体：Agentforceのエージェント挙動を記述するDSL。決定論ロジック（アロー記法 ->）とLLMプロンプト（パイプ記法 |）を1ファイルで共存させ、Atlas Reasoning Engineが実行する。
• 構文の骨格：config・system・start_agent・subagentの各ブロックで構成し、reasoning内のinstructionsとactionsでエージェントの1ターンを定義する。
• 学習リソース：公式サンプル集trailheadapps/agent-script-recipesが4カテゴリ・20超の例を提供。「agent script recipes」で探す実装者はここへ誘導する。
• 使いどころ：条件分岐が複雑・複数トピックをまたぐ・コンプライアンス要件がある業務で効く。単純なFAQボットはローコードCanvasで十分。
• 導入前提：Enterprise Edition以上＋AgentforceアドオンまたはFlex Credits。Developer Editionで無料検証が可能。

Agent Scriptとは｜LLM単体運用の限界を補うハイブリッド推論DSL

Agent Scriptの設計思想を理解する出発点は、「なぜLLMへの自然言語指示だけでは足りないのか」という問いです。ここでは、DSLとして設計された背景、決定論ロジックとプロンプトを共存させる言語構造、そして実行を担うAtlas Reasoning Engineとの関係を押さえます。

DSL化の背景にあるLLM単体運用の3つの限界

LLMだけでエージェントを動かすと、まず応答の一貫性が崩れます。同じ入力でも生成のたびに応答が変わり、顧客対応や業務処理のように再現性が要る場面では致命的です。次にビジネスルールの遵守が保証されません。「10万円以上は必ず上長承認」というルールを自然言語で伝えても、LLMが100%守る保証はありません。3つ目は処理フローの可視性で、なぜその応答に至ったかを追跡しづらく、金融・医療・防衛のような規制業界では監査上の障壁になります。Salesforceはこの3点を汎用言語ではなくエージェント制御に特化したDSLで補う設計を選びました。宣言的で読みやすい構文を保ちつつ、条件分岐やアクション呼び出しを確定的に記述できる点が核です。

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

Agent Scriptの特徴は、1つのスクリプト内でプログラムコードと自然言語プロンプトを分離しつつ共存させる点にあります。アロー記法（->）の行は上から順に確実に実行される手続き型ロジック、パイプ記法（|）の行はLLMへ送るプロンプトテキストとして組み立てられます。スクリプトは直接実行されるのではなく、Agent Graphと呼ばれる構造化された実行仕様にコンパイルされ、これをAtlas Reasoning Engineが解釈して実行します。ソースは拡張子.agentのテキストファイルで、Gitでのバージョン管理やレビューにそのまま乗せられます。次のコードが最小構成の骨格で、configでエージェントの識別情報、systemでグローバル指示、start_agentで入口、subagentで会話領域（サブエージェント）を定義します。

config:
   developer_name: "Order_Support_Agent"
   agent_type: "AgentforceServiceAgent"

system:
   messages:
      welcome: "ご注文についてお手伝いします。"
      error: "エラーが発生しました。"
   instructions:|
      あなたは丁寧な注文サポート担当です。
      最初に必ず本人確認を行ってください。

start_agent router:
   description: "ユーザーの意図を判定してサブエージェントへ振り分ける"
   reasoning:
      actions:
         go_order: @utils.transition to @subagent.order_status
            description: "注文状況に関する問い合わせ"

subagent order_status:
   description: "注文状況の確認を担当"
   reasoning:
      instructions:->
         | お客様の注文についてお手伝いします。

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

Atlas Reasoning EngineはAgentforceの中核となる推論エンジンで、Agent Scriptによって挙動を構成可能（configurable）になった点が大きな進化です。ユーザーがメッセージを送ると、まずstart_agentが実行され、変数の初期化とトピックの振り分けが行われます。続いて該当トピックのreasoning内instructionsが上から処理され、このときアロー記法の部分はエンジンが決定論的に評価し、パイプ記法の部分はプロンプトとしてLLMへ渡されます。つまり推論ステップごとに「プログラムが判断する箇所」と「LLMが判断する箇所」が自動で切り替わります。@utils.transitionによるトピック遷移は一方向で、遷移先の処理が終わっても元のトピックには自動では戻りません。この設計により、処理の流れが予測可能でデバッグしやすくなります。

アロー記法・パイプ記法で書くAgent Scriptの基本構文

ここからは開発者が最初に習得すべき構文パターンを、実際のコードで確認します。エージェントの挙動はsubagentブロック単位で定義し、その中のreasoningブロックがオーケストレーション層として機能します。「agent script developer guide」で検索する読者が求める、記法の使い分けとアクション設計の実体がここにあります。

アロー記法（->）とパイプ記法（|）で決定領域とプロンプト領域を分ける

Agent Scriptで最初に理解すべきは、|（パイプ）と->（アロー）の役割分担です。パイプ記法で書いたテキストは実行時にプロンプトの一部としてLLMへ送信され、自然言語で柔軟な対話指示を書けます。一方、アロー記法の行はAtlas Reasoning Engineが決定論的に処理するコードとして扱われ、条件分岐・変数代入・アクション呼び出しが上から順に確実に実行されます。instructions:->と書くと手続きモードに入り、ifによる条件分岐とプロンプト行を交互に配置できます。次の例では、注文IDが存在する場合だけプロンプトに番号を差し込んでいます。この「必要な情報だけをLLMに渡す」形が、ハルシネーションの抑制とコンテキスト精度の向上につながります。

reasoning:
   instructions:->
      | 顧客の注文についてサポートしてください。
      if @variables.order_id != "":
         | 現在の注文番号は {[email protected]_id} です。
      | 不明点があれば必要な情報を確認してください。

{! }フォーミュラでLLMへ渡すコンテキストを実行時に動的構築する

パイプ記法のプロンプト内では、{! }フォーミュラで変数や式の値を埋め込めます。単なるテンプレート展開ではなく、コンテキストエンジニアリングの手段です。全情報を一括でLLMに渡す従来方式は不要なノイズが推論精度を下げますが、{! }と条件分岐を組み合わせれば「今この瞬間に必要な情報だけ」をプロンプトに含められます。たとえば過去の問い合わせ履歴が一定件数以上ある顧客にだけ直近サマリーを挿入する、といった動的構築が可能です。プロンプトの肥大化を抑えつつ応答精度を上げ、トークン消費も削減できます。何をコンテキストとして渡すかの設計思想は、Prompt Engineeringとの違いで理解するContext Engineeringの考え方と共通します。

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

Agent Scriptでは、アクションの「定義」と「LLMへの公開」を別の操作として分離します。subagent直下のactionsで各アクションの名前・入力型・出力型・呼び出し先（target）を宣言しますが、この段階ではまだ定義されただけでLLMからは呼べません。LLMに使わせるにはreasoning内のactionsで明示的に公開します。次の例では、Flowを呼ぶget_orderを宣言し、reasoningで@actions.get_orderとして公開しています。with order_id=...の...はLLMが値を埋めるスロットです。この2段階により「宣言はするがLLMには自由に呼ばせたくないアクション」を制御でき、意図しない実行を防ぐガードレールになります。targetには、Apexを呼ぶapex://、Flowを呼ぶflow://、プロンプトテンプレートを呼ぶgeneratePromptResponse://の3種類のスキームを指定でき、外部API連携はApex経由で行います。

subagent order_status:
   description: "注文状況の確認を担当"
   actions:
      get_order:
         description: "注文IDから注文詳細を取得"
         inputs:
            order_id: string
         outputs:
            status: string
         target: "flow://Get_Order_Details"
   reasoning:
      instructions:->
         | お客様の注文状況をお調べします。
      actions:
         lookup: @actions.get_order
            with order_id=...

if/then条件分岐と@utils.transitionでトピック間遷移を書く

条件分岐はreasoningのinstructions内でアロー記法を使って書き、トピック遷移には@utils.transition to @subagent.遷移先を使います。LLMに選ばせる遷移はreasoningのactionsに置き、available whenで有効条件を絞れます。次の例は、本人確認済みなら返品用サブエージェント、未確認なら認証用サブエージェントへ遷移させる分岐です。@utils.transitionは即座に実行され、元トピックの後続行は処理されないため、遷移前に必要な前処理は先に済ませます。頻出する条件を上位に置くと不要な評価を減らせます。

reasoning:
   actions:
      go_returns: @utils.transition to @subagent.returns
         description: "返品対応へ遷移"
         available when @variables.is_verified == True
      go_auth: @utils.transition to @subagent.verification
         description: "本人確認へ遷移"
         available when @variables.is_verified == False

新Agentforce Builderの2ビューとAgentforce Vibesで変わる開発サイクル

Dreamforce 2025で刷新された新Agentforce Builderは、設計・テスト・デプロイを単一ワークスペースに統合し、自然言語のCanvasビューとコードのScriptビューを切り替えられます。ここでは2ビューの使い分け、テスト工数削減、JSONによるバージョン管理、そしてコード生成を担うAgentforce Vibesを整理します。

ローコードCanvasとコードScriptの2ビュー＋Agentforce Assistantの使い分け

Canvasビューは、トピックやアクションの関連をドラッグ＆ドロップで組みながら自然言語で挙動を記述するビジュアル編集環境で、技術背景のないビジネスユーザーでも初期設計を行えます。Scriptビューは、Agent Scriptの構文をシンタックスハイライトとリアルタイムバリデーション付きで直接編集する開発者向けモードです。両ビューは同一のエージェント定義を別表現で示すため、切り替えてもデータは失われません。加えてビルダー内蔵のAgentforce Assistantが「返品処理の機能を追加して」のような自然言語指示からAgent Scriptを生成します。要件定義段階はCanvasやAssistantで素早くプロトタイプを作り、条件分岐やガードレールを厳密に定義する段階でScriptビューへ移る流れが効率的です。

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

従来は構築・テスト・修正が分離し、1つの挙動を確認するのに画面を行き来する時間がボトルネックでした。新Builderのワンクリックシミュレーションは、エージェントとの対話をその場でプレビューでき、デバッグパネルで各ステップの推論理由・選択されたトピックとアクション・処理時間がステップバイステップで可視化されます。たとえば「注文ステータスの回答が誤ったトピックを経由している」問題も、トレースデータを見ればどのinstructionsでトピック判定を誤ったかを特定でき、修正後は同じ画面で即再テストできます。別環境へデプロイしてから検証する工程が不要になり、プロトタイプ段階の反復が速くなります。

ポータブルJSONとAgentforce DXでエージェント定義をバージョン管理する運用フロー

Agent Scriptの定義は拡張子.agentのテキストファイルとして管理でき、エージェント構成をコードとして扱うDevOpsが可能になります。テキストなので差分比較が容易で、複数メンバーが並行して変更しマージリクエストでレビューする一般的な開発フローに乗せられます（コンパイル結果のAgent Graphが機械可読な実行仕様になります）。実務では、Agentforce DXでローカルのSalesforce DXプロジェクトにスクリプトを取得し、Visual Studio Codeの拡張機能で編集・構文チェックを行い、コミットしてCI/CDに組み込み、サンドボックスへ自動デプロイとテストを回します。組織間でエージェントを共有する場合もスクリプトファイルをインポートするだけで済み、グループ企業への横展開やテンプレート配布が効率化されます。

Agentforce Vibes（旧Agentforce for Developers）で自然言語からLWC・Apexを生成

Agentforce Vibesは、Visual Studio Code拡張として提供されるAI搭載の開発エージェントで、自然言語の指示からLightning Web Components（LWC）やApexを生成します。旧称「Agentforce for Developers」から進化し、オープンソースのAIコーディングエージェントClineのフォークをベースに構築され、Salesforce DX MCP Serverで開発環境と連携します。対象組織のメタデータを読み取り、既存コンポーネントや命名規則を踏まえてコードを出力する点が他ツールとの違いです。提供開始当初は各組織に1日あたりGPT-5の呼び出しが50回割り当てられ、上限到達後はSalesforceがホストするQwen 3.0へ自動フォールバックする仕様でした。ただし2026年6月に課金体系が移行し、Developer Editionの無料枠はClaude Sonnet 4.5ベースの制限付き（およそ110リクエスト・150万トークンの組織あたり累計上限で、毎月リセットされない生涯枠）に変わり、従来のフォールバックは廃止されています。無料枠や利用モデルは変動が速いため、最新は公式のBillingガイドで確認してください。なお、Vibesは主にVS Code上のApex・LWC開発を、前述のAgentforce AssistantはBuilder内でのエージェント設計を支援する役割分担です。

Agent Script Recipesで学ぶ実装パターンと無限ループの回避

「agent script recipes」は、この記事に来る読者が最も多く検索するクエリです。SalesforceはGitHubで公式サンプル集を公開しており、まずここで動くコードを読むのが最短の学習ルートになります。カテゴリ構成と初学者向けの取り組み順、そして実装でつまずきやすい無限ループ・意図ずれの回避策を押さえます。

trailheadapps/agent-script-recipesの4カテゴリと学習順序

公式サンプル集はtrailheadapps/agent-script-recipesリポジトリで提供され、20以上のサンプルが4カテゴリに整理されています。Language Essentials（言語の基礎。helloWorldなど最小構成から学ぶ）、Action Configuration（Apex・Flow・Prompt Templateなど各アクションの設定と呼び出し）、Reasoning Mechanics（決定論的制御をどこまで加えLLMにどこを委ねるかの切り分け）、Architectural Patterns（複数トピックの状態管理やマルチエージェント構成のオーケストレーション）の順に難度が上がります。各レシピは単独で理解できる構成で、専用READMEにフロー概要・主要コンセプト・試行手順が付きます。学習はLanguage EssentialsのhelloWorldから始め、Reasoning Mechanicsでハイブリッド推論の勘所をつかみ、Architectural Patternsへ進むのが定石です。Developer Editionやスクラッチ組織へデプロイして動作を確認できます。

初学者がまず写経すべき実装パターン5選

最短で構文に慣れるには、次の5パターンを順に手を動かすのが効果的です。1つ目はhelloWorldで、config・system・start_agent・subagentの最小構成を体で覚えます。2つ目はアクション呼び出しで、Apex・Flow・Prompt Templateをsubagentから呼び、入出力型を宣言と一致させる基本を学びます。3つ目はreasoningの制御分岐で、アロー記法のifとパイプ記法のプロンプトを交互に置く書き方を身につけます。4つ目は認証フローで、start_agentから認証トピックへ@utils.transitionし、変数で状態を持ち回す全体像を把握します。5つ目はトピック委任（Topic Delegation）で、委任先の処理後に元トピックへ制御を戻すパターンを学びます。いずれも公式レシピに対応する例があり、READMEの概要図から入ると理解が速くなります。

推論ループ・トピック遷移で起きる無限ループと意図ずれの回避策

@utils.transitionによる遷移は一方向で、遷移先の処理が終わっても元トピックには自動で戻りません。これを理解せず「認証→注文照会→認証→…」と組むと循環参照で実質的な無限ループに陥ります。回避の基本は、設計段階でトピック間の遷移マップを図示し循環がないことを確認することです。元トピックへ制御を返す必要がある場合はトピック委任パターンを使います。もう1つの意図ずれは、instructionsが長大になったときに起きます。20行を超える指示はプロンプト総量を増やし優先度が曖昧になるため、1トピックの責務を単一目的に限定し、複雑な処理は複数トピックへ分割して各指示を短く保ちます。Builderのシミュレーションでトレースデータを確認し、各ステップの推論理由を検証する習慣が早期発見に有効です。

自然言語指示のみとの比較で見るAgent Scriptの制御性と採用判断

Agent Scriptを導入すべきかは、自然言語指示のみの方式と比べてどれだけ制御性が上がるか、そして自社の業務がその制御を必要とするかで決まります。応答ばらつきの実態、ガードレールの効果、誤分類が許されない業種の採用背景、そしてCanvasで十分か否かの判断基準を順に見ます。

自然言語プロンプトのみで起きる応答ばらつきと複合条件の評価漏れ

自然言語指示だけの運用では、同じ質問への応答の一貫性がLLMの確率的生成に左右されます。SalesforceのEngineering Blogは「LLM reasoning alone cannot carry enterprise load（LLMの推論だけではエンタープライズの負荷に耐えられない）」と明言しています。問題が顕著になるのは複合条件の場面です。「返品期限内かつ未開封かつ購入金額が5,000円以上」のような複数条件を自然言語で指示しても、LLMが全条件を漏れなく評価する保証はなく、一部を見落として不正確な判定を下しえます。同じ指示でもセッションによって応答フォーマットが変わり、後続システム連携で予期しないエラーを招くこともあります。Agent Scriptの決定論的制御を加えると、判定条件の評価漏れを構造的に排除し、再現性を大きく高められます。

決定論ガードレールによるハルシネーション抑制とコンプライアンス効果

アロー記法で「データベースから取得した情報のみをプロンプトに含める」といった制約を書けば、LLMが自ら情報を生成する余地が減り、ソースに基づかない回答（ハルシネーション）のリスクが下がります。コンプライアンス面では、規制対応が必要なステップを決定論的ブロックとして実装することで監査証跡のトレーサビリティが確保されます。たとえば金融商品を推奨するエージェントなら「リスク許容度の確認→適合性判定→免責事項の表示」をアロー記法で固定し、LLMには聞き取り部分だけを委ねます。これなら適合性判定が飛ばされず、免責表示もプログラムで保証されます。監査時もソースコードとデバッグログの照合で「規定のプロセスを必ず通過する」ことを技術的に証明できます。

医療・防衛・金融など誤分類が許されない業種でのAgent Script採用背景

採用が進むのは、応答の誤りが重大な結果を招く業種です。Salesforceは2026年1月26日に米陸軍と10年・56億ドル規模のIDIQ契約（Missionforce National Security）を締結しており、こうした防衛領域ではエージェントの判定ミスやハルシネーションが許容されないため、決定論的制御が要件になります。医療では患者のトリアージで症状分類ルールを決定論的に定義し対応手順もプログラムで固定する設計、金融ではKYC（本人確認）や異常検知で規制上必須のチェックを条件分岐に実装しLLMには対話部分だけを委ねる構成が検討されています。共通点は「判定の根拠を後から説明できること」という説明責任で、Agent Scriptのトレースデータとデバッグログがその基盤として評価されています。逆に誤分類リスクの低い一般問い合わせでは、導入メリットより設計・保守コストが上回る場合もあります。

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

すべてのエージェントにAgent Scriptが要るわけではありません。ローコードCanvasで十分なのは、トピック数が3以下で条件分岐がほぼなく、呼び出すアクションも限られる単純なエージェントです。FAQナレッジベースの検索回答、パスワードリセット手順の案内、定型の情報収集フォームなどが該当します。一方、次の条件に当てはまる場合はScript記述が要ります。条件分岐が3段階以上ネストする、複数トピックを横断する対話フローがある、アクションの実行順序が厳密に規定される、特定ステップの実行を監査上保証する必要がある、LLMへ渡すコンテキストを動的に構築する要件がある——といった場面です。判断に迷えば、まずCanvasで構築しシミュレーションを繰り返し、応答のばらつきや制御不足が確認された段階でScriptへ移る段階的アプローチが現実的で、開発コストも抑えられます。エージェント全体をどう分割するかはマルチエージェントの構成パターンの観点も参考になります。

Agentforce導入のエディション・課金モデルとコスト構造の実態

Agent Scriptと新Agentforce Builderを本番で使うには、Salesforceのエディション要件と課金モデルの理解が欠かせません。エディション別の利用範囲、3つの課金モデル、Data Cloudを含むTCO、そして作成からデプロイ・改善までの運用を整理します。

Enterprise・Performance・Unlimited・Developerのエディション別利用範囲

新Agentforce BuilderはEnterprise・Performance・Unlimited・Developer Editionで利用でき、利用時に標準のAgentforceおよびGenerative AIクォータを消費します。Developer Editionは無料でAgent Scriptの構文を試せるため、PoC（概念実証）に適します。ただし本番運用にはEnterprise以上のライセンスとAgentforceアドオンまたはFlex Creditsの購入が必要です。Starter・Pro・Foundationsではエージェント構築機能が制限されます。

Flex Credits・会話課金・ユーザーライセンスの3課金モデル比較と選定基準

Agentforceの課金は3系統に整理されています。Flex Creditsは消費ベースで、標準アクションは20クレジット（約$0.10）、音声アクションは30クレジット（約$0.15）を消費し、クレジットは10万単位で$500程度が目安です。会話課金は顧客向けチャットボット向けで24時間の1セッションあたり約$2。ユーザーライセンスは、Flex Creditsの利用を前提とするAgentforce User License（約$5/ユーザー/月）、無制限利用のAgentforceアドオン（約$125〜$150/ユーザー/月）、Flex CreditsとData 360クレジットを同梱するAgentforce 1 Edition（$550〜/ユーザー/月）があります。注意点として、Flex Creditsと会話課金は同一組織内で併用できません。1会話で多数のアクションを実行するならFlex Creditsが有利で、単純な問い合わせ主体なら会話課金がわかりやすく、社内全員が日常的に使うならユーザーライセンスが管理しやすい、という選び分けになります。

Data Cloudクレジットを含む初年度TCOの試算方法

総所有コスト（TCO）はエージェント費用だけでなく基盤費用も含めて見積もります。基盤としてSalesforce Enterprise Editionのライセンス（1ユーザー月額$175〜）が発生し、そこにAgentforceアドオンまたはFlex Creditsの購入費が加わります。エージェントがData Cloudでユーザーデータを参照する場合は、消費量に応じたData Cloudクレジット費用も乗ります。初年度はさらに、実装パートナーへの導入支援（基本的なQuickstartでエージェントあたり$2,000〜$6,000程度）、管理者・開発者のトレーニング、テスト期間のサンドボックス費用も見込みます。試算式は「基盤ライセンス＋Agentforceアドオン＋消費ベースクレジット＋導入支援＋トレーニング＋初年度メンテナンス」。Flex Creditsの消費量は事前予測が難しいため、パイロット期間の実績から平均消費量を出して年間コストを推定するのが実務的です。

作成から本番デプロイまでの手順とObservabilityによるKPI改善サイクル

構築からデプロイまでは、（1）Setupで「Agentforce」を有効化しEinstein Agent Userを設定、（2）Agentforce Studioで新規エージェントを作成しトピックとアクション、チャネルを設定、（3）新BuilderでトピックをCanvas／Scriptで記述し整合性を検証、（4）ワンクリックシミュレーションとTesting Centerのバッチテストで応答精度を検証、（5）問題がなければ有効化しWebやSlack、CRM画面へデプロイ、という5ステップが基本です。デプロイ後はAgentforce Observability（2025年11月に一般提供）で継続改善します。ダッシュボードには総セッション数・解決率・平均レイテンシ・会話品質の課題が表示され、まず解決率を最優先KPIに置きます。解決率が低いトピックは条件分岐の不備・指示の曖昧さ・入出力設計のいずれかに起因することが多く、トレースデータで原因を特定できます。週次で解決率の低いトピック上位を抽出し、サンドボックスで修正・テストして本番へ反映する反復が効果的です。Salesforceの事例では、1-800-Accountant社がObservabilityによる可視化でサービスリクエストの90%を自律処理する目標を掲げていると報告されています。

よくある質問

Agent Scriptとは何ですか

SalesforceがDreamforce 2025で発表した、Agentforce上のAIエージェントの挙動を制御するドメイン固有言語（DSL）です。決定論的なプログラムロジック（アロー記法 ->）とLLMへのプロンプト（パイプ記法 |）を同一ファイルで共存させる「ハイブリッド推論」を実現し、応答のばらつきや業務ルールの遵守漏れを構造的に抑えます。

Agent Script Recipesはどこで入手できますか

GitHubのtrailheadapps/agent-script-recipesリポジトリで公開されています。Language Essentials・Action Configuration・Reasoning Mechanics・Architectural Patternsの4カテゴリに20超のサンプルが整理され、各例に概要と試行手順のREADMEが付きます。Developer Editionやスクラッチ組織にデプロイして動作を確認できます。

Agent Scriptを使うのに必要なSalesforceエディションは何ですか

新Agentforce BuilderとAgent ScriptはEnterprise・Performance・Unlimited・Developer Editionで利用できます。Developer Editionは無料で構文を試せるためPoCに向きますが、本番運用にはEnterprise以上のライセンスに加え、AgentforceアドオンまたはFlex Creditsの購入が必要です。Starter・Pro・Foundationsではエージェント構築機能が制限されます。

Agent ScriptとAgentforce Vibesはどう違いますか

Agent Scriptはエージェントの挙動そのものを記述するDSLで、Builder内のScriptビューで編集します。Agentforce Vibesは、VS Code拡張として自然言語からLWCやApexを生成する開発エージェント（旧Agentforce for Developers）です。Builder内でエージェント設計を支援するのはAgentforce Assistant、VS CodeでApex・LWC開発を支援するのがVibes、という役割分担です。

アロー記法とパイプ記法はどう使い分けますか

アロー記法（->）は、条件分岐・変数代入・アクション呼び出しなど決定論的に確実に実行したいロジックに使います。パイプ記法（|）は、LLMへ送るプロンプトテキストに使い、自然言語で柔軟な指示を書きます。instructions:->ブロック内で両者を交互に配置し、{! }で必要な変数だけをプロンプトへ差し込むのが基本形です。

関連記事

• 金融DX担当者が押さえるべきAgentforce 360の基本構造と位置づけ
• マルチエージェントとは？仕組み・構成パターンと採用判断を実装者視点で解説【2026年版】
• シングルエージェントとマルチエージェントの違い｜使い分けの判断基準とコスト・失敗モード【2026年版】
• Prompt Engineeringとの違いで理解するContext Engineeringの本質と全体像