2026.11.09 2026.11.09

AI 生成の表示と「印」は画像と3Dデータのどこで消えるのか — 12月2日の期限の前に、当サイトの記事画像 2,862 枚で数え、3Dデータは問いとして整理した

ゲンキ

AI で作った画像に「AI 生成の表示」を添えるとき、人が読む一文と、機械が読む「印」は別のものになる。人が見る表示は記事の本文やキャプションに書き、機械が読む印は画像ファイルの中に書く。EU の AI Act でも、この二つには別々の条項が当たる。そして機械が読む印のほうには、2026 年 12 月 2 日に一つの期限が来る。

当サイトの記事画像は、手元の PC の ComfyUI で生成している。ComfyUI は、生成に使った設定を「生成の記録」として PNG の中に書く。この記録は AI 生成を示す標準の印ではない。それでも、ファイルの中に書いた情報が投稿までのどこで失われるのかを調べる材料にはなる。そこで、手元の記事フォルダにある PNG 2,862 枚と、WordPress の公開 URL から取り直した画像で、記録がどの段で消えるのかを数えた。

結果を先に書く。手元では 2,862 枚中 2,816 枚が生成の記録を持っていた。ところが、公開 URL から取り直した PNG の原寸 29 枚と縮小画像 203 枚では、記録を持つものは 0 枚だった。原因を切り分けるために試験用の画像を上げると、上げた直後の原寸には記録が残っていた。しかし上げてから 17 分後の読み取りでは、原寸は画素が同じで小さいファイルに置き換わり、記録は消えていた。

本記事は、条文と欧州委員会の説明を引いて整理したもので、法的助言ではない。読者や当サイトが条文上の義務を負うかどうかは判断しない。また、測ったのは縮小や保存し直しのように、普段の作業で意図せず消える場合だけで、印を消す方法は扱わない。実験はどれも各条件 1 回の実行で、結果は「この実行ではこうだった」として書く。

※本記事にはアフィリエイト広告（PR）が含まれます。

12月2日に終わるのは、第50条第2項の経過措置だけ
機械が読む「印」と、人が見る「AI 生成の表示」
行動規範は、署名した提供者に2層の印を求める
3Dデータについて、条文とガイドラインは何を言っているか
- C2PA の対応形式の表に、3D の形式の名前は無い
当サイトの記事画像はどう流れるか — ComfyUI から WordPress まで
手元の 2,862 枚では、2,816 枚が生成の記録を持っていた
- 2026 年 1 月の 25 枚は Google の C2PA を持っていた
公開 URL から取り直した画像では、原寸も縮小も 0 枚だった
どこで消えたのか — 上げた直後は残り、あとで置き換わっていた
この実測で言えないこと
付ける・残るか・置き場所 — 印について残っている三つの問い
まとめ — AI 生成の表示と印を分けて確かめる
参照

忍者AdMax

12月2日に終わるのは、第50条第2項の経過措置だけ

AI Act（規則 (EU) 2024/1689）の第50条は、一部の AI システムの提供者と配備者に透明性の義務を定める条文で、2026 年 8 月 2 日に適用が始まった。欧州委員会の AI Act Service Desk のタイムラインは、この日の項に「Transparency rules (Article 50) start to apply.」と書いている。

12 月 2 日は、このうち第2項だけにかかる期限である。対象は、2026 年 8 月 2 日より前に市場に出た、合成の音声・画像・動画・テキストを生成する AI システム（汎用 AI システムを含む）の提供者だ。12 月 2 日は、その提供者が第50条第2項（機械が読める印と検出）に適合するための経過措置の期限になる。

根拠は AI Act の第111条第4項である。この項は、2026 年 7 月 24 日に官報に掲載された規則 2026/1744（Digital Omnibus on AI）の第1条第39号(b) で加えられた。同じ規則の前文 (38) は、すでに市場に出ている提供者のために「4 か月」の経過期間を設けるのが適切だと説明している。

欧州委員会の Q&A も、猶予は 8 月 2 日より前に市場に出た AI システムに限られ、しかも第2項の印と検出の義務だけに認められると書く。したがって、「第50条が 12 月 2 日から適用される」「第50条の全体が延期された」という読み方は条文と合わない。なお、同じ 12 月 2 日には、一部の禁止規定（同意のない性的なディープフェイクなどを生成する AI システム）の適用も始まる。

