理解のアーキテクチャ： エンタープライズ・レガシーにおける構文を超えた モダナイゼーション

エグゼクティブ要約

エンタープライズ・レガシーシステムのモダナイゼーション——とりわけメインフレームの アーキテクチャからクラウドネイティブ環境への移行——は、決定的な転換点に達した 2020年代半ばにおいて。何十年ものあいだ、金融および政府セクターは次の 逆説的なパラダイムのもとで運営されてきた。モダナイズせよという要請は存亡にかかわる一方、そうした 取り組みの失敗率は壊滅的な高さのままで、70%から80%のあいだを推移している。 1 近年の登場は 大規模言語モデル（LLM）が革命を約束し、魅惑的な可能性を提示した 自動コード翻訳という可能性である。しかし初期の導入サイクルは、重大かつシステミックな 欠陥を明らかにした。標準的な生成AIアプローチを、複雑でモノリシックな リポジトリに適用したときの欠陥である。

いまわれわれは、新たなカテゴリーのエンジニアリング失敗の出現を目撃している。典型例は 大手銀行が三十年分の COBOLを商用コーディングアシスタントでJavaへ書き直そうとした、伝説めいていながら極めて現実的なシナリオである。そのAIは 洗練された局所翻訳器として機能し、構文は完璧に変換した。しかし結果の アプリケーションはデプロイ時にデータベースをクラッシュさせた。失敗は構文ではなく、 文脈の失敗であった。AIは「Lost in the Middle」症候群とテキストベースの ソフトウェア理解に制約され、実行ブロックの何千行も前に定義された 重要な変数依存を見逃した。 3

本ホワイトペーパーはVeriprajnaが提示するものであり、支配的な「LLMラッパー」 アプローチ——コードをテキストトークンの線形系列として扱うもの——は根本的に不適であると論じる エンタープライズ・モダナイゼーションの非線形な複雑さに対して。ソフトウェアはテキストではない。それはグラフである。それは 論理依存、データフロー、状態変化からなる高度に構造化されたシステムであり、 多次元の位相空間に存在する。 5

われわれは、前進可能な唯一の道はリポジトリ認識型知識の採用であると主張する グラフ 。確率的なテキスト予測からグラフベースの決定論的推論へと転換することで、 数百万行のコードにわたる変数依存を写像し、「Lost in the Middle」現象を解消し、モダナイゼーションを危険な賭けから 数学的に検証可能なエンジニアリング過程へと変えることができる。 7 本文書は、技術的な 表層的な構文翻訳から、深い意味的・構造的変換への移行を概説する。

第1章：レガシーの静かな危機 インフラストラクチャ

1.1 モダナイゼーションの逆説

現在のデジタル経済において、グローバル商取引のインフラは危うく依存している 冷戦期に開発された技術に。それは衝撃的で、しばしば認められない現実である。すなわち、 2025年において、世界の金融、ヘルスケア、政府システムの相当多数は レガシーコードベース——COBOLのような言語で書かれたモノリシックアプリケーション——によって駆動されている。 PL/IおよびRPGは、とっくに主流のコンピュータサイエンス課程から脱落している。 これらのシステムは単に「古い」のではない。それらは世界経済の基盤岩であり、 しかも驚くべき速度で浸食されている。

統計は、この依存の陰鬱な姿を描く。Fortune 500企業で稼働するソフトウェアのおよそ70%は 二十年以上前に開発されたものである。 9 銀行セクターでは、 状況はさらに深刻である。銀行システムの43%はCOBOL上に構築されており、これらの システムはATM取引の95%を処理している。 1 われわれは事実上、現代の 即時決済経済を、インターネット以前のデジタル基盤の上で動かしている。

この現状を維持するコストは急騰している。技術的負債は累積し、 米国だけで推定$1.52 trillionに達している。 1 組織は「明かりを 点け続ける」循環に囚われ、連邦IT予算の80%が運用と保守に充てられ、残るのは わずか20%がイノベーション向けである。 9 この資源の流出は深刻なスキル不足によって増幅される。 これらのシステムを書いた世代の開発者が引退するにつれ、それらを維持するために必要な制度的知識は 消滅していく。 10

表1：レガシーシステムの経済的負担

指標 統計 出典
技術的負債コスト（米国） $1.52 Trillion 1
連邦IT保守
予算		 総支出の約80% 9
銀行の依存 ATM取引の95%
がCOBOL上		 1
データ侵害の確率 3倍高い（10年超の
システム）		 11
開発者離職 58%が離職を検討
レガシースタックのため		 1

このデータはシステミックな脆弱性を示している。モダナイゼーションの要請は単なる コスト削減ではない。それは生存の問題である。十年超のシステムは統計的に三倍 セキュリティ侵害を経験しやすい。現代アプリケーションと比較してである。 11 規制上の データプライバシーとリアルタイム報告の要件が厳格化するにつれ（例：GDPR、DORA）、適応できないという レガシーシステムの不能は、最高次のコンプライアンスリスクとなる。

1.2 「銀行失敗」の解剖

新たなアプローチの必要性を理解するには、われわれは次のシナリオを解剖しなければならない。それが AIモダナイゼーション失敗の「患者ゼロ」となったシナリオである。この事例研究は、次によって参照される Veriprajnaのリーダーシップによってであり、標準AIが失敗する具体的メカニズムを示している エンタープライズ環境において。

大手金融機関が、コアの取引処理システムを移行するプロジェクトを開始した IBMメインフレーム（COBOL/DB2）からクラウドネイティブなJavaマイクロサービス・アーキテクチャへ。その 銀行は人気のAIコーディングアシスタント——本質的には基盤を包むラッパー——を用いた モデル——をコード翻訳に用いた。

