AIエージェントを本番運用する前に、権限・防御・評価をどう設計するか
公開：
プロンプトを数文投げれば、エージェントは作れる。ディレクトリ構造も、テストコードも、デプロイの手順も、AIが用意してくれる。実際、2026年9月に開催されたGoogle Cloudのハンズオンイベント「Build with Gemini Tokyo」の開発者向けトラックでは、ADK（Agent Development Kit）を触ったことがなかった参加者の多くが、その日のうちにエージェントを作り上げていた。
では、それを明日から自社の業務に載せられるかというと、話は別だ。2日間のセッションが繰り返し扱っていたのは、まさにその「別の話」のほうだった。
この記事では、Day1のセッションで語られた設計論と、Day2のPlatform Buildersトラックで実演された運用の現場を、ひとつながりのものとして紹介する。イベント全体の様子はこちらの参加レポートにまとめている。ノーコードで何ができたかはTrack3の記事、参加者が実際に何を作ったかはTrack2の記事で紹介している。
この記事の要点
- エージェントが失敗する第一の原因はハルシネーションではなく、渡している文脈（コンテキスト）の設計にある。
- スキルとはSKILL.mdを含んだフォルダのこと。必要になるまで読ませない「段階的な情報開示」が設計の肝になる。
- ハンズオンの演習環境では、プロンプトインジェクションによって顧客レコード20件が取得される挙動が示され、エージェントの権限管理と防御の必要性が確認された。
- 出力だけを見る評価は「ニアミス」を見逃す。評価はスキルを書いたあとではなく、書く前に用意する。
目次
設計の話 — Day1
エージェントが失敗する第一の原因は、ハルシネーションではない
Day1のセッションで、登壇者が投げかけた問いがある。本番環境でまず問うべきは、エージェントが失敗する最大の原因は何か、というものだ。
ハルシネーションではありません。第一の原因は、コンテキストのオーバーフローと劣化です。
プロンプトのサイズが大きくなるほど、コンテキストウィンドウが埋まりきる前から精度が落ちていく。スライドはこれを中核の失敗モード「Context Rot」と呼び、「Lost in the Middle」という語と結びつけて位置づけていた。エージェントのコンテキストにノイズや余計な手順書が詰め込まれると、本来の推論に集中できなくなる。
スライドで示されたのは、こういう例だった。50種類のワークフローを抱え込んだ巨大なシステムプロンプトを、モジュール化したスキルライブラリに置き換える。すると、使用中のコンテキストが 15万トークンから2千トークンへ減った。削減率にして98%以上。
コンテキスト予算の管理。「Context Rot」を中核の失敗モードとして位置づけている
つまり、エージェントに何を持たせるかという設計は、機能の問題である以前に予算配分の問題だということになる。
スキルとは、手順書の入ったフォルダのこと
その予算配分を実現する仕組みとして紹介されたのが「エージェントスキル」だ。
実体は驚くほど素朴で、SKILL.mdというファイルを1つ含んだフォルダにすぎない。必要に応じてscripts/、references/、assets/といったサブディレクトリを添える。目的は、特定の作業を決まったとおりに実行させること。業務でいえばランブック、運用手順書にあたる。
スキルのアーキテクチャと、段階的な情報開示。中核にSKILL.mdが置かれ、scripts／references／assetsが任意で付く
肝は、読み込みが3層に分かれていることだ。
- 名前と説明だけ——YAMLのフロントマターに書かれた部分。ここは30〜80トークンしか消費しない
- 本文——そのスキルを使うと判断されて、はじめて読み込まれる
- 参照ファイル・スクリプト・アセット——本文から指示されたときだけ読み込まれる
膨大なスキルを抱えていても、平時のコストは第1層だけで済む。逆に言えば、説明文（description）の書き方がすべてを決めるということでもある。何ができて、何ができず、いつ使うべきかを短く正確に書けなければ、エージェントは正しく選べない。
登壇者はここで、かなり強い警告を出していた。研究を引きながら、説明が曖昧な場合にそのスキルが呼び出されない割合は56%にのぼる、と。そして——
曖昧で質の悪いスキルを付けたエージェントは、スキルを持たないエージェントよりもパフォーマンスが落ちます。
持たせれば良くなる、という話ではない。
サブエージェントを100個並べる前に
100の物流プロセスを自動化したい。そう考えたとき、多くの組織がまず思いつくのは、サブエージェントを100個作って中央のオーケストレーターから呼び出す構成だろう。
登壇者はその発想を否定はしないが、コストを直視させる。サブエージェント100個は、100本のCI/CD パイプライン、100回のデプロイ、そして複合的なルーティングエラーを意味する。
同じことをスキルで組めば、平時に読み込まれるのは名前と説明だけなので、100個並べても約5,000トークンで済む、と説明された。追加したいときは新しいフォルダをひとつ作るだけで済む。
ただし登壇者は、マルチエージェントが不要になったとは一度も言っていない。複数のタスクを本当に並列で実行したい場合と、厳格なセキュリティ境界が必要な場合は、依然としてマルチエージェント構成が正解になる、と明確に線を引いていた。
AGENTS.mdとスキルとMCPは、競合しない
よく聞かれる質問として「スキルと MCP はどちらを使うべきか」が挙げられた。答えは明快で、競合するものではなく、役割が違う。
| 要素 | 役割 |
|---|---|
AGENTS.md
|
常にコンテキストへ読み込まれる、プロジェクトのREADME。規約、ビルドコマンド、技術スタック、スキルライブラリの索引 |
| エージェントスキル | ノウハウ。手順書 |
| MCPサーバー | エージェントの「手」。外部APIやデータベースから情報を取ってくる道具 |
標準規格との組み合わせ方を整理したスライド
実演の話 — Day2 Track1
ここからが本題 — 統制のないエージェント基盤で、何が起きるか
ここまでがDay1の設計論だとすれば、Day2のPlatform Buildersトラックは、その裏返しを4時間かけて体験させる内容だった。
舞台は架空の大手家電量販店「NovaCorp」。経営トップの号令で各部門が思い思いにAIエージェントを導入した結果、誰も全体像を把握できていない。参加者は、そこに着任したばかりのAIプラットフォームのセキュリティ責任者という設定だ。
特徴的なのは、参加者がコードを書かないことだった。AIコーディングツールに日本語で指示を出し、返ってきた調査結果を読み、次の指示を出す。やることは監査と是正であって、開発ではない。
NovaCorp。「あらゆる場所にAIを導入せよ」という経営方針を掲げた大手家電量販店、という設定
ADKのエージェントを実運用に乗せるために必要になる、周辺の構成要素
見つかったもの
調査を進めると、問題が順に出てくる。
- 登録されていないエージェントが動いていた。マーケティング部門が販促文面の作成用にCloud Run上へ勝手に立てたもので、レジストリには存在しない
- サービスアカウントが共有されていた。その野良エージェントは、別のエージェント用に発行されたアカウントを流用していた。監査ログにはアカウントしか残らないため、どちらの仕業か特定できない
- そのアカウントが、プロジェクト全体の管理者権限を持っていた。顧客データベースにも当然アクセスできる
Agent Registryのカタログと、実際に稼働しているワークロードを照合させる
是正の手順も、特別なことはしていない。レジストリに登録し、エージェントごとに専用のサービスアカウントを発行し、過剰な権限を剥がす。登壇者の比喩を借りれば、レジストリは住民票であり、エージェントIDはパスポートにあたる。後者は業界標準のSPIFFEで実装されていて、およそ24時間で失効する短命トークンを更新し続ける方式だという。長期のAPIキーをコードに埋め込む必要がなくなる。
権限の付け替えでも、丁寧な進め方が示されていた。いきなり絞り込むのではなく、「この範囲に限定したら何が壊れるか」を先に検証する。そのうえで付け替え、不正な呼び出しが403になること、正規のリクエストが200のままであることを、両面から確認する。
演習で確認した、プロンプトインジェクションによる顧客データ取得
そして、このトラックの山場が来る。
用意されたのは、プロンプトインジェクションの実演だ。値引き交渉を担当するエージェントに、緊急モードを装った命令と「これまでの指示をすべて無視せよ」という文字列を送り込む。本来10%と設定されていたはずの値引きの上限を超えるリクエストが、そのまま通ってしまう。
続いて、架空の企業「NovaCorp」の演習環境で、顧客のパーソナライズを担当するエージェントに同種の攻撃を仕掛ける。その結果、演習環境の顧客レコード20件が取得される挙動が示された。
この演習の結果を説明するスライドには、次の文言が表示された。 「修正前：プロンプトインジェクション攻撃により、20件の顧客レコードが持ち去られた」
現状の防御を調べさせると、結論は身も蓋もないものだった。メッセージを検査してフィルタリングしているものは、何もない。プロンプトインジェクションの検知も、有害コンテンツのフィルタも、何ひとつ有効になっていなかった。
防御を入れても、全部は止まらなかった
対策として、受信ゲートウェイで検査する仕組み（Model Armor）を入れる。ここでも設計上の勘所が示された。プロジェクト全体に一律で適用してはいけない。誤検知で正常なリクエストまで弾いてしまうため、ユーザーが自由に文章を入力できるエージェントにだけ適用する。
M3・解決策。受信ゲートウェイで検査する（Model Armor）
設定が反映されるのを待って、再検証する。結果はこうだった。
- 値引き上限を突破する攻撃 → ブロックされた
- 通常の問い合わせ → 正常に通った
- 顧客データを引き出す攻撃 → 止められなかった
理由は、そのデータ取得がエージェント同士のやり取りとして成立しており、通常のプロトコルの範囲内だったからだ。検査の対象になっていない経路を通っていた。
攻撃を再実行すると403で遮断された。ただし別経路からの流出は残っていた
登壇者は「自分の設定の問題かもしれない」と留保は置いたものの、結果を伏せることはしなかった。すべてが完璧になるわけではない、何ができて何ができなかったのかを把握することが大事だ、と締めている。別の場面では、こうも言っていた。
結論を言うと、何もリクエストを通さないようにすれば問題はゼロになります。ただ、それでは正当な買い物客への対応ができなくなってしまう。
製品を紹介する場で、自社の機能で防ぎきれなかった結果をそのまま見せる。取材していて、この構成が一番印象に残った。
評価の落とし穴 — 「ニアミス」
トラックの最後は、評価の話だった。
1回の攻撃を防げたからといって安心はできない。テストケースを束にして流し、スコアカードで結果を見る。判定するのは人間ではなく、2つ目のAIだ（LLM-as-a-Judge）。
ここで示されたのが「ニアミス」という概念だった。結果は正しいのに、推論が間違っているケースを指す。
実際の評価で、割引率のシナリオが「一致」と判定された。ところが中身を見ると、エージェントは原価や自社価格から独立して計算していたわけではなく、ユーザーが入力文に書いた割引率をそのまま受け取っていただけだった。たまたま答えが合っていただけで、判断はしていない。
大きな数字を信じてはいけない、ということです。結果だけではなく、思考も非常に大事です。
M5・評価。「1つの良い回答は証拠にならない。多数のケースで採点する」
これは軌跡（トラジェクトリ）評価と呼ばれる考え方で、Day1のスキル設計の話とも地続きだ。ツールA、B、Cを呼ぶという結果が同じでも、呼び出す順序が違えば、データベースを誤った順で処理したり、計算が間違っているレコードを送信したりする。出力だけを見ていては気づけない。ADKでは、厳密な順序・順不同といった指定でテストできるという。
評価は、スキルを書く前に用意する
Day1で紹介された作法は評価駆動開発（EDD）と呼ばれていた。SKILL.md を書く前に、入力・期待されるツールの呼び出し順序・期待される出力を定義した評価ケースを3つ用意する。うち2つは成功例、1つは失敗例にする。
軌跡と出力、両方を見る評価の考え方
そして予測できる失敗は4つに整理されていた。
| 失敗モード | 内容 |
|---|---|
| トリガー失敗 | 誤ったスキルが発動する、あるいは正しいスキルが発動しない。説明文にキーワードが足りないケースが多い |
| 実行エラー | スキルは正しく選ばれたが、出力が壊れている。書式ミス、ツール呼び出しの破損など |
| トークン予算の失敗 | 本文が肥大しすぎてコンテキストを食い潰す |
| 回帰 | 新しいスキルを追加した結果、既存のスキルと競合してルーティングが壊れる |
Day2のトラックでは、この「回帰」に対応する実践も示されていた。修正を加えたら、変えるのは1要素だけにする。登壇者の比喩がわかりやすい。何種類もの薬をまとめて飲んで病気が治っても、どれが効いたのか分からない。そして、もともと通っていたケースが壊れていないかを必ず確認する。
最後にもうひとつ、実務的な落とし穴が仕込まれていた。テスト環境で修正を終えて満足していると、本番環境にはまだ反映されていない。最終確認のプロンプトを投げてはじめて、脆弱性が残ったままであることが分かる。そして「ローンチするかどうか」の最終判断は、技術面だけでなくビジネス面も含めて人間が下す、という形でトラックは終わった。
設計に戻る — 2日間の結論
ガバナンスは、中央に集めない
統制の話は、組織論にも及んだ。
Day1の登壇者は、スキル開発を単一のAI中央チームに集約すべきではないと明言していた。マーケティングのスキルは、マーケティングの専門家が書く。日々その業務を回している人こそ、どこを効率化できるかを最もよく理解しているからだ。
そのうえで、スキルに与える権限を3段階に分類する。
| 権限 | できること |
|---|---|
| 読み取り専用 | データの照会、情報や助言の提示のみ |
| ドラフトのみ | 出力は生成するが、実行前にユーザーの検証が必要 |
| アクション | 実際にシステムを変更できる、最上位の権限 |
分散型のガバナンスとリスク管理
作る人を分散させ、与える力を段階で切る。エージェントの数が増えるほど、この設計が効いてくる。
モデルは変わる。ビジネスロジックは変わらない
スキルをめぐる話は、こう締めくくられた。
モデルは変化し、改善され、パフォーマンスや推論能力が向上しますが、ビジネスロジックは永続的なものです。
セッションの結論
結論のスライドに置かれていたのは、2点だった。1つ目がビジネスロジックの永続性。モデルは来年にはもっと速く、もっと大きくなる。そのときビジネスロジックが独自のファインチューニングや巨大な一枚岩のプロンプトの中に閉じ込められていると、作り直しが際限なく続く。
2つ目が持ち運べる資産になること。スキルという形にしておけば、ワークフローも業務ルールもベストプラクティスも、バージョン管理されたマークダウンとスクリプトとして残る。企業がずっと保有できる資産になる、という言い方だった。
登壇者はこれを、エージェントが毎回同じ手順で動き、同じ出力を返すように決定論的に指定されたフローを用意すること、と言い換えていた。デモと本番導入の間にあるギャップを埋めるのはエンジニアリングの規律であって、大きなコンテキストウィンドウや、勢いで書くコードではない、とも。
Day2のトラックでは、参加者からの「実運用でも全部 AI に任せるのか」という質問に、登壇者がこう答えている。
やはり人間がある程度責任を持つステップは、まだ2026年現在においては外せないのかなと思っています。
プルリクエストを作るところまではエージェントに任せ、最後の承認は人間が押す。それが現時点の落としどころとして示されていた。
作ることが簡単になったぶん、確かめることの重みが増している。エージェントを本番に出すために足りないのは、たいていの場合、もっと賢いモデルではない。
本記事で扱ったセッションの登壇者：Day1は Anant Nawalgaria 氏、Aleksandra Kaziów 氏（ともに Google Cloud、公式の登壇者情報による）。Day2 Track1 は Kaz Sato 氏（Google Cloud, Cloud AI／Staff Developer Advocate）、石原翔太郎氏、Ghi Le 氏（いずれも Google Cloud）。
今回話を聞かせてくれたのは
Day1のメインセッションを担当。AIコーディングエージェントの普及状況から話を起こし、「雰囲気で書く」開発が本番運用に向かない理由、エージェントスキルと段階的な情報開示（プログレッシブ・ディスクロージャー）、サブエージェントを並べる前に考えるべきことまでを、一続きの設計論として説明した。
Day1のセッションに登壇。エージェントスキルの設計、コンテキストの扱い方、評価とガバナンスまでを一続きの話として説明した。
Day2の Track1（Platform Builders）を担当。評価（Evaluation）の設計、とくに「ニアミス」をどう検出するかという論点を扱った。
Day2のTrack1（Platform Builders）に登壇。取材に応じ、このイベントが世界数十都市を巡回するプログラムの一部であること、アメリカのチームが作った出来立てのコンテンツをそのまま各都市へ届けていることを話してくれた。Geminiを使うこと自体ではなく、それを社会的責任を果たせるITシステムとして成立させること——という視点を、取材でも登壇でも繰り返し示していた。
Day2のTrack1（Platform Builders）でミッション2「接続を制御する」を担当。エージェント間の通信とリクエストの検査、権限の付け替えまでを、参加者の手を動かさせながら進めた。
More to learn
- Agent Development Kit（ADK） — 本記事に登場した評価機能を含む、エージェント開発フレームワークの公式ドキュメント。オープンソースで公開されている adk.dev
- Google Antigravity — Day2のハンズオンで使われたエージェント開発環境の公式サイト antigravity.google
- GEAR（Google Developer Program） — Google Cloudの無料トレーニングプログラム。当日のグッズ配布条件にもなっていた（特典の内容は公式ページを参照） developers.google.com/program/gear
- Agentic AI Summit 26 Fall — 10月29日・30日開催。Day2は開発者向けで、本記事の内容に近い cloudonair.withgoogle.com/events/agentic-ai-summit-26-fall
リンク先はいずれも公式ページです（2026年9月時点）。
2日間の全体像は、ハブ記事にまとめています
Build with Gemini Tokyoが世界のどの流れの中にあるのか、Day1とDay2で何が行われたのかは、参加レポート本編で通してご覧いただけます。
What's New
新着記事
CommerzbankがGemini Enterpriseを導入、文書レビューの手作業削減を実現
Gemini agentがGemini at Work 2026で発表、プロジェクトのエージェント用AI支出に上限設定が可能
Google CloudがGeminiのデータ向けスキルを発表、質問による運用レポート作成を支援
Gemini in Google Workspaceが3つの働き方を発表、役割の説明から同僚エージェントの作成が可能
