航空機の冗長化設計をサーバー設計に持ち込む

はじめに

747のコックピットについて調べてたら、信頼性工学の話に行き着いた。

そしてサーバーの高可用性設計は、航空業界の思想を後から借りてきたものだ。

用語まで輸入してる。Redundancy、FMEA、Fail-safe、MTBF。全部元は航空・軍需・宇宙の言葉。

1920〜30年代多発機。「1基止まっても飛べる」が要件化
1949年米軍規格 MIL-P-1629 でFMEAが成文化
1960年代アポロ計画。三重冗長と多数決
1974年 Tandem Computers が無停止コンピュータを商品化
1980年代〜 RAID、クラスタ、HA構成が一般化

人が死ぬ現場で数十年磨かれた思想を、ITが後から輸入した。だから元ネタの方が成熟してる。逆輸入する価値がある。

信頼性工学、これだけは覚えとくこと

1. 「壊れない」を目指すな。「壊れても動く」を作れ

部品の品質を上げる努力には天井がある。構成で守れば天井がない。

MTBFを2倍にするより、2重化する方が安いし確実。

2. 直列は掛け算、並列は足し算

構成	意味	計算	結果
直列	どれか1つ壊れたら全滅	稼働率を掛ける	99%×3 → 97%。増やすほど悪化
並列	1つ生きてれば動く	故障率を掛ける	1%×3 → 0.0001%。増やすほど改善

自分の構成が直列か並列か、それだけ見極める。

依存が1本増えるたびに、それは直列。

3. 単一障害点は「数」じゃなく「経路」で探せ

これがここでのメモの核心。後述。

4. 冗長度は「失う被害」で決める

747の実際の多重度。

系統	数	全滅したら
油圧	4系統	操縦不能。墜落
発電機	4基＋APU＋外部電源	徐々に系統喪失
空調PACK	3基	与圧喪失。降下すれば助かる
姿勢基準装置	3セット	計器不信

油圧4本、空調3基。この差が答え。

全部を最高冗長にすると、複雑さそのものが新しい故障要因になる。

5. 検知できない冗長は冗長じゃない

予備が壊れてることに気付かないまま本番が落ちたら、冗長化は無かったのと同じ。

これを潜在故障（latent failure）という。

航空機は飛行前点検で予備系を全部起動して確認する。

動かしてないものは動かない。

経路の話:日航123便

1985年。単独機として世界最悪の事故。

何が起きたか

7年前のしりもち事故の修理が不適切。リベットが規定3列に対し実質1列
金属疲労が進展し、後部圧力隔壁が破断
与圧空気が尾部へ噴出。垂直尾翼の約半分が吹き飛ぶ
同時に油圧4系統が全て切断

なぜ4系統あって全滅したか

747の油圧配管は、尾部で1箇所に集中して通っていた。

冗長化されていたはずの4系統が、同じ場所を通っていたために一撃で全滅した。

同じことが他でも起きてる

事故	機種	原因	結果
日航123便 1985	747	隔壁破壊	4系統全喪失。520名死亡
UA232便 1989	DC-10	ファンディスク破裂	3系統全喪失。184名生存
DHL貨物便 2003	A300	ミサイル被弾	3系統全喪失。着陸成功
カンタス32便 2010	A380	エンジン破裂	多数損傷。全滅せず着陸

UA232便が重要。DC-10の設計者はファンディスク破裂を想定していた。

そして「破片が3系統全部を切る確率は10億分の1」と計算して許容した。

そして実際に起きた。

確率計算が間違っていたのではない。「同じ場所を通す」という前提が、破片の前では無意味だった。

冗長化が守るのは「部品がそれぞれ独立に壊れる」ケース。

守れないのが「1つの事象が広範囲を物理破壊する」ケース。

破片は「これは系統2だから避けよう」とは考えない。通り道にあるものを全部切る。

業界が出した結論

確率じゃなく物理で考える ロータバースト・ゾーン（破片飛散範囲）を定義し、その中に重要系統を通すことを禁止
経路を空間的に分離 上下左右前後に離す。同じトンネルを通させない
油圧ヒューズ 破断検知で自動的にその区間を切り離す
電気バックアップ RAT、電動アクチュエータ。787は油圧全滅でも一部の舵面が動く

