「Building Effective Agents」を実務に落とす — Anthropic 公式ガイドの 5 パターンと設計原則

Anthropic が 2024 年 12 月に公開した Building effective agents は、AI エージェント設計の 定本 です。2026 年現在、業界のほぼすべてのエージェント実装は、この記事で定義された 5 パターンのどれか（または組み合わせ）になっています。

ただし原文は英語で、しかも「どう実装するか」より「どう設計するか」の抽象度が高いので、実務に落とすには解釈が要ります。

本稿では、

1. ワークフローとエージェントの違い
2. 5 つの基本パターンそれぞれの定義・用途・実装
3. 「フレームワークに頼らない」思想の本当の意味
4. MulmoTerminal など実製品での具体例

を日本語で解説します。原文を読む前に本稿を、読んだあとに本稿を、どちらでも読み物になるように書きました。

ワークフロー と エージェント は違う

Anthropic はまず、「agentic systems」 という傘用語を定義し、その下に 2 つを置きます。

ワークフロー (Workflows)

LLM とツールが事前定義されたコード経路を通じてオーケストレーションされるシステム

• 設計者が「どういう順序で何をするか」を書き下す
• LLM は各ステップで決められた仕事をするだけ
• 挙動は予測可能、デバッグしやすい、コストと時間が見積もれる

エージェント (Agents)

LLM が動的に自身のプロセスとツール使用を指揮し、タスク達成方法を自ら統制するシステム

• 設計者はツールと目標だけ与え、経路は LLM が決める
• 挙動は入力ごとに変わる、デバッグが難しい、コストが読めない
• その代わり、未知の問題に対処できる

実務的な見分け方: コードを書いていて「次は X を呼び出し、その結果で Y を呼ぶ」のような if-else がたくさん出てきたら ワークフロー。LLM が「次に何するか」を自分で決めているなら エージェント。

エージェントを使うべき時・使うべきでない時

Anthropic は**「できるならワークフロー、無理ならエージェント」** という保守的な立場です。

エージェントを使うべき時

• ステップ数が予測できない（調査系・探索系）
• 固定パスを書き下せない（分岐が開放的）
• 環境から段階的なフィードバックがある（ツール結果・テスト結果など）
• 成功基準が明確で測定可能

エージェントを避けるべき時

• 単一の LLM 呼び出しで十分
• 高コスト・長レイテンシが許容できない
• 失敗の累積リスクが許容できない
• 挙動の予測可能性が業務要件

金融の決済バックエンドや医療の意思決定 のような領域では、エージェントは慎重に。これらは明確な経路を書き下すべき場所です。

5 つの基本パターン

パターン 1: Prompt Chaining（連鎖型）

定義: タスクを段階的に分解し、前のステップの出力を次のステップに渡す。

input → LLM step 1 → output 1 → LLM step 2 → output 2 → ... → final

使いどころ:

• 既知の固定サブタスクに分解できる
• 各ステップの品質を個別に検証したい
• 1 プロンプトでは複雑すぎる

例:

• マーケティングコピー: 「ターゲット分析 → ドラフト → 翻訳 → ファクトチェック」
• ドキュメント生成: 「アウトライン作成 → 構造検証 → 本文執筆 → レビュー」

実装: Python / TypeScript で 20 行程度。LangChain を使う必要はなく、for ループで十分。

パターン 2: Routing（振り分け型）

定義: 入力を分類し、適切な特化プロンプト or 特化モデルへ振り分ける。

input → classifier LLM → category → specialist LLM A / B / C → output

使いどころ:

• 入力が複数カテゴリに分かれ、カテゴリごとに最適な処理が違う
• モデル使い分け（簡単な質問は Haiku、複雑な質問は Opus）

例:

• カスタマーサポート: 「技術問い合わせ / 返金 / 一般質問 / 緊急」の 4 分類で担当プロンプトに振る
• コード生成: 「新規実装 / リファクタ / バグ修正 / レビュー」で違うプロンプト

実装: 分類する LLM 呼び出し 1 回 → 結果で switch して適切な specialist を呼ぶ。これも 30 行程度。

パターン 3: Parallelization（並列型）

定義: 複数のタスクを同時実行し、結果を集約する。

2 つのサブパターン:

3a. セクショニング

独立したサブタスクを並列実行。

input → split → [task A / task B / task C 並列] → merge → output

例: 大きなドキュメントのレビューを「文法」「論理」「ファクト」で並列チェック。

3b. 投票 (Voting)

同じタスクを複数回実行して信頼度を上げる。

input → [LLM run 1 / LLM run 2 / LLM run 3 並列] → majority vote → output

例: コンテンツの安全性判定、重要な分類タスク、脆弱性レビュー。

実装: Promise.all や asyncio.gather で並列実行。これも 20-30 行。

パターン 4: Orchestrator-Workers（統括型）

定義: 中央の orchestrator LLM が、動的にサブタスクを分解・委譲し、worker LLM の結果を統合する。

input → orchestrator → (worker 1, worker 2, worker 3) → orchestrator → output

parallelization との違い: サブタスクが入力に応じて動的に決まる。設計時には「何体の worker が要るか」が分からない。

使いどころ:

• 複数ファイルにまたがるコード変更（どのファイルを触るかは入力次第）
• 複数情報源から集めるリサーチ（どのソースを使うかは入力次第）

例: Anthropic 自身の Research 機能 はこのパターン。

