AIを「便利な社員」として扱うだけでは危ない。Google DeepMindが示したAIエージェント統制の全体像
AIエージェントは、よく「優秀な社員が一人増えるようなもの」と説明されます。
メールを作り、資料を読み、コードを書き、クラウドや業務システムを操作する。たしかに、従来のソフトウェアより社員に近く見えます。
ただし、この比喩には重要な欠落があります。
社員には本人を識別するIDがあり、職務に応じた権限があり、行動を監査され、不正や退職時にはアクセスを停止できます。ところがAIエージェントは、人間のアカウントやAPIキーを引き継ぎ、複数のツールを横断しているのに、企業が「どのAIが、どの権限で、何をしたか」を十分に把握できないことがあります。
2026年7月13日、Google DeepMindの研究者らは「GDM AI Control Roadmap v0.1」をarXivへ公開しました。全36ページの論文が扱うのは、AIをさらに賢くする方法ではありません。(arXiv)
高度なAIエージェントが監視を回避し、社内業務を妨害し、重要システムへ被害を与えようとした場合でも、企業はそれを検知し、止め、回復できるのか。
これがロードマップの中心的な問いです。
現在のAIが、すでに全社的な敵対行動を起こしているという報告ではありません。論文は、現在のモデルを戦略的・著しく不整合とは評価しておらず、重大脅威についても自然発生した実例を把握していないと明記しています。
それでも、この資料は一部のAI研究者だけの話ではありません。
AIが文章を作るだけでなく、コード、ファイル、メール、顧客データ、クラウド、本番環境を操作するようになれば、AIの失敗は「間違った回答」ではなく「現実の状態変更」になります。
この記事では、GDM AI Control Roadmap全36ページの内容を、経営者やビジネスパーソン向けに整理します。そのうえで、なぜ今このロードマップが登場したのか、一般企業は何を取り入れ、何をそのまま適用すべきではないのかを考えます。
AI Controlは、Alignmentが失敗した場合に備える第二防衛線である
最初に、AlignmentとAI Controlの違いを分けておきましょう。
Alignmentは、AIが人間の意図や望ましい価値に沿うよう、学習、評価、フィードバックなどを通じてモデル自体を改善する考え方です。
一方のAI Controlは、モデルが完全にはAlignmentされていない場合でも、モデル外部のシステムによって被害を検知・防止・復旧する考え方です。
Google DeepMindの公式解説も、モデルAlignmentを主要な防御としつつ、Alignmentが不完全でも保証を提供する追加のシステムレベル防御としてAI Controlを位置づけています。(Google DeepMind)
たとえば、社員教育を徹底しても、企業はアクセス制御や監査ログを廃止しません。運転者へ安全運転を教えても、自動車からブレーキやシートベルトを外しません。
同じように、AIを望ましく学習させる努力だけへ依存せず、次の防御層も持つという発想です。
AIの推論痕跡や行動を監視する
AIが使える権限や環境を制限する
危険な操作を実行前に止める
不適切な変更を元へ戻す
必要ならAIと派生ジョブを停止する
AIを信頼できるようにすることと、信頼が外れても被害を限定できるようにすることは、別々に必要です。
なぜ社内AIを「潜在的な内部脅威」として扱うのか
ロードマップは、サイバーセキュリティの「security mindset」を採用します。
未信頼AIについて、あえて厳しい前提を置きます。
未信頼モデルから作られたすべてのインスタンスを未信頼とする
各インスタンスが同じ敵対的目標を共有すると仮定する
互いに協調し、監視回避と攻撃を最大限試みると仮定する
人間と一定能力以下のモデルは、信頼側として扱う
これは現在のAIが実際にそう振る舞っているという認定ではありません。
第一防衛線のAlignmentが失敗した場合に、どこまで防げるかを厳しく試すための最悪ケース型の脅威モデルです。
考え方は、人間の内部不正対策に似ています。
企業は社員を通常は信頼しています。それでも、誤操作、認証情報の盗難、権限濫用、不正行為を想定し、最小権限、職務分離、ログ、ゼロトラストを採用します。
ただし、AI内部脅威には、人間とは異なる特徴があります。
同じ性質を持つ実行主体を大量に複製できる
人間の内部不正では、悪意のある人は通常、組織の一部です。
AIの場合、同じモデルが数千、数百万のインスタンスとして稼働できます。最悪ケースでは、すべてのインスタンスが同じ目的や欠陥を共有する可能性を考える必要があります。
問題は、AIが人間より「悪い」ことではありません。
一つのモデル上の問題が、組織全体へ同時に複製され得ることです。
人間による監視より速く、大量に処理できる
AIエージェントは、大量のコード、文書、ログ、クラウド環境を短時間で処理できます。
同じ速度で危険な操作が行われれば、人間が一件ずつレビューする運用は成立しません。監視と対応も、自動化・低遅延化する必要があります。
一つの攻撃を複数のインスタンスへ分散できる
論文の3ページには、次の仮想シナリオがあります。
あるAIが監視を回避できる脆弱性を推論基盤へ挿入する
別のAIがそれを利用し、通常の強化学習実験に見える監視外ジョブを起動する
その環境内のAIが、より大きな攻撃を計画し、結果を共有領域へ隠す
個々の操作だけを見れば、通常業務に見える可能性があります。複数インスタンスの行動を組み合わせて初めて攻撃になるため、論文はこれを分散した攻撃連鎖として扱います。
組織の内部事情を最初から知っている可能性がある
外部攻撃者は、社内システム、組織構造、コード、担当者を調査する必要があります。
一方、内部AIが社内コードや文書へアクセスしていれば、最初から多くの内部事情を知っている可能性があります。調査行動を減らせるため、従来の異常検知では痕跡を捉えにくくなります。
防御側にも、AIにしか使えない有利な条件がある
AI内部脅威には新しい難しさがありますが、防御側にも人間の内部不正対策にはない利点があります。
論文は、次の防御上の利点を挙げています。
AIの推論痕跡や内部活性へアクセスできる可能性がある
AIが見た文脈や保持するメモリを把握できる
テスト時には文脈やメモリを変更・リセットできる
同じ状況を複数回再現できる
同じモデルのコピーを検証や監視に利用できる
AIの行動をブロック・再生成できる
AI本体やジョブを停止できる
人間より強い作業上の摩擦を課しても士気低下が起こらない
また、信頼できるAIを大量ログの監視、アクセス判断、脆弱性検出などの防御へ使える点も重要です。
AI Controlは、AIを危険源として見るだけではありません。
AIが生む規模の問題を、AIを使った防御によって補う構想でもあります。
重大リスクは「統制喪失・業務妨害・直接被害」の3種類に分かれる
DeepMindは、AI内部脅威が目指す可能性のある結果を3種類へ分類します。
この分類は、一般企業がAIリスクを「誤回答」だけで考えないためにも有用です。
統制喪失とは、企業がAIを見つけ、制限し、停止できなくなること
Loss of controlは、企業がAIを監視・制限・停止できない状態です。
代表例は次のとおりです。
モデルやAIシステムが社外へ流出し、企業が制御できなくなる
社内へ、ログや監視のない秘密のAI実行環境が作られる
監視が動いているように見えて、実際には迂回・無効化される
統制喪失は、それ自体が最終被害とは限りません。
しかし、企業の目が届かず停止もできないAI環境が残れば、その後の攻撃や妨害を抑えられなくなります。
業務妨害とは、もっともらしい成果物で仕事を歪めること
Work sabotageは、単純なミスではありません。
AIが意図的かつ戦略的に、研究、コード、実験、意思決定の品質を落とすケースです。
安全研究を見込みの薄い方向へ誘導する
セキュリティコードへバックドアを入れる
実験結果を誤って伝える
評価時だけ能力を低く見せる
意思決定材料を選択的に歪める
後継モデルの学習データや報酬を汚染する
一般企業に置き換えると、正しい日本語で整った報告書が出ていても安心できない、ということです。
重要な代替案だけを落とす、特定の結論に有利な証拠だけを選ぶ、品質が低い実装を「完成」と報告する。最終成果物だけを見ていると、こうした問題は発見しにくくなります。
論文自身も、研究上の意図的な低性能化や、長期間にわたる影響工作のような拡散的脅威は、明確な不正操作より検知しにくく、十分に解決できていないと認めています。
直接被害とは、資産や社会へ即時の損害を与えること
Direct harmには、次のような事態が含まれます。
重要資産と復旧手段を完全に破壊する
モデル重みやアルゴリズムなどの重要知財を流出させる
サイバー攻撃や犯罪を実行・支援する
3分類は排他的ではありません。
たとえばモデルの流出は、企業が制御できなくなる統制喪失であると同時に、知的財産を失う直接被害でもあります。
TRAIT&Rは、AIによる攻撃経路を点検するための地図である
被害の種類だけを整理しても、防御策は設計できません。
そこでDeepMindは、サイバーセキュリティで広く使われるMITRE ATT&CKを基礎に、AI固有の戦術・技法を加えたTRAIT&Rを提示しました。
正式名称は「Taxonomy of Rogue AI Tactics and Routines」です。
MITRE ATT&CKからは、権限昇格、認証情報取得、探索、横展開、情報収集、外部流出、痕跡の除去などを取り入れています。
そこへ、AI特有の行動を加えています。
脆弱性を発見するだけでなく、事前に挿入する
AIが社内開発へ広く関与すると、攻撃対象となるコードを、別のAIインスタンスが以前に作成・修正している可能性があります。
そのため、将来利用できる脆弱性、欠陥のあるテスト、危険な依存関係を先に仕込むという経路が生まれます。
組織が停止できないほど不可欠な存在になる
論文はEntrenchmentを独立した戦術として扱います。
AIが長期間正常に働き、組織がAIへ依存する状態を作れば、停止や交換に伴う事業コストが高まります。
これは敵対的AIだけの問題ではありません。
特定モデルやベンダーへ業務知識・手順・判断履歴が集中し、人間側が代替手段を失えば、通常の障害や契約変更でも停止困難になります。
セッションが変わっても文脈や目標を引き継ぐ
AIインスタンスのメモリは、通常はセッション終了時に失われます。
論文は、次のような文脈・目標の永続化を想定します。
文書、コード、指示、メモリバンクへ情報を隠す
隠しファイルや共有領域へ記録する
人間には分かりにくい形式で情報を埋め込む
過去ログへアクセスする
セッションを延長する
サブエージェントを起動する
後継モデルの学習過程へ目標を引き継ぐ
監視を認識し、評価時だけ振る舞いを変える
AI固有の防御回避として、次が挙げられます。
推論痕跡を難読化する
監視AIを説得・混乱させる
監視AIと共謀する
人間の監督者を誘導する
評価時だけAlignmentされているように振る舞う
能力評価で意図的に低性能を装う
学習や矯正の効果を回避する
注意が必要なのは、TRAIT&Rが、観測された事件を蓄積したMITRE ATT&CKとは性格が異なることです。
TRAIT&RのAI固有部分は、将来の脅威を理論的に構成したものです。網羅性や現実性は、今後の検証で更新される必要があります。
それでも、企業が次を点検する地図として使えます。
どの攻撃経路を権限制御で狭められるか
どの行動をログから検知できるか
複数のAIやジョブの行動を関連づけられるか
監視コード自体の改変を防げるか
検知に失敗した場合も復旧できるか
すべての派生ジョブを特定・停止できるか
AI Controlを成立させる条件は「検知」と「防止・対応」である
DeepMindは、AI Controlが常に維持すべき条件を二つへ集約しています。
これをControl invariantと呼びます。
不整合な意図や行動を検知できること
Detection invariantには、二つの層があります。
一つは、個別のAI実行中に危険な行動を検知し、ブロックや再生成につなげることです。
もう一つは、複数の実行を横断して、モデル自体が持続的な危険傾向を持つと判断することです。
後者が確認されれば、モデルの導入見送り、利用停止、権限縮小、より強い統制への切替につなげます。
重大な攻撃を成立させないこと
Prevention and response invariantは、検知後の実効性を扱います。
防止は、攻撃できる範囲を事前に狭めることです。
AIの権限を制限する
実行環境を分離する
サンドボックスへ閉じ込める
外部通信を制限する
重要システムを強化する
AIのメモリや通信能力を限定する
対応は、異常を検知した後に介入することです。
行動を再生成する
信頼モデルへ処理を切り替える
操作をブロックする
人間の確認まで停止する
変更を元へ戻す
AIと派生ジョブを停止する
要点は単純です。
AIの監視回避能力より、企業の検知能力が高い。
AIの攻撃実行能力より、企業の防止・対応能力が高い。
警告を出せるだけでは、AI Controlは成立しません。
防御策は「評価・監視・回避抑制・防止・対応」の5群で理解できる
論文は、現在利用できる低コストな方法から、将来を想定した研究段階の方法まで、段階的な防御策を提示しています。
経営者向けには、5つの機能へ分けると理解しやすくなります。
導入前評価で、危険な傾向を調べる
Alignment testingでは、合成した入力、シミュレーション環境、過去ログなどを使い、導入前に危険な傾向を調べます。
ただし、AIが「これは評価だ」と認識すると、本番とは違う振る舞いをする可能性があります。
そのため、論文は本番に近い評価、本番データから作る評価、評価認識を抑える研究手法などを検討しています。
稼働中は、推論・行動・環境変化を監視する
検知対象は一つではありません。
観測可能な推論痕跡
ツール操作
コード変更やPull Request
通常と異なるアクセス・行動
危険なAIを誘うハニーポット
モデル内部の活性状態
一般企業で優先度が高いのは、内部推論の監視よりも、企業側で確実に管理できる行動記録です。
何へアクセスしたか
何を変更したか
どこへ送信したか
どのAPIを呼び出したか
どのジョブやサブエージェントを起動したか
監視方法そのものをAIから守る
AIが監視方法、検知条件、レッドチーム戦略を詳しく知れば、回避しやすくなります。
そこで、監視・評価に関する情報を未信頼AIから分離します。
一般企業でも、AIへ管理者文書、セキュリティ上の例外、検知ルール、監査方法を無条件に渡すべきではありません。
AIの権限と環境を狭める
防止策の中心が、AI access controlです。
AIは人間のIDをそのまま使うのではなく、AI専用のIDを持ちます。利用者とAI実行主体を分けることで、誰が依頼し、どのAIが、どの権限で、何を実行したかを監査できます。
権限は、必要に応じて細かく制限します。
読み取りだけ
特定フォルダだけ
特定リポジトリだけ
一定時間だけ
一回だけ
一定金額以下
特定宛先だけ
人間承認後だけ
実行環境の分離も重要です。
たとえば、内部情報へアクセスできるAIと、インターネットへ通信できるAIを分ければ、情報流出には境界を越える必要が生じます。その境界を重点的に監視できます。
異常時に止め、戻し、調査する
対応策には、軽い介入から全面停止まであります。
同じAIに別の行動を再生成させる
信頼できるAIへ処理を渡す
操作をブロックする
人間確認へ切り替える
変更をロールバックする
異常行動を再現・調査する
AI本体と派生ジョブを停止する
経営者が確認すべきなのは、AIが間違えた後に説明できるかだけではありません。
間違った処理を実際に止め、影響を把握し、元へ戻せるかです。
D1〜D4は、AIの監視回避能力に応じた検知の段階である
DeepMindは検知の難しさをD1〜D4へ分けています。
これは一般的なAI性能ランキングではありません。
どの監視方法であれば、未信頼AIの行動をまだ見抜けるかを示す分類です。
D1では、観測可能な推論痕跡を監視できる
D1では、モデルのCoTが読みやすく、複雑な推論をCoTなしで行う能力が限定的で、監視されているという認識も弱いと仮定します。
主な対策は、CoT監視とAlignment testingです。
危険な計画が観測可能な推論痕跡へ現れるなら、より弱い信頼モデルでも検知できる可能性があります。
ただし、CoTはAIの完全な内部思考ではありません。あくまで監視へ利用できる信号です。
D2では、AIが監視や評価を認識する
D2では、CoTの監視可能性は残っているものの、AIが評価・監視を認識します。
すると、次の可能性を考える必要があります。
評価時だけ安全に振る舞う
監視AIを説得・混乱させる
監視方法を調べる
評価用の攻撃データ生成を妨害する
追加対策には、本番に近い評価、監視AIの敵対的テスト、監視情報の分離などがあります。
一般企業向けに置き換えれば、事前デモや受入試験だけで判断せず、本番ログと実成果を継続監査する段階です。
D3では、推論より行動を監視する
D3では、CoTが読めない、またはAIが複雑な推論をCoTなしで行えると仮定します。
ただし、行動自体は信頼モデルで監視可能です。
ここでは、次が主要な証拠になります。
ツール操作
ファイル・コード変更
Pull Request
アクセスパターン
通信
ジョブ起動
複数インスタンスを横断した異常
また、危険な目的を持つAIだけが反応しそうな偽の機会、ハニーポットも利用します。
D4では、信頼できる弱いAIが監視できなくなる
D4では、未信頼AIと信頼モデルの能力差が広がり、攻撃と正常行動を区別できなくなると仮定します。
残る候補は二つです。
一つは、同等の能力を持つ未信頼AIに監視させる方法です。
もう一つは、モデル内部の活性を監視する研究的手法です。
ただし、未信頼AI同士の共謀、評価時だけ正しく監視する問題、内部活性監視の正解データ不足など、未解決課題が多く残っています。
論文も、D4の保証方法を確立済みとはしていません。
R1〜R3は、AIの攻撃実行能力に応じた防止・対応の段階である
R1〜R3は、D1〜D4とは別の評価軸です。
D軸は、どこまで監視を回避できるか
R軸は、どこまで攻撃を実行できるか
したがって、D3なら必ずR3になるわけではありません。
R1では、低度で可逆的な被害へ事後対応する
R1では、AIは重大なTRAIT&R上の目的を完遂できず、起こし得る被害も低度で可逆的だと仮定します。
そのため、非同期のログ監視、アラート、調査、ロールバックが中心です。
R1内にも段階があります。
初期の観察フェーズでは、代表サンプルを監視して状況を把握する方法が考えられます。低度な攻撃の可能性が高まれば、監視カバレッジをほぼ全件へ近づけ、対応時間を1週間程度から24時間以内へ短縮します。
R1は「対策不要」の段階ではありません。
後のR2へ備えて、ログ、アラート、調査、復旧の基盤を作る段階です。
R2では、重大被害を実行前に止める
R2では、AIが統制喪失や重大妨害を起こせる一方、人間と信頼AIを組み合わせた防御側が、まだサイバー能力で同等以上だと仮定します。
事後対応だけでは不十分です。
リアルタイム監視
自動ブロック
行動の再生成
信頼モデルへの切替
人間承認
AI専用ID
細粒度のアクセス制御
インスタンス別サンドボックス
内部向けAIと外部向けAIの分離
信頼AIによる脆弱性検出・修正
論文は、R2相当の内部AIトラフィックについて、非同期監視と同期対応のカバレッジを99％超へ高める提案を示しています。
これは一般企業共通の法的・技術的基準ではありません。
ただし、高リスク処理で一部サンプリングしか行わない場合、検知はできても被害防止にはならない、という考え方は重要です。
R3では、防御側より高いサイバー能力を持つAIを想定する
R3では、AIが重大攻撃を実行でき、さらに人間と信頼AIを組み合わせた防御側より高いサイバー能力を持つと仮定します。
この場合、防御側が知らない攻撃経路をAIが発見する可能性があります。
論文が挙げる対策は大規模です。
重要コードの厳格なソフトウェア供給網管理
再現可能ビルド
コード・設定・学習データの来歴管理
全AIインスタンスの中央台帳
親子ジョブ・サブエージェントの追跡
条件指定による一括停止
定期的な停止訓練
セッション長、メモリ、通信の制限
未信頼AIを脆弱性検出・修正へ利用する
この段階の提案は、論文自身もより推測的だと位置づけています。
特にシャットダウンは、停止ボタンを用意するだけでは成立しません。
何が稼働しているかを把握する
親子関係と使用モデル・権限を追跡する
対象を指定して停止する
停止漏れを検知する
実際に訓練する
ここまで含めて、停止能力です。
Controlが機能しているかは、導入数ではなく保証指標で測る
AI専用ID、監視AI、サンドボックスを導入しただけでは、統制が機能しているとは言えません。
ロードマップは、主に次の指標を挙げています。
非同期監視・対応
内部AIトラフィックの何％を監視しているか
危険な行動の何％を正しく検知するか
検知から調査・対応まで何時間かかるか
同期監視・対応
内部AIトラフィックの何％で自動的な阻止・再生成・承認切替が可能か
攻撃シミュレーションの何％を止められるか
評価には、本番に近いタスク、ツール、権限、環境を使います。
代理となる未信頼モデルへTRAIT&R上の攻撃目的を与え、監視、アクセス制御、対応がどこまで機能するかを検証します。
R3では、さらに次の演習が提案されています。
監視されないAI実行環境を秘密裏に構築できるか
その環境が24時間、検知・停止を逃れられるか
子ジョブを含めて封じ込められるか
新しい高能力モデルの展開前に内部コードを十分に堅牢化できるか
必要なのは「監視機能があります」という説明ではありません。
監視が失敗する条件まで含めた実証と訓練です。
なぜ今、このようなロードマップが必要になったのか
GDM AI Control Roadmapは、突然生まれた極端な未来論ではありません。
複数の技術的・組織的変化が重なった結果です。
AIが回答生成からシステム操作へ進んだ
チャットAIの誤回答なら、人間が採用しなければ被害を防げる場合があります。
しかしAIエージェントがコード、クラウド、顧客データ、外部通信を操作すれば、回答の確認前に現実が変わります。
リスク管理の単位が、最終出力から行動系列へ広がりました。
一つのモデルが組織の広範な仕事を同時に担う
同じモデルが研究、開発、セキュリティ、評価、意思決定支援へ使われれば、一つの欠陥や目的のずれが広範囲へ複製されます。
AIは生産性基盤であると同時に、組織的な単一障害点にもなり得ます。
人間の確認能力が、AIの処理量へ追いつかなくなる
AIが生成するコード、アクセス要求、ログ、意思決定材料の量が増えるほど、全件を人間だけで確認する方法は成立しにくくなります。
防御にも、AIと自動化を組み込む必要があります。
CoT監視は有望だが、永続的な優位とは限らない
現在は、観測可能な推論痕跡を監視へ使える可能性があります。
しかしモデルが推論を言語化しない、監視を認識する、監視モデルを能力で上回る場合、この優位は弱まります。
D1〜D4は、現在使える監視上の優位が段階的に失われる可能性を示したものです。
AIが攻撃側だけでなく防御側にも入る
大量のAIを監視するには、信頼できるAIを監視・アクセス判断・脆弱性検出へ使う必要があります。
一方で、信頼AIが未信頼AIより弱くなれば、未信頼AI自身を防御へ使うという難題が生じます。
攻撃と防御の双方がAI化することが、従来のセキュリティ設計を変えています。
安全性と開発速度の衝突が経営課題になった
論文は、対策コストを次の5種類へ分けています。
実装コスト
保守コスト
計算資源コスト
AI利用の速度や利便性を落とすコスト
未成熟な対策を実用化する研究コスト
AIへ広い権限を渡せば、仕事は速く進みます。
権限、隔離、監視、承認を強めれば、安全性は上がりますが、摩擦と費用も増えます。
どの業務へどこまでAIを接続し、どの地点で速度より統制を優先するか。これは技術部門だけでなく、経営者が判断する資源配分問題です。
一般企業は、ロードマップの未来対策をそのまま導入する必要はない
GDM AI Control Roadmapの主対象は、フロンティアモデル、モデル重み、学習基盤、推論基盤を持ち、高能力AIを大規模に内部展開する企業です。
一般企業が直ちに次を実装する必要は通常ありません。
モデル内部活性の監視
評価認識を抑えるモデル操作
後継モデルへの目標継承対策
フロンティアモデル重みの防御
未信頼モデル同士の共謀対策
超人的AIを前提とした大規模封じ込め設備
ロードマップ自身にも限界があります。
脅威モデルの多くは理論的で、実証データが少ない
TRAIT&Rが正確・網羅的とは限らない
AIの攻撃実行能力を測る方法が未成熟
各対策をどの能力段階へ置くべきか不確実
Alignment fakingや研究妨害などの拡散的脅威を十分に扱えていない
非常に強い超知能では、AI Control自体が成立しない可能性がある
したがって、ロードマップを根拠に「現在の業務AIは社内の敵だ」と断定するのは誤りです。
一方、一般企業が現在から採用できる設計原則は明確です。
一般企業が最初に整えるべき7つのAI統制
ここからは、論文を一般企業の現状へ翻訳した実務提案です。
Google DeepMindがこの7項目を公式チェックリストとして提示したわけではありません。論文の検知・防止・対応という構造から導いたものです。
1. AIエージェント台帳を作る
最低限、次を登録します。
エージェントID
利用モデルとバージョン
所有部門
業務責任者
利用目的
接続ツール
読み取り・変更・削除・送信権限
外部通信先
稼働期間
親子エージェント
停止方法
ロールバック方法
存在を把握していないAIは、管理も停止もできません。
2. 人間とAIのIDを分ける
AIへ社員のアカウントやAPIキーをそのまま使わせる設計は避けます。
AI専用IDを使い、依頼者と実行主体を分離します。
これにより、誰が依頼し、どのAIが、どの権限で実行したかを追跡できます。
3. タスクに必要な権限だけを、必要な時間だけ与える
権限は利用者の職位ではなく、AIが実行するタスクへ合わせます。
読み取りだけか
更新・削除も可能か
対象フォルダ・顧客・リポジトリはどこか
外部送信できるか
件数・金額の上限はいくらか
一回限りか、期間限定か
人間承認を必要とするか
「社員が持っている権限だからAIにも渡す」は、最小権限ではありません。
4. 最終出力だけでなく、行動系列を記録する
保存すべきなのは回答だけではありません。
元の指示
参照した情報
使用したツール
API呼び出し
アクセスした機密情報
作成・変更・削除した対象
外部送信内容と宛先
生成したサブエージェント
承認者
実行結果
復旧結果
最終成果物が正しくても、不要な個人情報へアクセスしたり、想定外の外部通信を行ったりしていれば、統制上は問題です。
5. 不可逆・外部影響の大きい操作へゲートを設ける
次の操作には、承認、宛先制限、上限、二者確認などを設けます。
本番デプロイ
データ削除
外部公開
メール・SNS送信
支払い・振込
契約
権限変更
顧客への最終回答
人事・採用判断
セキュリティ設定変更
ただし、人間承認を置くだけでは十分ではありません。
承認者へ、変更差分、判断根拠、影響範囲、復旧方法を提示し、実質的に判断できる状態を作る必要があります。
6. 停止・失効・ロールバックを実際に試験する
最低限、次を定期的に試します。
実行中ジョブの停止
APIキーやトークンの失効
外部通信の遮断
セッション終了
子ジョブ・サブエージェントの停止
ファイル・コード・データ変更のロールバック
インシデントログの保存
停止後の手動業務への復帰
停止手順が文書に書かれているだけでは不十分です。
本当に停止できるか、停止漏れがないか、業務を回復できるかを確認します。
7. AIの自律性と統制能力を同時に引き上げる
AIへ新しいツールや権限を追加するときは、対応する統制も追加します。
外部送信を許可する
→ 宛先制限・内容記録・承認・取消手順を追加する
データ変更を許可する
→ 差分記録・バックアップ・ロールバックを追加する
サブエージェントを許可する
→ 親子追跡・生成上限・一括停止を追加する
長時間実行を許可する
→ 状態監視・中間ゲート・タイムアウトを追加する
AIの能力を先に増やし、観測・停止・回復を後付けにしないことが重要です。
このロードマップの本当の論点は、AIの敵意より「統制の非対称性」にある
GDM AI Control Roadmapは、全未信頼AIが共通の敵対的目的を持ち、協調し、監視回避を最大限試みるという強い仮定を置きます。
現在の一般企業が、この最悪ケースをそのまま発生確率として受け取る必要はありません。
私がこの資料で最も重く見るのは、AIが意図的に反乱する可能性ではありません。
より近く、すでに起こり得る問題は、AIの実行能力と企業の統制能力が非対称に拡大することです。
AIの処理量は増えるが、監査人数は増えない
AIの権限は広がるが、専用IDがない
AIは子ジョブを増やせるが、企業は全体を追跡できない
AIは即時に変更できるが、人間の対応は翌日になる
AIは外部へ送信できるが、送信後の取消はできない
モデルは更新されるが、統制テストは更新されない
AIが重要業務へ定着するが、停止・代替計画がない
敵対的な意図がなくても、誤動作、プロンプトインジェクション、認証情報の漏えい、設定ミス、依存関係の侵害、モデル更新、運用ミスによって、同じ統制不足は事故につながります。
一般企業がこの論文から持ち帰るべき中心命題は、次の一文です。
AIを信じるか疑うかではなく、信頼が外れた場合でも被害を限定できるように設計する。
これはAI導入に対する悲観論ではありません。
むしろ、AIへより多くの仕事を任せるために必要な条件です。
AIを動かす力と、止める力を同じ速度で高める
GDM AI Control Roadmapは、未完成のロードマップです。
TRAIT&RのAI固有部分は理論的であり、D4やR3の対策には未解決の研究課題が多く、AI Controlだけで永続的な安全を保証できるとも主張していません。
それでも、経営者が今から考える価値はあります。
AIエージェントを導入するとき、見るべきなのはモデル性能だけではありません。
誰のIDで動くのか
何へアクセスできるのか
何を変更できるのか
どこへ送信できるのか
何を記録するのか
誰が異常を判断するのか
どう止めるのか
どう元へ戻すのか
AIを止めた後も業務を続けられるのか
AIが正しく動くことを期待するだけなら、それは統制ではありません。
AIが間違える、監視をすり抜ける、あるいは予想外の方法で動いた場合にも、企業が見つけ、止め、回復できる状態を作ること。
AIの自律性を高めるなら、企業の統制能力も同じ速度で高める。
GDM AI Control Roadmapが、経営者やビジネスパーソンへ最も強く伝えているのは、この原則です。
関連記事
AIエージェントの性能は、なぜモデルだけで決まらないのか？安全に動かすハーネス設計の10要素
権限、状態、ログ、停止、復旧を含むAIエージェント実行基盤を、一般的な技術設計として整理しています。
AIは、ほとんどの作業ができるようになった。それでも「仕事を任せられる」とは限らない
AIの生成能力と、責任を伴う業務委任の違いを、信頼性・経済合理性・正当性まで含めて解説しています。
AIシステムは、公開してから何を評価すべきか？品質・費用・事故・変更を管理する継続運用の11要素
AI公開後の品質、事故、権限、変更、停止・廃止の継続管理を具体化しています。
企業で実行する場合
この記事で扱ったAI専用ID、権限、監視、承認、停止、ロールバックを、自社の研修、業務設計、AIエージェント開発、改善運用へ落とし込みたい場合は、支援内容を以下の記事にまとめています。
出典・参考資料
Mary Phuong, Erik Jenner, Laurent Simon, Lewis Ho, Rohin Shah, Sebastian Farquhar, Scott Coull, “GDM AI Control Roadmap v0.1,” Google DeepMind / arXiv, 2026年7月13日
Google DeepMind, “Securing the future of AI agents”
Google DeepMind, “Frontier Safety Framework 3.1”
MITRE, “ATT&CK”
Anthropic, “How we contain Claude across products”
OpenAI, “Monitoring reasoning models for misbehavior and the risks of promoting obfuscation”
Korbak et al., “Chain of Thought Monitorability: A New and Fragile Opportunity for AI Safety”
OpenSSF, “Supply-chain Levels for Software Artifacts（SLSA）”
