この記事では、コーディングエージェントを本格導入したチームで、なぜ「速くなったはずなのに全体が速くならない」という現象が起きるのかを、Inner / Middle / Outer の3つのループというモデルで説明します。
結論を先に書くと、ボトルネックは Middle Loop —— 人がAIの出力を評価し、統合し、修正する層 に移ります。ここを設計せずにエージェントの台数だけ増やすと、確認待ちの行列が伸びるだけになります。
対象読者
- Claude Code などのコーディングエージェントをチームに導入したものの、期待したほど開発速度が上がっていないと感じている方
- AI駆動開発を前提とした開発プロセス・チーム体制を設計する立場にある方（EM / テックリード / アーキテクト）
- 「AIにコードを書かせる」の次に何を整備すべきか探している方
背景・目的
従来の開発プロセスは2つのループでできていた
コーディングエージェントが登場する前、開発プロセスは大きく2つのループで説明できました。
| ループ | 内容 | 時間スケール |
|---|---|---|
| Inner Loop | IDE上でコードを書き、ローカルで実行し、コンパイルエラーやテスト失敗を直す日常的なサイクル | 分〜時間 |
| Outer Loop | コードレビュー、CI/CD、セキュリティスキャン、コンテナ化、ステージング、本番デプロイ | 日〜週 |
このモデルにおけるボトルネックは明快で、コードを書く速度でした。だからこそ、生産性向上の議論はほぼ常に「どうすればコードを速く書けるか」に収束していました。
エージェント導入で、Inner Loop だけが桁で速くなった
コーディングエージェントは、この Inner Loop をほぼまるごと自動化します。コード生成・実行・テスト・修正が数分単位で回ります。
ところが、ここで多くのチームが直面するのが次の状況です。
- コードは出てくるが、それが正しいかどうかを判断する工程が追いつかない
- レビュー待ちのマージリクエストが積み上がる
- 「AIに任せる範囲を広げよう」と決めるための意思決定コミュニケーションが増える
- 生成が速いので、タスクの依存関係を人が解きほぐす時間が相対的に大きくなる
つまり、Inner Loop を高速化しただけでは、開発効率はむしろ下がることさえある、というのが実態です。
Middle Loop —— 新しく現れた第3のループ
定義
Middle Loop とは、AIエージェントが解決策を提示した瞬間から始まり、それを CI/CD へ流すまでの間にある、人間による評価・統合・修正の工程です。
ここで人間のエンジニアが行うのは、コードの文法確認ではありません。次のような判断です。
- AIは本当に正しい問題を解いたか
- 要件や意図に合っているか
- 既存アーキテクチャから逸脱していないか
- 複数のAIエージェントが生成した成果物を、整合的に統合できるか
- 本番環境へ流して安全な変更か
Middle Loop は、人間の判断力とAIの実行速度が接触する層です。
3つのループの時間スケール
| ループ | 担い手 | 時間スケール |
|---|---|---|
| Inner Loop | AIが自動化 | 分単位 |
| Middle Loop | 人が評価・統合・修正 | 時間単位 |
| Outer Loop | 検証・反映・観測・是正 | 日〜週単位 |
分単位で出力される成果物を、時間単位でしか処理できない層が受け止めている —— これが行列ができる理由です。
Middle Loop を担う役割を Supervisory Engineering と呼ぶ
私はこの層を担うエンジニアリング活動を Supervisory Engineering（監督型エンジニアリング） と呼んでいます。「AIの作業を眺める役割」ではありません。人間がAIへ仕事を適切に分解して渡し、出力を評価し、必要に応じて修正させ、システム全体として成立させる活動です。
具体的には次の4つの役割を持ちます。
- 意図と制約を揃える —— 何を作るのか、何をしてはいけないのかを、エージェントが読む場所に置く
- 複数エージェントの成果物を統合する —— 個別には妥当な出力が、並べると揃っていない状態を解消する
- コードの書き方より振る舞いを評価する —— スタイルではなく、実行時に何が起きるかを見る
- CI/CD 前のゲートとして機能する —— 本番に流してよいかの最終判断
求められる能力が「速く書く」から「間違いを見抜く」「どこを見るべきか決める」へ移る、という言い方もできます。
AIを使った自働化の考え方 - 良いモノをより早く
重要なのは、Middle Loop の人手を、Middle Loop の中で頑張って減らすことはできないという点です。レビュアーを増やしても、それは同じ層の増員にすぎません。減らす手は前後のループへの投資しかありません。
そこで、AIによる開発のスピードと品質を維持するために、大事なのは、自律的に動く仕組みを構築することではなく、自律的に停止する仕組みを構築することにあります。この自動停止の仕組みを入れることで、停止した理由を可視化し、一つずつ原因を取り除き、自働化の範囲を広げていくことができます。ここでは、その具体的な方法を示します。
方向1: Inner Loop への投資 —— 自働化（アンドン）
トヨタ生産方式でいうアンドンは、「異常が起きたらボタンを押し、ラインを止めて全員に知らせる」仕組みです。これをAI駆動開発に持ち込むと次のようになります。
- AIが異常な動きをしたら停止する
- AIが処理を完了したら止まる（勝手に次へ進まない）
- 停止したら、処理された内容を人が確認する
さらに、AI自身にチェックリストと成果物を照合させ、完了を報告させるところまで含めます。逸脱が小さければプロンプトで即座に是正し、大きければ Issue を起票して止める。人が判断するのは「止めた内容」だけになります。
方向2: Outer Loop への投資 —— 省人化（ポカヨケ）
ポカヨケは「そもそも間違えられないように、工程に仕掛けを作る」考え方です。
- 静的解析・Linter・型・スキーマ・API契約テストで、逸脱を機械的に検出する
- CI で脆弱性・テスト・SLO を自動判定し、人が見るのは例外だけにする
- 判断を「都度の目視」から「宣言されたゲート」へ移す
ゲートを設計するのが人、ゲートを通るのがAI。この分担にできているかが、Middle Loop に張り付く人の量を決めます。
局所最適の集合は、全体最適にならない
Middle Loop に仕事が溜まるもう一つの理由が、AIの出力が「個別には妥当だが、並べると揃っていない」ことです。
エージェントは、渡された範囲では妥当な解を出します。範囲の外は見えていません。3つの Issue を別々に渡すと、こうなります。
- 抽象が重複する —— 既存のリポジトリ層に気づかず、似たものをもう1つ作る
- 流儀が割れる —— エラーを例外で返すもの、戻り値で返すものが混ざる
- 名前が割れる —— 同じ概念が Order / Purchase / Transaction と呼ばれる
これは能力の問題ではなく、見えている範囲の問題です。したがって対策も「もっと賢いモデルを使う」ではなく「どの範囲で最適化させるかを設計する」になります。
階層をつくるだけでは、出力は揃わない
よくある対策が Epic → Sub Epic → Issue の階層化です。これは必要条件ですが、十分条件ではありません。
エージェントが実行時に読むのは、渡された Issue の本文だけです。上位で決めたことは、ツリーの存在としては見えていません。整合性を生んでいるのは、階層そのものではなく次の2つです。
- 決定が成果物として固定されていること —— 境界・インターフェース・データモデル・エラー方針が、動かせない形で存在している
- 実行時に必ずコンテキストへ載ること —— CLAUDE.md / 規約ファイル / 参照必須の設計書 / 型定義やスキーマそのもの
整合性の種類ごとに、効く手段が違う
| 整合性の種類 | 何が揃わないか | 効く手段 |
|---|---|---|
| 構造的 | インターフェース / 依存方向 / データモデル | 上位で決めて固定する。最も強いのは契約をコードで表現する（型・スキーマ・OpenAPI・proto にすればAIは逸脱できない） |
| 規約的 | 命名 / エラー処理 / ログ | 階層ではなくゲートで強制する。Linter と CI に検査させるほうが、Epic に書くより確実 |
| 意味的 | 同じ概念が別の名前で呼ばれる | ユビキタス言語を成果物として持ち、常にコンテキストへ載せる |
文書で「こう書け」と指示するより、AIが逸脱できない形にするほうが強い、というのがここでの原則です。
詰まったポイント・Tips
コンテキストは「決めるとき」だけ広げる
「Epic 単位で最適化する」は「Epic 全体をエージェントに渡す」ではありません。コンテキストを広げるほど注意は拡散し、精度が落ちます。
| 階層 | そこで決めること | 成果物 | コンテキストの広さ |
|---|---|---|---|
| Epic | 境界の切り方 / インターフェース / データモデル / エラー方針 | 設計書・型定義・スキーマ | 広い（決定だけを出す。コードは書かない） |
| Sub Epic | 分割の単位と依存順 / 契約の具体化 | API定義・テーブル定義・テスト仕様 | 中 |
| Issue | 実装のしかた | コード | 狭い（前提は凍結済み） |
決定が凍結されていれば、Issue はコンテキストを狭く保ったまま揃います。
整合を取り続けるより、整合を取る必要が出ない切り方を選ぶ
Epic を「決済機能」のような機能で切ると、1つの Epic が注文・在庫・決済という複数のドメインをまたぎます。すると Issue 間で整合を取り続ける必要が残ります。
一方、境界づけられたコンテキストで切れば、Epic の中は1つのドメインで閉じます。ドメイン間の整合性は、コードで毎回書くのではなく基盤側の仕組みに寄せる —— という設計にできれば、AIをドメインをまたいだ設計から解放できます。
この「どこで切るか」の判断が、実は本連載で最も難しいテーマです。第4回・第5回で正面から扱います。
まとめ
- 成果: AI駆動開発におけるボトルネックは、Inner Loop（コードを書く速度）から Middle Loop（人が評価・統合・修正する速度）へ移ります。ここを認識できると、打ち手が「レビュー体制の強化」から「Inner Loop の自働化（アンドン）」と「Outer Loop の省人化（ポカヨケ）」へ変わります。
- 課題: Middle Loop の設計は、ツールを入れれば済むものではありません。何をゲートにするか、どの決定を凍結するか、指摘をどう仕組みに還元するか を、チームごとに決める必要があります。
そして、この3ヶ月のプログラムを設計する中で最終的に置いた成功条件は、「動くシステムができたこと」ではなく、次の一文でした。
レビュー指摘が、ルール / Skills / Hooks に還元され、レビュー工数が減っていく仕組みができたこと
最後にお読みいただきありがとうございました。この記事が同じ悩みを持つ方の参考になれば幸いです。
参考
「AIに任せたら、個別には妥当なのに全体として揃わない」という現象は、インフラ構築でも同じ形で起きます。実際の失敗体験がこちらにまとまっています。
執筆者紹介
執筆者
深津 航
株式会社Scalar 代表取締役CEO、Co-Founder
最近はAIを使った開発プロセスの改善に取り組んでいます。
Discussion