なぜマルスのベンダーは日立なのか——リアルタイムデータベース史から読み解く「国産DBの黄昏」

『マルスの秘密』という本に、「なぜマルスのベンダーは日立なのか」という章がある。JR（旧国鉄）の座席予約システム「マルス」が、なぜ半世紀以上にわたって日立製作所一社に握られてきたのか、そしていま「日立離れ」が忍び寄っている——という内容だ。

この本が出たのは2005年前後。読み返すと、当時の観測としては鋭いのだが、20年経ったいま答え合わせをすると、面白いほど予想が外れている部分と、当たっている部分がある。本稿では、この章を出発点に、リアルタイムデータベースシステムをめぐる国産ITベンダーの興亡史として話を広げてみたい。マルスは、その縮図として実によくできた教材だ。

リアルタイムDBは、ごく一部の業務の専売特許だった

まず時代背景を押さえておきたい。1950〜60年代、コンピュータで「リアルタイムにデータベースを引いて、即座に応答を返す」というシステムを構築するこどは、非常に難しいことだった。バッチ処理(夜間にまとめて計算処理を行う)が当たり前だった時代に、端末からの問い合わせに即座に答える、しかも複数の端末が同時に同じ座席や在庫やをダブルブッキングしないように整合性を保つ、というのは技術的な最先端、かつ多額の費用を要するものだった。

そして、そんな巨額をかけてリアルタイムDBを構築する必要がある業務は、世の中にそう多くなかった。座席や口座という「有限の在庫を、多数の窓口から同時に奪い合う」性質を持つ業務——具体的には銀行、証券、航空、鉄道、そして公営競技くらいのものだ。逆に言えば、これらの業界は当時としては例外的に、巨額のIT投資を正当化できる数少ない領域だった。リアルタイムトランザクション処理の歴史が、この数業種を軸に語られるのにはこうした理由がある。

しかも当時は、リレーショナルデータベース（RDB）という概念そのものが、ようやく世に出始めたばかりだった。E.F.コッドがリレーショナルモデルの論文を発表したのが1970年。製品として各社のRDBMSが本格的に立ち上がるのは1980年代に入ってからだ。つまり初期のマルスやSabreが作られた頃には、まだ「リレーショナル」ですらなく、専用に組まれたファイル構造とアクセス手法で在庫を管理していた。RDBが普及してからも、各社は「開発しながら市場に投入する」、走りながら考えるような状態でプロダクトを育てていった。

出発点はSabre——IBMの圧倒的な先行

このジャンルの原点は、なんといってもアメリカン航空とIBMが作った「Sabre」だ。

このシステム構築のきっかけとして知られるのは、1953年、アメリカン航空社長のC.R.スミスが、たまたま機内でIBMの営業マン（奇遇にも同じ「スミス」姓のR.ブレア・スミス）と隣り合わせたことに端を発する、という話だ。そこから話が転がり、IBMとアメリカン航空が正式に共同開発契約を結んだのが1959年、システムが本稼働したのが1964年。座席在庫と乗客記録をリアルタイムで処理し、それまで平均90分かかっていた予約手続きを数秒に短縮した。世界初のオンライントランザクション処理システムであり、当時としては民間最大級のリアルタイム商用データ処理システムだった。

ここで重要なのは、Sabreという「巨大な成功事例」をIBMが手中に収めたことの意味だ。航空予約とい困難なリアルタイム業務を実地でやりきった経験は、そのままIBMのメインフレームとトランザクション処理技術への絶大な信頼につながった。のちにIBMはリレーショナルデータベースの本家でもある（コッドはIBMの研究者だったし、SQLもSystem RもIBM発、商用DB2へと結実した）。ハードもDBも、リアルタイム予約システムのノウハウも、すべてIBMが先頭を走っていた。

日本の航空業界でも、JALはIBM、ANAはユニシス（旧バロース系）をメインフレームに採用している。世界中の航空予約システム（CRS）を親会社が手がけている日本IBM・日本ユニシスには、ハードもソフトも分厚い実績があった。リアルタイム予約システムの世界は、長らく「外資メインフレーマーが大きく先んじている」領域だったのだ。

国産ベンダーは「信頼できるマシンとDB」をゼロから積み上げるしかなかった

この構図のなかで、国産ベンダー——富士通、NEC、日立——は明らかに後発だった。

リアルタイムの基幹システムを作るには、二つの土台(プラットフォーム)が必要だ。落ちないハードウェア（メインフレーム）と、整合性を絶対に壊さないデータベースだ。外資はSabreやその後継群で実地に鍛えられた土台を持っていたが、国産勢はこれを自前でゼロから積み上げる必要があった。しかも「銀行や証券のオンラインが止まった」では済まされない世界である。信頼性の要求水準は、生半可ではなかった。

