シャドーAIは「禁止すれば消える問題」ではない

会社が認めていない生成AIやAIエージェントを、従業員が業務で使ってしまう。

これが「シャドーAI」です。

以前のシャドーITであれば、個人でSaaSを契約する、勝手にクラウドストレージを使う、部門独自でツールを導入する、といった話が中心でした。

しかし、シャドーAIはそれより厄介です。

AIは単なる道具ではありません。入力された情報を解釈し、要約し、変換し、判断材料を作り、場合によっては外部システム操作まで行う存在だからです。

だから、シャドーAI対策は「会社が選んだAIだけを使わせる」という発想だけでは限界があります。

これから必要なのは、AI利用を前提に、データ、権限、ログ、責任、レビュー、インシデント対応を設計することです。

シャドーAIは一部社員の問題ではない

シャドーAIは、すでに一部の意識の低い従業員だけの問題ではなくなっています。

ITProが報じたGartnerの分析では、サイバーセキュリティ責任者の69%が、従業員が禁止されたAIツールを使っている疑い、または証拠があると回答したとされています。また、2030年までに約40%の企業が、シャドーAIに起因するセキュリティまたはコンプライアンス上のインシデントを経験する可能性があるとも報じられています。

ここから見えるのは、企業がAI利用を止められていないということだけではありません。

現場で何が使われ、どのデータが入力され、どの業務判断や成果物に影響しているかを可視化できていない、という問題です。

さらに、PagerDuty調査を紹介したTechRadarの記事では、一般従業員の72%、上級職の77%が「自分たちはIT部門よりAIを理解している」と考えているという結果も紹介されています。

この数字が示すのは、IT部門と現場の認識ギャップです。

IT部門は「リスクがあるから制限したい」と考える。

現場は「公式ツールが使いにくいから、自分で便利なAIを使いたい」と考える。

このズレを放置すると、AI利用は地下化します。

なぜシャドーAIは広がるのか

シャドーAIが広がる理由は単純です。

現場にとって、AIは便利だからです。

IT技術者や情シスの日常業務だけでも、AIが効く場面は多くあります。

• 仕様書の要約
• 議事録の整理
• コードレビュー
• SQL生成
• 障害報告書の下書き
• 問い合わせメールの返信案
• Excel関数の作成
• ログ解析の補助
• 設計書のレビュー
• テスト観点の洗い出し

しかも、個人向けAIサービスは使いやすい。

UIは洗練され、応答も速く、導入手続きも不要です。

一方で、会社が正式導入したAIは、認証が面倒、使える機能が限られる、社内データに接続されていない、モデルが古い、プロンプト制限が強すぎる、といったことがあります。

ここで重要なのは、従業員が必ずしも悪意で使っているわけではないことです。

多くの場合、業務を早く終わらせたい、品質を上げたい、学習したい、顧客対応を改善したい、という自然な動機から使っています。

だからこそ、禁止だけでは効きません。

公式AIが不便で、個人向けAIの方が明らかに便利であれば、現場は公式ルートを迂回します。

シャドーAIの本当のリスクは「AIを使うこと」ではない

シャドーAIの議論では、「機密情報をChatGPTに入れてしまう」という話がよく出ます。

もちろん、それは重大なリスクです。

しかし、IT技術者の視点では、もう少し分解して考える必要があります。

データ漏えい

ソースコード、設計書、顧客情報、障害ログ、契約情報、認証情報、未公開の経営情報などが、外部AIサービスに入力される可能性があります。

OWASP Top 10 for Large Language Model Applicationsでも、Sensitive Information DisclosureはLLMアプリケーションの主要リスクとして整理されています。

問題は、社員が「これは機密情報だ」と認識しないまま、ログやコード断片、議事録、顧客問い合わせ内容を貼り付けてしまうことです。

プロンプトインジェクション

AIは自然言語を命令として処理します。

外部文書、Webページ、メール、チケット、ログ、PDFなどに悪意ある指示が埋め込まれていると、AIが本来のルールを無視したり、不適切な出力を返したりする可能性があります。

OWASPも同じく、Prompt InjectionをLLMアプリケーションの代表的なリスクとして位置づけています。

