ループエンジニアリングの解剖：動作・部品・アンチパターンで自走するループを点検する¶

対象 / ポイント

対象: Claude Code や Codex で、単発プロンプトの先にある自走ループ、定期実行、複数エージェント運用を設計したい開発者・技術リード。

ポイント:

ループはミスが何ターン生き延びるかでコストが決まる仕組みで、設計の主眼はミスと発見の距離を縮めることにある
1ターンは発見・受け渡し・検証・記録・スケジュールに分解でき、動作を1つ抜くと固有のアンチパターンになる
ループの床を決めるのは検証役で、生成役に自己採点させず懐疑的な別エージェントを構造的に分離する

仮に、ある夜、ループが20件のプルリクエストを開いたとする。すべてテストは緑である。だがそのうち3件には、テストが踏まない経路に潜むバグが入っていた。独立した検証がなければ、その3件はマージされ、誰も気づかないまま数日コードベースに居座る。

ここにループエンジニアリングで最も重要な直感がある。 ミスのコストは、それが発見されるまでに生き延びたターン数に比例する。 そしてループとは、放っておくとそのターン数を増やす機械である。

ループエンジニアリングが何であるかは、前記事のループエンジニアリングとは何かで扱った。前記事が定義・系譜・導入判断を扱うのに対し、本記事は稼働中のループを点検する設計監査に絞る。この記事の問いは一つだ。 ループをどう組み、どこで壊れ、どう止めるべきか。

1ターンの中で起きている5つの動作¶

1ターンは、単なる「もう一度実行」ではない。 Addy Osmani氏が整理した Loop Engineering の構成を見ると、ループは仕事を見つけ、隔離し、検査し、記録し、次に回す小さな制御系として動く¹。

朝のトリアージループを例にすると流れは具体的だ。スケジュールで起動し、CI失敗・未解決Issue・最近のコミットを読む。対象ごとにワークツリーを切り、片方のエージェントが修正を書き、もう片方がテストやプロジェクト知識に照らして粗を探す。コネクタがPRやチケットを更新し、手に負えないものはinboxに送り、状態ファイルを残す。

この一巡は5つの動作に分けられる。

動作	何をするか	トリアージループでの実装
発見	今ターンの仕事を自分で見つける	CI、Issue、コミットを読む
受け渡し	仕事を切り出し、隔離して渡す	項目ごとにワークツリーを切る
検証	別の視点を差し込んでNoと言う	評価役がテストと仕様に照らす
記録	会話の外に状態を書く	PR、inbox、状態ファイルを残す
スケジュール	翌ターンへ自動で回す	タイマーやイベントで起動する

発見はループ全体の品質の上限を決める。価値のない仕事を拾えば、残り4つをどれだけ丁寧にこなしても無駄になる。検証は唯一Noと言える動作で、最も手を抜きやすく、最も抜いてはいけない。

スケジュールこそが、1回の実行をループに変える。 1回走らせて終わりなら、それはループではなくバッチ処理だ。

6つの部品が動作を支える¶

動作が「何が起きるか」なら、部品は「回すために手元に要るもの」である。 Osmani氏の整理では、ループには5つの部品と、会話の外に残るメモリが必要になる¹。

部品	何か	対応する動作
オートメーション	スケジュールやイベントで起動する仕組み	スケジュール
ワークツリー	並列エージェント用の隔離ディレクトリ	受け渡し
スキル	単一ファイルに固定したプロジェクト知識	発見
コネクタ	MCP（Model Context Protocol）などで外部システムに繋ぐ口	記録、発見
サブエージェント	生成役と判定役の分離	検証
メモリ	ディスク上に残る永続状態	記録

取り違えやすいのが、メモリとコンテキストの違いだ。 コンテキストはエージェントがそのターンに見ているもので、リフレッシュで流される。 メモリはターンや日をまたいで残る。

ループが今日、昨日の続きから始められるのは、結果がマークダウン、Issue、ボード、PRに書かれて残っているからだ。エージェントは忘れるが、リポジトリは忘れない。

動作を1つ抜くと5つの壊れ方になる¶

ループの壊れ方は、5つの動作と一対一で対応する。動作を1つ抜くと、固有のアンチパターンになる。

型	抜けた動作	症状	処方箋
うなずきループ	検証	何百ターン回って一度もNoが出ない	生成と評価を分離する
健忘ループ	記録	毎朝、同じ地点から始まる	ディスク上の状態ファイルを持つ
手動ループ	スケジュール	最後の実行がデモした日のまま	本物のタイマーかイベントで起動する
盲目ループ	発見	朝、何をやらせるか人間が決めている	発見ロジックをスキルに落とす
もつれループ	受け渡し	並列実行で初めて衝突が露見する	タスクごとに1ワークツリーを切る

