AIはコードを速くした。なぜ製品はまだ遅いのか──「開発スピード」の正体【生産性】

1. 結論：開発スピードは「書く速さ」ではなく「価値が届くまでの時間」である

AIによって、コードを書く速度は確実に変わった。調査、設計のたたき台、実装、テストケースの生成、不具合原因の探索まで、以前なら半日かかった仕事が数十分で進むことがある。私自身、不具合修正では数十％という単位の改善を実感する場面がある。問題が既に定義され、正しい状態も比較的明確なら、AIは調査と修正案の往復を短くできるからだ。

ところが、新機能や新製品では同じ感覚にならないことがある。実装が早く終わっても、レビューを待ち、QA環境を待ち、関係部門の確認を待ち、リリース判定を待つ。複数チームの成果が全部そろうまで出せない設計なら、最速の一人が10倍速くなっても、顧客が触れる日はほとんど動かない。

ここで生産性の定義を置き直したい。

AI時代の開発生産性とは、作ったコードの量ではない。「必要だ」と気づいた瞬間から、安全で意味のある変化が顧客の手元に届き、現実の反応を得るまでの時間をどれだけ短くできたかである。

この意味でのリードタイムは、チケットを起票してから本番へ出す時間より少し長い。課題の発見、優先順位づけ、設計、実装、レビュー、QA、セキュリティ、承認、配信、利用、効果確認までを含む。DORAの「変更のリードタイム」はコミットから本番までを測るが、経営にはその外側にある「着想から検証済み価値まで」も必要だ。^[1]

この記事の提案は、長期戦略を捨てることではない。2年先は方向として持ち、3か月単位で市場へ届く賭けに分解する。 建築、製薬、車両、基幹インフラのように物理・法規・安全上の長期工程が避けられない分野と、更新可能なソフトウェアを同じ時間感覚で扱わない。AIが加速する現在、ソフトウェアで1年半後の大きな一発だけを約束することは、完成時点の正しさに賭ける行為になった。

2. コミットは180％増えても、リリースへの効果は30％まで薄まる

2026年5月のNBERワーキングペーパーは、この違和感を非常に直接的に捉えた。10万人超のGitHub開発者とAI利用データを分析し、AIツールの世代ごとに「コードを書くこと」と「コードを世に出すこと」の差を追った研究である。自律型コーディングエージェントではコミットへの累積効果が180％だった一方、プロジェクト数への効果は50％、実際のリリースは30％まで減衰した。著者らは、AIと人間の仕事が強い補完関係にあり、生産工程の弱いリンクで効果が薄まると説明する。^[2]

この研究はランダム化比較試験ではなく、マッチングを用いたイベントスタディである。全企業の因果効果としてそのまま一般化はできない。それでも「生産の階層を上がるほどAI効果が薄まる」という観測は、実務の詰まり方とよく一致する。

別の研究も、測る場所で結論が変わる。GitHub Copilotを使って単純なHTTPサーバーを作る実験では、処理時間が55.8％短縮した。Microsoft、Accenture、Fortune 100企業の計4,867人を対象にした三つのフィールド実験を統合すると、AI支援を受けた開発者の完了タスクは26.08％増え、経験が浅い開発者ほど大きな効果が見られた。^[3][4]

一方、2025年前半のAIを使い、成熟したOSSを熟知する16人が246件の実案件を処理したMETRのランダム化試験では、AI利用時の完了時間が19％長くなった。開発者は事前に24％速くなると予想し、試験後も20％速くなったと感じていた。METRは2026年に、後続データでは新しいエージェントによる改善がありそうだが、AIなしで働きたくない参加者が離脱する選択バイアスのため、効果量は信頼して確定できないと更新している。^[5][6]

矛盾しているのではない。新規で閉じた課題、日常の企業開発、巨大な既存コードベースでは、AIに渡せる文脈、正解の判定、レビュー負荷が違う。 「AIで開発は何％速くなるか」という一つの数字を求めること自体が、工程全体を見失わせる。

3. 日本企業の数字は「内向きの速さ」と「外向きの価値」の断層を示す

日本の状況を「海外は速い、日本は遅い」という印象論で語るのは簡単だ。しかし、国別の平均製品リリース日数を同じ条件で比較した公的な統計は見当たらない。DORAも、アプリケーションや利用者の文脈が違うチームを単純比較することを戒めている。必要なのは架空の国別ランキングではなく、比較可能な断面を重ねることだ。

