10%の壁：AIの生産性が頭打ちになる理由

DXは450社にわたる12万1,000人の開発者を調査しました。92.6%が少なくとも月1回はAIコーディングアシスタントを使用しています。AI生成コードは本番マージの26.9%を占めるようになりました。開発者は週あたり約4時間の節約を報告しています。¹ しかし、生産性は10%を超えていません。

この数字は3四半期連続で横ばいです。^{1 2} 導入率は上がりました。コード量も増えました。ツールも改善されました。しかし、成果は変わりませんでした。DXのCTOであるLaura Tachoは率直にこう述べています。「これは本質的にマネジメントの問題です。AIを試すだけで自動的に成果が出るかのような過大な期待がありました。」³

2025年のDORAレポートはこの乖離を明らかにしました。優れたエンジニアリングプラクティスを持つ組織では、AIが既存の強みを増幅しました。弱いプラクティスを持つ組織では、AIが既存の機能不全を増幅しました。同じツールで、正反対の結果です。レポートはこう結論づけています。「ソフトウェア開発におけるAIの主な役割はアンプリファイア（増幅器）です。高パフォーマンス組織の強みと、苦戦している組織の機能不全の両方を拡大します。」⁴

壁はモデルの問題ではありません。インフラの問題です。検証の欠如、コンテキストの欠如、ガバナンスの欠如によって築かれた壁は、より優れたモデルでは突破できません。本記事の姉妹記事がそのアーキテクチャを解説しています。Anatomy of a Clawではオーケストレーション層を、The Fabrication Firewallではアウトプットゲートを、Context Is Architectureではコンテキスト注入システムを説明しています。以下の記事では、それらのシステムがなぜ必要なのかを解説します。

TL;DR

12万1,000人の開発者を調査、92.6%が導入、生産性は10%で停滞。3つの根本原因がこの天井を説明します。コンテキスト飢餓（AIがプロジェクト知識なしに推測する）、検証の空白（レビューが追いつかないほど速くコードが出荷される）、ガバナンスのギャップ（AIが人間が強制する基準をバイパスする）です。DORAは、AIがその周囲のインフラ次第で強みも機能不全も増幅することを発見しました。⁴ 突破に必要なのは、より優れたAIではなく、AIを取り巻くインフラです。本記事では、そのインフラ構築のN=1の試みを、84のフック、43のスキル、19のエージェントを稼働させているシステムの具体的な数値とともに記録しています。

調査が示していること

DXのデータセットは、2025年11月から2026年2月にかけて観測された420万人の開発者を対象とし、450社にわたる12万1,000人の開発者の詳細パネルを含んでいます。¹ この数字は2つの物語を語っています。

導入の物語は明白です。 AIコーディングアシスタントはほぼ全員に普及しました。DXは月間92.6%の導入率と約75%の週間利用率を計測しました。¹ Stack Overflowの2025年調査では、84%の開発者がAIツールを使用中または使用予定と回答しています。⁶ JetBrainsは194カ国24,534人の開発者を対象に85%の定常利用率を計測しました。⁷ 導入の天井は近づいています。

生産性の物語は停滞しています。 DXは週あたり平均4時間の節約を計測しましたが、前四半期の3.6時間から変化はありません。^{1 2} AI生成コードは22%から26.9%に増加しましたが、コード量の増加はアウトプットの増加にはつながりませんでした。^{1 2} Laura Tachoはその計算を指摘しています。開発者がコードを書くのに費やす時間は業務時間の約20%です。業務時間の20%に対する10%の改善は、全体としてわずか2%の改善にすぎません。「タイピング速度がボトルネックだったことは一度もありません。」⁸

重要なのは最後の行です。DORAの2024年レポートは39,000人の専門家を調査し、AI導入が25%増加するごとに、デリバリースループットが推定1.5%低下し、デリバリー安定性が7.2%低下することを発見しました。⁵ 2025年のDORAレポートでは、AIとスループットの関係が2024年に観測された負の相関から正の相関へと変化しましたが、デリバリー安定性はAI導入と依然として負の相関を示していました。⁴ スループットが改善しても、AI導入は不安定性の増加と相関し続けました。

平均値よりも乖離のほうが重要です。METRは246件の実際のリポジトリイシューに取り組む16人の経験豊富なオープンソース開発者を調査し、AIツールを使用した場合に19%長くかかることを発見しました。⁹ Googleの96人のエンジニアによるランダム化比較試験では21%の速度改善が見られましたが、統計的に有意ではありませんでした（95%信頼区間がゼロをまたいでいた）。¹⁰