サーバーに置き換える

AZ（Availability Zone）: クラウドのリージョン内にある、電源・冷却・ネットワークを共有しない独立した区画。同一リージョン内で数km以上離れている。

AZを3つに分けた。これでAZ障害は乗り切れる。

だがリージョンは1つ。事業者も1つ。

このとき分散の効果は、共有している一番上の層で頭打ちになる。

AZを分けた → AZ障害まで守れる
リージョンが同じ → リージョン全体の障害では全滅
事業者が同じ → コントロールプレーン障害では操作すらできなくなる

台数もAZ数も無関係。共有している最上位の層が、その構成の単一障害点。

123便の油圧4系統と同じだ。系統は独立していた。だが尾部という一点を共有していた。

重要なのは「何を分けたか」ではなく「何を共有し続けているか」。

どちらも「数」は足りていた。共有していた一点が全てを持っていった。

補足として、対策後の形も並べるならこれだ。

台数はどの段階でも無関係。経路が同じなら1発で全滅。

物理より厄介な単一障害点

実際に事故るのはこっち。

SPOF	何が起きるか
DNS	何台生きてても名前が引けなければ到達不能
認証基盤	IdPが死ねば全サービス同時停止
証明書	全台同じ日に切れる
設定ファイル	同じ間違った設定が全台に入ってる
デプロイパイプライン	壊れたコードを全台に配る仕組み
運用担当者	その1人しか手順を知らない

デプロイは冗長化が裏目に出る唯一のパターン

物理故障には10台が守ってくれる。

だが同じバグを含むコードを10台に配ったら、10台同時に死ぬ。

冗長化した数だけ被害が増える。

だからカナリアリリース、段階的展開、ロールバック手順がある。

航空機が異なるメーカーの部品をわざと併用するのと同じ理屈。同一設計は同一欠陥で同時死する。

対応表

構造・設計レベル

航空機	サーバー / インフラ	共通する原則
油圧4系統・発電機4基	複数ノード、複数インスタンス	冗長化の基本。並列なら故障率は掛け算で下がる
姿勢基準装置3セットで多数決	Quorum、Raft、etcd の過半数合意	2重では「どちらが正しいか」判定できない。奇数にする
配管を機体の左右上下に分散	マルチAZ、マルチリージョン	数ではなく経路
ロータバースト・ゾーン	障害ドメインの定義	「同時に壊れる範囲」を物理で線引きする
油圧ヒューズ	サーキットブレーカー、Bulkhead	壊れた部分を切って残りを守る
PACK3基、油圧4系統という差	RTO/RPO による優先度分け	冗長度は失った時の被害で決める
異なるメーカーの部品を併用	マルチクラウド、実装の多様化	同一設計は同一欠陥で同時死する
RAT（最後の非常電源）	縮退モード、静的フォールバック	全部落ちても最低限は返す
全エンジン停止でも滑空できる	Graceful degradation	機能を落として生き残る

運用・監視レベル

航空機	サーバー / インフラ	共通する原則
ダークコックピット（正常時は無灯）	アラート設計、正常時は静か	常時警告が出てる状態は設計失敗
琥珀＝注意、赤＝緊急	Severity の階層化	重要度を視覚で即判別させる
飛行前点検で予備系を起動確認	定期フェイルオーバー試験	潜在故障。動かしてない予備は動かない
シミュレータでの定期緊急訓練	カオスエンジニアリング、DR訓練	訓練してない手順は本番で動かない
紙のチェックリスト	Runbook、Playbook	緊急時は認知能力が落ちる。その場で考えさせるな
ステライルコックピット	変更凍結期間、デプロイフリーズ	高リスク時間帯に余計な操作を入れない
CRM（乗員資源管理）	インシデントコマンド体制	誰が判断し誰が手を動かすか事前に決める
事故報告書の全世界公開	ポストモーテムの共有	一件の失敗を全体の学習にする
非懲罰的報告制度	ブレームレス文化	罰すると隠す。隠されると学習できない
耐空性改善命令	パッチの強制適用	教訓を全台に確実に反映させる

