AIで速くなったのは、一工程だけだった――国内企業の実測値で見るボトルネックの移動
2026.10.06 / Donut Service
AIに実装を任せれば、コードを書く工程は速くなる。ところが、チーム全体のリリースのペースは思ったほど変わらない――この不均衡について、これまでは海外のデータを引きながら整理してきました。500組織超の実測、開発者95名の縦断研究。どれも示唆に富む一方で、読者にとってはどれも「よその国の数字」でもありました。今回は、日本企業の実測値があります。
軸にするのは、ファインディ株式会社が2026年7月24日に Findy Tech Blog で公開した、自社主催イベント「AI DevEx Conference 2026」の登壇レポートです。登壇者は同社プリンシパルエンジニアの戸田氏。開発組織のAI推進を専任で担当している立場から、自社でAI導入の前後に指標がどう動いたか、そして改善のあとに数字がどう変わったかまでを公開しています。研究の多くが「こうなっている」で止まるのに対し、この事例は「見えたあと何をして、結果どうなったか」まで追える。そこが貴重です。
1. 最初に断っておくこと――出どころの利害と、n = 1 の限界
第一に、利害関係です。ファインディは「Findy Team+」「Findy AI+」という開発生産性の可視化サービスを販売する企業であり、このレポートの結論のひとつは「可視化が必要不可欠」です。つまり、自社商材の必要性を補強する構図にあります。これは以前「AIで浮いた時間はどこへ消えるのか」でDX社のレポートを扱ったときとまったく同じ構図で、本記事も同じ扱いをします。利害を伏せずに、数字自体は素直に読む。
第二に、これは1社の事例です。対照群はなく、採用や事業フェーズ、ツールの世代交代といった外部要因の統制もありません。「こうすればこうなる」とは読めない数字です。それでも引く価値があると筆者が考えるのは、海外の研究が集計データで捉えてきたのと同じ現象が、国内企業のダッシュボードにも現れたという事実そのものに意味があるからです。
2. 可視化して見えたこと――速くなった一工程、詰まった工程
同社が Findy Team+ で2024年と2025年を同一条件で比較した結果は、次の4つの数字に集約できます。
- コミットからオープンまでの平均時間：−10%
- 1人あたりのPull request作成数：横ばい
- レビューからApproveまでの時間：+50%
- 平均コメント数：+30%
コードを書く工程は確かに速くなった。しかし1人あたりの成果物は増えておらず、レビューからApproveまでの時間は5割延び、コメントのやり取りは3割増えた。登壇者の総括は端的です。「AIが速くしたのは『コード生成』という一工程だけでした」。
3. なぜ全体は速くならないのか――負荷は消えず、隣の工程へ移る
書く負荷が減った分だけ、読む・検証する負荷がレビュー工程に積み上がる。この「負荷の移動」の仕組み自体は「開発者95名を6か月追った縦断研究の記事」で整理したので、ここでは繰り返しません。あちらの研究が「負荷の移動は集計の生産性指標には映らない」ことを示したのに対し、今回の事例が示すのはその手前です。工程ごとの時間まで分解して眺めれば、移動そのものは数字に現れる。逆に言えば、リードタイムの合計だけを見ていたら、「速くなったはずなのにリリースが変わらない」という体感の正体は、最後まで見えなかったはずだということです。
4. 打ち手の順序――「基本」と「基礎」が先、AIはその増幅器
ボトルネックがレビューに見えたあと、同社が最初に手を入れたのはAIツールの追加ではなく、レビュー体制や開発の進め方といった土台の整備でした。「土台がないままAIを載せると、弱さも増幅されます」。増幅器としてのAIという見方は、DORAの2025年レポートが示したものと重なります。
改善後の数字も公開されています。2025年と2026年前半の比較で、1人あたりのPR作成数は約1.5倍。レビュー指摘数、レビューからApproveまでの時間、平均コメント数はいずれも横ばいでした。ここで注意が2つあります。まず、悪化を示した比較は2024年対2025年、改善を示した比較は2025年対2026年前半で、同じ期間の前後比較ではありません。次に、同社はこの結果を「質を落とさずに量を増やせた」と読んでいますが、レビュー指摘数が横ばいという数字は、レビューの負荷が増えていないことは示しても、質が保たれたことまでは保証しません。見逃しが増えても指摘数は減るからです。ここは同社の解釈として引いておきます。
5. 兼務から専任へ――体制を変えたら施策の速度が変わった
もうひとつ、この登壇で目を引くのは体制の話です。同社はAI推進を当初、通常業務との兼務で回そうとして、そこで壁に当たったと明かしています。「AIのアップデートは毎週のように発生します。その検証・展開・教育を、通常業務と兼務しながら同時並行で進めるのは、物量的に無理がありました」。ツール選定のような一度きりの仕事なら兼務でも回るかもしれません。しかしAIの検証・展開・教育は毎週補充される種類の仕事で、こなさなくても要求だけが積み上がっていきます。しかも「兼務だと優先度が下がり、誰が責任を持つのかも曖昧になりがちです」。本来業務が締め切りを持つ以上、締め切りのない推進業務は構造的に後回しになり、遅れた分だけキャッチアップの負担が膨らむ。要求は増え続けるのに、それに見合う時間も責任の所在も配分されていなかった、ということです。
そこで同社は組織構造を変え、AI推進の専任ポジションを置いて情報集約・検証・展開を一気通貫で担う体制にしました。「専任化の前後をFindy Team+で計測すると、AI推進のアクティビティは10倍以上に増えていました」。増えたのはあくまで「AI推進のアクティビティ」であって開発全体の生産性ではない、という点は正確に読む必要がありますし、「兼務なら10分の1になる」という逆向きの一般化もできません。それでも「同じ人月でも、構造を変えるだけで施策のスピードは大きく変わります」という一文は、推進役の兼務者が本来業務との二重の要求を負いがちだという意味で、「JD-Rモデルの記事」で見た「要求」と「資源」の配分の、具体的な一例として読めます。
6. まとめ――自分の環境で、何を並べて見るか
- 2024年対2025年の同一条件比較で、コミット→オープンは−10%、PR作成数は横ばい、レビュー→Approveは+50%、コメント数は+30%（ファインディ社の自社実測）
- 改善後（2025年対2026年前半。比較期間は上と異なる）は、PR作成数が約1.5倍で、レビュー指摘数・Approve時間・コメント数は横ばい
- 速くなったのは「コード生成」という一工程だけで、ボトルネックはレビュー工程へ移動した
- n = 1 の事例であり、可視化サービスを売る企業の発信でもある。一般化はできないが、研究と同じ現象が国内企業のダッシュボードにも現れた
「では可視化ツールを入れよう」と締めるつもりはありません。読者の多くは、専用サービスを導入できる立場にいるとは限らないからです。GitHubの標準機能だけでも、「コミットからPRオープンまで」と「レビュー依頼からApproveまで」の2つの時間は追えます。まずこの2つを並べて眺めるだけで、自分のチームのボトルネックがどちら側にあるのかは見当がつきます。
なお、個人開発者には、そもそも「レビュー待ち」が存在しません。自分で書いて自分でマージするからです。ただし代わりに、自分がレビュアーを兼ねています。筆者もレガシーPHPの保守案件では、生成そのものより「この変更で壊れないか」の検証に時間を取られます。生成が速くなるほど仕事の重心が検証へ寄っていく構図は、チームでも個人でも変わらないようです。
BrainSync Focus Timer のご紹介
仕事の重心がレビューと検証に寄るほど、まとまった集中時間の設計が効いてきます。私たち Donut Service が開発した BrainSync Focus Timer は、VS Code・Cursor のステータスバーに常駐するタイマーで、25/5（ポモドーロ）と52/17（ロングブロック）を切り替えながら使えます。生成を指示して待つ時間と、腰を据えて読む時間。リズムを分けて設計する道具としてお使いください。
休憩のタイミングを自動で知らせるポモドーロタイマー。無料でインストールできます。
BrainSync Focus Timer をインストールする →Cursor をお使いの場合は Open VSX 版 をご利用ください。
※ 効果には個人差があります。本記事は医療助言ではありません。
BrainSync — ソフトウェアエンジニアの心と脳を、やさしく整える。
ドーナツサービス · 東京
参考文献
- 戸田（starfish719）(2026). AI導入の「期待外れ」を乗り越える ─ 可視化と改善のサイクル、基本と基礎の徹底｜AI DevEx Conference 2026 登壇レポート. Findy Tech Blog（2026年7月24日）. https://tech.findy.co.jp/entry/2026/07/24/070000