AI Act と Omnibus の日付と枠組みは、G検定の法律・倫理は AI で現行制度に更新してから覚える — AI 法・基本計画・著作権・EU AI Act の一次資料をシラバスに対応づける（2026-10-04 公開）で一次資料から整理した。本記事はそれを繰り返さない。ここから先は、第2項が求める「機械が読める印」がファイルの中でどう扱われるかに絞る。

機械が読む「印」と、人が見る「AI 生成の表示」

第50条第2項の原文は、提供者に対し、AI システムの出力が「marked in a machine-readable format and detectable as artificially generated or manipulated」であるようにすることを求める。条件は、人が見て分かるかどうかではない。機械が読める形で印が付いていて、人工的に生成・操作されたものとして検出できるかどうかである。

これに対して第50条第4項は、ディープフェイクに当たる画像・音声・動画を生成・操作する AI システムの配備者に、そのコンテンツが人工的に生成・操作されたことを開示するよう求める。ディープフェイクは第3条(60) で、実在の人物・物・場所・団体・出来事に似ていて、人に本物だと誤って思わせるような、AI で生成・操作された画像・音声・動画と定義されている。同じ項は、公共の利益に関わる事柄を知らせる目的で公開するテキストを生成・操作する AI システムの配備者にも、一部の場合を除いて、テキストが人工的に生成・操作されたことの開示を求めている。

本記事では、第2項の機械が読むものを「印」、第4項の開示のように人が見て分かるものを「表示」と呼び、二つを入れ替えずに使う。条文の上では、印を付けるのは提供者、開示するのは配備者という分かれ方になっている。ただし、読者がどちらに当たるかは本記事では判断しない。

AI Act の前文 (133) は、印の技術の例として、透かし、メタデータによる識別、来歴と真正性を証明する暗号的な方法、ログ、指紋などを挙げている。このうち画像の作り手が手元で扱うのは、ファイルに書くメタデータと、画素に埋める電子透かしの二つである。

ファイルに書く印 — C2PA・XMP・PNG のテキスト

一つ目の方式は、画像ファイルの中に情報を書き込むメタデータだ。代表的なものが C2PA（Coalition for Content Provenance and Authenticity）の仕様で、来歴を記した「マニフェスト」に電子署名を付けてファイルに入れる。PNG の場合、仕様 2.5 はマニフェストを caBX という種類のチャンクに入れると定めている。このチャンクは、補助的で私用の、しかも「コピーしてはならない」種類として定義されている。

この「コピーしてはならない」には意味がある。PNG の仕様（W3C 勧告の第3版）は、編集ソフトが画像に必須のチャンクを変えたときには、自分の知らないコピー不可のチャンクを出力に写してはならないと定める。つまり、必須のチャンクを変える編集ソフトは、caBX を知らなければ、それを新しいファイルに写さない決まりになっている。

C2PA とは別に、XMP の項目で AI 生成を示す方法もある。IPTC の Photo Metadata は Iptc4xmpExt:DigitalSourceType という項目を定め、生成 AI で作った画像には trainedAlgorithmicMedia（名前は「Created using Generative AI」）という値を使う。PNG の中では、XMP は予約されたキーワード「XML:com.adobe.xmp」の iTXt チャンクに、EXIF は eXIf チャンクに入る。

PNG には、キーワードと文字列の組を入れる tEXt・zTXt・iTXt というテキストのチャンクもある。ComfyUI が書く生成の記録はここに入る。ただし、これは生成に使ったノードの設定を JSON にしたもので、C2PA や DigitalSourceType のように「AI 生成」を示す標準の値ではない。そのため本記事では、これを「AI 生成の印」とは呼ばず「生成の記録」と呼ぶ。

画素に埋める印 — 電子透かし

二つ目の方式は、画素そのものに知覚できない信号を埋める電子透かしである。メタデータがファイルの中の画素とは別の場所に書かれるのに対して、透かしは画素の側に入る。この点が、メタデータとの大きな違いだ。