McKinseyは単純なタスクで35〜50%の向上を見出しましたが、高複雑度タスクでは10%未満であり、自社の40人の開発者を対象とした調査ではジュニア開発者がAIを使用すると7〜10%遅くなりました。¹¹ パターンは明確です。AIは開発プロセスの中でそもそもボトルネックではなかった部分を加速させています。

突破した企業は、より優れたモデルを使ったのではありません。モデルが見落とすものをキャッチするインフラを構築したのです。

なぜ壁が存在するのか

3つの根本原因がこの停滞を説明しています。それぞれが独立して作用します。組み合わさると、より優れたモデルでは突破できない天井を形成します。

コンテキスト飢餓

AIコーディングアシスタントは、現在のファイルに表示されているコードとプロンプトウィンドウに収まるコンテキストだけで動作します。アーキテクチャ上の決定、APIのコントラクト、デプロイの制約、チームの命名規則は、誰かがその情報を注入しない限り知りません。

プロジェクト固有のコンテキストがなければ、モデルは推測します。もっともらしい規則に従うが実在しないファイルパスを捏造します。一般的なパターンには合致するがあなたのパターンには合致しないAPIのエンドポイントへの呼び出しを生成します。プロジェクトが使用していないパッケージからのインポートを提案します。¹²

Faros AIは1,255チームにわたる10,000人の開発者のテレメトリを分析し、AI支援のプルリクエストはAI非支援のものより154%大きいことを発見しました。¹² 大きなPRはコンテキスト依存のエラーの表面積が広くなります。AIは自信を持ってコードを生成します。コードはコンパイルされます。しかし、AIが一度も見たことのないConfluenceページに記載された制約は考慮されていません。

この挙動はモデル安全性の意味でのハルシネーション問題ではありません。モデルは設計どおりに機能しています。つまり、利用可能なコンテキストに基づいてもっともらしいコードを予測しているのです。問題は、利用可能なコンテキストが特定のコードベースでの正確性に重要な情報のほとんどを除外していることです。

検証の空白

AIは既存のレビュープロセスが吸収できるよりも速くコードを生成します。Farosは、AI支援のPRはレビューに91%長くかかることを発見しました。¹² 開発者は21%多くのタスクを完了し、98%多くのプルリクエストをマージしますが、レビューパイプラインは人間の速度の出力に対応しています。¹²

Stanfordの安全でないコードに関する研究はセキュリティの側面を定量化しました。研究者は47人の開発者にAI支援ありとなしでコーディングタスクを与えました。AI支援グループは5つのタスクのうち4つでより頻繁に安全でないソリューションを書きました。SQLインジェクションのタスクでは、AIグループの36%が脆弱なコードを書いたのに対し、コントロールグループでは7%でした。AI支援を受けた参加者は、安全でないコードを書いていたにもかかわらず、自分のコードが安全だと信じる傾向がありました。¹³ 出力の高速化と偽りの自信の増大の組み合わせが、手動レビューではスケールで埋められない検証のギャップを生み出しています。

GitClearは1億5,300万行のコード変更を分析し、コードチャーン（書かれてから2週間以内に書き直されるコード）がAI以前のベースラインに比べて2024年には倍増すると予測しました。¹⁴ AIツールによるコード量の増加は、生産性向上を部分的に相殺する手戻りを生み出しています。Stack Overflowの2025年調査はこの摩擦を裏付けています。66%の開発者が「ほぼ正しい」AI生成コードの修正により多くの時間を費やしていると報告しています。⁶

ガバナンスのギャップ

AI生成コードは、人間の開発者が内面化しているガバナンスメカニズムをバイパスします。シニア開発者はスタイルガイドを確認し、リンターを実行し、変更ログを更新し、アーキテクチャ変更についてチームリードに通知することを知っています。AIアシスタントはプロンプトを満たすソリューションを生成します。「コンパイルが通りテストをパスする」と「組織の基準を満たす」の間のギャップがガバナンスです。

McKinseyの研究者は、ジュニア開発者の速度低下の原因を、生成されたコードと組織コンテキストのギャップに帰しました。ジュニア開発者にはまだ内面化していない基準にAIの出力が適合するかどうかを評価する判断力がありません。それらの基準を自動チェックとしてエンコードするガバナンスインフラがなければ、AIの出力はチェックされずに下流へ流れます。

