AI駆動開発で人を律速にしない：5つのボトルネック類型と解消パターン

TL;DR

• AIがコードを書く速度は十分に速い。チームが遅い原因は「人間が判断を待たせている」こと
• 人間が律速になるポイントは5類型に分類できる：要件確認、設計判断、PRレビュー、承認フロー、障害トリアージ
• 各類型には4つの解消パターンがある：非同期化、事前型化、自動化、委譲
• 全部を同時に直す必要はない。制約理論（TOC）の原則で「今の最大律速」を1つ特定して潰すのが最速

はじめに

こんにちは、みねです。

AIコーディングエージェントを導入したチームで、こんな光景を見たことはないでしょうか。

AIが15分でPRを出してくれたのに、レビュー待ちで3日間放置されている。

「どのライブラリを使うか」の相談がSlackで2日間宙に浮いている間に、AIは別の仕事をする余力があるのに止まっている。

障害が起きたとき、AI生成コードの意図がわからず、結局書いた本人（AI指示者）を呼ばないと対応できない。

AIの実装速度がどれだけ上がっても、開発フローの中に「人間の判断待ち」がある限り、チーム全体のスループットは変わらない。これは制約理論（TOC: Theory of Constraints）が40年以上前から教えてくれている原則です。

ボトルネック以外をいくら高速化しても、システム全体のスループットはボトルネックの処理能力で決まる。

本記事では、AI駆動開発で人間が律速になる5つの類型を特定し、それぞれに適用できる4つの解消パターンを整理します。

この記事のゴール: 読者が自チームの「今の最大律速」を診断し、明日から1つ解消施策を始められる状態になること。

この記事がカバーしないこと:

• AIツールの比較（→ 2026年のAIコーディング最前線）
• PRレビュー律速の詳細な対策（→ AI生成PRでレビューが詰まる本当の理由）
• 権限設計の詳細（→ 権限マトリクスとガードレール設計）

1. なぜ「人間」が律速になるのか

1.1 ボトルネックの移動

AI導入前の開発フローでは、コードを書く速度が最大の律速でした。だから「優秀なプログラマーを採用する」「ペアプロで生産性を上げる」が有効だった。

AI導入後、コード生成は劇的に速くなりました。しかし、それによって次のボトルネックが顕在化しただけです。

graph LR
    A[要件定義] --> B[設計判断]
    B --> C[実装]
    C --> D[レビュー]
    D --> E[承認]
    E --> F[デプロイ]
    F --> G[障害対応]

    style C fill:#d4edda,stroke:#28a745
    style A fill:#f8d7da,stroke:#dc3545
    style B fill:#f8d7da,stroke:#dc3545
    style D fill:#f8d7da,stroke:#dc3545
    style E fill:#f8d7da,stroke:#dc3545
    style G fill:#f8d7da,stroke:#dc3545

緑が「AIで高速化された工程」、赤が「人間依存で律速になりやすい工程」です。

1.2 TOCの5ステップ

制約理論は、システム改善のために5つのステップを提唱しています。

1. 制約を特定する — どこが最大のボトルネックか？
2. 制約を最大限活用する — ボトルネックの無駄を排除する
3. 他をボトルネックに従属させる — ボトルネック以外の速度を合わせる
4. 制約を強化する — ボトルネックの処理能力を上げる
5. 繰り返す — 新しいボトルネックが現れたら最初に戻る

この考え方をAI駆動開発に適用すると、「人間が判断を待たせている場所」を特定し、その処理能力を上げるか、人間を外すことがチーム全体の改善になります。

2. 5つのボトルネック類型

AI駆動開発で人間が律速になるポイントを、フローの順番に5つに分類します。

類型1: 要件確認律速

症状: Issueが曖昧で、AIが実装に着手できない。または着手しても「意図と違う」で差し戻しが発生する。

[Issue作成] --曖昧--> [AIが質問] --待ち--> [人間が回答] --待ち--> [AI実装開始]
                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
                        この往復が1〜3営業日かかる

典型的な原因:

• 「いい感じにお願い」という丸投げIssue
• 受入条件（Acceptance Criteria）が未定義
• 非機能要件（パフォーマンス、セキュリティ）の記載漏れ

関連記事: コンテキスト負債とは何か、Issueテンプレで要件解像度を上げる

類型2: アーキテクチャ判断律速

症状: 「Redisを使うか、インメモリで良いか」「REST vs GraphQL」といった設計判断で、合意が得られるまでAIの手が止まる。

典型的な原因:

• 技術選定の基準が暗黙知
• アーキテクチャ決定権者が1人に集中
• 「とりあえず動くもの」と「正しい設計」のトレードオフが言語化されていない

類型3: PRレビュー律速

症状: AIが高速にPRを量産するが、レビューキューが詰まる。1PRのレビュー待ち時間がLead Timeの大半を占める。

典型的な原因:

• AI生成コードは「意図」が読みにくい
• PRが大きすぎてリスク判定に時間がかかる
• レビュアーが固定化している

