2026年 カリフォルニア州AB 853のAI検出ツール設計と検収

「AI検出ツールを公開すれば、カリフォルニア州の要件は満たせる」と考えるのは危険です。実際には、画像や動画をアップロードできるだけでは足りず、URL検査、API呼び出し、system provenance dataの出力、個人情報の扱い、latent disclosureとの互換性まで一つの検証経路として設計する必要があります。

この記事では、カリフォルニア州AB 853のAI検出ツールをこれから実装・改修するプロダクト担当者、エンジニアリング責任者、CTO、プライバシー担当者に向けて、2026年8月2日の運用開始を前提に、どこを確認し、何を証拠として残すべきかを整理します。法令の適用判断そのものは、必ず専門家に確認してください。

まず押さえるべきAB 853の位置付け

AB 853は、California AI Transparency Actの運用開始日を2026年1月1日から2026年8月2日へ変更した法律です。対象となるのは、カリフォルニア州内から公開利用でき、月間訪問者または利用者が100万人を超える生成AIシステムを作成・コード化・提供する「covered provider」です。違反については、1件につき5,000ドルの民事制裁金が定められ、違反日ごとに個別の違反として扱われます。(leginfo.legislature.ca.gov)

要件の原文は、カリフォルニア州議会のAB 853法文で確認できます。ただし、AB 853が追加した大規模オンラインプラットフォームや生成AIホスティングプラットフォームの規定は、主に2027年以降の運用開始です。2026年8月2日に焦点を当てるチームは、まずcovered provider向けの検出ツールと生成コンテンツの開示機能を分けて確認してください。(leginfo.legislature.ca.gov)

対象チームを判断する3つの質問

最初から実装に入ると、対象外の社内ツールに過剰対応したり、逆に第三者API経由のサービスを見落としたりします。次の順番で整理すると、担当範囲を決めやすくなります。

1. 自社が生成AIシステムを作成・コード化・提供していますか。
   単に外部モデルを利用する企業ユーザーと、独自の生成AIサービスを公開する事業者では位置付けが異なります。

2. カリフォルニア州から公開利用できますか。
   州内利用者を技術的に遮断していない場合、利用者の所在地、公開範囲、契約形態を法務と確認します。

3. 月間利用者または訪問者が100万人を超えていますか。
   この数値はAB 853におけるcovered providerの定義に含まれる重要な判定要素です。集計期間、ログイン利用者と訪問者の重複除外、地域別集計の根拠を保存してください。(leginfo.legislature.ca.gov)

第三者モデルを組み込むアプリ、画像・音声生成を提供する企業、APIだけを販売するモデル提供者では、誰が「作成・コード化・提供」に該当するかが変わり得ます。迷う場合は、サービス構成図と責任分界表を作成してから法務に渡す方が、口頭説明より判断しやすくなります。

AI検出ツールの必須経路を比較する

実装前に、利用者が実際に使う入口を分解します。カリフォルニア州AB 853のAI検出ツールでは、ブラウザー画面だけを用意してAPI利用者を置き去りにする設計は避けるべきです。

法律上のAI検出ツールは、利用者がコンテンツをアップロードするか、オンラインコンテンツへのURLを提供でき、さらにウェブサイトを訪問せずに呼び出せる技術、つまりAPIなどを支援する必要があります。無料で利用できることも要件に含まれます。(leginfo.legislature.ca.gov)

第一歩：入力経路を先に固定する

「AI detection tool API 怎么做」に相当する検索をする開発者が見落としやすいのは、APIを後から画面機能に付け足すことです。最初に、画面とAPIが同じ検出エンジン、同じ判定基準、同じ出力スキーマを使う構成にします。

最低限、次の項目を決めてください。

• 受け付けるファイル形式と最大容量
• URL取得時のタイムアウト、リダイレクト回数、認証ページの扱い
• APIの認証方式、レート制限、再試行条件
• 検出不能、provenance dataなし、形式不正を区別する状態コード
• 結果の有効期限と再検査の条件

「判定できない」を「AIではない」と表示してはいけません。検出対象外、データなし、署名不正、取得失敗を別の状態として返すことが、誤認を減らす基本です。

第二歩：system provenance dataだけを出力する

system provenance dataは、特定の利用者と合理的に結び付けられない出所情報です。生成に使われた機器、システム、サービスの種類や、コンテンツの真正性に関する情報が中心になります。一方、個人情報や、特定利用者と結び付けられる固有の機器・システム・サービス情報はpersonal provenance dataに当たり得ます。(leginfo.legislature.ca.gov)

結果画面では、次のように階層を分けると安全です。

• 利用者向けの要約：生成または変更の有無、検出された方式、検証状態
• system provenance data：サービス名、生成システムの種類、真正性に関する情報
• 非表示または除外する情報：個人識別につながる識別子、端末固有情報、不要な位置情報
• 監査用の内部記録：処理時刻、検出エンジンの版、エラーコード、削除処理の結果

個人情報を含む出所データをそのままエクスポートすると、検出機能が新たな情報拡散経路になります。ユーザーが見たい「どのシステムで作られたか」と、運営側が保有する「誰の端末から送られたか」は、同じJSONに入れない方が管理しやすいです。

注意：system provenance dataを返せることと、コンテンツが本物だと断定できることは別です。署名がない、途中で編集されている、形式変換で情報が失われている場合は、判定の限界を結果画面に明示してください。

第三歩：latent disclosureとmanifest disclosureを分ける

latent disclosureは、人が通常見ただけでは分からない形でコンテンツに存在する開示情報です。manifest disclosureは、利用者が見て理解できる表示です。この2つは代替関係ではありません。

