2026.11.12 2026.11.12

WordPress に上げた AI 画像の C2PA はいつ消えるのか — 当サイトでは縮小画像で直後に、原寸も最適化のあとに消えていた

ゲンキ

AI で生成した画像に C2PA（画像の来歴を署名付きで書き込む規格）のマニフェストを付けても、ブログに載せた時点で読めなくなっていれば、読者の手元には届かない。WordPress C2PA の残り方について、WordPress の公式の AI プラグインの issue #421 は「縮小画像を作る段で、GD でも Imagick でも C2PA のマニフェストが壊れる」と書いている。ただし、これは起票者の記述で、WordPress 本体の文書ではない。そこで、当サイト swiftwand.com の WordPress に試験画像を実際に上げ、原寸（上げたファイルそのもの）と縮小画像（WordPress が作る各サイズ）を取り直して数えた。

試験画像は PNG と JPEG の 2 枚で、どちらも 1280×720 だ。ファイルに書くメタデータとして ComfyUI の生成の記録（PNG のみ）・EXIF（JPEG のみ）・XMP・C2PA を入れ、画素に埋める電子透かしとして TrustMark を入れた。これを REST API で上げ、直後と 17 分後に、原寸と WordPress が作った各サイズを取り直した。当サイトの WordPress では画像の最適化プラグイン EWWW Image Optimizer 8.9.1 が有効で、結果は WordPress 本体と EWWW の組み合わせのものである。

先に結果を書く。縮小画像は、上げた直後から PNG・JPEG とも全 7 ファイル（サイズ名で 8）で C2PA が無かった。原寸は直後は上げたファイルのままで、C2PA の検証も Valid だった。ところが 17 分後には、原寸が 2 枚とも、画素が同じでバイト数の小さいファイルに置き換わり、C2PA・生成の記録・XMP・EXIF のどれも無くなっていた。電子透かしの TrustMark は、原寸と正方形でない縮小画像では最後まで読めた。

試験画像は測ったあと削除し、原寸と全サイズの URL が 404 になったことを確かめた。実験は各条件 1 回で、「この実行ではこうだった」以上のことは言えない。EU AI Act 第 50 条などの法の話は扱わず、本記事は法的助言ではない。法の日付と、当サイトの画像の流れ全体で記録を数えた結果は AI 生成の表示と「印」は画像と3Dデータのどこで消えるのか（2026-11-09 公開）に書いた。

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

C2PA はなぜ縮小で外れるのか — hard binding はバイト列のハッシュで、縮小画像は別のファイルになる
WordPress 本体は縮小画像をどう作るか — 既定のサイズ・品質 82・image_strip_meta
画像の最適化プラグイン EWWW Image Optimizer は原寸も対象にする
WordPress C2PA の実測の条件 — メタデータと電子透かしを入れた PNG と JPEG を REST で上げた
結果1 — 縮小画像は上げた直後から C2PA が無かった
結果2 — 原寸は直後は残り、17 分後には画素が同じ小さいファイルに置き換わっていた
結果3 — TrustMark は正方形に切り抜いたサイズだけ読めなかった
当サイトの公開画像に生成の記録が無かった理由 — 上げた後の最適化と、投稿スクリプトの再送
結果の読み方 — WordPress 本体だけの挙動ではなく「本体＋EWWW」の結果である
この WordPress C2PA の実測で言えないこと
まとめ
参照

忍者AdMax

C2PA はなぜ縮小で外れるのか — hard binding はバイト列のハッシュで、縮小画像は別のファイルになる

C2PA のマニフェストは、どのバイト列に対して署名したのかを、ハッシュで指し示している。仕様（C2PA Technical Specification 2.5、2026 年 10 月）はこれを hard binding と呼び、「資産の全体か一部を一意に識別する暗号ハッシュ」と定義する。そのうえで、hard binding はその資産だけと一致し、そこから派生した資産や、そこから作った別の版（rendition）とは一致しない、と書く。

ハッシュを何に対して計算するかも決まっている。データハッシュ（c2pa.hash.data）では、マニフェストの置き場所として除外した範囲を除き、資産のバイトに対して計算する。画素ではなくバイトなので、見た目が同じでも、圧縮をやり直してバイト列が変われば一致しない。一致しなければ検証は assertion.dataHash.mismatch を返す。しかも仕様は、一致しないときに「改変されたのか、別のマニフェストを拾ったのか」は区別できないと書いている。

