Thiết kế vòng lặp tự chủ ── Kiến trúc vượt ra ngoài prompt

※本記事は、社内向け資料（図解形式）をもとに文章化（Manuscript形式に再構成）したものです。テーマは、コードを書き・レビューし・マージする作業を人が寝ている間にも回し続ける、レジリエントなマルチエージェント「Generator-Evaluator」アーキテクチャの設計です。

Overview

AI活用は、人がプロンプトを打って待つ「人間の時計」の時代を終え、エージェントが無人で回り続ける自律ループを設計する段階へと移行しつつあります。本稿は、社内向け資料をもとに、発見・受け渡し・検証・永続化・スケジューリングという5つのノードからなるループの構造と、GeneratorとEvaluatorを分離するアーキテクチャ、週に1,300本の機械生成PRをマージするStripeの事例、そして運用上のサーキットブレーカーを整理します。結論としては、生成のコストが実質ゼロに向かう中で希少であり続けるのは判断であり、厳格な評価者と人間が介入できるチェックポイントを備えたループを、エンジニアであり続けるつもりの人間として設計することが重要です。

「人間の時計」の終わり

従来のAI活用は「人間の時計」で動いていました。エージェントは入力を待ち、人間がEnterを押し、トークンが生成され、止まる。この繰り返しです。2026年6月、転換点が訪れました。Peter Steinberger（OpenClaw）、Boris Cherny（Claude Code）、Addy Osmani（Chrome）が、それぞれ独立に、同じ1週間のうちに同じ認識へと収束したのです。ツールはしきい値を越えた、と。

シフトの本質はこうです。エージェントにプロンプトを打つ人であることをやめ、それを代わりに行うシステムを設計する人になる。自律ループエンジンは、(1) タイマーで起動し（スケジュールで目覚める）、(2) 並列のサブエージェント（ヘルパー）を生み出し、(3) 自分自身に供給する（昨日の出力が今日の入力になる）という3つの性質を持ちます。

4層のAIプロトコルスタック

AI活用のレイヤーは4つに整理でき、上の層ほど失敗の影響範囲（ブラスト半径）が大きくなります。

層	核心的な関心事	境界の単位	失敗の影響範囲	人間の立ち位置
Layer 1: プロンプト	モデルに何を伝えるか	1回のやり取り	すぐ分かる誤答	タイピスト
Layer 2: コンテキスト	ウィンドウに何を入れるか	1セッション	自信満々の誤った推論	編集者
Layer 3: ハーネス	1回の実行を武装させる（ツール/アクション）	1タスク	出荷前に捕捉される不良差分	レビュアー
Layer 4: ループ	ハーネスのスケジューリング	無人の反復	数日単位で進む、構造を蝕む腐食	アーキテクト

回り続けるループの解剖学

自律ループは5つのノードで構成されます。

1. 発見（Discovery）── Skills（SKILL.md）が支える。プロジェクトの恒久的な知識であり、「意図の負債」を返済する。

2. 受け渡し（Handoff）── Worktreesが支える。並列実行のための独立したgitディレクトリ。

3. 検証（Verification）── サブエージェントが支える。Generator-Evaluatorの分離。「ノーと言える存在」。

4. 永続化（Persistence）── コネクタ（MCP）とメモリが支える。状態はディスク上のファイル（./state/triage.mdなど）に置く。エージェントは忘れるが、リポジトリは忘れない。

5. スケジューリング（Scheduling）── 自動化基盤（ローカルcron、GitHub Actions、クラウドルーチン）が支える。サイクルを閉じる。

Worktree並列化

問題：2つのエージェントが同じ作業ディレクトリを編集するのは、2人のエンジニアが同じ行にコミットするのと同じです。衝突は無人パイプラインを壊します。プリミティブ：claude --worktree fix/auth-test 'draft the fix' のように、独立した作業ディレクトリを分離します。効果：並列化を「動くが散らかる」から「動いてきれい」に変えます。1つのリポジトリ内の複数の独立した作業ディレクトリが、高スループットのissueトリアージを可能にします。

自己説得バブル ── GeneratorとEvaluatorを分ける

アンチパターンは、生成者（Generator）が自分の宿題を自分で採点することです。生成者は自分のコードを見ているのではなく、自分の自己説得の連鎖を見ています。これに対しGAN分割では、生成者と評価者（Evaluator）を分離し、評価者には敵対的なコードレビュアーの役割を与えます。「このコードは反証されるまで壊れていると仮定せよ。褒めるな。失敗する箇所を見つけよ」。

核心的な洞察：独立した評価者を厳格な懐疑者にチューニングすることは、生成者に自分の成果へ批判的にならせることよりも、数学的にも実務的にもはるかに実現しやすいのです。

外部実行による判定

欠陥：評価者がコードを読むだけなら、判定は「正しく見えるか」であって「正しく動くか」ではありません。シフト：評価者を外部の実行環境（例：Playwright MCP）に接続します。新しい標準：評価者はボタンをクリックし、画面遷移を強制し、DOMの状態を取得し、テストを走らせます。判定は「意図」から「振る舞い」へ移るのです。評価エージェント → Playwright MCPコネクタ → DOM検査/スクリーンショット/テストランナー → 合格/不合格の判定、という流れになります。

Maker-Checkerの停止条件

