Loglass VPoT の川村（@k0j1iii）です。
AI エージェントを作ってみたが、「制御が難しい」「中身がわからない」と感じた経験はないだろうか。LangGraph や AutoGen といったフレームワークの登場により、容易に AI エージェントを作れるようになった一方で、本番運用するためには「無限ループ」「コスト爆発」「デバッグ不能」といった壁に直面する。
本記事では、Anthropic・LangGraph・DeepLearning.AI を横断的に分析し、実務で繰り返し使われる 10 のデザインパターンに体系化する。
1. なぜ今、デザインパターンが必要なのか
1.1. 「エージェントを作りたいなら、エージェントを作るな」
LangGraph や AutoGen といったフレームワークが登場し、容易に AI エージェントを作れるようになった。デモ動画では、エージェントが問題なく動作し、タスクを完遂しているように見える。
しかし、いざそれを本番運用に組み込もうとした瞬間、いきなり難しさに直面する。
- 「ユーザーの指示が曖昧で、制御不能になる」
- 「単純なタスクなのに、無限ループしてコストが爆発する」
- 「デバッグしようにも、ブラックボックス化していて動作を理解することが難しい」
なぜか？ AI エージェント開発の最前線にいる Anthropic もこのような提言をしている。
"Start with simple prompts, optimize them with comprehensive evaluation, and add multi-step agentic systems only when simpler solutions fall short."（シンプルなプロンプトから始め、包括的な評価で最適化し、シンプルな解決策では不十分な場合にのみ、複数ステップのエージェントシステムを追加せよ）
— Anthropic, "Building Effective Agents" (2024) [1]
つまり、「いきなり複雑なエージェントを作るな。まずはシンプルなプロンプトで解決せよ」ということだ。
それにもかかわらず、多くのエンジニアはフレームワークに飛びついてしまい、過度な抽象化に自ら飛び込んでしまう。
1.2. フレームワークを学ぶ前に「型」を学ぼう
問題はツールではなく、「どのような構造（アーキテクチャ）で問題を解決すべきか」という共通言語が定まっていないことにある。
「ここはエージェントに任せよう」と言ったとき、ある人は「自律的に思考ループを回す ReAct」を想像し、別の人は「手順が決まったワークフロー」を想像している。これでは議論が噛み合うはずもない。
本記事では、特定のフレームワークに依存しない、実務で繰り返し使われる AI 設計のデザインパターンを体系化する。これらを理解すれば、プロジェクトのフェーズに応じた適切なアーキテクチャを選択できるようになるはずだ。
2. 実務で使える「共通言語」
2.1. 主要 3 ソースの横断分析
AI エージェント設計の「共通言語」を定義するために、現時点で最も実践的な知見をまとめている以下の 3 つのソースを選定し、横断的に分析した。
- Anthropic "Building Effective Agents" [1:1] — Claude を開発する Anthropic が、自社のエージェント開発経験から導いた設計原則
- LangGraph Documentation [2] — 代表的なエージェントフレームワークのひとつである LangGraph のアーキテクチャ設計ガイド
- DeepLearning.AI "AI Agentic Design Patterns with AutoGen" [3] — Andrew Ng 氏が監修する実践コースで紹介されているパターン
これらを突き合わせると、名称や粒度に差異はあるものの、繰り返し登場する設計パターンが見えてくる。本記事では、それらを 10 のパターンとして整理した。
なお、この 10 という数字に絶対的な意味はない。実務では複数のパターンを組み合わせることも多く、新たなパターンが今後追加される可能性もある。重要なのは「数」ではなく、「型で考える」という思考習慣を身につけることだ。
| パターン | 分類 | Anthropic | LangGraph | DeepLearning.AI |
|---|---|---|---|---|
| 1. Prompt Chaining | Level 2: Workflow | ✓ | ✓ | - |
| 2. Routing | Level 2: Workflow | ✓ | ✓ | - |
| 3. Parallelization | Level 2: Workflow | ✓ | ✓ | - |
| 4. Orchestrator-Workers | Level 2: Workflow | ✓ | ✓ | ✓ |
| 5. ReAct | Level 3: Agent | ✓ | ✓ | - |
| 6. Planner-Executor | Level 3: Agent | - | ✓ | ✓ |
| 7. Reflection/Critic | Utility | (言及) | ✓ | ✓ |
| 8. Evaluator-Optimizer | Utility | ✓ | ✓ | - |
| 9. Human-in-the-Loop | Utility | (言及) | ✓ | ✓ |
| 10. Memory-Augmented | Utility | (言及) | ✓ | - |
※ 凡例: ✓ = 明示的に言及、(言及) = 関連概念として触れられている、- = 言及なし
※ Reflection/Critic の Anthropic 列については、記事内で「自己批評的なループ」として触れられている Evaluator-Optimizer の概念を対応付けたもの。
※ LangGraph 列については、引用ページ [2:1] だけでなく、ReAct エージェントや Plan-and-Execute チュートリアルなど LangGraph ドキュメント全体を含めて対応付けている。
※ Evaluator-Optimizer は Reflection の一種とも捉えられるが、Anthropic が重視しているため独立して記載した。両者の違いは以下の通り：
- Reflection/Critic: 同一の LLM が自らの出力を批評し、定性的に改善する（自己批評）
- Evaluator-Optimizer: 別の LLM が評価者として機能し、定量的な基準に基づいてループを回す
2.2. 複雑性の 3 段階モデル：Start Simple
この 10 パターンを使いこなすには、まず実装の複雑性に基づく 3 つのレベルを理解する必要がある。Anthropic の記事でも強調されているように、「まず最もシンプルなパターンから始め、必要な場合のみ複雑性を足していく」のが鉄則だ。
※ ここで示す「Level 1/2/3」という分類は、本記事独自の整理である。
Level 1: 単一プロンプト
- 条件分岐を含まない LLM 呼び出し。RAG（関連情報の検索を含む生成）も含む。Level 2 以降を構成する基本単位。
- 制御主体: プロンプト
Level 2: Workflow (決定論的)
- パスや手順が事前に定義されているシステム。LLM は分岐判断やデータ処理を行うが、全体の制御フローはコードで固定されている。
- 制御主体: コード
Level 3: Agent (自律的)
- LLM 自身が「次に何をすべきか」を動的に決定し、ループを回すシステム。柔軟だが制御が難しく、コストも高い。
- 制御主体: LLM
少なくとも検証段階や初期段階では Level 1 や Level 2 で十分であるにもかかわらず、いきなり Level 3 を適用し、制御不能に陥っていることも多い。
3. パターン詳細ガイド：いつ、どれを使うべきか
ここからは、実務での採用頻度が高い順に解説する。
Level 1: 単一プロンプト
複雑なシステムを組む前に、まず単一プロンプトで粘るべきである。
0. Single Prompt / Simple RAG
概要: 条件分岐を含まない LLM 呼び出し。RAG も含む。
使いどころ:
- 要約、翻訳、単純な質問応答。
- 多くのビジネスユースケースは、プロンプトエンジニアリング（e.g., Few-shot）だけで解決できる。
Level 2: Workflow（決定論的な処理）
Level 1 で精度や機能が不足する場合は検討すべき。予測可能性が高く、デバッグが容易である。
1. Prompt Chaining（連鎖）
概要: タスクを複数のステップに分解し、シーケンシャルに実行する。前の出力が次の入力になる。
使いどころ:
- 長文生成（構成案作成 → 各章の執筆 → 統合）
- RAG（クエリ拡張 → 検索 → 回答生成）
メリット: 中間生成物をチェックできるため、単一プロンプトより圧倒的に品質が安定する。
2. Routing（振り分け）
概要: LLM を入力分類機として使い、下流の処理フローを分岐させる。
使いどころ:
- カスタマーサポート（「返品」ならフロー A、「技術的な質問」ならフロー B）
- ガードレール（「不適切な質問」なら拒否フローへ）
実装のコツ: ルーティング専用の軽量モデル（Gemini Flash や GPT-4o-mini など）を使うとコスト効率が良い。
3. Parallelization（並列化）
概要: 依存関係のないタスクを同時に走らせ、最後に集約（Voting や要約）する。
使いどころ:
- 多角的なレビュー（セキュリティ観点、パフォーマンス観点、ユーザビリティ観点で同時にコードレビュー）
- Web 検索（複数の検索クエリを同時に投げて情報を集める）
メリット: LLM のレイテンシ問題を緩和できる。
4. Orchestrator-Workers（指揮者と作業者）
概要: 中央の Orchestrator（LLM）がタスクを分解し、専門化された Worker に割り当て、結果を統合する。
補足: Anthropic はこれを「Workflow」に分類している。なぜなら、指揮者（Orchestrator）の指示が明確であれば、全体の動きは予測可能だからだ。
使いどころ:
- 複雑なコーディングタスク（e.g., 設計担当、実装担当、テスト担当に分ける）
- ファイル構造の変更など、広範囲な変更が必要な場合
Level 3: Agent（動的・自律的な処理）
Workflow では対応できないような「やってみないと次の手がわからない」タスクにのみ使用する。ここからは「制御」ではなく「ガイド」の領域になる。
5. ReAct (Reasoning + Acting)
概要: 「思考（Thought）→ 行動（Action）→ 観察（Observation）」のループを回す。
使いどころ:
- 探索的な質問への回答（「最新の iPhone のスペックを比較して」など、検索してみないと情報量がわからない場合）
- OS 操作・ブラウザ操作
注意点: ループ回数制限を設けないと無限ループやコスト爆発のリスクがある。また、OS 操作などはセキュリティリスクが高いため、実行可能なコマンドの制限やサンドボックス化も検討すべきである。
6. Planner-Executor（計画と実行の分離）
概要: 最初に全体の計画（Plan）を立て、Executor がそれを順番に消化する。ReAct の弱点である「近視眼的な行動」を防ぐ。
使いどころ:
- 明確なゴールがある長期タスク（「このリポジトリのライブラリバージョンを上げて、テストを通るようにして」）
メリット: 最初にプランを人間が確認・修正できるため、ReAct より制御しやすい。
Utility & Governance（品質と信頼性のための機能）
これらは独立したアーキテクチャではなく、上記の Level 1〜3 のパターンに添える形で導入する重要な要素だ。
7. Reflection / Critic（内省）
概要: 生成された出力に対して、LLM 自身が「批評」を行い、修正版を作成する。
効果: コード生成や文章作成において、品質を劇的に向上させる。
8. Evaluator-Optimizer（評価と最適化）
概要: Evaluator（評価者）が出力を定量的に評価し、基準を満たすまで Optimizer（最適化者）がループで改善する。
使いどころ:
- コード生成（コンパイル成功やテスト通過を評価基準とする）
- 翻訳（BLEU スコアなど機械的な品質指標でループを回す）
9. Human-in-the-Loop (HITL)
概要: 重要な意思決定の前に人間の承認を挟む。
実質的に必須となるケース: 金融取引、メール送信、DB への書き込みなど、取り消しが難しい・影響が大きいアクションを伴う場合。
実装: LangGraph などのフレームワークが最も輝く領域（e.g., 状態の一時停止・再開機能）。
10. Memory-Augmented（長期記憶）
概要: 会話履歴だけでなく、ユーザーの好みや過去の事実をデータベース（e.g., Vector DB）に保存・参照する。
使いどころ: パーソナルアシスタント、長期間にわたるコーチング Bot。
4. 戦略的実装ロードマップ
着実に実装を進めるためには、以下のステップを踏むことだ。
脱「とりあえず ReAct」:
→ まずは Level 1 か Level 2 で解けないか検討する。大抵のタスクはこれで解けるし、安定しやすい。
品質の壁に当たったら:
→ エージェント化する前に Reflection を追加する。モデルを大きくするより、自己推敲させた方が賢くなることが多い。
複雑性への対処:
→ タスクが複雑なら Orchestrator-Workers で責任を分割する。1 つのプロンプトに全てを詰め込まない。
最後の手段として Agent:
→ どうしても予測不可能な要素が残る場合のみ、Level 3（ReAct / Planner-Executor）を導入し、必ずガードレール（e.g., HITL）を敷く。
まとめ：フレームワークは「後から」検討しよう
「LangGraph を使うか、AutoGen を使うか」という議論は、このパターンの設計が終わった後で初めて意味を持つ。作りたいものが「ステートフルで循環するフロー（ReAct など）」なら LangGraph が適しているし、複数の自律エージェントが対話しながら解決する形なら AutoGen がハマるかもしれない。
しかし、Prompt Chaining で済むなら、生の Python コードと OpenAI SDK だけで十分なことも多いはずだ。
（ちなみに筆者は Pydantic AI が好み。重厚すぎず、型安全（Type-Safe）に書ける点が "Start Simple" の肌感覚に最も合う）
最後にもう一つだけ。正確には、フレームワークを選ぶタイミングは「エージェントの型」が見えた時ではない。「お客様の課題解決の最短ルート」が見えた時だ。
流行りのツールに飛びつくのではなく、まずは「目の前の課題を解決するには、どのパターンが最もシンプルで確実か？」を自問自答してほしい。その答えが出た時にはフレームワークに振り回されることはないはずだ。
次回について
今回は「AI エージェントのデザインパターンの全体像」という共通言語を定義した。だが、理論の理解だけでは開発が難しいことは理解しているので、本記事に反響があれば、今回紹介した主要パターンについて、具体的な実装コードと評価（Evals）の組み込み方を深掘りしていくことも考えている。
また、2025 年現在、Multi-Agent Collaboration（マルチエージェント協調）や Agentic AI Governance（エージェントのガバナンス）といった新しい設計観点が業界で活発に議論されている [4][5]。これらについても、実務で必要になった際に触れていく予定だ。
-
Anthropic (2024). "Building effective agents". https://www.anthropic.com/research/building-effective-agents ↩︎ ↩︎
-
LangChain. "LangGraph Documentation: Workflows and Agents". https://docs.langchain.com/oss/python/langgraph/workflows-agents ↩︎ ↩︎
-
DeepLearning.AI. "AI Agentic Design Patterns with AutoGen". https://www.deeplearning.ai/short-courses/ai-agentic-design-patterns-with-autogen/ ↩︎
-
McKinsey (2025). "Deploying agentic AI with safety and security". https://www.mckinsey.com/capabilities/risk-and-resilience/our-insights/deploying-agentic-ai-with-safety-and-security-a-playbook-for-technology-leaders ↩︎
-
OWASP. "State of Agentic AI Security and Governance 1.0". https://genai.owasp.org/resource/state-of-agentic-ai-security-and-governance-1-0/ ↩︎
Discussion