C2PA Technical Specification v2.4 公開解説新規追加された機能

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

はじめに

2026 年 4 月、C2PA から Technical Specification v2.4 が公開されました。v2.3（2025 年 12 月）からおよそ 4 ヶ月ぶりの改訂で、生成 AI・環境情報・マニフェストリポジトリ運用といった周辺エコシステムの成熟に合わせた新アサーションの追加と、JSON-LD ベースの新しい表現形式（crJSON）の導入が目玉になっています。

本記事では v2.4 で新規に追加された機能（crJSON / 新アサーション 3 種 / 埋め込み対応の拡張）に絞って整理します。Actions / Ingredient / Live Video / Soft Binding など既存仕様の改訂は本記事では扱わないので、興味があれば公式の §5.3 Version History を直接ご確認ください。各項目は公式 §5.3 Version History の英文を引用したうえで、その意味するところと実装影響を日本語で解説する形式にしています。

C2PA の基本概念は第1回 C2PAとは、Manifest の内部構造は第3回で扱っているので、用語で迷ったら適宜参照してください。

なお、v2.4 の公式な変更履歴は仕様書本文の §5.3 Version History にまとまっています。差分はこちら（C2PA Technical Specification v2.4 §5.3 Version History）で確認できます。本記事の引用はすべてこの一次情報からのもので、解説部分は各章で裏取りしながら整理しています。

v2.4 の位置付け

C2PA Technical Specification は 2024 年の v2.1 以降、年数回のペースで改訂が続いています。バージョンごとの大テーマはこんな流れです。

バージョン	公開時期	大テーマ
v2.1	2024 年 9 月	Manifest・Asset の状態定義整理、`c2pa` URN 導入、Time-stamp Manifest 新設
v2.2	2025 年 5 月	Soft Binding Resolution API、Android Motion Photo 等の Multi-part Asset、Update Manifest の時刻印
v2.3	2025 年 12 月	Live Video Streaming 導入、External Reference Assertion 新設、Cloud Data Assertion 改善
v2.4	2026 年 4 月	新アサーション 3 種、crJSON 新設、HTML・構造化テキスト対応、Live Video の動的パッケージ拡張、TIFF・Soft Binding 周りの細かな改訂

v2.3 で「配信・埋め込み先の多様化」に手を付け、v2.4 で「宣言できる中身と表現形式の多様化」に踏み込んだ、という読み方ができます。公式の v2.4 概要文も次のように要約しています。

This version introduces new asset format support, new assertions, and a new JSON-based serialization for Content Credentials, alongside clarifications and improvements to actions, ingredients, live video, and cryptography.

新フォーマット対応・新アサーション・新シリアライゼーション、加えて actions / ingredients / live video / 暗号周りの明確化と改善、という整理です。本記事は前半 3 つ（新フォーマット・新アサーション・新シリアライゼーション）にあたる §5.3 Version History の上から 3 ブロックに絞って扱います。

1. 新しい Content Credential JSON (crJSON) フォーマット

Introduced a new JSON-LD serialization of a C2PA Manifest Store (called crJSON) for use in profile evaluation, interoperability testing, and validation reporting.

crJSON is a derived view over C2PA data and is not independently verifiable or intended as an input format.

これまで C2PA マニフェストの本体（画像・動画・PDF 等に埋め込まれる署名付きデータ）は CBOR / COSE を JUMBF コンテナに入れた形式で、ここは仕様で固まっていました。一方で、そのマニフェストを読み取った結果をどう表現するか・どのような方式で表現するかは標準化されておらず、検証ツールごとに独自形式で結果を表示するようになっていました。

crJSON はこの「マニフェストを JSON-LD で表現する標準形」を定めたものです。仕様書が想定用途として明示しているのは次の 3 つです。

プロファイル適合評価（profile evaluation）
相互運用性テスト（interoperability testing）
検証レポーティング（validation reporting）

注意点として、crJSON は引用文どおり「派生ビュー」であって独立して検証できる形式ではなく、入力フォーマットとしての利用も想定されていない、という建て付けです。署名検証の根拠はあくまで CBOR 側のマニフェストで、crJSON はそれを標準化された JSON-LD として写像したもの、と捉えるのが実装上の正しい理解になります。

