シャドーAI監査とは？社内で無断利用されるAIツールを検出・管理する方法

シャドーAI監査とは、従業員が組織の承認を得ずに業務で利用しているAIツールを検出・評価し、利用ルールのもとで管理下に置くための内部監査プロセスである。ChatGPTやGeminiなどを個人アカウントで使う動きが広がるなか、情報漏洩やコンプライアンス違反のリスクを把握したいIT担当者・情報セキュリティ責任者に向けて、本記事では準備・検出・評価・管理体制の構築までを順を追って解説する。タイのPDPA（個人データ保護法）をはじめとするデータ保護の観点も織り込みながら、現場が回せる現実的な進め方を示す。

シャドーAIとは、IT・セキュリティ部門の把握外で従業員が業務に使うAIツールの総称である。 利便性ゆえに現場へ一気に広がり、気づかないうちに機密データが社外のAIへ流れる経路になりやすい。まずは、なぜこれが従来の問題と質的に異なるのかを整理する。

シャドーITとは、IT部門の許可を得ずに使われるSaaSや私物デバイスを指す。シャドーAIはその一種だが、決定的に違う点がある。それは、入力したデータがAI側に渡り、学習や応答生成に使われ得ることだ。単にツールが管理外にあるだけでなく、プロンプトに貼り付けた機密情報や個人情報が外部のモデルへ流出し、しかも一度渡したデータは取り消せない。

さらにシャドーAIは、誰でも無料で即座に使える参入障壁の低さ、出力をそのまま業務判断に使うことによる品質・ハルシネーション（もっともらしい誤情報）のリスク、そしてブラウザ1つで完結するために可視化が難しいという厄介さを併せ持つ。「管理外のアプリ」という従来の枠だけでは捉えきれない、新しい性質のリスクとして扱う必要がある。

シャドーAIが急増している背景には、いくつかの要因が重なっている。①生成AIが普及し、従業員が私生活で日常的に使い慣れた。②会社の公式AIが未整備、あるいは使いにくく、現場が自衛的に個人ツールへ流れる。③無料・即時・スマートフォンで完結し、導入の障壁が事実上ゼロである。④早く成果を出したいというプレッシャーがある。

つまり「禁止しているのに使われる」というより、「便利すぎて使わない理由がない」のが実態に近い。各種のAIガバナンス調査でも、多くの組織で従業員がChatGPTやClaudeなどを個人アカウントや私物端末で利用しており、IT部門からはその実態が見えていない、と繰り返し指摘されている。性善説で放置するか、可視化して管理下に置くか——その分岐点に多くの企業が立っている。

シャドーAIを放置したときのリスクは、大きく3つに整理できる。1つ目は情報漏洩だ。顧客の個人情報、営業秘密、ソースコードなどを外部AIに入力すれば、それが社外へ流出し得る。2つ目は法令違反である。タイのPDPAをはじめとするデータ保護法は、個人データの目的外の提供や国外移転に制約を課している。従業員が無断で個人データをAIに渡せば、行政処分や罰則、信用毀損につながる違反となり得る。3つ目はガバナンスの崩壊だ。「誰が・どのAIに・何を入力したか」の記録がなければ、監査や説明責任を果たせず、出力の誤りが業務に紛れ込む品質リスクも管理できない。

いずれのリスクも、いざ漏洩や違反が起きると、その対応コストを大きく押し上げるとされる。問題は、これらが「見えないところ」で進行している点にある。

いきなりツールを探し始める前に、「誰が・どの権限で・どこまでを」監査するかを決めておく。 体制とスコープが曖昧なまま検出に走ると、現場の反発と作業の空回りを招きやすい。

監査チームは、単独の部門で完結させない。情報セキュリティ・IT、法務とコンプライアンス（PDPAなどデータ保護の観点）、各事業部門の代表、そして権限付与の後ろ盾となる経営スポンサーで構成するのが基本だ。

権限面では、ログやネットワーク監視の参照、従業員へのヒアリング、ツール棚卸しへのアクセスといった権限を、監査開始前に正式化しておく。同時に、従業員の監視は行き過ぎると労務やプライバシーの面で別の法的問題を生むため、配慮が要る。役割分担はRACI（実行・説明責任・相談・報告）などで明文化し、誰が最終判断を下すかを曖昧にしない。経営層の承認を事前に得ておくと、後段の是正措置（利用禁止や代替手段の提供）を実行する力が大きく変わる。

まず、現行のAI利用ポリシーがあるかを確認する。実際には、AIに特化したポリシーが未整備の企業は少なくない。基準づくりで参照できる枠組みとして、NIST AI RMF（Govern・Map・Measure・Manageの4機能で構成される、米国発の任意フレームワーク）と、ISO/IEC 42001（認証取得が可能な、国際的なAIマネジメントシステム規格）がある。両者は管理項目の重複が大きく、運用モデルにNIST AI RMFを、外部認証の目標にISO/IEC 42001を据える組織が多い。

