はじめに

2026年6月ごろから「ループエンジニアリング（Loop Engineering）」という言葉が一気に見られるようになりました。きっかけは、Claude Code を作った Anthropic の Boris Cherny 氏の「もう Claude に直接プロンプトを書かない。ループを書くのが自分の仕事だ」という発言や、Peter Steinberger 氏の「エージェントにプロンプトするのではなく、エージェントにプロンプトを送る“ループ”を設計せよ」という主張です。これに名前を付けたのが Google の Addy Osmani 氏でした。

バズワードなので人によって解釈が分かれがちですが、この記事では 「ループエンジニアリングで人間の役割がどう変わるか」 を軸に、概念・仕組み・手元での実践を整理します（特定の解釈を“正解”として押し付けるものではなく、一つの整理としてお読みください）。

この記事で分かること

ループエンジニアリングとは何か（人間の役割の変化）
ここで言う「ループ」の構造（内側ループと外側ループ）
ハーネスエンジニアリングとの関係、そして過去の延長であること
手元のツールでの実践（/goal と /loop）
長時間動かすコツと、見落としがちな注意点

第1章：ループエンジニアリングとは（人間の役割の変化）

要点はシンプルで、人間の仕事が 「プロンプトを逐次書く」→「プロンプトが自動で送信されるループを作る」 へと移る、ということです。

これまでは、良いプロンプトを書き、返ってきたものを読み、次を打つ…という「1ターンずつエージェントを手で握っている」状態でした。ループエンジニアリングでは、仕事を見つけ→割り振り→チェックし→記録し→次を決める小さなシステムを作り、そのシステムにエージェントをつつかせます。

つまり、人間が設計する対象がプロンプトからループへ移動したわけです。

エンジニアが不要になる、という話ではありません
Cherny 氏は「優れたエンジニアはむしろこれまで以上に重要」と明言しています。何を作るか決め、顧客と話し、チームを調整し、ループが目指すべきゴールを定義するのは人間です。仕事が消えたのではなく、「コードを書く」から「コードを書くものを書く」へと一段上がった、という整理です。

第2章：ここで言う「ループ」とは（内側と外側）

本質は、人間が毎回プロンプトを打つ代わりに、システムがエージェントにプロンプトを送り、条件が満たされるまで作業し続けることです。

ここには2種類のループがあります。

内側ループ：実行役エージェントが作業し、判定役が「完了したか」を評価、未完了なら差し戻す、を繰り返す。
外側ループ：1つの作業が終わったら次のトリガー（システム障害、CI失敗、定期実行など）を待ち、また内側ループを起動する。

そして、最も重要な設計判断は「実行役（コードを書く）」と「判定役（チェックする）」を分けることです。同じ文脈で自己満足させず、別モデル・別コンテキストに検証させることで、ループが「間違いを自信満々に量産する装置」になるのを防ぎます。

第3章：ハーネスエンジニアリングとの関係と、過去の延長であること

「ハーネスエンジニアリングの次がループエンジニアリング」という単純な関係ではありません。ループを回すことを前提にするからこそ、ハーネス（エージェントを動かす足回り）に追加で求められる要素が出てくる、という関係です。実際、後述の /goal のようなコマンドは「作業ループを回すためのハーネスの追加要素」と言えます。

また、ループエンジニアリングは新しく発明されたものというより、これまでの試行錯誤の延長に名前が付いたものです。「一定の条件を満たすまでエージェントが作業を繰り返す」発想自体は各所で積み重ねられてきました。

このラダー（Matt Van Horn 氏の整理）で言うと、/goal 単体はレベル4。Cherny 氏や Steinberger 氏が実際に見据えているのは、外側ループを監視・制御するオーケストレーターが存在し、送られてくる要求から作業を切り分け、内側ループを回し、全体が自律的に回るレベル5だと考えられます。

Ralph ループ
Geoffrey Huntley 氏が名付けた手法で、シンプソンズの Ralph Wiggum に由来します。仕様（spec）に対して同じプロンプトを while ループで与え、毎回まっさらなインスタンスで1タスクずつ実装させる、を成功条件まで繰り返す、というブルートフォースなやり方です。「予測不能な世界の中で、決定論的にシンプル」なのが名前の由来です。

第4章：手元のツールで実践する（`/goal` と `/loop`）

