なぜ、メインフレームを今褒めるのはおかしいのか？
はじめに
かつて「コンピュータ」といえば、メインフレームを指しました。企業や官公庁の基幹業務を担う巨大な中央処理装置として、1970年代から1990年代にかけて、メインフレームは情報処理インフラの絶対王者でした。しかし、21世紀に入るとその栄光は急速に色あせていきます。なぜメインフレームは衰退したのでしょうか。そして、なぜ今なお「メインフレーム再評価」といった言説が現れるのでしょうか。本稿では、技術的、歴史的、社会的観点からその構造を紐解いていきます。
※ここで言うメインフレームは主に日本国産のものを指します。IBMは少し事情が違いますが、それについては以下で解説しています。
メインフレームとCODASYLの時代
メインフレームが絶対的な支配力を持っていた理由は、単にハードウェアが強力だったからではありません。それ以上に、ソフトウェアと設計思想が密接に結合していた点にあります。中でもCODASYL型のネットワークDBMSは、ポインタでレコードを直接つなぐ物理構造を設計者が明示的に構築することにより、補助記憶装置のI/Oパスを極限まで最適化することを可能にしていました。
このような設計は、極めて高速であると同時に極めて属人的でもありました。レコードのアクセス順序は設計者の頭の中にしかなく、関係の意味や整合性もコードに埋め込まれていたのです。つまり、性能は「神のような設計者」の存在によって担保されていました。アプリケーション側はCOBOLで書かれた処理系で構成されていましたが、その多くはSOLID原則も分割統治も意識されないモノリシックな構造であり、知性よりも手癖が支配するスパゲッティコードの温床となることも少なくありませんでした。
オープンシステムの未成熟とRDBMSの構造的限界
1980年代まで、メインフレームの支配は揺らぎませんでした。その背景には、オープンシステムの未熟さがあります。当時のUNIXは研究用や教育用としては優れていたものの、I/O制御、仮想記憶、ユーザ管理といった領域ではまだ洗練されておらず、商用業務を支えるだけの安定性や冗長性を備えていませんでした。
特にRDBMSは、登場当初「理論的には美しいが現場では使えない」と評されるほどの構造的な遅さを抱えていました。SQLは柔軟性を提供する代わりに、実行時にアクセス経路を計画し、ランダムI/Oを多発させる仕組みでした。同一ハードウェア上で比較した場合、CODASYLは必要なレコードにストレートにたどり着くのに対し、RDBMSはインデックス検索、条件評価、複数表のJOINといったコストの高い処理を必要とします。補助記憶装置が遅いHDDしかなかった時代において、これは致命的でした。
そのため、当時の技術者たちは「RDBMSは遅すぎて話にならない」「メインフレームの性能を再現するには100倍のリソースが必要」と口を揃えていました。オープンシステムに未来を見いだす者は少なく、メインフレームの優位は盤石のように思われていました。
仮想化とエミュレーションによる構造の変質
しかし2000年代に入ると、状況は急速に変化します。まず、メインフレーム自体が物理専用機から仮想化環境へと移行し始めました。汎用IAサーバ上でMSPやVOS3といったOSを仮想実行することで、専用ハードウェアの保守コストを削減しようとする動きが各ベンダで進みました。また、端末も専用機からPCに置き換えられ、エミュレータで画面を模倣するようになりました。
つまり、ハードウェアレベルではすでに“メインフレーム的なもの”は存在しておらず、アーキテクチャはエミュレーションによって延命されているという状態になったのです。これは、かつての専用機思想からの構造的な変質であったと言えるでしょう。
ハードウェア進化とRDBMSの反撃
メインフレームを過去のものとした最大の要因は、ハードウェアの進化によってRDBMSが“遅くても使える”段階に到達したことです。DRAM価格の下落により、数百GB単位のバッファキャッシュが常識となり、SQLクエリのランダムアクセスをDRAM上で処理できるようになったのです。さらにSSDの登場により、補助記憶のランダムI/O性能がHDD時代の10倍以上に跳ね上がりました。
同時に、RDBMSそのものも高度化しました。クエリオプティマイザ、パーティショニング、マテリアライズドビュー、インメモリDB、MVCCといった要素技術が、かつての構造的な欠点を段階的に克服していきました。2000年代中盤には、RDBMSが“十分に速い”存在になり、しかもメンテナンス性・可搬性・教育コストでメインフレームを圧倒するようになりました。
こうして、「神の設計者」がいなくても動かせる凡人向けの構造が、天才依存の古典的システムを駆逐していったのです。
なぜ「メインフレーム再評価論」が出てくるのか
構造的に劣勢となったメインフレームですが、定期的に「見直されるメインフレームの価値」といった言説が登場します。その背景は単純ではなく、いくつかの要因が考えられます。
再評価論が依拠する主な論点は、
- 高い信頼性と可用性
- ダウンサイジングに伴う移行リスク
- 特定ワークロードにおける性能
の3点に集約できます。確かにこれらは一面の真実を捉えています。しかし、技術の進歩を考慮すると、その優位性は限定的となりつつあります。
- 高い信頼性と可用性:
「メインフレームは止まらない」という長年の実績は事実です。しかし現代では、オープンシステムにおいてもクラスタリング技術やクラウドネイティブなアーキテクチャを用いることで、同等以上の可用性が実現可能になっています。 - ダウンサイジングに伴う移行リスク:
「ダウンサイジングに失敗した企業もある」という指摘も事実ですが、その原因の多くは、オープンシステムの技術的問題というより、プロジェクトにおける要件定義の甘さやマネジメントの不備に起因するケースが少なくありません。 - 特定ワークロードにおける性能:
メインフレーム自身も、Linuxやコンテナ技術をサポートするなどオープン化への対応を進めています。しかし、これはオープンシステムのアーキテクチャを後追いで取り込んでいる動きであり、かつてのような独自の技術的優位性を示すものではありません。むしろ、その構造がオープンシステムに近づくほど、「メインフレームでなければならない理由」は希薄になっていきます。
こうした技術的な議論とは別に、再評価論が広がる背景には、他の要因も指摘できます。一つは、メディアが好む「一周回って再評価」という物語の構図です。さらに、こうした記事の執筆者が、メインフレームの根幹をなす設計思想――例えば、オープン系では当たり前の「バイトストリーム」ではなくレコード形式を前提とするファイル構造や、階層を持たないフラットなファイルシステムといった、現代の常識とは異なる点――を深く理解しているケースは稀です。その結果、表面的な「信頼性」や「処理性能」といった言葉だけが切り取られ、その性能と引き換えに失われた柔軟性や、近代的な開発手法との親和性の低さといった構造的な課題が見過ごされがちになります。
もう一つは、既存システムを維持することでビジネスが成り立つベンダーや、キャリアの安泰を望む技術者といった、利害関係者の意向です。彼らにとって、現行システムの延命を正当化する言説は、構造的なポジショントークとして機能する側面があると考えられます。
まとめ
メインフレームは、かつて計算機社会を支配した存在であり、CODASYLという最適化されたデータ構造によって、同時代の他方式を圧倒していました。しかし、それは「神のような設計者」に依存した繊細な構造でもありました。RDBMSが登場して以降、ハードウェアの進化とソフトウェアの成熟によってその「構造的な遅さ」は吸収され、柔軟性と可搬性、そして多くの技術者による運用可能性という新たな価値が勝利しました。
現代における「メインフレームの再評価」を論じる言説は、こうした技術的な構造変化を十分に踏まえないまま、限定的な利点や関係者の意向を反映している側面があります。メインフレームはその歴史的役割を終え、アーキテクチャとしてはオープンシステムに吸収されつつあるのが実情です。この現実を直視し、技術の本質を見極めることこそ、情報技術の健全な進化につながるのではないでしょうか。
Discussion