航空が安全になったのは、各ボルトが定格荷重に耐えられるかを個別に試験したからではない。部品同士がどう相互作用し、誰が何を指揮でき、実際の運用が安全ケースの前提条件からどう乖離するかを問い続けたからである。この規律がシステム安全である。そのツールキットにはSTPA、FRAM、STECAなど、規制産業ですでに義務付けられている手法が含まれる。
AI安全はそれらをほとんど輸入していない。2026年の論文がそうする。
Luca Carlucci、James Fillingham、Robert Walpole、Bartłomiej Kryśは、これら3つの手法を、現実的な本番環境（研究室、企業顧客、開発者）におけるフロンティアコーディングエージェントに適用しました。 "先進AIからの制御喪失リスクへのシステム思考アプローチ" （arXiv:2606.13474; ICML 2026 Technical 人工超知能 Governance Workshop）。通常のモデルテストでは捉えられない3つの危険性を指摘している。
三つの方法、平易な言葉で
彼らが使用したシナリオ
彼らは3つの手法すべてを、本番ソフトウェア作業における最先端のコーディングエージェントで実行した。長期的な視野を持ち、ツールを使い、実際のコードベースと外部サービスを扱い、研究所、企業顧客、開発者の監督下にある。これがすでにこれらのシステムが提供される方法だ。システムレベルの制御喪失リスクは、まだほとんど分析されていない。
モデル評価が見逃す3つの発見
ラボが安全に関するコミットメントを決め、利用ルールを書き、違反を監視する仕組みだ。規制当局や顧客、監査人は運用を独立して確認できない。自己申告が主なフィードバックループになっている。
STECAはそれを壊れた制御構造として指摘する。制御行動が機能するのは、着弾したかどうかを誰かが確認できる場合だけだ。安全に責任を持つ当事者が、安全が保たれていることの主な証明源でもあるとき、そのループは損なわれる。これは設計上の事実であり、特定の研究室が不正直だという主張ではない。
STPAはエージェントが行動したことと人間がそれを知るまでのギャップをマッピングする。マルチステップのリアルタイム実行では、レビュアーがアラートを見る前に、エージェントがすでにツールを呼び出したり、コードを書いたり、変更をプッシュしたりしていることが多い。
航空業界ではこれを『ループから外れる』と呼ぶ。システムを停止する正式な権限は紙の上には残る。機能的な権限は追いつかない。それが今日のフロンティア・コーディングエージェントに対するリアルタイム監視の姿かもしれない。
FRAMは通常の変動に焦点を当てる。安全策はデプロイ時のシステムの状態に合わせて調整される。その後、プロンプトが変わり、タスクの組み合わせが変わり、エッジケースが積み重なり、実際の分布がリリース時に使用したサンプルから乖離していく。
何も警鐘は鳴らない。安全策は昨日までの状況に対して設計された通りに機能し続けている。新しい事例が、もはや適合しないルールにぶつかるまで、静かにギャップは拡大していく。
これがガバナンスに意味すること
モデルのテストは、入力に対してシステムが何をするかを尋ねる。だがその周囲の制御構造、誰が何に責任を負うか、リリース後に運用がどう逸脱していくかは示さない。能力スコアやレッドチームは依然として必要だ。だがそれだけでは足りない。
論文の要求はシンプルだ。モデルレベルのハザード分析とシステムレベルのハザード分析を、安全性評価の必須部分として組み合わせること。STPA、FRAM、STECAが具体的な出発点だ。一つのコーディングエージェントから経済全体に拡大した場合、同じ盲点が何を引き起こすのか 徐々な権力剥奪 後になるまで分かりにくい。
For the Foundation, the lesson lands on design, not on a single paper. Independent inspection, compute rules, and external verification exist so safety does not rest on a lab reporting on itself. That is why our plan centers 拘束力のある制限と検証, 、自発的な自己評価だけではない。完全な方法の詳細を知りたい場合は論文を読んでください: arXiv:2606.13474. そして、その発見をワークショップの引用だけでなく、法律や制度に活かせ。