テック技報最新号へ →
AIコーディング

サブエージェントは「役割」ではなく「文脈の独立性」で分け、残りはスキル＋ツールで1本のループに畳む

Anthropic の記事「Building agents: When to fold subagents into your main agent loop」の要点。チームや業務ごとにサブエージェントを作ると、受け渡しのたびに情報が抜ける。手順・判断基準はスキル、外部操作や必ず守る制約はツールに移し、1つのエージェントが同じ文脈で計画から実行まで持つ。移す前に end-to-end の評価を作り、1つずつ畳んで比べる。

@suna_gaku · 投稿 2026-10-24
#サブエージェント#スキル#mcp#評価#エージェント設計

どんな場面で使う？

  • 「調査係・実装係・レビュー係…」と役割ごとにサブエージェントを並べたが、結果がちぐはぐ／遅い／高い
  • 社内で各チームが自分用のエージェントを作り、上に司令塔を載せる構成になりかけている
  • システムプロンプトに各チームのルールが継ぎ足され、矛盾が出てきた

サブエージェントを残してよい3条件（記事より）

  1. 1本のループだと文脈が膨らみ、測って分かるほど性能が落ちる
  2. 互いに独立した作業を、使い捨ての新しい文脈で並列に片付けたい
  3. 1つのエージェントでは道具選びを誤る、またはシステムプロンプト内の指示がぶつかる

これ以外は、役割ごとに分けると「伝言ゲーム」になり、要約で返すたびに途中の判断や細部が落ちる。分けるなら、残りの部分からほとんど情報を必要とせず、短い結果だけ返せる仕事（独立した調査、境界のはっきりした部品、ブラックボックス検証）を切り出す。

手順（畳み方）

  1. end-to-end の評価を先に作る: 正解の代表例10件程度から始めてよい。最終回答を採点基準で採点し、司令塔があるうちは「正しいサブエージェントを選んだか」、畳んだ後は「正しいスキルを読んだか・正しいツールを呼んだか」を見る
  2. よく一緒に呼ばれるものから統合する: 片方の出力を次が使う、同じデータを触る、たいてい続けて呼ばれる、という組を1つのドメインエージェントにまとめる
  3. 残すサブエージェントは「ツールとして呼ぶ」: 会話の主導権はメインに残し、返答の形（スキーマ）を揃え、結論をメイン側で実データと突き合わせる。サブエージェントが利用者と直接話す必要があるときだけ、会話ごと引き渡す
  4. 1つずつスキル＋ツールに置き換えて比べる: プロンプトはスキル、API 呼び出しは MCP ツールへ。総合点だけでなく「前は通っていたのに落ちたタスク」を見る。1回の実行では出ない崩れもあるので、各タスクは複数回走らせる
  5. ツールは API 単位でなく、利用者の目的単位で束ねる: ツール定義が30〜50個を超えると選択精度が落ちやすい。ツール検索で必要なものだけ読み込ませる。前提条件や利用者ごとの権限はツール側で検査し、モデルが読める形で断る
  6. 単一ループの形: 1つのモデル・1つの文脈で、毎ターン複数のツール呼び出しをまとめて出し、ハーネスが並列実行して生の結果を返す。ターン数・費用の上限や書き込みの関所はハーネスに置く。計画は最初のターンに文脈内へ書かせ、結果を見て書き直させる

注意点

出典

X の元の投稿を開く