シャドーAIは「禁止」で防げない｜主要9社に学ぶ対策と事業機会

シャドーAIとは、会社が把握していないAI利用

シャドーAIは、会社の承認・監督の外にあるAI利用です。用途、入力情報、契約、実行権限を確かめます。

シャドーAIとは、会社の承認や監督の外で、従業員がAIを業務に使っている状態です。個人契約のChatGPTやGeminiで企画書を要約する行為が、わかりやすい例です。

対象は会話型AIだけではありません。たとえば、AI翻訳の拡張機能、議事録サービス、コーディング支援、SaaS内のAI機能も含みます。

さらに、社内で作られた未登録のAIエージェントも新しい論点です。

問題の中心は、特定のAIが危険なことではありません。誰が何を入力し、どの契約条件で処理され、何に使われたかを会社が説明できないことです。

例えば、公開情報の英訳と、未公開のM&A資料の要約では、同じAIでも危険度が違います。「使ったか」だけでなく、「何を、どの環境で使ったか」を見ます。

シャドーAIとシャドーITの違いは、追加で管理すべきリスク

従来のIT管理に、生成結果の確認とエージェントの操作権限の管理を加えます。 シャドーAIはシャドーITの一部です。

未承認の機器・サービスに伴うアクセスやデータ管理の問題に加え、生成結果の確認や、エージェントが実行する操作の管理が必要になります。従来のITでもデータ処理は行うため、「AIだけが情報を加工する」とは区別しません。

対策も、従来のWebサイト遮断だけでは足りません。個人アカウントと法人アカウントを見分け、入力内容を確認し、安全な代替手段へ導く必要があります。

シャドーAIの背景は、業務需要と社内環境を分けて調べる

未承認利用の動機を決めつけず、業務需要と社内ツール・承認条件のずれを調べます。 未承認利用を見つけたら、どの業務で何を改善したかったかを確認します。

文章の下書き、翻訳、データ整理などの需要と、使える社内ツール・承認条件が合っていない可能性があります。動機を決めつけず、利用者への聞き取りで確かめます。

社内ツールの使い勝手、利用対象者、申請にかかる時間、禁止理由の伝わり方を点検します。未承認利用の原因は組織ごとに異なるため、承認手続の遅さだけを原因にしないことが大切です。

MicrosoftとLinkedInの2024年調査では、AIを使う知識労働者の78％が会社から提供されていないAIを仕事に持ち込んでいました。調査全体は31市場の31,000人が対象ですが、78％の分母はそのうちのAI利用者です。

「会社提供ではない」と「会社が未承認」は異なるため、日本のシャドーAI率と直接比較しません。

この調査から当研究所が重視するのは、会社が用意した環境だけでは利用実態を把握し切れない可能性です。禁止対象を明確にしたうえで、使いたい業務と安全な代替手段を確認します。

別端末への移行などを当然の結果として扱わず、実際の変化を調べます。

有効な対策は、「禁止か自由化か」の二択ではありません。業務とデータの種類ごとに、使えるAIと操作を分けます。

シャドーAIの実態調査：日本の回答者の47％が部署内の未承認利用を報告

把握できていない部署を、未承認利用のない部署に含めないことが重要です。発見済みの利用への対応と、未把握の範囲の調査を分けて進めます。

部署の未承認利用を報告した回答は表示値合計47％、把握できていない回答は19％でした。対象と分母を分けて読みます。

PwC「生成AIに関する実態調査2026 春」の日本調査は、売上高500億円以上の企業・組織に所属する課長相当以上で、AI導入に関与する932人を対象にしています。調査期間は2026年2月12〜19日です。

未承認利用の質問は、回答者の所属部署の実態を尋ねています。

報告書143ページでは、部署内での未承認利用を「一部で散発的」とした回答が31％、「一部で定常的」が12％、「広範で定常的」が4％でした。表示値を合計すると47％です。

これは対象者の回答割合であり、日本の全企業や全従業員の利用率ではありません。

一方、把握できていない回答は19％、ほとんど発生していない回答は33％でした。各値は丸められているため、合計は100％になりません。

