2026年EU AI Act Article 50 自前運用の適合確認
2026年8月2日からEU AI Act Article 50が適用され、罰則は最大1,500万ユーロまたは全世界売上高の3％です。開放型モデルや自前サーバーでの運用は、Article 50の自動的な免除理由になりません。先にproviderとdeployerを判定し、その後に機械可読マーク、利用者向けの可視ラベル、証拠保存を分けて検証するのが安全です。(EU委員会のArticle 50 FAQ)
このページは、EUユーザー向けに自前運用の開放型モデル、生成AIアプリ、AIエージェントを提供する技術責任者、プラットフォームエンジニア、コンプライアンス担当者向けです。macOSの開発環境やクラウドMacを使い、複数モデルと配信経路を隔離検証したいチームにも適しています。
※本稿は法律意見ではありません。providerまたはdeployerに該当するか、例外や猶予が実際の製品に適用されるかは、契約、ブランド表示、提供地域、利用者との関係を含めてEU AI Actに詳しい法務へ確認してください。
「開放型モデルだから対象外」という判断を捨てる
EU AI Act上のproviderは、AIシステムを開発する、または開発させたうえで、自らの名称や商標でEU市場に提供、もしくは使用開始させる自然人・法人などです。EU域外に所在するproviderでも、AIシステムの出力がEUで使用される場合は対象になり得ます。deployerは、自らの権限の下でAIシステムを業務目的に利用する主体です。(EU AI Act本文のArticle 3およびArticle 50)
自前運用の現場では、次の3点を順番に記録します。
- モデル自体を誰が開発し、アプリケーション部分を誰が開発または委託したか。
- API、画面、生成物を誰の名称や商標で外部へ提供しているか。
- 利用規約、管理画面、公開承認、出力配信を誰が実際に管理しているか。
例えば、第三者が公開した開放型モデルを自社サーバーへ導入し、自社ブランドのチャットサービスとしてEU利用者に提供する場合、モデルのライセンスが開放型であることだけでは自社のprovider該当性を否定できません。一方、顧客企業が自社の権限下で社内向けに利用する構成では、その顧客側にdeployerの論点が生じます。具体的な契約関係を見ずに、片方へ固定するのは危険です。
Article 50(1)、(2)、(4)を混ぜない
実装担当者が最初に分けるべきなのは、同じ「透明性」でも義務の対象と担当主体が異なる点です。
- Article 50(1)：人がAIシステムと直接対話している場合、providerは原則としてAIとの対話であることを開始時点から明確に知らせます。AIエージェントやチャットボットが対象になり得ます。機械間通信や人との直接接触がないバックグラウンド処理は、この対話開示の範囲外となり得ます。
- Article 50(2)：合成されたテキスト、画像、音声、動画などについて、providerが有効で信頼でき、堅牢かつ相互運用可能な機械可読マークを付け、AI生成または加工された出力として検出できる状態にします。
- Article 50(4)：deployerがdeepfakeや、公共の関心事項を知らせる目的で公開するAI生成・加工テキストを扱う場合、人が認識できる形で明確に開示します。機械可読マークだけでは、この利用者向け開示を代替できません。(Article 50の義務を整理したEU委員会FAQ)
ここでの失敗は、「画面にAI生成と表示したので完了」「ファイルにメタデータを入れたので完了」と一方だけを確認することです。provider側の検出可能性と、deployer側の人向け表示は別の受入条件にします。
12月2日の猶予はシステム単位で確認する
Article 50は2026年8月2日から適用されます。欧州委員会のFAQが示す限定的な猶予は、2026年8月2日より前に市場へ投入された既存システムについて、生成AIコンテンツのマークと検出に関するArticle 50(2)の義務を2026年12月2日までに満たす扱いです。生成物の公開日やモデルの学習日だけを見て判断するものではありません。
確認用の証拠は、次の順でそろえます。
- システムの初回市場投入日、またはEUでの使用開始日を確定します。
- その日付を示すリリース記録、契約、公開承認、サービス開始ログを保存します。
- 2026年8月2日以後に追加した新機能、別ブランド、別モデルを既存システムと分けます。
- 出力の生成日と、利用者へ公開した日を別々に保存します。
- 2026年8月2日より前に生成されたコンテンツを、遡及的に一律再ラベルする義務と混同しません。
既存システムのAPIを大幅に変更し、新しいブランドで再提供した場合などは、単純な「旧システム」と扱えない可能性があります。猶予を使う場合でも、対象範囲と期限をシステムごとに法務承認しておくべきです。
注意：2026年12月2日はArticle 50の全義務を延期する日ではありません。対話時の通知、deepfakeの可視開示、公共の関心事項に関する公開テキストの扱いまで一括して待てるわけではありません。
出力分類を先に決め、例外を広げない
Article 50(2)の検証では、まず出力形式を分けます。
- テキスト：利用者に表示する回答、記事、説明文。
- 画像・音声・動画：ダウンロード、画面表示、SNSや動画基盤への配信対象。
- ソースコード：生成後に開発者だけが扱うのか、最終利用者へ説明や製品機能として表示するのか。
- 機械間出力：人へ露出せず、別システムが自動処理するだけか。
- 編集補助：標準的な編集支援にとどまるか、内容自体を生成・大幅加工しているか。
欧州委員会のFAQとガイドラインは、短い数字・記号・文字列、ソースコード、人に露出しない機械間出力、閉じた工業・製品開発環境で最終出力にならないものなどを対象外となり得る例として挙げています。また、標準的な編集補助にも境界があります。B2Bや工業用途の例外も狭い条件付きであり、サービス全体へ拡大解釈してはいけません。(Article 50の適用範囲と例外に関するEU委員会資料)
特にソースコードは「常に不要」と決めず、次を記録します。
- 生成物が人に読まれる画面へ表示されるか。
- そのコードが製品の最終成果物として公開されるか。
- AI出力に説明文、コメント、ドキュメントが混在していないか。
- 機械間処理の後に、人向けの結果へ変換されないか。
機械可読マークと可視ラベルを別々に受け入れる
技術選定では、メタデータ、透かし、署名、配信時のラベルを同じ機能として扱わないことが重要です。
メタデータは、ファイルやコンテナに出所情報を埋め込む方法です。検出器や配信基盤が読み取れる一方、再エンコードやメタデータ削除で失われる可能性があります。
透かしは、画像、音声、動画などの信号へ情報を埋め込む方法です。変換後の残存性を確認できますが、コンテンツ形式、圧縮率、編集操作によって検出性が変わります。
利用者向けラベルは、画面上の文言、アイコン、音声告知などです。人が見聞きしてAI生成や加工を理解するための仕組みで、Article 50(4)のdeployer側開示に関係します。
受入条件は、少なくとも次の5項目に分けます。
- 有効性：正しい生成物を検出できるか。
- 信頼性：誤検出と見逃しを把握できるか。
- 堅牢性：圧縮、切り出し、再エンコード後も機能するか。
- 相互運用性：別の検出ツールや配信先でも読み取れるか。
- 技術的実現可能性：対象形式、処理時間、既存配信経路に組み込めるか。
欧州委員会は、生成コンテンツのマークとラベルについてCode of Practiceを適合手段の一つとして認めています。ただし、署名していない事業者も別の適切な手段で適合性を説明する必要があり、Code of Practiceへの準拠だけで最終的な適合が確定するわけではありません。(AI生成コンテンツの透明性に関するCode of Practiceの評価資料)
合格条件を分岐で決める
現場の判断を止めないため、次の条件分岐をリリース審査に組み込みます。
-
EU向けに自社名で提供し、開発または開発委託も自社が管理している場合
→ provider候補としてArticle 50(1)、(2)、(5)を確認します。外部サービスの利用者へ表示する場合は、deployer側の(4)も確認します。 -
自社の権限下で業務利用するだけで、外部提供者ではない場合
→ deployerとして、deepfake、公共の関心事項に関する公開テキスト、対話対象の有無を確認します。 -
2026年8月2日より前に市場投入された既存システムであることを証明できる場合
→ Article 50(2)のマークと検出だけを2026年12月2日までの移行項目として管理します。それ以外の義務は別に確認します。 -
初回提供日やブランド変更の証拠が欠けている場合
→ 猶予を前提にせず、現行版を2026年8月2日適用のシステムとして扱い、法務承認が得られるまで公開範囲を止めます。 -
メタデータまたは透かしが変換後に失われる場合
→ 「ラベル表示だけで代替する」のではなく、形式別に別方式を追加し、検出失敗時の公開停止または再処理へ戻します。 -
本番環境でしか検証できない場合
→ 固定バージョンの隔離環境を先に用意します。モデル更新、エクスポート、変換、検出を本番で試行するのは避けます。
保存すべき証拠と5段階の実装手順
Article 50の適合確認は、ラベルの画面だけでは終わりません。少なくとも次の手順で、要求事項と実装を結び付けます。
-
対象台帳を作成する
モデル、推論サービス、AIエージェント、公開画面、API、配信先を一覧化します。provider、deployer、共同利用者、最終承認者も記録します。 -
日付と版を固定する
初回提供日、使用開始日、モデル版、推論サーバー版、ラベル実装版、公開日を保存します。Gitのタグだけでなく、デプロイ承認と設定変更の記録も残します。 -
出力サンプルを分けて生成する
テキスト、画像、音声、動画、ソースコード、機械間出力を分けます。公開前、変換後、配信後の3段階で同じサンプルを検出します。 -
変換と障害を再現する
圧縮、サイズ変更、再エンコード、形式変換、第三者基盤へのアップロードを想定します。マーク消失、検出失敗、重複ラベル、表示崩れを失敗例として保存します。 -
公開承認と回帰試験を結び付ける
どの担当者が何を確認し、どの条件で公開を許可したかを残します。モデル更新や配信経路の変更時は、同じサンプル群で再試験します。 -
公共の関心事項に関するテキストを別管理する
人による実質的な内容確認、編集権限、事実確認、最終的な法的責任者を記録します。校正やスペルチェックだけでは、ガイドラインが示す人によるレビューや編集管理にはなりません。
管理画面、監査ログ、版管理を一つの流れにまとめる場合は、ProxyMacのコンソール案内で運用単位を確認できます。
隔離検証はローカル機器とクラウドMacを使い分ける
Article 50対応では、単にモデルを起動できる環境より、固定版を並行稼働できる環境が重要です。必要な作業は、複数モデルからの一括生成、元ファイルの保存、変換処理、検出ツールの実行、失敗サンプルの再現、修正版の回帰確認です。
ローカル機器を選ぶ条件は、長期間同じ構成を使い、物理インターフェースや社内データを直接扱い、継続的な高負荷処理を自社で管理する場合です。一方、短期の並行検証、複数担当者の遠隔作業、既存環境を止めずに別版を試す場合は、クラウドMacの方が切り分けやすい場合があります。
現在の共有サーバーや単一のローカル機器だけで進めると、次の問題が起きやすくなります。
- 本番版と検証版のモデルやライブラリが混ざる。
- 変換前の元ファイルと配信後のファイルを比較できない。
- 検出失敗時に、どの設定が原因だったか追跡できない。
- 担当者の端末差で、同じ出力を再現できない。
実際の利用可能構成、納期、契約期間、マーク保持の実測値は、公開されたProxyMacの情報または個別の再現試験で確認してください。出典のない処理速度、成功率、料金、地域、対応形式を適合根拠として記載するべきではありません。短期の隔離環境が必要な場合は、ProxyMacの料金案内で契約単位を確認し、検証期間と回帰試験の回数を先に決めます。
まとめて合格にしないための最終確認
- providerとdeployerの役割を、名称、契約、管理権限で説明できる。
- Article 50(1)、(2)、(4)の担当主体と実装を分けている。
- 2026年12月2日の猶予を、既存システムのArticle 50(2)だけに限定している。
- テキスト、画像、音声、動画、ソースコードの扱いを個別に確認している。
- メタデータや透かしの保持を、変換後と配信後に検証している。
- 利用者向けの可視ラベルを、機械可読マークの代替にしていない。
- モデル版、実装版、生成日時、公開日時、承認者を保存している。
- 検出失敗やラベル消失を含むテスト記録を残している。
- 本番とは分離した環境で、固定版と回帰試験を運用できる。
- Code of Practiceを使うか、代替手段で同等性を説明する方針がある。
よくある判断のずれ
自前サーバーだからproviderではないという判断は、提供者名と市場投入の事実を見落とします。逆に、モデルを利用しているだけの組織を直ちにproviderと断定するのも適切ではありません。
可視ラベルを付けたからArticle 50(2)も満たすという判断も誤りです。人向け表示と機械検出は別の目的で設計されます。
人が一度目を通したから公共向けテキストの例外になるという判断にも注意が必要です。内容の実質確認、編集権限、最終責任がなければ、単なる形式確認にとどまる可能性があります。
FAQでは、Article 50の適用範囲、開放型モデル、2026年12月2日の猶予、ソースコード、証拠保存を別々に扱っています。役割判定と技術検証を一枚の「AI生成ラベル対応」として処理せず、システム台帳から分解して記録することが、後から説明できる運用につながります。
既存のローカル環境や共有サーバーで、モデル版、変換処理、検出結果を安定して再現できない場合は、無理に本番へ組み込まない方が安全です。まずは期間を区切ったクラウドMacの隔離環境で、生成、エクスポート、変換、検出、回帰試験を分けて実施し、合格した構成だけを本番へ戻す方が、現在の環境で起きる版の混在、再現不能、ロールバックの遅れを抑えやすくなります。短期の検証環境を検討する場合は、ProxyMacのコンソールで運用条件を確認してください。
最終更新：2026年8月3日。日付、適用範囲、12月2日の限定的な猶予、出力例外、罰則は、欧州委員会のArticle 50 FAQ、2026年7月20日公開のガイドライン、Code of Practice関連資料、AI Act本文を照合しています。
