Anthropicの「Building Effective Agents」を読み直す — WorkflowとAgentの5+1パターン

背景 — なぜいま「エージェントの作り方」を読み直す価値があるのか

2024年12月、AnthropicのErik S.とBarry Zhangが公開した「Building Effective Agents」は、AIエージェント開発の議論を一度地に足のついた場所に戻した記事です。当時は「エージェント」という言葉が曖昧なまま使われ、開発者は複雑なフレームワークを試しては期待した成果を得られない状況が続いていました。

2026年5月の現在、Claude CodeやClaude Skillsなど実用的なエージェント機能が次々と登場し、企業導入も具体的な検討段階に入っています。だからこそ、流行語ではなく構成要素の言葉でエージェントを語るこの記事の価値が、当時よりむしろ高まっていると言えそうです。

この記事を読み直す意義は2つあります。1つは、いまだに混同されがちな「ワークフロー」と「エージェント」の境界を、自分のシステムに当てはめて言語化できるようになることです。もう1つは、Anthropic自身が自社プロダクトの設計でどのパターンを採用しているかを逆算する手がかりになることです。

WorkflowとAgentを混同しないための定義

多くの開発現場で「AIエージェント」と呼ばれているものは、実態としてはワークフロー(Workflow)に近いことが多いです。両者の境界を理解することが、適切なアーキテクチャ選択の出発点になります。

ワークフローは、LLMとツールを事前に定義されたコードパスでオーケストレーションする仕組みです。人間が設計した制御フローに沿って、決められた順序で処理が進みます。「ユーザーの質問を分類して、適切な専門LLMにルーティングし、回答を整形する」という流れは典型的なワークフローです。

エージェントは、LLM自身が自分の処理経路とツール利用を動的に決める仕組みです。ループ構造を持ち、ツール実行の結果や外部環境の応答に応じて次の行動を選びます。コーディングタスクで「コードを書く→テストを走らせる→失敗箇所を直す→もう一度テストする」を成功まで反復するのがエージェントの典型です。

この区別は実装方針に直結します。ワークフローは予測可能なエラーパスを事前に設計しやすく、コストとレイテンシも見積もりやすい一方、エージェントは想定外の状況に強い反面、無限ループや暴走を防ぐガードレールが別途必要になります。

基本要素となる「拡張されたLLM」

ワークフローもエージェントも、共通の基本要素として「augmented LLM」が置かれています。これは素のLLM呼び出しに、以下の機能を組み合わせたものです。

• ツールアクセス:Function callingやMCP(Model Context Protocol)による外部システム連携
• メモリ:会話履歴や中間状態の保持
• 取り出し(retrieval):関連情報の動的な検索と埋め込み

この拡張LLMを最小のビルディングブロックとして、より複雑な構成を作っていくのが推奨アプローチです。最初から複雑な仕組みを設計するのではなく、シンプルな拡張LLMの組み合わせから始めて、必要な複雑さだけを足していく、という順序が強調されています。

実装の地に足のついた指針としては、Anthropic Context Engineering論で示されたjust-in-time取り出しやcompactionの考え方が、拡張LLMの「コンテキスト」面の設計に直結します。

ワークフローの5つのパターン

元記事では、ワークフローを構成する5つの基本パターンが提示されています。それぞれ異なる問題設定に対応し、必要に応じて組み合わせて使えます。

プロンプトチェイニング(Prompt Chaining)

最もシンプルなパターンで、複数のLLM呼び出しを順序立てて実行します。前のステップの出力が次のステップの入力になる、パイプライン型の構造です。

ユーザー入力 → ステップ1 LLM → ステップ2 LLM → ステップ3 LLM → 最終出力
                                  ↓ (gate)
                              中断/再試行

このパターンは、タスクを明確に分割できる場合に有効です。例えば技術文書の要約で「専門用語の抽出→背景知識の補完→構造化された要約の生成」のように、ステップごとに責務を分離できる場面に向きます。

途中にgate(チェック処理)を挟んで、品質が低ければ早期に止めるパターンも紹介されています。長くチェインを伸ばすほど誤差が伝播するので、適切な長さに保つことが運用上の鍵になります。