社内調査では、AIを使ったかに加え、文書要約、議事録、コード生成などの用途と、契約アカウントを尋ねます。調査目的や回答の扱いを説明し、未把握の利用と新しい業務需要を分けて整理します。

実態把握では、利用率・把握率・移行率を分ける

利用率は「対象者のうち、決めた期間にAIを業務で使った人」の割合です。把握状況は、全利用の真の総数が分からない段階で一つの率にせず、対象端末のログ取得状況、台帳登録数、聞き取りで見つかった未登録数を分けて示します。

承認済みAIの利用者が増えても、未承認利用者が移行したとは限りません。移行率は、最初に確認した同じ対象者を追って測ります。

架空例として、未承認利用を確認した100人のうち70人が指定した業務を承認済み環境へ移せたなら70％です。未移行20人、追跡できない10人も分母に残し、内訳を示します。

相談件数も役に立ちます。というのも、利用者からの質問が一時的に増えるのは、必ずしも悪い変化ではないからです。

むしろ、隠れて使う前に、確認する行動が増えた可能性があります。

部署別の用途も確認します。例えば営業の提案書、開発のコード、管理部門の契約文書では、入力情報と出力の確認者が異なります。

これは用途を整理する例であり、部門ごとの実態を一律に決める分類ではありません。

リスクは、情報漏洩から誤判断・契約・監査へ広がる

入力情報だけでなく、参照権限、出力の使い道、外部操作まで点検します。 シャドーAIのリスクは、機密情報の入力だけではありません。

入力、処理、出力、実行の四つの場面で見ます。

入力では、顧客名簿、未公開の設計図、ソースコード、契約書が外部AIへ送られる可能性があります。保存期間、学習利用、処理地域も契約ごとに違います。

処理では、外部接続や共有設定が論点です。たとえば、承認済みのAIでも、不必要に広い社内ファイルを参照できれば、別部門の機密情報へ届きます。

そのため、RAGの導入でも、検索精度の前に参照権限を確認します。

出力では、誤りや古い情報、差別的な表現、著作権上の問題があります。もし、そのまま顧客説明や広告に使うと、「AIが書いた」では済みません。

そのため、業務の責任者が最終的に確認します。

実行では、AIエージェントがAPIやMCPを使ってシステムを動かします。予約、発注、メール送信、ファイル削除に進むと、間違いの影響が大きくなります。

NISTのAI Risk Management Frameworkは、AIのリスク管理に任意で使う枠組みです。生成AI向けのプロファイルも公開されています。

ここでは、サイバーセキュリティ対策に加え、用途の審査、出力確認、事故対応を継続的に見直すための参考にします。

シャドーAI対策は、五層を組み合わせる

利用発見、データ保護、承認済み環境、操作権限、組織運用を組み合わせます。 シャドーAI対策は、一つの製品で完成しません。

次の五層を組み合わせます。

第一層は、利用の発見です。許可された範囲のネットワーク、ブラウザ、端末、クラウドのログを調べ、AIサービスとアカウントを確認します。

管理対象外の端末や回線が自動的に見えるわけではないため、対象外の範囲も明記します。

第二層は、データの保護です。具体的には、個人情報、営業秘密、ソースコードなどを分類し、プロンプトやファイル送信を確認します。

そのうえで、必要に応じて遮断、伏字化、警告を使い分けます。

第三層は、承認済みのAI環境です。法人契約、認証、利用ログ、保存設定を用途に合わせて整えます。

OpenAIの事業向けデータ方針では、事業データを既定で学習に使わない方針が示されています。ただし、学習しないことと保存しないことは別です。

契約プランごとの保持期間や設定条件を確認します。

第四層は、モデルとエージェントの統制です。具体的には、社内で作られたAI、API、MCP接続、操作権限を台帳化します。

読み取りと書き込みを分け、高リスクの操作に人の承認を置きます。

第五層は、組織運用です。具体的には、利用申請、例外承認、教育、インシデント対応、台帳更新を回します。