IPAの「DX動向2025」では、生成AIを導入・試験利用していた企業は日本39.3％、米国58.5％だった。さらに生成AIを部署の業務プロセスへ組み込んだ割合は、日本12.2％に対し米国42.4％。日本では個人の文書作成やアイデア出しに寄りやすく、米国では業務プロセスへ埋め込む比率が高かった。^[7]

1年後の「DX動向2026」では、国内企業の58.0％が生成AIを含むAIを導入または試験利用し、生成AIを「導入している」割合は前年度22.6％から44.0％へ伸びた。普及そのものは速い。しかし、AI導入企業のうち期待どおりか期待以上の効果を得たのは31.8％で、一定の効果はあるが期待未満という回答が50.6％だった。^[8]

もっと重要なのは効果の向きである。効果があった企業の91.6％は「業務が効率化・迅速化した」と答え、48.9％は企画提案の品質や速さ、29.2％は残業削減を挙げた。一方、顧客満足度の向上は4.5％、売上・利益の向上は3.9％にとどまる。道具は広がったが、価値が外へ届く構造は同じ速度で変わっていない。^[8]

日本生産性本部によれば、2024年度の実質労働生産性上昇率は時間当たり、一人当たりとも前年度比0.2％だった。これはAIだけの成績表ではない。産業構成、景気、価格、設備、人手不足など多くの要因が混ざるため、AIが効かなかった証明には使えない。ただ、個人の強い時短実感が、そのまま組織や国の付加価値へ現れるわけではないという問題提起とは整合する。^[9][10]

ここに日本企業の弱点を一つだけ求めるべきではない。IPAは、DX成果が出ている企業では経営・IT・業務部門の協調ができている割合が72.9％、成果が出ていない企業では37.1％と報告する。全社的な業務プロセス最適化に取り組む割合も、成果あり企業53.8％、成果なし企業29.5％だった。AI導入率より、部門をまたぐ流れを変えられるかが結果を分けている。^[8]

4. AIは能力差を消すだけでなく、別の場所で広げる

AIは経験の浅い開発者を押し上げる。前述の4,867人の実験で、経験が浅い層ほど効果が大きかったことは重要だ。しかし、ここから「全員が同じ速度で開発できる」とは言えない。

実務では、AIへ適切な境界を与える力、既存システムの暗黙知、生成物の誤りを見抜く力、テスト可能な小ささへ分割する力、事故時に戻せる設計をする力が結果を左右する。実装速度の差が縮まっても、監督・統合・判断の差が新しいボトルネックになる。

DORAの2025年調査は、世界の技術職約5,000人の回答と100時間超の定性データから、90％が仕事でAIを使い、80％超が生産性向上を感じる一方、30％はAI生成コードをほとんど、または全く信頼していないと報告した。AI利用はデリバリーのスループットとプロダクト成果に正の関係を持つようになったが、安定性とはなお負の関係があった。AIは弱い組織を直す万能薬ではなく、既存の強さと弱さを増幅するというのが同報告の中心結論である。^[11]

レビュー担当者に、AI以前と同じ時間、同じ人数、同じルールのまま、2倍の変更量を渡したらどうなるか。待ち行列が伸びる。大きなPRは後回しにされ、コンテキストスイッチが増え、確認範囲が広がる。AIがコードを増やすほど、人間が「どこまで見れば責任を果たしたことになるのか」という不安も増える。

だから、AIレビューを追加するだけでは足りない。生成AIに一次確認をさせても、最終判断の責任と対象範囲が曖昧なら、コメントが増えて別の待ち行列になる。必要なのは、変更を小さくすること、機械が判定できる部分を品質ゲートへ移すこと、人が見るべき意味・例外・不可逆性を明示することだ。

5. 安全のために遅くするのではない。安全に速くする仕組みへ変える

「早く出す」と聞くと、品質やセキュリティを軽視した見切り発車に聞こえるかもしれない。しかし、速さと安定性を二者択一にする前提が違う。DORAは、上位チームでは速度と安定性が両立し、両指標は多くのチームで相関すると整理している。小さな変更は理解しやすく、テストしやすく、失敗しても戻しやすい。^[1][12]

継続的デリバリーの考え方は「最後に大きく検査する」のではなく、テスト、セキュリティ、観測性を日々の小さな変更へ組み込む。DORAは、安全性が特に重要な規制産業でも、継続的テスト、全体へ埋め込んだセキュリティ、観測性がより重要になると説明する。NISTのSSDFも、動的脆弱性検査や既知脆弱性の再発防止テストを自動テストへ統合する例を示す。^[13][14]

