AIで浮いた時間はどこへ消えるのか――速度は上がったのに開発者体験が下がる理由

2026.09.01 10 分で読める 102 views

2026.09.01 / Donut Service

AIに実装を任せれば、時間は浮く。ここはもう疑っていません。実測でも、AIを使う開発者は週に4〜6時間を節約していると推定されています。ところが、「浮いた時間で新しいことができている」という実感は、数字の上でも体感の上でも、どうにも薄い。速くなったはずなのに、勘定が合っていないのです。

前回の記事「AIコーディング時代、エンジニアの認知負荷はどう変わったか」では、個人の頭の中で起きた変化——「書く負荷」から「読む負荷」への重心移動——を整理しました。今回はその続編として、組織とシステムの側で何が起きているのかを追います。

軸にするのは、DX社が2026年7月22日に公開した「State of AI Impact in Engineering: Q2 2026」（著者は同社 Deputy CTO の Justin Reock 氏）です。500を超える組織を DX Core 4 と DX AI Measurement Framework という一貫した枠組みで測り続けている四半期レポートで、「速度は上がったが、体験は下がった」という不均衡を数字で示しています。ただし、この数字の扱いには最初に断っておくべきことが2つあります。

1. 最初に断っておくこと——出どころの利害と、因果の限界

第一に、利害関係です。DX社は開発者体験（DevEx）の計測プラットフォームを販売するベンダーです。つまり「開発者体験が下がっている」という発見は、同社の商材の必要性を補強する構図にあります。本記事はこの点を伏せずに数字を扱います。

第二に、このデータから因果は言えません。これは同社自身が明言していることで、業界のAI採用率が90%を超えた今、「AIを使わない群」を対照群とする比較はもはや成立しません。以下の数字はすべて、AI導入と同じ期間に起きた時系列の併走であって、「AIが開発者体験を下げた」という証明ではないのです。

それでも引く価値があると筆者が考えるのは、特定の主張のために切り取られた単発の調査ではなく、同じ枠組みで測り続けられている定点観測だからです。この前提を共有したうえで、中身に入ります。

2. 実測が示す不均衡——速度の指標と体験の指標

レポートの骨子は、次の4つの数字に集約できます。

AI生成コードの比率：34%（Q1 2026）→ 52%（Q2 2026）。半年でほぼ倍増
プルリクエストのサイズ：中央値がほぼ倍増
時間の節約：AI利用者で週4〜6時間（推定）
Developer Experience Index（DXI）：67 → 65（Q3 2025→Q2 2026の4四半期）

書く側の指標は、明確に伸びています。一方でDXIの低下は、取材記事によれば同社の測定史上初めてのことで、Reock 氏はこれをエンジニア1人あたり年間およそ20時間ぶんの新たな摩擦に相当すると説明しています。

投資側の数字も並べておきます。組織あたりのAI支出は、四半期中央値で約1,500ドルから約44,000ドルへ増えました（4四半期）。テック業界に限れば約28倍です。それだけ投じて、新機能の開発に使う時間の比率（innovation ratio）は「横ばい」——より正確には57%から58%へ1ポイントの上昇です（diginomica の取材記事による）。Reock 氏自身、単一四半期の数字から結論を急ぐことには慎重で、浮いた時間を技術的負債の返済に意図的に振っている組織があれば、この指標は一時的に低く出るとも述べています。つまり「まったく動かなかった」ではなく、「投資と速度の伸びに対して、新しい価値の伸びが釣り合っていない」が正確な読みです。

3. 逆方向に動いた2つの指標——読みやすいのに、信用しきれない

このレポートで筆者が最も重要だと考えるのは、Code Maintainability（コードの保守性の実感）が +3.8% と改善した同じ期間に、Change Confidence（自分の変更を本番に出す自信）が −6.1% と悪化したことです（いずれもQ1 2026比）。

素直に考えれば、この2つは連動するはずです。読みやすく保守しやすいコードベースなら、変更を出す自信も上がるはずだからです。それが逆に動いたということは、「目の前のコードは以前より読みやすいのに、いま自分が出そうとしている変更は信用しきれない」という状態が、集計に表れる規模で起きていることになります。

一次体験としても、これには覚えがあります。生成されたコードは、たいてい整っています。命名は一貫し、コメントも付いている。それでも「自分が書いていないコード」の塊が半年で倍のペースで増えていけば、変更の影響範囲を頭の中のモデルで保証できる範囲は、相対的に狭くなっていきます。保守性の指標が拾っているのが前者で、変更への自信が拾っているのが後者だと考えると、この2つの数字は矛盾ではなく、同じ現象の表と裏に見えます。

4. 浮いた時間の行き先——ここからは仮説

では、週4〜6時間はどこへ行ったのでしょうか。レポート自身は、行き先を特定していません。書かれているのは、生成される行数が増えるほどレビューすべき行数も増えるという算術と、「PRは大きく、レビューは遅く、デリバリーは細かく刻まれなくなった」という観測までです。