そして、技術部門だけでなく、業務、法務、情報セキュリティが参加します。

AI事業者ガイドライン第1.2版は、2026年3月31日に公表された指針です。ガイドライン自体は非拘束的なソフトローであり、記載内容をすべて法的義務として扱うものではありません。

社内規程の検討に使いつつ、適用法令と契約は別に確認します。

欧州でAIを提供・利用する場合は、EU AI Actの適用日程と、自社の役割・用途を確認します。2026年8月2日の一般適用とは別に、先行適用や高リスクAIの移行期間があります。

利用監視ツールを入れただけで規制適合が完了するわけではありません。

製品を選ぶ前に、AI台帳の項目を決める

AI台帳は、サービス名を並べるだけでは足りません。利用部署、責任者、用途、入力データ、契約プラン、保存設定、接続先、出力の確認者を記録します。

AIエージェントについては、実行できる操作も台帳に加えます。メールの下書きと送信、見積案の作成と価格の確定は分けて扱い、人の承認が必要な境界を示します。

AIを新しく導入するときだけでなく、機能、契約、接続先、利用部署が変わったときにも台帳を更新します。

分担の例として、情報システム部門は台帳の形式、業務部門は用途の更新、法務とセキュリティ部門は高リスク項目の確認を担当します。更新漏れを防ぐため、実際の担当者と期限を決めます。

主要9社は、シャドーAIの「発見・保護・運用」を競う

主要9社は、管理したい業務と既存環境への適合で比較します。機能の数を導入効果に置き換えません。

シャドーAI対策の企業は、既存のセキュリティ基盤を広げる会社と、AI固有の問題に特化する会社に分かれます。

企業選定では、機能数の比較だけでは不十分です。現在のネットワーク、端末管理、データ分類、ID基盤にどこまで組み込めるかを見ます。

主要9社の比較は、管理したい場面から始める

最初の課題が「誰が何を使っているかわからない」であれば、通信とアカウントの可視化を優先します。Palo Alto Networks、Zscaler、Cloudflareなどが比較候補です。

「機密文書を入力してしまう」が中心なら、データ分類と操作別制御を見ます。Microsoft、Netskope、Harmonic Securityなどを、現在の情報管理基盤と合わせて比較します。

社内でAIエージェントを作り始めている場合は、別の選び方が必要です。Cisco、IBM、Zenityなどの台帳、権限、実行時保護を確認します。

同じ会社の製品でも、契約プランと構成で見える範囲が変わります。製品名だけで判断せず、自社の端末、ブラウザ、ネットワーク、クラウドで検証します。

評価表には、検知数だけでなく誤検知、見逃し、警告後の行動を入れます。管理者の画面が見やすくても、利用者が仕事を続けられなければ定着しません。

MicrosoftとPalo Altoは、シャドーAIを既存基盤に組み込む

製品群の連携条件、ライセンス、入力と出力のどこを検査するかを確認します。 以下は各社が公表している機能です。

自社環境での検知率や業務改善が確認された事例とは区別して読みます。

Microsoftはデータ、端末、IDをまたいで管理する

Microsoft Purview Data Security Posture Managementは、AI利用を可視化する仕組みです。対象はAIアプリとAIエージェントで、機密情報へのアクセス、外部への持ち出し、過剰な共有も同じ画面で追います。

Microsoft製品群を利用している場合は、データ保護とID・端末管理を組み合わせる構成が候補になります。ただし、非Microsoft環境への連携条件や提供段階は機能ごとに異なり、現行のDSPMにも一部プレビューの設定があります。

既存契約だけで必要な範囲を管理できるかは個別に確認します。

導入側は、使うブラウザと端末、対応AI、ログの保存期間を確認します。会話全文が見える権限も、管理者の役職ごとに分けます。

Palo Alto Networksは、承認状態と機能ごとに制御する

Palo Alto NetworksのAI Access Securityは、AIアプリを承認状態で分けます。具体的には、承認済み、未承認、条件付き利用の三つです。

さらに、アプリ全体の許可・禁止だけでなく、特定機能やプラグインを制御できます。

