SIEM・SOCでプロンプトインジェクションとシャドーAIを検知する方法 NIST・NCSC・INCDから監視設計を整理|セキュリティ対策Lab

投稿日時: 2026年09月25日更新日時: 2026年09月25日

生成AIを業務システムへ組み込む企業では、従来のマルウェアや不正ログインだけではなく、「AIへどの入力が渡されたか」「AIがどのデータを参照し、どのツールを実行したか」まで監視対象に含める必要があります。

一方、従業員が会社未承認の生成AIを利用するシャドーAIは、AIシステム側のログを取得できないケースがあります。この場合は、Proxy、DNS、CASB／SASE、IdP、DLP、Endpoint／Browserなど既存のセキュリティログから利用を把握します。

米国NIST、CISA、英国NCSC、イスラエル国家サイバー局（INCD）の公的資料を確認すると、各機関がSplunkやMicrosoft Sentinel向けの具体的なSIEMクエリを共通仕様として提供しているわけではありません。

ただし、

AIシステムと第三者サービスを棚卸しする
inference request、query、promptなどの入力を記録する
AIの出力と挙動を監視する
異常入力やadversarial inputを検知する
AIが利用するデータ、モデル、プロンプト、ログを資産として管理する
未承認クラウドサービスをCASBやSASEなどで把握する

という監視要件は公的資料から確認できます。

SOCでは、これらを単一ログではなく時系列で相関させることで、プロンプトインジェクションとシャドーAIの双方を検知しやすくなります。

結論　SIEMだけではなく5種類のログを相関する

プロンプトインジェクションとシャドーAIは、検知する場所が異なります。

リスク	主な検知場所	SIEMへ集約したいログ
直接プロンプトインジェクション	AIアプリ／AI Gateway	Prompt、User、Session、Model、Guardrail結果
間接プロンプトインジェクション	RAG／Agent／Connector	参照元URL・文書、取得データ、Tool Call、出力
AIエージェントによる不審操作	SaaS／API／Agent	Tool、Action、Target、Data Access、Approval
シャドーAI	Proxy／CASB／SASE／DNS	接続先AIサービス、ユーザー、端末、通信量
AIへの機密情報送信	DLP／CASB／Endpoint	Data Classification、Upload、POST、File
未承認AIのOAuth連携	IdP／SaaS	OAuth Consent、App ID、Scope、User
開発者の未承認AI API利用	Proxy／Cloud／Endpoint	API Endpoint、Process、Service Account、Token利用

プロンプト中に「ignore previous instructions」のような文字列があっただけで攻撃と判定する方法は十分ではありません。

間接プロンプトインジェクションでは、攻撃用の指示がWebページ、メール、PDF、チケット、ソースコードなど外部データへ埋め込まれ、利用者自身は攻撃文字列を入力しない場合があります。

そのためSOCでは、

「不審な入力」
↓
「AIの挙動変化」
↓
「機密データへのアクセス」
↓
「外部ツール実行や送信」

という一連のイベントを関連付けて確認します。

AIセキュリティ全体の管理については、以下の記事で整理しています。

NISTはAIの棚卸しとプロンプトインジェクションを明示

NISTの「Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile（NIST AI 600-1）」は、生成AIの情報セキュリティリスクとしてprompt injectionを明示しています。

NISTは直接プロンプトインジェクションだけでなく、攻撃者がWebや外部データなどAIが後から取得する情報へ命令を埋め込むindirect prompt injectionについても説明しています。

同資料のGOVERN 1.6では、組織が利用する生成AIシステムをAI資産台帳へ登録することを推奨しています。

さらに第三者のAIについて、

組織コンテンツへアクセスする第三者を棚卸しする
承認済みAI技術・サービスプロバイダーのリストを作成する

ことを挙げています。

シャドーAIをSIEMで検知するには、まず「承認済みAIが何か」という基準リストが必要です。

承認リストがなければ、SOCはAIサービスへの通信を検知できても、それが業務上許可された利用なのか、シャドーAIなのかを判断できません。

英国NCSCはPrompt・Queryのログ取得と異常入力監視を推奨

英国NCSCの「Guidelines for secure AI system development」は、AIシステムの運用段階で入力と挙動を監視するよう案内しています。

Secure operation and maintenanceでは、inference request、query、promptなどAIシステムへの入力をログへ記録し、侵害や不正利用が発生した際に監査・調査・復旧へ利用できる状態にするよう求めています。

