COBOLとは｜60年消えない理由・4つの特徴と3業界の稼働実態

【1分でわかるこの記事の要約】

• 社会的インフラの現役基盤： COBOLは誕生から65年を経た今も、世界のATM取引の95%、国内開発プロジェクトの約16%（Javaに次ぐ2位）を支える、金融・行政の不可欠な基盤である。

• 温存の合理的理由と限界： 10進数演算の正確性と大規模バッチ処理における圧倒的な信頼性が存続の理由だが、技術者の高齢化とシステムのブラックボックス化が深刻な経営リスクとなっている。

• 経営判断の岐路： 「全廃（Java等への移行）」か「共存（API連携等のモダナイゼーション）」か、AI活用による仕様可視化を含め、自社の状況に応じた段階的な戦略投資の判断が求められる。

COBOLとは、1959年に米国防総省の主導で開発された事務処理用プログラミング言語だ。誕生から65年以上が経過した現在も、全世界で推定2,500億行のCOBOLコードが稼働し、ATM取引の95%、対面クレジットカード取引の80%を処理している。「時代遅れの言語」と言われ続けながら消えない理由は、COBOLが持つ技術的な特性と、それに依存する社会インフラの規模にある。

日本では1963年にCOBOLが導入されて以来、金融機関、行政機関、製造業の基幹システムに深く組み込まれてきた。IPA（情報処理推進機構）の「ソフトウェア開発データ白書」によれば、国内開発プロジェクトの使用言語としてCOBOLはJava（42.4%）に次ぐ2位（16.3%）を占める。本記事では、COBOLの基本概念から、なぜ消えないのか、どこで動いているのか、何が問題なのかを構造的に整理する。

COBOLとは — 誕生の背景と基本概念

COBOL（Common Business Oriented Language）は、日本語に訳すと「共通事務処理用言語」だ。名前の通り、ビジネスの事務処理を効率化するために設計された。

誕生の経緯

1950年代、コンピュータの利用が軍事・科学計算から一般のビジネスにも広がり始めた。だが、当時の主要言語であるFORTRANは科学技術計算に特化しており、事務処理を行うには専門知識が必要だった。

この課題を解決するため、米国防総省が主導してビジネス向けの共通言語の開発プロジェクトが発足した。開発を主導したのは数学者・プログラマーのグレース・ホッパー氏だ。彼女が手がけた「FLOW-MATIC」を基盤に、1959年にCOBOLの初版が策定された。

日本での普及

日本では1963年からCOBOLが使われ始めた。銀行の勘定系システム、保険の契約管理、製造業の受発注管理——大量のデータ処理が必要なビジネス領域で急速に広まった。高度経済成長期に構築された基幹システムの多くはCOBOLで書かれており、その一部は改修を重ねながら現在も稼働し続けている。

プログラムの基本構造

COBOLのプログラムは4つの「部（DIVISION）」で構成される。

データの定義と処理手順が明確に分離されている点が特徴であり、この構造が大規模システムでの可読性と保守性を支えている。

COBOLが60年以上「消えない」4つの理由

「なぜCOBOLはまだ使われているのか」——この疑問に対する答えは、単に「移行する金がないから」ではない。COBOLには、特定の用途において他の言語では代替しにくい技術的な強みがある。

理由1: 10進数演算の正確性

COBOLは内部的に10進数（BCD: Binary-Coded Decimal）で演算を行う。これに対し、多くのモダン言語は2進浮動小数点を使用する。2進浮動小数点では「0.1 + 0.2 = 0.30000000000000004」のような丸め誤差が発生し得る。

金融業界では、利息計算で0.01円の誤差も許されない。年金の支給額計算、保険料の算定、税額の計算——いずれも端数処理の正確性が法的要件として求められる。COBOLの10進数演算は、この要件を満たす「設計段階からの保証」だ。

理由2: 大規模バッチ処理への適性

COBOLはバッチ処理——大量のデータをまとめて一括処理する方式——に最適化されている。毎日数百万件の口座残高更新、月末の給与計算、年度末の決算処理。「大量データの定型処理」は、COBOLが最も得意とする領域だ。

IPAの「ソフトウェア開発データ白書」では、大規模プロジェクト（100万ステップ以上）でのCOBOL使用率が100%に達する。リアルタイム処理やWebアプリケーションには向かないが、バッチ処理においてCOBOLの処理効率は依然として高い水準にある。

理由3: 英語に近い構文の可読性

