EU AI Act（規則(EU) 2024/1689）は、生成AIが生み出す「合成コンテンツ（synthetic content）」の社会実装を前提に、透明性を制度要件として組み込んだ。その中核の一つがArticle 50（Transparency obligations for providers and deployers of certain AI systems）である。提供者（provider）には、生成AIの出力を「人工的に生成・操作されたもの」として機械可読かつ検知可能な形でマーキングする義務が、運用者（deployer）には、ディープフェイクや一定のAI生成テキストを自然人に対して明確に開示する義務が課される。

本稿は、2026年8月2日に適用開始とされるArticle 50の要件を前提に、欧州委員会が2025年12月17日に公開した「AI-generated content transparency Code of Practice」第1次ドラフトの設計思想（多層マーキング、検知、アイコン/ラベル開示）を読み解き、エンジニアリング組織が取り得る実装戦略を提示する。なお本稿は法的助言ではなく、技術設計の観点から整理するものである。

Article 50の射程: providerの「機械可読マーキング」とdeployerの「明確な開示」

Article 50は、透明性義務を「誰が（provider/deployer）」「何に対して（出力コンテンツ種別）」「どの手段で（マーキング/ラベル）」課すかで整理している。実装設計では、まず責務分界を誤らないことが重要である。

  • provider側（Article 50(2)）: 生成AI（GPAIを含む）が生成する合成音声・画像・動画・テキストを、機械可読な形式で、かつ「人工的に生成/操作されたもの」として検知可能にマーキングする。技術的に可能な範囲で、有効性（effective）、相互運用性（interoperable）、頑健性（robust）、信頼性（reliable）を求め、コンテンツ種別の限界・実装コスト・一般に認められたstate of the art（技術標準に反映され得る）を考慮すると規定している。
  • 例外（同条文内）: 「出力を実質的に変更せず、編集支援や付随的な補助機能にとどまる」タイプのAIについては、マーキング義務の適用範囲が異なり得る。提供者は「生成」と「補助」を技術的に区別できる設計が必要になる。
  • deployer側（Article 50(4)）: ディープフェイクを開示し、また「公共の利益に関する事項について公衆に情報提供する目的」で公開され、かつ人間レビュー/編集責任がないAI生成・操作テキストを開示する（例外や文脈の扱いは条文・ガイダンスに依存する）。実装上は、公開フローと責任主体（編集責任の有無）をワークフローに落とし込む必要がある。

結論として、Article 50は「単一の透かしを入れる」では完結しない。providerは機械可読マーキングと検知の両輪を、deployerは自然人向けの表示（可視ラベル）を、それぞれ製品・配信・運用プロセスへ統合しなければならない。

Code of Practice（第1次ドラフト）が示す実装思想: 多層マーキングとアイコン/ラベル

欧州委員会が公開した第1次ドラフトは、Article 50(2)/(4)に対し、産業側が自律的に採用可能な実装パターンを「Commitment / Measure」として提示している。そこでは、現時点で単一技術で要件を満たすことは困難であり、複数の技術を組み合わせる多層アプローチが繰り返し強調される。

provider向け（マーキング/検知）では、特に次が重要である。

  • 多層の機械可読マーキング（Measure 1.1）: マークは複数層であり、例えば「ウォーターマークがメタデータ識別子を参照する」といった層間参照で頑健性を上げる設計が推奨される。
  • メタデータ埋め込み可能な形式（Sub-measure 1.1.1）: 画像・動画・文書のようにメタデータを保持できる形式では、コンテンツの来歴（provenance）と生成AIシステムの署名をメタデータへ付与し、操作種別（prompting/editing/generation等）も記録し、デジタル署名する方針が示される。
  • メタデータを安全に埋め込みにくい領域（Sub-measure 1.2.1）: テキスト等は改変・転載・再配布でメタデータ保持が難しいため、デジタル署名されたmanifest（provenance certificate）として「認証可能な出力」を提供し、第三者へ提示できるようにする、という方向性が示される。

