生成AIは実験段階を終え、いまやメール送信やコードデプロイ、決済処理まで自律的に実行する「AIエージェント」の時代に入りました。便利さの裏で、企業のSaaS環境には把握されていないAIツールやエージェントが増殖し、見えない権限リスクが拡大しています。

従業員の過半数がセキュリティ部門を介さずにSaaSを導入しているという報告や、非人間IDの管理不全、OAuthトークンを悪用した同意フィッシングの急増など、脅威はすでに現実のものです。リスクは「情報漏えい」から「権限の自律行使」へと質的に変化しています。

本記事では、OWASP Top 10 for LLM ApplicationsやEU AI法、NIST AI RMFなどの最新フレームワークを踏まえながら、SaaS権限の棚卸しと「連携最小化（Least Privilege Integration）」を軸にした実践的な対策を体系化します。AIを止めるのではなく、安全に活用するための具体策を、セキュリティ担当者とAI専門家の視点で解説します。

Shadow AIからShadow Agentへ：脅威モデルの根本的シフト

2026年、企業セキュリティの前提は大きく書き換えられています。かつて問題視されていたのは「Shadow IT」、そして生成AIの普及により「Shadow AI」でした。しかし現在、脅威の中心は「Shadow Agent（無許可の自律型AIエージェント）」へと移行しています。

この変化は単なる用語の違いではありません。リスクの質そのものが、「情報の流出」から「権限の自律的行使」へとシフトしているのです。

区分 主な対象 リスクの本質
Shadow IT 未承認SaaS データ分散・管理不備
Shadow AI 未承認AIツール 機密情報の入力・漏洩
Shadow Agent 自律型AIエージェント 権限の自動実行・破壊的操作

Shadow AIの時代、最大の懸念は従業員がChatGPTなどに機密情報を貼り付けることでした。実際、Cloud Security Allianceの2025-2026年レポートによれば、従業員の約55％がセキュリティ部門を通さずSaaSを導入しているとされています。

しかし現在の問題はそれにとどまりません。自律型AIエージェントは、ユーザーの代理としてメール送信、ファイル編集、コードデプロイ、さらには決済処理まで実行します。つまり、AIが「読む」だけでなく「行動する主体」になったのです。

OWASP Top 10 for LLM Applications 2025でも「Excessive Agency（過剰なエージェンシー）」が主要リスクとして挙げられています。これは、AIに与えた広範なOAuth権限が、誤作動やプロンプトインジェクションを通じて自律的に行使される危険性を指します。

さらにPalo Alto Networksの予測では、2026年にはインサイダー脅威の主体が人間からAIエージェントへと移行するとされています。AIは24時間稼働し、人間を超える速度で操作を実行できます。

Shadow Agentの本質は「見えない従業員が、常時フル権限で働いている状態」です。

加えて深刻なのが非人間ID（NHI）の管理不全です。CSAによれば、46％の組織がNHIを十分に監視できていません。退職者が作成したエージェントが権限を保持したまま残存する「ゾンビエージェント」も現実の問題になっています。

ここで重要なのは、防御モデルそのものを再設計する必要があるという点です。従来のDLPや境界防御は「データの外部流出」を前提に設計されていました。しかしShadow Agentは、正規の認証情報を用いて内部で正当に振る舞います。

もはや問題は「誰がアクセスしたか」ではなく、「AIが何を実行したか」です。この視点の転換こそが、2026年のセキュリティ戦略の出発点になります。

データ漏えいから「権限の自律行使」へ：Excessive Agencyの本質

データ漏えいから「権限の自律行使」へ：Excessive Agencyの本質 のイメージ

2024年から2025年にかけての主な懸念は、従業員が生成AIに機密情報を入力してしまう「データ漏えい」でした。しかし2026年、リスクの本質は大きく変わっています。問題の中心は「情報が外に出ること」から、「AIが権限を使って何をしてしまうか」へと移行しました。

OWASPが公表しているLLMアプリケーション向けリスク一覧の2025年版では、「LLM06: Excessive Agency（過剰なエージェンシー）」が重要項目として明示されています。これは、AIに本来必要以上の機能や権限、自律性を与えてしまうことで発生する脆弱性を指します。

Excessive Agencyとは、AIが“情報を知る”だけでなく、“自律的に実行する”状態を過剰に許してしまうことによるリスクです。

