EU AI Actと加州AI透明性法2026：開発者が変える機能

8月2日を境に変わる実装範囲

100万人。この数字を、カリフォルニア州で公開される生成AIサービスの利用規模として見たとき、単なるアクセス解析の指標では済まなくなります。一方、欧州連合では2026年8月2日から、チャットボットとの対話やAI生成コンテンツの識別に関する透明性義務が適用されます。では、同じ画像生成機能を欧州とカリフォルニア州で提供する場合、どの機能を共通化し、どこを分ける必要があるのでしょうか。

本稿では、EU AI ActとカリフォルニアAI透明性法2026を、法令の要約ではなく、生成、保存、書き出し、配信、検証という実際の製品フローで比較します。なお、以下は公開情報に基づく技術・運用整理であり、個別案件への法律意見ではありません。

欧州委員会は、EU AI Act第50条の透明性義務が2026年8月2日から適用されると案内しています。AIシステムの提供者には、生成または改変した音声、画像、動画、テキストを機械可読な形式で識別可能にする対応が求められ、一定のケースではデプロイヤー側に利用者向けの明確な表示が必要です。(digital-strategy.ec.europa.eu)

適用日と対象範囲

EU AI Act Article 50 合規

EU AI Act Article 50 合規で最初に確認すべきなのは、「モデルを作った会社」だけが対象なのかという点です。実際には、モデルや生成AIシステムを自社名で市場に提供するプロバイダーと、業務用途でシステムを利用してコンテンツを公開するデプロイヤーの双方に異なる義務が発生します。

生成AIシステムのプロバイダーは、出力にAI生成またはAI改変であることを検出できる機械可読マークを組み込む必要があります。音声、画像、動画、テキストでは、同じタグを付ければ終わりではなく、形式ごとに保存方法と破損時の扱いを設計します。

デプロイヤーは、ディープフェイクに該当する画像、音声、動画を公開する場合、人工的に生成または改変されたことを明確に表示します。また、公共の利益に関する情報提供を目的としたAI生成テキストにも、一定の表示義務があります。人間による確認や編集が入る場合の扱いは、生成工程と公開工程の記録で説明できるようにします。(digital-strategy.ec.europa.eu)

2026年7月時点の欧州委員会の案内では、2026年8月2日より前に市場投入された生成AIシステムについて、Article 50(2)の機械可読マークと検出に限り、2026年12月2日までの移行期間が示されています。過去に公開済みのコンテンツを一律に遡って表示する義務とは別の話なので、システムの投入日とコンテンツ生成日を別々に管理してください。(digital-strategy.ec.europa.eu)

加州 AB 853 AI透明性法

カリフォルニア州のAB 853は、既存のCalifornia AI Transparency Actの適用開始を2026年8月2日に延期しました。対象となる生成AIシステムの作成者、コード作成者、その他の提供者のうち、カリフォルニア州内で一般公開され、月間訪問者または利用者が100万人を超えるサービスには、利用者が無料で使えるAI検出ツールが求められます。(leginfo.legislature.ca.gov)

この検証ツールは、画像、動画、音声、またはそれらの組み合わせが、自社の生成AIシステムで作成・改変されたものかを評価し、コンテンツ内で検出できる来歴データを出力できる必要があります。つまり、単に「AIらしさ」を推定する検出器ではなく、自社システムの出力と来歴情報を確認する窓口として設計する必要があります。

AB 853には段階的な追加義務もあります。大規模オンラインプラットフォームに関する規定は2027年1月1日から、対象となる撮影機器メーカーの潜在的開示に関する規定は2028年1月1日から始まります。2026年8月2日の対応だけで、将来のプラットフォーム連携や機器由来のコンテンツまで完了したことにはなりません。(leginfo.legislature.ca.gov)

注意： 「AI Transparency Act」という名称だけで対象範囲を判断しないでください。月間利用規模、一般公開の有無、システムを作った主体、プラットフォームとして配信する主体を分けて判定する必要があります。

開発者が分けて考えるべき義務

EU AI ActとカリフォルニアAI透明性法2026は、どちらもAI生成物の透明性を重視しますが、要求される機能は同一ではありません。

この表は法令上の違いを実装判断に置き換えた本稿の整理です。欧州向けには「出力を識別できること」と「人に見える形で知らせること」を分け、カリフォルニア州向けには「自社生成物を検証できること」と「来歴情報を返せること」を分けて設計するのが実務的です。

たとえば、画面に「AI生成」と表示するだけでは、EUの機械可読マークを満たすとは限りません。逆に、ファイルに来歴情報を埋め込んだだけでは、ディープフェイクを閲覧する利用者への明確な表示が不足する可能性があります。

