プロンプトを書くだけでは、本番で動くAIエージェントは作れません。Googleが公開した54ページのホワイトペーパー「Introduction to Agents」は、チャットボットから自律型システムへ進むための設計地図として位置づけられています。
この記事では、同資料の骨格を整理します。5段階の成熟度モデル、3つのコア要素、本番運用に必要なAgent Opsまでを押さえれば、エージェント開発の全体像が見えてきます。
この記事でわかること
- Googleが定義するエージェントの5段階分類と、各段階で何が変わるか
- モデル・ツール・オーケストレーションという3要素の役割分担
- 本番投入に欠かせない評価・トレース・セキュリティの考え方
なぜ今、設計図が必要なのか
AIエージェントの試作は、フレームワークを使えば数時間で動かせます。一方で本番投入では、幻覚による誤回答、会話途中での指示忘れ、誤ったAPI呼び出しといった失敗が起きやすくなります。Googleの資料でも、プロトタイプ構築は容易だが、セキュリティ・品質・信頼性の確保が大きな課題だと明記されています。
従来のソフトウェア開発者は、処理の各ステップをコードで明示する「レンガ積み」型でした。エージェント開発では、目標・ツール・制約・品質基準を定義し、自律的に動くシステムを導く「監督」に近い役割へシフトします。資料は、この役割転換を前提に、再現可能なアーキテクチャを提示しています。
5段階のエージェント成熟度モデル
https://www.kaggle.com/whitepaper-introduction-to-agents
資料は、エージェントの能力をLevel 0からLevel 4まで5段階で整理しています。どの段階を目指すかを先に決めることで、過剰設計や機能不足の両方を避けられます。
Level 0：推論のみ
言語モデル（LM）単体で動く段階です。学習済み知識に基づく回答はできますが、外部ツールや記憶を持たないため、リアルタイム情報には対応できません。資料の例では、野球の歴史は説明できても「昨夜の試合結果」は答えられない、と説明されています。
Level 1：ツール接続
検索API、データベース、RAG（Retrieval-Augmented Generation）などのツールを接続し、外部世界とやり取りできる段階です。5ステップのループ（後述）がここから機能します。
Level 2：戦略的問題解決
複数ステップの目標を計画し、各段階で必要な文脈だけを選び出す「コンテキストエンジニアリング」が鍵になります。中間地点のカフェ探しのように、地図APIで中間地点を特定し、次の検索条件を自動生成する、といった連鎖処理が可能です。
Level 3：マルチエージェント協調
単一の万能エージェントではなく、専門エージェントのチームで分担する段階です。プロジェクトマネージャー型のエージェントが、市場調査・広報・Web開発などの下位エージェントへタスクを委譲します。エージェント間連携には、MCP（Model Context Protocol）やA2A（Agent2Agent）といったオープン標準が位置づけられています。
Level 4：自己進化
システムが自身の能力ギャップを検知し、新しいツールやエージェントを動的に生成する段階です。フィードバック、シミュレーション、本番障害から学習し、プロンプトやツール群を継続的に最適化します。
3つのコア要素と5ステップの実行ループ
エージェントは、モデル（脳）・ツール（手）・オーケストレーション（神経系）の3要素で構成されます。加えて、デプロイメント（体と脚）として本番環境への配置が必要です。
実行時は次の5ステップを繰り返します。
- ミッション取得 — ユーザーや自動トリガーから高レベルな目標を受け取る
- 状況把握 — 会話履歴、利用可能なツール、外部データを収集する
- 計画立案 — 目標と状況を照合し、多段階の実行計画を組み立てる
- 行動実行 — API呼び出し、コード実行、データベース照会などを行う
- 観察と反復 — 結果を記憶に追加し、目標達成までループを続ける
資料はこのサイクルを「Think, Act, Observe（思考・行動・観察）」と表現しています。カスタマーサポートの注文追跡の例では、注文検索→配送業者API照会→回答生成と、計画に沿った段階的実行が示されています。
モデル選定の実務的な考え方
ベンチマークスコアだけで選ぶのは失敗の典型です。資料は、自社のユースケース（コード生成なら自社リポジトリ、保険なら自社書類フォーマット）で評価することを推奨しています。Gemini 2.5 Proで計画を立て、Gemini 2.5 Flashで意図分類や要約を処理する、といったモデルルーティングも有効な設計パターンとして紹介されています。
ツール接続の標準
ツール連携にはOpenAPI仕様による関数呼び出しに加え、MCPが便利な発見・接続手段として位置づけられています。Human-in-the-Loop（HITL）ツールで購入確認や追加入力を求める設計も、高リスク操作では必須の選択肢です。
本番運用に必要なAgent Ops
3要素を組み立てただけでは、本番品質は担保できません。資料はAgent Opsを、DevOpsやMLOpsの延長として位置づけています。
評価設計
従来のoutput == expected型テストは、確率的な応答を持つエージェントには使えません。代わりに、ゴール達成率・ユーザー満足度・レイテンシ・1回あたりのコストといったビジネスKPIを定義し、「LM as Judge」で品質を採点する方式が推奨されています。ゴールデンデータセットへの自動評価と、本番A/Bテストを組み合わせ、デプロイのGo/No-Go判断を行います。
トレースによるデバッグ
OpenTelemetryトレースで、モデルへのプロンプト、選択されたツール、渡されたパラメータ、観察結果を時系列で追跡できます。メトリクスが低下したとき、「なぜそう動いたか」を特定する手段になります。
人間フィードバックの活用
ユーザーの低評価やバグ報告は、自動評価がカバーしきれないエッジケースの宝庫です。報告内容を再現し、評価データセットに恒久追加することで、同種の失敗を防ぐループが機能します。
セキュリティとエンタープライズ展開
エージェントには、人間ユーザーとサービスアカウントに加え、自律的に行動する「第3の主体」としてのエージェントIDが必要です。SPIFFEなどで検証可能なIDを発行し、最小権限の原則でツールやAPIへのアクセスを制限します。
プロンプトインジェクション対策として、コードによるハードガードレール（例：100ドル超の購入をブロック）と、AIによる動的ガード（Gemini as a Judge、Model Armor）のハイブリッドが推奨されています。組織規模で展開する場合は、MCP・A2A・LM推論リクエストを一元監視するゲートウェイ型のコントロールプレーンが、エージェントの乱立（agent sprawl）への対策として提示されています。
Googleの先端事例が示す到達点
資料後半では、研究分野のCo-Scientistと、アルゴリズム最適化のAlphaEvolveが紹介されています。
Co-Scientistは、研究者が目標を設定すると、スーパーバイザーエージェントが専門エージェント群へタスクを配分し、仮説の生成と評価を数時間から数日かけて反復します。AlphaEvolveはGeminiによるコード生成と自動評価を組み合わせ、進化的に解法を改善します。データセンター効率化、行列積アルゴリズムの高速化、未解決数学問題への新解法など、実績が挙げられています。いずれもLevel 3〜4の設計思想を具体化した例です。
開発者が取るべき次の一手
このホワイトペーパーは5部作シリーズの第1弾です。続編ではツール、メモリ、品質に特化した資料が予定されています。Google Skillsの「Agent Fundamentals」コースでも、同資料を基にした学習コンテンツが提供されています。
まずは自社のユースケースがLevel 1〜2で足りるか、Level 3のマルチエージェントが必要かを見極めます。次に、3要素の設計とAgent Opsの評価基盤を並行して整えます。プロンプトの巧みさより、ツール契約の堅牢さ、コンテキスト管理、継続的な評価の仕組みが、本番エージェントの成否を分けると資料は結論づけています。