後で触れる行動規範は、透かしを、電子署名付きのメタデータを補う頑健な仕組みと位置づけている。どの加工のあとまで透かしが読めるかは方式によって違い、本記事では測っていない。

人が見る表示 — 本文やキャプションに書く

表示は、人が見て分かるように書くものだ。画像の近くに「AI で生成した」と書く、記事の本文で説明する、といった形になる。例として書いておくと、この記事の画像は ComfyUI と Z-Image-Turbo で生成し、C2PA も透かしも付けていない。

ここで題の問いに戻る。本文やキャプションに書いた表示はページの側にあり、画像ファイルの中には入らない。反対に、印はファイルの中にあるので、ファイルを保存し直したり置き換えたりする段で失われうる。表示と印は、置かれている場所が違い、消える場所も違う。本記事の実測は、このうちファイルの中の情報がどこで消えるかを扱う。

行動規範は、署名した提供者に2層の印を求める

欧州委員会は 2026 年 6 月 10 日に、「Code of Practice on Transparency of AI-generated Content」（AI 生成コンテンツの透明性に関する行動規範）の最終版を公表した。独立の専門家が作ったもので、参加は任意である。ただし欧州委員会は、規範への参加が任意でも、第50条の透明性の要件そのものは法的義務だと書いている。

規範の本文は、署名した提供者に、生成 AI の出力へ少なくとも2層の機械が読める印を付けることを求める。一つは電子署名を付けたメタデータ、もう一つは知覚できない電子透かしだ。この2層は、音声・画像・動画とコンテナに入れたテキスト（containerised text）についての措置で、一つの印の技術だけでは第50条第2項の要件を満たせないあいだ、という前提が付いている。規範の中では「will」が必須の措置を、「encouraged」が法的には求められない任意の措置を表す。この2層は「will」で書かれている。

メタデータの層では、メタデータを持てる形式であれば、コンテンツが AI で生成・操作されたものかどうかを記録し、記録したすべての情報に電子署名を付ける。時刻の情報を使えるシステムでは、時刻も付ける。透かしの層は、その署名付きのメタデータを補う頑健な仕組みとされる。一方、指紋やログは任意の補助で、それだけに頼るのは十分でないと書かれている。

1層で足りるとされる場合もある。自由形式のテキストはメタデータを運べないので、透かしの1層で足りる。技術的に管理された閉じた環境で合成の出力を作る、物理的な製品に組み込まれた生成 AI システムも、特定の場合には1層でよいとされる。さらに規範は、同等以上の性能を市場監視の当局に示せれば、将来は別の印の技術（1つの技術でもよい）で適合を示せるとも書いている。

本記事の実測に関わるのは、印を残すことについての措置（Measure 1.2）である。署名した提供者は、技術的に可能で、オープンな標準で認識できる範囲で、入力にあった既存のメタデータの印を残し、意図して変えたり消したりしない。これは「will」で書かれている。ただし同じ措置は、後の処理で情報を正確に保つために必要な変更や置き換えなど、善意の正当な処理を妨げないとも書いている。これに対して、署名者のうちオンラインのプラットフォームや検索エンジンを運営する者が、そこでメタデータの印を保つようにすることは「encouraged」、つまり推奨にとどまる。来歴の追加の情報（AI システムの名前、提供者の社名、生成の時刻など）を示す Measure 1.3 も任意である。

規範自身も、メタデータの印の標準はさらに詰める必要があると認めている。欧州委員会は 7 月 8 日に、この規範が第50条の第2項・第4項・第5項の義務を十分に扱うと結論し、翌日に AI 理事会が評価を採択した。ただし欧州委員会は、規範に従うことが義務への適合の決定的な証拠にはならない、とも書いている。

もう一つ押さえたいのは、2層は規範に署名した提供者に向けた措置であり、法が2層を義務づけているわけではない点だ。2026 年 7 月 20 日に欧州委員会が採択した第50条のガイドラインは、要件を満たす限り、提供者は1つの印の技術にも、複数の技術の組み合わせにも頼れるとしている。また、来歴の連鎖をすべて記録して保つ義務は無いとも書く。

