GuideAdvanced

Loop engineering · AIを手動で操縦するのをやめ、ゴールに向かって自律的に働かせる

シリーズの最終レベル。ここまでで部品を学んできた——メモリ、GitHub、RAG、brain、C-A-R、agent-browser。Loop engineeringは、それらを自律的なシステムへと変える接着剤だ。AIは「チャットの向こう側にいる誰か」であることをやめ、ゴールに向かって自ら反復するエンジンになる。このサイクル、突然の請求から身を守る3つのブレーキ、そして本当に存在するコマンドで最初のループを組む方法を説明する。

Jun 23, 202613 min

これは誰のためのもの?

すでにAIで何かを作っていて、ある不快な事実に気づいた人のためのもの——あなた自身がボトルネックだ。あなたが目の前にいる間はAIが前進し、いなくなればすべてが止まる。この recurso は「私がすべてのステップを指揮する」から「自律的に前進するシステムを組む」への飛躍だ。プログラマーである必要はない。必要なのはパターンを理解することだ。

1. その瞬間 · 自分こそがエンジンだと気づくとき

今日、あなたがAIとどう働いているかを思い浮かべてほしい。指示を書く。待つ。何をやったかを読む。「今度はこれを直して」と言う。また待つ。確認する。「次はあれを足して」。何度も何度も。うまくいく——でも静かな問題がある。すべてのエンジンはあなた自身なのだ。あなたの注意力が燃料だ。コーヒーを取りに立ち上がった瞬間、プロジェクトは凍りつく。

Loop engineeringの瞬間は、こう考えたときに訪れる。「もし、一歩ごとにゼンマイを巻きに立ち会わなくてよかったら? ゴールを与えて、達成するまで一人でやりくりしてくれたら?」。それがまさにこれなのだ。このテーマについてFirecrawlの記事がとてもうまく言い表している。Loop engineeringでは、AIはチャットの向こう側の協力者であることをやめ、プログラムがループの中で呼び出す関数になる。

こうイメージしてみて

ここまでのあなたは運転手だった——旅のあいだずっと両手をハンドルに。Loop engineeringは、GPSに目的地を入れてオートパイロットを起動することだ。車は加速し、道を見て、進路を修正し、また見る——一人で、到着するまで。あなたは運転をやめ、旅を監督する立場になる。

2. その痛み · 手作業はスケールしない（そしてあなたを燃え尽きさせる）

この飛躍をしない痛みは本物で、正直だ——黙示録ではなく、消耗だ。症状はこうだ。

手作業があなたを制限しているサイン

長いタスク（プロジェクト全体を監査する、8社の競合を調べる、40ファイルを移行する）に何時間もかかる。なぜなら一列に、一つずつやっているから。

パソコンから離れると、進捗はぴたりと止まる。AIはあなた抜きでは続かない。

毎日同じ種類の指示を繰り返し、自分が監督ではなく機械のオペレーターだと感じる。

手が2本と開いたチャットが1つしかないので、大きなことを2つ同時にできない。

最もよくある誤解

多くの人が「AIを自動化する」とは、ただもっと長いプロンプトを与えることだと思っている。違う。長いプロンプトでも、あなたが送信を押して確認する必要がある。Loop engineeringは別物だ。あなたが何も押さなくても、システムが自分で続けるか止まるかを決めることなのだ。

3. その核心 · 行動する → 観察する → 推論する → 繰り返すのサイクル

どんなループも、単純でも複雑でも、同じ4つのステップを軸に回る。これを暗記してほしい。すべての本質だから。

あらゆるループの4ステップ

行動する — AIが何かをする（コードを書く、ウェブを検索する、テストを直す）。

観察する — やったことの結果を読む（テストは通った? 検索は何を返した?）。

推論する — その結果をゴールと照らし合わせる（もう完了? 何か足りない? エラーがある?）。

繰り返す — もう一度始めるか、終わったかを自分で決める。

普通のチャットとの違いは4つ目のステップだ。続けるかどうかをAIが決める、あなたではない。ループはゴールが達成されるまで、またはあなたが設けた限界に触れるまで、一人で回る（この限界はこれから見る。神聖なものだ）。