JPEG や PNG のような箱の形式には、箱ごとのハッシュ（c2pa.hash.boxes）も勧められている。いずれにしても、縮小画像は画素の数もバイト列も元と違う別のファイルだ。仮に WordPress が縮小画像にマニフェストを写したとしても、その縮小画像に対しては一致しない。つまり縮小で C2PA が使えなくなるのは、まず C2PA の仕組みの側の帰結である。c2patool で「AI 生成」の印を書き込み、検証の結果を読む手順は C2PA で AI 画像に来歴を付けて読む（2026-11-10 公開）に書いた。

マニフェストの置き場所は形式ごとに違う。仕様の付録 A.3 によれば、JPEG では APP11 のマーカーセグメントに入れ、1 つのセグメントは 64K バイトを超えられないので、大きければ複数に分ける。PNG では caBX というチャンクに入れる。caBX は「付随・私用・コピーしてはならない」種類のチャンクで、画像データ（IDAT）より前に置く。

この「コピーしてはならない」が PNG では効いてくる。PNG 仕様 1.2 は、コピーしてはならない（safe-to-copy のビットが 0 の）チャンクは画像データに依存すると定める。さらに、IDAT などの重要なチャンクを変えた編集ソフトは、自分の知らないそのようなチャンクを出力に写してはならない、と書く。縮小は画像データを作り直す処理なので、仕様どおりの編集ソフトなら caBX は縮小画像に写らない。

もう 1 点、C2PA は EXIF や XMP のようなマニフェストの外のメタデータも、できれば hard binding に含めるよう勧めている。含めた場合は、EXIF や XMP だけが消えても検証が通らなくなりうる。今回の試験画像のマニフェストがそれらをどう扱っていたかは、この実行では見ていない。

WordPress 本体は縮小画像をどう作るか — 既定のサイズ・品質 82・image_strip_meta

WordPress 本体は、縮小に使う画像処理の実装を候補の中から選ぶ。既定の候補は Imagick が先、GD が後で、条件を満たした最初の 1 つが使われる。Imagick の条件は、拡張が入っているかだけではない。7.1.4 の test() は、PHP の imagick 拡張が読み込まれていることに加えて、Imagick のクラス、拡張の版（2.2.0 以上）、JPEG の圧縮の定数、縮小や書き出しなどに使うメソッドがそろっているかを調べる。さらに選ぶときには、対象の画像の形式に対応しているか（supports_mime_type()）も確かめる。つまり既定では、必要な条件と対象の形式への対応を満たす Imagick を優先し、満たさなければ GD を試す。拡張が入っていても、Imagick が選ばれないことはある。

どちらが選ばれるかは、管理画面のサイトヘルスの情報画面で「Media Handling」の欄の「Active editor」に出る（英語の表記）。ただし、この欄の値は形式を指定せずに選んだ結果なので、形式ごとの対応の確認は入っていない（どちらも 7.1.4 のコードで確かめた）。

縮小画像のサイズは、初期値では次のとおりだ。サイトの設定やテーマで変わるので、当サイトで実際に作られたサイズは実測の節に書く。

サイズの名前	幅の初期値	高さの初期値	切り抜き
thumbnail	150	150	あり
medium	300	300	なし
medium_large	768	0（制限なし）	なし
large	1024	1024	なし
1536×1536	1536	1536	なし
2048×2048	2048	2048	なし

幅か高さのどちらかが 2560 px を超える画像では、さらに -scaled の処理が入る。ファイル名に -scaled を付けた縮小版を作り、添付ファイルが指す先をその縮小版に差し替え、元のファイルは original_image として記録して残す。縮小画像は -scaled からではなく元の画像から作る。今回の試験画像は 1280×720 なので、この処理は起きない。2560 px を超える画像は試していない。

品質の既定値は 82（WebP は 86）で、2016 年の 4.5 で 90 から下げた値である。出力の形式は、既定では HEIC／HEIF を JPEG にするだけで、PNG と JPEG は元の形式のまま縮小される。

メタデータについては、image_strip_meta というフィルターがある。縮小のときにメタデータを消すかを決めるもので、既定は true（消す）だ。ただし、このフィルターが効くのは Imagick で縮小するときだけである。コードの説明には、GD は既定で常にプロファイルを消すから、とある。

Imagick で消すときも全部ではない。7.1.4 の strip_meta() は、次の 5 つを残すリストを持ち、リストに無いプロファイルを消す。

icc・icm: 色のプロファイル
iptc: 著作権などの情報
exif: 向きなどの情報
xmp: 権利や利用条件などの情報

