【備忘録】Agentforceエージェント設計の全体像 ― Subagent時代のAtlas Reasoning Engineを俯瞰する

Last updated at 2026-04-23Posted at 2026-04-23

はじめに

Agentforceでエージェントを設計するとき、最初に悩むのが「そもそも何を・どの順で考えればいいのか」という全体像の部分だと思います。公式ドキュメントは非常に充実していますが、その分ページ数が多く、入口から読んでいくと迷子になりやすい印象があります。

この記事は、Agentforceでエージェントを設計する際に押さえておきたい要素と流れを、1本の記事で俯瞰できるように整理した備忘録です。初学者の方が公式ドキュメントを読み進める際の「地図」として使えることを狙いました。

⚠️ 呼称変更の過渡期に注意
2026年4月から、Agentforceの Topics は Subagents に名称が変更されました。機能は変わりませんが、公式ドキュメントでも両方の呼称が混在しています。本記事では新呼称の Subagents に統一しつつ、旧呼称の Topics も括弧書きで補足します。

※本記事は個人の整理メモです。正確な仕様は必ず公式ドキュメント（末尾にリンク）で確認してください。

1. Agentforceとは何か

まず大枠として、Agentforceは Salesforceプラットフォームにネイティブ統合されたAIエージェント基盤 と整理できます。

従来のチャットボットが「問い合わせに応答する」ものだったのに対して、エージェントは次のように振る舞う点が違うポイントです。

ユーザーの発話（utterance）を受け取る
推論して、どのタスクを・どの順で実行するか決める
必要なデータを取得する（CRMレコード、ナレッジ記事、外部システム）
アクションを実行する（レコード更新、Flow起動、メール送信など）
結果を踏まえて応答を生成する

Agentforceの大きな特徴は、エージェントが Salesforceのオブジェクトモデルを直接参照できる ことです。外部API経由で接続するのではなく、人間のユーザーと同じオブジェクト・項目・権限の枠組みでデータを読み書きできると捉えると理解しやすそうです。

2. エージェントを構成する4つのビルディングブロック

Agentforceのエージェントは、大きく4つの要素で構成されていると整理できます。

2.1 Subagents（旧 Topics）

特定の業務領域を担当する「小さなエージェント」 です。

例: Lead Qualification、Case Resolution、Order Status
1つのエージェントの中に複数のSubagentを配置する
会話の起点は Agent Router（旧 Topic Selector、Agent Script上は start_agent ブロック）
- すべてのユーザー発話はまず Agent Router に入り、そこからどの Subagent に渡すかが判定される
ユーザーの発話が来たら、Reasoning Engineが「どのSubagentが扱うべきか」を判断して切り替える

💡 Subagentsは旧称Topicsです。2026年4月から名称変更されましたが、機能は同じです。「より専門性を持った小さなエージェントの集合体」というニュアンスを出すための呼称変更と整理できます。同様に、会話の入口である Topic Selector も Agent Router に呼称変更されています。

2.2 Actions

Subagentが実行できる具体的な行動（ツール）です。

実装手段はいくつかの選択肢があります
- Apex クラス（@InvocableMethod）
- Flow
- Prompt Template
- 外部API呼び出し（MuleSoft連携など）
Subagent間でActionは共有されません
- 公式Agent Script Referenceにも "If you import an action to a subagent, the subagent gets its own copy of the imported action" と明記されている
- ライブラリからimportした場合でも、各Subagentごとにコピーが作られる挙動

このため、同じAction（例: レコード取得）を複数のSubagentで使う場合は、それぞれに持たせる必要があります。一見冗長ですが、Subagentごとに独立してバージョン管理できるという利点もあります。

2.3 Instructions

**自然言語で記述する「振る舞いのガイド」**です。

Subagentごとに「何をするか・何をしないか」を指示する
LLMが解釈して、応答の方針や判断基準として使う
従来のプロンプトエンジニアリングに近いが、Subagent単位で分割されている点が特徴

2.4 Variables

Actionの出力を保持して、後続のロジックで使うための変数です。

Actionの結果をVariableに格納 → 条件分岐で使う → 別のActionの入力にする、という流れを作れる
決定的な（deterministic）制御の要になる要素