深掘り記事: AI生成PRでレビューが詰まる本当の理由

類型4: 承認フロー律速

症状: レビューは終わっているのに、マージ承認者がいない。デプロイ承認のキュー待ちが発生する。

典型的な原因:

• 承認権限が特定の人物に集中
• 承認基準が不明確（「なんとなくLGTMが出るまで待つ」）
• 本番デプロイに二重承認が必要だが、2人目が捕まらない

深掘り記事: 権限マトリクスとガードレール設計

類型5: 障害トリアージ律速

症状: AI生成コードに起因する障害が発生したとき、「誰が」「何を見て」「どう判断するか」が属人化している。

典型的な原因:

• AI生成コードの意図が記録されていない（「なぜこの実装か」が不明）
• 障害対応のランブック（手順書）がない
• 責任範囲が曖昧（「AIが書いたコードは誰の責任？」）

3. 4つの解消パターン

5つの類型に対して、以下の4つのパターンを適用できます。

パターンA: 非同期化

考え方: 「同期的に待つ」を「非同期で進める」に変える。

ポイント: 非同期化は「判断を省略する」のではなく、「判断の機会を確保しつつ、待ち時間をゼロにする」こと。

パターンB: 事前型化

考え方: 毎回の個別判断を、事前に定めたルール・テンプレートで置き換える。

ポイント: 事前型化のコストは「1回の判断をテンプレ化する手間」。そのテンプレが10回以上再利用されるなら、投資回収は確実。

関連記事: 受入条件を先に書くTDD実践、意思決定ログと証拠管理の型

パターンC: 自動化

考え方: 人間の判断を、機械的なルールやAIに置き換える。

ポイント: 自動化は「信頼できるガードレール」があって初めて成立する。テストカバレッジが低い状態で自動マージを導入すると事故になる。

関連記事: リスクベースリリース運用

パターンD: 委譲

考え方: 判断権限を分散し、1人に集中しないようにする。

ポイント: 委譲は「責任の放棄」ではない。委譲先の判断品質を担保するために、事前型化（パターンB）と組み合わせる。

4. 実践マップ：類型×パターン

5つの類型と4つのパターンの組み合わせを一覧にします。自チームの状況に合わせて、最も効果が高いセルから着手してください。

効果 × 導入コストで優先順位をつける:

5. 始め方：TOCボトルネック診断

5.1 今の最大律速を特定する

以下のチェックリストで、自チームの最大律速を特定してください。

Lead Timeの分解

1つのIssueについて、以下の各区間の所要時間を記録します。

Issue作成 → 実装着手: ___日（要件確認待ち）
実装着手 → 設計確定: ___日（設計判断待ち）
設計確定 → PR作成:   ___日（実装時間 ← ここはAIが速い）
PR作成   → レビュー完了: ___日（レビュー待ち）
レビュー完了 → マージ:    ___日（承認待ち）
マージ   → 本番:         ___日（デプロイ待ち）

最も長い区間が、あなたのチームの律速です。

5.2 計測の簡易な方法

高額なツールは不要です。以下のGitコマンドで概算できます。

# PRのオープンからマージまでの日数（直近20件）
gh pr list --state merged --limit 20 --json createdAt,mergedAt \
  --jq '.[] | "\(.createdAt) -> \(.mergedAt)"'

# Issue作成からクローズまでの日数（最初のPRまでの時間の近似として）
gh issue list --state closed --limit 20 --json createdAt,closedAt \
  --jq '.[] | "\(.createdAt) -> \(.closedAt)"'

5.3 1つだけ潰す

律速が特定できたら、セクション4のマトリクスから導入コストが最も低い施策を1つ選んで実行してください。

よくある最初の一手:

1つ潰したら、Lead Timeを再計測して次の律速を特定する。このサイクルを回すことが、TOCの本質です。

まとめ

AI駆動開発のスループットを決めるのは、AIの性能ではなく人間の判断フローです。

1. 律速を5類型で診断する — どこで人間が待たせているか
2. 4パターンで解消する — 非同期化、事前型化、自動化、委譲
3. TOCの原則で1つずつ潰す — 全部同時にやらない

「AIが速くなったのに、チームが速くならない」と感じたら、それはAIの問題ではなく、フロー設計の問題です。

関連記事

• AI生産性のパラドックス：なぜ「速くなった」のにチケットが消えないのか — 本記事の前提となる「パラドックス」の解説
• AI生成PRでレビューが詰まる本当の理由 — 類型3（PRレビュー律速）の深掘り
• 権限マトリクスとガードレール設計 — 類型4（承認フロー律速）の深掘り
• コンテキスト負債とは何か — 類型1（要件確認律速）の根本原因
• AI開発KPIと学習ループ — 改善サイクルの計測設計
• 受入条件を先に書くTDD実践 — パターンB（事前型化）の具体例
• 意思決定ログと証拠管理の型 — パターンB（事前型化）のADR実践
• AIでコードは増えるのにプロダクト価値が伸びないのはなぜ？ — 親テーマの全体構造