"Should I Give Up Now?" Investigating LLM Pitfalls in Software Engineering

複雑な Web 開発タスクにおける 26 名の参加者を対象とした調査により、LLM の不正確な回答や文脈の喪失などの 9 種類の失敗がユーザーの認知負荷を増大させ、回答の有用性が低い場合の放棄リスクが 11 倍に跳ね上がる一方で、追加のプロンプトが放棄を抑制する傾向があることが明らかになり、ソフトウェアエンジニアリングにおける LLM の効果的な統合に向けた課題と将来の研究方向性が示されました。

要約

この論文は、**「AI 助手（チャットボット）を使ってプログラミングをしていると、いつか『もうやめようかな』って思ってしまうのか？」**という問いを、実際の開発者の体験から調査したものです。

まるで**「経験の浅い新人エンジニアが、天才だが少し気まぐれな『AI 助手』とペアで仕事をしている」**ような状況を想像してください。

以下に、この研究の核心をわかりやすく解説します。

---

🍳 1. 研究の舞台：「完璧なレシピ」を頼んだら、なぜか焦げ付いた料理が返ってきた

研究者たちは、学生やプロのエンジニアに、複雑なウェブサイトを作るという「料理の注文」を頼みました。そして、彼らが**「ChatGPT（AI）」**という助手に「レシピ（コード）」を頼む様子をじっと観察しました。

理想としては、AI が「はい、完成した！」と完璧な料理を出してくれるはずですが、現実はそうではありませんでした。

🚧 2. 何が問題だったのか？（9 つの「失敗パターン」）

AI が返してきた答えには、大きく分けて3 つの大きな問題がありました。

1. 「半分しか作ってくれない」または「間違っている」
   • 例: 「全体を作ってください」と頼んだのに、重要な部品（例えば「お皿」や「フォーク」）が抜けていたり、味が全然違う料理が出てきたりします。
   • ユーザーの反応: 「えっ、これじゃ食べられないよ…」と、自分で修正し始めます。
2. 「情報が多すぎて頭がパンクする」
   • 例: 「塩の量だけ教えて」と頼んだのに、AI が「料理の歴史から、塩の製造工程、そして全レシピ」を 100 ページ分も書き出してきます。
   • ユーザーの反応: 「どこを見ればいいの？」と、必要な情報を探すだけで疲れてしまいます。
3. 「前の話を忘れている」
   • 例: 1 分前に「赤い服を着て」と頼んだのに、次の会話では「青い服」を提案したり、前の会話で決めた「塩の量」を無視したりします。
   • ユーザーの反応: 「さっき言ったじゃん！」と、何度も同じことを説明し直すハメになります。

🛠️ 3. ユーザーはどう対処した？（「辛抱強く」か「諦める」か）

ユーザーはこれらのミスを直すために、以下のような工夫をしました。

• 言い換え: 「もっと具体的に教えて」と再度頼む。
• 分解: 「全部じゃなくて、まずはここだけ作って」と細かく指示する。
• 手直し: AI が作ったコードを自分で修正する。

しかし、26 人の参加者のうち 17 人（約 6 割）は、最終的に「もう AI には頼まない」と決めて、自分で作業するか、他のツール（Google 検索など）を使うことにしました。

📊 4. 重要な発見：「諦める」を決める 2 つのルール

この研究で最も面白い統計的な発見は、**「いつ AI を捨てるか」**を予測するルールが見つかったことです。

• ルール①：役に立たない答えが 1 回あると、諦める確率が 11 倍になる！
  • AI が「全然役に立たない」答えを出すと、ユーザーはすぐに「もうダメだ」と感じ、作業を放棄する傾向が強まりました。
• ルール②：やり取りを繰り返すほど、諦めにくくなる。
  • 逆に、何度もやり取りを続けている間（プロンプトを繰り返している間）は、ユーザーは「もう少し頑張れば直るかも」と粘り強く取り組む傾向がありました。
• ルール③：プログラミングの経験がある人ほど、早く見切りをつける。
  • 経験豊富なプロは、「この AI はこのレベルのミスをするんだな」と即座に見抜き、無駄な時間を省いて自分で作業に移ります。一方、初心者は「自分の指示が悪いのかな？」と悩み、AI に執着し続けてしまう傾向がありました。

🧠 5. 結論：AI は「魔法の杖」ではなく「気まぐれな見習い」

この論文が伝えたいのは、**「AI が完璧なコードを書くようになっても、人間との『やり取り』自体に問題がある」**ということです。

