シャドーAITの台頭

シャドーITはSaaS時代の密かな楽しみだったとしたら、シャドーAITは生成AI時代の「一時的な特効薬」です。承認されていないAIモデル、ツール、自律エージェントが、承認やログ記録、制御なしにビジネスワークフローに密かに組み込まれる現象です。それは高速で便利ですが、牙をむくこともあります。

Netskopeの2025年生成AIレポートによると、組織は現在平均して約6つの生成AIアプリを使用しています。上位25%の組織では13以上を使用しており、全体では300以上の異なる生成AIアプリが追跡されています。また、生成AIアプリに送信されるデータ量は、前年比で30倍以上に増加していることが測定されました。Menlo SecurityのAIレポートは、シャドー生成AIが68%急増していると警告しており、「役立つもの」が「危険なもの」へと変わりつつあります。Ciscoの2025年レディネス・インデックスによると、約60%の組織が未承認のAIツールの特定に自信がないと回答しており、監視の必要性が強調されています。Gartnerは、これを制御不能になった生成AIデータプログラムに関連付けています。

シャドーAIが組織や職種を超えて拡散し、特に従業員が私物のAIを持ち込む場合に、実際のデータ漏洩やガバナンスリスクをもたらしています。

本記事は、シャドーAITの検知と管理に関する実践的なテレメトリ優先ガイドです。検出結果をMITRE ATLAS、LLMアプリケーション向けOWASP Top 10、NIST AI RMFにマッピングします。また、収集すべきログ（CloudTrail、CloudWatch、エンドポイントログ、アプリケーションログ、Model Context Protocol/MCPテレメトリ）について具体的に説明します。また、本日すぐにSIEMに組み込めるSumo Logicスタイルのクエリもご紹介します。

シャドーAITとは

シャドーAITとは、AIサービス、AIツール、およびエージェント的を繋ぎとめるもの（プラグイン/ツール、MCPサーバー、Bedrockエージェント、LangChainツールなど）の不正使用を指し、これらは本番データやシステムに接触する可能性があり、多くの場合セキュリティの監視範囲外で発生します。 

AI列車は駅を出発し、企業が苦境に立たされているのは、AIツールを許可しなければ、影のAIを奨励することになるということです。従業員は、AIが私たちの生活のあらゆる側面にもたらす価値を経験しています。AIは単にデータを処理するだけでなく、データから学習し、荒唐無稽な出力を幻覚し、最も機密性の高いシステムにアクセスし、時には一家団欒のほろ酔いおじさんのように秘密を漏らすからです。

なぜ急増しているのでしょうか？その理由は、AIの民主化パワーにあります。ツールが非常に身近になり、非技術者でもタスクを自動化するエージェントを立ち上げたり、プロのようにコーディングするコパイロットを立ち上げたりできるようになりました。しかし、監視なしでは、データ漏えいからコンプライアンスの悪夢まで、企業全体にリスクの盲点を生み出しています。 

近い将来、インシデント後のミーティングで、リーダーが “あのアプリケーションがAIを使っているとは知らなかった “とか、”誰がAIの使用を許可したのか？あるいは、「誰がAIをそのように使うことを許可したのか」と。暗闇に光をもたらすには、チームのAI戦略に寄り添い、イノベーションをサポートしつつ、摩擦をあまり生じさせないようにコントロールとガバナンスを巻き込む必要があります。 

AIレッドチームやペネトレーションテストの評価を実施できるほど成熟している組織なら、未来は明るいでしょう。それらの評価者と連携し、テスト中にログテレメトリを収集してください。そうすれば、侵入が発生した際に、将来の敵対的行動やAIの悪用を検知する仕組みを構築できます。

プログラムを定着させるためのフレームワーク

AI TRiSM

AI TRiSM は、Artificial Intelligence Trust, Risk, and Security Managementの略です。ガートナー社による造語で、AIシステムのライフサイクル全体を通じて信頼性、コンプライアンス、安全性を確保するために設計されたフレームワークです。わかりやすく言うと、 Trust は、AIがどのように意思決定を行うかを説明できるか？それは公平で、信頼でき、偏りがないか？ リスク（Risk） は、何がうまくいかない可能性があるのか？データ漏洩、幻覚、敵対的なハッキング、規制上の問題などを考えてみましょう。 セキュリティ 攻撃、誤用、不正アクセスからモデル、データ、インフラをどのように保護するか？

NIST AI RMF 1.0 + Generative AI Profile (AI 600-1) 

