SAFE RFC：OSAAの航空業界式AIインシデント交換は公開ドラフトであり、まだシステムではない

2026年8月4日、Black Hat USAがラスベガスで開幕する中、Linux FoundationはShared AI Findings Exchange（SAFE）Working GroupのためのRequest for Commentsを公開した。これは、組織がAIセキュリティインシデントやニアミスを機密の共有チャネルに報告し、それらから集合的に学び、失敗から導かれた防御管理策を公開するための提案である。Linux Foundationは発表の中で、初稿はCisco、CrowdStrike、Hugging Face、NVIDIA、Red Hatをはじめとする他のアライアンスメンバーの貢献者によって作成されたと述べた。同日、Open Secure AI AllianceのGitHubリポジトリを通じてコミュニティレビューのために公開された。このエントリは危害を記述していない。ポリシー記録であり、アーカイブにはinfoの重大度グレードとAの信頼度グレードを付けて登録され、その主題は出来事ではなくプロセスである。この記録の重大度グレード、信頼度評価、情報源リストはAIインシデントアーカイブ内に、その周辺に登録された項目と並んで収められている。

草案はメンバーに対し、4つの事項を報告するよう求め、その理由を無視するよう求めている。

8月の文書は修辞に乏しく、トリガーについて具体的です。「Reporting Compact」という見出しの下で、会員資格の条件として、自らが運用するAIシステムが次の4つのいずれかを行ったと気づいた、または合理的に疑った場合にインシデントを報告することへの同意を会員に求めています。すなわち、第三者のシステムに無許可でアクセスし、悪用し、妨害し、誤用し、または改変した場合。サンドボックス、ネットワーク、アイデンティティ、ポリシー、またはツールの境界を脱出または迂回して第三者に影響を与えた場合。所有者の同意なく第三者の機密情報にアクセスした場合。または、運用者が当該活動が無許可である、もしくは承認された範囲外であると知った、または合理的に疑った後も、本番ターゲットの探索、アクセス、または改変を続けた場合です。

次に来るのが、大部分の役割を果たす文だ。「意図は、事象が報告対象となるかどうかを決めるものではない。環境がシミュレーションされていたと信じることは、インシデントを説明するかもしれないが、それを報告する義務をなくすものではない。」この条項は、システムが、運用者が密閉されたテスト環境だと信じている環境で稼働し、稼働中のインフラを演習の一部として扱っている場合を対象としているように読める。運用者の環境に関する信念は事象を説明するかもしれないが、報告義務をなくすものではない。草案はまた、メンバーに対し、確認された危害を生じさせた事象だけでなくニアミスも報告し、30日以内に予備的な制御失敗分析を提出するよう求めている。

期限：即時、72時間、4営業日、90日

草案の中で最も具体的なのは通知表であり、その最初の行は期限ですらない。直接影響を受ける組織には直ちに通知することになっている。すべての期限は、報告対象となる事案を疑う合理的根拠となる事実を会員が認識した時点から起算され、調査が終了した時点からではない。以下の表は8月4日草案から転載したものであり、10月改訂でも同じ期間が維持されている。

これらの行のうち3行は他者への通知について、4行はSAFE自体への通知について述べています。この区別が重要なのは、このフレームワークが明示的に開示制度ではないからです。草案には「これらのタイムラインは、影響を受ける当事者への通知、既存のCoordinated Vulnerability Disclosureのベストプラクティスを通じた顧客への通知、または規制当局もしくは法執行機関への通知に関する、適用される契約上の義務その他の法的義務を代替するものではありません」と記されています。SAFEが追加するのは、規制機関ではない組織に対する並行した義務と、3段階の開示モデルです。このモデルでは、最後の段階である公共安全レポートのみが広く共有されることを意図しています。

8月には制御レイヤーが8層、10月には11層

レビューはモデル単体ではなく、運用スタックを中心に構成されている。8月の草案は8つの層を列挙し、各層に一つの問いを投げた——モデルは不確実性と停止条件を認識したか；認可と環境上の前提は明示されていたか；分類器、承認、行動制限は機能していたか；資格情報、権限、実行は制約されていたか；分離とデータ境界は独立に検証されていたか；運用者はリアルタイムで検知し中断できたか；エスカレーション経路とキル手順は明確だったか；クラウド、評価、データ、ツールのパートナーが想定された制御を無効化していなかったか。

