C2PA 署名に SDK だけでは不十分な理由

前回の記事では、AI 生成コンテンツの増加により、本物のメディアと改ざんされたコンテンツを見分けることが難しくなっている現状について解説しました。現在、組織が問題の理解からソリューションの導入へと進むなか、より実践的な課題が浮上しています。それは、本番システムや企業のワークフロー全体に C2PA を導入するには何が必要か、ということです。

EU AI Act や California AI Transparency Act などの規制では、C2PA の使用は義務付けられていません。しかし、AI の利用を開示し、検証可能な真正性を維持することを組織に求める圧力は高まっています。これにより、コンテンツの来歴を証明するためのオープンで相互運用可能な標準への関心が高まっています。

オープンソースの C2PA SDK の統合は重要な第一歩ですが、本番環境への導入にはそれだけでは不十分です。

Content Credentials は、より大規模なトラストシステムの表層にあたります。その背後には、来歴情報を含むマニフェスト、マニフェストを保護する暗号署名、そして署名を生成したアプリケーションやサービスを識別する証明書があります。

SDK を使用すれば署名済みコンテンツを作成できます。しかし、それだけでは、長期にわたって信頼され続ける C2PA 署名サービスの運用に必要な要件を満たすことはできません。

Content Credentials は、より大きなトラストモデルの一部

Coalition for Content Provenance and Authenticity（C2PA）は、デジタルコンテンツの来歴を記録し、保護するための技術標準を定めています。

保護されたアセットには、その作成や変更に関する情報を記述したマニフェストが含まれます。ワークフローに応じて、以下のような情報を含めることができます。

• コンテンツの作成または編集に使用したアプリケーション
• アセットに対して実行された操作
• 来歴情報を表明した当事者
• 生成 AI ツールが作成に使用されたかどうか

これらの情報は、従来のメタデータとして単に追加されるわけではありません。マニフェストには暗号署名が施されるため、検証者は、署名の生成後に来歴情報が変更されたかどうかを確認できます。従来のメタデータは、比較的容易に変更または削除できる場合があります。C2PA 署名は改ざん検知の仕組みを提供し、来歴情報が署名者の意図した内容であることを確認するのに役立ちます。Content Credentials は、その情報をユーザが簡単に確認できる形で表示します。そして、その完全性を保護しているのが基盤となる署名です。

C2PA に関する 5 つのよくある誤解

C2PA で何ができ、何ができないのかを理解することで、この標準の価値と、本番環境への導入に必要な要件の両方が明確になります。

誤解 1：C2PA は AI 生成コンテンツを検出する

C2PA は AI 検出システムではありません。

画像、動画、文書を解析し、人工知能（AI）によって作成されたものかどうかを判定するものではありません。C2PA はその代わりに、コンテンツがどのように作成または変更されたかを暗号技術によって検証可能な形で記録します。この記録には、制作過程で AI 支援ツールが使用されたことを示す情報も含めることができます。

これは重要な違いです。AI 検出技術はコンテンツを解析し、確率に基づいて判定します。生成 AI モデルの進化に伴い、こうした判定の信頼性が低下する可能性があります。C2PA は異なるアプローチを採用しており、クリエイタ、パブリッシャ、アプリケーションが、コンテンツとその履歴について透明性のある検証可能な情報を表明できるようにします。

この透明性を重視する考え方は、新たに登場している規制の枠組みにも合致しています。たとえば、EU Artificial Intelligence Act では、特定の AI 生成コンテンツや AI によって加工されたコンテンツについて、透明性に関する義務が導入されています。この法律は C2PA を義務付けるものではありませんが、C2PA 標準を利用することで、組織は来歴情報を伝え、必要に応じて AI の使用を開示するための実用的かつ相互運用可能な手段を得られます。 

誤解 2：オープンソース SDK だけで十分