このリストに、C2PA の入れ物である JPEG の APP11 は無い。また PNG を縮小するときは、圧縮の設定に加えて「不要なチャンク」を外すと書かれており、通常の（パレットでない）PNG では png:exclude-chunk に all を設定して書き出す。ImageMagick 7.1.2-35 のソース（coders/png.c）では、all は tEXt・zTXt・tIME・cHRM・bKGD と日付のテキスト（date）などの付随するチャンクを外す指定で、ImageMagick の知らないチャンクはこの設定にかかわらず書き出さない。png.c には caBX の名前が出てこないので、caBX は知らないチャンクに当たる。当サイトのサーバーの ImageMagick の版は確かめていないので、実際に何が残ったかは実測で示す。

一方、原寸については、7.1.4 のアップロードの処理（wp-admin/includes/image.php）が、縮小画像を元のファイルから作る。-scaled や、EXIF の向きに合わせて回転した版（-rotated）も別のファイルとして保存し、元のファイルは original_image として記録する。WordPress 本体は、縮小画像を作っても原寸のファイルは変えない、とコードからは読める。4.5 の開発者向けの記事も、その版での縮小画像の変更について「WordPress に上げた原寸の画像はこの変更の影響を受けない」と書いている。

縮小で C2PA が壊れる、という記述の出どころは、WordPress の公式の AI プラグイン（リポジトリ WordPress/ai）だ。issue #421「WordPress should detect C2PA manifests on upload」（2026-04-12 起票）は、縮小画像を作る段で GD でも Imagick でも C2PA が壊れ、元のファイルはディスクに残るが、マニフェストを読める機会はアップロードの時点だと書く。この issue は PR #459 のマージで 2026-10-08 に完了として閉じられた。PR #459 も、APP11 は GD／Imagick の保存し直しで残らず、元のバイト列がそのまま残っているのはアップロードの時点だけだと書いている。

この PR の機能は、AI プラグイン 1.5.0（2026-10-30）で「Content Verification」という名前の実験的機能として出た。上げた JPEG・PNG・WebP の C2PA を読み取りだけで検出し、添付ファイルと一緒に保存する機能で、暗号の検証と JUMBF／CBOR の完全な読み解きは後回しにされている。readme はこのプラグインを WordPress 本体の一部ではないと明記し、実験的機能は版ごとに大きく変わったり無くなったりしうると書く。WordPress が C2PA に対応したわけではない。なお、WordPress 本体の課題管理（core trac）にはチケット #65952 があるが、本記事では中身を確かめられなかったので、末尾の参照にリンクだけを示す。

縮小サイズや画像の扱いを確かめるには、WordPress の管理画面とメディアの基本を押さえておきたい。7.x に対応した入門書なら、設定の場所から順に確かめられる。

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

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

Amazon

楽天市場

ポチップ

画像の最適化プラグイン EWWW Image Optimizer は原寸も対象にする

当サイトで有効な EWWW Image Optimizer は、最新版が 8.9.1（2026-10-29）である。readme によれば、既定でメタデータを消し、設定の名前は「Remove Metadata」だ。設定画面の説明は「EXIF、コメント、色のプロファイルなど、画素のデータでないものをすべて消す」という内容で、公式ドキュメントも「画素をどう描くかをコンピューターに伝えないものは、すべて画像から取り除かれる」と書く。ただし、Compress API か Easy IO を使う場合は、この設定にかかわらず色のプロファイルを残す。

本体と大きく違うのは、原寸も対象になる点だ。公式ドキュメントは、メディアライブラリに上げた画像を自動で最適化すると書く。readme の FAQ は、既存の画像を置き換えるかという問いに「最適化した版が小さいときだけ」と答え、プラグインは大きな画像を決して作らない、とも書く。WordPress 本体は原寸を変えないが、EWWW が入ったサイトでは原寸のファイルも置き換わりうる。メタデータの除去も、原寸と縮小画像の両方に掛かる。

もう 1 つ、EWWW は自前の画像処理の実装を、本体の候補の先頭に足す。この実装は本体の Imagick の実装を引き継ぎ、縮小のときに image_strip_meta も同じ形で呼ぶ。ただし縮小の処理（thumbnail_image()）は上書きしていて、PNG の扱いが本体と違う。付随するチャンクを外す設定（png:exclude-chunk に all）を入れるのは、パレットの PNG で透過が無いときだけで、通常の PNG には圧縮の設定しか入れない。

