カリフォルニア州 SB 53 コンプライアンス:フロンティア AI 透明性法(TFAIA)の実務ガイド

約2分Mike ThriftMike Thrift
カリフォルニア州 SB 53 コンプライアンス:フロンティア AI 透明性法(TFAIA)の実務ガイド

2025年9月29日、カリフォルニア州のギャビン・ニューサム知事は、参議院法案53号「フロンティア人工知能透明性法(TFAIA)」に署名しました。これにより、カリフォルニア州は、最も計算集約的なAIシステムの開発者に対して、拘束力のある安全性、透明性、およびインシデント報告の義務を課す全米初の法域となりました。この法律は2026年1月1日に施行され、過去6ヶ月の間、最大手のAIラボや成長著しい中堅モデル開発者が、リスクを文書化し、ガバナンス枠組みを公開し、壊滅的なリスクシナリオについて規制当局に報告する方法を静かに再編してきました。

貴組織が基盤モデルのトレーニング、ファインチューニング、あるいは大幅な改変を行っている場合、または他の開発者が依存する大規模な計算クラスターを運営している場合、SB 53は現在、米国で理解しておくべき最も重要なAI法です。本ガイドでは、規制の対象者、公開すべき事項、15日間の重大インシデント報告の仕組み、適用される内部告発者の保護義務、そしてこの法令を実務的なコンプライアンスプログラムにどのように落とし込むかについて解説します。

SB 53が実際に規制するもの

州ごとに広がっている雇用AI法(ニューヨーク市地方法律144号やコロラド州AI法など)とは異なり、SB 53はアルゴリズムによる採用ツール、信用引受モデル、あるいはテナント審査システムを規制するものではありません。この法律が対象とするのは、より狭いカテゴリー、すなわち並外れた計算規模でトレーニングされたフロンティア基盤モデルと、そこから生じ得る壊滅的なリスクシナリオです。

この法律は、2つの規制伝統の交差点に位置しています。製品安全法の分野からは、企業がリスク評価を公開し、インシデントが発生した際に当局に通知すべきであるという考え方を取り入れています。金融規制法の分野からは、大規模なプレーヤーは小規模なプレーヤーよりも重い開示義務を負うべきであるという考え方を取り入れています。その結果、2つの閾値に基づいた階層的な規制体系が構築されました。

10^26 FLOPsの計算閾値

SB 53における「フロンティアモデル」は、ファインチューニングやその後の改変による累積計算量を含め、10の26乗回以上の整数または浮動小数点演算(FLOPs)を使用してトレーニングされた基盤モデルと定義されています。この閾値は、現在は失効した連邦大統領令14110号の報告トリガーやEU AI法の汎用AI(GPAI)の階層と意図的に一致させられているため、米国の主要なラボのほとんどは、自社がこの基準を超えているかどうかをすでに把握しています。

見落とされがちなのは、この法令が派生的な改変による累積計算量をカウントしている点です。閾値に近いベースモデルを採用し、継続的な事前学習、強化学習によるファインチューニング、あるいは他のモデルとの重みのマージを行った場合、単一のトレーニングランで10^26 FLOPsを超えていなくても、その派生モデルはフロンティアステータスに該当する可能性があります。すべてのベースモデル、すべてのファインチューニング、すべての蒸留、およびすべての重みのマージをカタログ化し、各ステップで消費されたFLOPsを追跡することは、今や不可欠な帳簿記録(ブックキーピング)の規律となっています。

大規模フロンティア開発者のための5億ドルの売上高閾値

「大規模フロンティア開発者」とは、前暦年における当該法人および提携会社の年間総売上高が5億ドルを超えたフロンティア開発者を指します。売上高テストは連結ベースで行われ、親会社、子会社、および共通の支配下にある提携会社が合算されます。10億ドルの資金調達を行ったものの、実際の収益が4,000万ドルである小規模なAIスタートアップは、大規模フロンティア開発者には該当しません。一方、FLOPsの閾値を超える小規模なAI部門を持つ上場テクノロジー・コンングロマリットは、ほぼ確実に該当します。

この階層化が重要なのは、大規模フロンティア開発者が最も重い義務を負うためです。具体的には、フロンティアAIフレームワークの公開、壊滅的リスク評価の実施、カリフォルニア州緊急事態管理局(Cal OES)への四半期ごとの内部利用リスク要約の提出、および匿名の内部告発者窓口の維持が求められます。FLOPsの閾値は超えているが売上高の閾値には達していない小規模なフロンティア開発者も、透明性レポートの公開や重大な安全インシデントの報告は義務付けられていますが、フルセットのフレームワーク制度の対象にはなりません。

