Gemini の C2PA 検証機能を c2patool と並べて試してみた

お断り: 本記事は 2026 年 5 月 19 日付の Google ブログ記事 Making it easier to understand how content was created and edited と、Gemini アプリのヘルプ Verify Google AI-generated images, videos, and audio with SynthID の内容を踏まえ、筆者が 2026 年 5 月 23 日に Gemini アプリで実際に画像を生成・検証し、ダウンロードした画像を c2patool（v0.26.50）で読み出して整理したものです。Gemini 側の画面挙動はロールアウト状況・地域・モデル更新で変わり得ます。最新の挙動は Google 公式の説明をご確認ください。本記事に誤りや古くなった箇所を見つけられた場合は、記事末尾のフィードバック枠よりお知らせいただけると助かります。

はじめに

2026 年 5 月 19 日、Google が「コンテンツがどう作られ、どう編集されたか」を理解しやすくする一連の取り組みを発表しました。Gemini アプリの SynthID 検証は既に世界で 5,000 万回（50 million times）使われているとされ、ここに C2PA Content Credentials の検証が乗り、さらに Search や Chrome にも段階的に広がっていく流れが明示されています。Pixel 8 / 9 / 10 の動画にも Content Credentials が数週間内に拡張される予定で、Meta も Instagram でカメラ由来の Content Credentials をラベル表示する方針を表明しています。

C2PA を専門にやっている当社としては、これまで c2patool などの開発者向けツールが中心だった「Manifest を読む」操作が、一般ユーザーにとっても少し身近になってきたな、というくらいの受け止めです。本記事ではその発表内容を整理したうえで、Gemini アプリで実際に検証機能を触ってみた結果と、同じ画像を c2patool で読み出した結果を並べて、「一般ユーザーに見える情報」と「実装者が見ているデータ」の段差を整理します。

5 月 19 日の発表で何が変わるのか

要点を絞ると次の 4 つです。

項目	内容
Gemini の C2PA 検証	「これはオリジナルか、何で編集されたか」を Gemini アプリで確認可能に。同日からロールアウト開始
Search / Chrome への展開	Lens・AI Mode・Circle to Search・Gemini in Chrome から SynthID 検証が使える。C2PA 検証も今後数か月で順次
Pixel の動画対応	Pixel 8 / 9 / 10 のネイティブカメラが画像に続いて動画にも Content Credentials を付与
Instagram のラベリング	Meta が Instagram でカメラ由来の Content Credentials をラベル表示する方針を表明

加えて Google Cloud 側では「AI Content Detection API」が Gemini Enterprise Agent Platform 上で公開され、Google 製モデル以外も含めた AI 生成判定が API として呼べるようになりました。本記事では一般ユーザー向け機能（Gemini アプリでの検証）にフォーカスし、API 側は別途扱います。

ポイントは、C2PA は「業界標準としてゆるく広がっていく」段階から「ユーザーの目に触れる UI として刺さる」段階に入ったということです。Pixel カメラで撮影 → Instagram でラベル表示 → Gemini で検証、という消費者導線が初めて一本につながりました。

Gemini アプリで今できること

ヘルプの記述から、現時点で Gemini アプリでできることを整理します。

種類	サポート対象	制限
画像	単一ファイル、100 MB 以下	1 日あたり概ね 10 回
動画	90 秒未満、100 MB 以下	1 日あたり概ね 10 本、合計 5 分まで
音声	1 時間未満	1 日あたり合計 3 時間まで

やってみた (1): Gemini で画像を生成して Gemini に検証させる

まず Gemini アプリで「机の上にサボテンが置いてある画像を生成して」と頼みます。

Gemini アプリで机の上にサボテンの画像を生成依頼している画面

生成された画像はこちらです。

Gemini が生成した、机の上にサボテンの鉢が置かれた画像

これを別の Gemini セッションにアップロードし直して「Is this AI generated?」と聞いてみます。

