シャドーAIとは何か—企業が把握できていないAI利用のリスクと検出方法

従業員が業務で個人的に利用している生成 AI ツールを、組織が把握できていない状態を「シャドー AI」と呼ぶ。シャドー IT の再来とも言われるが、AI 特有の難しさがある。本記事ではシャドー AI が組織にもたらす実害、3 層での検出方法、よくある失敗パターン、そして「禁止」より圧倒的に効果の高い「正規化」アプローチを、サンプルポリシー文付きで解説する。

1. なぜシャドー AI が急増するのか

シャドー AI は次の構造的要因で必然的に発生する：

• 個人で無料アカウントが作れる：ChatGPT・Claude・Gemini・Perplexity 等
• 業務効率が即時に上がる：1 時間の作業が 10 分になる魅力は強い
• 「ちょっと試すだけ」の敷居が低い：URL を開いて貼るだけ
• 正規ルートが追いついていない：法人契約の整備、社内ツールの提供が遅れている
• 誰にも報告する必要がない：上司も使っているケースが多い

シャドー IT 時代と決定的に違うのは、「データを送信した瞬間に学習される可能性がある」 という不可逆性。法人契約の SaaS にデータを入れた場合は契約上の保護（非学習の担保等）が効くが、個人向け無料アカウントでは「入力データを学習に利用する（オプトアウト方式）」がデフォルトの規約になっているサービスが多い。

2. シャドー AI の実害

a. データ漏洩

• 顧客リスト・問い合わせ内容を「要約してほしい」と ChatGPT に投入
• 機密の M&A 資料を「校正してほしい」と AI に投入
• 社内コードを「最適化してほしい」と公開モデルに投入

これらは モデル提供者の学習データに恒久的に取り込まれうる。後から「やっぱり消して」が効かない。

b. 誤情報の業務化

• AI 生成のデータを未検証で社内資料・対外提案に組み込む
• ハルシネーションを含むコードがプロダクションに入る
• 統計情報・引用情報の捏造に気づかず社外発信

c. 規制違反

• 従業員の個人向け無料アカウント経由で、EU 顧客の個人データを米国の LLM サービスに送信（GDPR 上、米国への送信そのものが違反なのではない。法人契約で GDPR 第28条の処理者契約〈DPA〉を結び、第5章〈第44条〉の移転根拠——EU-US データプライバシーフレームワーク〈DPF〉の十分性認定〈第45条、欧州委員会決定 (EU) 2023/1795〉や標準契約条項〈SCC、第46条〉——を確保すれば適法に行える。問題になるのは、DPA がなく、移転根拠も組織として確保していない個人アカウント経由で送ること）
• 改正個情法で特定した利用目的の範囲を超えた、本人同意のない目的外利用
• 業界規制（金融・医療）下のデータを規制対応していない AI に投入

d. 再現性の喪失

• 重要な意思決定の根拠が「AI に聞いた」で、誰がどう聞いたか追跡不能
• 監査要件を満たせない
• インシデント時の影響範囲が特定できない

これらが組み合わさると、1 件のシャドー AI 利用が組織存続レベルのリスクになりうる。実際、Samsung の従業員が ChatGPT に機密ソースコードや会議録を入力して社外流出が問題化した事例（2023 年）をはじめ、シャドー AI 経由の情報漏洩は現実に発生している。

3. シャドー AI の検出方法（3 層）

Layer 1: ネットワーク層

DNS・プロキシ・SSL インスペクションで生成 AI サービスへのアクセスを抽出。

検出対象ドメインの例：

chatgpt.com
chat.openai.com
claude.ai
gemini.google.com
perplexity.ai
copilot.microsoft.com
poe.com
character.ai
（その他、月次で更新）

CASB（Cloud Access Security Broker）や SWG（Secure Web Gateway）を統合した SASE / SSE（Secure Access Service Edge / Security Service Edge）プラットフォーム（Netskope One SSE、Zscaler Internet Access、Cisco Secure Access〈Cisco Umbrella の後継〉、Palo Alto Networks Prisma Access〈Prisma SASE〉等）の生成 AI アプリ検出・制御機能を活用。

取得すべきメトリクス：

• 利用者数（部署別・ロール別）
• 利用回数・頻度
• データ送信量（サービス別）
• アクセス元 IP・端末

Layer 2: エンドポイント層

ブラウザ拡張・デスクトップアプリの利用状況、データ投入の検出。

• ブラウザ監視：エンタープライズブラウザ（Island、Palo Alto Networks Prisma Browser〈旧 Prisma Access Browser／Talon〉等）または拡張で投稿内容を可視化
• DLP（Data Loss Prevention）：送信データに機密情報が含まれているかを検出
• EDR：AI クライアントアプリの起動・利用ログ

Layer 3: アプリケーション層

業務システム経由の AI 利用を捕捉。