最も多いのが、うなずきループだ。ループは走り、エージェントがコードを書き、同じエージェントが「良い」と宣言する。独立したチェックがないため、もっともらしいミスが機械の速さで積み上がる。

症状は明快である。何百ターンも回って一度もNoが出ないなら、本物の検査は存在しない。前記事で紹介した「PR監視ループが1日で43コミットを生成し、ほぼすべて却下された」実例は、この型の典型だった⁶。

残る4つも読みやすい。健忘ループは結果がコンテキストにしか残らず、翌ターンが同じ仕事を再発見する。手動ループは起動を人間に頼り、やがて忘れられる。盲目ループは毎朝、人間が仕事を手渡す。もつれループは同じ作業ディレクトリを複数エージェントが書き換える。

実務で怖いのは、これらが独立していないことだ。検証を欠くループは記録も欠きがちで、一つのチェックに無頓着なチームはたいてい全部に無頓着である。

Noと言える検証をどう作るか¶

生成役に自己採点させると甘くなる。 AnthropicのPrithvi Rajasekaran氏は、長時間アプリケーション開発ハーネスの実験で、エージェントに自分の出力を評価させると、品質が凡庸でも自信を持って褒めがちだと観測している²。

これは賢さの問題ではない。自分の宿題を自分で採点しているだけだ。コードを書いた文脈には「なぜそう書いたか」の理由が詰まっているので、出力を見ても結果ではなく、そこに至った自己説得の連鎖が見えてしまう。

効くのは、生成役を自己批判的にすることではない。 別のエージェントを懐疑的な評価役に仕立てることだ。 Anthropicのハーネスは、GAN（生成的敵対ネットワーク）の発想から、planner、generator、evaluatorの3エージェント構成へ発展している²。

評価役が読むだけでは「正しく見えるか」しか判断できない。フロントエンドでは、評価役にPlaywright MCPを渡し、ページを開かせ、クリックさせ、スクリーンショットを撮らせ、DOMを検査させる。判断の根拠を「このJSXは正しそうだ」から「ボタンを押したら遷移した」に移すためだ。

評価役の指示は短くてよい。

File: .claude/agents/reviewer.md
役割: 敵対的なコードレビュアー。
前提: このコードは証明されるまで壊れている。
褒めるな。何が失敗するかを探せ。
順に確認する:
1. 読む前に実行する。
2. テストを走らせ、出力を貼る。
3. 著者が飛ばしたエッジケースを探す。
4. チケットと実挙動を照合する。
UIならPlaywright MCPで開き、押し、撮り、DOMを見る。
判定はPASSか、REJECTと理由に限定する。

Claude Codeの/goalは、この発想を停止条件に寄せて部品化している。完了条件を与えると、Claudeは各ターン後に小型で速いモデルで条件成立を判定し、満たさなければ次のターンへ進む³。作業した本人とは別の判定器が停止を決める点が重要だ。

Codex側の/goalも、継続テンプレートと予算到達テンプレートで、objective、token budget、証拠ベースの完了監査、budget-limited時のふるまいを分けている⁴。詳しくは/goal解説記事で扱った。ここでは、条件達成まで走らせる/goalと、一定間隔で再実行する/loopを混同しないことだけ押さえればよい。

生成と評価の分離にはコストがある。 Anthropicの実験では、単一エージェント20分・9ドルに対し、フルハーネスは6時間・200ドルで、コストは20倍超だった²。だからこそ、これは品質が要る仕事に対して選ぶ構造だ。

ループの床を決めるのは評価役である。 生成役の水準が「何を作れるか」を決め、評価役の水準が「何を世に出さないか」を決める。

Stripeの週1,300 PRは何に支えられているか¶

エンタープライズ規模の実例として見るべきは、Stripeの社内エージェント「Minions」だ。 Steve Kaliski氏の解説によれば、MinionsはSlackリアクションから開発作業を起動し、週およそ1,300件のPRを出している⁵。人間はコードを書かず、レビュー側に残る。

直感に反するのは、信頼性の説明がモデル名では終わらないことだ。 MinionsはOSSのエージェントハーネスGooseをStripe向けにフォークし、社内ツール、コード検索、テスト、クラウド開発環境とつなげている⁵。鍵は、モデルが起きる前の段にある。

エージェントが動き出す前に、Slackの文脈、対象リポジトリ、コード検索、社内ドキュメント、チケットから作業文脈を組み立てる。 LLM（Large Language Model）に何もかも探させる部分ほど制御しづらい。ここから引ける設計原則は単純だ。 決定論的にできる作業は、確率的モデルに渡さない。

