日本の近代化は、古いコードの上で動いている
日本の銀行口座に給料が入る。保険金が支払われる。工場の部品が発注される。鉄道、物流、電力、自治体、病院、商社、メーカーの帳票が更新される。表面ではスマートフォンのアプリが光り、AIが会話し、クラウドが世界を動かしているように見える。
しかし、その奥では、何十年も前に書かれた業務システムが、今日も黙って働いている。COBOL、メインフレーム、UNIXサーバー、独自仕様、複雑なバッチ処理、長年の改修で枝分かれしたプログラム。これらは古いから価値がないのではない。むしろ、日本企業の業務ノウハウが沈殿した巨大な資産である。
富士通と日本IBMが2026年6月17日に発表したモダナイゼーション協業は、この見えにくい日本の中枢を対象にしている。両社は、富士通のソースコード変換ソリューション「Fujitsu PROGRESSION」と、IBMのAIエージェント駆動型開発支援プラットフォーム「IBM Bob」を組み合わせ、富士通メインフレームやUNIXサーバー上で動くCOBOLプログラムをJavaへリライトし、変換後のコードをAIで補正、リファクタリングする。
これは、派手なAIニュースではない。チャットボットでも、ロボットでも、宇宙船でもない。しかし、日本のデジタル変革にとっては、おそらく最も現実的で、最も重いテーマの一つである。日本の未来は、新しいAIだけでなく、古い業務システムをどう扱うかで決まる。
なぜレガシーシステムは捨てられないのか
レガシーシステムという言葉には、少し冷たい響きがある。古い、遅い、複雑、保守が難しい。確かに、その通りの面はある。しかし企業の現場から見れば、レガシーシステムは単なる古い機械ではない。
そこには、会社の業務そのものが入っている。請求のルール、与信の判断、在庫の動き、税制への対応、例外処理、顧客との約束、現場が何十年もかけて積み重ねた小さな工夫。マニュアルには残っていないが、コードには残っている。担当者は退職しても、業務ロジックはプログラムの中で生き続ける。
だから、レガシーシステムの近代化は、単なる引っ越しではない。古い家から新しい家へ荷物を運ぶような話ではない。むしろ、古い町の地下に埋まった水道管と電線を、街を止めずに入れ替える作業に近い。
銀行の決済システムを止めることはできない。保険の支払いを止めることはできない。工場の生産計画を止めることはできない。自治体の住民サービスを止めることもできない。日本の企業がレガシーシステムを恐れるのは、それが古いからではない。それが重要すぎるからである。
2025年の崖は、過ぎたのではなく、足元にある
経済産業省は2018年のDXレポートで「2025年の崖」という表現を使い、日本企業が既存システムの問題を解決できなければ、デジタル競争で遅れ、大きな経済損失を被る可能性があると警告した。
2025年はもう過ぎた。だから問題も過ぎ去ったのか。そうではない。むしろ、崖はカレンダー上の日付ではなく、企業の足元に残り続けている。経済産業省は2025年5月、レガシーシステムモダナイゼーション委員会の包括報告書を公表し、レガシーシステムが最新デジタル技術の導入を妨げ、日本の産業競争力低下につながる可能性を改めて指摘した。
報告書が重視するのは、単なる技術更新ではない。経営者の意識、IT資産の可視化、情報システム部門の自律性、事業部門との連携、ベンダーとの関係、人材育成、業界横断のエコシステムである。つまり問題は、プログラム言語だけではない。日本企業の意思決定と組織文化の問題でもある。
古いシステムを直すには、古い組織の癖も見直さなければならない。
富士通とIBMが組むことの歴史的な重み
富士通とIBMという組み合わせには、歴史的な重みがある。富士通は1954年、FACOM 100を完成させた。これは日本初の実用的なリレー式自動計算機とされ、日本のコンピューター史における大きな節目だった。電話交換機の技術から生まれたリレー技術が、戦後日本の計算機産業の土台を作った。
一方、IBMは日本の企業計算機市場に深く関わってきた。パンチカード、会計機、メインフレーム、企業向けシステム。IBMの技術とビジネスモデルは、日本企業の情報処理にも大きな影響を与えた。
戦後のコンピューター産業では、富士通、日立、NEC、IBM Japanなどが大型機市場で競い合った。互換機、独自OS、汎用機、周辺機器、ソフトウェア、顧客基盤。そこには競争があり、技術の誇りがあり、日本企業の情報システムを支える巨大な産業があった。
その歴史を知ると、今回の協業は単なるベンダー連携ではない。かつて大型機市場で競い、企業システムを作ってきた二つの系譜が、今度は古いシステムを次世代へ渡すために組むのである。
COBOLは、なぜまだ生きているのか
COBOLは1959年に生まれた。Common Business-Oriented Languageという名前の通り、商業・事務処理のために作られた言語である。英語に近い読みやすさを目指し、会計、取引、帳票、バッチ処理に向いた構造を持っていた。
現代の感覚では、COBOLは古く見える。しかし、古いから消えるとは限らない。むしろ、銀行、保険、政府、製造、流通など、正確性と安定性を重視する領域では、長く使われてきたコードが巨大な信頼の塊になっている。
COBOLの問題は、言語そのものだけではない。問題は、人がいなくなることだ。昔の仕様を知る技術者が引退する。ソースコードの全体像を知る人が減る。設計書が古い。改修の履歴が複雑。外部システムとの接続が絡み合う。システムは動いているが、誰も全体を説明できない状態になる。
これがブラックボックス化である。動いているから安全なのではない。動いているが、変えられないから危ないのである。
Fujitsu PROGRESSIONとIBM Bobが狙う現実的な道
今回の協業の中心は、COBOLをJavaへリライトし、変換後のコードをリファクタリングすることにある。富士通のFujitsu PROGRESSIONは、富士通メインフレームやUNIXサーバーで動くCOBOLプログラムを、Javaなどのオープン環境に適した言語へ変換する。富士通の知見により、業務ロジックの整合性や既存仕様との互換性を保ちながら、移行リスクを抑えることが狙いだ。
そこにIBM Bobが加わる。IBM Bobは、AIエージェント駆動型のエンタープライズ開発支援プラットフォームとして、COBOLからJavaへ変換された後のコード補正やリファクタリングを支援する。従来は人手に依存しがちだった業務ロジックの検証やテスト、構造化を、AIで効率化しようとする。
ここで重要なのは、「AIが全部自動で解決する」という話ではないことだ。むしろ、AIを使いながら、人間の判断と業務理解を残す道である。レガシーシステムの近代化では、コードを変換するだけでは足りない。変換後の構造が保守しやすいか、将来の機能追加に耐えられるか、業務部門が理解できるか、テストで業務の例外を拾えるかが重要になる。
リライトは入口であり、リファクタリングは再設計である。
AIは魔法ではなく、翻訳者である
AIによるレガシー近代化は、しばしば過大評価される。古いCOBOLを読み込ませれば、きれいなJavaに変わり、クラウドで動き、コストが下がり、DXが進む。そんな単純な話なら、2025年の崖は最初から存在しなかった。
実際には、AIは魔法使いではない。むしろ優秀な翻訳者に近い。古い言語を読み、新しい言語へ置き換え、構造を整理し、設計書を作り、テストの候補を出し、人間が見落とす関係を可視化する。だが、その翻訳が正しいかどうかを判断するには、業務を知る人間が必要になる。
特に日本企業のシステムには、標準化されていない業務ルールが多い。得意先別の例外、法改正への対応、古い商習慣、部門ごとの運用、手作業との接続。AIはコードを読めても、なぜその例外が存在するのかまでは自動では理解できない。
だから、AI時代のモダナイゼーションで必要なのは、エンジニアを不要にすることではない。エンジニア、業務担当者、経営者の会話を増やすことである。
メインフレームは悪者ではない
レガシー近代化の議論では、メインフレームが悪者のように扱われることがある。古い、閉じている、高い、クラウドに向かない。確かに、そうした課題はある。しかし、メインフレームは長く企業の基幹業務を支えてきた。大量トランザクションを安定して処理し、止まらないことを求められる領域で信頼を築いてきた。
本当の問題は、メインフレームを使っていること自体ではない。問題は、事業変化に合わせてシステムを変えられないこと、データを活用できないこと、人材が足りないこと、コスト構造が見えないこと、そして経営がIT資産を自分の問題として把握していないことである。
したがって、近代化は「脱メインフレーム」という一つの掛け声で済むものではない。残すもの、移すもの、書き換えるもの、分離するもの、APIでつなぐもの、クラウドへ出すものを見極める必要がある。企業ごと、業務ごと、リスクごとに答えは違う。
日本企業の本当の課題は、可視化である
経済産業省の報告書が重視するように、レガシーシステム近代化の第一歩は可視化である。何がどこで動いているのか。誰が使っているのか。どの業務に関係するのか。どのデータがどこへ流れているのか。どの部分が本当に古く、どの部分はまだ使えるのか。
多くの企業では、この地図が失われている。担当者は部分を知っている。ベンダーは一部を知っている。古い設計書は残っているが、現実とずれている。経営者は総額のIT費用を知っていても、どのシステムが競争力を生み、どのシステムが足かせになっているのかを把握できていない。
AIによるコード解析や設計書生成は、この可視化の部分で力を発揮する可能性がある。コードの依存関係、処理の流れ、データ項目、例外条件、重複ロジックを見える形にする。見えなければ、変えられない。
人材の崖も同時に来ている
レガシーシステムの問題は、技術だけでなく人材の問題でもある。COBOLを書ける人、メインフレームを運用できる人、古い帳票処理を理解する人、バッチの順番を知る人、異常時の手順を覚えている人。これらの人材は高齢化している。
若いエンジニアは、クラウド、AI、Python、JavaScript、コンテナ、モバイルアプリへ向かう。COBOLやメインフレームを学びたい人は少ない。しかし、社会の重要なシステムはまだそこにある。ここに人材のミスマッチがある。
富士通とIBMのような大手がAIを使った近代化を進める意味は、単に効率化ではない。人材不足の穴を埋め、暗黙知を形式知に変え、若い技術者が古いシステムに触れるための橋を作ることでもある。
レガシーを消すのではなく、未来へ継承する
レガシーという言葉には、二つの意味がある。古いもの、そして遺産である。日本企業の基幹システムは、この両方を持っている。古く、複雑で、保守が難しい。しかし同時に、長年の業務知識と顧客対応の積み重ねを含む遺産でもある。
近代化の目的は、その遺産を捨てることではない。未来へ使える形で継承することだ。AIを使い、コードを読み解き、Javaへ変換し、構造を整理し、クラウドやデータ活用へつなげる。これは破壊ではなく、翻訳であり、修復であり、再設計である。
日本のDXは、華やかな新規事業だけでは進まない。古いシステムを動かしながら変えるという、もっと泥臭い仕事が必要になる。富士通とIBMの協業は、その泥臭さに正面から向き合う動きである。
AI時代の競争力は、古いシステムを変えられるかで決まる
生成AIの時代には、企業はデータを使えるかどうかで差がつく。顧客データ、在庫データ、決済データ、製造データ、契約データ、医療データ、物流データ。だが、そのデータが古い基幹システムの奥に閉じ込められていれば、AIは十分に力を発揮できない。
AIを使うには、AIに渡せるデータ基盤が必要である。データ基盤を作るには、業務システムの構造を理解する必要がある。構造を理解するには、古いコードと古い運用を読み解く必要がある。つまり、日本のAI競争力は、最新モデルだけでなく、古いCOBOLをどう扱うかにも左右される。
富士通とIBM Japanの協業は、目立たないが、かなり重要な場所を突いている。新しいAIを語る前に、AIを使える会社へ作り替える必要があるからだ。
日本の未来は、未来的な画面の中だけにあるのではない。黒い筐体の奥、古いコードの行間、誰も触りたがらなかったバッチ処理の中にもある。そこを読み解き、壊さず、次の世代へ渡せるか。日本のデジタル変革は、そこから始まる。
- 富士通と日本IBMは、COBOLからJavaへのリライトとAI支援リファクタリングで協業する。
- 対象は、富士通メインフレームやUNIXサーバー上で動く基幹業務システムである。
- レガシーシステムは古いだけでなく、企業の業務知識を蓄積した重要資産でもある。
- 経済産業省は、レガシーシステムがDXと産業競争力の障害になると警告している。
- 生成AI時代の競争力は、古いシステムのデータと業務ロジックを活用できるかにかかっている。
出典・参考
この特集は、富士通、日本IBM、経済産業省、情報処理学会コンピュータ博物館、富士通ミュージアムなどの公開情報をもとに構成した。