• API 利用ログ：社内プロキシ経由の OpenAI API 等の呼び出し
• Copilot 系プラグイン：Microsoft 365 Copilot、GitHub Copilot、Slack AI 等の利用状況
• 業務 SaaS 内 AI 機能：Salesforce Agentforce、Notion AI、Zoom AI（旧 Zoom AI Companion）等

3 層を統合して可視化する基盤が AI-SPM（AI Security Posture Management） である。

4. 検出だけでは不十分

検出した結果を放置すると、現場のフラストレーションだけが残る。検出は手段であり、目的は「正規化」。

検出後の定型アクション：

検出 → リスク評価 → 対応判断
                       │
                       ├─ 即時遮断（高リスク）
                       ├─ 警告通知（中リスク）
                       ├─ 利用記録（許容範囲）
                       └─ 正規ルート提供（業務需要あり）

ほとんどのシャドー AI 利用は「業務需要あり」のカテゴリに入る。これを正規化するのが最も効く。

5. 「禁止」より「正規化」のすすめ

シャドー AI への最も実効的な対策は、正規の代替を高品質に提供すること。

正規化の構成例

ポイントは**「無料の個人アカウントより便利」にすること**。具体的には：

• 待ち時間が短い（社内最適化）
• 結果が業務文脈に沿っている（社内ナレッジで RAG）
• データ非学習が契約で担保されている（安心感）
• 結果のコピペが既存ツールに直接組み込める（提案書 / メール / チャット）

これが達成できれば、シャドー AI は自然に消える。禁止だけでは絶対に勝てない。

6. サンプル：社内 AI 利用ポリシー（最小版）

# 社内 AI 利用ポリシー（v1.0）

## 1. 適用範囲
全従業員・契約社員・業務委託の方が、業務目的で生成 AI を利用する場合に適用。

## 2. 利用区分

### 区分 A：自由に利用可
- 公開情報のみを扱う質問・要約・翻訳
- 社内提供の正規 AI ツール（社内チャット、Copilot Enterprise 等）

### 区分 B：注意して利用
- 社内情報（公開可能なもの）を扱う場合
- → 正規ツール経由のみ。個人アカウントでの利用は禁止

### 区分 C：原則禁止（要承認）
- 個人情報、機密情報、未公開財務情報、未公開製品情報、契約書全文
- → 正規ツール経由でも、データ分類タグでブロックされる

## 3. 禁止事項
- 区分 C の情報を、無料アカウントの AI に投入すること
- 規約上「データを学習に使う」AI サービスへの業務情報投入
- AI 出力を未検証で対外資料に組み込むこと

## 4. 違反時
- 第 1 段階：注意喚起と研修
- 第 2 段階：所属長面談
- 第 3 段階：人事処分の対象

## 5. 相談窓口
- 利用したい AI サービスがあるが正規ルートにない → 情報システム部
- 業務上の判断に迷う → AITB ヘルプデスク

このシンプルな構成で、現場が判断に迷わないことが重要。複雑なポリシーは読まれない。

7. AITB が推奨する初期 3 ヶ月ロードマップ

[Month 1]
- SASE / SSE（CASB・SWG）のログから直近 30 日の AI アクセスを抽出
- 上位利用ツール TOP 5 を特定
- 利用者数・部署分布を経営層に共有（脅すためでなく、規模感の認識合わせ）

[Month 2]
- 上位 5 ツールの代替案を策定（法人契約 or 内製）
- 業務別ユースケース TOP 3 を選定し、社内チャット UI に組み込み
- AI 利用ポリシー v1.0 を策定・公開（複雑にしすぎない）

[Month 3]
- 正規ルートの社内告知＋無料社内勉強会
- AIBOM の整備開始（[AIBOM 入門記事](/articles/aibom-intro/)参照）
- 区分 C データの自動検出（DLP）
- 検出ダッシュボードを情報システム部に常設

3 ヶ月で「シャドー AI が見える化されている」「正規ルートが用意されている」「ポリシーが共有されている」状態に到達する。これが最低限の出発点。

8. KPI 設計

シャドー AI 対策の効果を測る指標：

• 正規ツール利用比率：（正規ツール経由のリクエスト数）/（全 AI リクエスト数）
• シャドー AI 検出件数の推移：月次で減少傾向か
• 区分 C データの誤投入検出件数：DLP でのブロック数
• AI 利用に関する相談件数：増加は健全（隠れず相談している証拠）
• インシデント発生件数：これが下がっているか

「シャドー AI ゼロ」を目標にすると逆効果になりがち（隠れるだけ）。「正規ツール比率の向上」を主 KPI に置くのが健全。

詳細な設計支援、AI-SPM 製品の選定、ポリシー策定の伴走は 無料相談 からご依頼ください。AITB は組織規模・業界に応じた現実的な打ち手を一緒に設計します。