A framework for assessing the capabilities of code generation of constraint domain-specific languages with large language models

本論文は、大規模言語モデルによる制約ドメイン固有言語（OCL や Alloy など）のコード生成能力を、構文の正当性と正しさの観点から評価する汎用フレームワークを提案し、Python との比較やコード修復・複数試行などの改善策の影響を分析することで、特定のタスクにおける効果的なコード生成設定の決定を支援するものである。

要約

この論文は、**「AI（大規模言語モデル）に、専門用語や特殊なルールで書かれた『魔法の呪文（コード）』を書かせることができるか？」**という問題を、非常に丁寧な実験を通じて解き明かした研究報告です。

専門用語を避け、日常の例え話を使って解説しますね。

1. 背景：AI は「万能」ではない？

最近の AI（チャットボットなど）は、普通のプログラミング言語（Python や Java など）なら、まるでベテランの職人のようにコードを書くことができます。これは、AI がインターネット上の膨大な「普通のコード」を学習しているからです。

しかし、**「ドメイン固有言語（DSL）」**と呼ばれる、特定の分野（ここでは「システムのルールや制約」を定義する言語）に特化した言語になると、AI の性能はガクンと落ちます。

• 例え話： AI が「料理のレシピ（Python）」は完璧に作れるのに、「化学実験の特殊な手順書（OCL や Alloy）」を書かせようとすると、失敗ばかりしてしまうようなものです。なぜなら、その「特殊な手順書」のレシピ本が、AI の学習データにほとんどないからです。

2. この研究の目的：AI の「料理上手さ」を測る新しい「採点表」

研究者たちは、AI がこの特殊な言語でどれだけ上手にコード（ルール）を書けるかを測るための、**「新しい採点システム（フレームワーク）」**を作りました。

このシステムは、以下の 3 つのステップで AI を評価します。

1. 文法チェック（Well-formedness）： 書いた文章が、その言語のルールに合っているか？（例：「主語と動詞が合っているか？」）
2. 正解チェック（Correctness）： 書いたコードが、本当に意図したルールを正しく表現しているか？（例：「『赤信号で止まれ』というルールを、本当に『止まれ』と書いているか？」）
3. 直し作業（Code Repair）： もし間違っていたら、AI に「ここが間違ってるよ」と教えて、直させることができるか？

3. 実験：Python と「魔法の言語」を比べる

研究者たちは、この採点システムを使って、以下の 3 つの言語で AI をテストしました。

• Python： 一般的な料理（よく知られた言語）
• OCL と Alloy： 特殊な化学実験手順書（あまり知られていない言語）

そして、4 種類の AI（GPT-4o など）を使って、約 10 万回もの実験を行いました。

4. 驚きの結果と教訓

実験から、いくつかの面白い発見がありました。

① 言語によって AI の実力は天と地ほど違う

• Pythonでは、AI はほぼ完璧にコードを書きました。
• しかし、OCL や Alloyのような特殊な言語では、AI は文法ミスばかりしたり、意味の通らないルールを書いてしまったりしました。
• 結論： 特殊な言語を扱う場合、AI の「言語ごとの得意不得意」が非常に重要です。

② 「指示の出し方（プロンプト）」はあまり重要ではない

「AI にどう指示を出せばいいか？」という悩みがありますが、実験では**「指示の出し方を変えても、結果はあまり変わらない」**ことがわかりました。

• 例え話： 料理人に「最高のステーキを作ってください」と言うか、「最高のステーキを作ってください、塩は控えめに」と言うかで、結果に大きな差は出ませんでした。重要なのは「その料理（言語）を熟知している料理人（AI）を選ぶこと」です。

③ 「何回も試す」と「直す」のが最強の秘訣

一番効果があったのは、以下の 2 つの組み合わせでした。

• 複数回挑戦（Multiple Attempts）： 1 回で失敗しても、3 回、5 回と AI に書かせて、一番良いものを選ぶ。
• 直し作業（Code Repair）： 間違っていたら、「ここが間違ってるよ」と教えて、AI に修正させる。
• 結論： 「1 回で完璧な答え」を期待するより、「何回も試して、間違ったら直す」というプロセスを踏むと、劇的に品質が上がります。

④ 一度に全部書かせるのがおすすめ

