AIコーディングツールがもたらす生産性向上は本物です。ただし、その向上がソフトウェアの品質、プロダクト判断、組織の学習にも比例した改善をもたらしているかは、まだ証明されていません。このギャップは、ツケが回ってくる前に押さえておく価値があります。
主なポイント:
- AnthropicのCEOは、AIコーディングツールの生産性インパクトを約15〜20%と見積もっています。本来なら大きな数字を打ち出したい立場の人物が出した、控えめな推定です。一方、Anthropic自身のエンジニアは自己申告で50%の向上を報告しています。両者の30ポイントの差こそ、これらのツールが実際に何をしているのかを冷静に議論する出発点になります。
- ランダム化比較試験では、長年自ら手を入れてきた複雑なコードベースで作業する熟練開発者が、AIツールを使うことで計測上はむしろ遅くなっていました。それでも本人たちは、速くなっていると信じ込んでいたのです。
- Goldman Sachsは、特定の用途では確かな効果が出ているにもかかわらず、経済全体で見るとAI導入と生産性の間に意味のある相関は見られないと指摘しています。
- リスクはツールそのものにあるのではありません。慎重な導入が「足かせ」に映り、無頓着な導入が「大胆さ」と称えられる――そんな競争的プレッシャーこそが本質的な問題です。
- ともに作る摩擦――グルーミングセッション、コードレビュー、「これらの要件は互いに矛盾しています」と声を上げる開発者――は、ソフトウェア以上のものを生み出してきました。AIエージェントには、その副産物を再現できません。
「vibe coding」とは何か――そして定義がなぜ重要なのか
混乱はこの言葉そのものから始まります。2025年2月、Andrej Karpathyはツイートで「vibe coding」という言葉を生み出しました。AIに完全に身を委ね、差分を読まずに受け入れ、コードを理解しているかどうかを気にしない――そんな週末のワークフローを軽い調子で表したものです。彼はこの言葉を、使い捨てのプロジェクトに限定して使うと明確にしていました。
その後の展開は示唆に富みます。Karpathy自身、本格的な仕事には「agentic engineering」という呼び方のほうが好ましいと後に語っています。AI支援コーディングから後退したのではなく、その実践には監督、厳密さ、そして職人的な姿勢が必要だと考えるからです。2026年3月のNo Priorsポッドキャストのインタビューでは、12月以降一行もコードを書いていないと話しています。
一方でGene KimとSteve Yeggeは、2025年にVibe Coding: Building Production-Grade Softwareを上梓し、同じ名前で厳密なプロフェッショナルの実践を定義しました。序文を寄せたのはDario Amodeiです。さらに別の文脈では、この言葉は蔑称として、誇りの印として、民主化の象徴として、そしてAI支援開発全般のほぼ同義語としても流通しています。
この定義の混乱が問題なのは、まったく異なる実践が同じラベルの下で並走できてしまうからです。規律あるレビュー、明確なオーナーシップ、丁寧な検証を伴ってAIを使うチームと、生成された出力を最低限の精査で受け入れるチームが、言葉の上では似て聞こえてしまう。用語は曖昧でも、ガバナンスの選択は曖昧であってはいけません。
この記事は、AI支援開発に反対する論ではありません。問いたいのは、「速く・広く導入し、変革を宣言せよ」という文化的プレッシャーのもとで、組織が慎重なやり方をしているつもりで実は無頓着なやり方をしてしまうとき、何が起きるのかということです。
AIコーディングの生産性について、データは何を示しているのか
もっとも信頼できる推定値は、見出しが示唆するよりずっと控えめです。そして、認識と実態のギャップには驚かされます。
Dario Amodeiは2026年2月のDwarkesh Podcastで、当事者の立場から出てくるものとしては最も誠実といえる推定を示しました。AIコーディングツールの生産性インパクトを**15〜20%**程度と見積もったのです――より大きな数字を主張する動機が十分にあるはずの人物が、意図的に控えめに置いた概算です。
2025年後半に発表された別のAnthropic社内調査では、同社のエンジニア132名へのアンケートをもとに、自己申告で約**50%**の生産性向上が報告されました。両者は性質の異なる計測です――一方は広い意味での生産性の概算、もう一方はAI企業のエンジニアによる、ツールへの早期アクセスという特権を持った立場での自己申告。それでも、この差はじっくり考えるに値します。測っているものが違い、どちらも厳密な数字ではありません。それでも、反対方向を指す2つの概算の間に30ポイントの開きがあるという事実は、何かを物語っています。AIを理由とする人員判断の多くが、独立した評価ではなく「体感の生産性」に基づいて行われていることを思えば、なおさらです。
METRのランダム化比較試験は、これまでに実施されたAIコーディングツールの独立研究のなかでも特に厳密な部類に入り、エンジニアリングリーダーにとって最も関連性の高い文脈――長年自ら手を入れてきた、大規模で複雑な成熟したコードベースで作業する熟練開発者――を扱いました。その設定では、AIツールを使った開発者は使わなかった場合より19%遅くなっていました。事前には24%の高速化を予測していたにもかかわらずです。さらに示唆的なのは、研究終了後に彼ら自身は「AIによって20%速くなった」と推定していたことです――客観的データはその逆を示していたのに。
METRはこの結果が他の文脈に一般化できない可能性があると慎重に注記しています。経験の浅い開発者、なじみのないコードベース、新規開発の文脈ではAIツールの振る舞いが変わるかもしれません。しかし認識のギャップ――開発者が体感する作業速度と実際の速度との体系的なずれ――は、はるかに広く当てはまります。今のAI生産性論争を駆動しているものの多くを説明するのは、減速そのものよりも、このギャップなのです。
Goldman Sachsのエコノミストは2025年第4四半期の分析で、「経済全体のレベルでは、生産性とAI導入の間に意味のある相関は見られない」としています。同じ分析は、ソフトウェアコーディングとカスタマーサービスという特定のローカルな用途では、約30%の生産性向上が確認できるとしています。AI生産性のストーリーは、局所的には実在します。しかし、語られているような広範な変革にはまだ至っていません。
現在のデータが裏付けているのは、誇大宣伝とその反動の双方が描くものよりも、ずっと狭い範囲の話です。AIコーディングツールは特定の文脈で意味のある向上を生み出せます。同時に、主観的な加速感が計測上の改善を上回るという、繰り返し現れる認識のギャップも生み出します。データがまだ示せていないのは、コード生産の高速化が、ソフトウェアの品質、プロダクト判断、チームの学習における比例的な向上に確実につながる、ということです。
レイオフのナラティブはエビデンスに耐えるのか
AIによる生産性向上を理由に人員削減を最も声高に語る企業のなかには、エビデンスがもっとも薄い企業も含まれています。
Klarnaが最も示唆的なケースで、Fortuneが詳しく報じています。同社は、AIアシスタントが700人のカスタマーサービス担当者の仕事をこなしていると主張しました。数か月のうちに、顧客は画一的な応答や人間によるサポートの欠如に不満を漏らし始め、同社は人間スタッフの採用を再開します。CEOのSebastian Siemiatkowskiは、何が起きたかを率直に語っています。「コストが評価要因として支配的になりすぎたようで……結果として品質が下がってしまった」。Klarnaは、AIによる代替戦略が常に失敗するという証拠ではありません。「処理した量」を「提供した品質」と取り違えたとき何が見過ごされるのかを、鮮明に示した例なのです。
Klarnaは最も詳しく記録された事例ですが、孤立した話ではありません。2025年から2026年にかけて、複数の企業がAIによる人員削減を発表する一方で、アナリストや内部関係者はより単純な説明――パンデミック期の過剰採用――を指摘しました。それでも市場は、ほぼすべてのケースで「AI」というフレーミングを評価したのです。
2,000人の経営者を対象としたIBMのCEO調査では、約束した投資収益を実現しているAIプロジェクトは4件に1件にすぎないと報告されています。それでも約3分の2は、価値を明確に把握する前にでも投資する理由として、出遅れるリスクを挙げています。
この最後の数字は、じっくり考える価値があります。AI投資の主たる原動力は、リターンの裏付けではなく、競合が先に動いたらどうなるかという不安なのです。その不安は理解できますし、文脈によっては合理的ですらあります。しかしそれは、ある種の集団的な自己欺瞞の温床にもなります――変革が起きたから発表するのではなく、発表することが競争上必要だからAI主導の変革を発表する、という構図です。ナラティブは結果より速く伝わります。
そして結果が見えてくる頃には、ナラティブはすでに採用判断、投資家の期待、戦略的コミットメントを形作っており、容易には巻き戻せません。
ツールは本物です。ナラティブは、ツールがしていない仕事を肩代わりしているのです。
なぜ「コード生産の高速化」は「優れたソフトウェア」と同じではないのか
こちらのほうが、より重要な問いです。そして、生産性論争の枠を超えて意味を持ちます。
iPadでClaudeアプリを開いてみてください。動きます。ただ、日常的に使えばわかるとおり、これは明らかに、iPadを手にして「しっくりくる」感覚を求めるユーザーの視点から十分に練り上げられた製品ではありません。
これは主にコード生成の問題ではありません。判断の問題です。アプリがどうあるべきか、使ったときどう感じるべきか、ブラウザではなくこちらに手を伸ばさせるものは何か――誰かがそれを決めなければなりませんでした。コード生成の改善は実装を速めるかもしれませんが、それだけではこの意思決定の層は解けません。解くには、他の人間が実際にどんな体験をしているかへの持続的な注意が必要であり、その種の注意は遅く、不確かで、「vibe」では生み出せないのです。
生産が安く速くなれば、作る前にじっくり考えるべしという経済的圧力は弱まります。それらしいものを数日でリリースし、あとは反復すればよい。複合的な影響として、この論理は「ソフトウェアを使う価値あるものにする真のユーザー理解への投資」を積極的に阻害します。何週間もかけて慎重なユーザーリサーチをするくらいなら、出して様子を見ればいいのではないか――。問題は、「出して様子を見る」が有用な学びになるのは、何を見たいのか、なぜ見たいのかをすでに定義してある場合だけだということです。それなしでは、リリースが明らかにすることは期待よりも少なく、見つけた問題を直すコストは想定より大きくなります。それが見えてくる頃には、決定はすでに下されています。これは同じ本能の別バージョンです――見えるもの・速いものを最適化し、遅く・測りにくいものを後回しにする。
この傾向――心躍る指標を最適化しつつ、それを支える仕組みを軽視する――は新しいものではありません。1920年代、ある顧客がType 35レーシングカーのブレーキについて苦情を述べたとき、Ettore Bugattiはこう答えたとされています。「私の車は走るために作っているのであって、止まるために作っているのではない」。発言から約100年が経ちました。それが体現する思考様式は、どうやら不滅のようです。Bugattiの車は美しく、力強く、ブレーキが弱いことで悪名高いものでした。とても速く走ったのです――走らなくなる、その瞬間までは。
2023年、Gene KimとSteven SpearはWiring the Winning Organizationを出版し、高パフォーマンス組織の研究をもとに、その解毒剤を**slowification(スロウィフィケーション)**と名付けました。実行の前に計画し、準備し、共通理解を築く時間を取ることは、速さの対極ではなく、速さを持続可能にするものなのです。意図的な準備に投資した組織は、検討の一瞬一瞬を排除すべきコストとして扱った組織を、一貫して上回りました。Kimはその後、Vibe Coding: Building Production-Grade Softwareを共著し、まさにこの種の厳密で意図的な実践を主張しています。彼が2023年に見いだした原則は、AI支援開発の進め方にそのまま当てはまるのです。
生産の天井は上がりました。理解の天井は動いていません。
これは新しいパターンではありません。世代を重ねるごとに登場した優れたツール――表現力豊かな言語、リッチなフレームワーク、クラウドインフラ――は、理解しないままモノを作ることを安く速くしてきました。ローコード運動はソフトウェア制作の民主化を約束し、結果として「作るのは速いが使うのはもどかしい」ソフトウェアを大量に生み出しました。AIコーディングツールは、このパターンの最も強力な実例であって、その発明ではありません。
組織が作れるものと、組織が本当に理解しているものとのギャップは、抽象化のあらゆる層で再生産されてきました。それが今や、かつてないスピードで再生産されているのです。
AIエージェントが人間の開発者を置き換えるとき、何が失われるのか
ソフトウェアを優れたものにする判断は、プロダクトマネージャーだけが握っていたわけではありません。それはチーム全体に分散し、ともに作るときの摩擦のなかから生まれていました。
すべての摩擦に価値があるわけではありません。一部は官僚主義、レイテンシ、避けられる抵抗です。しかし一部は、集団的な理解が生まれる場所であり、現在の自動化の波は、両方をまとめて取り除くことを容易にしてしまいます。
これは純粋に理論上の話ではありません。今エンジニアリングコミュニティのあちこちで、開発者が自身の経験を語るときに繰り返し現れている現象があります――速くリリースし、生産性が上がったと感じながら、システムが実際に何をしていて、なぜそうなっているのかへの把握を、静かに失っていくのです。先に挙げた研究はそれをマクロレベルで裏づけ、現場の会話もまた裏づけています。
グルーミングセッションで開発者が「これらの要件のうち2つは正面から矛盾しているので作れません」と異議を唱えたとき、組織は、うまく避けてきた何かに直面させられました。その不快感は計画プロセスの失敗ではなく、計画プロセスが機能している証でした。要件は、誰かが実際に実装しようとするまでは整合的に見えるよう書かれていた。開発者の戸惑いこそが、組織を映す鏡だったのです。
シニアとジュニアのエンジニアの間でコードレビューが行われたとき、双方ともそれまで持っていなかった何かを得て席を立ちました。ジュニアは、ある種の問題をどう考えるかを学びました。シニアは、それまで暗黙にしか持っていなかった何かを言語化することを迫られ、言語化する行為そのものが、その理解を研ぎ澄ましました。会話が学びそのものであり、コードはその残滓です。
この区別は、見た目以上に重要です。Michael Polanyiは生涯をかけてこれを精緻化しました。「我々は語れる以上のことを知っている」とThe Tacit Dimensionで書いています――そして、その系として、語れることは常に実際に知っていることより少ないのです。
実践を通じて築かれる理解は、読書や指導を通じて得る情報とは質的に異なります。複雑なシステムが負荷下でどう壊れるか、ある種のユーザーがある種の戸惑いにどう遭遇するかを、本で読んで「知る」ことはできません。そこに居合わせる必要があるのです――モデルを抱え、それが壊れる様子を目にし、その残骸から修正版の理解を組み立てる、という経験を経なければなりません。
それこそが、誰がそう呼ぶかどうかにかかわらず、グルーミングセッションやコードレビューが摩擦の副産物として生み出していたものでした。
AIエージェントは、これらの副産物を生み出しません。文句も言わずに進みます。エージェントの従順さは、要件が明確だった証拠ではありません。「エージェントは文句を言わない」というだけのことです。
AIエージェントのコードはレビューできます。しかし、エージェントとあの会話をすることはできません。エージェントはレビューを「理解」として持ち越しません。何年もそうしたやり取りを通じて育まれていたはずのジュニア開発者は、そもそも採用されなくなりつつあります。そして、そうしたやり取りを生成コードに置き換えた組織は、自分が依存していると気づいてさえいなかった仕組みを取り除いてしまったのです――ソフトウェアを生み出すこととはまったく別の働きをしていた仕組みを。
問うべき問い
見るべき指標は、リリース速度がどれだけ上がったか、だけではありません。生産における向上が、明晰さ、判断、学習における向上と釣り合っているかどうか――そこです。
これはAIツールへの反対論ではありません。Karpathy、Kim、Yeggeのいずれもが説く監督、職人的な姿勢、判断とともに正しく使えば、これらのツールには確かな価値があります。問うべきは、今この瞬間が、そうした使い方の条件を整えているかどうかです。競争への不安、考える前にリリースせよという圧力、何かを理解するために減速することは劣ったパフォーマンスだという感覚の高まり――これらはどれもツール自体が生み出すものではありません。今ツールを取り巻いている文化的な空気なのです。
レーシングドライバーは、ブレーキは減速のためのものではないと知っています。ブレーキはコミットメントを可能にするためのもの――何かあれば止まれるという確信があるからこそ、コーナーへ強く踏み込めるのです。チームが今「速度」の名のもとに取り除いている摩擦は、まさにこれであることが少なくありません。オーバーヘッドでも非効率でもなく、そもそも速く走ることを可能にしていた仕組みだったのです。AI支援開発の厳密な実践者はこれを理解しています。競争的不安に飲み込まれた組織は、たいていそうではありません。
より多くのコードをリリースすることは、より優れたソフトウェアを作ることと同じではありません――そして、これまでも同じだったことはありません。コードはつねにアーティファクトでした。それを生み出した理解の可視的な残滓であって、理解そのものではないのです。変わったのは、アーティファクトと理解との取り違えそのものではありません。その取り違えを大規模に維持することが、いかに速く安くなったか、です。
問うべき問いは――正直に、具体的に、自分自身のチームについて――あなたが実際にしているのはどちらの導入なのか、ということです。この問いは多くの場合、外部の視点があるほうが取り組みやすくなります。両方を見てきて、何に目を向ければよいかを知っている誰かの視点があれば、なおさらです。
こうした問いに、すっきりとした答えはありません――そして、そう主張する人はおそらく、十分真剣に問うていないのでしょう。DoiTでは、まさにこの緊張のなかで舵を取る数百人ものエンジニアリング・テクノロジーリーダーと並走してきました――何を残し、何を変え、気づかないうちに何を失おうとしているのかを見極める仕事です。私たちが学んできたのは、適切な人々と適切な問いを交わすことが、どんなフレームワークよりも良い答えを生む、ということです。私たちには見えていないものが見えている方、機能しているやり方でこの課題に取り組まれている方は、ぜひお話を聞かせてください。
よくあるご質問
「vibe coding」にはどのような意味がありますか? この用語には現在、少なくとも3つの異なる意味があります。本来の意味――2025年2月にAndrej Karpathyが造語したもの――は、使い捨てプロジェクトに適した、カジュアルで「身を委ねる」スタイルのワークフローを指していました。Gene KimとSteve Yeggeはその後、2025年の著書Vibe Coding: Building Production-Grade Softwareにおいて、同じ名前のもとで厳密さ、監督、職人的な姿勢を強調する真摯なプロフェッショナル実践を定義しました。一般的な用法では、AI支援開発全般の同義語として、また無頓着なAI採用に対する蔑称としても使われています。定義の混乱は重要です。同じ用語が「AI出力の無思慮な受容」と「規律あるagentic engineering」の両方を指してしまうと、特定のチームが実際に何をしているのかについて、意味のある会話をすることが非常に難しくなるからです。
AIコーディングツールは、ソフトウェアの品質を改善せずに生産性だけ高めることがあり得ますか? あり得ます。データはむしろ、それがすでに大規模に起きていることを示唆しています。AIツールはコードのアウトプットを計測可能なほど増やし、デリバリーサイクルを短縮できます。ただし、何を作るかを決める判断、要件の明確さ、製品の背後にあるユーザー理解の深さまで改善するわけではありません。Goldman Sachsは、ソフトウェアコーディングという特定の用途で実際の生産性向上を確認しています。同社が――そしてより広いエビデンスが――まだ示せていないのは、その向上がソフトウェアの品質や製品アウトカムの比例的な改善につながっている、ということです。
METRのAIコーディング研究は、実際のところ何を明らかにしましたか? METRの2025年のランダム化比較試験は、開発者本人がよく知る大規模で成熟したオープンソースのコードベースを使い、16名の経験豊富な開発者に246の実タスクを課しました。AIツールを使った開発者は、使わなかった場合よりタスク完了に19%長くかかりました。事前には24%の高速化を予測し、事後にも自分は速かったと信じていたにもかかわらず、です。METRは、この結果はこの文脈に固有のものであり、経験の浅い開発者やなじみのないコードベースには一般化しない可能性があると注記しています。認識のギャップ――データが逆を示しているのに、AIに助けられていると体系的に思い込んでしまうこと――こそが、最も広く適用できる発見です。
自己申告と実測のAI生産性の間に、なぜこれほど大きな差があるのですか? 2つのデータが、それぞれ異なる角度からこのギャップを示しています。2026年2月のポッドキャスト出演で、Dario AmodeiはAIコーディングツールの生産性インパクトを約15〜20%と見積もりました。一方でAnthropic社内調査(2025年後半)では、Anthropic自身のエンジニアが自己申告で50%の生産性向上を報告しています――性質の異なる計測ではあるものの、両者の差は示唆に富みます。METRの研究も同様の知覚パターンを発見しました。開発者はAIによって20%スピードアップしたと信じていましたが、客観的計測は19%の減速を示していたのです。METR自身のギャップ分析は、いくつかの要因を挙げています。AI支援コーディングは認知的負荷が小さく、実際にはそうでなくても速く感じられること、開発者が「楽さ」と「速さ」を取り違えている可能性があること、AI生成コードのレビュー・修正・後始末にかかる時間が、自己申告には通常含まれていないこと、などです。
Klarnaがカスタマーサービス担当者をAIに置き換えたとき、何が起きましたか? Klarnaは約700人のカスタマーサービスの役割を、OpenAIと共同開発したAIアシスタントに置き換え、AIが同等の仕事をこなしていると主張しました。ところが数か月のうちに、AIエージェントが複雑で機微のある感情的なやり取りに苦戦するなか、顧客は画一的な応答や人間サポートの欠如への不満を訴え始めます。CEOのSebastian Siemiatkowskiは、誤りを率直に認めました。「コストが評価要因として支配的になりすぎたようで……結果として品質が下がってしまった」。同社は2025年に人間のカスタマーサービススタッフの採用を再開しています。このケースは単なる失敗事例にとどまりません。指標が「示された理解」ではなく「処理した量」に置き換わったとき、何が失われるのかを示すお手本として読み解けるのです。
slowificationとは何で、ソフトウェアチームにとってなぜ重要なのですか? slowificationは、Gene KimとSteven Spearの2023年の著書Wiring the Winning Organizationで提示された概念です。実行の前に、計画、準備、共通理解への意図的な投資を行うこと――下流で速く確実に動くために、あえて減速すること――を指します。彼らが高パフォーマンス組織を横断して行った調査では、これが一貫した差別化要因でした。slowifyしたチームは、検討の一瞬一瞬をコストとして扱ったチームを一貫して上回ったのです。この原則はソフトウェア開発にそのまま当てはまります。「遅く感じられた」グルーミングセッション、丁寧なユーザーリサーチ、コードレビューは、まさにこの働きをしていることが多かったのです――自信ある実行が依拠する共有知識を生み出す働きです。
AIツールはアウトプットを増やしながら、理解を減らしてしまうことがありますか? あります――そしてこれは、生産性を高めるかどうかという問いより、おそらく重要な問いです。アウトプットと理解は、それぞれ異なる仕組みから生まれます。コードは実行から生まれ、理解は問題をともに解いていく摩擦から生まれます――矛盾する要件に異議を唱える開発者、シニアエンジニアがそれまで暗黙にしか持っていなかったことを言語化させられるコードレビュー、明確な仕様に見えていたものが実はそうでなかったとチームが気づくグルーミングセッション。AIエージェントはこうした副産物を生み出さずに先へ進みます。文句を言わず、明確化を求めず、会話を学びとして持ち越しません。組織は、システムが何をしているのか、なぜそのように作られているのか、ユーザーが本当に何を必要としているのかへの把握を失いながら、より多くのソフトウェアをリリースすることができてしまいます。アウトプットは増えます。それに伴うべき理解は、ペースを保てません。
Goldman Sachsは、AIに生産性への影響はないと結論づけているのですか? 厳密にはそうではありません。Goldman Sachsのエコノミストは同じ2025年第4四半期の分析で、経済全体のレベルではAI導入と生産性の間に意味のある相関は見られないとしています。同じ分析は、特定のローカルな用途――最もよく挙げられるのはソフトウェアコーディングとカスタマーサービス――では約30%の生産性向上を確認しています。描かれているのは、特定の文脈での実際の向上が、まだ広範な経済的生産性の改善には変換されていないという構図です。この区別は、組織がAI投資をどう考えるかにとって重要です。効果が十分に裏づけられた文脈での的を絞った導入は、AIを汎用の生産性ブースターとして扱うのとはまったく違うのです。