Gemini に生成画像を投げて「Is this AI generated?」と聞いた応答画面

応答はこうでした。

はい。この画像ファイルには、Google LLC（Google Media Processing Services）の AI によって作成および編集されたことを示す安全な記録が含まれています。

これらの種類の記録は C2PA Content Credentials と呼ばれ、コンテンツの出所と履歴をファイルに安全に埋め込みます。

注目してほしいのは、Gemini が「SynthID 透かしを検出した」ではなく「C2PA Content Credentials が含まれている」と明示的に答えている点です。5 月 19 日からの C2PA 検証ロールアウトが実機で確かに動いていて、Manifest を直接読み取って claim_generator（Google LLC / Google Media Processing Services）を要約しているのが見て取れます。質問は英語で投げましたが、応答は日本語で返ってきました。

やってみた (2): 同じ画像を c2patool で読む

ここからが実装者視点での見え方です。生成画像を PC のブラウザから直接ダウンロードして、c2patool (v0.26.50) で Manifest を読みます。

c2patool sites/hp/public/assets/images/blog/gemini-c2pa-verification/Gemini_Generated_Image_bqklr7bqklr7bqkl.png | jq '{
  active_manifest,
  validation_state
}'

{
  "active_manifest": "urn:c2pa:ae81ba4c-c9cc-2b79-4e4a-45f8dacc979d",
  "validation_state": "Valid"
}

validation_state: Valid は「Manifest の署名と整合性チェックは pass、ただし証明書のトラスト評価は別の話」という意味です（後述のコラムで Trusted まで上げます）。Gemini が「Google LLC の AI で作成および編集されたことを示す安全な記録」と要約している裏側でどんな検証を走らせているかは外からは見えませんが、ローカル c2patool に C2PA 公式の Trust List を渡せば Trusted まで上がる以上、Gemini 側も同等のトラストアンカー（おそらく自社のもの）を参照しているのではないかと推測できます。

active manifest の中身を絞って見ます。

c2patool sites/hp/public/assets/images/blog/gemini-c2pa-verification/Gemini_Generated_Image_bqklr7bqklr7bqkl.png | jq '
  .manifests["urn:c2pa:ae81ba4c-c9cc-2b79-4e4a-45f8dacc979d"] | {
    claim_generator_info,
    signature_info: (.signature_info | {alg, issuer, time, cert_serial_number}),
    actions: [.assertions[] | select(.label=="c2pa.actions.v2") | .data.actions[] | {action, digitalSourceType}],
    ingredient: (.ingredients[0] | {relationship, parent_manifest: .active_manifest})
  }'

{
  "claim_generator_info": [
    {
      "name": "Google C2PA Core Generator Library",
      "version": "914819096:914819096"
    }
  ],
  "signature_info": {
    "alg": "Es256",
    "issuer": "Google LLC",
    "time": "2026-05-23T08:51:30+00:00",
    "cert_serial_number": "3655090356939435118458746357446390718679319596"
  },
  "actions": [
    { "action": "c2pa.opened",    "digitalSourceType": null },
    { "action": "c2pa.edited",    "digitalSourceType": "http://cv.iptc.org/newscodes/digitalsourcetype/composite" },
    { "action": "c2pa.converted", "digitalSourceType": null }
  ],
  "ingredient": {
    "relationship": "parentOf",
    "parent_manifest": "urn:c2pa:54849d48-33d0-10a3-9dad-42807910518f"
  }
}

ここまで来ると、Gemini が要約していた情報の出どころが具体的に見えます。

「Google LLC の AI で作られた」: claim_generator_info.name = "Google C2PA Core Generator Library" と signature_info.issuer = "Google LLC"
「C2PA Content Credentials が含まれている」: ES256 署名された Manifest が JUMBF として埋まっていて validation_state が Valid
「作成および編集された」: active manifest 側の actions が c2pa.opened → c2pa.edited（composite）→ c2pa.converted の系列