また、out-of-distribution inputやadversarial inputの明示的な検知も例示されています。

NCSCのMachine Learning Principlesでも、AIシステムへの入力と出力を監査できるログを確保し、通常とは異なるユーザー活動を自動監視する考え方が示されています。

この考え方をSOCへ適用すると、Promptログだけではなく、

User / Agent ID
Session ID
Request ID
入力元
参照したRAGデータ
Model名・Version
Guardrail判定
Tool Call
外部API呼び出し
出力先
DLP判定
人間による承認結果

を同じトランザクションとして追跡できる構成が必要になります。

イスラエルINCDはAIコンポーネントのAIBOM管理を推奨

イスラエル国家サイバー局（INCD）は、クラウド環境でAI機能を利用する組織に対し、AIのライフサイクル全体でセキュリティ対策を実装し、利用しているAIコンポーネントの最新AIBOMを保持するよう案内しています。

AIBOMは、AIを構成するモデル、データ、ライブラリ、サービスなどを把握する考え方です。

INCDは、AIBOMを脆弱性管理へ組み込むことでリスク管理に利用できるとしています。

SIEM／SOC運用では、この考え方を「監視対象台帳」として利用できます。

たとえば、

AI資産台帳の項目	SOCでの用途
AIサービス名	承認済み／未承認の判定
Model / Version	脆弱性・挙動変更時の影響確認
API Endpoint	Proxy・Firewallログとの照合
利用部門	通常利用か異常利用かの判断
Connector / MCP	外部操作可能範囲の把握
Service Account	IdP・Cloudログとの照合
接続データ	機密情報へのアクセス判断
Owner	アラート発生時の確認先

AIBOM自体がシャドーAIを自動検知するわけではありません。

しかし、「登録済みAI」と実際のネットワーク・SaaS利用を比較すれば、管理台帳にないAIサービスを抽出できます。

プロンプトインジェクション検知で取得したいログ

プロンプトインジェクションをSOCで調査するには、AIアプリケーションのログだけでは足りません。

最低でも次の5層を関連付けます。

層	取得したいイベント
AI入力	Prompt、Query、添付ファイル、入力元、User、Session
Retrieval	RAG文書、URL、メール、チケット、検索結果、取得時刻
AI処理	Model、Version、Guardrail、Safety判定、Response
Agent／Tool	Tool名、Action、Target、Parameters、Approval
既存IT	DLP、IdP、SaaS Audit、Proxy、Firewall、EDR

特にAIエージェントでは「Tool Call」を記録しないと、プロンプトインジェクションによって実際に何が行われたのか追跡できません。

MITRE ATLASでも、LLM Prompt Injectionだけでなく、AI Agent Tool InvocationやExfiltration via AI Agent Tool Invocationが攻撃技術として整理されています。

SIEMで検知したいプロンプトインジェクションの5パターン

政府機関が以下のSIEMルールをそのまま提供しているわけではありません。

ここではNIST、NCSC、CISA、MITRE ATLASが示すリスクとログ要件を、SOC向けの相関条件へ置き換えています。

1. 不審なPromptの直後に高権限Toolが実行された

相関条件の例：

Prompt anomaly / Guardrail alert
→ 数分以内
AI Agent invokes privileged tool
→ write / delete / send / execute

このアラートでは、プロンプト文字列だけではなく、AIが実際に書き込み操作へ進んだかを優先して確認します。

2. 外部コンテンツ取得後に通常と異なるTool Callが発生した

間接プロンプトインジェクション向けです。

Agent retrieves external URL / email / document
→ 同一Session
Tool call outside expected workflow

たとえば、Web検索だけを行うエージェントが、外部ページを読み込んだ直後にメール送信やCRM更新を要求した場合です。

3. AIが機密データへアクセスした直後に外部送信した

AI accesses confidential repository
→ Sensitive data classification hit
→ External tool/API invocation

MITRE ATLASが示すAI Agent Tool経由のExfiltrationに近い挙動です。

外部送信先が新規ドメイン、個人メール、未承認SaaSであれば優先度を上げます。

4. 同一ユーザー／セッションでGuardrail違反が連続する

Repeated rejected prompts
＋ Prompt obfuscation / encoding
＋ rapid retry

単発の拒否は通常利用でも発生します。

短時間に言い換え、文字コード変換、多言語化などを繰り返しながら同じ制限を回避しようとする挙動を相関させます。

5. AIの出力異常と既存セキュリティイベントが同時に発生する

