多くのチームが Microsoft 365 Copilot や似た業務AIを導入するとき、最初に期待するのは「もっと速く資料を探したい」だ。メール、文書、会議メモ、社内検索結果を読めるなら、普通のチャットボットより仕事に近い答えを返せるのは当然だ。

ただ、SearchLeak のような脆弱性は別のことを教えている。業務AIが会社のデータを読めるほど、それをただの検索ボックスとして扱ってはいけない。問題は「AIが作り話をするか」だけではない。外部コンテンツに誘導され、本来は社内だけで見えるはずのデータを外へ持ち出さないかが問題になる。

このミニ講座で扱うのは、「従業員が勝手に資料をダウンロードするか」ではない。もっと見えにくい層だ。外部コンテンツがAIに指示を出せるとき、ユーザーがコピー&ペーストしていなくても、AI自身の回答を通じて内部データが外へ送られないか。業務AI検索を導入する前に、まずこの境界線を引く必要がある。

特定の脆弱性番号(CVE、公開された脆弱性を識別する共通番号)の修正方法を教える記事ではない。責任をユーザーに押しつける記事でもない。扱うのは、もっと日常的な判断だ。AI検索がメールや文書を見られるとき、チームはどのデータ境界を先に決めておくべきか。「ちょっと探して」を漏えい経路にしないための話だ。

SearchLeak が見せた業務フロー上の問題

Varonis Threat Labs が公開した SearchLeak の調査では、研究者は Microsoft 365 Copilot Enterprise の検索リンク、AI回答内のHTML画像読み込み、許可されていた Bing 関連ドメインをつなげて、データを外へ送る経路を作った。Microsoft はセキュリティ更新で関連CVEを修正済みで、Mashable もこの事例がAIアシスタントのセキュリティで繰り返される問題をどう示しているか整理している。

平たく言えば、危険は「攻撃者があなたのアカウントにログインする」ことだけではない。もっと厄介なのは次の流れだ。

  1. 従業員本人は、もともと一部のメールや文書を見る権限を持っている。
  2. AIもその従業員の仕事を手伝うため、それらの内容を読める。
  3. 外部リンクやページが、AIが処理する内容の中に指示を隠す。
  4. AIが回答するとき、機密情報を画像URLや別の外部リクエストに埋め込むよう誘導される。
  5. ユーザーが明示的にコピー&ペーストしていなくても、内部データが外へ送られる可能性がある。

だから「従業員を信頼している」だけでは足りない。従業員は普通に見える検索リンクをクリックしただけかもしれない。本当に操作されているのは、AIがデータを読み、整理し、回答を生成する部分だ。

業務AI検索を導入する前に、データを三層に分ける

最初から「Copilot を有効にするか」と聞かないほうがいい。AIが読める可能性のあるデータを先に分ける。データの種類によって、必要な扱いが違うからだ。

データ階層AIに許可する使い方先に必要な境界
一般業務データ公開文書、会議アジェンダ、通常のプロジェクト状況要約、検索、ToDo整理に使える出典を残し、未確認情報を確定事項として書かせない
社内機密データ顧客リスト、見積もり、契約書ドラフト、社内財務、従業員データ社内文脈での検索補助に限る。外部ページや画像リクエストへ持ち込ませない読み取り範囲を制限し、検索記録を残し、不要な外部接続を閉じる
高リスクデータ二要素認証(2FA)のワンタイムコード、パスワードリセットメール、鍵、未公開の取引・法務情報AIに要約、転述、自動返信で使わせないデータ源から隔離し、AIの検索範囲に入れない

この表が防ぎたいのは、人がダウンロードボタンを押すことではない。AIの回答そのものが出口になることだ。大事なのは、「人が見られる」ことと「AIが自由に処理してよい」ことは別だという点だ。人が二要素認証(2FA)のワンタイムコードを見れば、普通はそれが機密情報だと分かる。AIがそれをただのメール本文として扱うと、悪意ある指示に従って回答やURLに入れてしまうかもしれない。

事故後に聞くべきなのは、誰がリンクを踏んだかではなく、どの境界がなかったか

チームが「怪しいリンクを踏まない」だけを防御線にしているなら、AIワークフローの責任を最後のユーザーに丸投げしているのと同じだ。SearchLeak 型の事例は、事後レビュー表で見るほうが向いている。どの段階を、そもそも通すべきではなかったのか。

