こんにちは、Ryohei(@ityryohei)です!

文章の要約、コードレビュー、画像作成、アクセス解析の説明。便利な生成AIは、会社が正式導入する前から現場へ入り込みます。担当者が個人アカウントで顧客メールを要約したり、無料のAI拡張機能へソースコードを貼り付けたりすると、管理者が把握しない場所へ業務データが移動します。こうした未承認のAI利用は「シャドーAI」と呼ばれます。

英国NCSCは2026年9月7日、「The hidden risks of shadow AI」を公開しました。同資料は、シャドーAIを組織の承認済みシステムやプロセスに記録されていないAI技術の利用と定義し、機密情報の露出、データに対する可視性・統制の喪失、攻撃者に与える新しい機会を主なリスクとして挙げています。

これは特定企業の漏えい事件を発表した記事ではありません。また、AI利用そのものを中止するよう求める内容でもありません。業務上の需要を満たす安全な選択肢がなければ、未承認利用は残り続けるという前提で、現状把握と代替手段の整備を促すものです。本稿では2026年10月13日時点の公式資料を基に、日本のWeb制作・サイト運営へ落とし込みます。

シャドーAIはなぜ普通の「便利ツール利用」より見えにくいのか

従来のシャドーITでは、未承認のクラウドストレージやチャット、私物端末などが問題になりました。シャドーAIでは、ブラウザーだけで使える対話サービス、IDE拡張、議事録ボット、画像生成、翻訳、問い合わせ要約など、入口が非常に多くなります。登録不要の機能や既存SaaSへ後から追加されたAI機能もあり、「新しいシステムを導入した」という自覚がないままデータ処理が始まることがあります。

さらに、AIへの入力は短い質問だけとは限りません。ファイル添付、リポジトリ参照、クラウドドライブ連携、ブラウザー履歴、メールボックス、会議音声など、便利になるほど取得範囲が広がります。利用者は一度の要約依頼と考えていても、組織側から見ると、顧客データや認証情報を第三者サービスへ送る新しいデータフローが生まれています。

Web運営で起こりやすい5つの持ち出し

1. 問い合わせ・注文・会員情報

返信文を作るため、顧客名、メールアドレス、注文番号、相談内容をそのまま個人用AIへ貼り付ける例です。文章生成に不要な識別子まで含まれていれば、目的に対して過剰な入力になります。EC、会員サイト、採用サイト、医療・士業関連サイトでは、自由記述欄に機微な情報が含まれる可能性も考えなければなりません。

2. ソースコードと設定ファイル

AIコーディング支援へ貼ったコードには、非公開アルゴリズムだけでなく、内部URL、テーブル名、クラウド構成、コメント、テスト用アカウントが含まれることがあります。特に.env、デプロイ設定、CI/CDログ、エラーログを丸ごと渡すと、APIキーやトークンが混入しやすくなります。秘密情報が見つかった場合は、単にチャット履歴を消すのではなく、資格情報の失効・再発行が必要です。

3. アクセス解析と障害ログ

アクセス解析のCSVやサーバーログをAIに分析させると、IPアドレス、URLパラメータ、ユーザーID、検索語、リファラーなどが含まれる場合があります。障害解析ではリクエスト本文やCookie、認証ヘッダーが記録されていることもあります。アップロード前に、必要な列だけを抽出し、識別子や秘密情報を除く処理が必要です。

4. デザイン素材と公開前情報

未公開キャンペーンの画像、商品情報、提案資料、顧客から預かったロゴを画像生成・校正サービスへ入れると、契約上の秘密保持や素材の利用条件に影響する可能性があります。「学習に使わない」という設定だけで判断せず、保存期間、管理者の閲覧、委託先、削除方法、生成物の利用条件を確認します。

5. AI拡張機能へ与えた接続権限

リスクは入力した文章だけではありません。ブラウザー拡張やIDEプラグインが、開いているページ、全リポジトリ、クリップボード、クラウドドライブへアクセスできる場合があります。個人アカウントでOAuth連携したサービスは、退職・異動時の棚卸しから漏れることもあります。何を入力したかに加え、どこまで継続アクセスを許したかを確認する必要があります。

日本の事業者が確認したい公的な注意点

個人情報保護委員会は2023年6月2日の注意喚起で、個人情報取扱事業者が生成AIへ個人情報を含むプロンプトを入力する場合、特定した利用目的の達成に必要な範囲であることを十分確認するよう求めました。また、本人同意なく個人データを入力し、そのデータが回答生成以外の目的で扱われる場合には、個人情報保護法に違反する可能性があるため、提供者が機械学習へ利用しないことなどを十分確認するよう示しています。

したがって、「有名なサービスだから」「有料プランだから」だけでは判断できません。契約するプラン、管理設定、地域、機能によってデータの扱いが異なる場合があります。入力内容と目的、サービス側の利用範囲、保存・削除、国外での取り扱い、再委託先などを、自社の法務・個人情報管理の担当者と確認してください。本稿は一般的なセキュリティ解説であり、個別案件の法的判断を代替するものではありません。

経済産業省は2026年3月31日に「AI事業者ガイドライン第1.2版」を取りまとめ、同年4月1日更新の公式ページで本編、概要、チェックリスト、ワークシートを公開しています。小規模組織でも、サービス名だけの許可リストではなく、利用目的、扱えるデータ、責任者、監視、事故対応まで整理する際の土台として活用できます。