2026年10月21日付で、翌日リポジトリにコミットされた10月改訂版は、三つの層を追加する。サービング経路、確定時点における認可、そして一連のアクションにまたがるワークフロー構成である。また、レビューを、合格、不合格、証拠不十分、該当なしという四つの許容回答を伴う段階的評価に変え、変更ログに、これらの所見は一般的なシステム安全性や法令遵守を確立するものではないと記している。この変化の過程は、著者らが何を懸念するようになったかを示す記述として読む価値がある。モデルがきちんと振る舞ったかどうかではなく、応答したモデルが構成されていたモデルだったかどうか、アクションが実行された時点で権限がなお存在していたかどうか、そして一連の流れ全体が、それを開始したスコープの内側にとどまっていたかどうかである。

航空、でも航空のどの部分？

記録自体の枠組みづけ——NASAのAviation Safety Reporting Systemをモデルにしたシステム——は、草案ではなくLinux Foundationの発表に沿っている。発表ではASRSを「業界が学び改善できるように、飛行事故を分析し対応するために設計された、任意参加・機密の報告システム」と説明している。8月の草案も10月の改訂版も、どこにもASRSの名前を出していない。草案はただ、SAFEが「機密の安全報告システムの最も強力な機能を採用すべきだ」と述べているだけである。これは小さな違いだが、実務上の帰結を伴う。発表は、本文がまだ確約していない期待を打ち立てている。

この類推は、RFCプロセス自体の内部で議論を呼んだ。8月5日に個人の立場で執筆した貢献者によって開かれた初期のプルリクエストは、「ASRSの類推には、欠けている制度的要素がある」と主張する。すなわち、ASRSがかなりの程度機能するのは、報告がNASAによって受領、処理、非識別化されるからであり、NASAは「公的で非規制的かつ非商業的な第三者」であって、規制当局としてのFAAでも、運航が報告されている航空会社でもない、というのである。このプルリクエストは、1998年のインターネット・ガバナンスのプロセスにも依拠しており、10月30日時点でオープンのままだった。SAFEの運営者がNASAの役割を果たせるかどうかは、確定した機能ではなく、未解決の設計上の問題である。10月の文書は、利益相反の開示、忌避、およびAlliance Steering Committeeへの不服申立ての経路を伴わせて、作業部会をアライアンス自身のガバナンスの下に置いている。

独立系の報道は、さらに狭い第二の区別を浮き彫りにした。Infosecurity Magazine は8月6日の記事で、Linux Foundation の投稿が AI エージェントに具体的には言及していないと指摘した。エージェント的な枠組みは NVIDIA の併載投稿に属し、そこでは「AI エージェントは単なるモデルではない。それはシステムだ」と主張して、アライアンスのメンバーが提供したハーネス、サンドボックス、ガードレール、評価ツール群を列挙している。草案のトリガーは、文字どおりに読めば、認可の範囲外で行動するシステムに関するものであり、発表の訴えは、文字どおりに読めば、エージェントに関するものだ。

コメント投稿者が、コストを誰が負担するかについて述べたこと

現行の文書案に対して公にされた最も具体的な反対意見の一つは、外部の批評家ではなく、同盟の創設メンバーから出た。Avondale.AIの創業者兼最高技術責任者であるStephen Sargentは、8月7日に電子メールで意見書を提出し——文書によれば、Linux Foundationの法務チームがそれを確認したのはこの日だ——8月9日に公開した。彼はまずミッションへの支持を表明し、その後、この協定は組織の規模に応じて適用を調整できないと論じる。「RFCは従業員5万人の組織と小規模チームを区別していない」。彼の評価では、4営業日での報告に保存されたフォレンジックバンドルを加えると、小規模事業者が割ける以上にスタッフの時間を消費する可能性がある。彼の提言は段階的な枠組みであり、規模の閾値を下回る場合には、機密扱いの報告と、公開の遅延または匿名化を既定とするものだ。

2つ目の異議は、期限ではなく開示に関するものだ。彼は、小規模事業者にとって「公開による開示はそれ自体が執行の一形態である」と主張する。大企業の報告は脚注になり、小規模企業の報告は見出しになるからだ。そして、一定の規模閾値を下回る場合は非識別化された報告を既定とすべきだと求めている。3つ目は、タイムラインではなくレビューの枠組みに関するものだ。8層モデルは企業内で分離されたチームを前提としているため、1人での導入では「運用者がすべてを行う」ことになり、欠けている層は、それが単に異なる運用モデルにすぎないのに、統制上の失敗と解釈される。彼の4つ目の異議は「最小限の相互運用性と保証の実務」という表現に関するもので、彼はこれを任意の報告から事実上必須となるツール導入への道筋と捉えている。この立場声明は、ある会員の見解であり、その会員自身によって公表されたものである。Linux Foundationの8月4日の発表はこれに先立つもので、この問いには触れていない。後日、10月5日にオープンされ、10月30日時点でもオープンのままのプルリクエストが、セキュリティ運用センターを持たない運用者向けのエビデンステンプレートを提案している。これは、その懸念が届いたことを示すものであり、採用済みの修正ではなく候補にすぎず、作者は、これが「SAFEの採用や法的十分性を確立するものではない」と述べている。

