COBOLは死なない──誕生から66年、世界の金融取引の95%を今も動かす言語の話
はじめに
「COBOLはもう死んだ言語だ」──そう言われ続けて、66年が経つ。
しかし今日もあなたがATMで現金を引き出したとき、クレジットカードで決済したとき、給与が口座に振り込まれたとき、その裏側ではCOBOLが動いている。
世界の金融取引の95%、米国の自動決済システム（ACH）の処理の大部分、日本の主要銀行の勘定系──これらを2026年現在も支えているのは、1959年に生まれた言語だ。
「なぜ死なないのか」という問いへの答えは、感傷でも惰性でもない。COBOLが生き続けるのには、工学的な理由がある。
1. COBOLとは何か──誕生から現在まで
1959年、国防総省の会議室で
COBOLの誕生は1959年。米国国防総省が主導した会議で仕様が策定された。中心人物の一人が、コンピュータ科学の先駆者グレース・ホッパーだ。
ホッパーの設計思想は明確だった。「プログラムは英語で書けるべきだ」。当時のアセンブラや数式中心の言語に対するアンチテーゼとして、COBOLは人間が読める業務処理言語として設計された。
設計思想：2つの核心
COBOLには2つの設計上の核心がある。
① 英語に近い可読性
IDENTIFICATION DIVISION.
PROGRAM-ID. INTEREST-CALC.
DATA DIVISION.
WORKING-STORAGE SECTION.
01 PRINCIPAL PIC 9(10)V99.
01 ANNUAL-RATE PIC 9(3)V9(4).
01 INTEREST-AMOUNT PIC 9(10)V99.
PROCEDURE DIVISION.
COMPUTE INTEREST-AMOUNT = PRINCIPAL * ANNUAL-RATE / 100
DISPLAY "利息額: " INTEREST-AMOUNT
STOP RUN.
変数名がPRINCIPAL（元本）、ANNUAL-RATE（年利）、INTEREST-AMOUNT（利息額）。コードを読めば何をしているかが自然言語に近い形でわかる。
② 10進数演算の正確性
COBOLの数値型COMP-3（パック10進数）は、金額計算において浮動小数点誤差が発生しない。
多くのモダンな言語が採用しているIEEE 754準拠の2進浮動小数点数では、次のような演算が問題を起こす。
// JavaScript / Python等における丸め誤差の例
console.log(0.1 + 0.1 + 0.1 === 0.3); // => false
console.log(0.1 + 0.1 + 0.1); // => 0.30000000000000004
「たった1京分の4の誤差」に見えるかもしれない。しかし利息計算・為替レート・億単位の取引でこの誤差が積み重なれば、一瞬で致命的な不整合になる。
対してCOBOLは、言語仕様のレベルで10進数をそのままメモリ上に保持する型をネイティブにサポートしている。
* COBOLにおける絶対的な固定小数点数の定義
01 BALANCE PIC 9(13)V99 COMP-3.
* 整数部13桁・小数点以下2桁を「パック10進数」としてメモリ上で10進数のまま厳密に計算する
JavaやPythonでBigDecimalなどの重いクラスを明示的に呼び出さなければならない処理を、COBOLはCPUの10進演算命令と直結したレベルで、ネイティブかつ超高速に実行できる。銀行が1円単位の正確性を求める以上、この特性は今も代替できていない。
現在の規模
COBOLのコードは今も世界中で動いている。
| 指標 | 規模 |
|---|---|
| 現存するCOBOLコード総量 | 推定2,000億〜3,000億行 |
| 毎日処理されるトランザクション数 | 推定950億件以上 |
| 日本の主要銀行の勘定系 | 多くが数千万〜数億行規模 |
数字だけ見ると、COBOLはどのモダン言語よりも「実際に動いている」言語だ。
2. なぜ金融取引の95%を動かしているのか
レコード指向I/Oの圧倒的スループット
金融システムの処理の多くはバッチ処理だ。夜間に数千万件の取引レコードを一括で処理し、残高を更新し、帳票を生成する。
COBOLがこのバッチ処理に強い根本的な理由は、レコード指向のI/O設計にある。
一般的なRDB/オブジェクト型のI/Oと、COBOLのレコード指向I/Oを構造で比較すると以下のようになる。
【一般的なRDB/オブジェクト型I/O】
[ディスク] ──► [SQL解析/カーソル] ──► [ORM/オブジェクトマッピング] ──► [アプリ層]
↑
1行ごとにデータ型のパースやバインディングのオーバーヘッドが発生
【COBOLのレコード指向I/O】
[ディスク] ──► [固定長バッファ（メモリ）] ──► [DATA DIVISIONの定義（構造体）]
↑
ディスクから読み込んだバイナリが、そのままメモリ上の変数（PIC句）に
マッピングされ、パースなしで即演算可能
メモリが極めて高価だった時代に生まれた「データをパースせず、構造体の形のままメモリに一発展開してシーケンシャルに処理する」という設計は、ギガバイト・テラバイト級のバッチ処理において、今なおモダンなストリーム処理を圧倒するスループットを発揮する。
IBMのZ16上でCOBOLが処理できるトランザクション数は、1日あたり最大3,000億件。この数字はクラウドの一般的なワークロードと比較対象にならない。
40〜60年分の業務ロジックが埋め込まれている
より本質的な理由は、コードに業務知識が蓄積されていることだ。
日本の大手銀行の勘定系COBOLには、過去40〜60年間の金融規制変更・商品改定・特例処理・障害対応が、すべてコードとして刻み込まれている。
「この条件分岐は何のためにあるのか」──ドキュメントが存在しないケースも多く、コード自体が唯一の仕様書になっている。これを別の言語で「同等に」再実装するコストは、天文学的な数字になる。
3. 「COBOLは読めない」は本当か
JavaエンジニアがはじめてCOBOLを見たとき、まず戸惑うのは構造の違いだ。しかし慣れると「意外と読める」と感じる人が多い。
DIVISIONによる構造とJavaクラスの対比
COBOLプログラムは4つのDIVISIONで構成される。
| COBOL DIVISION | Javaの対応概念 | 役割 |
|---|---|---|
| IDENTIFICATION DIVISION | クラス宣言 | プログラム名・作成日・作者 |
| ENVIRONMENT DIVISION | 設定・プロパティ | 入出力ファイルの物理名マッピング |
| DATA DIVISION | フィールド宣言 | 変数・レコード構造・ファイル定義 |
| PROCEDURE DIVISION | メソッド本体 | 処理ロジック |
利息計算の対比コード
実際のコードで比較してみよう。「元本×年利÷12で月次利息を計算する」という処理だ。
// Java版（doubleを使うと精度が保証されない点に注意）
public class InterestCalc {
public static void main(String[] args) {
double principal = 1000000.00; // 元本
double annualRate = 0.015; // 年利1.5%
double monthlyInterest = principal * annualRate / 12;
System.out.printf("月次利息: %.2f円%n", monthlyInterest);
}
}
IDENTIFICATION DIVISION.
PROGRAM-ID. INTEREST-CALC.
DATA DIVISION.
WORKING-STORAGE SECTION.
01 PRINCIPAL PIC 9(10)V99 COMP-3 VALUE 1000000.00.
01 ANNUAL-RATE PIC 9(1)V9(4) COMP-3 VALUE 0.0150.
01 MONTHLY-INTEREST PIC 9(10)V99 COMP-3.
PROCEDURE DIVISION.
COMPUTE MONTHLY-INTEREST = PRINCIPAL * ANNUAL-RATE / 12
DISPLAY "月次利息: " MONTHLY-INTEREST "円"
STOP RUN.
構造は冗長に見えるが、何をしているかは明確に読める。COMPUTEは計算、DISPLAYは出力。英語として読めるのが設計思想の現れだ。
PIC 9(10)V99という型定義が独特だが、これは「整数部10桁・小数部2桁の固定小数点数」を意味する。Javaのdoubleと違い、精度が保証される。
4. COBOLが死なない本当の理由
技術的負債ではなく「埋め込まれた業務知識」
COBOLコードを「技術的負債」と呼ぶのは正確ではない。
負債というのは「返済すれば消える」ものだ。しかしCOBOLに蓄積された業務ロジックは、移行しても消えるわけではない。同じ複雑さが、別の言語で書き直されるだけだ。むしろ、書き直す過程で業務知識が失われるリスクの方が大きい。
移行コストの非対称性
「なぜ移行しないのか」に対する現実的な答えは、コストの非対称性だ。
| 項目 | 内容 |
|---|---|
| 移行対象 | 数千万〜数億行のCOBOL/アセンブラ |
| 移行期間 | 大手行クラスで10〜15年 |
| 概算費用 | 数百億〜数千億円 |
| リスク | 移行中の障害が社会インフラに直結 |
「動いているシステムを止めない」という判断は、保守的な思考ではなく合理的なリスク管理だ。
COBOLエンジニア高齢化問題
COBOLを深く理解しているエンジニアの平均年齢は、日本では50代後半〜60代に達しているとされる。
逆説的だが、これがCOBOLの価値をさらに高めている。希少なスキルセットは市場価値が上がる。米国では2020年代に入り、COBOLエンジニアの時給が急騰した例も報告されている。
5. これからのCOBOL──モダナイゼーションの現実
「捨てる」ではなく「読み解いて再構築する」
現実的なアプローチは、COBOLを「捨てる」のではなく、業務ロジックを正確に読み解いて、現代的な言語で再構築することだ。
そのための技術的アプローチとして、静的解析パイプラインの構築が広まっている。
COBOL/HLASM ソース
↓ 字句解析・構文解析
AST（抽象構文木）
↓ CFG（制御フローグラフ）構築
SSA形式（静的単一代入）
↓ 意味解析・IR生成
IR（中間表現）
↓ コード生成
Kotlin / Java
COBOLの構文解析自体は難しくない。難しいのは意味の解析だ。条件分岐の意図、REDEFINES句による型の多重解釈、GO TO文による非構造的な制御フロー──これらを正確に中間表現に落とし込む作業が、移行エンジニアリングの本質になる。
さらにHLASM（高水準アセンブラ）が混在する環境では難度が一段上がる。自己書き換えコードやEX命令（実行時に命令の一部を動的に書き換える）は、コンパイラ理論の静的解析が原理的に完全解決できない領域だ。「このアドレスに何が書かれているか」は実行してみなければわからない。これをどうIRに安全に抽象化するかが、2026年現在の移行エンジニアリングの最前線になっている。
AIによるCOBOL解析の現在地
大手クラウドベンダーがCOBOL移行支援ツールを相次いでリリースしているが、現時点ではAIによる自動変換は**「補助ツール」の域を出ない**。
AIは「読みやすくする」ことはできる。しかし「正しく動くコードに変換する」保証は、まだ人間のエンジニアリングに依存している。
おわりに
COBOLが死なない理由を一文で言うなら、「正確に動き続けることに、66年間最適化されてきたから」だ。
新しい言語は表現力が高く、エコシステムが豊かで、採用しやすい。しかし**「銀行口座の残高を1円も間違えずに処理する」という要件において、COBOLは今も最も実績のある言語だ**。
これから金融系・公共系の案件に関わるエンジニアにとって、COBOLを「読めないもの」として遠ざけるのはもったいない。構造を知れば読める。読めれば、業務ロジックが見える。
今回はCOBOLという言語の工学的な生存理由にスポットを当てたが、メインフレームのモダナイゼーションは言語変換だけで完結するものではない。富士通・日立・IBM各社のOS/TPミドルウェア/ファイル体系の決定的な非互換性や、アセンブラの静的解析における原理的な限界といった「ガチの地雷原」については、noteにて全6回の詳細な連載記事を公開している。
システム刷新のリアルな戦略論と技術論に興味のある方は、ぜひ合わせて覗いてみてほしい。
日本の汎用機はどこへ行くのか：2035年問題の深淵（note連載）ほか