世界を動かす技術を、日本語で。

シャベルウェアはどこに?AIコーディングの主張が合わない理由

概要

  • AIコーディングツール の生産性向上に対する疑念
  • METR研究 や自己検証で明らかになった効果の限界
  • 業界全体で 出荷ソフトウェア数に顕著な増加なし
  • 開発者や企業が AI導入圧力 に苦しむ現状
  • データと現実 が誇大広告と大きく乖離

AIコーディングツールの幻想と現実

  • ソフトウェア開発 歴25年以上の開発者による現場実感
  • AIコーディング 初期は期待していたが、最近の研究(METR)で疑念が生じた経緯
  • METR研究で、 開発者自身の生産性評価が不正確 である事実
    • AI導入で「20%速くなった」と思い込んでいたが、実際は「19%遅くなった」実例
  • 自己検証 のため、タスクごとにAI利用/非利用をコインで決定し、作業時間を計測
    • 6週間の記録でも 統計的有意差なし
    • メディアンで21%遅くなる傾向、METR研究と一致
  • AI導入による2倍速等の劇的な生産性向上は一切観測できず

業界の誇大広告と現実の乖離

  • Cursor 「異常な生産性向上」や Claude Code 「より早く良いソフトウェア」などの宣伝文句
  • GitHub Copilot 「Delegate like a boss」、 GoogleOpenAI の生産性向上主張
  • 開発者の14%が「AIで10倍生産性」と自己申告
  • 経営層や業界全体がFOMO(取り残される恐怖)でAI導入を急ぐ
    • 企業の「AIファースト」化、リストラや給与抑制の正当化材料
  • 実際には、AI普及後も新規ソフトウェアリリース数は横ばい
    • Indieブームや「シャベルウェア洪水」は発生せず
    • 数十TBのデータ分析でも リリース数グラフは平坦

データが示す現実

  • AI普及による新規アプリやゲームの爆発的増加は皆無
  • 「10倍生産性」主張が正しければ、 世界中のソフトウェアリリース数は倍増しているはず
  • GitHub等の新規プロジェクト数にも顕著な変化なし
  • AI導入が現場開発者の生活に悪影響
    • ツール未導入で解雇されるケース
    • 新しい職場への転職不安
    • 「プロンプト力」習得プレッシャーと自己否定感

開発者へのメッセージ

  • AIツール利用を強制されている開発者へ
    • もし「使いづらい」「遅くなる」と感じているなら、それは正常な感覚
    • データが直感を裏付けている
    • 「今まで通り」で問題なし、焦る必要なし
  • 経営層や同僚が「AIで10倍速」と主張したら、証拠を求めるべき
  • 本当に重要なのは出荷数のみ、AI導入でそれが増えていない現実に注目

よくある反論への反論

  • 「プロンプト力が足りないだけ」
    • データ上、10倍生産性の新規開発者は存在しない
    • 14%の「10倍速」自己申告が事実なら、リリース数は倍増しているはず
  • 「新技術だから時間がかかる」
    • 既に数年経過、今も効果が見えないのは問題
    • ユーザーの人生や雇用に直結する問題
  • 「プロンプト習得で成長」
    • Copilot調査でも6ヶ月で29%→34%の微増のみ
    • 劇的な効率化は見られない
  • 「品質向上で出荷数は変わらない」
    • コード品質自体も向上していない現状
    • テストやTDDも減少傾向
  • 「独自ドメインや.aiドメイン増加」
    • AIブーム便乗による一時的な現象、全体数の急増なし
  • 「大企業は会議が多く、個人開発は別」
    • 個人開発でも新規プロジェクト数は増えていない

AIファースト文化の矛盾

  • AIで10倍速になれるなら、なぜ公式トレーニングやガイドが機能しないのか
  • 「自分で試して学べ」という曖昧な指示
  • 公式プロンプトガイドも効果が薄い現実

結論 : AIコーディングツールの 劇的な生産性向上データで裏付けられていない。 開発者は 過度なAI導入圧力 に惑わされず、 自分の直感と実績 を信じて行動すべき。

Hackerたちの意見

なんか分かる気がする。CEOたちが「AIのおかげで既存の開発者が10倍生産的になったから、開発者を雇わない」って言ってるけど、その生産性向上が本当なら、全員雇おうとするんじゃない?同じ投資で10倍の生産性が得られるなら、もっとお金をつぎ込むはずだよね。もしかしたら、これらのグラフは、経営陣がAI革命をうまく活用して、コストを削減しつつ生産性をそのままに保ってるってことを示してるのかも。

