北国銀行の脱COBOLについて

北國銀行が提示した「4ヶ月でのCOBOL脱却」というニュースは、金融ITや基幹システムに携わる者にとって極めて強烈なインパクトをもたらした。メガバンクすら足踏みを続けるレガシーシステムの現代化（モダナイゼーション）を、地方銀行が生成AIを駆使して超短期間で成し遂げたという構図は、一見すると技術革新による劇的な逆転劇のように映る。

しかし、この事象の表面だけを掬い取り、「生成AIを使えば古いシステムは容易にJavaへ書き換えられる」と解釈するのはあまりに浅薄だ。海外の失敗事例や金融システムの構造、さらには言語そのものの寿命を冷静に紐解いていくと、北國銀行の取り組みの本質はAIの魔法などではなく、20年越しの緻密な経営戦略と極めてロジカルな工程設計にあることが浮かび上がってくる。

この記事では、このニュースの背後に隠された構造的真実と、日本の産業界が直面する「レガシーからの撤退戦」のリアルについて考案を深めたい。

1． 北國銀行の「4ヶ月・変換率97%」という数字のからくり

ニュースの見出しを飾った「4ヶ月」や「変換率97%」という数字は、単なる結果の断片に過ぎない。これを正しく評価するには、北國銀行がこれまで辿ってきたシステム構成の変遷と、AIの具体的な使いどころを分解する必要がある。

（1） 20年越しの準備：前提としての勘定系AWS移行

北國銀行が今回の言語変換をわずか4ヶ月で実行できた最大の要因は、すでに2021年の時点で、邦銀初となる勘定系システムのAWS（クラウド）移行を完了させていた点にある。

多くの金融機関において、COBOL脱却の最大の障害となるのは、半世紀近くにわたりブラックボックス化してきたメインフレーム（汎用機）というハードウェアそのものの縛りだ。北國銀行は今回のプロジェクト以前に、すでに重厚なメインフレームを破棄し、クラウド上でCOBOLを動かすオープン化のフェーズを終えていた。今回の取り組みは「メインフレームからの脱出」ではなく、「すでにクラウド上で動いていたCOBOLをJavaへ書き換える」という局地戦だったのである。

（2） 生成AIの使い方：コードの直接出力ではなく「変換プログラム」の開発

今回の試みにおいて最も戦略的だったのは、生成AIに個々のCOBOLプログラムを手当たり次第にJavaへ書き換えさせたわけではないという点だ。

金融システムにおいて、生成AIに直接コードを書かせるアプローチは致命的な破綻を招く。生成AIの出力には確率的なブレ（非決定性）が存在するため、同じ入力に対しても毎回異なるコードを生成するリスクがあり、精度100%の絶対的な正確性と再現性が求められる金融機関の計算処理には到底耐えられない。

北國銀行が行ったのは、COBOLからJavaへ統一されたルールで安全に翻訳するための「専用変換プログラム（トランスパイラ）」そのものを、生成AIの支援を得て構築・チューニングしたことだ。

• 変換ルールの厳格な定義：COBOL固有の型や金融計算の丸め処理を、Javaの共通ライブラリへどう落とし込むかの設計思想を定義する。

• トランスパイラの精度向上：変換プログラム自体を生成AIを使って高速にブラッシュアップし、北國銀行のコードに最適化した翻訳機を作り上げる。

• 一括機械変換の実行：完成したトランスパイラに全ソースコードを通し、一貫した構文ルールで一気にJava化を図る。

つまり「4ヶ月」という期間の大半は、泥臭い手作業のコード書き換えではなく、「精度の高い自動翻訳機を作り上げるための試行錯誤」に費やされたのである。

（3） 「残り3%」とカットオーバーに潜む現実

変換率97%という数字は驚異的だが、反面として残り3%は標準ルールでは変換できなかった特殊な例外処理や、長年の改修で歪んだコアロジックであることを意味する。

仮に全体で100万行のプログラムが存在する場合、残り3%とは3万行に及ぶ手動修正の山だ。この最もリスクの高い3%を、自社のエンジニアが仕様を読み解きながら手動でデバッグし切ったことこそが、内製化の本当の泥臭さであり評価されるべき点と言える。

さらに重要なのは、現状はコードの変換が終わった段階であるにすぎず、新システムが実際に稼働する「カットオーバー」はこれから迎えるという事実だ。旧システムと新システムに過去数億件規模の本番データを流し込み、出力結果が1ビットの狂いもなく一致するかを検証する回帰テスト（レグレッションテスト）や、Java特有のメモリ処理に伴う遅延を抑えるチューニングなど、本当の試練はカットオーバーの無事故通過まで続くことになる。

2． メガバンクが真似できない構造的理由

