これはこの四層の一番上に立つ

これら「〇〇エンジニアリング」は互いを置き換えるものではなく、層が積み重なっている。各層が扱う対象は下の層より一回り大きい。一言のプロンプトから、コンテキストウィンドウ一つ、実行一回、そして最後に自分で回り続けるループへ。各層を開いて、それが何を扱い、失敗したときにどれだけ被害が広がるかを見てみよう。

同じバグ（agent がある関数の戻り値を誤読した）を四つの層に置いて見てみよう。上の層に行くほど、発見が遅れ、代償が大きくなる。ループ層まで来ると、この誤読は state file に書き込まれ、翌日には事実として読み戻され、それを土台に層を重ねて積み上げていく。誰かが気づいて見に行くころには、その誤った前提はすでに構造を支える壁になっている。

これがループエンジニアリングで最も覚えておくべき直感だ。誤りの代償は、それが人に発見されるまでに生き延びた周回数に等しい。そしてループは構造上、「周回数を最大化する」機械なのだ。この先に出てくるすべてのもの——evaluator、人手によるチェックポイント、予算上限——が存在する唯一の目的は、「間違いを犯す」ことから「発見される」ことまでの距離を縮めることにある。

一周回は五つのステップ、どれを欠いても決まったパターンで壊れる

「ループ」を空回りと誤解しないでほしい。毎周回、具体的な仕事をこなす。やる価値のある仕事を見つけ、agent に渡し、正しいか検証し、状態を保存し、次の一手を決める。五つのうちどれか一つでも欠けると、ループは回らないか、その場で空転するかのどちらかになり、しかも決まった名前を持つパターンで壊れる。

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

この五つのステップは選択式のチェックリストではなく、互いに依存し合う一つの全体だ。規律のあるチームは五つとも実装する。急いでいるチームは最初の二つ（発見＋引き渡し）しか実装しない。この二つは目に見える成果を生むが、残り三つが生むのは「安全」であり、最も省かれやすい部分だからだ。

ループを組み立てるには、六つの部品を揃える必要がある

五つのステップが語るのは「一周回で何が起きるか」、六つの部品が語るのは「回すために手元に何が必要か」だ。両者は一対一で対応する：発見は skills、引き渡しは worktrees、検証は sub-agents、永続化は memory、スケジューリングは automations が担う。各カードを開いて、それぞれが何を解決するのか見てみよう。

六つの部品が揃えば、ループは骨格を得る。automation がそれを動かし、worktree が自滅的な衝突を防ぎ、skill が同じ労働の繰り返しを防ぎ、connector が外の世界を見せ、sub-agent が自己修正させ、memory が記憶させる。だが骨格を組み上げるのはまだ始まりにすぎない。同じ六つの部品からでも、二人の人間はまったく正反対のものを組み立てられる——それが最後の節のテーマだ。

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

ループで一番難しいのは、agent を走らせることでは決してなく、その中に「NO」と言えるものを組み込むことだ。そしてコードを書いたその agent こそ、最も「NO」と言いそうにない存在なのである。

② 解決策は作者を変えることではなく、審判を交代させることだ。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 を懐疑者として調整し、実際に手を動かして検証させ、最後の一撃をまったく新しいモデルに委ねる——この四つが合わさって初めて、ループに「NO と言う」力が宿る。

ある人の朝と、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/ へ

六つすべてが揃っていれば、どれだけ小さくても本物のループだ。どれか一つでも欠ければ、それは前節で見た五つの失敗パターンのどれかが、姿を変えて現れたにすぎない。最初のループは小さいほうがいいが、「NO」と言えるチェックと人手による 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 月

2026 年 6 月の同じ週、Google Chrome の Addy Osmani、Anthropic の Boris Cherny、OpenClaw の作者 Peter Steinberger がそれぞれ同じことに行き着き、Osmani がそれに名前を付けた。あなたは「AI を操作する人」から「AI を駆動するシステムを設計する人」に変わる。あなたが書くのはもう AI へ送る言葉ではなく、AI へ自動的に言葉を送り続ける仕組みそのものだ。

メリットは、一人でチーム分の仕事をこなせることだ。あなたが寝ている間も回り続ける。しかし自分で回り続けられるループは、自分で間違えることもできる。楽しげに走れば走るほど、その誤りは静かになる。特に最も難しく、最も省略されやすいあのステップ——検証において。

ループが一周するのは五つのステップだ：やるべき仕事を発見する → AI に引き渡してやらせる → 独立して正しいか検証する → 進捗を保存する → 時間が来たら自動でまた走る。どれか一つでも欠ければ、ループは回らないか、その場で空転する。

どのステップを欠くかによって、対応する壊れ方をする：検証を欠くと → 頷きループ（自分で自分を承認する）、永続化を欠くと → 記憶喪失ループ（毎日ゼロからやり直す）、スケジューリングを欠くと → 手動ループ（デモが終わったら誰も走らせない）、発見を欠くと → 盲目ループ（結局あなたが仕事を割り振る羽目になる）、引き渡しを欠くと → もつれループ（複数の AI が並行して改変し合い、めちゃくちゃになる）。

五つのステップの中で最も難しく、最もよく省略されるのが検証だ。しかもコードを書いたその AI に自分を採点させてはいけない。頭の中は「なぜこう書いたか」という理由でいっぱいで、自画自賛するだけだからだ。独立した AI に交代させ、デフォルトで「コードは壊れている」と仮定し、さらに実際にページを開き、ボタンをクリックし、スクリーンショットを撮る必要がある。コードを読むだけでは足りない。銀行で高額送金の入力と複査が必ず別の二人であるのと同じだ。

このパターンはすでに実際の規模で動いている。Stripe の Minions パイプラインは毎週 1300 件以上の PR（コード変更リクエスト）をマージしており、一行たりとも人手で書かれていない。頼っているのはより強力なモデルではなく、確定的な作業（例えばコードチェックの強制実行）をハードコードし、AI が迂回できないようにすることだ。

ここに挙げた数字はすべて当事者本人（Stripe のエンジニア、Steinberger 本人）による一次情報で、第三者による再現はない。「Claude Code の九割は自分で書いている」といった類の広く流布した話の多くは又聞きの伝聞であり、ざっくりした参考程度に留めておくべきだ。実際に手を動かしたいなら、本文の第 7 節に /loop、/goal、--worktree、SKILL.md の設定、そして最小の完全なループが一式まとめて置いてあるので、そのまま真似できる。