COBOLをAIでJavaに変換すれば、レガシー脱却できるのか？おすすめの言語も考える
1. COBOLモダナイゼーションが注目されている理由
COBOLを使ったレガシーシステムは、今でも多くの重要業務を支えています。
ただ、課題もあります。読める人が少ない。設計書が古い。修正の影響範囲が分かりにくい。若手SEが入っても、最初の理解にかなり時間がかかる。
昔は、熟練SEの頭の中にシステム構成が入っているような状態でした。「仕様書はどこですか？」と聞くと、「ソースを見れば分かる」と返ってくる世界です。
若手からすると、そのソースが読めないから聞いているのですが、ここで静かな修行が始まります。しかも、修行の入口に地図がありません。
そこで注目されているのが、AIを使ったCOBOL解析やモダナイゼーションです。
AIを使えば、ソースコードの概要を整理したり、設計書のたたき台を作ったり、修正候補を出したりできます。では、AIでCOBOLをJavaに変換すれば、すぐにレガシー脱却できるのでしょうか。
結論から言うと、AI変換だけでレガシー脱却できると考えるのは危険です。ただし、AIはレガシー脱却を進めるための強力な武器になります。
2. AIでできること
AIを使うと、COBOL資産に対してかなりのことができます。
たとえば、ソースコードの概要説明。入力・処理・出力の整理。PERFORMやIF文の流れの説明。テーブル・ファイル更新箇所の洗い出し。設計書のたたき台作成。Javaへの変換案の作成。テスト観点の整理。
これだけでも、若手SEにとっては大きな助けになります。
特に、最初の全体像をつかむ作業には効果があります。いきなり長いCOBOLソースを読めと言われるより、AIに概要を出してもらい、その後でソースを確認する方が入りやすいです。
AIは、暗い城に入るときの松明のようなものです。城の構造を完全に理解してくれるわけではありませんが、最初の一歩はかなり歩きやすくなります。
ただし、松明を持っているからといって、床の落とし穴が全部見えるわけではありません。レガシーシステムには、そういう落とし穴が普通にあります。
3. AIだけでは難しいこと
AIでCOBOLをJavaに変換すれば、それだけでレガシー脱却できるかというと、答えは慎重に考える必要があります。
AIはコードの変換はできます。しかし、業務仕様を完全に理解しているわけではありません。
たとえば、COBOLのある条件分岐が、過去の障害対応で入ったものかもしれません。特定顧客だけの例外処理かもしれません。もう使っていないように見えて、実は帳票や外部連携で必要かもしれません。
AIはコード上の形は読めます。しかし、「なぜそうなっているのか」までは、ソースだけでは分からないことがあります。
COBOLをJavaに変換しても、業務仕様が整理されていなければ、単に「読みにくいCOBOL」が「読みにくいJava」になるだけです。
これはレガシー脱却ではなく、レガシーの引っ越しです。段ボールの中身を整理せずに新居へ運ぶようなものです。場所は変わったのに、開けたら結局ぐちゃぐちゃだった、という状態になります。
4. 業務仕様の理解が一番重要
COBOLモダナイゼーションで一番重要なのは、変換先の言語ではなく、業務仕様の理解です。
この処理は何のためにあるのか。どのデータを正としているのか。どのタイミングで更新されるのか。例外処理にはどんな意味があるのか。帳票・画面・バッチ・外部連携のどこに影響するのか。
ここを理解しないまま変換すると、動くけれど危ないシステムになります。
Javaにするか。Goにするか。Pythonにするか。クラウド化するか。
それらは大事です。ただし、その前に「何を守るべきか」を明確にしないといけません。
レガシーシステムには、長年の業務ノウハウが詰まっています。古いから悪い、COBOLだから悪い、という単純な話ではありません。
本当に脱却すべきなのは、COBOLという言語そのものよりも、「誰も仕様を説明できない状態」「影響範囲が分からない状態」「設計書が更新されていない状態」「変更するたびに熟練SEの勘に頼る状態」です。
5. おすすめの言語は何か
COBOL資産の移行先として考えるなら、Javaだけが正解ではありません。ただし、目的によって向き・不向きがあります。
Java
業務システム全体を移行するなら、現実的にはJavaが第一候補になりやすいと思います。
理由は、企業システムでの実績、保守人材、フレームワーク、既存ツールとの相性があるためです。
大規模な基幹システム、Web業務システム、バッチ処理、DB処理などを考えると、Javaはかなり無難で現実的です。
「全部を一気に変えるのは怖いけれど、長期保守できる形にしたい」という場合、Javaは選びやすい言語です。
C# / .NET
Microsoft系の基盤が強い会社であれば、C# / .NETも有力です。
Windows環境、社内業務システム、画面系、帳票系との相性を考えると、十分に候補になります。既存の社内基盤や開発者のスキルセットがMicrosoft寄りなら、Javaより自然な場合もあります。
Go
Goは、COBOL資産全体の置き換えというより、周辺APIや軽量バッチ、クラウドネイティブな小さなサービスに向いています。
シンプルで、並行処理に強く、外部連携やマイクロサービス化では有力です。
ただし、巨大なCOBOL資産をそのままGoへ変換する選択は、Javaより慎重に考えた方がよいです。設計力、運用力、チームの習熟度がかなり重要になります。
「全部Goで作り直そう」は、響きはかっこいいです。ただ、現場ではその後の保守体制まで考えないと、別の意味で修行が始まります。
Python
Pythonは、AIやデータ分析、自動化で強いイメージがあります。そのイメージはかなり正しいと思います。
ただし、COBOLで動いていた大規模な基幹業務処理を、丸ごとPythonに置き換えるのは慎重に考えた方がよいです。
Pythonは、COBOL本体の移行先というより、モダナイゼーションの補助ツールとしてかなり有効です。
たとえば、COBOLソースの解析スクリプト。COPY句の依存関係洗い出し。プログラム一覧の自動作成。影響範囲調査の補助。テストデータ作成。移行前後の差分比較。ログ解析。AI・LLM連携。設計書生成の前処理。
このあたりはPythonが強いです。
つまり、Pythonは「COBOLを置き換える言語」というより、COBOLを解析し、移行し、検証するための道具として使うとかなり有効です。
TypeScript
TypeScriptは、画面刷新や管理画面、Webフロントエンドに向いています。
COBOLの業務ロジック本体というより、周辺UIの刷新で使うイメージです。古い画面をモダンなWeb画面に置き換えるなら、TypeScriptはかなり現実的な選択肢です。
Kotlin
KotlinはJavaとの親和性が高く、Spring系の開発でも使えます。Javaより簡潔に書ける場面もあり、新規開発では魅力があります。
ただし、既存の開発体制や保守人材を考えると、Javaより慎重に導入判断する必要があります。
Rust
Rustは高性能で安全性の高い言語ですが、基幹業務全体の移行先というより、性能や安全性が特に重要な一部の基盤部品向きだと思います。
COBOL資産全体の置き換え先として最初に選ぶより、特定用途で検討する言語です。
6. 用途ごとに言語を分けるのが現実的
私の考えでは、COBOLモダナイゼーションでは、すべてを1つの言語に置き換えるより、用途ごとに使い分ける方が現実的です。
COBOL資産全体の移行先はJava。Microsoft基盤ならC# / .NET。周辺APIや軽量バッチはGo。AI・解析・自動化支援はPython。Web画面刷新はTypeScript。Java資産との親和性を活かすならKotlin。一部の高性能・安全性重視の部品にはRust。
このように役割を分けて考えると、レガシー脱却の計画が現実的になります。
「どの言語が最強か」ではなく、「どの部分に、どの言語を使うと保守しやすいか」で考えるべきです。
技術選定は、刀選びに似ています。太刀も短刀も弓も、それぞれ役割があります。全部を一本の刀で済ませようとすると、だいたいどこかで無理が出ます。
7. 変換よりも先に影響調査が必要
COBOLをJavaに変換する前に、まずやるべきことは影響調査です。
どのプログラムがどこから呼ばれているか。どのCOPY句を使っているか。どのファイルやDBを更新しているか。どの帳票や外部連携に影響するか。どの処理が本当に使われているか。
ここを整理せずに変換すると、変換後のテストで苦しみます。
AIは影響範囲の候補出しに使えます。しかし、最終判断は人間が行う必要があります。
特にレガシーシステムでは、「使っていなさそうに見えるけど、年1回だけ動く処理」が存在します。このタイプは厄介です。普段は静かですが、本番の大事な日に突然存在感を出してきます。
だから、変換より前に、処理の棚卸し、依存関係、テスト観点を整理することが重要です。
8. Codex + VS Codeで解析する流れ
実務でAIを使うなら、チャットだけでなく、Codex + VS CodeのようなIDE連携が使いやすいと感じています。
チャット形式だけだと、ソースを貼る、回答を読む、自分で修正する、自分でテストする、また貼り直す、という流れになります。1回ならよいですが、何度もやるとかなり手間です。
VS Codeでプロジェクトを開き、Codexに関連ファイルを確認させながら進めると、解析の流れが作りやすくなります。
おすすめの流れは次の通りです。
- 対象プログラムの概要を説明させる
- 入力・処理・出力に分けて整理させる
- 呼び出し元・呼び出し先を確認させる
- COPY句や関連ソースを確認させる
- 修正・変換候補を出させる
- 影響範囲とリスクを洗い出させる
- テスト観点を作らせる
- 小さく修正して検証する
大事なのは、いきなり「Javaに変換して」ではなく、まず「何をしている処理なのか」を理解することです。
AIは変換機として使うより、解析者・設計補助・レビュー補助として使う方が安全です。
まとめ
COBOLをAIでJavaに変換すれば、すぐにレガシー脱却できる。そう考えるのは少し危険です。
AIは強力です。ソース解析、設計書のたたき台作成、変換案、修正候補、テスト観点出しに使えます。
しかし、AIだけでは業務仕様の理解、過去経緯、影響範囲、運用上の例外までは完全に判断できません。
変換先の言語としては、全体移行ならJavaが現実的な第一候補になりやすいです。Microsoft基盤ならC# / .NETも有力です。Goは周辺API、新規サービス、軽量なバッチ、クラウドネイティブな部分で有力です。PythonはAI・解析・自動化支援に向いています。TypeScriptは画面刷新に向いています。
ただし、言語選定より先に大事なのは、業務仕様と影響範囲の整理です。
レガシー脱却とは、COBOLを別の言語に置き換えることだけではありません。業務仕様を見える化し、影響範囲を整理し、テスト可能な形にし、次の世代が保守できる状態にすることです。
AIはそのための強力な武器になります。ただし、最後に判断するのはSEです。
AIに変換させる。SEが読み解く。テストで確認する。設計書に残す。
この流れを作ることが、これからのCOBOLモダナイゼーションの現実的な進め方だと思います。