シャドーAIのリスクと対策｜全面禁止に頼らない可視化・公式代替・監査の進め方

シャドーAIとは、従業員や部門が、会社の承認・管理外で生成AIサービスを業務に使う状態です。個人アカウントで議事録を要約する、顧客向け提案書の下書きを作る、ソースコードを外部AIへ貼り付ける、といった行為が該当し得ます。

結論から言えば、対策の出発点は全面禁止ではありません。「誰が、どのAIを、どの業務で、どの種類の情報とともに使っているか」を把握し、用途に応じた安全な代替手段とルールを用意することです。禁止だけでは、業務上の不便さを解消できず、個人アカウントや未把握のサービスへ利用が移るおそれがあります。

生成AIでは、個人情報・機密情報の漏えい、誤情報の利用、知的財産の取り扱い、第三者サービスの契約・設定の不整合などを分けて管理する必要があります。NISTの生成AIリスクプロファイルでも、データプライバシー、もっともらしい誤情報（confabulation）、情報完全性、知的財産、第三者コンポーネントを含むバリューチェーンなどがリスク領域として整理されています。NIST AI 600-1

本記事の手順、判定表、テンプレート、KPI例はMojiによる実務上の提案です。扱うデータ、契約、従業員への監督範囲、利用するモデル・サービス、許容できない誤りに応じて、法務・情報セキュリティ・人事と調整してください。

シャドーAIで問題になるのは「未承認」そのものではない

シャドーAIは、単に「会社が知らないAIツールがある」ことではありません。次の4つが同時に不明な状態になることが本質的な問題です。

• 利用者：誰が利用しているか、退職・異動後にアクセスを止められるか
• 入力：どの情報を貼り付け、アップロードし、連携したか
• 設定・契約：学習利用、保持、共有、権限、データ保存場所などの条件を確認できるか
• 出力・操作：何を根拠に使ったか、誤った出力や外部送信を後から追跡・修正できるか

そのため、シャドーAI対策は「ツール名のブラックリスト」を増やすだけでは完結しません。利用実態、入力データ、業務の影響度、統制可能性を結び付けて判断します。

シャドーAIの主なリスクを、発生経路ごとに整理する

特に個人情報については、「匿名化したつもり」でも、他の情報と組み合わせて個人を特定できる場合があります。個人情報保護委員会は、生成AIサービスに関する注意喚起を公表しており、個人情報取扱事業者が個人データを入力する場合には、利用目的との関係や、提供先での利用方法を確認する必要があると示しています。個人情報保護委員会：生成AIサービスの利用に関する注意喚起等

また、生成AIの出力は、正しそうな文体で誤った内容を返すことがあります。重要な意思決定、法令解釈、顧客への確定回答、対外公開物に使う場合は、モデル名ではなく「誰が、どの根拠を確認し、何をもって公開可能とするか」を定義してください。生成AIの基本的な仕組みと導入時の注意点は、生成AIとは？種類・使い方・活用例・導入時の注意点でも整理しています。

全面禁止だけでは残りやすい3つの問題

1. 業務上の需要が消えない
   要約、翻訳、下書き、調査、コード補助などで時間短縮の需要がある場合、承認済みの代替手段がなければ、利用は見えない場所へ移り得ます。
2. 申告する動機が生まれない
   発覚時の処分だけが強調されると、従業員は相談・申告よりも隠蔽を選びやすくなります。初期段階では、用途の申告を処罰ではなく安全な利用環境を整える材料として扱う設計が重要です。
3. 例外業務を処理できない
   顧客指定ツール、研究開発、採用、開発支援など、画一的なルールに収まらない業務があります。例外を認めるなら、責任者、対象データ、期限、ログ、見直し日をセットで管理します。

これは「何でも許可する」という意味ではありません。高リスクのデータや行為は明確に禁止し、それ以外は承認済みの環境・手順へ寄せるという設計です。

