最近話題沸騰の Loop Engineering とは結局何なのか

四つの層の最上段に立つ

これらの「XX エンジニアリング」は互いに取って代わるものではなく、一層ずつ積み重なっている。各層が扱うものは下の層より一回り大きい。一文から、一つのコンテキストウィンドウへ、一回の実行へ、最後は自分で回り続けるループへ。各層をクリックして、何を担い、エラー時にどれだけ大きく弾けるか見てほしい。

同じ一つのバグ（agent がある関数の戻り値を誤読した）を四つの層に置いて見よう。上に行くほど、発覚は遅く、代価は大きい。ループ層になると、この誤読は state file に書き込まれ、翌日に事実として読み戻され、それに沿って一層ずつ積み上げられ、誰かが見に行く頃には、その誤った前提はもう耐力壁になっている。

これがループエンジニアリングで最も覚えておくべき直感だ。誤りの代価は、それが人に発覚するまで生き延びたラウンド数に等しい。そしてループは構造上「ラウンド数を最大化する」機械なのだ。後に出てくるものすべて——evaluator、人手の関門、予算上限——存在する唯一の目的は、「ミスをする」から「発覚する」までの距離を縮めることにある。

一周五ステップ、どれが欠けても決まった形で壊れる

「ループ」を空転と取り違えてはいけない。各ラウンドで具体的なことをやる。やる価値のある仕事を見つけ、agent に渡し、正しいか検証し、状態を保存し、次の一手を決める。五ステップのどれが欠けても、ループは回らないか、その場で空回りするか、しかも名前のついた形で壊れる。

以下では Osmani が自分で組んだ「朝の triage ループ」を例に、各ステップが何をやるか、そしてそれを飛ばすとどのループに変わるかを順に見ていく。

この五ステップは選べるチェックリストではなく、互いに依存し合う一つの全体だ。規律のあるチームは五ステップ全部を装着する。慌てたチームは前二ステップ（発見＋受渡）だけ装着する。この二つは目に見える出力を生むからだ。後の三ステップが生むのは「安全」で、最も省かれやすい。

ループを組むには、六つの部品を揃える

五ステップは「一ラウンドで何が起きるか」、六つの部品は「回すには手元に何が要るか」を語る。両者は一対一で対応する。発見は skills、受渡は worktrees、検証は sub-agents、永続化は memory、定期実行は automations に頼る。各カードをクリックして、何を解決するか見てほしい。

六つの部品が揃えば、ループは骨格を得る。自動化が動かし、worktree が共食いを防ぎ、skill が重複労働を避けさせ、connector が外を見させ、sub-agent が自己修正させ、memory が記憶させる。だが骨格を組むのは始まりにすぎない。同じこの六つの部品で、二人が正反対のものを組み上げられる。これが最後の節の話だ。

最難関のステップ：なぜ AI に自分を採点させてはいけないか

ループの最難関は、agent を走らせることでは決してない。その中に「ノー」と言えるものを一つ置くことだ。そしてコードを書いたその agent こそ、最も「ノー」と言いそうにない者なのだ。

② 解法は作者を変えることではなく、審判を替えることだ。generator をより自己批判的に調整する、この道は通じない。作者に自分の視点から飛び出せと要求することはできない。できるのは、別の独立した agent を立てることだ。ゼロからコードを見て、まったく異なる指示を持ち、自己説得を一切まとっていない。独立した懐疑者を調整する方が、作者を自己批判的にするよりずっと容易だ。発想は GAN（敵対的生成ネットワーク）から来ている。一つのネットワークが造り、一つが粗探しする。コードに移せば、一つが書き、一つが審査する。

③ コードを読むだけでは足りない、実際に手を動かす。evaluator がコードを読むだけなら、判定するのは「これが正しく見えるか」であって「これが正しく動くか」ではない。フロントエンドのタスクで、Rajasekaran は evaluator を Playwright MCP につなぎ、QA のように実際にページを開き、ボタンを押し、スクリーンショットを撮り、DOM を検査させた。判断の根拠は「この JSX は問題なさそう」から「ボタンを押したら、ページが遷移した、スクショはこれ」に変わる。ついでに下層のモデルも替える。同じモデルに指示だけ替えても、しばしば同じ盲点を引きずる。コミュニティでよく使われる一つのキャリブレーション：evaluator に、コードは壊れている前提で、そうでないと証明されるまで疑わせる。デフォルトの立場は信頼ではなく懐疑であるべきだ。

