第1章：はじめに
前回 AI Agent Jump Start：応用編#1 失敗しないAIエージェント設計：段階的導入と目的に応じたデザインパターンの選び方 では、シンプルから複雑へと段階的に導入できる4つの基本パターンを整理しました。
- 決定論的チェーン（Level 0：非エージェント）
- シングルエージェント（Level 1：基本エージェント）
- 順次実行エージェント（Level 2：ワークフロー型）
- 協調型マルチエージェント（Level 3：協調・並行型）
本記事では、基本パターンを設計・実装する上でどのような課題があるのか、それを解決するためのデザインパターンを、論文 Agent Design Pattern Catalogue: A Collection of Architectural Patterns for Foundation Model based Agents に基づき解説します。
Agent Design Pattern Catalogue では、18の設計パターンが体系的に整理されており、各パターンの適用文脈やトレードオフについても詳しく解説されています。
これにより、実際のプロジェクトで遭遇する様々な課題に対して、適切なパターンを選択し活用することが可能になります。
第2章：AIエージェント設計における課題
ここでは、現在のAIエージェント開発で直面する主要な課題を整理し、それぞれの背景と影響について見ていきます。
2.1 幻覚（ハルシネーション）
エージェントは誤った応答を生成するリスクがあります。
背景：複雑なタスク理解が困難
エージェントは複雑なタスクを完全に理解し実行することにしばしば困難を抱え、計画生成や行動手順における推論の不確実性につながります。特に長い計画において、含まれるステップは相互に依存する可能性があり、わずかなステップの逸脱でも全体の成功率に大きな影響を与える可能性があります。
背景：ユーザーからの指示が不明瞭
エージェントとの対話中にユーザーが限定的な文脈、曖昧な目標、不明確な指示を提供する場合があります。
2.2 説明可能性の制限
エージェントの推論プロセスをユーザーに説明することが困難となる可能性があります。
背景：内部アーキテクチャーの「ブラックボックス」化
エージェントと基盤モデルの洗練された内部アーキテクチャーが説明可能性を制限し、エージェントが自身の推論ステップを解釈することが困難になっています。
2.3 説明責任プロセスの複雑化
エージェントの行動に対する責任の所在が不明確になる可能性があります。
背景：さまざまなエージェントやツール連携による相互作用の複雑化
高度に自律的なエージェントは、特定のタスクについて他のエージェントやツールに委任して実行されることがあります。このような状況では、責任と説明責任が複数の実体間で絡み合う可能性があります。
第3章：AIエージェント設計デザイン・パターン
Agent Design Pattern Catalogueで提示された18のパターンは、AIエージェントの機能コンポーネント（カテゴリー/活用シーン）に基づいて体系的に分類することができます。
論文には明示的に機能コンポ―ネントとパターンの分類はなされていません。筆者の意図で分類したものです。
出典：Agent Design Pattern Catalogue
| 機能 | 課題へのアプローチ | パターン | 概要 |
|---|---|---|---|
| ゴール設定 | 複雑なタスクの理解と実行における困難を解決するため、タスク分解と目標設定を体系化 | 受動的ゴールクリエーター（Passive goal creator） | 対話インターフェースを通じてユーザーの明確な指示を分析 |
| 能動的ゴールクリエーター（Proactive goal creator） | ユーザーの行動履歴や環境情報を分析して自動的に目標を予測・提案 | ||
| 計画生成 | 複雑なタスクの理解と実行における困難を解決するため、タスク分解と目標設定を体系化 | ワンショットモデルクエリ(One-shot model querying) | 単一のクエリで計画を生成 |
| インクリメンタルモデルクエリ(Incremental model querying) | 段階的なクエリで計画を精緻化 | ||
| シングルパスプランジェネレーター（Single-path Plan Generator） | ユーザーの目標達成につながる中間ステップの生成を調整 | ||
| マルチパスプランジェネレーター（Multi-path Plan Generator） | ユーザーの目標達成につながる各中間ステップで複数の選択肢を生成 | ||
| 入出力最適化 | ユーザーからの限定的な文脈や曖昧な指示による仕様不足の改善 | プロンプト/レスポンス最適化（Prompt/Response Optimiser） | 入力または出力内容と形式に応じてプロンプト/レスポンスを最適化 |
| RAG（Retrieval-Augmented Generation） | 外部知識の活用による回答精度の向上 | ||
| 振り返りと改善 | 説明可能性の向上とエラーの早期発見・修正 | セルフリフレクション（Self-reflection） | エージェント自身による推論プロセスの検証・改善 |
| クロスリフレクション（Cross-reflection） | 他のエージェントや基盤モデルからのフィードバック・改善 | ||
| ヒューマンリフレクション（Human Reflection） | 人間からのフィードバックを収集・改善 | ||
| 協調とコラボレーション | 複数エージェント環境での責任分散を管理し、協調的な問題解決を実現 | 投票ベース協力（Voting-based Cooperation） | 複数エージェント間で投票による合意 |
| 役割ベース協力（Role-based Cooperation） | エージェントの役割に従って意思決定 | ||
| ディベートベース協力（Debate-based Cooperation） | エージェント間での議論を通じた意思決定 | ||
| システム設計と品質保証 | 信頼性、堅牢性、全体的な信頼性を確保するためのインフラ設計 | マルチモーダルガードレール（Multimodal Guardrails） | 基盤モデルの入力と出力を制御し、倫理・法律など要件を満たす |
| ツール/レジストリ（Tool/Agent Registry） | 多様なエージェントとツールの管理 | ||
| エージェント・アダプター（Agent Adapter） | エージェントと外部ツールを接続するインターフェースを提供 | ||
| エージェント評価者（Agent Evaluator） | 多様な要件と指標に関してエージェントを評価するテストを実行 |
「計画生成」と「振り返りと改善」のパターンについて以下の観点から詳しく解説します。「協調とコラボレーション」については次回の記事で取り上げます。
- パターンの意図：問題と解決策の概要
- 解決策の詳細
- メリット・デメリット
各パターンは単独で使用できるだけでなく、組み合わせることでより強力で信頼性の高いAIエージェントシステムを構築することが可能です。
3.1 「計画生成」におけるパターン
3.1.1 ワンショットモデルクエリ（One-Shot Model Query）
出典：Agent Design Pattern Catalogue
| 大項目 | 小項目 | 内容 |
|---|---|---|
| パターンの意図 | 課題 | エージェントはどのように効率的に計画のステップを生成できるか？ |
| 解決策 | 基盤モデルを一度だけ呼び出して、必要なすべての計画ステップを生成する | |
| 適用場面 | ユーザーがエージェントに特定の目標を伝えて対話する際の計画生成場面 | |
| 解決策の詳細 | 1. 単一クエリでの計画生成：ユーザーが指定した目標と制約に基づいて、基盤モデルに1回だけクエリを実行 2. 包括的な理解：ユーザーの要件（例：限られた予算）を考慮して、提供された入力を一度に理解 3. 多段階計画の策定：広範な目標を達成するための多段階計画を考案し、包括的な説明を提供 |
|
| メリット | 効率性 | 基盤モデルを一度だけクエリすることで消費時間を節約 |
| コスト効率性 | クエリが1回のみのため、ユーザーの費用を削減 | |
| シンプルさ | 複雑な行動計画を必要としないタスクに十分対応可能 | |
| デメリット | 過度の単純化 | 複雑なタスクですべての要件を一度に完全に把握できない可能性（複雑なタスクには不適切な場合がある） |
| 説明可能性の不足 | 計画生成の詳細な推論ステップを提供できない | |
| コンテキスト制限 | トークン制限により応答品質が制約される可能性 |
3.1.2 インクリメンタルモデルクエリ（Incremental Model Query）
出典：Agent Design Pattern Catalogue
| 大項目 | 小項目 | 内容 |
|---|---|---|
| パターンの意図 | 課題 | 基盤モデルは最初の試行で正しい応答を生成するのに苦労する可能性がある。エージェントはどのように正確な推論プロセスを実行できるか？ |
| 解決策 | プラン生成プロセスの各ステップで基盤モデルにクエリし、計画を生成する | |
| 適用場面 | ユーザーからのフィードバックを反映し、計画を生成して応答する | |
| 解決策の詳細 | 1. 段階的推論の実行：基盤モデルへの複数回のクエリを通じて段階的推論プロセスを実行し、目標達成のための計画を段階的に開発 2. フィードバック統合：推論プロセスと生成された計画の両方に人間からのフィードバックを受信し、モデルクエリ中に適宜調整を実施 3. クエリ管理：クエリ回数をエージェント設定で事前定義またはユーザープロンプトで決定し、再利用可能なテンプレートを使用してプロセスを導く 4. テンプレート活用：コンテキスト注入または明示的なワークフロー/計画リポジトリを通じた管理を行い、他のコンポーネントが統合基盤モデルにクエリする際に適用 |
|
| メリット | 補助的コンテキスト | インクリメンタルモデルクエリにより、ユーザーは限られたコンテキストウィンドウの問題に対処するため、コンテキストを複数のプロンプトに分割できる |
| 推論の確実性 | 基盤モデルは自己チェックまたはユーザーからのフィードバックにより推論ステップを反復的に改良する | |
| 説明可能性 | ユーザーはインクリメンタルモデルクエリを通じて詳細な推論ステップを提供するよう基盤モデルにクエリできる | |
| デメリット | オーバーヘッド | インクリメンタルモデルクエリは基盤モデルとの複数の相互作用を必要とし、プラン決定の時間消費を増加させる可能性がある。商用基盤モデルを利用する際、大量のユーザークエリはコスト集約的になる可能性がある |
3.1.3 シングルパスプランジェネレーター（Single-path plan generator）
出典：Agent Design Pattern Catalogue
| 大項目 | 小項目 | 内容 |
|---|---|---|
| パターンの意図 | 課題 | エージェントはどのようにユーザーの目標を達成するための戦略を効率的に策定できるか？ |
| 解決策 | ユーザーの目標達成につながる中間ステップの生成を調整する | |
| 適用場面 | エージェントはユーザーにとって「ブラックボックス」とみなされるが、ユーザーはエージェントがどのようにユーザーの目標を達成するかのプロセスを気にかける場合がある | |
| 解決策の詳細 | 1. 目標理解と調整：ユーザーの目標を受信し理解した後、単一経路プラン生成器は他のエージェントやツールのためのプランの作成を調整し、タスクの優先順位を付けて段階的に導く 2. 推論と論理的思考：プラン生成プロセスには中間ステップが実行可能で最適であるかどうかの推論と論理的思考を実施 3. 線形プラン形成：各ステップはChain-of-Thought（CoT）のような線形で直接的なプランを形成し、単一の後続ステップのみを持つように設計 4. 自己一貫性確認：自己一貫性を採用して基盤モデルに複数回確認し、最も一貫した答えを最終決定として選択 5. 粒度調整：生成されたプランは与えられた目標に基づいて異なる粒度を持ち、複雑なプランは複数のワークフロー、プロセス、タスク、細かいステップを組み込む |
|
| メリット | 推論の確実性 | 単一経路プラン生成器は複数ステップのプランを生成し、推論プロセスを反映してユーザーの目標達成における不確実性や曖昧性を軽減できる |
| 一貫性 | 相互作用するユーザー、エージェント、ツールに最終目標への明確で一貫した経路を提供する | |
| 効率性 | 単一経路プラン生成器は、不要なステップや注意散漫を排除することで、エージェントの効率性を向上させることができる | |
| デメリット | 柔軟性 | 単一経路プランは、多様なユーザーの好みやアプリケーションシナリオに対応する柔軟性が限られる可能性があり、ユーザーが解決策をカスタマイズできない |
| 過度の単純化 | エージェントは多面的なアプローチが必要な生成されたプランを過度に単純化する可能性がある |
3.1.4 マルチパスプランジェネレーター（Multi-path plan generator）
出典：Agent Design Pattern Catalogue
| 大項目 | 小項目 | 内容 |
|---|---|---|
| パターンの意図 | 課題 | 複雑なタスクや問題に直面した際、包括性と多様性を考慮して、エージェントはどのように高品質で一貫性があり効率的な解決策を生成できるか？ |
| 解決策 | ユーザーの目標達成に至る各中間ステップで複数の選択肢を作成することを可能にする | |
| 適用場面 | エージェントはユーザーにとって「ブラックボックス」とみなされるが、ユーザーはエージェントがどのようにユーザーの目標を達成するかのプロセスを気にかける場合がある | |
| 解決策の詳細 | 1. 不確実性の解決：マルチパス計画生成器は、推論プロセス内の不確実性や曖昧さを解決するために、中間ステップの複数の選択肢を持つ計画を生成 2. 一貫性の確保：相互作用するユーザー、エージェント、ツールに最終目標への明確で一貫したパスを提供 3. 人間の好みとの整合：ユーザーは各中間ステップを確認して計画を最終決定でき、人間の好みをカスタマイズされた戦略に反映 4. 包括性の実現：エージェントは複雑なタスクの推論プロセスで複数の方向性を指定 |
|
| メリット | 推論の確実性 | マルチパス計画生成器は、推論プロセス内の不確実性や曖昧さを解決するために、中間ステップの複数の選択肢を持つ計画を生成できる |
| 一貫性 | 相互作用するユーザー、エージェント、ツールに最終目標への明確で一貫したパスが提供される | |
| 人間の好みとの整合 | ユーザーは各中間ステップを確認して計画を最終決定できるため、人間の好みがカスタマイズされた戦略に吸収される | |
| 包括性 | エージェントは複雑なタスクの推論プロセスで複数の方向性を指定できる | |
| デメリット | オーバーヘッド | タスクの分解とマルチプラン生成により、ユーザーとエージェント間の通信オーバーヘッドが増加する可能性がある |
3.2 「振り返りと改善」におけるパターン
出典：Agent Design Pattern Catalogue
3.2.1 セルフリフレクション（Self-reflection）
| 大項目 | 小項目 | 内容 |
|---|---|---|
| パターンの意図 | 課題 | 生成された計画は基盤モデルの幻覚に影響される可能性があり、計画と推論ステップをどのように見直し、効率的にフィードバックを組み込むか？ |
| 解決策 | エージェントは計画と推論プロセスに対するフィードバックを生成し、自ら改善のガイダンスを提供する | |
| 適用場面 | ユーザーの目標と要件が与えられると、エージェントは目標を達成するためのタスクセットに分解する計画を生成する | |
| 解決策の詳細 | 1. 計画生成：ユーザーがエージェントに特定の目標を促すと、エージェントはユーザーの要件を達成する計画を生成 2. 反省プロセス：ユーザーはエージェントに計画と対応する推論プロセスについて反省するよう指示 3. 推論検証：エージェントは推論プロセスを遡り、特定の中間結果が間違っており、その後のすべてのステップを誤導していないかを検証 4. 調整と改善：推論プロセスを調整・整合させて改善された計画を作成 5. 記憶保存：反省プロセスと結果を継続的学習のためにエージェントの記憶に保存 6. 段階的実行：最終的な計画を段階的に実行 |
|
| メリット | 推論の確実性 | エージェントは自身の応答と推論手順を評価し、エラーや不適切な出力がないかチェックし、それに応じて改善を行うことができる |
| 説明可能性 | 自己反省により、エージェントは推論プロセスを見直し、ユーザーに説明することができ、エージェントの意思決定プロセスの理解を促進する | |
| 継続的改善 | エージェントは記憶や知識ベース、プロンプトや知識の形式化方法を継続的に更新し、反省ステップなし或いは少ない反省ステップでより信頼性が高く一貫した出力をユーザーに提供できる | |
| 効率性 | 他の反省パターンと比較して追加の通信オーバーヘッドが発生しないため、エージェントが自己評価することは時間節約になる。継続的改善により、エージェントは将来より正確な応答を提供し、全体的な推論時間消費を削減できる | |
| デメリット | 推論の不確実性 | 評価結果は自己反省の複雑さとエージェントの生成応答評価能力に依存する |
| オーバーヘッド | 自己反省はエージェントの複雑さを増加させ、全体的なパフォーマンスに影響する可能性がある。自己反省機能を持つエージェントの改良と維持には専門的な専門知識と開発プロセスが必要である |
3.2.2 クロスリフレクション（Cross-reflection）
| 大項目 | 小項目 | 内容 |
|---|---|---|
| パターンの意図 | 課題 | エージェントの能力が制限されており、満足のいくパフォーマンスで反省を行うことができない場合、このエージェントの出力と推論ステップをどのように評価するか？ |
| 解決策 | 異なるエージェントや基盤モデルを使用してフィードバックを提供し、生成された計画と対応する推論手順を改良する | |
| 適用場面 | エージェントはユーザーの目標を達成するための計画を生成するが、考案された計画の品質を評価する必要がある | |
| 解決策の詳細 | 1. 別エージェントへの委任：エージェントが正確な結果や精密な計画ステップを生成できない場合、ユーザーは反省に特化した別のエージェントにクエリを送るよう指示 2. レビューと評価：反省エージェントは元のエージェントのログ出力と関連する推論ステップをレビューし評価し、改良提案を提供 3. 反復プロセス：反省エージェントが計画を確認するまで反復的に実行 4. 複数エージェント活用：包括的な回答を生成するために複数のエージェントに反省をクエリ |
|
| メリット | 推論の確実性 | エージェントの出力とそれぞれの方法論が他のエージェントによって評価・改良され、推論の確実性と回答の精度を保証する |
| 説明可能性 | 複数のエージェントを使用して元のエージェントの推論プロセスをレビューし、ユーザーに詳細な説明を提供する | |
| 包括性 | 複数のエージェントにクエリを送る際、反省フィードバックには異なる推論出力が含まれ、包括的な改良提案の形式化に役立つ | |
| スケーラビリティ | Cross-reflectionは、反省エージェントをシステム運用を中断することなく柔軟に更新できるため、スケーラブルなエージェントベースシステムをサポートする | |
| デメリット | 推論の不確実性 | 全体的な回答の品質と信頼性は、他の反省エージェントのパフォーマンスに依存する |
| 公平性の保持 | 様々なエージェントが反省プロセスに参加する際、提供されるすべてのフィードバックの間で公平性を保持する方法が重要な問題となる | |
| 複雑な責任追跡 | Cross-reflectionフィードバックが深刻または有害な結果を引き起こした場合、複数のエージェントが使用されると責任追跡プロセスが複雑になる可能性がある | |
| オーバーヘッド | エージェント間の相互作用による通信オーバーヘッドが発生する。ユーザーは反省エージェントの利用に対して料金を支払う必要がある場合がある |
3.2.3 ヒューマンリフレクション（Human-reflection）
| 大項目 | 小項目 | 内容 |
|---|---|---|
| パターンの意図 | 課題 | 人間の好みが推論プロセスと生成された計画に完全かつ正確に捉えられ、統合されることをどのように保証するか？ |
| 解決策 | エージェントが人間からフィードバックを収集し、計画を改良して人間の好みに効果的に合わせる | |
| 適用場面 | エージェントは、ユーザーの目標と要件を一連のタスクに分解する計画と戦略を作成する。これらのタスクは他のツールやエージェントによって完了される | |
| 解決策の詳細 | 1. 計画作成：ユーザーが目標と指定された制約を提示すると、エージェントはまず一連の中間ステップからなる計画を作成 2. レビュー提示：構築された計画とその推論プロセスログはレビューのためにユーザーに提示されるか、実現可能性と有用性を検証するために他の人間専門家に送付 3. フィードバック収集：ユーザーや専門家は、どのステップを更新または置換できるかを示すコメントや提案を提供 4. 反復的改善：計画はユーザー/専門家によって承認されるまで反復的に評価・改善 |
|
| メリット | 人間の好みへの整合性 | エージェントはユーザーや追加の人間専門家から直接フィードバックを受け取り、人間の好みを理解し、結果や手続き的公平性、結果の多様性などを改善できる |
| 異議申し立て可能性 | 異常な行動や応答が発見された場合、ユーザーや人間専門家はエージェントの結果に即座に異議を申し立てることができる | |
| 効果性 | 人間反映により、エージェントは計画の改良にユーザーの視点を含めることができ、ユーザーの特定のニーズと理解レベルに合わせた応答の形式化に役立つ。これにより戦略の使いやすさが保証され、ユーザーの目標達成の効果性が向上する | |
| デメリット | 公平性の保持 | エージェントは現実世界について偏った情報を提供するユーザーに影響される可能性がある |
| 限定的な能力 | エージェントは人間の感情や経験を理解する能力がまだ限定的である可能性がある | |
| 不十分な仕様 | ユーザーはエージェントに限定的または曖昧な反省的フィードバックを提供する可能性がある | |
| オーバーヘッド | ユーザーはエージェントとの複数回のコミュニケーションに対して料金を支払う必要がある場合がある |
第4章：意思決定モデル
論文では、18パターンを選択するための意思決定モデルが提案されています。
特定の選択や選択順序は存在しません。
出典：Agent Design Pattern Catalogue
4.1 パターン選択の実践例：代替パターン
代替パターンは、同じ問題に対する異なる解決アプローチを表します。つまり、「AかBか」の関係性です。
特徴と選択の指針
- 同じ設計問題に対して、どれか一つを選択する関係
- プロジェクトの制約と優先順位を明確にします
- 異なるトレードオフ
- 各パターンのトレードオフを比較検討します
- 相互排他的な選択肢となることが多い
- 一つのアプローチに集中して実装します
具体例
問い：エージェントは補完的なコンテキストとしてユーザーの環境情報を取得することができるか？
| 回答 | 代替パターン | アプローチ | メリット/強み | デメリット/トレードオフ |
|---|---|---|---|---|
| NO | 受動的ゴールクリエーター（Passive Goal Creator） | ユーザーとの対話で明確なコンテキストを取得 | + efficiency シンプル、効率的 |
- reasoning uncertainty 推論の不確実性が増す可能性 |
| YES | 能動的ゴールクリエーター（Proactive Goal Creator） | ユーザーの行動や履歴をもとに目標を自動設定 | + accessibility 障害を持つユーザーへの対応、自動化 |
- overhead 複雑性、プライバシーの懸念 |
4.2 パターン選択の実践例：補完パターン
補完パターンは、同じ目標に向かって協力し合うパターンを表します。つまり、「AとBの両方」の関係性です。
特徴と選択の指針
- 同時に使用することで効果を高める
- 異なるパターンの相乗効果を検討します。また、統合の複雑性とメリットのバランスを評価します。
- 異なる側面から同じ問題を支援する
- 段階的な導入を検討します。まず一つのパターンから開始し、後に他のパターンを追加を検討します。
具体例
問い：ユーザーとの効果的なコミュニケーションを実現するには？
| 補完パターン | 役割 | 機能 |
|---|---|---|
| プロンプト/レスポンス最適化（Prompt/Response Optimiser） | 入出力の品質向上 | ユーザーの指示を標準化されたプロンプトに変換 |
| RAG（Retrieval Augmented Generation） | 知識の補強 | 外部知識ベースから関連情報を取得 |
両方を同時に使用することで、より高品質なコミュニケーションを実現します。
問い：複数エージェントによる効果的な問題解決を実現するには？
| 補完パターン | 役割 | 機能 |
|---|---|---|
| 投票ベースの協力（Voting-based Cooperation） | 合意形成 | エージェント間の投票により最適解を選出 |
| 役割ベースの協力（Role-based Cooperation） | 専門性の活用 | 各エージェントが専門分野を担当 |
| のディベートベース協力（Debate-based Cooperation） | 合意形成 | エージェント間の議論により最適解を選出 |
組み合わせることで、専門性と合意形成の両方を活用した協調システムを構築します。
最後に / 次のステップ
本記事では、AIエージェント開発における実践的な課題と、それを解決する18の設計パターンについて、論文「Agent Design Pattern Catalogue」を基に体系的に解説しました。
機能コンポーネント別に整理された18のパターンを通じて、各課題に対する具体的な解決アプローチを提示しました：
- ゴール設定：ユーザーとの対話方式の選択（受動的 vs 能動的）
- 計画生成：タスクの複雑性に応じた計画策定手法（ワンショット vs インクリメンタル、シングルパス vs マルチパス）
- 入出力最適化：プロンプト最適化とRAGによる回答精度の向上
- 振り返りと改善：3つの異なるリフレクション手法による継続的改善
- 協調とコラボレーション：複数エージェント環境での効果的な協力体制の構築
- システム設計と品質保証：信頼性と堅牢性を確保するインフラ設計
意思決定モデルを通じて、代替パターン（AかBかの選択）と補完パターン（AとBの組み合わせ）の概念を紹介し、プロジェクトの制約と目標に応じた適切なパターン選択の方法を示しました。
次の応用編 #3 では、マルチエージェントのパターンを解説します。
Discussion