Microsoft ペイントのAI画像には、Microsoftのサーバーが発行したGUIDが不可視透かしとして埋め込まれている。ソフトウェア開発者のXusheng Li氏は、同じwatermarkIdが署名済みのC2PA来歴情報にも記録されることを実画像で確認した。Microsoft フォトでは、別のpromptGenerationIdを同じ透かしライブラリへ渡すコード経路が見つかったが、実画像での動的確認までは示されていない。

ペイントの対象には、Copilot+ PCのNPUで画像を作るローカル生成機能も含まれる。ただし、画像生成を端末内で実行しても、プロンプトの審査と来歴情報への署名はオンラインだ。Microsoftはプロンプトとともに端末・ユーザー識別子を収集すると公表しているが、2種類のGUIDとアカウント情報を対応づけて保存・照合しているかは明らかにしていない。

画像ファイルに入るwatermarkId自体はMicrosoftアカウントIDではない。要求の連結と署名に使うpromptGenerationIdとも別のGUIDだ。両者は同じ審査応答で発行されるものの、第三者が画像から利用者を特定できることや、Microsoftがサーバー記録から生成者を照合していることは実証されていない。

AD

ローカル生成の前後でMicrosoftサーバーを通る

Li氏が調べたペイント 11.2605.71.0のCocreatorは、画像を作る前にプロンプト、スタイル、前回のpromptGenerationIdをAzure上の審査エンドポイントへ送る。サーバーは修正後のプロンプトに加え、新しいpromptGenerationIdとwatermarkIdを返す。前回のIDをlastPromptGenerationIdとして次の要求へ渡すため、一連の生成要求も明示的に連結される。

ペイント自身の認証済みセッションを使ったLi氏の試験では、サーバーはHTTP 200で2種類のGUIDを返した。その後、修正後のプロンプトと利用者のスケッチからローカルNPUが画像を生成し、Watermarker.dllがwatermarkIdをピクセルへ書き込む。

処理の対応関係は次の通りである。

段階 ペイントのローカル生成で扱う情報
プロンプト審査 prompt、style、前回のpromptGenerationIdを送信
審査応答 revisedPrompt、promptGenerationId、watermarkIdなどを受信
端末内の画像生成 revisedPromptとスケッチをNPUで処理
不可視透かし watermarkIdをピクセルへ埋め込み
オンライン署名 promptGenerationId、画像、生成条件などを送信
C2PAマニフェスト watermarkIdをsoft bindingへ記録する署名経路

したがって「ローカル」が指すのは画像を合成する推論部分である。Microsoftの公式説明も、Copilot+ PC機能はNPUで画像を生成する一方、Microsoftアカウントとインターネット接続が必要で、安全機能はAzure上で動くとしている。

16バイトのGUIDがピクセルとC2PAを結ぶ

透かしへ渡される本体は16バイトのGUIDだ。ペイントの実装は先頭の1バイト、GUID、1バイトのチェックサムを連結し、18バイト、すなわち144ビットへ展開する。各ビットを最低3回配置し、幅と高さがともに192ピクセル以上の画像を要求する。

Li氏が512×512ピクセルの合成画像で試したところ、全262,144ピクセルのうち193,376ピクセルが書き込み前後で変化した。これは視覚品質や加工耐性を測る試験ではないが、隅に小さな印を置く処理とは異なり、画像全体へ微小な変更を分散させる実装だと分かる。ペイントでは書き込みに失敗すると、画像生成全体がエラーになる。

さらに、ペイントから保存した実際のPNGには18,979バイトのcaBXチャンクがあり、C2PAマニフェストにcom.microsoft.invismark.1というアルゴリズム名と同じGUIDが入っていた。サーバーが返したwatermarkId、ピクセル内の透かし、c2pa.soft-binding.valueが一致したことになる。

C2PAのsoft bindingは、ファイル内のマニフェストがSNSや画像編集で失われても、画像から取り出した識別子を手掛かりに来歴記録を見つけ直すための仕組みだ。C2PAの公式リストにはcom.microsoft.invismark.1が画像・動画向けのMicrosoft Responsible AI InvisMarkとして登録されている。