自動の最適化が有効な既定の状態では、サイトヘルスの「Active editor」に EWWWIO_Imagick_Editor か EWWWIO_GD_Editor が出るとコードからは読める（本体の既定の候補に無い Gmagick の編集クラス WP_Image_Editor_Gmagick が読み込まれていれば EWWWIO_Gmagick_Editor）。

アップロードの時点の処理（最大寸法を超える画像の縮小と自動の回転。最大寸法の既定は 2560×2560）は、wp_handle_upload に掛かる。REST API でファイルの本体を送る上げ方でも、このフィルターは通る。

過去の画像を見るときに効くのは、8.9.0（2026-10-13）の変更履歴だ。そこに「サーバー上の optipng を使うときに PNG のメタデータが消えていなかった」不具合の修正がある。つまり 8.9.0 で修正されるまでは、サーバー上の optipng を使う設定で PNG のメタデータが消えない不具合があった。いつの版からかは変更履歴に書かれていない。当サイトがサーバー上のツールで最適化しているのか、API を使っているのかは確かめていない。

なお、メタデータを消すのは EWWW だけではない。本体も GD なら常に、Imagick ならリストの外を縮小のときに消す。他の最適化プラグインは調べていない。当サイトの EWWW の設定画面も読んでいないので、以下は設定ではなく挙動だけを書く。

画像の最適化のようなプラグインは、入れたあとに設定を見直す習慣があるかどうかで差が出る。月1回のメンテナンスの手順をまとめた本で、プラグインと設定の点検を決まった作業にしておきたい。

これからのWordPressセキュリティ本格講座（秀和システム・書籍）

¥2,640 （2026/11/02 18:00時点 | Amazon調べ）

Amazon

楽天市場

ポチップ

WordPress C2PA の実測の条件 — メタデータと電子透かしを入れた PNG と JPEG を REST で上げた

試験画像の元は、当サイトの 2026-11-02 の記事のカバー画像（ComfyUI で生成した PNG、1280×720）である。寸法は当サイトの記事画像と同じにした。知りたいのは、当サイトの画像に実際に起きることだからだ。記録は次の順に入れた。C2PA は画素とバイト列を固定するので、最後に付けている。

電子透かし: TrustMark（変種 Q）で値 sw1102 を埋める
メタデータ: PNG には ComfyUI が書いた生成の記録（prompt のテキスト）を残し、iTXt の XMP に IPTC の Iptc4xmpExt:DigitalSourceType＝trainedAlgorithmicMedia（生成 AI で作った画像を示す値）を書く。JPEG（品質 95）には EXIF の ImageDescription と、同じ内容の XMP を書く
C2PA: c2patool の試験用の鍵で署名する。--create trainedAlgorithmicMedia で AI 生成の印（c2pa.created に付く digitalSourceType）を付け、使ったモデルを書く c2pa.ai-disclosure を "created": true の形で足す。タイムスタンプは付けない

できた PNG は 939,713 バイト、JPEG は 222,821 バイトだった。署名は c2patool に同梱された試験用の鍵によるもので、本物の署名用の証明書は使っていない。そのため検証の結果は「署名と改ざんの検査は通った（Valid）が、署名者が信頼リストに無いので Trusted ではない」になる。なお、Valid は署名後に変更されていないことの確認であって、画像が AI で生成されたことの証明ではない。

上げ方は、REST API の POST /wp/v2/media に、ファイルのバイト列をそのまま送る方法だ。当サイトの投稿スクリプト（deploy.py）は通していない。投稿には付けていない。送った内容は次のとおりである。

POST /wp/v2/media
Content-Disposition: attachment; filename=<ファイル名>
（本文はファイルのバイト列そのもの）

PNG は 12:22:58、JPEG は 12:23:00（2026-11-02）に上がり、どちらも HTTP 201 が返った。7.1 の REST API の既定ではサーバー側で縮小画像を作るので、測ったのはサーバー側の処理である。応答の media_details.sizes には、full を含めて 9 つのサイズの名前があった。

サイズの名前	当サイトで作られた寸法
thumbnail	150×150
post-thumbnail	150×150
medium	300×169
small_size	320×180
thumbnail_size	320×320
medium_size	640×360
medium_large	768×432
large	1024×576
full	1280×720（原寸と同じ寸法・同じバイト数）

本体の初期値の名前に無いもの（post-thumbnail・small_size・thumbnail_size・medium_size）もあった。どこで登録されたサイズかは確かめていない。1536 と 2048 は元より大きいので作られていない。thumbnail と post-thumbnail は同じ 150×150 のファイル（同じ URL）を指し、full は原寸のファイルそのものを指していた。そのため縮小画像は、サイズ名で数えると 8、ファイルで数えると 7 になる。以下の数はファイルで数え、表だけはサイズ名ごとに 1 行を置く。