この4つの関係を一言でまとめると、「Subagentの中で、Instructionsに基づいてActionを実行し、その結果をVariableに格納して次の判断に使う」という構造です。

3. Atlas Reasoning Engine の動き

Agentforceの推論を司るのが Atlas Reasoning Engine です。Salesforceエンジニアリングブログでも "graph-based workflows" と説明されており、Agent Script で書いたエージェントは Agent Graph という構造化された仕様にコンパイルされ、このAtlas Reasoning Engineが解釈して実行します。オーケストラの指揮者のように、どのSubagentがいつ何をするかを制御します。

1メッセージの処理フロー

ユーザーのメッセージがどう処理されるかを、シンプルな5ステップで追ってみます。

ユーザーが発話を送信
ユーザーが「注文の状況を教えて」といったメッセージを入力する
Agent Routerに入る
すべての発話はまず Agent Router（start_agent ブロック）に入り、ここで適切な Subagent への振り分けが行われる
選択されたSubagentの reasoning instructionsを上から順に解決
この部分が重要で、LLMに問い合わせる前に、プログラム的な式（ロジック）を先に解決します。必要に応じて別のSubagentへ遷移することもあります
プロンプトを組み立ててLLMに送信
ロジックの解決結果を踏まえて、LLMに渡すプロンプトを生成・送信する
LLM出力＋Action実行結果を応答として返す
LLMが生成した自然言語と、Actionの実行結果を組み合わせてユーザーに応答する

Hybrid Reasoning という考え方

このフローの核心が Hybrid Reasoning という概念です。

従来のプロンプトベースのエージェントは、「全部プロンプトに詰め込んでLLMに解釈させる」方式でした。これだと、ビジネスルールのような絶対に守ってほしい処理まで確率的な解釈に委ねることになり、予測性が低くなります。

Agentforceは次のように整理しています。

ロジック命令（->）: 決定的に実行される。ビジネスルール、Action実行、変数設定、条件分岐はここで書く
プロンプト命令（|）: LLMに送られる自然言語。ニュアンスのある会話や応答生成はここに任せる

「決まりきった部分はプログラムで確実に」「曖昧な部分はLLMの柔軟性で」というハイブリッド構造です。

4. Agent Script の最小例

実際のAgent Scriptがどう書けるのかを、簡略化した最小の例で1つだけ示します。
会話の入口 start_agent と、1つの Subagent（旧 Topic）を並べた骨格です。

# 会話の入口（Agent Router）
start_agent topic_selector:
  description: "ユーザーの発話を適切なSubagentに振り分ける"
  reasoning:
    instructions:
      | ユーザーの意図を分析して、どのSubagentが最適か判断してください。
  actions:
    go_to_case_status:
      @utils.transition to @subagent.case_status_lookup
      description: "ケースのステータス問い合わせならこちら"

# ケースステータス問い合わせのSubagent（旧 Topic）
subagent case_status_lookup:
  description: "ケース番号をもとにステータスを返す"
  reasoning:
    instructions:
      # ロジック命令: Actionを実行してVariableに格納
      -> run @actions.get_case_status with
           case_number = @variables.user_case_number
         set @variables.case_status = @outputs.status
      # プロンプト命令: LLMに応答方針を指示
      | ユーザーに対して、現在のケースステータスを丁寧に伝えてください。
      | 現在のステータス: {!@variables.case_status}
  actions:
    get_case_status:
      target: apex://GetCaseStatusAction
      inputs:
        case_number:
          type: string
          required: true
      outputs:
        status:
          type: string

読みどころ

トップレベルに start_agent ブロックと subagent（旧 topic）ブロックを直接書く
actions: ブロックは各 Subagent の内側に書く（Subagent間で Action は共有されない）
-> で始まる行は 決定的なロジック（Action実行と変数格納）
| で始まる行は LLMに渡す自然言語プロンプト
@actions.xxx @variables.xxx @outputs.xxx @subagent.xxx で、エージェント内のリソースを参照する
{!@variables.xxx} の形式で、プロンプト内に変数を埋め込む