ペイント版の再圧縮、リサイズ、スクリーンショット後の検出率は未公表である。C2PAの公式リストが示すのはInvisMarkという技術名と対象メディアまでで、今回のペイント実装がどの加工に耐えるかは別に測る必要がある。

AD

画像に入るGUIDとユーザーIDの距離

Microsoftはペイントのサポート文書で、乱用防止と監視のため、プロンプトと一緒に端末・ユーザー識別子を収集すると明記している。ローカル生成でもMicrosoftアカウントへのサインインが必須だ。審査サーバーは同じ要求に対してpromptGenerationIdとwatermarkIdを発行し、後の署名要求は前者と透かし入り画像をMicrosoftへ送る。この処理ならMicrosoft側で両GUIDとアカウント関連情報を相関し得るが、対応表の保存や照合運用は確認されていない。

しかし、画像に記録される値は生成ごとのGUIDであり、アカウント名や端末IDではない。公開資料からは、Microsoftが対応表を保存しているか、保存期間はどれほどか、実際に照合しているかが分からない。別々に生成した画像へ同じGUIDが付くとの証拠もないため、第三者が複数の画像を見ただけで同じ利用者の作品だと束ねられるとはいえない。

メタデータを削除した画像からGUIDを取り出すには、InvisMarkに対応した検出器も要る。Li氏の調査は一般向けのデコーダーやMicrosoftの来歴検索サービスを実証していない。考えられる追跡経路は、Microsoftが対応記録を保持している場合の照合であり、誰でも画像から個人を割り出せる仕組みではない。

フォトは別のGUIDを透かしへ渡す

フォト 2026.11060.2004.0にも同名のWatermarker.dllがあり、Image CreatorとRestyle ImageのローカルStable Diffusion経路から呼び出される。ペイントが専用のwatermarkIdを埋め込むのに対し、フォトのコードはpromptGenerationIdをGUIDへ変換して透かしに渡していた。透かし処理が失敗した場合、フォトはエラーを記録しつつ画像を返し続けるように見える点もペイントと異なる。

フォトについて示された証拠は主にバイナリの静的解析である。ペイントで行われた実際のサーバー応答や保存画像のC2PA解析と同じ水準の動的確認までは示されていない。両アプリが同じライブラリを使うことと、サーバー側で同じ保存・照合方針を採ることは分けて考える必要がある。

可視のCopilotロゴも別経路だ。ペイントの「表示しない」「常に表示」「毎回確認」という設定はAddPerceptibleWatermarkを制御するが、GUIDを書き込むWmkWriteWatermarkには作用しない。解析された版では、不可視透かしを止める利用者向け設定は確認されていない。

AD

EUのマーキング義務とC2PAのプライバシー勧告

EU AI ActのArticle 50は2026年8月2日から適用され、AIが生成・操作した出力を機械可読な形式でマークし、検出できるようにすることを生成AIシステムの提供者へ求める。だが、EUの公式説明はプロンプトに固有のGUIDや、利用者との対応づけを要求していない。Microsoftも今回の実装をEU対応として導入したとは説明していない。

C2PAの実装ガイダンスは、soft bindingを追加する場合、利用者が選べる方式にするよう推奨している。来歴情報を後から回復できる利点と、以前のマニフェストへ結び直すことで生じるプライバシー上の不利益を、作成者へ説明することも勧める。これは法的義務ではないものの、ペイントの公開説明に欠けている情報を具体的に示している。

Microsoftはリモート審査、C2PAマニフェスト、プロンプトと端末・ユーザー識別子の収集を開示している。未説明なのは、watermarkIdがピクセルとC2PAの双方へ入り、別のpromptGenerationIdと同じ審査応答で発行される点だ。両GUIDとアカウント情報を対応づけて保存・照合しているかは分からない。

利用者が判断するには、GUIDとアカウント情報の対応表を保存するか、保存期間と利用目的は何か、不可視透かしを無効にできるかという説明が要る。Microsoftがこの3点を明らかにすれば、来歴を長く保つ機能と、匿名性を損ない得る識別子の境界を評価できる。