ガバナンスのギャップはチーム全体で複合的に悪化します。ある開発者のAI生成ユーティリティが別の開発者の既存モジュールと重複します。2つのAI生成エンドポイントが同じAPIに対して異なるエラーフォーマットを使用します。AI生成のマイグレーションがチーム標準とは異なる命名規則に従います。個々の違反は小さなものです。累積的な影響として、コードベースがレビューで修正できるよりも速く自身の規則から逸脱していきます。

壁の向こう側はどうなっているか

DORAの発見は、同一のツールを使用する2つの集団を描写しています。優れたプラクティスを持つ組織ではAIが強みを増幅しました。弱いプラクティスを持つ組織ではAIが機能不全を増幅しました。⁴ 両者の間の変数は、どのAIを使うかではありません。AIの周囲にあるインフラです。

各根本原因はインフラによる修正に対応します。以下の表は、問題から解決策への連鎖を示し、姉妹記事で文書化したシステムからの具体的な実装例を1つ挙げています。この例は具体的な数値を伴う1つの試みであり、万能の処方箋ではありません。

コンテキスト注入は、モデルが全プロンプトでプロジェクト固有の情報を受け取ることで飢餓に対処します。ディスパッチャーフックが9つのシーケンシャルハンドラーを起動し、現在の日付、Gitブランチ、作業ディレクトリ、プロジェクトの規則、アクティブなタスクコンテキスト、アーキテクチャ上の制約を注入します。モデルはユーザーのリクエストを処理する前に200〜400トークンのグラウンディングコンテキストを受け取ります。計測レイテンシ：9つのフック全体で合計200ms。モデルは実際のパスを伝えられているため、ファイルパスの推測をやめます。¹⁵

独立した検証は、ルーチンチェックの検証ボトルネックから人間を除外することで空白に対処します。自律開発ループ（Anatomy of a Clawで文書化）はコードを生成し、完全なテストスイートを実行し、結果を独立して動作する3つのレビューエージェントに提出します。実装エージェントは自分自身の出力をレビューしません。この分離は、Stanford研究でAI支援グループが安全でないコードに対してより自信を持っていたという知見を反映しています。自己検証は、著者が人間であれ人工知能であれ信頼できません。¹³

自動ガバナンスは、チーム基準を実行可能なチェックとしてエンコードすることでギャップに対処します。The Fabrication Firewallは、すべてのアウトバウンドアクションをローカル、共有、外部に分類し、外部公開を人間のレビューに委ねます。品質ゲートは、テスト出力やファイルパスを引用する代わりに曖昧な表現（「動くはずです」「正しいようです」）を使用する完了報告をブロックします。このシステムは、人間の開発者が全行をレビューする時間があれば適用するであろう基準を強制します。AI生成速度では、その時間はありません。

統合されたシステムは自身のコードベースで計測可能な成果を生み出しています。セマンティック検索用に4,518のコードチャンクがインデックスされ、15,800ファイルにわたる49,746のボールトチャンクが永続メモリとして機能し、テストスイートは変更が完了を報告する前に自動実行されます。¹⁵ これらの数値は1人の開発者のインフラを記述しています。このアプローチが一般化できることを証明するものではありません。しかし、壁の向こう側に適切なツールがあれば壁は透過可能であることを示すことはできます。

ガバナンス比率

Anatomy of a Clawで解説されているフックシステムは84のフックを含んでいます。機能別の検証済みカウントは、何かを実行すべきかを判断する35の判断フック、あらかじめ決められたアクションを実行する44の自動化フック、5つのユーティリティフック（ディスパッチャー、状態管理）に分けられます。ガバナンス比率は4:5です。開始時は1:6でした。¹⁵

開始時の比率は、ほとんどのチームが最初に構築するものを反映しています。つまり自動化です。コンテキストを注入する。メトリクスを記録する。出力をフォーマットする。使用状況をログに残す。これらのフックが、誰もが得られる10%を捕捉します。AI以前からすでに部分的に自動化されていた開発の機械的な部分を自動化するのです。DXのデータはこれを裏付けています。週あたり4時間の節約は、コード生成とボイラープレート削減、つまり開発サイクルの中ですでに最速だった部分のタスクから来ています。¹

判断フックへのシフトは、追加の成果がどこから来るかを反映しています。

McKinseyの2025年の約300社の上場企業調査では、最高パフォーマンス企業が生産性で16〜30%、品質で31〜45%の改善を達成していました。¹⁶ これらの組織は80〜100%の開発者導入率と組織統合を兼ね備えていました。差別化要因は導入率（全体で10%の向上と相関する）ではなく、その導入の周囲に構築されたインフラとプロセスでした。