AIは、高額電信送金の処理を担うCOBOLプログラムを取り込んだ。その プログラムには、われわれがTRN-LIMITと呼ぶ変数を含む複雑なCOMPUTE文があった。 AIは構文を完璧に翻訳した。COMPUTE文をJavaの BigDecimal演算に変換した。コードはコンパイルされた。単体テスト——同一のAIが生成し、根拠としたのは 局所コードブロック——は合格した。

しかし、ユーザー受入テスト（UAT）環境へのデプロイ時、最初の 取引がデータベース整合性チェックをクラッシュさせた。

剖検： 変数TRN-LIMITは、AIが翻訳したソースファイル内では定義されていなかった。それは定義されていた COPYBOOK（共有ヘッダファイル）にあり、実行チェーンの何千行も前に取り込まれていた。 さらに重要なことに、そのCOPYBOOKにはREDEFINES句が含まれていた——COBOLの構文であり、 同一のメモリアドレスを、二つの異なるデータ型として解釈することを許す。依存するのは まったく別モジュールで立てられたフラグである。 テキストの「チャンク」で動作するAIは、TRN-LIMITを単純な数値フィールドと見た。見えなかったのは REDEFINES句である。それが別ファイルにあり、直近の コンテキストウィンドウに含まれていなかったからだ。変数の標準定義を「ハルシネーション」した。メインフレーム 環境では、そのメモリアドレスはパック十進数を保持していた。Java環境では、AIは それを標準整数として扱った。この不一致により、Javaアプリケーションは破損した バイナリデータをデータベース列へ書き込み、参照整合性の失敗を引き起こした。 4

失敗は構文ではなかった。Javaコードは構文的に完璧だった。失敗は 文脈的盲目であった。AIは「視野」の外に存在する依存を見逃し、 壊滅的な意味的乖離を招いた。

1.3 「リフトアンドシフト」対リファクタリングのジレンマ

業界のモダナイゼーション実績は惨憺たるものであり、次の導入以前からそうであった 生成AIの。研究によれば、70%から80%のデジタル変革および レガシーモダナイゼーションプロジェクトが目標を達成できていない。 2

伝統的に、組織は二項対立の選択に直面してきた。

1.​ 再ホスト（リフトアンドシフト）： コンパイル済みアプリケーションをクラウド上のエミュレータへ移す。これは 「スパゲッティコード」と負債を保存し、ホスティング請求書を変えるだけである。失敗するのは クラウドの俊敏性を解き放つことである。 14

2.​ 書き換え（リファクタ）： コードを現代言語で手作業で書き直す。これは 天文学的に高価で、遅く、危険である。文書化の欠如と「巨大な 泥団子」アーキテクチャのためであり、ビジネスロジックがデータアクセスと不可分に絡み合っている。 10

生成AIは「第三の道」——自動リファクタリング——を提供するはずだった。しかし、 「銀行失敗」は証明する。ソフトウェア位相のより深い理解なしには、AIは単に 欠陥コードの生成を加速するだけである。

第2章：確率的な失敗 翻訳

2.1 「ラッパー」経済とその限界

この高い賭け金の環境に「LLMラッパー」が参入した。即座の反応は ソフトウェアコンサルティング市場がGPT-4の公開に対して示したのは、次のように振る舞うツールの氾濫であった 開発者と基盤モデルのあいだの薄いソフトウェア層として。 15 これらのツールは約束する 「コードとチャットする」ことであり、開発者はCOBOLの段落を貼り付け、Javaの メソッドを受け取ることができる。

これらのラッパーはAI導入の参入障壁を下げる一方、根本的に欠陥がある 大規模システム再エンジニアリングに適用したときに。ラッパーは典型的にナイーブRAGに依拠する （検索拡張生成）。この過程で、システムはユーザクエリを受け取り、検索する ベクトルデータベースから、クエリと_テキスト的に類似した_コード断片を探し、それらを スニペットとしてLLMに文脈として供給する。 17

エンタープライズ文脈におけるこのアプローチの限界は深刻である。

1.​ 文脈的近視： ラッパーはコードをテキスト断片として見る。理解しないのは、 SECTION-Aで変更された変数ACCOUNT-BALANCEが、決定ロジックを駆動するという事実である 五千行離れたSECTION-Zにおいて。

2.​ 構文的成功、意味的失敗： 述べたとおり、LLMはJavaコードを生成でき、それは 完璧にコンパイルされるが、元のCOBOLの正確な実行時振る舞いを再現できない グローバルな状態変化を見逃したからである。 4

Veriprajnaは「薄いラッパー」哲学を拒否することで自らを区別する。われわれは主張する。深い AIソリューションはリポジトリの_構造_を理解しなければならず、ファイルの_テキスト_だけではなく。

2.2 「Lost in the Middle」症候群

標準AIがレガシーモダナイゼーションで失敗する理由を理解するには、われわれは理解しなければならない 大規模言語モデルの認知アーキテクチャを。これらのモデルは次に基づく Transformerアーキテクチャであり、「注意機構」を用いて重要度を重み付けする 入力テキストの異なる部分の。 18

現代のLLMは巨大なコンテキストウィンドウ（最大100万トークン）を誇るが、その能力は その文脈を効果的に_使う_ことは一様ではない。実証研究が示したのは 「Lost in the Middle」効果として知られる現象である。長い 情報系列を提示されると、LLMはU字型の性能曲線を示す。

●​ 初頭バイアス： 冒頭の情報を想起する精度が非常に高い プロンプトの。

●​ 近時バイアス： 末尾の情報を想起する精度が非常に高い。

●​ 谷： 中央に位置する情報では性能が大幅に劣化する。 3

