COBOL開発へのローカル LLM 導入実践 １：環境構築と動作確認

現在、大規模言語モデル (LLM) の性能向上に伴い、開発における AI 活用方法が従来のコーディング支援から AI エージェントを活用した自動開発へと進化しており、Anthropic 社、IBM 社、Microsoft 社、Google 社などが提供する[Kケ1.1][N宣1.2]高性能なモデル（以降、パブリック LLM と記載）を活用した開発スタイルを、Python や Java などの開発現場で導入済みという方もいらっしゃるのではないでしょうか。

一方、COBOL が現役で稼働する基幹システムの開発に対する AI 活用は、あまり行われていないようです。その理由は様々あるかと思いますが、代表的なものを挙げてみますと、以下のような点ではないでしょうか。

1. COBOL に対するコーディング生成能力に疑問がある
2. ミッションクリティカルなビジネスロジックや自社のナレッジの外部送信に対する安全性に不安がある
3. どう活用できるか分からない

１の原因については、膨大なトレーニングデータを基に構築されるLLMに、COBOLのビジネスロジックとして成立するレベルのプログラムコードが含まれていないためです。

このようなコードが大量に公開され、トレーニングデータとして入力できれば、大きな改善が見込めるものの、自社の機密となりうるコードを積極的に公開する企業は希少であり、この点の改善には時間がかかることが想定されます。２については、パブリック LLM 利用におけるエンタープライズ契約では、入力データをトレーニングデータとして使用しないといった文言はあるものの、送受信自体の安全性やエージェントの不適切な挙動のブロックなど、安全性について検討すべき点が多くあります。

もし、環境をクローズド、すなわち、自社内のネットワーク内で閉じることができれば、安全性の問題に加え、LLM の利用料金もかからない低コストな AI 開発環境を手に入れることができます。そして、それを実現するのが、本連載のテーマであるローカル LLM です。しかし、ローカル環境で稼働する LLM は、前述したようなパブリック LLMと比較すると大きく性能が劣ります。その結果、前述した高性能モデルではできることが、ローカル LLM ではできない、といったことが頻繁に起こります。

この連載では、COBOL 開発にローカル LLM を導入することで、何ができるのか、何ができそうにないのかを実際に確認していきながら、３の活用方法について探していきます。

なお、LLM の稼働には一般的に GPU 性能、特に VRAM 容量が重要です。本記事では、特別な明記がない限り、特に AI 向けの環境を用意することなく、8GB というAI 活用には少し心もとないサイズで進めていきます。

ローカルAI 開発環境を構築しよう

Python, Java では Visual Studio Code (以降、VSCode と記載) 、もしくは、その互換エディターを使用した開発が一般的ではないでしょうか。ロケットソフトウェア製品では、以前より COBOL 開発の IDE として Eclipse, Microsoft Visual Studio をサポートしていますが、現在では、VSCode においても、マーケットプレイスから Rocket Software の拡張機能をインストールすることで、COBOL の開発が可能です。

VSCode への拡張機能インストールと基本的な使い方については、こちらをご覧ください。

さて、AI エージェントを利用した開発といえば、GitHub Copilot Chat のように自然言語で入力した指示内容を AI が解釈したうえで AI が自動で実行してくれることを想像するのではないでしょうか。同様の機能が実現できる拡張機能はマーケットプレイス上に複数公開されていますが、本記事では Zoo Code を使用します。

次に、最も重要となる LLM ですが、今回のような VRAM 8GB という環境下では高性能なモデルは動きません。また、AI エージェントがファイル作成、プログラム実行といった機能を利用するために、LLM の Capability として Tools を持つ LLM を選択する必要があります。このような条件を満たす LLM は、執筆時の 2026 年 7 月時点では、Google 社が公開しているGemma 4 E2B などが該当しますので、これを採用しました。

構成としては、以下のようになっています。

実行してみよう

まずは、基本的な環境ができているかを以下のプロンプトを使って確認してみましょう。 “180番目の素数を検索するJavaプログラムをFindPrime.javaとして作成して。そのうえでプログラムを実行して”

