数字で見るシャドーAI

　IBMが毎年公表する「Cost of a Data Breach 2025」（データ侵害のコストに関するレポート）では、侵害を経験した組織のうち63％がAI利用を統制する方針を「持っていない、または策定中」でした。さらに、調査対象となった組織の約20％（5組織に1組織）が、シャドーAIによるデータ侵害を報告しています。シャドーAIの利用が多い組織ほど侵害時のコストが高くなる傾向も示されており、IBMによると、シャドーAIの利用が少ない、または確認されていない組織との差は平均67万ドル（1億円規模）でした。方針の空白と、無許可利用の広がりが、実際の損害につながっているわけです。

　これらは世界的大企業も含む調査であり、日本の一企業にそのまま当てはまる数字ではありません。ただ、「方針がない／策定中の組織が多数派であること」「5組織に1組織がシャドーAIによるデータ侵害を報告していること」は、規模を問わず無視しにくい傾向です。むしろ、専門部隊を持たない中堅・中小企業ほど、利用実態の把握が手薄になりやすい点に注意が必要です。

　注意したいのは、シャドーAIが「悪意ある従業員」の問題ではない、という点です。先に触れた通り、その大半は「早く、効率的に仕事を片付けたい」という前向きな動機から始まります。むしろ、優秀で意欲のある従業員ほど新しいツールに手を伸ばしやすく、シャドーAIの発生源になりやすいと言えます。ここを取り違えて“犯人探し”をすると現場は身構え、無断のAI利用はますます見えなくなります。対策の出発点は処罰ではなく、まず実態を見えるようにすること――この順番を間違えないことが肝心です。

シャドーAIから伸びる、3つの被害ルート

　では、把握できていないAI利用は、具体的に何を引き起こすのでしょうか。代表的な3つの被害ルートを整理します。

1．機密情報の“うっかり入力”

　冒頭の田中さんのように、議事録や見積書、顧客リスト、ソースコードといった社外秘の情報を、無料のチャットAIに貼り付けてしまう経路です。2023年には大手電機メーカーのサムスン電子で、技術者が不具合確認のために社内のソースコードをChatGPTへ入力したと報じられました。同社はこれを受け、社内での生成AI利用を一時制限したとされます（米ブルームバーグの報道による）。ツールの設定によっては、入力した内容が学習やサービス改善に使われる場合もあります。会社の管理外に送信した情報は、後から完全に取り戻すことが難しい点にも注意が必要です。

2．退職者による“持ち出し”

　シャドーAIは、退職時の情報持ち出しとも結び付きます。個人アカウントで使っていた生成AIには、業務でやりとりした内容が会話履歴として残ります。会社が把握していない以上、退職時にその履歴を消去、回収する手だてはありません。そもそも退職者経由の情報流出は古くからの定番ルートで、IPA（情報処理推進機構）の「企業における営業秘密管理に関する実態調査2024」でも、中途退職者を経由した営業秘密の漏えいは発生経路の一つとして挙げられています。

3．ツール側で起きる“思わぬ情報漏えい”

　自社が正しく使っていても、利用しているAIサービス自体の不具合で情報が露出することもあります。実例として、OpenAIは2023年3月、オープンソースのライブラリの不具合によって、一部の利用者に他人のチャット履歴のタイトルが見えてしまったと公表しました。同社の説明では、特定の時間帯にアクティブだった有料利用者の約1.2％について、氏名やメールアドレス、クレジットカード番号の下4桁などの一部が他の利用者から見えうる状態だった可能性があるとされます。

　会社が把握していないツールでは、こうした事故が起きても気付けず、影響範囲も追えません。「どの従業員が、どのサービスを使っているか」を会社が把握していれば、提供元から注意喚起が出たときに即座に該当者へ連絡できますが、シャドーAIではそれができないのです。

禁止より把握、把握より仕組み

