コード行数には、より優秀な広報担当者がついた
(curlewis.co.nz)- 開発者の生産性評価はコード量ではなく、顧客価値、売上、信頼性といった成果指標で判断すべき
- Google、Anthropic、OpenAI、Cursorの最近のAIコーディングに関する宣伝数値は、いずれもコード生成比率やコード行数のような量的主張に集中している
- GitHub Copilotの過去の「作業速度55%向上」という主張は検証可能な成果だったが、「AIが書いたコードの比率」は改善の有無と無関係に増えうる
- 実際の研究結果は割れており、Cui et al.の完了率+26%から、METRの「19%遅くなった」とその後の撤回、企業の90%が測定可能な効果なしとする調査まで、**組織単位の効果は約10%**程度
- AI導入は必要だが、成果測定はDORA指標、信頼性、意味のある変更の速度、売上、顧客価値といった検証済みの基準に基づくべき
コード行数指標の復活
- 15年前、SaaS企業の2人のシニア開発者のうち一方がもう一方より40%多くのコードを書いたという事実だけでは、より優れた開発者とは言えない
- 本当に重要なのは、何が**出荷（ship）**され、顧客・売上・安定性に貢献したかであり、コード行数やPR件数は何十年にもわたり悪い測定方法だと学ばれてきた
- 2026年に業界が前面に出している代表的な数値は、すべてAI作成コード比率に集中している
- Google: 新規コードの**75%をAIが生成**
- Anthropic: マージされた本番コードの約80%をClaudeが作成、エンジニアは四半期ごとに「8倍多くのコード」をデプロイ
- OpenAI: 同じく約80%
- Cursor: 「1日1億行以上のエンタープライズコードを作成」
- これらの数値はすべて量（volume）の主張であり、「AIが書いたコードの比率」はより洗練された宣伝文句を得たコード行数にすぎない
- これらの企業がいずれもAIベンダーである以上、採用率を大きく見せることが重要な動機として働く
以前は成果を主張していた
- 数年前は、重要な数値は規模ではなく種類そのものが違っていた
- GitHubの代表的な主張は、Copilotを使うと作業を55%速く完了できるというもの
- 批判は多かったが、これは成果（outcome）の主張であり、大胆で反証可能で、価値に関するものだった — 間違っていれば間違いだと証明できる
- 2026年の主張は、失敗しようのない構造になっている
- 「コードの75%がAI作成」は、デプロイ高速化・障害減少・顧客満足といった実際の改善と無関係に成り立ち、しかも上昇し続けうる
- ボリューム指標が失望を招くのは採用が頭打ちになったときだけであり、採用自体が本物であることには大半が同意している
- 主張は大きくなったが、語っている内容は少なくなった
看板には載らない部分
- その間に起きたのは、成果の証拠が複雑になったことだ
-
採用を支持する結果
- Cui et al.: 約5,000人の開発者を対象に完了タスク +26%、特にジュニア開発者で最大の改善 — ほとんど議論の余地がない
-
逆方向の証拠
-
METRの立場転換
- 2026年2月、METRは事実上この立場を撤回 — 後続の推定値では**速度向上（speedup）**へと反転した（誤差範囲は非常に広い）
- 開発者がもはやAIなしでの作業を拒み、エージェント作業にかかる時間を信頼性高く自己申告できなくなったため、研究設計そのものを破棄した
- 最新の立場は、2026年のAIは開発者の速度を高める可能性が高いが、その度合いをきれいに測定することはできない、というもの
-
企業単位の効果
- NBERの約6,000人の役員調査: 69%の企業がAIを活用中だが、約10社中9社が測定可能な生産性効果はないと報告
- 横断研究のコンセンサスは、組織単位で約10%向上という水準 — 有用ではあるが、「開発者がもう不要だ」というレベルではない
- それでも「19%遅くなった」だけを引用する懐疑論者もチェリーピッキングであり、研究は更新され続け、業界は測定対象そのものを変えている
AI版の虚栄指標
- これはAIベンダーの主張だけの問題ではない
-
成熟度モデルと梯子
- Carnegie Mellon SEIとAccentureは数日前、AI Adoption Maturity Model を発表 — 5段階・8次元で、「組織の95%は利益が出ていない」という統計をマーケティングに活用
- Steve Yeggeの「8 levels of AI-assisted development」は、どのツールを使い、どれだけ監督するかで順位づけする
- あらゆるツールベンダーが成熟度の梯子を打ち出し、その最上段はたいてい「自社製品をもっと使う」ことになっている
- これらの梯子は採用の強度を測っているだけなのに、それを成熟度と呼んでいる、包装違いの同じ代用品だ
-
定義の混乱
- Augmentが219人のエンジニアリングリーダーに「AI-native engineering」の定義を尋ねたところ、219通りの異なる答えが返ってきた
-
Anthropicの二面性
- 「8倍多くのコードを出荷」という主張をしながら、同時に今年最も厳密な研究の1つも提示している
- RCTの結果、AI支援を受けた開発者は、たった今リリースしたコードの**理解度で17%低いスコア**となり、統計的に有意な生産性向上もなかった
- 研究部門は知見を更新し、マーケティング部門はボリュームを数える — その2つが同時に真である状況だ
なぜこの問題に注目するのか
- これらの数値は飾りではなく、予算・成果期待・人員計画を動かす
-
AIを名目にした人員削減
- 2月、Jack DorseyはBlockの人員の**40%以上（4,000人超）**を削減、AIを明示的な中心根拠として提示 — 「より小さなチームが、私たちの作るツールで、より多くを、より良くできる」
- 数週間後、Atlassianも**10%（約1,600人）**を削減、しかも「AIが必要なスキル構成や役割数を変えないふりをするのは不誠実だ」と認めた
- Dorseyは同じ発表の中で、事業は堅調で粗利益は成長中だとも述べている
-
生産性主張への疑問
- 「AIで全員がより生産的になり、人員が少なくて済む」のであれば、その証拠を見たいが、現時点では存在しないと考える
- 人員の一部が実際に遊休・低活用状態にあることを示す必要があり、プロダクト/SaaS企業には終わりのないロードマップがある以上、増えた余力は顧客価値・速度に使われるのが自然で、MAU・転換率・売上に表れるはずだ
- 人員削減を選んだということは、生産性の主張が、別の理由（過剰採用、投資家からの圧力）ですでに下された決定のPR役を果たしているというシグナルだ
- 効率性ベースの削減が正当化されることもあるが、その場合に使うべきなのはトークン数や「AI作成コード比率」、成熟度の梯子の等級ではなく、すでに運用されている個人評価システムである
- 選別の根拠が虚栄指標なら、その選別は「口紅を塗った宝くじ」にすぎない
結論
- 反AIではなく、すべてのエンジニアが毎日AIを使うべきだという立場だ
- AI-firstであれAI-proficientであれ、呼び名に関係なく、新しいツールや最新モデルを好奇心を持って試すことが必要だ
- 業界は高級言語、IDE、自動補完、アジャイル、devopsを取り込み続けてきたし、昔を懐かしむ抵抗勢力はいつもいたが、結局は合流してきた
- 今回違うのは速度であり、「クラウド」導入は数年先延ばしにしても生き残れたが、AIでは数か月しか猶予がないかもしれない
- AI導入はスタートラインであってスコアボードではない
- エンジニアリング成果の測定方法はすでに知られている — DORA指標、信頼性、意味のある変更の比率、そして最終的には売上と顧客価値
- 検証済みの方法を捨てて、AIの虚栄スコアを選ぶ理由はない
- ベンダーの売り込み、役員レビュー、LinkedInフィードで投げるべき質問はこうだ: 「それは成果か、ボリュームか？」
- 働き方はAI-firstで、測り方は検証済み（battle-tested）の方法であるべきだ
1件のコメント
Hacker Newsの意見
この奇妙な流れは、2026年2月のOpenAIブログ記事[1]で頂点に達したように思える。最近フロントに上がっていた記事[2]で、エージェントが100%書いた何かを作る過程を扱っている
ただ、その代物が実際には何なのか、ユーザーにどんな価値を与えるのかは説明されていない。最も近い説明でも「この製品は社内で数百人が使っていて、毎日使う社内パワーユーザーもいる」程度だ
それなのに、コード100万行という事実は冒頭の数百語の中で2回も繰り返されている
[1] https://openai.com/index/harness-engineering/
[2] https://news.ycombinator.com/item?id=48416264
「コード100万行」で「エージェントが100%書いた」のなら、なおさらそう思える。でなければ、部署のWiki向けのJSメニューで、実質的にはjqueryをMS JScriptで作り直してJS 5に変換する代物かもしれない
LLMがどれだけ強力でも、保守可能性もほとんどない気がする
https://github.com/openai/symphony
ポッドキャストのインタビューでは、ユーザーがダウンロードするElectronアプリで、だから定期的に新しいビルドを作るのだと話していた。ここの「Autonomous Merging Flow」セクションを参照: https://www.latent.space/p/harness-eng
Microsoft側の人が「エンジニア1人あたり毎月コード100万行を求める」みたいなことを投稿していたのをずっと思い出す。私が話したたいていのエンジニアには風刺のように読まれていたが、実際にはまったく風刺ではなく、LLMによるコード生成に対する多くのCEOの態度をかなりよく反映していたようだ
ただ、ここ数か月では保守不能な量のコード行を生み出すことへの過熱は少し冷めてきた感じがする。より実用的で現実的な見方が公の場で多く共有されるようになり、一部の技術企業の経営上層部にも少しずつ届いている気がする。まだ完全に終わってはいないのかもしれない
実際には大半のコードはテストされていなかった
月100万行 / 月25日 / 1日8時間 / 1時間60分
コードレビューする側にはかなり大きな問題に見える
エンジニアごとに毎月100万行のコードを作らせながら、その行が会社にどうやって利益をもたらすのか、あるいはその過程でどれだけのトークンがいくらのコストで燃えるのかを考えていなかったのだから、どう見ても十分に練られた計画ではなかった
一方で技術的負債は、経営陣を同じようには引きつけられなかった。負債は一般に問題になりうるものではあっても、実際に問題になるまでは避けたり処理したりする必要のないものと見なされるので、後回しにされ続ける
私が働く2つの小規模会社の両方で、こういう様子を見た。数か月前にClaude Coworkが導入されて皆とても興奮していたし、今でも毎日使ってはいるが、期待していた魔法と比べればかなり失望しているように見える
出力は平凡で冗長、極めて基本的なことさえ間違え、トークン上限に何度も引っかかり、自分でやったほうが速いので結局手作業に戻す、という不満が出ている
最初のうちはツールの使い方がまずい面もあるだろうが、AI CEOやLinkedInの商売人、YouTubeのAIサプリ売りが語ることと現実との間には、まだギャップがあると人々は気づきつつある
「AIが全員をより生産的にしたので人員はそれほど要らない」と会社が言うなら、その根拠を見たい。今のところ、そんな根拠が存在するとは思わない
実際には、でたらめを言いながら、コロナ期の過剰採用を巻き戻す言い訳としてAIを使っているだけだ。同時に投資家には、最新の流行技術を取り入れて、よりスリムでコスト効率の高い組織になったように見せている
投資家が最新の流行技術の採用を重視しているというより、利益を重視しているのだと思っていた
それに、「寝室にいるどんなバカでも使えるピカピカの技術を、うちも使ってます！」と言うような会社は、完全に競争力のない会社でもある
この業界は何十年ものあいだ「自分たちの仕事は複雑で時間もかかるので、生産性を簡単には測定できない」と説明してきたのに、AIが登場した途端、急にコード行数、N倍の倍率、週あたりのチケット数のようなものが有用あるいは客観的な指標であるかのように持ち上げられているのが、ひたすら滑稽でもある
コード行数のような指標を拒んできた理由は変わっていない。重要なのはコードの産出量ではなく、品質の高い成果物だ。AIも人間が抱える問題をそのまま引き継いでいる。それなのになぜか、私たちは学んできたことを投げ捨てていて、少し恥ずかしくもある
緩く関与しながら攻撃的で要求ばかり多い上司は、いつの時代にもいたからだ。従業員からより多くの努力を絞り出すことが主な仕事で、調整などには貢献しない上司にも、残念ながら経済的価値はある
だから実際の成果と、コード行数のような測定に基づく二つのアプローチの雲が、常に重なって存在してきた
AIは、こうした緩く関与しつつ要求ばかり多い上司を満足させるための道具をすべて提供する。だからこれからは、コード行数や機能追加を指標として好む人がもっと増えるだろう。今やそれが簡単になったからだ
A+のシニア開発者が8か月かけて機能を作ったのに、結局リリースされない、あるいはMVPが破棄されるなら、そのA+シニア開発者は無駄にされたことになり、生産性は同じプロジェクトに参加したB+エンジニア2人と同じになる
これは実際には非常によくある問題だが、採用やプロジェクトのリソース配分ではたいてい無視される。AIがこれを意味のある形で変えることはないだろう
チームが作業をはるかに早く終えられる可能性はあるが、上の官僚的階層はそのままである可能性が高く、そうなるとAIコーディングで得られる利益はわずかになる。AIに合わせるには会社を上から作り直す必要があるが、そんなことはほとんど起きないだろう
終盤のAI押しは、不自然なくらい根拠がない。理由も、目標も、利益についての主張もなく、「とにかくAIを使え、開発者は新しいものを受け入れるべきだ」という調子だ
最近読んだ文章の中にも、短い文脈でAIを批判するふりをしながら、結局はAI広告で終わるものがあり、両者をつなぐ内容は何もなかった
投資家や大口顧客も、主要契約に署名する前に考え直すだろう
だからAIを使うべきだ。コストと利益を細かく気にしてはいけない。世界はこの方向に進んでおり、ソフトウェア開発で食べていきたいなら、自分もその方向にいなければならない
「今回の違いはスピードだ。クラウドは数年遅れて受け入れても生き残れた。AIは数か月かもしれない」というくだりはおかしい
筆者は、AI企業が自社製品の必須性について行う親AI的な主張が反証不可能であることを理解しているように見えたのに、すぐに「ちょっと待て、私が反AIだとは思わないでくれ」と引き下がっている
上の主張は、文章の残りで批判している生産性の主張より、どうしてより厳密だと言えるのか？ 数か月以内にAIを受け入れなければ「生き残れない」という話が？
AI CEOが言っても事実ではないし、AI CEOのたわごとを指摘する人が、どんな理由であれ同じことを言っても事実にはならない
AIのせいで人を解雇すると言うのは、解釈の余地が広すぎるし、責任を自分ではなくAIに移している。現実的には、CEOがやったことをAIのせいにしてはいけない。従業員をAI向けに再教育することもできたのに、そうしなかった。なぜだろう？ もしかするとAIのせいではないからかもしれない
実際に自分で直接書いたもので、ほかで言われるような「AI slop」で作ったものではないので、おそらく終盤で「人間らしく雑」になってしまったのだと思う
「ちょっと待て」の部分を根拠で支えられていなかった点はその通りだが、それでも人はAIを試してみるべきだという考えは変わらない。実験して、自分に役立つやり方を見つけるべきだ。似たようなエンジニア同士でも、価値を得る方法のスペクトラムは非常に広かった
ツールをきちんと試してみるコストはほとんどなく、「意図的に導入し、実証された退屈な方法で測定せよ」という立場は、「導入しなければ死ぬ」と同じではない
会社が「AIによって誰もがより生産的になったのだから、人員はそれほど必要ない」と言うとき、暗に会社はもっと生産的になりたいわけではないと言っていることになる。
より生産的な少数の人に、より少ない賃金を払って同じ生産性を求めているという意味だ。
生産単位あたりで雇用主が受け取る金と従業員が受け取る金の間に、なぜ不均衡があるのだろうか？
より少ない人数で同じ産出を得るなら、会社や国家の生産性は改善している。
より少ない人数で同じ生産性というなら、産出もそれに合わせて減るので会社には利益がなく、固定費があればむしろ悪化することさえある。
https://www.mckinsey.com/featured-insights/mckinsey-explaine...
コード行数は、オフィスにいる時間と大して変わらないと思う。パンデミック前にはいつも「オフィスにいなければ、働いているかどうかどうやって分かるんだ？」と言っていた。
簡単だ。すべての従業員評価に使う産出指標で、彼らがビジネスに何を貢献しているかを見ればいい。
コード行数がいまだに負債ではなく資産のように扱われていることには、私たちエンジニアの責任が大きいと思う。私たちは自分が作ったものを誇りに思うが、何かがどれだけ「大きい」かを説明するには指標が必要で、結局いちばん数えやすい指標に戻ってしまう。
用語を変えるべきだ。特に「…そしてそのコストはコードN行だった」という表現をもっと使うべきだ。そのコード行をどこに使ったのかも言うべきだ。
「新機能Xを実装したが、たった200行で済んだ」
「そのバグは見つけるのが本当に大変だったが、結局コードは6行で済んだ」
「XのケースではやっていたことをYのケースではやっていなかったが、分かってみるとその区別自体が不要だった。だから問題を修正すると同時にコード20行を節約できた」
コード行数は私たちが支払う価格だ。私たちは何を買ったのかを言わずに200ドル使ったと自慢したりはしない。なぜコード行数ではそうするのだろう？
「申し込みが遅れて200ドル余計に払うことになった」と、「手塗りの職人製陶器ランプホルダーをたった200ドルで買えた。Amazonの工場製は1,200ドルを超える」はまったく別の話であり、コードでもまさに同じ違いに対応する。