モダナイゼーションプロジェクトでは、単一のCOBOLプログラムが何千行にも及ぶことがあり、しかも それ自体が何千行もあるコピーブック（依存）を参照することがある。もし 重要な変数の定義——たとえばMAX-TRANSACTION-LIMIT——がこの中央に現れると 巨大な文脈において、AIは統計的にそれを見落としやすい。 21

AIが変数定義を見落としても、止まらない。それは「ハルシネーション」する。仮定するのは 事実ではなく確率に基づく、その変数の既定型または値である。銀行システムでは、 変数が実際にはパック十進数であるのに整数だと仮定すると、丸め 誤差が生じ、金融データを破損しうる。 22

表2：標準LLMの認知的限界

現象 説明 モダナイゼーションへの影響
Lost in the Middle 劣化した注意が
長いプロンプトの中央で。3		 見逃された変数定義が
大きなファイルに埋もれている。
ハルシネーション もっともらしいが誤った事実の
捏造。22		 依存や論理を発明し、
文脈の隙間を埋める。
初頭／近時バイアス テキストの始端／終端への
焦点。20		 中核ビジネスロジックを無視する
手続きの中央に位置する
論理を。
確率的生成 確率的テキスト
予測。		 一貫性のないコード
生成。再実行すると
プロンプトは異なる
論理をもたらす。

2.3 「単語の袋」対「論理の木」

標準LLMおよびベクトルRAGシステムは、コードを主にトークン系列として処理する。 それらは意味的類似に依拠する——クエリ内の語が文書内の語と一致するかを確認する ベクトル空間において。 17

しかし、コードは自然言語ではない。自然言語では、「猫がマットの上に座った」は 五十ページ前の文からほぼ独立した意味を持つ。ソフトウェアでは、x = y + 1 はゼロの 意味しか持たない。xとyの定義、型、現在状態を知らなければ。これらの 定義は別ファイル、別モジュールに存在するかもしれず、あるいは親から継承される クラスから。 5

「ラッパー」AIが「支払いロジックをリファクタせよ」のようなクエリの文脈を取得するとき、取得しうるのは 「payment」という語を含む五つのコードチャンクである。見逃しやすいのは、次の名前のチャンクである GlobalVarDef.cblであり、支払いロジックが使う税率を定義している。そのファイルは一度も 「payment」という語に言及しないからである。

この断絶は、テキスト検索_と_構造的 _理解_のあいだの根本的ギャップを表す。このギャップを埋めるには、コードを文学として扱うのをやめ、扱い始めなければならない グラフとして。 23

第3章：ソフトウェアの物理学——

コードはグラフである

3.1 関係システムとしてのソフトウェア

Veriprajnaでは、ソフトウェアリポジトリは本質的に関係データベースであると認識する 論理の 。コードベース内のすべての実体——変数、関数、クラス、モジュール、データベース スキーマ——は、密な関係の網の中に存在する。

●​ 包含： ファイルはクラスを含み、クラスはメソッドを含み、メソッドは含む 変数宣言を。

●​ 継承： クラスBはクラスAからプロパティとメソッドを継承する。

●​ 呼び出し： メソッドXはメソッドYを呼び出す。

●​ データフロー： 変数Zは関数Qによって変更され、関数Rによって読み取られる。

これらの関係は、アプリケーションの「グラウンドトゥルース」を構成する。それらは確率的ではない。 それらは決定論的である。メソッドXがメソッドYを呼び出すなら、それは硬い事実であり、統計的な 尤度ではない。標準LLMは確率領域で動作する。レガシーを安全にモダナイズするには システムを、われわれはそれらの確率的生成能力を決定論的現実に錨で固定しなければならない コード構造の。 7

3.2 抽象構文木（AST）

この構造理解の基礎単位は**抽象構文木（AST）**である。 ASTは、ソースコードの抽象的な構文構造の木表現である。生の テキスト文字列とは異なり、ASTは言語の階層と文法規則を捉える。 24

たとえば、次のCOBOL文は COMPUTE INTEREST = PRINCIPAL * RATE 単なる五語ではない。ASTでは、それはAssignmentNodeであり、Target（Interest）と Expressionを持つ。ExpressionはMultiplicationNodeであり、LeftOperand（Principal）と RightOperand（Rate）を持つ。26 レガシーコードをASTへ解析することで、テキストの曖昧さを超える。われわれは プログラム的にあらゆる変数使用、あらゆる算術演算、あらゆる制御 フロー分岐を識別できる。これにより「ラウンドトリップ」エンジニアリングが可能になる——コードをASTへ変換し 再びコードへ戻してもデータ損失なし——構造分析が正確であることを保証する。 27

標準RAGで用いられる「テキストチャンキング」とは異なり——ファイルが盲目的に500トークンへ切断される 断片へ、しばしば関数を半分に分割する——AST解析は論理境界を尊重する コードの。関数は論理の離散単位として扱われ、テキストの無作為な区間ではない。 23

3.3 コールグラフと依存行列

ASTが単一ファイルの構造を表す一方、コールグラフは神経系を表す アプリケーション全体の。制御の流れを可視化し、どの段落または サブルーチンが他を呼び出すかを写像する。 29

レガシーCOBOLシステムでは、コールグラフは動的呼び出しやGOTO論理によってしばしば覆い隠される 「スパゲッティコード」を生む。静的テキスト分析では容易に解決できない。GOTO LABEL_Xが どこに着地するかを、LABEL_Xが動的または条件付きで定義されている場合。

