作者：Yanhua
アントニオ・グリはGoogleのエンジニアリングディレクターであり、AIエージェント開発を21のデザインパターンに分解した453ページの本を執筆した。
しかし、これは書評ではありません。この本を読んだ動機は非常に具体的です。私は『Harness Engineering』を書き、Clawdbotの失敗体験を書き、『AIエージェントは魔法ではない』という、トークンを消費してから真正に使いやすいものになるまでの7つの転換点を書き上げました。毎回書き終えた後、完全には解明できていない疑問が残りました：これらの背後には、再利用可能な基本的なロジックが存在するのでしょうか？
この本は私に答えをくれただけでなく、私の予想以上に深かった。
あなたが書いたのはおそらくAgentではない
プロローグに最も鋭い判断が隠されている。
ほとんどの人が使っている「AI」は、Level 0：ツールもメモリも持たず、行動できない素のLLMです。2025年のアカデミー賞最優秀作品はどれかと聞けば、推測します。本にははっきり書かれています：Level 0のものはAgentではありません。
上昇することが真のエージェント：
レベル1：ツール使用者
エージェントがツールの使用を開始しました：検索、API、データベース。しかし、単に「APIを呼び出せる」だけでなく、いつ呼び出すか、何を呼び出すか、結果をどのように使うかを自ら判断しなければなりません。書籍には具体的な例が挙げられています：ユーザーが「最近新しいドラマは何か」と尋ねたとき、エージェントはその情報がトレーニングデータに含まれていないことに自ら気づき、自発的に検索ツールを呼び出して結果を統合します。重要なのは「自ら気づく」ことです。人間が「調べてみろ」と指示したわけではなく、エージェント自身が検索の必要性を判断したのです。この判断能力が、レベル1の門限です。
レベル2：戦略的思考者
追加されたのは、プランニングとコンテキストエンジニアリングの2つです。書籍では、コンテキストエンジニアリングを「情報の積み重ねではなく、文脈を精選し、切り詰め、パッケージ化すること」と定義しています。非常に優れた例として、ユーザーが2つの場所の間にカフェを探しているケースが挙げられています。エージェントはまずマップツールを呼び出して大量のデータを取得し、その後「次に必要なのは道路名だけだ」と判断して、マップの出力を短いリストに切り詰め、ローカル検索ツールに渡します。この一連のプロセスはすべて情報のノイズ除去を行っています。
本の中に、何度も読み返した一文があります。「AIに最高の正確性を実現させるには、短く、焦点が絞られ、力強いコンテキストを提供しなければならない。」Context Engineering とは、まさにこのことを実践するものです。
このレベルになると、エージェントは自己反省が可能です。作業を終えた後、自分で確認し、問題があれば自ら修正します。後で詳しく説明します。
レベル3：複数エージェントの協働
本の立場は明確です：全能のスーパーエージェントを作ろうとしないでください。本当の信頼できる方法は、プロジェクトマネージャーエージェント、リサーチャーエージェント、デザイナーエージェント、コピーライターエージェントのようにチームを構築することです。本には新製品のリリースの例が挙げられています：「プロジェクトマネージャーエージェント」が全体を調整し、タスクを「マーケットリサーチエージェント」、「プロダクトデザインエージェント」、「マーケティングエージェント」に割り振ります。鍵は通信です：エージェント同士はどのようにデータをやり取りし、状態を同期し、衝突を処理するか。この章では、最も単純なシングルエージェントから最も柔軟なカスタムハイブリッドまで、6種類の通信トポロジーが図示され、それぞれのシナリオに適した使い方が説明されています。
この4つのレベルを見た後、なぜ多くの人が「私のAgentは使いにくい」と言うのかがようやく理解できました。モデルに問題はないのですが、あなたはそれをチャットボットのように使っているだけで、それすらLevel 1にも達していない可能性があります。
コンテキストエンジニアリング：本の中で最も過小評価されている概念
私は以前、Harness Engineeringという記事を書き、レースコースの設計がエンジンの馬力よりも重要であると述べました。この本を読んだ後、Context EngineeringがpromptレベルにおけるHarness Engineeringの対応物であることに気づきました。
従来のPromptエンジニアリングは「どのように質問するか」だけを扱います。本書のContextエンジニアリングは、「質問する前に、エージェントの前に何が置かれているか」を扱います。これは4つの情報層を含みます：
第一層、system prompt。Agent が誰で、どのような語調で、どのような境界を持つのかを定義する。多くの人がこの層だけを書いている。
第二層、外部データ。RAGで検索されたドキュメント、ツール呼び出しの返値、リアルタイムAPIデータ。これは多くの人がつまずくポイントです：データを入力する必要は理解しているが、モデルを圧倒しないようにどのように入力すべきかがわからない。
第三層、暗黙のデータ。ユーザーの身元、インタラクションの履歴、環境の状態。明示していないがエージェントが知っているべき情報。たとえば、「明日の会議をJohnに確認するメールを送って」とエージェントに指示した場合、エージェントはあなたのカレンダーに明日予定されている会議の内容や、あなたとJohnの関係を把握しているべきである。
第4層、フィードバックループ。エージェントが毎回出力した後、自動的に品質を評価し、次回のコンテキスト戦略を調整する。本書ではこれを「自動化されたコンテキスト最適化」と呼んでいる。GoogleのVertex AI Prompt Optimizerは、この考え方に基づくエンジニアリング実装である。
ここで読んでいるとき、以前書いた「AIエージェントは魔法ではない」という記事を思い出した。その記事には「あなたのエージェントにはルールが必要であり、多くのルールが必要だ」という経験則があった。今改めて振り返ると、それらのルールは本質的にContext Engineeringの手作業版であり、本書ではそれを体系化している。
リフレクション：2つのエージェントは1つより本当に優れている
これはこの本の中で、私にとって最も実践的な価値のあるパターンです。
Reflectionの核心はシンプルです：Agentが仕事を終えたら、自ら見直し、問題があれば自ら修正します。しかし、その実装方法には工夫が必要です。書籍には明確に記されています：ProducerとCriticは、異なるシステムプロンプトを持つ別々のAgentでなければなりません。同じパーソナが自分の作品を審査すれば、必ず盲点が生じます。同じLLMにコードを書かせ、その後で自分が書いたコードを審査させると、それは「問題ない」と答える可能性が非常に高いです。
本には完全なコード例が記載されています。
Producerのプロンプトは「あなたはPython開発者です。階乗を計算する関数を書き、境界条件と例外を処理してください」です。
Criticのプロンプトは「あなたは細部にこだわる上級エンジニアであり、コードを一行ずつレビューし、バグ、スタイル、見落とされた境界条件、改善点をチェックします。完璧であれば
CODE_IS_PERFECTと出力し、そうでなければすべての問題を列挙してください」。次に、for ループがあります：Producer がコードを記述 → Critic がレビュー → Producer がフィードバックに基づいて修正 → Critic が再レビュー → Critic が
CODE_IS_PERFECTと述べるか、最大イテレーション回数に達するまで繰り返します。
これだけで十分です。しかし、本には見落とされがちなコストの問題が指摘されています：各リフレクションのループは新しいLLMの呼び出しであり、反復回数が増えれば増えるほどコストがかかります。さらに、対話履歴が膨らむにつれて、コンテキストウィンドウが以前のバージョンや批評で埋め尽くされ、実質的な推論スペースが狭まってしまいます。したがって、リフレクションのベストプラクティスは：適切な最大反復回数（本では3としています）を設定し、Criticが満足したら即座に停止し、完璧を求めないことです。
コードを書く以上の用途があります。記事の執筆、計画の立案、ドキュメントの要約、論理パズルの解決など、Producer-Criticモデルはすべて適用できます。本には7つの適用シーンが挙げられていますが、その核心的なロジックは同じです：まず出力し、次に検証し、最後に修正します。
マルチエージェントは複雑であれば良いというわけではありません
この章で最も気に入ったのは、その六つの通信トポロジー図です。多くの人が最初から複雑なものを取り入れますが、実際にはほとんどのシナリオで三种で十分です：
単一エージェント（独立実行）：タスクを互いに依存しないサブタスクに分割でき、各エージェントが自身のタスクを独自に処理します。シンプルで保守しやすいです。
ピアツーピア：エージェント同士が直接通信し、中央制御ノードは存在しない。分散化され、耐障害性が高く、あるエージェントが停止しても全体に影響しない。ただし、調整コストが高く、混乱しやすい。
スーパーバイザー（中央スケジューリング）：1つのスーパーバイザーエージェントが複数のワーカーエージェントを管理し、タスクを割り当て、結果を収集し、コンフリクトを解決します。階層が明確で管理しやすいですが、スーパーバイザーは単一障害点であり、パフォーマンスのボトルネックにもなります。
その他の3種（Supervisor-as-Tool、階層型、カスタムハイブリッド）は、前述の3種の変形および組み合わせです。書籍には、必要なトポロジーはタスクの複雑さに依存すると実践的に記されています。タスクを細分化しすぎると通信コストが増加し、あるレベルに達すると、Supervisorモードの方が階層型よりも効率的になります。
私の経験では、多くの人がMulti-Agentを構築する際に、通信プロトコルに80%の時間を費やし、より基本的な問いである「このタスクは本当に複数のAgentを必要とするのか？」を忘れてしまうのです。本には明確に書かれていますが、Level 2の単一Agent + Reflectionで十分な場合がほとんどです。Level 3は、単一Agentでは本当に対応できないシナリオ向けに用意されています。
Memoryの3層モデル、以前から漠然と感じていたが名前をつけなかった
この章で最も共感したのは、ObsidianとClaudeに関する2つの記事を書いている際に、エージェントのメモリをどのように階層化すべきかをずっと考えていたからです。
本の中に答えが載っています：
セッション（セッション層）：現在の会話のコンテキストウィンドウであり、最も短い記憶です。会話が終了すると消えます。ロングコンテキストモデルはこのウィンドウを拡大するだけですが、本質的には一時的であり、毎回の推論でウィンドウ全体を処理する必要があるため、コストが高く、遅くなります。
ステート（状態層）：現在のタスク実行中の一時的なデータ。たとえば、「現在実行中のタスクは何か」、「どの段階まで完了したか」、「途中で生成されたデータは何か」など。セッションより長く維持されるが、タスク終了時にクリアされる。書籍ではGoogle ADKのステートメカニズムを用いた完全な例を示している。
メモリ（永続層）：セッションやタスクをまたいだ長期記憶。ユーザーの好み、学んだ経験、重要な過去の意思決定をデータベースまたはベクトルデータベースに保存し、セマンティック検索を行う。書籍では、メモリは単に保存するだけでなく、「何を保存するか」「いつ保存するか」「どのように検索するか」の全体的な戦略を設計することが非常に重要であると強調されている。保存しすぎるとノイズが増え、保存しすぎると十分な情報が得られない。
以前私がClawdbotに関する記事を書いた際、「ステータスファイル」と「ワークスペースドキュメント」に言及しましたが、これらは本質的にState層とMemory層を手作業で構築していたものです。その本はこの作業をフレームワーク化しています。
五つの仮定、そのうち五番目が最も馬鹿げている
最後に、エージェントの未来に関する5つの仮説が提示されている。最初の4つはまだ合理的な推論の範囲内にある：汎用エージェントがコードを書くことからプロジェクトを管理するまで、深くパーソナライズされた主動的なニーズ発見、エッジ型知能がスクリーンから物理世界へと進出、エージェントが独立した経済主体となる。
第五に衝撃を受けたのは、変形Multi-Agentでした。
目標を明確に宣言するだけです。たとえば、「高品質なコーヒーを販売するECビジネスを始める」。システムは自動的に「市場調査エージェント」と「ブランドエージェント」を作成します。一度データを実行した後、ブランドエージェントは不要と判断し、代わりに「ロゴ設計エージェント」、「ウェブサイト構築エージェント」、「サプライチェーンエージェント」の3つに分割します。ウェブサイト構築エージェントがボトルネックとなった場合、システムは自動的に3つの並列エージェントを生成し、異なるページを同時に処理します。このプロセス全体で、システムは各エージェントのプロンプトを継続的に自動最適化し、チーム構成を継続的に再編成します。
本ではこれを「目標駆動型の自己変形マルチエージェントシステム」と呼んでいます。これはあなたが書いた計画を実行するのではなく、自ら計画を生成し、調整し、実行チームを再構成します。
これはKarpathyのAutoResearchを思い起こさせる：目標、指標、境界をprogram.mdに定義し、「起動」する。人間はループの外にいる。しかし、この本はさらに進み、エージェントチームの構成や再編成まで、システム自身に決定させる。人間は「何を必要とするか」を宣言するだけだ。
今すぐできる3つのこと
この本を読み終えて、すぐに実行できる3つのアクションがあります：
まず、現在のAgentにCriticを追加してください。Claude Code、CrewAI、または独自に構築したフレームワークを使用しているかに関わらず、現在のワークフローの最後に、別のAgent（異なるsystem promptを使用）が前ステップの出力をレビューする工程を追加してください。コード生成にはコードレビューを、記事執筆には事実確認を、計画策定には実行可能性の評価を組み合わせます。LLMの呼び出しは一回増えるだけで、品質はほぼ倍増します。本書のProducer-Criticモデルは、そのまま使い回せます。
第二に、Prompt Engineeringだけでなく、Context Engineeringを開始してください。Agentに与えた指示ファイルを振り返ってください。もしすべてが「あなたはどのように行動すべきか」というルールだけで、「現在どのような環境にいるか」という文脈が欠けていれば、補ってください。Agentに、現在どのプロジェクトにいるのか、以前にどのような決定を下したのか、ユーザーの好みは何かを伝えてください。本のContext Engineeringの章と、あなたの
AGENTS.mdは、同じことを二つの異なる表現で述べているだけです。第三に、すぐにMulti-Agentに進むのは控えましょう。あなたの単一AgentをLevel 2まで仕上げてください：ツール、Reflection、Memoryを備えた状態にします。書籍では繰り返し強調されていますが、Level 2の単一AgentにProducer-CriticとContext Engineeringを加えることで、ほとんどの実際のシナリオをカバーできます。Level 3は、本格的に複数分野にまたがり、複数段階を経て並列的にタスクを分担する必要がある場合のために用意されています。多くの人の問題はAgentが十分でないのではなく、一つのAgentもきちんと調整できていないことです。
この本は453ページで、Springerより2025年に出版されます。コード例はLangChain/LangGraph、Google ADK、CrewAI、OpenAI APIをカバーしています。序文はGoogle Cloud AIのバイスプレジデントが執筆し、Goldman SachsのCIOによる推薦の序文もあり、意外に読み応えがあります。
しかし私がそれを推奨する理由は「包括的」だからではありません。読めばあなたは一つに気づきます：過去半年間、Agentで経験したすべての失敗が、すでにパターンとして整理されているということです。あなたはReflectionを再発明する必要も、Memoryをどのように階層化すべきか推測する必要も、Multi-Agentにどの通信トポロジーを使うべきか試す必要もありません。
誰かが地図を描いてくれたので、あとは歩くだけです。
AIエージェントを使って開発していますか？現在のエージェントはレベル幾つですか？