11分

AIの精度が上がったのに、開発が終わらない｜伸びたのは期間ではなくスコープだ

Claude CodeClaude Opus 5AI駆動開発AI開発コードレビューPMBOK-AI生成AI

Summary

AIコーディングで開発期間が長くなったという実感は、気のせいではない。ただし原因はモデルの劣化ではない。Claude 4.5世代から5世代で精度は上がっており、特に伸びたのは長時間の自律作業だ。Anthropic公式は Opus 5 について「タスクのスコープを拡大し、要求されていないステップを追加することもある」と明記している。1回の依頼で走る範囲が広がり、差分が膨らみ、人間の検証量が増える。Faros AI の22,000開発者調査ではレビュー時間中央値が5倍、CircleCI の2,800万ワークフロー分析では main ブランチのスループットが7%低下した。伸びているのは開発期間ではなくスコープだ。だから対策は速く読むことではなく、スコープを先に固定することになる。

伸びたのは開発期間ではなくスコープ — 精度向上が差分量と検証量を押し上げる構造

モデルの精度は上がっている。それなのに、開発が前より終わらない。 最近この感覚が続いている。Claude Code に投げた1タスクが戻ってくるまでの時間は明らかに長くなったし、戻ってきた差分は前より大きい。

最初は自分の錯覚か、モデルの劣化を疑った。調べた結論は違った。精度は上がっている。上がったからこそ、こうなっている。 そして伸びているのは開発期間ではない。スコープだ。

本記事ではまず、4.5世代から5世代で何がどれだけ上がったのかを数字で確認する。次に2026年に出た大規模な実測データでこの体感を裏付け、最後にスコープを先に固定する具体策を示す。

答えを先に：伸びたのは期間ではなくスコープ

結論を1行で言う。AIの能力が上がった分だけ1回の依頼で走る範囲が広がり、差分が膨らみ、人間側の検証量が増えた。

体感の説明実際に起きていること
時間「1タスクが遅くなった」1回の実行で扱う作業量が増えた
差分「レビューが終わらない」PRサイズが増え、確認対象が増えた
範囲「頼んでないことをやる」モデルがスコープを自己判断で拡張する
結果「開発期間が伸びた」期間あたりの成果物量が増えた（＝スコープが伸びた）

同じ2週間で、前は1機能だったものが今は1機能＋周辺リファクタ＋テスト＋ドキュメントになっている。時間の使い方は変わっていない。中身の量が変わった。 ここを取り違えると、対策の方向を間違える。

ずんべぇ
ずんべぇ
精度が上がったのに遅くなるって、矛盾してませんか？
うぉんば
うぉんば
遅くなってない。1回で運ぶ荷物が増えただけだよ。
ずんべぇ
ずんべぇ
えっ、じゃあ得してるんじゃ…？
うぉんば
うぉんば
荷物を頼んだ覚えがあるならね。頼んでない荷物も混ざってるから、仕分けの時間が増えてる。

精度は実際にどれだけ上がったのか

まず事実を押さえる。過剰に持ち上げず、数字だけ並べる。

モデル公開SWE-bench VerifiedSWE-bench Pro
Claude Sonnet 4.52025年9月77.2%—
Claude Opus 4.82026年5月88.6%69.2%
Claude Sonnet 52026年6月85.2%63.2%
Claude Opus 52026年7月24日96.0%79.2%

Sonnet 4.5 の 77.2% はAnthropic公式の発表値。それ以降はベンチマーク集約サイト調べであり、Anthropic自身は SWE-bench を見出しに使っていない。ここが重要だ。公式が前面に出したのは別のベンチだった。

Claude 4.5世代から5世代へ — SWE-bench の伸びと、長時間エージェント系ベンチの伸び方の違い

Claude Opus 5 の公式リリースが主役に据えたのは、長時間のエージェント作業を測る Frontier-Bench v0.1 だ。Opus 4.8 の 18.7% に対し、Opus 5 は 43.3%（いずれも max effort 時）。公式は、Opus 4.8 の性能を2倍以上にしつつ、1タスクあたりのコストは下げたと説明している。

そして公式は、性能向上の中身をこう書いている。

Opus 5 is much stronger at verifying its work and iterating carefully until it succeeds. （自身の作業を検証し、成功するまで丁寧に反復する力が大きく向上した）

自己検証して、直して、また試す。 これが1回の実行が長くなった直接の理由だ。伸びたのは「正解率」だけではなく「1回で引き受けられる仕事の長さ」だった。METR の time horizon 計測でも、モデルが自律で完遂できるタスクの長さは2024年以降およそ89日で倍増している。

