AIエージェント設計パターン完全ガイド2026｜Anthropic Building Effective Agents 5パターン+3エージェントハーネス

AIエージェント設計パターンとは｜Anthropic「Building Effective Agents」の知見

AIエージェント設計パターンは、LLMを中核とする自律システムを構築するための再利用可能な構造の集合です。Anthropicが2024年12月に公開し2025〜2026年に業界標準となった「Building Effective Agents」(資料集 + Cookbook)は、ワークフロー型(Workflows)とエージェント型(Agents)を区別した上で、5つの合成可能パターンを提示しました。Cloudflare/Microsoft等の主要ベンダーがこの分類を公式ドキュメントに採用しており、2026年時点で事実上の業界共通言語になっています。

Anthropicの最重要メッセージは「シンプルなプロンプトから始め、評価で最適化し、複雑な多段エージェントは他に方法がないときだけ追加する」というものです。最も成功する実装は専用ライブラリや込み入ったアーキテクチャではなく、シンプルで合成可能なパターンを使っています。本記事では5つの合成可能パターン、Workflows vs Agentsの違い、2026年の3エージェントハーネス(計画/生成/評価)、主要フレームワーク(LangGraph/CrewAI/AutoGen/Mastra等)、そしてrenue独自視点として「設計パターン選定6原則」を解説します。

Workflows vs Agents｜Anthropicの根本的区別

観点	Workflows(ワークフロー型)	Agents(エージェント型)
制御フロー	事前定義された決定論的経路	LLMが動的に経路を決定
予測可能性	高い	低い
コスト	低い	高い
適用	定型業務・既知の問題	未知の問題・適応的タスク
失敗時の挙動	追跡しやすい	追跡が難しい
運用負荷	低い	高い

Anthropicは「ほとんどの場合Workflowsで十分。Agentsが本当に必要なケースは少ない」と明言しています。真の自律エージェントが正当化されるのは、タスクが「既知の経路では解けない」「複数ステップの計画が動的に必要」な場合です。

5つの合成可能パターン

パターン1: Prompt Chaining(プロンプトチェイニング)

1つのタスクを複数のステップに分解し、前のLLM出力を次の入力にする逐次処理。各ステップにゲート(Validation Gate)を挟むのが推奨。例: アウトライン作成→ドラフト執筆→事実確認→最終整形。シンプルで予測可能、デバッグ容易。2026年の実務で最も多用される基本パターンです。

パターン2: Routing(ルーティング)

入力を分類して適切な専門ハンドラに振り分けるパターン。例: 問い合わせ内容を分類→技術質問は技術DB、契約質問は契約モジュールへ。「万能プロンプト」より専門化したプロンプト群の方が品質・コスト効率良。モデル階層化(高難度はGPT-5/Opus、簡単なものはHaiku/Mini)とも組み合わせます。

パターン3: Parallelization(並列化)

独立して実行可能なサブタスクを並列で走らせる。2種類:

Sectioning:タスクを独立部分に分割して並列化(例: 長文の章別翻訳)
Voting:同じタスクを複数回実行して投票で結果決定(精度・信頼性向上)

レイテンシ短縮+品質向上の両方に効きます。LLM-as-a-Judgeの3回投票もVotingの応用です(LLM評価指標)。

パターン4: Orchestrator-Workers(オーケストレータ-ワーカー)

中央のオーケストレータLLMが動的にサブタスクを分解しワーカーLLMに割り当てるパターン。Parallelizationが事前定義の分割なのに対し、Orchestrator-Workersはタスク内容に応じて分割が変わります。例: コード変更要求→Orchestratorが変更対象ファイルを動的特定→各ファイルへの変更を並列ワーカーに割当。マルチファイル編集や動的分解が必要なタスクに強力です。

パターン5: Evaluator-Optimizer(評価者-最適化者)

1つのLLMが出力を生成し、別のLLMが評価・フィードバックして反復改善するフィードバックループ。例: 翻訳の品質を評価LLMが採点し、改善箇所を指摘→生成LLMが修正。文学翻訳・コード生成・複雑な推論で特に効果的です。LLM-as-a-Judgeを評価者に組み込めます。

真の「Agents」型｜計画+ツール+ループ

Anthropicの定義する真のAgentは「LLMが動的に環境を観察し、ツールを呼び出し、結果を見て次の行動を決定するループ」を回す存在です。Function Callingでツール群を渡し、停止条件(タスク完了/エラー/上限)に達するまでループします。本質的にはOrchestrator-Workersの動的版で、タスクの構造自体をLLMが決めます。Computer Use(Computer Use ガイド)はその代表例です。

2026年の新潮流｜3エージェント・ハーネス

InfoQ(2026年4月)で報じられたAnthropicの新研究「Three-Agent Harness」は、長時間の自律AIワークフローのために計画(Planner)・生成(Generator)・評価(Evaluator)の3エージェントを分離するアプローチです。

Planner:タスクを分解し、計画を立てる(推論モデルを使うのが効果的)
Generator:計画に従って実装・出力を生成(高速モデルが最適)
Evaluator:生成結果を評価し、不足・誤りを指摘(別の推論モデルが望ましい)