今日は、限界効用について学ぶことになるよ :) ビジネスやアイデアの中で、利用できる人数や行動には限界がある。要するに、問題に対して無駄にリソースを投げつけているだけ。解雇が多い理由は、AIが効率を生んでいるから。みんなが気づいていないのは、AIロボットやGPUが人間を1対1で置き換えるわけじゃないってこと。1人ができる作業量を置き換えるんだ。それが結果的に1人の従業員を減らすことになる。あなたの仕事がAIに奪われるわけじゃなくて、もう始まってる。でも、どれだけの人間が必要かが新しい供給と需要のポイントで、仕事がどれくらい続くかに関わってくる。常にもっとクリエイティブな頭が必要とされるけど、今はそれが不足してる。職を探しているソフトウェアエンジニアがどれだけいるか、信じられないよ。年収10万ドルから20万ドルの仕事を探してるのに、ビジネスにどれだけお金を節約できるか全然分かってない。学校で創造性が潰されちゃったんだ。誰かに指示されるのを待っていて、誰もいないときにどうしていいか分からなくなってる。みんな行き詰まってる。見えているのは能力の欠如じゃなくて、方向性をコントロールしたり、追う価値のあるアイデアを作る能力の欠如なんだ。

こういうC-suiteの人たちも、残っている人たちがAIに置き換えられることを期待している。彼らはホッケースティックの「AGIがすぐそこにある」という話に乗ってる。私はそうは思わないけど、少なくともそれなりに論理的ではあるよね。本当にそう信じているなら、もっと開発者を雇いたいとは思わないはず。

利益率が下がるにつれて、どこかから価値を絞り出さなきゃいけなくて、それが労働の雇用や解雇、報酬に影響するから、そういう結果に強いバイアスがかかるんだ。AIの魅力の99%は労働コストの削減にあるし、雇用はそれに逆行する。とはいえ、AIの生産性主張は信じてないけど、理論的にあなたの仮説に寄与する要素を指摘してるだけだよ。

同時にいくつかのことが真実であり得るよね。1. LLMは一般的なタスクに対して開発者の生産性を一律10倍にはしない。2. LLMは限られたタスクのセットに対しては劇的に生産性を上げる。3. LLMは単純作業を自動化できて、時間的には人間よりかかるかもしれないけど、実質的にはバックグラウンドで作業が進んでる。LLMは新しいAPIやライブラリについて、俺が自分で調べるよりもずっと早く理解させてくれる。知らない言語で少しのグルーコードを書く必要があるとき、LLMは時間を節約してくれるし、二度と使わないかもしれないことを学ぶ必要もなくしてくれる。既存の大規模なコードベースを修正するのは?生産性はせいぜいトントンだね。新しいウェブサイトの足場を作るのは?LLMはそれが得意だよ。クラスのモックを書くのも?LLMはモックライブラリの使い方をよく知ってて、俺よりずっと早く終わらせてくれる。特に、複雑なモックを書くのは年に数回しかやらないから、その間にやり方を完全に忘れちゃうし。新しいコードベースをナビゲートするのも?LLMは約70%くらいはいい感じだね。過剰に設計されたWTFプロジェクトを開いたことがあるなら、HTTPルートがどこで定義されているかを見つけるだけでも大変だよ。「おい、クロード、このプロジェクトのルートエンドポイントはどこで定義されてるの?認証のための依存性注入された関数はどこにある?」正しい道具で、正しい仕事をしよう。釘にハンマーを使うのはやめて。

新しいウェブサイトのための足場を作るの?LLMはそれが得意なんだ。すごく得意で、記事の著者が示したすべての統計は、既存のコードベースではなく新しい開発に基づいているにもかかわらず、せいぜい横ばいだったよ。

依存関係がどこから来るのか分かるなら、もっと調べてみないと。インジェクションのせいで他の人のコードベースが手に負えなくなるのが本当に嫌なんだ。「フレームワークは数十億行のコードをスキャンして実装を見つけることができるし、君もできるよ!」

