ループエンジニアリング：プロンプトからループへ

この記事では、あなた自身の代わりに作業を実行してくれるプログラム可能なエージェントの作り方に焦点を当てることにしました。これにより、毎朝コンピューターの電源を入れて、何度も同じコマンドを入力する必要がなくなります。

エージェントは自動的に起動し、タスクを自ら見つけ出し、問題を特定し、結果を保存してあなたのデスクに提示します。

はじめに

Loop のアイデアは突然生まれたわけではありません。2026 年 6 月のある週、3 人の業界専門家がほぼ同時に同じ考えを口にしました。それは、このレベルの開発を始める時期が来たということです。

その 1 週間後、Andrew Ng 氏がこの議論を「プロダクトを 0 から 1 へ構築する」というより広い文脈の中に位置づけ、より包括的な全体像を示しました。

この記事はそのストーリーから始まり、その後、スクラッチから最小限でありながら完全な Loop を構築する手順を説明します。5 つの動作、6 つのパーツ、1 つの「ノー」と言うドア、そして 1 つの人間用ドア。すべてあなた自身のマシン上で動作し、あらゆるソフトウェアプロジェクトで再利用可能です。

出典: HuaShu Orange Book, Loop Engineering: Stop Asking Me What It Is (v260615, June 2026)

3 人が導火線に火をつけた週

2026 年 6 月: 3 人の人物が、互いに連携することなく、数日のうちにほぼ同じことを言いました。

Peter Steinberger (OpenClaw の開発者) は X に 2 つの文を投稿し、890 万回の閲覧数を記録しました:

https://x.com/steipete/status/2063697162748260627

その投稿こそが、この議論の実際の始まりでした。それはマニフェストや長文のエッセイではなく、人々が密かにすでに行っていたことに名前を付けた、たった 2 行の文章でした。

Boris Cherny: 私はもう Claude にプロンプトを送っていません。私には実行中の Loop があります。それらが Claude にプロンプトを送り、何をすべきかを判断しています。

Addy Osmani: Loop エンジニアリングとは、エージェントにプロンプトを送る役割を自分自身から置き換えることです。代わりにそれを行うシステムを設計します。

実践は名前よりも数ヶ月早く行われており、誰もがすでに Loop を書いていましたが、まだ誰もそれに名前を付けていませんでした。

つまり、Loop は現在、AI エージェントが長期的に反復的にソフトウェアを作成できるようにするための重要な要素となっています。

Andrew Ng 氏は、3 つの Loop を時間スケールに基づいて最も内側から最も外側へと整理しました。最も内側の Loop が最も速く、最も外側の Loop が最も遅くなります。さらに、最も外側の Loop への入力は、最も内側の Loop の出力から得られます:

Loop

誰が実行するか

サイクル長

外側の層への出力

エージェンティックコーディング Loop

エージェント自身

秒 - 分

実行可能なバージョン

開発者フィードバック Loop

人間 + エージェント

数十分 - 数時間

より明確なプロダクトビジョンと仕様

外部フィードバック Loop

ユーザー + チーム

数時間 - 数週間

ビジョンを進化させる実際のデータ

Andrew Ng 氏は時間によるマップを与えてくれました。異なる速度で動作する 3 つの Loop です。Addy Osmani 氏は抽象化による 2 つ目のマップを描きました: プロンプト -> コンテキスト -> ハーネス -> Loop。

Loop エンジニアリングは最上位に位置し、ハーネスにはない 3 つの動詞を追加します。それは タイマーで実行 し、ヘルパーを生成 し、自分自身にフィード します。今日の出力が明日の入力になります。これこそが、同じタスクを N 回実行するのではなく、Loop にするものです。

最も重要な直感: 同じバグでも、各層でコストが異なります:

層

重視するもの

中核的な問い

プロンプトエンジニアリング

プロンプトを書く

モデルに何を伝えるか

コンテキストエンジニアリング

ウィンドウに何を読み込むか

何を取得し、要約し、クリアするか

ハーネスエンジニアリング

単一の実行を準備する

どのツール、どのアクション、何を完了とするか

Loop エンジニアリング

ハーネス上でのスケジューリング

それを何度も自動実行させる方法

Loop は設計上、「ターン数」を大きくする機械です。ここからのすべての決定（評価者、人間用ゲート、トークン上限、状態ファイル）は、「ミスの発生」から「誰かがそれに気づく」までの距離を短くするために存在します。

1 ターンの内部で何が起こるか:

「Loop」は「その場でぐるぐる回る」と誤解されることがあります。そうではありません。すべてのターンには 5 つの具体的な動作があります。どれか 1 つでも欠けると、Loop は実行されないか、実行されてもどこにも進みません。