設計哲学レベル

航空機	サーバー / インフラ	共通する原則
フェイルセーフ（安全側に倒れる）	Deny by default、書き込み拒否	迷ったら安全な方へ落ちる
フェイルオペレーショナル	HA構成、自動フェイルオーバー	止めずに動かし続ける
フェイルソフト（性能低下で継続）	レートリミット、機能縮退	全滅より部分継続
FMEA	障害シナリオ分析	全要素に「これが消えたら?」を問う
使用頻度の高い操作を手元に配置	UI/CLI設計、危険操作にガード	物理的距離が優先度を表す
ファイアハンドルの2段階動作	破壊的操作の二重確認、--force要求	致命的操作は意図の明示を要求する
油圧を全喪失させない設計へ投資	復旧手順より予防に投資	PCAは実用化されず、根本対策が選ばれた

FMEA:全要素に「これが消えたら?」を聞く

Failure Mode and Effects Analysis（故障モード影響解析）。

1949年に米軍規格 MIL-P-1629 として成文化され、アポロ計画で本格運用された。今はISO規格。これも航空・軍需からの輸入品。

「これが壊れたら何が起きる?」を全構成要素に対して1つずつ聞く。

表の形

列	意味
構成要素	何が
故障モード	どう壊れるか
影響	何が起きるか
発生頻度	起きやすさ
検知性	気付けるか
深刻度	どれだけまずいか
RPN	頻度 × 検知性 × 深刻度
対策	どうするか

RPN（Risk Priority Number）の大きい順に対策する。

インフラでやるとこうなる

構成要素	故障モード	影響	検知	深刻度	対策
DBプライマリ	プロセス停止	書き込み不可	即時	高	自動フェイルオーバー
DNS	名前解決不能	全サービス到達不能	遅い	最高	セカンダリDNS、TTL短縮
TLS証明書	期限切れ	全接続拒否	切れるまで気付かない	最高	自動更新、期限監視
IdP	認証不能	ログイン全滅	即時	最高	緊急バイパス経路
デプロイ基盤	不正な設定を配布	全台同時死	遅い	最高	カナリア、段階展開
運用担当A	離職・病欠	復旧手順不明	事故時に判明	高	Runbook化、複数人訓練

潜在故障:持ってることと、使えることは別

「使わないから壊れない」は間違い。使わなくても劣化する。

ゴムは硬化する。潤滑油は固着する。電池は自己放電する。接点は酸化する。可動部は動かさないと固まる。

動かさないことそのものが故障原因。

そして最悪なのは、壊れていることに誰も気付けない点。本番が落ちた瞬間に初めて分かる。これを潜在故障（latent failure）という。

ITでの対応物

対象	確かめ方
バックアップ	定期的に実際にリストアする
スタンバイDB	定期的に昇格させる
フェイルオーバー	本番で計画的に実行する
DR環境	定期的に切り替えて業務を通す
Runbook	訓練で実際にコマンドを叩く
連絡網	抜き打ちで疎通確認

Netflix の Chaos Monkey が本番サーバーをランダムに落とすのは、これが理由だ。

「壊れたら困る」を待つのではなく、平時に自分から壊して、予備系が本当に動くか確かめる。

RAT(非常発電装置)を定期展開するのと、思想として完全に同じ。

結論

確かめていないものは、持っていないのと同じ。

冗長化した数を数えても意味がない。その予備が今この瞬間に動くかどうか、確かめた日付を言えるか。それが可用性の実態だ。

本当の価値は「検知性」の列

見落とされるのは「壊れてることに気付けるか」。

証明書の期限切れ → 切れた瞬間まで誰も知らない
予備系の故障 → 本番が落ちるまで分からない（潜在故障）
バックアップの破損 → リストアするまで分からない

航空機が飛行前点検で予備系を全部起動するのは、検知性を人工的に上げているから。

やる時のコツ

