過去の本連載を改めて眺めてみると、「陸」「空」「C4ISR(Command, Control, Communications, Computers, Intelligence, Surveillance, and Reconnaissance。式・統制・通信・コンピュータ・情報・監視・偵察)」系の話題は多いが、艦艇や海戦に関する話題があまり出ていなかったことに気付いた。そこで、その辺の話題を何回かに分けて取り上げてみよう。

軍艦の戦闘システム

今では陸・海・空を問わずにシステム化・コンピュータ化が花盛りだが、過去を振り返ってみると、意外とバラツキがある。そうした中で、比較的、人手や人力に頼らない形になってきていたのが艦艇の分野だ。

例えば、戦艦の主砲を撃つのに、個々の砲が個別に照準するのではなく、集中指揮する方式が登場したのは、なんと20世紀の初頭、第一次世界大戦より前の話である。具体的にいうと、艦橋より上、艦でもっとも高い場所に「主砲射撃指揮所」を設置して、そこに砲術長が陣取る。主砲射撃指揮所を高所に設けたのは、その方が見通しがきくからだ。

そして、主砲射撃指揮所に設置した方位盤を使って敵艦に狙いをつけると、全部の砲がその狙いに合わせて向きや仰角を変える。その際に砲を指向すべき向きを計算するのが、射撃盤と呼ばれる機械式計算機である。砲を指向して弾と装薬(弾を撃ち出すための火薬)を装填した後で発砲を指示すると、全部の砲が一斉に、同じ目標に向かって弾を撃ち出す。そういう仕組みである。

当初、目標の探知や測距は人間の目玉や光学機器に頼っていたが、第二次世界大戦でレーダーが登場した。また、航空機から偵察報告を受け取ることもあるだろう。

砲がミサイルに変わっても、目標の方位・距離・針路・速力といったデータを得た上で、それに基づいて諸元を計算してから発射を指示するところは似ている。相手が水上目標でも陸上目標でも空中目標でも、基本的なところは同じだ。

ところが、そこで問題が生じる。レーダーやその他のセンサーから目標に関するデータが入ってきても、そのデータを射撃指揮用のシステムに入力するところは手動なのである。するとどうなるか。

例えば、「敵航空機を発見。方位2-7-3、距離40マイル、針路1-1-3、速力600ノット」という報告がレーダーから入ってきたら、そのデータを手作業で艦対空ミサイルの射撃指揮装置に入力する。それからおもむろに射撃指揮装置が諸元を計算して、ミサイルを発射機に装填、それからようやく発射して誘導する運びになる。これでは時間も手間もかかるし、入力ミスの可能性もある。

また、同時に複数の探知があった場合には、それぞれについて脅威度や優先度を判断しなければならない。判断を間違えると惨事になる。

システム同士の連接

この問題を解決するにはどうすればよいか。それが、システム同士の連接である。

つまり、センサー・システムが得た探知データを、人間による判断・読み取り・入力といった手間を介さないで、指揮管制システムに入力してしまう。指揮管制システムは、入ってきた探知データに基づいて脅威評価や優先順の判断を行い、それに基づいてミサイルや砲の射撃管制システムにデータを送り出す。射撃管制システムは、そのデータに基づいて交戦する。

「探知」「指揮管制」「射撃管制」といった個々の機能をバラバラに作動させて人間が間を取り持つのではなく、互いにデータや指令をやりとりできるように連接した艦のことを、システム艦と称することがある。ちなみに、海上自衛隊で初めてシステム艦の概念を取り入れたのは、ヘリコプター護衛艦「しらね」級だとされる。

このシステム艦の概念を突き詰めた究極の姿が、本連載の第8回・第9回で取り上げたイージス艦と、そこに搭載するイージス戦闘システムである。イージス戦闘システムは単に対空戦やミサイル防衛のためだけに存在するのではなく、対潜戦(ASW : Anti Submarine Warfare)や対水上戦(ASuW : Anti Surface Warfare)までカバーする、汎用性の高い戦闘システムだ。だから、それらすべてをカバーするセンサーと兵装、そして指揮管制機能が一体になっている。

システム化を実現するための課題

そこで問題になるのが、「システム同士の連接」である。単に電線をつなげば済むという話ではないからだ。

もちろん、物理層のレベルで相互接続を可能にしなければ話が始まらない。だから電気的特性やコネクタの形状・ピン配置を合わせるのは当たり前のことだが、さらに探知データを入出力する際のデータ・フォーマット、指令をやりとりする際のデータ・フォーマットなどをキチンと取り決めておかないと、データのやりとりも指令のやりとりも成立しない。

また、軍艦の寿命は数十年に渡るものだから、運用の途中で搭載システムを入れ替えることもある。その際に、システムを総入れ替えするならまだマシだが、一部のサブシステムだけを入れ替えるとなると、それが既存のサブシステムとデータや指令をやりとりできるかどうか、という問題が生じる。

そうなると、物理層のレベルであれ、電気特性であれ、その上のプロトコルのレベルであれ、独自仕様でガチガチに固めてしまったのでは、後日のアップグレード改修や延命改修の際に大迷惑だ。どのレベルの話であれ、インタフェースはできるだけ標準化して、後で交換や更新を行いやすいようにする配慮が求められる。

近年、ウェポン・システムの世界でオープン・アーキテクチャ化ということが頻繁にいわれるのは、こういう事情があるからだ。当初にサブシステム同士を連接して動作させるだけでなく、後日のアップグレード改修のことまで考えなければならない。また、輸出商品としてみた場合、カスタマーの希望、あるいは武器輸出管理や政策に起因する制約から、やむなくサブシステム単位の入れ替えを迫られることもある。そうなると、入れ替えが効かないシステム構成では困るのだ。

なにもウェポン・システムに限らず、企業の情報システムでも事情は似たり寄ったりではないだろうか。システム・インテグレーションの苦労があるのは、軍艦の戦闘システムも同じなのである。

執筆者紹介

井上孝司

IT分野から鉄道・航空といった各種交通機関や軍事分野に進出して著述活動を展開中のテクニカルライター。マイクロソフト株式会社を経て1999年春に独立。「戦うコンピュータ2011」(潮書房光人社)のように情報通信技術を切口にする展開に加えて、さまざまな分野の記事を手掛ける。マイナビニュースに加えて「軍事研究」「丸」「Jwings」「エアワールド」「新幹線EX」などに寄稿しているほか、最新刊「現代ミリタリー・ロジスティクス入門」(潮書房光人社)がある。