2026-09-24AIセキュリティ情報漏えい中小企業

生成AIの利用ルールの先に要るもの ── 情報漏えい5つの層

生成AIの利用ルールを作った会社の文書には、たいてい同じ一文が入っています。「機密情報を入力しないこと」。

正しい一文です。ただ、これで防げる漏えいは全体の一部でしかありません。ここ数年に公開された事例を並べてみると、利用者が一つもミスをしていなくても漏れる、あるいは漏れかねない経路のほうが目立ちます。

社内ルールを「入力の禁止」だけで組んでいると、残りが丸ごと空きます。実際の事故、設定ミス、報告された脆弱性、研究者による実証を、5つの層に分けて、それぞれ何が効くのかを整理します。

① 入力 ── 利用者が貼り付けてしまう

一番有名な型です。2023年3月、サムスンの半導体部門がChatGPTの社内利用を認めた直後の20日ほどの間に、ソースコードや会議の内容を入力してしまう事例が3件発生しました。5月には、生成AIツールの社内利用が禁止されています。

問題は、入力した内容が会社の管理外のサービスに渡り、学習に使われる可能性があったことと、後から取り戻せなくなることです。当時使われていたのは個人向けの一般サービスで、法人向けのように、学習への利用の停止や保存の管理、利用状況の把握ができませんでした。実際に他者へ漏れたことまでは確認されていません。

ここは教育とルールが効きます。学習に使わない法人プランへの切り替えも同じ層の対策です。多くの会社が手を打っているのもここです。

サムスンは禁止に踏み切りましたが、大事なのは、使わせないことより、何を使っているかを把握することだと考えています。そのためには、使っていることを申告しやすい形にして、問題があれば法人プランや設定の見直しで手を貸します。AIセキュリティの方向性としても同じだと感じています。AIセキュリティを推進するISACAでも、AIの棚卸は、誰かを処罰するためではなく、使われているAIを特定するためのもの、という考え方です。

② 共有 ── 共有ボタンを押した先が公開だった

2025年の夏、ChatGPTの「会話を共有する」機能で作ったリンクが検索エンジンにインデックスされ、体調や人間関係を含む私的な会話が検索結果に出る状態になりました。提供元は、共有時に選べた「検索エンジンで見つけられるようにする」オプションを撤回しています。

入力した内容は本人が選んだものです。それでも、共有した先の公開範囲が想定と違えば漏れます。入力ルールでは止まりません。効くのは共有リンクの棚卸と、共有機能そのものを既定でオフにする設定です。これはAIに限った話ではなく、クラウドのストレージの共有リンクでも昔から起きてきた型です。

2026年9月24日時点で、ChatGPT・Claude・Gemini・Grokの共有ページのURLにアクセスすると、検索エンジンに載せないための指定（noindex）が返ってくることを確認しました。ただし、2025年にはChatGPTとGrokで、2026年7月にはClaudeで、共有ページが検索結果に出たと報じられています。なお、Claudeの件は、共有ページをrobots.txtでクロール禁止にしていたために noindex の指定が読まれず、URLだけが検索結果に載ったと報じられています。noindex が入っていれば安心、とも言い切れません。共有リンクは「知っていれば誰でも読める」公開ページです。どのサービスでも、公開と同じ扱いで棚卸をするのがよいと思います。Claudeは Settings > Privacy > Shared chats、Geminiは「Your public links」から、共有中のリンクを確認して削除できます。

③ 構築 ── 自分たちで建てたAIが開いていた

2026年2月、あるAIチャットアプリで、データベースの公開設定を誤ったまま運用されていたことが判明しました。3億件のメッセージと2,500万人分のデータが、認証なしで読み書きできる状態でした。このアプリ自体は大手モデルを呼び出すだけの「窓口」で、漏れたのはモデル側ではなく窓口側です。