厳密なコールグラフを構築することで、Veriprajnaは「デッドコード」（決して 呼び出されないコード）と「ゴッドクラス」（過度に結合したモジュール）を識別する。この分析は不可欠である モノリスをマイクロサービスへ分解するために。完全な呼び出し連鎖を知らなければ、われわれは サービスを安全に抽出できない。取り残す危険があるのは「ダングリング参照」であり、それは引き起こす 実行時失敗——冒頭の事例研究で銀行を苦しめたまさにそのシナリオである。 31

表3：構造分析対テキスト分析

機能 テキスト分析（標準
AI）		 構造分析
（Veriprajna）
分析単位 トークン／語 ノード（AST要素）
文脈境界 任意のトークン上限 論理スコープ
（関数／クラス）
依存解決 キーワード照合 グラフ走査
GOTO処理 テキスト文字列として扱う 制御フロー辺を写像
精度 確率的 決定論的

3.4 依存性注入と反転

現代のJavaおよびクラウドネイティブ・アーキテクチャは、依存性注入（DI）と 制御の反転（IoC）に大きく依拠する。レガシーCOBOLは逆に、ハードコードされた依存に依拠する およびグローバル状態に。一方から他方へ移るには、グラフ内のあらゆる依存を識別し、 それを「反転」する必要がある。

パラダイムを変えなければならない。「モジュールAがデータベースBへの接続をハードコードする」から 「モジュールAがデータベース接続をパラメータとして受け取る」へ。このアーキテクチャ転換は 不可能である。AIがそもそも依存を見えなければ。知識グラフは これらの依存を明示し、AIが必要なDIボイラープレートを生成できるようにする 自動的に、新システムがモジュール的でテスト可能であることを保証する。 4

第4章：Veriprajnaセマンティック フォージ

4.1 リポジトリ認識型知識 グラフのアーキテクチャ

「Lost in the Middle」症候群とテキストベース移行の脆さへの解決は リポジトリ認識型知識グラフである。これは統合グラフデータベースであり、結合するのは コードの静的構造（AST、コールグラフ）と、次の意味的意味である ビジネスロジック（文書、コメント、変数の意図）。 5

Veriprajnaは独自パイプラインを用いる。先端研究ではしばしば次と呼ばれる 「セマンティック・フォージ」であり、この知能を構築する。これは汎用ETL過程ではない。それは レガシーモダナイゼーション専用に構築されたエンジンである。 33

4.2 フェーズ1：Tree-sitterによる知的解析

われわれは堅牢なパーサ、主にTree-sitterを用い、レガシーコードベースを取り込む。この過程は 13以上の言語を支援する。COBOL、JCL、PL/I、Javaを含む。パーサは生成する リポジトリ内のすべてのファイルについてASTを。

決定的に、われわれはセマンティック・チャンキングを用いる。標準RAGパイプラインは「ナイーブ分割」を使う。 テキストを_n_トークンごとに切断する。これはしばしば関数シグネチャを本体から切り離し、あるいは 変数定義をその使用から切り離し、文脈を破壊する。セマンティック・チャンキングはASTを用いて 論理境界を識別する。コードをSECTION、PARAGRAPH、またはMETHODでチャンクし、 グラフのすべてのノードが完全で実行可能な論理単位を表すことを保証する。 23

4.3 フェーズ2：実体と関係の抽出

ASTが生成されると、セマンティック・フォージは実体と関係を抽出し、 グラフデータベース（例：Neo4j、Memgraph）を埋める。

●​ 実体： クラス、段落、変数、データベース表、APIエンドポイント。

●​ 関係：

○​ CALLS：段落を、それが呼び出すサブルーチンへ接続する。

○​ UPDATES_TABLE：論理ブロックを、それが変更するDB2表へ接続する。

○​ IMPORTS_COPYBOOK：ソースファイルをその依存へ接続する。

○​ DEFINES_VARIABLE：データ部を、それが作成する変数へ接続する。

このフェーズは静的テキストを動的位相へ変換する。いまグラフをクエリできる。 「CUSTOMER-IDフィールドを更新するすべての段落を見せよ。」このクエリは正確な 結果を即座に返す。grepやベクトル検索では不可能な技である。 14

4.4 フェーズ3：実体解決と統合

これが決定的な差別化点である。標準パーサはファイルAのACCT-NUMと ファイルBのACCT-NUMを二つの異なる文字列と見る。われわれのシステムは記号解決を行う。それは 両者が共有コピーブックの同一エントリを指すと判断する。これらを統合する グラフ内の単一の変数ノードへ。

さらに、われわれはクロスモーダル統合を行う。コードベースにPDFが含まれる場合 「User API」を記述する要件文書であり、コードにクラス名 UserAPIがあるとき、システムは埋め込みを計算して同一概念であると認識する。それは 文書ノードをコードノードと統合する。これにより_意図_（文書）が結びつく 実装（コード）と、AIに「なぜ」を「どのように」と並べて与える。 8

4.5 フェーズ4：推移閉包の計算

「銀行失敗」は推移的依存によって起きた。AはBに依存し、BはCに依存する。 AIはAを見たがCを見逃した。

Veriprajna知識グラフは推移閉包を計算する。システムが分析するとき モジュールAを、直接の近傍で止まらない。グラフを深く走査する（A -> B -> C） あらゆる変数の「真理の根」を識別するために。これにより、AIが生成するとき モジュールAのコードについて、モジュールCから正しい定義をインポートする。たとえモジュールCが 別ディレクトリまたは別リポジトリにあっても。 8

第5章：グラフ検索拡張 生成（GraphRAG）

5.1 ベクトルRAGの限界

ベクトル検索拡張生成（RAG）は、知識を追加するための業界標準である LLMへ。テキストをベクトル（数値表現）に変換し、類似ベクトルを見つける。 FAQのような非構造化テキストの照会には優れるが、コードには不十分である。

