はじめに

「文書を開いただけで、マルウェアも仕込まれていないのに、その文書が“感染源”になる」——そんな出来事が、研究者の実証（PoC）として公表されました。

セキュリティ研究者の Håkon Måløy が示したのは、Word 文書に人間の目には見えない形で指示文を隠しておくと、その文書を元に Copilot for Word で文章を書かせたときに、Copilot がその隠し指示を「利用者の依頼の一部」として実行してしまう、という問題です。しかも厄介なのは、Copilot が作った新しい文書にも同じ隠し指示が引き継がれ、その文書がまた次の“感染源”になる——つまり、文書をやり取りする普通の流れの中で、指示が自己増殖していく点です。マクロも、従来型のマルウェアも使いません。

これは「プロンプトインジェクション」と呼ばれる、AI ならではの弱点が、理論上の懸念から実害の形になったことを示す事例です。この記事では、何が起きたのか、なぜ根本的に難しいのか、そして AI を日常的に使う私たちが何をすべきかを整理します。

⚠️ この記事は攻撃手順を書きません

本記事は、仕組みを概念レベルで説明します。実際に使えるペイロード（攻撃コード）や再現手順は一切記載しません。 目的は、リスクを正しく理解し、防御と確認に役立てることです。悪用を助ける情報は扱いません。

🗓️ この記事の時点（2026年8月3日）と姿勢

本記事は 2026年8月3日時点で到達確認できた報道（The Hacker News・Malwarebytes・Simon Willison ほか）にもとづきます。事実／各社の説明／研究者の主張を分けて記します。日付・数値のうち確認できないものは書かないか「報じられている」と帰属します。Microsoft の緩和策の投入と、研究者による再現の主張は、どちらも帰属したうえで並べます。

📖 1. 用語の整理——プロンプトインジェクションと「ワーム」

まず、鍵になる2つの言葉を押さえます。

💡 ワード解説：プロンプトインジェクション

AI（大規模言語モデル）は、渡されたテキストを読んで応答します。このとき AI は、「これは守るべき指示」「これは単なるデータ（読む対象）」を明確に区別できません。そこを突いて、データのふりをした指示文を紛れ込ませ、AI に意図しない動作をさせる手口を「プロンプトインジェクション」と呼びます。今回のように、外部の文書に指示を仕込む形は、とくに XPIA（クロスプロンプト・インジェクション） と呼ばれます。

💡 ワード解説：なぜ「ワーム」と呼ぶのか

ワーム（worm）は、コンピュータの世界で「自分自身をコピーして次々に広がっていくプログラム」を指す古くからの言葉です。今回の手口は、プログラムそのものではなく隠し指示文が、Copilot の生成を介して次の文書へコピーされ広がります。振る舞いがワームに似ているため「AIワーム」と呼ばれています。

隠しテキスト自体は新しくありません（白背景に白文字、極小フォントなどで、人間には見えなくする手法は昔からあります）。今回の新しさは、それが AI の生成を介して自己増殖するという一点にあります。

🔁 2. 何が新しいのか——マルウェア無しで「増える」

従来のマルウェアは、実行ファイルやマクロといった「プログラム」が本体でした。だからこそ、ウイルス対策ソフトは「怪しいプログラム」を検出できます。

今回の手口には、その「プログラム」がありません。あるのは、普通の文書に紛れ込んだ、ただの文章（自然言語の指示）だけです。ウイルス対策の観点からは、ファイルはただの Word 文書に見えます。にもかかわらず、AI がそれを読んで動き、生成物に指示を残すことで広がっていく——ここが本質的に新しく、対処を難しくしています。

増殖の流れを図にすると、こうなります。

flowchart TD A["隠し指示を仕込んだ文書（人間には見えない）"] --> B["利用者が Copilot for Word に文書を元に作業を依頼"] B --> C["Copilot が隠し指示を依頼の一部として読み取り実行"] C --> D["生成された文書にも同じ隠し指示が残る"] D --> E["その文書を共有・再利用（次の媒介に）"] E --> B