面白いのは、active manifest がさらに親 Manifest（urn:c2pa:54849d48-...）を ingredient として参照していることです。親 Manifest 側を覗くと、さらに具体的なことが分かります。

c2patool sites/hp/public/assets/images/blog/gemini-c2pa-verification/Gemini_Generated_Image_bqklr7bqklr7bqkl.png \
  | jq '.manifests["urn:c2pa:54849d48-33d0-10a3-9dad-42807910518f"].assertions[].data.actions'

[
  {
    "action": "c2pa.created",
    "digitalSourceType": "http://cv.iptc.org/newscodes/digitalsourcetype/trainedAlgorithmicMedia",
    "description": "Created by Google Generative AI."
  },
  {
    "action": "c2pa.edited",
    "digitalSourceType": "http://cv.iptc.org/newscodes/digitalsourcetype/trainedAlgorithmicMedia",
    "description": "Applied imperceptible SynthID watermark."
  }
]

親 Manifest は ingredients を持たないチェーンの最上位で、actions が 2 つ並んでいます。1 行目の c2pa.created の digitalSourceType が trainedAlgorithmicMedia（IPTC の「学習済みアルゴリズムによるメディア」を意味するコード）になっていて、これが「AI で初めて生成された時点」の宣言です。

注目したいのは 2 行目の c2pa.edited で、description が「Applied imperceptible SynthID watermark.」になっています。SynthID 透かしの適用はピクセル値への統計的な埋め込みという物理的な処理に加えて、C2PA Manifest 内の action としても明示的に宣言されている、ということです。watermark の物理的存在と watermark を適用した旨の C2PA 宣言が両建てになっていて、Manifest が剥がれても透かしは残り、Manifest が残れば透かしの適用履歴も追跡できる、という二層構成が生成事業者側の実装に既に現れています。

つまり Gemini の出力は「Imagen / Nano Banana Pro 系で生成 → SynthID 透かしを適用」を親 Manifest に、「Gemini アプリ側でユーザー向けに変換・合成」を active manifest に、という二段構成で Manifest チェーンに記録されています。

Manifest URN や JUMBF ボックスの並びといった生データは c2patool 側にしか出てきません。このあたりの読み方は c2patool で Manifest を覗いてみると C2PA の Manifest 構造で詳しく扱っています。

コラム: Valid 止まりを Trusted まで上げる

ここまでの c2patool 出力では validation_state が Valid でしたが、実はトラストアンカーを指定すると Trusted まで上げられます。デフォルトで Valid 止まりだった理由は、c2patool 公式ドキュメントが明確に書いています。

c2patool does not have a built-in default trust list. Users must explicitly supply trust anchors through one of these methods.

つまり c2patool は組み込みのトラストアンカーを持っておらず、ユーザーが Trust List を明示的に渡さない限り、署名証明書は常に signingCredential.untrusted 扱いになる設計です。

C2PA 公式が conformance 用に配布している Trust List を取って、c2patool <path> trust --trust_anchors=<pem> の形で渡してみます。

curl -sLo c2pa-trust.pem \
  https://raw.githubusercontent.com/c2pa-org/conformance-public/refs/heads/main/trust-list/C2PA-TRUST-LIST.pem
curl -sLo c2pa-tsa-trust.pem \
  https://raw.githubusercontent.com/c2pa-org/conformance-public/refs/heads/main/trust-list/C2PA-TSA-TRUST-LIST.pem
cat c2pa-trust.pem c2pa-tsa-trust.pem > c2pa-combined-trust.pem

c2patool sites/hp/public/assets/images/blog/gemini-c2pa-verification/Gemini_Generated_Image_bqklr7bqklr7bqkl.png \
  trust --trust_anchors=c2pa-combined-trust.pem \
  | jq '{ validation_state, active: .validation_results.activeManifest }'