レビュー項目答えが曖昧な場合のリスク次の対応
AI検索はどのメールボックス、文書、チャット履歴を読めるのか?ユーザー権限に沿ってAIの可視範囲が広がっているのに、実際の範囲を誰も把握していないまずデータ源を棚卸しし、AI検索に不要な高リスクフォルダを外す
AI回答は外部画像、フォーム、リンクを読み込めるのか?回答そのものがデータ送信経路になる可能性があるコンテンツセキュリティポリシー、許可ドメイン、HTMLレンダリング規則を確認する
検索リンク内のパラメータをAIが指示として扱わないか?普通に見えるリンクが、隠れた指示をAIに実行させる可能性がある検索パラメータをサニタイズし、異常に長いURLやHTMLを含む検索URLを監視する
機密データをAIが読んだとき、マスキングや拒否ルールはあるか?AIが認証コード、鍵、顧客データを普通の文章として要約する可能性がある高リスク形式をマスキングし、ワンタイムコードをAI検索から除外する
AI検索の異常ログを見る担当者は誰か?システムにログがあっても、事故前に不審なパターンを見つける人がいない担当者を決め、外部送信リクエスト、異常検索、拒否ログを定期的に確認する

すべての会社がセキュリティ研究チームになる必要はない。ただ、「AIがデータを読んでくれる」ことを新しい業務フロー上の節点として扱う必要がある。節点である以上、データ範囲、外部接続、監視、人手対応を決めておくべきだ。

まだ利用範囲を広げないほうがいいケース

業務AI検索は便利だ。ただ、次のような状態なら急いで利用範囲を広げないほうがいい。

まだ広げないほうがいい状況先に止める理由
フォルダ権限を何年も整理していないAIが退職者、部署横断、古いプロジェクトメンバーの古い権限まで引き継ぐ
メールボックスにワンタイムコードやリセットリンクがよく届くこれらはAIに検索、要約、転述させるべき内容ではない。先に業務フローを変えるか隔離する必要がある
AI回答が外部コンテンツを埋め込める回答が画像、フォーム、外部URLを読み込めるなら、データ送信経路として扱う必要がある
監査ログを見る人がいないログがあっても誰も確認しないなら、事故後の説明材料になるだけで、事前検知にはならない
ユーザーがAIの読んだデータを把握できない画面に答えだけが表示され、出典や可視範囲が分からないなら、従業員は採用してよい回答か判断しにくい

使い方を切り替える判断も大事だ。たまに公開文書を整理したいだけなら、あるいは会社の権限管理がまだ混乱しているなら、全社検索をいきなり有効にするより、範囲を絞ってコピー&ペーストで使うAI下書きフローのほうが安全な場合がある。

小さなチームが先にできる三つのこと

第一に、「AIに読ませたい」データだけでなく、「AIに読ませるべきではない」データを整理する。ワンタイムコード、パスワードリセットメール、鍵、未公開の法務文書などは、もっと明確に隔離する必要がある。

第二に、AI検索の外部とのやり取りをチェック項目に入れる。外部リンクを開けるのか。画像を読み込めるのか。どのドメインが許可されているのか。検索パラメータがそのままAIに渡されないか。これらは「モデルが何版か」より、漏えいリスクに直接関わる。

第三に、この件の担当者を決める。「ITが見る」と曖昧に言うのではなく、誰が毎週異常検索を見るのか、誰がセキュリティ通知を受け取るのか、誰がAI検索権限を一時停止できるのか、誰が影響を受けるデータ所有者に連絡するのかを明記する。

AI検索の価値は、仕事のデータをより速く見つけられることにある。リスクも同じく、データがより速く元の境界を越えることにある。導入前に、どのデータは読めるのか、どのデータは外へ持ち出してはいけないのか、どのリクエストを止めるのかを決めておく。漏えい後になって、足りなかったのはAIの能力ではなくデータ境界だったと気づくのは遅い。

生活四コマ

四コマ漫画:業務AI検索が資料を整理し、外部コンテンツに誘導され、チームがデータ境界と人手監視を追加するまで。

  1. チームは業務AIを、資料を素早く探すアシスタントとして使う。
  2. 外部コンテンツが、隠れた指示をAIに処理させようとする。
  3. AIの回答が外部リクエストを読み込めるなら、データ送信経路になる可能性がある。
  4. チームはデータ分類、外部接続の制限、人手監視によって、「読めるもの」と「外へ出してよいもの」を分ける。

AI 整理カード

この記事の状況に合わせて、AI に整理してもらう

自分の AI チャットツールに貼り付けると、このミニクラスを自分用のチェックリストにできます。BMC は、あなたが AI に貼り付けた内容を見ることはありません。

Share

このミニクラスを共有

このミニクラスが仕事の詰まりをほどく助けになったら、AI の使い方を考えている人にも共有してください。

参考資料