国産各社はそれぞれ独自のDBを育てていった。富士通は「Symfoware（シンフォウェア）」、日立は「HiRDB」、NECも独自路線を持っていた。いずれもメインフレーム時代に培った技術を、後にオープン系へと展開していくことになる。日立のHiRDBは、メインフレーム上のDB「XDM/RD」で培った高信頼化技術を継承し、オープンシステム向けに進化させた純国産RDBMSだ。シェアードナッシング方式を採り、データの検索・更新を並列実行することで、大規模・高負荷でも性能を出せる設計になっている。

ここに、本書が直接は書いていない「裏事情」を補助線として引くと、構図がよりくっきりする。金融——銀行・証券のオンラインシステム——では、IBMと富士通が早くから強かった。都市銀行の勘定系を富士通やIBM、日立がそれぞれ分け合う構図のなかで、日立としては「自社の高信頼DBで攻め込める、大規模リアルタイムの実績」が喉から手が出るほど欲しかったはずだ。リアルタイムDBの看板事例を一つでも多く持つことは、後続の金融・公共案件すべてに効いてくる。だとすれば、国鉄のマルスは——採算度外視でも食らいつく価値のある——日立にとってのショーケースであり、技術の鍛錬場だった、と読むのが自然だ。

国鉄にとって、日立は「救いの神」だった

一方、国鉄の側から見ると、話はもっと切実だ。

『マルスの秘密』が描くのは、1958年の時点で、他社が尻込みするなか日立だけが手を挙げた、という事実である。国鉄にはコンピュータ技術がなく、唯一引き受けてくれた日立を当てにして、その尻を叩いてシステムを実現するしか道がなかった。国産初の販売用コンピュータHITAC 101を1963年11月に完成させたのも、この二人三脚の産物だ。

本書の表現を借りれば、両者は「同じ釜の飯を食う仲間」になっていった。国鉄側にはベンダーを指導できる技術もノウハウも蓄積されず、担当者が替わって過去の経緯が分からなくなっても、ベンダーを乗り換えることはできなかった。日立にしても「ここで降りては過去の投資が無駄になる」と、前に進むしかなかった。

これを後世の言葉で言えば、典型的なベンダーロックインである。発注側に技術が蓄積されず、特定ベンダーの製品・ノウハウに深く依存し、乗り換えコストが法外に高くなって離れられなくなる——マルスはその教科書的な事例だ。

しかし、ここが本稿で一番言いたいところなのだが、このロックインは、必ずしも「悪」ではなかったと私は思う。

座席予約システムというのは、止まれば全国のみどりの窓口が一斉に麻痺し、繁忙期には1日1000万コール以上をさばく、社会インフラそのものだ。こういうシステムにとって最重要の価値は、機能の華やかさでも調達コストの安さでもなく、安定して止まらないことである。長年連れ添ったベンダーと、現場を知り尽くしたエンジニアが、同じDBを使い続けて練り上げていく——ベンダーロックインの裏返しは、そのまま「枯れた信頼性の蓄積」でもある。汎用機（メインフレーム）ベースで始めたことが、結果として強固な安定性をもたらした。システムの趣旨を考えれば、それは決して悪い選択ではなかった。

本の「予言」は、半分当たって半分外れた

さて、『マルスの秘密』が2005年前後に下した観測は、「日立離れが忍び寄っている」というものだった。

その論拠はこうだ。コンピュータの進歩でリアルタイムDBは特別な技術ではなくなった。サーバと呼ばれる中型機でも処理できるようになり、共通言語の採用でオープン環境への対応が重視されるようになった。鉄道各社にもCRS開発の知識が蓄積され、ベンダーと顧客が一心同体である必要性は薄れた。実例として小田急電鉄が三世代目のCRSでベンダーをNECから東芝に切り替えた話を挙げ、評価基準が「ハードの機能」から「コストやソフト、保守サービス」へ移ったと指摘する。そしてマルスでも、メインフレームの役割が縮小し、最新のマルスではメインフレームを廉価なマシンに切り替えた——「日立が手塩にかけて育てたシステムが、自立の道を歩みはじめようとしている」と結ぶ。

この観測の「方向性」は、確かに当たっていた。業界全体としてオープン化・コスト重視・脱メインフレームの大波は、まさにこの後20年で本格化した。ベンダーと顧客の一心同体が崩れていく、という大局観も正しい。

ところが、ことマルスに関しては、予言は外れた。
日立離れは、起きなかった。

答え合わせ——マルスはいまも日立DBの牙城

現行の最新システムは「MARS 505」。2018年に開発を開始し、2020年から稼働している。そして、そのデータベースは日立のHiRDBだ。

マルスにHiRDBが初めて導入されたのは2004年、列車データの作成管理システムから。本書が「日立離れ」を予言していた、まさにその時期だ。だがその後HiRDBの適用範囲はむしろ拡大し、いまや複数のサブシステムで使われている。脱・日立どころか、DBの心臓部はがっちり日立純正で固められたままなのである。