従来のチャットボットは受動的でした。質問に答えるだけで、外部システムを変更することはありませんでした。しかし自律型エージェントは、OAuthトークンを通じてSaaSに接続し、メール送信、ファイル削除、コードのデプロイまで実行できます。ここに質的な断絶があります。

観点 データ漏えい中心の時代 Excessive Agencyの時代
主な懸念 機密情報の外部流出 AIによる自律的な操作実行
被害の性質 静的（情報のコピー） 動的（削除・改ざん・送信）
対策の中心 DLP・入力制限 権限設計・行動制御

たとえば、メール整理を任されたAIエージェントがプロンプトインジェクションを受け、「重要メールを削除せよ」という隠れた命令を正規の指示と誤認した場合、削除権限があれば即座に実行されます。これは単なる情報漏えいではなく、業務そのものの破壊です。

Palo Alto Networksの2026年予測でも、インサイダー脅威の主体が人間からAIエージェントへ移行する可能性が指摘されています。AIは24時間稼働し、人間より高速にAPIを叩き続けます。誤った判断がミリ秒単位で全社規模の影響に拡大するのが、Excessive Agencyの本質です。

さらに深刻なのは、「正規の権限を使っている」点です。攻撃や誤動作が発生しても、ログ上は合法的なトークンによるアクセスに見えます。従来の境界防御やDLPでは検知が困難になります。

つまり、2026年のAIリスクは「漏らさない」設計だけでは不十分です。AIに何をさせるのか、どこまで任せるのかを厳密に定義しない限り、便利さがそのまま破壊力に転化します。 Excessive Agencyとは、AIの自律性と権限設計が交差する地点で生まれる、構造的なリスクなのです。

SaaSサプライチェーンの盲点：OAuthトークンと同意フィッシングの高度化

多くの企業が見落としているのが、SaaS同士をつなぐOAuthトークンそのものが“攻撃面”になっている現実です。

Cloud Security Allianceの「State of SaaS Security 2025-2026」によれば、多くの組織で数千規模のサードパーティ連携が存在し、その相当数が休眠状態のまま強力な権限を保持しています。

問題はアカウントの乗っ取りではなく、「正規に発行されたトークンの悪用」にシフトしている点です。

攻撃対象 従来型 現在の主流
認証情報 ID・パスワード OAuthトークン
MFAの影響 突破が必要 原則不要
検知難易度 異常ログインで検知可能 正規API通信で検知困難

OAuthは本来、安全に権限委譲を行うための標準規格です。しかし一度「mail.readwrite」や「files.readwrite」といった広範なスコープが付与されると、そのトークンはユーザーの代理として継続的にAPIへアクセスできます。

しかも「offline_access」付きのリフレッシュトークンが発行されれば、ユーザーがログアウトしても、パスワードを変更してもアクセスが継続する場合があります。

これがSaaSサプライチェーンにおける“静かな永続侵害”の構造です。

さらに高度化しているのが「同意フィッシング（Consent Phishing）」です。攻撃者は偽のAI会議アシスタントやPDF要約ツールを装い、正規のMicrosoftやGoogleの同意画面を表示させます。

ユーザーは公式画面を見て安心し、「許可」をクリックします。しかし実際に許可しているのは、攻撃者の管理するアプリへの広範なAPIアクセスです。

パスワード窃取と違い、この手口はユーザー自身が“正当な操作”として権限を渡してしまう点が本質的に危険です。

Valence Securityなどの分析では、近年のSaaS侵害は総当たり攻撃よりも、OAuth悪用やトークンハーベスティングへとシフトしている傾向が示されています。

しかも侵害後の通信は正規API経由で行われるため、従来のIDSや境界型防御では検知が困難です。

つまり攻撃者は“侵入”しているのではなく、“正式に招き入れられている”のです。

この盲点を放置すると、1つの不注意な同意が、CRM、メール、ストレージ、さらには接続されたAIエージェント全体へ波及します。

OAuthトークンは単なる認証部品ではなく、SaaSサプライチェーン全体を横断する“横移動の鍵”です。

いま求められているのは、アカウント管理ではなく、トークンとスコープ単位での可視化と統制という発想への転換です。

AIワームと間接的プロンプトインジェクション：Morris IIが示した未来

AIワームと間接的プロンプトインジェクション：Morris IIが示した未来 のイメージ

