Shadow AI（シャドーAI）とは、IT 部門やセキュリティ部門の承認・監督・ガバナンスを経ずに、従業員が業務で AI ツールや生成 AI を利用することを指す。メール作成、議事録の要約、データ分析、資料作成——多くの組織で、AI の活用は経営層の計画ではなく、現場の従業員が「自分で」使い始めるところからすでに広がっている。

この記事は、情報システム・セキュリティ・コンプライアンス・経営の担当者に向けて、Shadow AI とは何か、なぜ起きるのか、どこが危険なのか、そしてどう向き合えばよいのかを、IBM・Microsoft・NIST・CISA の指針をもとに整理する。読み終えたとき、「AI を全面禁止すべきか」ではなく「どうすれば安全に使わせられるか」という問いに切り替えられる状態を目指す。

Shadow AI は、組織が把握・統制できないところで進む AI 利用のことだ。新しい問題に見えて、実は古くからある「Shadow IT」の延長線上にある。

まずは Shadow AI が指す範囲と、従来の Shadow IT との違いを押さえておきたい。言葉の輪郭がはっきりすると、後で説明するリスクの構造も理解しやすくなる。

IBM は Shadow AI を、IT・セキュリティ部門の承認や監督を受けずに、組織の管理外で使われる AI・生成 AI ツールと定義している（IBM「What is shadow AI?」）。ポイントは「AI を使っていること」ではなく「組織が見えていない使い方をしていること」にある。

具体的には、次のような利用がすべて Shadow AI に含まれる。

• 個人アカウントで一般向けの生成 AI チャットにログインし、業務文書を貼り付ける
• ブラウザ拡張機能として AI ツールを追加し、社内画面の内容を読み取らせる
• 承認されていない AI エージェントに、メールやファイルへのアクセス権を与える
• 表計算データや契約書を AI にアップロードして要約・分析させる

いずれも「ソフトウェアを正式に導入した」わけではないため、資産管理台帳にも残らず、IT 部門のレーダーには映らない。AI は数クリックで使い始められるからこそ、組織の認識と現場の実態のあいだに大きなギャップが生まれる。

Shadow AI は Shadow IT（無許可のソフトウェア・サービス利用）の一形態だが、リスクの質が異なる。従来の Shadow IT は「未承認のツールが入り込む」ことが主な問題だった。一方 Shadow AI は、ツールがデータを読み取るだけでなく、判断し、要約し、文章を生成し、ときに外部のデータソースと連携する。

Shadow AI が Shadow IT より厄介なのは、入力したデータの行方だけでなく、AI が出力した内容が業務に紛れ込む点にある。

IBM も Shadow AI を Shadow IT の「サブセット」と位置づけつつ、データセキュリティ・コンプライアンス・レピュテーションへの打撃はより大きいと指摘している。

Shadow AI が広がる最大の理由は、AI が「速く・手軽に・成果を出す」からだ。正規ルートが用意されていなければ、現場は自分でツールを探す。

ここでは、Shadow AI が生まれる構造を、現場の動機と組織側の不備の両面から見ていく。

Shadow AI が起きる理由は、大きく三つに整理できる。

第一に、手軽さ。多くの AI ツールはブラウザや既存アプリから数分で使い始められる。インストールも申請も要らない。

第二に、成果の速さ。AI がメール作成や議事録要約、表計算の分析を明らかに速くしてくれると実感すると、従業員にとって承認やポリシーの確認は「待たされる手続き」に見えてしまう。

第三に、正規の代替手段がないこと。組織が「この業務にはこのツールを使ってよい」という選択肢を用意していなければ、現場は目の前の仕事を片付けるために自分で手段を探す。

IBM が引用するある調査では、米国のオフィスワーカーの約 80% が業務で AI を使う一方、勤務先が指定したツールだけを使う人は 22% にとどまる（IBM「Is rising AI adoption creating shadow AI risks?」）。同様に IDC の 2025 年の調査では、56% の従業員が職場で未承認の AI ツールを使い、組織が提供・統制するツールを使う人は 23% だったと報告されている。数字の細部はさておき、傾向は明確だ——AI の正規ルートが整わないかぎり、人は自分のルートを作る。

Shadow AI のもう一つの特徴は、IT 部門の「導入プロジェクト」としてではなく、従業員一人ひとりの行動として広がる点だ。プレゼン資料を AI に要約させる、コードを AI に直させる、契約書を AI に下書きさせる——こうした行動は、誰かが許可を出す前に、すでに日常になっている。

