開発者は生産性が25〜39%上がったと感じている。でも会社のKPIは1ミリも動いていない。
これは感覚の問題ではない。データが示している現実だ。Faros AIが10,000人以上の開発者・1,255チームを対象に行った調査によると、AIコーディングツールを採用した組織では、PRのサイズが平均154%膨張し、開発者1人あたりのバグが9%増加した。個人の生産性が上がっているのに、組織全体の指標は改善していない——これが「AIコーディング生産性パラドックス」の実態だ。
3つの数字が示す現実
Faros AIは、ソース管理・タスクトラッカー・CI/CDシステムなど複数のテレメトリーデータを統合して分析した。個々の開発者の「感想」ではなく、実際のコードとワークフローから計測したものだ。
AIツール採用前後で何が変わったかを示す主要数値がある。
| 指標 | 変化 |
|---|---|
| PRサイズ（行数） | +154% |
| PRマージ数（開発者1人あたり） | +98% |
| PRレビュー時間 | +91% |
| バグ数（開発者1人あたり） | +9% |
PRの数は倍近くに増えた。コードを書く速度が上がったのは本当だ。しかしPR1件あたりのサイズも154%膨らんだ。レビューにかかる時間は91%増加した。その結果、組織全体のスループットは「有意な改善なし」という結論になった。
同じ期間、Googleが主導するDORA（DevOps Research and Assessment）は39,000人以上を対象に調査を行い、AIツール採用が25%増加したにもかかわらず、配信スループットが1.5%低下し、配信安定性が7.2%低下したと報告している。
なぜPRが154%大きくなるのか
AIはコードを「追加する」道具だ。「削る」道具ではない。
これを理解するには、AIがコードを生成する仕組みを知る必要がある。AIは「次に来る可能性が高いコード」を予測して出力する。そのパターンは、学習データに含まれていた「丁寧に書かれた完全なコード」を参照している。だから自然と、守備的なエラーハンドリング、詳細なバリデーション、豊富なコメント、全エッジケースへの対応が付いてくる。
// ❌ AIが生成する「守備的すぎる」コード（典型例）
// 2週間後に手直しが必要になりやすい
function validateEmail(email: string): ValidationResult {
const EMAIL_REGEX = /^[a-zA-Z0-9.!#$%&'*+/=?^_`{|}~-]+@[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?(?:\.[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?)*$/;
const MAX_LENGTH = 254; // RFC 5321準拠
const MIN_LENGTH = 3;
if (!email) return { valid: false, error: "Email is required", code: "MISSING" };
if (typeof email !== "string") return { valid: false, error: "Must be string", code: "TYPE_ERROR" };
if (email.length < MIN_LENGTH) return { valid: false, error: "Too short", code: "TOO_SHORT" };
if (email.length > MAX_LENGTH) return { valid: false, error: "Too long", code: "TOO_LONG" };
if (!EMAIL_REGEX.test(email)) return { valid: false, error: "Invalid format", code: "INVALID_FORMAT" };
return { valid: true, normalizedEmail: email.toLowerCase().trim() };
}
// ✅ 人間が書く同等のコード（シンプルで読みやすい）
function validateEmail(email: string): boolean {
return /^[^\s@]+@[^\s@]+\.[^\s@]+$/.test(email);
}
LogRocketの分析によると、REST APIエンドポイントを人間が書くと29行になるところを、AIが書くと186行になる（6.4倍）。エラーハンドリングのリファクタリングでは、16行の関数が288行に膨らんだ（1,700%増）という事例もある。
「動いた！」で止まる開発者の行動パターンも原因のひとつだ。AIが生成したコードが一応動けば、整理・削除・リファクタリングをせずに次に進む。コードは積み上がり、PRは膨れ上がる。
アムダールの法則という壁
工場の生産ラインを想像してほしい。AIは原材料の加工を3倍速にした。でも出荷口は同じ広さのままだ。
これがFaros AIが「アムダールの法則」と呼ぶ現象だ。アムダールの法則とは、並列化できる処理の一部を速くしても、並列化できない処理が残る限り、全体の改善には上限があるというものだ。開発パイプラインに当てはめるとこうなる。
コーディングは開発パイプライン全体の約30%を占める工程に過ぎない。仮にAIがコーディングを10倍速にしたとしても、理論上の最大改善は30%だ。そしてコーディングが速くなればなるほど、レビューという非並列化できない工程がボトルネックになっていく。
AIでコードを書く速度が10倍になっても、レビューの速度が変わらなければ、全体のスループットはむしろ悪化する。コードが増えれば増えるほど、レビュアーの負荷が上がるからだ。
コードの「質」も劣化している
スループットだけの問題ではない。コードそのものの質も変化している。
GitClearは2億1,100万行のコードを分析し、AI普及前後の変化を数値化した。コードチャーン（書いてから2週間以内に修正・削除されるコード）の割合が2020年から2024年にかけて大幅に増加した。既存コードを整理して再利用する「リファクタリング」は、2021年の変更行全体の25%から2024年には10%未満に減少している。
GitClearのレポートタイトルは「4x Growth in Code Clones（コード複製が4倍成長）」だ。コード複製とは、既存のコードをコピーして貼り付ける行為だ。AIは既存コードを整理・再利用するより、新たにコードを生成する。その結果、似たようなコードが各所に生まれ、長期的な保守コストを押し上げる。
AIが生成するコードは短期的には動くが、整理されていないまま積み重なっていく。コードベースが大きくなるほど、次にAIに頼んだときの精度が下がり、バグが増える——という悪循環に入りやすい。
「速くなった」という体感はどこから来るのか
では、なぜ開発者は「AIで速くなった」と感じるのか。
METRが2025年に行った実験がある。経験豊富な開発者16名を対象にしたランダム化比較試験で、AIツールを使った条件と使わない条件でタスク完了時間を計測した。
結果は驚くべきものだった。AIを使うと生産性が+24%上がると事前に予測し、使った後の体感も+20%速くなったと報告した。しかし客観的な計測では19%遅くなっていた。
事前予測+24%・事後体感+20%・客観測定-19%という三層の乖離だ。「速くなった感覚」は本物だが、その感覚が正しいとは限らない。
この乖離が起きる理由のひとつは、AIが「詰まらせない」という体験にある。考える時間が見えなくなり、手を動かしている時間が増える。主観的には速く感じるが、生成したコードの検証・修正・整理に使う隠れたコストが計測されていない。
開発者はAI生成コードを信頼していない
もうひとつの数字がある。開発者自身がAI生成コードをどう扱っているかだ。
DORAの調査では、39%の開発者が「AI生成コードをほとんど信頼しない」と回答している。約4割の開発者が、AIが出したコードをそのまま使わずに慎重に確認している。
開発者はAIを「完成品を出すツール」ではなく「叩き台を出すツール」として扱っている。叩き台を丁寧に確認するコストが、生成速度のメリットを相殺している。
LogRocketが指摘するように、AIコードのレビューは質的に異なる。人間が書いたコードをレビューするときは「正しく動くか」を確認する。AIが書いたコードをレビューするときは「正しく動くか」に加えて「本当に必要なのか」を確認しなければならない。守備的すぎるエラーハンドリング、不必要に詳細なバリデーション、重複した処理——これらが「必要かどうか」を判断するには、コーディングの知識より設計の知識が要る。シニアエンジニアほどAIコードのレビューに時間がかかるのはそのためだ。
組織投資のROIが出ていない
IBMが2024年に行った調査では、2,400人以上のIT意思決定者のうち、AI投資でポジティブなROIが出た企業は47%にとどまった。33%が損益分岐点、14%がマイナスROIと報告した。
Asanaの2025年レポート「The AI Super Productivity Paradox」も同じ構造を指摘している。個人のアウトプットは増えるが、組織のシステムがそれを吸収できていない——これがパラドックスの根本だ。
ツールを導入した。でも使い方は変えなかった。コードを書く速度だけ上がって、後の工程は据え置きのまま——という状況が組織の多数派だ。
ボトルネックはレビューだ
パラドックスを解消するには、ボトルネックを正しく特定する必要がある。AIの恩恵を受けているのはコーディング工程だ。詰まっているのはレビュー工程だ。
速くすべきはコーディングではなく、レビューだ。
具体的なアプローチとしていくつかの方向性がある。
PRサイズの上限設定はシンプルかつ効果的だ。「1PRあたり400行まで」「1機能1PR」などのルールを設けると、AIが生成した大量のコードを小さい単位に分割して提出するよう開発者の行動が変わる。Graphiteのようなスタックドプルリクエスト方式も、大きなPRを段階的にマージする仕組みとして機能する。
AIをレビューにも使う方向性もある。CodeRabbitやGitHub Copilot for PRなど、AIがPRを自動レビューするツールが存在する。生成AIにコードを書かせ、別のAIにレビューさせることで、人間レビュアーの負荷を下げる。
テスト自動化の強化も欠かせない。AI生成コードはバグが多い。テストカバレッジを上げると、レビュー前にバグを検出できる割合が増え、レビューコストを下げられる。
// ❌ AIが生成したコードをそのままPRに出す（500行、レビュー20分）
// - 全エッジケースのハンドリング
// - 詳細なログ出力
// - 複数のユーティリティ関数
// - バリデーションロジック
// ... 500行
// ✅ PRを分割して出す（各100行以下、レビュー5分）
// PR #1: コアロジック（100行）
// PR #2: バリデーション（80行）
// PR #3: エラーハンドリング（90行）
// PR #4: テスト（120行）
「AIを入れる前に」問うべきこと
AIツールを導入する前、あるいは導入した後にうまく機能していないと感じたときに確認すべき問いがある。
今のチームで、PRレビューが詰まることがどれくらいあるか。PRが出てからマージされるまでの平均時間はどれくらいか。レビュアーが1日にレビューできるPRの件数には上限があるか。
これらの問いに答えを持っていないまま「AIでコードを速く書けるようにしよう」と動いても、出荷口の広さは変わらない。原材料の加工を3倍速にしても、出荷口が詰まったままなら在庫が積み上がるだけだ。
Faros AIのデータが示すのは「AIを使うな」ではない。「AIを使うなら、レビュープロセスも一緒に変えろ」ということだ。コーディングだけ速くなった組織が、かえってスループットを下げている。その現実から目を背けないことが、AIを本当に使いこなす第一歩だ。
個人の体感と組織の数値が乖離する現象は、AIコーディングに限った話ではない。新しい技術が入ると、まず「速くなった感覚」が先行し、全体最適化は後からついてくる。今がその踊り場にある。PRサイズを計測してみてほしい。AIを使い始めてから、どう変わったか。その数値が、次の一手を教えてくれる。