【第10回】COBOL開発へのローカル LLM 導入実践２：
AIを活用した開発支援「コード説明」

基幹システムをはじめ、長年利用されているITシステムの仕様書は、過去の改修作業時に、適切に更新されていなかったことが原因で、ドキュメントの記述と実際のシステムの挙動が一致していないことが少なくありません。実際の挙動を把握する手段として、プログラムのソースコードから仕様書を逆生成するAIに大きな期待が寄せられています。また、若手技術者がこのようなシステムの保守・開発作業を担当する場合においても、AIによるコード説明は有用ではないでしょうか。

多くの場合、パブリックAIを用いていますが、ローカルLLMではどうなるのか、まずは確認してみましょう。
プロンプトに以下を入力して問合せを行います。

こちらが結果になりますが、open-file sectionの終了行位置がおかしくなっていますね。些細な点とはいえ、結果に誤りが含まれています。再度の問合せを行ってみますと、前回とは出力内容が異なりました。

実は、AIはプロンプト内容を基に応答結果を推論によって構築しています。このため、同じ入力に対して同じ結果が得られるとは限りません。プロンプトの見直しや、高性能なLLMやパブリックAIの利用により改善が見込めるものの、最終的には、開発者自身がAIの応答結果を鵜呑みにせず、内容を確認することが重要です。

続いて、結果の安定性向上について考えてみましょう。推論によって結果が不安定となるのであれば、事実のみを入力し、その内容を要約させれば、結果は安定するのではないでしょうか。例えば、仕様書を、RAG (Retrieval-Augmented Generation) 検索拡張生成と呼ばれる技術で事前に登録し、これらをAIの入力とすることで、推測から要約にシフトできます。ただし、仕様書記述がどこに該当するか、また、ある箇所を修正した場合の影響範囲調査となると、RAGだけでは対応できません。

プログラム内の説明コメントを都度確認するという泥臭い方法もありますが、コメントと実態があっているかの確認も必要となるため、開発者の負担が大きくなるだけで、AIの活用には至りません。

今回は、グラフDBという技術を使った案を試行してみます。グラフDBとは、データをノード（頂点）、データ間の関係をエッジとして表現するデータベースです。SNSにおける「友達の友達」の探索や、オンラインショッピングサイトでのおすすめ商品の提示など、データ間のつながりを活用する場面で広く利用されることがあります。

オープン系システムで多く利用されているリレーショナルデータベース（RDB）とは異なる考え方の技術ですが、「COBOLプログラムでどのように活用するのだろう？」と疑問に思われる方もいるかもしれません。

そこで今回は、以下の簡単なCOBOLプログラムを例に考えてみましょう。

COBOLに限らず、多くのプログラミング言語では、構文解析の結果グラフ構造で表現できます。今回の例では、その構造をグラフDB上で表現しています。

先ほどのコード例では、WORKING-STORAGE SECTIONにWK-VALというデータ項目が定義されています。この関係をグラフとして表現すると、(WORKING-STORAGE SECTION) → (WK-VAL) というつながりを持つことになります。これがグラフDBを構築する第一歩です。

グラフDBでは、このようなデータの要素を「頂点（ノード）」、頂点同士を結ぶ線を「エッジ」と呼びます。また、エッジには関係性を表す名前を付けることもできます。この例であれば、WORKING-STORAGE SECTIONがWK-VALを保持していることを表すhas_variableといったエッジ名が考えられるでしょう。

続いて、PROCEDURE DIVISIONも見ていきましょう。

(PROCEDURE DIVISION) —> (MAIN SECTION)
(MAIN SECTION) —> (MOVE “こんにちは” …)
(MAIN SECTION) —> (DISPLAY WK-VAL)
MOVE, DISPLAY文は命令文の一つなので、RDBのテーブルのようなデータ型を定義するStatementを作ります。
同様に、Sectionも専用の頂点を作成すると、以下のような定義になります。

一般的に、正規化されたRDBで同様の構造を表現する場合は、DivisionマスタやSectionマスタを作成し、それらの関係性をたどることは可能ですが、階層構造が深くなるにつれてSQLが複雑になりやすい傾向があります。