C2PA 仕様は公開されており、プロジェクトでは署名済みコンテンツの作成と検証に使用できるオープンソース SDK が提供されています。これらのツールは実装を始めるうえで役立ちますが、本番環境向けの署名サービスを導入するには、ライブラリを統合するだけでは不十分です。

本番サービス（およびそれによって生成される Content Credentials）が公式 C2PA エコシステム内で信頼されたものとして認識されるには、署名製品が C2PA Conformance Program の技術およびセキュリティ評価に合格し、法的なオンボーディングを完了する必要があります。承認された Generator Products のみが、公式 C2PA Trust List に掲載された認証局から C2PA Claim Signing Certificate の発行を受けることができ、公開されている Conforming Products List に掲載される資格を得られます。

したがって、適合性の確保は、オープンソースプロジェクトへの参加というよりも、製品認証に近いものです。製品は、適切な鍵の保護や証明書管理を含め、C2PA 仕様とそのセキュリティ要件に準拠していることを証明する必要があります。こうした管理は、デザインや広報から、ソーシャルメディア、Web、代理店、さらに幅広いマーケティング業務まで、関連するすべての組織内ワークフローに適用する必要があります。

また、これは継続的な取り組みでもあります。相互運用性と信頼されたステータスを維持するには、仕様や適合要件の変更に継続して対応する必要があります。つまり、本番環境での課題は C2PA を一度実装すれば終わりではなく、長期にわたりセキュアで、要件に適合し、信頼される署名サービスを運用し続けることです。

誤解 3：Interim Trust List で本番環境にも十分対応できる

初期の C2PA 実装の多くでは、Content Authenticity Initiative（CAI）の Interim Trust List や社内で開発した署名サービスを使用して、Content Credentials の検証が行われてきました。これらの方法は、評価、プロトタイプ、概念実証（PoC）には有用ですが、本番環境に対応した導入方法と考えるべきではありません。

Interim Trust List は、初期の導入とテストを支援するために作成されました。一方、本番環境では、適合するアプリケーションやサービス間で Content Credentials を一貫して検証できるよう、公式の C2PA Trust List を利用することが想定されています。

検証アプリケーションが公式 C2PA Trust List をより重視するようになるにつれ、そのトラストフレームワーク外で署名されたコンテンツは、現在の評価ツールで受け入れられていても、将来の本番環境では信頼されたコンテンツとして認識されない可能性があります。

そのため、本番環境への導入を計画するチームは、Content Credentials をどのように生成するかだけでなく、それらが C2PA エコシステム全体で信頼されるかどうかも検討する必要があります。公式のトラストフレームワークを利用することで、現在の相互運用性を確保するとともに、将来的な普及拡大にも対応しやすくなります。 

誤解 4：どの署名証明書でも使用できる

デジタル署名は C2PA の基本となる技術ですが、どの署名証明書でも使用できるわけではありません。

多くのチームは、すでに文書署名やコードサイニング証明書に馴染みがあるでしょう。これらの証明書は、文書やソフトウェアの発行元に対するトラストを確立しますが、異なるユースケース向けに設計されています。

C2PA 署名証明書では、異なるトラストモデルが採用されています。文書の作成者やソフトウェアパッケージの発行元を識別するのではなく、C2PA 署名を生成したアプリケーションやサービスを識別します。これにより、検証者は、保護された来歴情報がどの信頼された実装によって生成されたのかを確認できます。

そのため、C2PA の実装には、仕様およびその適合要件に沿った証明書発行が必要です。既存の企業向け署名証明書を流用するだけでは不十分です。

誤解 5：署名アプリケーションがクリエイタの ID になる

C2PA 署名証明書は署名を実行するアプリケーションやサービスを識別するため、Content Credentials で表すことができる ID はアプリケーションだけだと思われがちです。

Creator Assertions Working Group（CAWG）は、署名アプリケーションの ID とともに、組織が自身のクリエイタとしての ID を暗号技術によって表明できる ID アサーションのフレームワークを開発しています。これにより、サードパーティのアプリケーションやマネージドサービスが署名を実行する場合でも、パブリッシャ、メディア企業、ブランド、代理店などをコンテンツのクリエイタとして識別できます。

