シャドーAIと向き合う情シスの実務

「うちの社員、勝手にAIを使っていますね」。こう口にする情報システム（以下、情シス）担当者が増えています。

個人で契約できる生成AIサービスが普及した今、従業員が会社の承認を得ずに外部のAIツールを業務に使うケースは多くの組織で起きています。これをシャドーAIと呼びます。シャドーITのAI版です。

シャドーAIは情シスにとって頭の痛い問題です。ただ、「禁止する」だけでは解決しません。現場には業務を楽にしたいという切実なニーズがあり、禁止しても水面下での利用が続くだけのことが多いからです。

情シスに求められるのは、禁止という手段ではなく、シャドーAIの実態を把握し、リスクを分類し、安全に使える環境を整える設計です。この記事では、その実務の手順を整理します。

シャドーAIの発生メカニズム（現場ニーズ×整備の遅れ）と情シスの対応フロー概念図

シャドーAIが生まれる構造

シャドーAIが生まれる二つの構造（個人利用の容易化／整備とニーズのギャップ）を示す図

シャドーAIが生まれる背景には、二つの構造があります。

一つは、AIサービスの個人利用が容易になったことです。以前は社内にAIシステムを導入するには大規模な投資が必要でしたが、個人クレジットカードで契約できる生成AIサービスが普及したことで、担当者が個人判断で使い始めることが容易になりました。

もう一つは、会社によるAI整備が現場のニーズに追いつかないことです。業務の課題を抱えた担当者が「これをAIでできないか」と試したいときに会社がまだ承認済みのツールを用意していなければ、個人で探すという行動につながります。

この二つが重なるとき、シャドーAIは自然発生します。つまりシャドーAIは、従業員の行動の問題だけでなく、会社のAI整備の速度と現場のニーズの差から生まれる構造的な現象です。

この前提を情シスが持っていると、対応の設計が変わります。「なぜ禁止を守らないのか」という問いではなく、「どうすれば安全な選択肢を提供できるか」という問いが出発点になります。

実態を把握する

対応方針を立てる前に現状を把握することが必要です。「社内でどんなAIが、誰に、何のために使われているか」を可視化するステップです。

利用状況のヒアリング

まず手軽に始められる方法です。部門のリーダー層に「業務でAIを使っているか、使っているとすればどんなサービスか」を確認します。正式な調査として構えると答えにくくなるため、「現状を把握したい」という目的を前置きしたうえで、非公式に聞ける場を作る方が実態が出やすくなります。

ネットワークログの確認

技術的な実態把握の手段です。外部のAIサービスへのアクセスを示すログを確認することで、どのサービスが実際に使われているかを把握できます。ただし全ての利用が検出できるわけではなく、個人デバイスからの利用や、モバイル回線経由のアクセスは見えにくいことがあります。

アンケートや申告制の試行

禁止ではなく「申告すれば使える」という運用の下で実態を把握する方法です。まずは申告を求め、利用状況を集める段階を設けることで、全面禁止より実態が見えやすくなります。

どの方法を選ぶかは組織の文化と規模によって変わります。重要なのは「調査した」という事実ではなく、「何が使われているかを把握している」という状態を作ることです。

リスクを分類する

シャドーAIのリスク分類マトリクス（リスク種別×優先度）

実態を把握したらリスクを分類します。シャドーAIのリスクは一律ではなく、使われているサービスの種類と、入力されている情報の性質によって大きく異なります。

情報漏洩リスク: 外部のAIサービスに入力された社内情報が、サービス提供者のモデル学習に使われるリスクです。顧客情報・個人情報・機密情報・未公開の財務情報がAIに入力されていた場合、最も優先的に対処が必要なリスクになります
データの所在リスク: どこのサーバーで処理・保管されているかが不明な状態です。クラウドサービスによってはデータが海外のサーバーで処理されることがあり、情報管理のポリシーや規制への対応が必要な組織では確認が求められます
依存・継続性リスク: 個人が使い始めたサービスが組織として管理できない状態になることです。特定の担当者だけが使えるサービスに業務が依存していたり、サービスが突然終了・有料化したりした際の影響を把握できない状態がこれにあたります
利用追跡リスク: 誰がいつ何を入力したかの記録がない状態です。問題が起きた際の調査や、コンプライアンス対応のために、一定の利用ログが必要な場面が出てくることがあります

これらのリスクを整理すると、「すぐに対処が必要なもの」と「方針を決めれば許容できるもの」の区別がつきます。

承認・管理・推奨の三層で設計する

推奨・管理・禁止の三層設計図（ピラミッドまたは同心円）

リスクの分類ができたら、対応方針を設計します。シャドーAIへの対応は、「禁止か許可か」の二択ではなく、三つの層で設計すると実態に合います。

推奨層: 情シスが安全性を確認し、積極的に全社展開するサービスです。承認済みのAIチャットや、社内ネットワーク内で動作する生成AI環境がここに入ります。従業員が安全な選択肢として使えるものを用意することが、シャドーAIを減らす最も効果的な手段です
管理層: 利用を禁止はしないが、申告・確認を条件とするサービスです。業務目的での外部AIサービス利用を申告制にし、使用しているサービス名・用途・入力している情報の種類を把握できる状態にします。一律禁止の代わりに、実態を見える状態で運用するアプローチです
禁止層: 情報漏洩リスクが高く、業務での利用を認めないサービス・使い方です。機密情報・個人情報・未公開情報の入力を明示的に禁止し、違反時の報告経路を整備します

この三層を設計すると、「ルールがない」「全部禁止」のどちらでもない状態を作れます。従業員は何を使ってよいか迷わなくなり、情シスは把握できる範囲を広げられます。

自社に合わせた進め方 ── 「推奨層」を一つ用意するところから

シャドーAIへの対応を一気に整えようとすると、調査・分類・ポリシー策定・展開が同時並行になって動きが止まります。自社のペースで一歩ずつ進めることが現実的です。

最初の一手として有効なのは、「推奨層」に入るサービスを一つ用意することです。全社で安心して使えるAIチャット環境を一つ整備するだけで、シャドーAIの一部は自然に解消します。現場が「安全な選択肢がない」から個人サービスを使っていた場合、公式の選択肢があれば移行が進みます。

次に現状の利用実態を把握する調査を行います。完全な可視化を目指すより、「主要な部門で何が使われているか」をつかむ程度から始める方が早く動けます。

ポリシーの整備は、把握した実態を基に「禁止すべき使い方」を明確にするところから入ります。全面的なガバナンスの文書化は後から整えられます。まず「何はダメか」を明示するだけでも、現場の判断基準が変わります。

シャドーAIは「問題が起きてから対処する」より「起きにくい環境を整える」方が、情シスの負荷も組織のリスクも下がります。禁止の管理より、使える環境の整備に力点を置いた設計が長期的に機能します。