クラウドの使い捨て開発環境も大きい。各Minionは新しいブランチと環境で走り、並列に隔離された変更を作る。 CI、テストカバレッジ、ブルーグリーンデプロイが安全弁になり、最後に人間のレビューが残る⁵。

人間は去ったのではない。机を移しただけだ。書く側からレビューする側へ。

静かに溜まる4つの負債¶

自走するループは、同時に自走でミスをするループでもある。実行中にアラームを鳴らさない負債が4つ溜まる。

検証負債: 独立検証されない出力がコードベースに残る
理解の腐敗: 人間のメンタルモデルが変更量に追いつかない
認知の明け渡し: 滑らかに回るほど、人間が読まなくなる
トークン暴騰: リトライとサブエージェント生成で請求が膨らむ

冒頭の20件のPRで考えると見えやすい。 3件の埋もれたバグがマージされるのが検証負債だ。人間が20件を読まずに承認すると、理解の腐敗が起きる。翌朝のバッチを読まなくなれば認知を明け渡している。夜通しヘルパーを生んでリトライすれば請求は膨らむ。

4つは独立したリスク一覧ではない。一つの失敗が4つの顔で現れ、互いを強め合う。検証されない出力が増えるほど人間の理解は遅れ、理解が遅れるほど判断を明け渡し、見られないループほど長く走る。

運用の規律は3つに集約できる¶

理解の腐敗への防御は、ループの出力を全部読むことではない。それでは自動化の意味がない。 代表サンプルを毎日読み、各変更を「何をなぜそうしたか」自分の言葉で説明できるか確かめる。

説明できない変更は、メンタルマップがコードベースに遅れたシグナルだ。本番障害でそれに気づくより、静かな朝にサンプルPRで気づくほうが安い。

トークン暴騰への防御は、最初に硬い上限を切ることだ。 1回あたりの予算、日次予算、最大リトライ回数を、最初の驚くべき請求が来る前に設定する。これは節約ではなく回路遮断器である。

認知の明け渡しへの防御は、気持ちの問題ではなく構造の問題だ。ループの中に、人間のために一時停止する地点を最低1つ作る。人間が常に介入するからではなく、介入できる立場に人間を留めるためだ。

最初のループを今日組む¶

Stripeのパイプラインは到達点であって、出発点ではない。最初のループは、タイマーで何かを確認するだけの小さなものでよい。次は実行可能なGitHub Actionsではなく、最初に決める項目を示した設計用の擬似YAMLである。

trigger: "毎朝6時"
discovery: "CI失敗と未解決Issueを読む"
isolation: "項目ごとにworktreeを作る"
verification: "テストとlintが通るまで評価する"
persistence: "結果をPRと状態ファイルに残す"
human_gate: "自動マージせずレビューを待つ"

この短い設計票でも、部品の抜けを確認できる。実装時は、スケジュール、スキル、ワークツリー、/goalなど、利用する製品の正式な機能へ各項目を割り当てる。

実装前のチェックリストは次の6つだ。

要素	自問
発見の入口	タイマーで何を読むか。CI、Issue、コミット、inboxのどれか
状態ファイル	ターンをまたぐ記憶は、どのディスクファイルが持つか
評価役	Noと言える独立したチェックはあるか
隔離	並列エージェントは各々ワークツリーを持つか
トークン上限	支出の上限を切ったか。暴走したら誰が止めるか
人間のレビュー	どのステップが最後まで自動で進まず、人間のために止まるか

安全に育てる順序は、並列化を最後に回すことだ。並列で何件こなすかを増やす前に、何を発見するかを増やす。多数のエージェントを束ねる前に、評価役が本物のミスを捕まえることを証明する。

まとめ¶

ループは生成をほぼ無料にする。コード、計画、PR、修正が安く出てくる。希少なまま残るのは判断だ。

どの計画が正しいか。どの行を止めるべきか。動くが根本で間違っている出力はどれか。ループは百の選択肢を生めるが、真に選ぶことはできない。

同じ道具が、2種類のエンジニアの差を広げる。価値が機械的労働にあった人は、それが蒸発するのを見る。価値が判断にあった人は、それが百倍に増幅されるのを見る。 ループは平等に持ち上げない。各人が持ち込んだものを掛け算する。

増幅器は両刃だ。判断のミスもまた、忠実に、大量に、百回実行される。昔の世界では、悪い判断は手書きの一区画ぶんのコストで済んだ。新しい世界では、悪い判断は止まって問い直すことのない機械によって、そのまま実行される。

ループを作ること自体は、もう難しくない。難しいのは、作ったループに対して、設計者が何の判断を持ち続けるかを先に決めておくことだ。ループは設計者を忠実に掛け算する。理解を持ち込めば理解を、怠惰を持ち込めば怠惰を。