シャドーAI対策の全体設計 発見と封じ込めの判断基準

シャドーAIとは、組織の承認を経ずに従業員が私的に利用する生成AIサービスを指します。Copilot・Gemini・ChatGPT・Claudeといった主要サービスの無料版が広く使われるなか、業務データが意図せず外部へ送信されるリスクは避けられません。シャドーAI対策は「発見」と「封じ込め」の二段構えで設計する必要があり、どこまで止めてどこから認めるかの判断基準が統制の要になります。この記事では、私物アカウント利用の検出手段・封じ込めの判断フレームワーク・例外管理の運用設計を段階的に示します。

シャドーAI対策の全体像 発見と封じ込めの設計構造

シャドーAI対策は次の3層で構成されます。第一層は「発見」、第二層は「封じ込め」、第三層は「例外管理」です。発見だけでは対策として不完全であり、封じ込めの判断基準と例外の承認フローまで含めて初めて統制が成立します。

第一層の発見では、プロキシログ・エンドポイント監視・認証ログの3つの観測点から、組織管理外のAIサービスへのアクセスを検出します。プロキシログは通信先のURLとドメインを記録し、エンドポイント監視はデバイス上でのアプリケーション起動を捉え、認証ログは組織アカウント以外のログイン試行を記録します。この3つを組み合わせることで、ブラウザ経由・デスクトップアプリ経由・モバイル経由の全経路を捕捉できます。

第二層の封じ込めでは、検出したアクセスを「即時遮断」「警告の上で継続許可」「全面許可」の3区分に振り分けます。この振り分けは、送信されるデータの機密度・利用目的の業務適合性・代替手段の有無という3軸で判断します。即時遮断は機密情報を含む通信、警告の上で継続許可は業務目的が明確で代替手段がない場合、全面許可は学習目的など機密性の低い用途です。

第三層の例外管理では、封じ込めルールから外れる利用を承認する手続きを設けます。例外申請には「利用目的」「送信データの範囲」「利用期間」「終了後の削除確認」の4項目を記載させ、承認者は情報システム部門と法務部門の両方を含めます。例外の承認記録は監査証跡として保管し、定期的に利用実態を再評価します。

私物アカウント検出の3つの観測点

私物アカウントの検出には、プロキシログ・エンドポイント監視・認証ログの3つの観測点を組み合わせます。単一の手段では検出漏れが発生するため、複数の観測点を重ねることで精度を高めます。

プロキシログは、社内ネットワークから外部への通信を記録するプロキシサーバーのログです。ChatGPT（chat.openai.com）・Claude（claude.ai）・Gemini（gemini.google.com）といった主要サービスのドメインへのアクセスを検出し、通信量と頻度から業務利用かどうかを推定します。ただしプロキシログは、モバイル回線やテザリング経由の通信は捕捉できません。

エンドポイント監視は、従業員のデバイス上で動作するアプリケーションを記録します。デスクトップ版のChatGPTアプリやClaude for Desktopといったネイティブアプリは、プロキシを経由しない通信を行うため、エンドポイント監視なしでは検出できません。Microsoft Defender for EndpointやCrowdStrike Falconといったエンドポイント保護製品は、インストール済みアプリのリストとプロセス起動履歴を収集します。

認証ログは、組織が管理するIDプロバイダー（Microsoft Entra ID・Google Workspace等）のログインログです。従業員が組織アカウントで外部サービスにシングルサインオン（SSO）を試みた場合、認証ログに記録が残ります。ただし私物アカウントで直接ログインした場合は、組織の認証ログには残りません。この場合はプロキシログとエンドポイント監視で補完します。

封じ込めの判断基準 3軸での振り分け設計

検出したシャドーAI利用を封じ込めるかどうかは、次の3軸で判断します。データの機密度・利用目的の業務適合性・代替手段の有無です。この3軸を組み合わせることで、一律遮断と全面放置の中間にある「条件付き許可」の領域を設計できます。

データの機密度は、送信される情報が個人情報・営業秘密・取引先情報のいずれかに該当するかで判定します。該当する場合は即時遮断の対象とし、該当しない場合は次の軸へ進みます。機密度の判定は、データ分類ラベル（Microsoft Purview Information Protection・Google Cloud DLP等）と連携させることで自動化できます。ラベル付けされていないデータは、送信先のサービスが学習に利用するかどうかで判断します。

