日本の「最大12兆円」レガシー警告は、COBOL人材不足の話ではない。文字コードの話だ。

誰もが語る「崖」は、予算の話になっている

日本の「2025年の崖」は、経済産業省が2018年の「DXレポート」で最初にこの言葉を使って以来、日本におけるレガシーシステムリスクの基準点であり続けている。老朽化した基幹システムを刷新しなければ、2025年から2030年の間に最大で年間12兆円の経済損失が生じ得るという試算が示された(ict-miraiz、c3index)。それから7年が経ったいまも、この警告は古びていない。2025年に実施されたフォローアップ調査では、「2025年の崖を完全に乗り越えられた」と回答した企業はわずか7%にとどまり、約4割の企業がいまだに深刻な未解決課題を抱えていると回答している(ict-miraiz)。

この数字をめぐる論調の大半は、想定どおりのテーマに集中している。COBOL技術者の引退、誰も完全に文書化していないシステムの保守コストの膨張、一括置き換え(リップ・アンド・リプレイス)の切り替えに伴う運用リスク——といった話だ。それに比べてはるかに注目されていない失敗パターンがある。それは切り替え当日を待たずに発生する問題であり、文字の符号化方式が異なる2つのシステムが「1バイトが何を意味するか」について合意しなければならない、まさにその瞬間からデータの中に潜んでいる。

誰も予算化していない罠

IBM自身のモダナイゼーション向けガイダンスは、これをレガシー刷新プロジェクトにおける10の既知の失敗パターンの1つとして明示的に取り上げている。「文字コード・属性の罠」は、IBMが公開している「モダナイゼーション10の罠」の中で独立した項目として扱われている(IBM)。それは特殊な問題だからではなく、「解決済みに見えて実は解決していない」という性質の問題だからだ。

そのメカニズムはこうだ。1964年のIBM System/360以降に構築されたメインフレームシステムの多くはEBCDICを主体として使用しており、EBCDICと実際に現代のシステム環境で使われているShift-JISやUnicodeとは、基本的な照合順序(コレーション)についてすら一致しない。昇順に並べた場合、EBCDICでは英字が数字より先に並ぶが、Shift-JISやUnicodeでは数字が英字より先に並ぶ(日立ITPFドキュメント)。30年間「正しく動いてきた」COBOLのソート処理やORDER BY句が、同じロジックを再エンコードされたデータに対して実行した瞬間、エラーも例外ログも出さないまま、レコードの並び順を静かに入れ替えてしまう——しかも、既存の回帰テストスイートはそもそもそれを検知するようには書かれていない。

外字(ユーザー定義文字)がこの問題をさらに複雑にする。カスタム登録された外字を使用している環境から移行する場合、移行先の環境でその外字を再作成する必要があり、そもそも何文字まで登録できるかは、どの文字コードを採用するかによって変わってくる(日立ITPFドキュメント)。これには企業固有の部品番号に使われる外字や、金融機関特有の外字も含まれる。この互換性問題は決して珍しいものではなく、Oracleは移行後のアプリケーションをこの不一致に合わせて書き直さずに済むよう、EBCDICのバイナリ照合順序をエミュレートする専用機能を提供している(Oracleドキュメント)。主要ベンダーがこれを一度きりのファイル変換では静かに解決できない、独立した恒常的な互換性課題として扱っていることの表れだ。

移行スクリプトの問題ではなく、パーサー本体の問題

一般的な対処法は、データを読み込む処理の手前に文字コード変換ステップを挟み込むというものだ。エクスポートしたデータを変換ツールに通したあと、ソート比較や固定長フィールドの境界、DBCSの先行・後続バイト判定といった下流のロジックが、変換後のコピーに対しても元データと同じように振る舞ってくれることを期待する、という形になる。保存側と読み取り側で符号化方式の前提が一致していない場合、結果として起きるのは文字化け(モジバケ)だ。さらに厄介なのは、不一致が文字化けという分かりやすい形で現れず、単に値が静かに間違っているだけというケースだ。

Legacy Dragonは、パースするCOBOL・JCL・PL/I・VB6・VB.NET・PowerBuilder・Assembly・SQL/DB2・CICS・REXXという10のソース言語に加えて、Shift-JIS・EBCDIC・DBCSをネイティブに読み取る。これは意図的な設計上の配置だ。文字コードの処理は、Legacy Dragonがファイルを目にする前に走る前処理スクリプトの中ではなく、ASTと依存関係グラフを構築するパーサー自体の内部に置かれている。事前に変換されたコピーから構築されたグラフは、その変換ステップが間違えた内容をそのまま引き継いでしまう。一方、ソースを本来の符号化方式のままパースして構築されたグラフには、そもそもそのクラスの誤りを引き継ぐ余地がない——これは、まさに12兆円という試算がリスクの所在として想定している場所で重要になる。誰もが暗記している人材引退のスライドの中にではなく、EBCDICメインフレームの中核システムとShift-JIS時代の周辺システムが何十年も共存してきた現場の中に、その所在はある。

符号化の忠実性を解決するだけで、企業が経産省の「崖」から一気に脱却できるという主張ではない。人材の引退やシステムの老朽化リスクは、それ自体が現実的かつ別個の問題として存在する。ただし言えるのは、多くのモダナイゼーションプロジェクトがロジックに手を付ける前に実施する評価フェーズは、もっと小さく、しかも検証可能な問いから始めることができるということだ。すなわち——いま構築しているグラフは、このデータが実際にどう符号化されているかをすでに正しく理解しているのか、それとも検証していない変換ステップを、ただ信用しているだけなのか。

---

符号化を後から推測するのではなく、パーサーの段階であらかじめ処理しておくとどうなるか、興味があればdragon.aitytech.comでLegacy Dragonを確認してほしい。ASTグラフが影響分析を第一の目的として設計されている理由もあわせて読めるほか、[email protected]まで問い合わせることもできる。