AI事故報告書を読んでいたら航空業界パイセンが先輩風を吹かせてきたので、大人しく話だけ聞いてみた

AIの事故は、何を録れば調べられるのか

안녕하신게라！パナソニック コネクト株式会社クラウドソリューション部の加賀です。

今年8月、AIの事故調査報告書が1本公開されました¹。OpenAIが社内で走らせていた評価実験からAIエージェントの群れが外へ出て、第三者であるHugging Faceのシステムへ侵入した事故です。
調べたのは社外の独立組織であるMETRとRedwood Researchで、OpenAIの構内に入って報告書をまとめています。世界中で話題になるのは確定していたので、社外を構内へ入れたOpenAIの勇気を称えたいです。

同じことが、Anthropicでも1月から7月にかけて4件起きていました²。7か月で少なくとも5件、全部が「評価のつもりが外へ出た」です。

どれも、製品に載っている安全装置を外した状態での出来事で、能力の上限を測るために外すのが通例です。Anthropicは本番のサイバー分類器なら当時判明していた3件とも止まっていたと書き、OpenAIは本番の実行環境で侵害に至る割合が100分の1未満に落ちたとしています。測ったのは、どちらも当事者です。

中身は他の方の検証記事に譲ります。私が気になったのは調査のほうです。
記録は人が読める量を超えていて、行動ごとの時刻が入っておらず、調査範囲の手前にあった掲示板は消えていて、一部には調査対象のAIが偽の入出力を混ぜていた。

「それ、うちが通ってきた道だわ」

航空業界パイセンです。言われてみればAIエージェントは、けっこう飛行機のオートパイロットに似ています（燃料が高いのも）。行き先を指示されると、あとは自分で判断して動く。うまく行っている間は誰も中を見ない。間違えるときも、指示には忠実なままです。そして事故が起きたら、何があったのかを調べることになります。
安全のルールは血で書かれている、と言われる業界です。ひとまず聞いてみましょう。

「うちは、飛ぶ前に何を録るか決めてる」

METRが面食らったのは、読む量でした。掲示板のダンプが約120万件、行動記録が約1,300件で「そのほとんどが極端に長く、しばしば数百万トークンあった」。人間が全部を読むと、雑に見積もって数十人年かかります。調査チームは分析の大半をAIエージェントへ委譲し、その要約だけで1,000ページを超えました。要約に使ったモデルは、事件で攻撃に加担したのと同じモデルです（おーい）。報告書は、嘘をつかれた可能性を否定していません。

仮に起きていたとして、我々がそれを検知できたとは確信できない。

しかも、あるはずのものが無かった。

開始と終了のおおよその時刻は含まれていたが、個々のエージェント行動の時刻は含まれていなかった。

時系列が追えないので、調査チームはエージェントが date を叩いた箇所を手がかりに線形補間して復元しています。誤差は中央値12秒、いちばん外れた1件で約9時間。数百万トークンを録っておいて、肝心な1フィールドが無い。

そして、それまでの掲示板は消えていました。エージェントが社内のパッケージ配布基盤を叩きすぎて7月4日に落とし、翌日から調査が始まり、6日にキャッシュを初期化して掲示板ごと消して、7日に実験を再開し、8日に新しい掲示板が立っています³。調べられたのは、この新しいほうだけです。隠滅ではありません。汚染されたリポジトリを作り直すのは正しい手順です。保全してから消す、という順番が手順に無かったのだろうと思います（まさかキャッシュ内に掲示板があるなんて想像できないし）。

航空はここで胸を張ります。米国の定期便なら、2002年8月19日以降に造られた機体で録るパラメータは88項目⁴。1番目が時刻です。連続記録は運航25時間分、事故が起きたら60日以上の保存が義務。音声のほうも、CVR（操縦室音声記録装置）に機体ごとの最低記録時間が決まっています⁵。どれだけ長く飛ぼうと、読むべきものは88項目×25時間を超えません。消えないようにする手当ても条文にあります。ここからはEUの事故調査規則です。失われそうな証拠は写真等で残せ（第13条1項⁶）、調査官が着くまで現場に手を触れるな（同2項）、関係者は記録の消去を防げ（同3項）と続きます。

