シャドー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版シャドーITですが、さらに過激な一面も持ちます。AIは単にデータを処理するだけでなく、そこから学習し、突飛な出力を幻視し、最も機密性の高いシステムにアクセスし、時には親戚一同で集まった時に、うっかりと秘密を漏らしてしまう叔父さんのように振る舞ってしまいます。

急増の理由AIが急速に民主化しているところに原因があります――ツールが今や非常に身近になり、技術に詳しくない人でもタスクを自動化するエージェントや、プロのようにコードを書くコパイロットを簡単に立ち上げられるようになりました。しかし監視がなければ、データ漏洩からコンプライアンス上の悪夢に至るまで、企業全体にリスクの死角を生み出しています。 

近い将来、リーダーたちが「あのアプリケーションがAIを使っているとは知らなかった」と語る事後会議の話を耳にするでしょう。あるいは「誰がAIをそのように使用することを許可したのか？」とか。闇に光をもたらすには、チームのAI戦略に積極的に関与し、イノベーションを支援しつつ、過度な摩擦を生じさせることなく、適切な統制とガバナンスを構築する必要があります。 

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

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

AI TRiSM

AI TRiSMはArtificial Intelligence Trust, Risk, and Security Managementの略です。Gartnerによって提唱されたこのフレームワークは、AIシステムがライフサイクル全体を通じて信頼性が高く、コンプライアンスに準拠し、安全であることを保証するために設計されています。平たく言えば、Trustは「AIがどのように意思決定を行うのか説明できますか？」と尋ねているのです。それは公平で、信頼性が高く、偏りがないと言えるでしょうか？Riskは何が問題になる可能性があるかを扱います。データ漏洩、幻覚、敵対的ハッキング、規制上の問題を思い浮かべてください。Securityは、モデル、データ、およびそのインフラストラクチャを攻撃、悪用、または不正アクセスからどのように保護するかを扱います。

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

NISTのAIリスク管理フレームワークは、ガバナンスのGPSのような存在であり、マップ（リスクの特定）、測定（リスクの定量化）、管理（リスクの軽減）、ガバナンス（全体の見守り）といった中核機能を備えています。シャドーAI対策として、環境内の不正なAI利用をマッピングし、データ漏洩率などの指標でリスクを測定するとともに、AIシステム向けのインシデント対応要件を遵守します。

MITRE ATLAS 

これはAIシステムに対する敵対的プレイブックであり、MITRE ATT&CKに類似していますが、機械学習の脅威に特化して調整されています。データポイズニング（悪意ある者がトレーニングデータを改ざんする手法）やモデル回避（AIを誤った判断に誘導する手法）といった戦術を明らかにします。ATLASを使用して、ログをそのマトリクスと照合することでシャドーAIのリスクを評価します。例えば、不正なコパイロットにおける回避手法を示唆する可能性のある異常なAPI呼び出しを検出します。

OWASP Top 10 for LLM Apps (2025 更新)

この資料は、大規模言語モデル（LLM）特有の脆弱性を列挙しています。例えばプロンプトインジェクション（モデルを乗っ取る巧妙な入力）や機密情報漏洩（出力における個人識別情報（PII）の流出）などです。シャドーAIシナリオでは、従業員が知らず知らずのうちにこれらを引き起こす可能性があります。例えば、マーケティングチームが承認されていないLLMアプリを使用し、過信（幻覚的な出力を盲信すること）に陥りやすい状態にある場合、それが悪いビジネス判断につながることがあります。

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

クラウド/モデルAPI 

まずはAWS Bedrock（シャドーAI実験の温床）などのサービスからAPIログを収集することから始めます。例えば、converseコールとconverse_streamコールを監視します。入力/出力トークン、レイテンシ、分あたりの呼び出し数などのメトリクスを追跡します。 

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

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

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

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

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

エージェント（自律型AI実行体）はAPIとの対話を好みます。ログパターンを使用して、予期しないAPIキーや地理的位置情報など、異常な動作をフラグ付けします。「機械学習サプライチェーン侵害」といった戦術（例：怪しいモデルハブからのダウンロードを示すログ）を検知することで、MITRE ATLASと連携させます。エンドポイント/CLI/プロキシ上で、シェル履歴と外部向けDNS/HTTP通信をキャプチャし、公衆LLMやエージェントバックエンド（例：api.openai.com、api.anthropic.com、*.hf.space、*.perplexity.ai、*.deepseek.com）への不正な呼び出しを検知します。

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

MCPは、LLMアプリケーションがJSON-RPCを介してツール、リソース、プロンプトに接続する方法を標準化します。監査には貴重な情報です：ツールのログ/一覧、ツールの呼び出し、リソースの読み取り、プロンプトの取得、ユーザー承認、およびクライアント/サーバー間の相関ID。最新の仕様書では、ログ記録、機能ネゴシエーション、セキュリティ上の考慮事項が明示的に要求されています。これらを活用してください。

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

ここで強調すべきは、シャドーAITと内部脅威の境界線は、あっという間に曖昧になり得るという点です。従業員がAIを活用して革新的な取り組みを行う一方で、潜在的なセキュリティリスクに気づいていない場合や、AIを利用した悪意のある攻撃者の被害に遭うこともあるのです。これらのパターンと検知は、その背後にある意図にかかわらず、チームを支援することができます。

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

一見無害に見えるプロンプトが、エージェントに高リスクなツール（例：シークレットの読み取り、アクションの実行）を呼び出させます。通常のチャットリクエストの直後に、機密性の高いツール/コールまたはBedrock Agentアクションが表示されます。

ログ記録とアラート対象

• ビジネスコンテキストやユーザー承認フラグと一致しない、機密ツール（シークレット、本番環境API）へのMCPツール／コール
  
• 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はSumo LogicのユニバーサルAPIコレクターを使用してこの問題を解決しました。このコレクターはAPIエンドポイントを持つあらゆるデータソースを取り込むことができます。このコレクターはJPathもサポートしており、特定のJSONフィールド（例：$.user.id、$.message.text）を抽出して、Sumoの検索可能なフィールドに直接マッピングできます。

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

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

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

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

Sumo Logicでは、解析とマッピングは別々のステップです。解析後、BillはフィールドをSumoのデータモデルに整合させるカスタムマッパーを作成しました。また、キーワード検出を容易にするため、複数のプロンプト/応答ペアを単一の会話フィールド（説明）に連結しました。 

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

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

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

最後に、Billは機密キーワードを監視するためのカスタムマッチルールを実装しました。ルールはノイズを低減するためエンティティ（ユーザー）にスコープされ、文脈に合わせてMITREタグで調整されます。ベストプラクティスに従い、ルールは本番運用前にまずプロトタイプモードで展開されます。これにより、セキュリティアナリストが監視しているアラート選別プロセスを混乱させることなく、あらゆるエンティティ（この場合はユーザー）に対してルールを適用できるようになります。

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

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

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

結論

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

ソリューションは？ログが密告者：Sumo Logicダッシュボードでネットワークフローとアプリ使用状況を監視し、影の存在を早期に発見しましょう。命令ではなく、教育しよう。管理されたAIサンドボックスで、ならず者を味方につけるのです。方向性が知りたいですか？クラウドプロキシ/CASBログを活用してAI利用状況を把握し、AI向けTRiSMスタイルのガバナンスを適用するとともに、リスクの高い組み合わせ（例：機密データクラス→許可されていないAIドメイン、エージェントツール呼び出しの急激な増加）に対するSIEM検知ルールを作成します。これは、あらゆるAIを遮断することよりも、未知のものを観察可能で管理されたものに置き換えることなのです。

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