• モデルが新しくなっても（GPT-4 から GPT-5.1 へ）、根本的な問題は消えない。
  • 最初の答えは良くなっても、会話が続くと「前の話を忘れる」「文脈を無視する」といったミスがまた起き、ユーザーを疲れさせます。
• 「諦める」のは、AI のせいだけではない。
  • ユーザーが「この作業は AI には向いていない」と判断し、自分でやるか別の方法を探すのは、合理的な判断です。

💡 まとめ：私たちが学ぶべきこと

この研究は、**「AI 助手を使うときは、最初から『完璧な料理』を期待するのではなく、一緒に『試行錯誤』するパートナーとして扱う」**べきだと示唆しています。

• AI に頼りすぎない: 重要な部分は自分で確認する。
• 疲れたら休む: 何度も同じミスを繰り返すなら、一旦 AI を離れて他の情報源（Google やマニュアル）を頼る。
• 経験値を活かす: 経験豊富な人は、AI のミスを早く見抜いて「使い分け」ができるようになります。

つまり、**「AI に全部任せる」のではなく、「AI と一緒に、でも人間が主導権を持って進める」**ことが、最も効率的な仕事をするためのコツなのです。

技術概要

論文「Should I Give Up Now? Investigating LLM Pitfalls in Software Engineering」の技術的サマリー

この論文は、大規模言語モデル（LLM）がソフトウェアエンジニアリング（SE）のワークフローに統合される際の実践的な課題、特に開発者がタスク完了中に LLM を「放棄（Abandon）」に至るまでのプロセスと要因を、実証的な観察研究を通じて解明したものです。

以下に、問題定義、研究方法、主要な貢献、結果、および意義について詳細にまとめます。

1. 問題定義 (Problem)

近年、ChatGPT や Copilot などの LLM 支援ツールは、ソフトウェア開発者の生産性向上や認知的負荷の軽減に寄与しています。しかし、その利用経験は開発者によって大きく異なり、多くの開発者は回答の不正確さや一貫性の欠如により、ツールが非生産的であると判断しています。

従来の SE ツールや HCI 研究は、ツールが決定論的（同じ入力に対して同じ出力）で安定していると仮定してきました。しかし、LLM は確率的で多ターン（マルチターン）の対話を行う「ペアプログラマー」のような存在であり、文脈の喪失、ハルシネーション（幻覚）、指示の無視などの失敗が対話の過程で蓄積します。
本研究が取り組む核心的な問いは以下の通りです：

• 複雑な SE タスクにおいて、LLM はどのような条件下で役に立たない回答を生成するのか？
• ユーザーは失敗をどのように回避・緩和しようとするのか？
• どのような要因が、開発者がタスクの途中で LLM 支援を「放棄」する決定に至らせるのか？

2. 研究方法 (Methodology)

本研究は、複雑な Web 開発タスク（マルチファイル編集、多言語、ビジュアル統合を含む）において、開発者が LLM とどのように相互作用するかを調査する観察研究です。

• 参加者: 26 名の参加者（大学院生 21 名、プロのソフトウェア開発者 5 名）。
• タスク: 既存のチュートリアルに基づいた Web サイトの作成（HTML, CSS, JavaScript の実装、デプロイなど）。
• 使用モデル:
  • 初期研究：GPT-4 / GPT-4o
  • 再現性検証：GPT-5.1（最新のモデルでも同様のパターンが維持されるか確認するため）
• データ収集:
  • スクリーンレコーディングと音声記録: 思考発話法（Think-aloud）を用いて、参加者の推論過程と行動を記録。
  • 対話ログ: プラットフォームとのすべてのプロンプトと回答の記録。
  • 事後インタビュー: タスク完了後、LLM の有用性、挫折感、放棄の理由について半構造化インタビューを実施。
• 分析手法:
  • 質的分析: 対話ログ、コード出力、インタビュー記録を多角的に検証（Triangulation）し、失敗タイプ、原因、緩和策をコード化。
  • 量的分析（ロジスティック回帰）: 「LLM 放棄」の有無を従属変数とし、回答の有用性、タスク完了度、プロンプト回数、コーディング経験などを独立変数として分析。

3. 主要な貢献と発見 (Key Contributions & Results)

3.1 失敗の分類（9 種類の失敗タイプ）

LLM の失敗は、以下の 3 つのカテゴリに分類される 9 種類のタイプに集約されました。

1. 不完全または誤った回答 (Incomplete or Incorrect Responses)
   • F1 不完全な回答: 大規模なコードやスクリーンショットを提示しても、重要な部分が省略される。
   • F3 前提条件の欠落: 依存関係のインストールやファイル設定など、実装前の必須ステップが指示されない。
   • F7 誤った回答: バグを含むコードや論理的に誤ったコードを生成する。
