エージェントデザインパターン：私に「エージェントとは何か」を再理解させてくれた本

著者：Yanhua

Antonio GullíはGoogleのエンジニアリングディレクターです。彼は453ページの本を書き、AIエージェントの開発を21種類のデザインパターンに分解しました。

しかし、これは書評ではありません。私がこの本を読む動機は非常に具体的です：私はHarness Engineeringについて書いたことがあり、Clawdbotの失敗体験についても書きました。「AIエージェントは魔法ではない」という、トークンを燃やすことから本当に使えるようになるまでの七つの転換点についても書きました。毎回書き終えた後に完全に考え抜けていない問題が一つあります：これらの背後には再利用可能な基盤論理のセットがあるのでしょうか？

この本は私に答えを与えてくれました、しかも私が考えていたよりも深いものでした。

あなたが書いたものはおそらくエージェントではない

本の中で最も厳しい判断はプロローグに隠れています。

ほとんどの人が使っている「AI」は、単なるレベル0：裸のLLMであり、ツールも記憶も行動もありません。あなたが「2025年のオスカーの最優秀作品は何か？」と尋ねると、彼は推測します。本の中では非常に率直に言っています：レベル0のものはエージェントではない。

上に進むことで本当のエージェントになります：

• レベル1：ツール使用者

  エージェントはツールを使い始めました：検索、API、データベース。しかし、単に「インターフェースを呼び出せる」だけではなく、いつ呼び出すべきか、何を呼び出すべきか、結果をどう使うべきかを自分で判断しなければなりません。本の中では非常に具体的な例が示されています：ユーザーが「最近新しいドラマは何か？」と尋ねると、エージェントはこの情報がトレーニングデータにないことを自分で認識し、積極的に検索ツールを呼び出して結果を合成します。重要なステップは「自分で認識する」ことです。人間が「検索してみて」と言うのではなく、彼自身が検索が必要だと判断します。この判断能力がレベル1の門です。

• レベル2：戦略的思考者

  2つの要素が追加されました：計画とコンテキストエンジニアリング。本の中ではコンテキストエンジニアリングが定義されています：情報の積み重ねを行わず、精選、裁断、パッケージ化されたコンテキストを作成します。例は非常に巧妙です：ユーザーが2つの場所の間でコーヒーショップを探す場合、エージェントはまず地図ツールを呼び出して大量のデータを取得し、その後「次に必要なのは通りの名前だけだ」と判断し、地図を短いリストに裁断してローカル検索ツールに渡します。すべてのステップで情報のノイズを減らしています。

本の中には何度も読み返した一文があります：「AIに最高の精度を達成させるには、短く、焦点を絞り、力強いコンテキストを与えなければならない。」コンテキストエンジニアリングはこの作業を行うものです。

このレベルに達すると、エージェントは自己反省もできます。作業を終えた後、自分で見直し、問題を発見し、自分で修正します。後で詳しく説明します。

• レベル3：マルチエージェント協力

本の立場は非常に明確です：全能のスーパーエージェントを作ろうと考えないでください。本当に信頼できる方法は、チームを構成するように、プロジェクトマネージャーエージェント + 研究者エージェント + デザイナーエージェント + コピーライターエージェントのようにすることです。本の中での例は新製品の発売です：「プロジェクトマネージャーエージェント」が全体の調整を行い、「市場調査エージェント」、「製品デザインエージェント」、「マーケティングエージェント」にタスクを割り当てます。重要なのは通信です：エージェント間でデータをどう伝え、どう状態を同期し、どう衝突を処理するか。この章では、最も単純な単一エージェントから最も柔軟なカスタム混合まで、6種類の通信トポロジーが描かれています。それぞれのシーンに適したものが説明されています。

この4つのレベルを見た後、私はなぜ多くの人が「私のエージェントは使えない」と言うのか突然理解しました。モデルには問題がありません。問題は、あなたがそれをチャットボットとして使おうとしていることです。おそらくそれはレベル1にも達していないのです。

コンテキストエンジニアリング：本で最も過小評価されている概念