利用目的の業務適合性は、従業員がそのサービスを業務のどの工程で使っているかを確認します。文書作成・コード生成・データ分析といった業務工程に直結する場合は、代替手段の有無を評価します。業務との関連が不明確な場合は、利用者へのヒアリングを実施し、目的を記録します。

代替手段の有無は、組織が承認済みのツールで同じ作業が完結するかを判定します。たとえばCopilotの有償ライセンスが配布されている環境では、ChatGPTの私物アカウント利用は代替手段ありと判断されます。一方、組織が生成AIサービスを一切提供していない場合は、代替手段なしとして条件付き許可の対象となります。ただし代替手段なしと判定した場合でも、機密情報の送信は禁止します。

技術的な封じ込め手段と制約

封じ込めの判断が固まったあと、技術的な実施手段を選びます。主な手段はプロキシ遮断・アプリケーション制御・データ損失防止（DLP）の3つです。それぞれ制約があるため、組み合わせて運用します。

プロキシ遮断は、特定のドメインへのアクセスを遮断する方式です。ChatGPT（chat.openai.com）やClaude（claude.ai）といったサービスのドメインをブロックリストに登録し、社内ネットワークからのアクセスを止めます。ただしモバイル回線やテザリング経由のアクセスは遮断できません。完全な封じ込めを目指す場合は、モバイルデバイス管理（MDM）と組み合わせて、会社支給端末からのテザリングを禁止します。

アプリケーション制御は、エンドポイント上で特定のアプリケーションの起動を禁止します。Microsoft Defender Application ControlやAppLockerを使い、ChatGPTデスクトップアプリやClaude for Desktopの実行を阻止します。この方式はネイティブアプリに対して有効ですが、ブラウザ経由のアクセスには効果がありません。ブラウザ経由の利用を止めるには、プロキシ遮断と併用します。

データ損失防止（DLP）は、機密情報を含む通信を検出して遮断します。Microsoft Purview DLPやGoogle Cloud DLPは、送信データの中身を検査し、個人情報や機密ラベルが付与されたファイルの送信を止めます。ただしDLPはHTTPS通信の中身を検査するため、SSL復号化の設定が必要です。復号化の負荷とプライバシーへの影響を考慮し、対象範囲を絞ります。

例外管理の運用設計

封じ込めルールを設けたあとも、業務上やむを得ない理由で私物アカウント利用を認める場合があります。この場合は例外申請の手続きを用意し、承認記録を監査証跡として残します。例外を無制限に認めると統制が形骸化するため、申請要件と承認基準を明確にします。

例外申請には次の4項目を必須とします。第一に利用目的です。どの業務工程で、どのような成果を得るために使うかを具体的に記述させます。第二に送信データの範囲です。個人情報・営業秘密・取引先情報を含まないことを申請者に確認させ、違反時の責任を明記します。第三に利用期間です。例外は恒久的な許可ではなく、期限付きの一時措置として扱います。第四に終了後の削除確認です。利用終了時に、サービス側へ送信したデータを削除する手順を申請者へ説明させます。

承認者は情報システム部門と法務部門の両方を含めます。情報システム部門は技術的なリスク（データの送信先・学習利用の有無・監査ログの取得可否）を評価し、法務部門は契約条件と個人情報保護法への適合性を確認します。両部門の承認を得られた申請のみを許可します。

例外の承認記録は、承認日・申請者・利用目的・期限をデータベースへ記録し、期限到達時にアラートを出します。期限到達後も利用が継続されている場合は、再申請を求めるか、アクセスを遮断します。また四半期ごとに例外リストを棚卸し、代替手段が提供された場合は例外を取り消します。

発見から封じ込めまでの実施手順

シャドーAI対策を実施する手順は次の6段階です。第一段階は現状把握、第二段階は観測点の整備、第三段階は判断基準の策定、第四段階は封じ込め手段の実装、第五段階は例外管理の運用開始、第六段階は定期的な見直しです。

第一段階の現状把握では、既存のプロキシログ・エンドポイント監視ログ・認証ログを分析し、どのサービスが使われているかを洗い出します。ChatGPT・Claude・Gemini・Perplexityといった主要サービスのドメインとアプリ名をリストアップし、利用頻度と通信量を集計します。この段階ではまだ遮断せず、実態を記録することに集中します。

