C2PA Technical Specification v2.5 公開解説 変更点まとめ

お断り: 本記事は C2PA Technical Specification v2.5（2026年10月時点）と v2.4 を筆者が読解し、差分ベースで整理したものです。原典には本記事に含まれない細部（スキーマ定義・検証ルール・推奨事項など）が多数含まれます。実装や設計判断の根拠として用いる際は、必ず公式仕様書および関連する一次資料をご確認ください。本記事に誤りや古くなった箇所を見つけられた場合は、記事末尾のフィードバック枠よりお知らせいただけると助かります。

はじめに

2026 年 10 月、C2PA から Technical Specification v2.5 が公開されました。v2.4（2026 年 4 月）からおよそ 6 ヶ月ぶりの改訂です。v2.5 では対応ファイル形式が一気に広がったのが目立ちます。AI モデル（ONNX / SafeTensors）、データセット（Parquet）、ログファイル、Web アーカイブ（WARC）、MIDI、字幕（TTML / WebVTT）と、これまで C2PA の対象外だった領域に埋め込み方法が定義されました。暗号面では耐量子署名 ML-DSA が許可アルゴリズムに入っています。

本記事では、公式の Appendix F Version History に載っている変更項目をすべて拾ったうえで、実装や事業への影響が大きい次の 4 つを詳しく解説します。

その他の変更（検証手順の明確化、crJSON・API の補足、仕様書の構成変更など）は後半の「その他の変更」でまとめて紹介します。

変更点の全体像

Appendix F に載っている変更項目を、ブロックごとに一覧にします。

1. 新しいファイル形式と埋め込み方法

Added embedding and binding specifications for append-only text, WARC, Standard MIDI, TTML, ONNX, SafeTensors, Apache Parquet, and BlockFact .facti, .facta, and .factv formats.

Extended structured-text support to WebVTT, RSS, and Atom; clarified audio format support and ZIP-based OPC manifest content types.

v2.5 で埋め込み方法が定義された形式を用途別に並べると、次のようになります。

v2.4 で HTML や Markdown など対応範囲がテキスト関連のものに広がっていましたが、v2.5 では AI モデル・データ・ログ・アーカイブにまで拡大した形です。正直に言って初めて見るデータ形式もたくさんありました。以下、個人的に気になったもの 3 つを見ていきます。

1-1. AI モデルとデータセット（ONNX / SafeTensors / Parquet）

3 つとも考え方は共通で、各形式がもともと持っているキー・バリュー型のメタデータ領域に、Base64 エンコードした C2PA Manifest Store を c2pa:manifest というキーで格納します。

いずれの形式も「c2pa:manifest は 1 ファイルに 1 つだけ。複数見つかった場合はマニフェストが無いものとして扱う」と定められています。ハードバインディングは c2pa.hash.data アサーションで行い、マニフェストの格納位置を除外範囲（exclusion）に指定してハッシュを計算します。なお Parquet は暗号化された Parquet ファイルには埋め込めない、という制約が明記されています。

生成 AI の文脈では、これまで C2PA は「AI が出力した画像や動画」に来歴を付けるのが中心でした。v2.5 では出力物だけでなく、出力を生んだモデル自体や学習データにも同じ仕組みで来歴を付けられるようになりました。仕様書に具体的な用途は書かれていませんが、筆者としては、どの組織がどのモデルを公開したか、どのデータセットから派生したかを署名付きで追えるようになれば、モデル配布やデータ供給の場面でサプライチェーンの透明性を高める用途につながるのではないかと考えています。

1-2. 追記型テキスト（ログファイル・JSON Lines）

Plain-text files are commonly written in an append-only fashion: new lines are added at the end and existing content is never modified. This section defines how to associate C2PA provenance with such files using a rolling chain of signed checkpoints.

アプリケーションログのように末尾へ行を追記し続けるファイルは、ファイル全体に 1 回だけ署名する従来のやり方と相性がよくありません。追記のたびにファイル全体のハッシュが変わってしまうからです。v2.5 の §A.3.17 はこれを「署名付きチェックポイントの連鎖（a rolling chain of signed checkpoints）」で解決しています。

仕組みは次のとおりです。

