AIを増やしたら、なぜか自分が忙しくなった。ChatGPT × Codex × Claude Codeを自律運転するまでの3か月

生成AIを本格的に開発へ使い始めてから、およそ3か月が経ちました。

最初は単純に、AIへ任せる仕事を増やせば、その分だけ自分の仕事は減っていくと考えていました。Codexに実装を任せ、Claude Codeには別の修正や調査を依頼し、ChatGPTで仕様整理やレビューを進める。それぞれを並行して動かせば、一人で開発するより圧倒的に速く進められるはずです。

実際、コードを書く速度は大きく上がりました。

ところが、しばらくすると別の問題が起きました。

AIは働いているのに、なぜか自分が以前より忙しくなっていたのです。

誰がどのIssueを担当しているのかを確認し、Claude Codeが止まっていないかを見て、Codexの作業結果を確認し、Pull RequestのCIを確認し、レビューが終わったら次の仕事を探して割り振る。別のAIが同じ箇所を触っていないかも確認しなければなりません。

コードを書く作業は確かにAIへ移りました。しかし、その代わりに私は、一日中AIへ「次はこれをやってください」「ここから再開してください」「このPRを確認してください」と指示する人になっていました。

これは、自分が思い描いていたAI開発とは違いました。

ボトルネックが「実装」から「AIの管理」へ移った

AIコーディングを導入する以前は、人間がコードを書く速度がボトルネックでした。AIを導入すると、その制約はかなり小さくなります。一つの修正を進めながら、別のAIにテストを書かせ、その横で別の調査を進めることもできます。

ところが、並列化すればするほど新しい問題が増えます。 たとえば、Codexが認証処理を変更しているところへ、Claude Codeにも同じ認証周辺の修正を依頼してしまえば、両方の実装が正しくても統合時に衝突します。

あるチャットでは「PRをレビュー中」と認識していても、その間に別のAIや人間がcommitを追加してHEADが変わっていることもあります。以前のレビュー結果を、そのまま新しいHEADへ流用することはできません。

AI自身が「実装できました」と報告したので確認すると、別の実行条件ではテストに失敗することもあります。認証や接続確認で止まり、処理自体は進められる状態なのに誰も気づかないまま放置されることもありました。さらに、チャットや実行セッション自体が途中で切れることもあります。

AIを一つ使っているだけなら、人間が頭の中で状態を把握できます。しかし、複数のAIが高速に動き始めると、それは難しくなります。

そこで気づきました。

次に自動化すべきなのはコードを書く仕事ではなく、AIを管理する仕事なのではないか。

ここから、現在のControllerという考え方が生まれました。

失敗するたびに、運用ルールが一つずつ増えていった

現在の仕組みには、いくつか強いルールがあります。ただし、最初から体系的に設計していたわけではありません。実際には、運用で問題が起きるたびに、その問題を二度と起こさないためのルールを追加していきました。

この3か月で特に大きかったのは、「AIをもっと賢くすれば解決する」と考えなくなったことです。 問題の多くは、個々のAIの能力不足ではありませんでした。誰が何を担当するのか。どの情報を現在状態として信用するのか。どの条件を満たせば完成なのか。途中で止まった仕事を誰が回収するのか。どの時点で人間へ判断を戻すのか。これはモデル性能ではなく、運用設計の問題です。

最終的に、人間が一つずつタスクを配るのではなく、ControllerがGitHubや実行環境を確認し、現在状態を再構築したうえで、安全に進められる仕事を選ぶ構造へ変えました。

この仕組みを毎時00分に起動し、開発全体を継続的に見直すようにしました。

では、実際に動かすとどうなるのか。

2026年9月8日13時16分から翌9日13時16分までの24時間について、GitHubに残ったControllerの実運転記録を振り返りました。

実運転して分かったこと――24時間で実際に何が起きたか

結論から言うと、最も印象的だったのは「大量のPull Requestを自動で作れたこと」ではありませんでした。

むしろ、進めるべき仕事を進める一方で、進めてはいけない仕事を止められたことの方が、Controllerの価値をよく表していました。