第二段階の観測点の整備では、不足している観測手段を追加します。プロキシログが取得できていない場合はプロキシサーバーの導入を検討し、エンドポイント監視が未実施の場合はエンドポイント保護製品を導入します。すでに導入済みの製品がある場合は、ログの保存期間と検索性能を確認し、必要に応じてSIEM（Security Information and Event Management）へログを集約します。

第三段階の判断基準の策定では、データの機密度・利用目的の業務適合性・代替手段の有無の3軸を組織の実情に合わせて定義します。データ分類ラベルがすでに運用されている場合は、ラベルごとの送信可否を決めます。ラベルが未運用の場合は、個人情報・営業秘密・取引先情報の3種類を送信禁止データとして定義します。また組織が提供する承認済みツールのリストを作成し、代替手段の有無を判定する基準とします。

第四段階の封じ込め手段の実装では、プロキシ遮断・アプリケーション制御・DLPの3つを段階的に適用します。最初はプロキシ遮断から始め、ブラウザ経由のアクセスを止めます。次にアプリケーション制御でネイティブアプリの起動を禁止し、最後にDLPで機密情報の送信を検出します。すべてを同時に実装すると影響範囲が大きくなるため、段階的に進めます。

第五段階の例外管理の運用開始では、申請フォーム・承認フロー・期限管理の仕組みを用意します。申請フォームはSharePointやGoogle Formsで作成し、承認フローはPower AutomateやGoogle Apps Scriptで自動化します。期限管理は、承認記録をデータベースへ登録し、期限到達時にメールでアラートを送る仕組みを組みます。

第六段階の定期的な見直しでは、四半期ごとに例外リストを棚卸し、封じ込めルールの妥当性を確認します。新しい生成AIサービスが登場した場合は観測対象に追加し、組織が承認済みツールを導入した場合は代替手段ありと判定します。また封じ込め手段の誤検知が多発している場合は、判断基準を見直します。

統制設計の前提依存性

シャドーAI対策は、組織が従業員へ提供するツールの範囲に依存します。組織が生成AIサービスを一切提供していない場合、私物アカウント利用を全面禁止すると業務が停止するため、条件付き許可の範囲を広く取る必要があります。一方、組織がCopilotやGeminiの有償ライセンスを全員へ配布している場合、私物アカウント利用の必要性は低くなり、封じ込めの範囲を広げられます。

統制設計は、この前提が変わるたびに見直す必要があります。たとえばCopilotの有償ライセンスが一部にしか配布されていなかった時期には、ライセンス未配布の従業員に対してChatGPTの私物アカウント利用を条件付きで認めていた組織があります。その後ライセンスが全員へ配布された結果、ChatGPTの私物アカウント利用を即時遮断の対象へ変更しました。このように、統制の思想ではなく装置の置き場所と判断基準を、前提の変化に合わせて組み替えます。

また監査ログの取得範囲も、組織の承認が得られる権限に依存します。たとえばMicrosoft Purviewの監査ログを取得するには監査ロールの付与が必要ですが、このロールはメール等の閲覧権限を含むため、社内承認が得られない場合があります。この場合は監査ログの取得を諦め、プロキシログとエンドポイント監視で代替します。技術的に取得できるログと、実際に取得を許可されるログは一致しないため、承認が得られる範囲で設計します。

削除基準の設計と撤回の判断

シャドーAI対策の一環として、長期間使われていない私物アカウントを削除する基準を設ける場合があります。ただしこの基準は、低頻度で稼働する業務の存在を考慮しなければ成立しません。たとえば90日間未使用のアカウントを一律削除する基準を設けた場合、半年に1回だけ稼働する業務のアカウントまで削除されてしまいます。

削除基準を設計する際は、未使用期間だけでなく利用頻度のパターンを分析します。毎日アクセスするアカウント・週次でアクセスするアカウント・月次でアクセスするアカウント・四半期ごとにアクセスするアカウントといった利用パターンを、過去のログから抽出します。このパターン分析の結果、低頻度稼働のアカウントが一定数存在する場合は、未使用期間による一律削除を撤回します。代わりに、アカウント作成時に利用目的と想定頻度を申請させ、申請内容と実際の利用頻度を照合する方式へ変更します。

検証結果が出る前に削除基準を決定すると、このような手戻りが発生します。削除基準の策定は、ログの分析結果を材料として先に出し、その後で判断します。決定を急がせる前に、検証結果を提示する順序を守ります。