1. 前回のチェックポイント以降に追記された部分（セグメント）だけをハッシュ対象にする
2. セグメントの直後に、マニフェストへの参照を書いた sentinel 行を 1 行追記する
3. 各チェックポイントのマニフェストは、直前のチェックポイントのマニフェストを parentOf の ingredient として参照し、直前の sentinel 行のハッシュも保持する

sentinel 行の書式は、プレーンテキストと JSON Lines で次のように分かれています。

-----BEGIN C2PA CHECKPOINT----- <manifest-reference> -----END C2PA CHECKPOINT-----

{"c2pa:checkpoint":"<manifest-reference>"}

<manifest-reference> は外部の URI か、data:application/c2pa;base64,... 形式でマニフェスト本体を埋め込んだ data URI のどちらかです。

ハードバインディングには新しい c2pa.hash.segment アサーションを使います。仕様書の例は次のとおりです。

{
  "version": 1,
  "alg": "sha256",
  "hash": b64'axfDsyQ12xTN4nWbwIPzKx/rxSLSC1UQhasygsqD4Ls=',
  "segmentStart": 127,
  "segmentEnd": 143,
  "sentinelLength": 113,
  "predecessorSentinel": {
    "start": 14,
    "length": 113,
    "hash": b64'52VROEjEl9C7I15jXoXVjuO9LzZvsBVf04bXeubHuM8='
  }
}

segmentStart から segmentEnd までが今回のセグメント、predecessorSentinel が直前の sentinel 行の位置とハッシュです。チェックポイント同士がハッシュで連鎖しているので、過去のログを途中で書き換えると連鎖が崩れて検出できます。

1-3. WARC（Web アーカイブ）

The Web ARChive (WARC) format (ISO 28500:2017) is used by national libraries, legal deposit systems, and digital preservation institutions to archive web content.

WARC は国立図書館や法定納本制度、デジタル保存機関が Web コンテンツを保存するのに使う形式です。§A.10 では、専用のレコード型として Manifest Store を格納し、collection data hash アサーションでレコードごとのハッシュを記録する方法が定義されました。「いつ・誰が・どの Web ページを保存したか」を署名付きで残せるようになるので、Web 上の証拠保全やアーカイブの真正性担保といった用途にも使えるのではないかと筆者は見ています。

2. アサーションとアクション

2-1. Linked Resource Integrity Assertion

Added the Linked Resource Integrity assertion and relatedAssertions for actions and ingredients.

例えば、 HTML の <script src> や <img src> のように、ファイル内から外部リソースを URL で参照する形式は多くあります。しかし、v2.4 で HTML に C2PA を埋め込めるようになっても、署名の対象は HTML 文書そのものだけで、参照先のスクリプトや画像が差し替えられても検出できませんでした。

新設された Linked Resource Integrity アサーション（c2pa.linked-resource-integrity、§16.4.3）はこの穴を埋めるものです。仕様書は次のように位置付けています。

A linked resource integrity assertion provides cryptographic hash coverage for such externally referenced resources, supplying the equivalent of W3C Subresource Integrity (Subresource Integrity Level 2) for formats that do not natively support that concept.

つまり、ブラウザの Subresource Integrity（SRI）に相当する仕組みを、SRI を持たない形式にも提供するということです。構造は次の 2 パターンです。

加えて allURIsIncluded を true にすると、「取得・埋め込みされるリソースへの参照はすべてこのアサーションでカバーしている」と宣言できます。<a href> のような単なるリンクや、CSS の中からさらに読み込まれるリソースのように署名時点で列挙できないものは対象外です。

なお、検証側がネットワーク越しに参照先を取得してハッシュを確認するかは任意とされています。

2-2. 新しいアクションと時刻の幅指定

Added c2pa.modified, c2pa.rendered, and c2pa.reviewed; deprecated c2pa.removed in favor of c2pa.deleted, required allActionsIncluded, and added bounded action times.

アクション一覧（§16.4.1）に次の 3 つが加わりました。

c2pa.modified の追加にあわせて、c2pa.edited の説明には「変更が編集的かどうか判断できない場合は c2pa.modified を使う」と追記されています。c2pa.reviewed の具体的な用途は仕様書に書かれていませんが、報道機関の編集チェックや AI 生成物の人間による確認など、「手は加えていないが確認した」という事実を来歴に残したい場面で使われることになりそうです。c2pa.rendered は今回追加された MIDI 対応とも対応しています。