④ maker-checker：最後の一打を誰が下すか。Claude Code は /goal でこの構造を一つの原語にした。条件を一つ与え、条件が満たされるまで走らせる。肝心なのは、各ラウンドの終わりに、条件が達成されたかを真新しい小型で高速なモデルが判定すること。作業中のそのモデルではない。これは銀行で何十年も使われてきた maker-checker の原則だ。

evaluator を設定に落とすとこうなる。その一行一行が上の四つを実行している。役割を替え、壊れている前提、手を動かして検証、理由を逐条述べる。

ROLE: Adversarial code reviewer.（敵対的レビュアー）
ASSUME: this code is BROKEN until proven otherwise.
       # コードは壊れている前提、反証されるまで
DO NOT praise. Find what fails.  # 褒めるな、どこが壊れるかだけ探せ

CHECK, in order:        # 順番にチェック
  1. Does it run? (execute, don't read)   # 動くか:実行する、読むだけにするな
  2. Tests: run them, paste real output.  # テストを走らせ、実際の出力を貼れ
  3. Edge cases the author skipped.       # 作者が飛ばした境界ケース
  4. Does behavior match the ticket?      # 挙動がチケットと一致するか

USE Playwright MCP: open the page, click,
    screenshot, inspect the DOM. Judge behavior, not intent.

VERDICT: PASS only if every check holds.
         Otherwise REJECT + list each reason.
         # 全て通って初めて PASS、さもなくば REJECT し理由を一つずつ列挙

/goal all tests in test/auth pass and the lint step is clean
# 「test/auth が全て通り、かつ lint がクリーン」になるまで走る
# 注意：/goal は条件が満たされるまで走る、/loop（一定間隔で再実行）とは別物

ループの下限は、その evaluator が決める。generator の水準はループが何を生み出せるかを決め、evaluator の水準はそれが何を生み出さないかを決める。生成と評判を構造上分け、evaluator を懐疑者に調整し、手を動かして検証させ、最後の一打を真新しいモデルに委ねる。この四ステップを合わせて初めて、ループに「ノーと言える」能力が育つ。

一人の朝と、Stripe の毎週 1300 個の PR

二つの本物のループ。規模は極端に違うが、骨格は同じだ。一つのトリガーが開始を押し、一群の制約がそれを軌道に縛り、末尾に一つの人手の関門が座る。「あなたが眠っている間に走れる」は、モデルがどれだけ強いかではなく、この骨格がどれだけ安定しているかだ。

Stripe の最も直感に反する点：Minions はより強いモデルの上に建てられていない。オープンソースツール Goose の一つの fork だ。その核心の主張は、信頼性は制約の質から来るもので、モデルの大きさからではない、ということ。アーキテクチャ上、決定論的な関門（青）と創造性のある LLM ステップ（緑）が噛み合い交互に並ぶ。確定したロジックで解けることは、決して確率モデルに委ねない。この線をどこに引くかが、ループが信頼できるか否かを決める。（この実例は Stripe エンジニアの Steve Kaliski が How I AI ポッドキャストで明かした。）

「あなたが眠っている間に走る」は結局何に頼るのか

ローカルの /loop もデスクトップの定時タスクも、マシンを起動しておく必要があり、電源を切れば止まる。マシンを切っても走らせるなら、正解は Cloud Routines か GitHub Actions の定時トリガーだ。三つの方式がそれぞれ一区間を担う。

要点はどれが良いか選ぶことではなく、この二つは別の能力だと理解することにある。ローカル定期実行 =「私がいる間に何ラウンドか多く走らせる」、クラウド定期実行 =「私がいない間も走らせる」。ローカル再実行を「無人運転」の全部だと思い込むのが、最もよくある誤解だ。ノートパソコンの蓋を閉じれば、自律だと思っていたそのループは静かに止まる。成熟したループはしばしば両方を使う。ローカルが身近で緊密なチェックを担い、クラウドが夜通しの全体スキャンを担う。

ステップ・バイ・ステップ：最初のループを組む

Stripe のあのパイプラインは終点であって、起点ではない。最初のループは、ほとんどシステムに見えないほど小さくあるべきだ。時間が来れば何かを見に行く小さな代物。以下の五ステップはそのまま真似でき、各ステップにコマンドと設定が付き、最後に六要素を揃えた最小の完全なループになる。

① /loop を一つ起こす

v2.1.72 以降で使える。同じ一つのタスクを間隔で再実行する。スコープは session、繰り返しタスクは 7 日後に期限切れ、自マシンで走り、電源を切れば止まる。三つの使い方：

/loop 5m check the deploy   # 固定:5 分ごとに一回
/loop check the deploy      # agent が自分でペースを決める
/loop                       # .claude/loop.md のタスクを読む

② skill で自動発見：まず triage

一行を再実行するだけではループとは言えない。プロンプトを与え、毎朝三つのものを見て、対処する価値のあるものを列挙させる。「定時 + 自動発見」で初めてループの入門だ。発見のロジックは skill に書くこと、スケジュールに書かないこと。cron job の指示は誰も更新せず腐っていく。SKILL.md は保守でき、再利用できる。

NAME: morning-triage
WHEN: invoked each morning by automation.
      # 毎朝 automation から呼び出される
READ:
  - CI runs that failed since yesterday   # 昨日から落ちている CI
  - issues opened in the last 24h         # 過去 24 時間に開かれた issue
  - commits merged since the last run      # 前回実行後にマージされた commit
JUDGE: for each item, is it worth acting on?
       Skip noise. Keep only actionable findings.
       # 一つずつ判断:対応する価値があるかノイズか? 着手できるものだけ残す
OUTPUT: write findings + status to
        ./state/triage.md (one row per finding).
        # ./state/triage.md に書く、1 件 1 行

③ state ファイルを一つ加える

結果をチャット窓に残すな。発見ごと、どこまで処理したかを、一つの markdown ファイル（または一枚の Linear かんばん）に書く。agent は忘れるが、repo は忘れない。

| finding         | source    | status   |
|-----------------|-----------|----------|
| auth test flaky | CI #4821  | fixing   |
| null deref      | issue 92  | PR open  |
| stale dep       | commit a3 | inbox    |

④ /goal 評価器を加える

最も肝心で、最も飛ばされやすいステップ。/goal（v2.1.139 以降）は一つの条件が満たされるまで走り、条件が達成されたかを別のモデルが判定する。/loop とは違うことに注意：/loop は一定間隔で再実行、/goal は達成まで走り、停止条件を真新しい小型モデルが判定する。前節の reviewer.md（コードは壊れている前提、手を動かして検証、理由を逐条述べる）を添えて、各ラウンドで粗探しさせる。

/goal all tests in test/auth pass and the lint step is clean
# 「test/auth が全て通り、かつ lint がクリーン」になるまで走る、真新しい小型モデルが判定

⑤ --worktree で並行分離を加える

--worktree（または -w）で各バックグラウンド agent に独立した worktree を開く。一つの worktree に一つのタスク、複数の agent が同時にコードを書いてもファイルを取り合わない。

claude --worktree fix/auth-test  "draft the fix"
claude --worktree fix/null-deref "draft the fix"

最初のループの六要素チェックリスト

チェックして、自分が揃えたか見てほしい。前二つが回るか否かを決め、後四つが回り始めて問題が起きても誰も見ないか否かを決める。初心者が最もよくやる誤りは、前二つだけ装着すること。結果は、誰も見ず、誰も止められず、しかも自分にうなずき続けるループだ。

六要素を揃えた最小のループ

チェックリストをコードに落とす。下のこの一段は、一息で読み切れるほど小さいが、本物のループに必要な器官をすべて備えている。ただ縮小しただけだ。六つのコメントが六要素と一対一で対応する。

# 1. 定期実行 ， 本物のトリガー一つ
on:
  schedule:
    - cron: '0 6 * * *'   # 毎日 06:00、クラウドで走る

# 2. 発見 ， 一つの skill を呼ぶ、指示の塊ではなく
run: claude --skill morning-triage

# 3. 永続化 ， 状態をディスクに
#    skill が ./state/triage.md を書き repo に commit

# 4. 受渡 + 検証 ， 発見ごとに worktree 一つ、達成まで走る
for finding in $(parse ./state/triage.md); do
  claude --worktree "fix/$finding" \
    --goal "tests pass and lint is clean" \
    "draft a fix for $finding"
done

# 5. 検証 ， 各ラウンド後に真新しいモデルが stop を判定、
#    さらに reviewer agent が専ら粗探し

# 6. 人間 review ， 残しておくその扉
#    PR は開くだけで自動マージしない;判断に迷うものは ./inbox/ へ

六つすべて揃えば、どんなに小さくても本物のループだ。どれか一つでも欠ければ、それは前節の五つの失敗のどれかが、装いを変えただけのものになる。最初のループは小さい方がいいが、「ノー」と言うチェックと人間 review の関門だけは満載にしなければならない。

ループはこっそり四つの勘定を記す

自分で走れるループは、同時に自分で間違える能力のあるループでもある。元気に走るほど、静かに間違える。四つの代価がそれが動いている間に静かに積み上がり、どれも当場で警報を鳴らさない。

具体的な場面で四つがどう段階的に発火するか見よう。ループが一晩で 20 個の PR を開き、テストは全緑、表面上は大勝利だ。だがそのうち 3 つに、テストでカバーできない小さなバグが潜んでいる。

埋められたあの 3 つの誤りは、今やあなたが完全には読み解けなくなったコードベースに横たわり、もう見ない人によって「守られて」いる。本番環境でどれか一つが頭をもたげるまで発覚しない。四つの代価は、それぞれ独立したリスクのリストではなく、同じ一つの失敗から生えた四つの顔だ。互いに養い合い、最後に一斉に満期を迎える。

門番の方法はそれぞれ違う。

四つは一つの特徴を共有する。ループが走っている間、それらはすべて静かだ。ループエンジニアリングの最も魅力的な点は、一人にチームの仕事をさせること。最も危険な点も同じところにある。チームは自分で自分と言い争うが、一人にループを山ほど足すと、誰も議論しないエコーチェンバーに容易に変わる。門番は常に人間の判断力だ。

あなたは依然としてエンジニアだ、ボタンを押すだけの人ではない

同じ一つのループを、二人が組めば、正反対の場所へたどり着ける。そして違いはループそのものにはない。

ある人はループを、自分がすでに熟知したことの上でより速く走らせる。彼はコードを読み、方向に確信があり、ループが増幅するのは彼が元々持っていた判断だ。別の人は同じループを、二度と理解しなくて済むように使う。半年後、前者はより強くなり、後者は自分で読み解けない機械の門番になる。

ループは「品質がツールで決まる」たぐいのツールではない。それは強いがゆえに、あなたが持ち込んだものをそのまま増幅する。理解を持って臨めば理解を増幅し、怠惰を持って臨めば怠惰を増幅する。それは忠実な掛け算の記号で、掛けられるのはループを組んだその人だ。

ループは生成をほぼ無料にする。コード、計画、PR、修正、ほとんどタダで手に入る。残された希少なものは判断だ。どの計画が正しいか、どの行で止めるべきか、どの出力が走らせれば問題なくとも根本では間違っているかを知ること。ループは百の選択肢を生成できるが、本当に選ぶことはできない。あるいは「もっともらしく見える」基準で選び、「実際に正しい」基準では選ばない。この二つの間の隙間こそ、エンジニアが存在する理由だ。だからループエンジニアリングは判断を切り下げたのではない。判断を要さない仕事をすべて剥ぎ取り、判断を残された唯一のものにしたのだ。エンジニアの価値は、「タイプが速い、API を多く暗記している、ボイラープレートを厭わない」から、「どの道が正しいか、どの行で止めるべきか、どの出力が走らせれば正しくとも根本では間違っているかを知る」へ移った。

build the loop, but build it like someone who intends to stay the engineer, not just the person who presses go.Addy Osmani『Loop Engineering』2026 年 6 月