AIエージェントを増やすほど詰まる——「Middle Loop」という新しいボトルネックの正体
Claude Codeなどのコーディングエージェントをチームに入れたあと、こういう声が出てきたことはないだろうか。
「コードは出てくる。でも、それが正しいかどうかを確認する時間が追いつかない」
「マージリクエストが積み上がって、結局レビューがボトルネックになってしまった」
「エージェントの台数を増やしたら、むしろ確認待ちの行列が伸びた」
ツールを導入したのに、期待した速度が出ない。このパターンが、AI駆動開発を本格的に進めているチームで繰り返されている。Scalar社のエンジニアブログに掲載されたこの記事は、その現象を「3つのループ」というモデルで整理しており、読んでいてかなり解像度が上がった。
3つのループというモデル
記事が提示するモデルはシンプルだ。従来の開発プロセスには2つのループがあった。
- Inner Loop：IDE上でコードを書き、ローカルで実行し、コンパイルエラーやテスト失敗を修正する日常的なサイクル（時間スケール：分〜時間）
- Outer Loop：コードレビュー、CI/CD、セキュリティスキャン、ステージング、本番デプロイ（時間スケール：日〜週）
このモデルでのボトルネックは「コードを書く速度」だった。だからこそ、生産性の議論はほぼ常に「どうすれば速くコードを書けるか」に収束していた。
コーディングエージェントは、このInner Loopをほぼ丸ごと自動化する。コード生成・実行・テスト・修正が数分単位で回る。ここまでは想定通りだ。
問題は、この高速化が「全体の速度」に直結しないことにある。
そこで著者が提示するのが第3のループ、Middle Loopだ。AIエージェントが解決策を提示した瞬間から始まり、それをCI/CDへ流すまでの間にある、人間による評価・統合・修正の工程だ。時間スケールは「時間単位」。
つまり、分単位で出力される成果物を、時間単位でしか処理できない層が受け止めている——これが行列のできる構造的な理由だ。
Middle Loopで人間がやっていること
ここで注意したいのは、Middle Loopでの人間の仕事は「コードの文法確認」ではないという点だ。記事はその内容を明確に列挙している。
- AIは本当に正しい問題を解いたか
- 要件や意図に合っているか
- 既存アーキテクチャから逸脱していないか
- 複数のAIエージェントが生成した成果物を、整合的に統合できるか
- 本番環境へ流して安全な変更か
これを著者は「Supervisory Engineering（監督型エンジニアリング）」と呼ぶ。「AIの作業を眺める役割」ではなく、仕事を適切に分解して渡し、出力を評価し、システム全体として成立させる活動だ。
求められるスキルが「速く書く」から「間違いを見抜く」「どこを見るべきか決める」へ移っている、という表現がそのまま刺さる。
ここからは見方だが——制約理論と「局所最適の罠」
この構造を見て、まず思い浮かぶのは制約理論（TOC）の話だ。過去に取り上げたGartnerのVPアナリスト、ヨアキム・ヘルシュマン氏の発言とまったく同じ問題意識を、今度は実際の開発現場の解像度で語っている。「コーディングはボトルネックだったためしがない」——その実証が、このMiddle Loopの話だ。
エージェントを増やすとInner Loopのスループットがさらに上がる。しかしMiddle Loopの処理能力は変わらない。結果として、行列は伸び続ける。制約理論的に言えば、ボトルネック以外の最適化にリソースを注いでいる状態だ。
記事がもうひとつ指摘している問題が「局所最適の罠」だ。3つのIssueを別々のエージェントに渡すと、それぞれは渡された範囲では妥当な解を出す。しかし並べると揃っていない。
- 抽象が重複する——既存のリポジトリ層に気づかず、似たものをもう1つ作る
- 流儀が割れる——エラーを例外で返すものと、戻り値で返すものが混ざる
- 名前が割れる——同じ概念がOrder / Purchase / Transactionと呼ばれる
これはモデルの能力の問題ではなく、「見えている範囲の問題」だと著者は言い切る。だから対策も「もっと賢いモデルを使う」ではなく「どの範囲で最適化させるかを設計する」になる。この視点の転換は、実務的に非常に重要だ。
ここで判断軸として渡しておきたいのは、「AIエージェントが賢くなれば解決するか」を問い続けることだ。多くの場合、問題はモデルの能力ではなく、渡し方の設計にある。次世代のモデルが出るたびに「これで解決するかも」と飛びつく前に、まず設計側を疑ったほうがいい。
打ち手はMiddle Loopの外にある
記事の核心のひとつがここだ。「Middle Loopの人手を、Middle Loopの中で頑張って減らすことはできない」。レビュアーを増やしても、同じ層の増員にすぎない。
では何をするか。記事は前後のループへの投資という方向を示す。
Inner Loopへの投資：アンドン（自動停止）
トヨタ生産方式のアンドンを持ち込む考え方だ。「異常が起きたらラインを止めて全員に知らせる」仕組みをAI駆動開発に適用する。
- AIが異常な動きをしたら停止する
- AIが処理を完了したら止まる（勝手に次へ進まない）
- 停止したら、処理内容を人が確認する
さらに、AI自身にチェックリストと成果物を照合させ、完了を報告させる。逸脱が小さければプロンプトで即座に是正し、大きければIssueを起票して止める。人が判断するのは「止めた内容」だけになる。
Outer Loopへの投資：ポカヨケ（機械的ゲート）
「そもそも間違えられないように、工程に仕掛けを作る」考え方だ。
- 静的解析・Linter・型・スキーマ・API契約テストで逸脱を機械的に検出する
- CIで脆弱性・テスト・SLOを自動判定し、人が見るのは例外だけにする
- 判断を「都度の目視」から「宣言されたゲート」へ移す
記事の言い方が端的でいい。「ゲートを設計するのが人、ゲートを通るのがAI」。この分担にできているかが、Middle Loopに張り付く人の量を決める。
重要なのは、記事が「自律的に動く仕組みを構築すること」ではなく「自律的に停止する仕組みを構築すること」が大事だと言っている点だ。停止した理由を可視化し、原因を一つずつ取り除き、自働化の範囲を広げていく——このサイクルが、実際に機能するAI駆動開発の骨格だ。
実務的な示唆：立場によってやることが違う
開発者個人の視点では、まず自分がMiddle Loopをどれだけ担っているかを認識することが先決だ。AIが生成したコードをそのまま流すのではなく、「この出力は正しい問題を解いているか」という問いを持つ習慣が、Supervisory Engineeringの入り口になる。
テックリード・アーキテクトの立場では、Middle Loopに時間を取られている原因が「Inner Loopの設計不足」なのか「Outer Loopのゲート不足」なのかを分けて考える必要がある。記事が示すような「Epic → Sub Epic → Issue」の階層設計は必要条件だが十分条件ではない。エージェントが実行時に読むのは渡されたIssueの本文だけであり、階層の存在そのものは見えていない。整合性を生んでいるのは、決定が成果物として固定されていること（型・スキーマ・設計書）と、実行時に必ずコンテキストへ載ること（CLAUDE.mdや規約ファイル）だという整理は、実装に直接使える。
プロダクトオーナーや経営層には別の示唆がある。記事の著者がこのプログラムの成功条件として最終的に置いたのが「動くシステムができたこと」ではなく、**「レビュー指摘が、ルール / Skills / Hooksに還元され、レビュー工数が減っていく仕組みができたこと」**という一文だ。AI導入の評価軸を「何が作れたか」から「どのくらい次のレビューが楽になったか」に変えることができるかどうかが、AI駆動開発を本当に機能させられるチームとそうでないチームを分ける。
次に来る論点
記事はこれを連載の第1回と位置づけており、「どこでEpicを切るか」という問いが「最も難しいテーマ」として第4・5回で扱われるとある。境界づけられたコンテキストでEpicを切れば、ドメイン内の整合はAIに任せやすくなる。一方、機能軸で切ると複数ドメインをまたぐことになり、Issue間の整合を人が取り続けなければならない。
この「どこで切るか」の問いは、DDD（ドメイン駆動設計）とAI駆動開発の接点として、おそらく今後の開発設計の中心的なテーマになっていく。AIに渡す単位の設計が、そのままMiddle Loopの負荷に直結するからだ。
「AIに何を書かせるか」ではなく「AIにどの単位で考えさせるか」——次にAI駆動開発の記事を読むとき、この軸で見ると、また別の景色が見えてくる。