CIが通っていても、QCでHIGHなら止める

ORCHESTRATORのPR #90では、候補HEAD 520fb3e299bb1aa6c7d934a94d1a7d9a325a1e8aがLinuxとDarwinのHosted CIを通過していました。CIだけを見れば、そのまま受け入れたくなる状態です。

しかし、その後の独立互換性QCで、既存の永続化データを正しく扱えなくなるHIGHの問題が見つかりました。その候補はその時点で受入対象から外され、Ready、merge、deploy、Productionのすべてが停止されました。

さらに重要なのは、修正を始める際にも、すでにClaude Codeのwriterがその領域を担当していることを確認し、別のwriterを追加しなかったことです。競合を避けながら同じ担当者に修正を継続させ、変更後には古いCIとQCを無効として扱い、改めて検証する流れに戻しました。

この一連の動きは、「AIがコードを書ける」こととは別の能力です。現在の状態を読み、危険な候補を止め、担当の競合を避け、検証をやり直す管理機能が必要になります。

一度のPASSを信用せず、HEADが変われば検証をやり直す

SIGNALのPR #137でも、最終的なmergeまで一直線には進みませんでした。 最初の候補ではソースレビューを通過したものの、Hosted CIでTypeScriptとのモジュール境界に問題が見つかりました。修正した次の候補ではruntime regressionを通過しましたが、今度はTypeScriptのportableな実行条件で失敗し、独立レビューでもMEDIUMとして受入を止められました。

そこで再度修正し、最新mainとの同期まで済ませた最終HEADに対して、conformance、analytics audit、customer-accessの各CIと、別セッションによる独立QCを改めて取得しました。

すべての条件が揃った最終候補だけが、2026年9月9日13時06分にmergeされています。

この運用では、以前のHEADで得たPASSを新しいHEADへ流用しません。

live HEADを確認
      ↓
そのHEADのCIを確認
      ↓
そのHEADの独立QCを確認
      ↓
mainの現在状態を再確認
      ↓
条件が揃ったときだけmerge

人間が一つのPull Requestだけを見ているのであれば、少し慎重すぎるように見えるかもしれません。しかし、複数のAIが同時にcommitし、mainも動き続ける環境では、「何を検証したのか」ではなく、どのHEADを検証したのかを明確にしなければ安全性を保てません。

「改善したから採用」ではなく、効果がなければ捨てる

別の例では、みやこでITのCIを高速化するため、Gitのcheckoutをshallowにする実験を行いました。

実測すると、checkout時間はおよそ8秒から7秒になり、改善幅は約1秒でした。一方、独立したClaude CodeのQCでは、mainが動くタイミングによってmerge baseを正しく取得できなくなる可能性がHIGHとして指摘されました。

結果として、PR #272はmergeしていません。

約1秒の高速化のために、PR差分判定の正しさを危険にさらす価値はないと判断したためです。

AIによる自動化では、「どれだけ多く仕事を実行できたか」に注目しがちです。しかし実際には、やる価値のない仕事を途中で捨てることも重要な自動化でした。

AIはコードを変更できます。しかし、「変更できること」と「変更する価値があること」は別です。効果、リスク、複雑性を比較して、場合によっては何もしない。この判断まで制御ループへ入れなければ、AIは不要な変更を高速に積み上げる存在になってしまいます。

チャットが途切れても、GitHubから復帰する

この3か月でかなり苦労したものの一つが、セッションの継続性でした。

実行していたチャットやセッションが途切れると、以前は「どこまで終わっていたのか」を再び人間が説明し直していました。これは非常に非効率です。

そこで、現在はGitHub上のIssueを復旧アンカーとして使い、mainの現在位置、各PRのHEAD、CI、QC、現在担当しているwriter、残タスクなどを外部状態として残すようにしています。

2026年9月8日18時55分のChat-failure recovery checkpointでも、チャット履歴を実行権限や唯一のタスク台帳にせず、live GitHub readbackを優先する原則を明示しました。復旧時に必要なのは以前のChatGPTセッションを完全に再現することではありません。