ℹ️ 上記は構文のイメージを掴むための簡略例です。実際のプロパティやインデントの詳細は公式の Agent Script Referenceで確認してください。

5. 2つの実装モード

Agentforceエージェントは、ローコードとプロコードのどちらでも構築できます。

ローコード: Agentforce Builder

App Launcherから起動する統合ワークスペースで、画面は大きく3つのパネルに分かれています（2026年2月にGA）。

Navigation Explorer（左）: エージェントの Subagents、Variables、Connections、Data などの構造を俯瞰して辿るナビゲーション
Editor View（中央）: 編集のメイン領域。ここでビューを切り替えられる
- Canvas View: 自然言語ベースのドキュメント形式エディタ（初期値）
- Script View: Agent Scriptを直接編集するコードエディタ
- Preview View: 会話を試せるテストパネル。Trace機能で推論ステップを可視化できる
Agentforce Assistant（右）: エージェント自身に「Subagentを追加して」のように自然言語で依頼できるアシスタント

Canvas View と Script View は常に同期します。Canvasで構造を組んで、細部をScriptで調整する、という進め方が自然かもしれません。

プロコード: Agentforce DX / SDK

開発者向けのツール群も充実しています。

Agentforce DX: Salesforce CLI + VS Code + Git でメタデータとして管理
Agentforce Vibes 2.0: ブラウザベースのVS Code環境（Code Builderをベースにリブランド）。マルチモデル対応（Claude Sonnet / GPT-5 等）。TDX 2026 で発表
Agentforce Python SDK: エージェントをプログラム的に生成・管理
Agent API: 外部アプリから会話する
Agentforce Mobile SDK: iOS/Androidネイティブアプリに組み込む

チームでバージョン管理・CI/CDをしたい場合や、複数Orgへのデプロイが必要な場合はプロコード寄りの構成が向いていると整理できます。

6. 設計の進め方（最低限の順序）

初学者の方向けに、設計の流れを5ステップに圧縮しました。

ユースケースを1つに絞る
最初から全領域をカバーしようとしないこと。高頻度・低複雑度のタスクから始めるのが定石とされています
Subagentを切り分ける
1つのSubagentに複数領域を詰め込まない。業務単位で分割する
Action / Instructions / Variables を設計
既存のFlow・Apex・Prompt Templateを棚卸しして、Actionとして再利用できるか検討する
ガードレールを設定
Max Turn（会話ターン数の上限）を設定してループ暴走を防ぐ。エスカレーションルールや権限制御も合わせて設計する ※具体的な推奨値は公式ドキュメントで確認してください
Preview + Trace でテスト → デプロイ
Agentforce BuilderのConversation PreviewとTrace機能で、実際にどのSubagent・Actionが選ばれたかを確認しながら調整する

👉 設計思想のコツ: Salesforce公式は、この流れ全体を Context Engineering（プロンプトエンジニアリングの後継概念）と位置づけています。「完璧なプロンプトを書こうとする」のではなく「Subagents・Instructions・Actions をシステムとして設計する」という発想に切り替えるとハマりにくい印象です。

まとめ

Agentforceエージェント設計の全体像を整理すると、以下のようになります。

エージェントは Subagents × Actions × Instructions × Variables の4要素で構成される
会話の入口は Agent Router（旧 Topic Selector、start_agent ブロック）。ここから各 Subagent に振り分けられる
処理の中心は Atlas Reasoning Engine。Agent Script は Agent Graph にコンパイルされ、決定的ロジックとLLM推論を組み合わせた Hybrid Reasoning で動く
Agent Scriptは、ロジック（->）とプロンプト（|）を1つのファイルに統合して書けるDSL
実装モードは Agentforce Builder（ローコード） と DX / Vibes 2.0 / SDK（プロコード） の両輪
設計時は「完璧なプロンプト」ではなく Context Engineering の発想でシステム的に組み立てる

最初に「何を・どの順で考えればいいのか」の地図さえ持っていれば、細部は公式ドキュメントを辿って埋めていけるはずです。この記事が、その入口になれば幸いです。

参考（公式情報）

※仕様は随時アップデートされます。必ず最新の公式ドキュメントで確認してください。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up