部品じゃなく「消えたら困るもの」から始める サーバー、ネットワーク、DNS、認証、証明書、デプロイ経路、人。
「壊れる」を広く取る 止まる / 遅くなる / 間違った答えを返す / 気付かないうちに壊れてる。3つ目が一番厄介。止まってくれた方がマシ
全部対策しようとしない RPNで並べて上から数件。油圧4本、空調3基の話と同じ
一度やって終わりにしない 構成が変わったら更新する。航空機も設計変更のたびにやり直す

運用者が知らないものは、疑えない

737 MAXで何が起きたか

2018年ライオンエア610便、2019年エチオピア航空302便。346名が死亡した。

原因は MCAS という自動補正システムの誤作動だった。

737 MAXは大型エンジンを前上方に搭載した結果、機首が上がりやすい特性が出た。MCASはこれを検知して、自動で機首を下げる。

問題はここだ。

機体には迎角センサーが左右2つある
だがMCASは1つしか参照しない設計だった
センサー1個の誤作動が、そのまま操縦を奪う
さらにMCASの存在がマニュアルにほぼ記載されていなかった

パイロットは、自分の機体に何が積まれているかを知らなかった。

知らないものは疑えない

610便の乗員は、機首下げが20回以上繰り返される中で必死に引き戻し続けた。

だが何が起きているかを理解する手段がなかった。存在を知らないシステムは、原因候補にすら挙がらない。

そして事故後、ボーイングとFAAは運航を停止しなかった。手順通知だけを出した。

5ヶ月後、302便の乗員はその手順を知っていた。通知通りに実行した。

だが機体はすでに高速・機首下げ状態にあり、空気力に押されて手動トリムホイールが物理的に回せなくなっていた。手順は本番で動かなかった。

157名が亡くなった。

冗長化されていたのは物理層だけだった

センサーは2つあった。冗長化は物理的に用意されていた。

だがソフトウェアが1つしか読まなかった。

事故	用意されていたもの	実際
日航123便	油圧4系統	経路が1つ
737 MAX	AoAセンサー2つ	参照が1つ

リソースを冗長化しても、それを使う側が単一なら意味がない。

インフラで全く同じことが起きる

用意したのに使っていないパターン

マルチAZにDBを置いたが、アプリの接続先がプライマリ固定
LB配下に10台あるが、セッションが1台に固定
監視データを2系統で集めているが、アラート判定は片方だけ
バックアップを2箇所に取っているが、リストア手順が片方しか書かれていない

「用意した」と「使っている」は別。

運用者が知らされていないパターン

知らされていないもの	障害時に何が起きるか
なぜこの構成なのか	触っていい部分が分からず手が止まる
どこが単一障害点か	疑う場所が分からない
過去に何が起きたか	同じ障害を初めての障害として扱う
自動化が裏で何をしているか	意図しない動作を人為ミスと誤認する

最後が一番危ない。自動化されたシステムが「善意で」何かをしているとき、運用者はそれを異常と判別できない。MCASそのものだ。

「知らされていない」は3種類ある

意図的に隠された 737 MAXがこれ。悪意ではなく「訓練コストを増やしたくない」という営業判断だった
伝えたつもりで伝わっていない ドキュメントには書いてある。だが誰も読んでいない。存在を知らないドキュメントは無いのと同じ
誰も知らない 作った人が退職した。判断理由が失われた。これが一番多い

対策

自動化には必ず可視化を付ける 自動でやるなら、やったことをログに残し通知する。「勝手に直った」は「何が起きたか誰も知らない」と同義
無効化手段を用意する MCASの修正で追加されたのがこれ。パイロットが常に上書きできる。自動化に人間が勝てない設計は危険
設計判断の理由を残す ADR(Architecture Decision Record)。「なぜこうしたか」は数年で必ず失われる
運用者を設計に参加させる 運用する人が設計を知らない体制そのものが欠陥

そして責任の話になる

事故が起きたとき、こう言われる。

「手順通りやらなかった」「オペレーションミスだ」

だが判断材料がなければ、正しい判断は不可能だ。

航空業界はここを50年かけて転換した。「なぜミスできる設計だったのか」を問うようになった。人を責めても再発は防げないからだ。

IT側はまだ「担当者のオペミス」で片付ける現場が多い。

結論

冗長化も、手順書も、自動化も、運用者が「何が起きているか分かる」ことを前提にしている。