公開が義務付けられている事項:フロンティアAIフレームワーク

すべての大規模フロンティア開発者は、自社のウェブサイトでフロンティアAIフレームワークを公開し、最新の状態に保たなければなりません。年次レビューは必須であり、重要な変更があった場合は変更から30日以内に更新を行う必要があります。

正当化可能なフレームワークには、最低限以下の事項を記載する必要があります:

  • 壊滅的リスクの閾値と評価方法: どのような能力(化学、生物、放射線、核兵器への加担、大規模な重要インフラへの攻撃、自律的なエージェントの制御喪失シナリオなど)を、開発者は壊滅的な閾値を超えたとみなすか? 展開前にそれらの能力をどのようにテストするか?
  • リスク緩和戦略: 具体的な展開前の緩和策:拒絶トレーニング、能力の抑制、展開制限、監視付きアクセス、段階的なロールアウト、および展開後のモニタリング。
  • 第三者評価: どの外部レッドチーム、評価者、および監査人がモデルを評価し、その結果はどのように反映されるか?
  • 未公開モデルの重みに関するサイバーセキュリティ・プロトコル: 展開前の重みを盗難から保護するための、内部脅威対策、ハードウェア・セキュリティ・モジュール(HSM)、ネットワーク・セグメンテーション、およびアクセス・ロギング。
  • 重大な安全インシデントへの対応手順: 誰がインシデントの報告義務の有無を判断し、15日間のカウントダウンをどのように開始し、Cal OESとどのように連携するか。
  • 内部ガバナンス・メカニズム: 取締役会レベルの監督、AI安全責任者(AI Safety Officer)の役割、エスカレーション・パス、および安全レビューの頻度。
  • 標準への適合性: 法令が基礎的なベースラインとして扱うNIST AIリスクマネジメントフレームワーク(AI RMF 1.0)およびISO/IEC 42001への明示的なマッピング。

このフレームワークはマーケティング資料ではありません。これは、企業の公的なコミットメントが内部の実務と一致しているかどうかを司法長官が評価するために使用する、規制当局向けの文書です。SEC(米国証券取引委員会)のリスク要因開示やSOC 2のシステム記述と同等の厳格さでドラフトを作成することが、正しい姿勢です。

すべてのデプロイメント前の透明性レポート

大規模な開発者に限らず、すべてのフロンティア開発者は、新規または実質的に変更されたフロンティアモデルをデプロイする前に、透明性レポートを公開しなければなりません。透明性レポートは、フレームワークとは別のモデル固有の文書であり、以下を含める必要があります。

  • 会社名、ウェブサイト、および安全上の懸念に関する連絡方法
  • モデルのリリース日、およびサポートされている言語と出力モダリティのリスト
  • 意図された用途および適用される利用制限
  • 大規模開発者の場合、壊滅的リスク評価の要約とその結果(第三者評価者が関与したかどうか、およびその方法を含む)

「実質的な変更」には、主要な機能のアップグレード、新しいモダリティの追加、および学習データの混合比率の重要な変更が含まれます。パッチのリリースや日常的な安全性のファインチューニングには、通常、新しい透明性レポートは必要ありませんが、境界線上のケースについては、後に司法長官からレポートが公開されなかった理由を問われた場合に備え、書面による根拠を記録しておく必要があります。

15日間の重大インシデント報告期限

社内弁護士を最も驚かせたコンプライアンス上の負担は、インシデント報告のスケジュールです。フロンティア開発者は、重大な安全上のインシデントを発見してから15日以内にカリフォルニア州緊急事態管理局(Cal OES)に通知しなければなりません。インシデントが公衆衛生に差し迫った脅威を与える場合は、24時間以内というより厳しい期限が適用されます。

法典では、重大な安全上のインシデントを広義に定義しています。

  • 未公開のモデルの重みへの不正アクセスまたは盗難
  • 壊滅的リスクの顕在化
  • デプロイされたモデルに対する開発者の制御の喪失
  • 安全策を無効化するような、モデルの欺瞞的または回避的な行動

防御可能な内部プロセスを構築するということは、インシデントが発生する前に次の3つの質問に答えておくことを意味します。

  1. 誰が決定するか? 指名された1人の役員(多くの場合、最高AI安全責任者または指定された代理人)が、文書化されたエスカレーション基準に従って、報告期限を開始する権限を持つべきです。
  2. 何が期限を開始させるか? 「発見」がトリガーとなります。15日間の期間はその時点から計算されるため、いつ、誰が、どの監視システムを通じてインシデントを発見したかを内部文書に正確に記録する必要があります。
  3. 報告書はどのように送信されるか? Cal OESは、開発者の提出物のために機密の受付プロセスを維持しています。報告チームは、実際のインシデントが発生するかなり前に、機密性の高い技術詳細の暗号化送信を含む提出ワークフローのリハーサルを行うべきです。

