アーカイブ / LLM
コード生成の依頼文を整えると何が変わるか：HumanEvalの5条件を比較
PromptResponse
PromptResponseの原論文から掲載した図です。細部はクリックして拡大できます。
出典：PromptResponse / arXiv ↗概要
- HumanEvalの164問を5種類の依頼文で各10回試し、GPT-4oによる計8,200回のコード生成を比較した。
- 著者らは、書式の統一、とくにJSONで生成効率と回答の文字列上の安定性が改善したと報告する。
- 言語モデルで調整した依頼文では、付属テストに基づく課題成績が有意に悪化したと報告されている。
補足：編集した模式図で仕組みを確認する
VISUAL EXPLAINER
図でつかむ、PromptResponseの仕組み
- 01HumanEvalの課題
- 025種の依頼文
- 03GPT-4oで生成
- 04コードと測定値
原論文の説明をもとにした模式図です。処理の細部は省略しています。
研究の背景
PromptResponseは、コード生成の依頼文をどう書くかによって、生成結果がどう変わるかを調べる研究である。大規模言語モデル（LLM）は文章からコードを作れるが、同じ課題でも書式や表現によって回答が変わりうる。
HumanEvalの元の課題文には、例の見出しや配置などにばらつきがある。依頼文の情報を一定の形にそろえたとき、テストの合否、処理時間、繰り返し生成した回答の似かたに違いが出るかを確かめた。
手法
著者らは、Python関数を作るHumanEvalの164問を用いた。元の文章のほか、項目を分けたJSON、Markdown、YAMLと、Mistral AIの言語モデルで説明文を調整した版を作成した。JSON版では、たとえば挨拶を返す関数の名前、署名、説明、入力例と期待する出力を、それぞれ決まった項目に置く。署名とは関数名や引数、戻り値の型を示す記述である。
各課題の各条件をGPT-4oへ個別に送り、10回ずつコードを生成した。付属テストの合否、生成時間、コード評価時間、回答の文字数を記録した。回答同士の似かたにはROUGE-Lを使った。これは文字列に共通して現れる文字の並びの長さに基づく指標で、コードの意味が同じかを直接判定するものではない。
新規性
著者らは、同じHumanEval課題について、元の文章、JSON、Markdown、YAML、別の言語モデルで調整した文章を比較した。書式をそろえる操作と文章を調整する操作を、一つの実験で検討した点に特徴がある。
付属テストの合否に加え、生成とコード評価にかかる時間、回答の文字数、繰り返し生成した回答同士の文字列上の類似度も記録した。これにより、正解率だけでは分からない書式の影響を調べている。
従来手法との違い
比較の基準は、HumanEvalの元の依頼文を変更せず使う条件である。JSON、Markdown、YAMLでは項目の配置を統一し、関数の署名や説明などの文言は原則として保った。別の条件では、Mistral AIの言語モデルで説明文を調整した。
著者らは、書式の統一、とくにJSONで生成効率と文字列上の安定性が改善し、課題成績にも小幅な改善があったと報告する。一方、言語モデルで調整した条件では課題成績が有意に悪化し、ほかの測定項目に有意な改善はなかったという。
実験結果
著者らはHumanEvalの164問を5条件で各10回実行し、合計8,200回GPT-4oに問い合わせた。課題成績は各問の10回答のうち付属テストをすべて通る割合である。生成時間、全回答とテスト合格回答の評価時間、回答の文字数を記録し、同じ課題の10回答間のROUGE-Lも算出した。
著者らの報告では、書式の統一、とくにJSONで生成効率と文字列上の安定性が改善し、課題成績の向上は小幅だった。言語モデルで調整した依頼文では課題成績が有意に悪化した。確認できた本文の範囲では結果表の数値や検定条件を確認できないため、改善幅や有意差の判定方法は示せない。
応用の可能性
編集上の応用案 · 論文が実証した用途とは区別しています。
編集上の応用案：社内で使う小さなPython関数の実装依頼を、項目を定めたJSONに整えてコード生成へ渡す。入力は既存の関数仕様、署名、入出力例、制約とし、出力は担当者が確認する生成コードとする。
必要な元データは仕様文と実行可能なテストで、合否ラベルはテスト結果から得る。追加学習用データやセンサー入力は想定しない。仕様をJSONへ移す際は、例外条件や制約が落ちていないか人が照合する。効果は業務で確かめるべき仮説である。
応用先の候補からNauhに相談できます。
導入時の検証
導入時の検証案 · 対象データでの再評価が必要です。
導入時の検証案：既存のPython関数仕様と実行可能なテストを少数集め、元の依頼文と、同じ要件を項目別に整理したJSONを用意する。署名、入力例、期待する出力、制約が両条件で一致するかを人が確認してから、同じモデルで複数回ずつコードを生成する。
元データは仕様文とテストで、合否ラベルはテスト結果から付ける。追加学習用データやセンサーは使わず、必要な適合作業は社内仕様をJSONの項目へ写すこととする。テスト通過率、生成時間、回答の文字数、再生成時の類似度を比較し、変換にかかった手間も記録する。
限界と課題
著者らは、生成時間がサーバーの負荷にも左右されるため、測定値を一般的な所要時間として扱えないと明記する。実験条件はHumanEvalのPython課題をGPT-4oの既定設定で解くもので、結果を別の課題やモデルへそのまま広げる根拠は示されていない。
編集上の検証事項は、書式変換後も仕様の意味が保たれるか、社内の課題でも同じ傾向が出るかである。ROUGE-Lが示すのは回答の文字列上の類似度であり、保守のしやすさを直接測るものではない。
出典
元のタイトル・要旨を確認する（英語）
PromptResponse: Optimizing Prompts for LLM Coding Tasks
Large language models (LLMs) are increasingly used in research workflows and software development pipelines, yet their output remains sensitive to input prompt variations. This paper presents $\unicode{x00AB}$PromptResponse$\unicode{x00BB}$, a controlled study examining how formatting and LLM-based tuning of coding task prompts affect the resulting code's performance, efficiency, and stability. Using five semantically identical yet syntactically distinct variants of the HumanEval dataset$\unicode{x2014}$baseline, JSON, Markdown, YAML, and an LLM-tuned version$\unicode{x2014}$we had GPT-4o solve its coding problems over 8200$\unicode{x00A0}$executions. Our results show that consistent formatting$\unicode{x2014}$especially JSON$\unicode{x2014}$improves generation efficiency and syntactic stability, with minor gains in task performance. Conversely, the LLM-tuned prompts resulted in significantly degraded task performance without significant improvements in any other dimension. These findings suggest that low-effort reformatting alone can yield measurable improvements, while tuning must account for model alignment. We conclude our work with providing a set of practical recommendations informed by our results as well as releasing our dataset variants and evaluation pipeline for future work.
論文本体の取得範囲に基づく解説。AIが作成した未校閲の記事です。性能の数値は著者の評価条件に依存します。応用例と検証計画は編集上の提案です。解説更新：2026-10-01