エンジニアの生産性は2倍が限界？2026年、LLMコーディングの現実的な到達点

世間でよく耳にする「10倍の生産性向上」という言葉。しかし、2026年の現在、LLMを活用した開発現場で実感できる現実的な向上幅は2倍程度ではないでしょうか。AIの進化は目覚ましいものの、プログラミングの本質である設計や保守の難しさは変わりません。皆さんはどう感じていますか？理想と現実のギャップについて語り合いましょう。

これは最近見たHarness Engineering is not Enough: Why Software Factories Fail という動画で語られていたテーマを思い出させるね（警告：最後の3スライドは広告っぽいけど）。気に入ったのは、動画内でDexがさらっと触れていたソフトウェア開発の内訳図だ。- 25% 計画とチーム間の調整 - 25% コーディング - 25% テスト/検証 - 25% コードレビュー/リファクタリング。一つの議論として、エージェント型のコーディングツールを使えばそのコーディング部分を大幅に加速できるというものがある。つまりコーディング自体は2倍速になるかもしれない。でも、ソフトウェアエンジニアがやる仕事全体で見れば、それはわずかな効率化に過ぎないんだよね。

自分の考えでは、LLMとの付き合い方は、その分野に対する自信と、自分がその責任を負っているか、あるいは理解する必要があるかどうかで調整すべきだと思う。自分の中ではこんな感じかな。

• 学習段階：0.5倍〜1倍。システムプロンプトを「先生モード」に変更する。そのシステムやツールを習得するために生産性を多少犠牲にしても、後で確実に元が取れるからね。自信がつくにつれて徐々に先生モードの制約を緩めていくんだ。
• 実務レベル：2倍〜3倍。十分に慣れてくれば、かなりの生産性向上が実感できる。時間の大半は計画フェーズに費やす。これは自分が詳しくない、あるいは興味はないけれど、とにかく仕事を終わらせなければならない分野でのモードだね。
• マスターレベル：10倍以上。自分はWebフロントエンドを12年以上やってるから、計画や実装をすぐに確認できるし、最初のプロンプトを投げる時点で何を作りたいかほとんど分かっている。

※1倍＝AI導入前の自分の速度

前提には同意するけど、この視点は「何があってもやるはずだった仕事」にしか当てはまらないと思う。これらのツールの真の力は、これまで時間やモチベーションがなくて諦めていた「やってみたかったアイデア」を形にできることにあるんじゃないかな。

つまり比較すべきは「LLMあり・なしで同じものを作る」ことではなく、「そもそもLLMがなければこれを作るつもりだったか？」という点。この場合、生産性の差はもっとずっと大きくなるよ。

自分はちょっと変わった外れ値かもしれない。アカデミア出身ということもあって、1倍から無限大倍（つまりAIなしでは決して触れなかったであろうタスク）まで幅広いね。

使い慣れたもの（R言語とか）だと、いい感じにコンパクトなスパゲッティコード（長いパイプ演算子 %>% を使ったもの）を書ける。画面に収まりきらないようなスクリプトは落ち着かないし、自分のスタイルは自分にしか分かりにくいものかもしれない。誰かに教える時も特にそうしてるわけじゃないし。

AIにやらせると、そういうコードを何千行も、一度だけなら1万行とか出してくる。全部ソースに含めて動くならかっこいいけど、それを管理・修正していくのは正直楽しくない。

でも、論文の再現をワンショットでできるようになったのは大きいね（昔は1時間かかっていたのが、最近は劇的に良くなった）。これは数年前なら手を出さなかったタスクだよ。Githubがない、あるいはあっても役に立たないようなメソッド論文の話だけどね。

自分はおそらく5倍〜10倍の範囲にいるけど、うちはかなり小規模なチームで、長年アイデアのバックログを溜め込んできたからね。自分がアーキテクチャを主導していて、作業に対する完全な裁量権がある。自分と同じような立ち位置の人なら、ただスピードを上げたいがためにプロセスや儀式でがんじがらめになっている大企業の人よりも、ずっと大きな成果を出せると思う。

完全に場合によるよね。肝心なのは「平均してどれくらい生産性が上がるか」でしょ？

一度、ベンダーと共有するためにコードベースを完全に解体しなきゃいけないタスクがあったんだ。自分の見積もりでは2週間と伝えていたんだけど、Claudeに投げたら1時間で終わった。変更を確認したら完璧だったよ。もちろんこれは例外的な例だし、かなり基本的なコードベースだったけど、実際に起こったことだ。

全体として見れば、もし8時間ぶっ通しで働く精神力があれば、「通常」の5倍のパフォーマンスを簡単に出せるだろうね。でも、そんなレベルで毎日働けるわけじゃないし。それに自分は慎重すぎてテストや検証をやりすぎるから、そもそも足の速い開発者ではないという自覚もある。

もし2倍の速度が出ているなら、それはあなたの調整能力やインテリジェントな作業の計画能力が限界に達しているからかもしれない。今すでにプラトー（停滞期）にいて、たとえモデルが今の2倍強力になったとしても、あなたの人間としてのスループットはやはり2倍のままという可能性が高い。

私たちには誰しも、注意深さ（あるいは細部へのこだわり、時間、エネルギーなど）が不足して、それ以上うまく管理できなくなる限界がある。

マネージャーが2人のチームならうまく管理できても、20人のチームだと管理できなくなるのと一緒だ。

昔はコードが書けることが生産性の大きな要因だったけど、今はエージェント的なチームと連携する上で要求される、他の認知的・メタ認知的能力に比べればその重要性は下がっているよ。

最近、Claude Codeを使って、データベースと2つのアプリが連携するツールを作ったんだ。ドメイン知識はある程度あったし、最小限の成果物を再利用して構築していくつもりだった。

OPの説明は自分の経験とかなり重なるね。LLMのおかげで多くのことを素早くこなせたけれど、実際にユーザーがツールに触れて「これいいね」「いや、ここが違う、修正が必要だ」「誰も思いつかなかったけど、これがあるとXYZもできるようになるのでは？」といったフィードバックをくれることに代わるものはない。そのやり取りには現実的な時間がかかるし、コーディングエージェントだけで代用できるとは思えない。

2つ目にコード構造の問題。定性的な話だけど、Claudeは目標に向かって効率的に動くものの、こちらの心が読めるわけじゃない。2つのクライアントアプリで特定のパターンを共通化したいとか、最短距離の解法が将来的な拡張性や汎用性を損ねているといったことは理解できない。こちらが指示しない限りね。修正を後回しにすると、LLMが自分で生成したスパゲッティコードを解こうとしてトークンを無駄に消費するだけだし。結局、意図を直接コードで書くか、英語で詳細な指示を書くかに関わらず、すべてに時間がかかるんだよ。

AIにどっぷり浸かっている知り合いがいるんだけど、エージェント的なツールを何でもかんでも信じ込んでいるんだ。新しいiPhoneでメールを設定中に問題が起きた時、Claudeにサーバーへテストを投げさせたらしい。実際には何もテストなんて行われてなくて、Claudeは「いろいろ試してみたけどダメだった」という長文のレポートを捏造して、全部サーバーのせいにしていただけだった。

実際の原因：ただパスワードを打ち間違えていただけ

LLMにはできないと言われているようなことでも、決定論的なコードを生成させてから、その結果に対して人間が解説を加えていくというアプローチをとれば、かなり引き出せるよ。あまりネガティブになりすぎず、何かの参考になれば。