オープンループ vs. クローズドループ

2つの味がある。オープンループ: ゴールと完全な自由を与える（「私の競合を全部見つけてスコアをつけて」）——探索には強力だが、基準が曖昧だと結果はノイズだらけになる。クローズドループ: 一歩ずつ道を示し、各ステップの検証方法まで指定する——より予測可能で、より安く、より良い結果。本番ではほぼ常にクローズドが使われる。

4. 3つの神聖なブレーキ（これなしではループではなく、開いた請求書だ）

これは誰も教えてくれない部分で、最も重要だ。一人で回るループは、一人でクレジットを使い果たしうる。Loop engineeringの技術の大半は、AIに反復させることではない——永遠に反復してアカウントを空にするのを防ぐことだ。常に存在すべき3つのブレーキがある。

決して欠けてはならない3つのブレーキ

反復の上限 — 回る最大回数。「多くても10回試して、それで止まれ。」

変更チェック（diff-check） — Nラウンド後にAIがもう何も変えないなら、止まる。無駄に空回りしている。

支出の上限 — トークンまたは金額の限界。達したら、達成していようがいまいがループは終わる。

ほとんど誰も設けない4つ目のブレーキ（そして最も裏切り者だ）

上の3つのブレーキは量（何回、いくら）を制御する。だが本当にあなたを救うのは品質のブレーキだ。不正防止ルール。もしAIに「すべてのテストを通せ」と頼めば、彼女にとって「勝つ」いちばん簡単な方法は…テストを消す、スキップにマークする、検証内容を弱めることだ。3つのブレーキは緑の旗で通過する——そしてあなたのアプリは壊れたまま。ループには常にこう加えること。「成功を装うために検証内容を消す・スキップ（skip）する・弱めることは禁止。本当の原因を直せ」。これはテストだけでなく、あらゆるゴールに当てはまる。

刻み込むべき一文

Firecrawlの記事から、一言一句。「3つのブレーキがなければ、あなたが回しているのはループではない。開いた請求書だ。」どんな自律ループを起動する前にも自問しよう。回数の上限、変更の上限、支出の上限はあるか? 一つでも欠けていたら、起動するな。

もう一つのリスク · 理解の負債

AIがあなたが理解できるよりも速くコードを生み出すと、危険な溝が開く。あなたのプロジェクトに、理解していないものが存在するのだ。ループが速く回るほど、その溝は広がる——誰かが変更を確認しない限り。だからLoop engineeringはC-A-Rプロトコルと手を取り合う。ループは構築し、あなた（または検証エージェント）が監査する。

5. その習慣 · バラバラのメッセージではなく、ループで考える

Loop engineeringは一度きりでやることではない。絶え間ないマインドセットの転換だ。AIでタスクをやろうとするたび、最初のプロンプトを書く前に自問しよう。「これは単発のメッセージか、それともループか?」。大きなタスクの大半は、たくさんのメッセージに変装したループだ。

常にループを考えるべき瞬間

タスクに明確な「完了」の基準があるとき（全テストが通る、バグを10個見つける、文書が全ポイントをカバーする）。

同じサイクルを手で繰り返しているとき（実行 → 失敗 → 修正 → もう一度実行）。

タスクが一回では大きすぎるとき（全部監査する、全部移行する、多くの情報源を調べる）。

あなたがいない間に何かを起こしたいとき（デプロイを確認する、ウェブを見張る、日々のチェック）。

検証者ルール（最も見返りの大きいパターン）

すべての中で最も割の良い技。やる人と確認する人を分ける。あるエージェント（またはエージェントの連鎖）が変更を加え、別の異なるエージェントがあなたのルールとテストに照らして採点する。検証者はより賢い必要はない——ただ別人であればいい、監査人の冷静な頭を持って。これがまさにC-A-Rプロトコルのやることだ。構築と監査を別々のターンで行う。

6. 最初のループの組み方（本当に存在するコマンドで）

