LLMとコードを書くときに意識したい時間配分と手戻りの減らし方

本記事では、LLMと人間のやり取りの仕方がコード生成の生産性にどう影響するかを調べた研究を紹介します。

プロンプトの工夫や時間配分、エラーとの向き合い方がどのように成果に結びつくかを実験的に検証しています。実際にLLMと対話しながらタスクに取り組んだ結果から、実務に活かせるヒントが見えてきました。

LLMを開発補助として活用したい方にとって、日々の使い方を見直すきっかけになるかもしれません。

背景

ソフトウェア開発の現場では、LLMを使って作業を効率化する取り組みが広がっています。にも関わらず、「LLMとどのようにやり取りすれば、より効果的にタスクをこなせるのか」。その「使いこなし方」については詳しくわかってはいません。

LLMとの対話は、「いつでも最適な結果を出してくれる」と期待されてしまいがちです。しかしLLMの実行はプロンプトによって行われます。指針がない場合、何度もプロンプトを書き直してもほとんど改善が見られず、無駄な反復作業になってしまう場合もあります。その結果、開発者が望む成果を得られず、かえって生産性が下がることもあります。

実際の開発では、複数のクラスや外部ライブラリ、APIとの連携といった、より大きな構造の中でコードを書く必要があります。プロンプトの型だけでなく、ユーザーがどのような文脈を与えるのか、設計書やテストコードのどの部分を使うのかといった選択も、やり取りの結果に大きく影響します。

こうした実務的な工夫を体系的に整理し、LLMとのやり取りをうまく進めるためのヒントを得る必要があります。

そこで本記事では「関数レベルやプロジェクトレベルの開発タスクにおいて、どんなやり取りのしかたがもっとも生産的か？」を探るために実際のユーザーを対象とした調査を取り上げます。

これまでの研究ではどこまで分かっている？

LLMによるコード生成に関する研究は、主に二つの方向で進んできました。
ひとつは「コード生成そのものを自動化する仕組み」を作ること。もうひとつは「実際の開発者がLLMとどう向き合っているか」を観察することです。

コード生成の仕組みをどう作るか

これまでの研究では、たとえばLLMに「建築家」や「ソフトウェアエンジニア」といった役割を与え、それぞれが連携してコードを組み立てていくような仕組みが提案されてきました。
また、テスト駆動開発（TDD）の考え方をLLMに取り入れ、まずテストを書いてからコードを生成させることで、精度を高めようという試みもあります。

他にも、単体テストをどう評価するか、あるいは生成されるコードの品質をどう高めるかといったテーマでも研究が進んでいます。
クラス間の依存関係など、より現実に近い構造を扱えるような課題セットも登場しましたが、こうした複雑なタスクではLLMの精度に限界があることも明らかになっています。

とはいえ、多くの研究はいまだに「関数レベルのシンプルな問題」に焦点を当てており、プロンプトの設計方法を細かく比較するような検討はあまり進んでいません。

LLMは現場でどう使われているか

一方で、「実際の開発者がどうLLMを使っているか」を調べる実証的な研究もあります。

たとえば、学生がプログラミングの課題に取り組む際、LLMにどんな助けを求めているかを分析した調査では、知識の確認や、コードの生成といった使い方が多いことが分かっています。
また、特定の実験課題をCopilotと一緒に解く様子を観察した研究や、TDDのワークフローを組み込んだプロンプトで成果を検証したものもあります。
関数レベルのコードに対してLLMが出力したコードを大量に分析し、エラーの種類を整理した研究もあります。

ただ、参加者の経験の幅や、やり取りの進め方の違い、どんな資料を使ったかといった点までは深く掘り下げられてきませんでした。

LLMとのやり取り、何が結果を左右するのか

どんなやり取りがうまくいくのかを考えるには、「そもそも何が影響するのか」を整理する必要があります。

軸はこの3つ

LLMと人間のやり取りは主に三つの観点で分析可能です。

1. ユーザー側の特徴（経験やスキル）
2. モデルの種類（無料か有料か、どのUIを使ったか）
3. やり取りの進め方（どうプロンプトを作ったか、何を使ったか）

①ユーザー側の特徴について

開発者側のスキルや経験がどう影響するのか？

• プログラミング歴や業務経験がどれくらいあるか
• LLMをどの程度使い慣れているか
• LLMが出したコードをどれくらい信用しているか
• アルゴリズムの課題にどれだけ慣れているか

②モデル側の違いについて

使ったモデルの種類も影響します。

無料版と有料版、WebUIかIDEかAPIかなど、使う環境によって結果の出やすさやユーザー体験が変わることがあります。

③やり取りの方法や進め方について

やり取りの進め方もさまざまです。

