Agent Design Pattern Catalogue: LLMエージェント構築の羅針盤
序文
お疲れ様です、波浪です。
いやー、近頃はFoundation Model（以下FM）をベースとしたエージェントが熱い！ みんなAutoGPTとかBabyAGIとか名前くらいは聞いたことあるんじゃないでしょうか？ GPTが流行って久しいけど、それを使って自律的なエージェントを組み立てる、まさに「ゴール指向型」のAIエージェント構築が世界中で加速しています。
でも、実際にエージェントを設計しようとすると「どこから手をつけりゃいいんだよ！？」って思う人も多いはず。僕も最初はそうでした。なにせ新しい概念やツールがわんさか出てくるし、FMそのものが超巨大なブラックボックス状態。そして「これ、本当に狙ったゴールにたどり着けるの？」みたいな懐疑的な気持ちも出てくるじゃないですか。
そんな悩める子羊たちは俺と一緒に論文（arXiv:2405.10467v3）でも読もうぜ！ そして何かした気になろう！
その名も「Agent Design Pattern Catalogue: A Collection of Architectural Patterns for Foundation Model based Agents」。訳すと「エージェント設計パターンカタログ：基盤モデルベースエージェントのためのアーキテクチャパターン集」…長いわ！
論文で紹介されている18個のパターン。これを「エージェントってどうデザインすりゃいいんだ！？」と悩んだ時に、サクッと使えるガイドとして提示していけたらこれ幸いですね。
昔、CやJavaで大規模プロジェクト組んでた頃は、アーキテクチャパターンなんてGoF本を見ながら「ふむふむ」ってやって。。。やって。。。ごめん嘘こいたあんな本読んでないです、僕は結城浩先生のデザイソパターソ本擦り切れるまで読んでました。GoF本？英語とか読めるわけないじゃん
今はLLMを中心としたエージェント時代。パターンも大きく様変わりしています！
閑話休題
それじゃあ章立てていくぜーーー！！！！！
章立て
- はじめに：FMベースエージェント時代の幕開け
- エージェント設計が難しい理由
- パターンカタログの全体像
-
ゴール生成系パターン
4.1 パッシブゴールクリエイター(Passive Goal Creator)
4.2 プロアクティブゴールクリエイター(Proactive Goal Creator) -
プロンプト・レスポンス最適化系パターン
5.1 プロンプト/レスポンスオプティマイザー(Prompt/Response Optimiser)
5.2 RAG：Retrieval Augmented Generation -
モデルクエリ戦略系パターン
6.1 ワンショットモデルクエリ(One-Shot Model Querying)
6.2 インクリメンタルモデルクエリ(Incremental Model Querying) -
プラン生成パターン
7.1 シングルパスプランジェネレーター(Single-Path Plan Generator)
7.2 マルチパスプランジェネレーター(Multi-Path Plan Generator) -
リフレクション(振り返り)パターン
8.1 セルフリフレクション(Self-Reflection)
8.2 クロスリフレクション(Cross-Reflection)
8.3 ヒューマンリフレクション(Human Reflection) -
マルチエージェント協調パターン
9.1 投票型協調(Voting-based Cooperation)
9.2 ロールベース協調(Role-based Cooperation)
9.3 ディベート型協調(Debate-based Cooperation) -
ガードレール・ツール接続パターン
10.1 マルチモーダルガードレール(Multimodal Guardrails)
10.2 ツール/エージェントレジストリ(Tool/Agent Registry)
10.3 エージェントアダプタ(Agent Adapter) -
エージェント評価パターン
11.1 エージェントエバリュエーター(Agent Evaluator) - これらのパターンをどう活用するか？
- 規制対応や標準化とパターンの関連性
- 評価手法への展望
- まとめ
はじめに：FMベースエージェント時代の幕開け
昔、僕がドラクエ4でクリフトに殺意を覚えている頃、ここまでAIが人間らしく振る舞うなんて想像もしなかった！ ファミコンやスーファミで遊んでた90年代、そしてガラケーでアプリ作ってた時代を経て、今やFM（Foundation Model）と呼ばれる巨大モデルがテキストからコード、画像、何でも理解・生成しちゃう時代です。
関係ないけどこのFMって用語、もう一般用語なの？こないだのre:invent でもAWSがふつーに使ってて一体どう言う概念なのかわかんなかったんだよね俺、まあいいけど。
さてその中で、FMベースのエージェントは一種の「自律的でゴール指向なAI」。ユーザーが「これやっといて！」と言えば、目標を分解し、計画し、実行してしまう。けど、問題は山積み。最終ゴールへのプロセスがブラックボックスだったり、曖昧なタスクで混乱したり、責任の所在が不明瞭になったり……。
そこで、我々にはアーキテクチャパターンが必要になるんだ！ Patterns of patterns！ 昔GoFパターンでオブジェクト指向設計が楽になったように、FMエージェント設計もパターンでスッキリ整理できます。
エージェント設計が難しい理由
「単にLLM（大規模言語モデル）使えばエージェントになるんじゃね？」と思った人、甘い！
実際にはこんな課題があるんです。
- ゴール特定が難しい：ユーザーの要求がふんわりしてて、本当にやりたいことが曖昧。
- 推論の不確実性：計画を立てても、その途中でモデルが妄想（ハルシネーション）することも！
- 説明可能性不足：中で何が起きてるかブラックボックスで不安が拭えない。
- アカウンタビリティ(責任)が複雑：誰が責任持つ？エージェント？ユーザー？開発者？外部ツール？
- データとプライバシー問題：FMモデルを再学習するコストやプライバシー保護も面倒。
こういった苦しさを解決するために、設計パターンが提案されているわけです！
パターンカタログの全体像
紹介するパターンは全部で18種類。
- ユーザーのゴールを処理するための「ゴール生成系」
- プロンプトやレスポンスを最適化する「プロンプト・レスポンス系」
- モデル問い合わせ（クエリ）の仕方を決める戦略的パターン
- プラン生成をどうするかの指針
- 計画を振り返る「リフレクション」
- マルチエージェント間協調（投票、ロール分担、ディベート）
- ガードレールで安全性を担保したり、外部ツール接続を整理したり
- 最後にエージェント自体を評価する仕組みも用意。
このカタログがあれば、「今自分が抱えてるエージェント設計の悩み」に対して、どのパターンが助けになるか見えてきます。
ゴール生成系パターン
ぶっちゃけこれがいちばん大事、計画性のない仕事は全てꘐ（読み仮名：ファー 意味：リビア語、意味は死とかゴミとかそんな意味）です
パッシブゴールクリエイター(Passive Goal Creator)
ユーザーが入力したプロンプトから、エージェントが受動的にゴールを特定するパターン。「とりあえずユーザーが言ったことを元に、ゴールを固める」。
簡単だが、ユーザー任せなんで、曖昧な要求がくると推論が不安定になることも。
プロアクティブゴールクリエイター(Proactive Goal Creator)
ユーザーの文脈だけじゃなく、周辺環境や他のツール情報を拾ってエージェントが積極的にゴールを推測する。
たとえばカメラ映像やスクショなどからユーザーの環境を理解し、ゴールを確定。「お、手話してる？この指示はこういうゴールだな！」みたいな感じ。
ただし実装は複雑でコスト高め。
プロンプト・レスポンス最適化系パターン
プロンプト/レスポンスオプティマイザ(Prompt/Response Optimiser)
「ユーザーの入力が雑すぎて困る！」というとき、このパターンでプロンプトやレスポンスを標準化。
テンプレートを使って整形し、フォーマットを揃える。
だが、すべてを網羅できるわけではなくメンテコストもかかる。
RAG(Retrieval Augmented Generation)
ローカルデータや特定の知識ベースから情報を引っ張ってきてFMに食わせる手法。
大規模モデルを再学習することなく、外部データを都度参照。
プライバシー確保しつつコスト削減も狙える。ただしデータ管理が大変。
モデルクエリ戦略系パターン
ワンショットモデルクエリ(One-Shot Model Querying)
一発でFMに問い合わせて、全部の計画をまとめて引き出す。
効率的でコストも低いが、複雑なタスクには向かない。説明可能性も低い。
インクリメンタルモデルクエリ(Incremental Model Querying)
ステップごとにFMに問い合わせながら計画を立てる。
ユーザーが途中でフィードバックを入れることも可能で、説明性・精度を高められるが、コストは上昇。
プラン生成パターン
シングルパスプランジェネレーター(Single-Path Plan Generator)
一つの道筋でステップを並べるCoT(Chain-of-Thought)的な手法。
明快だが柔軟性は欠ける。
マルチパスプランジェネレーター(Multi-Path Plan Generator)
複数の道筋（選択肢）を用意してユーザーが選べるようにするTree-of-Thoughts的な手法。
複雑な問題でユーザ好みに合わせられるが、オーバーヘッド増。
リフレクション(振り返り)パターン
セルフリフレクション(Self-Reflection)
エージェント自身が生成した計画を自分で振り返り、改善する。
効率的だけど、エージェント自身が弱いと大した改善にならない。
クロスリフレクション(Cross-Reflection)
別のエージェントにフィードバックを求める。
多様な視点で精度UP。ただしエージェント間の公平性や責任が複雑に。
ヒューマンリフレクション(Human Reflection)
ユーザーや人間の専門家がフィードバックを与え、最終的に人間の意図・好みを最大限反映。
ただし人間側が曖昧だと意味なし。
マルチエージェント協調パターン
投票型協調(Voting-based Cooperation)
複数エージェントが意見を出して多数決する。
公平性や集合知を狙うが、通信オーバーヘッドは増える。
ロールベース協調(Role-based Cooperation)
エージェントに役割を割り振り、階層的に責務分担。
スケーラブルで責任範囲も明確になる。
ディベート型協調(Debate-based Cooperation)
エージェント同士が議論（ディベート）しあって合意を探る。
批判的思考や適応性向上が狙えるが、複雑性も上がる。
ガードレール・ツール接続パターン
マルチモーダルガードレール(Multimodal Guardrails)
入力・出力を検閲、ルール化して有害な情報流出や倫理的問題を防ぐ。
安全性確保だが、実装コスト増。
ツール/エージェントレジストリ(Tool/Agent Registry)
利用可能なツールやエージェントをリスト化するカタログ的存在。
「どのツール使えばいいか？」を素早く判断できる。
エージェントアダプタ(Agent Adapter)
外部ツールのインターフェースをエージェントが理解しやすい形式に変換。
面倒な接続調整を自動化するイメージ。
エージェント評価パターン
エージェントエバリュエーター(Agent Evaluator)
設計時や運用時にエージェントの性能をチェックする仕組み。
独自メトリクスでの品質評価や改善の指針に。
これらのパターンをどう使う？
パターンは「これを使え！」と決まっているわけではありません。
自分のエージェントがどんな用途なのか、ユーザーはどんなインタラクションを期待しているのか、何を優先するのか（安全性？拡張性？効率性？）によって選択が変わってきます。
- 対話形式でユーザーをサポートするなら、「パッシブ目標クリエーター + RAG + 人間反省」でシンプルかつ適応度UP。
- 複雑なタスク自動化なら、「プロアクティブ目標クリエーター + マルチパスプランジェネレーター + クロス反省 + 役割ベース協力」で高度な柔軟性と信頼性を。
- 安全性重視なら、「マルチモーダルガードレール + 自己反省」を前面に出して問題発言防止。
実際は動かしてみては修正、さらに試しては改善のループ。
「正解は一つではない」というのが、この領域の面白いところです。
規制対応や標準化とパターンの関連性
EUのAI法やNISTのガイドライン、ISO規格など、AI関連のルール整備が進んでいます。
これらに対応するためにはMultimodal Guardrailsで出力をフィルタしたり、Role-based Cooperationで責任を明確にするなど、パターンが役立つ可能性大。
「パターン＋規制対応」でエージェントを社会的に受け入れやすくする、これも今後の大きなテーマです！
評価手法への展望
エージェントをテストする「Agent Evaluator」はまだまだ成熟途上。
どういうメトリクスで評価する？ 説明可能性や責任追跡を数値化するには？
この辺り、これからの研究課題ですが、少なくともパターンがあれば評価ポイントを明確にしやすい。
まとめ
FMベースのエージェントは可能性無限大だけど、設計となると一筋縄じゃいかない。
でも、こうしたアーキテクチャパターンを知っていれば、どの段階で何が必要か、どう改善できるか、手掛かりが見えてくるはずです。
僕が初めてドラクエ4を手にした日から四半世紀以上、え？四半世紀も経ってるの？... たってるな...
まあ、ええ！四半世紀たって！ついにまともなクリフトが作れるエージェント設計時代が来た！
とにかく、試して壊して学び続ける、それがLLMエージェント開発の醍醐味！
我が人生にいっぺんの悔いなし！！！！！！！！！
以上、良いエージェント開発ライフを！！！
Discussion