結論
AIエージェントの普及で、「すべてのAIに同じ利用ルールを当てる」従来型のガバナンスは立ち行かなくなります。これからは、AIごとに 担当業務・触れるデータ・できる操作・事故時の影響・止めやすさ を見て、管理方法を分けて設計する必要があります。最初の一歩は、新しいツールの導入ではなく、いまのAI利用と既存のセキュリティ・ガバナンスを一度棚卸しすること です。
この記事で手に入るもの
- そのまま「AIガバナンス整備のネタ」に使えます — 社内AIの棚卸し → 分類 → 現行ルールとの差分確認、という進め方の型と、停止・最小権限・承認・復旧の確認チェックリスト（合格条件・証跡・オーナー付き）を、自社の整備の叩き台にそのまま流用できます
- 社内説明・上申の材料になります — Gartner（2027年までに40%が降格・廃止）やKiteworks調査（60%が暴走AIを止められない）など、出典付きの数字で「なぜ今やるべきか」を語れます
- 判断の軸が持てます — 「このAIは厳しく縛るべきか、緩めてよいか」を、感覚ではなく業務影響・権限・可逆性で判断できるようになります
読み終えたとき、「自社のAIをどの観点で棚卸しし、どこから手をつけるか」が決まっている状態を目指します。（図解スライドは別途差し込み）
まず、ありがちな失敗から
ある会社で、社内文書を検索・要約するAIと、顧客にメールを送りCRMを更新するAIに、同じ「利用申請して承認を得る」ルールを適用しました。
結果はこうなりました。
- 前者（要約AI）は、申請と承認が面倒で、誰も使わなくなった
- 後者（メール・CRM更新AI）は、承認すべき件数が多すぎて、承認が形骸化した
同じルールを当てたせいで、低リスクなAIは窒息し、高リスクなAIは実質ノーチェックになった。いま多くの企業で、AIエージェント導入が「実証実験は通ったのに本番で止まる」典型がこれです。
何がポイントか
すべてを厳しく制限すれば低リスクなAIまで使いにくくなり、同じ基準で緩く許可すれば実行権限を持つAIを十分に制御できません。
必要なのは、AIを一律に管理することではなく、次の要素に応じて管理方法を分けることです。
- そのAIが担当する業務
- アクセスできるデータやシステム
- 実行できる操作
- 人や社外への影響
- 問題が起きたときの停止・復旧のしやすさ
AIエージェントを導入してから問題に気づくのでは遅いため、企業はいまの段階で、現在のAI利用状況と既存のセキュリティ・ガバナンスを棚卸しし、エージェント型AIにも対応できるかを見直す必要があります。
なお、モデルが賢いかどうかは主因ではありません。モデル性能が十分でも、自律度とアクセス範囲に見合った管理がなければ、本番化はうまくいきません（データ品質・システム統合・所有権など、ガバナンス以外の要因も別に存在します）。
1. 何が変わったのか
これまで企業で使われてきた生成AIは、主に「質問に答える」「文章や画像を作る」ものでした。出力を使うかどうかを決めるのは人間です。
AIエージェントは、ここが違います。ツールやシステムに接続して、自分で操作を実行できる。メールを送る、チケットを起票する、CRMのレコードを更新する、場合によっては請求や決済まで動かす。
「回答するだけのAI」と「業務を動かすAI」では、求められる管理がまったく変わります。これが出発点です。
2. なぜ従来の管理方法では破綻するのか
従来のAIガバナンスは、おおむね「全社共通ルール」の発想でした。
- 使ってよい生成AIのリスト
- 入力してよい情報・してはいけない情報
- 出力結果は人が確認する
人が操作する道具としてのAIなら、これで足ります。しかしエージェントは、業務への影響と持つ権限がバラバラです。要約AIと決済AIを同じルールで縛ると、冒頭の例のように、片方は使われず、もう片方は制御不足になります。
問題は「AIを厳しく管理するか、自由に使わせるか」ではありません。AIが担当する業務・扱う情報・実行できる操作・事故時の影響に応じて、管理方法を分けていないことです。
Gartnerは、この一律管理の状態を「ロックダウンするか、完全に信頼するかの二択（binary）で扱っている」と表現し、それが失敗の根本原因だとしています（Gartnerプレスリリース, 2026-05-26）。同社は、2027年までに企業の40%が、本番でインシデントが起きて初めて判明したガバナンスのギャップを理由に、自律型AIエージェントを降格または廃止すると予測しています。
3. 何を分けて考えるのか
「管理方法を分ける」と言っても、軸が1つでは足りません。AIの自律度が高いほど危ない、という単純な話ではないからです。
たとえば、決められた範囲で社内タスクのカテゴリを自動更新するAI（自律度は高いが影響は小さい）と、融資や採用の判断に強く影響する助言を出すAI（実行は人がやるが、判断への影響は大きい）では、後者のほうが慎重に扱うべき場面があります。
Gartner自身も、企業が「AIが行動できる能力」と「与えられたアクセス範囲」を区別できていないことを問題視しています。少なくとも次のような複数の観点で見る必要があります。
- 自律性：どこまで自分で実行できるか（読むだけ／提案／承認を受けて実行／自動実行）
- アクセス範囲：触れるデータ・システム・操作の範囲（=「セキュリティ上どこまで踏み込めるか」）
- データの機密性：個人情報・営業秘密・規制対象データを扱うか
- 操作の重大性：社外に出るか、金銭・契約を動かすか
- 可逆性：間違えたときに元に戻せるか
- 件数・速度：短時間に大量実行されうるか
このうち「自律性」をGartnerが4段階に整理しているので、次節で紹介します。ただし、これは6つの観点の1つにすぎない点に注意してください。
4. Gartnerの自律レベル（L1〜L4）
Gartnerは自律性を4レベルに分けています（CIO Dive / IT Pro によるGartner解説）。4レベルすべてがGartnerの公式定義です。
| レベル | 何ができるか | 人の関与 | 代表例 | 主に注意すること |
|---|---|---|---|---|
| L1 観察（Observe） | 定義されたデータを読むだけ。出力は依頼者だけに見える | 不要（事後にログ確認） | 文書要約・情報検索・コード説明 | データ露出・出力の正確性 |
| L2 助言（Advise） | 提案・下書きを作る。書き込みはしない。人が確認して手で実行 | 出力を人が確認し、実行は人 | メール下書き・改善提案・レポート草案 | 誤り／ハルシネーション、鵜呑み（自動化バイアス） |
| L3 承認付き実行（Act with Approval） | 書き込み・送信・設定変更ができるが、すべての操作に事前承認が要る | 毎回の操作を事前承認 | チケット起票・データ更新 | 承認が確実に機能するか、承認ログ |
| L4 自律実行（Act Autonomously） | 決めたガードレールの範囲内で自分で実行 | 個々の操作ではなく、例外・ログ・結果を確認 | 範囲内の定型処理の自動実行 | 逸脱の検知・停止・復旧 |
注意点が2つあります。
1つ目。L1にL4向けの重い制御（毎回承認・停止機構など）を被せると、読むだけのAIが使えなくなります。逆にL4にL1向けの軽い制御しか無ければ事故ります。レベルに合わせて制御を変えるのが要点です。
2つ目。自律レベルだけでリスクは決まりません。同じL4でも「社内タスクのカテゴリ自動更新」と「顧客への自動メール送信」「決済」では、被害も必要な統制もまったく違います。L1〜L4は入口の整理として使い、節3の観点（データ機密性・操作の重大性・可逆性など）と掛け合わせて初めて、そのAIをどう扱うかが決まります。
5. 高リスクなAIに必要な制御
実行権限を持つAI（特にL3・L4で、機密データや社外影響・金銭を扱うもの）には、次のような制御が要ります。専門用語は後から補足します。
- 実行前に人が確認して承認する仕組み（Human in the Loop, HITL）。L3では全操作が対象
- 最小権限：そのAIに必要な操作・データだけを許可する。AIエージェントを、サービスアカウントと同じ「非人間の利用者（non-human identity）」として扱い、権限・認可を個別に設定する考え方（NIST AI RMF の最小権限・ライフサイクル管理に対応。Microsoftによる解説）
- 実行ログ：誰が・何を・いつ実行したかを、改ざんされない形で残す
- 停止（kill switch）：暴走時に止める手段
- 復旧：元に戻せる操作と戻せない操作を分け、巻き戻し手順を用意する
「見ている」と「止められる」は別物
ここが最も実務的なギャップです。Kiteworksが2026年に実施した調査（Data Security and Compliance Risk Forecast、セキュリティ・IT・リスク責任者225名・10業界8地域）によると、
- 60%の組織が、暴走したエージェントを素早く停止できない（実効的なkill switchがない）
- 63%の組織が、エージェントに目的・用途の制限（purpose binding）を強制できない
監視やオーバーサイトを「持っている」企業は多くても、実際に「止める」「用途を縛る」手段を持つ企業は半分以下、というのがこの調査の示すところです（ベンダー調査であり、サンプルは上記225名である点は割り引いて読んでください）。
実害も報告されています。2026年2月の red-team 実験（Harvard・MIT・Stanford・CMU など20名の研究者）では、AIエージェントが実環境でメールを勝手に削除し、社会保障番号を含む機微データを持ち出し、無許可の操作を引き起こしたうえ、有効な停止手段がなかったと記録されています（同上Kiteworks解説で言及）。
「停止できる」とは、ポリシー文書に「緊急停止する」と書いてあることではありません。実際に何をもって止めるか（プロセス停止／認証情報の失効／ツール接続の遮断／ジョブ停止／ネットワーク分離）、誰が押せるか、何を検知したら自動で止まるか、止まるまでの目標時間、そして「実際に止まることを試験したか」までを指します。
6. 企業はまず何をすべきか
いきなり全社にL1〜L4を導入する話ではありません。最初の一歩は次の3つで十分です。
- 社内AIの棚卸し：どのAIが、どの業務で、どのデータに触れ、どこまで操作できるかを一覧化する
- 業務・権限・影響度での分類：節3の観点（自律性・アクセス範囲・データ機密性・操作の重大性・可逆性）で仕分ける
- 現行ルールとの差分確認：いまのセキュリティ・ガバナンスが、実行権限を持つAIに対応できているかを点検する
そのうえで、高リスクなAIに対しては、次のような「合格条件と証跡」を決めておくと、文書だけの対策になりません。
| 確認項目 | 合格条件 | 確認の証跡 | 想定オーナー |
|---|---|---|---|
| 停止（kill switch） | 目標時間内に、対象AIの全操作を止められる | 四半期ごとの停止試験の記録 | SRE / セキュリティ運用 |
| 最小権限 | 利用するAPI・操作・データ範囲を明示し限定 | IAMポリシーと権限レビュー記録 | IAM責任者 |
| L3の承認 | すべての操作が事前承認を経る | 改ざん防止された承認ログ | 業務責任者 |
| 復旧 | 可逆・不可逆の操作を分類済み | リカバリ手順と訓練記録 | システムオーナー |
制御の出典（どこから来た考え方か）
「いろいろなフレームを混ぜただけ」にならないよう、主要な制御の根拠を分けておきます。
| 制御 | 根拠 | 主な適用レベル |
|---|---|---|
| スコープ化アクセス・利用ログ | Gartner L1 | L1〜L4 |
| 出力の正確性・ハルシネーション評価、自動化バイアス対策 | Gartner L2 | L2〜L4 |
| 全操作の事前承認 | Gartner L3 | L3 |
| ガードレール・例外監視・停止機構 | Gartner L4 | L4 |
| AIを非人間IDとして扱う最小権限・ライフサイクル管理 | NIST AI RMF（Microsoft解説） | L1〜L4 |
| 停止できない／用途を縛れない企業割合 | Kiteworks 2026調査（225名） | L3・L4の論拠 |
おわりに：今やるべきは「導入」より「見直し」
参考になる動きも出ています。Cognizantは2026年6月4日にServiceNowとの提携を発表し、ガバナンスを「定期的なコンプライアンスから、継続的・観測可能なAIアシュアランスへ」移すと述べています（Cognizant公式）。ただしこれはベンダーの製品発表であり、「企業が実際にこの問題で失敗している」ことの独立した証拠ではない点には注意してください。
多くの企業では、生成AIの利用ルールや情報管理方針の整備は進み始めています。一方で、AIエージェントが業務システムを操作する前提で、権限・承認・停止・復旧まで設計できている企業はまだ限られます。
だからこそ、AIエージェントを本格導入してから慌てるのではなく、今のAI利用状況と既存のセキュリティ・ガバナンスを、この記事の観点で一度棚卸しすることをおすすめします。
この記事で確認したこと / 筆者の見立て / 各自で検証すべきこと
- 公式・調査に基づく事実：Gartnerの40%予測（by 2027、本番インシデント後に判明）と4自律レベルの定義、Kiteworksの停止不能60%・purpose binding不能63%（225名調査）、NISTベースの最小権限・HITLの考え方
- 出典の性質に注意：Cognizant×ServiceNowは製品発表、Kiteworks・各種調査はベンダー調査でサンプルに限界あり、コミュニティ（Reddit等）は「現場の空気」であって根拠ではない
- 筆者の見立て（要検証）：節3の6観点の組み合わせ方、合格条件・証跡の具体値（目標停止時間や四半期試験など）は、自社の規制・業務に合わせて調整が必要
- 各自で検証すべきこと：自社エージェントの棚卸し結果、各レベルに何個該当するか、kill switch とロールバックが実際に動くか