MS Paint がローカル生成画像にサーバー発行 GUID を埋め込んでいた

はじめに

AI 生成画像に「これは AI が作った」という印を付ける流れは、もう議論の段階を過ぎて実装フェーズに入っている。EU AI Act の透明性義務は 2026年8月2日に全面適用され、C2PA の Content Credentials はカメラメーカーからクラウド生成サービスまで採用が広がった。

その最中の 2026年8月24日、リバースエンジニアリングの報告が Hacker News で 312 ポイントを集めた。Xusheng Li 氏の解析によれば、Windows の Paint と Photos は AI 生成画像のピクセルそのものに、サーバーが発行した GUID を不可視ウォーターマークとして埋め込んでいる。しかも生成処理が NPU 上でローカル実行される経路でも、この GUID は毎回サーバーから取得されている。

争点は「AI 画像に印を付けたこと」ではない。付けられた印が、AI かどうかを示すフラグではなく、生成リクエスト 1 件ごとに一意な識別子だった点にある。本記事ではその技術的な中身、C2PA 仕様上の位置づけ、そして画像を扱うシステムを設計する側が何を確認すべきかを整理する。

何が見つかったのか

解析対象は Paint v11.2605.71.0 と Photos v2026.11060.2004.0。報告されている挙動は次の通りだ。

埋め込み対象は PNG・JPEG・GIF・.paint 形式。BMP は C2PA マニフェストを保持できないため除外されている。

ペイロードは 18 バイトで、構造は 0x4c || GUID[0-15] || checksum。GUID 16 バイトの前後にプレフィックスとチェックサムが付く形になっている。埋め込みには最小 192×192 ピクセルが必要で、512×512 の画像では 262,144 ピクセル中およそ 193,376 ピクセルの RGB 値が改変される。各ビットは 8 ピクセル単位のブロックに最低 3 回重複して書き込まれ、再エンコードや軽微な編集に耐えるよう設計されている。

実装の所在は Watermarker.dll。解析では 1.67 MB というサイズが、目に見えるロゴを重ねるだけの機能にしては大きすぎるという違和感が起点になっている。エクスポートされている WmkWriteWatermark() は次のシグネチャを持つ。

WmkWriteWatermark(
  output_pixels, payload, payload_length,  // payload_length は 16 固定
  width, height, stride, input_pixels, pixel_format
)

ペイロードが 16 バイト未満なら -6、超過なら -5、画像の容量が足りなければ -8 を返す。GUID 以外を入れる想定がない、用途を絞った関数だ。

同じ GUID は C2PA 署名済みマニフェストの c2pa.soft-binding アサーションにも記録される。アルゴリズム識別子は com.microsoft.invismark.1。

"c2pa.soft-binding": {
  "alg": "com.microsoft.invismark.1",
  "blocks": [{ "scope": "the entire image", "value": "83424621-..." }]
}

「ローカル生成」はどこまでローカルなのか

この報告で最も実務的に重い部分は、Copilot+ PC の Cocreator における生成フローの実測だ。報告されている順序はこうなっている。

プロンプトが .../v1/paint-cocreator/moderate-prompt に送信される
サーバーが watermarkId（GUID）、promptGenerationId、revisedPrompt を含む JSON を返す
Stable Diffusion の推論がローカル NPU で実行される
Watermarker.dll!WmkWriteWatermark() がサーバー発行 GUID をピクセルに埋め込む
画像が /v1/paint-cocreator/image-sign に送られ C2PA 署名を受ける

つまり、重い推論こそローカルだが、プロンプトのモデレーションと識別子の発行はリモートで、生成の前後にネットワーク往復が挟まる。「オンデバイス推論だからプロンプトは外に出ない」という読み方は、この経路については成立しない。

Microsoft のサポートページは、コンテンツフィルタの存在と「生成画像には AI 生成であることを示す C2PA マニフェストが含まれる」ことを記載している。一方で、ピクセルへの不可視 GUID 埋め込み、その GUID がモデレーション要求と紐づくサーバー発行値であること、com.microsoft.invismark.1 の存在は記載されていない、というのが報告者の指摘だ。