●​ 変数の改名： 開発者がAccountをAcctに改名すると、意味的類似は 低下する。論理が同一であっても。

●​ 論理対キーワード： 「利息計算」を検索しても実際の計算を見逃しうる。もし 関数がFNC-001と名付けられ、コメントがなければ。

●​ 断片化した文脈： ベクトルRAGはコサイン類似に基づき「チャンク」を取得する。取得しうるのは 単体テストとUIコメントであり、中核ビジネスロジックを見逃す。なぜなら 変数名がクエリ語と一致しないからである。 36

5.2 GraphRAGの優位

GraphRAGは知識グラフの構造で動作し、テキスト類似だけではなく。

1.​ アンカー識別： ユーザが「支払いロジックをリファクタせよ」と尋ねると、システムは用いる ベクトル検索をエントリポイント探索に（例：ProcessPayment段落）。

2.​ グラフ走査（拡張）： そこで止まらず、GraphRAGはグラフを走査する 辺を。引き込むのは

○​ CALLS辺でサブルーチンを見つける。

○​ READS辺で変数定義を見つける。

○​ INCLUDES辺でコピーブックを見つける。

3.​ 文脈構築： これらの接続された断片——テキスト的には非類似でも 論理的には不可分な——が、一貫したプロンプトへ組み立てられる。

この関連性拡張は、LLMが自己完結し実行可能なスライスを受け取ることを保証する 論理の。理解するのは計算の_テキスト_だけではなく、その_機構_である。 36

5.3 マルチホップ推論

研究は、GraphRAGがベクトルRAGを有意に上回ることを示す。次を要するタスクにおいて 「マルチホップ推論」——数ステップ離れた事実を接続すること。ソフトウェアでは、 ほぼすべてのバグはマルチホップ推論の失敗である（例：AがBを呼び、BがXを変え、CがXを読む。もし Aが変われば、Cは壊れるか？）。

GraphRAGはAIに複雑な影響分析の問いに答えさせる。「利息を変えれば モジュールAの利率論理が、モジュールZのどの報告画面に影響するか？」ベクトルRAGは これに答えられない。モジュールAとモジュールZはテキスト類似を共有せず、結びついているのは 関数呼び出しの連鎖によってのみである。グラフはこの連鎖を走査し、確定的な 答えを提供する。 38

表4：ベクトルRAG対GraphRAG

機能 ベクトルRAG GraphRAG
検索キー 類似（コサイン距離） 関係（グラフ辺）
文脈品質 高再現、低適合
（ノイズ）		 高適合、接続された
文脈
マルチホップ推論 劣る（間接リンクを見逃す） 優れる（走査する
連鎖を）
ハルシネーションリスク 高い（欠けたものを推測する
リンクを）		 低い（取得されたリンクは
明示的）
最適用途 非構造化テキスト（FAQ） 構造化システム（コード、
生物学）

第6章：移行のエンジニアリング—— 技術的深掘り

6.1 「グローバル変数」の罠を解く

COBOLの最も危険な側面の一つは、グローバル変数の使用である。定義されるのは DATA DIVISIONであり、プログラム全体のさまざまなPERFORM文によって変更される。 Javaでは、ベストプラクティスはカプセル化を命じる。メソッドは隠れた状態に依拠すべきではない。

解決策： Veriprajnaのエージェントはグラフ上でデータフロー分析を行う。われわれはあらゆる変数のライフサイクルを追跡する 変数の。

●​ 段落CALC-TAXがGROSS-INCOMEを読むなら、グラフはGROSS-INCOMEを識別する 入力依存として。

●​ JavaメソッドcalcTax()を生成するとき、AIは明示的にBigDecimalを追加する grossIncomeをメソッドシグネチャへ。

●​ 次いでメソッドの_呼び出し元_を更新し、正しい値を渡すようにする。

「暗黙のグローバル状態」から「明示的なパラメータ渡し」へのこの自動リファクタリングは 事例研究の銀行を苦しめた副作用バグを防ぐ。 4

6.2 GOTOスパゲッティの解体

COBOL移行における最も手強い障害の一つがGOTO文である。GOTOは許す プログラム実行がどこへでも跳ぶことを許し、非線形な制御フローを作り、それは忌避される 現代の構造化プログラミングにとって。 40 JavaにはGOTO文がない。

GOTO論理の翻訳は構文翻訳以上を要する。それは制御フロー 平坦化を要する。

1.​ グラフ分析： GOTOの着地点を制御フローグラフの辺として写像する （CFG）。

2.​ パターン認識： グラフはパターンを識別する。

○​ より前のラベルへ戻るGOTOはループとして識別される。

○​ ブロックを飛ばすGOTOは条件分岐（if/else）として識別される。

○​ 出口段落へのGOTOはreturnである。

3.​ 再構造化： グラフに導かれたAIは、これらのジャンプをwhileループへリファクタする。 do-whileループ、またはJavaのbreak/continue文へ。

GOTOが作る「ループ」を可視化するグラフがなければ、テキストベースLLMはしばしば 再帰関数呼び出しを生成し、StackOverflowErrorに至り、あるいは単にハルシネーションする 存在しない論理フローを。 4

6.3 「デッドコード」の扱い

レガシーシステムは、もはや使われないコードで満ちている——古いキャンペーン、廃止製品、 デバッグルーチン。このコードを移行するのは金の無駄であり、セキュリティ表面積を増やす。 テキストベースAIは与えられたすべてを移行する。区別できないのは、稼働中と死んだ コードである。

