💻 computer science

When Prompt Under-Specification Improves Code Correctness: An Exploratory Study of Prompt Wording and Structure Effects on LLM-Based Code Generation

この探索的研究は、プロンプトの過少指定が構造的に最小限のベンチマークではコード生成を通常劣化させる一方で、LiveCodeBench のようなより豊かなタスクでは誤った手がかりを撹乱することで正確性を驚くほど向上させる可能性を示し、プロンプトの頑健性が固定されたモデルの性質ではなく、タスクの構造に強く依存することを明らかにしている。

原著者： Amal AKLI, Mike PAPADAKIS, Maxime CORDY, Yves Le TRAON

公開日 2026-04-28

📖 1 分で読めます☕ さくっと読める

CC BY 4.0

原著者： Amal AKLI, Mike PAPADAKIS, Maxime CORDY, Yves Le TRAON

原論文は CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) でライセンスされています。 ✨ これは以下の論文のAI生成解説です。著者が執筆または承認したものではありません。技術的な正確性については原論文を参照してください。免責事項の全文を読む

あなたがコンピュータプログラムを作成するよう依頼する際、非常に優秀だが少し文字通りすぎる助手を雇うと想像してください。あなたは彼らに一連の指示（「プロンプト」）を与えます。長らく、専門家たちは指示がより精密で詳細かつ厳格であればあるほど、助手はうまく機能すると信じていました。もし一つの細部を省略すれば、助手は混乱し失敗すると考えられていたのです。

この論文は、その古い信念に挑戦します。研究者たちは、助手に詳細を「少なく」与えることが、実際にはより良いコードの作成を助ける場合があることを発見しました。

彼らがこれをどのように発見したか、簡単な比喩を用いて説明します。

1. 2 種類の「試験」

研究者たちは、AI モデルの性能を測る 2 種類の異なる「試験」（ベンチマーク）でこのアイデアを検証しました。

「フラッシュカード」試験（HumanEval）： これらは短い単一文のフラッシュカードのようなものです。指示は非常に簡潔で、追加の文脈はありません。「このリストをソートする関数を書いてください」と頼むようなものです。
「教科書」試験（LiveCodeBench）： これらは教科書の章全体のようなものです。長い物語、規則のリスト、入力と出力の例、そして特定の制約が含まれています。「名前をソートするリストについての物語があります。規則は次の通りです：名前は 10 文字を超えてはいけません。そして、入力の例は以下の通りです…」と言うようなものです。

2. 実験：指示を「壊す」

研究者たちは、これらの指示を意図的に 3 つの方法で「突然変異」させ、何が起きるかを観察しました。

曖昧さ（LV）： 具体的な言葉を曖昧な言葉に置き換えました（例：「ソート」を「並べる」に変更）。
不足指定（US）： 特定の規則や制約を削除しました（例：数字の大きさにに関する規則を削除）。
汚れたフォーマット（SF）： 誤字を追加したり、スペースを変更したりしました。

3. 驚くべき結果

結果は、AI がどの「試験」を受けたかによって大きく異なりました。

「フラッシュカード」試験では： 研究者が詳細を削除したり言葉を曖昧にしたりすると、AI の性能は急落しました。短い小テストからヒントを削除された時にパニックに陥る学生のように、AI は混乱し、壊れたコードを書きました。
「教科書」試験では： 同じことを行った場合、AI の性能は変化しなかったか、驚くべきことに向上しました。

「ネットゼロ」の錯覚：
当初、研究者たちは「教科書」試験を受けた AI は単にその変化を気にしていなかったと考えていました。しかし、より詳しく調査すると、綱引きのような状況があることがわかりました。

いくつかの変化は AI を失敗させました（劣化）。
しかし、ほぼ同数の変化は、以前は失敗していた場所で AI を成功させました（改善）。
この 2 つの力が互いに打ち消し合い、何も起きていないように見せかけていたのです。

4. なぜ「少ない」ことが時に「多い」ことになるのか？

この論文は、規則を削除することがなぜコードを修正する場合があるのか、その興味深い理由を突き止めました。それは**悪い習慣と「手がかり」**に関するものです。

AI を、特定の教科書から答えを暗記している学生のように想像してください。

罠：時折、プロンプト内の特定の単語や特定の数字が「トリガー」として機能します。それは AI に、一見正しく見えるが実際にはこの特定の課題には不適切な、暗記された解決策を思い起こさせます。
- 論文からの例： 問題に「通貨」という言葉が含まれていました。この言葉は AI に金融の為替レートを想起させ、後向きな思考のアルゴリズムを使用させる結果となりました。
解決策： 研究者たちが「通貨」という言葉を削除し、「リソース」といった曖昧な言葉に置き換えると、AI はその「金融の記憶」をトリガーしなくなりました。代わりに、AI はゼロから問題の構造を考えることを強いられました。これにより、正しい解決策が導き出されたのです。

