あらゆるメインフレーム移行は、誰かがメインフレーム移行ツールを検索するところから始まります。そのあとに続くベンダーのデモは、判で押したように見事です。数千行の COBOL を投げ込むと、読める Java が出てくる。テストは通り、スライドは七割から八割の自動化を約束します。デモそのものは、たいてい正直です。ただし、そこで使われているコードは、あなたのコードとは似ても似つかない振る舞いをしています。

本稿では、実在するツールの分類を整理し、それぞれが本当に得意とすること、そして実務の負荷がかかったときに壊れやすい具体的な場所を説明します。想定している読者は、社内でベンダーを推す立場の人ではなく、事業計画に署名する立場の人です。

正直な立ち位置： メインフレーム移行ツールは、解析、データ移動、機械的な変換において、たしかに多くの有用な仕事をこなします。できないのは、あなたの業務ルールを理解することです。自動変換は、動くコードなら確実に生み出します。しかし、あなたのチームが保守したいと思えるコードは生み出しません。そして、その差を埋める作業にこそ、予算の大半が実際に消えていきます。

メインフレーム移行ツールの四つの分類

市場は一見ひしめき合って見えますが、製品が実際に何をするのかで並べ替えると、様相は変わります。ほとんどすべてが四つの群れのどれかに収まり、本気の移行プログラムは、そのうち少なくとも三つからツールを持ち込むことになります。

発見・解析ツールは、あなたのソース資産を読み込み、何を持っているのかを教えてくれます。COBOL、JCL、コピーブック、データベース定義を解析し、呼び出し関係のグラフ、データの系譜、依存関係の木を組み立てます。この分類はもっとも地味で、そしてもっとも安定して価値があります。四十年にわたって積み上がってきたシステムの全体像を持っている人は、社内に一人もいないからです。

リホストおよびエミュレーション基盤は、コンパイル済みのメインフレームの処理を、汎用ハードウェアやクラウドのインスタンス上で動かせるようにします。COBOL は COBOL のまま、JCL は JCL のまま残り、互換層がメインフレームの提供していた実行時サービスを肩代わりします。

自動変換ツールは、ソースコードを COBOL から Java や C#、あるいは別の現代的な対象言語へ変換します。買い手がもっとも心を躍らせる分類であり、そして後述する理由から、もっとも頻繁に失望を招く分類でもあります。

データ移行ツールは、データそのものを運びます。VSAM ファイル、順編成データセット、DB2 のテーブルを、リレーショナルあるいはクラウドネイティブの保管先へ移します。汎用の ETL 製品ではそもそも解釈できない文字コードの変換、パック十進数の項目、レコードのレイアウトを、これらは扱えます。

主要なクラウド事業者はこれらのいくつかをまとめて提供していますし、専業ベンダーはここ数年の買収を通じてかなり集約が進みました。複数年の保守契約に署名する前に、その製品を現在どこが所有していて、ロードマップにどこまで約束があるのかを確認してください。この市場では、技術よりも所有者のほうが頻繁に入れ替わります。

解析ツールが本当に得意なこと

どれか一つの分類だけを買うのなら、これを買ってください。発見ツールは、手作業でやれば契約要員のチームが数か月かけて答えることになる問いに、答えを出します。

出来のよい解析製品なら、本番で実際に呼ばれているプログラムはどれで、十年前から死んでいるプログラムはどれか、画面の項目から半ダースのプログラムを経て DB2 のテーブルへデータがどう流れているか、どのコピーブックがサブシステムをまたいで共有されているか、そして本当に危険なコードがどこに住んでいるかを教えてくれます。最後の出力こそが計画を変えます。どのメインフレーム資産にも、すべてがそこに依存している一握りのプログラムが存在し、それが事業側の思い描いているものであることは、めったにありません。