結果は、こちらからご覧いただけますが、FindPrime.java ファイルの作成からコンパイル、そして実行とうまく動いていることが分かります。
Claude や GitHub Copilot Chat などの利用と比較すると、応答に時間はかかるものの、完全なローカル環境でも、ここまでできることが確認できます。もし、ローカル LLM 環境がハイスペックであれば、さらによい性能と応答速度で利用することができます。

では、COBOL でも同じことをやってみましょう。さきほどのプロンプトを Java -> COBOL に変更した以下のプロンプトを利用します。
“180番目の素数を検索するCOBOLプログラムを find_prime.cbl として作成して。そのうえでプログラムを実行して”

結果はこちらからご覧いただけますが、Java と同じようにはできず、以下の問題がありました。

1. 1カラム目から全ての行が始まっており、プログラム記述に問題がある ( 00:55 参照)
2. ロケットソフトウェア製品のコンパイルコマンドは cob だが、LLM からはオープンソースのコンパイルコマンドの実行が提案された ( 01:56 参照)
3. 固定長形式への変換を意図したインデント追加を依頼したところ、不適切な位置への SPACES 挿入が複数提案された ( 03:48 参照)。また、その内容も不完全だった

１、３については、LLM 作成時の COBOL に対するトレーニングデータが十分ではなかったことから、Java と比較すると低品質な結果が生成されたと考えられます。プロンプトの見直し、コーディング特化モデルや高性能モデルの使用によって改善する可能性はあるものの、少なくとも今回の検証条件においては、Java などと同じレベルでのプログラム自動開発はできませんでした。しかし、このことが COBOL 開発・運用への AI エージェント導入不可を意味するわけではありません。どの作業を AI エージェントに任すべきか、人が担当すべき作業は何か、正しく整理することで、AI エージェント導入が行えます。以降の連載で検証していきたいと思います。

問題点２についてはどうでしょうか。今回、LLM から期待した結果が戻されなかった原因は、ロケットソフトウェア製品のコンパイルコマンドに関する情報が不足しているためです。では、ファインチューニングやツールを作らなくてはいけないのでしょうか。ツールはまだしも、ファインチューニングとなると大きな作業になりますが、実は今回のような LLM が知らない情報をプロンプトに含めることで容易に対応することができます。Zoo Code では、以下のような rules.md を作成して対応します。

今回は環境を検証することが目的であるため、特定ファイルに対する操作のみを記述していますが、これまで使用していたコンパイル用スクリプトなどを指定することで、従来同様の手順が自動実行できるようになります。

AI エージェントによる自動実行を確認するために “こんにちは” を出力するだけの単純な hello.cbl を作成したうえで、以下のプロンプトを指示しました。

“hello.cblをコンパイルして実行して”

結果はこちらでご覧いただけますが、期待した通り、エージェントが Rocket Visual COBOL 製品を使ったコンパイル、実行を行い、正常に終了できていることが確認できます。

まとめ

今回は、VSCode 上で COBOL のローカル LLM を用いた AI 開発を行うための環境構築とその動作を確認しました。一般的に、LLM をローカルで利用するには、価格とのトレードオフではあるものの、VRAM 容量を大きくすることでより高性能なモデルを使用することができます。その究極形がパブリック LLM です。しかし、これらの利用料金に対する成果が見合わない不安や、問合せするためのデータがネットワーク送信されることの安全性などを気にされる方もいらっしゃいます。

ローカル LLM の使用は、性能こそ大きく劣るものの、このような問題を解決し、自社内でクローズされた AI 環境構築を実現することができるメリットがあります。パブリック、ローカル、いずれにしても、導入前に、どのようなことを AI に任せるのか事前に検討・整理しておかなければ、十分な結果を得ることができません。ローカル LLM でできることはローカル LLM 、できないことはパブリック LLM でといった使い分けにより、コストを抑えつつ、AI 全般に関する技術知見を社内に蓄積することができます。

次回の記事では、ローカル環境での COBOL プログラムの開発支援について検証したいと思います。