大規模なフロンティア開発者の義務は、事後的なインシデント報告にとどまりません。3ヶ月ごと(または他の合理的なスケジュールに従って)、大規模開発者はフロンティアモデルの内部利用から生じる壊滅的リスク評価の要約をCal OESに送信しなければなりません。この四半期ごとの周期はSB 53に固有のものであり、米国の法律がAIラボに対して、進行中の内部利用リスクの調査結果を行政機関に報告することを義務付けたのはこれが初めてです。

内部告発者保護と匿名の内部チャネル

SB 53は、カリフォルニア州の一般的な内部告発者制度の上に、フロンティアモデルによる壊滅的な被害のリスクを評価、管理、または対処することを使命とする「対象従業員」に適用されるAI固有の一連の保護を重ねています。

フロンティア開発者は、対象従業員が以下の相手に対して情報を開示することを妨げたり、開示したことに対して報復したりしてはなりません。

  • カリフォルニア州司法長官
  • 連邦規制当局
  • 直属の上司、または調査権限を持つ他の上司
  • リスク評価を職務とする他の対象従業員

保護される開示対象は、(a) 開発者の活動が壊滅的リスクから公衆衛生または安全に対する具体的かつ実質的な危険をもたらすと信じるに足りる合理的な根拠、および (b) 開発者がSB 53自体に違反したと信じるに足りる合理的な根拠の両方をカバーしています。

大規模なフロンティア開発者は、匿名の内部報告チャネルも維持しなければなりません。法典は以下を求めています。

  • 対象従業員が壊滅的リスクの懸念に関する匿名開示を行えるワークフロー
  • 調査に関する報告従業員への月次のステータス更新
  • 開示と結果を要約した役員および取締役への四半期ごとの報告(不正行為で告発された特定の個人は報告の対象から除外される)

裁判所は、報復行為に対する訴訟で勝訴した原告に弁護士費用を認めることができます。極めて重要なことに、この法典は立証責任を転換させています。対象従業員が保護された活動が不利益な処分の寄与要因であったことを示した場合、開発者は、その処分が独立した正当な理由によって発生したはずであることを証明する責任を負います。

壊滅的リスクの定義

SB 53の重心は「壊滅的リスク」の定義にあります。法典では、フロンティアモデルが以下の3つの因果メカニズムのいずれかを通じて、50人以上の死亡もしくは重傷、または10億ドル以上の財産の損害もしくは損失に実質的に寄与するという、予見可能かつ重大なリスクと定義しています。

  1. 兵器支援。 化学、生物、放射性物質、または核兵器の作成、配備、もしくは使用、あるいは同等の被害をもたらすサイバー兵器への実質的な寄与。
  2. 制御不能な有害行為。 人間の監視が限定的な状態でのモデルによる行為であって、人間が行えば殺意を必要とする重大な犯罪となるもの。
  3. 制御の喪失。 モデルに対する開発者の制御の喪失により、モデルが実質的に有害な行為に従事すること。

この定義には重要な除外事項が設けられています。すでに公開されている情報に基づくリスク、適法な連邦政府の活動から生じる被害、およびモデルの寄与が実質的でない被害はすべて対象外となります。この除外規定により、履歴書審査のバイアス、ハルシネーションによる医療アドバイス、著作権侵害といった日常的なアプリケーションのリスクが壊滅的リスクの体制をトリガーすることはありません。これらの被害は現実のものですが、SB 53ではなく他の法律によって対処されます。

民事罰と法執行

カリフォルニア州司法長官が独占的な執行権限を持っています。民事罰は違反1件につき最大100万ドルに達する可能性があり、行為の重大性に応じて調整されます。SB 53自体には私的提訴権はありませんが、内部告発者への報復禁止規定は、被害を受けた従業員による民事訴訟を通じて独立して執行可能です。

実務上、法執行のリスクは以下の3つの領域に集中しています。

  • しきい値の操作。 累積計算量を10^26 FLOPsの直前に抑えつつ、明らかにフロンティアクラスの機能を備えたモデルを出荷するようトレーニングを構成する企業は、厳格な調査の対象となります。法律における「累積計算量」という文言により、この戦略は脆弱なものとなっています。
  • フレームワークの不備。 ポリシーを列挙しているだけで実施の証拠がないフレームワークは、各コミットメントを運用の成果物、責任者、および監査ログに関連付けているフレームワークよりも攻撃を受けやすくなります。
  • インシデント報告の遅延。 15日間の期限、あるいは差し迫った脅威に関する24時間の期限を逃すことは、規制当局が歴史的に積極的に訴追してきた、明確で文書化可能な違反の一種です。