なお、この不可視ウォーターマークはユーザー設定でオフにできない。Paint には可視の Copilot ロゴを付けるかどうかのトグルがあるが、それとは別系統になっている。

技術的背景 — C2PA の hard binding と soft binding

なぜピクセルに埋めるのか。ここは C2PA 仕様を知っていると腑に落ちる。

C2PA のマニフェストは通常、ファイルのメタデータ領域に格納される（PNG なら caBX チャンク、JPEG なら APP11 マーカー）。そこに載る hard binding は資産全体または一部の暗号学的ハッシュで、改ざん検知としては強い。ただしメタデータは剥がせば消えるし、SNS にアップロードすれば多くの場合サーバー側で削られる。

そこで導入されたのが soft binding — 不可視ウォーターマークや知覚ハッシュ（フィンガープリント）を指す。Durable Content Credentials の定義では、soft binding は改ざん耐性を hard binding に譲る代わりに耐久性を担う。埋め込まれた識別子をキーにマニフェストリポジトリを検索できるため、メタデータが完全に剥がされた画像からでも元のマニフェストに辿り着ける。これが soft binding の設計意図であり、そのまま今回の懸念の実体でもある。

アルゴリズム名の invismark は、Microsoft が WACV 2025 で発表した InvisMark を指す。論文の主張は PSNR 約 51、SSIM 約 0.998 という不可視性を保ちながら、各種の画像操作を通しても 97% を超えるビット精度を維持し、**誤り訂正符号込みで 256 ビット（= UUID を余裕で収める容量）**を埋め込めるというもの。実装は GitHub で公開されている。研究として公開されていた技術が、OS 標準アプリのデフォルト経路に降りてきた、という構図になる。

規制が求めたものと、実装されたものの差

タイミングは偶然ではない。EU AI Act の Article 50 は、生成 AI の出力を機械可読な形式でマークし、人工的に生成・操作されたものとして検出可能にすることを提供者に義務づけており、2026年8月2日に全面適用された（8月2日以前から市場にあったシステムには 2026年12月2日までの猶予がある）。違反時の制裁金は最大 1,500万ユーロまたは全世界年間売上高の 3% のいずれか高い方だ。

ここで押さえるべきなのは、条文が求めているのは「AI 生成であることの識別可能性」であって、「生成リクエストごとに一意な識別子」ではない、という点だ。Hacker News の議論でもこの区別が中心論点になっている。「EU が望んだ通りのものだ」という指摘に対し、義務は AI 生成であることを示すことまでで、プロンプト固有の GUID を埋めることまでは求めていない、という反論が並んだ。

規制対応として必要な情報量は 1 ビットで足りるところに、128 ビットの一意 ID が入っている。トップコメントはこれを「デジタル版のプリンタ黄色ドット」と呼び、サーバー側にモデレーションログが残っている以上、識別子から発行時のリクエストへ遡る経路が存在すること自体を問題視した。GDPR の観点から扱われるべきだという意見も出ている。

エンジニアへの影響 — 何を確認すべきか

まず、適用範囲を誤読しないこと。 「Paint で保存した画像すべてに ID が入る」という要約が出回っているが、報告の範囲はそうではない。ウォーターマークが確認されているのは AI 生成パイプラインを通った画像で、リサイズのような通常編集で埋め込まれる証拠は示されていない。ただし境界は完全には確定していない。報告者自身が AI ベースの背景削除など「AI 支援の編集」については未確認としており、HN にはスクリーンショットが AI 生成として扱われたという報告も 1 件ある。自分の用途がグレーゾーンに触れるなら、実物を検査するのが早い。

検査方法は明快だ。 PNG なら caBX チャンク、JPEG なら APP11 マーカーを覗き、C2PA マニフェストの c2pa.soft-binding に値が入っているかを見る。C2PA 公式の c2patool でマニフェストをダンプすれば、alg と value がそのまま読める。生成画像を受け取って再配布するサービスを運用しているなら、これはインジェスト時のチェック項目に入れる価値がある。

