米海軍イージス艦を見る(4)戦闘システムの形態管理

今回で4回目となるが、今回もしつこくイージス艦の話題で引っ張ってみることにする。若い方は御存じないかもしれないが、イージス艦の歴史は結構長い。一番手のミサイル巡洋艦「タイコンデロガ」(CG-47、通称「タイコ」)が竣工したのは、1983年のことである。それが2015年になってもまだ建造が続いているのだから、30年以上の歴史があるわけだ。

イージス戦闘システムのカオス状態

コンピュータに限らず、何でも同じことだが、運用・保守管理を行う立場からすれば、同一機種・同一仕様のモノでそろえるのが一番いい。路線単位で同一形式の車両をそろえている首都圏のJR各線を見れば、そのことはよくわかる。

しかしイージス艦の場合、1980年代から2010年代まで延々と開発・配備をやっているのだから、その間に改良を取り入れているうちに、いろいろなハードウェアとソフトウェアが入り乱れるのは当然の帰結。そうでなくても軍艦というのは、同型艦を造っているうちにいろいろいじりたくなり、同じクラスでもこまごまと仕様が変わるものである。

ドンガラ(船体や機関)の話はおいておこう。イージス戦闘システムだけとっても、えらくたくさんの仕様がある。まず、コンピュータはAN/UYK-7に始まり、AN/UYK-43、AN/UYQ-70、CPS(Common Processing System)と変化してきた。それに伴い、オペレーターが使用するコンソールも新しくなっている。第112回で書いたように、集中処理から分散処理へという大変化も起きている。

さらに、交戦の要となるミサイル発射機も新しくなっているし、眼となるAN/SPY-1レーダーも何種類かある。さらに、CEC(Cooperative Engagement Capability)対応の有無、BMD(Ballitic Missile Defense)対応の有無、NIFC-CA(Naval Integrated Fire Control-Counter Air)対応の有無といった違いも加わり、米海軍が保有するイージス艦は多種多様な仕様が入り乱れてカオスになっている。

基本的には、第112回で書いたようにベースライン(BL)というくくりがあるのだが、同じベースラインでもBMD対応の有無などに違いがあるので、ベースラインの数字が同じなら同一仕様、とは言いきれない。

さらに最近では、艦載システムを陸揚げしてBMDに特化させたイージス・アショアまで出現している。艦載型の特定BLを抜き出して余分な機能を落とせばイージス・アショアができるわけだが、ハード/ソフトの管理が必要になるのは同じことだ。

実は、横須賀に配備されているイージス巡洋艦×3隻とイージス駆逐艦×9隻を見るだけでも、すでに形態は何種類も入り乱れている。BMD対応艦×7隻・BMD非対応艦×5隻、CEC対応艦×7隻・CEC非対応艦×5隻、NIFC-CA対応と判明している艦が2隻といった具合だ。

アップグレード改修による形態統一

こうなると、管理が面倒になるだけの問題では済まない。古いハードウェアはメンテナンスに手がかかるし、パーツが手に入らなくなってくる。コンピュータが違えばソフトウェアも違うから、ソフトウェアの開発やバグ対処や機能強化などの維持管理にも手がかかる。

しかも、ソフトウェアは機能が増えなくてもバグフィックスでバージョンが上がる。たとえソースコードの互換性を維持していたとしても、ハードウェアが違えばビルドはやり直しだろう。古い大型コンピュータのAN/UYK-7と、UNIXベースのAN/UYQ-70で同じバイナリ・コードが走るとは思えない。それだけでもソフトウェアのビルドや配布にかかる負担は増える。

結果としてTCO(Total Cost of Ownership)が上がるところは、企業のシステムと似ている。

PCの世界で1983年から2015年までの年月を考えると、Windows 1.0(見たことがある人はどれだけいるだろう?)からWindows 10までが入り乱れているようなものである。

そこで米海軍では、古いイージス艦の戦闘システムを更新して、可能な範囲でハードウェアとソフトウェアの形態を統一する方向で作業を進めている。つまり、BL4.x、BL5.x、BL6.x、BL7.xを装備する艦のうち古い方から順次、最新のBL9.xに入れ替えていこうというわけだ。

先に横須賀にやってきたイージス駆逐艦「ベンフォールド」(DDG-65)も、その改修によってBL9.1cに更新した。当然、コンピュータ機器は総取り換えである。軍艦も商船も定期的にドック入りして点検・整備・補修を行うものだから、その手の長期入渠に合わせてシステム更新を行うのが通例となる。

ただし、ハードウェアはCOTS(Commercial Off-The-Shelf)品を活用するのが目下の趨勢で、BL9.xも例外ではない。そしてCOTS品は製品寿命が比較的短いので、「一度導入したらそれで終わり」とは行かない。陳腐化対策を当初から織り込んで、定期的に更新していく必要がある。

ACBとTI

そこで米海軍では、ハード/ソフトのそれぞれについて、定期的に更新していく考えを持ち込んだ。ソフトウェアはACB(Advanced Capability Build)という単位で2年ごと、ハードウェアはTI(Technical Insertion)という単位で4年ごとに更新するのが基本的な考え方となる。

さすがにハードウェアを2年ごとに更新するのは大変だし、プロセッサやメモリが十分な能力を備えておれば、ソフトウェアのバージョンアップによって機能向上やバグつぶしを行いつつ維持できる、という考えのようだ。

このACBとTIの組み合わせによるライフサイクル管理は、イージス戦闘システムだけでなく、潜水艦の指揮管制装置や水上艦のSSDS(Ship Self Defense System)などにも取り入れ始めている。

余談だが、IT業界の人間にとって「ビルド」はなじみが深い言葉である。しかし、軍事分野の人間にとってはそうでもないようで、「ビルド」という言葉の解釈に難渋して妙な日本語訳をつけるケースが散見されるのは面白い。

さて。イージス艦はわが国にも存在するが、すでに複数のベースラインが混在している。さらに2隻を増勢しようとしているが、これら8隻の形態管理が問題になってくる可能性がある。米海軍でBL4やBL5のフネがいなくなってしまった時、他国で使っているBL4やBL5のフネはどうすればいいのか。

後から登場した「あたご」型・2隻は、これからBMD対応改修を予定しているから、それに乗じてシステムを更新できる可能性があるが、最初に建造した「こんごう」型・4隻はどうするのだろうか。