ミサイル防衛に関する最近の話題(9)ノースロップ・グラマンのIBCS

日本では、ミサイル防衛を受け持つシステムというと、イージスBMDの知名度が高い。また、アメリカ本土にはC2BMC(Command and Control Battle Management Communications)という指揮管制システムがあり、これは米海軍のイージス艦ともリンクしている。ところがアメリカには、もうひとつ、ミサイル防衛関連の指揮管制システムがある。

日本では、ミサイル防衛を受け持つシステムというと、イージスBMDの知名度が高い。また、アメリカ本土にはC2BMC(Command and Control Battle Management Communications)という指揮管制システムがあり、これは米海軍のイージス艦ともリンクしている。ところがアメリカには、もうひとつ、ミサイル防衛関連の指揮管制システムがある。

陸軍の野戦用として開発されたIBCS

それがノースロップ・グラマンのIBCS。手元のデータを調べてみたところ、最初に話が出たのは2006年、開発が決まったのは2010年初頭のこと。想定した脅威は、航空機、巡航ミサイル、弾道ミサイルといったところ。

当初の狙いは、陸軍が野戦環境で使用する統合防空・ミサイル防衛(IAMD : Integrated Air and Missile Defense)のための指揮管制システムを実現することにあった。だから、陸軍の部隊が展開するところに随伴できるようにする必要がある。そこで、機材一式をシェルターに収めて、トラックに載せて移動できるようにしている。

当初はIAMDのためのシステムということで、IBCSはIAMD Battle Command Systemの略だった。しかし最近になって名称が変わり、同じ「IBCS」だが、Integrated Battle Command Systemの略になった。つまり、IAMD「だけ」を受け持つシステムではなくなったということだ。

実のところ、イージス・システムも対空戦(AAW : Anti Air Warfare)が開発の発端であり、表芸でもある。しかし実際には、対水上戦(ASuW : Anti Surface Warfare)や対潜戦(ASW : Anti Submarine Warfare)に関わるシステムともリンクしており、総合的な艦載指揮管制装置となっている。

IBCSもそれと似た経過をたどっている。当初はIAMDのためのシステムとして構想され、開発が進んできたが、より広範に戦闘指揮を受け持つシステムに発展したのが現状だという。担当する任務の幅が広がれば、そこで使用するセンサーや通信機器やソフトウェアも追加する必要がある。

• 2020年8月、ノースロップ・グラマンがテストのために設置したIBCSのEOCとICE　写真：U.S. Army

• 2020年5月に行われたIBCSの飛行試験（FT-5）の様子。IBCSは巡航ミサイル模擬標的の脅威を継続的に追跡する　写真：U.S. Army

艦載システムとの決定的な違い

さて。イージス艦の場合、指揮管制を受け持つコンピュータ・システムに加えて、レーダー、艦対空ミサイル発射機、ミサイル用の射撃指揮システム、ソナー、艦対空以外の各種ミサイル、艦載砲など、さまざまなセンサーや武器を組み合わせているが、それらはすべて1隻の「フネ」にまとめられており、そのフネがひとつの戦術単位になっている。フネが動けば、そこに積まれている機材一式もワンセットになって動く。

ところがIBCSでは事情が異なる。陸戦用で、しかも機動性を持たせる必要があるから、所用の機材一式をひとつのプラットフォームにまとめてワンセット、というわけにはいかない。そんなことをやったら「陸に上がったイージス艦」ができてしまう。

そのため、IBCSでは中核となるコンピュータ機器や通信機器だけを車載化して移動できるようにしており、センサーや武器は分離されている。それらが、IFCN(Integrated Fire Control Network)というネットワークを介してIBCSとつながっている。

例えば、対空捜索用のレーダーならAN/MPQ-64センティネルやAN/TPS-59、地対空ミサイルならMIM-104パトリオット、THAAD(Terminal High-Altitude Area Defense)といった装備がある。米陸軍では、イスラエル製のミサイル迎撃システム「アイアン・ドーム」を試験導入しているが、これもIBCSにつながることになると思われる。

このほか2019年には、F-35が機上センサーで探知情報を得て、それをIBCSに送り込む実証試験を実施したこともある。ただし直結はできず、ロッキード・マーティンが中継器材を用意した由。

オープン・アーキテクチャがキモ

ともあれ、IBCSでは「頭脳」の部分と「眼」や「耳」の部分、それと実際に敵をぶん殴る「手足」の部分がすべて独立している上に、後から新たなセンサーや武器を追加する可能性がついて回る。機能面も同様で、新たな機能を実現するためのソフトウェア、新たなセンサーや武器を活用するためのソフトウェアが、後から加わる可能性がある。

それだけでなく、センサーや武器が物理的に離れた場所にいる(そこがイージス艦と決定的に違う)ことから、通信機能が重要になる。物理的なインターフェイスだけでなく、上位のインタフェースについても、さまざまなシステムと接続するための配慮が求められる。

しかも、野戦環境下で移動できることが前提だから、有線の通信システムに全面依存するわけにはいかず、衛星を含む無線通信が不可欠である。当然、妨害対策やサイバー・セキュリティといったことも考慮に入れなければならない。

したがって、IBCSはオープン・アーキテクチャ化した設計、将来の拡張性を考慮した設計が不可欠であり、それがこのシステムのキモでもある。最初から、指揮管制、センサー、武器をワンセットにして固定化するのでは、将来の発展に対応できないのだ。

そこで貧乏根性を発揮してしまい、「目下の所要に対応できるものを、ギリギリで作ってコストを抑えよう」と考えると、後で余計な手戻りとコストが発生することになる。将来の発展を視野に入れて、それに対応できる土台を作る方が、結局は安上がりなのだ。IBCSがIAMD専任から総合的な指揮統制システムに発展しているが、これは将来の発展を視野に入れた土台ができていたからこそ実現できたものだ。

無論、センサーや武器を開発する際にも、これから新たに開発するものは、IBCSとつなぐことを前提にする必要がある。これはメーカー単独の課題ではなくて、発注する官側の責任でもある。既存のものについては、直結が無理ならゲートウェイを用意することになるのだろう。