ルーティング(Routing)

入力の種類や特性に応じて、異なる処理パスに分岐させるパターンです。分類器役のLLMが入力を解析し、最適な専門系統に振り分けます。

ユーザー入力 → 分類LLM ┬→ 技術質問系統(専門LLM)
                       ├→ 一般質問系統(汎用LLM)
                       └→ 画像処理系統(マルチモーダルLLM)

カスタマーサポートで「請求関連」「技術サポート」「返品交換」を別チームに振り分けるのと同じ発想です。それぞれの系統で別のプロンプト、別のツール、別のモデルを使い分けられるので、コスト最適化の余地が大きいのも特徴です。

実装上は分類精度がボトルネックになります。誤分類への耐性として、信頼度が低いときに既定系統へフォールバックする、複数カテゴリ該当を許容する、などの設計が要点になります。

並列化(Parallelization)

大きなタスクを独立したサブタスクに分割し、並列処理することで時間短縮と精度向上を狙うパターンです。SectioningとVotingの2つのバリエーションが示されています。

Sectioningは、入力を複数の部分に分割して並列処理し、結果を統合します。

大きな文書 ┬→ セクション1 → LLM → 部分要約 ┐
           ├→ セクション2 → LLM → 部分要約 ┼→ 統合LLM → 全体要約
           └→ セクション3 → LLM → 部分要約 ┘

Votingは、同じタスクを複数のLLMで並列実行し、結果を比較・統合します。

同一タスク ┬→ LLM-A → 結果A ┐
           ├→ LLM-B → 結果B ┼→ 投票/統合 → 最終結果
           └→ LLM-C → 結果C ┘

サブエージェント並列パターンでは、Claude Code環境でこの並列化を実装する具体例が紹介されており、処理時間の短縮と結果のばらつき低減を両立する事例が読めます。

オーケストレーター・ワーカー(Orchestrator-Workers)

中央の制御LLM(Orchestrator)が複数のワーカーLLMを管理し、タスクを動的に割り当てるパターンです。並列化との違いは、オーケストレーターが進行状況を見ながら、必要に応じてワーカーの追加や再指示を行う動的さにあります。

オーケストレーター
   ↓ タスク分析・計画
   ├→ ワーカー1 → 結果 ┐
   ├→ ワーカー2 → 結果 ┼→ オーケストレーター(統合・追加指示)
   └→ ワーカー3 → 結果 ┘

このパターンは、タスクの複雑度が実行時まで読めない場合や、ワーカー間で結果を相互参照しながら進める場合に向きます。複数の情報源からデータを集め、相互参照しながら報告書を作るタスクが典型例です。

Anthropicのマルチエージェント研究システムは、このパターンをClaude Researchで実装した事例で、リードエージェントとサブエージェントの分業設計が詳しく解説されています。

評価者・最適化者(Evaluator-Optimizer)

生成された結果を評価し、必要に応じて改善指示を出すパターンです。品質管理と反復改善を自動化する仕組みとして機能します。

生成LLM → 結果v1 → 評価LLM ┬→ [合格] → 最終出力
                            └→ [不合格] 改善指示 → 生成LLM → 結果v2 → ...

このパターンは、出力品質の基準が明確で、改善方向を定式化できるタスクに向きます。コード生成でテスト成功を評価基準にする場合や、翻訳で原文との整合性を反復チェックする場合が典型です。

運用上の落とし穴は、評価基準の客観性と改善指示の具体性です。評価基準が曖昧だと無限ループに陥り、改善指示が抽象的だと最適化が空振りします。試行回数の上限を必ず設定するのも実運用の必須事項です。

エージェントは「ループ + 環境フィードバック」で定義される

ワークフローが静的な処理フローであるのに対し、エージェントは動的な環境適応能力を持ちます。この違いを生む核心が、ループ構造と環境フィードバックの組み合わせです。

エージェントの基本構造は以下のループで表現されます。

1. 現在状況の観察
2. 次のアクションの計画
3. ツール実行
4. 環境からのフィードバック(ground truth)を取得
5. 1に戻る(または停止条件を満たして終了)