ここが素敵なところ。変なプログラミングは一切要らない。Claude Codeのようなモダンなコードエージェントを使えば、すでに部品が組み込まれている。これらのコマンドは実在し、公式ドキュメントに載っている。

Claude CodeのLoop engineeringキット

/goal <条件> — ゴールへ向かうループの核心。条件を設定すると、各ターンの後に高速モデルが達成されたかを確認する。まだなら、Claudeは制御を返す代わりに一人でもう一周始める。「緑になるまで働け」だ。検証可能な条件が必要（例:「全テストが通る」「git status がクリーン」）。

/loop [間隔] [プロンプト] — 時間で繰り返す、ゴールへ反復するのではない。一定間隔ごとにプロンプトを実行する（/loop 5m デプロイを確認して）か、間隔なしならClaudeが自分でペースを選ぶ。何かを見張るのに便利で、「Xを達成する」ためではない。/goalと混同しないこと。

/schedule — クラウドのルーティンを作る。スケジュールされたタスク（毎時、毎日）で、ノートパソコンを閉じていても走るもの、あるいはGitHubのイベントに反応するもの。

/batch — 大きな仕事を5〜30の並列ユニットに分割し、それぞれが自分のサブエージェントと隔離された独自のworktreeで動く。各ユニットが自分の担当をこなし、テストを走らせ、自分のプルリクエストを開く。（移行や大規模変更のための、ループの工業版だ。）

ほとんど誰も理解していない区別

多くの人が`/goal`と`/loop`を混同するが、別物だ。`/goal`は条件を満たすまで反復する（「達成するまで働け」のループ）。`/loop`は間隔で繰り返す（「X分ごとにこれをやれ」）。「全テストを直せ」には/goalが欲しい。「デプロイを5分ごとに見張れ」には/loopだ。これらの混同は初心者ミスの第1位だ。

権威ある事実 · これの出どころ

Loop engineeringは無から生まれたのではない。ReActパターン（Reason → Act → Observe、2022年の論文）から来ている。これがモデルにサイクルの中で推論し行動することを教えた。その後Reflexionが来て、自己批判のステップを加えた——エージェントが自分自身を修正する。2026年の飛躍は持続時間だ。エージェントは短いチャットの応答から、一人で数分から数時間走るようになった。Loop engineeringは、その自律性に本気のエンジニアリング（とブレーキ）を施すことだ。

そして、ループを信頼できるものにする補助部品も実在する。worktrees（claude --worktree）で複数のエージェントが互いを踏まずに働き、skills（SKILL.mdを持つフォルダ）でAIが毎回あなたの文脈を再発見しなくて済み、hooksで重要な瞬間にアクションを引っかけ、MCPコネクタでループが外部ツール（Slack、GitHub、あなたのデータベース）に手を伸ばす。

このシリーズでほぼ全部の部品をすでに持っている

最高なのは、ゼロから始めないこと。メモリはループに周回をまたいで生き残る状態を与える。RAG / brainは文脈を与える。skillsはあなたの知識をコード化する。GitHubは安全な帰還点を与える。agent-browserは本当に観察するための目を与える。Loop engineeringはそれらをサイクルにつなぐだけだ。全部このシリーズにある——最後に直リンクを置いておく。

7. 本当の使い方 · まず設計し、それからコマンドを呼び出す

ここがほとんどのチュートリアルが飛ばす、そしてカギとなる細部だ。ループはタスクを説明しただけでは自分で起動しない。「テストを直すループを組んで」という長い文章を貼り付けると、AIは計画を設計してくれる——だが実行はしない。AIが本当に反復を始めるには、あなたがコマンドを明示的に書かなければならない（Claude Codeでは /goal か /loop）。2ステップだ。まず設計、それから呼び出し。

コマンドはオプションではない

自然言語でループを説明しただけなら、AIは計画で応答して止まる——あなたのゴーサインを待つ。自律ループはあなたがコマンドを打ち込んだときにだけ発火する（/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 だ。例えば、テストを直すならこんな感じ。

Claude Code

/goal 全テストが通る（スイート全体を実行）、いかなるテストも消さずスキップせず、最大15周