限界は解釈にあります。四万個の節点を持つ依存関係のグラフは、データであって洞察ではありません。誰かがその出力を眺め、業務上の機能単位にまとめ直し、何から動かすかを決める必要があります。業務ルールを自動的に導き出すと謳うツールが生み出すのは、意図の記述というよりコードの言い換えに近いものです。そして両者は、業務側が黙って適応してきた欠陥がコードに潜んでいる、まさにその場所で食い違います。

方式を決める前に解析を走らせてください。当社のメインフレーム近代化の進め方 についてのガイドが、そこで得た知見を、作り直し・リファクタリング・基盤の載せ替えという判断へどう反映させるべきかを扱っています。

リホスト基盤：速くて本物、しかし近代化ではない

リホストは、選べる選択肢のなかでもっとも見通しが立ちやすく、それゆえに慢性的に過小評価されています。

理屈は単純です。あなたの COBOL は、メインフレームの実行時サービスを模した基盤の上で再コンパイルされるか解釈実行され、トランザクション処理、バッチのスケジューリング、ファイルの取り扱い、ジョブ制御はこれまでどおりに振る舞い続けます。ソースがほとんど変わらないため、試験の負担は他のどの経路よりもはるかに軽く、プロジェクトは年単位ではなく月単位で終わります。

節約は本物で、それはソフトウェアからではなくハードウェアと課金の仕組みから生まれます。物理的なメインフレームから降りたあと、年間の運用費が大きく下がったと報告する組織は少なくありません。そしてそれは、次の段階の作業を賄えるだけの額になることも多いのです。

リホストがしないのは、多くの取締役会がこの種のプログラムを承認する、その理由への対処です。リホストがうまくいったあとも、手元にあるのは COBOL のコードベースであり、COBOL の技術者は依然として必要で、その採用しやすさは何も改善していません。アプリケーションが変更しやすくなったわけでもありません。リホストは時間と現金を買ってくれます。それは本当に価値のあることですが、近代化ではなく基盤の変更として、正直に説明されるべきものです。

もう一つ、新しい依存も持ち込みます。IBM の実行環境を、あるベンダーの互換層に取り替えたわけで、あなたの本番環境はそのベンダーが支援を続けることに依存するようになります。この市場で集約がどれほど頻繁に起きるかを思えば、それは事業計画に書き込んでおく価値のあるリスクです。

自動変換：本当の問題はここにある

COBOL の自動変換は動きます。そこは問題ではありません。問題は、出てきたものがどんな姿をしていて、それと共に生きるのにいくらかかるかです。

変換エンジンはおおむね忠実です。誰も意図していなかった振る舞いまで含めて、振る舞いを保存します。忠実であることが、唯一まともに擁護できる設計目標だからです。保険料計算のある丸め処理の癖が、1997年から保険数理の担当者が埋め合わせ続けてきた欠陥だなどと、ツールに知る術はありません。だからそれを正確に再現します。それは正しい選択であり、同時に、新しい Java のシステムが古いシステムの積み上げてきた奇癖をすべて受け継ぐということでもあります。

出力は入力の形にも縛られます。GOTO の連鎖、PERFORM THRU による落ち込み、ALTER 文、そして複数の経路から入ってくる段落で書かれた COBOL は、きれいなメソッドに分解できません。分解できるきれいな構造が、そもそも存在しないからです。そこから現れるのは、COBOL の制御フローをなぞり、COBOL の変数名を使い、しばしば元のコードより読みにくい Java や C# です。実務家はそれを JOBOL と呼びます。移行そのものは成功裏に完了しながら、どちらの言語でも誰も保守できないコードベースが残る、ということが十分に起こり得ます。

とくに割に合わない苦痛をもたらす構文がいくつかあり、それらは手作業の見積もりを左右するので、早い段階で確認しておく価値があります。

手作業の量を決める五つの構文