地方銀行である北國銀行がこのモデルを成立させたからといって、それをそのままメガバンクに適用することは不可能に近い。そこには怠慢ではなく、背負っているシステムの規模と社会的リスクの違いに起因する構造的な壁が存在する。

（1） 桁違いのコード量と複雑な歴史の累積

メガバンクの基幹システムが抱えるコード量は数億行規模に達し、北國銀行のそれとは桁が1つから2つ異なる。さらに、過去の大型銀行統合の過程で異なるシステムを「接ぎ木」のように連結してきた歴史があり、全体像を完全に把握している人間が１人も存在しないという暗黙の負債を抱えている。

仮に変換率が97%だったとしても、メガバンクにおける「残り3%」は数百万行から数千万行の特殊ロジックを意味する。その手動修正と検証にかかるコストは数千億円規模に膨らみ、期間も数年から十数年を要するため、投資対効果の面で経営判断として成り立たない。

（2） ダウンが許されない社会的決済インフラの重圧

地方銀行のシステム障害も甚大な影響を及ぼすが、メガバンクの勘定系システムは日本全体の経済活動を支える国家レベルの決済インフラそのものだ。システムがたった数時間停止するだけでも全国の振込やカード決済が止まり、経済活動が止まる。

リスクとリターンの天秤があまりにも不釣り合いであるため、メガバンクにとっての「動いているものには触るな」という判断は、極めて合理的な自己防衛戦略となる。

3． 海外の失敗事例が示す「力技モダナイゼーション」の限界

レガシーシステムからの脱却で悲惨な結果を招いた事例は、海外にも枚挙にいとまがない。これらの失敗は、システム変換における地雷がどこにあるかを明確に示している。

（1） 英国TSB銀行の大惨事（2018年）

英国の大手行であるTSB銀行は、親会社のシステムへ統合するにあたり、旧来のCOBOLベースのシステムから一気に新システムへ切り替える「ビッグバン移行」を断行した。

その結果、数百万人の顧客が口座にアクセス不能となり、他人の口座情報が表示されるなどの壊滅的なシステム障害が発生した。事前のテスト不足と、長年複雑化したビジネスロジックを解きほぐせないまま外部ベンダー主導で一括置換を試みたことが敗因であった。

（2） 米国DOGEと社会保障局（SSA）の無謀な宣言

米国政府効率化省（DOGE）を率いるイーロン・マスクは、米社会保障局が抱える約6千万行のCOBOLコードを「生成AIを使って数カ月で書き換える」とぶち上げた。しかし、実務経験者や専門家からは即座に実現可能性を否定されている。

この試みが無謀とされる理由は、技術的な変換精度以上に「ドメイン知識（業務文脈）の欠如」にある。制度の歴史や法改正に伴う例外処理の意図を理解しないまま、AIの力技だけでコードを翻訳しようとすれば、必ず年金支給の現場で計算不整合を起こす。AIはコードの構文を追うことはできても、その背景にある数十年の行政ロジックの「意味」までは自発的に解釈できない。

（3） 北國銀行が踏まなかった地雷

これらの失敗事例と対比すると、北國銀行の勝因が浮かび上がる。
第１に、インフラのクラウド化とアプリのJava化を同時に行わず、段階的にリスクを分離したこと。
第２に、AI任せにせず、銀行業務のロジックを熟知した自社エンジニアが全責任を持ってコードを検証・手動修正したことである。

4． メガバンクの現実的回答：「包囲戦」と「枯れた技術」の価値

では、一括変換を選べないメガバンクは、どのようにレガシー問題と向き合っているのか。彼らが採っているのは、正面突破ではなく「包囲戦（Strangler Fig Pattern：絞め殺しの木パターン）」と呼ばれる徐々に領域を削り落としていく戦略だ。

（1） マイクロサービス化と本丸の最小化

メガバンクは、勘定系という巨大な塊の中から「住宅ローン審査」「外為処理」「顧客管理」といった機能を周辺部分から１つずつ切り出し、クラウド上の最新言語で再構築している。

残された勘定系の「本丸」には、預金や為替の正確な残高計算という、最もシンプルかつミスが絶対に許されない処理だけを留める。コア機能を極限まで小さく絞り込み、改修の必要がない「高速で正確な電卓」へと仕立て上げることで、COBOLのまま安全に塩漬けにするアプローチだ。

（2） 「枯れた技術」が持つ圧倒的な安心感

ITの世界において、COBOLのような古くから使われている技術は「枯れた技術」と呼ばれる。これは衰退を意味するのではなく、半世紀にわたり世界中の現場で使い倒され、あらゆる不具合や脆弱性が出し切られた「極限の安定性」を獲得していることを意味する。

