AI翻訳されたCOBOLがデータベースをクラッシュさせる理由

問題点

ある大手銀行は、30年にわたるCOBOLのコードベースをJavaへ書き換えるようAIに依頼しました。AIは構文を完璧に翻訳しました。コードはコンパイルされ、単体テストも合格しました。その後、最初のトランザクションでデータベースがクラッシュしました。

この失敗の原因は、出来の悪いコードとは何の関係もありませんでした。Javaは文法的にも非の打ちどころがないものでした。問題は隠れた依存関係にありました。それはTRN-LIMITという変数で、共有ヘッダーファイル内に定義されており、AIが実際に翻訳したコードからは数千行も離れた場所にありました。そのヘッダーファイルにはREDEFINES句が含まれていました。これはCOBOLの機能で、まったく別のモジュールで設定されたフラグに応じて、同一のメモリアドレスが2種類の異なるデータ型を持つことを可能にするものです。AIはこれらを一切見ていません。TRN-LIMITを単純な数値として扱ったのです。実際には、これはパック10進数でした。この不一致により、Javaアプリケーションは破損したバイナリデータをデータベースに書き込み、参照整合性違反を引き起こしました。

これは例外的なケースではありません。調査によれば、レガシーモダナイゼーションプロジェクトの70%から80%は目標を達成できずに失敗しています。あなたの組織でも、従業員のほとんどよりも古いコード上で基幹システムが稼働しているおそれが高いでしょう。移行を計画している段階であれ、すでに移行中であれ、この失敗パターンは深刻に受け止めるべきものです。AIはタイプミスをしたのではありません。見えない関係を見逃したのです。これは根本的に性質の異なるリスクであり、現在のツールのほとんどはこれに対する答えを持っていません。

なぜこれがあなたのビジネスにとって重要なのか

ここでの財務的エクスポージャーは膨大であり、貴社の貸借対照表のすべての行に及んでいます。

米国だけでも、技術的負債は1兆5,200億ドルに達すると推定されています。レガシーシステムを稼働させている組織であれば、今まさにその負担の一端を抱えているのです。**連邦IT予算の約80%が運用と保守に充てられ、新しいことに使えるのはわずか20%にとどまります。銀行セクターの露出はとりわけ深刻です。銀行システムの43%は依然としてCOBOL上で稼働しており、それらのシステムはATM取引全体の95%**を処理しています。

これは、あなたのリスクプロファイルにとって次のような意味を持ちます:

• **セキュリティへの露出が3倍になります。**稼働10年以上のシステムは、モダンなアプリケーションと比べて統計的にデータ侵害を受ける可能性が3倍高くなります。モダナイゼーションを1四半期遅らせるごとに、攻撃対象領域は拡大していきます。
• **コンプライアンス要件は強化されています。**GDPRやDORAといった規制は、リアルタイム報告とデータプライバシー管理を求めます。レガシーシステムはこれらの要件を念頭に設計されていません。適応できない状態は、規制当局に気づかれるコンプライアンスリスクになりつつあります。
• **専門人材が去っていきます。**これらのシステムを書いた開発者たちは引退しつつあります。開発者の58%が、レガシーな技術スタックが原因で退職を考えていると回答しています。組織の暗黙知が会社から歩み去るとき、保守コストはさらに増加します。
• **失敗した移行は数百万ドル単位の損失を生みます。**失敗率は70〜80%。確率はあなたに不利です。失敗した移行の代償はプロジェクト予算にとどまりません。技術リーダーシップへの信頼を損ない、各チームが待ち望む業務能力の提供を遅らせます。

取締役会はデジタルトランスフォーメーションを求めています。規制当局はモダンな統制を求めています。予算はシステムの維持だけですでに逼迫しています。「静かに失敗する移行」に付き合っている余裕はありません。

内部で実際に起きていること

標準的なAIがなぜここで失敗するのかを理解するために、コードベースを都市にたとえてみてください。すべての関数、変数、データベーステーブルは建物です。それらをつなぐ結び付き――どの関数がどれを呼び出し、どの変数がどの計算に値を供給するか――が道路です。

今、誰かに市内の全建物の電話帳を渡して、交通網を再設計するよう頼んだと想像してください。相手が持っているのは名前と住所だけで、地図はありません。どの道路がどの建物同士を結んでいるのかは分かりません。標準的なAIコーディングツールは、あなたのコードに対してまさにこれを行っています。テキストは読めても、構造は見えていないのです。