特にAIエージェントが外部情報を読み、メール送信やAPI実行まで行う場合、プロンプトインジェクションは単なる出力の乱れでは済みません。

操作リスクになります。

判断のブラックボックス化

現場がAIで作った要約や分析をそのまま業務判断に使うと、どの情報を根拠に、どの前提で判断したのかが追跡しにくくなります。

これは、監査、品質保証、障害分析、説明責任の観点で問題になります。

AIが出した結論ではなく、その結論がどの入力、どの参照情報、どのプロンプト、どのモデル、どのバージョンから生まれたのかを追跡できる必要があります。

AIエージェントによる実行リスク

2026年時点では、AI利用は単なるチャットにとどまりません。

メール送信、チケット更新、コード生成、クラウド操作、データベース問い合わせ、RPA連携などを行うAIエージェントが広がっています。

この段階になると、問題は「AIが正しい答えを返すか」ではありません。

AIにどの権限を与え、どの操作を許し、どこで人間が承認するかです。

「禁止」だけでは逆効果になる

従来型の対策は、次のようなものでした。

• 会社が認めたAIだけを使う
• 個人向けAIは禁止
• 機密情報を入力しない
• 未承認サービスへのアクセスを遮断する

これらは必要です。

しかし、それだけでは不十分です。

現場にとって公式AIが使いにくければ、個人アカウント、ブラウザ拡張、モバイルアプリ、無償SaaS、部門契約ツールへ流れます。

完全禁止にすると、利用実態が地下化し、IT部門から見えなくなります。

AxiosのシャドーAI報道でも、企業がAIツールを全面禁止しても十分に機能せず、セキュリティチームは利用を統制する方向へ移っていると説明されています。

IT技術者が考えるべき方向は、「使うな」ではありません。

安全に使える経路を用意し、危険な使い方を検知し、用途ごとにリスクを制御することです。

これはゼロトラストの考え方に近いです。

すべてを信用しない。しかし、業務は止めない。

アクセスを文脈で判断し、ログを取り、権限を絞り、継続的に監視する。

AI利用にも同じ発想が必要です。

AI利用台帳から始める

最初にやるべきことは、AI利用の可視化です。

どの部署が、どのAIサービスを、何の業務で、どのデータと組み合わせて、どの成果物に使っているのか。

これを把握しないまま、いきなり高度なAIガバナンスを作っても機能しません。

実務上は、次のような台帳が必要です。

管理項目	確認すべき内容
AIサービス名	ChatGPT、Claude、Gemini、Copilot、社内LLM、部門SaaSなど
利用部門	開発、運用、営業、法務、人事、マーケティングなど
利用目的	要約、翻訳、コード生成、分析、FAQ、エージェント実行など
入力データ	公開情報、社内情報、機密情報、個人情報、顧客情報、ソースコードなど
出力の使い道	参考情報、社内文書、顧客提出物、業務判断、システム実行など
権限	誰が使えるか、どのデータにアクセスできるか
ログ	プロンプト、応答、添付ファイル、操作履歴を残すか
リスク分類	低・中・高、または業務影響度別
承認者	IT、セキュリティ、法務、業務責任者など
代替手段	公式AIで代替可能か、専用環境が必要か

この台帳は、単なる棚卸しではありません。

AIに関するCMDBのような役割を持ちます。

シャドーAI対策の第一歩は、禁止リストを作ることではなく、現場が本当に何に困ってAIを使っているのかを把握することです。

データ分類とDLPをAI前提で見直す

シャドーAI対策では、従来のDLPをそのまま適用しても不十分です。

AIへの入力は、メールやファイル転送のように単純ではありません。

たとえば、次のようなケースがあります。

• ソースコードの一部を貼り付ける
• 障害ログを要約させる
• 顧客問い合わせ内容を整形させる
• 議事録音声をAI文字起こしにかける
• 社内資料をPDFでアップロードする
• チケット情報をAIエージェントに読ませる
• RAGで社内文書を検索させる

これらはすべて、「ファイルを外に送った」ほど明確ではありません。

しかし、実質的にはデータ流出や二次利用のリスクがあります。

AI時代のDLPでは、次の3つを見直す必要があります。