1. 検証は 「ノー」 と言う動作です。
2. スケジューリングは、このターンを次のターンに引き継ぐ動作です。

これこそが、それを Loop にしている部分です。

これから構築するプロジェクトに当てはめると: 小規模チーム向けの朝のトリアージ Loop です:

アクション

機能

トリアージ Loop 内での動作

発見

このターンが何をすべきか判断する

スキルが CI / イシュー / 最近のコミットを読み取る

引き継ぎ

タスクを割り当て、分離する

各発見項目に独自のワークツリーを作成

検証

別のエージェントを導入して「ノー」と言わせる

レビュアーとしての第 2 サブエージェントがテストとスキルを調査

永続化

会話の外部に状態を書き込む

PR + Linear チケット + ./state/triage.md

スケジューリング

ターンごとに実行させ続ける

GitHub Actions の cron が 06:00 にトリガー

以下の 5 つのレッスンはそれぞれ、1 つの動作を成長させます。

5 つのレッスン = 完全な Loop。

そして、最初のレッスン 発見 から始めます。なぜなら、Loop が今日何をする価値があるかを決定できなければ、それ以降のことは何も重要ではないからです。

レッスン 1 発見: 朝のトリアージ SKILL.md を書く

スキル、プロンプトの壁ではありません。

想像してみてください。月曜日の朝 6 時、あなたのラップトップは閉じられており、GitHub Action が起動して claude --skill morning-triage を実行します。何を読み取り、何を実行可能と判断し、どこに結果を書き込むか。これらすべては、あなたがこれから書く SKILL.md の中に存在します。

Osmani 氏の重要な言葉: 自動化はスキルをトリガーするべきです。それは文書化され、更新可能なプロジェクト知識であり、cron ジョブに貼り付けられたプロンプトの壁ではありません。貼り付けられたプロンプトはそこで腐っていくだけです。なぜなら、スケジュールの中に埋もれたものを誰もわざわざ更新しに行かないからです。

このレッスンでのあなたのタスク: .claude/skills/morning-triage/SKILL.md にスキルを書き、それが 3 つのソース（CI / イシュー / コミット）を自ら読み取り、何をする価値があるかを自ら判断し、結果を ./state/triage.md に書き込み、さらに Loop が実行してはならないことを明示する Stop セクションを持つようにします。

以下がスターターです。3 つの箇所を変更すれば、あなたのものになります:

1# .claude/skills/morning-triage/SKILL.md
2---
3name: morning-triage
4trigger: invoked by daily automation
5---
6
7## Read   (発見の入力 — あなたのリポジトリが実際に持っているソースに置き換えてください)
8- 前回の実行以降に失敗した CI 実行      # gh run list --status failure
9- 過去 24 時間にオープンされたイシュー   # gh issue list --search "created:>=…"
10- 昨日以降にマージされたコミット         # git log --since=yesterday
11- 前回の ./state/triage.md              # 「昨日 → 今日」の引き継ぎ
12
13## Judge  (上限 — Loop に選択させ、リストを渡さないでください)
14各候補について、以下を判断:
15- 今すぐ実行可能か、それともノイズか?
16- リリースをブロックするか? → 優先度 = P0
17- すでに追跡中か? → スキップ
18今日、ワークツリーを作成する価値があるものだけを保持。
19
20## Write  (永続化 — チャットではなくマークダウンに記録)
21./state/triage.md に追記:
22| 発見項目 | ソース | 優先度 | ステータス |
23ファイルをコミットして、明日読み取れるようにする。
24
25## Handoff  (レッスン 2 の準備)
26保持された各発見項目について、タスク行を出力:
27  worktree=fix/<スラッグ>
28  goal=<停止条件>
29
30## Stop   (唯一の非定型セクション — ここはよく考えてください)
31絶対にマージしない。絶対に削除しない。
32自信がないものは → ./inbox/ に人間用として。
33PR は作成しない。

ここで実際に機能する 3 つのセクション:

Read: これが発見の入力です。具体的なソースを、実際のコマンドに至るまでリストアップしてください。「コンテキストを読む」はソースではありませんが、gh run list --status failure はソースです。

Judge: これが Loop 全体の上限です。Loop は「実行可能 vs ノイズ」を自ら判断します。あなたからリストを受け取りません。なぜなら、もし毎朝まだリストを渡しているなら、あなたは「実行」を自動化しただけで、「選択」を自動化していないからです。そして通常、選択の方がよりコストのかかるステップです。ソースがどんなに優れていても、このセクションがゴミを選べば、他の 4 つの動作は価値のない作業に費やされることになります。