Laura Tachoの指摘はここにも当てはまります。「根本的な制約に対処せずにパフォーマンスを改善するというテクノロジーの約束には懐疑的です。」³ 根本的な制約は判断の制約です。このコードは基準を満たしているか？この変更は下流で何かを壊さないか？この出力に捏造が含まれていないか？自動化フックはこれらの問いに答えられません。判断フックは、経験豊富な開発者が頭の中で適用する基準をエンコードすることで、不完全ながらも答えることができます。

比率はまだ均衡に達していません。このシステムはまだ統治するよりも多く自動化しています。この不均衡自体が診断指標です。自動化フックが判断フックを上回るオーケストレーション層には改善の余地があります。

実際に構築すべきもの

姉妹記事で解説されたシステムは84のフック、43のスキル、19のエージェント、15,000行のインフラを持っています。¹⁵ 15,000行は必要ありません。必要なのは3つです。

コンテキスト注入フック1つ。 現在の日付、ブランチ、作業ディレクトリを全AIプロンプトに注入する5行のbashスクリプトです。この注入はハルシネーションの一カテゴリ全体を排除します。モデルは実際のファイルパスとブランチ名を持っているため、推測をやめます。

#!/bin/bash
# inject-context.sh — minimum viable context injection
echo "Date: $(date +%Y-%m-%d)"
echo "Branch: $(git branch --show-current 2>/dev/null || echo 'not a git repo')"
echo "Directory: $(pwd)"

品質ゲート1つ。 完了報告から曖昧な表現をgrepする15行のスクリプトです。エージェントがテスト出力を引用する代わりに「動くはずです」と言えば、ゲートがブロックします。このゲートは最もコストの低いエントリーポイントで検証の空白に対処します。¹⁵

#!/bin/bash
# quality-gate.sh — minimum viable verification
INPUT=$(cat)
HEDGES=$(echo "$INPUT" | grep -ciE '\bshould (work|pass|be fine)\b|\bprobably\b|\blooks correct\b')
if [ "$HEDGES" -gt 0 ]; then
  echo '{"decision":"block","reason":"Hedging language detected. Cite test output instead."}'
else
  echo '{"decision":"allow"}'
fi

独立したテストランナー1つ。 コード変更のたびにプロジェクトのテストスイートを実行し、テストが壊れた場合に明確に失敗するフックです。実装はプロジェクトごとに異なります。原則は変わりません。コードを書くエージェントが、そのコードの唯一の審判であってはなりません。

ワークフローで最も壊れやすい部分から始めてください。AIがファイルパスを捏造するなら、コンテキストフックを最初に構築してください。AIがテストされていないコードを出荷するなら、テストランナーを最初に構築してください。AIがエビデンスなしに「完了」と書くなら、品質ゲートを最初に構築してください。

Karpathyはバイブコーディングからエージェンティックエンジニアリングへの進化を説明しました。「作業を行うエージェントをオーケストレーションし、監督として行動する。」¹⁷ 上記の3つのフックは最小限の実行可能な監督です。30%の向上は生み出しません。しかし、10%から15%へと前進させ、追加するたびに次に対処すべき制約が明らかになります。

壁は現実です。しかし、具体的でもあります。コンテキスト飢餓、検証の空白、ガバナンスのギャップはエンジニアリングの問題であり、エンジニアリングによる解決策があります。モデルは改善され続けるでしょう。しかし、AIをコードジェネレーターとして扱い、その出力を統治するインフラを構築しないチームにとって、壁は10%のままです。

重要なポイント

個人の開発者向け。 コンテキスト注入フック1つから始めてください。日付、ブランチ、作業ディレクトリを注入する5行のbashスクリプトが、AIハルシネーションの一カテゴリ全体を排除します。モデルが推測ではなく実際のファイルパスを知った時、壁は崩れ始めます。

チームリーダー向け。 ガバナンス比率を計測してください。AIフックのうち、出力を検証するものとタスクを自動化するものの比率はどうなっていますか。自動化フックが判断フックを上回っているなら、チームは最初の10%しか捕捉していません。DXのデータは、週あたり4時間の節約がコード生成、つまり開発サイクルの中ですでに最速だったタスクから来ていることを確認しています。¹

プラットフォームエンジニア向け。 AI導入を拡大する前に検証レイヤーを構築してください。DORAは、エンジニアリングインフラなしにAIを導入した組織で、導入とともに不安定性が増加したことを発見しました。^{4 5} 3つの根本原因は3つのインフラ修正に対応します。パイプラインで最も摩擦を引き起こしているものから始めてください。

Sources