実務では、変更を三段階に分けると責任範囲を狭めやすい。

全変更へ最高リスク向けの審査を課すと、安全性ではなく滞留を作る。一方、リスク分類を口実に重要な確認を外せば事故になる。そこで各ルールに「守るリスク」「適用対象」「自動化できる判定」「責任者」「失効・再評価日」を持たせる。過去に一度必要だったという理由だけで永久に残すのではなく、代替の自動制御が入ったら人手の承認を外す。

ルールを減らす人だけが責任を背負う構造では、誰も減らさない。経営が引き受けるべきなのは、「省略を許した個人」ではなく、リスク階層とガードレールを組織として承認する責任である。

6. 私たちは「アフターAI」ではなく、変化の現在進行形にいる

AI以前とAI以後を一本の線で区切りたくなる。しかし、2023年ごろのチャット中心の利用から、コードベースを読み、コマンドを実行し、複数工程を進めるエージェントまでの変化は数年で起きた。METRの2025年と2026年の報告だけを比べても、道具が変わる速さのために同じ実験設計を維持しにくくなっている。

これは「パラダイムシフトが起きた」という過去形より、「いま足場が動いている」という現在進行形で捉えた方がよい。ソクラテス的な態度を借りるなら、重要なのは未来を知らないことではなく、知らない範囲を知ったうえで、学習速度を設計することである。

2年後の製品像を語ること自体は必要だ。予算、人材、法規、データ、基盤整備には長い時間がかかる。危険なのは、2年後の機能一覧を今日の理解で固定し、顧客の反応を完成日まで受け取らないことだ。2年後に成功する自信があるかではなく、その自信を更新する証拠が次の90日で何件得られるかを問うべきである。

以前の記事「AIエージェントはSaaSを殺すのか──GUI・API・集約の2030年」では、長期的にはエージェント向けのAPI・権限・監査基盤を育てながら、短期には顧客が今使える画面内AIも出す「二層戦略」を提案した。未来にGUIが縮小する可能性があっても、今日の顧客が画面で価値を得るなら、いま動くものを届ける意味はある。

これは使い捨てを礼賛する話ではない。捨ててもよいのは仮説と表面の体験であって、顧客データ、権限、監査、決済、セキュリティまで雑に作ってよいわけではない。変えにくい土台は長く育て、変わりやすい価値提案は短く試す。 盆栽のように育てる基盤と、季節ごとに植え替える鉢を同じものにしない。

7. 1年半の大計画を、90日の「市場に届く学習」へ切り直す

ソフトウェアの計画は、次の三つの時間軸に分けられる。

• 2年の方向：どの顧客課題を解く会社でありたいか、守るべきデータ・権限・ブランドは何か。
• 6か月の能力：必要なAPI、データ品質、テスト基盤、観測性、販売・サポート体制をどこまで作るか。
• 90日の賭け：誰に、どの最小価値を、いつ出し、何をもって継続・修正・終了を決めるか。

90日を、90日間の開発期間にしてはいけない。最初の2週間で対象顧客と成功条件を絞り、次の2〜4週間で最小の変更を本番へ出し、残りを利用観測と改善へ使う。統合や審査が重い領域でも、社内利用、限定テナント、読み取り専用、提案だけで実行しないAIなど、不可逆性を下げた形なら先に学べることがある。

この運用を機能させるには、企画、開発、QA、セキュリティ、営業、サポートを別々の締切で管理しない。最小単位の価値を一緒に定義し、その単位が本番へ届くまでを共同所有する。DORAが指摘するように、メトリクスを部門ごとに孤立させると、摩擦と責任の押し付けが起きる。^[1]

失敗を許すという表現も、少し正確にしたい。許すのは、制御された小さな仮説が外れることだ。セキュリティ事故、法令違反、復旧不能なデータ破壊を「挑戦」と呼んではいけない。早く試せる企業は、勇敢だから速いだけではない。失敗半径を小さくする技術と、撤退を評価できる経営を持っている。

8. 測るべきはAI利用率ではなく、アイデアから価値までの滞在時間である

AIアカウント数、プロンプト数、生成行数、資料作成時間は導入状況を見る補助指標にはなる。しかし、それを生産性の主指標にすると、使うこと自体が目的になる。

まず一つの製品で、直近20〜30件の変更を次の状態に分ける。

1. 課題を認識してから優先順位が決まるまで
2. 着手待ち
3. 実装中
4. レビュー待ち・レビュー中
5. QA・セキュリティ・承認待ち
6. リリース待ち
7. 顧客が使い、効果を判定できるまで

