>
>
公開日
最終更新日
シャドーAIは、生成AIの普及に伴って急速に増えている情報セキュリティ課題です。従業員が無料のAIチャットに議事録やソースコードを貼り付けるケースだけでなく、業務用アカウントで外部AIへOAuth連携するケース、SaaSに追加されたAI機能を無自覚に使うケースも含まれます。
対策の出発点は、未承認利用を見つけた部門に業務目的を聞くことです。業務用ID、端末、ネットワーク、SaaS連携のログを照合し、用途に合う公式環境へ移します。本記事は、50名未満の兼任情シスから300名超の専任チームまで、組織規模に応じて実行できるシャドーAI対策を整理します。
シャドーAIとは｜BYOAIとの境界線
シャドーAIとは、組織が審査・承認・管理していないAIサービスやAI機能を、従業員が業務目的で利用する状態です。
本記事のポイント：
シャドーAIは、未承認のAIチャット、ブラウザ拡張機能、AIエージェント、OAuth連携を含む管理外のAI利用です。
無償版や個人契約のAIに入力したデータが学習に利用されるかは、提供者・契約・設定・地域で異なるため、サービスごとのデータ利用条件を確認して判断します。
対策は一律禁止ではなく、利用実態の可視化、安全な公式AI環境、技術的制御、継続監査を組み合わせて実施します。
管理職の利用は入力データの重要度が高いため、一般社員と同じ教育だけでは不十分です。
シャドーAIは「ChatGPTを使ったかどうか」だけで判定しません。個人契約のAIチャットに顧客情報を入力する行為、業務用Google WorkspaceやMicrosoft 365のIDで未審査アプリへログインする行為、ブラウザ拡張機能にWebページの読み取り権限を与える行為、SaaSの新しいAI機能を契約・設定の確認なしに使う行為はいずれも対象になります。
シャドーAIの判定基準
判定の軸は「AIを使っているか」ではなく、「組織がデータ、権限、ログ、契約条件を把握しているか」です。承認済みの法人契約であっても、利用目的やデータ区分を超えて使えばリスクは残ります。反対に、個人所有のAIであっても、会社が利用条件、端末管理、退職時のアカウント処理、監査ログ、データ保存場所を定めて管理しているなら、管理された持ち込み利用として扱える場合があります。
BYOAIは「Bring Your Own AI」の略称として使われますが、業界で統一された厳密な定義がある用語ではありません。そのため、オプトアウト設定だけで安全なBYOAIと判断するのは危険です。学習利用の停止設定があっても、保持期間、第三者提供、越境移転、管理者によるログ取得、退職者のアクセス停止、個人端末の暗号化などは別に評価します。
データ利用条件と追加学習の違い
「AIに入力した情報は必ず学習され、他社へ出力される」という説明は正確ではありません。提供者によっては、法人向け契約やAPI利用において、顧客データを基盤モデルの学習に利用しない条件を明示しています。一方で、無償サービスや個人向けプランでは、設定や利用地域によって会話内容が品質改善やモデル改善に利用される可能性があります。
情シスでは、各AIサービスについて利用規約だけでなく、プライバシーポリシー、データ処理契約、学習利用の設定、保存期間、管理ログ、データ所在を台帳化します。学習利用が停止されていることを確認できても、顧客情報や営業秘密を無制限に入力してよいわけではありません。入力可能なデータは「公開情報」「社内一般情報」「個人情報・契約情報・営業秘密」のように区分し、最後の区分は原則入力禁止と決める運用が実務的です。
無断利用が把握される仕組み
「シャドーAIはバレるのか」と考える従業員もいますが、会社支給端末や業務用IDを使う限り、利用痕跡は複数の場所に残ります。Secure Web Gatewayの通信ログ、IdPのログイン履歴、Google WorkspaceやMicrosoft Entra IDのOAuth同意履歴、端末管理ツールのアプリ一覧、ブラウザ拡張機能の導入履歴が代表例です。
ただし、個人スマートフォンを私用回線で使ったアクセスまで常に把握できるわけではありません。見つけにくい利用を罰するより、業務で使える公式環境と相談窓口を用意し、利用を管理下へ戻す設計が必要です。無断利用に起因するデータ流出の防止策は、生成AIやChatGPTの利用に伴う情報漏洩リスクと具体的な対策でも確認できます。
管理職・役員層における高リスク利用
管理職・役員層は、経営会議資料、人事評価、未公表の業績、組織再編、M&A、重要顧客との交渉情報を扱います。一般社員と同じ頻度のAI利用でも、1件の入力が与える影響は大きくなります。管理職がシャドーAIを利用する場面は、全社ガイドラインが整備されている企業でも確認されており、入力データの重要度が高いことから影響範囲が大きくなりやすい点が課題です。
管理職への対策は、抽象的な注意喚起では機能しません。「取締役会資料の要約は禁止」「公開済みのプレスリリースを基にした文章案作成は許可」「人事評価をAIに入力する場合は匿名化済みの公式環境に限定」といった業務場面ごとの判断例を示します。承認されたAI環境でも、役員・人事・法務のデータを扱う部門は別ポリシーに分けると、例外判断が速くなります。
▲ 業務で利用するAIサービスが「シャドーAI」に該当するかを判定するフロー
シャドーITとシャドーAIの根本的な決定差
シャドーITとシャドーAIはどちらも未承認サービスの利用ですが、AIは入力データの変換、推論、外部連携、自律実行を伴うため、管理対象が広がります。
従来のシャドーITには、個人契約のクラウドストレージ、チャット、ファイル共有、プロジェクト管理ツールなどがあります。シャドーITも、公開共有設定の誤り、誤送信、退職者アカウントの放置、連携アプリへの過剰権限付与、ベンダー侵害によって情報漏洩を起こします。「不正アクセスがなければ安全」とは言えません。
シャドーAIでは、これらに加えて、入力内容がプロンプトとして処理されること、AIが誤った回答を生成すること、外部ツールや社内APIへアクセスすることが新しい論点になります。特にエージェント型AIは、閲覧だけでなくファイル作成、メール送信、チケット登録、データベース更新まで実行できるため、権限設計が中心課題になります。
比較項目 | シャドーIT | シャドーAI |
|---|---|---|
主な対象 | 未承認のストレージ、チャット、業務SaaS | AIチャット、生成AI機能、AIエージェント、AI拡張機能 |
主な漏洩経路 | 誤共有、公開設定、退職者アカウント、ベンダー侵害 | プロンプト入力、ファイル添付、外部連携、会話履歴、AIの自律実行 |
主な完全性リスク | 誤更新、同期ミス、権限設定ミス | ハルシネーション、プロンプトインジェクション、誤った自動処理 |
権限管理の重点 | アカウント、共有範囲、退職時の停止 | アカウント、OAuthスコープ、APIキー、エージェント実行権限 |
監査の重点 | サービス一覧、利用者、共有設定、ログイン履歴 | 利用者、入力可能データ、プロンプトログ、連携先、実行ログ |
思考プロセスの外部化
AIに資料を要約させたり、企画案を比較させたりする行為では、ファイルそのものだけでなく、判断の前提、顧客名、課題、価格、優先順位がプロンプトに含まれます。これは単なるファイル保管とは異なる情報の外部化です。営業資料を匿名化しても、案件時期、地域、製品仕様、取引条件の組み合わせから取引先が推測される場合があります。
そのため、データ分類はファイル名や個人情報の有無だけで決めません。「公開済みか」「契約上の守秘義務があるか」「競争上の優位性を含むか」「人事・医療・金融など規制対象か」という観点で分類します。AIに渡す前に匿名化する場合も、再識別可能性を含めて評価します。
データシャドーイングと間接プロンプトインジェクション
データシャドーイングとは、本記事での作業用定義として、利用者が直接入力したデータ以外に、AIが連携先から取得した情報や会話履歴、添付ファイルのメタデータなどが、意図しない形で処理対象に入る状態を指します（業界統一の定義がある用語ではありません）。たとえば、メール要約AIに受信箱への広範なアクセス権を与えると、依頼したメール以外の情報がAIの処理範囲に入る可能性があります。
間接プロンプトインジェクションは、Webページ、文書、メールに埋め込まれた悪意ある命令をAIが取り込み、本来の指示を逸脱する攻撃です。「この文書を要約して」と依頼したAIが、文書内の隠れた指示に従って外部送信や不正な操作を試みるケースが想定されます。外部Web検索や社内SaaSへの書き込み権限を持つAIエージェントでは、読み取り専用から始め、書き込み・送信は人間の承認を必須にします。
▲ 従来のシャドーITとシャドーAIにおける管理対象・リスク・対策の対比
企業におけるシャドーAI起因のセキュリティインシデント事例
シャドーAIの被害は、機密データの入力、認可設定の不備、AI出力の無検証利用という三つの経路で発生します。
事例は、特定のAI製品が危険であることを示すものではありません。どのサービスでも、データ分類、権限、利用者教育、承認手順が欠ければ、同様の問題が起こり得ます。以下では公式発表または広く確認されている報道に基づく事例と、実務上の再発防止策を分けて紹介します。
【実在事例】Samsungの機密情報入力事例
Samsung Electronicsでは2023年3月、半導体部門の従業員がChatGPTにソースコードや社内会議に関わる情報を入力した事案が、Bloomberg・Reuters等の複数の海外メディアで報じられました。Samsungはその後、従業員による生成AI利用を制限する方針を示しました。この事例が示すのは、利用者に悪意がなくても、デバッグ、要約、翻訳といった日常業務が機密情報の外部入力につながる点です。
再発防止では「ソースコードを入力しない」と記載するだけでは足りません。開発者が使える社内コード補完環境、承認済みモデル、秘密情報を検出するDLP、リポジトリへのアクセス範囲を用意します。公式環境が遅い、利用回数が少ない、必要な言語に対応していない状態では、現場は個人アカウントへ戻りやすくなります。
OAuth連携による権限拡大
AIサービスへ「Googleでログイン」や「Microsoftでログイン」を使うと、認証だけでなくメール、カレンダー、ファイル、連絡先などへのアクセス権限を要求される場合があります。OAuthの同意画面で許可したスコープは、パスワードを共有しなくても外部アプリが業務データへアクセスできる仕組みです。
Vercelなど開発者向けサービスを狙った認証情報窃取やサードパーティ連携を悪用する攻撃は、開発環境におけるトークン管理の重要性を示しています。個別事案をシャドーAIそのものが原因と断定するのではなく、AIを含む外部アプリ連携で過剰な権限を与えないことが対策の要点です。業務用IDで外部AIを利用する場合は、管理者承認済みアプリのみを許可し、メール全件・ドライブ全件への恒久的アクセスを原則禁止します。
ハルシネーションの無検証利用
生成AIはもっともらしい誤情報、架空の出典、存在しない機能を出力することがあります。法務、経理、医療、採用、顧客対応では、誤った出力が契約、請求、意思決定、差別、風評に直結します。AIの出力をそのまま顧客へ送る行為は、情報漏洩がなくても品質事故になります。
対策は、用途別に人間のレビュー責任者を決めることです。社内文章の下書きは利用者本人の確認、対外文書は部門責任者の確認、法令・契約・財務・人事判断は専門担当者の確認を経て公開します。参照元URLや根拠資料の提示が必要な業務では、AIの回答を根拠とせず、一次資料に遡る手順を残します。
医療・製薬分野における想定リスクシナリオ
臨床試験データの無断アップロードを特定企業の実在事故として扱うことはできません。しかし、医療・製薬分野では被験者情報、治験データ、研究計画、承認申請資料に厳格な管理が必要です。無料AIに症例情報を貼り付けて要約した場合、個人情報、機微情報、契約上の秘密、規制提出前情報が混在する可能性があります。
この分野では、匿名化済みデータでも再識別リスクを検討し、利用できるモデル、保存地域、ログ保持、委託先、アクセス権を文書化します。監査ログを取得できないAIサービスは、規制対象データを扱う業務では利用範囲を公開情報の編集補助などに限定します。
実際に発生したトラブルを起点に対策を深掘りする場合は、実際に発生したシャドーAI起因のセキュリティインシデント事例と予防策も参照してください。
社内で発生し得るリスクをより詳しく把握したい場合は、シャドーAI起因のセキュリティインシデント事例と防止策もあわせてご確認ください。
情シスが導入すべき技術的なシャドーAI検知手法
シャドーAIは一つの製品では検知しきれないため、通信、ID、端末、データ、APIの五層を組み合わせて把握します。
製品を選ぶ前に、検知対象を決めます。AIチャットの利用、OAuth連携、ソースコード送信、AIエージェントの実行履歴では、必要なログと制御手段が異なります。
通信ログによるAI利用の可視化
NetskopeやZscalerのようなCASB、Secure Web Gatewayは、支給端末や社内ネットワークからアクセスされるAIサービスを可視化する手段です。未承認AIのドメイン、通信量、アップロード傾向を把握し、業務用途と考えられる利用を優先調査できます。NetskopeはAIアプリの可視化やデータ保護機能を提供し、Zscalerは生成AI利用時のデータ保護を案内しています。
ただし、TLS復号の範囲、BYOD、私用回線、テザリング、VPN外通信は設計上の対象外になり得ます。通信監視だけで「全利用を把握できる」と判断せず、IDログや端末管理の結果と照合します。監視の目的、対象、保存期間、閲覧できる担当者は就業規則や個人情報保護の観点から明文化します。
業務用IDとOAuth同意の監査
Google Workspace、Microsoft Entra ID、Oktaなどの管理画面では、業務用IDが許可した外部アプリを確認できます。OktaでシャドーAIを防止する場合は、アプリカタログの許可リスト化だけで終わらせず、OAuth同意ポリシー、管理者承認フロー、危険なスコープの検知、退職・異動時のトークン失効を組み合わせます。
まず、メール読み取り、ファイル全件アクセス、オフラインアクセス、組織データの編集といった高リスク権限を一覧化します。高リスク権限を要求する未承認アプリが見つかった場合は、利用者へ業務目的を確認し、代替手段があるならトークンを失効させます。監査ログを取得できるなら、同意日時、利用者、権限、アクセス先を月次でレビューし、取得できなければ管理対象のAIを限定します。
端末とブラウザ拡張機能の統制
ブラウザ拡張機能は、閲覧ページや入力欄を読み取れる権限を持つ場合があります。文章校正、翻訳、会議要約、画面キャプチャ、コード補完の機能は便利ですが、処理対象のテキストが外部へ送信される可能性を評価しなければなりません。Microsoft Intune、Jamf、MDM、EDRなどで、会社端末に導入できる拡張機能とアプリを制御します。
開発部門では、IDE拡張機能、ローカルAIアプリ、CLI型AIツールも棚卸し対象です。ソースコードの送信を止めたい場合は、リポジトリ、端末、ネットワークの各層で検知します。端末側の制御は誤検知や業務阻害を起こすこともあるため、最初は監査モードで利用実態を確認し、影響が大きいルールから段階的に遮断します。
AI GatewayとDLP連携の実装条件
Cloudflare AI GatewayやKong AI GatewayのようなAI Gatewayは、LLM APIへの通信を集約し、認証、利用量、ログ、ルーティングを管理する仕組みです。Gatewayを設置しただけで、すべてのプロンプトを自動的にマスキング・遮断できるわけではありません。
プロンプトDLPを実現するには、対象アプリケーションの通信をGateway経由に強制するネットワーク設計、個人APIキーを使わせない認証設計、検査対象となるデータの定義、DLP製品またはポリシーとの連携、暗号化通信の扱い、例外申請手順が必要です。APIを使う社内アプリでは効果を発揮しやすい一方、従業員がブラウザで個人契約AIを使う通信は別の対策が必要です。
製品カテゴリ別の選定基準
カテゴリ | 代表例 | 主な把握対象 | 導入前に決める条件 |
|---|---|---|---|
CASB・SWG | Netskope、Zscaler、Cloudflare One | AIドメインへの通信、アップロード、Web利用 | 復号範囲、私用回線の扱い、遮断基準 |
情報保護 | Microsoft Purview | 機密ラベル、DLPアラート、Microsoft 365内の利用 | 機密区分、検知語、誤検知時の手順 |
SaaS管理 | ジョーシス、マネーフォワード Admina | アカウント、SaaS利用、連携状況 | 連携するIdP、棚卸し頻度、退職時の停止 |
AI Gateway | Cloudflare AI Gateway、Kong AI Gateway | API経由のAI利用、コスト、ログ | 経由強制、APIキー管理、DLP連携 |
生成AIの社内利用を可視化する具体的な進め方は、生成AIの社内利用状況を可視化してシャドーAIを検知する具体的な手順でも整理しています。
具体的に社内でのログ収集や可視化を進める際は、生成AIの利用状況を可視化してリスクを防ぐ具体的手順を参考にしてください。
2026年に急増するシャドーエージェントとSaaS組み込み型AI
2026年のシャドーAI対策では、対話型AIだけでなく、社内外のデータへ接続して動くAIエージェントとSaaS標準搭載AIを管理対象に含めます。
生成AIは、チャット画面に質問する段階から、カレンダー、メール、ストレージ、CRM、チケット管理、開発環境を横断して処理する段階へ広がっています。Model Context Protocolのような仕組みを利用すると、AIが外部ツールやデータソースへ接続しやすくなります。その便利さは、権限設計と監査が不十分な場合に、データ流出や誤操作の範囲を広げます。
シャドーエージェントの権限リスク
シャドーエージェントとは、情シスや管理者が把握しないまま稼働し、外部サービスや社内データに接続するAIエージェントです。利用者が「議事録を要約するだけ」と考えて導入しても、実際にはカレンダーの閲覧、会議録画の取得、メール送信、ファイル作成の権限を要求する場合があります。
エージェントは、最初から書き込み権限を与えません。検証段階では読み取り専用、接続先はテスト用データ、外部送信とデータ削除は人間承認、実行ログは一定期間保存という制約を設けます。業務システムの更新を任せる場合は、実行前後の差分を記録し、ロールバック手段を用意します。
いつの間にか追加されるSaaSのAI機能も管理対象にする
DeepL、Grammarly、Canva、Notionなど、従来から利用しているSaaSやブラウザ拡張機能には、AI機能が追加・拡張され続けています。契約時にはAI機能がなかったとしても、更新後に文章生成、要約、検索、会議録作成、画像処理が有効になることがあります。これを「いつの間にかAI」として扱い、SaaSの更新情報と管理設定を定期的に確認します。
確認する項目は、AI機能の有効・無効、処理対象データ、学習利用の有無、データ保持、管理者ログ、利用者ごとの権限、地域設定です。契約プランや地域によって提供範囲が異なるため、ベンダーの管理者向け公式ドキュメントで確認できれば限定検証に進み、確認できなければ機密データを扱う部門では有効化を見送ります。
AI利用台帳の更新手順
AIを含むSaaSは、年1回の棚卸しでは変化に追いつきません。月次で新規OAuth同意と高リスク権限を確認し、四半期ごとにAI機能の追加・契約変更・データ処理条件を見直します。台帳には、サービス名、利用部門、利用目的、データ区分、契約プラン、管理者、認証方法、連携先、保存期間、ログ有無、次回見直し日を記録します。
この台帳があれば、AI機能の追加を見つけた際に、どの部門へ確認し、どのデータが影響を受け、停止か限定利用かを短時間で判断できます。AIガバナンスの体制設計は、自律型AI時代に対応するためのAIガバナンス体制の構築ステップも参考になります。
国内外で強化されるAIガバナンス法規制の最新動向
AI関連法規制は用途と事業者の役割によって適用範囲が異なるため、シャドーAI利用を最大制裁金と直接結び付けず、実際の利用目的から評価します。
法規制対応では、自社が提供者か利用者かで確認事項が変わります。情シスは、利用中のAI、用途、扱うデータ、EU市場・顧客との接点をAI台帳に記録します。
EU AI Actの適用時期と実務影響
EU AI Actは2024年8月1日に発効したEU規則です。適用は段階的で、禁止されるAI慣行に関する規定は2025年2月から、一部の汎用AIモデルに関する規定は2025年8月から適用されます。透明性義務を含む多くの規定は2026年8月2日から適用されています。法令本文はEU AI Actの公式法令で確認できます。
第50条の透明性義務は、特定の対話型AI、生成コンテンツ、感情認識・生体分類などに関わる事業者へ影響します。日本企業でも、EU市場へAIシステムを提供する場合、EU域内の利用者へ出力を提供する場合、またはEU内で利用される出力を生み出す場合には、域外適用を検討します。ただし、社内従業員が未承認AIを使っただけで直ちに最高額の制裁金が課されるわけではありません。
EU AI Actの制裁金は違反類型により異なり、最大3,500万ユーロまたは全世界年間売上高の7%という上限は、禁止されたAI慣行など最も重い違反区分に関するものです。自社のAI利用が高リスク用途に当たるか、EU向けサービスの透明性義務に関係するかは、用途、提供者・導入者としての役割、対象国、違反内容で判断します。EU向けに採用、人事評価、与信、教育、重要インフラなどのAIを提供・利用する企業は、法務と連携して個別評価します。
日本のAI法とAI事業者ガイドライン
日本では、人工知能関連技術の研究開発及び活用の推進に関する法律が2025年6月に公布・施行されました。この法律は、AIの研究開発・活用を推進する枠組みを定めるもので、一般企業のシャドーAI利用に対して直接の罰則を設ける法律ではありません。政府のAI事業者ガイドラインは、事業者に対して安全性、公平性、プライバシー保護、セキュリティ、透明性、アカウンタビリティの考え方を示しています。
法令上の直接義務と、取引先が求めるセキュリティ質問票は区別します。B2B取引では、顧客がAI利用状況、データの学習利用、委託先、アクセス管理、事故対応を確認する場合があります。質問票に対応する必要がある企業では、AI台帳、利用規程、教育記録、OAuth監査記録、インシデント対応手順を整備しておくと、回答根拠を示しやすくなります。
ISO/IEC 42001の活用範囲
ISO/IEC 42001は、AIマネジメントシステムに関する国際規格です。認証取得はすべての企業に必須ではありませんが、AIを自社サービスの中核に組み込み、顧客監査や海外取引で管理体制の説明が必要な企業では、統制の枠組みとして役立ちます。50名未満でAI利用が限定的な企業は、規格認証から始めるより、AI台帳、データ分類、承認フロー、教育の四点を先に整備します。
ISO 42001の考え方や管理システムの構成は、国際基準に準拠したAI管理システムを定めたISO 42001の解説ガイドで確認できます。
法規制への対応にとどまらず自社の規律を構築したい場合は、社内体制や評価基準を整えるAIガバナンス推進完全ガイドをご参照ください。
シャドーAI対策で陥りやすい失敗パターンと防止策
シャドーAI対策で失敗しやすいのは、利用を止める仕組みだけを先に導入し、現場の業務を代替する手段を用意しないケースです。
ルールが存在するだけでは行動を変えにくいため、実際の利用場面に合わせた技術と運用が必要です。
公式環境なき一律禁止
AIチャットのURLを遮断し、「業務でのAI利用は禁止」と通知するだけでは、私用スマートフォン、テザリング、自宅PC、個人アカウントへの移行を招きます。利用は見えなくなり、事故が起きても早期報告されにくくなります。これがダークシャドーAI化です。
禁止が必要なデータ区分は明確にします。一方で、公開情報の要約、定型文の下書き、アイデア出し、プログラムの一般的な説明など、低リスク業務には公式AI環境を提供します。安全な代替手段があるなら、利用者は管理外のサービスへ移りにくくなります。
URLフィルタリングへの過信
URLフィルタリングは有効な手段ですが、AIチャットのドメインを一つ止めても、SaaS内のAI機能、ブラウザ拡張機能、IDE、API、個人回線経由の利用には対応できません。URL遮断は入口対策の一つであり、ID、端末、DLP、利用規程と組み合わせます。
特に開発部門では、CLI、IDE拡張、Git連携、APIキーによる利用が残りやすいため、Web閲覧ログだけで利用実態を評価しません。OAuth同意、端末アプリ、API利用量、リポジトリの秘密情報検出を合わせて確認します。
ガイドラインの放置
長いPDFをイントラネットに置くだけでは、現場は判断できません。ガイドラインには、入力禁止情報、許可用途、確認が必要な用途、利用可能な公式ツール、外部連携の申請先、違反時の報告窓口を一枚で分かる形にまとめます。
たとえば「顧客名を含むメールを要約したい」「採用候補者の履歴書を比較したい」「ソースコードのエラーを調べたい」という具体例について、入力可否と代替案を示します。AIサービスや契約条件は変化するため、最低でも四半期に一度、利用部門と内容を更新します。規程作成の土台には、社内ルール策定にそのまま使える生成AI利用ガイドラインの作成テンプレートを使えます。
監視の目的外利用
通信やOAuthの監視を導入すると、従業員は「行動を常に監視される」と感じることがあります。監視対象、目的、保存期間、閲覧権限、アラート後の対応を説明せずに導入すると、信頼を損ねます。監視ログを人事評価や懲罰のために安易に転用すると、事故報告が遅れる要因にもなります。
利用者への通知では、「機密情報の流出防止と安全な公式環境の改善」が目的であることを示し、ログへのアクセスを必要最小限の担当者に限定します。検知結果は、初回から処罰に結び付けず、業務目的とデータ区分を確認して是正する流れを基本にします。
ルールなしの禁止による形骸化を防ぎ安全な利用を促すには、生成AIの社内ガイドライン策定と運用ルール雛形を活用した規定づくりが有効です。
安全な生成AI利用を実現する4段階の対策ロードマップ
シャドーAI対策は、可視化、代替環境、規程、継続監査の順に進めると、利用を隠れた状態から管理可能な状態へ移しやすくなります。
初日からAI Gatewayや大規模CASBを導入する必要はありません。従業員数、扱うデータ、業務用IDの統制状況に応じて、最初の対策を決めます。
期間の目安 | 段階 | 実施内容 | 完了判定 |
|---|---|---|---|
第1週 | 可視化 | AIサービス、OAuth連携、端末拡張機能、利用目的を棚卸しします。 | 未承認AIと高リスク権限の一覧があります。 |
第2〜4週 | 代替環境 | 公式AI、SSO、データ区分、申請窓口を整備します。 | 低リスク業務で使える公式手段があります。 |
第2か月 | 規程・教育 | OK・NG例、OAuth権限上限、例外申請、レビュー責任を定めます。 | 部門ごとの利用判断ができます。 |
第3か月以降 | 監査・改善 | ログレビュー、権限失効、利用者アンケート、規程更新を継続します。 | 新規AI利用を定常運用で審査できます。 |
第1段階の可視化
最初の一週間では、完璧な全数把握を目指しません。業務用IDのOAuthアプリ一覧、請求明細にあるAIサービス、ブラウザ拡張機能、部門ヒアリングを使い、利用頻度とデータ重要度が高いサービスを優先します。確認項目は、利用者数、用途、入力データ、連携先、認証方式、契約プラン、管理者、ログの有無です。
可視化の結果、個人情報・営業秘密・ソースコードを扱う未承認AIが見つかった場合は、即時遮断だけで終わらせません。業務停止の影響を確認し、公式環境へ移す期限、データ削除依頼、OAuthトークン失効、代替ツール提供をセットで実施します。
第2段階のセキュアな代替環境
代替環境は、業務の代表的な需要に合わせます。文章作成が中心ならSSOと管理ログを備えた法人向けAI、開発が中心ならコードを扱う範囲と秘密情報検出を備えた環境、社内文書検索が中心ならアクセス権を継承できる検索・要約環境を用意します。すべてを一つのAIに集約する必要はありませんが、利用者が迷わないよう公式窓口を一本化します。
AI Gatewayを採用する場合は、API通信をGatewayへ経由させ、部門ごとのAPIキーを会社管理に切り替えます。DLP検知の精度が確認できるなら、まず個人情報や秘密鍵など明確なパターンから遮断し、誤検知の多い自由記述は監査モードで調整します。
第3段階の規程と責任分担
規程では、情シスがすべての出力内容を承認する体制を目指しません。情シスはID、端末、ネットワーク、ログ、承認フローを管理し、利用部門は用途の妥当性、入力データの分類、出力の事実確認を担います。法務、人事、情報セキュリティ、個人情報保護部門は高リスク用途の判断基準を整えます。
例外申請では、利用目的、対象データ、必要な権限、保存期間、出力の利用先、責任者、終了予定日を記録します。期限付きで許可し、期間終了時に継続・停止・公式環境への移行を判断すると、例外が恒久化しません。
第4段階の継続監査
監査では、未承認サービスの発見数だけをKPIにしません。公式AIへの移行率、OAuth高リスク権限の削減数、教育受講率、事故報告から初動までの時間、利用者の満足度も確認します。遮断件数だけを追うと、利用者が隠れる方向へ動くためです。
50名未満では、経営者または兼任情シスがAI台帳とOAuthアプリ一覧を月次確認し、公式ツールを一つに絞る運用から始めます。50〜300名では、部門責任者をAI利用窓口にし、SSO、端末管理、四半期監査を組み合わせます。300名超では、CASB・DLP・IdP・SaaS管理を連携し、AIエージェントの権限審査とインシデント対応演習を定例化します。
今週から使える即行動チェックリスト
✅ 業務用IDで許可されているOAuthアプリを出力し、メール・ストレージ全件アクセス権を持つアプリを確認します。
✅ 未承認AIを利用している部門へ、禁止通知ではなく利用目的と入力データを聞き取ります。
✅ 公開情報、社内一般情報、個人情報・営業秘密の三段階で、AIへの入力可否を決めます。
✅ 低リスク業務に使える公式AI環境と、例外申請の窓口を公開します。
✅ 監視対象、保存期間、閲覧権限を従業員へ通知し、月次のログレビュー担当を決めます。
取引先のセキュリティ確認にも備える場合は、SCS評価制度の要件をクリアするためのセキュリティ対策チェックリストを使い、AI対策を含む統制状況を整理できます。
対策ロードマップとあわせて自社やサプライチェーンのセキュリティ評価を高めたい方は、SCS評価制度★3取得チェックリストを活用して管理体制をご確認ください。
▲ 安全な生成AI利用を実現する4段階の対策ロードマップ
よくある質問
シャドーAI対策で判断に迷いやすい論点を、実務で使える基準で回答します。
Q：シャドーAIは個人用スマートフォンからの利用でも検知できますか？
A：社内ネットワークや管理対象端末を経由しない個人スマートフォンの利用は、CASBやSWGだけでは把握できません。業務用データの私用端末への保存を禁止し、公式AIを業務用IDで提供することで、管理外利用を減らします。
Q：無償版AIで学習利用をオフにすれば、業務利用しても安全ですか？
A：学習利用の停止は一つの条件にすぎません。保存期間、管理ログ、データ所在、退職時のアカウント停止、契約上の責任分担を確認できなければ、個人情報や営業秘密の入力は許可しません。
Q：SaaSに標準搭載されたAI機能もシャドーAIに該当しますか？
A：情シスが機能の有効化、処理データ、契約条件、管理ログを把握していなければ、管理外AIとして扱います。既存SaaSの更新時にAI機能が追加されるため、四半期ごとに設定とデータ利用条件を見直します。
Q：OktaなどのIdPだけでシャドーAIを防げますか？
A：IdPはOAuth同意やSSOアプリを統制するうえで有効ですが、個人アカウント、私用端末、ブラウザ拡張機能、APIキー利用までは単独で網羅できません。通信、端末、SaaS管理、利用規程を組み合わせて運用します。
Q：AI Gatewayを導入すればプロンプトの機密情報をすべて遮断できますか？
A：AI Gatewayが監視できるのは、原則としてGateway経由に強制したAPI通信です。DLP連携、検知ルール、個人APIキーの禁止、ブラウザ利用への別対策がなければ、全経路の遮断にはなりません。
まとめ
シャドーAIは、未承認のAIチャットだけではなく、OAuth連携、ブラウザ拡張機能、SaaS標準AI、AIエージェントまで含む管理課題です。対策では、全利用を禁止するよりも、業務用IDのOAuthアプリ一覧を出力し、高リスク権限を持つ未承認アプリを特定することから始めます。そのうえで、入力可能なデータ区分と公式AI環境を定め、利用者が安全な経路を選べる状態を作ります。明日着手するなら、まず業務用IDに接続された外部アプリの棚卸しと、部門別のAI利用目的の聞き取りを行ってください。
本記事の内容に誤り等がございましたら、こちらからご連絡ください。
監修
Admina Team
情シス業務に関するお役立ち情報をマネーフォワード Adminaが提供します。
SaaS・アカウント・デバイスの管理を自動化し、IT資産の可視化とセキュリティ統制を実現。
従業員の入退社対応や棚卸し作業の工数を削減し、情報システム部門の運用負荷を大幅に軽減します。
中小企業から大企業まで、情シス・管理部門・経営層のすべてに頼れるIT管理プラットフォームです。