NISTのAIリスク管理フレームワーク は、Map（リスクの特定）、Measure（リスクの定量化）、Manage（リスクの軽減）、Govern（すべてを監督）などのコア機能を備えた、ガバナンスのGPSです。これをシャドーAIに適用して、環境内の未承認のAI利用をマッピングし、AIシステムのインシデント対応要件に従いつつ、データ暴露率などのメトリクスでリスクを測定します。

MITRE ATLAS 

これはAIシステムのための敵対的プレイブックであり、MITRE ATT&CKに似ていますが、機械学習の脅威に特化しています。データポイズニング（悪意のある者が訓練データを改ざんすること）やモデルエベージョン（AIを騙して誤った判断をさせること）などの戦術をマッピングしています。ログをATLASのマトリクスと照らし合わせることで、シャドーAIのリスクを評価します。例えば、未承認のcopilotにおけるエベージョン手法を示す可能性のある異常なAPIコールを特定することなどが挙げられます。

OWASP Top 10 for LLM Apps (2025 更新)

この貴重なリストには、プロンプトインジェクション（モデルを乗っ取る巧妙な入力）や機密情報の開示（出力に個人情報が漏洩すること）など、大規模言語モデル（LLM）特有の脆弱性が記載されています。シャドーAIのシナリオでは、従業員が知らず知らずのうちにこれらを誘発する可能性があります。例えば、マーケティングチームが承認されていないLLMアプリを使用し、過度な依存（ハルシネーションによる出力を盲信すること）によって誤ったビジネス判断を下すといったケースです。

何を記録すべきか（なぜ記録すべきか）。

クラウド/モデルAPI 

まずは、AWS Bedrock（シャドーAIの実験場になりやすい場所）のようなサービスからのAPIログを連携させることから始めましょう。例えば、converseおよびconverse_streamの呼び出しを監視します。入力/出力トークン、レイテンシ、分あたりの呼び出し回数などのメトリクスを追跡します。 

ほとんどのクラウドプロバイダーはテレメトリを文書化しています。たとえばAWSのBedrockでは、以下の計測機能があります：

• InvokeModel / Converse / ConverseStreamおよびAgents (InvokeAgent)用CloudTrail管理/データイベント。これらは、アイデンティティ、モデルID、およびリージョンをまたぐ異常の特定に最適です。
• CloudWatch Agentsメトリクス：呼び出し回数、トークン数、初回トークン到達時間（TTFT）、スロットリング、クライアント/サーバーエラー——ガードレールブロックレートやコスト/不正利用の異常値に最適。
• CloudWatchログ/S3への呼び出しログ記録（入力/出力）—フォレンジックおよびレッドチームプロンプトに不可欠（個人識別情報（PII）の厳格な管理を伴う）。

Sumo Logicは、CloudTrail + CloudWatch + 呼び出しログをダッシュボードとクエリに統合するBedrockアプリを標準で提供します。

モデルに関係なく、生成AIの使用状況を監視するために重厚で独自のスタックは必要ありません。OpenAIスタイルのAPIは、関心のあるテレメトリ（レイテンシ、エラー、トークン数、モデレーション結果）をすでに返しています。開発者が独自のAI機能を構築している場合は、SDKの呼び出しにインストルメンテーションを施してください。例えば、SDKの呼び出しを小さなPythonの「エージェント」でラップし、構造化されたイベントを発行して、使用しているSIEMや可観測性プラットフォームに転送します。テレメトリには通常、呼び出し率、エラー率、入力および出力トークン数、そして（オプションで）サンプリングされたプロンプト/レスポンスが含まれます。HTTPSコレクター経由でJSONイベントをSIEMに転送します。（トレース/スパンのコンテキストが必要な場合は、OpenTelemetryの新しい生成AIセマンティックコンベンションを使用してこれらのフィールドを標準化できますが、これはオプションです）

未承認エージェントの検出

エージェント（自律的なAIの実行者）はAPIとチャットするのが大好きです。ログパターンを使用して、予期しないAPIキーやジオロケーションのような異常な行動にフラグを立てます。例えば、怪しいモデルハブからのダウンロードを示すログなどです。エンドポイント/CLI/プロキシで、シェル履歴とイグレス DNS/HTTP をキャプチャし、パブリック LLM やエージェントのバックエンド（例えば api.openai.com、api.anthropic.com、*.hf.space、*.perplexity.ai、*.deepseek.com）への許可されていないコールをキャッチします。

MCP (モデルコンテキストプロトコル)監査

MCPは、LLMアプリがツール、リソース、およびプロンプトにJSON-RPC経由で接続する方法を標準化します。これは監査において非常に価値があります：tools/list、tools/call、resources/read、prompts/get、ユーザー承認、およびクライアント/サーバー間の相関IDを記録します。最新の仕様では、ログ記録、機能のネゴシエーション、およびセキュリティ上の考慮事項が明示的に示されているので、これらを活用してください。