AI behavior anomaly
＋ new OAuth consent / token use / data access
＋ outbound connection

AI側の異常だけでは誤検知が多いため、Identity、Cloud、DLP、Networkのイベントと組み合わせます。

Prompt本文をSIEMへそのまま保存する場合の注意点

PromptやResponseは、インシデント調査で有力な証跡になります。

一方で、Promptには顧客情報、個人情報、ソースコード、契約内容、認証情報などが含まれる可能性があります。

NCSCもAI関連のログ自体を機密性のある資産として保護するよう案内しています。

そのため、

SIEMへ全文保存するか
機密情報をマスキングするか
Hashや分類結果だけを保存するか
SOC担当者の閲覧権限をどう設定するか
保存期間を何日にするか

を事前に決めます。

全Promptを無期限にSIEMへ蓄積する構成は、監視基盤そのものが新しい機密情報集約先になります。

シャドーAIはCASB・Proxy・IdP・DLPから検知する

英国NCSCはShadow IT Guidanceで、許可なく使われるAI技術をshadow AIとして明示しています。

同ガイダンスでは、未承認クラウドサービスの把握手段としてCASB、SASE、UEM、Network Scanner、Asset Managementなどを挙げています。

特にCASBについて、ネットワーク通信を監視して利用中のクラウドサービスを把握し、未承認サービスの利用を識別できると説明しています。

2026年9月にNCSCが公開した「The hidden risks of shadow AI」でも、組織の承認プロセスに含まれていないAI利用をshadow AIと定義しています。

SOCでは「AIサービスへアクセスした」だけで即インシデントにするのではなく、承認状況と送信データを組み合わせます。

SIEMで検知したいシャドーAIの5パターン

1. 承認リストにないAIサービスへのアクセス

Proxy / CASB category = Generative AI
＋ destination not in approved_AI_services

最初に作るルールです。

ただし閲覧だけで情報漏洩とは判断せず、利用者、通信方向、アップロードの有無を確認します。

2. 未承認AIへのファイルアップロードとDLP検知

Unsanctioned AI domain
＋ HTTP upload / large POST
＋ DLP = confidential / personal / source code

シャドーAI検知の中でも優先度を上げやすいパターンです。

「未承認AIを見た」ではなく「機密データを送った可能性がある」イベントへ絞れます。

3. 未承認AI SaaSへのOAuth Consent

New OAuth application
＋ AI service
＋ unapproved App ID
＋ high-risk scopes

AIサービスがメール、ファイル、カレンダー、GitHubなどへOAuthで接続される場合、Webアクセスだけを監視していても実態を把握できません。

IdPやSaaS側のOAuth同意ログをSIEMへ連携します。

4. 開発端末から未承認AI APIへ継続通信

Developer endpoint / server
＋ new AI API endpoint
＋ recurring POST
＋ service account or API token usage

CLI、IDE拡張、コード生成ツール、Agent Frameworkなどはブラウザを使わないため、Webフィルタだけでは見逃します。

Endpoint、DNS、Proxy、Cloud Workloadのログも対象にします。

5. 未承認AIブラウザ拡張機能の利用

Browser extension inventory
＋ unapproved AI extension
＋ access to corporate SaaS

ブラウザ拡張は、閲覧中のWebページや入力内容へアクセスできる権限を持つ場合があります。

UEMやEndpoint Managementで拡張機能を棚卸しし、許可リスト外を監視します。

シャドーAI検知には限界がある

CASBやSASEを導入しても、すべてのシャドーAIを検知できるわけではありません。

NCSCは、暗号化通信を復号・中継しない構成では、CASBから個人アカウント利用などサービス内の具体的な行動まで確認できない場合があると説明しています。

また、

個人スマートフォン
モバイル回線
自宅端末
個人契約のAI
AI機能を内包する一般SaaS
ローカルLLM

は企業ネットワークのProxyログだけでは見えない場合があります。

したがって、シャドーAI対策は「ネットワークで全てブロックする」だけでは成立しません。

承認済みAIを用意し、利用申請を簡単にし、DLPやIdPなど複数のログを組み合わせます。

関連：業務に潜むシャドーAIとは-見えない生成AIが企業にもたらすリスクとは

SIEMへ正規化したいAIセキュリティのフィールド

製品ごとにログ形式が違う場合でも、SIEM上では共通フィールドへ正規化すると相関しやすくなります。