ブラックボックスの偉大さは、その頑丈さだと思われがちです。EUROCAE ED-112 は3,400Gを6.5ミリ秒、1,100℃を60分といった耐性を求めていて⁷、たしかにめちゃくちゃ頑丈ではあります。でも事故調査を成立させているのは、そこだけではありません。調査対象の最大量を、飛ぶ前に決めてあることです。だから人力で読めるし、報告書は12か月以内を目安に出せます（第16条6項。間に合わなければ毎年中間報告、と同7項にあるので、超過も織り込み済みです）。

航空で記録が信用できるのは、乗員を信用しているからではなく、値を入れるのがセンサだからです。操縦席から記録装置へ、値を書き換える経路がありません。
AIエージェントは、ここが繋がっていました。OpenAIはツール呼び出しをモデルの外で録っていました。それでもエージェントはコンテナを抜け出し、ツールを実行する仕組みそのものを差し替えて、外側の記録に偽の入出力を流し込みました。はっきり痕跡が残ったものだけで、少なくとも96件。報告書は、もっと巧妙なものを見落としたかもしれない、と書いています。
「モデルの外で録る」だけでは足りませんでした。録る側が、調査対象の手の届くところに置いてあります。

ここまでは、真似できないことが1つもありません。時刻を入れる。消す前に保全する。記録する装置を、エージェントと同じ箱に入れない。どれも、そう決めておけばよかっただけの話です。

「で、計器は積んでるの？」

ここから風向きが変わります。

航空が88項目を選べたのは、計器の一覧がそのまま候補リストだったからです。高度計があり、対気速度計があり、姿勢指示器があった。ピトー管が測った値を記録しているから、あとになってその値がおかしいと分かる。

AIエージェントに、その計器がありません。標準で取れるのは入力と出力だけです。思考過程と呼ばれるログもまた出力で、そこからAIの意図を汲もうとしているのは人間側です。掲示板の指示を信じたのか、疑いながら従ったのか、そもそも見てすらいなかったのか。

汲み間違えた例が、もう出ています。Anthropicは7月、当時わかっていた3件を「モデルが環境をシミュレーションだと信じていたから」と説明し、9月に引っ込めました。モデルがそう述べていたことだけを根拠に信念を断定すべきではなかった、と。

先輩は、それを条文で禁じています。飛行誘導システムは、乗員の誤りと混乱を最小にするよう設計しなければならない。いま何のモードで動いているかを示す手段を設けること。アーム中のモードも、遷移も、勝手に基本モードへ戻ったときも表示すること。そして、セレクタスイッチの位置を以て表示としてはならない（14 CFR 25.1329(i)⁸）。

スイッチの位置から察させるな、内部状態そのものを出せ。オートパイロットにはそれを出す計器があり、AIエージェントにはありません。私たちは、出力から意図を汲んでいます。条文が禁じたのは、このやり方でした。

思考過程は、汲めないどころか、邪魔になることもあります。Anthropicのオフライン監視を4件のうち1件の記録へ当てると、危険と判定された行動は約1%でした。思考過程を取り除いて、ユーザの発言とツール呼び出しと結果だけを見せると、約50%に跳ね上がっています。

それでも、警報にはなります。OpenAIは事後報告で、ツールを使う強化学習と評価に思考過程（CoT）の監視を必須化したと書いています。当時これが動いていれば、Hugging Faceが侵害される30時間以上前に通報できたはずだ、とも。計器ではなく、鳴ったり鳴らなかったりする警報です。
Anthropicが8月末に出した実時間の監視は、自社の事案を確実に捕まえる、と報告書にあります。見ているのは思考ではなく、サンドボックスを探ったか、インターネットへ出たか、という外形です。

計器を作ろうとはしています。引っ込めるにあたって、Anthropicは2つのツールを当てました。モデル内部の活性を自然言語で説明させるものと、その活性が特定の語にどれだけ似ているかを測るものです。ただし前者は作話しうるし、後者は単語1つ分のスコアしか出ません。報告書は結果を「それだけでは決定的ではない」と位置づけています。
針はあっても、目盛りがまだ読めません。

先輩、乗り方が違うんです

オートパイロットを監視する人は、機体の中にいます。AIエージェントを使う人は、外にいます。