読み取りは 2 回行った。1 回目は上げた直後（12:23:03）、2 回目は 17 分後（12:40:03）である。17 分は 12:40:03 − 12:23:03 で出した。EWWW が裏で遅れて処理する場合に備えて、2 回読むことを先に決めていた。どちらの回も、原寸と全サイズを応答の URL から取り直した。そのうえでファイルの中のテキスト・EXIF・XMP・C2PA の箱を当サイトのスクリプトで探し、C2PA の状態を c2patool で、電子透かしを TrustMark で読んだ。

結果1 — 縮小画像は上げた直後から C2PA が無かった

直後（12:23:03）の結果をまとめると、次のようになる。

ファイル	C2PA	生成の記録（`prompt`）	XMP（標準の場所）	EXIF	TrustMark
PNG の原寸（939,713 バイト）	Valid	有	有	—（元から無い）	読めた
PNG の縮小画像（7 ファイル、サイズ名で 8）	7 ファイルとも無い	7 ファイルとも有	7 ファイルとも無い（形を変えたテキストが有）	—	正方形の 2 ファイル以外で読めた
JPEG の原寸（222,821 バイト）	Valid	—	有	有	読めた
JPEG の縮小画像（7 ファイル、サイズ名で 8）	7 ファイルとも無い	—	7 ファイルとも有	7 ファイルとも有	正方形の 2 ファイル以外で読めた

縮小画像は、PNG・JPEG とも、どのファイルにも C2PA の箱が無かった。c2patool で読むと「No claim found」、つまりマニフェストが見つからないという結果になる。この点は、公式の AI プラグインの issue #421 と PR #459 の記述と合う。ただし、これは当サイトの組み合わせでの 1 回の結果で、WordPress 本体の仕様として書かれたものではない。

原寸のほうは、直後は 2 枚とも上げたファイルとバイト数が同じだった。C2PA の検証は Valid のままで、生成の記録・XMP・EXIF・TrustMark もすべて残っていた。本体のアップロードの処理は元のファイルを変えない、という 7.1.4 の image.php の読みと合う結果で、この時点で原寸の URL からファイルを取れば、C2PA は読めた。

PNG の縮小画像には、別の形の変化があった。生成の記録の prompt は残っていた。ところが XMP は、標準の置き場所である iTXt の XML:com.adobe.xmp には無く、代わりに Raw profile type xmp というキーのテキストになっていた。さらに date:create・date:modify・date:timestamp のテキストが足されていた。

これは ImageMagick が PNG を書き出すときの形である。縮小に ImageMagick が使われたと見られるが、サイトヘルスの「Active editor」は読んでいないので断定はしない。Raw profile type xmp の中身は、元の XMP と同じ文字列を 16 進で書いたものだった。ただ、XMP を標準の置き場所で探す道具からは、この縮小画像の XMP は見えないことになる。

もう 1 つ、直後の PNG の縮小画像には prompt が残り、cHRM・bKGD・tIME のチャンクも足されていた。どれも 7.1.2-35 の png.c で all が外すチャンクに当たるので、この縮小では付随するチャンクを外す設定は効いていなかったと読める。本体のコードは通常の PNG にこの設定を入れるが、EWWW 8.9.1 の実装はパレットの PNG にしか入れない。試験画像の PNG は色の型が 2（RGB）で、パレットではない。EWWW の実装で縮小されたのなら、prompt が残ったこととコードは合う。ただし「Active editor」は読んでいないので、どちらの実装が使われたかは断定しない。

一方、JPEG の縮小画像は 7 ファイルとも EXIF と XMP が残っていた。Imagick の残すリストに exif と xmp があることと合う結果だが、これも縮小に使われた実装を示す証拠にはしない。

結果2 — 原寸は直後は残り、17 分後には画素が同じ小さいファイルに置き換わっていた

17 分後（12:40:03）に取り直すと、原寸が 2 枚とも別のファイルになっていた。PNG は 939,713 バイトから 814,653 バイトに、JPEG は 222,821 バイトから 157,338 バイトに減っていた。減った割合は、PNG が (939,713 − 814,653) ÷ 939,713 ＝ 125,060 ÷ 939,713 で約 13.3%、JPEG が (222,821 − 157,338) ÷ 222,821 ＝ 65,483 ÷ 222,821 で約 29.4% である。

