はじめに
2025年以降のLLMモデル・AIエージェントの急速な発展に伴い、企業でのAIエージェントの活用も、当初のチャットボット型による1問1答的な使い方から、より広範囲かつ柔軟な業務を任せていくというフェーズへの進展が進みました。
一方で、AIエージェントの設計には唯一の正解が存在せず、例えば、一見同じように見える「取引先企業の調査タスクを自動化したい」という要望でも、扱う情報の量、求められる精度、コスト・レイテンシの制約等によって最適なアーキテクチャの設計は大きく異なります。
AIエージェント開発は、目的と制約が動く以上、とりあえずこうしておけば大丈夫というようなベストプラクティスは存在しません。AIエージェントは機能として閉じたシステムではなく、環境との接続がポイントでもあるため、ある環境ではワークしていたAIエージェントが、別の環境では全くワークしないという事も少なくありません。
つまり、特定の正解パターンがないため、むしろ重要なのは、様々な方法論・デザインパターンとしての「引き出し」をどれだけ持っているか、そして目の前に置かれた状況・制約に応じて、適切なパターンを選べるかという事になります。
私自身、実はデザインパターンを意識して作った事はあまりなく(あとから名前がついていた事を知るケースが多い)、目的から逆算して、今回はこの構成かなという事を試し、状況と制約・フェーズを踏まえながら、破壊と創造を繰り返してアップデートをするという形を取っていますが、一度、自身の振り返りと学びの観点も含め、AIエージェント設計における主要なデザインパターンを整理してみました。
厳密に言えば、組み合わせ次第でパターン数は無限になるのですが、今回は学術的・デモ的に面白いものの、実際にはおそらく利用できないようなアイディアベースのものは抜きにして、各主要ベンダーのブログでも共通的に紹介されている手法に絞って整理していきたいと思います。
7つのカテゴリで考える
AIエージェントのデザインパターンは目的・観点別にある程度のグループ化が可能なため、今回は全体感を把握しやすくするために、7つのカテゴリに分類しています。
今後出てくる新しい手法なども、「どの問題を解決するための手法なのか」という事を意識して深掘りする事で、理解が容易になるのではないかと思います。
| No. | カテゴリ | 観点 | 代表的なパターン |
|---|---|---|---|
| 1 | Reasoning推論 | どう考え、行動するか | ReAct / Plan-and-Execute / Replanning / Goal-directed Loop / Parallel Exploration |
| 2 | Reflection & Verification内省・検証 | どう間違いを検出し、改善するか | Reflection / Local Reflection / Global Reflection / Generator-Evaluator / Self-Heal |
| 3 | Decomposition分解 | 大きな仕事をどう分解するか | Parallelization / Orchestrator-Workers / Hierarchical Decomposition / Query Decomposition |
| 4 | Coordination協調 | 複数エージェントをどう連携させるか | Supervisor / Handoff / Group Chat / Blackboard |
| 5 | Context Managementコンテキスト管理 | 限られたコンテキストをどう使うか | Skills / Scratchpad / Context Triage / Memory |
| 6 | Autonomy & Control自律制御 | 自律実行をどう制御するか | Step & Token Budget / Termination Condition / Human-in-the-loop / Approval Gate / Escalation |
| 7 | Safety & Security安全性 | 安全に入出力・実行させるか | Input Guardrail / Output Guardrail / Tool Guardrail / Pre-action Validation |
それでは見ていきましょう。各セクションは独立なので、ご自身の事例において気になる箇所など、逆引き的に見て頂いても問題ありません。
1. Reasoning Patterns（推論パターン）
どう考え、行動するか。AIエージェントの一手ごとの意思決定ループを決める、最も基礎となる観点です。ここでどの推論パターンを選ぶかによって、後段のコスト・レイテンシ・信頼性に大きな影響を与えるため、最も重要な設計ポイントの一つになります。
ReAct
おそらくAIエージェントのパターンでもっとも有名な、思考(Thought)→行動(Action)→観察(Observation)を1ステップずつ交互に繰り返す、最も基本的な推論ループです。
1ステップごとに実行と観測を挟み込むため、初見の環境や、状況の変化に柔軟に対応した動作が可能になります。
メリット：1ステップごとに、実行結果を見てから次を考えるので、想定外のエラーや新しい情報が出てきてもその場で軌道修正できます。手順やステップを事前に読み切れない複雑な環境ほど、この柔軟性が効いてきます。
デメリット：ステップの数だけLLMを呼び出すことになるので、レイテンシとコストはループの数だけ積み上がっていきます。特にレスポンスの速さが問われるケースでは注意が必要です。また、事前の全体計画がなくその場その場で判断する形のため、全体としてはむしろ遠回りな経路を辿ってしまうというケースもあります(ただ、複雑性の高い環境では、最初に全体計画を立てる事に意味がないケースもあるため、必ずしも計画的であることが良いとは限らない)。
有効なユースケース：Web調査や対話的なデバッグのように、そもそも手順を事前に決め切れない探索的なタスクに向いています。逆にやるべきことや手順がほぼ固定されているケースにおいては、不必要に制御が複雑になるため、採用するメリットはあまりないと言えます。AIエージェントの動きのイメージがよくわかるため、ハンズオンや演習では非常におすすめです。
Plan-and-Execute
ReActはその場その場で計画と実行を繰り返す形でしたが、これは先に全体の実行計画を立て、その計画に沿って各ステップを順番に実行するパターンです。ReActが「推論→行動」を逐次繰り返すのに対し、Plan-and-Executeでは実行前に複数ステップからなる全体計画を明示的に作成します。最初に計画フェーズを挟むため、実行内容がトレースしやすい(制御がしやすい)点も特徴です。
メリット：全体計画を先に定めるため、複数ステップにまたがるタスクでも一貫した方向性を保ちやすくなります。また、実行前に計画を人間や別のAIがレビューするという形への応用もできるため、重要な処理ではガバナンス上の利点もあります。
デメリット：最初に立てた計画を前提に進めるため、途中で状況や前提が変化すると計画と実際の結果が乖離しやすくなります。実行と観測の前に計画を立てるため、いわゆる初期の仮説思考が外れた時に軌道修正ができません。想定外のレスポンスなどが多数発生するケースでは、ReActのほうが柔軟に対応できます。
有効なユースケース：全体計画を立て、タスクリストに基づいてAIエージェントに行動させたいケース、特にシンプルであるものの、ある程度のステップ数があるケースで有効です。あまりこれをそのまま使うケースはないかと思いますが、非常にシンプルで最初の計画がほぼ外れないケースでは用途があるかもしれません。
Replanning
最初に立てた計画に引っ張られてしまうというPlan-and-Executeの弱点を補う形で、実行途中の失敗や新情報を受け、当初の計画そのものを作り直すパターンです。状況変化に応じた計画の更新により、柔軟な対応が可能になります。
メリット：前提が崩れた瞬間に計画そのものを作り直せるので、Plan-and-Executeの「一度決めたら融通が利かない」という弱点をそのまま補えます。外部環境が不確実な現場ほど、再計画できるというこの柔軟性の効果が大きくなります。
デメリット：再計画のたびにLLM呼び出しが発生するため、ループが増加するとコスト・レイテンシ共に増加します。上限を設けずに使うと、状況が少し変わるたびに計画を練り直し続け、いわば無限ループに陥る可能性があるため、ガードレールの設定が重要になります。計画が外れ続けるような複雑な環境の場合は、ReActのような探索型のほうが良いケースもあります。
有効なユースケース：インシデント対応や長時間の自律作業など、途中で前提が覆るものの、対応はある程度計画的に進めるべきタスクに有効です。ただし、AIエージェントとしての複雑性は増すため、再計画のルールやガードレールの設計が重要になります。レスポンスの速さが重要なケースでは、あえて再計画させずに一旦Plan-and-Executeの結果を報告させて指示を仰ぐという形のほうが良いというケースも少なくないかもしれません。
Goal-directed Loop
明示的なゴールを与え、そのゴールを達成するまで、エージェント自身が次の行動を判断しながらツール呼び出しや推論を繰り返す実行構造です。
ReActが1ステップの中身（思考→行動→観察）を規定するのに対し、Goal-directed Loopが規定するのは「ゴールが達成されるまで自律的に反復する」という全体の制御構造です。ループ内部でどのように考え、どのように行動するかまでは規定しないため、実際にはReActやReplanningなどの推論パターンと組み合わせて利用します。
メリット：達成すべき明確なゴールを与えておけば、あとはエージェントが自律的にゴールを達成するまで稼働します。あらゆる手段を講じながら、AIが目的達成まで試行錯誤を行うため、人間の介入度が低いという意味では、自動化の恩恵を最も素直に受けられる形です。
デメリット：自律性が高い分、停止条件などを適切に設定しないと、コストとレイテンシは青天井になります。また、人間による介入や補正がない分、途中のエラーが後続のステップに複合的に積み重なるリスクもあり、局所最適解から抜けられないというリスクもあります。あらゆる手段を講じて目的を達成しようとするため、ガードレールを適切に設定して、事前にAIエージェントが動ける範囲を絞っておかないと、想定外の事故に繋がる可能性もあります。スタートが早く、一見魅力的ですが、ある種タスク設計をスキップするような形であるため、むしろ高くつくという事も少なくありません。
有効なユースケース：ミスがそれほど致命的にならない、オープンエンドな問題解決に向きます(コストやレイテンシの制約もないバッチ処理のようなケース)。品質保証的に、組織での本番運用で利用することはあまりないかもしれませんが、ゴールだけ渡してAIに色々と実験させ、インサイトを得るという形では有効かもしれません。自律性という意味では最大になるため、かなり小さめにゴールを設定するという形も含め、検討軸には入れておきたいパターンの一つです。
Parallel Exploration
同じタスクに対して複数の推論経路・解法候補を並行して生成し、投票やスコアリングで最良のものを採用するパターンです。
メリット：複数の候補を同時に試すことで、1本道の推論ではまりがちな局所解を避けやすくなります。ある種AIの使い方としては非常に上手い形で、人間の場合は、工数制約によってなるべく最良のパターンを少数選ぶ形ですが、AIは人間に比べて複数案の試行コストを下げやすいため、複数の推論経路を並行して探索できます。これはアンサンブル学習にも近い発想です。
デメリット：試行数がそのままコストに跳ね返るため、呼び出し回数分だけ費用は線形に増えていきます。加えて、複数の候補をどう統合するか(単純に多数決でいいのか)というロジック設計も課題として残ります。それでも、AIのある種高すぎる柔軟性とモデルアップデート等による変更に対する頑強性の向上という観点では非常に重要と言えるのではないかと思います。
有効なユースケース：複数の検討軸や異なるLLMモデルで試した結果を統合することができるため、探索の幅が必要なタスクで有効になります。別々のサブタスクを並列に走らせて全部を合成したいなら、カテゴリ3のParallelizationの方が該当します。コードの脆弱性検査でも抜け漏れの抑制、OCRのような読み取り系タスクでの頑強性向上、デザイン系タスクでの切り口の増加など、幅広いタスクで利用できます。ただ、試行フェーズはやや広めに選択肢を取りつつも、並列数が増えるほどコストが増加するため、運用フェーズでは無駄な選択肢を刈り取っていく必要があります。
2. Reflection & Verification Patterns（内省・検証パターン）
どう間違いを検出し、改善するか——出力の質を、生成後の検査ループで底上げする観点です。評価機構をどう設計するかという事が、AIエージェントの出力の信頼性を決める大きな要因となります。
Reflection
エージェントが自分の出力を評価し、問題点を指摘してから修正する、最も基本的な自己修正パターンです。Goal-directed Loopが「タスクが終わったか」を判定するのに対し、Reflectionは「結果が妥当か」を自分で振り返る点が異なります。
メリット：タスク実行と自己評価の頭を切り替えさせることで(タスクを明確にわける事で)、特に大きな設計変更なく、精度の向上が期待できるリーズナブルな形です。人間でも「タスクが終わったら、最後に見直してね」という依頼で、意外と更に良くなるのと同様です。
デメリット：振り返りによるLLMの呼び出しが増える分、コストとレイテンシは増加します。ほぼミスがないタスクかつ速度重視の場合は、あえてリフレクションさせなくても良いでしょう。あくまでトレードオフなので、リフレクションが効くかどうか試してみて、採否を検討するのが良いかと思います。
有効なユースケース：コード生成や文章作成など、自己チェックで明確な改善余地が見えているタスクに向きます。逆に、そもそも良し悪しの基準がAIにも判定できないタスクでは、むしろ修正によって品質が下がったり、無限ループになる可能性があります。何をもとに自己評価するのかという観点でのインストラクションが重要になります。
Local Reflection
タスク全体の最終結果ではなく、個々のステップやサブタスクの直後にその場で妥当性を自己チェックする、粒度の細かいリフレクションです。
メリット：個々のステップの直後にその場でチェックするので、誤りが後工程まで伝播する前に食い止められます。粒度が細かい分、問題が起きた箇所も特定しやすく、モジュールの改善やデバッグも容易になります。特に最終アウトプットまでのステップが長い場合は、このように品質を積み上げていく形が良いでしょう。
デメリット：ステップごとにチェックが入る以上、オーバーヘッドは確実に積み重なります。すべてのステップに同じ厳しさでチェックを入れると、かえって全体のスループットを落としてしまうこともあります。細かければ良いというものでもないため、どの粒度で内省させるかという設計が重要になります。
有効なユースケース：多段のツール呼び出しやコード編集のように、途中の小さなミスが後工程に致命的な影響を与えるタスクに向いています。逆に、多少の誤りを後でまとめて直せるなら、次のGlobal Reflectionの方が効率的です。
Global Reflection
ステップ単位ではなく、タスク完了後に成果物と実行過程全体を俯瞰して評価・改善するリフレクションです。
メリット：ステップ単位の細かい振り返りでは見えない、全体としての整合性や目的適合をまとめて担保できます。部分最適の積み重ねだけでは品質が上がらない成果物では、このパターンの価値が出ます。また、ローカルリフレクションよりコストとレスポンスのパフォーマンスに優れます。
デメリット：フィードバックが得られるのがタスクの最後になるため、そこで大きな手戻りが発覚するとやり直しのコストは相応に大きくなります。途中経過が見えない分、進行中のリスクを検知できないという設計上の弱点もあります。
有効なユースケース：長文レポートやマルチステップ計画のように、部分よりも全体の一貫性が問われる成果物に向きます。実際には、Global Reflectionをまず試してみて、弱い所にLocal Reflectionを入れていく(頑強性を高める)という形になるでしょう。
Generator-Evaluator
LLMの非常に重要な特性の一つとして、自分の出力を高く評価するという傾向があります。これは私の仮説ですが、ユーザーとのアラインメントによるモデル調整の中で、不安そうな回答や、常に中立を貫く回答より、自信を持って回答してくれるLLMのほうがユーザーの印象が良く、そちらにバイアスがかかっているのではないでしょうか。 つまり、LLMは自己評価が基本的に高いため、セルフチェックの弱点を補うために、生成担当のエージェントと、受入基準に照らして合否を判定する検証担当のエージェントを役割として明確に分離するパターンです。人間の場合でも、作成者と評価者は基本的に分けるべきなのと同様になります。
メリット：異なるLLMモデルや敵対性レビューを目的とした別エージェントに分けることで、第三者レビューが可能になります。検証側は生成の経緯を知らないまま成果物だけを見るため、「自分で書いたものだから大丈夫だろう」という判定の甘さが入り込む要素を除外できます。Claude Codeで開発した内容をCodexにレビューさせるという事を試したことがある方はよくわかると思いますが、別の切り口で様々な問題点を指摘してくれます。この第三者による敵対性レビューを繰り返す事で、品質の大きな向上・抜け漏れの抑制が期待できます。
デメリット：過程などのコンテキストをあまり渡さないというのは良い面もありますが、悪い面もあります。特に背景や過程を知らない人にプレゼン資料のレビューをお願いしても、的外れな指摘が返ってくる可能性もあります。レビュー側のエージェントにはどの観点でレビューさせるのか、目的は何なのかという事を正しく指示しないと、無意味なレビューと改善だけが繰り返される可能性があります。また、反復回数の上限を設けておかないと、合格の出ない修正ループが延々と続くリスクがあるため、上限とエスカレーション経路は必ずセットで用意する必要があります。
有効なユースケース：コードレビュー、セキュリティレビューのように、ある程度合否の基準が定義できるタスク、第三者も含む複数視点で抜け漏れを抑制したいタスクに向きます。リフレクションで抜け漏れが多いなという場合は、Evaluatorを別のエージェントとして切り出す事で信頼性の向上が期待できます。ちなみにEvaluatorは複数のエージェント、モデルで多角的に評価させる形でも良いです。
Self-Heal
コードなどの生成物を実行・テストし、失敗結果を自分へのフィードバックとして自動修正するループです。人手を介さず、テストに基づく動作確認と修正まで自律的に進められるコーディングエージェントの定番パターンです。
メリット：テストという客観的なシグナルをもとに自動修正できるので、人手を介さずテストに基づく動作確認と修正まで自律的に進められます。コーディングエージェントにとっては、ある種必須と言える基本的な仕組みです。
デメリット：テストカバレッジが弱いと、「テストは通るが本質的には誤り」という解にあっさり収束してしまいます。テストの質そのものが甘いと、この仕組みは品質を保証しているように見えて実は何も保証していないという怖さがあるため、テスト自体の品質保証も必要になります。
有効なユースケース：客観的な合否シグナル（テスト結果、ビルドの成否）が得られるコーディングエージェント全般に向きます。テストスクリプトが組めるのであれば、資料作成やその他のタスクにもベースラインの担保として応用できます。
3. Decomposition Patterns（分解パターン）
大きな仕事をどう分解するか——1回のコンテキストに収まらない仕事や、大きなタスクを依存関係のない独立なタスクに分解して処理する観点です。分解には、人間が設計時にサブタスクを固定しておく静的な形や、LLMが入力を見てその場で分解する動的な形があります。適切に問題を分割する事で、モジュール化によるデバッグとトレーサビリティの向上、モデル配置の最適化や並列化による高速化も期待できます。最初はシンプルな形から始めつつも、上手くいかない場合はこのタスク分解を検討するというのも重要な観点になります。ある種、設計者の力量が最も問われる箇所であるとも言えます。
Parallelization
人間が設計時に分割を固定しておく、静的分解の代表です。いわゆるワークフローになりますが、入力のうち各処理に必要な情報だけを切り出して複数のエージェントに渡し、並列に処理させた結果を1点に合成します。Fan-out／Fan-in、Scatter-Gatherと呼ばれることもあります。
メリット：サブタスクが互いに依存しないので、並列処理による高速化が期待できます。各エージェントには必要な情報だけを渡すため、1つの巨大なプロンプトに全部を詰め込むより、それぞれの処理が単純になり精度も安定します。分割が固定なので動きが読みやすく、運用に乗せやすいのも実務では大きな利点です。1つの巨大な問題をハイエンドのモデルで解くのではなく、小さな10個の問題に分割して軽量モデルを利用するなど、コストとレイテンシの調整にも利用できます。
デメリット：あくまでそれぞれが独立に分解できるタスクという点がポイントで、依存関係のあるタスクの場合に無理に分割してしまうと、コンテキスト不足により、1つのエージェントでの実施より精度が落ちる場合があります。分割と統合という2つの処理が増えるため、適切に分割できることと統合時にちぐはぐな結果にならないように注意が必要です。特に、最終的に1つの文章を作るというようなタスクで、各章の作成を個別のエージェントに任せて最後にcombineすると、全体として重複や一貫性のない文章になる可能性があります。どこまでは分割して、どこまでは分割しないのかという見極めが重要になります。
有効なユースケース：複数ソースからの企業情報調査や多面的なコンテンツ審査のように、入力に対して依存関係のない複数の処理を実施するケースに向いています。特に、並列化によるレスポンス向上の効果が大きいので、私も普段から「これ並列化できないかな」と常に考えるようにしています。シンプルですが、実務では頻出のパターンと言えるでしょう。
Orchestrator-Workers
中央のオーケストレーターが入力を分析してサブタスクをその場で動的に決定し、複数のワーカーへ委譲、結果を統合するパターンです。Parallelizationが分割を設計時に固定するのに対し、こちらは実行時にLLMが分割そのものを決める点が違います。
メリット：事前に構造が読めない仕事でも、その場でサブタスクを組み立てて対応できる柔軟性があります。事前の固定分割では対応できない、複雑で予測不能なタスクに強いのが特徴です。Workerの数は固定ではないので、その場で必要な分生成できます。
デメリット：柔軟性が高い分、制御が非常に難しくなります。デバッグ性とトレーサビリティの低下と共に、再現性も低下するため、社内での業務利用においては、タスク分割のルールがかなり明確、または複数のチケット処理を動的に生成したそれぞれのWorkerに割り当てるというようなある程度スコープが明確なタスクでないと品質保証の観点で難しい可能性があります。
有効なユースケース：コーディングエージェントなど、必要な処理が事前に読めないタスク——複数ファイルにまたがるコードベースの開発やリファクタリング——に向いています。柔軟性が高い分、一度の失敗の影響が少ないタスクには向いていますが、高い品質保証が求められるタスクにおいては、サブタスクをルール化し、Parallelizationで処理できないかをまず検討したほうが良いでしょう。動的であり柔軟性が高いというのはあくまでトレードオフになります。
Hierarchical Decomposition
先ほどは一段階の分割でしたが、サブタスクをさらに階層的に分解する、マネージャーの配下にマネージャーがいるような構造です。階層的にタスクを分解する事で、かなり大きいタスクにも対応する事を想定した設計になります。
メリット：サブタスクをさらに階層的に分解できるので、非常に複雑で洗練された成果物も体系的に組み上げられます。各階層で専門分化できる分、1階層のOrchestrator-Workersでは手に負えない規模の仕事にも対応できます。
デメリット：階層が増えるほどアーキテクチャの複雑さとモデル呼び出し数が跳ね上がり、レイテンシもコストも大きく増加します。階層を無闇に増やすと、管理コストが仕事の中身より重くなるという本末転倒なケースにもなりかねません。
有効なユースケース：情報収集→分析→報告書作成のような、多段階かつ各段階で専門分化が必要な大規模調査に向きます。1階層で足りる規模なら、素直にOrchestrator-Workersに留めておいた方が扱いやすいでしょう。
Query Decomposition
複雑な1つの質問を複数の単純なサブクエリへ分解し、個別に検索・回答してから統合する手法で、RAG／検索の文脈で広く使われます。ここまでの3つが仕事そのものを分解するのに対し、こちらはあくまで検索系がメインの話になります。並列化が本質ではなく、複数の目的が混ざったクエリを分解してそれぞれ処理させることで精度の向上が期待できます。
メリット：複雑な1つの質問を単純なサブクエリに分けることで、LLMへの指示内容が明確になります。特にユーザーからの自由入力を受け付ける場合には、クエリ分割が有効な手段となるでしょう。特に複数の観点が混ざったクエリをそのままベクトル検索してしまうと、適切な箇所にヒットしない可能性が高いため、RAGの精度を上げたいときにまず試す価値のある手法と言えます。
デメリット：サブクエリが増えれば増えるほど、検索コストとレイテンシは素直に積み上がります。分解の質そのものに回答精度が引っ張られるため、分解が不適切な場合、むしろそのまま検索するケースより精度が下がることもあります。サブクエリへの分解精度を上げるのか、そもそものインプットの質を上げるのかは設計論点になります。
有効なユースケース：複数観点の比較を含む質問に答えるRAGシステムに向いています。特に入力がやむを得ず複雑になるケースでは、どの単位で検索が必要になるのかというサブクエリの検討が重要になるでしょう。対象のスコープがある程度絞られているなら、サブクエリの分割ルールも明示的に指示したほうが良いかと思います(分割しないケースも含め)。
4. Coordination Patterns（協調パターン）
複数エージェントをどう連携させるか——誰が誰に何を渡し、誰が最終判断を持つのかというトポロジーの観点です。「とりあえずマルチエージェントにすれば賢くなる」というのはよくある誤解で、中央集権にするのか、中央を置かないのかなど、権限管理とタスク委譲の設計として捉えた方が選びやすくなります。
Supervisor
中央のSupervisorエージェントが専門エージェントへタスクを振り分け、結果を統括するパターンです。マルチエージェントでまず最初に検討するのは、おそらくこのパターンでしょう。専門エージェント同士が直接会話することはなく、最終的な意思決定権と会話の主導権は常にSupervisorに残ります。
メリット：専門エージェント同士が直接やり取りしない分、挙動を追いやすく権限管理やログ設計もシンプルになります。最終的な意思決定権が常に1箇所に定まるので、責任の所在をはっきりさせたい業務系のエージェントと特に相性が良い構成です。各エージェントをモジュールとして作りこんでおけば、他のプロジェクトへの横展開・再利用もしやすくなります。
デメリット：すべてのやり取りがSupervisorを経由する以上、Supervisorそのものがボトルネックや単一障害点になりやすくなります。専門エージェントの数が増えるほど、振り分けの精度が全体の品質をそのまま左右する構造でもあります。またSupervisorが膨らみがちなので、シンプルな判断に留められるよう、各エージェント間とのメッセージの設計も重要になります。
有効なユースケース：役割分担が明確で、責任の所在をはっきりさせたい業務系エージェントに向きます。Supervisorと各エージェントが密にやり取りする形ではなく、各エージェントがある種自己完結的にタスクを完遂し、結果を戻すというケースに向いています。逆に、Supervisorと各エージェントのやり取りが高頻度で発生し続けるケースでは、収束しない可能性がある点に留意が必要です。
Handoff
あるエージェントが会話の制御権を、より適切なエージェントへ渡して自分は退くパターンです。Supervisorが仕事を割り振って結果を回収し、最後まで責任を持ち続けるのに対し、Handoffでは渡した側は以後関与せず、受け取ったエージェントがそのままユーザーと直接やり取りします。コールセンターで「担当におつなぎします」と転送され、以後はその担当と話す形と同じです。
振り分け役から専門エージェントへ一方向に渡すのが基本形ですが、専門エージェント同士も含めてどこからどこへでも渡せるようにし、全体を見る管理者を置かない構成をSwarmと呼びます。「今どのエージェントが会話を持っているか」だけが状態になります。
メリット：事前にステップが決めきれないタスクでも、途中で気づいた時点で適切な専門エージェントにタスクを引き継げます。各エージェントは自分の専門と「誰に渡すか」だけを知っていればよいので、エージェントを1体足すだけで対応範囲が広がり、個々のプロンプトも小さく保てます。
デメリット：制御権が1体ずつ移るため並列実行はできず、いわゆる統率者や全体管理者もいないため、AからBへ、BからまたAへというたらい回しのループを止める仕組みを自前で持つ必要があります。どのエージェントを経由して完了に至ったのかの追跡や制御も、Supervisor型に比べると格段に難しくなります。
有効なユースケース：カスタマーサポートのように、最初の窓口と最終的な対応者が違い、しかも途中で話題が変わるため事前に振り分けを決め切れない対話型のタスクに向いています。処理の順序が決まっている業務なら、ワークフロー型で組むかSupervisorを置く方が圧倒的に扱いやすいでしょう。各AIエージェントの守備範囲がもっと大きくなっていく世界では、このケースも増えてくるようになるかもしれません。
Group Chat
複数のエージェントが同じ会話スレッドを共有し、前の発言を読んだうえで順番に発言していくパターンです。Supervisorが各エージェントに仕事を割り振って結果を回収するプロジェクトマネージャー型だとすれば、こちらは全員が同じ会議室で議論する会議型です。各エージェントが順番に発言する形や、会話を見て次の発言者を指名するChat Managerのような司会役を置く形もあります。
メリット：複数のエージェントが同じスレッドで議論を重ねる過程がそのまま残るので、エージェント間の透明性は非常に高くなります。1つの視点では出てこないアイデアが、掛け合いの中から自然に出てくるのもこの形の面白いところです。
デメリット：エージェントの数が増えるほど収拾がつかなくなる可能性があり、実務では3体程度までに抑えるのが目安とされています。誰かが交通整理をしないと、いつまでも結論が出ない会議と同じ状態になりえます。
有効なユースケース：設計レビューや企画レビューのように、専門家同士の反論と修正そのものに価値がある場面に向いています。単に複数の意見を個別に聞きたいだけならParallelizationで十分ですし、業務処理ならSupervisorの方が扱いやすいので、Group Chatを選ぶケースはそれほど多くないかもしれません。特に収束ルールをどこで担保させるかが重要になり、気が付けばSupervisor型のようになってしまっているかもしれません。
Blackboard
エージェント同士が会話せず、共有の作業状態（黒板）に各自が読み書きすることで間接的に協調するパターンです。Group Chatが会話を共有して順番に発言するのに対し、こちらが共有するのは仮説・途中結果・タスク一覧といった構造化された状態で、各エージェントは順番を待たず、黒板を見て自分が貢献できる状態になったときに書き込みます。会議ではなく、共有ホワイトボードに各自が付箋を貼っていく形だと考えると分かりやすいでしょう。黒板そのものが解に収束していくのがこのパターンの特徴です。
メリット：エージェント同士が直接やり取りしなくて済むため、疎結合になりエージェントの追加・削除が容易になります。誰がいつ貢献するか決まっていない、探索型の問題解決とは特に相性が良い構成です(直接やりとりはさせないが、緩く情報連携はさせたい場合)。
デメリット：共有状態への書き込みタイミングが重なると、競合や不整合が起きやすくなります。また、明示的に順番を制御する形ではないため、順序や依存関係の大きいタスクでの採用は難しいでしょう。
有効なユースケース：各エージェントが非同期・不定期に貢献する探索型の問題解決に向いています。厳密な順序や責任の所在を明確にしたいなら、Supervisorのような中央集権型の方が向いています。
5. Context Management Patterns（コンテキスト管理パターン）
必要な知識をAIにどう持たせるか——コンテキストウィンドウというAIにとって最も重要なリソースをどうマネジメントするかという観点になります。プロンプトにすべてを詰め込むのではなく、忘却も意識して、必要なときに必要な分だけ取り出す設計が重要になります。
Skills
必要な手順・専門知識を、常時プロンプトに載せるのではなくオンデマンドで読み込ませる仕組みです。段階的読み込みの形にする事によってコンテキスト効率がよく、テンプレートファイルやスクリプトも含めてパッケージ化できるため、移植性と再利用性にも優れます。AIに必要な能力を外付けできる仕組みです。 この段階的読み込みはProgressive Disclosureとも呼ばれ、典型的には3段階です。常時載せるのは名前と1行の説明の一覧だけ、選ばれた時点でスキル本体を読み、本体の中で参照されたときに初めて詳細資料やスクリプトを読みます。スキルが50個あっても、常時コンテキストに載っているのは50行の目次だけ、という状態を作れます。同じ考え方はツール定義にも使えるので、MCPなどでツール数が膨らんだ場合にも有効です。
メリット：必要な手順や専門知識をオンデマンドで読み込むので、プロンプトを肥大化させずに多数の領域をカバーできます。1つのエージェントが持てる知識・能力の幅を、実用的に広げられる仕組みです。
デメリット：スキルの数が増えるほど、どのスキルを読み込むべきかというルーティング自体のトークンコストが増えていきます。また、スキルを使うかどうかはAIの判断なので、必要なタイミングで必要なスキルが必ず呼ばれるという保証はありません。例えば、後処理で必ずやってほしい処理があるなら、スキルを追加してプロンプトとして指示するのではなく、ステップとして分離してしまったほうが良いでしょう。
有効なユースケース：定型的なタスクを多数任せたい汎用型エージェントで効果を発揮します。スキルとして分離して育てることで、組織で再利用できる事も1つの利点になります。ただ、特化型AIエージェントのように、必要な処理を必要なタイミングで呼ばせるという厳密性が重要なケースでは、ロジックとして組んでしまったほうがよいので、積極的にスキルを採用する事はそれほどないかもしれません。Cowork系エージェントではデフォルト機能として搭載されているように、汎用型エージェントには必須の仕組みとなります。
Scratchpad
コンテキストが逼迫しがちな長い処理において、中間結果をファイルなどの作業用領域に書き出し、コンテキストを圧迫せずに後から参照できるようにするパターンです。あくまで1つのタスクの中で使う作業メモで、タスクが終われば捨てる前提のものです。セッションをまたいで残したい情報は、後述するMemoryの役割になります。
メリット：中間結果を作業領域に書き出しておけるので、コンテキストウィンドウを圧迫せずに長い作業過程を保持できます。長時間タスクの状態や途中経過を後から振り返れるという副次的な利点もあります。実行計画をコンテキストウィンドウの中に持つとどんどん流れていってしまいますが、このように外部化させチェックリストとして利用することで、計画の遵守性と信頼性の向上が期待できます。
デメリット：何を残して何を消すかという管理設計を適切に実施しないと、スクラッチパッド自体がある種雑多なメモと化してしまいます。書き込みと読み込みのルール定義が重要になります。
有効なユースケース：多数の中間ステップを伴う長時間タスクに向きます。長い処理では古い情報がコンテキストウィンドウ外に押し出されたり、圧縮・要約の対象になるため、重要な情報はコンテキストウィンドウの外部に出しておくという戦略は非常に重要になります。ただ、一つのエージェントを大きくして、記憶の外部化を必要以上に試行錯誤するより、目的やステップ別にエージェントを分割し、1つのエージェント自体のサイズを小さく保つほうが全体としてはシンプルになるケースもあります。
Context Triage
コンテキストウィンドウ、つまり今回のLLM呼び出しに渡す情報の中身を、ステップへの関連度に応じて「そのまま残す」「要約して残す」「捨てる」の3つに振り分ける運用です。対象は会話履歴、ツールの出力、検索で拾った文書、メモリから引いた内容等で、トリアージという文字通り、全てを等しく扱わずに対応を変えることが肝になります。
実務においては明確な契機がいくつかあり、ツール出力が返ってきた直後に巨大な結果を切り詰める毎ターンの機械的なフィルタ(特にブラウザ操作系では必須)、コンテキストがウィンドウの7〜8割に達したときに古い履歴をまとめて要約に置き換える圧縮、そしてサブタスクが完了したときに途中経過を保持するか、結論だけ残すかという整理です。処理の複雑性が増加した際には、このようなトリアージの考え方が必須となります。
メリット：重要度・関連度で情報を取捨選択することで、コンテキストの浪費を防ぎ応答品質の劣化を避けられます。情報を足すのではなく引く発想に切り替えるだけで、パフォーマンスが目に見えて改善することも珍しくありません。LLMがいま一つ的を射ない対応やレスポンスになってきたなと感じた場合は、トリアージを優先検討し、コンテキストをコンパクトに保つ事が有効になります。
デメリット：選別の基準を誤ると、本当に必要な情報まで一緒に落としてしまう危険があります。何を残すかの判断ロジック自体が甘いと、削っているつもりが逆に精度を落とすことにもなりかねません。不要な情報を渡す必要はもちろんないのですが、どちらかというとコンテキスト不足による性能低下が初期フェーズでは大きく出るので、コンテキストを最初は多めに渡しつつ、不要な箇所を削りながら性能を見ていくという戦略が効率的でしょう。
有効なユースケース：長時間稼働するエージェントや大量のツール出力を扱うタスクではトリアージの検討が必須になります。一方で、各エージェントのサイズやタスク範囲を小さく保つことで、そこまで神経質になる必要もないケースもあります。なんとなくのイメージでトリアージしてしまって、重要な情報が落ちないように留意が必要です。明らかに後続プロセスでは不要な情報に関しては(特にツール呼び出し系に付随するレスポンス)、LLMにとってノイズにしかならないので、積極的に落としてしまってよいでしょう。
Memory
単一のタスク内だけでなく、セッションをまたいで情報を引き継ぐためのパターンです。コンテキストウィンドウは1回の会話が終われば消えますし、Scratchpadもそのタスクが終われば役目を終えます。つまり、何もしなければエージェントは毎回初期化された状態から始まります。そこで、1回の会話内で完結する短期記憶（Working Memory）と、セッションをまたいで残す長期記憶（Long-term Memory）を分けて設計します。短期記憶の実体はコンテキストウィンドウそのもので、長期記憶は外部のストアです。すべてを長期記憶化するとコンテキストがすぐに肥大化するため、「後で使う価値がある事実か」を判定してから長期記憶へ昇格させる設計、また長期記憶から不要な情報は定期的に削除する設計も重要になります。
メリット：セッションを跨いだ文脈を維持できるので、前回のタスク実行時の成功・失敗事例を学ぶことができます。ユーザーやプロジェクトごとに継続的な関係を積み上げていけるのは、単発のタスク実行にはない大きな価値です。また、この長期記憶はナレッジとして他のエージェントと共有することも可能です。
デメリット：何を長期記憶へ昇格させるかの判定ロジック自体に保守コストがかかり、古くなった記憶が誤った前提のまま使われ続けるリスクも常につきまといます。長期記憶化して再利用する仕組みは直感的には有効そうですが、特殊なケースをエージェントが重要と誤判断して長期記憶化すると、その誤った前提が後続セッションでも使われ続け、性能を継続的に低下させる危険があります。基本的には長期記憶への書き込みは人間の承認に基づいて実施させたほうがよく、AIに直接長期記憶を更新させる場合は、何かしらの評価機構がセットで必要になるでしょう。直感的な仕組みのわかりやすさと実務利用の容易性は必ずしもイコールではありません。
有効なユースケース：同じユーザー・同じプロジェクトと繰り返しやり取りするエージェントでのナレッジ化に力を発揮します。中途半端に導入すると、管理項目が増え、エージェントの動作に影響を及ぼす以上、制御も複雑化します。まずは過去事例の参照のような使い方から始めるのが良いかもしれません。
6. Autonomy & Control Patterns（自律制御パターン）
自律実行をどう制御するか——エージェントがどこまで自由に動いて良いかの境界線を引く観点です。「自律的に動く」という言葉に引っ張られて何でも任せてしまうと、いつまでも処理が終わらないという無限ループに陥る可能性があります。ただただ自律化すればいいというわけではなく、自律化を検討する場合は、合わせて適切なハーネス機構（上限を切る、終わりを定義する、人間に確認・委譲させる等）の設計が必須になります。
Step & Token Budget
実行できるツール呼び出しや推論ループの回数、利用可能なトークン数にあらかじめ上限を設ける制御機構です。いつのまにかLLMの利用コストが膨大な額になっていたという事を防ぐための仕組みで、AIエージェントの開発を開始する際には、一番最初に考慮すべき点になります。特に開発者の経験がまだ浅いケースでは事故が起きがちなので、開発チームの管理者が最も気を配るポイントであると言えるでしょう。自律性とのトレードオフによって生じる最悪のケースのインパクトを下げておくための設計になります。
メリット：実行回数とトークン数にあらかじめ上限を設けておくだけで、無限ループやコストの暴走を確実に防げます。仕組みとしてはシンプルですが、自律性の高いエージェントにおける安全弁として必須となる設計です。私は実行時間も測っていて、例えば、今回のユースケースで10分以上AIが動いているとすればそれは何かしらのエラーが発生しているなというケースでは、実行時間の上限を10分にして、上限を超えた時点で強制終了するようにしています。
デメリット：上限を低く設定しすぎると、正当なタスクなのに未完了のまま強制終了させられてしまいます。適切な上限値そのものがタスクごとに変わるため、本来の目標値に少し余裕を持たせた形で上限を設定しつつ、定期的な見直しが必要になるでしょう。
有効なユースケース：自律性の高いエージェント全般、特にReActやGoal-directed Loopのようなループ系パターンには必須の組み合わせです。ステップ数が最初から決まっている定型処理やループ機構を持たない場合には不要になります。
Termination Condition
エージェントのループを終了させる、明示的な判定基準です。Step & Token Budgetが「これ以上は回させない」という異常系の打ち切りであるのに対し、こちらは「目的を達したから止まる」という正常系の出口を定義します。ループの終わり方は基本的にこの二通りしかないため、ループを設置する際は、必ず正常系と異常系をセットで用意する必要があります。
メリット：適切に終了条件を明示・判定することで、既に目的を達成しているにもかかわらず追加の不要なタスクを繰り返してしまうというような事象を回避できます。「いつ終わるべきか」を明示的に定義しておくこと自体が、設計の質を底上げする効果もあります。
デメリット：条件の定義が曖昧だと、実際には不完全な結果のまま「終わったつもり」になってしまう危険があります。逆に条件を厳しくしすぎると、今度はいつまでも終わらないという反対方向の問題も起こり得ます。
有効なユースケース：固定ステップ数を決められない動的な計画エージェント全般で必須になります。LLMに判定させるとどうしても曖昧さが生じてしまうため、終了判定をプログラムによって機械化できるのであればそのほうが望ましいでしょう。終了判定に特化したサブエージェントを分離し、客観的に評価させるという形も一つの選択肢になります。
Human-in-the-loop
ワークフローのどこかに人間の判断を組み込み、その時点で実行を一時停止して、人間の応答を待ってから再開するパターンです。どこまでをAIに任せ、どこから人間が引き取るかという線を引く考え方そのものになります。一時停止と再開を挟む以上、通知の仕組みや待機中の状態の保持、人間への情報の提示と操作UIといった、やり取りを支える基盤が別途必要になります。
人間を呼ぶ方式には大きく2つのケースがあり、1つは、設計者があらかじめ「このアクションの前では必ず止まる」と決めておくApproval Gate、もう1つは、エージェント自身が「これは自分の手に負えない」と判断した時点で引き渡すEscalationになります。
Approval Gate
Human-in-the-loopの中でも最も基本的な形で、送金・削除・本番デプロイなど、権限・影響の観点で重要な操作の実行直前に、承認を必須にするゲートです。汎用系のAIエージェントやCluadeCode, Codexなどを使った事がある人はよくわかると思いますが、特定の操作の前に承認をするかどうかの設計が基本的に組み込まれています。
では、どの操作にゲートをかけるのでしょうか？固定のリストで決めておく形が基本ですが、影響範囲や可逆性からアクションごとにリスクを評価し、低リスクなら自動実行、高リスクなら承認へと動的に振り分ける形もあり、こちらはRisk-based Routingとも呼ばれます。ただ、この場合はリスク評価の精度に安全性が依存するため、低リスクと誤判定された高リスク操作がそのまま実行されてしまう可能性がある点には注意が必要です。
メリット：常に確認させると煩雑ですし、勝手に全て処理させるのは危険ですが、特定の処理の前に必ず人間の判断を挟む事ができるため、AIエージェントの運用の安全性を高める事ができます。適切なタイミングでガードレールを入れる事で、知らない間にDBのレコードを全て削除してしまっていたり、社外にメール送信してしまったりという事故を防ぐ事ができます。また、承認ログがそのまま監査証跡にもできるため、実務上非常に重要な観点にもなります。
デメリット：過度に承認設計を入れてしまうと、人間の対応待ちがボトルネックになり、せっかくの自律性のメリットが薄れてしまいます。承認件数が増えすぎると、確認自体が惰性になり、承認が形骸化しやすいという問題にもなり得ます。なるべく必要最小限にしつつ、前と後ろになるべく寄せるというように頻度を減らす設計も重要になります。
有効なユースケース：金銭のやりとり・本番環境・顧客対応など、誤りの復旧コストが高いアクションに絞って使います。低リスクな読み取り専用の操作にまで適用すると、自律性を自ら低下させることになるので、避けた方が良いでしょう。
Escalation
エージェントが自身の能力や権限の限界に達したと判断した際、人間へ処理自体を引き継ぐパターンです。Approval Gateはあくまで特定処理の実行可否を確認する行為でしたが、こちらは処理自体を人間が引き継ぐ形になります。
メリット：自分では対応できない想定外のケース、または責任・権限上AIで対応してはいけないケースを、安全に人間へ引き渡せます。AIが勝手に判断して処理を進めないように、「引き際」を仕組み化できるのは、実務上非常に重要になります。
デメリット：エスカレーションの基準が曖昧だと、過剰に人間に引き渡しすぎる、あるいは逆に引き渡すべき場面でも自分で対応してしまうという両極端に振れてしまいます。基準の精度がそのままシステム全体の信頼性を左右すると言っても過言ではありません。これは対象のユースケースによって、安全側に倒すのか許容側に倒すのかはケースバイケースになります。
有効なユースケース：Handoffの最終的な到達点、あるいは自動化スコープを超えたインシデント対応の受け皿として機能します。一次対応をAIエージェントで受けつつも、やり取りが一定の回数を超えた場合や、AIにとって想定外のケースが来た場合は人間に引き継ぐという設計にすることで無理なく運用できます。100%自動化をなるべく目指しつつも、この前提で運用設計しておくほうが適用可能範囲が広がるため、全体の自動化率が高くなる可能性があります。
7. Safety & Security Patterns（安全性パターン）
処理の安全な入出力・実行の担保——エージェントに関わる入出力とツール呼び出しを検査する観点です。AIエージェントの処理の各所に配置するべき、ガードレールのパターンになります。
Input Guardrail
プロンプトインジェクションなど、入力段階のリスクを検査・フィルタするガードレールで、入力がエージェントに届く手前に配置します。ユーザーからインプットを受け取り、その内容を元にLLMを呼び出すケースなどでは必須になります。
メリット：プロンプトインジェクションのような攻撃を、エージェントに届く前の入口で早期に遮断できます。特に外部に公開するシステムにおいて、ユーザーのチャット入力を受け付ける場合は、最も留意すべきポイントになります。基本的にはユーザーからのクエリをそのままLLMに渡すというようなことはなく、適切なルーティング・フィルタ処理を入れた上で、エージェントに流していくという形になります。メリットというより、設計としては必須と言えるでしょう。
デメリット：誤検知（正当な入力の拒否）と検知漏れは常にトレードオフの関係にあり、バランス調整には継続的なチューニングが必要になります。厳しくしすぎるとユーザー体験を損ない、緩くしすぎると存在意義がなくなるという難しさがあります。入力側の自由度をそもそも下げるという対策もあります(自由入力を禁止して選択式にする等)。
有効なユースケース：ユーザーからの入力を伴うすべてのエージェントシステムの入口で必要になります。社内の閉じた環境で信頼できる入力しか受け取らないというケースであれば、少し厳密性は下げても良いですが、特に社外へ公開する場合は、最も留意して設計するポイントになります。
Output Guardrail
最終出力をユーザーに返す前に、機密情報の漏洩や有害コンテンツを検査するガードレールです。文字化けやレイアウト崩れなど、ユーザーに出してはいけない品質のものをアウトプットしないという制御にも利用できます。
メリット：ユーザーに届く直前に、機密情報の漏洩や有害コンテンツを最後にもう一度検査できます。入口や途中の対策を仮にすり抜けてしまっても、最終ゲートを適切に設計しておくことで、ユーザーへ提示される前に食い止められるという安心感があります。開発・プロトタイプで色々と中間ステップを試行錯誤する前に、この出力のガードレール設計を優先して対応しておくことで、不要な懸念やリスクを関係者に広げなくて済むという利点もあります。
デメリット：こちらもInputと同様で、厳しくしすぎると実際は問題はないアウトプットも出力から除外されてしまいます。特に、一定期間待たされた上で最終出力が出ないというのは、ユーザー体験としては最もネガティブになるため、出力のガードレール機構は用意しつつもそもそもここで引っ掛からない状態がベストです。出力ガードレールに引っ掛かったら、その根本原因を解消する形でインプットと中間ステップを見直すという対応が必要になります。
有効なユースケース：LLMの出力をユーザーに返すサービス全般で必須です。内部利用のみで出力先が限定されているケース、ある程度の間違いを許容してでも出力が見たいケースの場合は、少し緩めに調整する形になります。そもそもLLMの自由出力ではなく、固定の選択肢しか返さない形にして、出力のガードレール自体を不要にする設計も検討できます。
Tool Guardrail
これは特に、こちらでコントロールが難しい外部ツール(API,MCP等)の呼び出しの際に重要になるガードレールです。自作の関数などの場合、特にLLMコールの無い物の場合は不要ですが、外部ツールや社外MCPのように、呼び出し先で更にLLMが呼ばれたり複雑な処理が走るケースでは、こちら側で内部処理と出力をコントロールする事ができないため、ユーザーからのインプットと同様に、レスポンス内容をそのまま利用するのではなく、検査プロセスを入れる事が必要になります。
メリット：想定外のレスポンスや、汚染されたツール応答が後続の処理に伝播するのも食い止められます。またツールの呼び出し前にガードレールを入れる事で、個人情報などが外部ツールに渡されていないかの抑止に利用することもできます。
デメリット：チェック項目の設計にはツールごとのドメイン知識が必要で、汎用的なルールだけでは十分にカバーしきれません。ツールが増えるたびにガードレールも個別にメンテナンスする必要が出てくるため、運用コストが重くなります。汎用性の高い外部ツールを採用する場合は、突然のバージョンアップによる挙動の変化も含め留意が必要です。
有効なユースケース：処理の複雑性と汎用性の高い外部ツールを利用する際に重要になります。レスポンス形式がそもそも決まっていて、柔軟性の高くないツールの場合は、そこまで厳格にする必要はないでしょう。
Pre-action Validation
特に不可逆なアクションを実際に実行する直前に、計画やパラメータが制約条件・ビジネスルールに適合しているかを機械的にチェックするステップです。基本的にはHuman-in-the-loop型にすべきですが、人間の全件チェックが難しいケースでAIに実行までさせたい場合は、LLMの判定とは別にこのようなバリデーションステップを別途用意する事で想定外のアクションを未然に防ぐ事ができます。
メリット：不可逆なアクションを実行する直前に機械的にチェックすることで、実行してから間違いに気づくという最悪の事態を防げます。人手を介さない設計という意味では、自動化を阻害しないための実践的な仕組みと言えます。
デメリット：チェックすべきルール自体を網羅的に整備・保守するコストがかかり、ルールが古くなれば当然すり抜けも発生します。ルールベースである以上、想定していなかったケースには対応できないという限界はどうしても残ります。実際にはバリデーションステップとHuman-in-the-loopを併用して、判断に迷うものは人間側に流すという設計が必要になるでしょう。
有効なユースケース：常時人手で確認するほどではないが、自動チェックで多くの誤りを弾ける制約が明確な業務に向きます。判断基準がルール化しにくい業務、クリティカルでミスが許されないケースでは、素直にHuman-in-the-loop型にしたほうが良いでしょう。
まとめ
いかがだったでしょうか。
AIエージェントの設計は、一つの正解が存在しないある種総合芸術のような領域です。今回はAIエージェントを主軸にしたデザインパターンの紹介でしたが、実際には周辺システムや業務プロセス、入出力データを含む全体設計が重要になります。
そして、一つの正解がないからこそ、状況に応じて対応できる引き出しを多く持っているかどうかが、実際の設計においては重要になります(例えばそもそもAIを使わないほうがいいパターンも含めて)。
個人的には、複雑性を最大限まで下げ、どれだけシンプルな形で設計できるかがアーキテクトの腕の見せ所になると思います。マルチエージェント型のAIエージェントで、とりあえずローンチして走りだす事と、安定・継続的に運用できるか(価値を生み出し続けられるか)は全く別の話になります。
【参考】