8月4日と10月30日の間に何が変わりましたか。

リポジトリの履歴は、RFC が実際に何を生み出したかを示す最良の記録であり、報道が示唆するよりも読み解きやすい。最初のコミットは 8 月 3 日に着地し、草案と拡張された readme は 8 月 4 日の 00:14 と 00:19 UTC にコミットされた。その後、リポジトリは 10 週間沈黙した。10 月 14 日、Alliance は憲章とメンバーファイルを追加し、リポジトリを SAFE ワーキンググループの本拠地とするよう readme を書き直した。暫定共同議長としてその日、NVIDIA の Paul DiOrio と Red Hat の Josh Boyer が記録された。10 月 21 日、ワーキンググループは SAFE v1 を公開し、その変更履歴の最初の項目は、本文が「SAFE の説明から『proposed』を削除する」ものであり、それを確立された Alliance ワーキンググループとして位置づけることだとしている。

その状態について、切り分けて考える価値のある2つの点がある。リポジトリのreadmeには現在「Status: Approved — Approved by the Steering Committee」という一文があり、これは公開記録のなかで批准表明に最も近いものだ。一方、同じリポジトリにある憲章には依然として「Under development. The SAFE charter will be published here once approved by the Steering Committee.」と書かれている。変更ログは10月の文書を「SAFE v1」と位置づけ、何を変更するかを説明しているが、誰が、どの投票で、いつの日付で批准したかは述べていない。SAFEが今や承認済みの仕様なのか、それとも統治憲章がまだ書かれていないワーキンググループなのかを知りたい読者は、これらの文書から明快な答えを得られない。

何が確立されており、何が確立されていないのか

• 制定:Shared AI Findings ExchangeのRequest for Commentsが2026年8月4日に公開されました。Linux Foundationは発表日をこの日付としており、これに貢献者として名を連ねている組織はCisco、CrowdStrike、Hugging Face、NVIDIA、Red Hatで、「Open Secure AI Allianceの他のメンバー」とともに名前が挙げられています。

• 確定済み:草案には、4つのトリガーを備えた報告協定、即時から90日までの通知表、証拠保全リスト、階層化されたレビュー枠組み、および3段階の開示モデルが含まれています。全文はリポジトリで公開されており、その履歴も併せて公開されています。

• 確認済み（ただし出典表示のみ）：アライアンスの規模 —「120以上の組織」— はNVIDIA自身の数字であり、Infosecurity Magazineの8月6日の記事で繰り返されています。確認した報道のいずれも独立した会員監査を示しておらず、リポジトリのmembersファイルには120組織ではなく、コントリビューター2名と暫定議長2名が記載されています。

• 未確認：この協定の下で誰かが報告を提出したこと。10月30日の公開記録には、コミット、プルリクエスト、イシューが示されているが、インシデント報告、パイロット、最初の事例、コメント期限、投票規則、批准日は示されていない。この枠組みは、会員が会員資格の条件として「同意する」義務を記述しているが、それは誰かがまだ履行した義務とは同じではない。

• 議論の的:中立な公的運営者がいなければASRSの比較が成立するのか（公開プルリクエストで反対が主張されている）、小規模運営者にとって報告負担は釣り合っているのか（創設メンバーの立場表明で反対が主張されている）、そしてフレームワークのどこまでがエージェント固有でどこからが一般的なAIセキュリティなのか——この区別についてLinux Foundationの文書とNVIDIAの文書では描き方が異なる。

そのどれも記録を誤ったものにはせず、アーカイブのA評価はそれ自体の基準では正当化できる。一次資料は、何が、いつ、誰によって公表されたかについて互いに一致しており、草稿も全文を読むことができる。その評価が担えないのは、読者が最も知りたいこと、つまりそのメカニズムが機能するかどうかだ。それについてはどちらとも言える証拠がない。なぜなら、そのメカニズムはまだ実際の事例を迎えていないからだ。