例えば、法人アカウントを認め、同じサービスの個人アカウントを制限する構成や、入力する機密情報をDLPで検査する構成があります。必要な基盤・ライセンス・ポリシー設定が前提です。

公式資料ではAI Access Securityは生成AIの応答を検査・記録しないとされており、出力の確認まで同じ製品で完結すると考えないことが重要です。

この考え方は、Zero Trustと似ています。「AIだから許可」ではなく、人、端末、アカウント、操作、データで判断します。

ネットワーク企業は、未承認AIの入り口を押さえる

通信経路による対策は、監視できる経路と対象外の端末・回線を分けて評価します。 通信を使った対策では、どの経路を管理下に置けるかが先に決まります。

Zscalerは、AI SaaSから開発ツールまで同じ経路で見る

Zscaler AI Access Securityは、複数のAIへのアクセスを管理します。その対象は、一般的な生成AI、SaaS内のAI、開発支援ツールです。

そして、プロンプトと応答を通信経路で確認し、データ漏洩やポリシー違反を防ぎます。

この方式の強みは、現場が新しいAIを使い始めても、通信経路から見つけやすいことです。一方、個人端末や監視対象外の回線は別に考えます。

Netskopeは、操作別制御と利用者へのナッジを重視する

Netskope Skylight AI Securityは、AIアプリの操作を分けて見ます。具体的には、ログイン、投稿、アップロード、ダウンロードなどが対象です。

さらに、AIアプリのリスク評価と、送信されるデータの意味の確認も組み合わせます。

Netskopeは、機密データの送信時に警告し、承認済みツールへ案内する機能も紹介しています。通知が実際の移行につながるかは、対象業務と利用者を決めて検証します。

Cloudflareは、社員のAI利用と自社AIアプリの両方を見る

CloudflareのShadow AI Reportは、Gatewayを通る通信からAIサービス利用を分類します。公式説明ではShadow IT分析にTLS検査が必要です。

利用者やサービスで絞り込めますが、Gatewayを通らない通信や取得しない情報は別の把握方法が必要です。

別のAI Security for Appsは、自社のWebアプリやAPIに含まれるAIエンドポイントを発見します。一つの「シャドーAI」でも、従業員利用と開発者の未登録AIでは、見る場所が違います。

AI固有の対策は、モデルとエージェントまで広がる

AI資産の発見と、エージェントが実行する操作の制御を分けて検証します。 発見、構成の検査、実行時の保護は別の機能です。

必要な連携と監視対象を確認します。

Ciscoは、発見と実行時保護を一つにする

Cisco AI Defenseは、DNSとクラウドのログからAI利用を発見します。その上で、AIアプリの入力と出力を検査し、プロンプト攻撃や不適切な出力を防ぎます。

通信のドメイン名だけでは、何を入力したかはわかりません。逆に内容検査だけでは、社内に何個のAIがあるかを把握できません。

Ciscoは二つを結びます。

IBMは、セキュリティとAIガバナンスを同じ台帳で扱う

IBM Guardium AI Securityは、未登録のAIとAIエージェントを発見します。その対象は、クラウド、コード保管庫、組み込みAIです。

さらに、構成ミスと脆弱性を検査し、プロンプトと応答も保護します。

Guardium AI Securityは、watsonx.governanceとの連携によりAI資産情報を共有する構成を示しています。情報セキュリティ部門の脆弱性確認と、リスク管理部門の用途審査をつなぐ候補ですが、連携設定と台帳の更新責任を確認します。

Harmonic Securityは、止めすぎないデータ保護を狙う

Harmonic Securityは、承認済みかどうかを問わず、AIツールの利用と機密データの送信を見つけます。その場で警告し、利用者が業務を続けられる安全な方法へ導くことを重視しています。

特徴は、ルール作成の重さを減らす設計です。導入側は、日本語の顧客名、製品名、契約表現など、自社固有の機密をどこまで識別できるかを試します。

Zenityは、人のプロンプトよりAIエージェントの行動を見る

