Uberの研究チームは2026年5月、AIエージェントの不正な挙動を検出するフレームワーク「ADR（Agentic AI Detection and Response）」を公開しました。ほぼ同時期に、MicrosoftもMicrosoft 365管理センターとMicrosoft Entra Agent IDで、IT部門が把握していない「シャドーAIエージェント」を検出する機能をプレビュー提供しています。
個人が導入したデスクトップエージェント、部署が試作したブラウザ自動化、登録されていないMCPサーバーは、チャットボットよりも強い権限でファイルや業務システムへ接続できます。企業のIT部門・事業責任者にとって重要なのは、こうした利用を一律禁止することではなく、何が動いているかを検出し、誰の代理でどのデータとツールへどの権限でアクセスしたかを記録し、リスクに応じて許可・制限・停止できる状態をつくることです。
以下では、UberのADRの考え方とMicrosoftの検出・統制機能を手がかりに、企業が実装するための具体的なチェックを整理します。
※本記事は2026年8月時点の情報です。
シャドーAIエージェントとは？「使っているアプリ」だけでは見えない
シャドーAIは、組織の承認やITの可視化を経ずに使われるAIアプリケーションやサービスです。シャドーAIエージェントでは、さらに、モデルが計画を立て、ファイルを読み書きし、外部ツールを呼び出し、別のエージェントへ処理を渡すことがあります。
問題は、誰かがAIを使ったかどうかではなく、AIが人の代理として何を実行したかを追跡できないことです。
「誰が、何を、いつ、なぜ」をつなげて記録する
たとえば、担当者がエージェントへ依頼し、エージェントが社内検索を行い、MCP経由でチケットを更新し、別のエージェントが通知を送るとします。最終操作だけを人のサービスアカウントで記録すると、どの指示がどの動作につながったか分かりません。ユーザー、エージェント、サブエージェント、ツールの委任チェーンを保持することが、監査とインシデント対応の前提になります。
これは、AIエージェントの導入事例を読むときにも重要です。AIエージェント導入事例の成果だけでなく、権限、承認、ログ、停止方法が公開されているかを見ると、自社で再現できるかを判断しやすくなります。
ポイント
シャドーAIエージェント対策は利用禁止ではなく、誰の代理で何を実行したかという委任チェーンを記録できる状態をつくることです。
Uber ADRに見る実装例｜検出を仕組みとして分解する
ADR（Agentic AI Detection and Response）は、MCP経由でツールを使うAIエージェントを対象にした検出・対応の枠組みです。論文では、通常のエンドポイント監視だけでは、エージェントの推論、プロンプト、意図から実行までの因果関係が見えにくいと指摘しています。
| ADRの要素 | 役割 | 企業での置き換え |
|---|---|---|
| ADR Sensor | エージェントの実行に関する高精度なテレメトリを集める | プロンプト、ツール呼び出し、委任、データ移動を共通形式で記録する |
| ADR Explorer | 本番前のレッドチームと難しい検出例をつくる | プロンプトインジェクション、権限逸脱、秘密情報持ち出しを事前検証する |
| ADR Detector | 軽いトリアージと文脈を含む判定を組み合わせる | 全イベントを高価な判定にかけず、重大度に応じて段階的に検査する |
| Shift-left prevention | 本番の検出結果を、実行前の防止へ反映する | 秘密情報や危険なツール呼び出しを、実行前に止める |
ADRの論文では、Uberで10か月以上運用し、7,200超のホスト、日次1万超のエージェントセッションを扱ったと報告しています。また、認証情報の露出を検出し、事前防止へつなげた実績も記載されています。これらはUberの環境における報告値であり、一般企業で同じ数値を再現できるという意味ではありません。重要なのは、検出を一つのAI判定器に任せず、センサー、オフライン検証、オンライン検知、防止へ分けている点です。
AIエージェントの本番運用を考えるときは、AgentOpsの可観測性・評価・監視の考え方も参考になります。エージェントの出力だけでなく、途中のツール呼び出しと失敗理由を残して初めて、改善と監査が両立します。
ポイント
ADRは検出をセンサー・事前検証・オンライン検知・防止の4段階に分け、単一のAI判定器に依存しない設計です。
統制の中核｜エージェントID・短期権限・ゲートウェイ
Uberが公開したエージェントIDの設計では、エージェントを人や通常のワークロードとは異なる、代理実行主体として扱います。Security Token Serviceは、広く長く使える資格情報ではなく、委任の各ホップに短命で範囲を絞ったトークンを発行します。MCP Gatewayは、エージェントからツールへの呼び出しを仲介し、ポリシーを適用する場所になります。
「許可リスト」だけでなく、実行時の文脈を見る
登録済みのエージェントでも、目的外のデータへアクセスしたり、通常と異なる量のツールを呼び出したりすれば危険です。人の承認を求める操作、読み取りだけで済む操作、自動実行を許す操作を分け、リスク、データ分類、対象システム、実行時間、変更量で動的に判定します。Microsoft EntraのエージェントIDに関する公式ガイダンスでも、最小権限、スポンサー、定期的なアクセスレビュー、孤児エージェントの廃止、ログ監視が推奨されています。
Microsoft 365管理センターのShadow AI機能は、未管理のAIエージェントを検出し、デバイス、ユーザー、最終利用、ネットワーク通信などを確認する仕組みをプレビュー提供しています。現時点では対応エージェントやブロック対象、Intuneなどの前提条件があり、機能は変わり得ます。製品名をそのまま導入要件にせず、自社のOS、ネットワーク、ID基盤でどこまで見えるかを確認します。
シャドーAI対策の目的は、現場の試行を止めることではありません。安全なサンドボックス、承認済みモデル、標準のMCPコネクター、相談窓口を用意し、正規ルートの方が速く使える状態をつくることが、無断利用を減らします。
ポイント
エージェントには短期トークンと最小権限を割り当て、MCP Gatewayで実行時の文脈をもとにポリシーを適用します。
実装チェックリスト｜検出から廃止までを一周させる
導入は、いきなり全社ブロックを行うより、まず現状を観測し、リスク分類と代替手段を準備してから統制へ進めます。最低限、次の順序を確認します。
- 棚卸し：端末、SaaS、API、MCPサーバー、社内開発のエージェントを複数のログから検出する
- 所有者：目的、責任者、スポンサー、対象業務、連絡先、廃止予定日を登録する
- リスク分類：読み取り／書き込み、個人情報、機密情報、外部送信、金銭・顧客影響で段階化する
- 権限：エージェント固有ID、短期資格情報、最小スコープ、承認フローを設定する
- 監視：プロンプト、ツール、データ移動、設定変更、失敗、拒否、手動介入を保存する
- 対応：危険なセッションを停止し、資格情報を失効させ、原因と影響範囲を調査できるようにする
- 定期レビュー：使われていないエージェント、所有者不在、過剰権限、期限切れを廃止する
評価指標は、検出件数を増やすだけでは不十分です。未登録エージェントを見つけるまでの時間、重大なデータ移動の検出率、誤検知による現場負荷、停止から復旧までの時間、定期レビューで廃止できた数を追います。検出が増えたときに「AI利用が危険になった」と決めつけず、これまで見えていなかった利用を可視化できた可能性も含めて解釈します。
シャドーAIの統制を生成AI全体の利用ルールと接続する場合は、生成AI活用事例で整理されている業務目的・効果測定と、セキュリティ側の監査項目を同じ台帳へ置くと、現場とITの分断を小さくできます。
野良AIエージェント対策のまとめ｜禁止ではなく、観測できる実行基盤へ
シャドーAIエージェントの問題は、AIを使う社員がいることではなく、エージェントの権限、データ経路、ツール呼び出し、委任関係、廃止責任が不明なまま増えることです。UberのADRはテレメトリ、事前検証、オンライン検出、防止を分け、UberのエージェントID設計は短期資格情報と委任チェーンを重視しています。
企業が最初に行うべきことは、すべてを止めることではありません。まず自社で動くAIアプリとエージェントを発見し、所有者と目的を登録し、読み取りと書き込みの権限を分け、危険な操作に人の確認を残します。そのうえで、使われていないものを廃止し、検出結果を事前防止や開発標準へ戻します。統制を利用者の障壁ではなく、安心して使える共通基盤として提供できるかが、シャドーAI対策の実効性を決めます。
ポイント
最初の一歩は全面禁止ではなく、稼働中のAIアプリ・エージェントを発見し、所有者登録と読み取り／書き込み権限の分離から始めることです。
よくある質問（FAQ）
Q. シャドーAIエージェントとは何ですか？
IT部門の承認や可視化を経ずに使われるAIエージェントです。モデルが計画し、ファイルや業務システムを操作し、別のエージェントへ処理を委任する場合があるため、通常のAIアプリよりも権限と実行経路の把握が重要です。
Q. シャドーAIはすべて禁止すべきですか？
一律禁止は、現場が別の未管理ツールへ移るリスクがあります。まず利用を検出し、データ、権限、業務影響で分類したうえで、承認済みの代替手段、サンドボックス、相談窓口を用意し、リスクの高い操作だけを制限する方法が現実的です。
Q. UberのADRは何を参考にできますか？
エージェントのテレメトリを集めるセンサー、本番前のレッドチーム、軽量判定と文脈判定を組み合わせる検出、実行前の防止という分解が参考になります。Uberでの運用値をそのまま再現するのではなく、自社のログとリスクに合わせて小さく実装します。
Q. 最初の導入チェックは何ですか？
端末・SaaS・API・MCPサーバーを横断して棚卸しし、所有者、目的、データ、権限、ログ、停止方法、廃止予定日を登録します。その後、読み取り専用の低リスク業務で検出と監査ログを検証し、書き込みや外部送信を伴う用途へ段階的に広げます。
参考情報：
Uber Research「ADR: An Agentic Detection System for Enterprise Agentic AI Security」
Uber Engineering「Solving the Identity Crisis for AI Agents」
Microsoft Learn「Understand Shadow AI in Microsoft 365 admin center」
Microsoft Learn「Best practices for Microsoft Entra Agent ID」
Microsoft Learn「Shadow AI discovery in Global Secure Access」
関連記事
- AgentOpsでAIエージェントを可観測にする
- AIエージェント導入事例と統制の考え方
- 生成AI活用事例で業務ルールを設計する
- Gemini Enterpriseのエージェント管理
- AWS Kiro Crewのマルチエージェント運用
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。