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連載）ほか