その前提が崩れていたら、他がどれだけ完璧でも意味がない。

346名が亡くなったのは、センサーが壊れたからではない。

壊れたことを知る手段が、操縦席になかったからだ。

やること

構成図を出して、要素を1つずつ指で押さえて「これが消えたら何が死ぬ?」を聞く。

FMEAの本質はこれしかない。

聞く順番。

物理（ラック、電源、AZ、リージョン）
ネットワーク（スイッチ、経路、帯域）
認証（IdP、証明書、鍵）
名前解決（DNS）
デプロイ（CI/CD、設定配布）
人（属人化してる手順）

だいたい3〜6で出てくる。

そして出てきた全部を冗長化しようとするな。

油圧は4本、空調は3基。失った時の被害で優先順位を付ける。

IT側が借りきれてない3つ

構造の冗長化はコピーできてる。足りてないのは運用文化の方。

潜在故障の検査 予備系を定期起動する文化がまだ薄い
非懲罰的報告 制度として持ってる組織は少数
教訓の業界共有 航空は事故報告書を公開する。ITは社内で閉じがち

訓練されていない人間を前提に設計する

ここまでは運用者の話だった。ここでエンドユーザーの話をする。

航空機の乗客と、ITのエンドユーザーは同じ立場に置かれている。

専門知識がない
訓練を受けていない
それでも最低限の操作を要求される
失敗すると失うのは自分
説明されても聞いていない

航空業界はこの前提を受け入れた上で設計している。

航空業界が採った4つの戦略

1. 説明はする。効果が薄くても続ける

全員が見ないと分かっていても、セーフティデモは毎便必ず流す。やらないよりは確実に生存率が上がるから。事故調査でも「デモを見ていた乗客の方が生存率が高い」という指摘が繰り返し出ている。

2. 説明に頼りきらない

聞いていなくても助かるように、座席のしおり、床面の誘導灯、乗員の誘導で多重化する。

3. 判断させない

緊急時、乗員は叫ぶ。「荷物を置け」「こっちへ来い」。どうすべきかを考えさせない。選択肢を与えない。

4. 失敗の被害を設計で抑える

聞いていなくても、座席は16Gの衝撃に耐える。内装は難燃素材で、燃えた時の有毒ガスまで規制されている。個人の行動に依存しない防御を先に置く。

ユーザーの「失敗」は何に対応するか

ユーザー側で起きること	何が起きているか	有効な設計
振り込め詐欺	緊急時に判断を誤る。急かされると検証しない	時間を挟む。高額振込の遅延、確認画面での警告、ATMでの通話制限
フィッシング	偽の指示に従う。見分けは人間には困難	本人に判断させない。パスキー、ドメイン照合を機械がやる
簡単なパスワード	そもそも訓練されていない	強度を人間に判斷させない。パスキー、パスワードマネージャ、バリデーション
アカウント情報の管理不備	平時は使わないものを、いざという時に使えない	リカバリーコードを事前に検証させる。多重の復旧経路
対策していない端末	設定は誰もしない	デフォルトで有効。OS標準で守る
個人情報の意図しない公開	不可逆な操作を軽く実行してしまう	公開範囲のデフォルトを閉じる。公開時に警告と猶予
デマを信じる	判断材料がないまま判断させられる	出所の表示、ラベリング、一次情報への導線
権限の与えすぎ	誰が何をできるかを考えていない	危険な操作ができる人を事前に絞る
復旧手段の喪失	締め出されてから気付く	独立した復旧経路。使う前に一度検証させる

共通する結論

ユーザーに正しい行動を期待する対策は、必ず失敗する

「強いパスワードを設定しましょう」 → 守られない
「怪しいリンクは踏まないで」 → 踏む
「公開範囲を確認して」 → 確認しない

航空機が「乗客が説明を聞く」前提で設計されていないのと同じだ。

セキュリティも「ユーザーが正しく行動する」前提で組んではいけない。

それでも説明はやめない

ここが重要だ。航空業界は全員が見ないと分かった上で、毎便必ず流し続けている。

効果がゼロではないからだ。

だから結論はこうなる。