禁止だけで終わらせない対策の優先順位

優先1:実態を把握し、責めずに申告できるようにする

最初から違反者探しにすると、利用が隠れます。どの部署が、何の作業を短縮するため、どのAIを使い、どのデータを入力・接続しているかを調べます。ヒアリング、簡易アンケート、経費・SaaS契約、SSOやプロキシのログ、ブラウザー拡張の棚卸しを組み合わせます。監視を行う場合は、従業員への説明、目的、収集範囲、保存期間、閲覧権限を明確にします。

NCSCのシャドーIT資料も、多くの未承認利用は悪意ではなく、正式ツールや手続きが業務ニーズを満たさないために起きると説明しています。「なぜ使ったか」を把握すると、安全な代替策の優先順位が見えます。

優先2:サービスではなく「データ×用途」でルールを作る

「生成AIは全面禁止」「この製品なら何でも可」という二択では運用しにくくなります。公開情報の校正、匿名化したコード例、社内限定資料、顧客個人データ、認証情報というようにデータを分類し、用途ごとに許可条件を決めます。

  • 公開済み文章の要約:承認済みサービスで利用可。出力は人が確認する
  • ソースコード:秘密情報を自動検査し、対象リポジトリを限定した法人管理環境のみ
  • 問い合わせ・顧客データ:必要部分を最小化・仮名化し、契約と管理設定を確認した環境のみ
  • パスワード、APIキー、秘密鍵、セッショントークン:AIサービスへ入力禁止
  • 公開・送信・削除などの操作:専用権限と実行前承認、監査ログを必須にする

優先3:承認済みの代替手段を早く提供する

申請に数週間かかる一方、無料AIは数秒で使えるなら、現場は後者を選びがちです。低リスク用途向けの承認済みAI、相談窓口、短期間の試行環境を用意し、判断期限を示します。管理者アカウント、SSO、MFA、利用者の追加・削除、共有設定、監査ログ、データ利用設定を組織側で統制できるプランを選びます。

優先4:契約・設定を継続的に見直す

導入時の審査で終わらせず、機能追加や規約変更も追跡します。確認項目は、入力と出力の保存期間、モデル改善への利用とオプトアウト、管理者・提供者による閲覧、データ所在地、再委託先、削除手順、エクスポート、インシデント通知、サポート時のアクセス、退職者アカウントです。新しい連携機能は既定で無効にし、必要性を確認してから個別に有効化します。

優先5:漏えいを前提に初動を決める

未承認AIへデータを入力したことが分かったら、利用者を責める前に、何を、いつ、どのアカウント・機能で、どこまで共有したかを保全します。サービス側で削除可能かを確認し、資格情報が含まれれば即時失効します。個人データ、顧客契約、営業秘密、著作物への影響を担当部門と評価し、必要な通知・報告を判断します。証拠を消す恐れがあるため、自己判断で履歴だけを削除させない手順も必要です。

小規模なWeb制作会社・運営チーム向けチェックリスト

  • 現在使われているAIサービス、拡張機能、個人アカウント、OAuth連携を把握しているか
  • 問い合わせ、ログ、コード、デザイン、認証情報をデータ分類へ当てはめたか
  • 承認済みAIで入力できるデータと禁止データを、具体例付きで示したか
  • サービスの保存・学習利用・削除・再委託・管理機能をプラン単位で確認したか
  • コードやログを送る前に秘密情報と個人データを検出・除去する工程があるか
  • SSO、MFA、最小権限、退職者削除、監査ログを組織アカウントで管理しているか
  • 新しいAIツールを短期間で相談・試行・承認できる窓口があるか
  • 誤入力時の連絡先、削除依頼、トークン失効、影響評価、顧客対応を手順化したか

限界:見つけたサービスを止めるだけでは再発する

ネットワーク遮断やアプリ制御は有効な層ですが、私物端末や別回線、サービス内蔵機能まで完全に把握できるとは限りません。DLPも、コード断片や文脈上の機密性を常に正しく判定できるわけではありません。技術的制御だけでなく、現場が安全な代替手段を選べる速度と、間違いを早く報告できる文化が必要です。

また、未承認利用をゼロにすること自体を唯一の指標にすると、実態が地下化します。把握率、承認までの時間、禁止データの検知、個人アカウントから法人環境への移行、誤入力後の封じ込め時間など、リスク低減につながる指標で改善を追います。

まとめ

2026年9月7日のNCSC資料が示す核心は、「知らないものは管理できない」という点です。シャドーAIは、利用者のモラルだけの問題ではなく、正式な環境が現場の需要に追いついていないことを示すサインでもあります。

Web運営者は、顧客データ、ソースコード、ログ、制作物、接続権限の流れを可視化し、データと用途ごとに利用条件を決める必要があります。承認済みの代替手段を迅速に提供し、契約・設定・アカウント・事故対応を継続管理することが、AIの利便性を残しながら漏えいリスクを下げる現実的な道です。

参考資料

この記事を書いた人

Ryohei

Webエンジニア / ブロガー

福岡のWeb制作会社に務めるWebエンジニアです。エンジニア歴は10年程で、好きな言語はPHPとJavaScriptです。本サイトは私がインプットしたWebに関する知識を整理し、共有することを目的に2015年から運営しています。Webに関するご相談があれば気軽にお問い合わせください。