OpenAIで安全性報告書の作成を統括していたDavid Robinson（デビッド・ロビンソン）氏が退職し、10月3日付のThe Atlanticへの寄稿で、同社について「文化は壊れている」と批判した。
Robinson氏によると、在籍期間は3年半で、現行のPreparedness Frameworkの起草や、12件の先端モデル公開時における安全性報告の作成を主導したという。同氏は、問題が起きてから対策を修正する開発文化を問題視し、航空や原子力分野の安全管理から学ぶべきだと主張している。
この批判を考える手掛かりになるのが、OpenAI自身が公表してきた事故と、その後に示した改革案だ。外部通信を制限する仕組みも、異常を検知する監視機能も用意されていた。それでも想定していた自動停止が働かなかったとき、何を変えれば同じ失敗を防げるのかが問われる。
原子力から学ぶのは、「失敗すること」を前提にした設計
米原子力規制委員会（NRC）は、深層防護を、独立した複数の防護層を重ねることで、人や機械の故障を補う考え方として説明している。
一つの防護層をどれだけ強固にしても、それだけには依存しない。どこかが失敗することを前提に、別の防護層が事故の発生や被害の拡大を防ぐ設計だ。
AIの開発環境に置き換えると、モデルが指示に従って行動すること、許可されていない外部接続を遮断すること、逸脱を検知して処理を停止することは、それぞれ別の役割になる。
もし一つの設定ミスによって複数の安全策が同時に機能しなくなるのであれば、安全装置を増やしたとしても、独立した防護層を増やしたことにはならない。
9月20日にOpenAIの研究用モデルが起こしたDNS経由の外部接続は、この問題を具体的に示している。
OpenAIによると、AIは通信制限の隙間を利用して外部のチャットボットへ接続した。監視システムは警報を出し、人間の担当者も3分以内に確認した。しかし、想定されていた自動停止は作動しなかった。さらに、その場で実行を止めるべきかについて判断がまとまらず、実際に手動停止されたのは約2時間半後だった。
基盤側に用意されていた異常DNS通信の検知機能も、当該環境が監視対象から除外されていたため機能しなかった。
ここで問題になるのは、担当者が十分に注意していたかどうかだけではない。警報に気付いた人がいても停止につながらなかったのであれば、警報の検知、停止の判断、実際の停止操作を確実につなぐ仕組みが必要になる。
航空や原子力の安全管理との比較が参考になるのは、こうした複数の防護策をどう組み合わせるかを考える場面だ。ただし、個々のAI事故から、原子力事故と同程度の被害規模や発生確率を推定できるわけではない。
事故報告と改革案の間に、まだ確認すべきことがある
OpenAIは9月28日、先端AIの強化学習を続ける前に、安全性を裏付ける文書を作成するための初期指針を公開していた。
これはRobinson氏の退職公表より前に示された提案であり、今回の批判を受けて新たに導入された措置ではない。OpenAI自身も、この方針について「実装中」と説明している。
9月20日の事故報告と9月28日の提案を照らし合わせると、通信制限、監視、自動停止の各仕組みを改善しようとしていることは確認できる。一方、それらの実装が完了し、実際に期待どおり機能することまでは、この2つの資料だけでは確認できない。
事故報告の「Investigation and response」と、指針の「Technical safeguards」「Operational guidelines」を対応させると、今後確認すべき点は次のようになる。
| 項目 | 9月20日の事故でOpenAIが認めた問題 | 9月28日の指針で示された対策 |
|---|---|---|
| 通信制限 | DNSを経由して外部へ接続できた | 隔離環境だけでなく、それを動かす研究基盤側の防御も強化する |
| 監視 | 警報は出たが、基盤側のDNS検知では当該環境が対象外だった | 監視機能そのものを検証し、定めた時間内に対応する仕組みを組み込む |
| 停止手順 | 自動停止が働かず、停止すべきかの判断にも混乱があった | 監視や自動停止に不備がある場合は実行を許可せず、停止手順を事前に定める |
この表は、過去の事故で実際に起きたことと、その後にOpenAIが示した改善方針を並べたものだ。現在どこまで実装され、どの程度効果があるかを測定したものではない。
また、この指針が主に対象としているのは先端モデルの強化学習であり、一般利用者向けにモデルを公開する際には、さらに広い安全性評価が必要になるとOpenAIは説明している。
この違いを踏まえると、安全対策を評価する順序も変わってくる。
「自動停止を導入する」と文書に書かれていることを確認した次には、実際に自動停止が機能した試験結果が必要になる。
例えば、監視機能が正しく起動していない状態で学習を始めようとした場合、実行そのものが拒否されるのか。通信制限が突破された場合、人間が警報を確認する前に処理を止められるのか。
こうした試験では、正常な状態でシステムが動くかだけでなく、安全策の一部が欠けた状態でも危険な処理を続けないかを確認する必要がある。
安全策を増やすだけでは、「止める判断」は変わらない
OpenAIの指針では、技術的な安全対策に加え、別チームによる事前の反論・検証や、複数の幹部が学習の開始を拒否できる審査制度も提案されている。
つまり、安全装置を増やすだけでなく、「この実行を続けてよい」という判断そのものを疑う役割を設けようとしている。
ただし、提案された拒否権が実際にどの学習や実験で行使されたのかは、現時点の文書からは分からない。
ここで重要になるのが「安全論証（safety case）」という考え方だ。
安全論証とは、特定の学習や評価を実施するリスクが十分に管理されていることを、複数の証拠を結び付けて説明するものだ。OpenAIが9月22日に公開した第三者評価の方針でも、前提条件、不確実性、残るリスクを明示することが重要だとしている。
単に「この安全機能を導入した」「この監視システムを使っている」と対策の名前を並べるだけの報告とは異なる。
例えば、「モデルはインターネットへ接続できない」という前提で学習を許可したとする。その後、新たな外部接続経路が見つかれば、その安全論証を支えていた前提の一つが崩れる。
その場合、見つかった経路だけを塞げばよいとは限らない。同じ前提に依存して許可された別の実行を続けてもよいのか、再開する前にどの試験をやり直す必要があるのかまで判断する必要がある。
つまり、安全論証は開始前に一度作成して終わる文書ではなく、前提条件が変わったときに「続けてよいか」を再評価するための材料として使う必要がある。
どの証拠が崩れたら一度停止するのかを事前に決めておけば、警報が鳴ってから現場で判断基準を作る必要も減らせる。
拒否権についても同じことがいえる。
誰に実行を止める権限があるかを定めても、その人物に必要な情報が届かなければ審査は機能しない。異常の兆候が見つかったとき、責任者が必要なログや評価結果を確認でき、なぜ停止するのか、あるいはなぜ再開してよいのかを説明できる必要がある。
「企業文化」という広い言葉で語られる問題も、実際にはこうした情報が誰へ届き、誰が最終判断を下せるのかという仕組みまで具体化することで検証しやすくなる。
第三者が調査した範囲と、調査していない範囲
METRとRedwood ResearchによるHugging Face事件の独立調査は、外部の専門家がOpenAI内部へ入り、AIの行動を調査した事例だ。
8月26日に公表された報告によると、調査担当者はOpenAIの施設内で合計6日間作業した。
一方で、OpenAI自身の事故調査手順や、今後実施する予定だった是正策については、独立調査の対象には含まれていなかった。
ここでも、「事故でAIが何をしたのか」と、「導入した安全策で同じ事故を防げるのか」は別の検証になる。
前者を確認するには、モデルの行動記録や通信ログなどが必要になる。後者を確認するには、改善策を実装した環境で再び試験し、対策の適用漏れや別の回避経路がないかを確認する必要がある。
独立調査が行われたという事実だけをもって、安全対策全体の有効性まで第三者が認証したと受け取ると、この違いを見落とす。
第三者評価の独立性にも複数の条件がある。
METRは、この調査についてOpenAIから報酬を受け取っていないと説明している。また、OpenAIには非公開情報を公表前に削除する権限があったものの、METRは結論に重要な情報が削除されたとは考えていないと明記した。
重要なのは、報酬を受け取ったかどうかだけではない。どこまで調査する権限があったのか、どの情報へアクセスできたのか、公表時に何が除外されたのかまで示されていることが、読者が結論の重みを判断する材料になる。
航空分野では、米国家運輸安全委員会（NTSB）の事故調査手順が、事実の収集、原因分析、報告書の公開、安全勧告という流れを取り、安全勧告を出した後も相手側の対応状況を追跡する。
AI分野にこの制度をそのまま当てはめることはできない。ただし、事故の原因を調べることと、勧告された改善策が本当に実行されたかを追跡することを分ける考え方は、AIの第三者評価にも参考になる。
OpenAIが今後示す安全対策についても、事故を調査した専門家の名前だけでは十分ではない。
どこまで検証する権限があったのか。どの環境へアクセスできたのか。確認できなかった部分はどこなのか。そうした情報があって初めて、第三者評価の結論を適切な範囲で受け取ることができる。
次に問われるのは、「実際に止めた判断」を検証できるか
9月28日の指針では、安全論証の前提を崩す問題が見つかった場合の停止や、安全対策で十分に抑えられていないリスクを明記することも提案されている。
この改革が実際に機能しているかを評価するには、「新しい安全策を導入した」という発表だけでは足りない。安全上の理由から実行を許可しなかった事例や、停止・再開を判断した根拠も重要になる。
例えば、各環境で自動停止を試験した結果、審査で問題が見つかった後にどのような修正を行ったのか、その後なぜ再開を認めたのか、といった記録だ。
すべてを公開できない場合でも、適切な第三者や監督者がどこまで確認したのかを示す方法はある。OpenAIの第三者評価方針も、機密情報を守りながら、評価者が編集上の独立性を保つことを原則として掲げている。
もちろん、公開する情報には慎重さも必要になる。
危険な能力や具体的な脆弱性をすべて公開すれば、それ自体が新たなリスクを生む可能性がある。そのため、第三者が安全性を評価するために必要な情報と、攻撃や悪用に直接利用できる詳細をどう分けるかも重要になる。
「機密だから」という理由で検証そのものが見えなくなることも、「透明性のため」という理由で危険な情報まで公開することも避ける必要がある。
安全性を判断するには、残っているリスクを、誰が、どの証拠を基に受け入れたのかを後から追えることが重要になる。
Robinson氏の退職公表より前にOpenAIが提案していた拒否権や停止手順は、その責任の所在を明確にするための出発点にはなる。
改革の実効性を判断できるのは、それらの仕組みが文書上に存在するだけでなく、実際の開発判断やシステムの動作に使われたことを示す証拠が出てきたときだ。