Zenityは、企業向けAI、独自エージェント、端末上のAI利用を可視化し、権限や実行時の動作を制御する機能を紹介しています。接続できる環境と取得できる情報は導入構成によるため、自社のエージェントで検証します。

承認済みのエージェントでも、必要以上の権限を持てば危険です。シャドーAIの対象は、未承認アプリだけでなく、把握されない自動実行へ広がっています。

自社はシャドーAI対策のどこへ入れるか

通信ログ、業界辞書、業務設計、ID・API運用から入口を確認します。

01　通信ログやSOC運用がある

AI利用棚卸し・診断の入口があります。

• 利用中のAIを発見できる
• アカウントと端末を識別できる
• 発見後の改善まで持てる

02　業界辞書や機密定義がある

日本語型データ保護へ入れます。

• 顧客固有の機密を定義できる
• 誤検知と検知漏れを直せる
• DLPやブラウザ企業と組める

03　業務設計や教育を提供できる

承認済みAIの運用へ入れます。

• 対象業務を一つに絞れる
• 申請と例外承認を設計できる
• 利用者の声を改善へ戻せる

04　IDやAPIを運用している

AIエージェント権限管理へ入れます。

• 読み取りと書き込みを分けられる
• MCP接続と実行を記録できる
• 誤実行時に停止・復旧できる

シャドーAI対策から生まれる4つの新規事業

事業の候補は、棚卸し、日本語データ保護、承認済み環境の運用、エージェント権限管理です。 次の四つは、既存製品を活用しながら日本語・業界固有のデータや導入後の運用を支える事業案です。

当研究所による検討案であり、需要や収益性が実証済みの市場分類ではありません。

既存顧客と情報管理の知識があれば、棚卸しや承認済み環境の導入支援から需要を確かめられます。顧客がその後の運用まで求めるか、社内で実施するかを聞き、継続サービスの範囲を決めます。

検知ルールの更新、教育、例外審査は継続サービスの候補です。ただし、月額契約にしても利益が残るとは限りません。

調査・対応時間、ライセンス、問い合わせ、事故時の負担を含めて原価を見積もり、顧客の継続意向と合わせて判断します。

AIアプリの一覧だけでなく、検知ミスを減らす評価手順や問い合わせへの対応力が、提供価値の候補になります。顧客がその改善へ費用を払うかを確認します。

自社資産から、最初の買い手と対象業務を絞る

同じ対象で移行を追い、誤警告と見逃し、運用費を分けて評価します。 参入方法は、技術の高さだけで選びません。

自社が持つ顧客接点と運用責任から絞ります。

例えば、勤怠や経費のSaaS企業を考えます。この場合、対策全体を売るより、自社のAI機能を安全に使う管理機能の方が自然です。

たとえば、機密入力の防止と利用ログを追加します。

セキュリティ運用会社であれば、既存のSOCにAI利用アラートを加える方が早いでしょう。通信、ID、端末のログを合わせ、利用者の状況を説明できます。

業界専門性の高い会社であれば、日本語の機密データ判定が候補です。「個人情報」の一語ではなく、医療の病歴、製造の図番、金融の口座情報のように業界ごとに定義します。

最初の商品は、一部署・一業務・一種類のデータに絞ります。何を監視できるか、検知の正確さ、承認済み環境への移行、審査・運用時間を、同じ対象と期間で比較します。

四つの指標で、商品として続くかを見る

第一は対象範囲です。調べた部署、端末、AIサービス、期間を記録し、ログや聞き取りで確認できた数と、調べられていない範囲を示します。

見えていない利用まで含めた「全社把握率100％」とは表現しません。

第二は移行率です。未承認AIを止めた後、承認済みの環境へ移れた人を測ります。

逆に、業務そのものを諦めた場合は、改善とは言えません。

第三は検知の品質です。警告の正確さだけでなく、見逃した機密入力も確認します。

あらかじめ正解を付けたテスト用データを使い、適合率、再現率、誤検知率を別々に示します。実際の機密情報を無断で外部へ送ってテストしないことも前提です。

