知られざるCOBOL王国の興亡
1959年生まれの言語が、日本の金融を今日も動かしている
あなたが今日ATMを操作したとき、その裏で動いていたコードは、65年前に書かれた言語かもしれない。
2026年の今も、日本の銀行・行政・保険会社のコアシステムは、1959年設計のプログラミング言語「COBOL」で動いている。「いつか置き換えよう」と言われ続けて30年。経産省が「このままでは最大12兆円／年の損失が出る」と警告してから7年。それでもCOBOLは動き続けている。
これは誰かの怠慢の話ではない。技術が「インフラ」になったとき、人間がいかに身動きを取れなくなるか——その構造的な記録である。
本記事は実際の技術的・社会的背景に基づいたブラックコメディ仕立ての読み物です。引用・参照はすべて実在の文献・発言・報道に基づきますが、語り口はフィクション的表現を含みます。
1959年、ある語りかける言語が生まれた
西暦1959年、冷戦のさなか、アメリカで一つのプログラミング言語が生まれた。
名を COBOL（コボル）という。Common Business-Oriented Language——「共通事務処理用言語」と訳される。コンピュータに英語で語りかけるように命令を書けば、給与計算も、在庫管理も、帳票印刷もこなしてくれる、まったく新しい仕組みだった。
設計の指揮を執ったのは、グレース・ホッパー（Grace Hopper）海軍少将。彼女はすでに1957年に世界初の英語構文コンパイラ「FLOW-MATIC」を開発しており、「コンピュータは数字の専門家だけが使うものではない」という思想をCOBOLに込めた。プログラムの行は、まるで英語の業務マニュアルのように読める。
MOVE EMPLOYEE-NAME TO OUTPUT-LINE.
WRITE PAYROLL-REPORT.
「これなら普通の事務員でも読める」。ホッパーの目論見は正しかった。COBOLは1960年に公式仕様が確定すると、アメリカ国防総省の後押しを受けてたちまち普及した。そして1960年代、日本の大企業・金融機関・官公庁のもとに、IBM製メインフレームとともに海を渡ってきた。
日本の銀行は1960年代半ばに「第1次オンライン」（勘定系基幹システム）、1970年代半ばに「第2次オンライン」（総合オンラインシステム）を次々と構築した。その基盤には例外なくCOBOL、そしてIBMや富士通のメインフレームがあった。
こうして日本は、アジアの2バイト文字圏において最大のCOBOL王国へと成長した。
王国の繁栄──なぜ日本でCOBOLは根付いたのか
COBOLが日本で特別に根付いた理由は、ある種の「相性のよさ」にある。
1.1 金融計算の厳密性という壁
銀行の世界では、円の下一桁が合わなければ帳簿が閉じない。利息計算、元利均等返済、外国為替——これらは小数点以下の微妙な丸め処理が問題になる。COBOLは「固定小数点演算」と呼ばれる仕組みを使い、数値を10進数のまま扱う。JavaやPythonは内部的に2進数（浮動小数点）で計算するため、ごくわずかな誤差が生じる可能性がある。
「円の下一桁にこだわる」銀行にとって、COBOLは替えの利かない相棒だった。
1.2 夜間バッチという不動の要塞
日本の銀行は毎夜、数千万件の取引データを一括処理する「夜間バッチ」を動かす。朝の窓口開始までに、全顧客の残高・利息・引き落としを確定させなければならない。COBOLとメインフレームの組み合わせは、この大量処理においていまだ世界最高水準の信頼性を誇る。
「止まらない」「正確に動く」——この2点だけで、銀行は60年間COBOLを手放せなかった。
1.3 国策という後押し
1960〜70年代、通産省（現・経済産業省）はコンピュータ産業の国産化を推進した。富士通・日立・NEC・三菱電機といった国内メーカーがIBM互換機を開発し、COBOL対応のメインフレームを大量に供給した。「国内のシステムはCOBOLで動く」という前提が、インフラとして定着していった。
30年の沈黙──誰もCOBOLを語らなかった時代
1990年代、インターネットの波が来た。
Javaが登場し、Webアプリケーションがビジネスの表舞台に躍り出た。若手エンジニアはLinuxとオープンソースに熱狂し、PythonやPerlを学んだ。「これからはオープン系だ」「メインフレームは時代遅れだ」という声があちこちで聞こえた。
しかし銀行の地下では、COBOLが黙々と動き続けていた。
この時代、COBOLに携わるエンジニアたちはある種の「忍者」だった。表には出てこない。会議室でイノベーションを叫ぶ人々とは別世界で、夜間バッチのログをひたすら監視し、障害があれば数千行のコードを読んで原因を突き止めた。若手は誰もCOBOLを学ぼうとしなかったため、1970〜80年代に書かれた古いコードの「読める人間」が少しずつ、しかし確実に減り続けた。
「このモジュールの動作原理を知っているのは、もう田中さんだけです」
そういう会話が、日本中の金融システム開発現場で、静かに繰り返されていた。
Y2K問題と、束の間の覚醒
2000年問題（Y2K問題）は、COBOL王国に一瞬の光を当てた。
1990年代後半、世界中のシステムが「西暦を2桁で記録していた」という問題を抱えていることが明らかになった。「1999年→00年→1900年と誤認する」恐れがあり、銀行・行政・電力・航空の全システムが対応を迫られた。
そしてこの修正作業の大半は、COBOLコードへの手術だった。
日本の金融機関は、Y2K対応のため数百億円単位の費用を投じた。COBOLプログラマーの需要は一時的に急騰した。「やはりCOBOLを知っている人材が必要だ」という認識が経営層にまで広まった。
しかしY2K問題が無事に過ぎ去ると、再び沈黙が戻った。
「とりあえず動いている」——これが王国の統治原則だった。動いているシステムを触ることは危険であり、触らないことが美徳とされた。COBOLの延命は、この慣性によって加速していった。
みずほ銀行という「王国の鏡」
COBOL王国の複雑さを最も雄弁に物語るのは、みずほ銀行のシステム史である。
5.1 3行合併という地雷原
2002年、第一勧業銀行・富士銀行・日本興業銀行の3行が合併してみずほフィナンシャルグループが誕生した。この合併では、それぞれの銀行が長年使っていた異なるCOBOLシステム（STEPS・TOP・BEST）を統合する必要があった。
しかし統合は失敗した。2002年4月の開業直後から大規模なシステム障害が連発し、ATM停止・振込遅延・口座引き落とし不能が相次いだ。被害件数は250万件を超えた。
5.2 MINORI——4,000億円の賭け
その後、みずほ銀行は新たな基幹システム「MINORI（みのり）」の開発を2011年6月に着手した。完成まで6年、全面移行まで8年という超長期プロジェクトで、投資額は4,000億円台半ばと報じられた。2019年7月に全面稼働にこぎつけたが——MINORIの勘定処理コアは、依然としてCOBOLで実装されていた。
5.3 継ぎ目という新たな弱点
4,000億円台半ばを投じた「刷新」の後も、COBOLは王座に座り続けた。「リプレイス」とは、COBOLを置き換えることではなく、COBOLの上にJavaの衣を着せることだったのかもしれない。
そして2021年、MINORIは複数回の大規模障害を起こした。原因の一つは、COBOLのバッチ処理とJavaのオンライン処理の連携部分にあった。新旧の技術をつなぐ「継ぎ目」が、脆弱性の温床になったのである。
2025年の崖──経産省が鳴らした警鐘
2018年9月、経済産業省は「DXレポート〜ITシステム『2025年の崖』克服とDXの本格的な展開〜」を公表した。
日本企業が抱えるレガシーシステムは2025年前後に臨界点を迎える。COBOLをはじめとする古い言語で書かれたシステムは、技術者の高齢化・引退によって「誰も中身を知らないシステム」になりつつある。このまま放置すれば、2025年以降、日本全体で最大12兆円／年の経済損失が生じる——。
「2030年には最大約79万人のIT人材が不足するとも試算された」という予測も盛り込まれていた。その不足の多くは、COBOLなど特定のレガシー言語を扱える人材に集中する。
6.1 2025年、崖は越えられなかった
では現実はどうなったか。2026年の今、「2025年の崖」は乗り越えられたのだろうか。答えは、否である。
経済産業省は2025年5月、「レガシーシステムモダン化委員会総括レポート」を公表した。内容は、崖は依然として存在し、モダナイゼーション（近代化）は思うように進んでいないというものだった。
COBOL技術者の黄昏──平均年齢57.8歳の王国
COBOL王国の最大の危機は、外部からではなく、内部から来ている。
日本のCOBOL技術者の平均年齢は57.8歳とも言われる（信頼できる公的統計は未公表だが、業界複数の調査が類似した水準を指摘している）。40歳未満のCOBOLエンジニアは全体の15%にも満たない。現在のCOBOL技術者の多くが50〜60代であり、2030年にかけて大量退職期を迎える。
「このモジュールは1978年に書かれました。仕様書はありません。書いた人はすでに退職しています。なぜこのロジックになっているかは、誰も知りません」
こういう状況が、日本中の基幹システム開発現場で現実として存在している。IPA「DX白書」では、33.2%の組織が「システム知識の喪失」をモダナイゼーションの最大の障壁として挙げている。
7.1 逆説：引退した技術者が「高単価」で戻ってくる
一方、矛盾した現象も起きている。COBOL技術者の需要が、逆に高まっているのだ。
基幹システムの維持・更新ができる人材は減っているのに、システムを止めるわけにはいかない。結果として、定年を迎えたCOBOLエンジニアが「シニア技術者」として再雇用され、高単価で現場に戻る現象が起きている。60〜70代のエンジニアが、30代の若手が誰も読めない古いコードを守っている——それがCOBOL王国の現在地だ。
なぜ、リプレイスは失敗し続けるのか
「いつかCOBOLを置き換えよう」という掛け声は、この30年で何度繰り返されただろうか。しかし、リプレイス（システム置き換え）はほとんど失敗する。理由は複合的だ。
8.1 下一桁の地獄
COBOLは10進数（固定小数点）で計算するが、JavaやPythonは2進数（浮動小数点）で計算する。金融の利息計算や外国為替では、この違いが「円の下一桁」のズレとして現れる。テスト段階で「数字が合わない」問題が頻発し、移行プロジェクトが頓挫した事例は国内外で多い。
8.2 仕様書のない数十万行
現役のCOBOLシステムには、「なぜこのロジックになっているのか」が書かれた文書が存在しないものが多い。書いた人間がいない、覚えていない、あるいはすでに亡くなっている。リバースエンジニアリング（動いているコードから仕様を逆算する）を試みても、業務知識がなければコードの意味が理解できない。
8.3 365日止められないプレッシャー
銀行のシステムは365日・24時間停止できない。移行期間中も本番システムを動かし続けながら、並行して新システムをテストしなければならない。この「走りながら改造する」作業は、どんな優秀なチームでも極限の困難を伴う。
そして最大の問題は、「誰も責任を取りたくない」という組織的な力学だ。
COBOLシステムを「動いているうちは触らない」という判断は、個人にとっては合理的だ。触って障害が起きれば責任を問われる。触らなければ、少なくとも今日は安全だ。この判断が積み重なると、組織全体がレガシーを温存する方向に動く。
王国の年代記
誰も悪くない──構造の問題として
COBOLが生き続けているのは、誰かが悪いからではない。
COBOLを選んだ1960年代の技術者たちは、当時の最善を尽くした。COBOLで書かれたシステムを「動いているから触らない」と判断した管理者たちも、リスク管理として合理的だった。Y2K対応でCOBOLを延命させた経営者たちも、当時できる選択をした。みずほ銀行の技術者たちも、4,000億円台半ばと8年をかけて最善を尽くした。
それでも結果として、2026年の今、日本の金融・行政インフラは1959年に設計された言語で動いている。
これは技術の問題であり、組織の問題であり、そして人間の問題だ。「今動いているものを止める動機」がどこにもない状況で、誰が変革に踏み出せるだろうか。コストとリスクは変革する側が負い、利益は誰もが受け取る。この非対称性が、COBOL王国を永続させた。
経産省の「2025年の崖」は越えられなかった。しかしそれは、崖が実在しなかったのではなく、崖を越えることの難しさを正確に示していた。
COBOL王国は、明日も動く。静かに、正確に、誰も気づかないところで。
深夜3時。東京のどこかのデータセンターで、
今夜も夜間バッチが走っている。
数千万件の預金残高が更新され、
利息が計算され、
引き落としが確定する。
その処理を書いたのは誰か、
もう誰も覚えていない。
いつ書かれたのか、
仕様書には記録がない。
なぜそのロジックなのか、
聞ける人間は退職した。
だが処理は完走する。
エラーなし。警告なし。
ログに記録される1行の文字列：
―― 処理 完了