解決策： コールグラフは到達不能ノードを識別する——入ってくる辺を持たない段落またはファイル 辺（呼び出し元なし）。Veriprajnaのシステムはこの「デッドコード」を削除対象としてフラグする。その前に 移行が始まる前に。これは典型的にコードベース規模を20-30%削減し、有意な コスト削減とより清潔な最終アーキテクチャをもたらす。31

第7章：エージェンティックな未来——ディープAI 対浅いラッパー

7.1 チャットボットを超えて：エージェンティック・ワークフロー

Veriprajnaは「チャットボット」を配備しない。われわれは自律AIエージェントを配備する。エージェントとは 計画し、実行し、フィードバックに基づき行動を修正できるシステムである。 2

浅いラッパーのワークフロー：

1.​ ユーザ： 「このコードを変換せよ。」

2.​ ラッパー： テキストをGPT-4へ送る。

3.​ 出力： Javaコードを返す。

4.​ 結果： コードはコンパイルまたは実行に失敗する。開発者が手作業でデバッグする。

Veriprajnaディープエージェントのワークフロー：

1.​ 計画： エージェントは対象COBOLファイルのASTを分析する。識別するのは 依存であり、知識グラフを照会する。

2.​ 取得： 移行に必要なGraphRAG文脈を取得する。

3.​ 生成： 「スキーマ制約デコーダ」を用いてJavaコードを生成する。それは Java構文規則と型安全性を強制する。 7

4.​ 検証（ループ）： エージェントは生成されたJavaコードをサンドボックスで_コンパイル_する。

5.​ 自己修正： コンパイラがエラーを投げた場合（例：「変数が見つからない」）、エージェントは エラーを読み、欠けた依存をグラフに照会し、コードを再生成する。

6.​ 妥当性確認： 単体テストを実行する（元のCOBOLトレースから生成）し、保証する 出力が入力の振る舞いと一致することを。

このコンパイル修正ループは、妥当性確認の負担を人間からAIへ移し、劇的に リファクタリングのコストを削減する。 42

7.2 ヒューマン・イン・ザ・ループ監督

エージェントは実行において自律的だが、戦略においては監督される。知識グラフは 解釈可能性を提供する。「ブラックボックス」ニューラルネットワークとは異なり、グラフは開発者に許す AIが決定した_理由_を正確に見ること。「AIがcom.bank.logicをインポートしたのは、見つけたからだ COPYBOOK-Xへの依存を。」

この透明性は銀行のような規制産業で不可欠である。コードのすべての行が 監査可能でなければならない。われわれは「信用せよ、私はAIだ」から「これがこの論理の引用連鎖だ」へ移る。 43

第8章：結論と戦略的 展望

8.1 リポジトリ認識のROI

McKinseyのデータは、GenAIがコーディング作業を50%削減しうると示唆するが、配備された場合に限る 正しく。 14 Veriprajnaのグラフベース・アプローチの投資対効果（ROI）は、次によって駆動される 手戻りの排除によって。

●​ 手作業移行： 高コスト、高リスク、市場投入が遅い。

●​ ラッパーAI： 中コスト（「ハルシネーション」のデバッグのため）、高リスク（隠れたバグ）、 中程度の市場投入時間。

●​ リポジトリグラフAI： 低コスト（自動化）、低リスク（決定論的検証）、速い 市場投入。

「コンテキスト切替」のオーバーヘッドを排除することで——開発者が何時間も探す 変数がどこで定義されているかを——Veriprajnaは開発者生産性を2倍から3倍に高める。比較対象は 標準AIツールである。 2

8.2 継続的モダナイゼーションによる将来耐性

モダナイゼーションは一回限りの事象ではない。それはライフサイクルである。コードベースが変換されると 知識グラフへ、それは生きた資産として残る。新しいJavaコードが進化するにつれ、グラフは リアルタイムで更新される。これにより可能になるのは

●​ 自動文書化： AIは最新の文書を生成できる 新システムについて、グラフを読むことで。 44

●​ アーキテクチャドリフト検出： システムはアーキテクトに警告できる。新しいコードが違反すれば グラフで定義されたモジュール性規則に。 45

8.3 構造的転換

「銀行失敗」の教訓は明瞭である。コードはテキストではない。 それは複雑で相互接続された 論理のシステムである。テキストしか理解しないツールでそれをモダナイズしようとするのは、次に等しい 地図なしに通り名の一覧だけで都市をナビゲートしようとすることに。あなたは「Lost in the Middle」になる。

Veriprajnaは地図を提供する。リポジトリ認識型知識グラフを構築することで、われわれは提供する AIに、レガシーシステムの複雑さを航行するために必要な構造的知能を。 われわれは依存を写像し、結び目をほどき、機能するモダナイゼーションを届ける 構文においてだけではなく、現実において。

われわれは単にコードを書くのではない。理解をエンジニアリングする。これが違いである チャットボットとソリューション提供者のあいだの。これがエンタープライズ・モダナイゼーションの未来である。

Veriprajna. ディープな課題のためのディープAI。

