ソフトウェアの観点から見た将来戦闘機(8)コンセプトとアーキテクチャの重要性

これまで複数回にわたり、「将来戦闘機に関わりそうな機能・能力」について、それを実現するためのソフトウェアという観点を中心にして、いろいろ書いてきた。今回は、根本的なところで「そもそも将来戦闘機とは」という話を書いてみたい。

戦闘機はSystem of Systemsを構成するパーツの1つ

これまで述べてきた機能・能力とは、要するにサブシステムである。さまざまなサブシステムが集まり、互いに連携することで、戦闘機という1つのシステムができる。これはサブシステムの集合体だから、System of Systemsである。

ところが、その戦闘機も、「航空戦を行う組織」を構成するサブシステムの1つである。普通、「航空戦を行う組織」のことを空軍というが、日本では航空自衛隊といっている。看板は違っていても、意味としては同じである。

戦闘機以外にも、レーダーサイトや早期警戒機といった探知手段、パトリオットのような地対空ミサイル、それらを指揮管制するJADGE(Japan Aerospace Defense Ground Environment)システムとそれを扱う管制官、そして人材を育成するための教育訓練、装備品や人を動かすための兵站支援。これみんな、「航空戦を行う組織」を構成するサブシステムである。

そして、その「航空戦を行う組織」は、陸海空をはじめとするさまざまなドメイン(領域)をカバーする「国防のための組織」を構成するサブシステムの1つである。

さすがに、System of Systems of Systems of……なんていい方はしないが、実際にはさまざまなサブシステムが階層を構成して互いに連動・連携しながら機能することで、初めて国防が成立している。ということは、どんなサブシステムを、どう組み立てて、どう機能させるか、というアーキテクチャが大事になるはずだ。

• PAC-3 MSEのテストの様子(PATRIOT Advanced Capability-3 Missile Segment Enhancement)　写真：US Army

• PAC-3 MSEが弾道ミサイルのテスト中にターゲットを攻撃している様子(PATRIOT Advanced Capability-3 Missile Segment Enhancement)　写真：US Army

航空戦のコンセプトとアーキテクチャ

お題が将来戦闘機だから航空戦の話をすると、「空の上ではどのような脅威が想定されるか」「それに対して、いかにして立ち向かい、勝利を収めるか、せめて負けずにしのぎきるか」ということを考えなければならない。

スポーツの試合とは話が違うから、「どういうルールで戦うのが、我にとって最も有利なのか」ということを考えなければならない。それがあって初めて、「どういう組織を構築して、何をどれだけ用意するか」が決まるし、そこで重要な位置を占めるサブシステムである戦闘機についても、「どういう機能・能力が必要か」がわかってくる。

その、コンセプト(どう戦うか)、そしてアーキテクチャ(どういう「戦うシステム」を構築するか)に関するグランドデザインを欠いた状態、あるいは不明瞭な状態で、「カタログ値で仮想敵機に勝てる機体を」と考えるだけでいいのだろうか?

どう戦うかが決まって初めて、どんな機能・能力が必要になるかがわかる。「こんな機能・能力があるから、それを使ってどう戦おうか」では本末転倒。ましてや、「他国でこんなことをやっているから、バスに乗り遅れるな。うちもやる」では、グランドデザインがお留守になりかねない。

寡を持って衆を制す…… ?

対空戦の場合、最終目標は「飛来する敵機を叩き落とすか、せめて追い払って、日本の上空で好き勝手にさせないこと」といえる。こちらの方が質的・数的優勢にあれば実現はしやすいが、第2次世界大戦が終結してからこちら、あいにくとそんな状況になったことはない。

時代劇だと、善玉の方が数が少ないのに、腕にモノをいわせてチャンチャンバラバラ、最後には悪玉はみんな地面の上に倒れている、という終わり方がお約束。だが、現実の航空戦が、そんな簡単にいくものだろうか?

「寡をもって衆を制す」はキャッチフレーズとしては華々しいけれども、普通に真正面から渡り合っていたら、最後には押し負けてしまうのではないか?　もっとこすっからく、陰険に、不意打ちでも何でもやって相手の裏をかく必要があるのではないか?

それであれば、それを実現するためにはどういう航空戦のありようが求められるのか、を考える必要がある。そして導き出した結論に対して、これまで述べてきたような各種のサブシステムあるいは要素技術を、どのように組み立てて、はめ込んでSystem of Systemsを構築するか。本当に真剣に考えなければならないのは、そこではないか。

システム開発のお仕事に携わった経験がある方なら、最初のアーキテクチャ設計が大事だということはおわかりいただけると思う。アーキテクチャに問題があると、後で開発やインテグレーションに苦労したり、拡張性・発展性がなくて頭を抱えたりする。そういう話である。

個別の要素技術だけ取り上げて「こんなにいいものができました。仮想敵国のものよりも優れた数字が出ています。すごいでしょう」だけで、果たして戦の役に立つのか。

筋論からいえば、実際に航空戦の最前線にいる人が音頭をとって「将来航空戦のビジョン」(注 : 将来戦闘機のビジョンではない)をとりまとめた上で、そこからブレイクダウンする形でアーキテクチャを策定して、技術開発を進めていかなければならないのではないか。

なのに、そのアーキテクチャを構成するサブシステムの1つ(戦闘機のこと)にだけ焦点を当てるだけでいいのか。もちろん戦闘機の性能が良く、優れた能力を備えているに越したことはないが、その能力を発揮させるには、もっと上のレベルでのお膳立てが必要になるのではないか。

第356回で取り上げた策源地攻撃の話が典型例で、「長い槍」だけでは成立しない。ターゲティングのための「遠くを見る目」がなければ始まらない。それらをどう組み合わせて、どう連携させるか。これはまさにアーキテクチャの問題である。

プラットフォーム中心、ハードウェア指向の考え方から距離を置いて、航空戦のビジョンや、そのためのグランドデザイン、それを具現化するためのアーキテクチャということも考えてみていいのではないか。そこでは、「これまで○○を使っていたのだから、後継も同じカテゴリーのものを」という前動続行はひとまず御破算にして、ゼロベースで考えなければならない(結果として同じになったというのはありだが)。