90日間の実施計画の策定

SB 53プログラムをまだ立ち上げていない組織にとって、以下の順序が効果的です。

1日目から30日目:範囲の特定とギャップ分析。

  • トレーニング、ファインチューニング、マージ、または大幅に修正されたすべての基盤モデルをカタログ化し、それぞれの推定累積計算量を算出する。
  • 前暦年の連結収益(すべての関係会社を含む)が5億ドルを超えていたかどうかを判断する。
  • エンジニアリング、セキュリティ、法務、広報、人事のメンバーからなる、部門横断的なAI安全性・コンプライアンス・ワーキンググループを結成する。
  • 現在の慣行をNIST AI RMF 1.0およびISO/IEC 42001と照らし合わせ、ギャップを特定する。

31日目から60日目:起案とガバナンス。

  • フロンティアAIフレームワークを、バージョン管理された公開可能な文書として起案する。
  • 能力評価、脅威モデリング、および危険な領域においてモデルがフロンティア級の能力を持つと判断するための基準を含む、壊滅的リスク評価手法を構築する。
  • 文書化されたアクセスログと内部脅威モニタリングを備えた、未公開の重み(weights)に対するサイバーセキュリティ管理を立ち上げる。
  • 匿名の内部通報チャネルと、毎月のステータス更新および四半期ごとの取締役会への報告のためのワークフローを確立する。

61日目から90日目:運用の準備。

  • 重みの盗難インシデントや壊滅的リスクの顕在化をシミュレートする机上演習を行い、15日間および24時間の報告ワークフローを練習する。
  • 対象となる従業員に対し、内部告発者の権利と匿名チャネルについてトレーニングを実施する。
  • 展開パイプラインにあるモデルについて透明性レポートを公開し、フロンティアAIフレームワークへの相互参照を含める。
  • Cal OES(カリフォルニア州緊急事態管理庁)への四半期ごとの壊滅的リスク概要の提出と、年次のフレームワーク見直しをスケジュールに組み込む。

他のAI・プライバシー規制との調整

SB 53は単独で存在するものではありません。コンプライアンスチームは、以下の規制等との関連性を整理する必要があります。

  • NIST AI リスクマネジメントフレームワーク: 本法律が明示的に参照しており、実質的なガバナンス基盤の多くを提供しています。
  • EU AI法の汎用AI(GPAI)階層: 文書化の重複が相当数あり、単一の調整済み内部フレームワークで両方に対応可能です。
  • コロラド州AI法およびテキサス州責任あるAIガバナンス法: ハイリスクな意思決定を行うAIの展開者の義務を規定しており、ダウンストリームの顧客に適用される可能性があります。
  • カリフォルニア州消費者プライバシー法(CCPA)および自動意思決定技術に関するCPPAの規則: モデルの展開と交差しますが、SB 53とは独立して運用されます。
  • 連邦AI安全性研究所の自発的コミットメントおよび今後予定される連邦の優先法案: コンプライアンスの基準が変わる可能性があります。

正確なコンプライアンス記録と明確な監査証跡は、これらすべての制度において不可欠です。財務報告を支えるものと同じ文書化の規律が、AIガバナンスの報告も支えます。フロンティアAIフレームワーク、壊滅的リスク評価、インシデントログ、および内部告発の調査記録は、少なくとも5年間保存し、役員の交代や組織再編の影響を受けない方法で保管されるべきです。

コンプライアンスと財務記録を監査可能な状態に保つ

フロンティアAIフレームワークの公開、Cal OESへの四半期ごとの提出、あるいは司法長官の調査への対応であっても、根底にある規律は同じです。つまり、バージョン管理され、監査可能な明確な記録です。AIネイティブのチームがコードベースに使用しているのと同じプレーンテキストによるアプローチは、会計帳簿にも見事に適合します。Beancount.io は、財務データの完全な透明性とコントロールを可能にするプレーンテキスト会計を提供します。ブラックボックスやベンダーロックインはなく、規制当局が現在求めているガバナンスの規律と自然に調和するクリーンな監査証跡を実現します。無料で始める ことができ、開発者や財務のプロフェッショナルがなぜプレーンテキスト会計に切り替えているのかをご確認いただけます。