アプリケーションの ID と組織の ID を分離することで、企業は制作ワークフローをより柔軟に構築できます。また、コンテンツの署名に使用するツールを変更したり、外部に委託したりした場合でも、クリエイタとしての識別情報を維持できます。

本番環境での C2PA 署名に必要な要件

概念実証（PoC）の段階を超えて導入する場合は、署名を支えるインフラストラクチャについても考慮する必要があります。

本番環境への実装では、以下の管理が必要になる場合があります。

• C2PA 専用証明書の発行と更新
• 署名用秘密鍵の保護
• アクセス制御と認証
• 適合性テストと法的なオンボーディング
• C2PA 仕様の変更への対応
• サポート対象のメディア形式 
• 監視、可用性、運用保守
• 既存のアプリケーションやコンテンツパイプラインとの統合

これらの機能を社内で構築し、運用することもできます。この方法では署名環境をチームが直接管理できますが、そのセキュリティ、保守、継続的な適合性の維持についても自社で責任を負うことになります。

もう 1 つの選択肢は、マネージド署名プラットフォームです。署名機能を API 経由で提供しながら、証明書ライフサイクル管理、安全な鍵の保護、継続的な適合性の維持をプラットフォーム側で処理できます。

どの方法が適しているかは、組織のセキュリティモデル、利用可能な専門知識、統合要件、トラストインフラを自社で運用する方針によって異なります。

DigiCert Content Trust Manager による C2PA 署名の統合

DigiCert Content Trust Manager を使用すると、開発者は API を通じて、既存のアプリケーションやコンテンツワークフローに C2PA 署名を統合できます。証明書管理、鍵の保護、適合性への対応は、プラットフォーム側で行われます。

統合を構築する前に試してみたいチームは、Web インターフェイスからコンテンツをアップロードし、Content Credentials を付与することもできます。自動化された本番ワークフローでは、API を利用することで、既存のアプリケーションやコンテンツパイプラインに署名処理を組み込むことができます。

一般的な統合は、以下の 4 つのステップで行います。

1. API キー（またはクライアント認証証明書）と Account ID を DigiCert ONE アカウントから取得します。
2. 署名するファイルを選択します。 Content Trust Manager は、さまざまな画像、動画、音声、文書形式をサポートしています。 
3. Content Trust Manager API にファイルを送信します。 その際、パブリッシャ、クリエイタ、編集者など、表明する制作上の役割を指定します。 
4. Content Credential が付与された署名済みファイルを受け取ります。 

以下は、1 つのコマンドで実行する例です。

この API 呼び出しによって署名済みコンテンツが返されるため、アプリケーションは保護されたファイルを保存し、既存のワークフロー内で引き続き処理できます。

DigiCert Content Trust Manager が署名インフラを運用するため、開発チームは PKI、証明書、秘密鍵、適合性を自ら管理するのではなく、アプリケーションに検証可能な来歴情報を追加することに注力できます。

デジサートは、統合オプションや機能を継続的に拡充しています。最新の API、サポートされる形式、実装ガイダンスについては、最新の製品ドキュメントをご確認ください。

すべての Content Credential にトラストを組み込む

C2PA は、コンテンツの来歴を検証可能にするための標準的な手段を提供しますが、それぞれの Content Credential を支えるトラストは、署名サービスの構築方法と運用方法に左右されます。C2PA の普及が進むにつれ、チームは目に見えるバッジだけでなく、来歴情報の安全性と相互運用性を確保し、長期にわたって信頼性を維持するためのインフラについても検討する必要があります。

デモを見ることで、DigiCert Content Trust Manager が、信頼できる C2PA 署名とコンテンツの来歴管理を大規模にどのように支援するかをご確認いただけます。