Stop: このファイルの中で唯一定型ではない部分です。Loop はスキルが指示することすべてを実行し、スキルが指示すること だけ を実行します。「絶対にマージしない」と書かなければ、いつかあなたの代わりにマージしてしまうでしょう。

レッドラインを明確に示してください: 絶対にマージしない、絶対に削除しない、main にプッシュしない、不確かなものは PR ではなく ./inbox/ に人間用として送る。

もう 1 つ知っておく価値のあること: この同じスキル構造は、朝のトリアージ以外でも機能します。Read セクションを「昨日のアクセスログ + 新しいイシュー + 現在のデプロイバージョン」に置き換えれば、夜間のサイトヘルスチェック Loop になります。Judge に「これは昨日からのリグレッションか?」という 1 行を追加すれば、複数日にわたる比較が可能になります。

このレッスンが防ぐ問題 - ブラインド Loop:

最もよくある「Loop のように見えるが実際は違う」もの。Loop は実行されますが、あなたはまだ毎朝作業を割り当てています（「ねえ、この 3 つのバグを見て」）。それは実行の自動化であって、発見の自動化ではありません。

症状: Loop があなたを決して驚かせない。なぜなら、それはあなたがすでにやる必要があると知っていたことだけを実行するからです。

修正: Judge をスキルの中に配置し、今日の作業を自ら選択させる。

次に進む前に、これら 3 つの質問に答えてください:

1/ Stop セクションは何行ありますか?

「絶対にマージしない」だけなら、もう 1 行追加してください。この Loop に他に何をさせてはいけませんか?（イシューを絶対にクローズしない / main に絶対にプッシュしない / 一度に 3 つ以上の発見項目を扱わない...）

2/ Read の最初の行を、あなたのプロジェクトで実際に実行されるコマンドに書き換えてください

3/ このスキルが 1 年間変更されなかったら、何が起こりますか?

では比較してください: cron ジョブに貼り付けられたプロンプトの壁が 1 年間放置されたら、何が起こりますか?

レッスン 2 引き継ぎ: 作業を割り振り、分離する

レッスン 1 のスキルが実行され終わりました。./state/triage.md には 5 つの実行可能な発見項目が含まれています。最も自然な次の思考は、5 つのエージェントを同時に起動して、高速化することです。まさにそのステップが、タングルド Loop を育てる方法です。複数のエージェントが同じディレクトリ内の同じファイルを編集し、マージ日は考古学の作業になります。

その解毒剤は 1 行です: すべての発見項目は独自のワークツリーを取得します。

git worktree は組み込みの git メカニズムです。1 つのリポジトリ、複数の独立した作業ディレクトリ。それぞれが独自のブランチにチェックアウトされます。git worktree add ../fix-auth fix/auth は、../fix-auth に完全に分離されたワークスペースを開きます。ビルド、編集、テスト。何も他のものに影響を与えません。発見項目ごとに 1 つのワークツリー = エージェントは物理的に分離されます。

このレッスンでのあなたのタスク: ./state/triage.md から各発見項目を読み取り、発見項目ごとに分離されたワークツリー（fix/<スラッグ> という名前）を開き、その中で修正案を作成するエージェントを送り込み、無限に生成されないように並列数の上限を設定するスクリプトを書いてください。

1# state/triage.md を読み取り、発見項目ごとに 1 つのワークツリー
2# 変更: MAX_PARALLEL をあなたのマシン / 請求額に合わせて
3MAX_PARALLEL=3
4
5# 変更: パースをあなたの実際の triage.md の列に合わせて
6findings=$(awk -F'|' 'NR>2 && $5 ~ /open/ {print $2}' \
7           state/triage.md | head -n $MAX_PARALLEL)
8
9for finding in $findings; do
10  slug=$(echo "$finding" | tr ' ' '-' | tr -cd '[:alnum:]-')
11
12  # 重要な行: エージェントごとの物理的分離
13  git worktree add ../wt-$slug -b fix/$slug
14
15  # 変更: goal はレッスン 3 の評価者が読み取る停止条件
16  claude --worktree ../wt-$slug \
17    --goal "tests in tests/$slug pass and lint is clean" \
18    "draft a fix for: $finding" &
19done
20
21wait   # すべての並列エージェントが終了するのを待つ
22
23# クローズルール: エージェントは自動マージしない — ワークツリーは
24# レッスン 5 の人間用ゲートを待つ
25echo "All worktrees ready for review:"
26git worktree list

ここで重要なルール: main では決して作業しないこと。

