Google ADKで作るゼロトラストAIエージェント実装チェックリスト
GoogleのADK記事は、ツール利用、コード実行、データベース更新を行うAIエージェントに、署名、サンドボックス、ポリシーゲートウェイが必要だと示している。

この記事の要約
This article covers Google ADKで作るゼロトラストAIエージェント実装チェックリスト. GoogleのADK記事は、ツール利用、コード実行、データベース更新を行うAIエージェントに、署名、サンドボックス、ポリシーゲートウェイが必要だと示している。
ポイント
- Published: September 1, 2026
- Category: AI & Developer Tools
- Tags: Google ADK, AI Agents, Zero Trust, Prompt Injection, Developer Tools, Security
- Views: 242
- Reading time: ~6 min read
"GoogleのADK記事は、ツール利用、コード実行、データベース更新を行うAIエージェントに、署名、サンドボックス、ポリシーゲートウェイが必要だと示している。"
出典: https://developers.googleblog.com/build-zero-trust-ai-agents-with-googles-agent-development-kit/

要点整理:本番エージェントには強い境界が必要
システムプロンプトは安全境界ではありません。確率的なモデルへの指示であり、プロンプトインジェクションやモデル更新で崩れる可能性があります。Googleの記事が示すゼロトラスト設計は、モデルがだまされる前提で、重要な制御をプロンプトの外に置きます。状態を変える書き込みの署名、生成コードの隔離、入力と出力とツール呼び出しの決定的な検査が中心です。
エージェント安全性が注目される理由
AIエージェントはサポート、分析、コンテンツ運用、開発作業に入り始めています。問題は回答品質だけではありません。悪意ある指示を受けたとき、どの権限まで届くかが重要です。Googleの例では、返金エージェントが金額を計算して台帳に記録します。攻撃者が規則を無視させ、高額返金や環境変数の表示を求めると、モデルを信頼した設計ではデータベースと実行環境が危険になります。
第一の対策:重要な書き込みに署名する
すべてのワーカーが同じ広いデータベース接続を使う構成は避けるべきです。各エージェントが自分の鍵で状態変更ペイロードに署名し、APIや入口のガードがコミット前に検証します。これにより、どのエージェントが記録を作ったか、承認された内容は何か、後から改ざんされていないかを確認できます。決済、権限変更、公開処理、モデレーションでは特に有効です。
第二の対策:生成コードを隔離する
エージェントは計算、ファイル解析、データ整形のために短いコードを作ることがあります。本番サーバーの通常権限で実行すると、秘密情報の漏えいやホスト侵害につながります。GoogleはgVisorのような隔離、ネットワーク遮断、能力削除、メモリ制限、短いタイムアウトを挙げています。小規模チームでも、専用ランナー、ネットワーク制限、入出力ログ、秘密情報からの分離は最低限必要です。
第三の対策:プロンプトとツール実行を検査する
ポリシーゲートウェイは、脱獄表現、秘密鍵らしい出力、上限を超える返金、危険なSQL、高リスク操作を検査できます。モデルより創造的である必要はなく、予測可能であることが重要です。AIツールを選ぶときは、ワークフロー別のID、変更不能な監査ログ、サンドボックス、管理者が上書きされない制限、攻撃テストを確認しましょう。BTTCソフトウェアディレクトリ と BTTCブログ も参考になります。
よくある質問
Google ADKは必須ですか?
必須ではありません。ADKは例であり、ID、サンドボックス、ゲートウェイ、監査はどのフレームワークにも有効です。
よいプロンプトでprompt injectionは解決しますか?
いいえ。指示は行動を改善しますが、外部の強制制御の代わりにはなりません。
小規模チームの最初の一歩は何ですか?
エージェント実行環境から広い認証情報を外し、高リスクツールにゲートウェイとログを加えます。
導入時に確認したい運用ポイント
AIエージェント基盤を選ぶときは、モデル名やデモの派手さだけで判断しないことが大切です。確認すべきなのは、ワークフローごとに権限を分けられるか、ツール呼び出しが変更できない形で記録されるか、失敗時に取り消せるか、管理者の制限をユーザー入力が上書きできないかです。社内導入では、まず要約、分類、下書き、読み取り専用検索など低リスクな用途から始めると安全です。署名、隔離、ゲートウェイ、アラートがテストで確認できてから、書き込み権限を少しずつ広げます。
開発チームへの実務的な示唆
この考え方は大企業だけのものではありません。小さなプロダクトでも、無人ジョブが公開APIを通す、直接データベースを書かない、公開前に検証を行う、結果を監査ログに残す、という形で同じ原則を使えます。エージェントに便利な権限を与えるほど、境界の設計が価値になります。安全な自動化は速度を落とすためではなく、失敗を小さくし、後から説明できる状態を作るための投資です。
権限を段階的に広げる
すべてのエージェントに同じ強い権限を与える必要はありません。読み取り専用の要約や分類は比較的低リスクですが、アカウント変更、返金、公開、削除を行うエージェントは別扱いにするべきです。まず小さな権限で運用し、監査ログを見ながら失敗パターンを集め、テストを増やしてから権限を広げます。これにより、便利さを保ちながら事故の影響範囲を抑えられます。
評価で見るべき証拠
ベンダーや社内チームには、言葉ではなく証拠を求めましょう。サンドボックスの設定、ネットワーク制限、署名検証の失敗例、ブロックされたツール呼び出し、復旧手順、監査レポートが確認できると、運用前の判断が現実的になります。特に自律的な公開や顧客対応では、正常系のデモだけでなく、悪意ある入力を受けたときの停止動作を確認することが重要です。
継続的な監査を忘れない
一度設定した境界も、モデル更新、ツール追加、業務ルール変更で古くなります。定期的に拒否ログ、署名検証、サンドボックスの失敗、手動承認の件数を見直すことで、便利な自動化と安全性のバランスを保てます。
チェックリストをチームで共有する
セキュリティ担当だけでなく、プロダクト、サポート、データ、マーケティングも同じ基準を理解する必要があります。どの操作は自動化でき、どの操作は承認が必要で、どのログを残すかを文書化すると、エージェント導入後の判断がぶれにくくなります。
結論
ゼロトラストAIエージェントは本番運用の基本になります。狭いIDを与え、コードを隔離し、ツール呼び出しを検証し、監査できる証拠を残すことが重要です。