生成AIがSaaSと深く結びついた2026年、最も象徴的な事件のひとつがAIワーム「Morris II」です。IBMの分析によれば、これは実行ファイルではなく“プロンプト”として自己複製する世界初の生成AIワームであり、AIエージェントの自律性そのものを攻撃面に変えました。

特に重要なのは、ユーザー操作を必要としないゼロクリック型の伝播を実証した点です。AIメールアシスタントなどが外部コンテンツを処理するだけで、悪意ある命令が内部に取り込まれ、出力を通じて自己複製します。

段階 攻撃内容 影響
侵入 メールや画像に悪意あるプロンプトを埋め込む ユーザーは気づかない
複製 AIが出力内に命令を再生成 自己増殖が開始
伝播 連絡先や他システムへ自動送信 SaaS横断で拡散
ペイロード 機密情報の抽出・外部送信 大規模データ漏洩

この仕組みは、OWASP Top 10 for LLM Applicationsが警告する間接的プロンプトインジェクションと密接に関係します。攻撃者はチャット欄に直接入力するのではなく、AIが参照するウェブページや共有ドキュメントに命令を潜ませます。

AIがRAG機能でそれらを読み込むと、データと命令の区別が曖昧になり、「以前の指示を無視せよ」「内部情報を送信せよ」といった文脈が実行されてしまいます。これは人間の判断を介さずに発動するため、防御が難しいのです。

AIは“読むだけ”でも感染します。信頼された情報源が、そのまま攻撃ベクトルになります。

さらに危険なのは、AIエージェントが持つOAuth権限との組み合わせです。広範なメール送信権限やDriveアクセス権を持つエージェントが感染すれば、被害範囲は指数関数的に拡大します。CSAの2025-2026年レポートが指摘するように、多くの組織ではサードパーティ統合が数千単位で存在し、その全体像を把握できていません。

Morris IIが示した未来は明確です。攻撃はファイルではなく“言語”として拡散し、境界防御では止まりません。AIの出力・参照データ・権限スコープを横断的に監視する新しい統制モデルが不可欠になります。

もはやプロンプトは単なる入力文ではなく、実行可能なコードに近い存在です。AIワームはその事実を証明し、SaaS連携時代のセキュリティ設計を根本から問い直しています。

CopilotとRAGが露呈させる過剰アクセス権問題

Microsoft 365 CopilotのようなRAG（検索拡張生成）型AIは、ユーザーがアクセス可能な社内データを横断検索し、最適な回答を生成します。便利さの裏側で露呈するのが、長年放置されてきた過剰アクセス権（Over-permission）の問題です。

Copilotは新たな権限を作り出すわけではありません。しかし、既存の権限設定の甘さを一気に可視化し、しかも“活用可能な形”で引き出してしまいます。

RAG型AIが引き起こすリスク構造

要素 従来環境 Copilot/RAG導入後
共有設定ミス 存在に気づかれにくい 自動検索で発見・要約される
閲覧可能な機密情報 探さなければ見つからない 質問一つで抽出される
アクセス権棚卸し 形骸化しやすい リスクが顕在化

SecurityWeekが報じたReprompt攻撃や、Varonisが分析したEchoLeak事例では、Copilotが参照可能な情報を悪用し、外部へ送信させる手法が確認されています。これはAIそのものの欠陥というより、「誰が何にアクセスできるか」という設計の甘さが攻撃面を拡張した結果です。

特に問題となるのは、SharePointやOneDriveで頻発する「組織内全員に共有」「リンクを知っていれば閲覧可能」といった設定です。従来は“偶然見つからない限り安全”でしたが、RAGはそれらをインデックス化し、文脈に応じて再構成します。

たとえば「今期の予算状況を教えてください」という無害な質問でも、閲覧可能状態にある役員会資料やM&A関連文書が統合的に引用される可能性があります。これは情報漏えいというより、アクセス権設計の失敗が高度検索によって増幅された状態といえます。

さらに間接的プロンプトインジェクションが組み合わさると、Webページや共有ドキュメント内に埋め込まれた命令文がCopilotに解釈され、機密情報を外部送信させる経路が生まれます。OWASPが指摘するExcessive AgencyやPrompt Injectionのリスクは、まさにこの文脈で現実化しています。

Copilotは情報を漏らすのではなく、「漏れる状態にあった情報」を効率よく掘り起こします。

