COBOL（1950年代末に登場した事務処理向けの古いプログラミング言語）の保守要員が不足し、Pythonや TypeScriptへの移行を検討しているチームに向けて、OpenAIが公表した低リソース言語対応の取り組みを整理します。普段C言語やJavaScriptのような主要言語でLLM（大規模言語モデル）を使っている開発者にとっても、評価設計の考え方は参考になるはずです。
OpenAIはChatGPTの対応範囲を、COBOLやSQLite（組み込み用途で使われる軽量なデータベースエンジン）のような、学習データが少ない言語・技術に広げる取り組みを進めています。背景には、LLMの性能がPythonやJavaScriptなど「学習データが大量にある言語」に偏りやすいという構造的な課題があります。
なぜ低リソース言語でLLMの精度が落ちるのか
LLMはインターネット上の大量のコードを学習して、次に来るトークン（単語や記号の最小単位）を予測する仕組みで動いています。GitHubの公開リポジトリを見ればわかる通り、PythonやJavaScriptのコード量はCOBOLやCOBOL由来のレガシー資産に比べて桁違いに多く存在します。
学習データが少ない言語では、モデルが文法の細部や標準ライブラリの使い方を誤って出力する頻度が上がります。たとえばCOBOLのPERFORM文やWORKING-STORAGE SECTIONのような固有構文は、主要言語の構文知識からの類推だけでは正しく扱えません。これが「低リソースプログラミング言語」と呼ばれる問題の本質です。
OpenAIが新設した評価の中身
この課題に対処するため、OpenAIはソフトウェアエンジニアリング全般の評価に加えて、SQLiteの操作タスクやCOBOLのマイグレーション（移行）タスクに特化した評価セットを新たに整備したと説明しています。これは単なるベンチマークスコアの比較ではなく、実務で発生する「既存コードの意図を理解し、別言語に書き換える」という作業を模した評価設計です。
COBOLマイグレーションの評価が重要なのは、単純な構文変換では済まないためです。COBOLの業務ロジックには、数十年分の仕様変更がコメントなしで埋め込まれているケースが珍しくありません。モデルが元のロジックを壊さずに移植できるかどうかを測る評価軸は、一般的なコード生成ベンチマーク（たとえばHumanEvalやMBPPのような関数単位の正答率を測るもの）とは性質が異なります。
RAGやファインチューニングとの関係を整理する
ここで気になるのは、低リソース言語への対応力をどう底上げするかという設計の選択肢です。大きく分けて3つのアプローチがあります。
- モデル本体の追加学習（事前学習段階でCOBOLコードを増やす方法。モデル提供側でしか実施できない）
- ファインチューニング（手元のCOBOL資産で既存モデルを追加調整する方法。自社でデータを用意すれば実施可能）
- RAG（Retrieval-Augmented Generation、検索で関連情報を取得してから回答を生成する仕組み。社内の仕様書やコピーブック定義を検索対象にできる）
COBOL移行プロジェクトでは、RAGが現実的な選択肢になりやすい傾向があります。理由は、COBOLのCOPY文で参照される共通定義（コピーブック）や、関連するJCL（ジョブ制御言語）の情報を検索で補完できるためです。ファインチューニングはデータ量と品質管理のコストが高く、移行対象システムが1つしかない場合は投資対効果が見合わないこともあります。
一方で、COBOLのような構文が特殊な言語は、トークナイザ（文字列をトークンに分割する前処理部品）の効率も確認しておく価値があります。トークン分割が非効率だと、同じ業務ロジックでも主要言語より多くのトークンを消費し、API利用コストやコンテキストウィンドウ（モデルが一度に扱える入力量）の消費が増えます。
今日から確認できること
自社でCOBOL資産やSQLiteを使った組み込みシステムを抱えている場合、次の点を確認しておくと移行検討がしやすくなります。
- 使用中のChatGPTやAPIのモデルバージョンが、低リソース言語評価の対象になっている世代かどうか（OpenAIのモデル一覧ページでCOBOL・COBOLマイグレーションへの言及があるか確認）
- 移行対象のCOBOLコードにコメントや仕様書がどれだけ残っているか（RAGの検索対象として使えるドキュメントの有無）
- コピーブックやJCLなど、プログラム本体以外の関連資産を検索可能な形で用意できるか
- 評価用に、実際の業務ロジックから抜粋した小規模なテストケースを自前で作れるか（公開ベンチマークだけでは自社資産の特殊性を測れないため）
特に最後の点は見落とされがちです。公開されている評価セットはあくまで一般的なパターンを想定したものであり、自社固有の業務ルールまでは網羅していません。移行プロジェクトを始める前に、少数でもよいので「正解が明確なCOBOLモジュール」を使った独自の検証セットを作っておくと、モデル選定やプロンプト設計の判断材料になります。
まとめ
COBOLやSQLiteのような低リソース言語への対応強化は、LLMが「学習データの多い言語に強い」という構造的な偏りに向き合う動きの一つです。移行プロジェクトを検討している場合は、モデル任せにせず、コピーブックや仕様書を検索対象に組み込んだRAG構成を優先的に検討してみてください。
あわせて、公開ベンチマークに頼り切らず、自社のCOBOL資産から小規模な検証セットを作ってモデルの出力を確認する作業も欠かせません。まずは手元のレガシーコードがどの程度ドキュメント化されているかを棚卸しするところから始めてみるとよさそうです。