同年5月に公開された調査では、外部から到達できるAIサービスが約100万件見つかり、そのうち相当数が認証なしで動いていました。大手のモデルをラップして立てたサーバも数百台単位で含まれています。

この層は「試しに建てたものが残る」のが怖いところです。検証用に立てた社内AIが、認証なしのまま外を向いている。中小企業ほど起きやすい類です。

④ 注入 ── AIが勝手に持ち出す

2025年6月に公表された「EchoLeak」（CVE-2025-32711）は、Microsoft 365 Copilotに対する攻撃です。細工されたメールが届いていると、利用者がCopilotに普段通り質問しただけで、AIがそのメールを指示として読み取り、社内のデータを外部へ送り出してしまいます。利用者はメールを開く必要すらありません。修正は提供されています。

2026年4月には、監視ダッシュボードのAI機能に同じ手口を使い、企業のデータを攻撃者のサーバへ送らせることができる脆弱性も報告されました。（Grafana側は、成立には利用者の操作が必要だとして、影響の見方に反論しています。）

AIが読み込む文書やWebページは、全て「命令の入口」になり得ます。ここは教育の射程外です。AIが外部へ通信できる範囲を絞る、という設計側の仕事になります。

⑤ 権限 ── 渡した鍵が大きすぎた

2026年3月末から4月初めにかけて、大手クラウドのAI基盤で、既定の権限の範囲を悪用するとサービスアカウントの認証情報や内部のリソースに届くことを、研究者が示しました。同じ2026年3月には、ある大手プラットフォーム企業で、社内AIエージェントの誤った助言を担当者がそのまま実行し、社内のアクセス範囲が2時間ほど広がりました（先方は、利用者データの不適切な取り扱いはなかったとしています）。こちらは、AIの提案を人が確認せずに反映した、という話です。

AIをメールやドライブ、チャットに繋ぐと、便利さと同じ量だけ鍵を渡すことになります。事故の原因は「AIが賢すぎたから」ではなく、権限設計が雑だったからです。これは従来のアクセス管理と全く同じ話です。

教育で止まるのは、5つのうち1つ

並べ直すと、こうなります。

層	効く対策
① 入力	申告しやすい形での実態把握・教育・利用ルール・法人プラン
② 共有	共有リンクの棚卸・共有機能の既定オフ
③ 構築	認証の既定オン・社内に立てたAIの棚卸
④ 注入	外部宛通信の制限・ベンダー修正の追随
⑤ 権限	最小権限・コネクタ単位の承認・監査ログ

①以外は、社員が完璧にルールを守っていても起きます。経営層に説明する時は、ここを先に言い切った方が話が速い。社員を信用するかどうかの問題ではない、設定と権限の問題です、と。

今日から手が付く4つ

大きな仕組みを入れる前に、費用をかけずにできることが4つあります。

何が使われているかを把握する ── 社員が使っているAIサービスと用途を、聞き取りやアンケートで洗い出す（ある程度の匿名性を持たせると、正直に答えてもらいやすい）。申告した人を咎めず、問題があれば法人プランや設定の見直しで支える。結果は既存の資産台帳に載せ、担当者を1人決めて、年に1回は見直す。禁止する前に、まず実態を知る
共有リンクの棚卸 ── 使っているAIサービスの共有機能を一覧にして、既定でオフにする
社内に立てたAIを探す ── 検証用に立てたまま外を向いているものがないか確認する
繋いだ先の権限を絞る ── メール・ドライブ・チャットと連携する時は読み取り範囲を最小にし、誰が承認したかを残す

どれも新しい技術の話ではありません。共有リンクの公開範囲、認証のかかっていないサーバ、渡しすぎた権限。AIが登場する前から、クラウドのストレージや社内システムで繰り返し起きてきた事故と、同じ型です。棚卸・認証・最小権限という、これまでのセキュリティでやってきたことを、AIという新しい置き場所に当てるだけです。

AIの導入を止める必要はないと考えています。止まるのは、事故が起きたあとのほうです。