つまり問題の本質はAIではなく、ID管理とデータガバナンスです。ユーザーが本来不要なフォルダに閲覧権限を持っていないか、退職者が作成した共有リンクが残っていないか、グループ設定が実態と乖離していないか。RAG環境では、これらが即座に攻撃面へと転化します。

Copilot導入は単なる生産性向上プロジェクトではありません。全社的なアクセス権の再設計を迫るガバナンス改革でもあります。RAGは組織の知識を賢く統合しますが、その前提として「誰が何を見るべきか」を厳密に定義し直すことが不可欠です。

非人間ID（NHI）とゾンビエージェントの増殖リスク

自律型AIの普及とともに、組織内で急増しているのが非人間ID（NHI: Non-Human Identities）です。サービスアカウント、APIキー、OAuthトークン、ボット、そしてAIエージェント。これらは人間ではないにもかかわらず、実質的に“従業員以上”の権限を持つ存在としてシステムを動かしています。

Cloud Security Allianceの2025-2026年レポートによれば、46%の組織がNHIを効果的に監視できていないと回答しています。しかも多くの企業で、NHIの数は人間IDの数倍から数十倍に達していると推定されています。

つまり、企業のアイデンティティ基盤はすでに「人間中心」ではなく、「機械中心」へと静かに移行しているのです。

比較項目 人間ID 非人間ID（NHI）
ライフサイクル管理 入退社で明確 作成後に放置されやすい
認証強度 MFA導入が一般的 トークン依存で無期限化しやすい
活動時間 勤務時間帯中心 24時間365日稼働

問題は、これらのNHIの中に「ゾンビエージェント」が生まれていることです。担当者が異動・退職しても、彼らが作成したAIエージェントやOAuth連携は削除されず、権限を保持したまま稼働を続けます。

OWASPが指摘するExcessive Agencyのリスクとも直結しますが、過剰な権限を持ったエージェントが長期間放置されることで、攻撃者にとって理想的な潜伏先になります。人間IDと異なり、挙動が多少不自然でも「自動処理」と見なされやすく、検知が遅れます。

さらに深刻なのは、AIワーム「Morris II」のような自己複製型攻撃との組み合わせです。IBMの分析が示す通り、AIエージェント間のAPI連携はワームの伝播経路になり得ます。ゾンビエージェントが存在する環境では、感染後の横展開が加速度的に進みます。

NHIの増殖は単なる管理負荷の問題ではありません。
それは「攻撃者に常駐IDを提供している状態」に等しいのです。

特にリフレッシュトークンを伴うoffline_access権限は、パスワード変更やMFA強化の影響を受けません。同意フィッシングや偽プラグイン経由で発行されたトークンが残存すれば、攻撃者は“正規アクセス”として活動を続けられます。

Palo Alto Networksの予測が示唆するように、インサイダー脅威の主体がAIエージェントへ移行する未来では、NHI管理はオプションではなく前提条件になります。

今後の焦点は明確です。すべてのNHIを可視化し、用途・所有者・有効期限を紐付け、不要なものを即時失効させること。ゾンビ化を許さないライフサイクル管理こそが、Shadow Agent時代の基礎防衛線になります。

EU AI法・NIST AI RMF・ISO/IEC 42001の実務インパクト

2026年、AI活用は「技術課題」から「規制対応を前提とした経営課題」へと明確に移行しています。EU AI法、NIST AI RMF、ISO/IEC 42001はそれぞれ性格が異なりますが、いずれも企業に対し、AIの透明性・説明責任・サプライチェーン管理を実装レベルで求めています。

特にShadow AIや自律型エージェントが拡大する環境では、これらの枠組みは単なるガイドラインではなく、日常オペレーションに直結する統制基準として機能します。

枠組み 法的拘束力 実務インパクト
EU AI法 あり（域外適用） 技術文書整備・責任分界の明確化
NIST AI RMF なし（事実上の標準） リスク管理プロセスの体系化
ISO/IEC 42001 認証規格 AIガバナンス体制の制度化

EU AI法の実務的な重みは「ダウンストリーム責任」にあります。GPAIをAPI経由で利用する企業も、技術文書の保持やリスク評価の実施が求められます。欧州委員会のガイドラインによれば、提供者から十分な情報を取得し、自社システムの適合性を証明できなければ制裁対象になり得ます。つまり「外部AIを使っているだけ」は免責理由になりません。