このループで重要なのが、ツール実行の結果、外部システムからの応答、ユーザーの追加指示などの環境フィードバックです。LLMが内部的に「次は何をすべきか」を推論するのではなく、実際に環境に働きかけてその応答を見て次を決める点が、ワークフローとの根本的な違いになります。

Claude Codeサブエージェントガイドで紹介されているコーディングエージェントは、この原則の好例です。コードを書き、テストを実行し、エラーメッセージという環境フィードバックを受け取って、次の修正アクションを決めます。ワークフローでは対応できない、予期しないエラーや複雑なデバッグタスクに対応できるのは、このループ構造があるためです。

エージェント設計で見落とされがちなのは、行動が完全に自律的である必要はないという点です。重要な操作には人間の承認を挟む「human-in-the-loop」もエージェントの有効な実装パターンとして位置付けられています。

いつWorkflowでいつAgentか — 使い分け早見表

アプローチ選択は、タスクの特性と要求される能力で決まります。次の早見表を判断のたたき台に使えます。

具体例として、カスタマーサポートで考えてみます。よくある質問への回答は「分類→回答検索→整形」という明確なワークフローで処理できます。一方、技術的なトラブルシューティングは「症状の確認→仮説の立案→検証→結果に基づく次の仮説」という反復的なプロセスが必要で、エージェントが向きます。

判断のもう1つの軸として、コストとレイテンシのトレードオフがあります。エージェントは性能と引き換えに、コストとレイテンシを増やす構成だと明示されています。CIで毎晩走るバッチ処理なら問題なくても、エンドユーザーが待つUIに直接組み込むなら、ワークフローまたはハイブリッド構成のほうが現実的という判断が成立します。

ツール設計はエージェント体験(ACI)を決める

元記事のAppendixで強調されているのが「Agent-Computer Interface(ACI)」という概念です。人間向けのユーザーインターフェース(HCI)とは異なる原則で、エージェント向けのツールインターフェースを設計する必要があるという主張です。

LLMがツールの機能を理解し適切に使用するには、人間が読んで理解できる説明(human-readable)が決定的に重要です。APIエンドポイント /user/update の説明として「ユーザー情報を更新する」では不十分で、「指定されたuser_idのユーザーの氏名、メールアドレス、プロファイル情報を部分的または全面的に更新します。必須パラメータはuser_idのみで、更新したい項目だけを指定可能」といった詳細が必要です。

エージェント向けツールの書き方では、この原則をさらに発展させ、エージェントが混乱しやすいツール設計のハマりどころと対策が解説されています。

ツール設計の基本原則は以下の通りです。

1. 目的の明確化:ツールが何を達成するのか、どんな状況で使うべきかを明記
2. パラメータの説明:各パラメータの意味、型、必須性、デフォルト値を詳述
3. 戻り値の構造:成功時と失敗時の応答形式を具体例付きで説明
4. 制約条件:使用上の制限、権限要件、レート制限などを明示
5. エラーハンドリング:典型的なエラーケースと対処方法を提示

Anthropicがこの数年で出してきたCode execution with MCPやAgent Skills実践など、ツール設計を主題にした記事の系譜は、すべてこのACIの考え方を出発点にしていると読めます。

Anthropic自社プロダクトとの照合 — Claude Code/Skillsはどのパターンを採用しているか

元記事のフレームワークが、Anthropic自身のプロダクトでどう適用されているかを逆算すると、設計思想の一貫性が見えてきます。

Claude Codeは、基本構造としてエージェント・パターンを採用していると読めます。コーディングタスクで、ファイル読み取り → コード生成 → テスト実行 → エラー修正のサイクルを成功まで反復実行する仕組みは、まさに記事で定義されたエージェントの典型です。テスト結果、ビルドエラー、実行結果という環境フィードバックに基づいて次のアクションを決める動作は、ループ + 環境フィードバックの原則そのものです。

ただしClaude Codeマルチセッション機能では、複数のサブタスクを並列実行する際にオーケストレーター・ワーカー・パターンも併用していると考えられます。メインセッションがタスクを分割し、サブセッションに振り分ける構造は、記事のパターンと一致します。

