AI駆動開発の実践例

AI駆動開発の全体感 ～AI時代の生産性を何で測るのか

［第1回］コード生成の高速化で、開発のボトルネックはどう変わるのか

  • 渋谷 優介

2026年9月3日 09:00

　本連載では、AI駆動開発について「AIで速くなった」という総論から一歩踏み込み、工程ごとに何が実際に変わり、どこに新しい負荷が移ったのかを、Algomatic社での実践を交えて順に整理します。読者の皆さんが自社の開発プロセスに当てはめて考えられる、実務的な内容をお届けします。

　AI駆動開発とは、要件定義・設計・実装・テストといった開発プロセス全体にAIを組み込み、人間が判断・監督しながら開発を進めるアプローチです。なかでも実装プロセスにおけるAIを用いたコーディングは、ここ1年で大きく進歩し、コードを書くスピードは飛躍的に上昇しました。一方で、「実装は速くなったのに、リリースまでの日数はあまり変わっていない」と感じる方もいると思います。

　その変化は、従来の「プログラムの行数」や「PR数」だけでは捉えきれません。AIによって実装が高速化する一方、負荷は要件や設計の意思決定、レビューやテスト、AIを監督する作業へ移り始めているからです。

　つまり、AI駆動開発によって変わっているのは、コードを書く速度だけではありません。開発のボトルネックと、生産性の測り方そのものが変わり始めています。

　本連載では、要件定義から開発、テストまで、AI駆動開発を実践してきた経験をもとに、現場で何が起きているのかを整理します。第1回は、上流・下流・認知負荷・開発指標の4つの観点から、開発全体の変化を見ていきます。

コード生成だけが先に高速化している

　JetBrainsの開発者調査では、85％がAIツールを日常的に利用。DORAの2025年レポートでも業務でAIを利用する技術者は90％に達しました。MCPサーバーの登録数も、2026年8月時点で7万件を超えています［1］。

　OpenAIの社内開発事例では、3人のエンジニアがCodexを活用し、5カ月で約100万行のコードと約1,500件のPRを生み出しました。人間はコードを直接書くのではなく、AIへの指示や成果物の確認に注力しています［2］。

　組織全体でも「作る速度」は上がっています。Faros AIが22,000人の開発者、4,000以上のチームを分析したところ、AI利用が増えた組織では、開発者あたりのエピック完了数が66％、タスクスループットが33.7％増加しました［3］。

　一方、同じ調査では、レビュー着手までの時間は156.6％、レビューに要する時間は441.5％増加しています。現在起きているのは、単純な「開発全体の高速化」ではなく、実装だけが先に高速化し、負荷が上流と下流へ移動している状態です。

図1：AI駆動開発による負荷の分散

　AI駆動開発では、実装の負荷が下がる一方、「何を作るべきか」を決める上流と、「生成されたものが正しいか」を確かめる下流の重要性が相対的に高まります。さらに、同時に扱える仕事が増えることで、開発者が抱える認知負荷も高まる可能性があります。

上流工程：意思決定の重みが増える

　上流工程そのものが遅くなっているわけではありません。Vella ＆ Blincoeの調査では、設計に費やす時間はわずかに減少しています［4］。

　ただし、Jellyfishの2026年レポートによると、AIの利用用途は「コードを書く」が53.1％なのに対し、「要件分析」は35.8％、「仕様作成」は24.2％でした。実装ほど上流工程はAIに委譲できていません［5］。

　人間に曖昧な仕様を渡せば、「Aですか、Bですか」と質問して止まることがあります。しかしAIエージェントは、足りない前提を推測し、それらしい実装を生成できます。そのため、上流の曖昧さは質問ではなく、動いてしまうコードとして返ってくる可能性があります。

　実装コストが下がるほど、誤った要求や設計判断も高速に実装できるようになります。重要なのは仕様書の量ではなく、要求や制約を具体化し、AIに任せる判断と人間が持つ判断を切り分けることです。

下流工程：作る仕事から、確かめる仕事へ

　コード生成が速くなるほど、「この変更を本当に通してよいのか」を判断する仕事が増えます。

　LinearBによる810万件規模のPR分析では、AI生成PRの受理率は32.7％だったのに対し、人間が作成したPRは84.4％でした［6］。AIがコードを書けば終わり、というわけではありません。

　Vella ＆ Blincoeの研究でも、82％が「コードを書く時間が減った」と回答する一方、レビューでは40％、テストでは42％が以前より時間を使う方向に変化しました。「作る仕事」から「確かめる仕事」へのシフトは統計的にも確認されています［4］。

　これまでレビューは、人間が書いたコードを別の人間が読む工程でした。AI駆動開発では、大量に生成される「もっともらしいコード」が、要求や設計意図に照らして本当に正しいのかを検証する工程へ変わりつつあります。

人間の認知能力が新しいボトルネックになる

　エージェントを使えば、一つひとつの作業時間は短くなります。その分、あるエージェントに実装を依頼しながら、別の出力やテスト結果を確認し、複数のPRをレビューする進め方が可能になります。

　手を動かす負荷は減る一方、判断対象とコンテキストスイッチは増えるのです。Vella ＆ Blincoeの研究でも、84％が生産性の改善を感じる一方、開発者体験が悪化した参加者は14％から27％へ増加しました［4］。

　この問題を長期的なソフトウェアの健全性から整理したのが、Margaret-Anne Storeyの「Triple Debt Model」です［7］。

図2：AI駆動開発で加速する3つの負債［7］

　このモデルでは、次の3つの負債が定義されています。

  • Technical Debt：アーキテクチャやコード品質に蓄積する負債
  • Cognitive Debt：システムに対する人間の理解や推論能力が失われる負債
  • Intent Debt：目的、制約、仕様、設計判断など意図が残らない負債

　AIが生成するコードでは、人間が実装過程を経験しないため、「なぜこの構造なのか」「どこを変えると何が壊れるのか」という理解が形成されにくくなります。

　AIが並列実行できるタスク数は増えても、人間が理解し、判断できる量が同じ速度で増えるわけではありません。

AI時代の生産性を何で測るのか

　コード量が増えていることと、コードベースが良くなっていることは同義ではありません。

　AIによって仕事の形が変わった以上、時間・行数・コミット数だけでは生産性を測りにくくなっています。見るべきなのは、 要求からリリースまでのリードタイム、レビュー待ち時間、手戻り、障害、そして最終的にどれだけ価値を届けられたか です。

まとめ

　AI駆動開発の本質的な変化は、単なるコーディングの高速化ではありません。

　実装コストが下がった結果、開発のボトルネックは、上流の意思決定、下流の検証、人間の認知能力へ移動しています。

　これから重要になるのは、AIにどれだけコードを書かせたかではなく、何を作るべきかを正しく決め、生成物を検証し、チームが理解可能な状態を維持しながら価値へ変換できたかということです。

　開発者の仕事は、コードを書く実装者から、AIに方向を与え、正しさを判断し、開発全体を監督する役割へと重心を移しつつあります。それに合わせて、開発方法だけでなく、生産性の測り方も再設計する必要があります。

著者プロフィール：渋谷 優介

ソフトバンクに新卒入社し、交換機の運用に従事。その後、エンジニアとして新規システム部門の立ち上げを経て、ベンチャー企業を複数社経験。2024年10月にAlgomaticへ参画。現在はHR領域で生成AIを用いたプロダクト開発をテックリードとして推進中。

・株式会社Algomatic：https://algomatic.jp/

開発者と読み解くAIの世界 記事一覧

Amazonで購入