一方、グラフDBはこうした関係性の管理を得意としています。例えば、Division（”PROCEDURE”）配下のSection一覧を取得するだけでなく、そのさらに配下にあるStatement一覧を取得することも容易です。データそのものだけでなく、データ同士のつながりを自然にたどれる点が大きな特徴といえるでしょう。

余談ですが、この構成をさらに発展させて、プロジェクト、アプリケーション、プログラムといった概念をグラフ上に取り込むことで、システム間の連携関係も表現できるようになります。

これにより、基幹システムで作成されたデータがどのアプリケーションで利用されているのか、といった関係性も検索できるようになります。影響調査や仕様把握の場面では、大きなメリットになるのではないでしょうか。

では、このプログラムの構造を表すデータをどのように作ればいいのでしょうか。いくつか方法があり、弊社製品のEnterprise Analyzerが提供するAPIの利用や、オープンソースをはじめとしたパーサーの解析結果を利用することができます。今回は、オープンソースのKoopa (COBOL) Parser Generatorを利用しました。

次に、AIがグラフDBから必要とする情報を取得し、要約してもらう方法を考えます。AI単独では、人間のようにウェブ検索やDB検索といったことは行えませんが、スキルやMCPサーバーを介して機能を拡張することができます。

スキルとは、AIが利用できるツールです。ウェブ検索を行うためのツール、DB検索のツールといった、AIがプロンプト内容を実現するための便利な手段を提供するもので、登録したAIのみが利用できます。

一方、MCPサーバーとは、複数スキルを提供するサーバーであり、標準仕様によって、様々なAIからツール利用できるようにするものです。MCPサーバーを利用することで、AIは実際のデータがどう格納されているかを知る事なく、好きな開発言語を用いて、ツールの呼出し元であるAIが求める処理を実装することができます。ウェブの世界における、他システムがデータを容易に操作するためのREST APIみたいなものですね。今回はMCPサーバーにスキルget_abstractを用意しました。

機能は、プログラム名と概要を取得する構造（今回は、Division, SectionなどCOBOLプログラムの構造ですね）を指定すると、グラフDBを検索し、配下構造の概要を取得します。
この対応により、環境は以下のようになりました。

結果を分かりやすくするため、aircode.cbl の PROCEDURE DIVISION配下に対して、以下のような簡単な概要を登録しています。

では、以下のプロンプトを用いて問合せを行ってみましょう。

ご覧のように、まず概要を取得し、その内容をもとにサマリーが生成されていることが分かります。ここで取得される概要はAIの推論結果ではなく、あらかじめ登録されたデータに基づくものです。そのため、AIが生成した応答の信頼性向上が期待できます。応答時間が20秒を超えている点は、前回ご紹介した通り、LLMの稼働環境がVRAM 8GBで使用しているモデルを快適に利用するには十分ではないことに起因しています。これは、稼働環境を見直すことや使用するモデルを軽量にすることで改善できます。例えば、文章の概要をサマリーするといった要件は軽量のモデルでも十分行うことができます。こちらは、Qwen3.5-9Bを使用した結果になりますが、非常に高速な出力がされています。パブリック、ローカルにかかわらず、要件に合わせたモデルの使い分けも重要ではないでしょうか。

また、get_abstractツールのパラメータ名などを工夫することで、より自然な言葉で問い合わせられるようになるでしょう。さらに、用途に応じたツールを複数用意することで、プログラムのコード説明だけでなく、アプリケーションやプロジェクト間の連携を含めた情報の取得も可能になります。

AIによる仕様書作成やコード説明は非常に有用ですが、そこだけで終わってしまうのは少しもったいないのではないでしょうか。
例えば、今回はコードを説明するためにグラフDBを利用しましたが、グラフDBの価値は説明機能の提供だけではありません。データ項目同士の参照関係や代入関係をたどれるため、修正時の影響調査にも活用できます。次回は、実際にグラフDBを利用して修正箇所を洗い出し、AIを使ったコード修正に挑戦してみたいと思います。