EU AI法第50条は2026年8月2日に施行されました。これは透明性に関する章であり、システムの高リスク性に関わらず、一般的なエンジニアリングチームに最も影響しやすい条項です。焦点は、人々が機械と対話していることを認識できるかどうかにあります。
報道ではモデルプロバイダー側の対応が注目されがちです。たとえば、Anthropicによる第50条(2)の行動規範への署名や、Claudeの透かし機能はプロバイダー側の話です。しかし、そのAPIを呼び出し、出力を自社製品に組み込む場合、あなたは別の役割・別の義務を負います。モデルプロバイダーが準拠していても、あなた自身の義務が自動的に満たされるわけではありません。
この記事では、APIを提供・運用するチームの視点で第50条を整理します。各条項の要求、プロバイダーとデプロイヤーの責任分界、免除規定の実務的な意味、そしてその判断をApidogとCIで検証可能な契約に変換する方法を扱います。
5つの条項と対象者
| 条項 | 対象者 | 要求事項 |
|---|---|---|
| 50条(1) | プロバイダー | 人と直接対話するシステムは、AIであることを明確にする必要がある。ただし、合理的に情報に精通した人にとって明白な場合は除く。 |
| 50条(2) | プロバイダー | 生成AIシステムは、合成された音声・画像・動画・テキストを、人工的に生成または操作されたものとして検出可能な機械可読形式でマークする必要がある。 |
| 50条(3) | デプロイヤー | 感情認識システムおよび生体認証分類システムは、それらに晒される人々へ通知する必要がある。 |
| 50条(4) | デプロイヤー | ディープフェイクを開示する必要がある。公共の利益に関する事項について一般市民へ情報提供するために公開されるAI生成テキストも開示対象となる。 |
| 50条(5) | 両方 | 開示は、最初の対話または露出時までに、明確かつアクセスしやすい方法で行う必要がある。 |
重要なのは、プロバイダーとデプロイヤーの区別は企業規模ではなく、システムごとの役割で決まることです。
- 生成AIシステムを構築し、EU市場に投入する: プロバイダー
- 他社のAIシステムを自社の権限で利用する: デプロイヤー
- Claudeを自社製品へ組み込み、独自ブランドで提供する: スタックの異なる箇所で両方の立場になり得る
まずは、提供しているAPI・UI・ワークフローごとに役割を明文化してください。
50条(2): 機械可読なマーキング
50条(2)は、合成音声・画像・動画・テキストを生成するAIシステムのプロバイダーに向けた要件です。出力を、人工的に生成または操作されたものとして検出可能な機械可読形式でマークする必要があります。
ただし、法律は完璧な技術を求めているわけではありません。実装では、次の条件を考慮することが求められます。
- コンテンツ種別ごとの特性と制約
- 実装コスト
- 一般に認められた最新技術
- 技術的実現可能性
- 有効性、相互運用性、堅牢性、信頼性
このため、実務では主に次の2種類が使われます。
- テキスト: 統計的透かし（ウォーターマーキング）
- ファイル: 署名付きC2PAマニフェスト
どちらも完全ではありません。しかし、第50条の文言は、こうした現実的な制約を前提にしています。
ツール開発チームに関係する免除
標準的な編集のための補助機能
標準的な編集を補助する機能は対象外です。
例:
- スペルチェッカー
- コードフォーマッター
- 入力中のオートコンプリート
- JSONのキー順序を整えるツール
入力データを実質的に変更しない場合
与えられた入力データを実質的に変更しないシステムも、50条(2)の対象外です。
一方で、実務では境界が曖昧です。たとえば、段落のトーンを変更するリライト機能は、スペルチェックとは言えません。判断をアーキテクトだけで確定せず、法務チームとレビュー可能な基準を作る必要があります。
実装で管理する項目
モデルプロバイダーがマーキングを行っている場合でも、APIチームは少なくとも次を管理してください。
ai_models:
- id: claude-model-a
output_marking: true
marking_effective_from: "2026-08-02"
- id: legacy-model-b
output_marking: pending
fallback_allowed: false
特に、コストやレイテンシーの都合でモデルフォールバックを行う場合は注意が必要です。マーク付きモデルからマークなしモデルへ静かに切り替わると、保証が崩れます。
CIでは、解決後のモデルIDを検証対象にしてください。
pm.test("許可されたモデルが解決されている", () => {
const model = pm.response.headers.get("x-ai-model");
pm.expect([
"claude-model-a"
]).to.include(model);
});
50条(4): 多くのプロダクトで重要になる条項
デプロイヤーには、主に2つの開示義務があります。
ディープフェイクの開示
ディープフェイクを構成する画像・音声・動画を生成または操作するシステムを展開する場合、そのコンテンツが人工的に生成または操作されたものであることを開示する必要があります。
芸術、風刺、フィクションなどでは扱いが軽くなります。ただし、生成コンテンツの存在を、作品の表示や享受を不必要に妨げない方法で開示する必要があります。
公共の利益に関するAI生成テキストの開示
公共の利益に関する事項について一般市民へ情報を提供する目的で公開されるテキストを、AIが生成または操作する場合も開示対象です。
ただし、次の条件を満たす場合は免除規定があります。
- 人間によるレビューまたは編集上の管理がある
- 自然人または法人が公開に対する編集上の責任を負う
ここで重要なのは、「人がざっと確認した」だけでは不十分になり得ることです。免除規定に依拠するなら、誰が編集責任を持つのか、どの工程でレビューするのか、後から証明できるプロセスを持つ必要があります。
たとえば、以下のような記録を残せるようにします。
{
"article_id": "policy-update-2026-08",
"ai_assisted": true,
"review_status": "approved",
"reviewed_by": "editor@example.com",
"reviewed_at": "2026-08-03T09:30:00Z",
"editorial_owner": "Example Media Ltd."
}
一方、製品コピー、サポートマクロ、コードコメント、社内要約は、通常「公共の利益に関する事項について一般市民に情報を提供するために公開されるテキスト」には該当しません。第50条(4)は、すべての公開テキストを対象にする規定ではありません。
50条(1)・50条(5): チャットUIとAPI契約のルール
50条(1)は比較的シンプルですが、実装から漏れやすい要件です。
人と直接対話するシステムは、利用者がAIシステムと対話していることを認識できるように設計する必要があります。ただし、合理的に情報に通じ、観察力があり、慎重な人物にとって明白な場合は除かれます。
「明白である」に依存するのはリスクがあります。
-
AIアシスタントと明記されたチャットウィジェット: 判断しやすい - 人間名を名乗り、人間らしい文体で応答し、AI表示がないサポートチャネル: リスクが高い
50条(5)は、開示のタイミングと形式を定めます。
- 最初の対話または露出時までに表示する
- 明確である
- 識別可能である
- アクセス可能である
利用規約に埋め込むだけでは、最初の対話時の開示にはなりません。
APIレスポンスに開示情報を含める
自社APIが他社のチャットUIを支える場合、UI上の表示はAPI利用者が実装します。そのため、APIは「この応答がAI生成であるか」を契約として返す必要があります。
たとえば、ヘッダーとレスポンスボディの両方で表現できます。
HTTP/1.1 200 OK
Content-Type: application/json
X-AI-Generated: true
X-AI-Model: claude-model-a
{
"message": {
"role": "assistant",
"content": "配送状況を確認します。"
},
"disclosure": {
"ai_generated": true,
"label_required": true,
"model": "claude-model-a"
}
}
OpenAPI定義にも含めてください。
components:
schemas:
Disclosure:
type: object
required:
- ai_generated
- label_required
properties:
ai_generated:
type: boolean
description: 応答がAIシステムによって生成または操作されたかを示す
label_required:
type: boolean
description: 利用者向けUIでAI開示が必要かを示す
model:
type: string
description: 解決されたモデルID
これは、APIにAI開示を追加する際の中心的な設計です。UIの表示ルールだけにせず、下流のコンシューマーが実装できるAPI契約にします。
期日と、まだ変動しているもの
2026年8月2日
第50条が施行されました。これは確定日です。
2026年6月10日
AI生成コンテンツの透明性に関する行動規範が公開されました。欧州委員会とAIボードは、これをコンプライアンスを実証するための適切な自主的ツールとして確認しました。7月末までに約190組織が署名しており、Anthropicもその一つです。
2026年12月2日
2026年5月に暫定合意されたAIオムニバスパッケージを通じ、2026年8月2日より前に市場投入された生成システムが50条(2)の機械可読マーキング要件を満たすための延長期限として広く報じられています。
この日付は変動する可能性があります。見出しだけを前提に実装計画を固定せず、弁護士と最終テキストを確認してください。
また、古いモデルIDを利用している場合は、プロバイダーによる後付け対応に依存する可能性があります。実際にどのモデルが選ばれたかを、実行時・テスト時の両方で確認することが重要です。
不遵守の代償
第50条違反は、第99条の罰金階層では第2層です。
- 前会計年度の全世界年間売上高の3%
- または1,500万ユーロ
- いずれか高い方
資格のある中小企業（SME）には、いずれか低い方が適用されます。
参考として、禁止された行為には最大3,500万ユーロまたは7%、当局へ誤解を招く情報を提供した場合には750万ユーロまたは1%の罰金が定められています。透明性違反は最上位の制裁ではありませんが、全世界売上高の3%を軽視することはできません。
法的判断をエンジニアリング作業に変える
法的解釈を担うことはエンジニアリングチームの仕事ではありません。しかし、法務判断の結果を、再現可能かつ検証可能な実装に落とすことはチームの仕事です。
APIチームが所有すべき作業は、次の4つです。
1. システムごとの役割を記録する
インターフェースごとに、プロバイダーかデプロイヤーかを記録します。
systems:
support-chat:
role: deployer
ai_provider: third-party
content-generation-api:
role: provider
output_types:
- text
この1行が、適用される条項を判断する起点になります。
2. モデル設定にマーキング状態を持たせる
モデルID、マーキング有無、有効化日、フォールバック可否を設定として管理します。
models:
claude-model-a:
machine_readable_marking: true
enabled_from: "2026-08-02"
allowed_for_public_content: true
legacy-model-b:
machine_readable_marking: false
allowed_for_public_content: false
3. 開示をUIではなくAPI契約にする
モデル出力を返すすべてのAPIパスに、開示情報を含めます。
対象には以下を含めてください。
- 通常レスポンス
- ストリーミングレスポンス
- キャッシュヒット時のレスポンス
- 非同期ジョブの結果
- エラー後に返す部分的な生成結果
4. 開示をテストする
開示フィールドは、リファクタリングやレスポンス変換で消えやすい項目です。仕様・実行時・CIの3層で検証してください。
例として、APIテストでは次をアサートします。
pm.test("AI生成フラグが返される", () => {
const body = pm.response.json();
pm.expect(body).to.have.property("disclosure");
pm.expect(body.disclosure).to.have.property("ai_generated");
pm.expect(body.disclosure).to.have.property("label_required");
});
pm.test("AI応答では開示ヘッダーが true", () => {
pm.expect(pm.response.headers.get("x-ai-generated")).to.eql("true");
});
OpenAPI仕様を検証する方法で仕様側を検証し、APIアサーションで実行時の保証を追加できます。
Apidogでは、モデルID、開示ヘッダー、レスポンスボディの開示フィールド、OpenAPIスキーマをテストシナリオとして管理できます。その後、CIでapidog-cliを実行し、保証が崩れたときにビルドを失敗させます。
すでにGitHub ActionsでAPIテストを実行しているチームなら、既存ジョブへ追加できます。
- name: Run AI disclosure contract tests
run: apidog-cli run --scenario ai-disclosure-contract
環境を構築しながら確認したい場合は、Apidogをダウンロードしてください。
より広いガバナンスプロセスを整備する場合は、APIガバナンス必須チェックリストや、大規模チーム向けの最適なAPIガバナンスツールも参照できます。
よくある質問
EU圏外にいても第50条は適用されますか？
適用される可能性があります。EU AI法は、システムをEU市場に投入するプロバイダー、および特定の状況でシステム出力がEU内で使用されるEU圏外のプロバイダー・デプロイヤーにも適用されます。法人の所在地だけでは判断できません。
モデルプロバイダーが出力をマークしています。私は準拠していますか？
いいえ。プロバイダーが50条(2)を満たしていることは、プロバイダー自身の義務が果たされていることを意味します。デプロイヤーとしての50条(1)、50条(4)、50条(5)に基づく義務は別です。
Anthropicも、「あなたの製品とサービスに第50条が何を要求するかを個別に評価してください」と明示しています。
公開するAI生成テキストすべてにラベルを付ける必要がありますか？
いいえ。50条(4)が対象とするのは、公共の利益に関する事項について一般市民に情報提供するために公開されるテキストです。また、人間によるレビューまたは編集上の管理があり、誰かが編集上の責任を負う場合には免除規定があります。
利用規約にあるチャットボットの免責事項で十分ですか？
いいえ。50条(5)は、最初の対話時までに、明確かつ識別可能な形式で情報を提供することを求めています。
50条(4)におけるディープフェイクとは何ですか？
実在する人、物、場所、出来事に似ており、偽って本物のように見える生成または操作された画像・音声・動画です。芸術、風刺、フィクション作品には、より軽い開示義務が適用されます。
罰金はいくらですか？
第99条に基づき、前年度の全世界年間売上高の3%または1,500万ユーロのいずれか高い方までです。資格のある中小企業（SME）の場合は、いずれか低い方が適用されます。
行動規範に署名すべきですか？
署名は任意で、主にプロバイダーを対象としています。署名すれば、コンプライアンスを実証するための認められた経路が得られます。署名しない場合、当局はアプローチを個別に評価します。これは技術的な判断ではなく、法的な判断です。
まとめ
第50条は短く、多くのAPIチームに直接関係する部分はさらに限定されます。
多くの場合、あなた自身がウォーターマークを埋め込むプロバイダーではありません。一方で、次の責任を負う可能性は高いでしょう。
- 利用者がAIと対話していることを伝える
- 編集上の責任を伴わずに公開する、公共の利益に関するAI生成テキストを開示する
- 最初の接触時までに、その開示を行う
実装上の要点は明確です。
- システムごとの役割を把握する
- 利用モデルとマーキング状態を管理する
- 開示をAPI契約に含める
- CIで継続的に検証する
ポリシーを文書化するだけでは保証になりません。レスポンス契約とテストに落とし込んで初めて、変更に耐えられるコンプライアンスになります。
Top comments (0)