「AWSにホストを移すツールがあるんですよね」——半分正しく、半分は危険な誤解です。AWS Mainframe Modernizationは確かに強力で、COBOLを自動でJavaに変換もできます。しかし移行の山場は変換そのものではなく、変換後の等価性検証と、ツールが拾いきれない周辺です。このシリーズの総論として、2つの道と「ツールで済む範囲・済まない範囲」を、誇張なしで示します。
01まず2つの道 — リファクタか、リプラットフォームか
AWS Mainframe Modernizationには、性格の全く異なる2つのパターンがあります。ここの選択が移行のすべてを決めます。
| 自動リファクタ（Blu Age） | リプラットフォーム（Micro Focus/Rocket等） | |
|---|---|---|
| やること | COBOL→Java、画面→Web、JCL・データを近代化技術に自動変換 | COBOLをCOBOLのまま、互換ランタイムで再コンパイルして動かす |
| 移行後の姿 | Javaのモダンな資産。将来の内製・改修がしやすい | COBOL資産が残る。既存のCOBOL要員がそのまま活きる |
| 向くケース | 脱COBOL・技術者不足の解消が目的。中長期の内製化 | まず脱ホストが目的。COBOL資産と要員を活かしたい |
| 主な労力 | 変換率の最後の詰め＋現新比較 | 環境差の吸収＋現新比較 |
どちらを選んでも、最後に待っているのは現新比較（等価性検証）です。これは後述しますが、移行工数の見積もりで最も過小評価される部分です。
02Blu Ageは何をしてくれるのか
自動リファクタ（Blu Age）は、確かに驚くべきことをします。COBOLのソースを解析してJavaに変換し、CICSのBMSマップをAngularのWeb画面に、VSAMやフラットファイルをリレーショナルなデータストアに、JCLを実行制御に翻訳する。手作業では年単位の書き換えが、機械変換で土台まで進みます。ここは本当に強力で、過小評価すべきではありません。
03では、何が「済まない」のか
正直に書きます。自動変換は土台を作りますが、次のような部分は人の仕事として残ります。ここを見積もりから落とすと破綻します。
- 変換率の最後の1割 — 標準的なCOBOLは高い変換率で通りますが、非標準の書き方、環境依存の挙動、アセンブラの混在、特殊ユーティリティ呼び出しは個別対応が要る
- 文字コードと数値表現 — EBCDIC・JEF・COMP-3（パック10進）の変換は、後述の専用記事が要るほど地雷が多い
- VSAMのデータモデル判断 — 機械的にテーブル化はできても、「そのまま持つか、正規化して作り直すか」は設計判断
- 認証・セキュリティ — RACF/ACF2の世界観はAWSにそのまま移せない（ID基盤の再設計）
- 現新比較 — そして最大の山。「変換できた」と「同じ結果が出る」は別物です
04富士通COBOL・GS系という日本固有の事情
日本のホスト移行には、IBM z/OSだけでなく富士通GS系（NetCOBOL、JEFエンコード）という大きな一群があります。海外発の移行ツールやノウハウはz/OS・EBCDIC前提のものが多く、JEFの文字コード、富士通COBOLの方言、外字の扱いといった日本固有の論点は、そのままでは埋まりません。ここは国内で実際に手を動かした経験がものを言う領域です（当社は富士通GS21系の案件経験がございます）。
05「ツールが決める」のではなく「設計が決める」
まとめると、Mainframe Modernizationは移行を可能にする強力な道具ですが、成否を決めるのはツールの選択ではなく、その周りの設計——現新比較の設計、データモデルの判断、文字コードと数値の扱い、認証の再設計——です。ツールはトラックであって、荷造りと道順は人が決めます。
このシリーズでは、その「人が決める部分」を1本ずつ掘り下げます：現新比較／VSAM／EBCDIC・JEF・COMP-3／認証。COBOLerの方が「そこ、わかってる」と思える深さで書いていきます。 そしてBlu Age採用のほんとうの壁（言語・アジャイル・テスト文化）は、技術以上に見積もりを左右します。全体の位置づけは移行の全体フローも併せてどうぞ。
ホスト移行の方式判断（リファクタ／リプラットフォーム）と、ツールで済まない周辺の見積もりは、経験値が金額を左右します。EMWはBlu Ageを含む近代化と、富士通GS21系を含む国内ホスト移行の知見で、机上でない見積もりをお出しします。
相談する