2. 認知的過負荷と情報管理の失敗 (Cognitive Overload & Information Mismanagement)
   • F2 圧倒的な回答: 多段階のタスクに対して、構造化されていない長大な回答が返され、必要な部分の抽出が困難になる。
   • F4 過剰に複雑な回答: シンプルな解決策で済む場面で、不必要に高度な技術（例：CSS の nth-child など）を提案する。
   • F8 誤った画像生成: 視覚的な出力を要求された際に、不正確な画像を生成する。
3. 文脈の喪失と無駄な努力 (Lack of Context Retention & Redundant Effort)
   • F5 文脈の欠如: 会話の文脈を忘れ、以前の指示を無視して一般化された回答をする。
   • F6 無関係な回答: 曖昧な質問を誤解し、的外れな回答をする。
   • F9 プロンプト変更への無反応: ユーザーが指示を修正しても、同じ回答を繰り返す。

3.2 失敗の根本原因 (12 要因)

失敗は「ユーザー側の要因」と「LLM 側の限界」の両方に起因します。

• ユーザー側: 曖昧なプロンプト、タスクの過剰な委任、回答のスキミング（読み飛ばし）、技術用語の不足など。
• LLM 側: ユーザーの専門性を無視した回答、ファイル操作のサポート不足、コードの局所化（どの部分を変更すべきか）の欠如、視覚出力の限界、検証機能の欠如、指示の無視など。

3.3 緩和策と放棄の決定

• 緩和策: ユーザーは「タスクの細分化（スキャフォールディング）」「プロンプトの明確化」「外部ソースへの参照」「手動デバッグ」などの戦略を用いて失敗を克服しようとしました。
• 放棄の要因: 17 名の参加者（全体の約 65%）がタスク完了中に ChatGPT を放棄しました。
  • 統計的発見: 量的分析により、「役に立たない回答（Unhelpful responses）」を受け取ると、放棄する確率が約 11 倍（オッズ比 11）に跳ね上がることが示されました。
  • プロンプト回数の効果: プロンプトを 1 回増やすごとに、放棄する確率は 17% 低下しました（粘り強い対話が放棄を防ぐ傾向）。
  • 経験の影響: コーディング経験が豊富な開発者ほど、LLM の失敗に耐性があり、放棄率が低い傾向がありました。

3.4 モデルの進化（GPT-5.1）の影響

GPT-5.1 での再現実験においても、上記の失敗カテゴリや緩和戦略はほぼ同様に観測されました。

• 単発のコード生成能力は向上しましたが、多ターン対話における文脈維持、編集の局所化、一貫性などの根本的な相互作用の崩壊は解消されていませんでした。
• ユーザーの行動パターン（失敗への対処法や放棄のタイミング）はモデルのバージョンアップによっても大きく変化しませんでした。

4. 意義と示唆 (Significance & Implications)

4.1 理論的意義

• LLM 放棄の動態的理解: 従来のツール採用研究が「導入時の判断」に焦点を当てていたのに対し、本研究は「対話の過程で蓄積する失敗」がどのように「放棄」という行動に至るかを解明しました。
• 人間-AI 相互作用の新たな視点: LLM は静的なツールではなく、共適応的なパートナーであり、その失敗は単発のエラーではなく、対話の軌跡（Interactional Trajectories）として蓄積することを示しました。

4.2 実用的示唆

• LLM デザインへの提言:
  • ユーザー適応: ユーザーのスキルレベルに合わせた回答の調整（CC1 の改善）。
  • 文脈管理: 長文対話における文脈の維持と、変更箇所の明確な提示。
  • 非生産的ループの検知: ユーザーが「プロンプトの穴（Rabbit-hole）」に陥っていることを検知し、代替案や外部リソースを提案する機能の必要性。
• 開発者への示唆:
  • LLM は「自律的な問題解決者」ではなく「拡張ツール」として位置づけるべき。
  • 完全なコード生成を期待するのではなく、断片的な支援を受け取り、手動で統合・検証するワークフローが重要。
  • 経験の浅い開発者は特に、LLM の出力を盲目的に信頼せず、批判的な検証と外部リソースの併用が必要。

4.3 結論

LLM の回答精度の向上（ワンショット性能）だけでは、複雑な SE タスクにおける信頼性の高い協働は実現できません。失敗の蓄積がユーザーの放棄を招くメカニズムを理解し、対話の質（文脈維持、適応性、検証）を高めることが、LLM をソフトウェア開発に効果的に統合するための鍵となります。