LLMは新しいAPIやライブラリについて、俺が自分で調べるよりもずっと早く理解させてくれる。すごいスピードアップだよ。知らない言語でちょっとしたグルーコードを書く必要があるとき、LLMは時間を節約してくれるだけじゃなく、たぶん二度と使わないであろうことを学ばなくて済むようにしてくれるんだ。これについては、気持ちが揺れ動くんだよね。同じような感情を抱いたこともあるけど、あまりにも頻繁にカーテンの裏を覗いて、ドキュメントを読んで外部依存関係に慣れた後、LLMの返答が逆説的に慣習に従っていなかったり、オンラインで見つけたコード例に問題を無理やり合わせようとしていたり、機能を不適切に使ったり、シンプルにできることをわざわざ遠回りしてやったりすることに気づくんだ。近くで見ると魔法のように感じるけど、あまりに近づきすぎると理解している気になってしまうのが心配なんだよね。

釘にハンマーを使うのはやめて。え、じゃあ釘には何を使えばいいの?

LLMは雑務を自動化できるけど、人間よりも時間がかかることもある。それでも、実際にはバックグラウンドで作業が進んでるんだ。バックグラウンドで監視なしにできるこの雑務って何なの? AI推進派は、成功している具体的なタスクについてもっとはっきり説明するべきだと思う。あまりにも曖昧で手を振るだけの説明にはみんな疲れてきてるよ。

俺の経験とも合ってる。ちょっとしたリファクタリングやスキーマからの型定義なんかでは役立つけど、それ以上のタスクになると、見落としがあって再作業が必要になることが多い。未来には俺の言葉を食うことになるかもしれないけどね。一方で、最近、経験の浅いエンジニアが大きな機能を実装しようとして、LLMが出すものを「良い」と受け入れてしまって、実際には以下のような問題があることに気づいていないのを見かけた。- 既存のスタイルガイドやパターンに従っていない。- 適切なライブラリが複数あるのに、ゼロからロジックを実装してしまって、今はそのコードを所有することになる。- すべてのことをしようとする巨大なPRになっている。

「適切なライブラリが複数あるのに、ゼロからロジックを実装することで、今私たちが所有するこのコードは、すべてのことをしようとする巨大なPRになっている。コードの量によっては、これをポジティブにしか見れないかな?50行のコードのために巨大なライブラリを引っ張ってくることが多すぎる。」

確かに、こういったことの発見は、今の仕事で私がまだ解決しようとしていることで、少なくともLLMsを使ってコード(ベース)を分析したり検索したりすることはできるかもしれない。ただ、チームメンバーがかなり独立して作業できる必要があるから難しいんだよね。でも、内部ライブラリの知識がすごく孤立しちゃうこともあるし。

グリーンフィールド開発の経験は全然違うよ。プロジェクトの初期段階では、LLMの意見はプロジェクトを始める個人と同じくらいの価値しかない。コーディングスタンダードや他の項目はまだ確立されていないからね。バグだらけの半端なコードでも、プロジェクトはまだデモできる状態なんだ。1つのプロジェクトをデモする代わりに5つをデモできるのは大きなプラスだよ。

これらの主張は、話題がこんなに深刻でなければ重要ではない。テックリーダーたちは、競合他社が自分たちが見逃している大きな利益を得ていると信じて、FOMOに陥っている。これが、彼らをAIファースト企業としてのブランド変更に駆り立てたり、新たな生産性の物語で解雇を正当化したり、AIが根本的に価値の方程式を変えたという前提のもとで開発者の給与を低く抑える原因になっている。これが今の俺の最大の問題。職場で解決しようとしている問題は、慎重な計画と実行が必要で、AIは全く役に立っていない。マネージャーからは、「私の最新プロジェクトの納期が元の見積もりの20%に短縮された」と言われた。「私たちはAIファースト企業だから」と。SVPやPMの間の大騒ぎは本当に異常で、こんなの見たことない。

「マネージャーが、私の最新プロジェクトの納期が元の見積もりの20%に短縮されたと言ってた。なぜなら、私たちは『AIファーストの会社』だから。神よ、彼らを許してください、彼らは自分たちが何をしているのか分かっていません。」

SVPやPM、あるいはラインマネージャーがAIを使って、2ヶ月のインターンプロジェクトを1週間で実装するのを見てみたいな。--- [1] 一般的に、インターンの時間の半分はコーヒーマシンを探したり、時間通りに出社する方法を学んだり、他のインターンとミニゴルフを楽しむイベントに参加したり、ユニットテストが存在することを発見したりするのに使うんだ。