複数のルールを同時に書かせるか、1 つずつ書かせるかという実験では、**「一度に全部書かせる（バッチ処理）」**方が、ルール同士の矛盾が起きにくく、結果が良い傾向がありました。

5. まとめ：私たちに何ができるか？

この研究は、AI を使う人への**「実践的なガイドライン」**を提供しています。

• AI を選ぶときは慎重に： 特殊な言語を使うなら、その言語に強い AI を選んでください。
• 完璧を求めない： 1 回で完璧なコードが出ないのは当たり前です。
• プロセスを重視する： 「何回も試して、間違ったら直す」という作業をシステムに組み込むのが、最もコストパフォーマンスが良い方法です。

つまり、**「AI は魔法の杖ではなく、練習が必要な見習い職人」**です。適切な言語を選べば、そして「練習（複数回挑戦と直し）」をさせれば、驚くほど素晴らしい成果を出してくれる、というのがこの論文のメッセージです。

技術概要

論文「制約ドメイン固有言語（DSL）における大規模言語モデル（LLM）のコード生成能力を評価するためのフレームワーク」の技術的サマリー

本論文は、大規模言語モデル（LLM）を用いたコード生成技術が、汎用プログラミング言語（GPL）に比べてドメイン固有言語（DSL）、特に制約言語（OCL や Alloy）においてどのように機能するかを体系的に評価するためのフレームワークを提案し、その実証実験を通じて得られた知見を報告するものです。

1. 背景と問題定義

LLM は自然言語からのコード生成において高い能力を示していますが、その性能は学習データに含まれるコードの量に依存します。Python や Java などの人気のある汎用言語（GPL）では大量のデータが存在しますが、ドメイン固有言語（DSL）や制約言語（OCL、Alloy など）は「低リソース言語」として扱われ、学習データが不足しています。

特に制約言語には以下の固有の課題があります：

• 低リソース: 学習用サンプルが少なく、構文や意味の理解が困難。
• 双方向の依存関係: 制約はドメインモデル（スキーマ）に依存するため、モデルの定義と制約の記述の両方を同時に管理する必要がある。
• 宣言的性質: 手続き型言語とは異なり、実行ではなく検証やテストが主目的であり、正しさを判定するのが難しい。
• グローバルな相互作用: 個々の制約が独立せず、相互に影響し合うため、個別の評価が困難。

これらの課題に対し、LLM が DSL のコード生成においてどの程度有効か、またどのような設定（プロンプト、モデル選定、リカバリー手法など）が最適かを定量的に評価する統一的な評価フレームワークの必要性が指摘されています。

2. 提案手法：モジュール型評価フレームワーク

著者らは、コード生成プロセスの各段階をパラメータ化して比較・評価できるモジュール型フレームワークを提案しました。このフレームワークは以下の 4 つの主要ステージで構成されます（図 1 参照）。

1. プロンプト構築 (Prompt Building):
   • 入力（コーディングタスク、ドメイン記述、ドメインモデル）に基づき、9 種類の異なるプロンプトテンプレート（PT1-PT9）を生成します。
   • 拡張（Augmentation）: 連鎖推論（CoT）やドメインモデルの説明生成、モデルのコード化などを取り入れたプロンプト設計。
   • タスク配信戦略: 複数の制約を一度にバッチ処理するか、個別に逐次処理するか（OP1-OP3）。
2. コード生成と抽出 (Code Generation & Extraction):
   • 選択された LLM にプロンプトを送信し、生成されたコードを抽出します。
   • 非決定性を考慮し、同じタスクに対して複数回（k 回）の生成試行（Multiple Attempts）を行うオプションを提供します。
3. Well-formedness（形式正しさ）評価:
   • 生成されたコードが言語の構文規則に従っているか（パース可能か）を検証します。
   • 失敗した場合は、エラーメッセージを LLM に提示して**コード修復（Code Repair）**を 1 回行い、再度検証します。
4. Correctness（正しさ）評価:
   • 形式正しいコードが、自然言語の仕様を満たすか（機能的に正しいか）を検証します。
   • 検証手法として、LLM-as-a-Judge（LLM による自動評価）と、必要に応じて手動評価や単体テスト（Alloy の AUnit など）を使用します。
   • 同様に、失敗した場合は 1 回のコード修復を試みます。

評価指標:

• Accuracy (Pass@1): 1 回目の試行で正解する確率。
• Pass@k: k 回の試行のうち、少なくとも 1 つが正解する確率。

3. 実験設定

提案フレームワークの妥当性を検証するため、以下の設定で大規模な実験を行いました。

• 対象言語: 2 つの制約 DSL（OCL, Alloy）と、比較対象の汎用言語（Python）。
• 対象 LLM: 4 種類（GPT-4o, GPT-4o-mini, DeepSeek Coder 6.7B, Llama 3.1）。
• データセット: 既存のデータセットを拡張し、30 のドメインモデルと 182 の制約タスク（計約 10 万件の生成タスク）を評価対象としました。
• 変数: 言語、LLM 選定、プロンプトテンプレート（9 種類）、タスク配信方法、コード修復の有無、試行回数（k=1,2,3）。

4. 主要な結果と知見

4.1 言語とモデルの影響

• 言語による性能差: Python が最も高い Well-formedness と Correctness を示しました。一方、OCL と Alloy は構文エラー（Well-formedness の欠如）が多く、特に小規模なコンテキストウィンドウを持つオープンソースモデル（DeepSeek, Llama）では、制約関連のコード生成が極めて困難でした。
• モデルの選定: GPT-4o が全体的に最高性能でした。GPT-4o-mini は Python では良好ですが、OCL において性能が低下しました。これは、GPT-4o の学習データに OCL 類似の記法が含まれている可能性を示唆しています。オープンソースモデルは制約 DSL の生成には実用的ではないことが示されました。

4.2 プロンプトエンジニアリングの影響

• プロンプトテンプレート: 言語やモデルの組み合わせによっては統計的に有意な差が見られましたが、全体的に「どのテンプレートが最も優れているか」という明確なトレンドは見つかりませんでした。
• 結論: 性能差が小さい場合、トークン数を最小化できる単純なテンプレート（PT1）を使用するのが効率的であるという結論に至りました。言語への事前知識があるモデルでは、高度なプロンプト設計の恩恵は限定的です。

4.3 戦略的改善の効果

• 複数回試行（Multiple Attempts）: 試行回数（k）を増やすと、正解する確率（Pass@k）は線形的に向上しますが、コストも増大します。
• コード修復（Code Repair）: 生成されたコードを LLM に修正させるプロセスを導入すると、正解率が 10-20% 向上しました。
• 最適戦略: 「複数回試行」と「コード修復」を組み合わせることが、最も高い品質のコードを生成する戦略ですが、最もコストがかかります。
• タスク配信: 複数の制約を個別に生成する（Isolated）よりも、同じドメイン内の制約を 1 つのプロンプトでまとめて生成する（Batch）方が、モデルの文脈理解が安定し、結果として整合性の高い出力が得られる傾向がありました。

5. 貢献と意義

本論文の主な貢献は以下の通りです：

1. 包括的な評価フレームワークの提案: プロンプト、モデル、評価手法、修復戦略など、コード生成プロセスのすべての要素をパラメータ化し、体系的に比較可能なモジュール型フレームワークを構築しました。
2. 制約言語における LLM 性能の定量的評価: OCL と Alloy といった低リソースな制約言語において、LLM が直面する具体的な課題（構文エラー、ドメインモデルとの整合性など）を Python と比較して明らかにしました。
3. 実践的なガイドラインの提示: 約 10 万件の生成タスクに基づき、以下の実用的な指針を導き出しました（表 6 参照）：
   • 低リソース言語では、言語に精通したモデルの選定がプロンプト調整よりも重要。
   • 言語対応が十分なモデルでは、過度なプロンプト設計より「複数回試行」と「検証」が有効。
   • 関連する制約は個別ではなく、まとめてプロンプトに含めるべき。
   • リソースが許容される場合、「複数回試行」と「コード修復」の併用が最適。

6. 結論

LLM を用いた DSL のコード生成は、学習データの不足により依然として課題を抱えていますが、適切なフレームワークによる評価と戦略（モデル選定、複数回試行、修復プロセス）の適用により、その品質を大幅に向上させることができます。本フレームワークは、特定のタスクや言語に対して最も効果的なコード生成設定を決定するための基盤を提供し、将来的には RAG（検索拡張生成）やファインチューニングとの統合などへの展開も視野に入れています。