ソフトウェア保証とサイバーセキュリティへの教訓。
「飛行機に乗るべきです。 そのほうが安全です」
事実です。自動車での移動と比べれば、確率はあなたに味方します。差は歴然で、私たちは飛行機を怖がる旅行者にそう言ってよく念押しします。
それでも、私が知る最も賢い人たちのうち2人は、この統計に同意しながらも飛行機に乗ろうとしません。私は搭乗するたびに彼らのことを思い出します。 数週間前にJetBlueの便がたどった北行きの経路の一部をなぞるJetBlue便で休暇から戻ったときも、それは同じでした。
問題となった便も、おそらく休暇客でいっぱいだったのでしょう。2025年10月30日、メキシコのカンクン国際空港からニューアーク・リバティ国際空港へ向かうエアバスA320の旅です。翌日にニューヨーク・タイムズが報じたところによれば、メキシコのリゾートを出発して2時間半ほど経った頃、1230便の乗客はうとうとしていた可能性が高いのですが、突然の高度低下で叩き起こされました。望まれない曲芸飛行が終わった後、15人以上の乗客が不本意ながら休暇を延長し、タンパの病院で治療を受けることになりました。JetBlueのパイロットはそこで緊急着陸を成功させたのです。
JetBlueの担当者は、機体は点検のため運航から外されたと述べました。
商業航空では、まれな大惨事に加え、ときおり事故やトラブルが起きます。一般の利用者にとって、こうしたトラブルの報道は定期的に目にする程度にはあるため、この手のニュースは、より大きなパターンが見えてくるまで安全に引き出しにしまっておけます。理解できることですが、もしこれで話が終わっていたなら、なおさらそうだったでしょう。特に、737 Maxの問題が始まって以来、この種の望まれないスリルの対象はボーイング機であることが多かったのですから。このJetBlue便に関わった機体も、そしていま私が23A席に座っている機体もエアバスで、2024年2月のFAA専門家パネル報告書が「ボーイングの安全への取り組みにおけるギャップ」と呼んだような問題の影響を受けにくいと考えられていました。
これがあの機体か、と私は思いました。続く調査で何が明らかになったのか。機械的故障？ ソフトウェア、ひょっとするとマルウェア（ただし可能性は非常に低い）？
「原因」
タイムズは、2025年11月28日、私がJFKへ戻る便に乗ったその日に、その調査結果をきちんと報じました。記事は一部、エアバスのプレスリリースを基にしており、次の一文で始まっていました。
欧州の航空機メーカーは、最近の事案により「強い太陽放射が、飛行制御の機能にとって重要なデータを破損させる可能性がある」ことが示されたと述べた。
エアバスA320の機材群と、それを運用する航空会社への影響は広範に及ぶでしょう。 タイムズは、世界中の航空会社がA320をどの程度採用しているかを調べたうえで、最大6,000機が影響を受け、一部はハードウェア変更が必要になる可能性があると報じました。
それは大きな影響だ、と私は思いました。そして次を読みました。
多くの場合、この問題は以前のソフトウェア・バージョンに戻すことで比較的迅速に対処できる。
待ってくれ。
「単一事象効果」
では、この放射線の影響はどれほど頻繁に起きているのか。 根底にある物理は何なのか。
実は、そこには語るべき科学史があります。ノーベル賞受賞者のビクター・ヘスは、気球飛行で高高度の放射線レベルを測定し、宇宙線の存在を発見しました。第一次世界大戦より前のことです。1960年代には宇宙計画で乗員の健康上の懸念となりました。1975年の論文は、衛星の異常を放射線による「単一事象効果（SEU）」として特定し、1979年までには、電子機器が海面高度でも影響を受け得ることが理解されていました。
1990年までにFAAは、航空旅行者にリスクがあることを認めました。コンピュータへの依存度が高いフライ・バイ・ワイヤ機であるエアバスA320は、この現象が航空工学コミュニティでよく理解されていた時代に設計されました。
当時のソフトウェアエンジニアなら理解していたように、SEUへの対処にはハードウェアとソフトウェアの機能が必要です。たとえばECCメモリ。 また、ビット反転によって極端に範囲外の命令が生成される場合に備えたサニティチェックも。
機能。 では、なぜ2025年後半のA320で、ソフトウェアを以前のバージョンにロールバックすることが対策になるのでしょうか。 放射線によるSEUに対処するための機能は、現行リリースにあるなら以前のリリースにもあるはずでは？ それとも、以前のリリースで採られていた手法を置き換えるような、SEUへの新しい革新的な対処法が導入されていたのでしょうか。
ソフトウェア・ライフサイクル管理の基礎
この時点で、私の中のソフトウェア品質エンジニアが身を乗り出しました。どういうわけか、放射線という話の全体が、妙に本筋と関係がないように思えたのです。
疑問を抱いたのは私だけではありませんでした。
トニー・フェルナンデスはAirAsia Aviation Groupの創業者です。AirAsiaの現在の運航には相当数のエアバス機が含まれ、さらに約400機のエアバス機を発注しています。フェルナンデスは最近のインタビューで懸念を表明しました。
「少し奇妙に思えます。これは（エアバスが）検討しなければならないことで、明らかにテストされていなかったのでしょう」とフェルナンデスはサウスチャイナ・モーニング・ポストに語りました。フェルナンデスは、エアバスが2025年に820機を生産するという現在の目標を達成するためのコミットメントで逼迫している可能性があると推測しました。
目を引く放射線のストーリーラインとは別に、表面的な原因は、機体のピッチとロールを管理し、パイロットのサイドスティックから機体後部の昇降舵へコマンドを送るエレベーター・エルロン・コンピュータ（ELAC 2）のソフトウェア問題として説明されました。ソフトウェアのロールバックは「L104」を「L103」と呼ばれるバージョンに戻すものでした。ELACハードウェアの開発元であるタレスは、当該ソフトウェアは自社の責任ではないとロイターに述べました。
ニューアーク行きのJetBlue便で乗客が経験した突然の機首下げは、A320だけでなく、さまざまなエアバス機種にも影響し得ます。 A319およびA321系列の複数のバリエーションも影響を受けます。ある推計では、エアバスの発表時点で3,000機以上のA320が空を飛んでいた可能性があるとされました。11月28日の乗客たちを想像してみてください。機内WiFiを備えた人も多く、このソフトウェア脆弱性について読み、安全性の計算を頭の中でやり直していたことでしょう。
SDLCの教訓4つ。屈しない固有リスク2つ
扇情的な「太陽放射」や「宇宙線」の話を超えて、エアバスには真剣なソフトウェア開発ライフサイクル（SDLC）の議論が必要です。私なら、主な示唆を4つ挙げます。いずれもおなじみのものです。
- テストエンジニアリング
- CI/CDとパイプライン品質
- オブザーバビリティ
- サプライチェーン
「コーディング」が示唆の一つに入っていないことに注目してください。 確かにL104で、ビルドのパッケージングミスや、サービス呼び出しの誤削除、APIパラメータの誤設定または誤解、あるいはソースコードの構文エラーといったコーディングエラーが入り込んだ可能性はあります。これらはどれも普通に起こり得ることで、健全なSDLCはそれに対処します。
- テストエンジニアリング。優れたテストハーネスがあれば、ELACのレンジチェックを呼び出すはずだった帯域外テレメトリをシミュレートできます。 テストハーネスは、ソフトウェアとは別工程としてではなく、ソフトウェアと同時並行で設計・構築される必要があります。
- CI/CDとパイプライン品質。このグループに変更管理や構成管理を加えてもよいでしょう。エアバスがL104のSDLCパイプラインでCI/CDを使っていたかどうかにかかわらず、今後はその方向へ進むはずです。SDLCパイプラインのどこかが壊れ、この基本機能が「リグレッション」することを許してしまいました。 原因が一度きりの偶発的なものとは考えにくいです。
- オブザーバビリティ。これは、私がIEEEの小さなワーキンググループの一員として、オブザーバビリティ原則を取り込む新しいDevOps標準の策定に取り組んでいることもあり、加えました。SEUはオブザーバビリティの優れたユースケースです。なぜなら、テストエンジニアは宇宙線が当たるのを待つわけにはいかない一方で、重大なSEUイベントへの応答失敗が観測可能であることを保証しなければならないからです。これには、より慎重な要求工学と、重要機能に必要なテレメトリの理解が伴います。
- サプライチェーン。タレスがL104の問題のあるリリースに関与していなかったとしても、エアバスのプラットフォームには多くのサプライヤーのソフトウェアとハードウェアが含まれます。コンピューティングのサプライチェーン全体にまたがる統合は、安全要件と望まれる製品寿命の双方によって増幅される課題をもたらします。タレスの「うちの問題ではない」という趣旨の反応は、共同での情報共有や問題解決に課題があること、あるいはサードパーティリスク管理チームの可視性が限定的であることを示している可能性があります。
事態はさらに悪化し得ます。SDLCのこれら4領域のいずれか一つでも欠落があれば、マルウェアの入り込む機会が生まれ、アビオニクスにとっては悪夢のシナリオとなります。
AIが救う？
私が懸念するのは、固有のリスクが2つ、いまだ十分に緩和されていないことです。複雑性と専門化です。A320の機能セット全体、あるいはソフトウェア部品表（SBOM / API-BOM）でさえ管理するのは容易ではありません。1987年に投入された製品であり、広範な導入済み機材群にわたってレガシーのハードウェアとソフトウェアをサポートする必要があることを考えてください。 複雑性と専門化はいずれも、着実に不透明さを増し、トレーサビリティ、透明性、管理可能性の確保を難しくしていくでしょう。
間違いなくエアバスも、私たちと同様に、支援のためにAIを取り込むでしょう――おそらくL105で。これは必要となる専門性を増やし、機体全体の複雑性も増します。 AI一般に対する世間の不安を考えると、どの時点で、より多くの旅行者が「確率は自分に味方している」と感じなくなるのでしょうか。
この記事はFoundry Expert Contributor Networkの一環として公開されています。
参加したいですか？