マネージャーが言ってたんだけど、最新プロジェクトの納期が元の見積もりの20%に削減されたんだって。「AIファーストの会社だから」って。もしインシデント対応も自動化されたLLMに任せられるなら、まあ、いいんじゃない? CEOの思い通りにさせて、評判の代償を払わせればいい。うまくいかなかったら、LLMがコードを書いてなかった日の状態にgitリポジトリを戻せばいいんだし。ちょっと冗談半分だけどね。

もし著者がこれを読んでいるなら、最近のソフトウェア開発の量に関して実際にステップ関数があることを証明する材料があるよ。具体的な数字は出さないけど、確かにかなりのコードを押し出している。オンラインに出てこない理由は、ほとんど自分のためと仕事のためにソフトウェアを書いていて、主な目標は「より良くする」ことで、「より早くする」ことではないから。もっとツールを使って、より良いインフラ、より良いログ、もっとプロトタイピング、もっと実験、もっと探求している。俺のオープンソースの仕事はこちらだよ:https://github.com/orgs/go-go-golems/repositories 。これは単発のものだけじゃなくて(vibes/やgo-go-labs/リポジトリにはたくさんあるけど)、お互いに積み重なっている長寿命のコードベースやフレームワークなんだ。

同じく。多くの日で、コードの出力の90%はClaudeが生成したもので、1日かかっていたことが今では1時間もかからずに終わる。私の個人的なOSSプロジェクトのかなりの部分もAIの助けを借りてる。見た目では分からないかもしれないけど、厳しいスタイルガイドがあって「AIスタイル」を抑えてるし、READMEでもAIの使い方についてあまり話さないからね。Intellisenseや構文ハイライトを使ったことも言うべきだと思ってる?

それが「意味がない」とか言ってるのに、生産性が上がってるってどうやって確信してるの? 何か証拠はあるの?

ここでの主張には完全に同意する。AIを使っても大きな生産性の向上は見ていない。ソフトウェアエンジニアが問題解決や識別、コンピュータコードへの翻訳を積極的に練習しないと、そういったスキルが衰えてしまう神経的疲労が起こると思う。そう、AIは未来の2倍や10倍の技術ではないと約束されていた。生産性の向上が既存のプライベートコードベース内で起こっているだけかもしれない。それでも、市場でのオファーの展開が明らかに改善されているはずなのに、それが見受けられない。俺のコンサルティング業務では、新しい創業者や気が狂ったCTOがAIの使用を推進し、最終的にはスパスティックなコードベースを扱うのに時間を費やすことになって、共同理解を築くことができない現象を定期的に目にしている。最近、エンジニアリングのベストプラクティスを再導入するためにアドバイザリー役やリテイナーを引き受けている。

ソフトウェアエンジニアが問題解決や判断、コンピュータコードへの翻訳を積極的に練習しないと、神経的な疲労が起こると思うんだ。そうなると、そのスキルが衰えてしまう… これはほとんどすべてのスキルに当てはまると思うし、自転車の乗り方でもそうだよね。確かに乗り方は忘れないけど、自転車と一体になって上手に操る能力は衰えてしまう。もしエンジニアリングでもそうなら、これは本当に警告として受け止めるべきだと思う。

ほとんどは「ジュニアは死んだ」という主張と共にコードが画面にスプレーされる動画以上のものではない。これが起こる「理由」は、リスクが高いからだと思う。経済が揺れている。テックの仕事が消えていく。AIが救世主になるという高い不安感があって、開発者や能力を置き換えるためにAIが必要だという群衆の間に半宗教的なものが形成されている。とはいえ、俺自身はAIで素晴らしい結果を得ているけど、やっぱり何をしているかを理解している必要がある。ほとんどの人はそうじゃない(初心者から中級者の範囲を超えて)。だから、誇張された主張でソーシャルメディアを埋め尽くしているのも驚きじゃない。もしAIの前にスーパーパワー(コードを書くこと)がなかったなら、そのスーパーパワーを持つことが平等化の手段として、他の全てのリソース(物質的、心理的など)を使って、1) スーパーパワーは良い、2) スーパーパワーは消えない、3) スーパーパワーの欠陥は無視すべきだという立場を維持することになる。どんなハイプサイクルでも、こういう人たちは淘汰されて、中間地点が見つかり、次の言い訳を待って何十億ドルも焼き尽くすことになる。

つまり、AIに関する話が多い中で、真実はかなり明白だと思う。特に、主流メディアの「科学」記事みたいに、いつも小さな情報を元に「すぐそこにある」みたいな大げさな主張をするのが多いから。