c2pa-rs 側ではすでに実装済みで、Reader::cr_json() / Reader::cr_json_value()（PR #1919）が利用できます。CLI にも --crjson フラグが用意されていて、c2patool で署名済みアセットから crJSON を直接吐き出せる状態です。

実機で --crjson の有無で出力を比較してみます。c2patool のインストールと、c2pa-rs リポジトリのテスト用 fixture（C.jpg）をクローンするだけの最小ケースです。

# 1. c2patool をインストール（最新版 0.26.50 以降に --crjson フラグあり）
cargo install c2patool

# 2. c2pa-rs リポジトリを clone（テスト用 fixture を使うため）
git clone --depth 1 https://github.com/contentauth/c2pa-rs.git

# 3a. デフォルト（--crjson なし）の出力
c2patool c2pa-rs/cli/tests/fixtures/C.jpg

# 3b. --crjson 付きの出力
c2patool c2pa-rs/cli/tests/fixtures/C.jpg --crjson

3a（フラグなし）の出力。c2patool 独自形式の JSON で、manifests はマニフェスト ID をキーにしたオブジェクト、assertions は {label, data, kind} の配列構造です。

{
  "active_manifest": "contentauth:urn:uuid:a621a5d8-147d-499b-95d7-2eaff1009efc",
  "manifests": {
    "contentauth:urn:uuid:a621a5d8-147d-499b-95d7-2eaff1009efc": {
      "claim_generator": "make_test_images/0.6.1 c2pa-rs/0.6.1",
      "title": "C.jpg",
      "format": "image/jpeg",
      "assertions": [
        {
          "label": "stds.schema-org.CreativeWork",
          "data": { "@context": "http://schema.org/", "@type": "CreativeWork", "author": [...] },
          "kind": "Json"
        },
        { "label": "c2pa.actions.v2", "data": { "actions": [...] } }
      ],
      "signature_info": { "alg": "Ps256", "issuer": "C2PA Test Signing Cert", ... }
    }
  }
}

3b（--crjson）の出力。冒頭に @context が付き、manifests はマニフェスト配列、assertions はラベルをキーにしたオブジェクトに変わります。

{
  "@context": {
    "@vocab": "https://c2pa.org/crjson",
    "extras": "https://c2pa.org/crjson/extras"
  },
  "manifests": [
    {
      "label": "contentauth:urn:uuid:a621a5d8-147d-499b-95d7-2eaff1009efc",
      "assertions": {
        "stds.schema-org.CreativeWork": {
          "@context": "http://schema.org/",
          "@type": "CreativeWork",
          "author": [{ "@type": "Person", "name": "Gavin Peacock" }]
        },
        "c2pa.actions": { "actions": [...] },
        "c2pa.hash.data": { "alg": "sha256", "hash": "b64'YKIA...", ... }
      },
      "claim": { ... }
    }
  ]
}

出力構造が変わっているのが見て取れると思います。3b は冒頭に @context が付いた JSON-LD 形式になっており、これが仕様で標準化された crJSON ビューです。深掘りしたい場合は JSON-LD 公式サイトと W3C JSON-LD 1.1 仕様を参照してください。

2. 新アサーション

2-1. Repository Receipt Assertion

Added a new Repository Receipt Assertion (c2pa.repository-receipt) to record proof that a C2PA Manifest has been ingested by a C2PA Manifest Repository.

マニフェストリポジトリ（Manifest Repository: Glossary §2.4.5 の定義は「C2PA Manifest や Manifest Store を格納でき、content binding で検索できるリポジトリ」）への取り込み証明を、取り込まれた側のマニフェスト内に記録するためのアサーションです。

仕様書 §18.27.1 Description が想定用途として明示しているのは次の 3 点です。

Such use cases include providing non-repudiation of ingestion, establishing that a manifest was present in a repository at a particular time, or supporting workflows in which an external service attests to registration of the manifest.

つまり、

取り込まれたことの否認防止（non-repudiation of ingestion）
特定時点でマニフェストがリポジトリに存在していたことの証明
外部サービスがマニフェストの登録を立証するワークフローの支援

