エージェント設計パターン2026年9月21日 | |
🐧 要するにどういう話かLLMを用いてエージェントを構築する際の設計パターンについて。主にAnthropicの記事を参考にしている。 1. はじめにLLMの文脈で「エージェント」と言ったとき、人によって指すものが違う。完全に自律的に長時間動作し、自らの判断でツールを選択して複雑なタスクをこなすシステムを指す人もいれば、開発者が事前に定義したコードパスに従って動作するシステムを指す人もいる。 この記事では、両方を「エージェント系システム」という総称で扱う。ただし、アーキテクチャ上の区別は明確にする。
使用タイミング第一の原則は単純さである。最もシンプルな方式から始め、複雑さは成果が明確に改善される場合のみ追加する。エージェント系システムは、タスク性能を高める代わりにレイテンシとコストが増える。そのため、追加の複雑さには測定的な改善が求められる。多くのアプリケーションでは、検索とコンテキスト内例を備えた単一のLLM呼び出しで十分である。 複雑さが必要と判断された場合：
この記事では、基本構成要素から始め、複雑さが増す順にワークフローパターンを紹介し、最後にエージェントについて述べる。 2. 拡張LLMエージェント系システムの基本的な構成要素は、外部能力で拡張されたLLMである。
現代のLLMはこれらの能力を能動的に使える。自ら検索クエリを生成し、適切なツールを選択し、保持する情報を判断する。実装上重視すべきは2点である。
ツールの統合としてModel Context Protocol（MCP）という方式がある。サードパーティ製ツールをモデルに公開する方法を標準化するものである。具体的な機構よりも、モデルが必要とする情報や操作に確実にアクセスできることを担保することが本質である。 以降の記事では、各LLM呼び出しがこれらの拡張能力にアクセスできる前提で記述する。 3. ReAct：推論と行動の統合問題ReActの登場前まで、推論と行動は別々に研究されてきた。
どちらか一方だけでは、計画と外部情報源との対話の両方が必要なタスクには不十分である。 ReActのアイデアReActは、エージェントの行動空間に言語空間を追加する。モデルが推論トレース（思考）とタスク固有の行動を交互に生成する。
これにより相乗効果が生まれる。推論が「どの行動を取り、その結果をどう解釈するか」を導き、行動が推論を根拠づける外部情報を提供する。 効果
ReActは、思考→行動→観察のループをタスク完了まで繰り返すパターンであり、多くのLLMエージェントの基盤となる。 4. Reflexion：言語による強化学習問題従来の強化学習はモデルの重みを更新してエージェントの行動を改善するが、大量の学習サンプルと高コストなファインチューニングを必要とする。LLMベースのエージェントでは、多くのタスクでこれは現実的でない。 ReflexionのアイデアReflexionは、重みの更新の代わりに言語による強化を用いる。パラメータを調整する代わりに、エージェントが以下を行う。
これは、省察テキストが「意味的勾配」として機能するからである。不透明なスカラー報酬の代わりに、モデルが解釈可能な具体的な改善方向を与える。 構成要素
効果
Reflexionが示すのは、フィードバックがモデルが理解する同一のモダリティ（言語）で表現される限り、LLMは勾配降下なしに自らの失敗から学習できるという洞察である。 5. ワークフローパターンワークフローは、制御の流れが事前に定義されているエージェント系システムである。以下のパターンを、複雑さが増す順に紹介する。 5.1 プロンプトチェイニングパターン： タスクを固定の順序のステップに分解し、各LLM呼び出しが前ステップの出力を処理する。ステップ間にプログラムのチェック（ゲート）を挿入して、品質を確認してから進行できる。 flowchart LR
A[LLM呼び出し1] --> G1{ゲート}
G1 --> B[LLM呼び出し2]
B --> G2{ゲート}
G2 --> C[LLM呼び出し3]
使用場面： タスクが固定のサブタスクにきれいに分解でき、各LLM呼び出しを単純化することでレイテンシと引き換えに精度を上げたい場合。 例：
5.2 ルーティングパターン： 入力を分類し、専用の後続処理へ振り分ける。関心の分離（separation of concerns）により、カテゴリごとに最適化されたプロンプトやツールを構築できる。各パスは独立したプロンプト、ツール、モデルを持てる。 flowchart LR
I[入力] --> R{ルータ}
R -->|種別A| A[処理A]
R -->|種別B| B[処理B]
R -->|種別C| C[処理C]
使用場面： 入力空間に明確なカテゴリがあり、カテゴリごとに異なる処理が有効な場合。分類がLLMや従来の分類器によって信頼性をもって行える場合。 例：
5.3 並列化パターン： 複数のLLM呼び出しを同時に実行し、出力をプログラムで集約する。2つの主要なバリエーションがある。
flowchart LR
T[タスク] --> A[LLM呼び出しA]
T --> B[LLM呼び出しB]
T --> C[LLM呼び出しC]
A --> AGG[集約]
B --> AGG
C --> AGG
使用場面：
例： - 分割： ユーザーのクエリを処理するモデルと、不適切なコンテンツをスクリーニングするモデルを別々に用意する。単一の呼び出しで両方を行うより性能が向上する。 - 投票： 複数のプロンプトでコードのスニペットを脆弱性の観点からレビューし、複数のレビュアーが合致したときにのみ指摘を確定する。 5.4 オーケストレーター-ワーカーパターン： 中央のLLM（オーケストレーター）がタスクを動的に分解し、ワーカーLLMに委譲し、その結果を統合して最終出力を生成する。 flowchart TB
T[タスク] --> O[オーケストレーター]
O -->|サブタスク1| W1[ワーカー1]
O -->|サブタスク2| W2[ワーカー2]
O -->|サブタスク3| W3[ワーカー3]
W1 --> O
W2 --> O
W3 --> O
O --> R[最終出力]
並列化との違い： 並列化ではサブタスクが開発者により事前定義される。オーケストレーター-ワーカーでは、オーケストレーターが入力に応じて実行時に必要なサブタスクを決定する。 使用場面： 必要なサブタスクを事前に予測できない場合。例えばコーディングでは、変更すべきファイルの数や各ファイルの変更内容がタスクに依存する。 例： - 複数ファイルにまたがる複雑な変更を行うコーディングエージェント。 - 複数の情報源から情報を収集・統合する検索エージェント。 5.5 評価者-最適化者パターン： 1つのLLMが出力を生成し、別LLMがそれを評価してフィードバックを返す。生成側がフィードバックに基づいて修正し、基準を満たすまでループを繰り返す。 flowchart LR
G[生成LLM] --> E[評価LLM]
E -->|フィードバック| G
E -->|合格| D[完了]
使用場面：
例：
Reflexionとの関係：Reflexionは、評価と自己省察をエージェント自身が行い、フィードバックを1回のループで捨てずトライアル間で保持する、評価者-最適化者の自己完結的なインスタンスである。 6. エージェントエージェントは、LLMが自らのプロセスに対して動的な制御を持つエージェント系システムである。ワークフロー（開発者が制御の流れを定義する）とは異なり、エージェントは実行時に以下を決定する。
動作エージェントは典型的に次のループで動作する。
エージェントはチェックポイントで人間への確認を挟むこともできる。特に曖昧さや障害に遭遇したときである。 使用場面
リスク
対策：
例
7. まとめ最も洗練されたシステムを作るのが目標なのではない。必要な用途に適したシステムを作ることが目標である。シンプルに始め、測定し、成果が明確に改善される場合のみ複雑さを追加する。 エージェント系システムの設計における3つの原則：
📚 参考文献
| |
| PENGUINITIS | |