少なくとも俺の経験では、真っ白なキャンバスのプロジェクトでは優れているよ。何もないところから、基本的なものを作りたいときにね。ツールはたぶん、俺よりも早く新しいReactプロジェクトをセットアップできる。でも、実際の作業リポジトリで試すたびに、ほとんど役に立たなくなっちゃうんだ。だから、そんなに盛り上がるんだろうね。テクノロジーデモには完璧だけど、管理者は現実の世界で結果が出ない理由を不思議がるんだ。

新しいソフトウェアのリリースを見ていくのにいい視点だね。俺も、今頃は大きな増加が見られると思ってた。別の理論として、コードを書くことはソフトウェアリリースのボトルネックではなかったということがある。何を作っているのかを探求し、それをプラットフォームに載せるには時間と努力がかかる。一方で、AIツールで「間違った持ち方」をするのは本当に簡単だよね。時々、すごくいい日があって、やっと理解したと思うんだけど、次の日には他の方法でまだ間違って持っていることに気づく。ソフトウェア製品を作るのが難しい理由を理解するのがこんなに難しいのは哲学的に興味深い。そして、どうやってもっと生産的にするか。20年間ソフトウェアを作ってきたけど、まだ本当に分かっているとは思えない。

それに、プロダクトを作るとき、ユーザーがどう求めているかを見たり、後から気づいたエッジケースを修正したりする反復プロセスを早めることはできない。これがプロダクトを良くする要素で、ソフトウェアが成熟するのに10年かかるっていう記事がある理由だよね。: https://www.joelonsoftware.com/2001/07/21/good-software-take...

これが答えだね。プログラミングは、フリーランスの人間が書いたコードでもAIを使ったものでも、ソフトウェアを提供する上でのボトルネックじゃなかった。AIは、過剰採用の解雇を正当化する便利な口実に過ぎないし、今や「AIファースト」になったから、投資家がさらにお金を燃やすためにドアを開けているんだ。

答えは、今まさにそれを作っているってことだよ。エージェントが十分に良くなるまでは、AIは全然スピードアップしてくれなかった。今年の4月か5月になってやっとだ。今日、iMessageのアーカイブをスタンドアロンのウェブサイトにエクスポートするためのCLIを作ったんだけど、これには数週間かかるところだった。おそらく1、2日でホームブリューのフォーミュラとして出せると思う。今はiOSアプリも作ってるけど、手作業でやってたらもっと時間がかかってたはず。でも、意図的に時間をかけてるんだ。とにかく、投稿のデータはほとんど3月か4月で終わっていて、生成AIがコーディングに役立ち始めたのはその頃なんだ(Copilotは2022年11月から使ってるけど)。

参考までに、これは私の経験とかなり一致してる。AIの流行に乗るのは遅かったけど、データのカットオフ日直前にリリースされたモデルやツールの組み合わせを使ったことで意見が変わったんだ。友達からの印象では、多くの企業がこれらのツールを使うことにOKを出すまでにもっと時間がかかってるみたいだから、その採用による出力にはかなりの遅れがあると思う。ただ、METRの研究についても似たような懸念があって、生産性の結果に関する集計研究がもっと増えることを期待してる。

エージェントが十分に良くなるまでは、AIは全然私を早くしてくれなかった。それが今年の4月/5月だったんだ。5ヶ月前のことで、10倍の時間で言えば6年分だよ。

批判が出るたびに、ここ3年間の反応が「いや、使ってないからだよ、やっと良くなったんだ!」ってのがすごいよね。

ここにお手軽なものがあるよ…証拠付きで。背景としては、メッセージをLLM出力にエンコード/デコードするPythonパッケージのサイドプロジェクトを作ってるんだ。証拠として、使ってるツールが、入力したプロンプトや生成された解決策、コードの差分の要約を表示するマークダウンを作成してくれるんだ。詳しくはここで見てみてね: https://github.com/sutt/innocuous/blob/master/docs/dev-summa... 具体的な例としては、分岐のためにメモ化のレートコードスタイルのアルゴリズム実装を使ったよ。これを手作業で実装するのには数日かかるところが、仕様を書くのに約20分、解決策をレビューしてマージするのに20分かかったよ。興味があれば、ここで生成された差分を見てみてね: https://github.com/sutt/innocuous/commit/cdabc98

この説明に「ステガノグラフィー」って言葉を使ってほしかったな、READMEに書いてたみたいに。そうすれば、何をするものかが100%分かりやすくなるのに。