2026年8月17日にGoogle Developers Blogで公開された zero-trust AI agents の実装ガイドは、AIエージェントを本番業務へつなぐ企業にとって重要な整理でした。結論から言うと、今回の論点は『モデルの賢さを上げること』ではなく、『モデルが誤っても壊れない境界をどう置くか』です。特に返金、顧客対応、社内DB更新のように状態変更を伴う運用では、system prompt だけで安全を担保しようとすると限界が出ます。
GoogleはADKとGeminiで作ったサポートエージェント例を使い、Cloud KMSによる署名、gVisorによるコード隔離、deterministic semantic gateway による入出力検査の3層を提示しました。日本の開発チームが見るべきポイントは、どの層をどの責任者が持つかを先に決めることです。情シス、プロダクト、開発基盤の分担が曖昧なまま agent を増やすと、便利さより監査負債が先に膨らみます。
何が公開され、なぜ今確認すべきか
Googleの公式記事は、ADKで作る自律エージェントが live database、internal API、dynamic runtime environment に触れた瞬間、普通のアプリ開発ではなく production state を変える主体になると明言しました。つまり『会話できるツール』ではなく『権限を持つ実行体』として扱え、という整理です。
記事内では autonomous support & refund agent を例に、自然言語の prompt injection 1本で過大返金、環境変数の流出、ホスト侵害まで連鎖し得ると説明しています。2026年のAI導入で増えているのは、まさにこうした問い合わせ対応、台帳更新、ワークフロー自動化です。日本企業でも PoC から本番へ移る段階なので、今のうちに『どこをLLMに任せ、どこを決定論で閉じるか』を設計しておく価値があります。
3つの防御層: 署名・隔離・ゲートウェイ
1つ目は Cloud KMS と HSM を使った write 署名です。記事では、各エージェントに固有の鍵を割り当て、データベースへ書き込む payload ごとに署名させる構成を示しています。これにより、誰の処理がどの更新を生んだかを後から追跡しやすくなり、SQL injection や不正な再書き換えも監査で検知しやすくなります。AIの判断が正しいか以前に、『その更新が本当に想定エージェント由来か』を証明できるのがポイントです。
2つ目は gVisor による kernel-level の実行隔離です。LLMが動的に作った Python をそのまま exec したり、通常のコンテナへ載せるだけでは、外部通信やホスト侵害の余地が残ります。Googleは runsc、network none、cap-drop=ALL、メモリ上限、CPU制限を組み合わせ、生成コードを user-space kernel 内で実行する例を出しました。これは『コード生成AIを使う』企業ほど優先度が高い論点です。
3つ目は deterministic semantic gateway です。これは prompt と tool call の前後に、秘密情報、越権指示、金額上限違反などをルールベースで検査する層です。社内導入で『AIにどこまで任せるか』の線引きに迷う場合は、まずこの層から整備するのが現実的です。 自社のagent運用ルール設計やレビュー基準を急ぎたい場合は、 HelloCraftAIに相談 してください。
導入担当が最初に決めるべき判断ポイント
判断ポイントは3つです。第1に、state-changing action を全部洗い出すこと。返金、承認、削除、更新、送信など、あとから取り消しにくい操作は一覧化し、署名対象と gateway 対象を先に分けます。第2に、生成コードを許すかどうか。もし許すなら gVisor のような sandbox を前提にし、ネットワーク遮断と resource limit をセットで入れます。第3に、モデル変更時の回帰試験を持つこと。Googleも CI/CD で gateway ルールをテストすべきだとしています。
特に日本企業では、『AI利用ポリシーはあるが、実行権限の設計はない』状態が起きがちです。今回のガイドは、生成AIガバナンスを文書だけで終わらせず、署名検証、権限制御、テスト自動化に落とし込む必要性を示しています。開発責任者は model 選定より前に、どの操作を人間承認に残すか、どこから先を sandbox 必須にするかを定義しておくと、後戻りコストを抑えられます。
HelloCraftAI視点の実装順序
実装順序は、1) semantic gateway で危険な入力と危険な出力を止める、2) state-changing tool に署名または承認トークンを要求する, 3) 動的コード実行を gVisor などへ隔離する、の順が現実的です。最初から完璧なゼロトラスト基盤を作るより、事故コストの高い箇所から hard boundary を増やす方が進めやすいです。
また、Googleの記事は refund agent 例ですが、転用先は広いです。社内FAQ bot が SaaS 管理APIを叩くケース、営業支援agent がCRMを書き換えるケース、コード修正agent が本番ブランチへPRを出すケースでも同じです。『自然言語で指示できる』ことと『安全に実行できる』ことは別物なので、PoC成功をそのまま本番基準にしないのが重要です。
FAQ
Q. system prompt を強く書けば十分ですか？ A. 十分ではありません。Googleは system prompt を soft constraint と位置づけ、prompt injection や model update で振る舞いが崩れ得ると説明しています。安全境界は LLM の外側に置く必要があります。
Q. まず全部に HSM や gVisor を入れるべきですか？ A. いいえ。返金、削除、外部送信、権限変更のような high impact action から優先導入するのが現実的です。閲覧専用の summarization agent と、DB更新を伴う agent では必要な守りが違います。
Q. どのチームがオーナーになるべきですか？ A. semantic gateway はアプリ/プラットフォーム、署名基盤は情シスまたはクラウド基盤、sandbox は開発基盤が持つ形が進めやすいです。重要なのは、責任分界を曖昧にしないことです。
今週のチェックリスト
今週やるなら、まず agent が実行する update / delete / send の一覧を作る、次に禁止したい prompt と tool call を 10件ほど列挙して gateway テストを書く、そのうえで生成コード実行の有無を確認してください。もし『どの層から入れるべきか』『社内のAI利用規程と実装をどう接続するか』で迷うなら、PoCのまま広げる前に設計レビューを挟むべきです。ゼロトラスト化は大げさな標語ではなく、AI agent を業務システムへ入れるための最低限の実装要件になりつつあります。
