社内でAIアシスタントに文書を読ませる作業は、もう特別なことではなくなりました。「この報告書をもとに提案書の下書きを作って」「先月の議事録を要約して」——WordでもGoogleドキュメントでも、日常的に走っている操作です。
ここで一つ、確認しておきたいことがあります。その文書に、目に見えない指示が仕込まれていたらどうなるか。
2026年7月末、研究者のHåkon Måløy氏がMicrosoftのMSRCとの協調開示として公表した内容は、この問いに具体的な答えを出しました。しかも、単に「読まれてしまう」ではありません。読ませた結果として、その指示が別の文書に増えていくという部分が実証されています（Word worm crawls into Copilot, spreads chaos — The Register）。
見えない文字が、命令として読まれる
仕組み自体は拍子抜けするほど単純です。
Word文書の中に、白い背景の上に白い文字で、JSON形式のプロンプトを書いておく。人間が開いても何も見えません。印刷しても出ません。ところが、その文書を素材にしてCopilot for Wordに「これをもとに書いて」と頼むと、Copilotは書式を剥がしてテキストとして読み込みます。白文字も、ただのテキストです。
そして読み込んだCopilotは、そこに書かれた指示を、利用者が出した依頼の一部として扱います。これが間接プロンプトインジェクションと呼ばれる攻撃の基本形で、AIが「利用者の命令」と「読んだ文書に書いてある命令」を確実には区別できないことに由来します。
この構図自体は既知のもので、AIエージェントに社内データを触らせる前にでも扱いました。今回の研究が新しいのは、その先です。
「増える」ところが今回の本題
Måløy氏の実証で肝になるのは、Copilotが編集した文書に、同じ隠しプロンプトが白文字で書き足されるという挙動です。
順を追うと、こうなります。
- 汚染された文書をもとに、Aさんが Copilot に社内報告書を書かせる
- Copilot は隠し指示を読み、出力した報告書にも同じ隠し指示を白文字で付ける
- この時点で、社内報告書が新しい感染源になる
- 後日、Bさんがその社内報告書を素材に Copilot で別の資料を作る
- 同じことが起きる
3の時点で、最初の汚染文書も、攻撃者も、もう必要ありません。社内で正規に作られ、正規に共有されている文書が、それ自体で連鎖を続けます。研究では、これが主要な商用オフィススイートにおける文書経由のAIワーム自己増殖の初期の公開実証だと位置づけられています。
ここが従来のマルウェアと感覚的に違うところです。実行ファイルでもマクロでもありません。中身は、ただのテキストです。 ウイルス対策ソフトが検知する対象の形をしていません。
「もう直っている」で済まない理由
対応の経緯も押さえておく価値があります。
Måløy氏は2026年3月にMSRCへ報告し、Microsoftは3月31日に挙動を確認。2つの緩和策を展開しています。元のプロンプトの文言をブロックすることと、基盤モデルをGPT-5.5に上げることです。
ところが、氏が文言を変えたところ、攻撃の大枠は再現しました。公開の時点で、この種類の脆弱性に対する包括的な緩和策は存在しないというのが氏の見解です。
これは Microsoft の対応が悪いという話ではなく、攻撃の対象がコードの欠陥ではなく「モデルが自然言語を解釈すること」そのものだからです。特定の文言を禁止しても、意味が同じ別の文言が通ります。パッチで塞げる形をしていません。
同じ構造の問題として、AIが書いたコードの点検を誰が持つかという話はAIが書いたコードのセキュリティは誰が見るのかで扱いました。AIを業務に入れると、これまでなかった種類の入口が増えるという点では同じ系統の課題です。
発注する側・導入する側が決めておくこと
この話をCopilotだけの問題として片付けるのは正確ではありません。文書を読み込んで作業するAIアシスタントは、Google WorkspaceのGeminiも、社内に構築したRAGも、構造としては同じ入口を持っています。
そのうえで、いま決めておく価値があるのは次の3点です。
1. 外から来た文書を、そのままAIに読ませてよいか
いちばん効きます。取引先から届いた提案書、Webからダウンロードした資料、応募書類。社外由来の文書をAIアシスタントの素材にする前に、一度中身を確認するという運用を挟むだけで、初期の感染経路はかなり絞れます。
確認といっても難しいことではありません。文書全体を選択して文字色を変える、あるいはプレーンテキストに書き出して眺める。白文字の隠し指示は、これで見えます。
2. AIが生成した文書を、そのまま次の素材にしてよいか
今回の研究がいちばん警告しているのはここです。AIの出力を、確認せずに次のAIセッションの入力にすることが連鎖を作ります。 「Copilotで作った資料をCopilotに読ませる」は、日常の作業として自然に発生します。
現実的な線引きとしては、社内で共有・保管する版に落とす前に人が一度読む。これは元々やるべきことでもあります。
3. 事故が起きたときに、何が漏れうるかを把握しているか
AIアシスタントがアクセスできる範囲＝事故のときに漏れうる範囲です。Copilotにせよ Gemini にせよ、利用者本人が見られるファイルには基本的にアクセスできます。その利用者が、実は全社のドライブを見られる権限を持っていたというケースは珍しくありません。
ここはAI固有の話ではなく、共有権限とDLPの話です。Google Workspace側の制御可能な範囲はGoogle WorkspaceのDLPとプラン差で、監査の観点は監査ログとアラートで不審操作を検知するで整理しています。
使うのをやめる、という結論にはならない
念のため書いておくと、これは「AIアシスタントを業務から外すべき」という話ではありません。文書を読ませる作業の効果は大きく、やめる合理性はありません。
ただ、これまで「文書は開いても安全」という前提で動いてきた運用が、そのままでは成り立たなくなっています。マクロ付きのExcelを開くときには警戒する習慣が社内にあるはずです。それと同じ警戒を、AIに読ませる操作にも持つというだけの話です。
現時点で製品側の完全な防御がない以上、入口（外部文書）と出口（生成物の再利用）の2箇所に人の確認を挟むのが、いちばん費用対効果の高い対策です。
今週、1つだけ試すなら
直近でAIアシスタントに読ませた文書を1つ選んで、全選択して文字色を黒に変えてみてください。 何も出てこなければ、それで構いません。かかる時間は1分です。
そのうえで、社内のルールを1行だけ足す。「社外から受け取った文書は、AIに読ませる前に中身を確認する」。これで足ります。長い規程を作る必要はありません。
社内でAIアシスタントをどこまで、どの権限で使わせるか。文書の取り扱いと共有権限を含めて整理したい——そうしたご相談は、グリームハブの開発・AI・自動化のご相談で承っています。要件によって最適な構成は変わるため、個別にお見積りします。お問い合わせからご相談ください。
Sources
- Word worm crawls into Copilot, spreads chaos — The Register（2026年7月29日）
- Microsoft Copilot for Word vulnerable to self-propagating worm-like attack — CyberInsider
- Hidden prompt turns Microsoft Copilot into an AI worm — Malwarebytes（2026年7月）
- Researcher discovers self-propagating AI worm found inside Microsoft Copilot for Word — Cybernews