この段階では、完成したポリシーを作る必要はない。「何を許可し、何を条件付き許可とし、何を禁止するか」という判断の軸を、データの機密度とツールの特性の掛け合わせで仮置きしておく。後のステップで検出結果と突き合わせながら精緻化していく。

監査スコープは3つの軸で定義する。①対象部門：全社一斉は負荷が重いため、機密データを扱う部門（営業、開発、人事、経理など）から始める。②対象ツール：チャット型AIだけでなく、AI機能を内蔵したSaaS、ブラウザ拡張、コード補助ツールまで含める。③対象データ：個人情報、営業秘密、規制対象データがどこにあるかを押さえる。

スコープを欲張ると、監査は終わらなくなる。第1サイクルは高リスク領域に絞り、回しながら範囲を広げていくのが現実的だ。あわせて、監査の期間と成果物（ツールの棚卸し表、リスク評価、是正計画）も最初に定義しておく。ゴールを明文化しておくことで、「やってみたが何も決まらなかった」という事態を避けられる。

検出は「ネットワーク・端末のログ」と「人への聞き取り」を組み合わせるのが基本である。 技術的検出だけでは私物端末経由を取りこぼし、聞き取りだけでは過少申告になりやすいからだ。

技術的な検出の基本は、プロキシ、ファイアウォール、SWG（セキュアWebゲートウェイ）のログから、既知のAIサービスのドメインへのアクセスを集計することだ。CASBやSASEを導入していれば、SaaSの利用状況をより広く可視化できる。DNSログやエンドポイント上のアプリ検出も補完になる。

ただし限界もある。私物端末やモバイル回線、自宅からの利用は、社内ネットワークを通らないため捕捉できない。また、暗号化通信の中身を見るSSL可視化には、プライバシーへの配慮と法的根拠が必要だ。検出の精度を左右するのは、既知AIサービスのドメインリストをどれだけ整備・更新できるかにある。新しいサービスは次々に登場するため、リストは一度作って終わりにはできない。

技術的検出の死角を埋めるのが、アンケートとヒアリングだ。ここで最も大切なのは、冒頭で「処罰が目的ではなく、実態把握と環境改善のための調査である」と明言することだ。責める姿勢が伝わると、回答は一気に過少申告へ振れる。

匿名アンケートで「どの業務で・どのAIを・どんなデータを使っているか」を集め、現場ヒアリングで本音（公式ツールの不便さなど）を拾う。実際には「禁止されていると知らなかった」という回答も多く、これは取り締まりの対象ではなく、教育ニーズの手がかりとして扱うべきだ。回収率を上げたいなら、経営層からの呼びかけを添えると効果が出やすい。数字を取り締まる調査ではなく、現場の事情を理解する調査として設計することが、結果的に正確な実態把握につながる。

SaaS管理ツール（SSPMやCASBなど）を使うと、契約・課金・OAuth連携・ブラウザ拡張といった情報から、利用中のAIサービスを自動的に棚卸しできる。とりわけ有効なのが、会社アカウントにOAuthで連携された外部AIアプリの洗い出しだ。これらは、許可を得ないまま社内データへアクセスする経路になり得る。あわせて、ブラウザ拡張の管理状況やIdP（ID基盤）のログイン履歴も突き合わせる。

手作業の棚卸しと違い、こうしたツールは継続的に検出できるのが強みだ。第1サイクルの監査が終わった後の「常時監視」の仕組みとして組み込むと効果的である。ツールは数多く存在するため、自社のIT環境（IdPやMDMの有無など）に合うものを選定する。導入そのものが目的化しないよう、何を検出したいかを先に決めておきたい。

検出したツールは「リスクの軸」で採点し、承認・条件付き承認・禁止の3段階に振り分ける。 全部禁止でも全部放任でもなく、リスクに応じた線引きが現実解になる。

結論として、リスクは「どんなデータを入れるか」と「ツールがそれをどう扱うか」の掛け算で決まる。

各軸を高・中・低でスコア化し、合算してリスクの大きさを見る。とりわけ注意したいのは、無料の個人向けプランは入力が学習に使われやすい設計になっている場合がある点だ。同じツールでも、契約プランによってデータの扱いが変わるため、「どのプランで使っているか」まで含めて評価する。

結論として、機密データを安全に扱える証跡があるものは承認、危ういが代替が難しいものは条件付き、論外なものは禁止に振り分ける。

この分類は固定ではなく、契約変更や代替手段の提供によって見直していく。最も重要なのは、「禁止」を決めるときは必ず「承認された代替手段」をセットで示すことだ。代替がないまま禁止だけ通告すると、現場は再びシャドーAIへ回帰してしまう。