教育は続ける。だが教育に依存しない

層	役割
説明・教育	効果はゼロではない。届く人には届く
デフォルトで安全	説明が届かない人を守る
不可逆操作への摩擦	判断を誤っても取り返せる
被害の上限	全部突破されても全損しない

1枚では止まらない。重ねて止める。多層防御そのものだ。

非常口座席

15歳以上
重いドアを操作できる体力
乗務員の指示を理解できる言語能力
同伴者の介助が必要ないこと

そして必ず口頭で確認し、本人の同意を得る。「緊急時に手伝えますか」と聞く。

これは権限管理そのものだ。

危険な操作ができる立場に誰を置くかを事前に決めて、本人に自覚させる。

「権限を持っていることを本人が知らない」状態が、一番危ない。

それでも起きた後の設計

ここまでは「起こさない」「起きても飛び続ける」話だった。最後はそれでも起きた後だ。

ここが最も手薄になる領域でもある。

サバイバブル・クラッシュという考え方

墜落の多くは、人間が生き残れる衝撃の範囲内で起きている。

死因になるのは衝撃そのものより、その後に起きることだ。だからそこを設計する。

16G要件 座席が前方16Gに耐える。座席が壊れて投げ出されるのを防ぐ
キャビン構造の保持 客室空間が潰れないように主構造を設計する
主脚の設計 胴体着陸時、脚が折れる方向を制御する。燃料タンクを突き破らない向きに壊れる
エンジンの脱落設計 過大な力がかかったら主翼から離れて落ちる。翼を引き裂いて燃料タンクを破るより、捨てた方がいい

壊れ方を設計する。これが本質だ。

火災を遅らせる

墜落後の最大の死因は火災と煙だ。だからここに最も投資されている。

難燃性内装 燃焼試験に合格した素材のみ
有毒ガス規制 燃えにくいだけでなく、燃えた時に何が出るかまで規定
座席の火炎遮断層 クッション材への延焼を遅らせる
燃料タンクの不活性化 タンク上部の空間に窒素を注入し、爆発しない濃度に保つ。TWA800便事故(1996)を受けて義務化

90秒ルールの90秒は、この火災が致命的になるまでの猶予から逆算されている。

原因を残す:ブラックボックス

ここが航空業界の真骨頂だ。

FDR 飛行データ記録装置。数千項目のパラメータを記録
CVR 操縦室音声記録装置

要求性能が異常に高い。

条件	要求
衝撃	3400G
火災	1100度で60分、260度で10時間
水圧	深度6000m相当で30日
圧壊	2270kgで5分
貫通	227kgの鋼杭を3mから落下

試験は空気砲で壁に撃ち込む。そして機体で最も壊れにくい尾部に搭載する。

機体が全損しても、記録だけは残るように設計されている。

そして守っているのは記録データだけだ。周辺回路は壊れてもいい。守る対象を極限まで絞っている。

一機の事故が、全世界の同型機を安全にする

独立した調査機関が調査する(運輸安全委員会、NTSB)
責任追及と原因究明を分離する
報告書は全世界に公開される
耐空性改善命令で全同型機に改修が強制される

この記事で挙げた設計の多くが、この経路で生まれた。

事故	生まれたもの
日航123便 1985	油圧経路の分離、油圧ヒューズ
マンチェスター空港火災 1985	床面誘導灯、難燃素材の強化
TWA800便 1996	燃料タンクの窒素不活性化
テネリフェ 1977	CRM訓練、無線用語の標準化
エールフランス447便 2009	ピンガーの長寿命化、ピトー管の改修
737 MAX 2018/2019	MCASの両センサー参照、AoA警告の標準装備

IT側:全部が消えても残るもの

何を残すか

守る対象は極限まで絞る。全部残そうとすると、全部失う。

優先度	残すもの	理由
最優先	何が起きたかの記録	これが無いと原因が分からず、同じ障害を繰り返す
最優先	構成の定義(IaC・設定)	これがあれば作り直せる。環境そのものより価値がある
高	データのバックアップ	ただしリストア検証済みのものだけが資産
高	復旧手順(Runbook)	頭の中にしかないものは失われる
中	連絡体制と権限情報	誰に何を頼めるか