の 3 つです。

実装上の重要な制約として、§18.27.1 はこのアサーションを update manifest 内にしか書けないと定めています。

Such a receipt may be recorded via a repository receipt assertion. When recorded, it shall only appear within an update manifest.

update manifest はアセット本体への編集を伴わず、追加でアサーションを書き足すためのマニフェスト（§11.2.3）です。リポジトリ側が後から受領証明を書き足す動線を仕様で固めた、という設計です。

2-2. Environmental Sustainability Assertion

Added a new Environmental Sustainability Assertion (c2pa.environmental-sustainability) to convey machine-generated sustainability metrics (energy, greenhouse gas emissions, and water consumption).

エネルギー消費量・温室効果ガス排出量・水消費量といった環境メトリクスを機械可読で残すアサーションです（§18.26 Environmental Sustainability）。仕様書 §18.26.1 Description は次のように定義しています。

The environmental sustainability assertion is used to convey machine-generated sustainability data associated with the creation or modification of an asset. The information carried by this assertion is intended to support transparency and auditing of environmental costs (for example, energy consumption, greenhouse gas emissions, and water use) across a content supply chain, including workflows that use Generative AI.

つまり、コンテンツの作成・修正に伴う環境コストを、生成 AI を含むコンテンツサプライチェーン全体で透明化・監査可能にする、というのが仕様で明示された意図です。

data オブジェクトには energy_kwh（kWh）、carbon_kgco2e（kgCO2e、ISO 14064-1:2018 準拠）、water_litres（L）の 3 フィールドのいずれか、または複数を含められます。各フィールドは value（非負の数値）を必須とし、任意で measurementMethod（reverse-DNS 名前空間で計測手法を記述）を持てます。

なぜこのアサーションが入ったかについては、仕様書本文には背景説明はありませんが、実際にマージされた提案 PR の説明文に立法文脈の根拠が明記されています。アサーション提案 PR #2007 “Introduce assertion for carrying machine-sourced environmental sustainability data” に次の一文があります。

This could be an useful application of C2PA in the context of emerging legislation such as the EU AI Act (art. 53).

EU AI Act Article 53（Regulation (EU) 2024/1689 第 53 条）は汎用 AI モデルプロバイダの透明性義務（学習・運用に伴う計算資源情報の開示等）を定めた条文で、ここを射程として C2PA 側でも機械可読な形でデータを残せるようにしておこう、という動機です。仕様本文が ISO/IEC TR 20226:2025（エネルギー消費測定）と ISO 14064-1:2018（GHG 排出量測定）を normative reference に採用しているのも、既存の国際標準計測体系に乗せることで規制対応の根拠として使いやすくする意図と整合します。

2-3. AI Disclosure Assertion

Added a new AI Disclosure Assertion (c2pa.ai-disclosure) for machine-readable AI transparency info.

AI 透明性情報を機械可読で宣言するアサーションです（§18.28 AI Disclosure）。使用したモデル（modelType / modelName / modelIdentifier）、コンテンツの学術分野（scientificDomain）、人間関与度（humanOversightLevel: fully_autonomous / prompt_guided / human_validated）を構造化して残せます。

既存の c2pa.actions や digitalSourceType を置き換えるものではなく補完する位置付けで、生成 AI を扱う事業者にとっては最優先で押さえるアサーションです。

3. 埋め込み対応の拡張

Added support for embedding C2PA Manifests into HTML documents.

Added support for embedding C2PA Manifests into structured text formats (source code, YAML, Markdown, AsciiDoc, etc.).

v2.3 までの C2PA は、画像・音声・動画・PDF など「既存のメタデータ規約を持つバイナリ形式」への埋め込みが中心でした。v2.4 ではこれが HTML（§A.7）と構造化テキスト（§A.9）にも拡張されました。