NIST AI RMFは法規制ではありませんが、米国政府調達やグローバル企業との取引では事実上の前提条件になりつつあります。生成AIプロファイルではサードパーティリスク管理や継続的モニタリングが強調されています。これはAI-SPMやSaaS権限棚卸しと直結する要求です。

ISO/IEC 42001は「仕組み化」の圧力を企業内部にかけます。Annex Aではサプライヤー管理、影響評価、責任体制の明確化が求められます。単発のリスク評価ではなく、経営レベルのAIマネジメントシステム構築が必要です。認証取得は営業上の信頼シグナルにもなります。

規制対応は「チェックリスト消化」ではなく、SaaS連携管理・非人間ID統制・データフロー可視化を含む実装改革を伴います。

実務では、①AIインベントリの整備、②第三者連携の契約・責任分界点の明文化、③影響評価プロセスの標準化、④監査証跡の保存が必須になります。CSAやNISTの資料が示す通り、継続的監視が前提です。

2026年における本質的インパクトは明確です。AI活用は自由度の高い実験から、説明可能で監査可能な経営インフラへと再定義されました。規制は抑制ではなく、持続可能なAI競争力を持つ企業とそうでない企業を分ける分水嶺になっています。

AI-SPMの台頭：SSPMでは防げないAI特有リスクへの対応

自律型AIエージェントの普及により、従来のSSPM（SaaS Security Posture Management）では捉えきれないリスクが顕在化しています。SSPMは設定不備や公開範囲の誤りといった「静的な構成リスク」を検出する仕組みですが、AIはモデル、プロンプト、エージェント挙動といった「動的な要素」を内包します。

Cloud Security Allianceが指摘するように、2026年のSaaS環境はAPIで密結合されたメッシュ構造へと進化しており、その上でAIが自律的に権限を行使します。この変化に対応するために登場したのがAI-SPM（AI Security Posture Management）です。

観点 SSPM AI-SPM
管理対象 SaaS設定・公開範囲 モデル・プロンプト・AIエージェント
リスク検知 MFA未設定・共有設定ミス 過剰エージェンシー・データフロー逸脱
可視化範囲 人間ID中心 非人間ID・Shadow Agent含む

最大の違いは、AI-SPMが「AIの行動そのもの」を管理対象に含める点にあります。OWASPが2025年版で警告するExcessive Agencyは、エージェントが与えられた権限を自律的に過剰行使するリスクを示していますが、これは設定監査だけでは検知できません。

AI-SPMはまず組織内のAI資産を自動検出し、Shadow AIや未承認エージェントを洗い出します。そのうえで、どのデータにアクセス可能か、どのOAuthスコープを保持しているか、どの外部プラグインと接続しているかを横断的に可視化します。

さらに重要なのがデータフローの追跡です。入力データがどのモデルに渡り、どの出力がどのSaaSへ書き戻されるのかをマッピングすることで、CopilotやRAG環境で問題となる意図しない情報露出経路を特定できます。SecurityWeekが報じたReprompt型攻撃のような間接的データ流出も、流れの可視化なしには防げません。

AI-SPMの本質は「構成管理」から「AI挙動の統制」への転換にあります。

従来は「誰がアクセスできるか」が中心でしたが、AI時代は「AIが何をしようとしているか」を監視する必要があります。非人間IDの増加を背景に、AIエージェント専用IDの棚卸しや権限最小化もAI-SPMの重要機能です。

2026年のセキュリティスタックにおいて、AI-SPMは単なる追加ツールではありません。SSPMやDSPMと連携しながら、AIモデル・データ・権限の三位一体でポスチャを継続的に評価する中核レイヤーとして位置づけられつつあります。

AI特有のリスクは、AIを前提とした管理基盤でしか制御できません。これがAI-SPM台頭の本質的な理由です。

SaaS権限の棚卸し実践ガイド：OAuthスコープの可視化と削減

OAuthスコープの棚卸しは、SaaS時代の最重要オペレーションです。CSAの「State of SaaS Security 2025-2026」によれば、多くの組織で数千規模のOAuth連携が存在し、その相当数が未監視または休眠状態にあります。

問題の本質は「どのアプリがあるか」ではなく、どのスコープ（権限）を、どのIDで、どの期間保持しているかを把握できていない点にあります。