Microsoft はこの状況について、組織は「どの AI アプリが、誰によって、どう使われているか」をそもそも把握できていないことが多いとし、対策の出発点を「禁止」ではなく「発見（discover）」に置くべきだとしている。実際 Microsoft は、管理者が組織内で使われている未管理の AI エージェントを把握できるよう、Microsoft 365 管理センターに「Shadow AI」機能（プレビュー）を追加した。

裏を返せば、多くの組織は「何が起きているか分からない」状態から始まる。これは管理の不在というより、AI 利用のスピードがガバナンスの整備を追い越した結果だと考えるほうが実態に近い。

Shadow AI の危険は「未承認ツールが入る」ことにとどまらない。データ漏えい、可視性の欠如、コンプライアンス違反、未検証の AI 出力、そしてシャドーデータ・シャドーモデルへの拡大——リスクは五つの層で重なっていく。

順に見ていこう。

最も直接的な危険はデータ漏えいだ。従業員が社内データを一般向けの AI ツールに入力すると、その情報は組織の統制範囲の外に出ていく。IBM は、財務データ、企業秘密、独自のソースコード、機微なビジネスメールが公開 LLM に入力され、保持されたり別の用途に使われたりしうると指摘する。

ここで重要なのは、リスクが「一人がツールを使い間違えた」レベルにとどまらないことだ。顧客データや財務情報、ソースコードが未承認の AI アプリ経由で流出すれば、影響はコンプライアンス、契約上の義務、プライバシーインシデントにまで及ぶ。

実際 IBM の調査では、シャドーAI が関与したデータ侵害は、そうでない侵害よりも平均コストが大きく上振れし、5 社に 1 社がすでにシャドーAI に関連した侵害を経験したと報告されている（IBM「2025 Cost of a Data Breach Report」）。一度の貼り付けが、見えないところで高くつく構造になっている。

Shadow AI が危険なのは、それが「可視性の外」にあるからだ。IT 部門が、従業員がどの AI アプリを使っているかを知らなければ、アクセス制限も、データ損失防止（DLP）も、監視も設計できない。守るべき対象が見えないところで動いている。

コンプライアンスの観点でも問題は深い。多くの組織は、データの保管場所（データレジデンシー）、プライバシー、記録の保持、機密保持、業界固有の規制について、すでにポリシーを持っている。ところが Shadow AI が起きると、従業員はそのポリシーが及ばない経路でデータを処理してしまう。IBM と Microsoft はいずれも、Shadow AI がコンプライアンス上の課題に直結すると指摘している。組織が一度も評価していないアプリが、規制対象のデータを扱ってしまうからだ。

既存の SaaS やクラウドアプリには統制が効いていても、ブラウザ拡張、スタンドアロンのエージェント、ローカルのモデル実行環境、API ラッパーといった新しい形の AI は、従来のポリシーの想定外から入り込む。ガバナンスを AI の普及スピードに合わせて広げないかぎり、ポリシー違反は起こりやすくなる。

Shadow AI のリスクは「入力」だけではない。「出力」にもある。従業員が AI にレポート、契約要約、コードの提案、顧客対応文、分析結果を作らせ、承認されたワークフローや人間のレビューを通さずに使えば、AI の誤りがそのまま業務プロセスに紛れ込む。

厄介なのは、その誤りが「AI のリスク」として認識されないことだ。レビュー層も、AI 出力がどの工程で使われたかという記録もないため、AI の誤りは「ふつうの人的ミス」として処理されてしまう。原因が未承認の AI 利用にあることが、見えなくなる。

さらに IBM は、Shadow AI が単独では現れないと指摘する。それは「シャドーデータ」「シャドーモデル」と一緒に育つ。検証されていないデータ、出所の分からない第三者のデータセット、誰も素性を知らないモデルが、一つのワークフローに同居しうる。こうなるとリスクは、アプリ単位の話から、データのサプライチェーン、モデルのサプライチェーンの話へと広がる。「誰がどのアプリを使ったか」だけでなく「どのデータが、どこで、どのモデルに使われたか」が問われる、システム的なリスクになる。

Shadow AI への正しい対処は「AI を全面禁止する」ことではない。従業員が安全に AI を使える正規ルートを用意し、可視化・統制・ガバナンスを段階的に整えることだ。

ここでは、実務として何から始めればよいかを整理する。

Microsoft は、Shadow AI への対応を段階的なアプローチで進めることを推奨している。「Prevent data leak to shadow AI」のガイダンスでは、次の 4 つのフェーズが示されている。

ポイントは、いきなり「遮断」から始めないことだ。何が使われているかを知らないまま禁止しても、利用は別の経路に移るだけになる。まず発見し、次に「使ってよいアプリ／使ってはいけないアプリ」を仕分け、機微データを分類して統制をかけ、最後に運用として回るガバナンスを作る——この順序が現実的だ。

