COBOLにしかない機能とは？C#と比較してわかった「金融システムが絶対死なない理由」

「給料日、ATMに並んだら『メンテナンス中』でイラッとしたことはありませんか？」

「『振込は翌営業日になります』という表示を見て、ネット社会なのになんで即時じゃないの？と不思議に思ったことはありませんか？」

「ニュースで『銀行システム障害』と聞くたびに、私のお金、本当に大丈夫なの？と不安になることはありませんか？」

私たちが日々スマホで便利に使っている銀行アプリや、街中のATM。

実はその裏側では、最新のAIでもブロックチェーンでもなく、1959年に生まれた

「COBOL（コボル）」

という、いわば「おじいちゃん言語」が今も現役で動いていることをご存知でしょうか。

「古すぎてエンジニアがいない」

「2025年の崖」

などと散々言われているのに、なぜメガバンクや政府は数百億円を投じても、この古い言語を最新の「C#」などに完全移行できないのか。

そこには、単なる「予算不足」や「怠慢」では片付けられない、もっと根深い

「技術的な理由」と「人間の心理」

が隠されているのです。

私は普段、満員電車に揺られながら東京で働く会社員であり、副業でライターをしています。

生活者としての「なんで？」という素朴な疑問と、ライターとしての「徹底的なリサーチ力」を武器に、今回は専門書や技術フォーラム、果ては海外のエンジニアの悲鳴まで（笑）、あらゆる情報を掘り起こしました。

文系の方にもわかるように、専門用語を日常生活のアレコレに例えながら、「金融システムの黒い心臓」とも呼ばれるCOBOLの正体を解き明かします。

この記事を読めば、あなたは銀行のシステムがなぜ「あんなに融通が利かないのか」、そして逆に「なぜあんなに信頼できるのか」が腑に落ちるようになります。

明日、職場の同僚や家族に

「ねえ、ATMがメンテナンスしてる本当の理由、知ってる？」

と、ちょっと自慢げに話せるトリビアと、技術の裏側にある「人間のドラマ」を持ち帰っていただけるはずです。

結論から言うと、COBOLはただの「化石」ではありません。

それは特定の任務（お金の計算）のために極限まで進化・特化した「専用機」です。

対してC#は、何でも器用にこなす「万能機」。

古いからダメ、新しいから良いという単純な話ではなく、私たちの預金を守るために、実はこの新旧の技術がギリギリのバランスで共存している

──それが、この世界の真実なのです。

デジタル遺品どうする？アカウント管理から法的手続きまで今すぐできる終活ガイド【2026年最新】

【残酷な真実】フリーランス新法で何が変わった？働き方の実態と対策【2026年版】

アニメーターの年収はなぜ低い？「やりがい搾取」と言われる給与の仕組みと是正への動きを解説

スポンサーリンク

第1章：見えざる巨人「COBOL」の正体

そもそもCOBOLって何者？

COBOL（コボル）は、1959年にアメリカで生まれたプログラミング言語です。

「Common Business Oriented Language（事務処理用共通言語）」の略で、その名の通り、ビジネスの事務処理をするために生まれました。

驚くべきデータがあります。

• 世界のATM取引の95%
• 対面金融取引の80%
• 銀行基幹業務の43%

これらが、いまだにCOBOLで動いているんです。

私たちが「ペイペイ！」とか言ってスマホ決済をしているその裏側、一番深いところでは、還暦を過ぎたCOBOLおじいちゃんがそろばんを弾いているようなものです。

なぜ「C#」と比較するの？

C#（シーシャープ）は、Microsoftが作った現代的で大人気なプログラミング言語です。

スマホアプリも、Webサイトも、ゲームも、AI開発もなんでもできる、いわば「クラスの人気者」。

「そんなに優秀なら、古いCOBOLなんて捨てて、全部C#にしちゃえばいいじゃない？」

誰もがそう思いますよね。

でも、それができない。

そこには「機能」の決定的な違いがあるんです。

スポンサーリンク

第2章：演算精度の迷宮「1円」を巡る攻防

金融システムで一番大事なこと。

それは「計算を間違えないこと」です。

「そんなのコンピュータなんだから当たり前でしょ？」

と思いますよね。

でも、実はここが最大の落とし穴なんです。

コンピュータは「割り算」が苦手？

一般的なコンピュータ（そしてC#などの多くの言語）は、数字を「2進数（0と1）」に変換して計算します。

ところが、私たち人間が使う「0.1（10分の1）」という数字。

これ、2進数に直すと「0.00011001100...」と無限に続く小数になっちゃうんです。

つまり、「割り切れない」。

C#などの現代的な言語で、何も考えずに計算すると、ほんのわずかな「誤差（丸め誤差）」が出ることがあります。

「0.1円くらいの誤差、いいじゃない」と思いますか？

でも、もしそれが1億回の取引で積み重なったら？

数千万円のズレになります。

銀行でそんなことが起きたら、信用は崩壊です。

COBOLの必殺技「パック10進数（COMP-3）」

