製品が EU AI Act Article 50 の対象となる場合、機械可読ウォーターマークだけで対応が完了するわけではありません。ProviderとDeployerには、それぞれ異なる義務があります。Deployerの義務の一部では、特別なツールなしに人が認識できる、明確なラベルが引き続き必要です。この規則は 2026年8月2日 から適用されます。限定的な 2026年12月2日 までの猶予期間は、8月2日より前に市場に投入されたシステムに対するArticle 50(2)のマーキング義務だけを対象とします。欧州委員会の公式FAQとガイダンスページでは、この点が明確に説明されています。European Commission FAQ Guidelines page
この記事はエンジニアリング向けのチェックリストであり、法的助言ではありません。目的はより限定的です。公式の適用範囲、日付、例外、レビュー基準を、実際にリリースできるプロダクト制御へ落とし込むことです。このチェックリストでは、Article 50(1)、Article 50(2)、およびArticle 50(4)の生成コンテンツに関する義務に焦点を当てます。感情認識システムおよび生体カテゴライゼーションシステムに関する、別個のArticle 50(3)の義務は扱いません。このワークフローに依拠する前に、役割、適用範囲、例外について、資格を有する法律専門家に確認してください。
EU AI Act Article 50：誰が何をするのか？
欧州委員会の現在のガイダンスでは、作業を主体ごとに分けています。Providerは、AIとの直接的なやり取りに関する通知と、合成出力への機械可読マーキングを担当します。Deployerは、ディープフェイクのラベル付けと、一部の公益性のあるテキストのラベル付けを担当します。Guidelines page Quick facts
| 主体 | トリガー | 公式ガイダンスの説明 |
|---|---|---|
| --- | --- | --- |
| Provider | 自然人とのAIによる直接的なやり取り | AIとやり取りしていることが明らかな場合を除き、最初のやり取りから本人に通知する。 |
| Provider | 合成されたテキスト、画像、音声、動画の出力 | 適用範囲の制限と例外に従い、機械可読マークを付け、検出可能性を確保する。 |
| Deployer | ディープフェイクへの接触 | 遅くとも最初に接触する時点までに、明確で認識可能な開示を行う。 |
| Deployer | 人によるレビューまたは編集上の管理を経ていない公益性のあるテキスト | テキストがAI生成またはAI操作されたものであることを明確にラベル付けする。 |
この区分は重要です。Providerによる非表示のマークだけでは、Deployerの視認可能な開示義務を自動的に満たすことにはならないからです。欧州委員会は、DeployerがProviderによって埋め込まれた機械可読マークだけに依拠することはできないと述べています。European Commission FAQ
重要な日付
Article 50の中核的な義務は 2026年8月2日 から適用されます。欧州委員会のFAQでは、Article 50(2) のマーキング義務について、2026年12月2日 までの限定的な猶予期間が追加されています。ただし、これは2026年8月2日より前に市場に投入された生成AIシステムに限られます。8月2日より前に生成されたコンテンツには遡及的なラベル付けは必要ありませんが、欧州委員会は可能な場合にはラベル付けを推奨しています。European Commission FAQ Quick facts
法律上、関連する日付は2つあります。ロールアウト計画では、社内ポリシー上の3つ目の日付を設定する場合があります。
Providerが構築すべきもの
Providerにとって、直接的なやり取りに関する規則は比較的単純です。システムが自然人との実際の双方向のやり取りであり、そのやり取りが明らかにAIによるものではない場合、最初のやり取りの開始時点から本人に通知する必要があります。欧州委員会は、「明らかである」という例外は狭く解釈すべきだと述べています。European Commission FAQ
より難しいのは出力のマーキングです。合成されたテキスト、画像、音声、動画を生成するシステムのProviderは、機械可読マークを適用し、検出可能性を確保する必要があります。同じFAQでは、ソースコード、人への露出を伴わない一部のマシン間出力、一部のクローズドループ型の産業用途または製品開発用途など、一部の出力は適用範囲外または免除対象であるとも説明されています。European Commission FAQ
ここで、チームは通常この作業を単純化しすぎます。以下は、欧州委員会のチェックリストを逐語的に再現したものではなく、実装上の解釈です。Providerの義務は「ウォーターマークを有効にする」ことではありません。次のことです。
すでにAI bill of materials→でProvider、ランタイム、出力経路を追跡している場合は、そのインベントリに出力ごとのマーキング適用範囲と検証結果を追加してください。そうでなければ、後からArticle 50への対応を証明することがはるかに難しくなります。
Deployerが引き続き行うべきこと
Deployerには別の問題があります。Deployerの義務は、視認可能で、文脈に依存し、接触を基準とします。人が結果を見たり読んだりする場合、ファイル内の非表示マークだけでは不十分です。
ディープフェイクについて、欧州委員会は、遅くとも最初に接触する時点までに開示を行い、特別なツールなしに理解できる必要があると述べています。公益性のあるテキストについては、実質的な人によるレビューまたは編集上の管理を経ていない限り、Deployerはコンテンツにラベルを付ける必要があります。欧州委員会は、スペルチェックや文法の修正だけでは該当しないと明示しています。European Commission FAQ
ここでは、検出技術よりもワークフロー設計の方が重要です。
Deployerが問うべきことは「AIが関与したか？」ではありません。問うべきなのは「私たちは人々に何を見せたのか、そしてその特定のアセットについてどのようなレビュー証拠があるのか？」です。
*キャプション：Article 50はProviderとDeployerの義務を分けています。機械可読マークと視認可能なラベルは、異なる問題を解決します。*
ウォーターマークだけでは不十分な理由
現在のProvider向けドキュメントを見るだけでも、単一レイヤーのソリューションが弱い理由が分かります。
OpenAIは、C2PAメタデータによってコンテンツに来歴情報を持たせられると説明しています。同時に、メタデータは削除されたり、アップロードやダウンロード中に失われたり、リサイズやスクリーンショットなどの変換によって壊れたりする可能性があるとも述べています。2026年7月29日時点で、OpenAIのドキュメントは、対応画像向けのSynthIDと公開検証プレビューによる第2のレイヤーについて説明しています。OpenAI provenance OpenAI verify
Googleの公開されているSynthID textドキュメントも、別の角度から同じ点を示しています。テキストウォーターマーキングの仕組みを説明する一方で、徹底的な書き換えや翻訳の後には検出器の信頼度が大幅に低下する可能性があると述べています。この制限はArticle 50にとって重要です。Deployerの義務には公益性のあるテキストが含まれ、編集済みテキストは例外ではなく通常の状態だからです。SynthID Text docs
ElevenLabsは現在、SynthIDとC2PAを音声の透明性スタックの一部として位置付けており、無料のtext-to-speech生成にまずウォーターマークを導入し、その後対象範囲を拡大し始めたと説明しています。これは有用な実装上の証拠ですが、下流のすべてのプラットフォームがシグナルを保持することの証明ではなく、あくまでProviderが報告したロールアウト状況です。ElevenLabs SynthID post
最近の研究も同じ結論に至っています。Article 50の構造的ギャップに関する論文は、コンプライアンスを事後的なラベル付けに還元することはできないと論じています。来歴フレームワークに関する論文は、来歴メタデータとウォーターマーキングは異なる証明上の問題を解決すると論じています。ファセット型アトリビューションに関する論文は、「AIが使われた」という大まかな開示では、システムがどこで、どのように、どのようなレビューの下で介入したのかを捉えられないと論じています。実務的なエンジニアリング上の解釈は、より限定的です。Article 50への対応には、技術的なマーキングだけでなく、ワークフローの証拠も必要です。 Structural gaps paper Provenance framework Faceted attribution paper
実践的なエンジニアリングチェックリスト
1. すべての公開出力経路をインベントリ化する
公開向けのテキスト、画像、音声、動画を生成できる各システムを一覧化します。モデル名だけで終わらせないでください。出力を提供するサーフェス、公開を管理する主体、出力が自然人に届くかどうかを含めます。欧州委員会によるProviderとDeployerの区分は、モデルブランドではなく、システムと接触のレベルで適用されます。European Commission FAQ
最低限必要な項目：
2. コード上でProviderの義務とDeployerの義務を分離する
アセットに汎用的な `ai_disclosure=true` フラグを1つ付けて、対応完了としないでください。次のように、別々の制御が必要です。
この分離によって、マーク付きファイルに視認可能なラベルがなお必要だった理由や、資格を有するレビュアーが実質的な承認を行ったため、公益性のあるテキストアセットが免除対象となった理由を証明できます。
3. 実質的な人によるレビューの基準を定義する
欧州委員会は、実質的なレビューには関連する知識と専門的判断が必要であり、編集上の管理とは、責任を負う主体がテキストの内容を承認、変更、または拒否できることだと述べています。スペルチェックは明示的に除外されています。European Commission FAQ
CMSのレビューステップで次の質問に答えられない場合：
レビュー例外に依拠するための証拠は不完全です。
4. 生成の成功だけでなく、変換後の保持をテストする
機械可読マークについて、エンジニアリング上の問いは「埋め込めるか」だけではありません。「アセットが実際にたどる経路で、そのマークは保持されるか」です。
少なくとも次をテストしてください。
OpenAI、Google、ElevenLabsはいずれも堅牢性について説明していますが、あらゆる変換後に完全なシグナルが残るとは主張していません。OpenAI provenance SynthID overview ElevenLabs SynthID post
5. オペレーターが実際に実行できる検証経路を維持する
オープンソースのC2PAスタックは、現在の実際のワークフローで利用できるほど活発です。C2PAの適合性プログラムと信頼リストは稼働しており、`c2patool`でマニフェストを検査または追加でき、`c2pa-rs`のリリースも2026年7月時点で継続しています。C2PA conformance c2patool docs c2pa-rs releases
これにより、オペレーター向けに単純な経路を用意できます。
6. 例外を、属人的な記憶ではなく明示的なポリシーとして扱う
欧州委員会のガイダンスでは、条件に依存する複数の除外および例外が説明されています。ソースコード、人への露出を伴わず、専らマシン間処理を目的とする出力、そして説明されている状況における一部のクローズドループ型の産業用途または製品開発用途を、適用範囲外として挙げています。また、支援的な標準編集、公益性のあるテキストの実質的なレビュー、明らかに芸術的、創造的、風刺的、架空、または類似のディープフェイクについても区別しています。これらは一律の免除ではありません。特定の出力経路が関連条件を満たす理由を文書化してください。European Commission FAQ
これらの例外が人の記憶だけに依存していると、内容が変化してしまいます。意思決定ツリー、ポリシー表、またはリリースチェックリストに組み込み、各例外を許可されるコンテンツ経路に紐付けてください。
現在のツールがすでに役立つ領域
OpenAI、Google、ElevenLabsは現在、チームに実際の構成要素を提供していますが、それぞれに限界があります。
OpenAI
2026年7月29日時点で、OpenAIは自社が C2PA Conforming Generator Product であり、ChatGPT、Codex、APIを通じて生成された対応画像にSynthIDを適用し、OpenAI生成画像向けの研究プレビュー検証ツールを提供していると説明しています。また、検出方法は完全ではなく、シグナルがないことは、その画像がAI生成ではない証明にはならないとも述べています。OpenAI provenance OpenAI verify
GoogleはSynthIDを、画像、音声、テキスト、動画向けのメディア横断型ウォーターマーキングシステムとして位置付けています。テキストのドキュメントは特に具体的です。ウォーターマーキングはlogits processorとして実装されていますが、翻訳や徹底的な書き換えによって検出が弱まる可能性があります。これは、過度な保証を避けるべき場所を示してくれるため有用です。SynthID overview SynthID Text docs
ElevenLabs
2026年7月29日時点で、ElevenLabsは、同社の音声検出器がまずSynthIDウォーターマークを確認し、ウォーターマークが見つからない場合はAI Speech Classifierにフォールバックすると説明しています。これは概念的に適切なパターンです。まず来歴シグナルを使い、次により弱い推論シグナルを使います。ElevenLabs Audio Detector documentation
C2PAとオープンソース検証
C2PAは、来歴メタデータのための最も実用的なオープン標準であり続けています。公式仕様、適合性プログラム、コマンドラインツールが揃っているため、本番パイプラインで検証ゲートをサポートできます。C2PA home C2PA spec c2patool docs
想定してはいけないこと
次のことを想定しないでください。
これらは、誤ったコンプライアンス上の安心感を生む失敗パターンです。
まとめ
EU AI Act Article 50を簡潔にエンジニアリングの観点から読むと、次のようになります。Providerは合成出力を検出可能にし、Deployerはそれを人々にとって明らかなものにする必要がある場合があります。
だからこそ、適切な実装はバッジではなくチェーンです。
このように構築すれば、Article 50はエンジニアリング上の制御面になります。「ウォーターマークを追加した」とだけ考えると、別個のDeployer義務を見落とす可能性があります。このアーキテクチャはコンプライアンスの証拠を支援できますが、法的な適用範囲を決定したり、コンプライアンスを保証したりするものではありません。
FAQ
Providerの機械可読マークは、Deployerのディープフェイクラベル義務を満たしますか？
いいえ。欧州委員会のFAQでは、DeployerはProviderの機械可読マークだけに依拠することはできないと説明されています。ディープフェイクには、接触する本人に対する明確で認識可能な開示が引き続き必要です。European Commission FAQ
人によるレビューによって、公益性のあるテキストがラベル付けの対象外となるのはいつですか？
自然人が関連する知識を用いてコンテンツの内容を意図的にレビューした場合、または編集主体が実質的な根拠に基づいてテキストを承認、変更、拒否できる場合に限られます。スペルや文法の修正などの形式的な確認は該当しません。European Commission FAQ
Article 50(2)では、ソースコードやマシン間出力は適用範囲に含まれますか？
必ずしもそうではありません。欧州委員会のFAQでは、ソースコード、人への露出を伴わない一部のマシン間出力、一部のクローズドループ型の産業用途について、条件付きで適用範囲外または免除対象として挙げています。European Commission FAQ