AI エージェントを構築するすべてのチームが、同じ壁にぶつかります。
最初は 1 つのプロンプトと少数のツールから始まります。
うまくいきます。
しかし、要件が増えていきます。エッジケースが増え、チームが増え、リスクも増えます。
突然、あなたの「エージェント」は 3,000 ワードのシステムプロンプトになり、一度に 5 つの仕事をこなそうとします。
修正策は、もっとプロンプトエンジニアリングをすることではありません。
適切なパターンを選ぶことです。
ここでは、本番環境のエージェントシステムを構成する 15 のパターンと、それぞれを正確にいつ使うべきかを紹介します。
パターンを選ぶ前に
すべてのタスクにエージェントが必要なわけではありません。
タスクにエージェントが必要となる条件は次のとおりです。
→ 1 回のモデル呼び出しで信頼できる結果が得られない場合
→ モデルが実行時にツールやデータソースを選択する必要がある場合
→ タスクに計画、検証、または反復的な改良が必要な場合
→ ワークフローにハードコードできない不確実性が実際にある場合
入力から出力へのパスが予測可能な場合、タスクには通常エージェントは必要ありません。
要約。分類。単純な抽出。テンプレート化された生成。
これらは、直接モデルを呼び出す方が、より速く、安く、信頼性が高くなります。
エージェントでラップすると、レイテンシと障害ポイントが増えるだけで、メリットはゼロです。
パターン 1 — Single Agent（シングルエージェント）
最も単純で最も一般的な開始点です。
1 つのモデル。1 つのシステムプロンプト。制限されたツールセット。
モデルはどのツールを呼び出すかを決定し、結果を確認し、回答するのに十分な情報が得られるまで続けます。
実際の例： 注文状況を確認し、配送状況をチェックし、問題を解決できない場合はチケットを作成するカスタマーサポートエージェント。すべて 2〜3 のツールと 1 つの明確な役割で行います。
使用するタイミング： タスクが明確に定義され、ツールセットが小さく、1 つのエージェントが混乱することなく全体のコンテキストを保持できる場合。
破綻するタイミング： ツールを追加し続け、システムプロンプトが 1 ページを超えて大きくなったとき。それは、より長いプロンプトではなく、別のパターンが必要であるというサインです。
パターン 2 — Multi-Agent Sequential（マルチエージェント・シーケンシャル）
専門化されたエージェントが固定の順序で実行されます。各エージェントの出力が次のエージェントの入力となります。
実際の例： 契約書レビューパイプライン。1 つのエージェントが義務を抽出し、次のエージェントがリスクを特定し、3 番目のエージェントが調達部門向けのサマリーを作成します。この順序は変わりません。
使用するタイミング： ワークフローに明確で繰り返し可能なステージがあり、各ステージが次のステージに必要なものを正確に生成する場合。
破綻するタイミング： プロセス中に見つかった内容に基づいて順序を変える必要がある場合。シーケンシャルパイプラインはパスが固定されていることを前提としています。そうでない場合は、より動的なものが必要です。
パターン 3 — Multi-Agent Parallel（マルチエージェント・パラレル）
独立したサブタスクが同時に実行され、その後 1 つのビューに結合されます。
実際の例： 午前 2 時の本番インシデント。3 つのエージェントがログ、メトリクス、最近のデプロイを同時に調査します。順番ではなく、同時にです。障害対応では毎分が重要だからです。
使用するタイミング： サブタスクが真に独立しており、スピードが重要である場合。
破綻するタイミング： タスクが実際には互いの結果に依存している場合。依存関係のある作業を強制的に並列実行すると、レースコンディションと不完全なコンテキストが発生します。
パターン 4 — Loop（ループ）
終了条件が満たされるまで、一連のステップを繰り返します。
実際の例： データクリーニングエージェント。乱れた CSV データをプロファイリングし、クリーニング計画を提案し、品質基準を満たしているかチェックし、満たしていない場合は再試行します。最大ラウンド数は制限されています。
使用するタイミング： タスクに複数の試行が必要で、明確でチェック可能な停止条件を定義できる場合。
破綻するタイミング： 信頼できる終了条件がない場合。終了条件がないと、コストが際限なく増加し、システムが永遠に終了しない可能性があります。
パターン 5 — Review and Critique（レビューと批評）
審査エージェントが別のエージェントの出力をレビューし、批評し、具体的で実用的なフィードバックを提供します。
実際の例： 生成されたレポートが、人間の目に触れる前に、別の「批評家」エージェントによってレビューされ、根拠の弱い主張、不足している証拠、不明瞭なセクションが指摘されます。
使用するタイミング： スピードよりも品質が重要であり、システムに後付けではなく最初からセカンドオピニオンを組み込みたい場合。
破綻するタイミング： 批評家エージェントが生成エージェントと同じ盲点を持つ場合。同じ前提で訓練されたレビューアは、同じ間違いを見逃します。
パターン 6 — Iterative Refinement（反復的改良）
品質スコアのしきい値を伴うフィードバックループ。生成エージェントは、基準を超えるまで改良を続けます。
実際の例： マーケティングコピー生成エージェント。自分のドラフトをブランドガイドラインに照らしてスコアリングし、最低品質スコアに達するまで書き直しを続けます。単なる合格/不合格のチェックではなく、段階的な改善です。
使用するタイミング： 出力品質が真に変動し、「十分良い」に測定可能なしきい値がある場合。
破綻するタイミング： スコアリング関数が曖昧であったり、ゲーム可能である場合。モデルが実際の改善なしに自己スコアを水増しできる場合、ループはトークンを無駄に消費するだけです。
パターン 7 — Coordinator（コーディネーター）
中央のルーティングエージェントが、実際に尋ねられている内容に基づいて、リクエストを専門のエージェントに振り分けます。
実際の例： サポートチケットは、請求、技術、アカウント、配送、または不正の専門家にルーティングされます。それぞれが狭いコンテキストを持ち、1 つのエージェントがすべてを知ろうとするわけではありません。
使用するタイミング： 異なるコンテキスト、ツール、または決定ロジックを必要とする、真に異なるリクエストタイプがある場合。
破綻するタイミング： ルーティング自体があいまいになる場合。リクエストがきれいに 1 つのカテゴリに分類されない場合、コーディネーターが新しいボトルネックとなり、誤ったルーティングの原因となります。
パターン 8 — Hierarchical Task Decomposition（階層的タスク分解）
ルートエージェントが複雑な目標をより小さなサブゴールに分解し、専門のワーカーに委任し、最終的にすべてを 1 つの回答に統合します。
実際の例： 「来年、どの 3 か国に進出すべきか？」という質問が、競合分析、規制調査、物流の実現可能性、市場規模の推定に分解され、それぞれが異なる専門家によって処理され、その後統合されます。
使用するタイミング： 問題が 1 回の推論パスでは広すぎるが、独立した専門分野にきれいに分割できる場合。
破綻するタイミング： サブゴールが実際には独立していない場合。ワークストリームがリアルタイムで互いに情報を提供する必要がある場合、あらかじめ分解してしまうとその相互作用が失われます。
パターン 9 — Swarm（スウォーム）
複数の専門エージェントが共有の議論に貢献し、互いの前提に挑戦し、ファシリテーターが最終的な推奨事項を統合します。
実際の例： 会社はサブスクリプション層を開始すべきか？ 研究、エンジニアリング、財務、サポートの各エージェントが複数ラウンドにわたってそれぞれの視点を議論し、その後ファシリテーターがトレードオフを検討します。
使用するタイミング： 単一の「正しい」答えがなく、真に競合する視点によって形作られた、よく考えられた決定が必要な場合。
破綻するタイミング： 迅速で決定論的な答えが必要な場合。スウォームは意図的に遅く、探索的です。スピードが必要な場合は間違ったツールです。
パターン 10 — ReAct (Reason and Act)（ReAct：推論と行動）
エージェントが推論と行動を交互に行います。何を調査するかを決定し、ツールを呼び出し、結果を観察し、十分な証拠があるかどうかを判断します。
実際の例： 「キュー処理が停止しているようです」— エージェントはドキュメントを検索し、サービスヘルスをチェックし、調査結果を関連付け、その後に修正を提案します。調査パスは事前に定義されておらず、その過程で見つかったものに依存します。
使用するタイミング： 答えに至るまでのパスが事前に真に計画できず、各ステップで明らかになる内容に依存する場合。
破綻するタイミング： 調査が収束せずに長引く場合。推論と行動のサイクルには常に上限を設定しないと、無限の探索リスクがあります。
パターン 11 — Human-in-the-Loop（ヒューマン・イン・ザ・ループ）
エージェントが調査し推奨しますが、リスクのあるあいまいな決定については人間が最終判断を下します。
実際の例： 返金承認。低リスクで明確なケースは自動化されます。高額、不正の兆候、ポリシー例外は、確定前に人間のレビューのために一時停止されます。
使用するタイミング： 決定に実際の財務、法的、または評判上のリスクが伴い、完全な自動化がまだ受け入れられない場合。
破綻するタイミング： これをアーキテクチャ上の機能ではなく、単なる UI 機能として扱う場合。永続的な状態、レビューアの割り当て、タイムアウト処理、エスカレーションパスが必要であり、単なる「一時停止」ボタンではありません。
パターン 12 — Plan-and-Execute（計画と実行）
プランナーエージェントが、行動を起こす前に、完全な構造化計画を事前に作成します。レビュー可能で修正可能です。その後、実行エージェントがステップを実行します。
実際の例： 「ワーカーフリートを 10 インスタンスから 20 インスタンスにサイズ変更し、キューが排出されることを確認し、ランブックを更新する。」実行開始前に完全な計画が表示されます。ReAct のようにパスが段階的に出現するのとは異なります。
使用するタイミング： 行動を起こす前に計画をレビューまたは承認可能にしたい場合。実際の結果を伴う運用において重要です。
破綻するタイミング： 環境が計画の実行よりも速く変化する場合。古い計画を盲目的に実行することは、計画がないことよりも悪いです。
パターン 13 — Reflexion（リフレクション）
エージェントが自身の失敗を評価し、何が悪かったかを振り返り、その記憶を次の試行に引き継ぎます。
実際の例： コード生成エージェントがスクリプトを作成し、実行時に失敗し、エージェントが実際のエラーを分析し、修正すべき内容を記録し、再試行します。毎回同じ間違いを繰り返すのではなく、試行ごとに賢くなります。
使用するタイミング： 失敗が有益であり、自己修正が次の試行を真に改善する場合。
破綻するタイミング： 障害モードがランダムであったり、互いに関連していない場合。リフレクションは、学習すべき実際のパターンがある場合にのみ役立ちます。
パターン 14 — Custom Logic（カスタムロジック）
ハイブリッド。絶対に間違ってはいけないルールは決定論的なコードで処理し、判断、作成、例外処理はモデルに任せます。
実際の例： 返金ワークフロー。購入確認と不正チェックはハードな決定論的ルールとして実行され、決してモデルに委任されません。一方、顧客への応答の作成やルーティングの推奨はエージェントに任せます。
使用するタイミング： ワークフローに法的または財務的な影響を伴う実際の分岐ロジックがあり、何が決定論的で何が柔軟であるかを正確にする必要がある場合。
破綻するタイミング： チームが線引きを曖昧にし、ハードコードされたルールにすべき決定をモデルに任せてしまう場合。資格、権限、資金移動は、決してモデルだけの判断にすべきではありません。
パターン 15 — Event-Driven Agent（イベント駆動型エージェント）
エージェントは尋ねられるのを待ちません。イベントストリームを購読し、条件がトリガーされた瞬間に行動します。
実際の例： 不正検出エージェント。不審なトランザクションイベントが発生した瞬間に反応します。サポートチケットがその結果として発行されるのを待っていると、手遅れになります。
使用するタイミング： タイミングが何よりも重要であり、人間のリクエストを待つと行動の機会を逃してしまう場合。
破綻するタイミング： トリガー条件が適切に定義されていない場合。トリガーが曖昧なノイズの多いイベントストリームは、常にオオカミが来たと叫ぶシステムになり、さらに悪いことに、本当のシグナルを見逃します。
パターンの選択 — 不確実性に合わせる、誇大広告に合わせない
適切なパターンは、あなたの作業における不確実性の形に一致します。
→ どのツールを使うか不明 → Single Agent または ReAct
→ どこにルーティングするか不明 → Coordinator
→ 品質が不明 → Review & Critique または Iterative Refinement
→ 実行パスが不明 → Plan-and-Execute または ReAct
→ 自己修正方法が不明 → Reflexion または Loop
→ ビジネスリスクが不明 → Human-in-the-Loop または Custom Logic
→ 問題の構造が不明 → Hierarchical Decomposition または Swarm
→ リクエストを待てない → Event-Driven Agent
タスクが 1 つの信頼できるツール呼び出しだけを必要とする場合、スウォームはシングルエージェントよりも高度ではありません。
計画がステップ 3 で古くなる場合、Plan-and-Execute は ReAct からのアップグレードではありません。
最も信頼性の高い本番システムは、最も自律的なシステムではありません。
自律性は、それが価値を生み出す場所に正確に配置され、それ以外のすべての場所で制約されます。
本番エージェントシステムのための 10 のルール
- 機能する最小のパターンから始めること。クリーンなツール契約を持つシングルエージェントは、弱い契約を持つマルチエージェントシステムに勝ります。
- ツールの説明は契約書のように書くこと。モデルがツールについて知るのは説明からのみであり、あなたの意図からではありません。
- リクエストごとに、反復回数、ツール呼び出し、支出に上限を設けること。予算制限のないエージェントは、請求書に現れるまで待機している負債です。
- 完全なアクション証跡をログに記録すること。ツール呼び出し、引数、出力、最終決定。これがないと、インシデント調査は推測になります。
- 取り消し不能なアクションは、決定論的なチェックまたは人間の承認の後ろに置くこと。資金移動や本番変更の前に、モデルだけが唯一のゲートになることを決して許さないでください。
- ハッピーパスだけでなく、実際の障害ケースで評価すること。ハッピーパスの正確性はプロトタイプです。エッジケースの正確性が製品です。
- システムプロンプトが読めなくなる前に、責任ごとにプロンプトを分離すること。「でも Y のときは X をしないで」がプロンプトに忍び込んでいる場合、エージェントは 2 つの仕事をしています。
- マルチエージェントシステムを分散システムとして扱うこと。部分的な障害、タイムアウト、再試行、可観測性はオプションではありません。
- モデルレビューは決定論的検証の代わりにはなりません。品質向上には審査官を使用してください。正しさを強制するには、テストと権限チェックを使用してください。
- より単純なパターンを優先すること。単純な方が常に良いからではなく、節約した複雑さの予算を、より良いツール、より良いプロンプト、より良い評価に使えるからです。
以上が 15 のパターンすべてです。
ほとんどのチームが失敗するのは、間違ったパターンを選んだからではありません。
自分たちが実際にどの不確実性を解決しようとしているのかを、尋ねなかったからです。
パターンを選びましょう。問題の形に合わせましょう。自律性がその地位に値しないところに追加しないでください。
これが役に立ったなら：
→ あなたのチームでエージェントを構築するすべてのエンジニアと共有するためにリポストしてください
→ さらにこのような解説を得るために @sairahul1 をフォローしてください
→ ブックマークしてください — 新しいエージェントプロジェクトを始めるたびに、ここに戻ってくるでしょう
私は AI、製品構築、そしてあなたなしで機能するシステムについて書いています。