非推奨化と必須化は次の 2 点です。

• c2pa.removed（取り込んだ素材の除去）は非推奨になり、c2pa.deleted で表現します。c2pa.deleted が素材全体の削除を指す場合は、その素材の ingredient アサーションを参照できます（§16.4.1.13 Deprecated Actions）
• allActionsIncluded は v2.4 では「should（推奨）」でしたが、v2.5 で「shall（必須）」になりました（§16.4.1.3）。Claim Generator は、記録したアクションがすべてかどうかを必ず明示する必要があります

もう 1 つの「bounded action times」は、時刻を幅で表せるようにする変更です（§8.9）。時刻フィールドに timeStampType として absolute / lowerBound / upperBound を指定できるようになりました。開始と終了の両方に下限・上限を付けると、「この処理はこの範囲のどこかで行われた」という表現ができます。正確な時刻がわからない処理について、無理に 1 点の時刻を書かずに済むようになったということです。

3. 暗号とトラスト

3-1. 耐量子署名 ML-DSA と ESP256/384/512

Allowed ML-DSA post-quantum signatures and ESP256/384/512 identifiers; clarified algorithm and key matching.

署名アルゴリズムの許可リスト（§12.3.1）に、耐量子計算機暗号の ML-DSA（ML-DSA-44 / 65 / 87）が加わりました。FIPS 204 で標準化されたアルゴリズムです。従来のアルゴリズムより署名も鍵も大きく、仕様書には署名サイズが約 2.4〜4.6 KB と書かれています。採用する場合はマニフェストサイズの増加とのトレードオフになります。

あわせて、楕円曲線まで固定した識別子 ESP256 / ESP384 / ESP512 も追加されました。暗号としては従来の ES256 / ES384 / ES512 と同等です。

3-2. その他のトラスト関連の変更

Added bounded process timestamps and trust-list snapshot identifiers; recommended validity intervals for TSA trust anchors.

Trust List は定期的に更新されるので、「どの時点の Trust List で検証したか」を残せるようになったのは、検証結果を後から再現・監査するうえで重要な変更です。

4. Live Media

Expanded the scope beyond video and specified Enhanced RTMP carriage of Verifiable Segment Info, including segment sequencing and initialization binding.

v2.3 で導入された Live Video の仕様は、v2.5 で「Live Media」に改称され（§15.2）、ライブ音声配信のような映像を含まない配信も対象となりました。

あわせて、配信ソフトから配信サーバーへの送出で広く使われる Enhanced RTMP（E-RTMP）で署名情報を運ぶ方法が定義されました（§15.5.3）。

5. その他の変更

詳しく扱わなかった変更を、Appendix F の項目ごとにまとめます。

おわりに

v2.5 は、v2.4 までで固まった仕組み（マニフェスト、ハードバインディング、Trust List）をそのまま使いながら、対象を AI モデル・データセット・ログ・Web アーカイブ・ライブ配信へと広げた改訂でした。とくに次の 3 点は、C2PA の使いどころを大きく変える可能性があります。

• AI の出力物だけでなく、モデルや学習データそのものに来歴を付けられるようになった
• 追記型のログに、チェックポイント連鎖で改ざん検知可能な来歴を付けられるようになった
• 耐量子署名 ML-DSA が使えるようになり、長期保存するコンテンツの署名にも備えられるようになった

一方で、ML-DSA によるマニフェストサイズの増加や、E-RTMP の音声対応のように周辺仕様の更新待ちの部分もあります。実装ライブラリ（c2pa-rs など）の対応状況とあわせて確認しながら導入を検討してください。

C2PA の導入や仕様の読み解きについてのご相談は、サービス紹介をご覧ください。

参考資料

• C2PA Specifications ハブ
• C2PA Technical Specification v2.5
• C2PA Technical Specification v2.5 Appendix F Version History
• C2PA Technical Specification v2.4
• FIPS 204 Module-Lattice-Based Digital Signature Standard
• W3C Subresource Integrity