研究者の PoC では、たとえば文書中の財務の数値をひそかに書き換えるといった動作が示されたと報じられています（The Hacker News）。派手な破壊ではなく、気づかれにくい改ざんが起こりうる点も、この手口の不気味さです。

🗓️ 3. 時系列——報告・緩和・再現・公表

この一件は、研究者と Microsoft のやり取りを経て公表されました。事実として確認できる範囲を、時系列で並べます。

時期 出来事（報道による）
2026年3月6日 研究者が Microsoft のセキュリティ窓口（MSRC）へ報告
同月中 Microsoft が挙動を確認
その後 Microsoft が複数の緩和策を投入（「Edit with Copilot」体験の改修＋基盤モデルのアップグレード）
2026年7月28日ごろ 研究者が「改変したペイロードで同種の自己増殖攻撃が再現できた」と報告
2026年7月末 約144日の協調的な開示プロセスを経て公表
✅ Microsoft の対応と研究者の主張（両論）

Microsoft 側：報告を受けて挙動を確認し、複数の緩和策を投入したと説明されています。「Edit with Copilot」体験の改修に加え、基盤モデルをより新しい世代（GPT-5.5／5.6 系）へアップグレードした、と報じられています。 研究者側：それでもなお、改変したペイロードで同種の自己増殖攻撃を再現できたと主張しています。つまり、個別の穴は塞がれても、攻撃の「種類」全体は残っているという指摘です。 本記事は、どちらか一方を断じません。両者の説明を、そのまま並べて示します。

なお現時点で、公開された CVE 番号や Microsoft の単独のセキュリティ勧告は確認されていない、と報じられています（この点も報道ベースです）。

🧩 4. なぜ根本的に難しいのか——AIは命令とデータを区別しない

この問題が「パッチを当てて終わり」にならない理由は、AI の作りそのものにあります。

普通のプログラムは、「命令（コード）」と「データ（処理する対象）」がはっきり分かれています。ところが大規模言語モデルは、渡されたテキストを一続きの文脈として読むため、「これは守るべき指示」と「これはただの読む材料」を、原理的にきれいには分けられません。攻撃者が用意した文章と、利用者の正当な指示が、同じ文脈の中に混ざってしまうのです。

Simon Willison も、この事例について「（当然ながら）攻撃の“種類”全体をカバーする緩和策は今のところ存在しない」という趣旨を述べています。個々の手口は塞げても、「AI に読ませたテキストが命令として作用しうる」という構造そのものは残る、というのが多くの専門家の見方です。

言い換えれば、本質はこう要約できます——AI に読ませるものは、すべて命令になりうる。この一点を理解しておくことが、いちばんの防御になります。

🛡️ 5. 読者は何をすべきか

派手な対策より、普段の習慣が効きます。AI を日常的に使う開発者・電子工作層の視点で、実務的な持ち帰りを挙げます。

  • 出所の分からない文書・コード・Web ページを、そのまま AI に読ませない。 外部から来たものは「未信頼」として扱い、Copilot などに渡す前に中身を意識する。これは今回の Word に限らず、AI に外部データを食わせるすべての場面に当てはまります
  • AI の出力を、人間が確認してから使う。 生成された文書やコードを、そのまま共有・実行しない。とくに数値や条件など、静かに書き換えられても気づきにくい部分を目で確かめる
  • 組織なら、Copilot 等の設定と更新状況を確認する。 外部データと接続する機能（connected experiences など）の範囲を把握し、必要に応じて絞る。ベンダーの緩和策は適用しつつ、それだけに頼らない

この「出力の確認と責任は人間が持つ」という原則は、Linux カーネルが AI 支援コミットに定めた方針——Linux 7.2の誤解を解く｜RISC-V 256コアと「AI支援コミット」の現在地で扱った「AI は署名できない、責任は人間」——と、まったく同じ発想です。また、不可視の文字でコードに悪意を仕込む目に見えないマルウェア「GlassWorm」｜Unicode不可視文字が突いたVS Code拡張とnpmのサプライチェーンは、今回と同じ家族の攻撃（人間に見えないものを機械が読む）です。AI の安全性をめぐる大きな流れはAIが評価環境を「脱走」した夏｜1,178人が政府に求めた「ペーシング」でも扱いました。