HTML（§A.7）: <script type="application/c2pa"> でインライン埋め込み（Base64 エンコード）、または <link rel="c2pa-manifest" href="..."> で外部参照。いずれも HTML の head 内に配置し、仕様は外部参照を推奨。
構造化テキスト（§A.9）: ソースコード・YAML・TOML・INI・Markdown・AsciiDoc・LaTeX 等、コメント構文や front matter を持つ形式向け。-----BEGIN C2PA MANIFEST----- で始まり、マニフェスト参照（URL または data:application/c2pa;base64,... URI）を書き、-----END C2PA MANIFEST----- で終わる形式。
非構造化テキスト（§A.8）: Unicode の Variation Selectors を使った不可視埋め込み（後述で詳述）。

コード・文書の来歴証明という領域に C2PA の射程が広がった改訂で、これまでバイナリメディア中心だった C2PA がテキスト系コンテンツも扱えるようになりました。

補足: 非構造化テキストへの埋め込み（§A.8）

「非構造化テキスト」というのは、HTML や Markdown のようにマニフェスト参照を書ける場所がない、生のテキスト文字列を想定しています。たとえば LLM が出力したプレーンテキストをコピペで他システムに貼り付ける、といった場面で「文字列そのものに来歴情報を持たせたい」という用途です。

仕組みは、JUMBF 形式の C2PA Manifest Store をバイト列として、Unicode の Variation Selectors（U+FE00〜U+FE0F と U+E0100〜U+E01EF の範囲）にエンコードして、テキストの末尾に不可視で付加する、というものです。Variation Selectors は元々「絵文字や CJK の異体字選択」に使われる Unicode 仕様の正式メンバで、それ自体は何も描画しないため、文字列をそのまま読んでも見た目上は気づきません。

仕様で定義されているコンテナは C2PATextManifestWrapper という構造です。

aligned(8) class C2PATextManifestWrapper {
    unsigned int(64) magic = 0x4332504154585400;  // "C2PATXT\0"
    unsigned int(8)  version = 1;
    unsigned int(32) manifestLength;
    unsigned int(8)  jumbfContainer[manifestLength];
}

マジックナンバー（C2PATXT\0）+ バージョン + マニフェスト長 + JUMBF 本体、という単純なバイナリです。

エンコードアルゴリズムは 1 バイトずつ Variation Selector に対応付ける形で（§A.8.3.1）、

function byteToVariationSelector(byte b) {
    if (b >= 0 && b <= 15) {
        return U+FE00 + b;
    } else if (b >= 16 && b <= 255) {
        return U+E0100 + (b - 16);
    }
}

つまり 0〜15 は U+FE00 ベースの 16 個に、16〜255 は U+E0100 ベースの 240 個にそれぞれマッピングする、というだけのシンプルな対応です。デコード側はこの逆を辿ります。

配置ルール（§A.8.4.1）として重要なのは、

ラッパー全体の直前に Zero-Width No-Break Space（U+FEFF）を 1 つ置く（前方互換性確保のためと検出マーカーを兼ねる）
ラッパーは可視テキストの末尾に配置することが推奨
連続した 1 ブロックとして埋め込み、複数箇所に分割しない

検出アルゴリズム（§A.8.4.2）は、テキストを先頭から走査して U+FEFF を見つけ、その直後の Variation Selector 列の最初 8 文字をデコードして C2PATXT\0 のマジックと一致するかを確認、という流れです。

content binding は通常どおり c2pa.hash.data アサーションで行いますが、ハッシュ計算は NFC 正規化済みの UTF-8 バイト列に対して、exclusions フィールドでラッパーの位置を除外したうえで計算する、という規定があります（§A.8.6.1）。

なお §A.8.1 は「他の埋め込み方式が使える場合はそちらを優先すべきで、この方式は仕様としても review 中、運用フィードバック次第で変更される可能性がある」と明記しているので、本番投入の際はこの注意書きを踏まえて設計する必要があります。

おわりに

本記事で扱った 3 ブロック（crJSON / 新アサーション 3 種 / 埋め込み対応の拡張）は、いずれも v2.4 で新しく載った機能です。既存仕様（Actions / Ingredient / External Reference / Metadata / Live Video / TIFF / Versioning / Asset Type / Soft Binding）への改訂は本記事の範囲外なので、必要に応じて公式の §5.3 Version History を直接参照してください。