元記事は英語の長文記事「CLAUDE LOOP ENGINEERING: HOW TO BUILD AN AGENT THAT WORKS WHILE YOU SLEEP」。
主張をひとことで言うと、エージェントに自分でプロンプトを打つのをやめ、エージェントにプロンプトを打つ「仕組み（ループ）」を作る側に回れ。そのループは、きっかけ（トリガー）で起動し、隔離した作業場所で作業し、別のエージェントが悪い出力を差し戻し、結果をディスクに書き、翌日は止まったところから再開する。
この文書の範囲: 以下は記事本文（テキスト 186 ブロック）の日本語要約です。記事中の画像（図・表、12 枚）は取得していないため、図にしか書かれていない内容（冒頭の「60 秒版」、4 種類のループの比較表、4 つの請求書の図、最後の総まとめ表など）は含まれていません。
記事中の人物の発言・数値（Karpathy の 700 実験、Stripe の週 1,300 PR など）は記事の主張をそのまま要約したもので、一次情報での裏取りはしていません。
プロンプト → コンテキスト → ハーネス → ループの 4 層は置き換えではなく積み重なる。上の層ほど扱う単位が大きく（1 文 → 1 窓 → 1 回の実行 → 人なしで回り続ける仕組み）、下 3 層は人がキーボードの前にいる前提、ループはその前提を外す。
層を分ける実用上の理由は、壊れ方が表に出るまでの時間が層ごとに違うこと。悪いプロンプトは数秒で分かるが、悪いループは午前 3 時にコードを変え、その誤りを次の実行に食わせ、1 週間誰も気づかない。
「プロンプトは 1 回の標本、ループは制御装置」。動くループには必ず次の 5 部品がある。
| 部品 | 中身 | 無いとどうなるか |
|---|---|---|
| トリガー | 何が 1 回の実行を始めるか（メッセージ・時計・イベント・Webhook） | 人間が時計役のまま |
| 作業 | 文脈を集め、行動し、結果を読む | — |
| ゲート | 好みを持たずに出力を却下できるもの（テスト・ビルド・型検査・リンターの終了コード） | エージェントが毎回、自分に甘い自己レビューをする |
| 状態 | 会話の外にあるファイル。何が済んで次に何をやるか | 明日がゼロから始まる |
| 停止 | 終了条件と、条件が来ないときの上限 | 人が気づくまでお金を使い続ける |
1 周の順番は 見つける → 隔離した作業場所のエージェントに渡す → 別の指示を持つ 2 体目が壊しにかかる → 結果をディスクに残す → 次回を予約し、残りを持ち越す。どれか 1 つを抜くと、止まるか空回りする。
「何が始めるか」「何が終わらせるか」の 2 問で分類する。
| 種類 | 使うもの | 要点 |
|---|---|---|
| ターン制 | 普段の対話 ＋ SKILL.md | 検証手順を SKILL.md に書くと、編集が通った時点で止まらずレビュアーのように確認する。手順が測れるほど、早仕舞いの言い訳の余地が減る |
| ゴール制 | /goal | 毎ターン後に小さく速いモデルが会話記録を読み、「達成したか」を yes/no と 1 行の理由で返す。その理由が次ターンの指針になる |
| 時間制 | /loop・/schedule | /loop は自分のマシン上、/schedule は同じ形をクラウドのルーティンに移し、PC を閉じても回る |
| 能動型 | 全部を重ねたもの | クラウドのトリガー・明示された完了条件・隔離された並列作業場所・新しい文脈で来るレビュアーの 4 つを 1 コマンドに |
/goal の規則（記事の記載）：1 セッション 1 ゴールで、新しいゴールは古いものを置き換える。引数なしの /goal でターン数・トークン・評価者の直近の理由を表示、/goal clear で終了。条件は 4,000 文字まで。評価者は自分では何も実行しないので、Claude が会話に出したものしか判定できない。だから「test/auth の全テストが通り lint が clean」は 20 ターン持つが、「コードがきれい」は 1 ターン目で崩れる。
⚠️ よくある混同：/loop はタイマーで繰り返す、/goal は条件が成り立つまで続ける。予約と停止は別の仕事で、壊れたループの多くはこの 2 つを混ぜている。
/goal はこれを製品の機能にしたもの：作業に関わっていない新しいモデルが完了を決める。銀行の「大口送金の入力者と承認者は別人」と同じ原則先に元が取れるのは地味なもの：CI 失敗の仕分け、依存更新 PR、lint 修正、不安定テストの再現、テストが実在する範囲での issue → PR 下書き。
手作業に残すべきはワクワクする方：アーキテクチャの書き直し、認証と決済、本番デプロイ、曖昧なプロダクト仕事、「完了」を誰かが判断する必要のあるもの。
「レビューの処理能力がもともと天井なら、ループは待ち行列を短くせず長くする」。
/loop、無人で任せられると確信したら /schedule.claude/agents/ に独自の指示を持つ 2 体目、できれば別モデルローカルのループは PC の蓋を閉じた瞬間に止まる。開発サーバーを毎分見張るなら /loop しかない。午前 3 時に issue を見て PR を開くなら、クラウドのルーティンか GitHub Actions の予約実行。
「ローカル予約＝自分がいる間にあと数周」「クラウド予約＝自分がいない間に回す」。これを混同するから、自慢されるループの半分は席を立つと止まる。
下の層は普通の cron（5 フィールド、1 分単位）。CLAUDE_CODE_DISABLE_CRON=1 で全体を無効にできる。
本人より先に起きる。仕分けスキルが前日の CI 失敗・未処理 issue・最近のコミットを読み、対応すべき項目ごとに隔離した worktree を開く。1 体が修正を下書きし、2 体目がプロジェクトのテストとスキルでそれを攻撃する。コネクタが PR を開きチケットを更新し、曖昧なものは人間の受信箱へ、残りは状態ファイルで翌日へ。判断が始まるところでちょうど人間に止まる。
Slack でボットをタグ付けするか絵文字を付けるだけで起動。面白いのはモデルが起きる前：決定的なオーケストレーターが先に文脈を組み立てる（メッセージ内のリンク、Jira、ドキュメント、Sourcegraph と MCP でのコード検索）。書き終えたら、エージェントが迂回できないハードコードのパイプラインで lint を通す。学び 3 つ：
⚠️ 記事自身の注意書き：「Claude Code の 90% は自分で書かれている」のような見出しの数字はほぼ又聞き。Anthropic 自身の「マージ率 8 倍」も、会社自ら「実際の効果の過大評価であることはほぼ確実」と添えている。上の 2 例は当事者の一次情報に遡れるので、推論の材料にする価値がある。
| 請求 | 中身 |
|---|---|
| 検証の負債 | Geoffrey Huntley が名付けた「Ralph Wiggum ループ」：半分しか終わっていないのに完了シグナルを出し、満足して終わる。治療は意見を持たないゲート（コンパイルが通るか、終了コードが 0 か）。意見を持つレビュアーはいずれ自分を説得して承認する |
| 理解の腐敗 | ループが直せないバグが、一度も開いたことのないファイルに埋まっている朝に初めて気づく。自分のプロジェクトの「訪問者」になっている |
| 認知的な降伏 | 上 2 つの下にある坂。安定して回るほど信頼し、見なくなり、判断できなくなる。頻繁に覆す必要はないが、「これは違う」と言える力は保つ |
| トークンの暴発 | 書いたのはロジックでも、払うのは実行回数×単価。一晩空回りするバグは修正ではなく請求書になる |
その下にセキュリティの勘定もある：生成コードは誰かが読むより速くマージされるので、SAST・依存関係監査・シークレット走査をゲートに入れる。自動導入のコミュニティスキルは説明文に書かれたものを持ち込む（17,022 個のスキルを監査したら 520 個が認証情報を漏らしていた、という記事の記載）。長時間実行の冗長ログは誰も見ないログに秘密を撒く。「今回だけ」足した書き込み権限は、カレンダーに入れない限り二度と見直されない。
「1 人でチームの仕事ができる」が最大の魅力で、リスクも同じ場所にある。チームは内部で議論するが、1 人＋ループの山は全員が同意する部屋になる。
受け入れられた変更 1 件あたりのコスト。トークン消費・PR 数・予約ループ数は進捗に見えるが測っていない。ループの変更のうちレビューを生き残るのが半分未満なら、ループが消すはずだったレビュー作業を自分でやっている。
材料：/usage（スキル・サブエージェント・MCP 別の最近の消費）、引数なしの /goal（現在のゴールのターンとトークン）、/workflows（エージェント別の使用量と途中停止）。
売り手が言わないこと：一般向けプランで重い検証を本気の仕事に回すと、支出は効果より数週間早く現れる。だから「1 つの繰り返し仕事に 1 本だけ作り、その結果に予算を主張させる」。
生成はほぼ無料になり希少でなくなった。希少なのは判断。ループは 100 案を出して 1 つ選ぶこともできるが、選ぶ基準は「正しい」ではなく「もっともらしい」。その差が、この仕事がまだ存在する理由。
毎朝習慣で開いている仕事、新人に「毎日見るだけでいいから」と説明する仕事を選び、最初に渡せる 1 片を決める。
| 問い | はいなら |
|---|---|
| その仕事の確認方法を書き出せるか | スキルにする |
| 「終わった」の姿を正確に言えるか | /goal にする |
| 仕事が自分からではなく時計でやってくるか | /loop、のちに /schedule |
| どれもまだ | まず手動で 1 回を安定させる |
1 本作り、どこで止まり、どこで踏み込みすぎるかを見て締め、それから 2 本目。
同じループを作った 2 人が半年後に正反対の場所にいることがある。1 人は理解している仕事を速く進めるのに使い、ループは判断力を掛け算した。もう 1 人は理解しなくて済むように使い、ループはそれを掛け算した。ループは掛け算の記号で、あなたがその数。押すだけの人ではなく、エンジニアであり続けるつもりで作れ、と締めている。
要点を 5 行で
/loop（時間で繰り返す）と /goal（条件まで続ける）は別物。ローカルは席にいる間だけ、無人ならクラウド