最初の30日で進める、シャドーAI可視化の手順

以下は、すでに未承認利用が起きている可能性を前提にした、Mojiの提案する最小構成の進め方です。いきなり全社監視を始めるのではなく、目的、対象範囲、閲覧権限、保存期間を事前に決め、就業規則・プライバシー方針・労務上の扱いと整合させてください。

ステップ1：経営・情報システム・法務・人事で「守る対象」を決める

最初に、ツールの可否ではなく、入力してはならない情報を決めます。分類は複雑にしすぎず、現場が判断できる3〜4段階から始めると運用しやすくなります。

この表は架空の例です。実際の区分は、自社の情報資産管理規程、顧客契約、個人情報の取り扱い、業界規制に合わせます。

ステップ2：利用実態を複数の経路で集める

一つの検知手段だけでは、実態を過大にも過小にも評価します。次の経路を突き合わせて、利用候補の台帳を作ります。

• 匿名または記名の利用実態調査：ツール名、用途、入力データ、困りごと、承認済み環境への要望を集める
• 購買・経費確認：法人カード、立替精算、部門契約から候補を拾う
• SSO・IdPの記録：会社アカウントで認証したSaaSを確認する
• ネットワーク・SaaS・端末の記録：組織の方針と権限の範囲で、業務端末・ネットワークから利用候補を把握する
• 申告窓口：「使いたいがルールが不明」「すでに使っている」を相談できる窓口を設ける

ここでの目的は、違反者リストを作ることではなく、安全な公式代替を優先すべき業務を見つけることです。NIST AI RMFでも、AIシステムのインベントリ、役割と責任、継続的なモニタリング・定期レビューをガバナンスの要素として示しています。NIST AI RMF Core

ステップ3：利用候補を「ツール」ではなく「業務×データ」で優先順位付けする

同じ生成AIでも、公開済み記事の見出し案を作る用途と、顧客の契約書を要約する用途ではリスクが異なります。次の4項目を各1〜3点で評価し、合計点が高いものから対応します。

• 影響度：誤利用・漏えい時の顧客、事業、法務への影響
• 機密性：入力に含まれる情報の重要度
• 統制不能性：管理者機能、ログ、契約、アカウント回収ができない度合い
• 利用頻度：利用者数、利用回数、対象業務への依存度

合計点は絶対的なリスク評価ではありません。モデル・サービスの仕様、入力品質、対象業務の影響、許容誤差によって結論は変わります。比較可能な順番を付けるための一般的な設計上の目安として使い、判断理由を台帳へ残してください。

公式代替を用意する：承認済みAIの最低要件

利用実態が見えたら、最も多い低〜中リスク業務から、承認済みの代替環境を用意します。最初からすべてのAIサービスを比較・導入する必要はありません。まずは「利用者が個人アカウントへ戻らなくて済むか」を基準にします。

サービスを選ぶ際は、機能数やモデル名だけで決めず、上記の統制要件と現場の作業を同じ検証で確認します。生成AI導入の対象業務の選び方や定着設計については、生成AI導入前の業務棚卸しと現場定着の進め方も参照してください。

利用ルールは「禁止リスト」ではなく、用途別に書く

現場が迷うのは、「生成AIを使ってよいか」よりも「この作業で、この資料を、このサービスに入力してよいか」です。規程本文とは別に、日常業務で参照できる短い利用基準を用意します。

最低限、明文化する項目

• 承認済みサービスと利用可能なアカウント
• 入力禁止データと、加工・匿名化しても入力不可とする情報
• 許容する用途と、必ず人の確認を要する用途
• 外部公開、顧客送付、採用・人事評価、契約・会計判断などの承認者
• ファイルアップロード、外部コネクタ、ブラウザ拡張、APIキー利用の条件
• 未承認サービスを見つけた場合の申告先と是正手順
• 例外申請の条件、有効期限、再審査日