ここでCOBOLの登場です。

COBOLには

「パック10進数（COMP-3）」

という、独自の必殺技があります。

これは、

「数字を10進数のまま、コンピュータのメモリに詰め込んで計算する」

という機能です。

料理に例えるならこうです。

• C#のアプローチ
  ホールケーキを3等分するとき、目分量で「だいたい33.333...%」に切る。
• COBOLのアプローチ
  最初から「3等分専用のカッター」を使って、分子レベルで正確に切り分ける。

しかも、銀行で使われている巨大コンピュータ（メインフレーム）には、このCOBOLの計算方法をハードウェアレベルで実行する専用の回路が組み込まれています。

だから、COBOLは「物理的に計算がズレない」んです。

「四捨五入」の罠

さらに怖いのが「端数処理」です。

C#などの現代言語で「四捨五入して」と命令すると、標準では

「銀行丸め（偶数丸め）」

という方法が使われることが多いです。

これは「2.5」を「2」に、「3.5」を「4」にする（近い偶数に寄せる）方法。

統計的には公平なんですが、日本の商習慣である「四捨五入（2.5は3にする）」とは違います。

COBOLからC#にシステムを書き換えた瞬間、

「おい！ 全口座の利息計算が1円ずつズレてるぞ！」

というホラーな事態が発生するのは、大体このせいです。

スポンサーリンク

第3章：データ定義の魔術「形式美」への執着

COBOLのプログラムを見ると、現代のエンジニアは「うわ、面倒くさ！」と言います。

でも、その「面倒くささ」こそが、安全の要なんです。

PICTURE句：究極の「型抜きクッキー」

COBOLでは、変数（データを入れる箱）を作るときに、ものすごく細かく指定します。

これを

「PICTURE句（ピクチャー句）」

と言います。

例えば、こんな感じです。

05  PRICE-TAG    PIC $$,$$9.99.

このたった1行で、以下のことを全部指定しています。

1. これは数字です。
2. 整数は最大4桁まで。
3. 小数は2桁まで。
4. 3桁ごとにカンマを入れてね。
5. 先頭に「$」マークをつけてね。
6. 余計な「0」は消してね（0100円じゃなくて100円）。

C#で同じことをやろうとすると、クラスを作って、設定を書いて、表示するときにフォーマット指定をして……

と、結構な行数を書かないといけません。

COBOLは、データを「箱」に入れる瞬間に、その形に

ガシャン！

とプレスしてくれるんです。

これなら、新人さんが間違ったデータ入れようとしても入りません。

最強の防衛策です。

REDEFINES：貧乏性の知恵が生んだ「メモリの多重人格」

そして、COBOLには

「REDEFINES（リディファインズ）」

という、変態的（褒め言葉）な機能があります。

これは、

「同じメモリの場所を、違う意味で使い回す」

機能です。

例えば、「100バイトの箱」があるとします。

• ある時は、これを「お客様の住所（文字）」として使う。
• 次の瞬間、同じ箱を「日付と金額（数字）」として使う。

中身を変換するんじゃなくて、「見方を変える」だけ。

これ、昔のコンピュータのメモリが金（ゴールド）より高かった時代の、「貧乏性の知恵」なんです。

我が家で言えば、客間を物置としても使いつつ、急な来客時には襖を閉めてごまかす、みたいな運用です。

現代のC#はメモリ管理が自動化されている（ガベージコレクションと言います）ので、こういう「物理メモリのここ！」みたいな指定をするのが逆に苦手です。

でも、この「貧乏性の知恵」のおかげで、COBOLはメモリを極限まで節約しながら、超高速で動けるんです。

スポンサーリンク

第4章：夜のF1レースバッチ処理

銀行システムには、絶対に負けられない戦いがあります。

それが「夜間バッチ」です。

私たちが寝ている間に、何千万件もの振込や引き落としを処理し、翌朝のATM稼働に間に合わせる。

これは時間との戦いです。

ベルトコンベア vs オーダーメイドキッチン

ここでもCOBOLとC#には大きな違いがあります。

• COBOL（レコード指向）
  例えるなら「ベルトコンベア」です。
  データが決まった枠（さっきのPICTURE句）に流し込まれ、加工され、次へ送られる。
  余計なことはしない。淡々と、猛スピードで流すだけ。
• C#（ストリーム指向）
  こちらは「オーダーメイドキッチン」。
  データを読み込むたびに「オブジェクト」という新しいお皿を用意して、料理を盛り付け、使い終わったらお皿を洗う（捨てる）。

C#で1億件のデータを処理すると、使い終わったお皿（ゴミ）が山積みになります。

これを片付けるために「ガベージコレクション（ゴミ収集）」という機能が動くんですが、その瞬間、システムが一瞬止まります（Stop the World）。

「ちょっと待って、今片付けてるから！」と。

秒単位を争う夜間バッチで、この「一時停止」は致命的です。

「朝までに計算が終わらなかったら、ATMが開かない！」

そんな大事故を防ぐために、銀行は今もCOBOLという

