1. その瞬間 · 自分こそがエンジンだと気づくとき
今日、あなたがAIとどう働いているかを思い浮かべてほしい。指示を書く。待つ。何をやったかを読む。「今度はこれを直して」と言う。また待つ。確認する。「次はあれを足して」。何度も何度も。うまくいく——でも静かな問題がある。すべてのエンジンはあなた自身なのだ。あなたの注意力が燃料だ。コーヒーを取りに立ち上がった瞬間、プロジェクトは凍りつく。
Loop engineeringの瞬間は、こう考えたときに訪れる。「もし、一歩ごとにゼンマイを巻きに立ち会わなくてよかったら? ゴールを与えて、達成するまで一人でやりくりしてくれたら?」。それがまさにこれなのだ。このテーマについてFirecrawlの記事がとてもうまく言い表している。Loop engineeringでは、AIはチャットの向こう側の協力者であることをやめ、プログラムがループの中で呼び出す関数になる。
2. その痛み · 手作業はスケールしない(そしてあなたを燃え尽きさせる)
この飛躍をしない痛みは本物で、正直だ——黙示録ではなく、消耗だ。症状はこうだ。
- 長いタスク(プロジェクト全体を監査する、8社の競合を調べる、40ファイルを移行する)に何時間もかかる。なぜなら一列に、一つずつやっているから。
- パソコンから離れると、進捗はぴたりと止まる。AIはあなた抜きでは続かない。
- 毎日同じ種類の指示を繰り返し、自分が監督ではなく機械のオペレーターだと感じる。
- 手が2本と開いたチャットが1つしかないので、大きなことを2つ同時にできない。
3. その核心 · 行動する → 観察する → 推論する → 繰り返す のサイクル
どんなループも、単純でも複雑でも、同じ4つのステップを軸に回る。これを暗記してほしい。すべての本質だから。
- 行動する — AIが何かをする(コードを書く、ウェブを検索する、テストを直す)。
- 観察する — やったことの結果を読む(テストは通った? 検索は何を返した?)。
- 推論する — その結果をゴールと照らし合わせる(もう完了? 何か足りない? エラーがある?)。
- 繰り返す — もう一度始めるか、終わったかを自分で決める。
普通のチャットとの違いは4つ目のステップだ。続けるかどうかをAIが決める、あなたではない。ループはゴールが達成されるまで、またはあなたが設けた限界に触れるまで、一人で回る(この限界はこれから見る。神聖なものだ)。
4. 3つの神聖なブレーキ(これなしではループではなく、開いた請求書だ)
これは誰も教えてくれない部分で、最も重要だ。一人で回るループは、一人でクレジットを使い果たしうる。Loop engineeringの技術の大半は、AIに反復させることではない——永遠に反復してアカウントを空にするのを防ぐことだ。常に存在すべき3つのブレーキがある。
- 反復の上限 — 回る最大回数。「多くても10回試して、それで止まれ。」
- 変更チェック(diff-check) — Nラウンド後にAIがもう何も変えないなら、止まる。無駄に空回りしている。
- 支出の上限 — トークンまたは金額の限界。達したら、達成していようがいまいがループは終わる。
5. その習慣 · バラバラのメッセージではなく、ループで考える
Loop engineeringは一度きりでやることではない。絶え間ないマインドセットの転換だ。AIでタスクをやろうとするたび、最初のプロンプトを書く前に自問しよう。「これは単発のメッセージか、それともループか?」。大きなタスクの大半は、たくさんのメッセージに変装したループだ。
- タスクに明確な「完了」の基準があるとき(全テストが通る、バグを10個見つける、文書が全ポイントをカバーする)。
- 同じサイクルを手で繰り返しているとき(実行 → 失敗 → 修正 → もう一度実行)。
- タスクが一回では大きすぎるとき(全部監査する、全部移行する、多くの情報源を調べる)。
- あなたがいない間に何かを起こしたいとき(デプロイを確認する、ウェブを見張る、日々のチェック)。
6. 最初のループの組み方(本当に存在するコマンドで)
ここが素敵なところ。変なプログラミングは一切要らない。Claude Codeのようなモダンなコードエージェントを使えば、すでに部品が組み込まれている。これらのコマンドは実在し、公式ドキュメントに載っている。
/goal <条件>— ゴールへ向かうループの核心。条件を設定すると、各ターンの後に高速モデルが達成されたかを確認する。まだなら、Claudeは制御を返す代わりに一人でもう一周始める。「緑になるまで働け」だ。検証可能な条件が必要(例:「全テストが通る」「git status がクリーン」)。/loop [間隔] [プロンプト]— 時間で繰り返す、ゴールへ反復するのではない。一定間隔ごとにプロンプトを実行する(/loop 5m デプロイを確認して)か、間隔なしならClaudeが自分でペースを選ぶ。何かを見張るのに便利で、「Xを達成する」ためではない。/goalと混同しないこと。/schedule— クラウドのルーティンを作る。スケジュールされたタスク(毎時、毎日)で、ノートパソコンを閉じていても走るもの、あるいはGitHubのイベントに反応するもの。/batch— 大きな仕事を5〜30の並列ユニットに分割し、それぞれが自分のサブエージェントと隔離された独自のworktreeで動く。各ユニットが自分の担当をこなし、テストを走らせ、自分のプルリクエストを開く。(移行や大規模変更のための、ループの工業版だ。)
/goalが欲しい。「デプロイを5分ごとに見張れ」には/loopだ。これらの混同は初心者ミスの第1位だ。そして、ループを信頼できるものにする補助部品も実在する。worktrees(claude --worktree)で複数のエージェントが互いを踏まずに働き、skills(SKILL.mdを持つフォルダ)でAIが毎回あなたの文脈を再発見しなくて済み、hooksで重要な瞬間にアクションを引っかけ、MCPコネクタでループが外部ツール(Slack、GitHub、あなたのデータベース)に手を伸ばす。
7. 本当の使い方 · まず設計し、それからコマンドを呼び出す
ここがほとんどのチュートリアルが飛ばす、そしてカギとなる細部だ。ループはタスクを説明しただけでは自分で起動しない。「テストを直すループを組んで」という長い文章を貼り付けると、AIは計画を設計してくれる——だが実行はしない。AIが本当に反復を始めるには、あなたがコマンドを明示的に書かなければならない(Claude Codeでは /goal か /loop)。2ステップだ。まず設計、それから呼び出し。
/goal … か /loop …)。それは良いことだ。機械を放つ前に、設計とブレーキを承認することを強いてくれる。設計と実行は意図的に分けられている。ステップ1 — ループを設計する。これをあなたのエージェントに貼り付け、[角括弧]を埋めよう。計画、ブレーキ、そして——重要——その後に打ち込むべき正確なコマンドを返してくれる。
このタスクのために自律ループ(loop engineering)を組みたい: [タスクを説明。例:「失敗している全テストを見つけて直す」または「私の5社の競合を徹底的に調べて報告書を統合する」]。 私のツールは: [Claude Code / Cursor / その他]。設計する前に、私のプロジェクトを見て、このタスクの「真実」として使えるコマンドか正確なシグナルは何かを教えて(例: 本物のテストコマンド、または「完了」をどう測るか)。見つからなければ、私に聞いて。 行動する → 観察する → 推論する → 繰り返す のサイクルに従って、一緒に設計して。明確な言葉で、次を提案してほしい: 1. ゴール: 「完了」の正確で検証可能な条件(ループが本当に達成したから止まるべきだと、どうやって分かるか)。 2. このタスクにオープンループ(自由)とクローズドループ(決められたステップ)のどちらが向くか、そしてなぜか。 3. サイクル: 各周回でAIが何をするか(行動する)、結果をどう確認するか(観察する)、続けるかをどう決めるか(推論する)。 4. 分離: 実行するエージェントと、結果を検証する別のエージェント(下の不正防止ルールを含む)。 5. 4つのブレーキ、必須: - 反復の上限(回る最大回数)。 - 停滞チェック(Nラウンド後にもう進まないなら止める)。 - 支出の上限(トークンまたは時間の限界)。 - 不正防止ルール: 成功を装うために検証内容を消す・スキップ(skip)する・弱めることは禁止。根本原因(本物のコード)を直さなければならず、症状を黙らせるパッチを当ててはいけない。ある周回が直すより多く壊すなら、その周回を巻き戻す。 6. 私が自分で実行するために打ち込むべき正確なコマンド(あなたが勝手に実行しないこと)。Claude Codeでは: タスクが「条件を満たすまで反復する」なら `/goal <条件>` を使い、「一定時間ごとに繰り返す」なら `/loop <間隔> <プロンプト>` を使う。停止条件とブレーキを含んだ、コピーしてすぐ使える行を書いて渡して。コマンドが本当に存在するか確認して。でっち上げないこと。 7. 走っている間に私が監督できるもの。プログラミングをしない私にも読める、1周回あたり1行で、理解の負債に陥らないように。 まずは完全な設計、4つのブレーキ、打ち込むべき正確なコマンドだけを見せて。ループは実行しないで: 設計を承認したら、私がコマンドを打ち込んで発火させる。
ステップ2 — コマンドでループを発火する。設計とブレーキに納得したら、今こそAIが渡してくれたコマンドを打ち込む。「条件を満たすまで働け」(最も一般的)には、Claude Codeでは /goal だ。例えば、テストを直すならこんな感じ。
/goal 全テストが通る(スイート全体を実行)、いかなるテストも消さずスキップせず、最大15周
そこからAIは走り、結果を観察し、推論し、各ターンの後に一人でもう一度試す——高速モデルが条件の達成を確認するまで(またはブレーキに触れるまで)。もしゴールへ反復するのではなく、一定時間ごとに何かを繰り返したいなら(例えばデプロイを見張る)、そこでのコマンドは /loop だ。
/loop 5m デプロイが終わったか確認して、何が起きたか知らせて
8. 最も簡単な道 · AIが何をやり、何をあなたが決めるか
ややこしくならないように。これがあなたのコードエージェントがチャットだけで一人でできること、そしてあなたの決断であり続けることだ。
- ループ全体を設計する: ゴール、サイクル、ブレーキ——そして打ち込むべき正確なコマンドを渡す。
- あなたがコマンドを発火したら(
/goalか/loop)、周回を一人で回す: 行動し、観察し、推論し、条件を満たすかブレーキに触れるまで再試行する。 - 大きなタスク(監査、調査、移行)のために
/batchで並列にエージェントを起動する。 - 別のターンで自分の作業を検証する(検証者パターン)。
- ループを再現可能にする文脈をコード化したskill(
SKILL.md)を作る。
- ゴールと、いつ「完了」とみなすか——これが結果の品質を定義する。
- コマンドを打ち込むこと(
/goal …か/loop …): 自分では起動しない、計画を見てからあなたが点火する。 - 4つのブレーキ: 何周、いつ停滞で止めるか、いくら使うか、そして不正防止ルール。
- 生み出された変更を確認すること(理解の負債を溜めないため)。
- 品質基準 / ルーブリック——なぜならループはあなたが入れた良い基準を掛け算し、悪い基準も掛け算するからだ。
まとめ · あなたのLoop engineeringチェックリスト
- 明確な「完了」条件を持つゴールがある。
- 行動する → 観察する → 推論する → 繰り返すのサイクルを設計した。
- オープンかクローズドか決めた(本番ではほぼ常にクローズド)。
- 3つのブレーキがある: 反復の上限 + 変更チェック + 支出の上限。
- 誰が実行し誰が検証するかを定めた(別々のターン)。
- 理解の負債を溜めないよう変更を確認するつもりだ。
- ルーブリックに自分の最良の基準を入れた——ループがそれを掛け算するから。