組織での生成AI導入・運用では、利活用ガイドラインやルールの策定・文書化、リスクマトリクスによる管理を扱う資料もあります。IPAの公開ページは、導入、運用、リスク管理の章を含むガイドラインを案内しています。ただし同ページは、掲載資料がIPA自体の見解を代表するものではない旨も明記しているため、参考資料として扱い、自社の規程・契約・法令への適合は別途確認してください。IPA：テキスト生成AIの導入・運用ガイドライン

例外申請テンプレート

次はMojiによる架空の例です。例外を口頭承認で終わらせず、期限付きの記録にします。

未承認利用を検知したときの是正フロー

未承認利用を発見した場合、即座に一律で懲戒へ進めると、以後の申告を妨げることがあります。一方で、認証情報・高機密情報・個人データなどの入力が疑われる場合は、事実確認と封じ込めを急ぐ必要があります。以下のように、データと影響で分岐させます。

1. 記録する：サービス名、利用者、期間、用途、入力・添付・連携した情報、共有先、アカウント種別を確認する。
2. 緊急度を判定する：認証情報、個人データ、顧客機密、未公開情報が関わる場合は、情報セキュリティのインシデント手順へ接続する。
3. 利用を止めるか、代替へ移すかを決める：低リスクの一般利用であれば、承認済み環境へ移行させる。高リスクなら、利用停止、連携解除、パスワード・トークン失効、関係者への連絡などを優先する。
4. 原因を分類する：ルール未周知、公式環境の機能不足、申請が遅い、業務期限、設定不備のどれかを分ける。
5. 再発防止を反映する：ルール、公式代替、教育、申請導線、ログ、権限設定のどこを変えるか決め、期限と責任者を置く。

AIリスク管理は、一度ルールを出して終わりではありません。NIST AI RMFは、ガバナンスを横断的に位置付け、文脈の把握、測定、対応を反復する考え方を示しています。NIST AI RMF 1.0

運用が機能しているかを確認するKPI

KPIは「未承認利用をゼロにする」だけに置くと、申告が減って見かけ上よく見える場合があります。可視化、公式環境への移行、リスク低減、業務定着を分けて測ります。

数値の目標値は、組織規模、対象部門、既存のログ品質、許容誤差によって変わります。導入初月から厳しい閾値を固定するより、まずベースラインを取り、四半期ごとに「どのリスクを下げるための指標か」を見直す方が実務に適します。

管理者向けチェックリスト

• □ 入力禁止データを、現場が判断できる言葉で定義した
• □ 利用実態調査、SSO・購買・申告など複数の経路で利用候補を集めた
• □ AIサービス台帳に、業務責任者・データ区分・契約形態・見直し日を登録した
• □ 高頻度の低〜中リスク業務に対し、承認済みの公式代替を用意した
• □ 個人アカウントから会社管理アカウントへ移す導線を作った
• □ 用途別の利用ルールと、人の確認が必須となる業務を明文化した
• □ 例外申請に期限、責任者、再審査日を設定した
• □ 未承認利用の検知後に、封じ込め・事実確認・改善へ進む手順を決めた
• □ 可視化、移行、統制、是正、定着を別々のKPIで定期レビューする

まとめ：シャドーAI対策は、利用を隠さなくてよい運用を作ること

シャドーAIのリスクは、AIを使うこと自体ではなく、組織が入力・契約・設定・出力・責任所在を管理できない状態から生まれます。対策の優先順位は、①守るデータを決める、②利用実態を可視化する、③承認済みの代替環境を用意する、④用途別ルールと例外申請を整える、⑤検知後の是正とKPIレビューを回すです。

生成AIを含む全体的なリスク管理の枠組みは、AIのリスク管理・マネジメントとは？対応方法や費用について、AI利用におけるセキュリティ設計はAIのセキュリティ対策とは？運用・開発方法や費用についてもあわせて確認してください。