ループはいつ終わるべきか。/goalプリミティブは「条件が満たされるまで回す」を表現します（例：/goal test/authの全テストがパスし、lintがクリーンであること）。Generator（重いモデル）がコードを書き、Evaluator（重いモデル）がMCP経由でテストを実行し、Gatekeeper（速く、フレッシュなモデル）が/goalを評価します。満たされればループを抜け、失敗すれば却下理由をGeneratorに差し戻します。

原則：完了の判定は、作業をしたモデルのコンテキストの荷物を一切持たない、フレッシュなモデルが行わなければなりません。そして覚えておくべき言葉があります。ループの床は評価者である。生成者は生み出されるものの天井を決め、評価者は生み出さないものの床を決める。

ループが失敗する5つの形

欠けている要素	アンチパターン	症状	必要な修正
検証の欠如	うなずくだけのループ	100ターン、自分のゴミを承認し続ける	Generator-Evaluator分離の実装
永続化の欠如	記憶喪失のループ	毎朝まったく同じ作業を再発見する	状態ファイルのディスク書き込みを強制
スケジューリングの欠如	手動のループ	デモした日以来、一度も動いていない	cron/イベントトリガーを接続
発見の欠如	盲目のループ	いまだに毎回30分かけて「このバグを直して」を貼り付けている	ヒューリスティクスをSKILL.mdに焼き込む
受け渡しの欠如	絡まったループ	5つの並列エージェントが1つのgitディレクトリを破壊する	--worktreeによる分離を強制

エンタープライズ規模の決定論的インターリービング

Stripeの「Minions」パイプラインは、トリガー（Slack）→ コンテキストオーケストレーター（Sourcegraph/Jira）→ コード生成（LLM）→ 必須リンターゲート → Lint修正（LLM）→ Gitコミット → 人間レビュー（週1,300PR）という流れで、週に1,300本の機械生成PRをマージしています（オープンソースフレームワークGooseで駆動）。

秘訣は、決定論的なシステムに決定論的な仕事をさせることです。コンテキスト収集とlintは厳密にハードコードされ、LLMは硬いルールに縛られたガードレールの内側に完全に閉じ込められます。環境は「ペットではなく家畜（Cattle, Not Pets）」として扱い、EC2上のDevboxは状態の腐敗を避けるため即座に交換・破棄されます。

実行トポロジー ── ループはどこに住むのか

トポロジー	マシン状態	セッション	最小間隔	ローカルFSアクセス
クラウド（Cloud Routines / GitHub Actions）	マシンOFFでも可	不要	1時間	なし（クリーンクローン）→ 夜間トリアージに最適
デスクトップ（macOS cron）	マシンON	不要	1分	あり → 定期的なリポジトリメンテナンスに最適
ローカル（/loopコマンド）	マシンON	必要	1分	あり → 開発中の高頻度チェックに最適

ローカルの再実行を「寝ている間も動いている」と呼ぶのは誇張です。ローカルのスケジューリングが買うのは頻度であり、クラウドのスケジューリングが買うのは真の自律性です。1つのスケジューラで両方は手に入りません。

見張られていないループの悪循環

無人ループには4つのリスクがあります。検証の負債（テストは通るが微妙な論理欠陥を含むコードのマージ）→ 理解の腐敗（コードベースの心的地図が現実から乖離する）→ 認知的降伏（「どう動いているのか分からないが、PRを受け入れよう」）→ トークンの浪費（見張られていないエージェントが一晩中ヘルパーを生成し、無駄なバグ修正をリトライし続ける）。これらは4つの別個のリスクではなく、単一の複利的な失敗モードです。厳格な評価者を持たないループは、支出の決定権を自分のバグに委ねているのです。

ゼロコスト生成の経済学

豊富になるもの：生成。コード、計画、修正、プルリクエストのコストは実質ゼロに向かい、機械的労働は崩壊します。希少であり続けるもの：判断。ループは100個の実装候補を生成できますが、その選択は「正しく見える」に基づくのであって「実際に正しい」に基づくのではありません。増幅器としてのループ：ループは忠実な掛け算の記号です。理解を持ち込めば理解を増幅し、怠惰を持ち込めば災害を増幅します。

運用上のサーキットブレーカー

1. 常にサンプルを読む（理解の腐敗への防御）：毎日ランダムに選んだ機械生成PRを自分の言葉で説明できるか確かめる。説明できなければ、あなたの心的地図は既に古い。

2. 出荷前に上限を設ける（トークン浪費への防御）：実行ごとの予算上限や最大リトライ回数は、節約のためではなく、開放的なリスクを有界のリスクに変換するサーキットブレーカーである。

3. 扉を一つ開けておく（認知的降伏への防御）：人間のために一時停止するチェックポイントを少なくとも一つ作る。毎回介入するためではなく、介入できることを保証するために。

最小のレジリエントなループを配備する

最小構成は次のようになります。スケジュール（cron：クラウド自動化）で起動し、スキル（morning-triage：発見）を実行し、結果を./state/triage.md（永続化）に書き込む。発見された修正はワークツリー（fix/$finding：受け渡し）で実施し、「テストがパスしlintがクリーン」という/goal（検証）で判定する。出力フォルダは ./inbox/（未検証のものすべて）、./state/、./src/ に分かれ、自動マージは決してしない。未検証のものはすべて./inbox/に着地させるのが原則です。

最後に、この言葉で締めくくります。

「ループを作れ。ただし、エンジニアであり続けるつもりの人間として作れ。ボタンを押すだけの人としてではなく。」