私の現場で起きていること

抽象論で終わらせない。自分の手元で起きたことを書く。

指示外のリファクタが混ざる。 1箇所の修正を頼んだはずが、周辺の命名・型定義・構造まで整理されて返ってくる。整理そのものは妥当だ。だがレビューでは「頼んだ変更」と「頼んでいない変更」を仕分ける作業が先に発生する。差分が2倍になれば、読む時間も2倍になる。

テストとドキュメントまで一式ついてくる。 実装だけを頼んでも、テストコード、README の更新、型定義、コメントが揃って出てくる。これも品質としては正しい。ただしマージするには全部見る必要がある。見ないままマージするなら、それは品質が上がったのではなく確認を省略しただけだ。

1回の実行が長い。 以前は数分で返ってきた粒度の依頼が、自己検証と反復を挟んで数十分走り続けるようになった。その間こちらは待つか、別の作業に切り替えるかになる。切り替えれば文脈が切れる。

3つとも、モデルが賢くなった結果として起きている。劣化ではなく、進化の副作用だ。 そして Anthropic 自身がこの挙動を公式に認めている。Claude Opus 5 のプロンプティングガイドにはこうある。

タスクのスコープを拡大し、要求されていないステップを追加したり、タスクがどうあるべきかについて独自の判断を適用したりすることもあります

前回の記事AIへの指示は「手順」から「範囲」へで、私はこの一文を「能力向上の裏面」として引用した。今回はその裏面が工数として実際に現れたという話をしている。

気のせいではない — 2026年の実測データ

ここが本題だ。個人の体感で終わらせず、大規模な計測を並べる。2026年に入って、独立した4つの調査が同じ方向を指した。

2026年の実測4本 — 生成は増え、デリバリーは詰まる

1. Faros AI「Acceleration Whiplash」（2026年4月）

開発者22,000人・4,000チーム超・2年分の前後比較テレメトリ。この問いに関する最大規模の調査だ。結果は両面に出た。完了タスク +34%、エピック +66%。一方で開発者あたりのバグ +54%、インシデント/PR比は3倍超、レビュー時間の中央値は5倍、レビューなしでマージされる PR が 31% 増。（Faros AI）

2. CircleCI「2026 State of Software Delivery」

CI ワークフロー2,800万件の分析。全体のスループットは前年比 +59%。ところが main ブランチのスループットは中央値で 7% 低下し、main の成功率は 70.8% と5年で最低を記録した。マージ試行の約3回に1回が失敗している計算になる。コード生成とデリバリーの両方をスケールできたチームは、20チームに1チーム未満だった。（DEVOPSdigest）

3. 企業の「生産性2倍」指令を追った縦断研究

ある企業がAI活用で生産性2倍を掲げた前後を追った論文では、PRサイズ +154%、レビュー時間 +91%、一方で組織レベルの DORA 指標は横ばい。レビューカバレッジは約48%から約21%へ落ちた。論文が指摘する構造は単純だ。エージェントを持つ開発者は1日に5〜6本の PR を出せるが、レビュアーが意味のあるレビューをできる速度は今も1時間あたり200〜400行である。（arXiv:2607.01904）

4. GitClear「The Maintainability Gap」

2023年から2026年の6.23億件の変更を分析。重複ブロックは 81% 増（100万変更行あたり40.3→73.0）で観測史上最高。移動されたコード、つまりリファクタリングの割合は 2022年の21%から2026年は3.8%へ崩落した。いまやコピー&ペーストのほうが、リファクタリングより約5倍起こりやすい。（GitClear）

日本国内でも同じ像が出ている。AI生成コードのレビュー担当者の 86.3% が負担増を実感しているという調査がある。67.5% が週3時間以上の追加対応に追われ、78.6% が直近半年でAI起因のバグ・障害修正を経験していた。（キッカケクリエイション調べ）

4本とも、生成量は増えている。詰まっているのはその先だ。 個人の体感が組織の数字と乖離するこの現象を、Faros AI は Acceleration Whiplash（加速のむち打ち）と名付けた。うまい表現だと思う。

ずんべぇ
ずんべぇ
レビュー時間5倍って、みんなそんなに困ってるんですか…
うぉんば
うぉんば
困り方が見えにくいんだよ。個人の画面では速くなってるから。
ずんべぇ
ずんべぇ
あー、遅れが出るのはマージの手前なんですね。
うぉんば
うぉんば
そう。だから「自分は速くなった」と「プロジェクトは終わらない」が同時に成立する。