そのうえで、ここからは筆者の推測と断って書きます。浮いた時間の少なくとも一部は、レビュー・検証・生成物の監督という仕事に吸収されているのではないか。書き手として節約した時間が、読み手としての自分と同僚に、請求として回ってくる。前回の記事で個人の内側に見た「書くから読むへ」の重心移動を、組織のスケールで見ているという仮説です。PRサイズの倍増とレビュー遅延という観測とは整合しますが、繰り返すと、このレポートはそれを証明していません。

付け加えるなら、検証は判断の連続であり、判断の質は疲労に最も素直に削られます。睡眠負債とコードの品質の記事で整理したとおり、削られていることに本人は気づきにくい。働き方がレビュー中心へ寄るほど、この性質は効いてきます。

5. 測り方の問題——AI利用率がKPIになるとき

この不均衡に組織が気づいたとき、よくある反応は「ではAI活用度を測ろう」です。ここに落とし穴があります。利用率を評価指標に置いた瞬間、AIを使うこと自体が新しい職務要求になるのです。

職務要求-資源（JD-R）モデルの枠組みで、生成AIの導入と燃え尽きの関係を開発者442名の調査から統計的にモデリングした研究があります（Feng, Afroz, & Sarma。arXiv 公開のプレプリント）。職務要求はバーンアウトと正の関連を示し（β = 0.398, p < .001）、生成AIの導入は職務要求を高めることを通じてバーンアウトを高める側に働いていました。一方で、自律性や学習リソースといった職務資源（β = −0.360）と、AIそのものへの肯定的な認識（β = −0.246）は、バーンアウトと負の関連を示しています。さらに、組織からのプレッシャーはコーディング中心の職種で有意に高く（β = 0.51, p < .05）、組織規模が大きいほど高い（β = 0.41, p < .001）とも報告されています。横断調査なので、ここでも因果は確定しません。

それでも、設計の示唆は読み取れます。同じ「AI導入」でも、利用率を課す形にすれば要求側に積まれ、裁量と学習時間を厚くする形にすれば資源側に積まれる。どちらの側に積むかは、組織が選べる変数だということです。

なお、燃え尽きは働き方の設計の問題であると同時に、続く不調は健康の問題でもあります。強い疲労感や気分の落ち込みが数週間単位で続く場合は、職場の工夫だけで抱え込まず、医療機関や相談窓口の利用を検討してください。

6. まとめ——個人で締められるところ、組織に投げるところ

AI生成コード比率は半年で34%→52%、PRサイズ中央値はほぼ倍増。書く速度は確かに上がった（DX社・500組織超の実測）
一方でDXIは4四半期で67→65に低下。保守性（+3.8%）と変更への自信（−6.1%）は逆方向に動いた
週4〜6時間の節約（推定）に対し、新機能に使う時間の比率は57%→58%とほぼ横ばい。浮いた時間の行き先は、データ上は特定されていない
レビュー・検証・監督への吸収は、現時点では筆者の仮説。ただしPRサイズとレビュー遅延の観測、個人の負荷移動の実感とは整合する
ベンダー自社データゆえの利害と、対照群が成立しないゆえの因果の限界は、数字とセットで覚えておく

個人で締められるところは、前回の記事の結論と重なります。筆頭はPRを小さく保つこと。生成の単位を「自分がレビューで保証できる量」に合わせ、52/17ルールの記事で書いたような長めの集中ブロックを、生成ではなくレビューに割り当てる。

組織に投げるべきことは2つです。評価指標からAI利用率を外すこと。そして「時間が浮いたか」ではなく「浮いた時間がどこへ行ったか」を測ること。速さの勘定が合っていないこと自体は、もう数字に出ています。合わない帳簿を放置するかどうかは、ツールの問題ではなく、組織の設計の問題です。

BrainSync Focus Timer のご紹介

浮いた時間がレビューと検証に流れているなら、その時間こそ設計する価値があります。私たち Donut Service が開発した BrainSync Focus Timer は、VS Code・Cursor のステータスバーに常駐するタイマーで、25/5（ポモドーロ）と52/17（ロングブロック）を切り替えながら使えます。生成を指示して待つ時間と、腰を据えて読む時間。リズムを分けて設計する道具としてお使いください。

休憩のタイミングを自動で知らせるポモドーロタイマー。無料でインストールできます。

BrainSync Focus Timer をインストールする →

Cursor をお使いの場合は Open VSX 版をご利用ください。

※ 効果には個人差があります。本記事は医療助言ではありません。

BrainSync — ソフトウェアエンジニアの心と脳を、やさしく整える。

ドーナツサービス · 東京

参考文献

Reock, J. (2026). The State of AI Impact in Engineering: Q2 2026. DX Blog（2026年7月22日）.
Feng, Z., Afroz, S., & Sarma, A. (2026). From Gains to Strains: Modeling Developer Burnout with GenAI Adoption. arXiv:2510.07435.
MacQueen, A. (2026). Atlassian research coined the AI efficiency paradox — DX’s Q2 data now finds it inside engineering. diginomica（2026年8月12日）.