covered provider向けの生成コンテンツでは、latent disclosureに提供者名、生成AIシステムの情報、生成または変更の時刻、固有識別子などを含め、恒久的または極めて除去しにくい形にする考え方が示されています。また、その開示情報は自社の検証ツールで検出でき、広く認識された標準と互換性を持つ必要があります。(leginfo.legislature.ca.gov)

検収では、次の順番を一つの閉ループとして試します。

1. 生成システムで画像、音声、動画を作成する。
2. latent disclosureが付与されたファイルを取得する。
3. 形式変換、圧縮、軽微な編集を行う。
4. 自社のAI検出ツールにアップロードする。
5. system provenance dataを表示する。
6. disclosureが壊れた場合は、壊れたことを「未生成」と誤表示しない。
7. 生成時の記録と検出結果を照合する。

この検証がないまま「水印を付けた」と説明すると、潜在的な開示を付与できても、検出ツール側で読み取れない状態が残ります。

第四歩：アップロードとURLの留留を設計する

AI検出ツールのプライバシー設計では、保存期間を一律に決めるより、データの種類ごとに処理目的を分けます。特に確認したいのは、次の4種類です。

• 利用者アカウントや認証に必要な情報
• アップロードされた画像、動画、音声
• URLと取得した本文・メディア
• APIの監査ログ、エラー情報、フィードバック

「AI検出工具隐私留存要求」に相当する実務上の答えは、必要最小限の収集、短い一時保存、処理後の削除、監査用の匿名化記録です。アップロード内容をモデル改善に使う場合は、検出処理とは別の目的として、同意、通知、拒否方法、利用範囲を整理してください。

URL検査では、取得先のページに個人情報が含まれている可能性があります。HTML全体を長期保存せず、検出に必要なメディアとprovenance dataだけを処理し、取得失敗やタイムアウトの記録にはURLのクエリ部分をそのまま残さない設計が現実的です。

第五歩：フィードバックとログを分離する

法律上、検出ツールの有効性に関するユーザーフィードバックを集め、改善の試みに反映する仕組みが求められます。これは、利用者が任意に送る誤判定報告と、システムが自動的に収集するアップロードデータを同一視してよい、という意味ではありません。(leginfo.legislature.ca.gov)

フィードバック機能には、次の項目を用意します。

• 結果IDと判定状態
• 利用者が選べる誤判定理由
• 任意入力のコメント
• 元ファイルを再利用する場合の明確な同意
• 連絡を希望するかどうか
• 改善サイクルに反映した記録

結果IDだけを保存しても、後から検証できる場合があります。元ファイルを保存しない方針なら、検出エンジンの版、入力形式、処理時刻、エラー分類など、個人情報を含まない再現用メタデータを残します。

公開前のAB 853検収マトリクス

以下は、法令適用を断定する表ではなく、本站の分析として作成する実装確認用のたたき台です。社内では、各行に責任者、実施日、証拠の保存場所、未達時の対応期限を追記してください。

「結果が返るのに不合格」になりやすい例

検出結果が一度でも返れば完成、という判断は危険です。特に次の状態は、機能デモでは見逃されます。

• ブラウザー画面はあるが、APIから呼び出せない
• URLを受け付けるが、取得したページを長期間保存している
• system provenance dataと個人情報を同じ結果欄に表示している
• latent disclosureを自社ツールで検出できない
• 圧縮・形式変換後に「AIではない」と誤表示する
• 誤判定の報告を受け付けても、改善記録が残らない
• 料金やアカウント作成を理由に、不要な個人情報を要求する

特に「検出なし」と「非生成」を同じ表示にする設計は、利用者の意思決定を誤らせます。少なくとも、検出済み、検出情報なし、対象外、検証不能、取得失敗を区別してください。

EU AI Act Article 50へ能力を広げる場合

EU向けにも展開する場合、機械可読なマーキング、生成・変更の検出、深層偽造の明示といった能力は、カリフォルニア州の検出基盤と一部共通化できます。EU AI Act Article 50は、生成または操作された画像、音声、動画などについて、技術的に可能な範囲で機械可読形式のマーキングと検出可能性を求めています。(eur-lex.europa.eu)

ただし、カリフォルニア州のAI検出ツール要件、EUの利用者向け開示、各地域の個人情報保護義務は同じものではありません。共通エンジンを作る場合でも、地域ごとに表示文言、保存方針、責任主体、ユーザー通知を分けて管理してください。

検証環境をどう用意するか

この種の検証を手元のWindowsやLinux環境だけで進めると、メディア形式ごとの再現、複数のAPIクライアント、URL取得の隔離、ログの削除確認を一台に集約しがちです。環境差分の記録漏れ、常時稼働コスト、チーム間で同じ検証環境を再現できない問題も起こります。

一時的なクラウド環境だけに依存する場合も、転送経路や保存先が増え、誰がアップロードデータへアクセスできるかを説明しにくくなることがあります。Macを含む複数環境でメディア生成、API検証、削除処理を再現したいチームでは、ZilCloudのMacレンタル環境を検証用に分離し、必要な期間だけ利用する方法も選択肢になります。料金や利用条件はZilCloudの料金案内で確認し、個人情報を含む本番データではなく、権利処理済みの検証データを使ってください。

最後に残すべき成果物は、検出ツールの画面だけではありません。適用性の判断メモ、アップロード・URL・APIの試験結果、system provenance dataの出力例、latent disclosureの再検出結果、削除ログ、フィードバックの改善記録を一つの検収資料にまとめ、プロダクト、開発、プライバシー、法務が共同で確認してください。本文は法律上の助言ではありませんが、保存した検収マトリクスを使えば、2026年8月2日前の論点整理を具体的な作業に落とし込めます。

よくある質問