19世紀のイギリスで起きた「ゲージ戦争」は、単なる鉄道の規格争いではありませんでした。そこでは、性能では勝るとされていた技術が「相互運用性」という見えにくい価値の前に敗れるという歴史的な逆転劇が起きました。天才技術者が理想を込めた「広軌」は、なぜ姿を消すことになったのでしょうか。ゲージ戦争での出来事は、現代のソフトウェア開発における「独自仕様」の問題と驚くほどよく似ている気がします。今回は、ゲージ戦争の経緯をたどりながら、エンジニアが陥りがちな「技術的優位性への固執」と、その先に待つマイグレーション地獄を避けるための視点を考えていきましょう。
- もくじ
1. 「優れた技術」が負ける日
1-1. 「広軌」 vs 「標準軌」
鉄道が「未来の乗り物」として人々の夢を乗せていた1830年代、イギリスでは線路の幅（ゲージ）をどう決めるかで国中が二分されていました。これが後に語り継がれる「ゲージ戦争」です。イギリスの鉄道網が急速に拡大する中、2つの異なる規格が勢力を競っていました。
一方は「蒸気機関車の父」と呼ばれるジョージ・スティーブンソン（George Stephenson）の影響を受け、多くの鉄道会社が採用していた4フィート8.5インチ（約1,435mm）の「標準軌」です。この幅は、北部の炭鉱や馬車鉄道など、既存のインフラから引き継いだもので、建設コストが低く、すでに稼働している車両をそのまま流用できる実用的な選択でした。
もう一方は、グレート・ウェスタン鉄道（GWR）の設計を主導した天才技術者イザムバード・キングダム・ブルネル（Isambard Kingdom Brunel）が提唱した7フィート1/4インチ（約2,140mm）の「広軌」です。ブルネルは科学的な実験を重ね、線路幅を広くすることで車輪の摩擦が減り、車両の安定性と速度が飛躍的に向上すると確信していました。
その性能は数字にも表れています。広軌の列車は当時としては高速な時速80mph（約129km/h）を記録し、車体が大きく安定しているため乗客はゆったりとした車内で快適に過ごすことができました。技術的観点から見れば、広軌は安全性、乗り心地、将来的な拡張性のいずれの面でも標準軌を上回っており、ブルネルの理想は十分に筋の通ったものだったのです。
標準軌が「既存インフラとの互換性を重視した現実路線」だったとすれば、広軌は「純粋に性能を追い求めた理想型」でした。この2つの規格が「覇」を争っていたことになります。
1-2. 広軌はなぜ負けたのか
先に結論をお伝えすると、負けたのは広軌でした。技術的に優秀だったはずの広軌でしたが、鉄道網が全国に拡大していくにつれて致命的な問題が露呈し始めました。この最大の弱点を一言で表すと、「他とつながれない」ことだったのです。
広軌と標準軌の路線が接続する地点、例えば、グロスターやウルヴァーハンプトンなどの乗換駅では、列車をそのまま走り続けさせることはできません。異なる線路幅に合わせた車両はレールに載らないため、貨物はすべて手作業で積み替え、乗客は一度ホームに降りて別の列車に乗り直さなければなりませんでした。この「ゲージブレイク（ブレイク・オブ・ゲージ）」と呼ばれる現象が、1日に数百トンの輸送遅延を引き起こし、輸送コストを2倍以上に押し上げていました。経済活動にとってこれは致命的でした。商品が目的地へ届くまでに余計な時間とコストがかかるなら、何か特別な理由がない限り、広軌の路線を好んで使おうとはしないのではないかと思います。
このカギとなったのは「ネットワーク効果」です。標準軌の路線はイギリス全土に約1,710マイルへと広がっていた一方、広軌は約250マイルで差がありました。利用者が多いネットワークには、さらに多くの利用者が集まります。標準軌に乗れば全国どこへでも乗り換えなしでスムーズに移動できるのに対し、広軌は高性能でありながら「どこにも自由には行けない（かもしれない）」という欠点を抱えることになったわけです。
つまり、最終的に勝敗を決めたのは技術力ではありませんでした。どれだけ優れているかではなく、どれだけつながっているかというエコシステムの強さこそが、ブルネルの理想を打ち負かしたことになります。
Why the end of the gauge war didn't standardise Britain's railway - Network Rail
1-3. 規格統一と大改軌
事態を重く見たイギリス議会は1846年に「軌間規制法」を制定し、新規に建設する路線は標準軌に統一することを決定しました。延命を図ったグレート・ウェスタン鉄道は広軌と標準軌の両方を走れる「混合軌道」で時間を稼ぎましたが、それも限界を迎え、1892年、ついに全線を標準軌へと改軌することを決断します。
この「大改軌」はまさに史上最大級のマイグレーション（システム移行）でした。パディントンからペンザンスに至る複線を含む全線を、わずか数日間で標準軌へと切り替えるという大規模な作業は、線路だけでなく、それに合わせた車両、橋梁、トンネル、すべての設備を作り直すことを意味しました。その費用は当時の貨幣価値で数百万ポンド、現代換算では数億ポンド規模に達したとされています。現代の日本円に換算すると、なんと約570億円から1,000億円規模だったといわれています。
皮肉な見方ですが、最初から「つながり」を重視して標準軌を選んでいれば、必要がなかったコストということもできます。なにはともあれ、理想のために築いた新たなシステムを、現実に合わせて全面的に作り替える代償は小さいものではありませんでした。広軌は性能で勝っていても、「つながり」で敗れてしまうこととなったのです。
2. 独自仕様は現代のソフトウェア開発の「広軌」なのか？
2-1. 「私的API」「俺様フレームワーク」は安全なのか？
19世紀の線路幅を巡る争いは、現代のデジタル世界でも形を変えて繰り返されています。ブルネルの広軌がそうであったように、現代のソフトウェア開発における「独自仕様」もまた、当初は「性能向上」や「最適化」といった看板を掲げて現れます。
ソフトウェア開発の現場では、「既存のフレームワークは制約が多い」「自社の業務に最適化したい」という理由から、独自のフレームワークや私的なAPIを構築することがあります。開発初期の段階では、汎用品よりも数倍以上、効率的に動くかもしれませんし、自社のユースケースにぴったり合う便利な仕組みができたと感じられることは確かだと思います。しかし、これは「7フィート1/4インチの幅で線路を敷く行為」かもしれないのです。
独自仕様が生み出すかもしれない最大の「未来の負債」は、外部エコシステムとの断絶です。標準的なライブラリや他社のサービスと連携しようとした瞬間、線路幅が合わないためにデータがそのまま通らず、中間に変換レイヤーやアダプターなどを噛ませる必要が出てくることです。これは現代版の「ゲージブレイク」だといえます。
さらに、チームの運営においても、新しく加入したエンジニアは標準的なスキルセットがそのまま通用しないため、独自仕様を一から覚える学習コストが別途かかってしまうことになります。システムが大規模化し、外部との連携先が増えるほど、この「未来の負債」は深刻化していくことでしょう。広軌がたどった道筋に似ています。
2-2. VHS vs βから現代のWeb標準までに見る「負け規格」の共通パターン
歴史を振り返ると、「技術的な優位性」が「エコシステムの広さ」の前に屈した事例は枚挙にいとまがありません。
例えばビデオテープの世界がそうです。1970年代から80年代にかけて起きたビデオテープの規格争いである「VHS vs ベータマックス（β）」は典型例かもしれません。ソニーが1975年に発売したベータマックスの初期型（β1速度）は、のちのVHSと比較して画質や小型化で優れていました。しかし、初期モデルの録画時間は1時間に限定されており、1977年に2時間録画を可能にしました。
一方、1976年登場のVHSは、とにもかくにも最初から録画時間2時間を実現し、さらにVHSの開発元JVCは自社技術を積極的に他メーカーへライセンス供与することで参入障壁を下げていました。そして、多くのメーカーがVHS陣営に加わることで、レンタルビデオ店にはVHSのソフトが大量に並ぶことになり、ネットワーク効果が一気に働くことになったのです。高品質でありながら独自仕様で孤立したベータマックスは、市場から姿を消すことになります。興味深いのは、このパターンではVHSが後発であることでしょう。
現代では、特定のクラウドベンダーへ依存してしまうケースで同じような構図を繰り返しているようです。AWSやAzureなど特定ベンダー固有の独自サービスやAPIに深く依存したアーキテクチャを構築すると、コスト削減や戦略的な理由から乗り換えを検討した際に、API再構築などで数百万ドル規模のコストと膨大な時間が障壁となります。これは「クラウドベンダーロックイン」と呼ばれる問題で、現代版のゲージブレイクそのものだといえます。
Web標準（HTML/CSS）の世界でも同じことが言えそうです。例えば、仮に特定企業の独自ブラウザ仕様が一時的に注目を集めても、最終的にはW3Cなどが定めるオープンで広く支持された標準規格が生き残り、独自仕様はおそらく廃れていくでしょう。規格の統一競争で後れを取る側に共通するのは、技術の優劣よりも「広く受け入れられるかどうか」を軽視している点にあるように感じられます。
2-3. 「尖った技術」の5年後は？
新しく、高性能で、誰もまだ使っていない「尖った技術」はエンジニアの知的好奇心を強く刺激します。しかしシステム運用の現実は、その魅力とは裏腹に非情なことが多いようです。性能よりも「つながり」が未来を決めたゲージ戦争の教訓は、この問いに対するひとつの明確な答えを示していました。独自仕様を採用した技術の5年後を評価するためには、次の3つの軸で考えることが重要だと考えられます。
相互運用性
相互運用性の評価基準は、オープンな標準規格に準拠しているか、他のツールやシステムと素直につながれるかどうかだと思います。例えば、KubernetesのようなオープンエコシステムはIT業界全体に広く受け入れられましたが、特定ベンダーの独自コンテナ管理ツールはKubernetesと競合しては消えていった印象です。
採用コスト
採用コストは見逃せない評価基準です。チームに新しいメンバーが加わった際、標準的なスキルセットで即戦力として動けるかどうかでしょう。独自仕様を理解するために大きな教育コストが発生するなら、それ自体がそのものずばりの負債となり得ます。
撤退容易性
最後に念のため考慮しておきたいのが撤退容易性でしょう。もし、仮に採用を考えている技術が時代遅れになったり、より良い選択肢が登場したりしたとき、どれだけ低いコストで新しい環境に移行できるかを考慮します。いわば保険のような考え方です。言い換えると実験の意図がない場合は、「行くはよいよい帰りは怖い」では困る......ということになります。
3. エンジニアが気をつけたい「俺様仕様」の罠
3-1. なぜ、人は独自フレームワークや内製ルールを作りたがる？
独自仕様の危険性は理解できても、なぜ私たちは繰り返し「自分だけの線路」を敷きたくなるのでしょうか。そこにはエンジニア特有の心理的な罠が潜んでいるから......といえる気がします。
理由はシンプルです。既存の仕組みが不十分に見えるからです。優秀なエンジニアほど「標準的なフレームワークは機能が多すぎて重い」「汎用APIでは自社の業務ロジックに合わない」「自分ならもっとシンプルで美しい設計ができる」と考えるものです。エンジニアとしての誠実さや向上心からの発想であって、否定するどころか、むしろ推奨されるべき考え方です。
これはゲージ戦争のブルネルも同じです。既存の線路幅に疑問を持ち、科学的な根拠に基づいて広軌を設計した彼の姿勢は技術者として一本ビシッと筋が通っていました。問題だったのは、その判断が現在の課題に対してだけ最適化されていた点ではなかったかと思えます。将来の拡張、他社との連携、人材の入れ替わりといった要素が後回しにされがちで、目の前の性能向上や開発速度に集中するあまり、長期的なリスクの考慮が不足していた......というのは穿ちすぎた見方かもしれませんが、それくらい、エンジニアにとって独自仕様は合理的かつ魅力的に感じられるものなのだと思います。
3-2. 数年後の「マイグレーション地獄」を想定できるか？
独自仕様のツケは、作った直後ではなく、ほとんどのケースで数年後に訪れます。一例ですが、プロジェクト開始から3年後、担当したエンジニアが異動や転職でチームを離れ、ドキュメントが不足した状態で独自APIのバグ修正が必要になるといったシナリオは「よく聞く話」ではないでしょうか？ 独自仕様を知るエンジニアがいなければ、数行の修正に数週間かかることも起こり得ます。
深刻なのは、システムが拡大し、外部サービスや新しいインフラとの連携が必要になったときです。互換性のない独自仕様は連携のたびに積み替えを強いられ、修正コストが雪だるま式に膨らんでいきます。クラウドサービスの移行の際に特定ベンダーの独自機能への依存が足かせになって、別の環境への移行だけで数百万ドルを超えるコストが発生したクラウドベンダーロックイン事例は比較的多く報告されています。
Cloud vendor lock-in: 4 real-life scenarios and lessons learned（MasterBorn）
グレート・ウェスタン鉄道がのちに大改軌に追い込まれたように、最終的には「全面的な書き換え」「撤退」というもっとも高コストな決断が迫られます。最初の設計時に節約したコストを遥かに上回る代償を、後の世代のエンジニアが支払う可能性を考慮することも設計の一部なのかもしれません。
3-3. 「長期運用できる設計」の判断軸は何か？
では、エンジニアはどのような基準で技術選択をすべきでしょうか。「長期運用できる設計」かどうかを見極めるための判断軸はエコシステムへの適合度にあるように思えます。上述の5年後の評価と重ねて改めて考えてみましょう。
第一に、既存の標準規格との親和性を確認することでしょう。W3CやISOのような公的な標準、あるいは業界全体で広く採用されているデファクトスタンダードに沿っているかどうかは、将来の互換性を左右する最重要項目です。
第二に、コミュニティやエコシステムの規模を確認することです。利用者が多く、活発なコミュニティがある技術は、問題が起きたときの解決策が豊富で、将来的なサポートも期待できるからです。β陣営の悲劇は先行したにもかかわらず撤退を余儀なくされたことです。つまり、コミュニティやエコシステムの構築においてはVHS陣営にやられてしまったという見方も成立するのではないでしょうか。
第三に、撤退戦略を事前に描けるかどうかです。独自技術の採用を検討する際には、PoC（概念実証）の段階で「もしこの技術を捨てることになったら、どれくらいのコストがかかるか」を試算しておくことが重要だといえます。
性能や美しさだけでなく、つながりと将来の柔軟性を含めた総合評価や「設計」を行うことや、短期的な最適解が長期的な負債になる可能性を常に問い続けることが、現代のエンジニアに求められる視点なのかもしれません。
4. まとめ
イギリスのゲージ戦争は、性能で勝る広軌が相互運用性という現実に敗れてしまった、ある意味"悲しい"歴史です。この教訓は現代のソフトウェア開発にも直結します。独自仕様による争いはVHSとβの争いやクラウドロックインでも繰り返されてきたように、短期的な合理性があってもエコシステムから孤立すれば巨大な技術的負債となることを示しています。見方を変えると「閉じた高性能」は「開かれた接続性」に敗れることが多く、長期運用は「つながり」に支えられていることがわかります。
