TL;DR:
AIコーディングは1モデル・1セッション・1PRの問題ではなくなった。複数のAIワーカーをスコープを失わずに、証跡を残しながら、レビュー品質を保ちつつ動かすにはどうすればいいか。TheGateBreakerの答えはGitHub自体を「OS」として使うことだ。個々の要素は公開事例に存在する。文書化されていなかったのはその組み合わせだった。Perplexityが外部研究として裏付けた。
問題：コードを書く部分はもう「終わった」
AI がコードを書く。それはもう当たり前になった。
問題は別のところにある。複数の AI ワーカーを、同時に、セッションをまたいで、スコープを失わずに動かすことだ。
1 人のエンジニアが書くより速くコードが出てくる状況でも、次のことを失いやすい：
- スコープ：ワーカーが Issue を超えた作業を静かに始めていないか
- 証跡：判断と検証の記録が、ターミナル出力にしかないことはないか
- レビュー品質：実装者と審査者が分離されているか
- 状態：現在どのワーカーがどのタスクを持っているか、チャットの外で分かるか
- Human の制御：マージ・クローズ・公開の判断が、誰の手元に残っているか
単一モデルで単一タスクをこなすなら、この問題は小さい。5 つの AI ワーカーを並行させると、制御を失う。
業界にすでにあるもの
まず正直に言う。この問題への答えの「部品」は、すでに公開事例にある。
Perplexity の Deep Research が確認した既存パターン：
| パターン | 代表例 |
|---|---|
| GitHub Issue → AI PR → Human マージ | GitHub Copilot Coding Agent、Devin |
| Role 分離（PM/実装者/審査者） | MetaGPT、ChatDev |
| AI 実装 + 独立 AI レビュー + Human マージ | CyberAgent Devin 運用事例（2025年7月） |
| AI PR のセルフマージ防止 | Devin（アーキテクチャ制約）、newmo（Branch Protection） |
| マルチエージェント並列レビュー | Claude Code Review（16%→54% カバレッジ向上）[Perplexity 引用] |
我々は最初ではない。
Role 分離、Human-in-the-loop マージ、AI PR レビュー——これらは確立されたパターンだ。出発点として使える。
TheGateBreaker が作ったもの
TheGateBreaker は AI 開発ワークフローを実験するオープンリポジトリだ。運用モデルの核心は 2 つの設計にある。
ワーカー役割マトリクス
| ワーカー | 役割 | 主なサーフェス |
|---|---|---|
| Human | 最終決定者 | Gmail / GitHub |
| ChatGPT | PM・ディスパッチャー | GitHub Issue・ChatGPT |
| ClaudeCode | 実装者・自己監査者 | ローカルリポジトリ・PR |
| Codex | 独立レビュアー | PR レビュー |
| Perplexity | 外部リサーチワーカー | GitHub Issue コメント |
役割は ベンダーをまたいで分離する。ClaudeCode が自分の実装をクローズ審査することはない。Codex が実装することもない。この分離は「慣習」ではなく、AGENTS.md と CLAUDE.md にバージョン管理されたドキュメントとして存在する。
GitHub ネイティブな運用ループ
Human の意図
↓
ChatGPT が GitHub Issue に変換
↓
ClaudeCode が branch で実装
↓
PR オープン
↓
Codex が Tier 1（軽量）レビュー
↓
ClaudeCode が修正
↓
ClaudeCode が自己監査
↓
Codex が Tier 2（深層）レビュー
↓
Human がマージ・クローズ判断
↓
Worker Report が永続メモリになる
重要なのは 2 段階のレビュー設計だ。
- Tier 1（軽量レビュー）：通常の PR 開発中に走る。Codex が差分を見て正確性・スコープ逸脱・明白なバグをチェックする。軽い。
- Tier 2（クローズゲート）：Issue がクローズ候補になったときだけ走る。ClaudeCode がまず自己監査し（受け入れ基準を成果物にマッピング）、次に Codex が深層レビューし、最後に Human が判断する。
なぜ毎回深層レビューにしないのか。
実際に試した。2 つのコストが現れた。
Codex の深層レビューはトークン消費が大きい。毎回 Thorough Review を走らせると、クォータがすぐに枯渇する。加えて、ClaudeCode が実装 → Codex がレビュー → ClaudeCode が修正 → 再レビューというサイクルが深層モードで毎 PR に走ると、1 Issue の解決に要する実時間が著しく増える。
深層レビューを「クローズ判断のときだけ」に絞るのは、コスト管理であり、速度管理でもある。 普段の開発は Tier 1 で速く動かし、最終確認のときだけ Tier 2 を使う——これが実運用から導いた設計だ。
Perplexity が「差別化ポイント」と言ったもの
Perplexity の Gap Analysis は、公開事例に存在しないものを 5 つ特定した：
| Gap | 内容 |
|---|---|
| A | クローズ推薦前の自己監査ゲート — 主要製品のどこにも文書化されていない |
| B | PM と実装者が異なるモデル、クロスベンダーがポリシー — 実践事例はあるが明文化はない |
| C | リポジトリが運用メモリ（AGENTS.md、WORKER_BOARD.md、Worker Report）— 公開事例で見当たらない |
| D | 実装者 ≠ 審査者を明示的なガバナンスポリシーとして記録 — 慣習ではなくドキュメント |
| E | Issue クローズを PR マージとは別のゲート判断とする設計 — 分離した事例がない |
Gemini も同じ方向を支持したが、C（リポジトリ＝運用メモリ）と E（クローズゲート）は独立して特定しなかった。
TheGateBreaker の新規性は個々の要素ではない。組み合わせだ。GitHub ネイティブな運用モデルとして、明示的な役割、クローズゲート、永続レポートを組み合わせたもの。Perplexity がそれを外部から裏付けた——今のところこのプロジェクトで最も強力な外部検証だ。
実際に動かして分かったこと
並行ワーカーのブランチ衝突
複数の AI ワーカーが同じ作業ツリーを使うと、git のブランチ状態が知らない間に変わっている。ClaudeCode が実装を終えてコミットしようとしたら、別の操作がブランチを切り替えていた——という事態が起きる。対策：コミット前に必ずブランチを確認する。
PR なしの直接 push がゲートを無効化する
Tier 2 クローズゲートは、PR の diff を Codex に見せるから成立する。main に直接 push してから事後 PR を作っても、diff はゼロになる。Codex は何も審査できない。ゲートが機能したように見えて、機能していない。これを運用中に発見し、「クローズ候補の変更は feature branch に置き、PR を開いてから Tier 2 を開始する」というルールを明示した。仕組みを作っても、穴を塞ぐルールを書かなければ機能しない。
Gmail Inbox が Human の進捗コントロールキュー
Human は GitHub のポーリングをしなくていい。ワーカーの完了・レビュー結果・判断依頼が Gmail に届く。Human は Gmail を起点に GitHub を開いて判断する。これで Human が常時監視しなくても制御が保たれる。
ヤクシェービングの誘惑
運用モデルを整備していると、「運用モデルを作ること」が目的化するリスクがある。今あるものを定義して、収益が出るか自動化が本当に必要になるまでは自動化しない——という明示的な棚上げが必要だった。
採用ポリシー
今すぐ採用：
- GitHub Issue をタスクスペックとして使う
- PR をレビューサーフェスとして使う
- Worker Report をセッションログとして使う
- Issue Close Gate（Tier 1 軽量 / Tier 2 深層の 2 段階）
- Gmail Inbox を Human の進捗コントロールキューとして使う
棚上げ（トリガーが発火するまで）：
- Perplexity API ブリッジ
- カスタム GitHub App・GitHub Actions 自動化
- フルダッシュボード
棚上げを解除するトリガー： プロジェクトから収益が出る、Perplexity/Gemini の手動ワークフローが本当のボトルネックになる、GitHub・Worker Report・Gmail の状態ずれが運用苦痛になる。
残っている問い
このモデルは動いている。検証は今のところ 1 プロジェクトだ。
- ワーカー役割マトリクスは別のプロジェクトや別のチームに移植できるか
- Tier 2 クローズゲートのコストは品質向上に見合うか（そう感じているが数字がない）
- Perplexity の「外部リサーチワーカー」能力は別トピックでも再現するか（#455 は 1 回の実験）
- このモデルが成立する条件は何か——Human の関与量、ワーカー数、タスクの種類
「当然そうすべき」とはまだ言えない。だから記録として残す。
AI Worker OS シリーズ Article 2 です。Article 1：なぜ AI は自分の PR をレビューしてはいけないか
フォローお待ちしています。