テレメトリーにおけるシャドーAITの姿：3つの実例パターン

ここで強調すべき重要な点は、シャドーAITと内部脅威の境界線はすぐに曖昧になる可能性があるということです。従業員がセキュリティリスクに気づかずにAIでイノベーションを行っている場合もあれば、AIを利用した悪意のある攻撃者の犠牲になっている場合もあります。これらのパターンと検出は、パターンの背後にある意図に関わらず、チームに役立ちます。

パターン1 — プロンプトからツールへのピボット (OWASP LLM07/LLM08; ATLAS: プロンプトインジェクション)

一見無害なプロンプトが、エージェントに高リスクなツール（秘密情報の読み取り、アクションの実行など）を呼び出させます。通常のチャットリクエストの直後に、機密性の高いtools/callやBedrockエージェントのアクションが続くのが見られます。

ログ記録とアラート対象

• ビジネスコンテキストやユーザー承認フラグと一致しない、機密ツール（シークレット、本番環境API）へのMCP tool/call
  
• Bedrock InvokeAgentの急増、または「最初に検出された」アイデンティティ（UEBA）による新規アクショングループの作成。
  

パターン2 — トークンフラッドによるコスト/DoS攻撃（OWASP LLM04; ATLAS: リソース枯渇）

改ざんされたプロンプトやループは、トークンの暴走や再試行の繰り返しを引き起こします。

ログ記録とアラート対象

• CloudWatch InputTokenCount/OutputTokenCount のアイデンティティ/モデルごとの外れ値；増加するInvocationThrottles。
  
• コンテキストウィンドウの拡大を示す呼び出しログ（入力サイズが突然4倍に増加）。
  

パターン３ — 許可されていない汎用AIの使用（シャドーAIT「クラシック」）

エンドポイントは企業ネットワークから消費者向けAI APIと通信し、結果をコピー＆ペーストして企業システムに貼り付けます。

ログ記録とアラート対象

• 許可リストに含まれない識別子による既知のLLMドメインへのアウトバウンド通信/DNSアクセス；キーボードマクロ/コピーバッファがヘルプデスク調査に表示されます。業界の調査によると、チームはどのAIサービスが稼働しているかという可視性を欠いていることが多いですが、ログがそれを解決します。

すぐに導入できるSumo Logicスタイルの検知

新規識別子によるBedrock APIの使用（偵察/列挙）→ ATLAS TA0002; OWASP LLM10

このクラウドSIEMのFirst Seen Ruleは、当社のBedrockディフェンダーガイダンスを基に作成されたもので、AWS環境において新規ユーザーが特定のBedrock API呼び出しを使用していることが検知された場合にトリガーされます。

長期間有効なキーからのクロスリージョンInvokeModel（アカウント悪用）→ ATLAS Initial Access; OWASP LLM10

この検索クエリは、複数のリージョンでBedrockリソースをインスタンス化するためにアクセスキーが再利用される可能性を特定します。

Guardrail/Trace anomalies on Bedrock Agents (OWASP LLM06, LLM04)

以下のクエリは、Bedrockエージェントからの異常なエラー率やスロットリング活動をチェックし、エージェントの不正使用の可能性を示します。

シャドーAITの外部通信（未承認のLLMエンドポイント）

以下のクエリは、プロキシおよびファイアウォールのログから、未承認のLLMエンドポイントへの接続を検索します。必要に応じて、これらのエンドポイントへの接続が許可されているユーザーのルックアップテーブルを作成し、ルックアップテーブルのパスを追加してください。

MCP監査：承認なしの高リスクツール呼び出し (OWASP LLM07/LLM08)

以下のようなアプリログを出力すると仮定します。

クエリ：

(Backed by MCP’s JSON-RPC spec and server concepts; instrument tools/list/call, resources/read, prompts/get, and user approvals.) 

ChatGPT モニタリング事例

Sumo Logicの強みのひとつはその汎用性です。当社ではターンキーアプリと検知機能を提供していますが、真の価値はお客様がプラットフォームをどのように拡張するかによって生まれます。具体例として、当社の主要プロフェッショナルサービスエンジニアの一人であるBill Milligan（ビル・ミリガン）に、顧客がOpenAIのChatGPTの利用状況を監視する支援を行った最近のプロジェクトについて共有してもらいました。この支援は、ログの取り込みから実用的な知見の抽出まで、エンドツーエンドで行われました。

顧客の課題：Sumo Logicは、会話の文脈に基づいて、ChatGPTのプロンプト交換を追跡し、潜在的な内部脅威や、職場暴力につながる可能性のあるメンタルヘルスの懸念の初期兆候を特定できるか？