ここで問題となる技術的な失敗は、“Lost in the Middle”効果と呼ばれるものです。コーディングアシスタントなどのツールの基盤である大規模言語モデルは、注意機構を使ってテキストを処理します。研究により、これらのモデルは長い入力の冒頭と末尾の情報に対しては強い想起能力を示すものの、途中に埋もれた情報に対しては性能が急激に低下することが実証されています。数千行に及び外部ファイルを参照するCOBOLプログラムでは、重要な変数定義がまさにその盲点に位置していることがよくあります。

AIは定義を見逃しても、立ち止まって質問しません。推測します。統計的にもっともらしいけれども事実としては誤りのあるもので隙間を埋めるのです。AI用語では、これはハルシネーションと呼ばれます。あなたの銀行システムでは、AIが実際はパック10進数である変数を整数だと想定することを意味します。この一つの誤った想定だけで、財務データを破損させ、データベースの整合性を壊し、トランザクションシステムを停止させる可能性があります。コードはコンパイルされます。テストは合格します。そして本番環境が故障するのです。

何が機能し、何が機能しないのか

まずは、あなたのチームがすでに試みたか、検討したであろう各アプローチと、それぞれがなぜ不十分なのかから見ていきましょう。

**リフト・アンド・シフト（再ホスティング）：**コンパイル済みのアプリケーションをクラウドエミュレーターへ移動します。ホスティング費用は変わりますが、絡み合ったレガシーコードの一行残らずそのまま残ります。技術的負債をすべて新しい環境に持ち込み、クラウドの柔軟性は何も得られません。

**手動での書き直し：**開発者を雇って、すべてをJavaで手作業により書き直してもらいます。これは途方もなく時間がかかり、天文学的な費用がかかり、しかもCOBOLとモダンアーキテクチャの双方を理解する人材の確保にかかっています。COBOLの専門家が引退していく中、この方法は年々困難になっています。

**AIラッパーツール：**商用のAIコーディングアシスタントをコードベースに向けます。構文は素早く翻訳できます。しかし銀行の失敗事例が示すように、ファイル間の依存関係を見逃し、変数定義をハルシネーションで埋め、一見正しく見えるのに動作は誤っているコードを生み出します。

実際に機能するのは、コードをテキストファイルの山ではなく相互接続されたシステムとして扱う、グラフベースのアプローチです:

1. **テキストではなく構造を解析する。**コードを恣意的なテキストチャンクに刻む代わりに、すべてのファイルを論理構造を表す木構造に解析します。すべての変数、関数、制御フロー分岐がそこに含まれます。これにより、AIはコードの境界を尊重します。関数はテキストの無作為な断片ではなく、完全な論理単位として扱われるのです。

2. **すべての関係のマップを作成する。**コードベース内のあらゆる接続――どのモジュールがどのサブルーチンを呼び出すか、どのファイルがどの変数を定義するか、どの関数がどのデータベーステーブルを更新するか――を抽出し、ナレッジグラフに格納します。AIが支払い処理関数を翻訳する際には、“payment”に言及するテキストを掴むだけではありません。実際の依存チェーンをたどって、すべての変数定義、すべての共有ヘッダー、すべての下流への影響を取り込みます。これこそがVeriprajnaの呼ぶ リポジトリ認識型ナレッジグラフであり、“Lost in the Middle”問題を直接解決します。

3. **すべての出力をマップに対して検証する。**AIがJavaコードを生成した後、サンドボックス内でコンパイルします。コンパイラがエラー（存在しない変数など）を出した場合、システムはグラフに問い合わせ、依存関係を特定し、コードを再生成します。このコンパイル・修正ループは自動で回ります。開発者がレビューするのは、AIの生の推測ではなく、検証済みの出力です。

コンプライアンス部門と監査部門にとって最も重要な利点は、AIのすべての意思決定が追跡可能だという点です。ナレッジグラフは、AIがなぜ特定のライブラリをインポートし、なぜ変数をそのように定義したのかを正確に記録します。ブラックボックスではなく、引用チェーンが手に入ります。監査担当者は、生成されたコードの一行一行について論理の道筋を確認できます。

このアプローチは、移行開始前の無駄も排除します。ナレッジグラフはデッドコード――システム内の何からも呼び出されていない関数――を特定します。デッドコードの除去は通常コードベースを20〜30%削減し、移行コストの低減と最終システムの健全化をもたらします。

組織にとって、とりわけ 金融サービス業界 のように厳しい規制の監視下にある場合は、この種の透明性は任意のものではありません。また、モダナイゼーションにシステム横断的なデータリネージの追跡が必要であれば、Veriprajnaの データ来歴とトレーサビリティ 機能が、同じグラフベースのアプローチをデータパイプライン全体に拡張します。

詳細は 技術分析の全文を読む ことでご確認いただけます。または、 インタラクティブ版を体験する ことで、ナレッジグラフが実務でどのように機能するかを視覚的にご覧いただけます。