まず可視化の起点として、主要SaaSの管理コンソールからOAuthアプリ一覧とスコープ情報をエクスポートします。人間IDと非人間IDを区別して整理することが重要です。

確認項目 具体例 リスク観点
高権限スコープ mail全権限 / files.readwrite 大量データ抽出・削除
offline_access リフレッシュトークン保持 長期潜伏
全社同意アプリ 管理者一括承認 影響範囲の拡大
休眠トークン 90日未使用 侵害時の踏み台化

次に行うべきはリスクベース分類です。OWASPが指摘するExcessive Agencyの観点からも、書き込み・削除権限を持つアプリは優先的に再評価します。

特にAIエージェント系アプリは、読み取り専用で十分なケースが多いにもかかわらず、初期設定で広範なスコープを要求します。ここで「業務要件とスコープの整合性」を精査します。

棚卸しの目的は「危険なアプリの発見」ではなく、「不要な権限の削減」です。削除できない場合でも、read/writeからread-onlyへ落とすだけでリスクは大幅に縮小します。

削減フェーズでは三段階で進めます。第一に休眠アプリの無効化、第二にスコープ縮小、第三に再同意プロセスの導入です。

再同意では、利用部署に対し「この権限は本当に必要ですか」と具体的に確認します。抽象的なセキュリティ議論ではなく、実際の業務フロー単位で検証することが成功の鍵です。

さらに、管理者による全社同意を原則停止し、ホワイトリスト方式へ移行します。NIST AI RMFが強調するサードパーティリスク管理の実践として、ベンダーの認証状況やデータ処理方針も併せて確認します。

最後に、棚卸しは一度で終わりません。四半期ごとにスコープ増加や新規連携を差分監視し、トークンのライフサイクルを管理します。

OAuthスコープは「設定値」ではなく「攻撃面」です。可視化と削減を継続することで、Shadow Agent時代の被害半径を現実的な範囲に抑えられます。

連携最小化（Least Privilege Integration）を実装する設計原則

連携最小化（Least Privilege Integration）とは、AIエージェントやSaaS間連携に対して業務遂行に必要な最小限の権限のみを付与するという設計原則です。従来の最小権限の原則を、API連携と自律型AIの時代に合わせて再定義した考え方といえます。

OWASPのLLM06:2025 Excessive Agencyでも指摘されている通り、AIに過剰な権限を与えること自体が重大なリスクになります。特にOAuthベースの連携では、一度「許可」を押すだけで広範なスコープが恒常的に付与される点が問題です。

CSAの2025-2026年レポートでも、多くの組織が未使用の連携アプリや過剰スコープを放置している実態が示されています。連携最小化は、こうした構造的リスクを設計段階から抑え込むアプローチです。

設計観点 従来型連携 連携最小化設計
権限範囲 フルアクセス付与 フォルダ・機能単位で限定
有効期間 長期・無期限 タスク単位の一時付与（JIT）
ID管理 人間IDと共有 エージェント専用ID分離
高リスク操作 自動実行 人間承認を必須化

実装上の核心は3つあります。第一に、エージェント専用の非人間IDを分離し、行動ログを明確化することです。これにより「誰が何をしたのか」が追跡可能になります。

第二に、スコープの粒度を極限まで細かくすることです。OsoやAuth0が指摘するように、OAuth標準スコープはエージェント用途には粗すぎる場合があります。APIゲートウェイやポリシーエンジンで補完し、業務コンテキスト単位で制御する設計が求められます。

第三に、Just-in-Timeアクセスと自動失効設計を組み込むことです。トークンを常時有効にするのではなく、タスク実行時のみ発行し、完了後は即時破棄します。これによりトークン窃取時の被害範囲を劇的に縮小できます。

連携最小化の本質は「侵害を前提にして被害半径を縮める設計」にあります。

AIワームや同意フィッシングのように、完全な侵入防止は現実的ではありません。しかし、エージェントがアクセスできる範囲を限定していれば、仮に侵害されても組織全体への横展開は防げます。

連携最小化は単なる設定変更ではなく、アーキテクチャ思想です。便利さを最大化するのではなく、権限の半径を最小化することで信頼を設計する。それがShadow Agent時代における持続可能なAI活用の前提条件になります。

Human-in-the-LoopとJITアクセスで築く実践的ガバナンス

自律型AI時代のガバナンスは「止める」ことではなく、「適切な瞬間に人間が介在し、必要な時間だけ権限を与える」設計にあります。