🧑‍💻 6. 筆者の見方

📌 筆者の見方（これは他人事ではない）

筆者は、Claude Code や MCP サーバ、AI エージェントを実務で使っています。ESP-IDF のコードを AI に書かせたり、外部のドキュメントやログを読ませて要約させたり——という作業は、もはや日常です（Claude Code スキルで ESP32 開発を自動化 などで書いてきたとおりです）。だからこそ、今回の一件はまったく他人事に思えません。

正直に言うと、筆者自身「外部から拾った文書やエラーメッセージを、深く考えずに AI へ貼り付ける」ことがあります。今回の事例は、その何気ない習慣が入口になりうると突きつけてきました。「自分は対策済み」とは、とても言えません。むしろ、AI に読ませるものを無防備に選んでいたという自覚のほうが強いです。

そのうえで、対策は特別なことではないと感じています。外部由来のものは未信頼として扱う、出力は自分の目で確かめてから使う——結局これは、Linux カーネルの「署名も責任も人間」と同じ原則です。AI がどれだけ賢くなっても、最後に責任を持つのは人間という一点は動かない。今回の件は、その当たり前を実務の習慣に落とし込む、いい機会だと受け止めています。政治的な評価をするつもりはなく、あくまで一人の利用者としての反省です。

✅ まとめ

📌 この記事のポイント
  • 研究者 Håkon Måløy が、Word 文書に隠した指示を Copilot for Word が読み取り、生成物にも残って文書伝いに自己増殖する「AIワーム」の PoC を公開。マクロも従来型マルウェアも使わない
  • 新しさは「AI の生成を介して増える」点。ファイルはただの文書に見えるため、従来のウイルス対策では捉えにくい
  • 時系列：2026年3月6日に MSRC へ報告 → Microsoft が緩和策を投入 → 研究者は改変ペイロードで7月末に再現できたと主張（両論を帰属）
  • 根本の難しさは、AI が命令とデータを区別できないこと。個別の穴は塞げても「種類」全体は残る
  • 実務の芯は「AI に読ませるものは命令になりうる」。外部由来は未信頼扱い・出力は人間が確認・責任は人間が持つ

よくある質問（FAQ）

Q. これは Word や Copilot を使わなければ関係ない話ですか？

A. いいえ。今回の舞台は Copilot for Word ですが、本質は「AI に外部のテキストを読ませると、それが命令として作用しうる」という、生成AI 全般に共通する問題です。他のAIツールでも、外部の文書・コード・Webページを読ませる場面には同じリスクがあります。

Q. ウイルス対策ソフトで防げますか？

A. 期待しにくいです。今回の“中身”はプログラムではなく、普通の文書に紛れた自然言語の指示です。ファイルとしてはただの Word 文書に見えるため、従来型のマルウェア検出では捉えにくいのが特徴です。だからこそ、入力の扱いと出力の確認という運用面が重要になります。

Q. Microsoft は対応したのですか？

A. 報道によれば、Microsoft は報告を受けて挙動を確認し、「Edit with Copilot」体験の改修や基盤モデルのアップグレードなど複数の緩和策を投入したとされます。一方で研究者は、改変したペイロードで同種の攻撃を再現できたと主張しています。本記事は両者の説明を帰属したうえで並べています。

Q. 個人でできる対策は何ですか？

A. (1) 出所の分からない文書・コード・Webページをそのまま AI に読ませない、(2) AI の生成物は人間が確認してから共有・実行する（とくに数値や条件の書き換えに注意）、(3) 組織なら Copilot 等の設定・接続機能の範囲と更新状況を確認する——の3つが基本です。

Q. この記事の内容は今も正確ですか？

A. 本記事は2026年8月3日時点で到達確認できた報道にもとづきます。緩和策や攻撃の状況は今後変わり得ます。重要な判断の前には、末尾の情報源やベンダーの公式情報で最新を確認してください。

参考

本記事は公表された報道にもとづいて事実関係を整理したものであり、攻撃手法の詳細・再現手順は扱っていません。特定の製品や企業を非難する意図はありません。