一方で、RGB の画素は直後のファイルと完全に一致した（画素ごとの差の最大が 0）。見た目は変わらず、バイト列だけが変わったということだ。置き換わった原寸には、C2PA・生成の記録・XMP・EXIF のどれも無かった。電子透かしの TrustMark は読めた。

WordPress 本体のアップロードの処理は、原寸のファイルを変えない（7.1.4 の image.php から読める）。置き換えたのは、当サイトで有効な EWWW の最適化と見られる（EWWW の側の処理の記録は読んでいない）。画素が同じでファイルが小さくなり、画素以外のメタデータが消えた、という結果は、EWWW の既定（メタデータを消す、小さくなったときだけ置き換える）の説明と合う。置き換えが 12:23 と 12:40 のあいだのいつ起きたかは、この 2 回の読み取りからは分からない。上げた直後には起きず、裏で遅れて起きた、ということだけが言える。

縮小画像も、17 分後には一部が置き換わっていた。

PNG のサイズ	寸法	直後のバイト	17 分後のバイト	17 分後のテキスト
原寸	1280×720	939,713	814,653	無い
thumbnail	150×150	26,221	24,493	無い
post-thumbnail	150×150	26,221	24,493	無い
medium	300×169	50,112	48,354	無い
small_size	320×180	56,085	54,308	無い
thumbnail_size	320×320	96,818	94,767	無い
medium_size	640×360	185,363	183,429	無い
medium_large	768×432	271,265	269,408	無い
large	1024×576	473,176	470,868	無い

PNG は縮小画像の 7 ファイルとも小さくなり、prompt も Raw profile type xmp も日付のテキストも、すべて消えていた。

JPEG のサイズ	寸法	直後のバイト	17 分後のバイト	17 分後の EXIF・XMP
原寸	1280×720	222,821	157,338	無い
thumbnail	150×150	4,318	3,920	無い
post-thumbnail	150×150	4,318	3,920	無い
medium	300×169	7,675	7,277	無い
small_size	320×180	8,398	7,997	無い
thumbnail_size	320×320	12,744	12,596	無い
medium_size	640×360	23,062	23,062	有
medium_large	768×432	31,436	31,436	有
large	1024×576	48,964	48,964	有

JPEG の縮小画像は、7 ファイル中 4 ファイル（medium・thumbnail＝post-thumbnail・thumbnail_size・small_size）で EXIF と XMP が消えた。残り 3 ファイル（medium_size・medium_large・large）は、直後とバイト数が同じで、EXIF と XMP も残っていた。この 3 ファイルは置き換えられていないと見られる。EWWW は最適化した版が小さいときだけ置き換えると書いているが、この 3 ファイルがなぜ置き換わらなかったのかは、この記録からは分からない。

まとめると、この実行では、C2PA は縮小画像で直後から無く、原寸でも最適化のあとに無くなった。生成の記録・XMP・EXIF は、直後はおおむね残っていたが、17 分後には JPEG の大きめの 3 ファイルを除いて消えていた。

結果3 — TrustMark は正方形に切り抜いたサイズだけ読めなかった

電子透かしの TrustMark は、メタデータとは違う残り方をした。

ファイル	直後	17 分後
原寸（1280×720）	読めた	読めた
正方形でない縮小画像（300×169・320×180・640×360・768×432・1024×576）	読めた	読めた
正方形に切り抜いた縮小画像（150×150 と 320×320 の 2 ファイル）	読めない	読めない

PNG と JPEG で結果は同じだった。原寸と、縦横比を保った縮小画像では、直後も 17 分後も読めた。原寸も縮小画像も、直後と 17 分後で画素が同じだったので、結果が変わらないのは筋が通る。

読めなかったのは、正方形に切り抜いた 2 ファイル（150×150 と 320×320、サイズ名で 3）だけで、直後も 17 分後も読めなかった。縮小と JPEG 圧縮のあとに電子透かしが読めるかは電子透かしは AI 画像の縮小と圧縮に耐えるのか（2026-11-11 公開）で手元の加工として試したが、そこでは正方形の切り抜きは試していない。正方形の切り抜きでなぜ読めなくなるのかは、この実行では調べていない。

電子透かしは、C2PA のマニフェストそのものではない。消えたマニフェストを保管場所から探すための識別子として使う仕組み（soft binding）があるが、その位置づけは上の電子透かしの記事に任せる。当サイトはマニフェストの保管場所を持っていないので、ここで確かめたのは「縮小と最適化のあとに値が読めたか」までである。