個人がエージェンティックコーディングツールで実践するなら、/goal や /loop の助けを借ります。この2つはよく混同されるので、違いを押さえましょう。

コマンド	動き	用途
`/goal`	完了条件が満たされるまでプロンプトを注入し続ける。Claude Code では別モデルが完了を判定（軽量モデルが既定）	1つのタスクを最後までやり切らせる
`/loop`	一定間隔で（同じ）プロンプトやコマンドを送信する（スケジュール）	PR の面倒見・CI 監視・定期集約など繰り返し作業

/goal は「完了するまで走る」内側ループ、/loop は「一定間隔で叩く」心拍（ヒートビート）だと考えると分かりやすいです。外側ループ（イベントで内側ループを起動する基盤）は、これらだけでは完結しないため、cron や GitHub Actions、各ツールのスケジュール／自動実行機能、クラウド版の Claude Code などに頼ることになります。

実践フロー例（仕様駆動＋ `/goal`）

/goal はいきなり叩くのではなく、ゴールを丁寧に作り込む前段階が重要です。ある実践者の流れは次のようになっています。

ポイントは、「何を完了とするか（ゴール）」を仕様とテストケースの形で詳細に詰めておくことです。テストケースは「この観点も見て」「それはテストの意味がない」と人間がレビューして精度を上げます。ここを飛ばすと、/goal で走らせても見当違いなものが積み上がります。

第5章：長時間動かすコツと注意点

Cherny 氏が挙げる「Opus を数時間〜数日稼働させるヒント」は、おおむね次のとおりです。

権限をオート（自動承認）モードにする
ダイナミックワークフローで多数のエージェントをオーケストレーションする
/goal や /loop をうまく使う
Claude Code をクラウドで動かす（PC を開いていなくても走る）
エージェントが自分の成果を端から端まで自己検証できる手段を必ず持たせる（テスト自動化、フロントは Playwright 等）

忘れてはいけない6つ目：コストの上限
ループは「呼び出し続ければ無限に作業する」ため、数日走らせると請求額が跳ね上がります。反復回数・連続失敗回数・ドル上限のキャップ（サーキットブレーカー）を必須の設計要件として組み込みましょう。

ループは「品質を上げる道具」ではない

大前提として、ループは自動走行のアシストであって、それ自体が良い成果を生むわけではありません。むしろ頼りすぎると、**作られていくものと人間の理解がどんどんズレる（ドリフト）**という問題が起きます。ループが回っている間は基本的にブラックボックスになりがちだからです。

だからこそ、

何を完了とするか（ゴール／完了条件）を丁寧に定義する
どうタスクを分割し、いま何が並列で進んでいるかを人間が把握する
実行役と判定役を分け、継続的レビューと検証ゲートで信頼性を担保する

といった、人間のレビューとドメイン知識が要る部分は手を抜かないことが肝心です。ループが速くするのは「人間が指示を出さないと進まない」というスピードのボトルネックであって、品質保証はまた別の仕事、という切り分けを意識しましょう。

外側ループをどう実現するか
「特定のメールが届いたら」「システムがある閾値を超えたら」といったイベント駆動で内側ループを起動できると、定期実行より柔軟で、必要ないときにエージェントが動かないぶんコスト面でも有利です。実現にはクラウド上で動く基盤（GitHub Actions、各種オーケストレーション基盤、クラウド版エージェントなど）が必要になります。この「外側ループの実現」が、現状もっとも難しく、今後の普及の鍵になりそうな部分です。

まとめ

ループエンジニアリングは、人間の役割を 「プロンプトを書く」→「ループを設計する」 へ移す考え方
ループには**内側（実行→判定→再投入）と外側（トリガーで起動）**があり、実行役と判定役を分けるのが最重要
新発明ではなく ReAct → AutoGPT → Ralph → /goal → オーケストレーション という積み重ねの延長
手元では /goal（完了まで） と /loop（一定間隔） を使い分ける。ゴールを仕様とテストで作り込むのが前段のカギ
長時間運用はクラウド化・自己検証・コスト上限が要。ループは品質を保証しないので、ドリフトを防ぐ人間のレビューが不可欠

「もう Claude に直接プロンプトは書かない」という言葉は刺激的ですが、その本質は、レバレッジの効く場所が「1回のプロンプト」から「自走する仕組みの設計」へ移った、ということです。押す人ではなく、設計するエンジニアであり続けるつもりでループを組んでいきましょう。