前回は、エージェントAIの基本パターンとして ReAct、Reflection、Planning、Multi-Agent をざっくり整理しました。今回はもう一歩踏み込み、実装時に「どの責務をどの層に置くか」という視点で、設計パターンを4つのレイヤに分けて考えます。
1. ゴールと計画のレイヤ
最初に切り出すべきなのは、ユーザーの曖昧な依頼を実行可能なタスクへ変換する層です。DeepSquareの記事では、Passive Goal Creator と Proactive Goal Creator が、目標設定と計画生成のパターンとして紹介されています。Yue Liu氏らのAIエージェントデザインパターン解説 では、ユーザーの明示的な指示を対話で明確化する方式と、コンテキストからエージェント側が目標を提案する方式が整理されています。
開発者視点では、この層は「タスク定義器」です。入力は自然言語でも、出力は goal、constraints、success_criteria、allowed_tools のような構造化データにしておくと、後続の実行層が安定します。
計画生成では、Plan & Execute、Single-path Plan Generator、Multi-path Plan Generator を使い分けます。Google Cloudのガイドも、パターン選定ではタスクの複雑さ、レイテンシ、費用、人間の関与を評価すると説明しています。Google Cloudの設計パターン比較 単純なCRUDならSingle-pathで十分ですが、仕様策定や技術調査のように正解が一つでないタスクでは、複数案を出して比較する価値があります。
2. 推論と自己改善のレイヤ
次の層は、計画を実際の推論と行動に落とし込む部分です。Anthropicの設計ガイドを要約した記事では、Prompt Chaining、Routing、Parallelization、Orchestrator-Workers、Evaluator-Optimizer といったワークフローが紹介されています。効果的なAIエージェント設計方法 の整理を見ると、いきなり自律エージェントにするより、まず工程を分けて安定させるのが現実的です。
Prompt Chainingは「要件整理、設計、実装、テスト」のようにフェーズを分けるパターンです。ReActは、思考、ツール実行、観察を繰り返すループです。実装では、1回のLLM呼び出しにすべてを詰めるより、状態を短く保ち、各ステップでツール結果を観察させるほうが失敗を回収しやすくなります。
品質を上げたい場合は、Self-Reflective または Evaluator-Optimizer を足します。Qiitaの設計パターン整理では、Self-Reflectiveは軽量な自己内省、Evaluator-Optimizerは生成と評価を分離するループとして扱われています。AIエージェント デザインパターン完全ガイド コード生成ならテスト、文章生成ならチェックリスト、調査なら出典の網羅性を評価軸にすると、単なる「もう一回考えて」よりも効果が出ます。
3. 協調のレイヤ
単一エージェントが大きくなりすぎたら、協調レイヤを導入します。Orchestrator-Workersは、中央のオーケストレータがタスクを分解し、調査、実装、レビューなどのワーカーに渡す構成です。Weights & Biases Japanの記事では、Planning と Multi-Agent Collaboration の組み合わせが、論文調査や分析、執筆のような複雑タスクに向く例として説明されています。AIエージェントのデザインパターン
協調パターンには、役割ベース、投票ベース、討論ベースがあります。役割ベースはソフトウェア開発と相性がよく、プランナー、実装者、レビューアを分けるだけでも責務が明確になります。投票ベースは不確実な分類や候補選定に向き、討論ベースは戦略判断のように反論が価値を持つ場面で使います。
ただし、マルチエージェントは万能ではありません。共有状態、書き込み権限、失敗時のリトライ、最終判断者を決めないまま導入すると、単一エージェントよりデバッグが難しくなります。まず単一エージェント＋ツールで詰まりを見つけ、明確なボトルネックが出たところだけ分割するのが安全です。
4. 入出力と安全性ガードのレイヤ
最後の層は、入出力と安全性を制御する部分です。Zennの記事では、最小構成から始めること、マルチレイヤのガードレール、人間の介入、ツール定義の標準化が強調されています。失敗しないAIエージェント設計
Guardrailsは、プロンプト、ツール呼び出し、最終出力をチェックする仕組みです。社内API、個人情報、削除や送信のような不可逆操作を扱うなら、ルールベースの検証、人間承認、操作ログを必ず入れます。
Agent Adapterも重要です。LLMから見るツールインターフェイスを統一しておくと、裏側のAPIやモデルを差し替えてもワークフロー全体を壊しにくくなります。引数名、入力形式、失敗時の戻り値、権限境界まで含めて設計することで、ツール誤用を減らせます。
実装時の最小構成
実務で始めるなら、最初の構成は大きくしすぎないほうがよいです。おすすめは、ゴール定義器、Plan & Execute、ReAct風ツールループ、軽いEvaluator、Guardrails、Adapterの組み合わせです。
たとえばDevOps自動化なら、まずユーザー依頼を「対象サービス、環境、許可された操作、成功条件」に正規化します。次に、調査、変更案作成、確認、実行、検証というPlanを作ります。各ステップではログ検索、CI確認、設定ファイル編集などのツールを呼び、最後にEvaluatorが「本当に成功条件を満たしたか」を確認します。デプロイや削除のような操作だけはHuman-in-the-Loopで止めます。
このように見ると、エージェントAIの設計パターンは流行語ではなく、責務分離のための部品です。ゴール、推論、協調、安全性を別々に設計しておくと、最初は単一エージェントでも、あとからマルチエージェントや評価基盤へ拡張しやすくなります。