AI BOM（AI Bills of Materials）とは、システムが使うモデル・データソース・依存関係・外部AIサービスを一覧化した「部品表」のことだ。シャドーAI監査の成果物として、検出したすべてのAIツールをAI BOMに登録し、用途・データ種別・リスク区分・承認状態を記録する。

これが継続的なガバナンスの土台になる。新しいツールが現れたら追記し、監査の証跡として活用する。NIST AI RMFをはじめとする枠組みでも、こうしたインベントリ（資産台帳）管理は共通の要件として位置づけられている。台帳として一元化することで、「誰も全体像を把握していない」という、シャドーAIの根本にある状態そのものを解消できる。逆に言えば、台帳がないままでは、いくら個別に検出しても管理は積み上がっていかない。

評価で終わらせず、ポリシー・技術統制・教育の3点で「使い続けられる仕組み」に落とし込む。 監査は一度きりのイベントではなく、回し続ける運用プロセスである。

AI利用ポリシーには、許可ツールの一覧、データ区分ごとの入力可否、禁止事項、違反時の扱い、承認申請のフローを盛り込む。実効性を高めるコツは、抽象的な原則論で終わらせず、「この業務では、このAIに、このデータを入れてよい／いけない」と具体例で示すことだ。

周知は配布で終わらせない。研修、理解度チェック、新入社員のオンボーディングへの組み込みまでセットにする。そして改訂サイクルをあらかじめ決めておく。AIもツールも、提供事業者の規約も変わり続けるからだ。注意したいのは、ポリシーが厳しすぎると再びシャドー化を招くという点である。現場が無理なく守れる現実的な線を引くことが、結果的に遵守率を高める。

ルールだけに頼らず、技術で支えることが重要だ。具体的には、①CASBやSWGで未承認AIサービスへのアクセスを制御する（ブロック、または警告）。②DLP（データ漏洩防止）で、機密データの外部AIへの送信を検知・遮断する。③企業向けAIをSSO・MFA付きで提供し、正規ルートを使いやすくする。④社内AI基盤でプロンプトと出力をログ化し、監視できるようにする。

ここで外せない原則は、「禁止の技術統制」と「正規手段の提供」を必ずセットにすることだ。アクセスを塞ぐだけでは、現場は抜け道を探す。安全で便利な公式ルートへ自然に誘導する設計が伴って初めて、技術統制は機能する。塞ぐことと使わせることは、対立ではなく両輪として設計する。

教育では、なぜ危険なのか（具体的な漏洩シナリオ）、何が機密にあたるのか、どう使えば安全なのかを伝える。一度きりの研修で終わらせず、定期的に実施する。モニタリングの面では、新規AIサービスの検出を継続し（Step1を定期的に再実行する）、AI BOMを更新し、インシデント対応のフローを用意しておく。

進捗を測るKPIの例としては、承認ツールの利用率、未承認アクセスの件数の推移、研修の受講率などがある。これらを使って、監査→是正→再監査というPDCAを回す。最後に運用上の視点を一つ。シャドーAIをゼロにすることはできない、という前提に立つことが大切だ。ゴールは根絶ではなく、リスクを許容できる範囲に保ち続けることにある。

典型的な失敗は「いきなり全面禁止」と「一度監査して満足」の2つである。 どちらも、結局はシャドーAIをより見えない場所へ潜らせてしまう。

代替手段を用意しないまま禁止だけを先行させると、現場は「これでは仕事が進まない」と反発し、私物端末や自宅でこっそり使うようになる。つまり、より見えない場所へ潜ってしまい、かえって逆効果になる。

回避策は、①禁止と同時に承認済みの代替ツールを提供する、②なぜ禁止なのかを腹落ちさせる、③現場の業務ニーズを聞き取り、公式ツールに反映する、④移行期間を設ける、というものだ。メッセージを「使うな」から「これを使ってくれ」へ変換することが鍵になる。セキュリティと生産性を対立させる設計は、ほぼ必ずどこかで破綻する。両立させる前提で制度を組むことが、定着への近道だ。

AIサービスは次々に登場し、従業員の使い方も変わっていく。そのため、一度の監査結果はすぐに陳腐化する。回避策は、検出を定期的に実行し（四半期ごとなど）、AI BOMを生きた台帳として更新し、ポリシーを定期改訂し、新サービスのリスク評価を継続することだ。要は、監査を「プロジェクト」ではなく「運用プロセス」として組み込み、担当・頻度・成果物を定常化する。NIST AI RMFなどの枠組みも、継続的なGovern（統治）とMeasure（測定）を前提としている。

最後に改めて確認したい。シャドーAI監査の目的は取り締まりそのものではなく、安全に使える環境を整え続けることにある。可視化→評価→管理→教育のサイクルを定着させれば、リスクを抑えながら、AI活用の果実をきちんと得られる。