行動規範に署名するかどうかを含めて、AI の使い方を会社の決まりに落とすところまで考えるなら、取締役会や法務の目線でガバナンスの原則と実装の手順をまとめた解説書が手がかりになる。

AIガバナンス（商事法務・書籍）

¥3,080 （2026/11/02 17:57時点 | Amazon調べ）

Amazon

＼楽天ポイント4倍セール！／

楽天市場

ポチップ

3Dデータについて、条文とガイドラインは何を言っているか

3D プリントの作り手にとって気になるのは、AI で作った3Dデータがこの話に入るかどうかだろう。ここは二つの事実を必ず並べて読む必要がある。

一つ目は条文である。第50条第2項が挙げるのは「audio, image, video or text」で、3D の語は無い。ガイドラインの (60) も、第2項の対象の種類はこの列挙で尽きると書いている。

二つ目はガイドラインの (61) だ。3-D の画像・3-D の動画・3-D の音声と、仮想現実・拡張現実・複合現実を生成・操作する AI システムは、第50条第2項の範囲に入るとする。そのうえで、印を付ける出力は個々のアセットの最終的な形であり、3-D の画像などを作るために使う点群や 3D メッシュには印は要らないと書いている。

この二つを並べると、「3D は対象外」とは言えない。かといって、3D プリント用のデータに何かが求められるかどうかも、この二つからは決まらない。ガイドラインには拘束力が無く、AI Act の権威ある解釈は最終的には EU 司法裁判所だけが示せると、ガイドライン自身が (5) で断っている。3D プリント用の STL や 3MF がガイドラインの言う 3D メッシュに当たるかどうかを、当サイトは判断しない。

C2PA の対応形式の表に、3D の形式の名前は無い

ここからは法とは別の、形式の仕様の話になる。C2PA の仕様 2.5（2026 年 10 月）は、対応する形式を付録 A.1 の表にまとめている。2.5 では、追記型のテキスト、WARC、Standard MIDI、TTML、ONNX、SafeTensors、Apache Parquet などへの埋め込みが加わった。このように対応する形式が増えた一方で、付録 A.1 の表に 3MF・STL・OBJ・glTF/GLB・USD の名前は無い。

ただし、表には「Other ZIP-based formats」のような汎用の行もある。3MF などがそこに当たるかどうかを、仕様は述べていない。設計の説明では、マニフェストの入れ物が 3D の形式にも使えると書いているが、具体的な形式への埋め込み方は定めていない。そのため、「C2PA は 3D に対応しない」と言い切ることもできない。

実装の側では、C2PA の SDK である c2pa-rs の対応表（コミット c13b05f の supported-formats.md）にも 3D の形式は無い。この対応表には ZIP 系の形式も載っていないが、コードには EPUB や docx などの ZIP 系を扱う処理がある。その拡張子の一覧に 3mf は入っていない。

まとめると、3D データのどこに「AI 生成」を書けば次の道具に渡るのかは、法の解釈では決まらない。形式の仕様と、道具の実際の挙動で確かめる問いになる。

当サイトの記事画像はどう流れるか — ComfyUI から WordPress まで

実測の前に、当サイトの記事画像が通る段を並べておく。画像の生成にはローカルの ComfyUI を使っており、その仕組みとモデルのライセンスの読み方は挿絵をローカル画像生成でまかなう — ComfyUIとFLUXのライセンスを読み違えないために（2026-08-27 公開）で書いた。ここでは、各段でファイルに何が起きるかをリポジトリのコードから読む。

段	何が起きるか	生成の記録（`prompt`）の見込み
生成（ComfyUI の SaveImage）	PNG にテキストのチャンクを付けて保存する	書かれる
取得（generate.py）	ComfyUI の `/view` が返したバイト列をそのまま保存する	そのまま残る
文字の重ね（generate.py）	指定があるときだけ Pillow で開いて合成し、保存し直す	動けば書かれない
送信（deploy.py）	通常は元のバイト列を送る。WAF に拒まれたときだけ Pillow で保存し直して送り直す	再送すれば書かれない
WordPress	原寸を置き、縮小画像を作る	コードからは決まらない