COBOLの構文は他のプログラミング言語に比べて英語の自然言語に近い。MOVE A TO B（AをBに移す）、ADD X TO Y（XをYに加える）といった記述は、プログラミングの専門知識がなくても処理内容の概要を推測できる。

この可読性は、数十年にわたって異なる担当者が改修を重ねる基幹システムにおいて重要だ。「何をやっているか、おおよそ読める」ことが、保守の引き継ぎを容易にする設計上の強みになっている。

理由4: 長期運用実績による信頼性

COBOLで構築されたシステムの中には、30年以上の連続稼働実績を持つものがある。社会インフラとして24時間365日の安定稼働が求められる金融・行政システムにおいて、「数十年にわたって安定して動いている」という実績は、技術的な仕様以上に強い信頼の根拠になる。

ただし、この信頼性がCOBOLシステムの「温存」を促す面もある。「動いているものは触るな」という判断は、安定稼働の観点からは合理的だが、長期的にはブラックボックス化のリスクを蓄積する。

COBOLが動いている3つの業界 — 現在の稼働実態

COBOLが現在も稼働している主要な3業界と、その規模を整理する。

金融業界: 社会インフラの中核

IBMが公開しているデータ（IBM COBOL Report, 2022）によれば、COBOLは以下の規模で金融インフラを支えている。

• オンラインバンキングシステムの40%以上の基盤

• 対面クレジットカード取引の80%を処理

• 全ATM取引の95%を処理

• 毎日30億ドル以上の商取引を支えるシステムで稼働

日本国内でも、メガバンク・地方銀行の勘定系システム、生命保険・損害保険の契約管理、証券の約定処理など、金融の根幹をCOBOLが担っている。全銀システム（全国銀行データ通信システム）もCOBOLベースで構築されていたが、Javaへのマイグレーションも進み始めている。

行政機関: 年金・税務・住民基本台帳

国の年金管理システム、国税庁の税務処理システム、自治体の住民基本台帳システム——行政の基幹系にもCOBOLは深く組み込まれている。1,000万ステップ級のCOBOLシステムが、官公庁や大企業を中心に稼働中だ。

行政システムのCOBOLは、法改正のたびに改修が加えられてきた。税制改正、社会保障制度変更、マイナンバー対応——改修の累積で元の設計を大きく逸脱した状態になっているケースは珍しくない。レガシーシステムの典型的な姿がここにある。

製造業・流通: 受発注と在庫管理

製造業の受発注管理、在庫管理、生産計画の基幹系にもCOBOLが使われている。メインフレーム上で動く大規模な基幹系は、COBOL＋JCL（ジョブ制御言語）で構成されていることが多い。流通業のPOSデータ集計や卸売の受発注処理も同様だ。

これらの業界では、SAP等のERPパッケージへの移行が進んではいるが、COBOLで書かれた独自の業務ロジック——長年の取引慣行やカスタムルール——をERPの標準機能に完全に置き換えるのは容易ではない。

COBOLが抱える4つの課題 — なぜ問題視されるのか

COBOLの技術的な強みとは裏腹に、COBOLを取り巻く環境は年々厳しさを増している。

課題1: エンジニアの高齢化と人材不足

COBOLの最大の課題はエンジニアの不足だ。COBOLを扱えるエンジニアの平均年齢は55歳を超え、年間退職率は10%に達する（Reuters, 2023）。新たにCOBOLを学ぶ若手は極めて少なく、60%以上の組織がCOBOLエンジニアの確保を最大の課題と回答している。

「保守できる人がいなくなる」——この問題は、数年後ではなく今この瞬間に進行している。

課題2: ブラックボックス化

数十年にわたる改修の累積で、COBOLシステムの多くはソースコードと仕様書の乖離が深刻だ。設計当初の担当者はすでに退職し、「なぜこの処理が入っているのか」を説明できる人間がいない。

ブラックボックス化したCOBOLシステムは、改修のたびに想定外の影響が出るリスクが高く、テスト工数が膨らむ。結果として保守コストが上昇し、レガシーシステムの可視化による仕様の再把握が急務となっている。

課題3: モダン技術との連携困難

COBOLシステムの多くはメインフレーム上で動いており、REST APIやマイクロサービスアーキテクチャといったモダンな技術との直接的な連携が困難だ。DXの推進には、社内外のシステムとのデータ連携が不可欠だが、COBOLの閉じたアーキテクチャがこの連携を阻んでいる。