次の行動に必要な事実を、現在のSource of Truthから再構築できればよい。

この考え方を、私は「Reconstruct before Act」と呼んでいます。

過去のチャットは記憶として利用しますが、現在状態とはみなしません。現在のmain、PR、HEAD、CI、レビューと食い違う場合は、GitHub側を優先します。

24時間動かして分かったのは、「実行」より「制御」の重要性だった

24時間の記録を振り返ると、Controllerが行っていたことは単純なタスク実行ではありませんでした。

この3か月、当初は「AIをどこまで長時間働かせられるか」を考えていました。しかし、今は少し違います。

「24時間止まらないAI開発チーム」の価値は、AIが24時間コードを書き続けることではありません。 個々のAIは普通に止まります。CIも失敗します。認証を要求されることもあります。間違った変更を提案することもあります。

重要なのは、その一つ一つの失敗によって開発全体が停止しないことです。

安全に進められるものは進める。危険なものは止める。競合を避ける。状態が変われば検証をやり直す。効果がなければ捨てる。途中でセッションが切れても、現在状態から再開する。

止まらないのは一つのAgentではありません。

仕事を前へ進めるための制御ループです。

完全自律より、「人間が張り付かなくてよい状態」を目指す

この仕組みは、まだ完全自律開発ではありません。認証や権限確認が必要になることもありますし、本番反映のように人間の判断を残した方がよい領域もあります。

だからこそ、人間を完全に排除することを目標にはしていません。

目指しているのは、Human-lessではなくHuman-on-exceptionです。

通常の確認、タスク選定、割り振り、QC、再試行、復旧はAI側で回し、本当に人間の判断や権限が必要な例外だけを人間へ上げます。

AIが10人分の速度でコードを書けたとしても、人間が一日中その10人のAIを監視しているのであれば、まだ人間はオペレーションから解放されていません。この3か月で、自分自身がその状態をかなり経験しました。

だから、今後最も重要なKPIは、AIが何本のPull Requestを作ったかでも、何行のコードを書いたかでもないと考えています。

人間がAIチームを前へ進めるために介入した総時間です。

今回の24時間については、GitHubの履歴からCI、QC、merge、停止判断などを追跡できます。しかし、「人間が実際に何分間介入したか」までは、信頼できる形で復元できません。ここは推測で数字を作るべきではありません。

次の計測では、Controllerの起動回数、自動で着手したタスク、QCによる差し戻し、競合回避、自動復旧、人間へのエスカレーションと合わせて、人間の実介入時間も記録します。

3か月かけて分かったこと

3か月前の私は、「どのAIが一番コードを書けるか」をかなり気にしていました。今でもモデル性能は重要です。 ただ、複数のAIを実際の開発へ投入してみると、そこだけを改善しても全体の生産性は上がり続けないことが分かりました。

Agentが速くなればなるほど、次はAgent Operationsがボトルネックになります。

誰に何を任せるのか。どこまでを完成とするのか。どの状態を信用するのか。どの仕事を止めるのか。失敗したときにどう復旧するのか。そして、どこから人間の判断を必要とするのか。

この問題を一つずつ潰していった結果として、ChatGPTをControllerにして、CodexやClaude Codeをその下で動かす現在の形になりました。

振り返ると、3か月かかった理由は、設定方法が難しかったからではありません。

AIに仕事をさせる方法ではなく、AIが働き続けても壊れない運用を作る必要があったからです。

AIコーディングによって、コードを書く速度はこれからも上がっていくでしょう。そのとき、次に必要になるのは「もっと速くコードを書くAI」だけではないと思っています。

複数のAIを安全に働かせ、必要な仕事を進め、危険な仕事を止め、失敗しても復旧できる仕組み。

つまり、AI開発チームそのものを運用するControl Planeです。

3か月かけてようやく、その入口まで来ました。

---

観測範囲について：24時間の具体例は2026年9月8日13:16〜9月9日13:16のGitHub運用記録を中心に整理しています。人間の実介入時間はGitHub履歴だけでは正確に復元できないため、本記事では推測値を掲載していません。