複数の開発者がClaude CodeやCopilotなどのAIコーディングエージェント（自律的にコードを生成・修正するAIツール）を使い始めたのに、リリース速度が思ったほど上がらない。むしろレビュー待ちが積み上がっている。そんな状況に心当たりがあるチームリーダーやテックリードに向けて、この記事では原因の切り分け方と、今日から確認できるチェック項目を整理します。
個々の開発者は明らかに速くなっているのに、チーム全体のアウトプットは変わらない。この現象は矛盾ではありません。個人の生産性とチームのスループット（実際に出荷可能な単位で仕上がる仕事量）は、そもそも別の指標だからです。全員に速いタイプライターを渡せば書けるページ数は増えますが、それが一冊の本としてまとまるかどうかは別問題、という比喩が実態に近いといえます。
個人の速さとチームの速さを分けて考える
AIエージェントが直接押し上げるのは個人のアウトプットです。一方でチームのスループットは、レビュー・手戻り・待ち時間・変更の統合作業といった調整コストを差し引いた後に残る量になります。
この関係は、次のような形で捉えると理解しやすくなります。
チームのスループット ≈ 個人の速度向上の合計 − 手戻り − 待ち時間 − 統合作業AIエージェントを導入すると最初の項（個人の速度向上）は増えます。しかし他の変数を何も見直さなければ、残り3つの引き算項も同時に膨らみます。同時進行の作業量が増え、しかもそれを他のメンバーが把握しきれていない状態が生まれるためです。
チームリーダーが本当に問うべきなのは「全員をどう速くするか」ではなく「自分たちのボトルネックはどの引き算項にあるか」という点になります。
2025年に発表されたある調査では、成熟したコードベースに精通した経験豊富なオープンソース開発者が、AI支援ありのタスクで実際には時間がかかっていたという結果が出ています。本人たちはAIが速くしてくれると予想していたにもかかわらず、です。この結果を「AIは全般的に開発を遅くする」と一般化するのは早計ですが、体感速度と実測タスク時間がずれうるという点は、大規模な既存コードベースを抱える現場では無視できない示唆です。
また2025年版のDORAレポート（DevOpsのパフォーマンスを継続調査してきたGoogleの年次報告書）は、AIを「組織が既に持っている強みと機能不全の両方を増幅する装置」として位置づけています。つまり調整の仕組みが弱いチームほど、AIによって同時進行の作業量が増えることで、そのコストがより高くつく可能性があるということです。
5つの調整コストを段階的に見る
個人の速さがチームの速さに変換されない場合、原因は次の5つのコストのどれかに集約されることが多いです。いずれもAI導入以前から存在していた問題ですが、AIは発生頻度と規模を引き上げます。
- 重複調査: ステージング環境が毎晩リセットされる、あるモジュールは後方互換性を保つ必要がある、といった知見を誰かのAIエージェントが発見しても、その情報は一つのチャット履歴にしか残らず、別のエージェントが同じ調査を繰り返す（あるいは逆の結論に至る）
- 意思決定の漂流: 「金額は浮動小数点数ではなく整数セントで統一する」といった決定が口頭やチャットで一度共有されただけで、その場にいなかった複数のエージェントがそれぞれ違う実装を選んでしまう
- 所有権の曖昧化: 全員が高速に動いている結果、「決済まわりのリファクタリングは今誰が担当しているか」が誰にも即答できなくなり、二重着手または誰も着手しない状態が生まれる
- 引き継ぎ時の情報欠落: 午前のセッションから午後のセッションへ、あるいはノートパソコンからCI環境へ、あるいはツール間（Claude CodeからCodexへ、など）で作業が移る際に、直前の決定・未完了タスク・保留中の疑問点が引き継がれない
- 衝突と統合作業: 二つのエージェントが別々のブランチで同じファイルの重なる部分を編集し、Gitが正確にコンフリクトを検出するのは両方の作業が終わったあと。衝突自体は、どちらの側も相手の状況を知らなかった時点で既に発生している
既存の開発プラクティスとの関係を整理する
これらの調整コストは、実はAI以前からアジャイル開発やマイクロサービス体制で語られてきた課題と重なります。デイリースタンドアップやペアプログラミングは、まさに「重複調査」と「所有権の曖昧化」を防ぐための仕組みでした。
コードレビューやプルリクエストのテンプレートは「意思決定の漂流」を文書として固定する役割を担ってきました。
違いは、AIエージェントが人間よりはるかに速いペースで並行タスクを生み出す点です。従来は1人のエンジニアが1日にこなせるタスク数に自然な上限がありましたが、AIエージェントを複数のエンジニアが同時に走らせると、レビュー対象のプルリクエストや設計判断が短時間で急増します。GitHubのプルリクエストキューやJiraのチケット消化速度をウォッチしているチームでは、この変化がレビュー待ち時間の数値として表面化しやすくなります。
今日確認できること
自分たちのチームがどの調整コストで詰まっているかを見極めるために、次の観点を確認してみてください。
- 直近1〜2週間のプルリクエストで、レビュー待ち時間の中央値がAI導入前後で変化しているかを
git logやGitHub Insightsで確認する - 同じ設計判断（データ型の統一ルール、命名規則、エラーハンドリング方針など）が複数のブランチで矛盾していないかを、直近のマージ済みコードで抜き打ちチェックする
- タスク管理ツール（Jira、Linear等）で、担当者未割り当てまたは複数人が同時にアサインされているチケットの数を数える
- AIエージェントとのやり取り（チャット履歴やセッションログ）が、担当者交代時にどこに保存され、次の担当者が参照できる状態になっているかを確認する
- 同一ファイル・同一モジュールに対するコンフリクトの発生頻度を、直近のマージ履歴から
git log --mergesなどで振り返る
これら10項目相当のチェックを一度洗い出してみると、単に「AIツールの使い方が悪い」のではなく、意思決定を共有する仕組みや、担当割り当てを見える化する仕組みが追いついていない、という構造が見えてくることが多いです。
まとめ
AIコーディングエージェントは個人の生産性を確実に押し上げますが、それがチーム全体のスループットに直結するとは限りません。
差分の正体は、重複調査・意思決定の漂流・所有権の曖昧化・引き継ぎ時の情報欠落・衝突と統合作業という5つの調整コストにあります。
まずは直近のプルリクエストのレビュー待ち時間と、担当者未割り当てのチケット数を確認するところから始めてみてください。
そのうえで、意思決定をどこに記録し、誰が参照できる状態にするかという運用ルールを、AI導入前より一段具体的に見直す価値があります。