「止まらないベルトコンベア」

を使い続けているのです。

スポンサーリンク

第5章88レベルと「誰でも読める」罠

COBOLは「英語に近い」と言われます。

IF MALE PERFORM...
ADD 1 TO TOTAL.

「もし、男性なら、実行せよ」

「合計に1を足せ」

まるで英語の教科書です。

これは「自己文書化」といって、専門家じゃなくても読めるように作られているからです。

ビジネスルールを埋め込む「88レベル」

COBOLには

「88レベル」

という独特の機能があります。

これは、「'M' か 'F' なら『正しい性別』とする」みたいなビジネスルールを、データの定義場所に直接書き込んでしまう機能です。

これのおかげで、プログラムの本文はすごくスッキリします。

「もし『正しい性別』なら～」と書くだけでいいから。

「読める」からこその悲劇

しかし、「誰でも読める」ことには副作用もありました。

それは、

「誰でも触れてしまう」

こと。

何十年にもわたり、無数の担当者が、それぞれの書き方で「継ぎ足し建築」を行ってしまいました。

「このコード、何してるかわからないけど、動いてるから触るな」

そんな秘伝のタレみたいなコードが山積みになり、誰も全体像を把握できなくなってしまったのです。

これが「レガシーシステム」の正体です。

スポンサーリンク

第6章：2025年の崖「移行」という名の地獄

「そんなに古いなら、やっぱC#に書き換えようよ」

そう思いますよね。

多くの銀行もそう思いました。

そして、地獄を見ました。

仕様書がない！

システムの書き換え（移行）には「設計図（仕様書）」が必要です。

でも、30年前の仕様書なんて、今のシステムとは似ても似つかない状態です。

「現行のCOBOLコードこそが、唯一の正解（仕様）です」

そう言われた瞬間、C#への移行を担当するエンジニアは絶望します。

過去のバグ回避のための謎のロジック、退職した担当者の癖……

それらを全部解読して、C#で再現しなきゃいけない。

それはもはやプログラミングではなく、「考古学の発掘調査」です。

失敗率7割の理由

実際、オーストラリアの銀行はシステム刷新に5年と数百億円をかけました。

失敗事例も山ほどあります。

C#に書き換えたら、計算結果が1円ズレた。

処理スピードが出なくて夜間バッチが終わらない。

そんなトラブルが続出し、結局「COBOLのままの方がマシだった」と撤退するプロジェクトが後を絶たないのです。

これは、サンクコスト（埋没費用）への執着とも言えますが、同時に「COBOLという完成された芸術品」を、別の素材で再現することの難しさも物語っています。

スポンサーリンク

第7章：共存の時代未来への処方箋

じゃあ、私たちは永遠にCOBOLから逃れられないのでしょうか？

実は今、賢い戦略がとられています。

絞め殺しのイチジク戦略

植物の「イチジク」が、宿主の木に巻き付いて、時間をかけて取って代わるように。

「Strangler Fig（絞め殺しのイチジク）パターン」

という方法です。

1. 心臓部は残す
   お金の計算や元帳管理（勘定系）は、信頼できるCOBOLに残す。
2. 手足は新しく
   スマホアプリやWeb画面、新しいサービスは、C#やクラウドで作る。
3. つなぐ
   C#からCOBOLを呼び出して使う。

これなら、「計算がズレない安心感」と「スマホで使える便利さ」を両立できます。

そして長い時間をかけて、COBOLの機能を少しずつ、安全にC#側に移していくのです。

AIの登場

さらに最近では、生成AIがCOBOLのコードを解析して、C#に翻訳する手助けをしてくれるようになりました。

IBMなどは、AIを使ってCOBOLのモダナイズ（近代化）を進めるツールを出しています。

人間の手では解読不可能だった「秘伝のタレ」を、AIが解きほぐしてくれる未来が来ているのです。

スポンサーリンク

結論COBOLは「遺産」であり、C#は「未来」である

ここまで読んでいただき、ありがとうございました。

COBOLとC#。

この比較は「どちらが優れているか」という勝負ではありませんでした。

• COBOL
  「1円のズレも許さない」
  「絶対に止まらない」
  という、金融システムの狂気的なまでの厳密さを守るための「専用機」。
• C#
  変化に対応し、新しい価値（アプリやAI連携）を生み出すための「万能機」。

私たちの生活は、この2つの技術の絶妙なコンビネーションによって支えられています。

次にATMでお金を下ろすとき、あるいはスマホで残高を確認するとき、思い出してください。

画面の向こう側で、60歳のベテラン（COBOL）と、20代の若手エリート（C#）が、背中合わせで働いている姿を。

そう思うと、無機質なATMが、ちょっとだけ頼もしく見えてきませんか？

レガシー（Legacy）という言葉には、「時代遅れ」という意味もありますが、

「遺産」

という意味もあります。

先人たちが築き上げた「信頼」という遺産を、新しい技術でどう受け継いでいくか。

それが今、問われているのです。

付録：一目でわかる！COBOL vs C# 比較表