ComfyUI の SaveImage というノードは、起動オプション --disable-metadata を付けない限り、PNG のテキストのチャンクに prompt（生成に使ったノードの設定の JSON）を書く。画面から実行したときは、ワークフローも書く。ワークフローは、要求の extra_data に含まれて SaveImage に渡される。当サイトの generate.py は API から実行し、extra_data を送らない。そのため、記事画像に書かれるのは prompt だけになる見込みだった。

生成した画像は、ComfyUI の /view から取り出して手元の images フォルダに保存する。プレビューなどの指定が無ければ、ComfyUI はファイルをそのまま返す。generate.py もそのバイト列を書き出すだけなので、記録は変わらない。

generate.py には画像に文字を重ねる機能もある。image_prompts.md に **Overlay:** の行があるときだけ動き、Pillow で開いて合成し、保存し直す。さらに、投稿の道具である deploy.py は、通常は元のバイト列のまま画像を送る。サーバーの WAF に送信を拒まれた（HTTP 403）ときだけ、Pillow で PNG として保存し直して送り直す。

どちらの保存し直しでも、Pillow に pnginfo を渡していない。Pillow のコード（手元の 12.1.0。最新の 13.0.0 も同じ）を読むと、PNG を保存するとき、テキストのチャンクは pnginfo を渡したときだけ書かれる。EXIF も exif を渡したときだけ書かれる。一方、ICC プロファイルは渡さなくても元の画像から引き継ぐ。Pillow がメタデータをすべて消すわけではなく、何を渡すかで書くものが決まる。なお、これは公式ドキュメントの文言ではなく、コードから読んだ挙動である。

画像がアップロードのあとにどう扱われるかを追うには、まず WordPress のメディアと設定の基本を押さえておきたい。7.x に対応した入門書なら、メディアライブラリやプラグインの入れ方から順に確かめられる。

いちばんやさしい WordPress 入門教室バージョン7.x対応（ソーテック社・書籍）

¥2,530 （2026/11/02 17:58時点 | Amazon調べ）

Amazon

＼楽天ポイント4倍セール！／

楽天市場

ポチップ

手元の 2,862 枚では、2,816 枚が生成の記録を持っていた

最初に手元の画像を数えた。対象は、記事フォルダの images にある PNG のすべてで、2026 年 1 月から 11 月の記事の 2,862 枚になる。画像のバイト列から PNG のチャンクをたどり、テキストのチャンクのキー、EXIF（eXIf）、XMP、C2PA（caBX）の有無を数えた。

「生成の記録がある」は、キーが prompt のテキストのチャンクがあり、その本文が JSON として読めることと決めた。実行は 2026 年 11 月 2 日で、Windows 11 Pro、Python 3.13.17、Pillow 12.1.0 を使った。画像は読むだけで、保存し直していない。

月	画像	`prompt` あり	C2PA
2026-01	94	48	25
2026-02	49	49	0
2026-03	225	225	0
2026-04	267	267	0
2026-05	339	339	0
2026-06	329	329	0
2026-07	292	292	0
2026-08	378	378	0
2026-09	434	434	0
2026-10	365	365	0
2026-11	90	90	0
合計	2,862	2,816	25

テキストのチャンクは prompt の1つだけで、ワークフローを持つ画像は 0 枚だった。API から実行して extra_data を送らないという、コードから読んだ見込みどおりである。EXIF と XMP も 0 枚だったが、SaveImage はもともとこの二つを書かない。そのため、これは消えたのではなく、最初から無いと読むのが正しい。

prompt を持たない画像は 46 枚あった。内訳は、2026-01-13〜01-19 の記事の 25 枚が C2PA を持つ画像で、2026-01-06〜01-12 の記事の 21 枚はどの記録も持っていなかった。

文字の重ねの指定も、各記事の image_prompts.md から数えた。指定ありは 0 枚、指定なしは 2,825 枚で、37 枚は image_prompts.md を読めずに不明だった。読めた指定の範囲では、文字の重ねで保存し直す段を使う設定は無かった。

