Open Secure AI Allianceの参加者は2026年8月4日、AIシステムの事故や未遂事例を組織間で共有する「Shared AI Findings Exchange（SAFE）」の設置案をRFCとして公開した。採用されれば、影響を受けた組織への通知は可能な限り早く、信頼できる根拠から影響が見込まれる顧客への通知は72時間以内、SAFEへの初期報告は4営業日以内となる。AIエージェントが引き起こした問題を各社の内部調査で閉じず、共通の証拠と期限に基づく防御策へ変えられるか。提案の価値は、今後の運用で決まる。
SAFEは事故共有に期限を持ち込む
SAFE案が報告対象とするのは、運用中のAIシステムが第三者の環境へ無許可でアクセスした場合や、サンドボックスなどの境界を破って外部へ影響を与えた場合だ。第三者の機密情報を同意なく取得・再配布する行為も含む。運用者が、その活動が無許可または承認範囲外だと知るか、合理的に疑った後も、本番環境への探索や変更を続ければ報告しなければならない。
提案は、実験環境だと思っていたといった実行者側の認識を、報告を免れる理由にしない。損害が確定した事故に加えて、被害には至らなかったニアミスも対象になる。実行の意図や被害確定の有無より、第三者の境界を越えたか、越えかけたかを起点にする設計だ。
通知と公開は、次の時間軸で進む。
| 期限 | SAFE案が求める対応 |
|---|---|
| 可能な限り早く | 直接影響を受けた組織へ通知 |
| 72時間以内 | 信頼できる根拠から影響が見込まれる顧客へ通知 |
| 4営業日以内 | SAFEへ初期事故報告を秘密扱いで提出 |
| 14日以内 | 必要に応じて広範な顧客向け注意情報を発行 |
| 30日以内 | 法務・調査上の制約を踏まえ、事実に基づく暫定報告を公開 |
| 90日以内 | 改善状況を公開 |
| 毎週 | 重大なリスクが残る間、機械可読の更新を提供 |
この日程は、契約や法令、規制当局への報告を置き換えない。公開によって直ちに悪用される恐れがある場合や捜査を損なう場合には、限定的な例外を認める一方、影響先への速やかな連絡は残す。SAFEは新しい規制窓口を作る案ではなく、既存の義務と並行して業界内の学習速度を上げる仕組みである。
事故をモデルだけで終わらせない8層レビュー
RFCは、事故を8つの制御層に分けて調べる。モデルが不確実性や停止条件を認識したかに始まり、指示とセーフガードを経て、ツールと実行環境へ進む。さらに、監視と人間の運用に加え、クラウドや評価基盤を含む供給網まで対象にする。
AIエージェントは認証情報を使い、外部ツールを呼び出し、ネットワーク越しに操作する。モデルが想定外の判断をしても、権限を絞り、送信先を許可リストに限定し、異常な挙動を止められれば外部被害は抑えられる。反対に、モデル側の試験を通過していても、評価環境の隔離や人間の停止手順が崩れれば事故になる。8層のレビューは、原因をモデル性能の一語へ押し込めないための分解表だ。
調査に必要な証拠も具体化した。プロンプトや実行トレース、ツール呼び出し、ログに加え、モデルとセーフガードの版、実行時に使えた権限と認証情報を保存する。人間が承認・介入した時点、作成または変更したファイル、検知から復旧までの出来事も残す。完全な時系列と再現試験、改善を確認した証拠まで揃えるため、障害後に結果だけを説明して終える運用は認めない。
30日以内には、どの制御が機能しなかったかという暫定分析も提出する。これにより、「モデルが暴走した」という説明を、どの境界が破られ、どこで検知できず、誰が止められなかったのかという検証可能な問いへ開ける。
秘密共有から公開対策までの3段階
SAFE案の開示は3段階である。最初は信頼された参加者へ、侵害の兆候や封じ込め手順を秘密扱いで急報する。次に、当事者を特定しにくくした分析と推奨策を会員向けの運用情報として共有する。最後に機微情報を除き、根本原因や再発防止策、採用状況を一般向けの安全報告として公表する。
Linux Foundationは発表文で、NASAの航空安全報告制度を先例に挙げた。SAFEも、率直な報告を促すため、善意の過失には非懲罰的に対応し、必要に応じて報告者を匿名化する考えだ。ただし、故意または犯罪行為は保護から外す。学習のための秘密レビューと、当事者や規制当局が持つ法的権利を切り分ける。
事故レビューの成果は報告書に限らない。機微な証拠を漏らさず新たな危険も生まない場合、再利用できる試験と機械可読のポリシーを公開する。検知ルールや参照設定、対応手順も版管理されたカタログへ収める。たとえば実システムへの意図しないアクセスなら、外向き通信を既定で拒否し、接続先を許可リストで限定する。評価用設定への署名や実行前の隔離確認も対策の候補になる。
影響を受けた組織は事実誤認を訂正できるが、教訓や推奨策を拒否する権限は持たない。さらに、単一企業や一業種が結論を支配しない独立運営を求め、オープンとクローズドのAIを同じ手続きで扱う。RFCは中立運営と拒否権の制限を組み合わせ、共有された証拠を再現可能な対策へ反映させる設計だ。
120超の連合が越えるべき採用の壁
NVIDIAによると、Open Secure AI Allianceの参加組織は8月4日時点で120を超えた。アライアンスの発足発表は7月27日であり、SAFE案はその約1週間後に出た。初期案の作成にはCisco、CrowdStrike、Hugging Face、NVIDIA、Red Hatなどが加わっている。
参加組織が増えれば、異なるモデルやクラウド、セキュリティ製品をまたぐ事故の傾向を見つけやすくなる。ただし、数は制度の実効性を保証しない。RFCには正式採用の日程や必要な賛成数、報告を受ける組織の人員と予算、期限を守らなかった会員への対応が書かれていない。秘密情報をどこに保管し、既存の法的義務と秘密レビューをどう両立させるかも、今後の設計に残る。
特に注目すべきは、草案の中に「望ましい」とする原則と、会員が合意し「しなければならない」とする報告契約が併存している点だ。RFCが正式な会員条件へ変わる過程では、強い期限を保ったまま、企業が実際に事故情報と実行ログを預けられる運営主体を作れるかが試される。
評価は、RFCを採択した後の運用で決まる。参加組織が共通期限で事例を報告し、その証拠から作った試験や検知ルールを公開できるか。そこまで到達すれば、一社のニアミスを他社が本番事故の前に試せる防御策へ変えるというSAFEの目的が、初めて運用として確認できる。