私は以前、Harness Engineeringについて書いたことがあります。トラックの設計がエンジンの馬力よりも重要であるという内容です。この本を読んで、コンテキストエンジニアリングはプロンプトのレベルでのハーネスエンジニアリングのマッピングであることに気付きました。

従来のプロンプトエンジニアリングは「あなたがどう尋ねるか」だけを扱います。本の中のコンテキストエンジニアリングは「尋ねる前に、エージェントの前に何があるか」を扱います。それは4層の情報を含みます：

1. 第一層、システムプロンプト。エージェントが誰で、どんな口調で、どんな境界があるかを定義します。ほとんどの人はこの層だけを書いています。

2. 第二層、外部データ。RAGが取得した文書、ツール呼び出しの返り値、リアルタイムAPIデータ。これは多くの人がつまずくところです：データを与える必要があることは分かっているが、どう与えればモデルが溺れないかが分からないのです。

3. 第三層、暗黙のデータ。ユーザーの身元、インタラクションの履歴、環境の状態。あなたが明示的に言わなくても、エージェントが知っているべきことです。例えば、あなたがエージェントに「ジョンに明日の会議を確認するメールを送って」と言った場合、エージェントはあなたのカレンダーに明日の会議が何か、あなたとジョンの関係が何かを知っているべきです。

4. 第四層、フィードバックループ。エージェントは毎回出力した後、自動的に品質を評価し、次回のコンテキスト戦略を調整します。本の中ではこれを「自動化されたコンテキスト最適化」と呼び、GoogleのVertex AIプロンプトオプティマイザーはこの考え方のエンジニアリング実装です。

ここまで読んだとき、私は以前書いた「AIエージェントは魔法ではない」という記事を思い出しました。その中には「あなたのエージェントにはルールが必要であり、しかも多くのルールが必要だ」という経験がありました。今振り返ると、それらのルールは本質的にコンテキストエンジニアリングの手作り版であり、本の中でそれを体系化しています。

リフレクション：2つのエージェントは1つよりも良い

これは本全体で私にとって最も実践的価値のあるパターンです。

リフレクションの核心は非常にシンプルです：エージェントは作業を終えた後、自分で見直し、問題を発見し、自分で修正します。しかし、実現方法には工夫が必要です。本の中では明確に言っています：プロデューサーと批評家は2つの異なるエージェントを使用し、異なるシステムプロンプトを与えなければならない。同じペルソナが自分のものを審査する場合、必ず盲点があります。同じLLMにコードを書かせ、その後自分が書いたコードを審査させると、彼は「まあまあ良い」と言う可能性が高いです。

本の中では完全なコードの例が示されています。

• プロデューサーのプロンプトは「あなたはPython開発者であり、階乗を計算する関数を書き、境界条件と例外を処理します」です。

• 批評家のプロンプトは「あなたは非常に厳しい上級エンジニアであり、コードを行ごとに審査し、バグ、スタイル、見落とされた境界条件、改善点をチェックします。完璧であれば CODE_IS_PERFECT を出力し、そうでなければすべての問題を列挙します」です。

• その後はforループです：プロデューサーがコードを書く → 批評家が審査する → プロデューサーが意見に基づいて修正する → 批評家が再審査する → 批評家が CODE_IS_PERFECT というか最大反復回数に達するまで。

これだけシンプルです。しかし、本の中では見落とされがちなコストの問題を指摘しています：毎回のリフレクションループは新しいLLMの呼び出しであり、反復回数が多いほどコストが高くなります。また、対話の履歴が膨張するにつれて、コンテキストウィンドウが前のバージョンや批評意見で占められ、実際に利用可能な推論空間が狭まります。したがって、リフレクションのベストプラクティスは：合理的な最大反復回数を設定し（本の中では3を使用）、批評家が満足したら停止し、完璧を追求しないことです。

用途はコードを書くことだけではありません。文章を書く、計画を立てる、文書をまとめる、論理問題を解決するなど、プロデューサー-批評家モデルはすべてに適用できます。本の中では7つの応用シーンが列挙されており、核心的な論理は同じです：まず生成し、次に審査し、最後に修正します。

