Google エンジニアリングディレクター：AIエージェントのための21種類のデザインパターン

核心的な視点

2026-05-25 12:40:07

コレクション

Googleのエンジニアリングディレクターの新書が深く分析する：AIエージェントの21種類のデザインパターン。本記事では、「裸LLM」から高度なインテリジェントエージェントへの進化の核心を明らかにし、コンテキストエンジニアリング、二重エージェント反省メカニズム（プロデューサー-クリティック）、および三層メモリモデルを詳細に解析し、すぐに実行可能な3つの最適化戦略を提供します。

著者：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について書いたことがありますが、それはトラックの設計がエンジンの馬力よりも重要であるということです。この本を読んで、コンテキストエンジニアリングはプロンプトのレベルでのHarness Engineeringのマッピングであることに気づきました。

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

第一層、システムプロンプト。エージェントが誰で、どんな口調で、どんな境界を持つかを定義します。ほとんどの人はこの層だけを書いています。
第二層、外部データ。RAGが取得した文書、ツール呼び出しの戻り値、リアルタイムAPIデータ。これは多くの人がつまずくところです：データを与える必要があることは知っていますが、どう与えればモデルを圧倒しないかがわかりません。
第三層、暗黙のデータ。ユーザーの身分、インタラクションの履歴、環境の状態。あなたが明言していないが、エージェントが知っているべきことです。例えば、あなたがエージェントに「ジョンに明日の会議を確認するメールを送って」と言った場合、エージェントはあなたのカレンダーに明日の会議が何であるか、あなたとジョンの関係が何であるかを知っているべきです。
第四層、フィードバックループ。エージェントは毎回出力した後、自動的に品質を評価し、次回のコンテキスト戦略を調整します。本の中ではこれを「自動化されたコンテキスト最適化」と呼び、GoogleのVertex AIプロンプトオプティマイザーはこの考え方のエンジニアリング実装です。

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

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

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

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

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

プロデューサーのプロンプトは「あなたはPython開発者であり、階乗を計算する関数を書き、境界条件と例外を処理します」です。
批評家のプロンプトは「あなたは非常に厳しい上級エンジニアであり、コードを行ごとに審査し、バグ、スタイル、見落とした境界条件、改善点をチェックします。完璧であればCODE_IS_PERFECTを出力し、そうでなければすべての問題を列挙します」です。
その後はforループです：プロデューサーがコードを書く → 批評家が審査する → プロデューサーが意見に基づいて修正する → 批評家が再審査する → 批評家がCODE_IS_PERFECTと言うか、最大反復回数に達するまで。

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

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

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

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

単一エージェント（独立実行）：タスクを互いに依存しないサブ問題に分解できる場合、各エージェントは自分のことを自分で解決します。シンプルで、メンテナンスが容易です。
ピアツーピアネットワーク：エージェント間で直接通信し、中央制御ノードがありません。非中央集権で、耐障害性が高く、1つのエージェントがダウンしても全体に影響しません。しかし、調整コストが高く、混乱しやすいです。
スーパーバイザー（中央調整）：1つのスーパーバイザーエージェントが一群のワーカーエージェントを管理します。タスクを割り当て、結果を収集し、衝突を解決します。階層が明確で、管理が容易です。しかし、スーパーバイザーは単一障害点であり、パフォーマンスのボトルネックでもあります。

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

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

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

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

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

セッション（会話層）：現在の対話のコンテキストウィンドウで、これは最も短い記憶であり、対話が終わると消えます。長いコンテキストモデルはこのウィンドウを拡大するだけですが、本質的には依然として一時的であり、各推論ごとに全体のウィンドウを処理する必要があり、高価で遅いです。
状態（状態層）：現在進行中のタスクの一時的データ。例えば「現在のタスクは何か」、「どの段階まで進んでいるか」、「途中で生成されたデータは何か」です。セッションよりも長いですが、タスクが終了するとクリアされます。本の中ではGoogle ADKの状態メカニズムを使って完全な例が示されています。
メモリ（永続層）：セッションを超え、タスクを超えた長期記憶。ユーザーの好み、学んだ経験、重要な歴史的決定をデータベースやベクトルストアに保存し、意味的に検索します。本の中では非常に重要な点が強調されています：メモリは単に保存するだけでなく、「何を保存するか、いつ保存するか、どう検索するか」の一連の戦略を設計する必要があります。保存しすぎるとノイズが大きくなり、保存が少なすぎると不十分になります。

以前書いた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の推薦序文もあり、意外と素晴らしいです。

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

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