モダリティ別の表示設計

テキスト

チャットボットでは、会話開始時と継続中の画面で、AIシステムと対話していることを利用者が理解できるようにします。API経由で生成した記事や市場情報を公開する場合は、誰が編集したか、AI出力をどこまで修正したかをCMSの履歴に残すと、公共利益に関する文章の判断を説明しやすくなります。

画像と動画

画像や動画は、見た目の透かしと埋め込み型の来歴情報を併用します。前者は人が見て判断するための表示、後者はソフトウェアが検証するための情報です。リサイズ、再圧縮、切り抜き、字幕付与で来歴情報が失われる場合は、書き出し時に警告を出し、検証結果を監査ログへ保存します。

音声

音声では、可視的な透かしが使えません。そのため、音声ファイルのメタデータ、配信APIのレスポンス、プレーヤー上の表示を組み合わせます。音声を動画へ変換した時点で、元の生成情報が引き継がれるかをテスト対象に含めてください。

latent disclosure

潜在的開示、つまりlatent disclosureは、利用者が常に目で確認するラベルではなく、コンテンツに付随し、簡単には取り除けない情報を指します。AB 853では、対象となる提供者が生成した画像、動画、音声などに、技術的に可能な範囲で、恒久的または極めて除去しにくい開示を含める考え方が示されています。(leginfo.legislature.ca.gov)

生成パイプラインの改修手順

1. 対象地域と役割を棚卸しします。
   利用者の所在地、公開URL、契約主体、モデル提供者、アプリ提供者、コンテンツ公開者を一覧化します。EU向けのデプロイヤー義務と、カリフォルニア州向けの提供者義務を同じ担当者にまとめると、責任範囲が曖昧になりやすいためです。

2. 出力形式ごとの来歴データを定義します。
   画像、動画、音声、テキストについて、生成元システム、生成時刻、モデル識別子、編集履歴、検証結果をどこまで保持するか決めます。個人情報や秘密情報をそのまま埋め込まないよう、利用者向け情報と監査用情報を分離します。

3. 生成直後に機械可読マークを付与します。
   ダウンロード時ではなく、生成サービスの出力段階でマークを付けます。後工程で付与すると、保存前の一時ファイル、共有リンク、外部連携APIから流出する出力を把握できないためです。

4. 変換と配信の破損テストを行います。
   PNGからJPEG、動画の再圧縮、音声の形式変換、SNS向けの短縮、字幕の追加など、実際の利用者が行う操作を再現します。マークや潜在的開示が失われた場合は、再付与、警告、配信停止のどれを選ぶかを決めます。

5. 利用者向けの表示を別レイヤーで実装します。
   「AI生成」「AI改変」「AIとの対話」といった表示は、ファイル内の技術情報とは別に、画面上で読めるようにします。特にディープフェイクや公共利益に関する文章では、表示位置、文字サイズ、表示時間をプロダクトと法務で確認します。

6. GenAI latent disclosure 検証ツールを公開します。
   カリフォルニア州で対象となる場合、検証ツールは有料プランの付加機能ではなく、対象利用者が無料で使える導線として提供します。自社出力かどうか不明な場合も、「判定不能」「来歴情報を検出できない」と返せる設計にし、推測結果を断定表示しないことが重要です。

7. 証拠と例外を保存します。
   生成リクエスト、出力ハッシュ、マーク付与結果、変換履歴、検証ツールの応答、表示設定、手動上書きの理由を保存します。保存期間は契約、プライバシー、業界規制との整合性を確認し、必要以上の個人データを残さないようにします。

欧州委員会は、Article 50への対応を示す任意の実務規範も公開しています。自社方式を採用する場合でも、Article 50の透明性ガイドラインと実務規範を比較し、なぜ自社の方法が検出可能性と表示義務を満たすのかを文書化してください。(digital-strategy.ec.europa.eu)

実務上の経験： 最も多い失敗は、生成APIのテストではマークが残っているのに、CDN、画像最適化、動画変換、外部ストレージを経由すると消えるケースです。生成機能単体ではなく、公開ボタンを押してから利用者が保存するまでを1本のテストとして扱います。

工数と優先順位

改修量は、モデルの種類よりも出力経路の数で大きく変わります。画像だけをダウンロード提供するサービスと、画像・動画・音声をAPI、管理画面、共有リンクで配信するサービスでは、必要な検証箇所が異なります。

優先順位は次の順が現実的です。

