エージェント設計レシピ：Tool Use・Sub-agent・制御フロー

既製のエージェント（Claude のエージェント機能や Manus など）を「使う」のは入口にすぎません。自分の業務に合わせたエージェントを「作る」には、設計の型を知る必要があります。本記事では、土台になる 3 つのパターン――ツール使用（Tool Use）・サブエージェント（役割分担）・制御フロー（ワークフロー）――を、実際の製品名や数字を交えながら、初めての人でも順に組み立てられるよう整理します。

FIG.1　3 つの型は対立しない。実務では重ねて使う

01パターン1：ツール使用（Tool Use）

LLM は文章を生成するのは得意ですが、それ単独では「今の天気」を知らず、Slack に投稿することもできません。そこで、外の世界とつなぐ関数をツールとして渡し、AI に必要なときだけ呼ばせます。これがエージェントの最小単位です。

ツールは「名前・説明・入力スキーマ」の 3 点セットで定義します。AI は会話の途中で「このツールをこの引数で呼びたい」と構造化して返し、アプリ側が実際に実行して結果を会話に戻す――この往復を繰り返します。

tools: [
  {
    name: "get_weather",
    description: "指定した都市の今日の天気を返す",
    input_schema: {
      type: "object",
      properties: { city: { type: "string" } },
      required: ["city"],
    },
  },
  {
    name: "post_slack",
    description: "指定チャンネルにメッセージを送る",
    input_schema: {
      type: "object",
      properties: {
        channel: { type: "string" },
        text: { type: "string" },
      },
      required: ["channel", "text"],
    },
  },
]

「東京の天気を #general に投稿して」と頼むと、AI は自分で get_weather(city:"東京") → その結果を受けて post_slack(...) の順に呼びます。どのツールをいつ使うかは AI が判断します。

FIG.2　AI が「呼ぶ → 結果を受け取る」を繰り返して目的を達成する

設計のコツ

• 説明文は「何のために何をするか」を AI 目線で具体的に。曖昧だと AI が使うべき場面を取り違えます。
• 入力スキーマは厳密に（JSON Schema で型・必須・許容値を明示）。緩いと不正な引数を渡してきます。
• エラー文も AI が読める形で返す。「city が未指定」のように具体的なら、AI は自分で聞き直して回復できます。

02パターン2：サブエージェント（役割分担）

1 つの大きな仕事を、役割の違う複数のエージェントに分けて任せるやり方です。「司令役（オーケストレーター）」がゴールを小さなタスクに割り、それぞれを専門のサブエージェント（ワーカー）に投げて、結果を束ねます。これは orchestrator-workers（司令役とワーカー）パターンとも呼ばれます。

記事を書く例なら、こう分かれます。

main agent（司令役：進行管理と統合）
  ├ research-agent（資料集め・出典確認）
  ├ writer-agent（本文執筆）
  └ editor-agent（校正・SEO チェック）

FIG.3　司令役がタスクを分配し、各ワーカーの成果を統合する

この型が効くのは、必要な作業の数や中身が事前に読めない仕事です。たとえばコード修正では「何ファイル直すか」「各ファイルでどう直すか」がタスク次第で変わるため、司令役がその場で分解して割り当てます。一方、1 つのエージェントに大量のツールと責務を詰め込むと、応答が遅くなり、ツール選択を誤りやすくなり、全体のゴールを見失いがちになります。役割を分けるのは、その限界を超えるための手段です。

設計のコツ

• 各サブエージェントが独立して動けるよう、コンテキスト（前提・入力）を切り分ける。
• サブエージェントへの指示には「目的・出力フォーマット・使ってよいツール／情報源・担当範囲の境界」を明記する（Anthropic の研究システムもこの 4 点を渡している）。
• サブエージェント間の受け渡しは構造化（JSON など）で。自然文だと取りこぼしが起きる。

03パターン3：制御フロー（ワークフロー）

エージェントの動きを、AI の自由判断に任せきりにせず、コードで明示的に決めるやり方です。「スコアが高ければ人間に回す、低ければやり直す」「3 つを並列で取って要約する」「公開前に承認を待つ」といった流れを、フレームワークで組みます。確実性が求められる業務ほど、この型が向きます。

判断・分岐

if (review.score > 0.8) {
  await sendToHuman(result);   // 高品質 → 人へ
} else {
  await retryWithHints(input); // 低品質 → 指示を足してやり直し
}

並列実行

const [a, b, c] = await Promise.all([
  fetchTask("A"),
  fetchTask("B"),
  fetchTask("C"),
]);
const summary = await summarize([a, b, c]);

承認フロー（Human-in-the-loop）

const draft = await draft(input);
await requestApproval(draft);     // 人間の判断を待つ
const ok = await waitForApproval();
if (ok) await execute(draft);     // 承認後にだけ実行

2026 年時点では、こうした流れを途中で止めても状態を失わずに再開できる「持続実行（durable execution）」型のフレームワークが主流になりつつあります。代表例は LangGraph（状態を持つグラフとして組む）、Temporal（数時間〜数日続く長い処理に強い）、Vercel Workflow（2025 年 10 月ベータ公開、2026 年に正式提供・1 億回超の実行を処理）、Inngest（イベント駆動と承認待ちに強い）など。承認待ちのあいだ計算資源を消費せず一時停止して待てるため、Human-in-the-loop と相性が良いのが共通点です。

FIG.4　承認待ちは「止めて待てる」ことが肝。状態を失わず再開する

043 パターンの使い分け

3 つは排他ではありません。まず役割を表で押さえ、実務では組み合わせます。

パターン	向いている用途
ツール使用	外部システム連携、データ取得＋アクション。まず最初に試す最小構成。
サブエージェント	事前に手順が読めない複雑タスク。役割で分けると見通しが良い仕事。
制御フロー	条件分岐・承認・確実性が要る業務。流れを固定したい場面。

たとえば「制御フローで全体の流れを固定しつつ、各ステップではツールを使い、重い調査だけサブエージェントに任せる」といった重ね方が現実的です。

05「分ければ強い」とは限らない ―― コストの現実

サブエージェントは魅力的ですが、ただではありません。Anthropic が公開した調査では、複数エージェント構成は通常のチャットに比べておよそ15 倍のトークンを消費しました。その代わり、同社のリサーチ用途では単体の Claude Opus 4 を 90.2% 上回る成績を出しています。つまり「タスクの価値がトークン代を上回るとき」に初めて多エージェントが勝つ、という損得勘定です。

最も成功している実装は、複雑なフレームワークより「単純で組み合わせ可能な型」を使っている ―― Anthropic。

消費者向けの一問一答のような低単価の用途では、この 15 倍は割に合いません。逆に、法務デューデリジェンス・競合調査・専門文献レビューのような高価値の調査では元が取れます。多くの業務では、3 つのパターンを1 つのエージェントの中で使うだけでも十分な信頼性が得られ、多エージェント構成の高コストを避けられます。

06失敗を減らす実装テクニック

07つまずきやすい 3 つの注意点

08次のステップ

本章の続く記事「MCP 入門」「マルチエージェント設計」「Browser-Use / Computer-Use」で、ここで触れた接続規格や役割分担を実装レベルへ掘り下げていきます。まずは小さく――1 つのツールを 1 つのエージェントに持たせて動かすところから始めるのが、遠回りに見えて一番の近道です。