第四は運用時間です。新しいAIの審査、例外承認、問い合わせ対応にかかった時間を測り、契約額からライセンス費や人件費を引いて利益が残るかを確認します。

これらに継続意向と費用を加えると、運用サービスとして続ける条件を判断できます。改善事例を他社に使う場合も、利用許諾、契約、匿名化や集計方法を確認し、顧客の機密ログそのものを流用しません。

架空例：警告の正確さ85.7％でも、機密入力の25％を見逃す

テスト用の入力200件に事前に正解を付けたとします。機密80件のうち60件へ警告し、通常120件のうち10件へ誤って警告した例です。

数値は指標の違いを示す架空例で、各社製品の性能や導入実績ではありません。

適合率は60÷70＝85.7％で、「警告がどれだけ正しかったか」を示します。再現率は60÷80＝75％で、機密入力の25％は見逃しています。

誤検知率は10÷120＝8.3％です。警告数だけを減らすと見逃しが増えることもあるため、両方の結果を見て設定を決めます。

あわせて、日本語の言い換えや画像・ファイル入力、製品が対応しない操作を確かめます。検査対象外を「検知ミスなし」に含めず、処理の遅れと管理者の確認時間も記録します。

承認基準の作り方はPoCから事業化へ進むための評価設計も参考になります。

導入前に考える懸念と、見送る条件

監視範囲とプライバシー、誤検知への対応、緊急停止の担当を決めてから展開します。 第一の懸念は、監視のやりすぎです。

取得目的、対象者、閲覧者、保存期間、削除方法を定め、必要最小限の情報を扱います。従業員への説明と適用法令・社内規程の確認を行い、個人端末の全活動を当然に監視できるという前提は置きません。

第二の懸念は、誤検知で業務を止めることです。実務に近いテスト用データで、止めるべき入力と許可する入力の両方を試します。

業界固有語への対応と、誤って止めた場合の解除手順を確認します。

第三の懸念は、ツールを入れて安心することです。未承認利用の発見後に、所有者、評価、例外承認、停止、削除を回せなければ、ダッシュボードが増えるだけです。

次の条件を満たせない場合は、本番への展開範囲を絞り、先に不足を解消します。なお、危険な利用を止める緊急対応は、代替環境が完成するまで待つものではありません。

• 承認済みのAIと代替業務を用意できない
• 取得するプロンプトとログの範囲を説明できない
• 誤検知と検知漏れを改善する責任者がいない
• 個人端末と社外ネットワークを前提に入れていない
• AIエージェントの書き込み権限と緊急停止を管理できない

一方、はじめから全社展開を目指す必要はありません。一部署で、発見、警告、代替手段、改善を一周できるかを確かめます。

生成AI利用統制は、四者の責任を先に分ける

セキュリティ、業務、法務、推進部門で、審査・更新・事故対応の担当と権限を決めます。 シャドーAI対策は、情報システム部門だけの仕事ではありません。

次の四者で責任を分けます。

情報セキュリティは、利用発見、データ保護、アラート、インシデント対応を持ちます。ただし、どの業務でAIを使うと価値が出るかは決められません。

業務部門は、用途、入力データ、出力の確認者、誤りの影響を定義します。AIを使った成果物の最終責任も業務部門に残ります。

法務・リスク管理は、個人情報、営業秘密、著作権、契約条件、越境移転を確認します。すべてのAIを個別審査するのではなく、危険度ごとの条件を作ります。

デジタル推進・人事は、承認済み環境の定着、教育、利用者の声の回収を持ちます。警告が多すぎる、必要なAIがない、申請が遅いという問題を運用へ戻します。

外部ベンダーに任せる場合も、会社の責任は残ります。製品側は検知と制御を支援できますが、どのデータを機密とするかは利用企業が決めます。

運用会議では、件数より例外を見る

月次会議で、警告件数だけを報告しても改善は進みません。承認済みAIへ移れなかった理由、誤検知が多い言葉、審査が止まった業務を見ます。

例外承認には理由、対象業務、期限を記録します。期限が来たら、利用実態と残るリスクを確認して、延長、停止、正式採用を決めます。