ただし、最新のCOBOLコンパイラ製品はJSON対応やREST API呼び出し機能を備えているものもある。「COBOLだから連携できない」とは一概に言えず、製品とバージョンによって対応状況は異なる。

課題4: DX推進の足かせ

IT予算の大半がCOBOLシステムの保守運用に消費されると、新たなデジタル投資に回す余力がなくなる。経済産業省が2018年の「DXレポート」で提起した「2025年の崖」の核心がまさにこの構造だ。COBOLシステムの存在そのものが悪いのではなく、保守に経営リソースが吸い取られ、変革の余力が失われることが問題になる。

COBOLの今後 — 「全廃」か「共存」か

COBOLの今後は、「すべて捨てる」か「うまく付き合う」かの二者択一ではない。自社の状況に応じた段階的な判断が必要だ。

全廃アプローチ: Javaや.NETへの移行

COBOLシステムをJavaや.NETに変換して全面的に置き換えるアプローチだ。成功すれば保守人材の確保が容易になり、モダン技術との連携も開ける。だが、大規模COBOLシステムの移行には数年・数十億円規模の投資が必要で、移行中のリスク管理も課題になる。COBOL廃止のタイムラインと自社の状況を照合した判断が求められる。

共存アプローチ: API連携と段階的モダナイゼーション

COBOLシステムをすぐに廃止せず、APIラッパーやデータ連携基盤を介してモダン技術と「つなぐ」アプローチだ。コアのバッチ処理はCOBOLのまま維持し、フロントエンドやデータ分析層にはモダン技術を採用する。リスクとコストを抑えつつ、段階的にレガシー依存度を下げられる。

AI活用の可能性

AIによるCOBOLコードの解析・自動変換技術が実用段階に入りつつある。NTTデータの機械学習活用コード解析、富士通のテスト自動化技術など、大手SIerもAI活用を本格化させている。ブラックボックス化したCOBOLシステムの仕様を、AIで可視化して移行計画に活用する——保守人材の減少に対する現実的な打ち手だ。

まとめ — COBOLは「問題」ではなく「現実」

COBOLは「古い」という一言で片づけられる言語ではない。ATMでお金を引き出し、年金を受け取り、保険金を請求する——日常生活のあらゆる場面でCOBOLは静かに動いている。問題はCOBOLの存在そのものではなく、COBOLシステムを保守・進化させる体制が維持できるかだ。自社のCOBOLシステムの規模、保守人材の状況、ビジネスへの影響度を正確に把握した上で、「捨てる」「つなぐ」「維持する」の判断を下すことが、現実的なアプローチになる。

COBOLシステムの仕様、ドキュメントが残っていますか？

エイジレスでは、独自AI「ARIADNE」がCOBOLのソースコードから処理内容・依存関係を自動解析し、仕様書を可視化します。ベテラン精鋭部隊「TITANS」が業務意図を読み解き、移行計画の土台を整えます。

ASIS解析の資料をダウンロード

よくある質問

Q: COBOLは今から学ぶ価値がありますか？

A: 目的による。COBOL技術者の需要は保守・移行プロジェクトから安定的に発生しており、正社員で年収500〜600万円、フリーランスで600万円超の市場相場がある。新規開発の案件はほぼないが、保守人材の不足により競争率は低く、一定の市場価値がある。ただし、COBOLだけを専門にするのではなく、Javaやクラウド技術と組み合わせて「COBOLからの移行ができるエンジニア」を目指すのが、キャリア戦略としては堅実だ。

Q: COBOLシステムをJavaに移行するのにどれくらいかかりますか？

A: システムの規模と複雑さによるが、数万ステップ程度の小規模システムで6ヶ月〜1年、数百万ステップの大規模システムでは3〜5年かかるケースもある。コストは数千万円から数十億円と幅が広い。移行そのものだけでなく、現行システムの仕様可視化、テスト、並行運用期間を含めた計画が必要だ。まずは現行システムの棚卸しと仕様の可視化から着手することを推奨する。

Q: COBOLのサポートはいつまで続きますか？

A: COBOL自体は標準規格（ISO/IEC 1989）であり、「公式な廃止」はない。ただし、コンパイラ製品のサポートにはメーカーごとの期限がある。Micro Focus COBOLやIBM Enterprise COBOLなど主要製品のサポートは2035年前後が一つの節目と見られている。言語としてのCOBOLが使えなくなるわけではないが、コンパイラのサポート終了により、セキュリティパッチの提供やバグ修正が受けられなくなるリスクがある。