　前述した3つの被害ルートに共通するのは、「会社が把握していない」という一点です。逆に言えば、把握さえできていれば、対策は打てます。だからこそ第1回でも強調した通り、最初の一歩は全面禁止ではなく「見える化」が重要なのです。全面禁止が逆効果になりやすい理由は明快です。禁止しても、便利さを知った人は使い続け、ただ“報告しなくなる”だけだからです。すると会社は実態をつかめず、問題が起きても気付くのが遅れます。これが最も危険な状態です。

　目指すのは、禁止という建前ではなく、「把握」と「仕組み」です。順に、（1）安心して申告できる導線をつくり、（2）申告された利用を仕分けて、（3）安全な使い方を“公式の受け皿”（許可リスト）に集約していきます。

画像をご覧いただくには会員登録が必要です

会員登録・ログイン

図2 無罰の申告チャネル（著者作成）

　ただし、申告チャネルはあくまで出発点です。それだけでは「申告されなかった利用」が抜け落ちます。そこを補うのが、情シス側からの技術的なモニタリング（監視）です。大切なのは、これを「監視して叱る」ためではなく、見えていない通信を“見える化”するために使うと、目的をはっきり社内に伝えること。無罰の申告と組み合わせて初めて、把握の精度が上がります。

　必ずしも大掛かりな投資は必要ありません。また、既にある仕組みのログで確認できることもあります。

　特に、専任担当を置きにくい中堅・中小企業では、いきなり高度なツールをそろえる必要はありません。「既存ログの確認→無罰の申告→（必要に応じて）可視化ツールの導入」と、できるところから段階的に始めるのが現実的です。もちろん、これで万全というわけではありません。AIの利用状況は数カ月で変わるため、“把握の仕組み”は定期的に見直すことが前提になります。技術での検出と、現場からの申告。この2つは対立するものではなく、「見える化」を両側から支える車の両輪です。

やるべきこと

• 「AIを使ったら、この窓口に一言」という無罰の申告チャネルを用意する（フォーム1つでよい）
• 申告された使い方を「許可／要確認／停止」に仕分けし、安全なものは許可リストとして社内に共有する
• まず既存のプロキシ／ファイアウォール／SaaS管理画面のログで、どのAIサービスへ通信が出ているかを確認する（可視化の専用ツールは段階的に検討する）

やってはいけないこと

• 正直に申告した従業員を叱る、処分する（一度やると、以後は誰も申告しなくなる）
• 「申告がないから、シャドーAIは無い」と思い込む（“申告されない利用”こそ見えないリスク。だから技術的な確認も併用する）
• 個人アカウント任せのまま放置する（退職時に履歴を回収できない）

今日からできる一歩：無罰の申告チャネルを1本立てる

　まず「AIを業務で使ったら、ここに一言だけ書いてください」という申告フォームを1つ用意し、「正直に申告した利用を、頭ごなしに禁止したり取り上げたりはしません。安全な使い方を一緒に考えます」と先に宣言します。集まった申告を「許可／要確認／停止」に色分けすれば、それがそのまま会社の許可リストの原型になります。隠さず言える空気をつくることが、いちばん安く、そして効果的な対策です。

　把握の次は「線引き」です。連載第3回は、ChatGPTなどのチャットAIに“何を入れて良いのか”を取り上げます。入力した情報の行方、学習設定やAPIと一般チャットの違い、そして「入れて良いもの／ダメなもの」を、そのまま使える基準として整理します。

著者プロフィール：廣山 豊

　KDDIアイレット 内部統制室 室長／クラウド・イノベーション本部 セキュリティ事業部　部長／gaipack本部 gaipack特命部 AIDDセキュリティ室 室長

　AWS および Google Cloud の運用・運用自動化のための開発責任者を経て、現在はセキュリティ事業を統括。AIDD セキュリティ室では、AI に対するガバナンス構築やガイドライン作成のコンサル業務を行う。また、内部統制として各種監査対応やインシデントハンドリングも行っており、運用やセキュリティ、開発など横断的な知識が強み。

関連リンク : 2025 Japan AWS Top Engineers (Security)