3者を分離することで、長時間タスクの安定性と品質が大幅に改善されると報告されています。Coinbase/Intercom/Thomson Reuters等の事例が公開されています。

主要フレームワーク比較(2026年4月時点)

フレームワーク	提供元	得意
LangGraph	LangChain	有向グラフでステートフルなWorkflow/Agent記述
CrewAI	CrewAI	役割分担型マルチエージェント
AutoGen	Microsoft	非同期マルチエージェント連携
OpenAI Agents SDK	OpenAI	OpenAIエコシステム統合
Pydantic AI	Pydantic	型安全・構造化出力連携
Mastra	Mastra	TypeScript/Node向けエージェントFW
Vercel AI SDK	Vercel	フロント統合に強い
Semantic Kernel	Microsoft	.NET/Java エンタープライズ統合
NeMo Agent Toolkit	NVIDIA	NVIDIA推論基盤統合
LiteLLM	OSS	マルチLLMゲートウェイ(詳細)

「フレームワークが先」ではなく「パターンが先、フレームワークは実装手段」というAnthropicの原則に従い、まず必要なパターンを特定してから対応するFWを選びます。

パターン選択の決定木

1ステップで解けるか? → 単純プロンプトで終了
固定のステップ列で解けるか? → Prompt Chaining
入力を分類して別ハンドラに振るか? → Routing
独立タスクの並列で速くなるか? → Parallelization (Sectioning/Voting)
分割が動的に必要か? → Orchestrator-Workers
反復改善が必要か? → Evaluator-Optimizer
長時間・自律探索が必要か? → Agentsまたは3エージェントハーネス

下に行くほどコスト・複雑性・運用負荷が増えることを忘れないでください。上で解けるなら上で解くのが正解です。

renueの視点｜AIエージェント設計パターン選定6原則

renueは広告代理AIエージェント・AI PMOエージェント・Drawing Agent・SEO記事生成エージェント等を複数自社運用する中で、設計パターン選定の6原則を確立しています。

(1) Anthropic原則「シンプルから」を遵守:いきなり多段エージェントを作らず、まず単純プロンプト→Prompt Chaining→Routingと段階的に複雑化します。複雑化はROIがあるときだけ。

(2) 真のAgent型は最後の手段:動的計画が必要な業務だけにAgent型を採用します。それ以外はWorkflowsで十分です。コスト・予測可能性・運用負荷で雲泥の差が出ます。

(3) 評価CIで複雑度上げ判断:単純パターンで品質が頭打ちになったら次のパターンへ進む、というGolden Set評価ベースの判断にします。「なんとなく多段にする」は失敗の元です。

(4) 3エージェントハーネスはプランナー層に推論モデル:Planner=Claude Opus 4.6/GPT-5.4 Thinking、Generator=Sonnet/Gemini Flash、Evaluator=別の推論モデル、というモデル使い分けで品質×コストの最適化(推論モデル)。

(5) フレームワークよりパターンを先に:LangGraph/CrewAI/AutoGen等の選定は後。先に必要なパターンを言語化し、それに合うFWを選びます。FW先行はベンダーロックの温床です。

(6) AgentOpsと必ずセットで運用:複雑なパターンほどObservability・コスト管理・上限制御・レッドチーミングが必須。設計パターンと運用基盤は2輪。

よくある失敗パターン

いきなり多段Agent:単純プロンプトで足りる課題に過剰投資
フレームワーク先行:CrewAI/LangGraphを使うこと自体が目的化
評価なしで複雑化:複雑化したが品質が上がっていない
動的分解の暴走:Orchestrator-Workersが無限ループ
3エージェントハーネスでモデル使い分けせず全部同じ:コスト爆発
運用基盤なしでAgent運用:本番事故の温床

よくある質問（FAQ）

Q1. Workflowsで足りるか、Agentsが必要かどう判断しますか？

「事前にステップ列を書ける」ならWorkflows、「ステップ自体を動的に決める必要がある」ならAgentsです。多くの業務はWorkflowsで足ります。

Q2. 3エージェントハーネスはどんな場合に効きますか？

長時間タスク・複雑な意思決定・出力品質が重要なタスクで効果的です。短いQAには過剰です。

Q3. フレームワークは必須ですか？

不要です。Anthropic自身が「シンプルで合成可能なパターン>専用ライブラリ」と推奨しています。Pythonの素のSDKでも十分実装できます。

Q4. 日本語ではどのフレームワークが使いやすいですか？

LangGraph/Pydantic AI/Mastraがドキュメント・コミュニティ充実度で先行します。日本語特化のFWはまだ少ないです。

Q5. renueはエージェント設計を支援していますか？

はい。複数AIエージェント自社運用経験から、パターン選定・フレームワーク選定・Anthropic 3エージェントハーネス導入まで一貫して支援しています。

AIエージェント設計パターン・実装のご相談はrenueへ

renueは複数のAIエージェント事業を自社運用するAIエージェント開発企業として、Anthropic「Building Effective Agents」原則に基づく設計パターン選定・フレームワーク選定・3エージェントハーネス導入・評価CI統合までワンストップで支援しています。「シンプルから始めて段階的に複雑化」のアプローチでお困りの方はお気軽にご相談ください。

AIエージェント開発の事例を見る