マルチエージェントは複雑である必要はない

マルチエージェント協力の章で私が最も好きなのは、その6種類の通信トポロジー図です。多くの人は最初から複雑にしようとしますが、実際にはほとんどのシーンでは3種類で十分です：

1. 単一エージェント（独立実行）：タスクが互いに依存しないサブ問題に分解できる場合、各エージェントは自分のことを自分で解決します。シンプルで、メンテナンスが容易です。

2. ピアツーピアネットワーク：エージェント間で直接通信し、中心制御ノードがありません。非中央集権的で、耐障害性が高く、1つのエージェントがダウンしても全体に影響しません。しかし、調整コストが高く、混乱しやすいです。

3. スーパーバイザー（中央調整）：1つのスーパーバイザーエージェントが多数のワーカーエージェントを管理します。タスクを割り当て、結果を収集し、衝突を解決します。階層が明確で、管理が容易です。しかし、スーパーバイザーは単一障害点であり、パフォーマンスのボトルネックでもあります。

残りの3つ（スーパーバイザーをツールとして使用、階層型、カスタム混合）は、最初の3つの変種と組み合わせです。本の中では非常に現実的に言っています：必要なトポロジーはタスクの複雑さに依存します。 タスクが細分化されるほど、通信コストが高くなり、ある程度まで進むとスーパーバイザーモードの方が階層型よりも効率的です。

私の体験では、多くの人がマルチエージェントを構築する際に80％の時間を通信プロトコルに費やし、もっと基本的な質問を忘れています：このタスクは本当に複数のエージェントを必要としますか？ 本の中では明確に書かれていますが、レベル2の単一エージェント + リフレクションは、ほとんどの実際のシーンをカバーするのに十分です。レベル3は、実際に単一エージェントでは解決できないシーンのために用意されています。

メモリの三層モデル、私は以前ぼんやりと感じていましたが名前を付けていませんでした

メモリの章は私にとって最も共鳴するものでした。なぜなら、私はObsidian + Claudeに関する2つの記事を書くとき、常に1つの問題を考えていたからです：エージェントの記憶はどう層分けすべきか？

本の中で答えが示されています：

1. セッション（会話層）：現在の対話のコンテキストウィンドウで、これは最も短い記憶であり、対話が終了すると消えます。長いコンテキストモデルはこのウィンドウを拡大しただけですが、本質的には依然として一時的であり、毎回推論する際には全体のウィンドウを処理しなければならず、高価で遅いです。

2. 状態（状態層）：現在進行中のタスクの一時的データです。例えば「現在のタスクは何か」、「どの段階まで進んでいるか」、「途中で生成されたデータは何か」です。セッションよりも長いですが、タスクが終了するとクリアされます。本の中ではGoogle ADKの状態メカニズムを用いて完全な例が示されています。

3. メモリ（持続層）：セッションを超え、タスクを超えた長期記憶です。ユーザーの好み、学んだ経験、重要な歴史的決定は、データベースやベクトルストレージに保存され、意味的に検索されます。本の中では非常に重要な点が強調されています：メモリは単に保存するだけでなく、「何を保存するか、いつ保存するか、どう検索するか」の一連の戦略を設計する必要があります。保存しすぎるとノイズが大きくなり、保存が少なすぎると不十分になります。

私は以前、Clawdbotに関する記事の中で「状態ファイル」と「作業スペース文書」に言及しましたが、本質的には状態層とメモリ層を手作りしているものであり、本の中でそれをフレーム化しています。

5つの仮説、5つ目が最も驚くべきもの

本の最後にはエージェントの未来に関する5つの仮説が提起されています。最初の4つはまだ合理的な推論の範囲内です：汎用エージェントがコードを書くことからプロジェクトを管理すること、深い個別化があなたのニーズを積極的に発見すること、具身知能が画面を越えて物理的世界に出ること、エージェントが独立した経済主体になること。

