結論から言う。COBOLからJavaへのAI自動変換は「刷新の魔法の杖」ではない。AIは解析・変換・テストの工数圧縮が期待されるが、変換後コードが業務として正しく動くかを保証するのは依然として人の仕事だ。ツールに丸投げすれば、動くが意味を取り違えたコードや、特定ベンダーに縛られた新たなレガシーが生まれる。 2026年6月17日、富士通と日本IBMはモダナイゼーション協業を強化すると共同発表した。富士通の自動変換ツール「Fujitsu PROGRESSION」でCOBOLをJavaへリライトし、IBMのAIエージェント「IBM Bob」が変換後のリファクタリングとテストを支援する。日本IBMが主体となり、富士通が技術支援を担う座組だ。
本記事は、この協業で語られるAI自動変換ツールの実像を冷静に解きほぐし、品質検証と移行方式の選定、ベンダーロックイン回避、内製・外注の考え方までを、刷新の意思決定者向けに整理する。撤退スケジュールや移行方式の総論は富士通メインフレーム撤退と基幹システム刷新2026で扱っているので、本記事はそこに重複させず「AI変換の中身と検証」に絞る。
この記事の要点
-
2026年6月17日、富士通と日本IBMがモダナイゼーション協業の強化を共同発表（一次情報）。
-
富士通「PROGRESSION」でCOBOL→Javaへリライト、IBMのAIエージェント「IBM Bob」が変換後のリファクタリング・テストを支援。日本IBMが主体、富士通が技術支援という座組。
-
提供開始の具体日や定量的な削減目標はリリースに明記されていない（断定しない）。
-
AIは解析・変換・テストを支援するが、業務知識の把握と品質検証は人が担う。「丸投げ」は失敗する。
-
移行方式（リライト／リホスト／リビルド／パッケージ）の選定と、AI変換の品質保証設計が成否を分ける。
何が発表されたのか：事実だけを正確に押さえる
まず、報道や営業トークの誇張を排し、一次情報で確認できる事実だけを並べる。
| 項目 | 内容 |
|---|---|
| 発表日 | 2026年6月17日 |
| 発表者 | 富士通／日本IBM（共同発表・一次情報） |
| 取り組み | モダナイゼーション協業の強化 |
| 変換ツール | 富士通「Fujitsu PROGRESSION」でCOBOL→Javaへリライト |
| AI支援 | IBMのAIエージェント「IBM Bob」が変換後のリファクタリング・テストを支援 |
| 座組 | 日本IBMが主体、富士通が技術支援 |
| 提供開始日・定量目標 | リリースに明記なし（断定できない） |
ここで強調したいのは、「提供開始の具体的な時期」や「工数を何割削減できる」といった定量的な目標は、現時点の発表内では明記されていないということだ。だから本記事でも、削減率や納期短縮の数字は書かない。営業提案でこうした数字を提示された場合は、その根拠（対象規模・前提条件・検証範囲）を必ず確認してほしい。
背景にあるのは、富士通メインフレーム（GS21）の販売終息が2030年度、保守終了が2035年度末（2022年2月公表）という動かせない期限だ。UNIXサーバの保守も2034年度に終わる。COBOL資産を抱える企業は、限られた年数の中で移行を完了させなければならない。AI自動変換は、その重い作業を軽くする手段として注目されている。
FREE CONSULTATION
この記事の内容について、専門家に相談できます
AI・DX・セキュリティに関するご質問やお見積もりなど、お気軽にお問い合わせください。
AI自動変換ツールは「何を」やってくれるのか
「AIがCOBOLをJavaに変換する」と聞くと、ボタン一つで刷新が終わるように響く。だが実際にAIや自動変換ツールが担うのは、移行工程の一部であって全部ではない。工程を分解すると、AIの得意・不得意がはっきりする。
| 移行工程 | AI・自動変換ツールの寄与 | 人が担うべきこと |
|---|---|---|
| 現行資産の棚卸し・解析 | コードの依存関係・呼び出し関係の可視化を支援 | どの資産が現役か、廃止可能かの業務判断 |
| COBOL→Javaへの変換（リライト） | 構文レベルの機械変換を自動化 | 変換ルールの設計、例外パターンの方針決定 |
| 変換後コードのリファクタリング | 可読性・構造改善の提案・自動修正を支援 | アーキテクチャ方針、命名・設計規約の確定 |
| テスト | テストケース生成・実行・差分検出を支援 | 業務として正しい結果かの最終判定、受け入れ基準 |
| 業務知識の補完 | （苦手）コードに書かれていない暗黙仕様は補えない | 現場ヒアリング、仕様の再定義 |
ポイントは最下段だ。COBOL資産の最大の難所は、コードに書かれていない暗黙の業務ルール（特例処理、運用回避策、過去の経緯）にある。 AIはコードから読み取れる範囲の挙動は再現できても、「なぜこの計算をしているのか」「この分岐は何の業務都合か」までは復元できない。ここを人が把握し直さないと、機械的に変換しても「動くが意味の取り違えたシステム」になりかねない。
このリスクは、AI生成コードの品質問題全般と地続きだ。生成AIによる開発の落とし穴はバイブコーディングの危機（特集）でも整理している。COBOL変換に限らず、AIが書いたコードを検証なしで本番に乗せる怖さは共通する。
「丸投げ」が失敗する3つの理由
AI自動変換に過度な期待を寄せて丸投げすると、典型的に次の3パターンで失敗する。
-
意味等価でない変換を見逃す：構文としては正しく変換されても、丸め処理・桁あふれ・日付計算・文字コードの扱いなど、COBOL固有の振る舞いがJavaで微妙にずれる。会計・請求のように1円のズレが致命的な領域では、これが事故になる。
-
テストの「正解」が用意できない：自動でテストケースを生成できても、何が業務上の正解かを定義するのは人だ。現行システムの出力をそのまま正解とする「現新比較（パラレルラン）」の設計と、十分な業務データの準備を怠ると、検証が形骸化する。
-
新たなレガシーを作る：変換しただけのJavaは、COBOLの構造を引きずった読みにくいコードになりやすい。リファクタリングと設計方針を伴わなければ、5年後に「Javaになったが結局ブラックボックス」という第二のレガシーが生まれる。
つまり、AI変換の成否はツールの性能ではなく、検証設計と業務知識の再獲得をどれだけ人の側で固められるかで決まる。ツールはあくまで加速装置だ。
COBOL刷新、AI変換の前に「移行方式」と「検証設計」を固めませんか
ツール選定より先に、現行資産の棚卸し・移行方式の選定・品質検証の設計を行うことが、丸投げ失敗を防ぐ近道です。GXOは特定ツール・特定ベンダーに縛られない立場で、貴社のCOBOL資産に最適な進め方を整理します。構想段階のご相談だけでも歓迎します。
※ 営業電話はしません ｜ オンライン対応可 ｜ 構想段階の相談だけでもOK
FREE DOWNLOAD
AI導入チェックリスト（PoC 失敗要因 10項目）
情シス部門が PoC 前に押さえるべき失敗要因を10項目に整理した無料チェックリスト。
移行方式の選定：AI変換（リライト）は唯一の正解ではない
今回の協業はCOBOL→Javaの「リライト」を軸にしている。だが、刷新の選択肢はリライトだけではない。現行資産の状態・予算・期限・将来戦略によって、最適な方式は変わる。AI変換が万能ではない以上、まず方式を比較してから手段を選ぶべきだ。
| 移行方式 | 概要 | 向くケース | 留意点 |
|---|---|---|---|
| リライト（今回の協業の軸） | COBOLをJava等へ書き換える。AI自動変換が威力を発揮 | 資産を活かしつつモダンな言語基盤に移したい | 意味等価の検証が重い。暗黙仕様の再獲得が必須 |
| リホスト | ロジックはほぼ変えずオープン基盤・クラウドへ載せ替え | 期限が迫り、まず脱メインフレームを優先したい | 構造は古いまま。後で改善が必要になりやすい |
| リビルド | 業務要件から再設計して作り直す | 業務プロセスごと見直したい・差別化したい | 期間・費用が大きい。要件定義の負荷が高い |
| パッケージ／SaaS | ERP等の標準パッケージに業務を寄せる | 標準業務に合わせられる・自社開発を減らしたい | 既存業務とのフィット&ギャップ、カスタマイズ制約 |
リライトは「資産を活かす」点で魅力的だが、検証コストが最も重い方式でもある。一方、期限優先ならリホストで先に脱メインフレームし、その後段階的に改善する戦略も合理的だ。どれを選ぶかは、現状把握なしには決められない。移行方式の比較の全体像はレガシーシステムのモダナイゼーション（2025年の崖以降の進め方）でも体系的に整理している。
なお、富士通メインフレームに限らず、IBM i（AS/400）や日立VOS3など他基盤でも構図は似ている。基盤別の費用感やロードマップはIBM i（AS/400）モダナイゼーションの費用とロードマップや日立VOS3メインフレーム撤退（2034年）とモダナイゼーションが参考になる。基幹をERPパッケージへ寄せる選択肢を検討するならSAP ECC 2027年保守終了とS/4HANA移行の費用も合わせて読みたい。
ベンダーロックインをどう避けるか
AI自動変換ツールは強力だが、特定ベンダーの変換ツール・AIエージェント・実行基盤に深く依存すると、刷新後に新たなロックインが生まれるリスクがある。脱メインフレームの目的の一つが「特定メーカー依存からの解放」だったのに、刷新先で別のロックインに陥っては本末転倒だ。
ロックインを避けるための実務的なチェックポイントは次のとおりだ。
-
変換ルールと成果物の所有権：変換後のJavaソースコード、変換ルール、テスト資産は自社が保有・改修できるか。ツールが手元から離れた瞬間にメンテ不能にならないか。
-
標準技術への準拠：変換先がベンダー独自フレームワークに過度に依存していないか。標準的なJava・OSS・クラウドサービスで保守を継続できるか。
-
移行後の運用・改修体制：変換を請け負ったベンダー以外でも保守・機能追加ができる構造か。ドキュメントと設計が引き継げる形で残るか。
-
第三者によるレビュー可能性：変換方式・品質検証計画を、ツール提供元から独立した第三者が検証できるか。
ここで効いてくるのが第三者の目だ。変換ツールを提供する側は、当然ながら自社ツールでのリライトを前提に提案する。それが本当に自社にとって最適な方式か、ロックインを生まないか、見積もりは妥当かを、利害関係のない立場で検証する価値は大きい。提案された刷新計画・見積もりに第三者の視点を入れたい場合は見積もりセカンドオピニオンが活用できる。
内製か外注か：AI変換時代の体制設計
AIが変換工数を圧縮すると、「では内製でできるのでは」という議論が出る。だが前述のとおり、難所は変換そのものより業務知識の再獲得と品質検証にある。ここでの体制設計の考え方を整理する。
-
業務知識は内製で握る：何が業務上の正解か、どの特例処理が今も必要かを判断できるのは社内の業務担当者だけだ。ここを外部に丸投げしてはいけない。受け入れ基準と現新比較の正解定義は内製で持つ。
-
変換・テストの実装は外部の専門性を活用：AI変換ツールの運用、Javaアーキテクチャ設計、大規模テスト自動化は専門性が高い。経験のあるパートナーと組むことで、検証設計の質と速度が上がる。
-
ベンダー選定そのものを検証する：どのパートナー・どの方式に任せるかの判断を誤ると、刷新全体が傾く。ベンダー選定の観点はシステム開発会社の選び方に体系的にまとめている。
GXOは、特定の変換ツールやハードウェアを売る立場ではなく、貴社の資産と事業戦略に即して移行方式・検証設計・体制を組み立てる立場でレガシー刷新を支援している。サービスの詳細はレガシーモダナイゼーションおよびDX・システム開発を参照してほしい。
この記事を読むべき人・読むべきタイミング
-
富士通メインフレームやCOBOL基幹を抱え、2030〜2035年度の期限を意識し始めた経営層・情シス。
-
「AIでCOBOLをJavaに自動変換すれば安く速く済む」という提案を受け、その実像と落とし穴を知りたい担当者。
-
リライト／リホスト／リビルド／パッケージのどれを選ぶか、まだ方針が固まっていない企業。
-
変換ツールやベンダーへのロックインを懸念し、第三者の検証視点を入れたい意思決定者。
刷新は数年単位のプロジェクトになる。AI変換の提案を受けた「いま」が、方式と検証設計を固める最適なタイミングだ。
AI変換の提案、鵜呑みにする前に第三者の目を
COBOL→Java変換は工数を圧縮できる一方、検証設計とベンダーロックインの落とし穴があります。GXOは特定ツールに依存しない立場で、移行方式の妥当性・見積もり・検証計画を点検します。提案中の刷新計画があれば、その内容を持ち込んでのご相談も可能です。
刷新計画を第三者にチェックしてもらう → GXO お問い合わせ
※ 営業電話はしません ｜ オンライン対応可 ｜ 構想段階の相談だけでもOK
よくある質問（FAQ）
Q1. AIを使えばCOBOLからJavaへの移行は丸投げできるのか？
できません。AIや自動変換ツールは、コード解析・構文変換・テストケース生成といった工程の工数を圧縮します。しかし、コードに書かれていない暗黙の業務ルールの把握や、変換後コードが業務として正しく動くかの最終判定は人が担う必要があります。丸投げすると「動くが意味を取り違えたシステム」になるリスクがあるため、業務知識の再獲得と品質検証は社内で握ることをおすすめします。
Q2. 富士通×IBMの発表で、移行コストや工数はどれくらい削減されると示されたのか？
2026年6月17日の共同発表では、提供開始の具体的な時期や、工数・コストの定量的な削減目標は明記されていません。したがって「何割削減」といった数字は、現時点では公式に確認できません。営業提案でこうした数字を提示された場合は、対象規模・前提条件・検証範囲といった根拠を必ず確認してください。
Q3. リライト（AI自動変換）以外に、どんな移行方式があるのか？
大きく4つあります。AI変換で言語を書き換える「リライト」、ロジックを変えずオープン基盤へ載せ替える「リホスト」、業務要件から再設計する「リビルド」、ERP等のパッケージに業務を寄せる「パッケージ／SaaS」です。期限・予算・将来戦略によって最適解は変わります。まず現行資産を棚卸ししたうえで方式を比較し、その後に手段（ツール）を選ぶのが安全です。
Q4. ベンダーロックインを避けるには何を確認すればよいか？
変換後のソースコード・変換ルール・テスト資産を自社が保有・改修できるか、変換先が標準的なJava・OSS・クラウドで保守を継続できるか、変換を請け負ったベンダー以外でも保守できる構造か、を確認してください。脱メインフレームの目的が特定メーカー依存からの解放であるなら、刷新先で別のロックインに陥らないよう、利害関係のない第三者による方式・見積もりの検証が有効です。
まとめ
富士通と日本IBMの協業によって、COBOL→JavaのAI自動変換は現実的な選択肢として一段と存在感を増した。だが、AIが圧縮するのは解析・変換・テストの工数であって、業務知識の把握と品質検証という最大の難所は依然として人の仕事だ。「丸投げ」は意味の取り違え、検証の形骸化、新たなレガシーの発生という形で失敗する。
成否を分けるのは、ツールの性能ではなく、移行方式の選定と検証設計、そしてベンダーロックインを避ける第三者の視点である。期限が決まっている以上、AI変換の提案を受けた今こそ、方式と検証を固めるべきタイミングだ。
GXOは特定ツール・特定メーカーに縛られない立場で、現行資産の棚卸しから移行方式の選定、品質検証の設計、体制づくりまでを支援する。詳しくはレガシーモダナイゼーションとDX・システム開発を参照のうえ、刷新の概算はシステム開発の見積もりから、提案中の計画の点検は見積もりセカンドオピニオンからご相談いただきたい。
参考情報
-
日本IBM「Fujitsu and IBM Japan collaborate on modernization to support enterprise digital transformation」（2026年6月17日・一次情報）: https://jp.newsroom.ibm.com/2026-06-17-Fujitsu-and-IBM-Japan-collaborate-on-modernization-to-support-enterprise-digital-transformation
-
富士通 ニュースリリース（2026年6月17日・一次情報）: https://global.fujitsu/ja-jp/pr/news/2026/06/17-01
-
IT Leaders「富士通と日本IBM、モダナイゼーションで協業強化」（2026年6月・二次報道）: https://it.impress.co.jp/articles/-/29470
-
Web担当者Forum 関連記事（2026年6月18日・二次報道）: https://webtan.impress.co.jp/n/2026/06/18/52832
-
富士通「メインフレームおよびUNIXサーバの事業終息について」（2022年2月公表。メインフレーム販売終息2030年度・保守終了2035年度末／UNIXサーバ保守終了2034年度）: https://pr.fujitsu.com/jp/news/2022/02/10.html
稟議・RFPに落とす90日アクションプラン
この記事の論点を実際の商談・稟議・RFPに落とす場合は、情報収集で止めず、30日・60日・90日の3段階で意思決定材料を作る。重要なのは、ベンダーに「何ができますか」と聞く前に、自社の現行業務、データ、権限、運用制約、セキュリティ要件を数字で出すことだ。生成AI、RAG、AIエージェント、業務システム、基幹システム、レガシー刷新、補助金活用のどれであっても、この順番を外すと見積り比較が崩れる。
| 期間 | やること | 成果物 |
|---|---|---|
| 30日以内 | 対象業務を1〜3件に絞り、月間件数・担当人数・処理時間を確認する | 業務棚卸し、現状KPI、制約一覧 |
| 60日以内 | 要件定義、RFP、ベンダー選定軸、セキュリティ要件を整理する | RFP草案、比較表、概算予算 |
| 90日以内 | PoCまたは初期導入で効果・リスク・運用負荷を測る | 評価レポート、改善計画、本番判断 |
一次情報も同じ表に残しておく。AIやセキュリティが絡む案件では、NIST AI Risk Management Framework、OWASP Top 10 for LLM Applications、IPA 情報セキュリティ、JPCERT/CC 注意喚起、個人情報保護委員会を参照し、製品固有の公式発表と並べて確認する。補助金や中小企業施策を使う場合は、中小企業庁の更新も確認する。
GXOに相談する場合は、現状資料が完全でなくてもよい。最低限、対象業務、利用中システム、月間件数、希望時期、予算レンジ、既存ベンダー、セキュリティ制約の7点があれば、要件定義・RFP・ベンダー比較・AI開発・セキュリティ・レガシー刷新の優先順位を整理できる。