完璧にコンパイルされたのに元帳を破損させたCOBOL移行
コードは完璧だった。それこそが問題のすべてだった。
ある電信送金プログラムがCOBOLからJavaへ変換されていた。コンパイルは通った。単体テストも合格した。私たちがミスを捕まえるために築いたあらゆるゲートを通過した。ところが、ユーザー受け入れテストで、まさに最初のトランザクションがデータベースの整合性チェックに引っかかり、システム全体が倒れた。
原因究明は本来かかるべき以上に時間を要した。というのも、Javaには見た目上おかしなところは何ひとつなかったからだ。犯人はTRN-LIMITという名の変数だった。翻訳ツールはこれを通常の数値と解釈し、標準の整数型を割り当てた。だがTRN-LIMITは、ツールが見ていた場所には定義されていなかった。それはコピーブック——共有ヘッダーファイル——のなかで宣言されており、実行チェーンの数千行も前に取り込まれていた。そしてそのコピーブックにはREDEFINES句が含まれていた。これは、まったく別の場所で設定されたフラグに応じて、同じメモリ領域をまったく異なる二つのデータ型として読ませることのできるCOBOLの構文だ。メインフレーム上では、そのアドレスにはパック10進数が格納されていた。新しいJavaコードはデータベースの列に破損したバイナリを書き込み、元帳の参照整合性が崩れた。
コードは構文的には完璧無欠だった。失敗は文脈的なものだった。ツールは、その視野の外に存在する依存関係を見落としていた——そしてレガシーCOBOLのモダナイゼーションでは、資金が消えるのは、ほぼ常にこのパターンだ。
モダナイゼーションのプロジェクトが息絶えるのは、たいてい目に見えるコードのせいではない。ツールに見えなかったコードのせいで死ぬのだ。
これは、より優れた翻訳こそが答えだと信じるのをやめた理由と、その代わりに私たちがVeriprajnaで築き上げたものについての物語だ。
なぜ「COBOLを貼り付ければJavaが返ってくる」は、いつもデモで映えるのか?
この二年のあいだにメインフレーム・モダナイゼーションの会議に一度でも出席したことがあれば、こんな売り文句を耳にしたはずだ——COBOLを貼り付ければ、Javaが返ってくる。これが魅力的なのは、デモが必ずうまくいくからだ。誰かがこぎれいな200行のプログラムを放り込むと、モデルはクリーンで慣用的なJavaを返し、部屋にいる全員がほっと息をつく。ようやく、と。
私もしばらくは信じていた。私のチームが最初にこれに取り組んだとき、私たちは当然のことをした——翻訳をより良くしようとしたのだ。私たちはモデルにより多くの文脈を与え、COBOL特有の癖に合わせて調整し、出力品質をベンチマークした。この目的のために特別に作られたXMainframeというファインチューニング済みのオープンモデルさえあり、COBOLタスクでは汎用のコードモデルより約30%高いスコアを出す。翻訳はよりクリーンになった。Javaはより読みやすくなった。
それでもUATでは壊れ続けた。何度も何度も、まさにあの電信送金プログラムを沈めたのと同じ種類の隠れた依存関係で。私たちが磨いていたのは間違った対象だったと悟ったのは、その月のことだった。翻訳の品質などボトルネックではまるでなかった。コンパイルが通るコードは簡単な部分だ。難しいのは、ツールに見えないコードのほうだ。
これにまつわる数字は残酷なほど一貫している。メインフレーム・モダナイゼーションのプロジェクトの70~80%が目標を達成できない。70%が遅延するのではない——70%が失敗するのだ。よくある診断は、過小評価されたテストや雑なデータ移行を責める。それらは確かに現実の問題だ。だがそのほぼすべての根底には、私が今しがた目の当たりにしたのと同じ根本原因がある。ツールはコードベースを、変換すべきテキストとして扱う。それが実際には、理解すべきトポロジーであるにもかかわらず。
「COBOLを貼り付ければJavaが返ってくる」に見えないもの
文脈的な盲点を探し始めると、それはいたるところに見えてくる。私たちを最も頻繁に打ち砕いた3つのパターンがあり、そのいずれも、翻訳ツールが見つめているソースファイルには映っていない。
すでに述べたコピーブックの問題から始めよう。一つのCOBOLプログラムが40を超えるコピーブックを参照することもあり、しかもそれらのコピーブックは、さらに他のコピーブックを取り込む。そのため、ある変数の本当の定義が、取り込みの連鎖の何階層も奥に潜んでいることがある。テキストベースのツールは目の前にある文を読み、型を推測する。だがパック10進数のフィールドでは、その推測が知らぬ間に誤っていることを、そのツールは知る術がない。
次に、演算の問題がある。COBOLのCOMP-3パック10進数には、Javaにネイティブな相当物が存在しない。うっかりdoubleを使えば、金を動かすシステムに浮動小数点の丸めを持ち込んだことになる。正しいツールであるBigDecimalでさえ、デフォルトではCOBOLと一致しない——その丸めモードを明示的にHALF_EVENに固定し、COBOLのROUNDED句を再現しなければならない。これを誤れば、1トランザクションあたり1ペニーずつずれる。その1ペニーは数百万件のトランザクションにわたって積み重なり、数週間後、照合レポートが誰にも説明できない差異を検出する。
ほぼ誰もが忘れているパターンこそ、実際に本番を停止させるものだ。あなたのCOBOLは、それ単体では動かない。スケジューラ——CA-7やTWS——が、2千から5千のバッチジョブをオーケストレーションし、それらのあいだに依存関係の連鎖が織り込まれている。ジョブAが午前1時にデータセットを書き込み、それをジョブBが午前2時に読み込む。COBOLのすべての行を完璧に移行してもなお、真夜中に銀行を停止させることがある。誰もジョブネットワークをマッピングしなかったからだ。本番の依存グラフは、ソースコードのなかには決して存在しなかった。それはJCLのなかにあった。
午前2時に本番を壊すジョブは、あなたが見ていたジョブでは決してない。
私がトポロジーと言うのは、こういうことだ。あなたのビジネスを実際に動かしている成果物は、関係性のウェブ——プログラム、コピーブック、データセット、スケジュールされたジョブ、DB2テーブル、CICSトランザクション——であり、COBOLのソースは、そのなかの一本の糸にすぎない。
なぜ私は翻訳ツールを信じるのをやめ、地図を描き始めたのか
私たちにとっての転機は、地図こそがまさに製品なのだと決めたことだった。
一行でも翻訳する前に、私たちはコードベース全体の知識グラフを構築する——あらゆるプログラム、あらゆるコピーブックのエッジ、あらゆるJCL依存関係、あらゆるデータセットの受け渡し、あらゆるDB2の接点を——そして、ソースファイルが隠している推移的な関係を解決する。一つのプログラムが40を超えるコピーブックのエッジを持ち、そのうちの一つがREDEFINESを二つ先のモジュールに抱えていると分かれば、あのTRN-LIMITという惨事はそもそも起こらない。Javaの文字を一つでも打ち込む前に、そのフィールドがパック10進数だと分かっていたのだから。
これが業界の他社が売っているものとなぜ違うのか、正確に述べておきたい。この分野は混み合っており、その大半は、自らが解決する部分については本当に優れているからだ。
IBMのwatsonx Code Assistant for Zは、最も手強い既存プレイヤーだ——オーケストレーション、アーキテクチャ、コードの各エージェントを備えたエージェント型システムで、COBOLからJavaへの変換はもちろん、PL/IやIMSまで扱い、CPU消費をコピーブックの奥深くまで分析する。だがそれは、z/OS上で動作し、IBMのADDIツールに依存する200万ドル超のコミットメントでもあり、それがひそかにあなたをメインフレームに縛りつける——しかも、まさにそこから解放してくれるはずの移行のさなかに。それは振る舞いの等価性テストを行わず、あなたのJCLジョブネットワークをマッピングもしない。
次に、市場全体を作り変えた瞬間がある。2026年2月、AnthropicはClaude Code向けのCOBOLモダナイゼーションのプレイブックを公開した。IBMの株価は発表当日に13.2%下落し、3月には1億ドル規模のパートナーネットワークがこれに続いた。Claude Codeは、発見、ドキュメント化、そして見慣れないコードの読解に優れており——初期フェーズでは本当に役立つ。だがそれは汎用ツールだ。推移的な依存関係を解決するための組み込みの知識グラフは持たず、JCLのスケジューリング、振る舞いの等価性、あるいは規制下の銀行が生成しなければならない監査証跡を解決するふりもしない。
MicrosoftのAzure移行ファクトリーはJava Quarkusを標的とし、あなたのターゲットプラットフォームをAzureに縛りつける。大手システムインテグレーター——特許取得済みの変換エンジンを持つDXC、MasterCraftを擁するTCS、CobaltのInfosys、Accenture——は、50万ドルから500万ドル超の案件を手がけ、ベンダーのツールを導入するのであって、あなたのシステムについての知見を構築するわけではない。Accentureは、およそ7億4,990万ドルを投じ5年を要したオーストラリア・コモンウェルス銀行の基幹システム移行を主導した。そして、しばしば出発点として売り込まれるMicro FocusのVisual COBOLは、そもそもモダナイゼーションですらない——リホスティングだ。あなたのCOBOLは相変わらずCOBOLのまま、ただ新しいランタイム上に載るだけだ。技術的負債も人材の問題も、あなたが置き去りにしたその場所にそっくり残っている。
これらのどれもが、実際に何かをやってのける。だが、そのどれ一つとしてやらないことがある。完全な依存トポロジー——JCL、CICS、DB2、コピーブック、そのすべて——を、まず最初に、いかなるターゲットプラットフォームからも独立して構築し、その地図を、他のすべてが立脚する土台として扱うことだ。
ほとんどのベンダーは、より優れた翻訳ツールを売りつける。だが失敗する部分は、翻訳では決してなかった。
誰にも止められない時計
ここからが、これを工学の問題から緊急事態へと変える部分だ。
これらのシステムを理解している人々が去りつつある。米国のCOBOL開発者の平均年齢はおよそ55歳だ。その労働力のおよそ10%が毎年引退していき、大学の85%は1990年代にCOBOLをカリキュラムから外したため、後を継ぐ者はほとんどいない。いまや組織の60%が、熟練したCOBOL開発者を見つけることが最大のモダナイゼーション課題だと述べている——そして、これらのスタックをいまだに知る開発者の58%が、そのせいで辞めることを検討していると言う。
私はこの、いまも私を悩ませる場面に立ち会ったことがある。バッチウィンドウを本当に理解していたただ一人の人物の退職パーティーだ。誰もが笑顔で、ケーキがあり、そして私の頭のどこか奥で、こう囁く声がする——あの知識はたった今ドアの外へ歩き去った、そしてそれはどこにも書き留められていない、と。知識グラフとは、とりわけ、そのパーティーが開かれる前に、その人の頭のなかにあるものを捉える手段だ——依存関係の地図を、それを記憶していた人々よりも長く生き延びさせるための。
そして賭け金は、小さくも抽象的でもない。いまなお約2,200億行のCOBOLが現役の本番環境で動いている。それはATM取引の95%を処理し、1日におよそ3兆ドルを決済する。銀行システムの43%がその上に築かれている。米国の技術的負債は推定1兆5,200億ドルにのぼり、平均的な企業はレガシーの非効率に年間およそ3億7,000万ドルを費やしている。金融サービス企業に至っては、IT予算の70~75%を、ただ古いシステムを生き長らえさせるためだけに使っている。移行を正しくやり遂げたチームは、114~225%のリターンと年間およそ2,500万ドルの節減を報告している——だがその恩恵は、失敗しなかった移行の向こう側にしか存在しない。これは、何もしないことこそが高くつく選択肢となる、稀なモダナイゼーションなのだ。
新しいAIツールが、これをただ解決してくれるのでは?
これは私が最もよく受ける質問であり、もっともな問いだ。とりわけ、Anthropicの発表によって、まるで問題がたった今解決したと宣言されたかのように見えたあとでは。
私の正直な答えはこうだ。新しいツールは発見フェーズを劇的に速くした。それは本物の進歩であり——私自身も使っている。だが、エージェント型AIがCOBOLを読むのに長けてきたところで、実際にプロジェクトを殺すものは変わらない。Gartnerは、2026年までにエンタープライズアプリの40%がタスク特化型のAIエージェントを組み込むと予想している。だが、より多くのエージェントがより速くコードを翻訳しても、それらがそろって同じJCL依存関係に対して盲目であれば、何の助けにもならない。間違った問題に対する速さは、UATにより速くたどり着いてそこで失敗するための、より速い道にすぎない。
もう一つよく受ける質問は規制についてであり、これは中堅銀行が過小評価しがちなものだ。EUのデジタルオペレーショナルレジリエンス法——DORA——は2025年1月に施行され、レガシーシステムがそもそも通過するようには設計されていなかった、オペレーショナルレジリエンスと脅威主導型のペネトレーションテストを要求する。FFIECやOCCの米国の検査官は、老朽化したインフラを現在進行形のコンプライアンス上の欠陥として扱い、10年を超えるシステムは侵害の確率がおよそ3倍高い。新しいシステムが古いシステムとまったく同一に振る舞うことを証明する監査証跡を生成できない移行は、モダナイゼーションではない——それは、より良い構文をまとった新たな負債だ。
だからこそ、振る舞いの等価性テストは地図と同じくらい重要なのだ。この手法は、説明するのは容易だが、うまくやるのは難しい。レガシーシステムから実際の入力と出力を——ゴールデンデータセットを——捕捉し、振る舞いが一致するまで、エッジケースの一つひとつに至るまで、それを新しいシステムに対して再生する。数十年にわたって蓄積されたそれらのエッジケースは、しばしば、他のどこにも存在しない規制ロジックを符号化している——仕様書にもなく、人の頭のなかにもなく、ただ稼働中のコードのなかにだけある。私はこれが、銀行よりも保険会社をより手ひどく噛むのを見てきた。1998年の保険証券の裏書きにしか発動しない料率算定ルール、その丸めを存命の誰も説明できないのに、あらゆる監査が依存している支払備金の計算。それらを黙って失えば、どれが重要だったのかは、規制当局が尋ねてくるその日に思い知ることになる。
どのレンガを最初に抜くか?
ひとたび地図を手にすれば、それはどんな翻訳ツールにも言えないことを教えてくれる。どこから始めるのが安全か、を。
いまや主流の戦略は——それも正当な理由から——ストラングラーフィグ(絞め殺しのイチジク)だ。ビッグバン方式の書き換えの代わりに、一度に一つの機能を切り出し、旧と新を並行して走らせ、新しい部品が信頼を勝ち取るまで、レガシーシステムを稼働中のフォールバックとして残しておく。だが、ストラングラーフィグを推奨するどのベンダーも、最も難しい問いを省いている——どのモジュールを最初に絞め殺すのか?深く結合したモジュールを選べば、余計な手数をかけてビッグバンのリスクを作り直しただけになる。
知識グラフは、それに直接答える。結合度が最も低いモジュール——流入する依存関係が最も少ないもの——を浮かび上がらせ、危険な中核部に手を触れる前に、システムの実在する一部を切り出し、アプローチを実証し、組織的な自信を築けるようにする。地図は、単なるTRN-LIMITの失敗に対する保険ではない。それは順序づけの計画そのものだ。
私たちはこのすべてを——依存関係の知識グラフ、ストラングラーフィグの順序づけ、振る舞いの等価性を検証するハーネスを、いかなるターゲットプラットフォームからも意図的に独立させて——VeriprajnaのレガシーCOBOLモダナイゼーション部門に組み込んだ。狙いはまっすぐに、200万ドルを下限とする既存プレイヤーや七桁のSIが、相手にする価値もないほど小さいと見なす中堅の銀行や保険会社に向けられている。
私が正直に認めること
テクノロジーがすべてを解決するふりをするつもりはない。というのも、私が見てきた最も高くついた失敗は、まったく技術的なものではなかったからだ。
どんなツールも——私たちのものを含めて——組織的な合意形成を成し遂げたり、何年分もの不良データを片付けたり、二百人の開発者に働き方を変えるよう説得する政治的な戦いに勝ったりはしない。この市場が2026年の約90億ドルから、10年代の終わりまでにその倍へと成長すると予測されているのは、まさに支出の多くが、コンパイラではなく、人と組織の層に向かうからだ。そして、オープンソースであれ商用であれ、この世のどんなパーサーも、IBM Enterprise COBOLのあらゆる構文を完璧にはカバーしない——1985年以前のALTER文、最も深いREDEFINESを。そうでないと言う者は誰であれ、その隙間をあなたに売りつけているのだ。テクノロジーは必要だ。だがそれが十分だったことは一度もない。
だが、テクノロジーが確かに所有できる部分は、それを完全に所有しなければならない。移行が数百万ドルを焼き尽くしながら何も生み出さない理由は、誰かが下手なJavaを書いたからであることはめったにない。それは、実際には一度も地図にしていないシステムを翻訳したからだ——ウェブの糸を変換しているあいだ、そのウェブ自体は、それが裂けるその夜まで見えないままだった。
まず地図を描くことだ。それを書いた人々よりも長く生き延びたシステムは、見落とされた依存関係を許してはくれない。そして、何が何につながっているのかを見て取れるようになる前に、この仕事が安全であるバージョンなど存在しない。私たちはそれを、そこにあると誰も知らなかったたった一つのパック10進数のフィールドによって崩された元帳から学んだ。それらのフィールドが、あなたを見つける前に、あなたがそれらを見つけ出すことだ。