• 第1段階：対象地域、提供者・デプロイヤーの役割、公開規模の判定
• 第2段階：生成直後のマーク付与と、画像・動画・音声の変換テスト
• 第3段階：利用者向け表示、ディープフェイク表示、AI対話の告知
• 第4段階：無料検証ツール、来歴情報の返却、判定不能時の処理
• 第5段階：サプライヤー契約、監査ログ、透明性報告、将来のプラットフォーム連携

第三者モデルを利用している場合は、モデル提供者が付与したマークを自社の要件と同一視しないでください。自社アプリが再編集や形式変換を行うなら、最終出力の責任と検証可能性を自社側でも確認する必要があります。

越境サービスの差分ケース

欧州とカリフォルニア州の双方で利用できる画像・動画生成サービスを想定します。利用者はWeb画面から画像を生成し、動画化して共有リンクを発行します。モデル自体は第三者が提供し、サービス運営会社は出力を保存してCDNから配信します。

この場合、EU向けには、生成物を機械可読に識別できる状態で作成し、ディープフェイクに該当する動画には画面上の表示を付けます。サービス内にチャット形式のプロンプト支援があるなら、利用者がAIと対話していることも明示します。

カリフォルニア州向けには、対象規模に達しているかを判定したうえで、無料の検証ツールから自社生成物の判定と検出された来歴データを返せるようにします。さらに、2027年の大規模オンラインプラットフォーム規定を見据え、他社から受け取った来歴情報を破棄せず、配信時に検出できるデータモデルを採用します。AB 853は、対象プラットフォームについて2027年1月1日から、標準化された来歴データの検出などを求めています。(leginfo.legislature.ca.gov)

このケースで一つの共通基盤にまとめやすいのは、生成物ID、出力ハッシュ、編集履歴、来歴データ、検証結果の保存です。一方、EUの利用者向け表示とカリフォルニア州の無料検証ツールは、目的と画面設計が違うため、同一UIに無理に押し込めないほうが運用しやすくなります。

水印だけでは足りない理由

第一に、画面上の透かしは切り抜きや再編集で見えなくなるため、機械による検出手段になりません。第二に、来歴データがあっても、配信先がそれを削除すれば検証できなくなります。第三に、自社モデルの出力だけを記録し、第三者モデルの出力や人手編集後のファイルを記録しないと、公開時点の説明ができません。

さらに、AI検出器の確率判定を法令上の来歴確認と混同する問題もあります。一般的な検出器は、未知のモデル、圧縮、短い音声、部分編集に弱い場合があるため、検証ツールでは「自社の来歴情報を確認できたか」と「AIらしいと推定したか」を別の結果として表示してください。

2026年8月2日前の確認リスト

• EU域内で市場投入または利用開始するAIシステムを特定したか
• プロバイダーとデプロイヤーの責任分担を契約と仕様書に記載したか
• 画像、動画、音声、テキストごとに機械可読マークを検証したか
• ディープフェイクと公共利益に関するAIテキストの表示条件を決めたか
• チャットボット利用者へのAI対話表示を実装したか
• カリフォルニア州で月間100万人超の公開サービスに該当するか確認したか
• 無料のAI検証ツールが自社生成物と来歴データを扱えるか確認したか
• 潜在的開示が変換・配信後も残るかテストしたか
• 2027年、2028年の追加義務を製品ロードマップに登録したか
• 生成、変換、表示、検証、例外処理の証拠を保存できるか確認したか

複数地域向けの実装環境を整える場合、短期の検証用マシンを都度購入するより、必要な期間だけMac環境を確保して、SDK検証、変換テスト、CI/CDの再現テストを分離する方法もあります。SpinMacの日本語トップページでは、Macを使った開発・検証環境の選択肢を確認できます。費用や利用期間を比較する場合は、料金ページでプロジェクト単位の運用条件を確認してください。

現在のWindowsやLinux中心の環境だけで対応すると、外部ストレージや変換ツールの差分が増え、検証環境の再現、権限管理、短期プロジェクト終了後の機材処分が負担になりがちです。特に画像・音声・動画の書き出しを複数OSで確認する案件では、個別購入した端末を抱えるより、SpinMacで必要なMac環境を期間限定でレンタルし、プロダクト・エンジニアリング・法務が同じ検証手順を共有するほうが、環境差分と保守負担を抑えやすくなります。

最後に、この記事のチェックリストを保存し、2026年8月2日までに適用範囲と機能差分の合同レビューを設定してください。法令の対象判定、契約責任、表示文言は、製品担当者だけで決めず、工程を再現できる開発担当者と法務・コンプライアンス担当者が一緒に確認することが重要です。