ステップ1 – データ取り込み

OpenAIのエンタープライズ顧客は、ChatGPTコンプライアンスAPIを使用して、ユーザー入力、システムメッセージ、出力、アップロードされたファイル、GPT構成データを含む詳細なログとメタデータにアクセスできます。ただし、現時点では、このフィード用の事前に構築されたクラウド間コネクタやカタログアプリは存在しません（まだ！）。

Bill Milligan氏はこの問題を、APIエンドポイントを持つあらゆるデータソースを取り込むことができるSumo LogicのUniversal API Collectorを使用して解決しました。このコレクターはJPathもサポートしており、特定のJSONフィールド（例：$.user.id、$.message.text）を抽出して、Sumoの検索可能なフィールドに直接マッピングできます。

ステップ2 – シンプルなパーサーの構築

OpenAI APIからデータが正常に流れ込むようになると、Bill Milligan氏はSumo Logicの強力な組み込みパース言語に目を向けました。これにより、タイムスタンプを特定し、ベンダーや製品などのメタデータ値を割り当て、メッセージをさまざまな方法で分割および変換できるようになります。幸いなことに、パーサーは履歴データを使用してUI内で直接開発およびテストできるため、反復作業が迅速かつ可視化されます。

「パーサー」は、クラウドSIEMに転送される生のログを解析し、ベンダー、製品、イベントIDとともに、関心のあるフィールドを抽出します。

ステップ3 – スキーマまたはデータモデルへのマッピング

Sumo Logicにおいて、パースとマッピングは異なるステップです。パースの後、Bill Milligan氏はフィールドをSumo Logicのデータモデルに合わせるためのカスタムマッパーを作成しました。また、キーワード検出を容易にするために、複数のプロンプト/レスポンスのペアを単一の会話フィールド（description）に連結しました。 

プロのヒント：デフォルトでは、Sumo Logicのテナントはログメッセージを64kbに制限しています。これらの会話はかなり大規模になる可能性があるため、制限を256KBに増やすよう要求することで、ログの不要な切り捨てを回避できました。

「ログマッパー」がベンダー、製品、イベントIDを照合すると、解析エンジンによる分析前に、パーサーから抽出されたフィールドを正規化されたレコードにマッピングします。

ステップ4 – カスタムルールの作成

最後に、Bill Milligan氏は機密キーワードを監視するためのカスタム一致ルールを実装しました。ルールはノイズを減らすためにエンティティ（ユーザー）にスコープされ、文脈を把握するためにMITREタグで調整されます。ベストプラクティスに従い、ルールはライブ運用される前に、まずプロトタイプモードでデプロイされます。これにより、セキュリティアナリストが監視しているアラートのトリアージを混乱させることなく、任意のエンティティ（この場合はユーザー）に対してルールを試行させることができます。

これは、Cloud SIEMで記述可能な6つの強力なルールタイプの一つである「マッチ」ルールのルール式の一例です。  

カスタムルールにMITREタグを追加することで、Bill Milligan氏はルールがトリガーされたときに、生成されたシグナルが意味のある文脈を持つようにしました。Sumo Logicはシグナルと行動を個々のエンティティに自動的に紐付けるため、このルールは他のルールと組み合わせて、ユーザーのアクティビティを高精度で実用的なアラートへと昇格させることが可能です。

一見複雑に見えるワークフローも、明確なステップに分解することで、カスタムログソースの取り込みや高度なユースケースへの対応さえも非常に容易になります。

結論

平均的な組織では、驚くほど多くの生成AIアプリが実行されており、その多くが未承認のものです。これが減ることはなく、むしろ増えることが予想されます。シャドーITとそのより危険な派生形であるシャドーAI：チームがIT部門に一言も告げずに未検証のツール（あるいは無料のAIチャット）を導入する、陰湿な裏側。情報漏洩やバイアスの危険が山積している。 

解決策は？あなたのログが「密告者」になります。Sumo Logicのダッシュボードでネットワークフローとアプリの使用状況を監視し、影（シャドー）を早期に発見してください。「命令」するのではなく「教育」してください。統治されたAIサンドボックスを提供することで、ルールを破る者を味方に変えましょう。方向性が必要ですか？クラウドプロキシ/CASBログを使用してAIの使用状況を列挙し、AI TRiSMスタイルのガバナンスを適用し、リスクの高い組み合わせ（例：機密データクラス → 未承認のAIドメイン、エージェントツールの呼び出しの突然の急増）に対してSIEM検出を作成してください。これは、すべてのAIをブロックすることではなく、未知のものを、観測可能で統治されたものに置き換えることを目的としています。

AIセキュリティポリシーの作成方法について詳しく知る。