5つ目は私を驚かせました：変形マルチエージェント。

あなたは目標を宣言するだけです、例えば「高級コーヒーを販売するeコマースビジネスを作る」と。システムは自動的に決定します：まず「市場調査エージェント」と「ブランドエージェント」を作成します。データを一巡した後、システムはブランドエージェントが不要であると判断し、3つの新しいエージェントに分解します：「ロゴデザインエージェント」、「ウェブサイト構築エージェント」、「サプライチェーンエージェント」。もしウェブサイト構築エージェントがボトルネックになった場合、システムは自動的に3つの並行エージェントをコピーして異なるページを同時に処理します。全体のプロセスで、システムは各エージェントのプロンプトを継続的に自動調整し、チーム構造を再編成します。

本の中ではこれを「目標駆動型の自己変形マルチエージェントシステム」と呼んでいます。これはあなたが書いた計画を実行するのではなく、自己生成された計画を実行し、自己調整し、自己再編成するチームを構築するものです。

これを見て、私はKarpathyのAutoResearchを思い出しました：program.mdを書き、目標、指標、境界を定義し、「スタート」を押します。人間はループの外にいます。しかし、この本はさらに進んでいます：エージェントチームの構築方法や再編成方法もシステム自身に決定させます。人間は「何が欲しいか」だけを宣言します。

すぐにできる3つのこと

この本を読んで、私にはすぐに実行できる3つのアクションがあります：

• 第一に、現在のエージェントに批評家を追加してください。 たとえあなたがClaude Code、CrewAI、または自分で構築したフレームワークを使用しているとしても、現在のワークフローの最後にもう1つのステップを追加してください：別のエージェント（異なるシステムプロンプトを使用）に前の出力を審査させます。コード生成にコード審査を追加し、記事執筆に事実確認を追加し、計画策定に実行可能性評価を追加します。LLMの呼び出しが1回増えますが、品質の向上は往々にして倍増します。本の中のプロデューサー-批評家モデルは即座に使用可能です。

• 第二に、コンテキストエンジニアリングを始めてください、プロンプトエンジニアリングだけではなく。 あなたがエージェントに与えた指示ファイルを振り返ってください。もし全てが「あなたはどうするか」というルールで、「あなたが今どんな環境にいるか」というコンテキストが欠けているなら、それを補ってください。エージェントに、彼が今どのプロジェクトにいるのか、以前にどんな決定をしたのか、ユーザーの好みは何かを教えてください。本の中のコンテキストエンジニアリングの章とあなたの AGENTS.md は同じ事の2つの表現です。

• 第三に、急いでマルチエージェントに移行しないでください。 あなたの単一エージェントをレベル2に持っていく：ツールがあり、リフレクションがあり、メモリがあります。本の中では繰り返し強調されていますが、レベル2の単一エージェントにプロデューサー-批評家とコンテキストエンジニアリングを加えることで、ほとんどの実際のシーンをカバーできます。レベル3は、実際に分野を超え、多段階で、並行して分業するタスクのために用意されています。ほとんどの人の問題は、エージェントが不十分であることではなく、1つのエージェントさえも適切に調整されていないことです。

この本は453ページで、Springerが2025年に出版します。コードの例はLangChain/LangGraph、Google ADK、CrewAI、OpenAI APIをカバーしています。前書きはGoogle Cloud AIのVPが書いており、Goldman SachsのCIOの推薦序文もあり、意外に良い内容です。

しかし、私がこの本を推薦する理由は「包括的」だからではありません。あなたがこの本を読み終えたときに気づくことがあるからです：あなたが過去半年間にエージェントでつまずいた問題は、すでに誰かがパターンとして整理しているのです。あなたはリフレクションを再発明する必要はなく、メモリをどう層分けするかを推測する必要はなく、マルチエージェントにどの通信トポロジーを使用するかを試す必要はありません。

誰かがあなたのために地図を描いてくれました。残るのはそれを歩くだけです。

あなたはAIエージェントを使って開発していますか？あなたの現在のエージェントはレベルのいくつですか？