TrustMark を読み直すような確かめ方は、Python で画像をまとめて処理できると自分のサイトでも試しやすい。ファイルの一括処理を Python で書く基本書が1冊あると始めやすい。

退屈なことはPythonにやらせよう第3版（オライリー・ジャパン・書籍）

¥4,620 （2026/10/21 08:17時点 | Amazon調べ）

Amazon

楽天市場

ポチップ

当サイトの公開画像に生成の記録が無かった理由 — 上げた後の最適化と、投稿スクリプトの再送

当サイトの公開済みの記事画像を公開 URL から取り直したときには、生成の記録がどこにも無かった。手元の記事画像（images/ の PNG）は 2,862 枚中 2,816 枚が ComfyUI の prompt を持っていたのに、投稿 3 本（ID 14099・14161・14233）の原寸 29 枚と縮小画像 203 枚（サイズ名で数えると 232）では、すべて prompt が無かった。原寸 29 枚は、手元のファイルと RGB の画素が全部一致し、バイト列は全部違い、チャンクは IHDR・IDAT・IEND だけだった。

この形は、結果2 の置き換えとそっくり同じである。画素は同じでバイト列が変わり、画素以外のチャンクが消えている。公開済みの画像も、上げた後の画像の最適化で生成の記録が消えたとすれば説明が付く。

ただし、消える経路はもう 1 つある。当サイトの投稿スクリプト（deploy.py）は、画像を送るとき、まず元のバイト列のまま送る。サーバーの手前の WAF（要求を検査して拒む仕組み）が 403 を返したときだけ、Pillow で PNG として保存し直して送り直す。圧縮のレベルは 1・3・6・9 の順に試す。

この保存し直しは、convert("RGB") してから PNG で保存し、pnginfo を渡していない。Pillow では PNG のテキストのチャンクは保存のときに pnginfo で渡すので、送り直した PNG には生成の記録のテキストも caBX も書かれない、とコードからは読める。deploy.py が必ず記録を消すわけではなく、消えるのは 403 で送り直したときだけだ。当サイトでは、この送り直しの処理はまだ変えていない。

公開済みの画像のどれが送り直しを通ったかは、ファイルからは見分けられない。送り直しても画素は同じで、チャンクが IHDR・IDAT・IEND になるのは EWWW の処理でも同じだからだ。投稿のときの記録（送り直したかどうか）も残していない。そのため、公開済みの画像について言えるのは、公開 URL のファイルに記録が無かったことまでである。試験画像では、上げた後の最適化と見られる置き換えで記録が消えた。しかし過去の各画像が、上げる前の送り直しと上げた後の最適化のどちらの段で記録を失ったかは見分けられないので、1 つの原因に決めない。

なお、2026 年 1 月の手元の画像のうち 25 枚は、ComfyUI を使う前の画像で、Google の C2PA（署名した証明書の組織名は Google LLC、digitalSourceType は trainedAlgorithmicMedia）を持っていた。その時期の投稿 2 本（ID 1868・1931）の公開済みの画像は JPEG で上がっており、C2PA・EXIF・XMP は無かった。手元の PNG とは形式が違うので、どの段で消えたかはこの記録からは言えない。画像の生成の流れ（ComfyUI とライセンス）は挿絵をローカル画像生成でまかなう — ComfyUIとFLUXのライセンスを読み違えないために（2026-08-27 公開）に書いている。

結果の読み方 — WordPress 本体だけの挙動ではなく「本体＋EWWW」の結果である

WordPress C2PA の結果を読むときは、まず主語を取り違えないようにしたい。ここまでの結果は「WordPress 本体＋EWWW Image Optimizer 8.9.1」の組み合わせで起きたことで、「WordPress が C2PA を消す」とは書けない。当サイトの WordPress の版は、公開ページが読み込む本体のスクリプトの表示（ver=7.1.4）から 7.1.4 と見られるが、管理画面では確かめていない。

原寸が変わったのは EWWW の最適化によると見られ、本体は原寸を変えない。縮小画像に C2PA が無かったことは、C2PA の仕組み（hard binding はバイト列のハッシュで、派生した版とは一致しない）と、PNG の「コピーしてはならないチャンク」の規則、そして AI プラグインの issue と PR の記述と合う。それでも、縮小で C2PA が消えることは、WordPress 本体の文書に仕様として書かれていることではない。