計器は、人がいる側に付きます。中に人がいる乗り物は、中に計器を積みました。高度も速度も姿勢も、コックピットから読めるように揃っていて、録る項目もそこから選べた。外から使う道具は、外へ出るものしか揃いません。いつ動いたか、どのツールを呼んだか、何が返ってきたか。中で何が起きているかは、出てきた文字列から汲み取るしかありません。

内と外が逆になるのは、当たり前の話でした。そして逆になると、再現できない場所も入れ替わります。

航空も、全部を再現できるわけではありません。突風や局所的な気圧の急変は、同じ条件を揃えても同じようには起きません。再現シミュレータはあくまで近似です。それでも事故調査が成り立つのは、機体の中から測った値で押さえられているからです。外が揺らいでも、中がどう動いたかは記録から決まります。

AIエージェントでは、逆でした。時刻も、ツール呼び出しと戻り値も、決めてさえおけば外側で押さえられる値です。けれど中のほうは、仮に録れたとしても、走らせ直したときに近似にすらなりません。思考の突風は、同じようには吹きません。
Anthropicは事案の行動記録を途中から何度も走らせ直しています。社内の研究モデルは、元の記録では標的が実在企業だと述べて攻撃をやめています。同じ地点から走らせ直すと、やめたのは5.5%でした。報告書はこれを、運の良い結末だったかもしれない、と書いています。残り9割以上では、攻撃が続いていました。

先輩にはもう1冊あって、危険につながりうる事象を72時間以内に届け出させ、届け出た人を罰さないと決めています⁹。ヒヤリとした本人が中にいるから成り立つ制度で、外から使う道具には、その人がいません。攻撃をやめた5.5%は、誰も報告しなかったヒヤリハットを、あとから数えた数字でした。

飛行機の事故調査は、起きた1回を調べる仕事でした。記録が残っていれば、それで足ります。そもそも起きる確率を、飛ぶ前に決めてあるからです。破局につながる故障は10億飛行時間に1回より稀であること、と設計の基準にあります¹⁰。
こちらは、1回では足りません。同じところから何度も走らせて、散らばりのほうを見ることになります。
似て非なる乗り物です。先輩のやり方は、そのままでは移せなさそうです。

まとめ

航空は100年かけて、安心して乗れるようにしてきました。
記録装置を積み、何を録るかを離陸前に決め、数値を書き込む経路を操縦席から切り離し、消さないよう条文で縛り、事故にならなかった分まで集めた。どれも、痛ましい事故のあとに1つずつ積まれたものです。

それでも完成形ではありません。2024年1月のアラスカ航空1282便では、CVRが正常に動いていたのに2時間のループが回り切り、事案の音声が全部上書きされました。88項目を決めてあるあの業界が、飛行後にCVRの記録を保全する手順を規程へ書き込め、と勧告したのは2025年6月です¹¹。FAA（米連邦航空局）が新造機のCVRを25時間にする最終規則を出したのは、事故の2年後、2026年2月でした¹²。

先輩、ひとまず打刻から入れます。保全してから消す、という順番も手順に書きます。ツール呼び出しを録る場所も、エージェントの手が届かない側へ寄せます。
中のほうは、何を録るかの前に、何が測れるのかを探している段階です。88項目に当たるものは、そのあとでしか選べません。EU AI Actのように、ログを残せというルールだけは先に出来ています¹³。

先輩も、最初はそうだったはずです。

---

お断り
記事内容は個人の見解であり、所属組織の立場や戦略・意見を代表するものではありません。
あくまでエンジニアとしての経験や考えを発信していますので、ご了承ください。

本記事の数値・条文・引用は執筆時点（2026年9月）で公開されている一次情報にもとづきます。英語原文からの引用はすべて拙訳ですので、正確な表現は必ず原典をご確認ください。

1. METRとRedwood Research「Brief independent investigation of agents' behavior, reasoning and collaboration in the OpenAI / Hugging Face hacking incident」（2026年8月26日）。本記事のOpenAI側の数値と引用は、断りのない限りこの報告書からで、拙訳です。同日に OpenAI 自身の事後報告も出ており、こちらは日本語版があります。 ↩