• プロンプトをテンプレートから使ったか、自分で工夫したか
• 設計書やテストケースなど、どんな資料を使って文脈を伝えたか
• 開発プロセスとして、ウォーターフォール型か、TDD的に進めたか

こうした違いもまた、成果に大きく関わってきます。

ということで、今回確認された観点を整理すると以下のようになります。

プロンプトはどう書けばいい？代表的な4つのスタイル

LLMに何かを頼むとき、「どう聞くか」が結果を大きく左右します。
今回の研究では、実際のタスクで使われた4つのプロンプトの型が検証されました。どれも現場で応用しやすいスタイルばかりです。

1. 理由を説明させるスタイル（Reflection）

モデルにただ答えを出させるだけでなく、「なぜその答えなのか」まで語らせるスタイルです。
LLMに推論の筋道を言語化させることで、答えの妥当性を自分でも判断しやすくなります。コードの修正や確認がしやすくなるのがメリットです。

2. 別のやり方も聞いてみるスタイル（Alternative Approach）

ひとつの方法にこだわらず、他の選択肢も挙げてもらうスタイルです。
たとえば「この関数の実装、別の書き方ある？」と聞くイメージ。視点を切り替えたいときや、詰まったときに有効です。

3. 一歩ずつ考えさせるスタイル（Chain-of-Thought）

複雑な問題を細かく分解し、段階的に考えさせるスタイルです。
たとえば、「まず何を考えるべき？」「その次は？」といった流れで進めていくことで、より筋の通った回答が得られます。問題が複雑なほど効果が出やすい傾向があります。

4. いくつか例を見せてから聞くスタイル（Few-Shot）

あらかじめ「こんなふうに答えてね」とお手本を見せてから質問するスタイルです。
決まった形式で答えてほしいときや、安定した出力がほしいときに向いています。例をどう選ぶかがカギになります。

実験

モデルとのやり取りの方法が開発効率にどのように影響するかを明らかにするため、実際の開発者を対象にした実験が実施されました。

注目した三つのポイント

①やり取りの何が生産性に影響するか

まず最初に検証されたのは、やり取りの中のどんな特徴がコード生成の成果に結びつくかという点です。評価指標にはテストの合格率が用いられ、統計的な分析を通じて各特徴の影響度が明らかにされました。

②どんな進め方がうまくいくか

次に注目されたのは、やり取りの進め方と成果との関係です。たとえば、どんなプロンプトパターンが効果的か、どのような参照資料を使うとよいか、コピーアンドペーストか手動整形かといった細かい進め方の違いについても比較されています。

③どこでつまずきやすいか

やり取りの過程で発生したエラーを分類し、それぞれの頻度や特徴が整理されました。コードの出力結果、チャットのやり取り、画面の操作記録をもとに、エラーの原因とその対処のヒントがまとめられました。

実験の流れと所要時間

参加者には以下の3ステップで実験に取り組んでもらいました。

• ルール説明と資料配布（15分）
• ChatGPTとやり取りしながらタスクを解く（70分）
• 終了後にアンケートへ回答（15分）

参加者の募集と構成

参加者は、配布資料やLinkedIn、Upworkを通じて募りました。Pythonの経験が2年以上あることを応募条件とし、全世界から36名が参加しました。学生から実務経験者まで多様な経歴を持つ人々を集め、プロジェクト経験などを考慮して4つの比較グループに分けました。

タスクの進め方と使用ツール

参加者には、設計ドキュメント、プロンプトのテンプレート、Jupyterのスケルトンコードまたは問題リンクが提供されました。関数タスクには12名、プロジェクトタスクには24名が割り当てられました。原則として手動コーディングは禁止とし、ChatGPTが3回出力しても期待する結果が得られない場合のみ手動での修正が許可されました。

使用するモデルは、参加者の慣れに応じて無料版または有料版を選べるようにしました。無料版（GPT-4o-miniなど）は18名、有料版（GPT-4o）も18名が使用しています。

アンケートの内容と目的

背景情報ややり取りの進め方についての主観評価が得られるよう、選択式と自由記述を含む30問のアンケートが実施されました。生産性、正確性、効率性に関する感覚が、段階的な尺度で回答されました。

タスクの構成 関数編とプロジェクト編

各タスクでは、設計ドキュメントや仕様書に沿ったテストとスケルトンコードが整備され、即座に取り組める形式で提供されました。

関数タスクの選び方と構成

一般的なベンチマークは、タスクが細かく分割されており、今回のようなやり取り分析には適さないと判断されたため使用されませんでした。データ漏洩の懸念も踏まえ、LeetCodeやHackerRankから問題が選定されました。