なぜスコープが伸びるのか

構造はシンプルだ。4段階で説明できる。

  1. モデルが長い仕事を完遂できるようになる（Frontier-Bench 18.7%→43.3%、time horizon の倍増）
  2. こちらの依頼の粒度が自然に大きくなる（できるなら、まとめて頼む）
  3. 1回のアウトプットが大きくなる（自己検証・反復・周辺整備まで走る）
  4. 人間の検証量が増える（読む量は増えたが、読む速度は変わっていない）

問題は 4 にある。1〜3 は指数関数で伸び、4 は一定だ。 論文が言う「1時間あたり200〜400行」は、モデルが変わっても変わらない。人間の側は3年前と同じ速度でレビューしている。

そして厄介なのは、スコープ拡張の中身がだいたい正しいことだ。リファクタは妥当で、テストは有用で、ドキュメントは必要だ。だから拒否しにくい。気づかないうちに、2週間の計画に4週間分の成果物が積まれる。遅れているのではなく、増えている。 私がAI失敗の教訓で書いた「指示の解像度と出力の品質は比例する」という原則は、いま別の顔で効いている。解像度が低い指示は、品質ではなく量として跳ね返ってくるようになった。

対策：スコープを先に固定する

処方箋は1つに絞る。速く読む方法を探すのではなく、読む量を先に決める。

1. 「やらないこと」を書く

依頼に含めるべきは、やることの一覧ではなく境界だ。私は Issue に次の3行を足すようにした。

  • この Issue で触るファイルは X と Y のみ
  • 周辺のリファクタリングは行わない（気づいた点は指摘だけ）
  • テスト・ドキュメントは別 Issue

「気づいた点は指摘だけ」がポイントだ。モデルの判断力は使いたい。だが実行はさせない。 指摘は次の Issue の材料になる。

2. 1 Issue = 1 レビュー単位にする

私はもともと GitHub Issue 駆動で 1 Issue = 1 機能に分解している。5世代以降はここをさらに厳しくした。基準は機能の大きさではなく、自分が一度に読み切れる差分量だ。読み切れないなら、機能が小さくても分割する。レビュー容量が律速なら、投入量の側を合わせるしかない。

3. 受け入れ基準を数値で置く

完了条件を「動くこと」にすると、モデルは動く以上のものを作る。触ってよいファイル数、追加してよい依存、差分行数の上限を先に書く。曖昧な基準は、曖昧なぶんだけ広く解釈される。

スコープを先に固定する — 指示の Before/After

この3つは、Claude Opus 4.8で「AIに任せられる範囲」はどこまで広がったかで書いた「任せ方の地図」の実装レベルの話でもある。あのときは何を任せるかを決める話だった。今回は、任せた作業がどこまで広がってよいかを決める話だ。範囲を決めずに任せると、モデルは善意で広げる。

ただし、やりすぎないほうがいい。境界を細かく書きすぎれば、それは手順書に逆戻りする。書くのは境界だけで十分だ。

まとめ：遅れているのではなく、増えている

3行でまとめる。

  • Claude 4.5世代から5世代で精度は上がった。特に伸びたのは長時間の自律作業（Frontier-Bench で Opus 4.8 の2倍超）。1回の実行が長く、アウトプットが大きくなったのはその結果だ
  • 「開発期間が伸びた」の正体はスコープの膨張。生成量は増え、レビュー速度は変わらない。Faros AI・CircleCI・縦断研究・GitClear の4本が同じ方向を指している
  • 対策は速く読むことではなく、読む量を先に決めること。やらないことを書き、1 Issue を自分が読み切れる差分量に収める

前にプロンプトを磨くな、経験を積めと書いた。その延長でもう1つ言える。磨くべきは指示の細かさではなく、境界の引き方だ。

明日からできることは1つだけだ。次に Claude Code へ Issue を投げる前に、「やらないこと」を1行足してほしい。それだけで戻ってくる差分は変わる。読む量が減れば、開発は終わるようになる。

参考・出典

関連記事

AI駆動開発のワークフロー設計や、レビュー工程の再設計についてのご相談はお問い合わせからお気軽にどうぞ。

前の記事

AIへの指示は「手順」から「範囲」へ｜Claude Opus 5公式ドキュメントが示した転換

AIチームの構築に興味がありますか？

まずはお気軽にご相談ください

お問い合わせPMBOK-AIについて