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 をレビューしてはいけないか

フォローお待ちしています。