{
  "validation_state": "Trusted",
  "active": {
    "success": [ "..." ],
    "informational": [
      {
        "code": "signingCredential.ocsp.notRevoked",
        "explanation": "signing cert not revoked: 3655090356939435118458746357446390718679319596"
      }
    ],
    "failure": []
  }
}

failure が空になり、informational に残るのは signingCredential.ocsp.notRevoked だけ。これは OCSP responder にオンラインで照会して「証明書は失効していない」と返ってきた成功通知で、ある方が正常な状態です。timeStamp.untrusted も TSA 用 Trust List を結合したことで消えています。

Trust List の中身を覗くと、Google が既に C2PA conformance のトラストアンカーに登録済みであることが確認できます。

openssl crl2pkcs7 -nocrl -certfile c2pa-trust.pem \
  | openssl pkcs7 -print_certs -noout \
  | grep "^subject" | grep "Google"

subject=C=US, O=Google LLC, CN=Google C2PA Media Services 1P ICA G3
subject=C=US, O=Google LLC, CN=Google C2PA Mobile A 1P ICA G3
subject=C=US, O=Google LLC, CN=Google C2PA Mobile B 1P ICA G3
subject=C=US, O=Google LLC, CN=Google C2PA Root CA G3

つまり「Google LLC が信頼されていないから Valid 止まりだった」のではなく、「c2patool に Trust List を読み込ませていなかったから常に untrusted 扱いだった」が正しい解釈です。

所感

Manifest はもうエンドユーザーに「見られる」前提で書く

今回 Gemini に取り込まれたことで、これからは「Gemini が要約したときに、ユーザーにとって意味のある文に化けるかどうか」が品質の指標になっていきます。c2pa.actions.v2 のアクション系列と CAWG identity の埋め方を雑にやると、ユーザー画面に出る要約も雑になる可能性があります。

配信経路ごとの「剥がれ」を前提にした運用

C2PA Manifest は JUMBF ボックスとしてファイルに埋め込まれている以上、再エンコードやメタデータを保持しない転送経路を通れば消えます。Gemini アプリ内でせっかく Manifest を読み取って真正性を判定できても、ユーザーが画像をメッセンジャーや SNS、写真アプリ経由でやり取りした瞬間に検証材料が失われます。実装側は「ユーザーがどの経路で画像を持ち出すか」によって C2PA 検証の成立率が変わる前提で、剥がれた場合のフォールバックを SynthID 透かしや soft binding でどう組み込むかを設計する必要があります。

まとめ

Gemini アプリの C2PA / SynthID 検証は、今のところユーザー視点では「これは Google AI で作られたか」「これはカメラで撮ったオリジナルか」を質問できるシンプルな機能です。裏側では SynthID watermark と C2PA Content Credentials という別系統の仕組みが動いていて、c2patool で同じ画像を読むと、Gemini が要約として返した内容の出どころが Assertion 単位で具体的に見えます。

C2PA を実装する側にとっては、Manifest がエンドユーザーの目に触れる前提の時代に切り替わったということ。今のうちに Action 履歴と CAWG identity の設計を整えておけば、Gemini や類似の検証 UI で表示されたときに、ユーザーに伝わる Manifest になります。

当社（合同会社テックサンクス）は C2PA 専門でコンテンツ来歴対応の受託開発・実装コンサル・技術顧問を提供しています。Manifest 設計の見直しや署名インフラの構築でお困りでしたら、サービス案内からお気軽にご相談ください。

参考リンク

Google ブログ「Making it easier to understand how content was created and edited」: https://blog.google/innovation-and-ai/products/identifying-ai-generated-media-online/
Google ブログ「How we’re bringing AI image verification to the Gemini app」: https://blog.google/innovation-and-ai/products/ai-image-verification-gemini-app/
Gemini ヘルプ「Verify Google AI-generated images, videos, and audio with SynthID」: https://support.google.com/gemini/answer/16722517
C2PA Technical Specification v2.4: https://spec.c2pa.org/specifications/specifications/2.4/specs/C2PA_Specification.html