縮小に GD と Imagick のどちらが使われたかは、当サイトでは区別できなかった。PNG の縮小画像に ImageMagick の形のテキストが付いたことから、Imagick が使われたと見られる、までである。メタデータの有無から見分けることもできない。本体の Imagick なら JPEG の縮小画像に EXIF と XMP が残るはずだが、EWWW のメタデータの除去は縮小画像にも掛かる。そのため、GD でも Imagick でも、時間がたてば同じ「消える」になりうる。確かめるには、まずサイトヘルスの「Active editor」を読むことになるが、今回は読んでいない。

上げ方にも範囲がある。今回は REST API の既定の上げ方で、縮小画像はサーバーが作った。WordPress 7.1 のブロックエディターでは、対応するブラウザで、縮小画像をブラウザの側で作る仕組みが既定で有効になっている。この場合はサーバー側の画像処理の実装を使わず、EWWW のドキュメントも一部の処理が通らないと書く。ブロックエディターから上げた画像の残り方は測っていない。

時間の面でも読み方がある。公式の AI プラグインの PR は、元のバイト列が残っているのはアップロードの時点だけだと書いた。当サイトのこの実行では、原寸は上げた直後には元のファイルのままで、17 分後には置き換わっていた。この実行に限って言えば、原寸の C2PA を読めたのは、上げてから最適化で置き換わるまでのあいだだけだった。

自分のサイトで同じことを確かめるなら、手順は次の 4 つに絞れる。

サイトヘルスの「Media Handling」で「Active editor」を読み、縮小に使われる実装を確かめる
画像の最適化プラグインが入っているか、メタデータを消す設定かを確かめる
C2PA を付けた試験画像を 1 枚上げ、直後と時間をおいてから、原寸と各サイズを取り直して c2patool で読む
測り終えたら試験画像を削除し、URL が取れなくなったことを確かめる

この WordPress C2PA の実測で言えないこと

各条件 1 回の実行である。PNG と JPEG を 1 枚ずつ、1 回だけ上げた結果で、同じサイトでも毎回同じになるとは言えない
当サイトの組み合わせの結果である。WordPress 本体だけ、あるいは別の最適化プラグインのサイトでの結果ではない。EWWW の設定画面と、サイトヘルスの「Active editor」は読んでいないので、どの設定でこうなったかは書けない
GD か Imagick かは決めていない。ImageMagick の形のテキストが付いたことから Imagick と見られる、までである
置き換えの時刻は分からない。12:23 と 12:40 の 2 回しか読んでいないので、そのあいだのいつ置き換わったかは言えない
試した画像は 1280×720 だけ。2560 px を超える画像（-scaled）、パレットの PNG、EXIF の向きが付いた画像、WebP は試していない
REST API からの上げ方だけ。ブロックエディターや管理画面から上げた場合は測っていない
TrustMark が正方形の切り抜きで読めなかった理由は調べていない
試験用の鍵で署名した。検証の Valid は、署名者が信頼リストに無い状態での結果で、Trusted ではない。当サイトの記事画像には、C2PA も電子透かしも付けていない
法的な判断はしていない。どのサイトが何をしなければならないかは書いていない

試験画像は、測ったあと 2 枚とも削除した。削除の後に、原寸と全サイズの URL（PNG・JPEG とも、原寸 1 と縮小画像 7 の 8 つ）と REST での取得が、すべて 404 になったことを確かめている。

まとめ

WordPress C2PA の残り方を当サイトで測ると、2 つの段で消えていた。1 つ目は縮小画像で、上げた直後から PNG・JPEG とも縮小画像の全 7 ファイルに C2PA が無かった。縮小画像は元とバイト列も画素の数も違う別のファイルなので、仮にマニフェストが写っても hard binding は一致しない。2 つ目は原寸で、直後は上げたファイルのまま C2PA も Valid だったが、17 分後には画像の最適化と見られる処理で画素が同じ小さいファイルに置き換わり、メタデータがすべて消えていた。

画素に埋めた電子透かしの TrustMark は、原寸と縦横比を保った縮小画像では最後まで読めた。読めなかったのは正方形に切り抜いた 2 ファイルだけである。この 1 回の実行では、メタデータは画素が同じままの最適化で消え、電子透かしは最適化では残って、正方形の切り抜きで読めなくなった。消える段が、メタデータと電子透かしで違っていた。

ブログに AI 画像を載せて、C2PA を読者まで届けたいなら、自分のサイトで「縮小画像」と「原寸の最適化」の 2 つの段を確かめる必要がある。WordPress 本体の挙動だけを調べても、入っているプラグインで結果が変わりうる。試験画像を 1 枚上げ、時間をおいて原寸と各サイズを取り直して読めば、自分のサイトのどの段で何が消えるかが分かる。