フィールド	内容
`user_id`	AI利用者
`agent_id`	AI Agent／Service Identity
`session_id`	AI会話・処理単位
`request_id`	API／Inference処理単位
`ai_service`	利用AIサービス
`model_name`	Model名
`model_version`	Model Version
`input_source`	User、Web、Mail、RAG、File等
`source_uri`	取得元URL・Repository
`data_classification`	Public、Internal、Confidential等
`guardrail_result`	Allow、Block、Review
`tool_name`	AIが呼び出したTool
`tool_action`	Read、Write、Delete、Send、Execute
`target_resource`	操作対象
`approval_result`	Human approval結果
`destination`	外部送信先
`sanction_status`	Approved／Unsanctioned
`device_id`	利用端末
`src_ip`	接続元
`event_time`	時刻

Prompt全文を共通フィールドに必ず保持する必要はありません。

組織の情報分類とプライバシーポリシーに合わせ、必要な場合だけRestricted Log Storeへ分離する方法もあります。

SOCでのトリアージ手順

AI関連アラートが発生した場合は、「Promptに怪しい文字列があったか」だけで終わらせません。

まず対象サービスが承認済みか、ユーザーと端末が正規かを確認します。

次に同一Session／Requestで、外部コンテンツ取得、Guardrail判定、機密データアクセス、Tool Call、外部通信を時系列で並べます。

プロンプトインジェクションが疑われる場合は、攻撃指示がユーザー入力から来たのか、Web・メール・文書・RAGなど間接経路から来たのかを分けます。

実際にToolが実行されていた場合は、

変更されたファイル
送信されたメール
作成・変更されたSaaSレコード
外部通信先
利用されたToken
Agent／Connectorの権限

を確認します。

シャドーAIの場合は、アクセスの有無だけではなく、送信されたデータ区分、ファイルアップロード、OAuth権限、継続利用の有無を調査します。

SOCで最初に実装するなら4段階で進める

最初からAI専用SIEMルールを大量に作るより、段階的に可視化します。

第1段階　AIサービスの棚卸し

NISTのAI System Inventory、INCDのAIBOMの考え方を使い、

承認済みAI
API Endpoint
利用部門
Owner
Connector
Service Account
扱うデータ区分

を登録します。

第2段階　シャドーAIの利用可視化

Proxy、DNS、CASB／SASEからAIサービス利用を抽出し、承認リストと照合します。

この段階ではブロックより、実際に誰が何を使っているかを把握します。

第3段階　機密データ送信と権限利用を相関

DLP、IdP、SaaS Auditを追加します。

「未承認AIへのアクセス」から、

「未承認AIへ機密データを送信」
「未承認AIへOAuthで業務データを接続」

まで判別できる状態にします。

第4段階　AI AgentのPrompt・Retrieval・Toolを監視

自社AIや企業向けAgentでは、

Prompt → Retrieval → Model → Tool → Data → Destination

を1つのSessionとして追跡できるようにします。

AIエージェントのIDと権限管理については、以下の記事でも整理しています。

SIEM製品より先にログ設計を決める

Splunk、Microsoft Sentinel、Google Security Operationsなど、どのSIEMでも相関ロジック自体は実装できます。

差が出るのは、SIEM製品よりも「上流から何のログを取得できるか」です。

Promptログがなく、Tool Callも残らず、AIのSession IDとSaaS監査ログを結び付けられない状態では、SIEM側で高度な相関ルールを作っても間接プロンプトインジェクションの調査は困難です。

逆にシャドーAIでは、AIサービス側からログを取得できなくても、CASB、Proxy、IdP、DLP、Endpointを組み合わせれば利用実態を把握できるケースがあります。

企業が最初に確認したいのは、

「AI専用SOC製品を導入するか」ではなく、

「承認済みAIの台帳があるか」
「AI入力・出力・Tool Callを記録できるか」
「未承認AIへの通信を把握できるか」
「機密データ送信をDLPで判定できるか」
「AI Agentと人間のIdentityを区別できるか」

SIEM・SOCでプロンプトインジェクションとシャドーAIを検知する方法　NIST・NCSC・INCDから監視設計を整理

結論　SIEMだけではなく5種類のログを相関する

NISTはAIの棚卸しとプロンプトインジェクションを明示

英国NCSCはPrompt・Queryのログ取得と異常入力監視を推奨

イスラエルINCDはAIコンポーネントのAIBOM管理を推奨

プロンプトインジェクション検知で取得したいログ