問題構成は、簡単な問題が2問、中級が2問、上級が1問の計5問です。所要時間の目安として、簡単な問題は10〜15分、中級は20〜30分、上級は1時間以上かかると見込まれました。70分の時間枠の中で全72件のテストを通過するのは難しく、実力や戦略の違いが現れやすいように設計されています。

プロジェクトタスクの設計と条件

関数単体では測りにくいクラス間の依存や統合性が評価できるよう、マルチクラス構成の課題が2つ設計されました。テーマには、Eコマースアプリとスマートホームジムが採用されました。いずれの課題にも、設計ドキュメント、スケルトンコード、実行可能なテストが付属されました。

仕様には、パラメータ、戻り値、振る舞い、特別要件、エラー処理、入出力例が明記されました。Eコマース課題では5クラス14メソッド、スマートホームジムでは7クラス22メソッドが含まれました。クラス間の依存例もスケルトンに組み込まれ、一般的な仕様に準じた形式で整えられました。

テストケースは、同値分割法を用いて通常ケースとエッジケースが用意されました。Eコマースは128件、スマートホームジムは100件のテストが構成されました。サンプルコードにおいては分岐網羅率100パーセントが確認され、参加者によって提出された最終コードでは、平均行カバレッジ91.85パーセント、分岐カバレッジ99.83パーセントが記録されました。

進行は段階的に構成され、まずEコマース課題が解かれ、128件中121件以上に合格した場合に限り、次の課題に進むことが許可されました。

生産性をどう評価したか

生産性の評価には、70分間でのテスト合格率が主に用いられました。全件に合格した場合には、完了までの所要時間も評価指標として参考にされました。

一般的な生産性の観点には、正確性、効率性、保守性、セキュリティ、満足度などが含まれますが、本研究では特に「正確性」に着目し、比較の軸として明確にされました。

実験の結果

生産性に影響した主な要因

生産性を左右する15の特徴について、前処理、回帰分析、安定性選択の手法を組み合わせて検証しました。ここでは、テスト合格率を生産性の指標として使用しています。

この分析から、以下の3つが有意に影響していたことがわかりました。

• プロンプトパターンの選び方（Few-Shotがもっとも効果的でした）
• 初期実装とデバッグにかける時間のバランス（デバッグに時間を割くことで成果が向上する傾向がありました）
• アルゴリズム問題への習熟度（習熟している人ほど、生産性がやや下がる傾向が見られました）

効果的なやり取りの傾向

プロンプトパターンによる違い

関数タスクでは、12名中10名が70分以内に全72テストを通過しており、残りの2名も合格率は90パーセントと92パーセントに達しました。失敗が見られた部分は難易度の高い問題に限らず、各問題に含まれるエッジケースに集中していました。

Few-ShotやChain-of-Thoughtパターンを使った場合、ReflectionやAlternative Approachよりわずかに良い結果が得られました。また、主観的な評価でも、生産性や今後の利用意欲の点で高く評価されました。

一方、プロジェクトタスクは難易度が高く、最高でも合格率が0.53、最低は0.07という結果でした。Few-Shotは平均的に良好な成績を示し、Reflectionは最大値においてもっとも高いスコアを記録しました。主観評価でも、生産性、正確性、効率性のいずれにおいても高評価が得られました。

画面記録とチャットログの分析では、ReflectionとFew-Shotパターンでは、1つのクラスを完了するのに必要なやり取りの平均が3.5回、最大でも5回にとどまっていました。これに対して他のパターンでは、平均5.4回、最大7.3回となっており、おおよそ1.5倍のやり取りが必要となっていました。

上位参加者の共通点

プロジェクトタスクでは、やり取りの回数が平均51.9回、最大で82.3回に達しました。中でも高い成績を収めた上位6名には、以下のような共通点がありました。

• 5名がコピーアンドペーストと手動による整形（LLMから出力されたコードやテキストをそのままコピペするのではなく、参加者が自分で書式や構造を整え直す作業）を併用していた
• 上位3名はテンプレートの意図や期待される挙動を最初に明確に伝えたうえで依頼していた

この中でも、コンテキストの作成においてコピーと整形を併用していた人の平均合格数は95.88でした。コピーのみの人は77.25にとどまり、20%以上の差が見られました。

時間の使い方については、上位者はデバッグに多くの時間を使っており、初期実装の3倍に相当する時間をかけていました（実装17分に対し、テストベースの改良に50分程度）。

また、参照資料の活用では、失敗の原因を説明する際にテスト結果やテストコードを使用する傾向が強く、上位12名中10名が修正時に主にテストコードを提示していました。

エラーの実証的な分析

すべての参加者によって実行されたテストの総数は6,336件であり、そのうち791件がエラーとなりました。分類としては、ランタイムエラーが420件、ロジックエラーが255件、非実装によるものが116件でした。

