AI エージェントのコードベースを初めて書き始めるとき、「とりあえず LangChain を入れる」から始める人は少なくありません。Anthropic が 2024 年 12 月に公開した Building effective agents は、その選択を立ち止まって考えさせる定本です。2026 年現在、業界のほぼすべてのエージェント実装は、この記事で定義された 5 パターンのどれか、または組み合わせになっています。
ただし原文は英語で、しかも「どう実装するか」より「どう設計するか」の抽象度が高いので、実務に落とすには解釈が要ります。
この記事では、ワークフローとエージェントの違い、5 つの基本パターンそれぞれの定義と用途、「フレームワークに頼らない」思想の本当の意味、MulmoTerminal など実製品での具体例を日本語で解説します。原文を読む前にも、読んだあとにも、どちらでも読み物になるよう書きました。
ワークフロー と エージェント は違う
Anthropic はまず、「agentic systems」という傘用語を定義し、その下に 2 つを置きます。
ワークフロー (Workflows)
LLM とツールが事前定義されたコード経路を通じてオーケストレーションされるシステム
設計者が「どういう順序で何をするか」を書き下し、LLM は各ステップで決められた仕事をするだけ。挙動は予測可能で、デバッグしやすく、コストと時間が見積もれます。
エージェント (Agents)
LLM が動的に自身のプロセスとツール使用を指揮し、タスク達成方法を自ら統制するシステム
設計者はツールと目標だけ与え、経路は LLM が決めます。挙動は入力ごとに変わり、デバッグが難しく、コストも読めません。その代わり、未知の問題に対処できます。
実務的な見分け方としては、コードを書いていて「次は X を呼び出し、その結果で Y を呼ぶ」のような if-else がたくさん出てきたらワークフロー、LLM が「次に何するか」を自分で決めているならエージェントです。
エージェントを使うべき時・使うべきでない時
Anthropic は「できるならワークフロー、無理ならエージェント」という保守的な立場です。
エージェントを使うべき時
調査系・探索系のようにステップ数が予測できない場合、分岐が開放的で固定パスを書き下せない場合、ツール結果やテスト結果など環境から段階的なフィードバックがある場合、そして成功基準が明確で測定可能な場合、この 4 つが揃うとエージェント向きです。
エージェントを避けるべき時
単一の 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（振り分け型）
入力を分類し、適切な特化プロンプトもしくは特化モデルへ振り分けるパターンです。
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 → outputParallelization との違いは、サブタスクが入力に応じて動的に決まる点にあります。設計時には何体の 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 の書き方
使うべきときだけ選ばれるように書き、他ツールとの境界を明確にします。失敗時の挙動も書いておくと、LLM がエラー回復しやすくなります。
具体的な改善例 (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 の参加者が実運用で使っています。並列化の全体像は AI エージェント並列化で生産性 10 倍 にまとめました。
ACI の実装
セルヘッダーに git ステータス ⎇ ブランチ ●変更数 ↑ahead ↓behind を常時表示し、エージェントも人間も同じ情報を見られるようにしています。相対パス由来のバグを回避するため、ツール呼び出しは絶対パス限定。セッション名はユーザが 1 行書けるメモ機能にして、エージェントの発話が多くて追えない状況を解消しました。評価側の設計については AI エージェントの evals 入門 も参考になります。
まとめ
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 も運営しています。