Vector 35のソフトウェア開発者Xusheng Li氏は8月20日、Windows標準搭載のペイント（Paint）とフォト（Photos）がAI画像を生成する際、マイクロソフトのサーバーから受け取った16バイトのGUIDをピクセルにエンコードし、肉眼では見えない電子透かしを形成しているとするリバースエンジニアリング分析結果を公開した。The Registerが8月25日に追跡取材で報じたことで、この話は開発者コミュニティに広まった。
Li氏の解析によれば、このプロセスはプロンプトが端末を離れる瞬間から始まる。ユーザーがペイントのCocreatorに説明文を入力すると、アプリはまずそのプロンプトをマイクロソフトのAzure Front Doorエンドポイントに送って審査を受ける。サーバーは3つのものを返す。修正済みのプロンプト、promptGenerationId、そしてwatermarkIdと呼ばれる値だ。このwatermarkIdこそが、後にピクセルへ書き込まれるGUIDである。
電子透かしはどう埋め込まれるのか
エンコードを担うコンポーネントはWatermarker.dllという名前で、サイズは1.67MB。302.4MBの暗号化されたモデルファイルmager.onnxeとセットになっている。16バイトのGUIDには先頭に0x4cのマーカーが付き、末尾にチェックサムが付加され、合計18バイト、展開すると144ビットになる。各ビットを担うには最低でも8×8のピクセルブロックが必要なため、電子透かしを埋め込める最小の画像サイズは192×192となる。
そのコストは軽くない。Li氏が512×512の画像を計測したところ、26万2000ピクセルのうち19万3000ピクセルが改変されており、割合にして約74%だった。手法はコンテンツ適応型のブロックSVD系アルゴリズムで、肉眼では判別できないが、実際には画像の大部分を書き換えている。
同じGUIDは、C2PA Content Credentialsのメタデータにもsoft-binding（ソフトバインディング）の形で書き込まれる。アルゴリズム識別子はcom.microsoft.invismark.1と表記され、マイクロソフトによって署名される。ピクセル側とメタデータ側にそれぞれ1つずつ存在し、互いにバックアップし合う仕組みだ——C2PAのメタデータを剥ぎ取っても、ピクセル側の電子透かしは残る。
対応フォーマットはPNG、JPEG、GIF、そしてペイント独自の.paintだ。BMPは対象外で、Li氏はBMPが完全なC2PAマニフェストを格納できないためだと分析している。
2つのアプリで対応が異なる
ペイントとフォトでは、電子透かしの埋め込みに失敗した際の挙動が異なり、この違いが多くを物語っている。
- ペイント：電子透かしを埋め込めなければ、生成そのものが失敗扱いとなり、画像はユーザーに一切返されない。
- フォト：エラーログを記録した上で、電子透かしのない画像をそのまま渡す。
フォトのImage CreatorとRestyle Imageは、いずれも同じWatermarker.dllを使用している。ペイントの「電子透かしがなければ画像も出さない」という設計は、マイクロソフトの製品思想において電子透かしが生成フローの必須要素であり、後付けのオプションではないことを示している。
Li氏はさらに、ペイントが前回のpromptGenerationIdをlastPromptGenerationIdとして次回の審査リクエストに添えて送信している点にも気づいた。これにより、連続する複数回の生成がサーバー側で明示的に1本の鎖として連結される。
「ネットにつながっている」という事実
この仕組みが最も誤解されやすいのはCopilot+ PCにおいてだ。この種の端末はローカルNPUを搭載し、画像生成は実際に端末上で実行されており、マイクロソフトも一貫して「ローカル生成」を売り文句にしてきた。しかし、プロンプトの審査と来歴署名の2つの工程はいずれもクラウド側で行われる——GUIDはサーバーから受け取る必要があり、C2PA署名もマイクロソフトが行う必要がある。絵はローカルで描かれるが、その通行証はネット経由で発行される。
プライバシー上の推論はシンプルだ。マイクロソフト側が各プロンプトを送信元のアカウントと紐づけている限り、理論上は流出した画像1枚から電子透かしを逆引きすれば、誰が、どの生成で作った画像かを特定できる。Li氏の批判は電子透かし技術そのものではなく、開示の十分性に向けられている——マイクロソフトは自社のAI安全対策について公にしてきたが、C2PAマニフェスト内のGUIDがユーザーのプロンプトと紐づいていることまでは明言していない。The Registerはマイクロソフトにコメントを求めたが、記事執筆時点で回答は得られていない。
来歴証明と追跡の境界線
AI生成コンテンツに関するEUの透明性要件は、「これがAI生成物であるとユーザーに知らせる」ことに主眼を置いている。C2PAのような標準規格も、生成元や生成方法を明示するために設計されたものだ。マイクロソフトのこの仕組みは、単なる明示表示のさらに一歩先を行っている。生成のたびに一意の番号を発行しているのだ。
両者の技術的な実装はほぼ同じだが、用途はまったく異なる。ざっと計算すれば、「AI生成か否か」という二値情報を区別するだけなら1ビットで十分だ。16バイトのGUIDは2^128通りの値を持ち、余ったビット幅はより細かい情報をエンコードするためにしか使えない。このビット幅そのものが設計意図を物語っている——これはコンテンツラベルではなく、生成イベントの身分証なのだ。
一般のWindowsユーザーにとって、短期的な影響は限定的だ。ほとんどの人はペイントで生成した画像を匿名性が必要な用途に使うことはないだろう。しかし、ペイントを気軽なツールとして使っている人にとって、はっきりしたことが1つある。ローカルで生成することは、痕跡が残らないことを意味しない。すべての画像は、マイクロソフトにしか説明できない番号を背負って世に出ていく。
参考資料：Xusheng Li氏が公開したリバースエンジニアリング分析レポート、The Register、CocoLoop。GUIDのバイト長、電子透かしのビット数、512×512画像のピクセル改変数、C2PAアルゴリズム識別子の表記を確認済み。