手元の PNG に生成の記録があるかを確かめるだけなら、Pillow で開いて text を見る方法もある。Pillow の公式ドキュメントによると、PNG を開くと Image.text に tEXt・zTXt・iTXt の値が辞書で入る。読み取りだけの例を示す（ファイル名は自分の画像に置き換える）。

from PIL import Image

with Image.open("cover.png") as im:
    print(sorted(im.text))

既定のまま ComfyUI の SaveImage が書いた PNG なら、キーに prompt が出る。ただし C2PA のマニフェストはテキストのチャンクではなく caBX に入るので、この方法では見えない。本記事の集計は、これとは別に、チャンクを直接たどるスクリプトで行った。

2026 年 1 月の 25 枚は Google の C2PA を持っていた

C2PA を持っていた 25 枚は、ComfyUI を使い始める前の画像である。c2patool 0.28.4 で読むと、マニフェストを作ったのは 25 枚とも Google C2PA Core Generator Library で、署名した証明書の組織名は Google LLC だった。先頭の操作は c2pa.created、digitalSourceType は trainedAlgorithmicMedia で、生成 AI で作ったことが標準の値で記録されていた。署名の時刻は 2026-01-10T10:37:17Z から 2026-01-17T09:10:28Z の範囲にあった。

c2patool の判定は、25 枚とも Invalid だった。結果には、署名の証明書が信頼されていないこと（signingCredential.untrusted）と、期限が切れていること（signingCredential.expired）の二つが出た。c2patool 0.28.4 が使う c2pa-rs 0.91.7 は、Valid かどうかを決めるときに signingCredential.untrusted を許容する失敗として扱う。untrusted だけなら判定は Valid になるので、Invalid になったのは期限切れのためである。期限切れは c2patool の判定であり、画像が偽物だという意味ではない。手元の 2,862 枚のうち、AI 生成を標準の値で示す印を持っていたのは、この 25 枚だけだった。

公開 URL から取り直した画像では、原寸も縮小も 0 枚だった

次に、WordPress に上がっている画像を調べた。対象は5つの投稿の画像で、原寸と、WordPress が作ったすべての縮小サイズを取り直した。公開済みの画像を調べたのは公開 URL からの読み取り（GET）だけで、投稿や画像は変えていない。

投稿 ID	種類	ファイル	形式
14099	原寸	9	PNG
14099	縮小	63	PNG
14161	原寸	10	PNG
14161	縮小	70	PNG
14233	原寸	10	PNG
14233	縮小	70	PNG
1868	原寸	4	JPEG
1868	縮小	24	JPEG
1931	原寸	1	JPEG
1931	縮小	9	JPEG

表の縮小のファイルの数は、WordPress の2つのサイズ名（thumbnail と post-thumbnail）が同じ 150×150 のファイルを指すので、それを1つと数えた。PNG で上がっている3つの投稿では、原寸 29 枚と縮小画像 203 枚のすべてで prompt が無かった。手元には同じ画像の PNG があり、そちらは記録を持っている。そこで、原寸 29 枚を手元のファイルと比べた。

比べ方は二つで、バイト列が一致するかと、RGB に直した画素が一致するかを見た。結果は、29 枚とも画素は一致し、29 枚ともバイト列は一致しなかった。公開されている原寸のチャンクは IHDR・IDAT・IEND の3つだけで、テキストのチャンクは一つも無かった。つまり、画素は手元と同じなのに、ファイルは別のものになっていた。

2026 年 1 月の2つの投稿（1868・1931）の画像は JPEG で上がっていて、C2PA・EXIF・XMP は無かった。手元の PNG は Google の C2PA を持つが、形式が違うので、手元の印が投稿までのどの段で失われたのかは、この記録からは言えない。

どこで消えたのか — 上げた直後は残り、あとで置き換わっていた

手元に残っていた記録が、公開されている原寸では消えていた。では、どの段で消えたのか。

当サイトの WordPress では、画像の最適化のプラグイン EWWW Image Optimizer 8.9.1 が有効になっている。2026 年 11 月 2 日に、REST API のプラグインの一覧を読み取りで確かめた。EWWW の説明（配布物の readme と公式ドキュメント）は、既定でメタデータを消すと書き、画素の描き方を示さないものはすべて取り除くと説明している。また、メディアライブラリに上げた画像を自動で最適化し、最適化した版が小さいときだけ置き換えるとしている。ただし、当サイトの EWWW の設定は読んでいない。

