戦闘機の制御ソフトは“入れ替え可能”に？米CCAが示すオープン化の衝撃｜無人戦闘用機(27)

現物としては無人戦闘用機(CCA : Collaborative Combat Aircraft)の話になるが、それ以外の分野にも影響しそうな話が、今回のお題。題して「ソフトウェアのオープン化」である。パソコンやスマートフォンの話ではないが、似たところはある。

• 

  2025年8月に初飛行を実施したばかりの、GA-ASI製YFQ-42 Photo : USAF

閉じる

なぜ飛行中にソフトを切り替えられるのか？

パーソナルコンピュータの分野では、同じハードウェアで異なる種類のオペレーティング・システムを走らせたり、同じオペレーティング・システムの上で異なるアプリケーション・ソフトウェアを走らせたりということが、当たり前のように起きている。

ところが、ウェポン・システムや航空機の分野は事情が異なり、それぞれのシステムあるいは機体のために、専用のソフトウェアを開発するのが普通だ。

例えばF-35は、飛行制御でもセンサーでも武器管制でも、専用のソフトウェアをC++言語で書いている。そのソフトウェアの違いは、「ブロック○○ミッション・ソフトウェア」という名称で区分する。ひとつのブロックの下に、細かいサブ・バージョンの違いがあるところまで、パーソナルコンピュータのソフトウェアと同じである。

GA-ASIはどんな試験を行ったのか？

さて。ゼネラル・アトミックス・エアロノーティカル・システムズ(GA-ASI)が2026年2月12日に、同社が米空軍向けに開発している無人戦闘用機、すなわちCCAのYFQ-42Aで実施した飛行試験について発表した。

YFQ-42A自体は2025年から飛んでいるが、今回の試験の特徴は、初めて、サードパーティ製の自律制御ソフトウェアを組み込んだこと。それが、RTX傘下、コリンズ・エアロスペースが開発した“Sidekick Collaborative Mission Autonomy”である。

つまり、GA-ASIがYFQ-42Aのために開発したソフトウェアだけでなく、コリンズ・エアロスペースが開発したソフトウェアも、同じ機体の上で走ることを立証したわけである。

GA-ASIの説明によると、新しい種類の自律制御ソフトウェアをインストールして、GSC(Ground Station Console)から有効化した。それによってソフトウェアが動き始めれば、そこに地上のオペレーターが指令を送れるようになる。

続いて2026年2月24日に、アンドゥリル・インダストリーズのCCA・YFQ-44Aを用いて、飛行中に2種類のソフトウェアを切り替える試験が行われた。

ひとつはシールドAIが開発した“Hivemind”で、もうひとつはアンドゥリルが開発した“Lattice for Mission Autonomy”。まず、前者を用いて機体を飛ばして、指示されたポイントまで自律飛行を実施、そこで一連の試験を実施した。それが終わったところでソフトウェアを後者に切り替えて、同じ試験を実施した後で基地に戻るとの内容であった。

ノースロップ・グラマンはどんな試験を行ったのか？

また、ノースロップ・グラマンが2026年3月19日に、同社のCCAテストベッド・タロンIQにHimemindをインストールして飛行試験を実施したと発表した。ノースロップ・グラマンは自社で開発したPrismという自律制御ソフトウェアを持っているが、それをHivemindに入れ替えて飛ばしたもの。

同社は翌月の4月にも、タロンIQを用いて飛行中に動的なソフトウェア切り替えを実施する試験を実施した。こちらは、Applied IntuitionのAcuity Air Combat Autonomyソフトウェアから Accelint の自立ミッション・ソフトウェアへと切り替えた。切り替えの際にパフォーマンスへの影響は生じなかったとしている。

• 

  こちらはアンドゥリルが開発しているCCA、YFQ-44A Photo : USAF

A-GRAとは何か？なぜソフトを入れ替えられるのか

サードパーティ製のソフトウェアでも走る、あるいは、飛行中に異なる種類のソフトウェアを切り替えられるということは、ソフトウェアと機体の間のインターフェイス仕様が標準化されているということである。その標準化仕様に則ったソフトウェアを書けば良い。

それが、米空軍がCCAの自律制御ソフトウェア向けに策定した、A-GRA(Autonomy - Government Reference Architecture)。米空軍がA-GRAを策定した狙いは、機体(ハードウェア)と、それを制御するソフトウェアを分離すること。

だから、A-GRAの仕様に合わせて書かれたソフトウェア、それとA-GRAの仕様に合わせて作られた機体(正確には機上コンピュータか)であれば、機体とソフトウェアの組み合わせが自由にできるという話になる。

ソフトウェア分離は何を変えるのか？他分野への影響

開発者が異なれば、自律制御の部分でも、飛行制御の部分でも、センサー制御の部分でも、設計思想の違いや機能的な違いが出てくるだろう。すると、「今回のミッションでは、A社製ソフトウェアの方が向いているので、そちらを使おう」みたいな話が可能になる理屈。

また、あるソフトウェアに致命的なバグが見つかった場合でも、別の同等品を確保できれば、代替手段がなくて頭を抱えるような事態は避けられよう。

同じメーカーのソフトウェアを使い続けるにしても、ハードウェアとソフトウェアをきれいに切り分けてあれば、ソフトウェアだけ、あるいはハードウェアだけを更新するのが容易になるとの期待も持てる。ちょうど、米海軍がイージス武器システム(AWS : Aegis Weapon System)のオープン・アーキテクチャ化で目論んだのと同じように。

さらに話を広げると、基本的に同じ、あるいは共通性が高いソフトウェアを複数機種で共用できる、というところまで話が進む。実際、先に述べたように、HivemindはGA-ASIの機体でもノースロップ・グラマンの機体でも動作する。それなら、理屈の上ではアンドゥリルの機体がA-GRAに対応していれば、そこでも動作するはず。

なにもCCAに限らず、どんな飛行機でもソフトウェア制御の比重が高まってきているのは同じことだから、A-GRAみたいな考え方が広まれば、従来にはなかった運用が可能になるかも知れない。

ソフトウェアを選んだり切り替えたりするだけでなく、機能拡張(プラグイン)みたいな話が出てくる可能性も考えられないか。搭載機器が新しくなったり、新しい搭載機器を付け加えたりしたときに、対応するプラグインを加えればOK。みたいな形で。