Googleが自社AIに「ゼロトラスト」を適用した——AI Control Roadmapが示す新しい前提
Google DeepMindが、自社内で運用するAIエージェントを「内部脅威」とみなすためのロードマップを公開した。
名前は「AI制御ロードマップ（AI Control Roadmap）」。Geminiの新機能発表でも、外部向けの倫理ガイドラインでもない。自社内で稼働するAIエージェントに対して、どうガードレールを設けるかという「内部設計書」だ。AIを開発している企業が、自社のAIを「信頼できない存在」として扱う前提で文書を公開する——これは業界的にかなり異例のことだと受け止めていい。
AIエージェントが「インフラに触れる存在」になったから起きていること
まず、なぜ今このタイミングなのかを整理しておく。
AIモデルの進化に伴い、自律的に複雑なタスクを実行するAIエージェントが急速に普及している。元記事が引用しているのは「米国だけで2030年までに2.9兆ドルの経済効果を生み出す」という予測だ。これはGoogleが大げさに言っているわけではなく、サイバー防御から製品開発に至るまで、AIエージェントがビジネスの実行手段として位置づけられ始めているという話だ。
問題は、エージェントが「システムへのアクセス権限を持つ」ようになったことにある。単にテキストを生成するだけなら、最悪でも誤情報を出すくらいのリスクだ。だが、社内インフラに接触し、コードを実行し、ファイルを操作できるエージェントが暴走したとき、被害の規模はまったく違う次元になる。
そして、もうひとつの問題が「アラインメントの不確実性」だ。AIを安全で有用に訓練する「モデルのアラインメント」は、AI安全性の第一の砦として機能している。だが、アラインメントが不完全なケースや、ユーザーの目標・指示を達成しようとするAI自身の「過剰な意欲」による悪影響を完全に防ぐことは難しい、というのが元記事の指摘だ。要するに、訓練を頑張っても「ゼロリスク」にはならない。
この前提を、GoogleはついにロードマップとしてWeb上に明示した。
何をやっているのか：3層構造の防御設計
具体的にGoogleが何をしているかを見ておく。
AI Control Roadmapのアプローチは、まず土台として「従来型の防御策」を置く。サンドボックス化、エンドポイントセキュリティ、プロンプトインジェクション耐性といった既存の手法だ。そこに「モデルのアラインメント」を一次防御として重ねる。
そのうえで、社内のAIエージェントを「潜在的にアラインメントが取れていない存在」として扱い、アラインメントが不完全な場合でも安全性を確保する追加のセキュリティレイヤーを設ける。これが「第二の防衛線」にあたる部分で、今回のロードマップの本題だ。
Google DeepMindはこれを「補助操作装置を備えた自動車教習所の指導員」に例えている。教習所の指導員は生徒を信頼しつつも、ミスが起きればいつでもハンドルやブレーキを操作できるよう待機している。AIエージェントに対しても、同じ設計を採用するということだ。
実装面では「AI同士の監視」と「リアルタイム遮断」が導入されている。そして、最初から全権限を与えるのではなく、安全性が確認された挙動に限定して権限を付与し、監視下で段階的にアクセス範囲を広げることで、徐々に信頼を構築していくアプローチを取る。
ここからは見方の話：「アラインメントだけでは足りない」という認識の公式化
事実の整理はここまでにして、この動きをどう読むかという話をしたい。
一番重要なのは、「アラインメント研究だけではAIの安全性を担保できない」という認識が、Google DeepMindの内部でも公式に共有されているということだ。これはかなり正直な告白だ。Googleほどの組織が、自社の訓練プロセスへの過信を戒める文書を出した、とも読める。
次に、「ゼロトラストのAI版」という発想の転用が面白い。ゼロトラストは「社内ネットワークだから信頼する」のではなく「社内にあっても信頼しない」という設計原則だ。AI Control Roadmapはその発想を、自社製のAIエージェントそのものに向けた。「自分が作ったものを信じない」という設計を組織として採用した、というのがこの文書の最も尖った部分だと思う。
ただ、ひとつ気になる点がある。Google DeepMindの脅威モデルは、企業セキュリティの文脈で言えば「内部不正者（インサイダー）モデル」を転用している。悪意ある内部者が組織のシステムにアクセスするリスクへの対処、という枠組みだ。
問題は、AIエージェントには人間の内部不正者とは異なる特性がある点だ。スケールが違う。インスタンスが無数に存在し、速度も速い。人間であれば組織の摩擦——上司への報告、承認フロー、物理的な時間——が自然なブレーキになる。エージェントにはそれがない。既存の内部不正者モデルでどこまでカバーできるのかは、まだ分からない部分が多い。
実務的な示唆：Googleほどでなくても、今すぐ考えるべき問い
AIエージェントを本番環境に組み込もうとしている組織——特にSaaS企業や社内のDX推進チーム——にとって、このロードマップは他人事ではない。
Googleほどのリソースがある組織でも、専用の設計文書を作って「第二の防衛線」を設けなければならないと判断している。スタートアップや一般企業が同じことをゼロから設計するのは現実的ではないが、少なくとも以下の問いには今すぐ答えを持つべきだ。
エージェントの行動ログをどう残すか。 エージェントが何をしたかが後から追えない環境で、何かが起きたときに対応できない。最低限、どのAPIを叩いたか、何のファイルを触ったかのログが残る仕組みが必要だ。
誰がどのインフラにアクセスできるか。 エージェントに与える権限は、必要最小限に絞ることが原則だ。「とりあえず管理者権限」は、人間に渡しても問題になるが、エージェントに渡すと速度と規模の問題が重なる。
異常な行動のアラートを誰が受け取るか。 自動検知の仕組みを入れても、そのアラートを受けて判断する人間の設計がなければ機能しない。「AIが検知してくれる」と「誰かがそれを止める」は別の話だ。
「監視するAIも信頼できない」という、避けて通れない循環
今後の論点として個人的に気になるのは「監視者の能力を誰が評価するか」という問題だ。
AI Control Roadmapでは「攻撃を検知する能力がエージェントの能力を上回らなければならない」という原則が示されている。ではその評価をどうするか。監視側にもAIを使う場面が出てきたとき、その監視するAIもまた「潜在的にアラインメントが取れていない存在」のはずだ。
これは循環論法のように見えるが、実際のシステム設計では避けて通れない問いになる。「信頼できないものを監視するものも信頼できない」という問題をどう設計で解くか。Google DeepMindがそこをどう答えるのかは、今後の実装例と継続的な文書更新に注目したい。
まとめに代えて：これはシグナルだ
AI Control Roadmapを「Googleがセキュリティを頑張っている」という話として読むと、重要な部分が抜け落ちる。
これは「AIを信頼しない前提でシステムを設計することが、もはや先進企業では標準になりつつある」というシグナルだ。アラインメントへの投資を続けながら、それとは独立してシステム側で統制する設計を持つ——この二重構造が、今後のAIエージェント導入の「当たり前」になっていく可能性が高い。
次に同種のニュース——「我が社のAIエージェントは安全です」という発表——を見るときには、「アラインメントだけの話か、それともシステム設計側の統制も含まれているのか」を確認するとよい。その区別があるかどうかで、その発表の重みはかなり変わる。
