多くのチームが Microsoft 365 Copilot や似た業務AIを導入するとき、最初に期待するのは「もっと速く資料を探したい」だ。メール、文書、会議メモ、社内検索結果を読めるなら、普通のチャットボットより仕事に近い答えを返せるのは当然だ。
ただ、SearchLeak のような脆弱性は別のことを教えている。業務AIが会社のデータを読めるほど、それをただの検索ボックスとして扱ってはいけない。問題は「AIが作り話をするか」だけではない。外部コンテンツに誘導され、本来は社内だけで見えるはずのデータを外へ持ち出さないかが問題になる。
このミニ講座で扱うのは、「従業員が勝手に資料をダウンロードするか」ではない。もっと見えにくい層だ。外部コンテンツがAIに指示を出せるとき、ユーザーがコピー＆ペーストしていなくても、AI自身の回答を通じて内部データが外へ送られないか。業務AI検索を導入する前に、まずこの境界線を引く必要がある。
特定の脆弱性番号（CVE、公開された脆弱性を識別する共通番号）の修正方法を教える記事ではない。責任をユーザーに押しつける記事でもない。扱うのは、もっと日常的な判断だ。AI検索がメールや文書を見られるとき、チームはどのデータ境界を先に決めておくべきか。「ちょっと探して」を漏えい経路にしないための話だ。
このレッスンは「AI検索がメールを読めるとき、漏えいはハッカーだけが起こすものではない」を、読者が使える一つの判断問題に絞る。SearchLeakが示したのは、業務AIがメールや文書を検索できるようになると、リスクはモデルの誤答だけでは済まないということだ。外部コンテンツに誘導され、本来は社内だけで見えるはずのデータを外へ持ち出してしまう可能性がある。 本文の表やチェックは、チームが進む前に何を判断するかを見るためのものだ。
あわせて確認したいこと
この判断を実際のワークフローに入れるなら、ChatGPT Lockdown Mode は、敏感な作業の出口を減らすためにあるも合わせて確認すると、同じ停止点をタスク、権限、引き継ぎの確認に戻しやすい。
この判断を実際のワークフローに入れるなら、AI crawlerをサイトに入れるべきか？この表で3分で決めるも合わせて確認すると、同じ停止点をタスク、権限、引き継ぎの確認に戻しやすい。
SearchLeak が見せた業務フロー上の問題
Varonis Threat Labs が公開した SearchLeak の調査では、研究者は Microsoft 365 Copilot Enterprise の検索リンク、AI回答内のHTML画像読み込み、許可されていた Bing 関連ドメインをつなげて、データを外へ送る経路を作った。Microsoft はセキュリティ更新で関連CVEを修正済みで、Mashable もこの事例がAIアシスタントのセキュリティで繰り返される問題をどう示しているか整理している。
平たく言えば、危険は「攻撃者があなたのアカウントにログインする」ことだけではない。もっと厄介なのは次の流れだ。
- もともと読める： 従業員本人は、もともと一部のメールや文書を見る権限を持っている。
- AIも代わりに読む： AIもその従業員の仕事を手伝うため、それらの内容を読める。
- 外部が指示を隠す： 外部リンクやページが、AIが処理する内容の中に指示を隠す。
- 回答が出口になる： AIが回答するとき、機密情報を画像URLや別の外部リクエストに埋め込むよう誘導される。
- データが外へ出る： ユーザーが明示的にコピー＆ペーストしていなくても、内部データが外へ送られる可能性がある。
だから「従業員を信頼している」だけでは足りない。従業員は普通に見える検索リンクをクリックしただけかもしれない。本当に操作されているのは、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を、資料を素早く探すアシスタントとして使う。
- 外部コンテンツが、隠れた指示をAIに処理させようとする。
- AIの回答が外部リクエストを読み込めるなら、データ送信経路になる可能性がある。
- チームはデータ分類、外部接続の制限、人手監視によって、「読めるもの」と「外へ出してよいもの」を分ける。
AI 整理カード
要約の前に、AIに状況を確認させる このレッスンを自分用チェックリストにしたいときは、信頼できるAIツールに以下を貼る。機密情報は入れない。
このBMCミニレッスンを自分の状況に当てはめたい：AI検索がメールを読めるとき、漏えいはハッカーだけが起こすものではない
この記事が扱う具体的な問題：SearchLeakが示したのは、業務AIがメールや文書を検索できるようになると、リスクはモデルの誤答だけでは済まないということだ。外部コンテンツに誘導され、本来は社内だけで見えるはずのデータを外へ持ち出してしまう可能性がある。
記事URL：https://boosterminiclass.com/ja/posts/copilot-searchleak-data-boundary-checklist/
記事を要約するだけにしないでほしい。まず、次の3点を確認する質問をしてほしい。
1. いま扱っている実際のワークフローまたは判断は何か。
2. その流れに関わるデータ、権限、アカウント、費用、外部実行は何か。
3. 今日ほしいのは、停止判断、試用チェックリスト、引き継ぎテンプレート、リスク分級のどれか。
そのうえで、この記事固有の枠組みで私の状況を確認してほしい：1. このAI検索・要約ツールは、どのメール、文書、チャット履歴、顧客データを読めるのか；2. 従業員本人が見られる情報でも、AIが外部ページ、画像、フォームへ持ち込むべきではないデータはどれか；3. 検索リンク、外部コンテンツ、HTML返信、許可済みドメインがデータ送信経路にならないか；4. 業務AI検索を導入する前に確認する、データ境界、監視、人手対応のチェックリスト。
出力してほしいもの：
- 進める、範囲を絞って試す、一度止める、のどれかを一文で判断する。
- 枠組みを私の状況に当てはめ、準備済み／証拠不足／人間確認が必要、に分けた表。
- 今日できる最小の一手。
- 担当者、ログ、戻し方、人間レビューが必要な箇所。
アカウント、金銭、個人情報、外部実行に関わるときは、人間レビューで止める。
参考資料
- Varonis Threat Labs：SearchLeak: How We Turned M365 Copilot Into a One-Click Data Exfiltration Weapon — https://www.varonis.com/blog/searchleak
- Microsoft Security Response Center：CVE-2026-42824 — https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-42824
- Mashable：This Copilot vulnerability could expose emails, 2FA codes, and other sensitive data — https://mashable.com/tech/searchleak-microsoft-copilot-ai-assistant-vulnerability-report