NIST の AI リスクマネジメントフレームワーク（AI RMF）や CISA の AI セキュリティガイダンスも、AI を「個別アプリの問題」ではなく「システム全体のリスク」として捉えるよう促している。信頼性、セキュリティ、プライバシー、透明性、説明責任をまとめて管理するという発想だ。実務に落とすと、データガバナンス、アクセス制御、監視、人によるレビュー、明確な責任分担をセットで整えることになる。Shadow AI はセキュリティツールだけで解けるものではなく、ポリシー・ワークフロー・チェンジマネジメントを並走させて初めて解ける。

多くの組織が見落とすのは、「禁止」だけでは Shadow AI が消えないという点だ。承認済みのツールが現場の仕事に役立たなければ、従業員はやはり外部のツールを使う。だからこそ、対策の本丸は「安全に使える正規ルート（sanctioned path）」を用意することにある。

実務として、組織は少なくとも次の 4 つに取り組みたい。

1. 現場で起きている AI アプリの利用を可視化する
2. 「使ってよいアプリ」「使ってはいけないアプリ」を明確に定める
3. 機微データを分類し、統制（DLP・アクセス制御）をかける
4. 形だけのポリシー文書ではなく、実際に機能する AI ガバナンスを作る

<!-- TODO: Enison での AI 利用ポリシー策定・正規ツール整備の支援事例（Before/After や具体的な施策）を挿入 -->

ここで強調したいのは、Shadow AI は「現場が悪い」のではないということだ。それは、AI 導入のスピードがガバナンスを追い越しているという、組織からのシグナルである。現場が外部ツールに頼らずに済むだけの正規ルートを、組織がどれだけ早く用意できるか——問われているのはそこだ。

Q. Shadow AI と Shadow IT は何が違う？

Shadow AI は Shadow IT の一形態だが、AI ツールはデータを保存するだけでなく、要約・分析・文章生成・外部連携まで行う。このため、データセキュリティ、コンプライアンス、レピュテーションへの影響が従来のソフトウェア利用より大きくなる。IBM も Shadow AI を Shadow IT のサブセットとしつつ、打撃はより重いと指摘している。

Q. 組織が Shadow AI を抑えたいとき、まず何から始めるべき？

最初にやるべきは「発見（discover）」だ。どの AI アプリが実際に使われているかを把握し、そのうえで承認／未承認を仕分け、DLP などのデータ統制をかけ、従業員が使える正規のワークフローを整える。Microsoft が示す段階的アプローチもこの順序になっている。いきなり遮断から入ると、利用が見えない経路に移るだけになりやすい。

Q. AI をすべて禁止すれば解決する？

基本的には有効な解決策にならない。承認済みツールが現場の仕事に合っていなければ、従業員は結局、外部のツールを使い続ける。より効果的なのは、安全な代替手段（sanctioned alternatives）と、実際の業務に追従するガバナンスを用意することだ。

Shadow AI は、単に「従業員がこっそり AI チャットを使っている」という話ではない。それは、AI の活用が組織のガバナンスより速く進んでいることを示すシグナルだ。主なリスクは、データ漏えい、可視性の欠如、コンプライアンス違反、未検証の AI 出力、そしてシャドーデータ・シャドーモデルへの拡大の五つに整理できる。

IBM、Microsoft、NIST、CISA はいずれも同じ方向を指している——出口は「すべてを禁止すること」ではなく、可視性、ポリシー、安全な代替手段、そして実際に機能するガバナンスを作ることだ。

組織にとって正しい問いは「AI を禁止できるか」ではなく「どうすれば従業員に、データとリスクを組織の外に出さずに AI を使わせられるか」である。この問いに明確に答えられたとき、Shadow AI はリスクから、統制された AI 活用へと変わる。

---

参考文献

• IBM「What is shadow AI?」 https://www.ibm.com/think/topics/shadow-ai
• IBM「Is rising AI adoption creating shadow AI risks?」 https://www.ibm.com/think/insights/rising-ai-adoption-creating-shadow-risks
• IBM「Four Ways Your Organization Can Lower the Security Risk From Shadow AI」 https://www.ibm.com/think/insights/security-risk-shadow-AI
• Microsoft Learn「Prevent data leak to shadow AI」 https://learn.microsoft.com/en-us/purview/deploymentmodels/depmod-data-leak-shadow-ai-intro
• NIST「AI Risk Management Framework (AI RMF)」 https://www.nist.gov/itl/ai-risk-management-framework
• CISA「AI security guidance」 https://www.cisa.gov/ai

（本記事は一般的な情報提供を目的としており、最新の製品仕様・統計・規制動向は各一次情報源で確認してください。記載した調査数値は引用元の公表値に基づきます。）