非実装を除いた675件のエラーを詳しく分析したところ、ランタイムエラーは19種類、ロジックエラーは10種類のパターンに分類できました。

ユーザー側に起因するエラー

文脈の提示が不十分だったり、仕様の読み取りに誤解があったことで、エラーが発生していました。たとえば、応答の一部だけをコピーし、初期化が抜けたことで、既存の構造と新たな構造がぶつかるケースなどが該当します。

また、アルゴリズム経験が豊富な参加者の中には、初期段階でLLMに頼らずに手動記述を進めた結果、情報不足によるエラーを招いてしまうケースも見られました。

モデル側に起因するエラー

文脈が適切に与えられていたにもかかわらず、誤った出力が生じることもありました。属性の指定漏れ、引数型の取り違え、条件式の設定ミスなどが代表的な例です。

とくに、正規表現や論理演算の組み合わせでの誤りが多く見られました。Alternative Approachを使った場合、最初の案とは異なる後続の案に十分な文脈が反映されず、整合性が崩れることもありました。

デバッグ時に生じやすい特有のエラー

修正パッチを作成する過程で、ほかの部分に意図しない影響が及ぶことがありました。関数の移動や名前の重複、新旧コードの混在といった現象が起きやすく、複数クラス間の依存関係をうまく把握できていないと、混乱が発生することがわかりました。

現場で見えてきたヒント

今回の検証から、LLMを活用した開発の中で効果を高めるための具体的なポイントがいくつか見えてきました。

モデルを強くするより、プロンプトを工夫したい場面もある

LLMを使ううえでよく話題に上がるのが、「性能の良いモデルに切り替えるべきか、それともプロンプトの工夫を深めるべきか」という問いです。今回の実験では、どちらも重要ではあるものの、コード生成においてはプロンプト戦略の工夫が成果を押し上げやすいという傾向が見られました。

強いモデルは、その戦略を後押しする役割としてとらえるのが自然です。

LLMの活用を役割の違いにどう広げるか

今回の分析では、エンジニアとLLMの1対1のやり取りに注目し、その中で15の特徴に着目して評価を進めました。ただ、現実の開発現場では、設計、実装、テストといった役割が交差しながら進みます。こうした多様な役割にも展開していくことが次の課題になります。

たとえば、アーキテクトやテスターといった役割ごとに、異なる特徴や期待されるプロンプトのパターンを設定し、それぞれの立場でLLMとのやり取りがどうなるかを確かめていくと、多人数・多役割の現場における手順のヒントが得られます。今回のプロジェクトタスクや分析の観点は、そうした応用の出発点としても使える内容です。

現場で活かせるポイント

開発者として意識しておきたいこと

学習中のエンジニアや若手に限らず、LLMを日常的に使うような開発者にとっても、今回の結果は実践的なヒントになります。ポイントは、与える情報の質と、時間の使い方のバランスにあります。

• 要件を貼り付けるだけでなく、自分なりの理解を添えて文脈を整える
• 実装よりも早めにデバッグに入るよう時間配分を意識する
• 修正時には、設計書ではなくテストケースを使って意図を伝える

このような工夫を加えることで、やり取りの効率が大きく改善することがわかっています。

チーム運営で意識したいこと

規模の大きなプロジェクトでは、初期の実装よりも修正・検証フェーズに人手や時間を集中的に配分する判断が成果につながりやすくなります。とくにマルチクラスの修正が関わる場面では、副作用のある変更が起きやすいため、関数の移動や命名の重複、依存関係のズレといった点に注意を払うと事故を防げます。

また、LLMの活用をチーム内で広げる際には、テスト結果をやり取りの中心に据える運用を標準にしておくと、理解のすれ違いが減りやすくなります。

次に取り組みたい課題

今後の展開としては、複数人で異なる役割を担うような実験設定が重要になります。生成と説明といったサブタスクに応じて、プロンプトのパターンとモデルをどう組み合わせるかを整理していくと、ナレッジ共有や手戻りの減少につながるヒントが得られます。

また、機械学習コードのような専門性の高い領域や、セキュリティ・保守性といった品質特性に焦点を当てたシナリオを用意することで、それぞれの文脈に合ったプロンプト構造の設計も深めていくことができそうです。

まとめ

本記事では、ChatGPTを活用したコード開発のやり取りをどう工夫すればうまくいくかを調べた研究を紹介しました。

分析の結果、モデルの性能よりも、プロンプトの書き方や進め方が成果に大きく影響することが示唆されています。とくに、要件にひと言そえる、初期実装にこだわらず早めにデバッグに移るといった工夫が効果的とされています。チーム全体でも、テストをベースにやり取りを組み立てる方法が有効です。自分の開発スタイルに合ったやり方を少しずつ取り入れてみるとよさそうです。