104万行をAIと書いて分かった、並列開発で先に詰まるもの
目次
2025年7月27日に、いまのPentaTrailのリポジトリを作りました。最初のコミットはSupabaseとVercelを使ったマルチテナントSaaSの基盤で、その後はWebアプリ、ASM、データベース、Edge Function、課金、監査、ISMS対応まで同じmonorepoで開発しています。
2026年8月29日に全履歴を取り直して数えたところ、外部から取り込んだ検査テンプレートと機械が吐いた収集データを除く自作部分は、空行とコメントを除いて 1,040,063行 ありました。PRは1,646本、merge済みは1,451本です。
ここまで来ると、AIがコードを書けるかどうかは、開発上の大きな問いではなくなりました。いま困っているのは、「複数のAIに、同じリポジトリで安全に働き続けてもらうにはどうするか」です。
コードを書く速度は、まだ上がっている
PRを基本単位にして開発するようになったのは2026年3月頃からです。それ以前のPRは56本でしたが、3月以降だけで1,590本を作り、1,399本をmergeしました。
8月は29日までに410本をmergeしています。直近30日では433本、1日平均14.4本です。PR一本の追加行数は中央値342行、75パーセンタイルで1,649行でした。細かな修正だけを大量にPRへ分けた数字ではありません。
現在残っている104万行とは別に、全履歴では自作部分を約253万行追加し、約110万行削除しています。製品コードだけでも約83万行を書き、約51万行を消しました。AIが出したものを積み上げるだけではなく、かなりの量を作り直しながら進んでいます。
表1：2026年3月以降のPRの流れ
| 月 | 作成 | merge | merge/日 |
|---|---|---|---|
| 2026-03 | 45 | 10 | 0.3 |
| 2026-04 | 228 | 178 | 5.9 |
| 2026-05 | 307 | 274 | 8.8 |
| 2026-06 | 278 | 278 | 9.3 |
| 2026-07 | 278 | 249 | 8.0 |
| 2026-08（29日まで） | 454 | 410 | 14.1 |
この半年で、コードを出す速度はかなり上がりました。ところが、Claude Codeを複数同時に動かすようになると、別の種類の待ちが増えてきます。
AIを二つ動かすと、所有者が必要になる
一つのAIに一つのIssueを渡している間は、従来の開発とそれほど違いません。Issueを読み、実装し、テストしてPRを出すだけです。
複数のClaude Codeを同時に動かすと、二つのセッションが同じIssueを取りに行くことがあります。別のIssueでも、同じ認証コードや同じテーブルを触れば変更がぶつかりますが、PRになる前の作業はGitHubのPR一覧に出てこないので、気づくのが遅れます。
途中でセッションが落ちれば、「作業中」という印だけが残ります。本当に死んだ作業なら別のAIへ渡せますが、元のセッションがまだ生きていれば二重実装になりかねません。
人が数人で開発していれば、「そこは作業中です」の一言で済む場面です。AIを並列化するなら、この会話を仕組みに置き換えるほかありません。
その仕組みをIssue Loopと呼んでいて、runの識別、Issueのclaim、作業中に押さえている資源、runが生きているかを明示的に持たせています。claimの所有者を自分、他の生きたrun、死んだrunに分け、死んだ作業だけを引き継げるようにしました。同じ場所を変更しそうなIssueも、PRができる前から同時に走らせない方向へ寄せています。
CISOの目線で見ると、AIの性能ではなく変更管理の問題でしょう。変更主体を増やすなら、誰が何を触っているか、誰の作業が有効なのかを追えることが先に要ります。
Claudeが実装し、Codexには別の目で見てもらう
実装はClaude Codeに任せ、変更はCodexにも読ませています。同じAIに自分の実装を見直させるだけでは、最初の前提ごと引き継いで同じ穴を見落とすことがあるためです。
実際、何巡かレビューした後で、それまで拾えていなかった重要な問題を別の独立レビューが見つけたことがあります。ただ、レビューを増やせば最後まで自動で進めてよいわけでもありません。
権限やデータ保持、migrationの変更では、CIが緑でも設計上の判断が残り、直した結果ほかの契約を壊せばもう一度見直しになります。機械の検査だけで先へ進めてよい変更と、人が決める変更を分けなければなりません。
この部分は、以前書いたClaude と Codex の二刀流レビューの延長です。並列数を増やして分かったのは、レビューの目を増やすだけでなく、変更をどの順番で共有branchへ取り込むかまで管理しないと流れないことでした。
6並列の次に欲しいのは、24並列ではなかった
現在は事務所のデスクトップで4セッション、自宅のラップトップで2セッション、合計6セッションまでClaude Codeを並列に動かせます。制約になっているのは主にメモリで、RAMを多く積んだサーバーを置けばセッション数そのものは増やせます。
ところが、6本の仕事を絶えず安全に供給できるかは別問題です。
あるIssueが共通の認証処理を変更し、別のIssueが同じテーブルを変更するなら、空いているセッションがあっても同時には進めにくくなります。6本のPRを並列に作れても、1本をdevへmergeした時点で残りは一つ古い状態を見ているので、取り込み直してテストし、変更によってはレビューもやり直しになります。
実装は並列化できますが、共有するコードベースへの統合は同じようには並列化できません。
そのため、次に測りたいのはCPU使用率より、セッションが仕事を待っている時間、claimや変更箇所の衝突、PRを作ってからmergeされるまでの時間、人の判断で止まった回数です。ここが詰まっている状態でセッションだけ12、24と増やしても、待つAIが増えるだけでしょう。
次は、Issueを作る側がボトルネックになる
Issue Loopが安定すると、もう一つ人の仕事が残ります。何を作るかを決め、実装できる大きさまで分け、依存関係を見てIssueを並べる仕事です。
いま考えている次の層をProject Loopと呼んでいます。人が製品上の目的や解くべき問題を置き、リポジトリと既存Issueを調べて実装単位へ分解し、同時に進められる仕事をIssue Loopへ渡したうえで、その下でClaude Codeが実装し、Codexなど別系統のAIとCIが検査します。
まだ完成していません。
24セッションを起動することより、6セッションが何週間も仕事を切らさず、互いの変更を壊さず、問題のある変更を止めながら製品へ反映し続けるほうが、はるかに難しいと感じています。104万行まで開発してきて、AIネイティブ開発の律速はコード生成から、その周りの制御へ移り始めました。