1. 入力前の分類

公開情報、社内限定、機密、個人情報、顧客情報、認証情報、知財情報などを分類し、どの分類ならどのAIに入力できるかを決めます。

たとえば、次のように対応づけます。

情報区分	AI利用方針
公開情報	外部AI利用可
社内一般情報	契約済みエンタープライズAIのみ可
顧客情報	マスキング後、承認済み環境のみ可
個人情報	原則禁止。例外は法務・セキュリティ承認
認証情報・秘密鍵	全面禁止
未公開ソースコード	契約条件と保存設定を確認した環境のみ可

2. AIサービス側のデータ利用条件

入力データが学習に使われるのか。

保存期間はどれくらいか。

管理者がログを確認できるか。

リージョンはどこか。

監査証跡を出せるか。

契約上の責任分界点はどこか。

これらを確認しないまま、AIサービスを「便利だから」で使わせるのは危険です。

3. 出力の利用制御

AIが生成したコード、設計書、契約文、顧客向け回答をそのまま使ってよいのか。

レビュー必須なのか。

人間の承認が必要なのか。

ここを明確にしないと、AIの誤りが業務成果物に混入します。

AIエージェント時代は権限設計が最重要になる

チャットAIの段階では、主なリスクは入力と出力でした。

しかしAIエージェントでは、そこに「実行」が加わります。

たとえば、AIエージェントが次のような操作を行うとします。

• Jiraチケットを更新する
• GitHubのPRを作成する
• メールを下書きではなく送信する
• クラウドリソースを作成する
• SQLを実行する
• 顧客データを検索する
• ワークフローを自動実行する

この場合、問題は「AIが賢いかどうか」ではありません。

AIにどの権限を与えるかが核心です。

AIエージェントには、原則として最小権限を適用すべきです。

人間の管理者権限をそのままAIに渡してはいけません。

具体的には、次のように段階を分けます。

操作レベル	例	統制
参照のみ	ドキュメント検索、ログ要約	読み取り権限、参照ログ
下書き作成	メール案、PR案、チケット案	人間が確認して送信・登録
限定実行	テスト環境でのコマンド、検証用SQL	サンドボックス、許可コマンド
承認後実行	Git push、DB更新、クラウド変更	Human-in-the-loop、変更履歴
禁止領域	秘密鍵参照、IAM管理、本番削除	原則禁止、例外は個別承認

AIエージェントのログは、通常のアプリログより重要です。

なぜその操作をしたのか。

どの入力を参照したのか。

どのツールを呼び出したのか。

誰の承認を受けたのか。

これらを残さなければ、インシデント時に追跡できません。

AIガバナンスは管理対象になりつつある

シャドーAI対策を考えるうえで、規制や標準の流れも無視できません。

EUでは、欧州委員会のAI Act解説にあるように、AI Actがリスクベースの法的枠組みとして整備されています。汎用AIモデルに関するルールも2025年8月から適用され、透明性、著作権、安全性・セキュリティが重要な論点になっています。

また、欧州委員会はGeneral-Purpose AI Code of Practiceを公開し、汎用AIモデル提供者がAI Act上の義務に対応するための実務的な道筋を示しています。透明性、著作権、安全性・セキュリティの3章で構成されている点は、企業のAI管理にも参考になります。

標準化の面では、ISO/IEC 42001:2023がAIマネジメントシステムの国際規格として公開されています。ISOはこの規格を、組織がAI Management Systemを確立・実装・維持・継続的改善するための要求事項として説明しています。

さらに、NISTはAI Risk Management Frameworkを公開し、2024年7月には生成AI向けプロファイルであるNIST AI 600-1を公開しています。NISTは、このプロファイルが生成AI固有のリスクを特定し、組織の目的や優先順位に合わせたリスク管理行動を整理する助けになると説明しています。

つまり、AIガバナンスは「意識しましょう」という段階から、台帳、分類、リスク評価、ログ、監査、説明責任を持つ管理領域へ移っています。

IT技術者が実施すべき5つの項目

シャドーAI対策で、IT部門やセキュリティ部門がすぐに取り組むべきことは、次の5つです。

1. AI利用実態を棚卸しする