引用文献

  1. 2025 Legacy Code Stats: Costs, Risks & Modernization - Pragmatic Coders, 2025年12月10日閲覧, https://www.pragmaticcoders.com/resources/legacy-code-stats

  2. Legacy App Modernization: AI Automation Slashes Costs & Time - SoftProdigy, 2025年12月10日閲覧, https://softprodigy.com/ai-driven-legacy-app-modernization/

  3. Lost-in-the-Middle Effect | LLM Knowledge Base - Promptmetheus, 2025年12月10日閲覧, https://promptmetheus.com/resources/llm-knowledge-base/lost-in-the-middle-efectf

  4. How We Use AI Agents for COBOL Migration and Mainframe Modernization | All things Azure - Microsoft Developer Blogs, 2025年12月10日閲覧, https://devblogs.microsoft.com/all-things-azure/how-we-use-ai-agents-for-cobol-migration-and-mainframe-modernization/

  5. Bridging Code and Context: A Knowledge Graph-Based Repository-Level Code Generation, 2025年12月10日閲覧, https://quantiphi.com/blog/bridging-code-and-context-a-knowledge-graph-based-repository-level-code-generation/

  6. Structural-Semantic Code Graph (SSCG) - Emergent Mind, 2025年12月10日閲覧, https://www.emergentmind.com/topics/structural-semantic-code-graph-sscg

  7. SemanticForge: Repository-Level Code Generation through Semantic Knowledge Graphs and Constraint Satisfaction - ResearchGate, 2025年12月10日閲覧, https://www.researchgate.net/publication/397521461_SemanticForge_Repository-Level_Code_Generation_through_Semantic_Knowledge_Graphs_and_Constraint_Satisfaction

  8. RANGER: Repository‑level Agent for Graph‑Enhanced Retrieval - arXiv, 閲覧 2025年12月10日, https://arxiv.org/html/2509.25257v1

  9. 40 Legacy Software Migration Trends for Enterprises in 2025 | Adalo, 2025年12月10日閲覧, https://www.adalo.com/posts/cost-savings-from-replacing-legacy-tools-with-no-code-stats

  10. The problems with migrating legacy code: Moving from COBOL to Java and how Metabob can help, 2025年12月10日閲覧, https://metabob.com/blog-articles/the-problems-with-migrating-legacy-code-moving-from-cobol-to-java-and-how-metabob-can-help.html

  11. 7 Signs Legacy System Modernisation Can't Wait Any Longer - Dreamix, 2025年12月10日閲覧, https://dreamix.eu/insights/when-to-invest-in-legacy-system-modernisation/

  12. How to plan a seamless COBOL to Java migration in 8 weeks? - OptiSol Business Solutions, 2025年12月10日閲覧, https://www.optisolbusiness.com/insight/how-to-plan-a-seamless-cobol-to-java-migration-in-8-weeks

  13. Application Modernization Statistics: Future-Proof Insights - eSparkBiz, 2025年12月10日閲覧, https://www.esparkinfo.com/blog/application-modernization-statistics

  14. Modernizing legacy architectures using GenAI-powered Knowledge Graphs | by Sigmoid, 2025年12月10日閲覧, https://sigmoidanalytics.medium.com/modernizing-legacy-architectures-using-genai-powered-knowledge-graphs-73d96169f6d7

  15. How GPT Wrappers Can Accelerate Your AI Product Development - Synergy Labs, 2025年12月10日閲覧, https://www.synergylabs.co/fr/blog/how-gpt-wrappers-can-accelerate-your-ai-product-development

  16. The Ephemeral Scaffolding or Enduring Infrastructure? LLMs, Their Wrappers, and the Specter of a Dotcom Déjà Vu - Torome, 2025年12月10日閲覧, https://torome.co.uk/Template/PDO3/the-ephemeral-scafolding-or-enduring-inffrastructure-llms-their-wrappers-and-the-specter-of-a-dotcom-deja-vu

  17. GraphRAG vs. Vector RAG: Side-by-side comparison guide - Meilisearch, 2025年12月10日閲覧, https://www.meilisearch.com/blog/graph-rag-vs-vector-rag

  18. Lost in the Middle in LLMS. Why large language models ignore the… | by Cengizhan Bayram | Nov, 2025 | Medium, 2025年12月10日閲覧, https://medium.com/@cenghanbayram35/lost-in-the-middle-in-llms-86e461dc7212

  19. A practical guide to the Claude code context window size - eesel AI, 閲覧 2025年12月10日, https://www.eesel.ai/blog/claude-code-context-window-size

  20. Lost in the Middle: How Language Models Use Long Contexts - MIT Press Direct, 2025年12月10日閲覧, https://direct.mit.edu/tacl/article/doi/10.1162/tacl_a_00638/119630/Lost-in-the-Middle-How-Language-Models-Use-Long

  21. Why Language Models Are “Lost in the Middle” - Towards AI, 2025年12月10日閲覧, https://pub.towardsai.net/why-language-models-are-lost-in-the-middle-629b20d86152

  22. LLM Hallucinations – Definition, Examples and Potential Remedies - Software Mind, 2025年12月10日閲覧, https://softwaremind.com/blog/llm-hallucinations-definition-examples-and-potential-remedies/

  23. Repository GraphRAG MCP Server: A Deep Dive for AI Engineers, 2025年12月10日閲覧, https://skywork.ai/skypage/en/repository-graphrag-mcp-server-ai-engineers/1978326852212269056

  24. AST-Based Source Code Migration Through Symbols Replacement, 2025年12月10日閲覧, https://www.computer.org/csdl/proceedings-article/csde/2022/10089298/1M7LebbRyEw

  25. BMSD 2011, 2025年12月10日閲覧, https://is-bmsd.org/Documents/ProceedingsOfFirstBMSD.pdf

  26. Abstract Syntax Tree Creation - Compiler Design - Meegle, 2025年12月10日閲覧, https://www.meegle.com/en_us/topics/compiler-design/abstract-syntax-tree-creation

  27. AST (Abstract Syntax Tree) - by Dinis Cruz - Medium, 2025年12月10日閲覧, https://medium.com/@dinis.cruz/ast-abstract-syntax-tree-538aa146c53b

  28. Daily Papers - Hugging Face, 2025年12月10日閲覧, https://huggingface.co/papers?q=outlier%20chunk%20handling

  29. What is a Call Graph? And How to Generate them Automatically freeCodeCamp, 2025年12月10日閲覧, https://www.freecodecamp.org/news/how-to-automate-call-graph-creation/

  30. Generation of Call Graph for Java Higher Order Functions - IEEE Xplore, 2025年12月10日閲覧, https://ieeexplore.ieee.org/document/9138056/

  31. Enhancing Neural Code Representation with Additional Context - arXiv, 閲覧 2025年12月10日, https://arxiv.org/html/2510.12082v1

  32. Can We Translate Code Better with LLMs and Call Graph Analysis? - IJCAI, 2025年12月10日閲覧, https://www.ijcai.org/proceedings/2025/0848.pdf

  33. Code Graph: From Visualization to Integration - FalkorDB, 2025年12月 10日閲覧, https://www.falkordb.com/blog/code-graph/

  34. Codebase to Knowledge Graph generator : r/LocalLLaMA - Reddit, 2025年12月10日閲覧, https://www.reddit.com/r/LocalLLaMA/comments/1mzvk44/codebase_to_knowledge_graph_generator/

  35. SemanticForge: Repository-Level Code Generation through Semantic Knowledge Graphs and Constraint Satisfaction - arXiv, 2025年12月10日閲覧, https://arxiv.org/html/2511.07584

  36. RAG vs GraphRAG: Shared Goal & Key Differences - Memgraph, 閲覧 2025年12月10日, https://memgraph.com/blog/rag-vs-graphrag

  37. Do You Really Need GraphRAG? A Practitioner's Guide Beyond the Hype, 2025年12月10日閲覧, https://towardsdatascience.com/do-you-really-need-graphrag-a-practitioners-guide-beyond-the-hype/

  38. Navigating the Nuances of GraphRAG vs. RAG - foojay, 2025年12月10日閲覧, https://foojay.io/today/navigating-the-nuances-of-graphrag-vs-rag/

  39. GraphRAG vs RAG: Which is Better? | by Mehul Gupta | Data Science in Your Pocket, 2025年12月10日閲覧, https://medium.com/data-science-in-your-pocket/graphrag-vs-rag-which-is-beter-81a27780c4ff

  40. Why not GOTO Statement? [closed] - Stack Overflow, 2025年12月10日閲覧, https://stackoverflow.com/questions/19766205/why-not-goto-statement

  41. Alternative to a goto statement in Java - Stack Overflow, 2025年12月10日閲覧, https://stackoverflow.com/questions/2430782/alternative-to-a-goto-statement-in-java

  42. Legacy Code Modernization with Claude Code: Breaking Through Context Window Barriers, 2025年12月10日閲覧, https://www.tribe.ai/applied-ai/legacy-code-modernization-with-claude-code-breaking-through-context-window-barriers

  43. Legacy IT Modernization with AI | MITRE, 2025年12月10日閲覧, https://www.mitre.org/news-insights/publication/legacy-it-modernization-ai

  44. Documenting and Modernizing Legacy Codebases with C3 Generative AI, 2025年12月10日閲覧, https://c3.ai/blog/documenting-and-modernizing-legacy-codebases-with-c3-generative-ai/

  45. The AI revolution in application modernization: from manual burden to strategic advantage, 2025年12月10日閲覧, https://vfunction.com/blog/ai-app-modernization-strategy/

