この記事の要点
COBOLからJava・Pythonへの移行で業務ロジックを守るには、「コードを変換する」前に「業務ルールを取り出して確定する」ことが欠かせません。COBOLの業務ロジックは、IF文だけでなく、数値の桁定義・文字コード・JCLなど、コードの外にも埋まっているためです。本記事では、COBOL特有の「壊れやすい7つの急所」と、抽出・変換・現新比較による5ステップの進め方、生成AIの使いどころを解説します。
COBOL Java移行で業務ロジックを守る方法は、ひと言でいえば「変換の前に業務ルールを取り出し、変換後に新旧の結果が一致することを証明する」ことです。
COBOLの業務ロジックは、計算式や条件分岐だけではありません。COMP-3（パック10進数）の端数処理、EBCDICの並び順、88レベルの条件名、JCLのステップ順など、データ定義や実行環境にも分散しています。自動変換ツールで「変換率98%」を達成しても、残りの2%がこうした箇所に集中していれば、本番で請求金額や帳票がずれます。
そのため、①資産の棚卸し、②業務ルールの抽出と台帳化、③「守る・変える・捨てる」の合意、④変換ルールの標準化、⑤現新比較による等価性の証明、の5ステップで進めるのが安全です。生成AIは①〜②と⑤のテスト生成を大きく効率化しますが、仕様を変えてよいかの判断は人が担います。
本記事は、COBOL / RPGモダナイゼーションの全体像を解説した記事のクラスター記事です。移行方式の全体比較はそちらもあわせてご覧ください。
1. COBOL Java移行で「業務ロジックを守る」とは？
COBOL Java移行における「業務ロジックを守る」とは、移行後のシステムが、旧システムと同じ入力に対して業務上同じ結果を返すことを指します。
画面が動く、バッチが正常終了する、というだけでは不十分です。請求金額、帳票の並び、エラー時の扱いまで一致して、初めて「守れた」といえます。
経済産業省も、レガシーシステムが企業のDXを阻む要因になっていると繰り返し指摘しています（経済産業省「レガシーシステムモダン化委員会総括レポート」）。移行そのものは避けられなくても、業務ロジックを失う移行は、ブラックボックスを別の言語に移し替えるだけになってしまいます。
ここからは、まず「業務ロジック」とは何を指すのかを整理します。
1-1. 業務ロジックとは：計算・判定・状態・時間のルール
業務ロジック（ビジネスロジック）とは、業務の決まりごとをプログラムに置き換えたものです。大きく次の4つに分けられます。
- 計算ロジック：金額、利息、税額、単価の計算と端数処理
- 判定ロジック：与信可否、割引適用、エラー判定などの条件分岐
- 状態遷移ロジック：受注→出荷→請求→入金といったステータスの流れ
- 時間依存ロジック：締め日、月末営業日、年度切り替え、バッチの実行順
4類型ごとの検証方法は、移行後の業務ロジック検証の進め方で詳しく解説しています。本記事では、COBOLならではの「隠れ場所」に絞って見ていきます。
では、なぜ高い変換率をうたうツールを使っても、業務ロジックが壊れるのでしょうか。
1-2. 「変換率98%」でも業務ロジックが壊れる理由
自動変換ツールの「変換率」は、多くの場合「構文として変換できた行の割合」です。業務上の結果が一致する割合ではありません。
変換できなかった2%は、帳票の編集、外部連携、複雑な計算といった、業務的に重い箇所に集中しがちです。さらに、構文上は変換できた98%の中にも、数値型や文字コードの違いによる「静かなズレ」が潜みます。
もう一つ、変換後のコードの「書き方」そのものにも課題があります。
1-3. JaBOL（COBOL風Java）は「守った」ことになるのか
JaBOL（ジャボル）とは、COBOLの構造をそのまま写した、Javaの文法で書かれたCOBOLのようなコードです。
JaBOLは、行単位で変換するため結果の一致は比較的得やすい一方、Javaエンジニアには読みにくく、保守性が上がりません。つまり、短期的には業務ロジックを守れても、中長期的にはロジックを再びブラックボックス化させるリスクがあります。
「結果を守ること」と「理解できる形で残すこと」の両方が、本来の意味での業務ロジック継承です。
2. 移行方式で変わる「業務ロジックの残り方」
COBOL移行の方式は、大きく自動変換・リライト・リビルドの3つです。費用や期間で比較されることが多いですが、ここでは業務ロジックがどう残るかという視点で比べます。
2-1. 自動変換・リライト・リビルドの比較（継承度・保守性・検証コスト）
| 観点 | 自動変換（トランスパイル） | リライト（書き直し） | リビルド（再構築） |
|---|---|---|---|
| 業務ロジックの継承度 | 高い（行単位でそのまま写す） | 中〜高（設計し直しつつ継承） | 低〜中（業務から作り直す） |
| 移行後の保守性 | 低い（JaBOL化しやすい） | 高い | 高い |
| 主なリスク | 静かなズレ、読めないコード | 解釈の誤り、抜け漏れ | 仕様の取りこぼし |
| 検証コスト | 中（現新比較が中心） | 高（業務ルール単位の検証） | 高（受入テストの作り直し） |
| 向いているケース | ロジックを変えず早く移したい | 保守性と継承を両立したい | 業務自体を見直したい |
どの方式を選んでも、業務ルールの抽出と、新旧の結果比較は省略できません。 違いは「どこに工数がかかるか」です。
方式とあわせて決めるべきなのが、移行先の言語です。
2-2. 移行先はJavaかPythonか：業務ロジックの性質で選ぶ
COBOL Java移行が主流ですが、近年はCOBOL Python移行の相談も増えています。どちらが正解というより、移すロジックの性質で選ぶのが現実的です。
- Javaが向くロジック：大量件数の基幹バッチ、勘定系・請求系のトランザクション処理、長期運用が前提の業務。型が厳密で、
BigDecimalによる10進演算の実績が豊富です。 - Pythonが向くロジック：データ加工・集計、分析やAIと連携する処理、周辺の小〜中規模システム。記述量が少なく、データ活用基盤との相性に優れます。
1つのシステムの中で、基幹部分はJava、データ加工部分はPythonと分ける構成も有効です。ただし、どちらを選んでも、次章で紹介する「数値と文字コード」の扱いを誤ると、業務ロジックは壊れます。
3. COBOL特有：業務ロジックが壊れやすい7つの急所
COBOLの業務ロジックは、IF文の中だけにあるわけではありません。データの宣言の仕方、文字コード、さらにはプログラムの外側にも埋まっています。ここでは、COBOL Java移行・COBOL Python移行の現場で特にズレが起きやすい7つの急所を紹介します。
まずは、最も影響が大きい「数値」から見ていきます。
① 数値型と端数処理：COMP-3・ROUNDED・桁あふれ
COBOLは、PIC 9(7)V99 COMP-3 のように10進数の桁数を厳密に定義して計算します。一方、JavaのdoubleやPythonのfloatは2進数の浮動小数点数で、0.1のような値を正確に表せません。
さらに、端数処理のルールも言語ごとに異なります。
- COBOLは、
ROUNDEDを付けなければ切り捨て、付ければ四捨五入（0から遠い方へ丸め）です。 - Pythonの
round()とdecimalモジュールの既定は偶数丸め（銀行丸め）です（Python公式ドキュメント「decimal」）。 - 桁あふれの際、COBOLは上位桁を黙って切り捨てることがあります（
ON SIZE ERROR未指定時）。Javaにはこの挙動がありません。
例えば、1.005を小数第2位に丸める計算では、次のように結果が分かれます。
| 実装 | 結果 | COBOL（ROUNDED）と一致？ |
|---|---|---|
COBOL COMPUTE X ROUNDED |
1.01 | ― |
Java double ＋ Math.round |
1.00 | ✕ |
Java new BigDecimal(1.005) ＋ HALF_UP |
1.00 | ✕ |
Java new BigDecimal("1.005") ＋ HALF_UP |
1.01 | ○ |
Python round(1.005, 2) |
1.0 | ✕ |
Python Decimal("1.005")（既定の丸め） |
1.00 | ✕ |
Python Decimal("1.005") ＋ ROUND_HALF_UP |
1.01 | ○ |
1件あたり1円未満の差でも、数百万件のバッチで積み上がれば、決算や請求に響きます。JavaではBigDecimalを文字列から生成し、Pythonではdecimalの丸めモードを明示することを、変換ルールとして全体で統一しましょう（Javaの仕様はOracle公式「BigDecimal」を参照）。
数値の次に見落とされやすいのが、1つの領域を複数の意味で使う定義です。
② REDEFINES・OCCURS：1つの領域に複数の意味
REDEFINESは、同じメモリ領域を別の形式で読み替える仕組みです。例えば、レコード区分が「1」なら個人顧客、「2」なら法人顧客として、同じ領域を違う項目として解釈します。
どの区分のとき、どの定義で読むかという判断自体が業務ルールです。Javaのクラスに機械的に置き換えると、この判断が失われがちです。
OCCURS DEPENDING ON（可変長の繰り返し）も同様です。件数項目の値によって後続項目の位置が変わるため、移行後のデータ構造で正しく再現できているか確認が必要です。
データ定義には、さらに「名前の付いたルール」も埋まっています。
③ 88レベル条件名とCOPY句：データ定義に埋まったルール
88レベルの条件名は、88 優良顧客 VALUE 'A' 'B'. のように、値の範囲に業務上の意味を与える定義です。手続き部では IF 優良顧客 とだけ書かれるため、条件の中身はデータ部を見ないとわかりません。
また、COPY句（コピーブック）は複数のプログラムで共有されます。1つのCOPY句の変更が、数十本のプログラムの判定条件を同時に変えていることも珍しくありません。移行時は、COPY句単位で業務ルールを台帳化し、変換先でも共通クラスや定数として一元管理しましょう。
次は、処理の「流れ」そのものに潜む仕様です。
④ PERFORM THRU・GO TO：制御フローに潜む暗黙の仕様
COBOLのPERFORM A THRU Bは、段落Aから段落Bまでを連続して実行します。途中にGO TOがあると、実際にどの段落を通るかはソースを上から読んでも追いにくくなります。
段落の並び順を変えるだけで処理が変わる「フォールスルー」も、暗黙の仕様の一つです。リライト時に構造化プログラミングへ書き直す際は、書き直す前と後で同じ経路を通るかをテストで確認してから進めることが重要です。
ここからは、日本の基幹システムで特に注意が必要な急所です。
⑤ EBCDICと日本語コード：並び順・外字・全角半角
メインフレームのCOBOLは、多くの場合EBCDIC系の文字コードで動いています。EBCDICでは、英小文字 → 英大文字 → 数字の順に並びますが、ASCIIやUnicodeでは数字 → 英大文字 → 英小文字です。
そのため、「A001」と「1001」の並び順が移行前後で逆転します。並び順に依存したキーブレイク処理や帳票の出力順は、そのままでは結果が変わります。
日本語には、さらに固有の課題があります。
- メーカー独自の漢字コード（IBM漢字、JEF、KEIS、JIPSなど）からUnicodeへの変換
- 人名・地名に使われる外字（髙、﨑など）の対応表づくり
- シフトコード（SO/SI）の扱いと、固定長レコードのバイト数の変化
- 全角・半角の判定や、半角カナを前提にした入力チェック
文字コードは「データ移行の問題」と思われがちですが、比較・並び替え・桁チェックという業務ロジックそのものに影響します。
文字の次は、COBOLが得意とするファイル処理です。
⑥ ファイル処理：キーブレイク・マッチング・LOW-VALUES
COBOLのバッチには、ファイル処理の定番パターンに業務ルールが埋め込まれています。
- キーブレイク処理：キーが変わったタイミングで小計を出す。並び順の前提が崩れると集計が変わります。
- マッチング処理：マスタとトランザクションを突き合わせる。「片方にしかないレコード」の扱いが業務ルールです。
- LOW-VALUES／HIGH-VALUES／SPACES：COBOLにはNULLがなく、これらを「未設定」や「終端」の意味で使います。RDBのNULLへどう対応させるかを決める必要があります。
- FILE STATUS：「レコードなし（23）」などの戻り値ごとの分岐も、業務上の例外処理です。
VSAMからRDBMSへ移す場合は、こうした前提をSQLやアプリ側で再現できているか、同じデータで新旧の出力を突き合わせることが欠かせません。
最後の急所は、COBOLのソースコードを見ても見つからない場所にあります。
⑦ コードの外：JCL・ソートユーティリティ・CICS画面
COBOL資産の業務ロジックは、プログラムの外にも分散しています。
- JCL：ジョブのステップ順や、
CONDパラメータによる「前のステップが失敗したら実行しない」制御 - ソートユーティリティ（DFSORTなど）：
INCLUDE／OMITによる抽出条件や、SUM FIELDS=NONEによる重複レコードの除外 - CICSの画面定義（BMS）：入力項目の属性や、画面側で行っている入力チェック
- 運用手順：オペレーターが手作業で行っている再実行や補正
これらを見落とすと、COBOLプログラムをすべて正しく変換しても、業務の結果は変わってしまいます。 棚卸しの段階で、JCLやソートの制御文も業務ルール抽出の対象に含めましょう。
自社のCOBOL資産に「7つの急所」がどれだけ潜んでいるか、把握できていますか？
HBLABの無償AI診断では、ソースコードを解析し、移行時に業務ロジックが壊れやすい箇所や影響範囲を可視化します。移行方式を決める前の判断材料としてご活用ください。
4. 業務ロジックを失わないCOBOL移行の進め方：5ステップ
7つの急所を踏まえると、COBOL Java移行は「変換作業」ではなく、業務ルールを取り出して確定し、新しい言語で再現できたことを証明するプロジェクトだとわかります。ここでは、その進め方を5ステップで整理します。
Step1. 資産の棚卸しと影響範囲の把握
最初に、COBOLプログラム、COPY句、JCL、ソート制御文、画面定義、ファイル定義を一覧化します。プログラム間の呼び出し関係と、データの流れを可視化することで、どこに業務ロジックが集中しているかが見えてきます。
使われていないプログラムの洗い出しも、この段階で行います。移行対象を減らすことが、検証コストを下げる最も確実な方法です。棚卸しの観点はレガシーシステムアセスメントの記事で詳しく紹介しています。
棚卸しで全体像が見えたら、次は中身の業務ルールを取り出します。
Step2. 業務ルールの抽出：ソース・実データ・業務担当者
業務ルールは、次の3つの情報源を組み合わせて抽出します。
- ソースコード：計算式、条件分岐、88レベル、COPY句、JCL
- 実データ：本番データの値の分布や、例外的なレコードの存在
- 業務担当者：「月末だけこの処理を手で直している」といった運用知識
設計書が残っていない場合でも、ソースコードから設計情報を復元できます。生成AIを使った復元の手順は、AIリバースエンジニアリングによる設計書の復元をご覧ください。抽出したルールは、ルールID・内容・根拠となるソース箇所をセットで台帳に記録します。
ルールを取り出したら、それを「すべて引き継ぐか」を決める必要があります。
Step3. 「守る・変える・捨てる」を合意する
抽出したすべての業務ルールを、そのまま新システムに移す必要はありません。ルールごとに、守る（そのまま継承）・変える（業務改善として変更）・捨てる（不要なので廃止）のいずれかを業務部門と合意します。
特に、旧システムの計算ミスや、現在は使われていない分岐の扱いは、情シスだけでは判断できません。合意の進め方は移行後の業務ロジック検証の進め方で解説しています。
合意したルールを、ブレなく新しい言語に写すための準備が次のステップです。
Step4. 変換ルールを標準化する（数値・文字コード・ファイル）
COBOL Java移行やCOBOL Python移行で品質がばらつく原因の多くは、開発者ごとに変換の書き方が違うことです。そこで、変換前に次のような「変換ルール表」を作り、全員で守ります。
| 対象 | COBOL | Java | Python |
|---|---|---|---|
| 金額・数量 | PIC 9(n)V99 COMP-3 |
BigDecimal（文字列から生成） |
decimal.Decimal |
| 丸め | ROUNDED／切り捨て |
RoundingMode.HALF_UP／DOWN |
ROUND_HALF_UP／ROUND_DOWN |
| 未設定値 | LOW-VALUES／SPACES |
nullまたは既定値（方針を統一） |
Noneまたは既定値（方針を統一） |
| 文字コード | EBCDIC＋漢字コード | UTF-8＋外字対応表 | UTF-8＋外字対応表 |
| 並び順 | EBCDIC順 | 比較器（Comparator）で明示 | key関数で明示 |
ルール表があれば、自動変換ツールや生成AIへの指示もこの表に揃えられます。人が書いても、ツールが書いても、同じ結果になる状態をつくることがポイントです。
最後に、変換した結果が本当に正しいかを証明します。
Step5. 現新比較で等価性を証明する
現新比較とは、同じ入力データを旧システム（COBOL）と新システム（Java・Python）に流し、出力を突き合わせるテストです。帳票、ファイル、DBの更新結果を、項目単位・レコード単位で比較します。
比較の精度を高めるポイントは、次の3つです。
- ゴールデンデータ：本番データから、月末・年度末・例外ケースを含む代表データを選ぶ
- 差異の分類：「バグ」「合意済みの仕様変更」「文字コード由来の許容差」に分けて記録する
- テストの自動生成：COBOLの分岐を網羅するテストケースを生成し、新旧両方で実行する
テストの自動生成は研究も進んでいます。IBM Researchは、COBOLのプログラムから記号実行でテストを生成し、変換後のJavaでも同じテストを実行して等価性を検証する手法を発表しています（IBM Research「Automated Validation of COBOL to Java Transformation」）。
テストの全体設計はマイグレーションテストの進め方、新旧の挙動を一致させる手順は移行のリグレッションテストで詳しく解説しています。
5. 生成AIはCOBOLの業務ロジック継承をどこまで担えるか
生成AIの登場で、COBOL Java移行の進め方は大きく変わりつつあります。ただし、AIに任せてよい部分と、人が判断すべき部分ははっきり分ける必要があります。
5-1. AIが得意なこと：ルール抽出・設計書の復元・テスト生成
生成AIが特に力を発揮するのは、次の作業です。
- 大量のCOBOLソースを読み、業務ルールの候補を一覧化する
- 段落やCOPY句の役割を説明し、設計書を復元する
- 分岐条件からテストケースやテストデータを生成する
- 変換ルール表に沿って、Java・Pythonのコードを下書きする
これまでベテラン技術者が数か月かけていた読み解き作業を、大幅に短縮できる可能性があります。AI活用の全体像はマイグレーションのAI活用と品質担保をご覧ください。
一方で、AIの出力をそのまま採用してはいけない場面もあります。
5-2. 人が判断すべきこと：仕様の改変・例外ルール・端数処理
生成AIは、もっともらしい「改善案」を提案することがあります。例えば、旧システムの不自然な処理を、気を利かせて一般的な書き方に直してしまうケースです。
しかし、その不自然な処理こそが、取引先との契約や法令対応のための意図的な業務ルールかもしれません。仕様を変えてよいか、例外ルールを残すか、端数をどう処理するかは、必ず人が判断し、承認の記録を残しましょう。
AI特有の誤変換への対策は、生成AIマイグレーションのハルシネーション対策で詳しく解説しています。
6. 移行後に業務ロジックを再びブラックボックス化させない
業務ロジックの継承は、本番稼働で終わりではありません。移行後に再びブラックボックス化すれば、10年後に同じ問題を繰り返すことになります。
6-1. 業務ルールをコードから分離する
税率、割引条件、締め日のように変更頻度の高い業務ルールは、プログラムの奥に直接書き込まず、設定テーブルや専用のルール層に切り出します。
こうしておけば、ルール変更のたびに大規模な改修やテストが必要になる状態を避けられます。業務部門がルールの一覧を確認できることも、属人化を防ぐうえで大きな効果があります。
ルールを分離したうえで、もう一つ残しておきたいのが「動く仕様書」です。
6-2. テストを「生きた仕様書」として残す
移行時に作った現新比較のテストケースは、業務ルールが正しく動いていることを示す、最新の仕様書でもあります。
テストを使い捨てにせず、CI（継続的インテグレーション）に組み込んで改修のたびに自動実行すれば、業務ロジックが壊れたことにすぐ気づけます。ブラックボックス化の原因と対策は、システムのブラックボックス化の記事もあわせてご覧ください。
7. COBOL移行の業務ロジック継承チェックリスト（12項目）
社内での検討や、ベンダーとの打ち合わせにご活用ください。
計画・抽出
– ☐ COBOLプログラム、COPY句、JCL、ソート制御文、画面定義を一覧化した
– ☐ 使われていないプログラム・分岐を特定し、移行対象から外した
– ☐ 業務ルールをソース・実データ・業務担当者の3つの情報源から抽出した
– ☐ 業務ルールごとに「守る・変える・捨てる」を業務部門と合意した
変換
– ☐ 金額・数量の型と丸めモード（BigDecimal／decimal）を全体で統一した
– ☐ 桁あふれ時の挙動（COBOLの上位桁切り捨て）の扱いを決めた
– ☐ REDEFINES・88レベル・COPY句のルールを共通クラスや定数に集約した
– ☐ EBCDICの並び順、漢字コード、外字の対応表を作成した
– ☐ LOW-VALUES・SPACESとNULLの対応方針を決めた
検証・定着
– ☐ 月末・年度末・例外ケースを含むゴールデンデータを用意した
– ☐ 現新比較の差異を「バグ・仕様変更・許容差」に分類し、承認記録を残した
– ☐ 移行後もテストを自動実行できる仕組みを用意した
8. HBLABのCOBOL / RPG → Java / Python移行支援
HBLABは、ベトナムを拠点とするオフショア開発の体制と、AIを組み込んだ独自の移行基盤「Migurei AI Inside」を組み合わせ、レガシーシステムのモダナイゼーションを支援しています。
COBOL / RPGからJava / Pythonへの移行パッケージでは、金融・公共分野の基幹システムを主な対象に、次の工程を一貫して提供します。
- 技術調査：COBOL / RPG資産、COPY句、JCLの棚卸し
- アセスメント：業務ロジックが集中する箇所と移行リスクの可視化
- 移行戦略の策定：方式（自動変換・リライト・リビルド）と移行先言語の選定
- 業務仕様の抽出：AIによるリバースエンジニアリングで、業務ルールと設計書を復元
- コード変換：変換ルール表に基づくJava・Pythonへの変換
- 単体テスト：業務ルール単位でのテスト生成と実行
- 結合テスト：VSAMからRDBMSへの移行を含む等価性テスト（現新比較）
「どこから手をつければよいかわからない」という段階からご相談いただけます。
COBOL / RPG資産の移行、業務ロジックを守りながら進めませんか？
HBLABのマイグレーション・モダナイゼーションサービスでは、アセスメントから業務仕様の抽出、変換、等価性テストまでを一貫して支援します。
9. COBOL Java移行と業務ロジックに関するよくある質問
Q1. 自動変換ツールだけで業務ロジックは守れますか？
ツールだけで守り切るのは難しいのが実情です。構文の変換はツールで効率化できますが、数値型・文字コード・JCLなどの違いによるズレは、業務ルールの抽出と現新比較で確認する必要があります。
Q2. 設計書がなくても業務ルールは抽出できますか？
可能です。ソースコードからの解析に加え、生成AIによるリバースエンジニアリングで設計情報を復元できます。ただし、運用でカバーしている手作業のルールは、業務担当者へのヒアリングで補う必要があります。
Q3. 旧システムの計算ミスも新システムで再現すべきですか？
一律には決められません。取引先との精算結果に影響する場合は、意図的に再現することもあります。ルールごとに「守る・変える・捨てる」を業務部門と合意し、判断の記録を残すことが重要です。
Q4. RPG（IBM i）からの移行でも同じ考え方ですか？
基本的な考え方は同じです。RPGも、固定長のデータ定義や10進演算、EBCDIC系の文字コードを使うため、本記事の急所の多くが当てはまります。RPG固有の論点は、COBOL / RPGモダナイゼーションの全体像で解説しています。
Q5. Pythonへの移行が向いているのはどんなケースですか？
データの加工・集計や、分析・AIとの連携が中心の処理に向いています。一方、大量件数の基幹バッチや勘定系の処理は、10進演算や長期運用の実績が豊富なJavaが選ばれることが多いです。
まとめ
COBOLの業務ロジックは、計算式や条件分岐だけでなく、COMP-3の端数処理、REDEFINESや88レベルの定義、EBCDICの並び順、JCLやソートの制御文にまで分散しています。そのため、変換ツールの変換率だけでは、移行の成否は判断できません。
業務ルールを抽出して「守る・変える・捨てる」を合意し、変換ルールを標準化したうえで、現新比較で等価性を証明する。この5ステップで進めることが、業務を止めない移行への近道です。生成AIは抽出とテスト生成を大きく効率化しますが、仕様の判断は人が担います。
COBOL Java・Python移行で業務ロジックを確実に守りたい方は、まずは急所の可視化から始めてみてください。