つまり、プロンプトの追加情報は、時折 AI を誤った道へ導く「ヒント」を偶然与えていたのです。そのヒントを削除することで、AI は正しく作業を行うことを強いられたのです。

5. 主な教訓

この論文は結論として、頑健性とは AI の大きさ（小型モデルか巨大モデルか）に関係なく、指示がどのように構築されているかにかかっていると述べています。

AI に短い単一文のプロンプトを与える場合、それは非常に脆弱です。言い回しを間違えれば失敗します。
AI に豊かで多層的なプロンプト（例、制約、フォーマットを含む）を与える場合、それははるかに頑健です。指示の一部が混乱しても、頼れる「バックアップ信号」を持っています。
重要なのは： 時折、あまりに具体的であることが罠となります。特定の単語や数字は、誤ったショートカット（暗記されたが正しくないもの）を使うよう AI を無意識に誘導（プライミング）してしまうことがあります。それらの具体的な手がかりを削除することで、AI は問題を正しく解くことを強いられます。

要約すると： 完璧で詳細なプロンプトが常に最善であると仮定しないでください。時折、少し曖昧なプロンプトの方が、AI に自ら考えさせ、暗記された習慣の罠を回避させるのです。

論文「When Prompt Under-Specification Improves Code Correctness: An Exploratory Study of Prompt Wording and Structure Effects on LLM-Based Code Generation（プロンプトの未指定化がコードの正しさを向上させる：LLM 基盤コード生成におけるプロンプトの文言と構造の影響に関する探索的研究）」の詳細な技術的要約を以下に示す。

1. 問題提起

大規模言語モデル（LLM）がコード生成にますます利用される一方で、その出力の正しさはプロンプトの文言に極めて敏感である。先行研究では、未指定化（要件の欠落または弱化）や微細なプロンプトの摂動が一般的に性能を低下させることが確立されている。しかし、これらの知見は主に最小仕様ベンチマーク（例：HumanEval、MBPP）から導き出されたものであり、これらは構造的冗長性が限られた、短い単一ドキュメント文字列の説明を特徴としている。

著者らは、これらのベンチマークが LLM の脆弱性を過大評価していると仮説を立てている。現実世界のシナリオでは、タスクには豊富な多層的な仕様（説明、制約、入出力形式、例）が含まれることがよくある。本論文は、構造的に豊かな環境において未指定化の否定的効果が持続するかどうか、そして直感に反して、特定のプロンプト要素を除去することが、誤った検索の手がかりを撹乱することにより、コードの正しさを向上させる可能性があるかどうかを調査する。

2. 手法

ベンチマーク

本研究は、構造的特性が異なる 2 つのベンチマークを対比する。

HumanEval (HE): 短いドキュメント文字列を持つ 164 の単純な Python 問題。独立した制約、構造化された入出力、または例を欠く。「最小仕様」を表す。
LiveCodeBench (LCB): 完全な散文記述、明示的な制約、複数のサンプル入出力ペア、および形式仕様を備えた 1,055 の競技プログラミング問題（LeetCode、Codeforces、AtCoder）。「豊富な仕様」を表す。

モデル

本研究は 3 つのカテゴリーにわたる10 の LLMを評価する。

小規模オープンソース（6–7B）: CodeLlama-7B、DeepSeek-Coder-6.7B、Qwen2.5-Coder-7B。
大規模オープンソース（15–34B）: StarCoder2-15B、Codestral-22B、CodeLlama-34B、DeepSeek-Coder-33B、Qwen2.5-Coder-32B。
プロプライエタリ/推論: GPT-5-mini、Claude Sonnet 4。

プロンプト変異

著者らは、3 つの変換タイプを用いて3,651 の変異プロンプトを体系的に生成した。

語彙的曖昧性 (LV): 正確な用語や識別子をより広範な同義語に置き換える（例："sort" $\to$ "arrange"、delimiter $\to$ filler）。
未指定化 (US): 文法的に有効なプロンプトを維持しつつ、単一の明示的制約（値の範囲、順序規則、エッジケースの説明など）を除去する。
構文とフォーマット (SF): 意味を変えずに表面レベルのノイズ（タイプミス、インデントエラー、区切り文字の問題）を導入する。

評価指標

Pass@1: 正しさを測る主要指標。
遷移分析: 均一な劣化と相反する力を区別するために、Pass $\to$ Fail（劣化）とFail $\to$ Pass（改善）の遷移を追跡する。
注意アテンション分析: どのプロンプト領域が意思決定を駆動するかを理解するために、モデルのアテンションパターンを検証する。
根本原因分析: 変異が正しさを向上させたケースを人手で検査し、言語的メカニズムを特定する。

