AIがコードを書いた先でボトルネックはどこに移ったか——週200PR超えの現場から学ぶ4つの詰まりどころ
AIがコードを書けるようになった、という話ではない。コードを書かせた「先」で何が詰まるか、という話だ。
Findyのメディアに掲載されたGotaさんの記事は、AIエージェントを使ったプロダクト開発を週200PR超えのペースで回している現場から、ボトルネックがどう移り続けたかを具体的に記録している。Codex、Claude Code、Cursorを横断して動く「Software Factory」を自前で構築し、その過程でつくっては壊したPluginsが3ヶ月で100回以上。それだけ試行錯誤してわかったことが詰まっている記事だ。
読んで最初に感じたのは、「コードを書く速度が上がっても全体は同じ比率では速くならない」というシンプルな言葉の重さだった。
AIがコードを書けるようになった先で、何が詰まったか
AIへの期待値が「コードを書かせること」に集中しがちなのは、そこが一番わかりやすい変化だからだ。実際にPR数が増え、スプリントのタスクが片付くスピードは上がる。ダッシュボードの数字も改善する。
ところが、全体のスループットは思ったほど上がらない。
これは今に始まった話じゃないが、AIエージェントの時代になってその構造がより明確に出てきた。瓶のどこかが細くなっているかぎり、液体はそこでしか詰まらない。そして詰まる場所は一つ解消するたびに次の場所へ移る。Gotaさんの記事は、その移動の記録だ。
ボトルネック1：意図と前提のズレ
最初にぶつかったのは、コードは書けるが、つくりたいものがつくれるわけではない、という問題だった。
仕様書を詳細に書く方向に進んだが、エージェントが生成した大量の設計書を人間は同じ速度では読めない。事前に固めるほど、エージェントの強みである生成速度が失われる。質問攻め（記事内では「grill-me」と呼ばれるスキル）も試したが、10問・20問と来るうちに「うん、いいかんじ！じゃあそれで！」と理解を諦めてしまう。「理解負債の始まり」という表現が刺さった。
たどり着いた方法は逆転の発想だ。人間がひとつずつ前提を説明するのではなく、エージェント自身に「何をしようとしているのか」「なぜそうするのか」「どんな前提で考えているのか」を先に説明させる。人間は理解のズレだけを指摘する。ゼロから大量の情報を入力するより、ズレだけを直す方が認知的負荷は圧倒的に小さい。
人間が事前に握るのは、目的・制約・判定基準の3つに絞り、要求の細部まで事前に決めきることを意識的に減らしている、とある。ここに実務的なリアリティがある。「仕様を完璧にしてから渡す」というアプローチが、AIエージェント時代には逆効果になり得る。
ボトルネック2：正しくつくれたかの検証
指示が明確でも、エージェントは実装ミスを「普通にする」。そして「全ての実装が完了し、テストも正常にパスしました」と自信満々に報告してくる。
実装が数分で終わるのに、人間がローカル環境を立ち上げ、ブラウザをクリックし、ログを目で追っていたら、開発はそこで止まる。そこで検証もエージェントにやらせることにした。
ポイントは二つある。一つは、検証の中身だ。テストを流すだけではなく、実際のプロダクトを操作して確かめる。購入機能なら、商品選択から注文完了まで、エージェントがComputer Useなどを使って実際に触り、仕様書に書かれていない挙動までおかしくないかを見る。
もう一つは、検証の責任の分離だ。コードを書いたエージェント自身に検証の判定をさせない。同一セッションのまま検証させると、都合の良い検証ばかりを行う。だから全く新しいセッションで検証エージェントを立ち上げ、QAテスターとして敵対的に検証させる。クリティカルな指摘がなくなるか、指定した回数に達するまでループを回す。トークンの消費量はかなりのものだが、そのおかげで実際の環境でしか見つかりにくいバグを事前に潰せている、という。
証拠として添付させるのは、スクリーンショット・実行ログ・保存されたデータの中身。さらに「mainでは失敗し、このPRでは通る」ことを示す条件ごとの表、わざと壊すと検証が失敗することの確認、そして「このPRで証明していないこと」の明記だ。
「エージェントネイティブなアーキテクチャとは、エージェントが自分の間違いを安く速く見つけられる設計のことだ」という一文は、抽象論ではなく設計方針として読むべきだ。
ボトルネック3：レビューとAuto Merge
検証が回るようになると、次は別の問題が出た。最初の頃は10,000行のPRが平気で上がってきて、読めない・理解できない・どこから見ればいいかも分からない、という状態になった。
手をつけたのはPRの切り方だが、これはPRの段階で頑張るというより設計段階の話だ。目的と境界を最初に握っておけば、1つのPRが1つの目的に収まりやすくなる。Stacked PRの活用も含めて、人間が理解できる大きさとスコープに収める。行数を減らすことが目的じゃない。理解できる大きさに保つことが目的だ。
その先にあるのがAuto Mergeだ。人間が見るべき範囲を先に決めておき、それ以外は動いた証拠と不変条件のチェックが通ればマージまで進める。現状、人間が見るべき範囲は権限周り・データ構造・外部連携のような不可逆なものに絞っている。現在PRの約85%がAuto Mergeで入っており、PRをつくってからマージまでの時間の中央値は約18分、とある。
ただし最初からAuto Mergeにしていたわけではない。検証環境を整えながら、リスクの低いところから少しずつ切り替えてきた、という順序は重要だ。自動化を「最初から全部」やろうとすると壊れる。準備が整ったところから切り替えるという段階論がここにある。
ボトルネック4：構造を保ち続けること
Auto Mergeが85%になっても、解決したわけではなかった。
抜き打ちでレビューを見ると、動いてはいるが怪しい実装が普通に見つかる。フロントは可逆だからと雑に実装されていたり、同じような処理が複数箇所に整理されないまま入っていたり、古いルールが抜けきっておらずエージェントがそれに引っ張られていたり。
ここで重要な指摘がある。これは「人間にとって読みにくい」だけの問題ではない、ということだ。コードベースが汚れるほど、エージェントにとって「正しそうな実装の候補」が増える。同じような処理が3箇所あれば4箇所目をつくりやすくなる。後方互換性のような古いパターンが残っていれば、エージェントはそれを真似する。エージェントは今あるコードをお手本にして書くから、クリーンなコードベースを保つことは、エージェントの探索空間を狭める意味でも重要だ、という論理は正確だと思う。
コードを読まない分、構造を保つ仕事は逆に増えた。定期的に設計の見直しをかけ、重複やオーバーエンジニアリングが検出されれば修正する。マージされたPRの約2割はこうした保守のPRだ、という数字は象徴的だ。速くなった開発の5分の1が、構造の維持に使われている。
ここからは見方だが：何がモデルが強くなっても残るか
Gotaさんの記事で最も示唆的なのは、「つくって解体してきたもの」の節だ。
エージェントの段取りを細かく決める仕組みを一気につくったが、3週間で新モデルが出たことで不要になり、まとめて消した。一方、PRの証拠を機械的にチェックする仕組みや、検証環境をつくるスキルは0から5本に増えて育ち続けている。
この対比が、判断軸を与えてくれる。
消えていくのは、「モデルの能力不足を補うためにつくった仕組み」だ。モデルが10倍強くなれば、ガイドラインの細かさや段取りの精度は不要になる。残るのは、意図のズレを見つけること・失敗を観測できること・フィードバックを速く返すこと・コードベースの境界やアーキテクチャを保つこと——これらはモデルが強くなっても変わらない。
「エージェントを細かく制御する仕組みを増やすより、間違えてもすぐ気づける環境をつくる方に時間を使っている」という一文は、AI開発の設計思想として読める。
実務的な示唆：どこから手をつけるか
記事全体を通して見えてくる優先順位はこうだ。
まず検証の責任を分離する。 コードを書いたエージェントに検証させない、という原則は今すぐ適用できる。同一セッションでの自己評価は信用しない、という前提で設計する。
可逆・不可逆の仕分けを設計段階でやる。 権限周り・データ構造・外部連携のAPIは不可逆と分類し、複数案を比較検討する時間を設ける。フロントのUI実装などの可逆なものは素早く進める。この仕分けをしないまま自動化すると、後からの手戻りが大きくなる。
Auto Mergeは最初からやらない。 検証環境が整い、リスクの低い領域が明確になってから、少しずつ切り替える。いきなり全部に適用すると壊れる。
コードベースのクリーンさを「エージェントのパフォーマンス問題」として捉える。 人間のレビュアーのためだけに構造を整えているという認識だと後回しになる。エージェント自身の出力品質に直結する、という視点で優先度を上げる。
軽いまとめ
この記事が面白いのは、AIへの期待論でも警戒論でもなく、実際に動いている現場の記録だからだ。週200PR超え・Auto Merge 85%・中央値18分でマージ完了という数字は、「AIで開発を加速できる」という事実を示しながら、同時に「それを実現するまでにどれだけの設計と試行錯誤が必要か」も示している。
コードを書かせることは、もはや難しい仕事ではない。難しさが移った先——検証、構造、設計の前提合わせ——こそが今の開発現場で問われていることだ。
ここで読者に渡したい判断軸は一つ。「AIを導入したのに全体が速くならない」という状況に直面したとき、コードの生成速度を疑う前に、「ボトルネックは今どこにあるか」を先に見るべきだ。詰まっている場所が変わっているだけで、AIの問題ではないことが多い。
