アントニオ・グッリはGoogleのエンジニアリングディレクターです。彼はAIエージェント開発を21のデザインパターンに分解した453ページの本を執筆しました。しかし、これは書評ではありません。私がこの本を読んだ動機は明確です。私は「AIエージェントは魔法ではない」の中で、ハーネスエンジニアリング、Clawdbotの落とし穴、トークンバーンから真に実用的なAIエージェントへの7つの転換点について書いてきました。そのたびに、私は完全には理解できていない疑問を抱えていました。これらすべての背後には、再利用可能な根本的なロジックがあるのだろうか？この本は私に答えを与えてくれましたが、それは私が思っていたよりも深いものでした。あなたが書いているものは、エージェントですらないかもしれません。この本の最も辛辣な批判は、プロローグに隠されています。ほとんどの人が「AI」を使用しているのはレベル0だけです。ツールもメモリもアクションもない、むき出しのLLMです。2025年のアカデミー作品賞は何かと尋ねても、推測するだけです。この本ははっきりとこう述べています。レベル0はエージェントではない、と。次のレベルに進むことが真のエージェントです。レベル 1: ツール ユーザー。エージェントは検索、API、データベースなどのツールを使い始めます。しかし、それは単に「インターフェースを呼び出すことができる」ということではなく、いつ呼び出すか、何を呼び出すか、結果をどのように使用するかを独立して判断することでもあります。本書では具体的な例を挙げています。ユーザーが「最近どんな新しい番組がありますか？」と尋ねます。エージェントはこの情報がトレーニング データにないことを認識し、検索ツールを積極的に使用してそれを見つけ、結果を統合します。重要なステップは「自己認識」です。人間が「検索しろ」と言うのではなく、検索する必要があると判断するのです。この判断能力がレベル 1 の閾値です。レベル 2: 戦略的思考者。さらに 2 つの要素が追加されます。計画とコンテキスト エンジニアリングです。本書ではコンテキスト エンジニアリングを定義しています。情報を積み重ねるのではなく、コンテキストを慎重にフィルタリング、トリミング、パッケージ化します。素晴らしい例を挙げます。ユーザーが 2 つの場所の間にあるコーヒー ショップを探したいとします。エージェントはまず地図ツールを使用して大量のデータを取得し、次に「次のステップでは道路名だけが必要だ」と判断し、地図の出力を短いリストに切り詰め、それをローカル検索ツールに渡します。すべてのステップで情報のノイズ除去が行われます。私が何度も読んだ本に、「AI の精度を最高にするには、簡潔で焦点を絞った強力なコンテキストを与える必要がある」という一文があります。コンテキスト エンジニアリングとはまさにこのことです。このレベルでは、エージェントは自己反省することさえできます。作業を完了した後、それをレビューし、問題を特定して修正します。レベル 3: マルチ エージェント コラボレーション。この本のスタンスは明確です。常に全能のスーパー エージェントを作成しようとしないでください。本当に信頼できるアプローチは、プロジェクト マネージャー エージェント + 研究者エージェント + デザイナー エージェント + コピーライター エージェントのようなチームを構築することです。本書では、新製品の発売を例として取り上げています。「プロジェクトマネージャーエージェント」が全体のコーディネーターとして機能し、「市場調査エージェント」、「製品設計エージェント」、「マーケティングエージェント」にタスクを分配します。重要なのはコミュニケーションです。エージェントがどのようにデータを交換し、ステータスを同期し、競合を処理するかです。この章では、最も単純なシングルエージェントから最も柔軟なカスタムハイブリッドまで、それぞれ特定のシナリオに適した6つのコミュニケーショントポロジーを示しています。これら4つのレベルを読んだ後、多くの人が「私のエージェントはうまく機能していない」と言う理由が突然理解できました。モデル自体が問題なのではなく、チャットボットのように使用していることが問題であり、レベル1にすら達していない可能性があります。コンテキストエンジニアリング：本書で最も過小評価されている概念です。かつてハーネスエンジニアリングに関する記事を書き、トラック設計はエンジンの馬力よりも重要であると主張しました。本書を読んだ後、コンテキストエンジニアリングはプロンプトレベルにマッピングされたハーネスエンジニアリングであることに気づきました。従来のプロンプトエンジニアリングは「どのように質問するか」のみを扱います。本書のコンテキストエンジニアリングは「質問する前にエージェントの前に何があるか」を扱います。これには 4 つの情報層が含まれます。最初の層はシステム プロンプトで、エージェントが誰であるか、そのトーン、および境界を定義します。ほとんどの人はこの 1 つの層だけを記述します。2 番目の層は外部データです。RAG によって取得されたドキュメント、ツール呼び出しからの戻り値、およびリアルタイム API データです。ほとんどの人がここでつまずきます。データを与える必要があることはわかっていますが、モデルを過負荷にせずにデータを与える方法がわかりません。3 番目の層は暗黙的データです。ユーザー ID、インタラクション履歴、および環境状態です。明示的に述べていないものの、エージェントが知っているべきものです。たとえば、エージェントに「明日の会議を確認するために John にメールを送信してください」と指示した場合、エージェントはあなたのカレンダーで明日の会議が何であるか、およびあなたと John の関係が何であるかを知っている必要があります。4 番目の層はフィードバック ループです。各出力の後、エージェントは自動的に品質を評価し、次のステップのコンテキスト戦略を調整します。本書ではこれを「自動コンテキスト最適化」と呼んでおり、Google の Vertex AI Prompt Optimizer はこのアイデアのエンジニアリング実装です。これを読んだとき、以前の記事「AIエージェントは魔法ではない」を思い出しました。その記事では、「エージェントにはルールが必要であり、多くのルールが必要だ」という経験が述べられていました。今振り返ってみると、それらのルールは基本的にコンテキストエンジニアリングの手動版であり、本書ではそれを体系化しています。反省：エージェントは1つよりも2つのほうが間違いなく優れています。これは、本書全体の中で私にとって最も実用的な価値のあるパターンです。反省の核心は単純です。エージェントが作業を終えた後、それを自分でレビューし、問題を見つけて修正します。しかし、実装方法は重要です。本書では、プロデューサーとクリティックは、異なるシステムプロンプトを提供するために2つの異なるエージェントを使用する必要があると明示的に述べています。同じ人が自分の作業をレビューすると、必ず盲点が生じます。同じ LLM が最初にコードを書いてからレビューすると、おそらく「かなり良い」と評価されるでしょう。この本には完全なコード例が示されています。プロデューサーのプロンプトは、「あなたは Python 開発者です。境界条件と例外を処理しながら階乗を計算する関数を書いてください。」批評家のプロンプトは、「あなたは綿密なシニア エンジニアです。コードを一行ずつレビューし、バグ、スタイル、境界条件の欠落、改善点などを確認してください。完璧であれば CODE_IS_PERFECT を出力し、そうでなければすべての問題をリストしてください。」です。次に for ループがあります。プロデューサーがコードを書く → 批評家がレビューする → プロデューサーがフィードバックに基づいて修正する → 批評家が再びレビューする → 批評家が CODE_IS_PERFECT と言うか、最大反復回数に達するまで。それだけです。しかし、この本は、見落としがちなコストの問題を指摘しています。各リフレクション ループは新しい LLM 呼び出しであり、反復回数が増えるほどコストが高くなります。さらに、対話履歴が拡大するにつれて、コンテキスト ウィンドウは以前のバージョンと批判で満たされ、実際に使用できる推論空間が縮小します。したがって、反省のベストプラクティスは、妥当な最大反復回数 (本書では 3 回) を設定し、批評家が満足したら停止し、完璧を目指さないことです。その応用はコーディングをはるかに超えています。プロデューサー・批評家モデルは、記事の執筆、計画の作成、文書の要約、論理問題の解決に適用できます。本書では 7 つのアプリケーション シナリオがリストされていますが、すべて同じコア ロジック (最初に作成し、後でレビューし、次に修正する) に基づいています。マルチ エージェントは、複雑になればなるほど必ずしも優れているとは限りません。マルチ エージェント コラボレーションの章で私が最も気に入っているのは、6 つの通信トポロジです。多くの人は複雑なものから始めますが、ほとんどのシナリオでは 3 つで十分です。シングル エージェント (独立実行): タスクは独立したサブ問題に分割でき、各エージェントがそれぞれを処理します。シンプルで保守が容易です。ピアツーピア ネットワーク: エージェントは中央制御ノードなしで直接通信します。分散型で耐障害性に優れており、1 つのエージェントの障害がネットワーク全体に影響することはありません。ただし、調整コストが高く、混乱が生じやすいです。スーパーバイザー (集中型スケジューリング)：1 つのスーパーバイザー エージェントがワーカー エージェントのグループを管理します。タスクが割り当てられ、結果が収集され、競合が解決されます。階層は明確で管理が容易です。ただし、スーパーバイザーは単一障害点であり、パフォーマンスのボトルネックとなります。他の 3 つ (スーパーバイザーをツールとして使用、階層型、カスタム ハイブリッド) は、最初の 3 つのバリエーションと組み合わせです。本書では、実際には次のように述べられています。必要なトポロジーは、タスクの複雑さに依存します。タスクが細分化されるほど、通信コストが高くなります。ある時点で、スーパーバイザー パターンは階層型アプローチよりも効率的になります。私の経験では、多くの人がマルチエージェントシステムを構築する際に、時間の 80% を通信プロトコルに費やし、より根本的な質問を忘れています。このタスクには本当に複数のエージェントが必要ですか? この本では、レベル 2 のシングルエージェント + リフレクションで十分な場合が多いと明確に述べています。レベル 3 は、シングルエージェントではタスクを処理できないシナリオ用です。3 層のメモリ モデルについては、以前から漠然とした考えはありましたが、名前を付けていませんでした。この章は、Obsidian + Claude の論文を書いているときに、エージェントのメモリをどのように階層化すべきかという疑問をずっと考えていたため、私にとって最も共感できるものでした。この本は、その答えを提供しています。セッション: 現在の対話のコンテキスト ウィンドウ。これは最短のメモリで、対話が終了すると消滅します。長いコンテキスト モデルでは、このウィンドウを拡大するだけですが、基本的には一時的なものであり、推論ごとにウィンドウ全体を処理する必要があるため、コストがかかり、遅くなります。状態: 現在のタスク中の一時的なデータ。たとえば、「どのようなタスクが実行されていますか?」、「どのステップが完了しましたか?」、「プロセスでどのようなデータが生成されましたか?」などです。セッションよりも長いが、タスクの終了後にクリーンアップされる。本書では、Google ADK のステート メカニズムを使用した完全な例が提供されています。メモリ (永続レイヤー): セッションとタスクをまたいだ長期メモリ。ユーザーの好み、学習した経験、重要な履歴決定は、意味検索のためにデータベースまたはベクトル ライブラリに保存されます。本書では、重要な点を強調しています。メモリは単にデータを保存することではなく、「何を保存し、いつ保存し、どのように取得するか」についての完全な戦略を設計することです。保存しすぎるとノイズにつながり、保存しなさすぎると不十分になります。Clawdbot に関する以前の記事で、「ステート ファイル」と「ワークスペース ドキュメント」について言及しましたが、これは基本的にステート レイヤーとメモリ レイヤーを手動で開発することを意味します。本書では、このプロセスをフレームワーク化しています。5 つの仮定、5 番目が最も突飛。本書は、エージェントの未来に関する 5 つの仮定で締めくくられています。最初の 4 つは、まだ合理的な推測の範囲内です。汎用エージェントがコードの記述からプロジェクトの管理に移行すること。ディープ パーソナライゼーションがユーザーのニーズを積極的に発見すること。画面から飛び出して物理世界へと進出する具現化された知能、そして独立した経済主体となるエージェント。5つ目に衝撃を受けたのは、マルチエージェントの変革です。例えば「スペシャルティコーヒーを販売するeコマースビジネスを運営する」といった目標を宣言するだけで、システムは自動的に最初に「市場調査エージェント」と「ブランドエージェント」を作成します。データ分析を1ラウンド実行した後、ブランドエージェントは不要になったと判断し、「ロゴデザインエージェント」、「ウェブサイト構築エージェント」、「サプライチェーンエージェント」の3つの新しいエージェントに分割します。ウェブサイト構築エージェントがボトルネックになった場合、システムは自動的に3つの並列エージェントを作成し、異なるページで同時に作業させます。このプロセス全体を通して、システムは各エージェントへの指示を継続的かつ自動的に最適化し、チームアーキテクチャを常に再構築します。この本ではこれを「目標主導型、自己変革型マルチエージェントシステム」と呼んでいます。これは、あなたが書いた計画を実行するのではなく、独自の計画を生成し、それを調整し、実行チームを再編成します。これは、Karpathy の AutoResearch を思い出させます。program.md ファイルを作成し、目標、指標、境界を定義して、「開始」を押すだけです。人間はループの外にいます。しかし、この本はさらに進んでいます。エージェントチームがどのように形成され、再編成されるかさえ、システムが決定します。人間は「何が欲しいか」を宣言するだけです。すぐに実行できる 3 つのこと。この本を読んだ後、すぐに実行できる 3 つのアクションがあります。まず、現在のエージェントに批評家を追加します。Claude Code、CrewAI、または自作のフレームワークのいずれを使用している場合でも、既存のワークフローの最後にステップを追加します。別のエージェント (別のシステムプロンプトを使用) に前のステップの出力をレビューさせます。コード生成とコードレビュー、記事の執筆と事実確認、計画の策定と実現可能性レビュー。LLM の呼び出しが 1 回増えますが、品質の向上は 2 倍になることがよくあります。本書のプロデューサー・クリティックパターンはプラグアンドプレイです。次に、プロンプトエンジニアリングだけでなく、コンテキストエンジニアリングも始めましょう。エージェント用に作成した指示ファイルを振り返ってみてください。「何をすべきか」に関するルールばかりで、「現在どのような環境に直面しているか」というコンテキストが欠けている場合は、それを追加してください。エージェントに、現在どのプロジェクトに関わっているか、以前にどのような決定を下したか、ユーザーの好みは何かを伝えましょう。本書のコンテキストエンジニアリングの章とAGENTS.mdは、同じことを2つの方法で説明しています。3つ目は、マルチエージェントシステムに急いで移行しないことです。シングルエージェントをレベル2にしましょう。ツール、リフレクション、メモリを持たせましょう。本書では、レベル2のシングルエージェントにプロデューサー・クリティックとコンテキストエンジニアリングを組み合わせることで、ほとんどの現実世界のシナリオに対応できることを繰り返し強調しています。レベル3は、並列的な分業を必要とする、真にドメインをまたいだ多段階タスクのためのものです。ほとんどの人の問題は、エージェントが足りないことではなく、どれも適切に調整されていないことです。本書は453ページで、2025年にSpringer社から出版予定です。コード例は、LangChain/LangGraph、Google ADK、CrewAI、OpenAI APIを網羅しています。序文はGoogle CloudのAI担当副社長が執筆し、ゴールドマン・サックスのCIOによる前書きも掲載されています。これは意外にも素晴らしい内容です。しかし、私が本書を推薦する理由は「網羅的」だからではありません。本書を読めば、過去6ヶ月間にエージェント開発で遭遇した落とし穴がパターンとしてまとめられていることに気づくでしょう。もはやリフレクションを考案したり、メモリの階層化方法を推測したり、マルチエージェントシステムのための様々な通信トポロジーを試したりする必要はありません。誰かが地図を描いてくれたのです。あとはそれに従うだけです。あなたはAIエージェントの開発をしていますか？あなたのエージェントは現在どのレベルですか？[Yanhua]