そこからAIは走り、結果を観察し、推論し、各ターンの後に一人でもう一度試す——高速モデルが条件の達成を確認するまで（またはブレーキに触れるまで）。もしゴールへ反復するのではなく、一定時間ごとに何かを繰り返したいなら（例えばデプロイを見張る）、そこでのコマンドは /loop だ。

Claude Code

/loop 5m デプロイが終わったか確認して、何が起きたか知らせて

2ステップの黄金律

自然言語で設計する（ステップ1）→ 計画とブレーキを確認する → あなたがコマンドを打ち込む（ステップ2）。決して逆にしないこと。その分離があなたの安全だ。あなたが計画を見てボタンを押さない限り、いかなるループも起動しない。5分の確認が、開いた請求書からあなたを救う。

8. 最も簡単な道 · AIが何をやり、何をあなたが決めるか

ややこしくならないように。これがあなたのコードエージェントがチャットだけで一人でできること、そしてあなたの決断であり続けることだ。

エージェントがあなたのためにやること（チャットで）

ループ全体を設計する: ゴール、サイクル、ブレーキ——そして打ち込むべき正確なコマンドを渡す。

あなたがコマンドを発火したら（/goal か /loop）、周回を一人で回す: 行動し、観察し、推論し、条件を満たすかブレーキに触れるまで再試行する。

大きなタスク（監査、調査、移行）のために /batch で並列にエージェントを起動する。

別のターンで自分の作業を検証する（検証者パターン）。

ループを再現可能にする文脈をコード化したskill（SKILL.md）を作る。

あなたが決めること（委任しないこと）

ゴールと、いつ「完了」とみなすか——これが結果の品質を定義する。

コマンドを打ち込むこと（/goal … か /loop …）: 自分では起動しない、計画を見てからあなたが点火する。

4つのブレーキ: 何周、いつ停滞で止めるか、いくら使うか、そして不正防止ルール。

生み出された変更を確認すること（理解の負債を溜めないため）。

品質基準 / ルーブリック——なぜならループはあなたが入れた良い基準を掛け算し、悪い基準も掛け算するからだ。

NeuralOSでは

Loop engineeringの哲学は、NeuralOSのエージェントチームを内側で動かしているものだ。ゴールを受け取ってそれに向かって働くエージェントたち、調整する1体と、実行または検証する他のエージェントたち。今日それはインターフェースに描かれているのが見える（もう手に取れるビジョン）。完全な自律エンジンはバックエンドのロードマップの一部だ。狙いは、あなたがゴールと基準を設定すれば——システムが周回をこなすことだ。

まとめ · あなたのLoop engineeringチェックリスト

どんなループを起動する前にも、確認しよう

明確な「完了」条件を持つゴールがある。

行動する → 観察する → 推論する → 繰り返すのサイクルを設計した。

オープンかクローズドか決めた（本番ではほぼ常にクローズド）。

3つのブレーキがある: 反復の上限 + 変更チェック + 支出の上限。

誰が実行し誰が検証するかを定めた（別々のターン）。

理解の負債を溜めないよう変更を確認するつもりだ。

ルーブリックに自分の最良の基準を入れた——ループがそれを掛け算するから。

シリーズの締めくくり

シリーズをたどってここまで来たなら、もう完全なシステムを持っている。メモリ、GitHub、RAG、brain、graphify、C-A-R、セキュリティ、skills、agent-browser…そして今、それらを結ぶループ。あなたはAIを手動で操縦するのをやめた。今はゴールを設定し、良い基準とブレーキを与え、働かせておく。それがオペレーターではなく、スタジオのように作るということだ。

元記事 · Loop Engineering (Firecrawl)

この方法論に名前を与えた出典。本番のパターンを深掘りするのにおすすめの読み物。

C-A-Rプロトコル · バグなしで作る

検証者パターンの実践: 構築と監査を別々のターンで行う。ループの完璧な相棒。

AIに目を与える · agent-browser

サイクルの「観察する」ステップには本物の目が必要だ: AIが手探りでなく、ブラウザで確認すること。

#loop engineering#自律エージェント#自動化#上級#claude code

Ready to build?