実装: orchestrator が tool call で worker を起動する。10-15 ファイルくらいの中規模コード。

パターン 5: Evaluator-Optimizer（評価改善型）

定義: 1 体の LLM が回答生成、別の LLM が評価・フィードバック、を繰り返す。

input → generator → draft → evaluator → feedback → generator → draft 2 → ... → final

使いどころ:

• 反復改善が測定可能な価値を生む
• 評価側に明確な基準が存在する

例:

• 文学翻訳: ニュアンス・リズム・意味の 3 軸で評価してやり直す
• 複数ラウンドの調査: 「このドラフトで足りない情報は？」を評価側が指摘

実装: generator と evaluator を別プロンプトで分け、ループで回す。終了条件（スコア閾値・ループ回数上限）を明示する。

「フレームワークに頼らない」の本当の意味

Anthropic は LangChain / CrewAI / AutoGen / LlamaIndex などのフレームワークに対して、明確に 「最初は使わないほうが良い」 という立場を取っています。

なぜか

• 多くのパターンは数行〜数十行で書ける
• フレームワークは抽象化層を増やし、デバッグを難しくする
• 本来の動作メカニズムを隠蔽するので、問題の根本原因が見えない
• フレームワーク側に起因する「顧客エラー」が実際に多い

「使うな」ではなく「必要になるまで使うな」

これはフレームワーク全否定ではありません。「API を直接叩くところから始めて、必要性が明確になってから導入する」のが推奨される順序。

実際の判断基準:

• プロトタイプ段階: 必ず API 直接
• 本番運用: フレームワークが具体的に何を省力化するか明確なら導入
• 100 行以下のロジック: フレームワークは要らない

フレームワークが実際に役立つケース

• マルチエージェントの通信を抽象化したい（LangGraph の state graph）
• Memory 層の実装を再発明したくない（LlamaIndex）
• 大量の integration を使い回したい（LangChain の 100+ loaders）

これらが本当に必要な段階になったら導入する。先回りして入れると、不要な複雑性で詰まります。

ACI: Agent-Computer Interface の設計

Anthropic が強調するもう一つの原則は ACI (Agent-Computer Interface) の設計。

ツール設計には、人間コンピュータインタフェース（HCI）と同等の投資をするべき

具体例:

ツール名・パラメータ名

• 「ジュニア開発者がこの名前で意味を理解できるか」で判断
• send_mail より send_email_to_user
• path より absolute_file_path

引数の形式

• モデルがインターネット上で自然に見る形式に近いものを選ぶ
• JSON より Markdown、Markdown より XML タグ、など用途による
• 「余分なエスケープ・行数カウント」などのオーバーヘッドを避ける

description の書き方

• 使うべき時だけ選ばれるように書く
• 他ツールとの境界を明確に
• 「失敗時の挙動」も書く

具体的な改善例 (Anthropic の実験)

SWE-bench のエージェントで、ファイル操作ツールが相対パスを使うと間違えやすいことが発覚。パラメータを絶対パス限定にしたら完全に解決。

パラメータ 1 つの型変更が、エージェント全体の信頼性を変える。ACI の設計はそれくらい効きます。

MulmoTerminal での実例

MulmoTerminal は、これらの原則の 具体化 として参考になります。

Routing パターン

• 起動時の agent picker: タスクに応じて Claude Code / Codex / Gemini CLI / Grok / Muse を選ぶ
• user が明示的に選ぶ UI だが、設計思想は Routing

Parallelization パターン

• 9 セルで並列エージェント実行
• 独立した worktree でセクショニング
• Round table 機能は投票に近い

Orchestrator-Workers パターン

• 「issue から ▶」ボタンでの作業起動 → orchestrator として MulmoTerminal 自身が branch 作成 / worktree 切り / Claude 起動を順にやる

Evaluator-Optimizer パターン

• MulmoTerminal の adversarial review スキル: 1 セルがコードを書き、別のセルがレビューして欠陥を指摘
• Singularity Society BootCamp の参加者が実運用で使っている

ACI の実装

• セルヘッダーに git ステータス ⎇ ブランチ ●変更数 ↑ahead ↓behind を常時表示 → エージェントも人間も同じ情報を見る
• 絶対パス限定 のツール呼び出し（相対パス由来のバグを回避）
• セッション名を ユーザが 1 行書けるメモ機能 → エージェントの発話が多くて追えない状況を解消

まとめ

• Anthropic の Building effective agents は AI エージェント設計の定本
• ワークフロー（事前定義）とエージェント（動的）を区別し、できるならワークフロー
• 5 パターン: Prompt chaining / Routing / Parallelization / Orchestrator-workers / Evaluator-optimizer
• フレームワークに頼らない「API 直接から始める」思想
• ACI (ツール設計) に HCI と同じだけ投資する
• MulmoTerminal は複数パターンの実装例として参考になる

この 1 本を読んで、ちゃんと咀嚼する時間 が、2026 年のエージェント開発者にとっての最大の ROI です。

関連リンク

• 原文: Building effective agents (Anthropic)
• Anthropic Engineering Blog の歩き方 — 必読記事 15 選
• MCP (Model Context Protocol) 入門
• AI エージェント並列化で開発速度 10 倍
• MulmoTerminal — Claude Code を並列実行するコックピット

Singularity Society はテクノロジー集団として MulmoClaude / MulmoTerminal / MulmoCast を開発しています。エンジニア・起業家向けの実践プログラム BootCamp も運営しています。