対象読者: Agentforce 導入支援・インプリメンテーションベンダー、アーキテクト
目的: 新リリースが従来の GUI・Topic・Action に与える影響の整理、および「一つの指示で複数同期/非同期処理」を Agent Script だけで実現できるか、個別ワークフローや Chat カスタマイズがどこまで必要かを分析・記事化する。
1. リリース概要
Salesforce は Agent Builder（新 Agentforce Builder）、Studio、Agent Script をリリースした（Dreamforce 2025 発表、日本では 2026年2月頃提供開始）。
2. 従来の GUI・Agent Topic・Action への影響
2.1 構成の変化（Explorer）
新 Builder では左パネル Explorer により、従来の設定が次のように再編されている。
2.2 Topic の変更点
- Classification Description と Scope の統合
従来の「どう分類するか」と「この Topic で何をするか」が Topic の単一説明 に統合された。Topic 間遷移が追加されたことで「最初の分類」だけでなく「遷移先」で役割が分かれるため、説明の重複を避ける設計になっている。
- Topic 間遷移
Agent Script の transition to @topic.XXX により、一つの会話フロー内で複数 Topic を順に経由 できる。従来の「1発話＝1 Topic」の制約が緩和されている。
- Off Topic
従来は内部扱いで非表示だった Off Topic が、新 Builder では 明示表示・カスタマイズの可能性 が示唆されている（GA 時点の仕様要確認）。
2.3 Action の扱い
- Topic 経由の紐付けは維持
Action は引き続き Topic に紐づく。Agent 直結ではなく「Topic → Actions」の階層はそのまま。
- Agent Script からの呼び出し
Instructions 内で run @actions.XXX により、順次実行・条件付き実行・Follow-up 実行 が記述可能。従来の「LLM が選んで実行」に加え、決定論的な Action チェーン が書ける。
まとめ: 従来の GUI・Topic・Action の概念は残しつつ、設定の統合・遷移の追加・決定論的制御 で拡張されている。既存の Topic/Action 設計は活かしつつ、Script で制御を強化する移行が想定される。
3. 複雑エージェント — 一つの指示で複数同期/非同期処理
3.1 Agent Script でできること（同期・順次・条件）
これらは すべて「1 リクエスト・1 レスポンス」の枠内 で完結する。つまり「一つのユーザー発話」に対して、複数の同期処理を順番に実行する ことは Agent Script のみで実現可能。
3.2 Agent Script の実行モデルと「非同期」の位置づけ
- フロー制御
Reasoning instructions は 上から下に逐次実行 され、run / set / if / transition は LLM にプロンプトを送る前 に解決される。Action の呼び出しは 同期的（そのターンで結果が返る前提）。
- 長時間・バックグラウンド処理
Agent Script 自体には「Queueable を起動して後で結果を取得する」という 言語レベルでの非同期プリミティブはない。
非同期にしたい場合は、Action の実装側（Flow / Invocable Apex）で Queueable や Batch を起動し、その Action の戻り値（例: 実行ID）だけをエージェントが受け取る形になる。
「結果の確認」は 別ターン（ユーザーが「状態を教えて」と発話 → 状態確認用 Action を呼ぶ）で行う設計になる。
3.3 個別 Agent ワークフロー・Chat カスタマイズとの役割分担
結論（複雑処理）:
- 同期・順次・条件分岐・Topic 遷移 → Agent Script だけで実現可能。
- 非同期・長時間・「開始→後で結果確認」 → Agent Script は「開始用 Action」「状態確認用 Action」を 呼び出す側 として使え、実行の実体（Queueable、状態管理、ポーリング）は Action/オーケストレーション側 で実装する必要がある。
4. Agentforce Orchestration と Agent Script — 詳細比較・評価
ここでは、「複雑処理・Action」において、Agentforce Orchestration（GenericOrchestrator / StageRunner / 同期・非同期実行戦略）のような仕組みがまだ必要か、Agent Script だけでも足りるか を整理する。
4.1 Agentforce Orchestration が提供しているもの
本プロジェクトの Agentforce Orchestration は、おおまかに以下を実現している。
つまり、「複数ステージのうち一部を非同期（Queueable）で実行し、状態を DB に残し、後から状態確認やメニュー表示をする」までを一つのフレームワークで扱っている。
4.2 Agent Script のみでカバーできる範囲
これらは すべて 1 リクエスト内の同期実行 であり、Orchestration フレームワークがなくても Agent Script と標準の Action（Flow/Invocable）だけで実現できる。
4.3 まだ Orchestration（または同等）が必要なケース
まとめると、「1 ターン内の複雑な同期フロー」は Agent Script で十分 だが、「複数トランザクション・複数ターン・非同期チェーン・永続化・多チャネル起動」 は依然として Orchestration 層（またはそれに類する設計） が役に立つ。
4.4 評価マトリクス
4.5 結論 — いつ Orchestration が要り、いつ Agent Script だけで足りるか
Agent Script だけで足りる場合
- 一つの指示（1 発話）のなかで、複数の同期処理を順番に・条件付きで 実行すればよい。
- 例: 注文照会 → 返品可否チェック → 結果を LLM で要約して返す。
- この程度の複雑さなら、Orchestration は必須ではない。Agent Script の Action Chaining・条件・変数・Topic 遷移で実現できる。
Orchestration（または同等の仕組み）が依然として有効な場合
- 非同期ステージを含むマルチステップ（例: データ収集 → 外部 API（Queueable）→ 結果を DB に書き、別ターンで「結果見せて」）。
- 実行レコードによる監査・再実行・障害復旧。
- 同じワークフローを Agent / Flow / LWC / スケジュールの複数チャネルから起動 したい場合。
- ガバナや混合 DML を避けるため、ステージごとに Sync/Queueable を切り分けたい 場合。
インプリベンダー向けの整理:
- 新規で「チャット内で完結する複数ステップ（同期のみ）」を組むなら、まずは Agent Script のみで設計 し、必要になった時点で「開始・状態確認」用の Invocable や Orchestration 層を足す判断でよい。
- 既存の Agentforce Orchestration を導入済みの案件では、非同期・永続化・マルチチャネル の要件が続く限り、Orchestration はそのまま価値がある。Agent Script は エージェント側の制御（Topic・Action の選び方・順序・遷移） をきれいに書くために使い、「重いワークフロー」の実行は Orchestration に任せる ハイブリッド構成が現実的。
5. インプリベンダー・導入支援向けチェックリスト
[ ]
既存 Agent の移行: 新 Builder の Explorer 構成（Settings / Topics 統合）を把握し、Classification Description と Scope を単一説明に統合する方針を決める。
[ ]
Off Topic: 新 Builder で Off Topic が編集可能になるか GA で確認し、必要ならカスタム誘導 Topic と使い分ける。
[ ]
複雑な 1 ターン処理: 複数 Action の順次・条件分岐は Agent Script の Instructions で実装し、Orchestration に頼りすぎない。
[ ]
非同期・長時間・状態確認: 必要な場合のみ、Orchestration または「開始用 / 状態確認用 Invocable」を用意し、Agent Script からはそれらを Action として呼ぶ設計にする。
[ ]
トレース・デバッグ: Agent Script のコンパイル結果・フロー可視化、Agentforce DX のプレビュー・トレースを活用する。
6. 参照リンク