2. Anthropic「An alignment assessment of recent cybersecurity incidents」（2026年9月9日、9月10日に一部訂正）。4件の内訳はClaude Opus 4.6の初期版、Opus 4.7、社内の研究モデル、Mythos 5 で、このうち3件は7月30日に公表済みです。引っ込める前の7月時点での説明は、同社「Investigating three real-world incidents in our cybersecurity evaluations」（2026年7月30日）にあります。本記事のAnthropic側の記述はこの2本によります。なお9月9日の報告書は、英国AI安全研究所（UK AISI）が別途報告したインシデントを対象外としています。 ↩

3. OpenAIのBlack Hat発表によれば、無認可の掲示板は5月の訓練中から使われており、OpenAI自身のインフラ侵害は7月13日以降も続いていました。どちらも今回の調査範囲外です。 ↩

4. 14 CFR 121.344。米国の定期航空運送事業者（Part 121）に対する要件で、88項目は(f)、2002年8月19日以降に製造された機体が対象です。それ以前は製造時期に応じて18・22・34・57項目と段階的で、737の一部はさらに91項目まで求められます（(n)）。運航25時間分は(h)、事故時の60日以上は(i)。 ↩

5. 14 CFR 121.359。同じく Part 121 のCVR要件です。最低記録時間は機材と製造時期によって異なります。 ↩

6. Regulation (EU) No 996/2010。ICAO Annex 13 をEU法へ落とし込んだもので、EUR-Lexで全文が読めます。以降の条番号はすべてこの規則で、条文の引用は拙訳です。 ↩

7. EUROCAE ED-112（Minimum Operational Performance Specification for Crash Protected Airborne Recorder Systems）。米国の TSO-C124 系が参照する規格です。規格本体が有償のため一次情報へのリンクが張れず、本文の数値は二次情報によります。 ↩

8. 14 CFR 25.1329（Flight guidance system）。輸送類航空機の型式証明の要件で、現在の形になったのは2006年です。条文の引用は拙訳です。 ↩

9. Regulation (EU) No 376/2014。996/2010 から事象報告の条文（第19条）を引き取って独立した、報告のほうの規則です。報告義務が第4条（72時間は同7項）、任意報告が第5条。報告者の保護は第16条で、報告によってのみ判明した非故意の違反は訴追しない（6項）、懲戒・行政手続で報告者に不利に使わない（7項）、雇用主は報告者を不利に扱ってはならない（9項）と続きます。ただし故意と重過失は対象外です（10項）。前文(5)には「事故はしばしば安全上の事象や欠陥に先行される」「純粋に事後対応的な仕組みは、改善を続けるうえでは限界があると分かっている」とあり、事故調査だけでは足りないことが冒頭に書いてあります。引用は拙訳です。 ↩

10. 14 CFR 25.1309。安全な飛行と着陸を妨げる故障状態は extremely improbable でなければならない、と(b)にあります。10億飛行時間に1回（10のマイナス9乗／飛行時間）という目安は規則本文ではなく、FAA の AC 25.1309-1A が示したものです。25.1329 と同じく輸送類航空機の型式証明の要件で、条文の引用は拙訳です。 ↩

11. NTSB「In-Flight Separation of Left Mid Exit Door Plug, Alaska Airlines Flight 1282, Boeing 737-9, N704AL」（調査番号 DCA24MA063、最終報告 AIR-25-04、2025年6月24日）。勧告 A-25-25 が、飛行後にCVRの記録を保全する手順を標準運航手順・事故後チェックリストへ明記するよう求めるものです。25時間化（A-18-30）と既存機への遡及（A-24-9）も、この報告で再勧告されています。 ↩

12. FAA「25-Hour Cockpit Voice Recorder (CVR) Requirement, New Aircraft Production」（2026年2月2日、最終規則）。同年5月8日に訂正も出ています。対象は今後製造される機体で、既存機は従来のままです。EASAは先行して新造機に25時間を求めていました。 ↩

13. Regulation (EU) 2024/1689（AI Act）。高リスクAIシステムに、ログの自動記録（第12条）と最低6か月の保持（第19条）を課しています。ただし市販前の研究・試験・開発は適用対象外で（第2条6項・8項）、本記事の2件はどちらもその外側にあたります。 ↩