deployer向け（開示）では、アイコンとラベルの共通化が核になる。ドラフトは、ディープフェイク開示に関し、少なくとも初回露出時点までに「明確で区別可能」な形で開示すること、リアルタイム動画等のモダリティに応じて提示方法を調整することを要求している。また、公共の利益に関するAI生成・操作テキストの開示では、識別と例外判定（人間レビュー/編集責任の有無等）を内部プロセスとして整備し、過度な自動化に依存せず人間の監督を組み込むことが明記される。

技術要件を分解する: メタデータ、不可視マーク、可視ラベルの「三層」を別物として設計する

実装を難しくするのは、同じ「透かし/ラベル」でも目的が異なる点である。設計上は、少なくとも次の三層を別コンポーネントとして扱うのが安全である。

  • Layer A: 来歴メタデータ（provenance metadata）: 「誰が/何が/いつ/どの操作で生成・編集したか」を機械可読に表現し、デジタル署名で改ざん検知する。画像/動画/文書は埋め込み、テキストは外部manifest（証明書）として提供する設計が現実的である。相互運用を狙うなら、C2PAのようなコンテンツ真正性（Content Credentials）仕様に寄せることが実務上の合理性を持つ（ただし規制が特定仕様を直接指名するとは限らない）。
  • Layer B: 変換に耐える不可視マーク（robust/invisible marking）: 圧縮、リサイズ、クロップ、再エンコード、スクリーンキャプチャ等を経ても検知できるマークを目指す。強い頑健性は画質/音質劣化や誤検知とトレードオフであり、モダリティごとに「耐えるべき変換」を仕様化し、劣化許容を合意する必要がある。
  • Layer C: 自然人向けの可視ラベル（icon/label disclosure）: 誤認防止と説明責任のためのUI要件であり、機械可読性とは別軸である。露出時点で明確・区別可能であること、アクセシビリティ（視覚/聴覚/認知特性）を満たすこと、配信チャネルごとに一貫することが求められる。

三層は「どれか一つ」ではなく、相互補完である。メタデータは剥がされ得る。不可視マークは完全ではない。可視ラベルは転載で失われ得る。従って、組織としては「剥がされても別層で拾う」「改変されても別層で検知する」設計を採るべきである。

実装アーキテクチャ案: 生成パイプラインに「出力証明」と「開示UI」を組み込む

ここでは、生成AIプロダクト（API/アプリ）を提供する組織が、Article 50(2)/(4)に跨って対応するための参照アーキテクチャを示す。

1. 生成時（provider責務）: 出力に対する署名とマーキング

  • 出力ID（Output ID）: すべての生成・編集出力に一意IDを付与し、ログ/監査/証明書発行の基点にする。
  • 署名用キー管理: HSM/KMSで署名鍵を保護し、鍵ローテーションと失効（revocation）を設計に含める。署名検証に必要な公開鍵配布（JWKS等）も含める。
  • provenance表現: 画像/動画/文書は埋め込みメタデータへ、テキスト等は外部manifestとして発行する。manifestには少なくとも「モデル/バージョン」「操作種別」「生成時刻」「入出力ハッシュ（必要に応じて）」「ポリシー適用（例: 安全フィルタ）」を含め、署名する。
  • 多層マーク: メタデータと不可視マークを層間参照させる（例: 不可視マークにOutput IDの冗長符号化を埋め込み、メタデータにOutput IDと署名を保持する）。

2. 配信時（deployer責務）: ラベル提示と例外判定のワークフロー化

  • 配信チャネル別のラベルSDK: Web、モバイル、動画プレイヤー、SNS投稿、音声配信など、露出面ごとにラベル提示コンポーネントを提供し、一貫した表示を強制する。
  • 例外判定（編集責任/人間レビュー）: 「人間がレビューし編集責任を負ったか」をフロー上の状態として明示し、状態に応じてラベル義務や文言を切り替える。監査ログ（誰がいつレビューしたか）を保持する。
  • ディープフェイク分類の内部統制: 自動分類に依存し過ぎず、人間の監督とエスカレーションを組み込む。創作/風刺/フィクション等の文脈は誤分類が起こりやすく、ガイドラインと事後監査が必要である。