ビジュアルでインタラクティブな体験をご希望ですか？

本ペーパーの主要な調査結果、統計、アーキテクチャを、ナビゲーション可能なセクションとデータビジュアライゼーションを備えたインタラクティブ形式でご覧いただけます。

インタラクティブ版を見る
FAQ

よくあるご質問

なぜAIコーディングアシスタントはエンタープライズのレガシーモダナイゼーションに失敗するのか？

AIコーディングアシスタントはコードを線形テキストとして扱い、「Lost in the Middle」症候群に陥る——長い文脈の冒頭と末尾は正確に処理するが、中央に埋もれた重要な変数定義を見逃す。COBOLシステムでは、何千行も離れたREDEFINES句やCOPYBOOK依存がデータの解釈を完全に変え、構文は完璧だが意味的に壊れた翻訳を招く。

コードモダナイゼーションにおけるリポジトリ認識型知識グラフとは何か？

リポジトリ認識型知識グラフは、コードベース内のあらゆる実体——変数、関数、クラス、モジュール——をグラフのノードとして写像し、辺は包含、継承、呼び出し、データフロー関係を表す。キーワード類似を探すテキスト検索とは異なり、グラフは数百万行にわたる決定論的な構造依存を捉え、移行中に変数や状態変化が見落とされないようにする。

エンタープライズのレガシーモダナイゼーション課題はどれほど大きいか？

米国の技術的負債だけでも$1.52 trillionに達する。ATM取引のおよそ95%はいまもCOBOL上で動き、銀行システムの43%はCOBOLベースであり、連邦IT予算の80%はイノベーションではなく保守に充てられる。十年超のレガシーシステムはセキュリティ侵害を受ける確率が三倍高く、モダナイゼーションは存亡にかかわる要請である。

ソーシャル

他のプラットフォームでも公開

LinkedIn · 会社LinkedIn · 創業者YouTubeMediumDev.toSubstackInstagramFacebookX

確かな信頼のもとに、AIを構築する。

次世代のエンタープライズAI構築において豊富な経験を持つチームと、ぜひご一緒ください。信頼できるAI戦略の設計・構築・導入を、私たちがお手伝いします。

WhatsAppで連絡するチームにメールする

Veriprajna ディープテック・コンサルティング は、ヘルスケア・金融・規制対応分野における安全性重視のAIシステム構築を専門としています。当社のアーキテクチャは確立されたプロトコルに照らして検証され、包括的なコンプライアンス文書を備えています。

WhatsApp
すぐにチャット
通話を予約
Calendlyで予約
メール
[email protected]