OWASPが指摘するExcessive Agencyの本質は、AIに恒常的かつ広範な権限を与えてしまう点にあります。OsoやAuth0が解説するように、OAuthは本来ユーザー向けに設計された仕組みであり、自律的に判断するエージェントには粒度が粗い場合があります。そのため、Human-in-the-LoopとJust-in-Timeアクセスを組み合わせた実践的統制が不可欠です。

Human-in-the-Loopは単なる承認フローではありません。重要なのは「どのアクションを人間判断に戻すか」の設計です。たとえば大量の顧客データエクスポート、外部ドメインへの一括送信、削除操作など、不可逆または影響範囲が大きい処理に限定して承認を挟みます。これにより利便性を損なわず、リスクのみを抑制できます。

一方、JITアクセスは常時付与型権限の見直しを意味します。CSAのレポートでも指摘されるように、非人間IDは長期間有効なトークンを保持し続ける傾向があります。これをタスク実行時のみ短時間発行する方式へ移行することで、トークン漏洩やゾンビエージェント化のリスクを大幅に縮小できます。

項目 従来型 推奨モデル
権限付与 常時フルスコープ 必要時のみ限定スコープ
高リスク操作 自動実行 人間承認必須
トークン寿命 長期固定 短期・都度発行

実装面では、エージェント専用IDの分離、APIゲートウェイによるスコープ制御、ワークフローエンジンでの承認挿入が現実的です。さらにログをエージェント単位で可視化し、承認履歴と突合することで監査耐性も向上します。

Human-in-the-Loopは「不信」ではなく説明責任の確保であり、JITアクセスは「制限」ではなく被害半径の最小化です。 この二軸を組織標準として制度化することが、Shadow Agent時代における実践的ガバナンスの中核になります。

日本企業が直面する組織的課題と変革のロードマップ

日本企業がAI活用を本格化させる中で、最大の障壁となっているのは技術そのものではなく、組織構造と意思決定プロセスです。2025年度の国内調査では、多くの企業がAI導入を「実行フェーズ」に移行した一方で、部門主導の個別最適が先行している実態が明らかになりました。これはスピードを生む一方、統制なきShadow AIやShadow Agentの温床にもなります。

特に日本企業に顕著なのが、責任分界の曖昧さです。経営層は「活用推進」を掲げ、現場は成果を求められ、情報システム部門はリスクを抑えようとします。しかし、AIエージェントがSaaSを横断的に操作する時代において、縦割り構造のままでは統合的なリスク管理は機能しません。

AIリスクはIT部門の問題ではなく、経営・法務・事業部門を横断する経営アジェンダです。

Cloud Security Allianceの2025-2026年レポートによれば、46%の組織が非人間IDを効果的に監視できていません。これは技術不足というより、管理責任の所在が明確でないことが背景にあります。AIエージェントは誰の資産で、誰がライフサイクルを管理するのか。この問いに答えられない組織は少なくありません。

日本企業が直面する主な組織課題

課題 背景要因 放置した場合の影響
部門サイロ化 現場主導のツール導入 Shadow AIの常態化
責任分界の不明確さ AI専任組織の不在 インシデント時の対応遅延
権限管理の形骸化 従来型IAMへの依存 過剰なOAuthスコープの放置

では、どのような変革ロードマップが現実的でしょうか。第一段階は「可視化」です。AI-SPMやSaaS監査を通じて、すべてのAI資産とOAuth連携を棚卸しします。ここで重要なのは、技術的検出だけでなく、事業部門ヒアリングを組み合わせることです。

第二段階は「統合ガバナンス体制の確立」です。CISO直轄のAIガバナンス委員会を設置し、法務・リスク管理・事業部門を含めた横断的な審査プロセスを構築します。NIST AI RMFが示すように、サプライチェーン全体を含むリスク管理は継続的プロセスでなければなりません。

第三段階は「最小権限文化の定着」です。技術的な制御だけでなく、評価制度やKPIにも反映させます。利便性よりも統制を優先した部門が不利にならない設計が不可欠です。

最後に重要なのは、経営層の明確なコミットメントです。EU AI法や国内ガイドラインが示す通り、AIガバナンスは“遵守すべき義務”へと変わりました。AI活用を競争優位に変える企業と、リスクに足を取られる企業の差は、技術力ではなく組織変革力にあります。

参考文献