一つ目はパック十進数の演算です。COBOL の COMP-3 項目と固定小数点の十進数の意味論は浮動小数点に写像できず、写像させてしまうツールは、小数第四位でメインフレームと食い違う金額を生み出します。正しい変換は任意精度の十進数型を使いますが、それは処理が遅く、しかもすべての計算経路にわたって一貫して適用しなければなりません。

二つ目は文字コードです。EBCDIC から ASCII への変換は機械的ですが、照合の順序は同じではないため、並び順に依存するものはすべて変わり得ます。帳票が違う順番で出てきて、範囲の判定が違う挙動になり、キーの比較は新しいシステムでは正しく、しかし旧システムに照らすと誤っている結果を返します。

三つ目は REDEFINES と可変レコードです。一つの記憶域を何通りにも解釈する仕組みは、強く型付けされた言語に自然な対応物を持ちません。生成されたコードはたいてい、アクセサで包んだバイト配列の操作を吐き出します。動きはしますが、保守する側にとっては実に不快なものです。

四つ目はトランザクションの意味論です。CICS の擬似会話型プログラミング、つまり画面のやり取りのあいだ通信領域に状態を持ち回る方式は、現代のウェブやサービスのどの型にも対応しません。それを模倣すれば奇妙なものが出来上がり、きちんと作り直すなら、それは表示層の書き直しです。

五つ目はアセンブラのルーチンで、これがもっとも確実に過小評価されます。長く生きてきた資産のほとんどには、性能上あるいは基盤上の理由で書かれたアセンブラのモジュールが数本は含まれていて、たいていは何年も前に退職した誰かの手によるものです。これを変換するツールはありません。振る舞いから、試験を伴って、人の手で書き直すことになります。

移行先の言語を検討しているのなら、COBOL から Java への移行 と COBOL から C# への移行 についての詳しいガイドが、これらの構文がそれぞれの生態系でどう着地するかを扱っています。

データ移行ツールと、噛みついてくる細部

データの移動はコードの変換ほど注目されませんが、少なくとも同じくらいの遅延を生みます。

専門ツールがここで存在意義を持つのは、メインフレームのデータ形式が本当に厄介だからです。コピーブックのレイアウト、パック十進数とゾーン十進数の項目、符号のオーバーパンチ、OCCURS DEPENDING ON 句、そして一つの VSAM ファイルのなかに、十二バイト目の一文字で区別される何種類ものレコードが混在しうるという事実を、これらは理解しています。汎用の ETL 製品は理解しません。それで無理を通そうとしたチームは、たいてい同じ能力の劣化版を自作することになります。

より厄介なのは技術ではなく意味の問題です。メインフレームのファイルは、リレーショナルなスキーマでは直接表せない形で意味を抱え込んでいることがよくあります。別の用途に流用された予備項目、六桁の整数として保存され、世紀を推定する規則を伴う日付、有効な値の一覧が対照表ではなくプログラムの中にしかない状態フラグ、そしてアプリケーションが黙認している重複キーといった具合です。これらが移行先のスキーマで何になるべきかを決めるのは解析の仕事であり、自動化できません。答えは人の頭の中にしか存在しないからです。

突き合わせは最初から計画に入れてください。移行したデータセットのすべてに、レコード件数、合計値の照合、項目単位の比較が、一度きりではなく繰り返し必要になります。多くのプログラムでは並行稼働の期間も要ります。両方のシステムが同じ入力を処理し、出力を一バイト単位で突き合わせ、差分が消えるか説明がつくまで続けるのです。その比較の仕掛けは、それ自体が固有の開発費を持つ本物のソフトウェアであり、予備費ではなく計画の中に置かれるべきものです。

後悔しないメインフレーム移行ツールの選び方

いくつかの原則が、この種の判断を地に足のついたものにしてくれます。

概念実証は、ベンダーの見本ではなく、あなたのところのいちばんひどいコードで行うと言い張ってください。誰もが避けて通るモジュール、アセンブラの呼び出しと七重の REDEFINES を抱えたあれを選び、変換してみせてくださいと頼むのです。その結果は、どんな導入事例よりも多くを語ります。