ブラックボックスの4条件を満たしているか

1. 対象と物理的に分離されているか

尾部に積む理由がこれだ。機首が潰れても残る場所を選んでいる。

ログを監視対象と同じアカウント・同じリージョンに置いていないか
バックアップを本番と同じ認証基盤の配下に置いていないか
同じ事業者に依存していないか

2. 書き込まれたら改変されないか

失うのは障害だけとは限らない。改竄、誤削除、ランサムウェアでも失う。

追記のみ(append-only)
オブジェクトロック、WORM
バージョニングとMFA Delete

3. 記録側が対象に依存していないか

FDRは機体の電源が落ちても記録を続ける独立電源を持つ。

ログ転送がアプリケーションのプロセスに乗っていないか
障害時に転送経路ごと死なないか
落ちる直前の数分間が一番重要なのに、そこが欠ける設計になっていないか

4. 取り出せることを確認済みか

潜在故障の話だ。

ログを実際に検索・取得したことがあるか
バックアップを実際にリストアしたことがあるか
いつ確認したかを言えるか

最も見落とされる生き証人

**CVR(操縦室音声記録装置)**に相当するものだ。

なぜ音声まで記録するのか。データだけでは「なぜそう判断したか」が分からないからだ。

FDRは何が起きたかを記録する。CVRは乗員が何を考えていたかを記録する。両方揃って初めて原因が分かる。

IT側での対応物はこれだ。

インシデント対応中のチャットログ 何をどう判断したか
タイムライン いつ何に気付き、何を試したか
ADR なぜその設計にしたか

復旧が終わってから思い出そうとしても、もう思い出せない。

対応中に流れたSlackを保存しておけ。あれがCVRだ。

検査:今この瞬間に全部消えたら

本番環境が今この瞬間に全て消えたとして、何が手元に残るか。

消えた原因は分かるか
同じものを再構築できるか
どの時点のデータまで戻れるか
誰がそれを実行できるか

4つとも答えられなければ、まだブラックボックスを積んでいない。

対応表

航空	IT
壊れ方を設計する	障害時の縮退挙動を定義する
火災を遅らせる	被害の拡大を止める。サーキットブレーカー、隔離
90秒で脱出	復旧目標時間(RTO)を数字で決める
ブラックボックス	ログを障害の外側に保存する
尾部に搭載	監視・ログ基盤を対象と同じ場所に置かない
守るのは記録データだけ	守る対象を絞る。全部を守ろうとしない
責任追及と原因究明の分離	ブレームレス・ポストモーテム
報告書の全世界公開	障害報告の共有
耐空性改善命令	得た教訓を全システムに反映する

結論

残すべきはシステムではない。システムを作り直せるものと、なぜ壊れたかの証拠だ。
環境は再構築できる。データは復元できる。
だがなぜ壊れたか分からなければ、作り直したものも同じように壊れる。
航空業界が3400Gと1100度に耐える箱を作ったのは、機体を守るためではない。
次の便に乗る人を守るためだ。

おわりに

747のコックピットは、スイッチ1個、ハンドルのロック1つ、パネルの配置1つに理由がある。
あの操縦席は、100年分の事故報告書が物理的に形になったもの。

だから航空事故報告書はインフラ屋の教材として本気で使える。NTSBのは全部公開されてる。

ここで扱った事故には、いずれも多くの犠牲がある。

日本航空123便は520名が亡くなった。ユナイテッド232便では112名が亡くなっている。

ここに書いた設計原則は、すべてその犠牲の上に得られたものだ。

航空業界が事故報告書を全世界に公開し続けているのは、二度と同じことを起こさないためだ。
教訓を技術として受け継ぐ意図でここにメモを残す。

日本航空は御巣鷹の事故を風化させないため、社内に安全啓発センターを設けて機体の残骸と遺品を保存・展示している。新人教育で必ず訪れる場所になっている。

United 232便 油圧全喪失からエンジン推力だけで着陸を試みた
British Airways 9便 火山灰で4発全停止からの再始動
Qantas 32便 多重損傷を受けながら着陸に成功した設計改善の成果