OpenAIが銀行のレガシーシステム刷新に乗り出す——日本の金融機関が今すぐ検討すべきこと

公開日：2026年10月20日更新日：2026年10月21日文：クリスタルメソッド編集部監修：河合継（代表取締役）

OpenAIがレガシー言語対応を発表——銀行システム近代化に照準

2026年10月19日、OpenAIはCOBOL・Fortran・Visual Basicといったレガシープログラミング言語への対応強化をブログ投稿で発表した（m.economictimes.com報道）。掲げた目標は、モデルが未知のソフトウェアプロジェクトを自律的に理解し、変更計画の立案・開発ツールの操作・テスト実行・エラー修正のサイクルを担えるようにすることだ。

なぜ今、レガシー言語なのか。COBOLは現在もオンラインバンキング取引の40%超、クレジットカード対面取引の80%、ATM取引の95%を処理している（OpenAI引用、m.economictimes.com）。Fortranは気象予報や原子炉安全解析の基幹演算で現役だ。これらのシステムを動かし続けるエンジニアの高齢化と人材枯渇は、業界共通の構造問題として認識されており（gft.com、thoughtworks.com）、OpenAIの動きはこの構造問題に生成AI技術を直接当てようとする意思表明として読むべきだ。単なる開発補助ツールの拡張ではなく、エンタープライズ向けコード近代化市場への本格参入と位置づけられる。

銀行ITコスト構造の実態——レガシーシステム刷新が進まない根本原因

レガシーシステムの刷新が遅れる根本原因は、コスト構造にある。銀行のITバジェットの約64%が既存システムの保守・運用に費やされているという調査結果がある（thoughtworks.com、2024年9月公開）。新規投資に回せる原資が限られる中で、複雑に絡み合った相互依存コードを一括移行するリスクを経営陣が取りにくいのは合理的な判断でもある。

技術的な難しさも見落とせない。数十年にわたって積み上げられたCOBOLコードは、ビジネスロジックとシステムロジックが不可分に結合しており、コードを読んでも「何をしているか」はわかっても「なぜそうなっているか」の業務的文脈が失われていることが多い。GFT Technologiesの報告によれば、こうしたレガシーコードの相互依存性の高さが変更を困難にする最大の障壁とされている（gft.com）。COBOL技術者の高齢化・引退が加速する中、コードが「動いているが誰も触れない資産」と化すリスクは、日本の地方銀行や信用金庫において特に顕著だと考えられる。

銀行ITバジェットの現状（約64%が保守費）と、GenAI活用によってコスト構造の改善余地が生まれることを示す概念図。右図は方向性を示すものであり、実績数値ではない（出典: thoughtworks.com、2024年9月）。

次に読む：フィンテックが急成長している理由は？

フィンテックとは？急成長している理由と今後の展望を紹介します

GenAIはレガシーシステム刷新に実際に使えるのか——できることとできないこと

GenAIがレガシーモダナイゼーションに寄与できる領域は、すでに実証的な事例が出始めている。GFT Technologiesと8000万人超の顧客基盤を持つ大手金融機関が協働し、数百万行規模のCOBOLコードをGenAI支援で近代化するプロジェクトを進行中との報告がある（gft.com）。文書化・テストコード生成・コード変換といった工程で処理速度が引き上げられているとされる（gft.com、thoughtworks.com）。

OpenAIが今回打ち出したアプローチの要点は、モデルが単に「コードを翻訳する」だけでなく、プロジェクト全体の構造を理解した上で変更計画を立て、開発ツールを操作し、テストを実行してエラーを自己修正するという自律的なサイクルを担う点にある。

ただし、現時点で冷静に評価すべき限界がある。

業務ロジックの文脈復元は困難：COBOLコードに埋め込まれた30年分のビジネスルールをAIが完全に解釈できるかは未解決の問題だ。コードの構文変換と業務意味の保持は別次元の難しさを持つ。
発表済みの性能数値は未検証：OpenAIの発表に関連して言及される具体的なベンチマーク数値は、独立した第三者機関による検証がまだ確認されていない。導入判断の根拠を公式発表のみに置くことには注意が必要だ。
規制・監査対応のコストが残る：金融機関では、AIが生成・変換したコードが本番環境に入るまでに、金融当局への説明責任・システム監査・障害時のトレーサビリティ確保といった追加工程が必要になる。この部分のコストは自動化の恩恵と相殺される可能性がある。
検証できる人材の確保が先決：AIがコード変換を補助しても、変換後のコードを評価・承認できるエンジニアが社内に必要だ。COBOL知識がゼロの組織では、AIの出力品質を検証する人材の確保が導入前提条件となる。

日本の金融機関が今すぐ持つべき判断軸——稟議・調達の前に整理すること

OpenAIのレガシー言語対応強化は、日本の金融機関にとっていくつかの実務的な示唆を持つ。以下は根拠ある推論であり、不確実な部分は断定を避ける。

第一に、自行のCOBOL資産の棚卸しが先決だ。何百万行のコードがあり、そのうちどの部分が実際にビジネスクリティカルで、どの部分が「動いているが触れていない」状態かを可視化していない金融機関は多いと考えられる。GenAIの活用可能性を議論する前に、この棚卸しが意思決定の前提になる。

第二に、パイロットを周辺工程から始めることだ。COBOL全体の一括移行は、技術的・コスト的・規制対応的なリスクが高い。文書化の自動生成やテストコードの補助生成といった、本番環境に直接影響しない周辺工程からGenAIを試験投入する方が、リスクを抑えながら知見を蓄積できる。

第三に、ベンダー選定の評価軸を整備することだ。OpenAI以外にも、IBM・GFT Technologiesなど複数のプレイヤーがレガシーモダナイゼーション向けのアプローチを持つ。主要選択肢の比較を以下に示す。

提供元	主なアプローチ	強み	留意点
OpenAI（発表段階）	LLMによる自律的コード理解・変換・テスト	最新LLM活用・広範な言語対応を標榜	金融特化の実績・ベンチマークが未検証段階
IBM watsonx Code Assistant	COBOL→Java変換に特化したAI支援	金融機関向け実績・メインフレーム統合の親和性	ライセンスコストが高い傾向・ベンダーロックイン
GFT Technologies	GenAIを活用した移行コンサルティング	大規模金融機関での移行プロジェクト実績あり（gft.com）	テクノロジー提供よりSI主体・工数コストが発生
Thoughtworks	段階的モダナイゼーション支援	レガシー近代化の方法論的知見が蓄積（thoughtworks.com）	ツール単体での自動化よりコンサル工数が必要

第四に、金融庁の動向を継続的に確認することだ。金融庁は2024年度以降、AIを活用した金融サービスのリスク管理に関するガイドラインの整備を進めている。AIが変換したコードが本番稼働する場合の説明責任・検証要件については、監督当局の解釈が今後明確化される可能性がある。稟議・調達判断の前に規制動向を確認することが実務上不可欠だ。

OpenAIのレガシー言語対応強化は、銀行システム近代化の潮流を加速させる一つの起点になり得る。しかしそれが日本の金融機関にとっての解になるかどうかは、自行の資産規模・人材・規制対応能力という内部条件によって大きく異なる。技術的な可能性と経営的な実行可能性を切り離して評価することが、今の段階での適切な姿勢だ。

参考文献

Economic Times「OpenAI looks to help banks modernise legacy software their operations still depend on」（2026年10月19日報道）— https://m.economictimes.com/
Thoughtworks「銀行ITコスト調査」（2024年9月公開）— https://www.thoughtworks.com/
GFT Technologies「GenAI×COBOLモダナイゼーション」レポート — https://www.gft.com/