まず、現場にアンケートを取り、AI利用を申告しやすい雰囲気を作ります。

ここで「使っていたら処罰」から入ると、実態は隠れます。

目的は摘発ではなく、可視化です。

確認すべきなのは、利用ツール名、利用目的、入力データ、成果物、頻度、代替可能性です。

特に、開発、運用、営業、人事、法務は重点的に確認すべきです。

2. 公式AI環境を整備する

現場が使いたくなる公式AIを用意します。

単に「安全なAIを入れました」では不十分です。

社内認証、ログ管理、データ保護、社内文書検索、コード支援、議事録要約、プロンプトテンプレートなど、現場のユースケースに合った機能を提供する必要があります。

公式AIが不便で、個人向けAIの方が明らかに便利であれば、シャドーAIはなくなりません。

3. AI向けデータ分類ルールを明文化する

「機密情報を入れない」だけでは曖昧です。

技術者が判断できるレベルまで具体化します。

たとえば、公開情報は外部AI利用可、社内一般情報は契約済みエンタープライズAIのみ可、顧客情報はマスキング後に承認済み環境のみ可、個人情報は原則禁止、認証情報・秘密鍵は全面禁止、といった形です。

データ分類とAI利用可否を対応づけることで、現場が判断しやすくなります。

4. CASB、SWG、EDR、ログ基盤と連携する

技術的な検知も必要です。

AIサービスへのアクセス、ブラウザ拡張、個人アカウント利用、ファイルアップロード、API利用、異常なデータ転送を監視します。

ただし、検知は目的ではありません。

検知した後に、利用者へ安全な代替手段を案内し、必要なら正式利用申請へつなげる運用が必要です。

5. AI利用レビューを開発・運用プロセスに組み込む

開発プロセスであれば、AI生成コードのレビュー、ライセンス確認、セキュリティチェック、テストカバレッジ確認を行います。

運用プロセスであれば、AIが生成した障害原因分析をそのまま採用せず、ログ、メトリクス、変更履歴と突き合わせます。

AIを使うこと自体を問題にするのではありません。

AI出力を検証せずに業務判断へ流すことを問題にすべきです。

IT部門は門番ではなく、安全な通路を作る

シャドーAI対策で失敗する組織は、IT部門が門番になりすぎます。

「これは禁止」「それも禁止」「申請してください」「審査に時間がかかります」という運用だけでは、現場はIT部門を迂回します。

特に生成AIは、個人がすぐに使えるため、統制が遅いほどシャドー化します。

これからのIT部門に求められるのは、現場のAI利用を止めることではありません。

安全な通路を作ることです。

• すぐ使える公式AI環境
• 用途別のプロンプトテンプレート
• データ分類別の利用ルール
• 承認済みAIサービス一覧
• AI利用申請の簡素化
• ログと監査の自動化
• エージェント権限の標準設計
• AI出力レビューの開発標準化
• インシデント時の追跡手順

シャドーAIは、単なるセキュリティ問題ではありません。

現場の生産性要求と、IT統制の設計がかみ合っていないことの表れです。

まとめ: シャドーAI対策の本質は、AI利用を設計すること

生成AIは、すでに業務の中に入り込んでいます。

従業員は、文章作成、調査、コード生成、分析、要約、翻訳、問い合わせ対応にAIを使います。

今後はさらに、AIエージェントが業務システムを操作する段階に進みます。

そのとき、「会社が選んだAIだけを使いなさい」という方針だけでは限界があります。

必要なのは、AI利用を前提にした設計です。

AI利用台帳を作る。

データ分類を見直す。

公式AI環境を便利にする。

ログを残す。

権限を最小化する。

AI出力を検証する。

エージェントの操作範囲を制御する。

これらを、セキュリティ、法務、人事、業務部門、開発部門が共同で進める必要があります。

シャドーAIを完全にゼロにすることは現実的ではありません。

しかし、見えないAI利用を、見えるAI利用へ変えることはできます。

IT技術者に求められているのは、AIを禁止する文章を作ることではありません。

現場がAIを使いたくなる理由を理解し、その利用を安全・監査可能・再現可能な形に設計し直すことです。

---

作成日: 2026年6月19日