3. 検知・検証（横断）: 第三者検証と社内監査の両方に耐える

  • 検証API: 受領したコンテンツ（ファイル/URL）に対し、メタデータ署名検証、不可視マーク検知、manifest照合を行い、結果を返す。誤検知/見落としを前提に、信頼度（confidence）や根拠（どの層で検知したか）を返す。
  • 耐変換テスト: 圧縮率、解像度、クロップ率、再エンコード、字幕合成、音声ミキシング等、実運用で起きる変換をベンチマークとして固定し、リリースごとに回帰テストを行う。
  • プライバシー/最小化: provenanceに個人情報やセンシティブな生成指示が含まれないよう、公開されるメタデータと内部監査ログを分離する。

実装戦略: 「規制対応プロジェクト」ではなく「継続運用の品質システム」として設計する

2026年8月2日（適用開始想定）までに「とりあえず透かしを入れる」だけでは、相互運用性や検知、配信チャネルでの開示まで含む要件に耐えにくい。現実的には、次の順で段階導入するのがよい。

  1. Phase 0（今すぐ）: 出力ID、監査ログ、レビュー責任の状態管理を整備する。これは可視ラベル/証明書/検知の土台である。
  2. Phase 1（ファイル系から）: 画像・動画・文書など「メタデータ埋め込み可能」な出力に対し、署名付きprovenanceメタデータを実装する。検証APIを同時に作る。
  3. Phase 2（テキストの証明書）: テキスト出力について、署名付きmanifest（provenance certificate）発行と提示UI（リンク/検証画面）を実装する。転載耐性は限定的であるため、配信チャネル側の開示と組み合わせる。
  4. Phase 3（不可視マークの強化）: モダリティ別に耐えるべき変換を定め、不可視マークを追加/改善する。品質劣化や誤検知をKPI化し、継続改善する。
  5. Phase 4（エコシステム連携）: パートナーやプラットフォーム（配信/編集/保存）と相互運用を検証し、標準・実装の更新（state of the art）に追従する。

重要なのは、透明性を「コンテンツの属性」ではなく「生成・配信・編集・再配布までのライフサイクル」として扱うことである。マーキングが残らない経路を特定し、どの層で救うかを設計し、運用で回す。これがArticle 50の実装設計である。

FAQ

Article 50は「透かしを入れれば終わり」なのか？

終わりではない。条文は機械可読マーキングに加えて「検知可能」であることを要求し、さらにdeployerに対しては自然人向けの明確な開示（ラベル）を要求する。従って、生成パイプライン、検証、配信UI、監査プロセスの統合が必要である。

メタデータが消える（転載/再エンコード）場合はどうするのか？

消える前提で多層化する。メタデータに加え、不可視マークや外部manifest（証明書）を組み合わせ、どの層が失われても別層で検知・説明できる状態を目指す。加えて、配信チャネル側の可視ラベルは最初の露出における誤認防止として重要である。

可視ラベルはproviderが付与すべきか、deployerが付与すべきか？

責務は役割で分かれる。providerは出力の機械可読マーキングと検知可能性を担い、deployerは公開・配信の文脈で自然人向けの開示を担う。実装としては、providerがラベルSDKや検証情報を提供し、deployerの配信面へ組み込ませる設計が現実的である。

「編集支援（assistive function）」は対象外になるのか？

一律に対象外とは限らない。条文は「出力を実質的に変更しない補助機能」に触れており、適用範囲は機能の性質に依存する。プロダクトとしては、生成・編集・補助を区別可能にし、どの出力が透明性義務の対象かをログと設定で追跡できるようにしておくべきである。

参考文献