切り分けのため、公開済みの投稿とは別に、試験用の画像を上げて測り、測ったあとで削除した。もとにしたのは 2026-11-02 の記事のカバー画像（1280×720）である。これに生成の記録（prompt）、XMP（DigitalSourceType は trainedAlgorithmicMedia）、試験用の鍵で署名した C2PA などを入れた PNG を作った。大きさは 939,713 バイトだった。

上げ方は、deploy.py を通さず、REST API にファイルのバイト列をそのまま送る形にした。投稿には付けていない。そのうえで、上げた直後（12 時 23 分）と、その 17 分後（12 時 40 分）の2回、原寸と縮小画像を取り直して読んだ。

読んだ時刻	原寸のバイト数	原寸の `prompt`	原寸の C2PA	縮小画像（PNG）の `prompt`	縮小画像の C2PA
12 時 23 分（直後）	939,713	残る	残る	残る	どのサイズにも無い
12 時 40 分（17 分後）	814,653	無い	無い	無い	どのサイズにも無い

上げた直後の原寸は、上げたファイルとバイト数が同じで、prompt も XMP も C2PA も残っていた。縮小画像には直後から C2PA が無かったが、PNG の縮小画像には prompt が残っていた。ところが 17 分後の読み取りでは、原寸が 939,713 バイトから 814,653 バイトのファイルに置き換わっていた。読んだのはこの2回だけなので、置き換わった正確な時刻は分からない。RGB の画素は直後のファイルと完全に一致し、C2PA・prompt・XMP はどれも無くなっていた。PNG の縮小画像からも、テキストのチャンクはすべて消えていた。

同時に上げた JPEG の試験画像でも、原寸は 222,821 バイトから 157,338 バイトのファイルに置き換わり、C2PA・XMP・EXIF が無くなっていた。WordPress 本体の開発者向けの記事（4.5、2016 年）は、アップロードした原寸の画像は、その版での画像の処理の変更の影響を受けないと書いている。原寸が後から置き換わったことは、EWWW の説明と合う。

この結果は、公開済みの画像に生成の記録が無いことの説明の一つになる。当サイトの WordPress 本体と EWWW Image Optimizer 8.9.1 の組み合わせでは、試験画像の原寸が上げた後に、画素が同じで小さいファイルに置き換わり、記録が消えていた。置き換えたのは EWWW の最適化と見られるが、EWWW の側の処理の記録は読んでおらず、直接は確かめていない。

ただし、上げる前の段にも記録が消える経路がある。deploy.py が WAF に拒まれて画像を送り直した場合、その画像は上げる時点ですでに記録を持っていない。再送しても画素は変わらず、チャンクが IHDR・IDAT・IEND だけになるのは、上げた後に置き換わったファイルでも同じである。そのため、公開されているファイルからは、どちらの経路を通ったかを見分けられない。どの画像で再送が起きたかの記録も残していない。まとめると、試験画像では上げた後の置き換え（EWWW の最適化と見られる）で記録が消えた。そして、上げる前の WAF の再送でも記録は消える。過去の公開済みの画像がどちらの段で記録を失ったかは見分けられず、言えるのは、この二つの経路があるところまでである。

この実測で言えないこと

この実測から一般的な結論を引き出すことはできない。言えないことを並べておく。

各条件 1 回の実行である。手元の集計、公開 URL の取り直し、試験画像の2回の読み取りは、どれも1回ずつしか行っていない
生成の段そのものは測っていない。測ったのは手元の images フォルダに保存済みのファイルで、ComfyUI が出力した直後のファイルではない。記事画像を生成した時点の ComfyUI の版も分からない
公開済みの各画像がどちらの経路で記録を失ったかは分からない。deploy.py の再送と、上げた後の置き換えのどちらが起きたかは、ファイルからも記録からも決められない
当サイトの設定の結果である。EWWW の設定も、WordPress がどの画像編集の実装を使っているかも読んでいない。別のプラグインや設定のサイトでは、消える段が違いうる
REST API から上げた場合だけを測った。ブロックエディターから上げた場合は測っていない
2026 年 1 月の JPEG の投稿については何も言えない。手元の PNG と形式が違う
生成の記録は AI 生成の印ではない。直後の縮小画像で prompt が残り C2PA は無かったように、情報の種類によって消える段は違う。生成の記録の結果を、そのまま C2PA や透かしに当てはめることはできない
法の上での評価ではない。誰に何が求められるかは、本記事では判断していない

