LLMコーディングエージェントが依然として苦手な2つのこと
(kix.dev)- LLMコーディングエージェントは、コピー＆ペーストのようなコード移動作業を自然に実行できない
- コードのリファクタリング時に、記憶に頼ったコード記述方式のため一貫性を保証しにくい
- 問題解決の過程でほとんど質問せず、推測ベースの試行に終始する
- 人間の開発者は曖昧なときは質問を通じて問題を明確にするが、LLMは壁にぶつかるまで試行を繰り返す
- こうした特性のため、LLMエージェントは人間の開発者の代替ではなく、自信だけが先行するインターン程度と認識される
LLMコーディングエージェントの主な限界
最近、LLMをコーディング支援ツールとして活用しようという試みが進んでいるが、それでも人間の開発者から見ると不自然に感じる点がある。この記事では、LLMコーディングエージェントが特に使いにくさを感じさせる2つの理由を明確に説明する
1. コード移動とリファクタリング手法のぎこちなさ
- LLMは実際の「コピー＆ペースト」操作を行わない
- たとえば、大きなファイルを小さなファイル群へリファクタリングするよう依頼すると、LLMはコードブロックの一部を「記憶」し、元のファイルでは
deleteコマンドを使う一方、新しいファイルには「記憶した」コードをwriteコマンドで書き込む - 「cut」や「paste」のツールを使わず、すべての修正がメモリから復元される
- 人間の開発者はコード移動時に「コピー＆ペースト」によってコードが一致しているという確信を持てるが、LLMにはそれが保証できない
- これまでのところ、Codexだけが
sedやawkコマンドを使って人間の「コピー＆ペースト」操作をまねようとする試みを一部見せたが、完璧ではない
- たとえば、大きなファイルを小さなファイル群へリファクタリングするよう依頼すると、LLMはコードブロックの一部を「記憶」し、元のファイルでは
2. 質問のない問題解決アプローチ
- LLMの問題解決プロセスもまた、人間とは大きく異なる
- LLMはほとんど質問をせず、数多くの仮定に基づいて問題を解決しようとする
- 人間の開発者は、大規模な変更や状況が明確でない場合には常に質問によって状況を確認し、「悪い質問はない」という前提で行動する
- 一方でLLMは、ひたすら試行を繰り返し、問題が起きるとさらに強く繰り返す傾向がある
- プロンプトを過度に設計して質問を促すこともできるが、Rooなど一部のツールを除けば、このような挙動はあまり見られない
- 根本的には、LLM開発企業が**「より速いコード生成」に焦点を当てたRL（強化学習）**を適用してきたためかもしれない
結論
- こうした特性から、LLMはまだ人間の開発者を代替するには不十分である
- 実務では「自信過剰なインターン」程度の能力を示す
- LLMとの協業体験が完全に自然だと感じられない理由でもある
1件のコメント
Hacker Newsの意見
少し前に興味深い経験をした。コード関連ではなかったが、コードやその周辺領域でも十分起こり得る話だった（実際に同僚にも起きた）。HNで、15年前に可決された規制がなぜもっと一般化されなかったのかという議論の中で、私は当時の技術水準では一般的なケースを扱うのに不十分だったため、当時可能だった部分にだけ規制を適用したのだろうと推測していた（関連コメント）。数時間後に議論を見直すと、何人かが当時でもその技術は十分安価だったと言っていた。そこでLLMにこの話題に関する根拠を探させたところ、技術的限界が理由だという回答を得た。出典確認のために引用資料を見たら、実際に技術的限界を論じていたのはたった1件で、その出典がまさに私がHNに残したコメントだった。会社でその話をしたところ、同僚がGithubに「WindowsでXがどう動くか」という見解を書いたことがあり、後でGoogle検索をすると、LLMベースの回答がその見解を根拠に同じ主張をしていたという。だからLLMには「Xはどう動くのか？」ではなく、「もし誰かがXの動作を尋ねたら、引用に使えそうなリンク一覧を見せてくれ」と頼みたくなる
こういう聞き方は「sorting prompt」に近いと思う。Mike Caulfieldの関連文章で学んだテクニックで、私もコードを書くときに（例: Claude code slash command）活用している。LLMに単に答えさせるのではなく、資料調査や分類・評価を任せると、ずっと正確な結果が得られる
たいていの人も、HNで特定の話題のコメントを読むとき、「この人は何か知っていそうだから、とりあえず事実として受け取ろう」という感じで信頼しがちだ。直接経験したり検証済みの知識を得たりするのは実際とてもコストがかかるので、こうした「安い知識」にも結局は価値があると思う
LLMに根拠を求めたことがあるが、今のところLLMが自分の発言を本当に裏づける本物の根拠を出したことは一度もない
LLMはリンクまで捏造することがある。本当に実際の資料調査をさせるためのdeep researchモードが必要で、それでもリンク先の情報をどう解釈するかは結局学習に影響される
最近NotebookLMに6〜8件の信頼できる根拠（IETF、OpenID仕様と追加文書）を入れて、「OID4VPが許可しているcredential formatは？」という非常に単純な質問をしてみた。回答の90%は合っていたが、まったく根拠のないランダムなフォーマットを自信満々に追加してきた（まるで仕様の著者であるかのように）。怪しいと思って自分で仕様を確認したら、すぐ嘘だと分かった。今では「グラウンディングされた」LLMであっても、事実に対する信頼は完全に崩れたと言える
最近Codex CLIにHTMLファイルのリファクタをさせたのだが、期待していたようなコードのコピー＆ペーストではなく、LLMが記憶を頼りに新しく書いたコードに置き換え、そのうえコメントまで消した。複雑なリンクが40個連続するセクションがあり、デプロイ直前の最終確認として1つずつクリックしたところ、前半は正常だったのに途中から31個のリンクがすべて404になった。ドメインは問題ないのにURLパスだけが変わっていた。gitコミットで以前のURLを確認すると、LLMが実在しないパスにURLを「幻覚」で書き換えていた。こういう微妙で静かに入り込むエラーは本当に危険だ。必ず注意しなければならない
最後のポイントは非常に重要だと思う。「とても微妙で静かに入り込むミス」のせいで、LLMが人間並み、あるいはそれ以上に仕事をこなしても、同じやり方では扱えない。特にコードレビューは従来、問題を防ぐための重要な層だったが、ここで確認すべきエラーの種類が変わるなら、従来のコードレビュー手法は非効率になる。以前ならコードの大量移動時には、ブロックがそのまま移ったと仮定して、より高レベルの点に注目できた。しかしLLMのリファクタでは、「移動された」コードが実際には要約・再構成された「新規」コードかもしれないので、すべての文字を見なければならない。だからPull Requestの説明に「AI使用」セクションを入れて、どこでどうAIを使ったのかヒントを残せば、レビュー時に重点的に確認すべき領域を把握しやすいと思う
私もコードや調査の質問を投げると、似た経験を頻繁にしてきた。LLMは最初はうまくやるが、N回目以降になると勝手に内容を作り始める。最近旅行前にGeminiに最新情報として醸造所の一覧を頼んだら、すでに閉業した場所や臨時営業だった場所を平然と含めてきた。営業時間リンクの追加と、すでに閉業した場所の削除まで指示したのに、一覧の前半にしか反映されず、後半ではまったく関係のない修正をしたり、閉業した場所をまったく消さなかったりした。それでも毎回、完璧に調査したと自信満々に答えてくる
コードの話ではないが、一度イベント案内文のスペル・文法だけをチェックしてほしいとLLMに頼んだ。LLMは少し修正した版を返してきたが、日付をこっそり1日後ろにずらしていた。幸い気づいて直したが、とても単純な作業でも盲信してはいけないという教訓を得た。簡単で明確な一文のプロンプトであっても、LLMは驚くようなことをする一方、ときには最も単純なことですら予想外に間違える
5分前にもClaudeにコードへデバッグ文だけ追加してくれと頼んだら、正規表現をこっそり変えられた。diffなら簡単に見つかるが、大きな変更では本当に見落としやすくなる
デプロイ直前に40個のリンクを全部確認し直したのは賢明な判断だった。ただ、Codexが終えた後に
git diffも見ず、そのままmasterに上げたというのは少し驚くその記事の主張には同意する。ただ私が思う最大の問題は、エージェントがコードリポジトリのごく一部しか見ていない点だ。既存のヘルパー関数を知らずに、同じものを何度も新しく作ってしまう。UI開発では全体のUI構造を比較できないため、一貫性のないコードが繰り返される。結局、人間が「このファイルのヘルパー関数を参考にしろ」「この実装のようにしろ」「この文書は必ず読め」など、正しいコンテキストをきちんと与えなければならない。適切な文脈を直接与えれば、エージェントの活用度は大きく上がる。参考までに、もう1つの問題は大規模モノレポでフォルダ構造をたどるのが苦手で、たとえば下位ディレクトリで
npm testを実行することすらまともにできないケースが本当に多いことだまさに私が経験している問題と同じだ。最近Cursorで新機能を実装した200行あまりのコードをレビューしたが、実際に必要だったコードはわずかだった。ユーティリティライブラリにすでにある関数を見つけるのは本当に面倒なので、そのまま見過ごしてしまう。5年前ならこうしたレビューは新入社員のオンボーディング的な意味合いが大きく、見つけてあげることが重要だったが、今はCursorなどでコード量だけが増える一方、開発者本人も構造を知っていながら会社の方針であえてそうしている場合が多く、生産性が落ちていると感じる
npm testのようなコマンドを下位フォルダで実行するのはいつも問題だった。Vite/Reactフロントエンドと.NETバックエンドに分かれたrepoで、npmコマンドが失敗するとパニック状態になり、何度繰り返しても解決できず無駄なトラブルシューティングばかり繰り返す。一度はCLAUDE.mdに常にまず現在ディレクトリを確認するよう指示を書いたが、それでもランダムにパスを忘れる問題が残った。そこでrun-dev server restart、run-dev client npm installのように、どのディレクトリからでも通るaliasを追加し、純粋なdotnet/npmのようなコマンドは禁止リストに入れて、AIが直接プロジェクト説明書を参照してaliasを使うよう強制した。この方法がまだいちばん安定していたが、ここに至るまでかなりの時間と労力、ストレスが必要だった大規模コンテキストモデルがツールコールとして活用されるといいと思う。Gemini chatにはgithub全体のリポジトリを取り込む能力がある。新しい関数を書く前に、すでにコードベースに同じものがあるか確認してくれる「not-invented-here」ツールがあったらどうだろう。もちろん、誰かがすでにそういうツールを作っていないか先に調べるべきだろうが
だからclaude.mdのような文書が必要になる。自分たち独自のルールに従わせるには、必ず文書化が必要だ
実際こういう状況は、シニアエンジニアが実務で同僚と働いているとよく遭遇することでもある
文中で引用されていた部分には完全に共感する。LLMが上級開発者を置き換えられない点には同意する。正気の人間なら、現時点でそんなことを言うのはあり得ないと思う。ただ、性能の低い、あるいは中程度の開発者はすでに置き換えられていると思う。たとえば私たちの組織には6か月ブートキャンプ出身者が3人いたが、当時は良い開発者を見つけるのがあまりにも難しかったので採用した。しかし実際には本当に簡単なミッションですら苦戦し、毎回私がレビューでコードを全部整理しなければならなかった。その後AIツールが指数関数的に良くなり、この人たちのパフォーマンスを超えた。結局2人は解雇され、残る1人は自発的に辞めた。最近ではジュニア開発者の採用もほとんどせず、ブートキャンプ出身者は絶対に採らない予定だ。周囲も似たような状況で、そのためかブートキャンプ業界自体が消えつつある。AIが今後良い開発者まで置き換えられるかは分からないが、現時点のデータを見る限り、明らかにものすごい速さで進歩している。否定的な意見は現実から目を背けている。アメリカ初期には人口の90%が農業に従事していたが、今では2%にすぎない。それでも食料生産量と多様性はむしろはるかに大きくなった。これもすべて技術進歩の結果だ。同じことが開発業界でも急速に繰り返される可能性があると思う
もちろん技術で食料生産量は増えたが、実際には栄養価が低く、毒性が増したのも事実だ
ブートキャンプ出身者が成長できなかった原因をどう考えているのか気になる
さらに重要な教訓は、LLMがかなり単純な課題ですら、相当量の指示と監督なしには非常に脆弱だという点だ。私の小さなプロジェクト（2.5K行）でパーサのリファクタを頼んだところ、計画はもっともらしく見えた。段階ごとにチェックポイントを置いて順番に進めさせたが、実際に「旧構造は削除されたか？」「新構造に置き換えられたか？」と聞くたびに、「いいえ、そのまま残っています」という答えが返ってきた。80%のテストが失敗し、具体的な修正方向まで示しても、「リファクタ」という抽象的な作業では常に同じ問題で失敗する。結局、かなり細かく「どのクラスで何を変えろ」まで指示を書かなければならない。この程度なら独立して任せられず、LLMを使う意味自体が薄れてしまう
私の経験とは少し違う。typescriptで作った式ツリーパーサ（tinqerjs.org）は、自分で書いたコードは0で、Codex+Claudeだけで2週間（パートタイム）で完成し、数百のテスト（重複含む）もすべて追加した。ORMも作ってみたが、LLMを使えば少なくとも4〜10倍の時間短縮が可能だった。監督もほとんど不要で、結局は用途とプロセスの確立が結果を分けるのだと思う。LLM活用に慣れた開発者たちも、それぞれ独自のワークフローを構築しており、いずれもテスト・文書化・コードレビューに焦点を当てているという共通点がある
「<リファクタ指示が細かすぎないと意味がない>」という問題は、「高レベルのステップをうまく分解して指示すれば、自分ひとりでやるよりはるかに速い」というアプローチに切り替える必要がある
やはり記事で指摘されていた「AIがcut-pasteではなく削除・再生成方式」という話につながる。実際、コードが少しずつドリフトするのは避けられない
どのモデル／ツールを使ったのか気になる。CursorやCopilotを使っていても、こうした小さなリファクタで継続的な監督が必要になる問題はよく経験した
LLMには役立つ部分が確かにある。たとえば今朝、PDF Metadataパーサのバグを、PDF仕様を深く掘らずにLLMの助けで修正できた。しかし大半の場合、成果物は自分でやるより効率が悪い。以前Codex Codeにユニットテストを書かせようとしたときも、いろいろセットアップはしてあったが、データmockingが面倒で任せたのだった。8回も試行し、手動修正まで必要で、エンティティがobsoleteでサービスでもはや使われていないことも理解できなかった。結果的には失望した。開発者を完全に置き換えるには足りないが、かつてのStack Overflowのように、不慣れなテーマで知識への露出や解決策の誘導役としてはかなり優秀だと感じる
「質問をより明確にさせるよう促すプロンプト」を過剰にエンジニアリングしているとは思わない。むしろ「明確でなければ先に質問しろ」とプロンプト設計するのは非常に効果的だった。良いプログラマなら、仕様が完全に伝わっているか、追加のclarificationが必要かを自分で判断できるので、AIが事前に必要な追加質問をするよう導ける
いくつ質問するかを直接指定することもできる。複雑なテーマでは20〜30個の質問をあらかじめ要求するが、結果はかなり満足できる。こうしたQnAを別ファイルとして保存し、次のセッションや別のエージェントと再利用するのも有用だ
このやり方のおかげで、私はもう昔のようにプロンプトを書かない。アイデアだけ投げて「必要なら質問して」と入れておけば、たいてい自分が思いつかなかったポイントをうまく突いてくれる
本文のcopy-pasteの話を見て着想を得て、clippy（macOSユーティリティ）にエージェント用バッファツールを追加した。clippyはMCPサーバーを備えていてシステムクリップボードとやり取りするが、今回は別のプライベートバッファを使うのが適切だった。追加した機能はbuffer_copy（ファイルから特定の行範囲をコピーしてプライベートバッファに保存）、buffer_paste（バッファ内の正確なバイト列を対象ファイルに挿入／置換）、buffer_list（バッファ内の内容確認）だ。たとえば「auth.pyの50〜75行をコピー」とエージェントが指示すれば、サーバーがファイルI/Oだけを直接行い、token生成や幻覚は一切ない。システムクリップボードにも影響しない。従来はAIが生成したコードをそのままクリップボードにコピーして活用することもできた。clippyの主目的はmacOSのpbcopy改善で、実際のファイル内容をコピーしてターミナルからSlackやメールに実ファイルそのものを貼り付けることだ。macOSでClaudeなどMCP互換エージェントを使う人はこちらを参照。
brew install neilberkman/clippy/clippyでインストールできるたいていの開発者も質問するのがあまり上手くない場合が多い。多くのことを当然視して省略する傾向が強い。25年の開発経験の中で、半分以上の同僚が2つ目の欠点を持っていた。私自身もキャリアの半分はそうだったので、なおさら共感する
「LLMsはcopy-paste（あるいはcut-paste）をしない」という本文の主張のように、コードを記憶して削除し、新しく書き直す方式で、だから毎回新しいwrite commandだけを出しているような感覚がある。リファクタでは実際には本当のcopy/pasteはそれほど多くなく、コンテキストベースのrecallだけで処理することのほうが多い。実務ではcopy/pasteコマンド自体がそれほど有用かどうかも不明だと感じる（少なくとも私のテストでは大差なかった）。むしろ反復的でコンテキストを多く消費する部分は、fastmodのようなツールでcodexやclaudeに「この部分を一括修正」させるほうが効果的だ。問題解決へのアプローチ自体が人間と異なるので違和感はあるが、十分にプランを立てながら対話すれば、アプローチ自体を大きく変えられるかもしれない
IDEなら複数ファイルにまたがって関数シグネチャや名前を即座に変更できるのに、LLMエージェントが試みると数分かけても正確に処理できないことが多い。実際のcopy/pasteサポートには明確な効用があると思う
copy/pasteはコンテキスト爆発を減らす役割が大きい。モデルがコードブロックの内容を記憶していなくても、必要なときにいつでもアクセスできるようになるからだ