平均だけでなく中央値と85パーセンタイルを見る。一部の巨大案件が全体を歪めるためだ。併せて、仕掛品数、PRサイズ、レビュー待ち時間、テスト所要時間、デプロイ頻度、変更失敗率、再作業率、復旧時間を測る。最後に、利用率、継続率、問い合わせ削減、売上、処理時間など、その変更が狙った顧客成果を一つ置く。

AI導入前後で「実装中」だけが縮み、「レビュー待ち」が伸びていたら、次の投資先は新しいコーディングモデルではない。レビューの優先順位、小さな変更への分割、テスト自動化、責任範囲の明文化である。QA待ちが長いなら、テスターを急かすのではなく、テストデータ、環境構築、回帰試験、リリース判定のどこを機械化できるかを見る。

不具合修正で効果が大きく、新機能で小さいなら、それも重要な発見だ。不具合は望ましい状態が明確で、緊急度が合意され、優先順位の競争が少ない。新機能は「何を作るか」「誰の価値か」「売れるか」が未確定で、企画と意思決定の待ち時間が支配する。両方を同じ生産性指標で平均化すると、改善箇所を見誤る。

結び：スピードとは、急ぐことではなく、早く現実に会うことだ

AIがコードを書く速度を上げたことは、重要な進歩である。しかし、それだけでは製品は速くならない。生成された変更を、レビューし、試験し、安全に出し、顧客の反応から次を決めるところまで流れて、初めて生産性になる。

日本企業の最新データが示すのは、AIが効いていないという結論ではない。効率化・迅速化の効果は広く出ている。それが顧客満足や売上へ届く前に、組織のどこかで薄まっている。ならば、追加すべきものはAIライセンスだけではない。小さな変更、速いレビュー、自動化された品質、段階公開、観測、明確な撤退条件、そして不要になった承認を外す経営判断である。

1年半後、2年後の大きなリリースを否定する必要はない。ただし、その日まで正解を確かめない計画は危うい。未来を正確に予言できないなら、計画を弱くするのではなく、学習を強くする。

AI時代の勝負は、誰が最も速くコードを書けるかではない。誰が最も早く、安全に、現実から答えを受け取れるかで決まる。

参考文献・出典

1. [1]DORA「Software delivery performance metrics」。変更リードタイム、デプロイ頻度、復旧時間、変更失敗率、再作業率を、速度と安定性の両面から定義している。2026年1月更新。 ↩
2. [2]NBER Working Paper 35275「Writing Code vs. Shipping Code: Productivity Effects Across Generations of AI Coding Tools」。10万人超のGitHub開発者を対象とした2026年5月のワーキングペーパー。 ↩
3. [3]Microsoft Research「The Impact of AI on Developer Productivity: Evidence from GitHub Copilot」。HTTPサーバー作成課題のランダム化実験。 ↩
4. [4]Microsoft Research「The Effects of Generative AI on High-Skilled Work」。3社、計4,867人のフィールド実験。 ↩
5. [5]METR「Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity」。対象と限界を明記したランダム化比較試験。 ↩
6. [6]METR「We are Changing our Developer Productivity Experiment Design」。後続実験の選択バイアスと測定上の限界を説明している。 ↩
7. [7]IPA「DX動向2025説明会・解説資料」。日米独の生成AI導入状況と利用形態を比較。 ↩
8. [8]IPA「DX動向2026」。国内企業のDX、AI導入、効果、組織、人材を調査。 ↩
9. [9]日本生産性本部「日本の労働生産性の動向2025」。2024年度の時間当たり・一人当たり実質労働生産性を掲載。 ↩
10. [10]PRESIDENT Online「仕事が速くなった気がしているだけ…AI活用の現実」。個人の時短と組織・マクロの生産性の断層を考える際に参照した。 ↩
11. [11]Google Cloud「2025 DORA Report: State of AI-Assisted Software Development」。約5,000人の技術職調査と100時間超の定性データに基づく。 ↩
12. [12]DORA「Working in small batches」。AI時代の大規模変更を避け、レビュー・テスト・復旧を速くする実践。 ↩
13. [13]DORA「Continuous delivery」。高速・安全・持続可能なリリースを支える技術能力を整理。 ↩
14. [14]NIST SP 800-218「Secure Software Development Framework Version 1.1」。安全なソフトウェア開発を開発ライフサイクルへ統合する推奨事項。 ↩