「メタデータを消せば匿名化できる」は成立しない。 soft binding はメタデータ剥離を前提に設計されている。JPG → BMP → JPG のようなフォーマット変換で消えるのはマニフェスト側だけで、ピクセルに書かれた識別子は残る。逆に、ピクセルを十分に改変して soft binding を壊せば、今度は hard binding の署名検証が通らなくなる。匿名性と来歴証明の両立は、この設計上そもそも用意されていないと理解しておくのが正確だ。

社内で生成した画像の扱いにも効く。 未公開のモックアップやドキュメント用画像を Windows 標準アプリの AI 機能で作った場合、その画像には発行元サーバーのログに紐づく一意 ID が乗る。流出時に配布経路を辿る手がかりを、自組織以外が持つことになる。機密度の高いアセットについては、生成に使うツール自体を選定対象にするという判断が現実的な選択肢になる。

provenance を自分で実装する側にとっての教訓もある。 soft binding に何を入れるかは実装者の裁量だ。「AI 生成である」という事実を示すだけなら、コンテンツのクラス識別子で足りる。生成リクエスト単位の一意 ID を入れるなら、それは追跡可能性の設計判断であって、透明性の設計判断ではない。識別子の発行主体・スコープ・保持期間を、規制要求とは別のレイヤーとして明示的に決めるべきところだ。C2PA の署名鍵についても、Google Pixel の実装に対する攻撃実証がすでに報告されており、DRM と同じ攻防の構図に入るという指摘が議論の中で出ている。

まとめ

Windows の Paint / Photos は、AI 生成画像のピクセルにサーバー発行の GUID を不可視ウォーターマークとして埋め込んでいると報告された。18 バイトペイロード、最小 192×192、実装は Watermarker.dll。
Copilot+ PC の Cocreator では推論こそローカル NPU だが、プロンプトのモデレーションと GUID 発行はリモートで、生成の前後にネットワーク往復が入る。
埋め込み技術は Microsoft の研究 InvisMark で、C2PA の c2pa.soft-binding に com.microsoft.invismark.1 として記録される。soft binding はメタデータ剥離後もマニフェストに辿り着けることを目的とした仕組みだ。
EU AI Act Article 50 が求めるのは「AI 生成であることの識別可能性」であり、リクエスト単位の一意 ID はその要求を超える。この差分が今回の争点にあたる。
適用範囲は AI 生成経路に限られると報告されているが、AI 支援編集の扱いは未確定。実際の画像を c2patool などで検査するのが確実な確認手段になる。

来歴証明の仕組みは、偽情報対策として必要性が広く認められている。一方で「何を証明するか」と「誰を特定できるか」は、実装次第で簡単に地続きになる。今回の件は、その境界が仕様書ではなく DLL の中に置かれていた例として記録される。

今日のその他のニュース

Flutter と AGP 9 の対応状況が不透明 — Android Gradle Plugin 9 への対応をめぐり、Flutter の Android ビルドが壊れるケースが r/FlutterDev で報告されている。AGP のバージョンを固定しているか、CI が最新版を自動で拾う構成になっていないかを先に確認しておきたい。「昨日まで通っていた CI が今日落ちる」型の事故になりやすい。(Reddit)

Supabase Realtime Broadcast がバイナリペイロードに対応 — WebSocket・REST API・DB 経由で bytea を直接扱えるようになった。これまで画像フレームやセンサーデータを流すには Base64 化が必要でサイズが約 1.33 倍に膨らんでいたため、そのオーバーヘッドが消える。リアルタイム用途で Supabase を選ぶ判断が一段しやすくなった。(Supabase Changelog)

うるう秒の廃止が決定 — 即座に何かが壊れる話ではないが、うるう秒対応の smearing 処理や、閏秒を前提にした時刻検証ロジックを持つシステムは長期的に整理対象になる。時刻同期まわりを触る際の前提知識として押さえておきたい。(ITmedia)

MS Paint がローカル生成画像にサーバー発行 GUID を埋め込んでいた — C2PA soft binding が運ぶもう一つの情報