3. 主要な貢献と知見

知見 1: 頑健性は構造的であり、アーキテクチャ的ではない

HumanEval: すべての変異タイプが顕著な性能低下を引き起こした（例：US 変異は平均**-11.8%**の低下をもたらした）。
LiveCodeBench: 同じ変異はほぼゼロの正味影響をもたらした（例：US 変異はわずか**-0.9%**の低下のみ）。
結論: 頑健性はモデルのサイズやアーキテクチャの内在的な性質ではない。それはプロンプト構造によって支配される。豊富な仕様は、プロンプトの一部が劣化した際にフォールバック信号として機能する冗長性（制約、例、入出力）を提供する。アテンションマップは、LCB 上のモデルがこれらの補助コンポーネントに大きく依存しているのに対し、HE のモデルはほぼ説明のみに依存していることを確認している。

知見 2: 未指定化は正しさを向上させる可能性がある

「より多くの仕様は常に良い」という仮定に反し、本研究は LCB において未指定化がしばしばコードの正しさを向上させることを発見した。

LCB では、LV 変異におけるFail $\to$ Pass対Pass $\to$ Failの遷移比率はほぼ**1:1 (0.99)**であり、改善が劣化を相殺することを意味する。
HumanEval では、劣化が圧倒的に支配的だった（比率0.40）。
一貫した改善: 本研究は、複数のモデルにわたって制約や曖昧さを除去することが一貫して通過率を向上させた47 の特定の LCB タスクを特定した。

知見 3: 改善のメカニズム（検索手がかりの撹乱）

人手による分析により、元のプロンプトにはモデルを記憶されているが誤った解決策に固定させる「検索手がかり」が含まれていることが明らかになった。未指定化はこれらの手がかりを撹乱し、モデルを問題構造から推論することを強制する。

語彙的曖昧性 (LV):
- 変数名の変更: 過剰適合した関連性を破る（例：s を seq に改名することで、特定の誤ったアルゴリズムの検索を防ぐ）。
- 用語の一般化: 分野固有の名詞（例："currency"）を一般的な用語（例："resource"）に置き換えることで、モデルが分野固有のヒューリスティック（例：後方への金融スキャン）を適用するのを防ぎ、一般的なアルゴリズム的推論（例：前方 DP）を促す。
未指定化 (US):
- 制約の除去: 特定の制約（例： $C_i \le 10^9$ ）は、モデルが一般ケースでは失敗する最適化されたショートカット（例：スターグラフの直径の公式）を使用するよう誘導することが多い。制約を除去することで、モデルは一般的で正しいアルゴリズム（例：2-BFS）を使用することを強制される。
- 入出力のプライミング: 制約は、誤った入力解析パターン（例：LeetCode 風の input().split() 対競技プログラミングの stdin 形式）をトリガーすることがある。これらを除去することで、正しい解析を強制する。

4. 意義と示唆

ベンチマークの再評価: HumanEval などの最小ベンチマークは、現実世界のタスクに見られる冗長性が欠如しているため、LLM の脆弱性を過大評価している可能性がある。それらは、構造的な豊かさがプロンプトエラーを緩和する「相殺効果」を捉え損ねている。
プロンプトエンジニアリング: 本研究は、プロンプトは最大限に正確でなければならないという教義に挑戦する。いくつかのケースでは、過剰な仕様（特に誤解を招く制約や分野固有の識別子を意図的に含めること）がモデルを静かに誤導する。実務家は、特定の手がかりを除去することが場合によってはより良い結果をもたらす可能性があることに留意すべきである。
モデル開発: 検索手がかりへの感受性は、モデルの規模だけでは解決されない一般化のギャップを示している。最先端の推論モデル（GPT-5、Claude）でさえこれらの手がかりに陥ることは、パターンマッチングよりも構造的推論を優先するトレーニング戦略の必要性を示唆している。
将来の研究: 本論文は、現実世界の開発の構造的な豊かさを反映するベンチマークを求め、検索ベースの失敗を引き起こす特定の言語的トリガーの調査を推奨している。

まとめ

この探索的研究は、プロンプトの未指定化の影響が一様ではないことを示している。最小ベンチマークでは性能を劣化させるが、現実世界のタスクにおける豊富な仕様は、これらの効果を中和する冗長性を提供する。驚くべきことに、未指定化は、モデルが記憶された誤ったパターンに依存する原因となる誤った検索手がかりを撹乱することにより、コードの正しさを向上させる可能性がある。著者らは、頑健性はプロンプト構造の関数であり、精度が過剰適合をトリガーする特定の文脈では「少ない方が多い（less is more）」であると結論付けている。