Main は人間によるレビューのための着陸帯であり、エージェントの机ではありません。すべてのエージェントは fix/* ワークツリー上に存在します。

並列処理に上限を設ける: 無制限の生成はトークン暴走への入り口です（レッスン 5 で再び触れます）。MAX_PARALLEL は正直な質問に基づいて選んでください。「私のマシンはいくつ実行できるか」ではなく、「実際にレビューできる PR はいくつか」です。

マージは人間の判断です: Stripe はこのような Loop を通じて毎週 1,000 以上の PR を処理しており、人間は今でもすべてをレビューしています。人間はプロセスから去ったのではなく、机を変えたのです。コードを書くことから、コードをレビューすることへ。

そして、Stripe の事例から盗む価値のある詳細が 1 つあります。彼らは直感に反して、利用可能な最大のモデルではなく、厳格な決定論的ゲートを持つ より小さな モデルを使用しました。

教訓: Loop 作業には、生のモデルパワーよりも、厳格な検証ゲートの方が効果的です。

このレッスンが防ぐ問題 - タングルド Loop:

単一エージェントの Loop は完全に健全に見えます。問題が現れるのは、並列化した日だけです。5 つのエージェントが実行され、5 つの差分が同じファイルで衝突し、マージはカオスになります。

修正: すべてのタスクは独自のワークツリーを取得し、エージェント間で作業ディレクトリを決して共有しない。

次に進む前に、これら 3 つの質問に答えてください:

1/ MAX_PARALLEL にどの数値を設定しましたか? そしてその理由は?

（お金? マシン? それとも「正直にレビューできる PR の数」?）

2/ ワークツリーがクラッシュした場合（エージェントが何も触らずに終了した場合）

明日の状態ファイルはそれについて何を記録すべきですか?

3/ Stripe は、最大のモデルではなく、より小さなモデル + 厳格な決定論的ゲートを使用しました。

その選択は、あなたの Loop にとって何を意味しますか?

レッスン 3 検証: 「ノー」と言うドアを設置する（最も重要なレッスン）

これは Loop エンジニアリングにおいて最も難しい動作であり、他のどのレッスンよりも努力を払う価値があります。

Anthropic のエンジニア Prithvi Rajasekaran 氏は、長時間実行されるエージェンティックアプリに取り組む中で、あることに気づきました。エージェントに、自分が書いたばかりのコードを評価するように依頼すると、ほとんどの場合、自分自身を褒める のです。たとえ人間が見れば一目で平凡だとわかる場合でも。

これはモデルが愚かだからではありません。自分の宿題に点数をつけることは構造的に破綻しています。 コードが完成する頃には、エージェントのコンテキストは、なぜそのように書いたのかという自己正当化の連鎖で詰まっています。自分の出力を見るとき、結果を見ているのではなく、結果に対する主張を見ているのです。

これを Loop の中に入れると、災害に増幅されます: 毎ターンの「これで十分か?」という問いに、それを書いたばかりのエージェントが答えます。毎ターン、自分自身にうなずきます。長く実行されるほど、実際の品質から乖離していきます。これが ノッディング Loop であり、リストの中で最も高くつく問題です。

Rajasekaran 氏の修正方法を、彼自身の言葉で:

「スタンドアロンの評価者を懐疑的に調整することは、生成者に自分の作業に対して批判的にさせるよりもはるかに扱いやすい。」

これは構造的な問題であり、言葉遣いの問題ではありません。作者に自分の頭の外に出るように頼むことはできません。しかし、別の エージェントを、まったく異なる指示で、自己正当化の連鎖なしに、ゼロからコードを見るように導入することは できます。

このアナロジーは GAN から来ています。一方のネットワークが構築し、もう一方が攻撃します。作成者とチェッカーです。同じ古い銀行のルールです。送金する人と承認する人は別の人でなければなりません。

このレッスンでのあなたのタスク - 2 つのものを書くこと:

1) .claude/agents/reviewer.md に、5 つのセクション（ROLE + ASSUME + CHECK + USE + VERDICT）を持つ評価者システムプロンプト。

2) この Loop の停止条件を宣言する /goal コマンド。これは 別の新しいモデル によって判断され、生成者によって判断されるものではありません。

1# .claude/agents/reviewer.md  (3 箇所を変更)
2ROLE: 敵対的コードレビュアー。
3ASSUME: このコードは、反証されるまで BROKEN であると仮定する。
4褒めてはいけない。失敗する箇所を見つけよ。
5
6# 変更: CHECK をあなたのプロジェクトの実際の障害モードで順序付け、
7# 実行可能なチェックを最初に
8CHECK, 順序通り:
9  1. 実行できるか? (読むのではなく、実行する)
10  2. テスト: 実行し、実際の出力を貼り付ける。
11  3. 作者がスキップしたエッジケース。
12  4. 動作がチケットと一致するか?
13
14# 変更: どの MCP を使用するかは、何をテストしているかによる —
15# フロントエンド → Playwright, API → curl/httpie
16USE Playwright MCP: ページを開き、クリックし、
17スクリーンショットを撮り、DOM を検査する。
18意図ではなく、動作を判断する。
19
20VERDICT: すべてのチェックが成立する場合のみ PASS。
21         それ以外は REJECT + 各理由をリストアップ。

1# 停止条件 — 生成者ではなく、新しい小さなモデルによって判断される
2# 変更: あなたの発見項目の実際の検証可能な条件に置き換えてください
3/goal all tests in test/auth pass and the lint step is clean
4
5# 注意: /loop と /goal は同じものではありません
6#   /loop = 間隔で再実行 (停止判断なし — 危険)
7#   /goal = 新しいモデルが条件を真と判断するまで実行

2 つのエージェント、理想的には 2 つのモデル: 「同じモデル、異なるプロンプト」では、多くの場合、同じ盲点が維持されます。可能であればモデルも交換してください。

デフォルトの懐疑主義: 評価者のベースラインは ASSUME BROKEN です。信頼はチェックに合格することで獲得されるべきであり、デフォルトで付与されるものではありません。

意図ではなく、動作を判断する: 「この JSX は問題なさそうだ」と「ボタンをクリックしたら、ページが遷移した。これがスクリーンショットだ」は、まったく異なる世界です。評価者は 行動 しなければなりません。テストを実行し、ページをクリックし、コードを読んで雰囲気で判断してはいけません。

理由とともに拒否する: 理由がリストアップされていない REJECT は拒否ではありません。生成者は何を修正すればよいか全くわかりません。

そして試金石: あなたの評価者は、過去 5 ターン以上で実際に何かを拒否しましたか? 何百ものターンにわたって一度も「ノー」と言ったことのない Loop は、実際のワークロードでは統計的に不可能です。したがって、それは評価者が機能していないことを証明しています。

このレッスンが防ぐ問題 - ノッディング Loop:

Loop が実行され、エージェントがコードを書き、同じエージェントが「よさそうだ」と言います。毎ターン自己承認し、もっともらしい間違いを機械の速度で積み重ねます。修正: このレッスン全体。構造的分離 + デフォルトの懐疑主義 + 行動による判断 + サードパーティの停止条件。

次に進む前に、これら 3 つの質問に答えてください:

1/ あなたの評価者は、異なるプロンプトを持つ同じモデルですか、それとも異なるモデルですか? その理由は?

2/ 「意図ではなく、動作を判断する」を、あなたのプロジェクトの

具体的な文に翻訳してください。「私の評価者はコードを読みません。代わりに _____ を実行し、_____ を確認した場合のみ PASS します。」

3/ 「ほぼ十分」な新しいモデルが、あなたの /goal 条件を誤って PASS する可能性はどのくらいですか?

もし最も恐ろしい障害モードが X なら、今すぐ停止条件に X のチェックを追加してください。

レッスン 4 永続化: 今日の作業を明日まで存続させる

レッスン 3 が終了しました。あなたの評価者は 3 つの発見項目を判断しました。2 つは PASS、1 つは REJECT です。質問: これら 3 つの判定は今、どこに存在していますか?

もし答えが「コンテキストウィンドウの中」なら、明日の朝 6 時に Loop はリセットされたコンテキストで起動し、何も覚えていません。スクラッチから再トリアージし、昨日の未修正の REJECT につまずき、おそらく別のエージェントを割り当てて再度修正しようとしたり、完全に見逃したり、同じ穴に落ちたりするかもしれません。

それが 記憶喪失 Loop です。毎日が同じ場所から始まります。

1 行での解毒剤: メモリとはディスクに書き込まれた状態であり、コンテキストではありません。マークダウンファイル、Linear ボード、データベース。一度書き留められれば、エージェントがどれだけ完全に忘れても問題ありません。

これら 2 つは常に混同されるので、違いを明確にしてください:

コンテキスト = エージェントが 今回の ターンで見るウィンドウ -> リフレッシュのたびにクリアされる。

メモリ = ターンや日をまたいで存続する状態 -> ディスクに書き込まれる（マークダウン / DB / ボード）。

Loop はメモリのみを通じて今日 -> 明日を橋渡しします。

このレッスンでのあなたのタスク:

1. 少なくとも 4 つの列（発見項目 / ソース / 優先度 / ステータス）を持つ ./state/triage.md を作成する。レッスン 1 のスキルがそれを書き込み、レッスン 2 のワークツリーがそれを読み取ります。
2. コネクタ（MCP）を配線する: PASS 判定は自動的に PR をオープンし、REJECT は自動的にチケットを更新します。
3. 明日の Loop が今日の状態を実際に読み戻せることを確認する。

1# ./state/triage.md  (Loop のメモリ — 必要に応じて変更)
2
3| 発見項目         | ソース       | 優先度 | ステータス     |
4|-----------------|--------------|----------|------------|
5| auth test flaky | CI #4821     | P0       | 修正中     |
6| null deref      | issue 92     | P1       | PR オープン |
7| stale dep       | commit a3f9c | P2       | inbox      |
8
9# 必要に応じて列を拡張: last_seen, retry_count, assigned_to
10# このファイルはリポジトリにコミットされなければなりません —
11# そうしないと明日のクラウドランナーが参照できません

1// .mcp/connectors.json — Loop を外部世界に接続する
2{
3  "github_pr": {
4    "type": "mcp",
5    "on_event": "evaluator.verdict.PASS",
6    "action": "open_pr",
7    "branch": "fix/${slug}",
8    "auto_merge": false        // ← 必ず false。人間用ゲート = レッスン 5
9  },
10  "linear": {
11    "type": "mcp",
12    "on_event": "evaluator.verdict.REJECT",
13    "action": "update_ticket",
14    "fields": { "status": "Blocked", "reason": "${verdict.reasons}" }
15  }
16}

各列が重要な理由: ソースがない -> 発見項目がどこから来たのか監査できない。優先度がない -> 作業を順序付けできない。ステータスがない -> 明日がバトンを引き継げない。

そして、このレッスンの検証は、ごまかすことができない唯一のものです。明日まで待ってください。 起きて確認してください。inbox はまだありますか? 未完了の発見項目はまだステータスを保持していますか? 午前 6 時の実行は、昨日の続きから始まりましたか、それとも最初からやり直しましたか? これは、推論するのではなく、実際に実行することでわかります。

永続化に伴う静かな規律 - 常にサンプルを 1 つ読むこと。

永続化が機能すると、ある罠が開きます。Loop は高速で PR を送り出し、あなたは生産的に感じます。そして、コードベースに対するあなたのメンタルマップは、静かに時代遅れになっていきます。ルール: すべてを読んではいけません（それでは Loop の意味がありません）。しかし、1 日 1 つのサンプル PR を読み、Loop が何を変更したのか、そしてその理由を自分自身に説明することを強制してください。

説明できなくなった瞬間、あなたのマップは遅れをとっています。穏やかな朝にそれを修正するには 10 分かかります。本番インシデントの最中に修正するには、はるかに多くのコストがかかります。

このレッスンが防ぐ問題 - 記憶喪失 Loop:

Loop は良い仕事を見つけ、それを実行し、そして実行したことを忘れます。なぜなら結果はリセットされたコンテキストにしか存在しなかったからです。次のターンで同じ作業を再発見するか、さらに悪いことに、再実行して最初の試みを上書きします。

症状: 蓄積された進歩がない。毎日が同じ場所から始まる。修正: ディスク上の状態ファイル。

次に進む前に、これら 3 つの質問に答えてください:

1/ 「メモリ ≠ コンテキスト」を、あなた自身のプロジェクトからの

1 つの具体的な文に翻訳してください。「私の _____ はメモリであり、私の _____ はコンテキストです。」

2/ 明日の Loop が起動します。state.md のどの COLUMN を

最初に読み取って、最初の動作を決定しますか? その列に正しく名前を付けましたか? それとも、地雷を埋めただけですか?

3/ 規律: 1 つのサンプル PR を読むのは、1 日のうち何時ですか?

今すぐカレンダーリマインダーを設定してください。これは自分自身との契約です。

レッスン 5 スケジューリング: 現実的にし、安全にし、1 つのドアを開けたままにする

レッスン 1 ～ 4 はインストールされましたが、Loop はあなたがボタンを押すのをやめると停止します。最後の動作は 1 つの動詞です。それをトリガーに吊るすこと。

しかし、このレッスンで最も危険な部分は、cron を間違えることではありません。cron を 正しく 設定することです。なぜなら、そうすると Loop は本当に単独で実行され、1 つのバグが一晩中それを回転させ、ヘルパーがヘルパーを生成し、見覚えのない請求書を見て目が覚めることになるからです。

したがって、このレッスンは実際には 3 つのことを行います。トリガーを吊るし、上限を設定し、人間用のドアを維持すること。

最初に - スケジューラーを選んでください:

1クラウド (GH Actions)   デスクトップスケジュール   /loop (CC 内)
2実行場所         クラウド                あなたのマシン        あなたのマシン
3マシン起動?     不要                    必要                  必要
4セッションオープン? 不要                  不要                  必要
5最小間隔        1 時間                  1 分                  1 分
6ローカルファイル参照? 不可                可                    可

決定を左右する質問: この作業はあなたのラップトップから離れられますか?

1"毎分ローカル開発サーバーをチェックする"
2   → ローカル + /loop でなければならない (クラウドの 1 時間間隔では到達できない)
3
4"午前 3 時に GitHub イシューをスキャンして PR をオープンする"
5   → クラウドでなければならない (あなたのラップトップは閉じている — Loop は
6     それを待つことができない)

そして、この実践全体の中で最も巧妙な自己欺瞞は、ローカルタイマーを「寝ている間に実行されている」と扱うことです。そうではありません。「私がまだ起きている間に、あと数ターン余分に実行している」だけです。

次に - 上限を設定してください。 スケジューリングが機能すると、Loop は本当に無人で実行されます。そして、無人で実行されるものは、制御不能になる可能性があります。

トークン上限: これはあなたの財布を守るものです。毎日のトークン使用量にハードリミットを設定してください。それを超えたら、Loop は停止します。後で手動で再開できます。

ターン上限: これはあなたの時間を守るものです。発見項目ごとの最大ターン数を設定してください。それを超えたら、発見項目は人間用のキューに送られます。

並列上限: これはあなたのマシンとレビューキューを守るものです。レッスン 2 で設定した MAX_PARALLEL を思い出してください。それはここでも適用されます。

そして最後に - 人間用のドアを開けたままにしてください。

Loop はあなたの代わりに作業を行いますが、あなたをプロセスから排除するものではありません。人間用のドアは、Loop が対処できないもの、または対処すべきでないものが通過する場所です。

人間用のドアの例:

• 評価者が REJECT した発見項目 -> 人間用の inbox に送られる
• トークン上限に達した -> 人間に通知される
• ターン上限に達した -> 人間にエスカレーションされる
• 新しいスキルが必要 -> 人間が作成する

このレッスンが防ぐ問題 - 暴走 Loop:

Loop は制御不能になり、トークンを消費し、PR を生成し、あなたが止めるまで止まりません。修正: 上限を設定し、人間用のドアを維持する。

次に進む前に、これら 3 つの質問に答えてください:

1/ あなたの Loop のトークン上限はいくらですか? その数字はどこから来ましたか?

2/ 発見項目が最大ターン数に達したらどうなりますか? それはどこに記録されますか?

3/ 人間用のドアはどこにありますか? それはどのように実装されていますか?

このレッスンの課題:

1. .github/workflows/triage.yml を作成し、朝のトリアージスキルを起動する cron トリガーを設定する。
2. 3 つの上限を設定する: 実行ごとの予算、1 日の予算、最大リトライ回数。
3. ワークフローの最後にルールを設定する: PR は自動マージしない、不明なものはすべて ./inbox/ に送る。

1# .github/workflows/triage.yml  (3 箇所を変更)
2name: morning-triage
3
4on:
5  schedule:
6    - cron: '0 6 * * *'        # 変更: あなたのタイムゾーンの 06:00 (UTC)
7
8jobs:
9  triage:
10    runs-on: ubuntu-latest
11    timeout-minutes: 45          # ← 実行ごとの上限 · 変更
12    permissions:
13      contents: write
14      pull-requests: write
15    steps:
16      - uses: actions/checkout@v4
17
18      - name: morning triage
19        env:
20          ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
21          DAILY_BUDGET_USD: '20'   # ← 1 日の上限 · 変更
22          MAX_RETRIES: '3'          # ← リトライ上限 · 変更
23        run: |
24          claude --skill morning-triage \
25            --max-retries "$MAX_RETRIES" \
26            --daily-budget-usd "$DAILY_BUDGET_USD"
27
28      - name: open PRs (自動マージはしない)
29        run: |
30          # PR は自動的に開かれる。マージは人間が行う。
31          gh pr create --draft --base main \
32            --title "[loop] $(date +%F) triage" \
33            --body-file ./state/triage.md
34          # ここに `gh pr merge` は意図的にない
35
36      - name: route uncertain to inbox
37        run: |
38          ls ./inbox/ && echo "人間のレビュー待ちのアイテムがあります"

6 ヶ月後もループを生かし続ける 3 つのルール:

出荷前に上限を設定する: 3 つのレベル - 実行ごとのタイムアウト、1 日の予算、最大リトライ回数 - 最初の自律実行の 前 に設定し、恐ろしい請求書が届いた 後 ではない。トークン上限はお金を節約するためのものではない。それは、無制限のリスクを制限付きのリスクに変えるサーキットブレーカーだ。上限のないループは、支出の権限を自身のバグに委任しているようなものだ。

参考までに: Uber は AI 予算を 4 ヶ月で使い果たした後、エンジニア 1 人あたり月額 $1,500 のツール利用上限を設定した。あなたのループごとの上限は、その教訓を細分化したものだ。

1 つのドアを開けたままにする: PR は自動マージされない。不明なアイテムはインボックスに届く。あなたは 1 日に 1 サンプルを読む。ドアがあるのは、人間が常にそこを通るからではなく、ドアが存在することで、あなたがいつでも介入できる立場を維持できるからだ。 すべてのドアを溶接して塞いでしまえば、中に入る必要が生じた日に、鍵を失っていることになる。

実際に起動することを確認する。 少なくとも 3 ターンは実行する (ドライランも可)。最もよくある失敗: デモの日は華やかでも、木曜日には停止している。「最後の実行はデモを行った日」というのは、手動ループ (Manual Loop) の診断サインだ。

Claude Code 以外でも同様に機能する - 機能はベンダーにロックインされておらず、名前が変わっているだけだ:

1機能                 Claude Code          Codex
2スケジューリング     /loop · worker       Automations タブ
3条件付き実行         /goal                automation rerun + judge
4並列分離             --worktree           background worktree
5サブエージェント     .claude/agents/      .codex/agents/
6外部接続             MCP + plugins        MCP connector
7明示的スキル         SKILL.md             $skill-name
8オフライン実行       Cloud Routines       cloud (予定)

問題は「どのベンダーか」ではなかった。「6 つの機能すべてがインストールされているか」だ。

このレッスンが防ぐ病 - 手動ループ (Manual Loop):

4 つの動作を美しく構築したが、cron がない。それはループではない - 一度実行して忘れられたスクリプトだ。

修正: あなたの記憶に依存しないトリガーを取り付けること。

出荷前に、次の 3 つに答える:

1/ 3 つの上限の正確な数値は何か？

もしバグが一晩中暴走したら - どの上限が最初に防御を破るか？どれも破らないとしたら...それは何を意味するか？

2/ あなたの人間用ドアはどのようなものか？

(PR レビュー / インボックス / 毎日のサンプル確認 / 毎週の調整？) それを書き留める = 自分自身との契約に署名する

3/ 最後の質問: 6 ヶ月後、このループはあなたをより強くしているか (理解力、判断力、システムへの感覚) - それとも、あなたを読めない機械の管理者に変えているか？後者を避けるための計画は何か？

4 つの負債とエンジニアであり続けること

あなたのループは構築された: 起動し、作業を見つけ、自己批判し、記憶し、明日のスケジュールを自分で設定する。

ループが実行されている間、4 つのことが静かに積み重なる - そしてそれらの共通点は、どれもアラームを鳴らさない ことだ。

1検証負債 (VERIFICATION DEBT)     未検証の出力が積み重なる
2理解力の劣化 (COMPREHENSION ROT) コードベースは成長するが、あなたのメンタルマップは追いつかない
3認知的な降伏 (COGNITIVE SURRENDER) 「もう精査する気になれない」
4トークン吹き出し (TOKEN BLOWOUT)  バグが一晩中暴走 → 請求書として目にする

それらは互いに助長し合う: 未検証の出力は理解を蝕む -> 蝕まれた理解は降伏を招く -> 降伏はループをより長く実行させ、より多く消費させる -> それがさらに多くの未検証の出力を生み出す。

最初の単独実行の前に、新しいループをこれら 4 つすべてに対して監査せよ:

• 私の評価者は実際に拒否する - 飾りではない。
• 私は 1 日に 1 つのサンプル PR を読み、何が変更されたか説明できる。
• 「これは間違っている」と言う習慣を維持している。
• 上限は最初の実行の 前 に設定され、最初の請求書の 後 ではない。

そして、すべてを決定づける部分はここだ:

同じループでも、2 人の異なる人間が構築すれば、正反対の結果に終わる可能性がある。一方は、コードを読み、方向性を維持しながらより速く動くためにそれを使う - ループは彼らがすでに持っている判断力を増幅する。

もう一方は、まさに同じループを、二度と何も理解しないために使う - 6 ヶ月後、前者はより鋭くなり、後者は読めない機械の管理者になっている。

Addy Osmani: 「ループを構築せよ。しかし、単に『実行』ボタンを押す人ではなく、エンジニアであり続けるつもりの人間として構築せよ。」

ループは生成をほぼ無料にする。希少なまま残るのは判断力だ: どの計画が正しいか、どの行で止めるべきか、何が実行されているが根本的に間違っているか。ループは判断力を切り下げない - 判断力以外のすべてを剥ぎ取り、判断力だけを残す。

ループは忠実な増幅器だ:

理解をもたらせ - 理解を増幅する。

怠惰をもたらせ - 怠惰を増幅する。

何を増幅させたいかを決めよ - それを構築する前に。

乞うご期待！

頑張ってください :)