Claude Skills(Agent Skills)の設計は、より興味深い実装例を示しています。個別のスキルはワークフロー・パターンで実装され、それらを組み合わせて複雑なエージェント行動を構成する階層構造になっています。「メール送信」スキルは明確なワークフロー(宛先確認→内容生成→送信実行)ですが、「顧客対応」エージェントは複数のスキルを状況に応じて選択・実行するエージェント・パターンで動作します。

この設計は、「シンプルで合成可能なパターン」という記事の主張を体現していると読めます。1つのスキルは検証可能なワークフローに留めつつ、上位レイヤーで初めて自律性を発動させる構造は、暴走リスクを抑えながら柔軟性を確保する現実解です。

MCP(Model Context Protocol)の設計思想も、記事のACI原則と一致しています。エージェントが外部システムと対話するためのツール・インターフェースを標準化する仕組みで、人間が読んで理解できる説明(human-readable)を重視し、エージェントが確実にツールを理解・使用できるよう設計されています。

2024年末→2026年の進化 — 当時の主張は今も生きているか

記事公開から約1年半が経過した時点で、AIエージェント分野は急速に進化しています。それでも、基本的な設計原則は依然として有効性を保っていると言えそうです。

「フレームワークに頼らず、LLM APIから始める」という主張は、現在でも実用上の指針として機能しています。多くの企業向けエージェント・フレームワークが登場しましたが、実プロダクションでは特定フレームワークへの依存を避け、自社要件に合わせたシンプルな実装を選ぶ事例が目立ちます。

「パターンの組み合わせ」アプローチは、より洗練された形で実用化されています。Managed Agentsで紹介されている企業向けソリューションでは、5つのワークフロー・パターンを組み合わせて複雑な業務プロセスを自動化する事例が報告されています。

一方で、記事公開時点では予測しにくかった変化もあります。

マルチモーダル対応の進化で、エージェントが扱える環境フィードバックの種類が大きく拡張されました。画像、音声、動画からの情報取得が可能になったことで、より複雑な環境への適応が現実的になっています。

レイテンシの改善で、エージェント・パターンの適用範囲が広がりました。記事では「リアルタイム応答が必要ならワークフロー」という判断基準が示されていましたが、現在では準リアルタイムのエージェント応答が可能になり、この境界が曖昧になっています。

コスト効率も大きく改善しました。記事公開時点ではエージェントの反復実行による高コストが大きな制約でしたが、モデルの効率化と価格低下により、より多くの用途でエージェント・パターンが実用的な選択肢になっています。

安全性とガードレールの重要性は、想定以上に高まっています。エージェントの自律性が高まるにつれ、意図しない行動を防ぐ仕組みの重要性が広く認識されるようになりました。現在の実装では、エージェントの行動範囲を制限し、重要な操作に人間の承認を必要とする設計が一般的です。Harness Designで扱われている長時間エージェントの実装論は、この方向の延長線上にあります。

まとめ

「Building Effective Agents」が提供する枠組みは、AIエージェント開発の議論を実装可能な言葉に翻訳した点で、現在も高い価値を持っています。WorkflowとAgentの明確な区別、5つのワークフロー・パターンの体系化、そして「シンプルで合成可能」な設計思想は、プロダクション環境でのエージェント開発において重要な基準になります。

特に大事なのは、技術的な新しさや複雑さを追求するのではなく、解決すべき問題の特性に応じて適切なパターンを選ぶという姿勢です。明確に定義されたタスクには素直にワークフローを採用し、動的で複雑な問題にのみエージェント・パターンを適用する判断基準は、コスト効率と開発効率の両面で意味があります。

ツール設計におけるACI(Agent-Computer Interface)の概念は、エージェントの実用性を左右する見落とされがちな要素で、今後さらに多くの注目を集める領域になりそうです。人間向けのUI/UX設計とは異なる原則に基づくツール設計の重要性は、エージェント技術が普及するほど高まると考えられます。

2026年の現在、Claude CodeやClaude Skillsをはじめとする実用的なエージェント・システムが登場し、この記事の理論的フレームワークの有効性が実装側から裏付けられている状況です。それでも、基本に立ち返ってLLM APIを直接活用したシンプルな実装から始めるアプローチは、変わらず有効な開発戦略として参考になります。