2026.09.16
AIシャドーITを防ぐ実践的な管理と対策
IT関連
AIシャドーITとは、会社が承認していない生成AIやAI機能を、従業員が業務で使う状態です。便利だからと個人判断で使う行為が、機密情報の流出や誤情報の拡散につながるおそれがあります。
国内企業における生成AIの業務利用率は55.2％に達しています。総務省「令和7年版 情報通信白書」が示す普及の一方で、情シス部門が把握しない利用経路も増え、従来の端末管理だけでは統制が難しくなりました。
重要なのは、利用を一律に禁止することではありません。リスクを可視化し、承認済みの安全な選択肢と明確なルールを用意することです。本記事では発見、予防、事故対応、継続改善までを実務順に整理します。
AIシャドーITとは何かを正しく理解する
シャドーITとシャドーAIの違い
AIシャドーITは、未承認のクラウドサービスや端末利用に加え、AIサービスの無断利用まで含めて捉える実務用語です。特に生成AIは入力内容と出力内容の両方にリスクがあるため、通常のSaaS管理より広い確認が必要になります。
従来のシャドーITは、個人契約のストレージ、チャット、タスク管理ツールなどが中心でした。これに対しシャドーAIでは、文章要約、翻訳、議事録作成、画像生成、コード補完といった日常業務の中に利用が溶け込みます。
区別の要点は、AIがデータを処理して新しい回答を生成する点です。入力データが学習や品質改善に使われる契約条件なら、たとえ短時間の利用でも、データ管理責任が社外へ広がる可能性があります。
- 未承認の生成AIサービスへの業務データ入力
- 個人アカウントでのAI機能付きSaaS利用
- 管理外のブラウザ拡張機能やAPI連携
なぜ現場で無断利用が増えるのか
無断利用が起きる最大の理由は、現場が成果とスピードを求められるからです。承認手続きが遅い、利用可否が分からない、会社支給ツールの機能が不足するといった状況では、従業員は使いやすい外部サービスへ流れます。
調査では、従業員の60%が自分の仕事を遂行するために独自にAIを活用しています。また77％が生成AIを今後ビジネスに最も大きな影響をもたらす技術と捉え、73％が生産性向上を期待しています。
したがって、無断利用を個人の規律だけの問題として扱うべきではありません。安全な代替手段の不足という組織課題として受け止め、現場の用途に合う承認ツールと相談窓口を整える必要があります。
- 承認プロセスが長く、業務期限に間に合わない
- 何を入力してよいかの基準が共有されていない
- 便利な無料版を個人アカウントで使い始めやすい
見落としやすい利用シナリオ
見落としやすいのは、チャット型生成AIを開く行為だけではありません。Web会議の自動文字起こし、メール作成支援、翻訳サイト、画像生成、コード補完など、既存製品に組み込まれたAI機能も確認対象です。
例えば営業担当者が顧客との打ち合わせメモを外部AIで要約すると、氏名、連絡先、商談内容、価格情報が入力されることがあります。匿名化のつもりでも、案件の組み合わせから顧客が推測される場合があります。
ブラウザ拡張機能も盲点です。閲覧ページを読み取る要約拡張や文章校正機能は、権限設定によって社内システムの画面情報に触れます。導入済みSaaSだけでなく、ブラウザとAPIを含めて棚卸ししましょう。
- 社外秘の提案書を要約・校正させる
- ソースコードや障害ログを貼り付ける
- 個人メールで無料トライアルを登録する
放置できないリスクを業務別に見極める
情報漏洩とデータ利用のリスク
最優先で防ぐべきリスクは、機密情報と個人情報の外部送信です。利用者が入力したプロンプト、添付ファイル、会話履歴はサービス提供者の環境で処理され、契約・設定次第では保持や品質改善の対象になり得ます。
入力データをAIの学習に使わない設定があっても、それだけで安全とは限りません。保存期間、管理者の閲覧権限、保存先リージョン、外部連携、退会後の削除条件まで、利用規約と企業向け契約を確認する必要があります。
個人情報保護法の観点では、委託先として適切に管理されるかを確認しなければなりません。取引先の非公開情報や営業秘密は、不正競争防止法上の保護対象となる可能性もあり、入力禁止区分を先に定めることが重要です。
- 個人情報、認証情報、顧客データは原則入力禁止
- 契約前に学習利用と保持期間を確認
- 匿名化後も再識別の可能性を評価
誤情報・権利侵害が生む品質リスク
生成AIの出力は、もっともらしく見えても正確とは限りません。ハルシネーションにより、存在しない制度、誤った数値、架空の出典が混ざることがあります。対外資料や意思決定にそのまま使えば、品質と信用を損ないます。
コード生成では、脆弱な実装やライセンス条件に合わない断片が混入するおそれがあります。画像や文章の生成物も、著作権、商標、肖像、第三者の利用規約との関係を、人が用途に応じて確認しなければなりません。
対策の基本は、AIを最終決裁者にしないことです。重要な出力には根拠確認と人手レビューを必須とし、レビュー担当者、確認観点、承認記録を業務フローに組み込みます。
- 外部公開前に事実、出典、表現を確認
- 成果物の著作権・ライセンスを確認
- 高リスク判断は専門部署が最終承認
攻撃・規制・評判に関するリスク
AI利用では、悪意ある指示によって制約を回避させるプロンプトインジェクションも問題になります。外部サイトや添付文書を参照するAIエージェントは、埋め込まれた指示を信頼して、不適切な処理を行う可能性があります。
法令や契約に違反したデータ処理は、金銭面だけでなく取引継続にも影響します。英国のデータ保護規制では、違反時に2,000万ユーロ以上、もしくは組織の前年度の全世界における収益の4%という制裁金の枠組みがあります。
事故は技術部門だけの問題ではありません。誤った回答を顧客へ送る、未公開情報が公開生成物に含まれるといった事態は、ブランド毀損を招きます。法務、広報、現場責任者を含む連絡体制を平時から決めておくべきです。
- 外部コンテンツを参照するAIの権限を最小化
- 高リスク処理には承認とログを残す
- 事故時の広報・法務連携を事前に定義
未承認AIを発見するための棚卸し手順
調査は通信・契約・端末の順で始める
未承認利用は、利用者へのアンケートだけでは発見できません。まずネットワークログ、プロキシ、DNS、SSOの記録から、外部AIサービスへのアクセス傾向を把握し、次に支払い・契約情報、最後に端末とブラウザを確認します。
SaaS管理台帳には、正式契約だけでなく、無料版、個人契約、部門契約、試験導入を分けて記載します。サービス名、利用部門、アカウント種別、入力データ、管理者、連携先を記録すれば、優先順位を判断しやすくなります。
端末確認では、ブラウザ拡張機能、デスクトップアプリ、開発環境のプラグイン、APIキーを対象にします。検知結果をすぐ処罰に使うのではなく、まず安全な移行先を示すことが、実態把握の精度を高めます。
- ネットワークログでアクセス先を抽出
- 経費精算と法人カードの明細を照合
- 管理対象端末の拡張機能を確認
検知ツールの役割を使い分ける
検知手段は一つに絞る必要はありません。CASBはクラウドサービスの利用可視化と制御、DLPは機密情報の持ち出し検知、SIEMは複数ログの相関分析、ブラウザ管理は拡張機能とWeb利用の統制に向いています。
ただし、ツール導入だけでは誤検知や運用負荷が増えます。AI利用を一律遮断すると、従業員がより見えにくい個人端末へ移ることもあります。検知対象、アラートの重要度、一次対応者を事前に設計しましょう。
少人数の情シスは、既存のSSO、Webフィルタリング、MDMのログから始める方法が現実的です。高リスクの送信を先に把握し、利用量と部門ニーズが明確になってから、専用製品の投資判断を行います。
| 手段 | 主な対象 | 主な役割 | 導入時の注意 |
|---|---|---|---|
| CASB | クラウドサービス | 可視化・アクセス制御 | 対象サービスの確認 |
| DLP | 機密情報の送信 | 検知・遮断 | 分類ルールの整備 |
| SIEM | 認証・通信ログ | 相関分析・監査 | 分析担当者の確保 |
| ブラウザ管理 | 拡張機能・Web利用 | 許可・禁止設定 | 例外申請の運用 |
- CASBはクラウド利用の可視化に有効
- DLPは機密データの送信制御に有効
- SIEMは複数の記録を横断して分析
リスク評価で対応の順番を決める
発見したサービスは、利用者数だけで優先順位を決めません。入力データの機密性、外部共有の有無、学習利用設定、管理者機能、業務への影響、代替手段の有無を掛け合わせて評価することが必要です。
例えば、公開情報のアイデア出しは比較的低リスクでも、顧客台帳を含む議事録要約は高リスクです。同じツールでも、使う部門とデータによって扱いが変わるため、用途単位の評価が欠かせません。
評価結果は、承認、条件付き承認、停止、追加調査に分類します。現場へ判断理由と代替手段を返し、例外申請の窓口を用意すれば、隠れて使う動機を減らしながら統制を進められます。
- データ分類に応じてリスクを判定
- ツールではなく用途と連携先も確認
- 判断結果と理由を利用部門へ共有
AIシャドーITを減らす利用ルールと体制
利用ポリシーは禁止事項だけで終わらせない
AIシャドーITを減らす利用ポリシーは、禁止リストだけでは機能しません。従業員が迷わず判断できるよう、許可される用途、入力禁止情報、承認済みサービス、出力の確認方法、例外申請を具体的に記載する必要があります。
入力禁止情報には、個人情報、顧客の非公開情報、認証情報、ソースコード、未公表の財務情報、契約上制限された資料を含めます。一方で、公開済み情報の構成案作成など、低リスク用途を明示すれば利用者は行動しやすくなります。
ポリシーには、ログの保存期間、監視の目的、閲覧権限、違反時の対応も定めます。監視は従業員を過度に追跡するためではなく、情報資産を守るために必要な範囲で行い、透明性を確保することが大切です。
- 入力禁止情報と許可用途を区分する
- 公開前の人手確認を必須にする
- 例外申請と相談窓口を設置する
責任分担と承認フローを明確にする
AIの審査は情シス単独では完結しません。経営層はリスク許容度と投資判断、情シスは技術評価、法務は契約・知財、コンプライアンスは規制、現場は用途と効果の説明を担う体制が有効です。
承認フローでは、申請者が利用目的、対象データ、利用者、外部連携、保存設定を提出し、関係部署が確認します。承認後も設定や用途は変化するため、導入時の一回限りではなく定期レビューを組み込みます。
ALION株式会社のように、AIを含むシステム開発を専属チームで伴走支援する外部パートナーを活用する方法もあります。自社の業務要件を整理し、RAG（Retrieval Augmented Generation）など安全な構成を検討しやすくなります。
- 経営はリスク許容度と予算を判断
- 情シスは設定・連携・ログを評価
- 法務と現場は用途の適法性・必要性を確認
教育は具体的な業務場面で行う
教育は「AIに機密情報を入れない」という抽象的な説明では不十分です。営業、採用、開発、経理など部門ごとに、実際に扱うデータを例にして、入力可否と確認手順を演習形式で伝える必要があります。
研修では、誤ったプロンプトの例、ハルシネーションを見抜く確認方法、著作権確認、プロンプトインジェクションの危険性を扱います。受講率だけでなく、理解度テストや相談件数を追うと、定着状況を判断できます。
無断利用を申告した人を直ちに責める文化は、可視化を妨げます。早期報告を評価し、問題のあるツールを安全な承認環境へ移行させることが、継続的な改善につながります。
- 部門別のデータと利用例で研修する
- 受講率と理解度を継続的に確認する
- 相談・自己申告しやすい窓口を設ける
安全な生成AI環境を技術と運用で作る
承認済み環境を現場に提供する
安全な活用を進める最も効果的な方法は、業務に使える承認済み環境を提供することです。企業向け契約、SSO、多要素認証、管理者設定、利用ログを組み合わせ、個人アカウントより使いやすい状態を目指します。
ツール選定では、学習利用を無効化できるか、データ保持を制御できるか、保存先リージョンを確認できるか、管理者が利用者を統制できるかを確認します。無料版と企業契約では、管理機能や契約上の扱いが異なることがあります。
社内文書を活用する場合は、RAG（Retrieval Augmented Generation）を用いて、必要な情報だけを検索・参照させる構成が選択肢です。元データのアクセス権限を引き継ぎ、回答根拠を確認できる設計にします。
- SSOと多要素認証で本人性を担保
- 学習利用・保持・保存先を契約前に確認
- 社内データは権限連動のRAGで参照
アクセス制御とログ設計を行う
技術対策の目的は、すべてを止めることではなく、危険な入力と不適切な連携を減らすことです。DLPで個人番号や認証情報らしい文字列を検知し、Webフィルタリングで未承認サービスへの送信を制御します。
ログには、誰が、どのサービスを、いつ利用し、どのポリシーに該当したかを記録します。ただしプロンプト全文の収集は、別のプライバシーリスクを生みます。必要性、保存期間、閲覧者を最小限に設計します。
アラートは重要度を分けます。高機密データの外部送信は即時通知、低リスクサービスへのアクセスは月次レビューとするなど、運用可能な基準にすれば、担当者が本当に危険な事象へ集中できます。
- 高機密データの送信を優先して検知
- ログの閲覧権限を最小限に設定
- 重大度に応じて通知と対応を分ける
効果をKPIで継続評価する
対策の有効性は、導入した製品数では測れません。未承認ツール数、承認済みツールへの移行率、機密情報入力の検知件数、教育受講率、検知から是正までの時間をKPIとして継続的に確認します。
検知件数が増えたからといって、直ちに状況悪化とは限りません。導入初期は可視化が進んだ結果として増えることがあります。部門別、データ分類別、再発率で推移を見て、原因と改善策を判断することが重要です。
月次で運用会議を行い、利用部門の要望、例外申請、インシデント傾向を共有します。利用者の生産性と情報保護の両方を測ることで、使われる統制へ改善していけます。
- 未承認利用数と移行率を追跡
- 検知から是正までの時間を計測
- 部門別の再発率をレビューする
無断利用が判明したときの初動と再発防止
初動は利用停止と事実確認を同時に行う
無断利用が判明したら、まず被害拡大を防ぐため、対象アカウント、APIキー、外部連携の停止を検討します。ただし、証跡を失わないよう、利用ログ、設定画面、対象ファイル、通信記録を保全してから作業することが原則です。
次に利用者へ責任追及を目的としない聞き取りを行います。いつから使ったか、どのサービスか、どのアカウントか、何を入力したか、出力をどこへ転記したかを時系列で確認し、影響範囲を特定します。
入力内容は、個人情報、営業秘密、契約上の秘匿情報、ソースコードなどに分類します。サービス側の保持設定と学習利用の有無も確認し、削除依頼の要否と追加の封じ込め策を判断します。
- 停止前後の証跡を保全する
- 利用者から時系列で事実を聞き取る
- 入力データと外部共有範囲を分類する
報告と通知の判断を組織で行う
事故の報告判断は、情シスだけで決めてはいけません。個人情報保護、契約、業界規制、顧客への影響を法務・コンプライアンス・経営層と評価し、社内規程および関係当局の手続きに沿って対応します。
顧客や取引先への連絡が必要な場合は、確認済みの事実、影響する情報、実施済みの封じ込め、今後の問い合わせ窓口を明確にします。推測や未確認情報を混ぜず、更新時刻と責任者を一本化することが信頼維持に役立ちます。
外部AIサービスに削除を求める際は、対象アカウント、会話・ファイルの識別情報、削除範囲、完了確認の方法を記録します。契約によって対応範囲が異なるため、事前の契約確認が事故時の速度を左右します。
- 法務・コンプライアンスを早期に招集
- 対外連絡は確認済みの事実に限定
- 削除依頼と回答を証跡として保管
再発防止を利用者体験まで見直す
再発防止では、個人のミスとして終わらせず、なぜ承認済み手段が使われなかったのかを分析します。申請に時間がかかった、必要な機能がなかった、ルールを知らなかったなど、利用者の行動を生んだ原因を改善します。
是正策は、ポリシー改定、承認ツール追加、DLPルール調整、部門研修、承認フロー短縮に分けて担当と期限を設定します。同じデータ分類・同じ業務で再発しないかを追跡し、対策が現場で機能するか検証します。
特に中小企業では、最初から大規模な仕組みを目指す必要はありません。30日間で棚卸しと暫定ルール、90日間で承認環境と教育、以後は月次レビューというように、負担を抑えて段階的に進める方法が有効です。
- 無断利用の背景を業務プロセスから分析
- 是正策ごとに担当者と期限を定める
- 30日間・90日間の段階計画で定着させる
まとめ
AI活用の拡大に伴い、未承認利用をゼロに近づけるには、禁止と監視だけでは足りません。データ分類、承認済み環境、教育、ログ、事故対応を結び付け、現場が安全な方法を選びやすい運用へ変えることが重要です。
要点
- 未承認AIは通信、契約、端末、ブラウザを横断して棚卸しする
- 入力禁止情報と許可用途を明示し、例外申請を用意する
- CASB、DLP、SIEM、ブラウザ管理を目的に応じて組み合わせる
- 発見時は証跡保全、影響調査、削除依頼、再発防止を順に進める
- 利用率・検知件数・是正時間をKPIとして継続改善する
まずは、自社で利用を認めるAI、入力を禁止する情報、相談先の3点を決めて周知しましょう。AIを活用した業務システムや安全なRAG環境の設計に課題があれば、開発・運用を伴走できる専門チームへ相談することも有効です。
よくある質問
Q1. AIシャドーITとシャドーAIは同じ意味ですか？
シャドーAIは未承認のAI利用を指し、シャドーITは未承認のSaaS、端末、クラウド利用などを含むより広い概念です。実務では、AI特有の学習利用、出力品質、知的財産のリスクまで確認します。
Q2. 生成AIの業務利用を全面禁止すれば安全ですか？
全面禁止だけでは、個人端末や個人アカウントへ利用が隠れるおそれがあります。入力禁止情報、承認済み環境、教育、ログ監視を組み合わせ、安全な代替手段を示す方が実効性を高めやすいです。
Q3. 無断でAIに情報を入力した従業員がいた場合、最初に何をすべきですか？
対象アカウントや連携の停止を検討しつつ、ログや設定などの証跡を保全します。その後、入力内容、利用サービス、共有範囲を確認し、法務・コンプライアンスを交えて削除依頼や報告の必要性を判断します。
Q4. 中小企業が最初に始めるべき対策は何ですか？
承認済みツールの一覧、入力禁止情報、相談窓口を明文化することから始めます。次に既存のSSO、端末管理、Webフィルタリングのログで利用実態を確認し、優先度の高い用途から承認環境へ移行します。
Q5. RAGを使えば社内情報を安全に扱えますか？
RAGは社内文書を参照させる方法として有効ですが、それだけで安全性が保証されるわけではありません。元データのアクセス権限、参照範囲、ログ、外部送信の有無、出力の人手確認を併せて設計する必要があります。
参考文献・出典
見えないAIを、管理できるAIへ。 IBM watsonx.governanceは、AI利用のリスク管理とガバナンスを支援します。 詳細 公開日 2024年10月25日  ](/) [無料で試す](/neo/trial/) *…
www.desknets.com