付ける・残るか・置き場所 — 印について残っている三つの問い

この実測で分かったのは、ファイルに書いた情報が、当サイトの流れのどこで消えるかの一例である。AI 生成の印として考えるなら、問いは三つに分けられる。

付ける: C2PA のマニフェストを自分の画像に付けたとき、検証の道具は何を確かめたと示し、何を確かめていないと示すのか。電子透かしは、縮小・JPEG の圧縮・切り抜きのあとも読めるのか
残るか: WordPress の縮小や画像の最適化のあと、C2PA や透かしは残るのか。3D プリントのデータなら、スライサーで読み込んで保存し直したあと、ファイルに書いた「AI 生成」は残るのか
置き場所: 3MF・glTF・STL のような3Dデータでは、「AI 生成」をどこに書けば次の道具に渡るのか。C2PA の表に名前の無い形式で、マニフェストをファイルの横に置く方法は使えるのか

どの問いも、法の解釈ではなく、ファイルと道具の挙動で確かめるものだ。そして、上の実測が示すとおり、ファイルを上げた直後に残っていても、時間をおくと消えていることがある。確かめるときは、読むタイミングまで条件に入れておく必要がある。

3Dデータに印を入れる場所を自分で試すなら、モデルを開いて書き出し直す道具の操作に慣れておくと早い。Blender 5.x に対応した入門書が1冊あると、読み込みと書き出しの手順を確かめやすい。

Blender完全入門［5.x対応］（SBクリエイティブ・書籍）

¥1,540 （2026/09/20 10:10時点 | Amazon調べ）

Amazon

＼楽天ポイント4倍セール！／

楽天市場

ポチップ

まとめ — AI 生成の表示と印を分けて確かめる

本記事の要点を整理する。

2026 年 12 月 2 日は、8 月 2 日より前に市場に出た、合成の音声・画像・動画・テキストを生成する AI システム（汎用 AI システムを含む）の提供者が、第50条第2項（機械が読める印と検出）に適合するための経過措置の期限である。根拠は第111条第4項で、第50条そのものは 8 月 2 日から適用されている
機械が読む「印」と、人が見る「表示」は別のものだ。印にはファイルに書くメタデータと画素に埋める電子透かしがある。行動規範は、署名した提供者に、画像などの出力へ少なくとも2層の印を求める（1層で足りる場合もある）。ガイドラインは、要件を満たせば1つの技術でもよいとする
3D について、第50条第2項の条文の列挙に 3D の語は無い。一方で欧州委員会のガイドライン（拘束力は無い）は、3-D の画像・動画・音声を範囲に入れ、それを作るための点群や 3D メッシュには印は要らないと書く。C2PA 2.5 の付録 A.1 の表に、3MF・STL・OBJ・glTF/GLB・USD の名前は無い
当サイトの記事画像では、手元の 2,862 枚中 2,816 枚が ComfyUI の生成の記録を持っていたが、公開 URL から取り直した PNG の原寸 29 枚と縮小画像 203 枚では 0 枚だった。試験画像では、上げた直後の原寸に記録が残り、上げてから 17 分後の読み取りでは画素が同じで小さいファイルに置き換わって消えていた。上げる前の deploy.py の再送でも記録は消える

自分の画像の流れで同じことを確かめるなら、上げる前のファイルと、公開 URL から取った原寸を読み比べればよい。そのとき、上げた直後だけでなく、時間をおいてもう一度読む。当サイトでは、直後に残っていた記録が、時間をおいた読み取りでは消えていた。人が見る表示はページに、機械が読む印はファイルにある。AI 生成の表示を本文に書くことと、ファイルの中の印が残っているかを確かめることは、別々の作業として扱うのがよい。