レガシーホストのIT負債は、高いAIサービスを入れても自動では解けない。解けるのは、自社のIT負債の特性をRAGとグラフDBに落とし込んだときだけだ。
ベンダーのAIでも決定打にならない理由
数十年稼働してきたホストのコードは、最新仕様を知る者がおらず、有識者は退職間際、増築に次ぐ増築で影響範囲の特定すら難しい。
そこへ、ホストのOSやDBのバージョンアップが追い打ちをかける。モダナイズは待ったなしだが、現場は対症療法的な投資を繰り返すしかない。
ホストベンダー各社もAI解析サービスを打ち出しているが、これを入れれば自動で片付く、というほど単純ではないのが実情だ。
LLMには、得意な言語と不得意な言語がある
LLMの言語理解力は、学習データの量に比例する。COBOLはまだ公開情報が多いが、PL/Iになると急に手薄になり、ホスト用アセンブラにいたっては、ほとんど情報がない。
つまり同じ「ホスト資産の解析」でも、言語によってAIの読解精度は大きく変わる。ここを均して扱う解析サービスは、精度にムラが出やすい。
解くカギは、推論力をRAGとグラフDBに預けること
LLMは「国語ができる」だけでなく「推論が得意」でもある。この推論力を使い、自社のIT負債の特性をRAGに、確定した呼び出し関係や依存構造をグラフDBに定義していく。
このRAGを支えているのが、エンベディングという技術だ。言葉やコードの意味の近さに応じて、多次元の情報空間に星座を自動で配置していくような仕組みである。
ただし、この星座の並べ方を決めるアルゴリズムにも、選び方や調整の余地がある。ベンダー任せにせず、自社のIT負債の特性に合わせて調整できるかどうかが、精度の分かれ目になる。
この下ごしらえの8割を自動化できれば、残り2割に人間の目を集中させられる。いわゆるグラフRAGの発想だ。
筆者自身、Mac Studio上のローカルLLMで、広大なコンテキストを活用したこの構想のPoCを提案している最中である。