十進数の演算と並び順をツールがどう扱うのかを名指しで尋ね、要約ではなく生成された出力そのものを見せてもらってください。醜い入力から読めるコードを示せないベンダーであれば、手作業の手当ての見積もりは提示額より大きいと考えて構いません。

自動化率は、工数ではなく行数の指標として扱ってください。文の九割を変換するツールでも、リスクのすべてが詰まった残りの一割はあなたの手元に残るかもしれず、その一割が日程の半分以上を平然と食い潰します。

最後に、どのツールも触れない部分に予算を取ってください。試験の仕掛け、突き合わせ、並行稼働、運用手順書、そして再教育です。当社の COBOL 移行の費用と期間のガイド が、これらの費目がプログラム全体にどう配分されるのが普通かを示しています。

決める前に、利害のない見立てを

Mecanik はレガシーメインフレーム移行 と COBOL 移行 のプログラムに、ツールの再販業者としてではなく技術者として関わっています。つまり、どの基盤を選ぶかで当社に入る手数料はありません。私たちは発見の工程を回し、本当に手強いモジュールを人の手とツールの両方で変換し、その差を、誰かが何かに署名する前にお見せします。

資産がもっと小規模である場合や、問いがツールよりも移行先の言語に関わるものである場合は、当社の COBOL 近代化サービス のページが、その作業をどう見積もるかを説明しています。いずれにせよ、有益な最初の一歩は、あなたのコードベースに実際に何があるのかを短く話し合うことです。ツールの問いに対する答えは、そこに全面的に依存しているからです。

関連記事: COBOL近代化サービス：ベンダーの選び方 、COBOLからPythonへの移行 - 英国企業向けガイド 2026 、COBOLからGoへの移行:英国企業向けガイド 、COBOLからRustへの移行 - 英国企業向けガイド 。

よくある質問

メインフレーム移行ツールでプロジェクト全体を自動化できますか？ いいえ。自動変換は文の大半を変換しますが、残りにはアセンブラのモジュール、トランザクションの状態管理、可変レコードの構造、そして文書化されていない業務ルールが含まれ、これらは人の手を必要とします。試験、突き合わせ、並行稼働も、コードの自動化率がどれだけ高まっても影響を受けません。

リホストと自動コード変換では、どちらが優れていますか？ 解いている問題が違います。リホストは処理をメインフレームのハードウェアから素早く降ろし、運用費を下げますが、手元には COBOL が残ります。コード変換は言語と採用市場を変えますが、費用もリスクも相当に高くなります。多くの組織はまずリホストし、そのうえで段階的な変換の資金を賄います。

変換された COBOL のコードは、なぜあれほど読みにくいのですか？ 変換エンジンが、COBOL の制御フロー、命名、データ構造まで含めて振る舞いを忠実に保存するからです。GOTO の連鎖と共有記憶域を前提に組まれたコードには、Java や C# にきれいな対応物がなく、出力は元の構造をそのまま映します。保守できるコードにするには、変換のあとに人の手でリファクタリングする必要があります。

メインフレーム移行ツールが見落とすデータの問題は何ですか？ 形式の変換はうまく扱いますが、意味は解決できません。別の用途に流用された予備項目、世紀を推定する規則を伴う六桁の日付、プログラムの中にしか定義のない状態コード、黙認されてきた重複キーは、いずれも移行先のスキーマを正しく設計する前に人の判断を要します。

移行後のシステムが同じ振る舞いをすることを、どう検証しますか？ 定めた期間、両方のシステムを同じ本番の入力に対して動かし、出力を項目単位で突き合わせます。それを支えるのが、移行したデータセットごとのレコード件数と合計値の照合です。差分は一度にではなく継続的に見つかるものなので、その比較の仕掛けはそれ自体を成果物として作ってください。