ハード構成も、本書のイメージとは少し違う。マルスの中央装置は、日立製メインフレーム「AP8000」と、日立製UNIX系サーバ「EP8000」などからなる分散構成だ。たしかにメインフレーム一辺倒だった時代から、処理の多くが周辺サーバへ移り、メインフレームの役割は縮小した。本書の「メインフレームを廉価なマシンに切り替えた」という記述は、当時のマルス501世代の流れとしては正しい。だが、メインフレームが消えてUNIXクラスタに完全移行したわけではなく、メインフレームとUNIXサーバが役割分担する構成として、いまも日立製ハードの上で動いている。

つまり、「オープン化の大波」と「マルスの日立依存」は、20年かけて両立した。これは矛盾ではない。オープン系のサーバやUNIXを取り入れて構成を現代化しつつ、止められない心臓部は実績ある国産DBで固め続ける——社会インフラとしては、極めて合理的な落としどころだったと言える。「枯れた信頼性」を捨てなかったことが、結果的にマルスを生きながらえさせた。

ちなみにここで一点、誤解を解いておきたい。HiRDBは「オープンソースDB（PostgreSQLなど）に寄せて作ったもの」ではない。むしろ逆で、メインフレームのDB資産（XDM/RD）をオープン系プラットフォームへ持ち出して育てた、生粋の純国産RDBMSだ。マルスの現行DBは、その純正HiRDBがそのまま使われている。

一方で、本の大局観は別の場所で当たっていた——国産DBのオープン化への呑み込まれ

マルスという個別事例では予言が外れた。だが、本書が捉えていた「オープン化の大波」という大局観は、業界全体ではしっかり的中している。象徴的なのが、国産DBそのものの運命だ。

富士通のSymfowareを見てみよう。かつて自前のエンジンで作られていたこの国産DBは、いまやPostgreSQLベースに作り替えられている。「Symfoware Server (PostgreSQL)」や「Enterprise Postgres」がそれだ。富士通は2003年頃からPostgreSQLとの融合に動き、最終的にネイティブエンジンからPostgreSQL互換へと舵を切った。OSSのPostgreSQLを核に、性能・信頼性・サポートを富士通が上乗せする——という形である。

背景にあるのは、顧客側の「商用DBによるベンダーロックインを避けたい」という強い要求と、そして身も蓋もない話だが、国産ベンダー単独でDBエンジンをフルスクラッチで進化させ続ける体力が、もう続かないという現実だ。グローバルではOracle、Microsoft SQL Server、そしてOSSのPostgreSQLやMySQLが市場を席巻し、クラウド時代にはAWSやGoogle、Azureのマネージドサービスがさらにその上を行く。専用ハード＋専用DBで囲い込む垂直統合モデルは、コスト面でも開発リソース面でも、オープン／クラウドの物量に抗しきれなくなった。

国産DBが生き残る道は、二つに分類された。一つは富士通Symfowareのように、潔くOSS（PostgreSQL）を土台に乗り換え、その上に自社の付加価値を載せる道。もう一つは日立HiRDBのように、純正エンジンを維持しつつ、対応OSをオープン系に広げ、クラウド（AWS上での提供など）にも対応させて延命する道だ。どちらが正解ということはないが、いずれも「単独でエンジンを未来永劫進化させ続ける」という前提が崩れた後の、現実的な選択であることは共通している。

マルスが教えてくれること

ここまでをまとめると、マルスの物語は三つの層で読める。

後発国産ベンダーの執念の物語
Sabre／IBMが世界を先行するなか、信頼できるハードとDBをゼロから積み上げ、採算度外視で社会インフラに食らいつくことで、技術と実績を蓄えていった。マルスは日立にとって、金融や公共の大規模案件へ広げるための、またとない鍛錬場だった。

ベンダーロックインの再評価
発注側に技術が残らず特定ベンダーに深く依存する——一般には忌避されるこの構造が、止められない社会インフラにおいては「枯れた信頼性の蓄積」という別の顔を持つ。安さや流行りの技術より、止まらないことが最優先される世界では、長年の二人三脚はむしろ資産だった。本書が予言した「日立離れ」がマルスでは起きなかったのは、現場が無意識のうちにこの価値を理解していたからだろう。

垂直統合からオープン／クラウドへの不可逆な潮流
本書の大局観は、マルスという個別事例では外れたが、国産DB全体の運命としては的中した。富士通SymfowareのPostgreSQL化が示すように、国産ベンダーが単独でDBエンジンを支え続ける時代は終わりつつある。マルスがHiRDBの牙城であり続けているのは、その大潮流のなかでの「例外的な堅城」なのであって、潮流そのものを否定するものではない。

20年前、『マルスの秘密』の著者は「日立が手塩にかけて育てたシステムが、自立の道を歩みはじめようとしている」と書いた。だが実際には、マルスは親離れせず、いまも日立DBの上で走り続けている。皮肉なのは、世の中のほとんどのシステムがオープン／クラウドの大波に呑み込まれていくなかで、この「親子の絆」こそが、社会インフラとしての安定を支える最後の砦になっている、ということかもしれない。

技術の進歩は、確かに多くの専用技術を「特別ではないもの」に変えた。だが、半世紀の信頼を一朝一夕にコモディティが置き換えられるわけではない。マルスとHiRDBの20年は、そのことを教えてくれている。