AIサービスやSaaSの機能変更に合わせ、台帳と承認済み一覧を見直します。例えば四半期ごとの定期点検に加え、新しい外部接続や重大なリスクが見つかった時点で確認します。

利用者には、使えるAI、入力できる情報、迷ったときの相談先を一枚にまとめて示します。違反の注意とともに、安全に仕事を進める方法を伝えます。

シャドーAIに関するよくある質問

定義と、対策を始める際の確認事項をまとめます。

Q. シャドーAIとは何ですか？

A. 会社の承認や監督の外で、従業員や開発者がAIを業務に使う状態です。個人アカウント、AI拡張機能、未登録のAPIやAIエージェントも含みます。

Q. なぜ生成AIを禁止するだけでは不十分ですか？

A. 禁止を通知しても、対象業務の需要や利用実態を把握できるとは限らないためです。高リスクな利用は止めつつ、承認済みの代替手段と相談先を用意し、移行できたかを確かめます。

Q. シャドーAIはどうやって見つけますか？

A. ネットワーク、DNS、ブラウザ、端末、クラウド、ソースコードのログを組み合わせます。ただし、技術的な検出だけでは個人端末や業務目的が見えないため、利用者への調査も併用します。

Q. 承認済みの法人向けAIなら安全ですか？

A. 自動的に安全にはなりません。保存、学習利用、接続先、データ参照権限、アカウント、監査ログを確認します。利用目的とデータの危険度も別に審査します。

Q. 生成AI利用ルールには何を書きますか？

A. まず、承認済みツール、利用可能な業務、入力できないデータを定めます。次に、出力の確認者、外部公開条件、申請、例外、記録を決めます。インシデント報告と違反時の対応も必要です。

Q. シャドーAI対策は新規事業になりますか？

A. なり得ます。利用棚卸し、日本語型データ保護、承認済みAI環境の運用、AIエージェントの権限管理が候補です。検出して終わらず、誤検知と利用定着を改善する運用責任が必要です。

まとめ：シャドーAI対策は、見つけて安全な代替手段へ導く

見つけた利用への対応と未把握範囲の調査を進め、安全な環境への移行と運用負担を確かめます。 シャドーAIは、会社の承認や監督の外にあるAI利用です。

会話型AIだけでなく、AI拡張機能、開発支援、未登録のAIエージェントも対象になります。

PwCの日本調査では、932人が答えた所属部署の実態について、未承認利用がある三つの回答の表示値合計が47％でした。把握できていない回答は19％です。

発見済みの問題への対応と、未把握範囲の調査を分けて進めます。

危険な利用は止めながら、承認済みAI、データ保護、相談先、例外承認を整えます。改善したかどうかは警告件数だけでなく、同じ利用者が適切な環境へ移れたか、見逃しと運用負担がどう変わったかで確認します。

日本語・業界固有のデータ判定、運用代行、エージェント権限管理は事業の候補です。一部署・一業務で顧客の困りごと、提供できる範囲、費用と継続意向を確かめてから、参入や提携を判断します。

参考文献

調査の対象と各社の提供機能を公式資料で確認しています。製品情報の確認日は2026年9月28日です。

事業案・点検方法・架空例は当研究所による整理です。

• PwC：生成AI実態調査2026 春（143頁）
• PwC：調査概要・対象者
• Microsoft・LinkedIn：2024 Work Trend Index
• NIST：AI Risk Management Framework
• 総務省・経済産業省：AI事業者ガイドライン第1.2版
• 欧州委員会：AI Actの概要・適用日程
• Microsoft：現行Purview DSPM
• Palo Alto Networks：AI Access Securityの対象と条件
• Zscaler：AI Access Security
• Netskope：Skylightによる生成AI対策
• Cloudflare：Shadow AI Reportの仕組みと前提
• Cloudflare：AI Security for Apps
• Cisco：AI Defenseの公式ホワイトペーパー
• IBM：Guardium AI Security
• Harmonic Security：提供機能
• Zenity：プラットフォームの提供機能
• OpenAI：事業向けデータ方針