特にCOBOLは、10進数の正確な計算処理や、夜間に膨大なデータを一括処理するバッチ処理において今なお比類なき強みを持つ。一度組まれた仕様が崩れない堅牢性は、変化の激しい最新言語にはない強みであり、「動いているなら触るな」という判断には十分な技術的ロジックが存在する。

5． 避けられないカウントダウン：人材枯渇とメインフレーム終了

しかし、いくら「枯れた技術」が安全であっても、現状維持を許さない物理的な限界が近づいている。それが「COBOLエンジニアの死滅」と「国産メインフレームの撤退」という二重のタイムリミットだ。

（1） 人材の物理的消滅（2025年の崖）

日本のCOBOLエンジニアの平均年齢は50代後半から60代に達しており、かつてシステムを作り上げた世代の完全退職が目前に迫っている。若手エンジニアにとってCOBOLを学ぶことは将来のキャリア形成の観点から敬遠されるため、補充の利かない自然減が続いている。

システムがどれほど安定していても、それを保守・修正できる人間が市場から消滅すれば、いざという時の対応が不可能になる。

（2） 国産ベンダーの撤退と2035年の限界

ハードウェアの側面でも退路は断たれつつある。日立製作所がすでにメインフレームの自社生産から事実上撤退したのに続き、富士通も2030年度にメインフレームの販売を終了し、2035年度には保守サポートを完全に終了すると表明した。

これにより、富士通のメインフレームに依存してきた地銀や官公庁は、2035年までに「IBMのメインフレームへ引っ越す」か「メインフレーム自体を破棄してクラウドへ逃げる」かの二者択一を強制されることになった。世界市場がIBMの一強独占へ向かう中、ベンダーロックインの深化を嫌う企業にとっては、北國銀行のような脱レガシーへの挑戦はもはや選択肢ではなく「必須の撤退戦」と化している。

6． 30年前の言語「Java」を選ぶ意味と、未来への免罪符

今回の事例に対して投げかけられるもう一つの鋭い疑問が、「なぜ今さら30年も前に誕生したJavaに書き換えるのか。いずれまた次の言語への切り替えに迫られるのではないか」という点だ。

確かにJava（1995年登場）自体もIT業界ではすでにベテランの領域にあり、最新の言語に比べれば古い。しかし、ここには次世代を見据えた明確なロジックが存在する。

（1） エコシステムと人材の調達可能性

Javaを選ぶ最大の理由は、世界で最も利用されている言語の一つであり、エンジニアの層が極めて厚いことだ。COBOLの最大の弱点であった「人材の不全」を、世界で最も人が集まる巨大なエコシステムへ引っ越すことで解決できる。

（2） 「二度とブラックボックスを作らない」ための構造化

今回のJava化の本質は、単に言語を変えたことではなく、COBOL特有のスパゲッティコードを解読し、現代的な「オブジェクト指向」に基づいて整理・可視化させたことにある。

仕様書が存在せず誰も読めなかった暗黒のコードが、Javaとしてモジュール化され、クラウド上で動く標準的な作法に揃えられたことで、システム全体の構造が完全にクリアになった。

（3） 未来の切り替え難易度の劇的な低下

仮に20年後、Javaが完全に陳腐化し、新しい言語へ移行する時期が来たとしても、次回はCOBOLからの脱却のような命がけの外科手術にはならない。

構造が整理され、クラウド標準に乗ったJavaコードであれば、将来登場するであろう高度なAIツールを用いて、部分的に別の言語へ変換していくことがはるかに容易になる。「二度と不可解なレガシーを作らない構造に改修した」ことこそが、北國銀行がJava化によって得た最大の資産なのである。

7． 結語：北國銀行の成功が問いかける真の教訓

北國銀行の事例を「生成AIを使ったスマートな成功体験」として消費してしまうと、本質を見誤る。彼らが成し遂げたのは技術の勝利ではなく、「20年間にわたりブレずにIT投資と内製化を続けた経営と組織改革の勝利」だ。

地銀特有の危機感からITをコアコンピタンスと位置付け、行員のプログラミング教育を進め、銀行特有の減点主義やベンダー丸投げ体質を破壊してきた土台があったからこそ、生成AIという新しいツールを正しく使いこなすことができた。

富士通の2035年限界に向け、すべての日本企業はレガシーシステムからの撤退計画を余儀なくされている。生成AIは確かにその撤退戦を極めてスピーディーに進めるための強力な武器になり得る。しかし、その武器を扱えるだけのドメイン知識と、100%の正確性をテストし切る覚悟を自社の中に保持できるか。

北國銀行が突きつけたのは、最新AIの可能性ではなく、レガシーと向き合うすべての経営者に求められる「覚悟の有無」そのものなのである。