ループエンジニアリングとは？/loop・/goalで組む自律ループの設計と始め方【2026年9月】

ループエンジニアリング（Loop Engineering）は、AIコーディングエージェントに毎回自分でプロンプトを打つのをやめ、代わりに「仕事を見つけ、エージェントに渡し、結果を検証し、進捗を記録して次を決める」仕組みを設計する手法です。2026年6月にPeter Steinberger氏やBoris Cherny氏の発言をきっかけに実践者のあいだで広まり、同月7日のAddy Osmani氏の記事「Loop Engineering」で部品と運用の形が整理されました。Claude Codeの/loop・/goalやCodexのAutomationsといった部品が製品に標準搭載されたことで、手作りのbashループなしでも組めるようになりました。この記事では定義と他の手法との階層関係、ループの部品、Claude Code・Codexでの動かし方、準備度を測るloop-auditの実測値、止め方と向かない仕事までを一次情報で整理します。

まとめ：ループエンジニアリングの定義と始め方の要点

ループエンジニアリングとは、エージェントに指示を出す側を人間からシステムへ置き換える設計です。Osmani氏は部品を「定期起動（Automations）・Worktree・Skills・プラグイン／コネクタ・サブエージェント」の5つと、会話の外に置く記憶（状態ファイルやLinearのボード）に分けています。プロンプト・コンテキスト・ハーネスを置き換えるものではなく、ハーネスの一つ上に載る層です。

Claude Codeでは、条件を満たすまで回し続ける/goal、一定間隔で回す/loop、クラウドで回すルーティン（/schedule）が中心の部品になります。/loopはセッション内でしか動かず、繰り返しタスクは作成から7日で失効するため、毎日回すループはルーティンやGitHub Actionsへ置きます。

始め方は、自動修正をしないレポートのみ（L1）のDaily Triageからです。完了条件をテストの成否やスコアなど機械で確かめられる形で書けない仕事は、ループにしないと決めておきます。

ループエンジニアリングの定義と2026年6月の提唱経緯

Addy Osmani氏の定義とBoris Cherny氏らの発言

Osmani氏は2026年6月7日の記事で、この手法を「エージェントにプロンプトを打つ人としての自分を置き換え、代わりにそれを行うシステムを設計すること」と定義しました。ここでのループは、目的を定めるとAIが完了まで反復する再帰的なゴールだと説明しています。同じ記事は、Peter Steinberger氏の「コーディングエージェントにプロンプトを打つべきではない。エージェントにプロンプトを打つループを設計すべきだ」と、Claude Codeを率いるBoris Cherny氏の「もうClaudeにプロンプトは打たない。ループがClaudeにプロンプトを打ち、次に何をするか決めている。自分の仕事はループを書くことだ」という発言を起点に置いています。

2026年8月14日の続編「Practical Loop Engineering」では、ループを「エージェントが行動し、結果を確かめ、やり方を調整することを目標達成まで繰り返す、自律的で自己修正型のフィードバックサイクル」と言い直しています。フィードバックで目標へ近づける制御の考え方自体はサイバネティクス以来のもので、新しいのは制御対象がコーディングエージェントになった点です。Osmani氏自身も記事の冒頭で「まだ初期段階で懐疑的でもあり、トークン費用には細心の注意が要る」と書いています。

プロンプト・コンテキスト・ハーネスとの階層関係

4つの手法は置き換えではなく積み重なります。Osmani氏は2026年7月15日の「Own the Outer Loop」で、エージェントを「モデル＋ハーネス（ファイル・ツール・記憶・スキル・サンドボックス・権限・可観測性・復旧）」、ループを「調査・実装・検証の繰り返し」と定義しました。ループはハーネスで動くエージェントを、タイマーで起こし、助手を生み、自分で次の仕事を与える層です。

下の層が雑なままループ化すると、雑な作業が速く量産されるだけです。指示文と文脈の設計はコンテキストエンジニアリングとは？Prompt Engineeringとの違いと4つの実装手法、環境の設計はハーネスエンジニアリングの解説で扱っています。

Ralph Wiggumループから製品の標準機能への移行

ループの原型は、Geoffrey Huntley氏が2025年7月14日に公開した「Ralph Wiggum」手法です。中身は同じプロンプトファイルを延々とエージェントへ流し込むシェルの無限ループでした。

while :; do cat PROMPT.md | claude-code ; done

コマンド名は原文のままで、現在のClaude Codeではclaude -pで非対話実行します。Osmani氏は、部品が製品に組み込まれる前のループエンジニアリングは、こうした手作りのbashループを自分で保守し続けることだったと振り返っています。2026年9月時点では同じ役割をClaude CodeとCodexの標準機能で組め、両者の部品の形はほぼ同じです。

自律ループを構成する5つの部品と外部状態

決まった時刻にコマンドを起動するだけのcronと違い、ループは結果の検証・状態の引き継ぎ・停止条件までを設計に含めます。そのための部品と、Claude Code・Codexで対応する機能を並べます。

典型は、毎朝の定期起動がトリアージ用スキルを呼び、前日のCI失敗・未処理のissue・直近のコミットを読んで状態ファイルに書き出す形です。着手する価値がある項目ごとにgit worktreeで隔離した作業ツリーを開き、1体目のサブエージェントが修正案を作り、2体目がスキルと既存テストに照らして確かめます。スキルの書式はAgent Skills（SKILL.md仕様）の解説を参照してください。

作る役と確かめる役を分ける理由と検証役の既定値

ループの構造で最も効くのは、書く役と確かめる役の分離だとOsmani氏は述べています。コードを書いたモデルは「自分の宿題を採点するには甘すぎる」からです。無人で回るループでは、信頼できる検証役がいることだけが、人がその場を離れてよい理由になります。

Cobus Greyling氏が個人で公開しているコミュニティの参照実装（GitHubのcobusgreyling/loop-engineering、MITライセンス。後述のarXiv論文もレビュー対象にしたもの。以下リファレンス実装）が生成する検証役の定義は、既定の姿勢を「証明されるまで却下（REJECT）」に置き、「実装役がテストを通したという申告を信じず、自分で実行する」と定めています。判定はAPPROVE・REJECT・ESCALATE_HUMANの3値です。Osmani氏が注意するとおり、サブエージェントはそれぞれがモデルとツールを呼ぶぶんトークンを消費するため、二重確認に費用を払う価値がある変更に絞って使います。

状態ファイルが途切れを防ぐ仕組みとコミットされない実態

モデルは実行と実行のあいだで全てを忘れるため、記憶はコンテキストではなくディスクに置きます。Osmani氏の言葉では「エージェントは忘れるが、リポジトリは忘れない」。状態ファイルには試したこと、通ったこと、未解決のことを残し、翌朝の実行が続きから始められるようにします。

実態は処方どおりではありません。2026年8月22日にarXivへ投稿された論文「Loop Engineering: Building Blocks, Adoption, and Impact」（Lulla氏ら、arXiv:2608.21884）は36,710件のリポジトリを調べ、ヒューリスティクスに一致した256件のうち217件で自律エージェントループの稼働を確認しました。そのリポジトリはループの設定はコミットしているものの、議論で推奨される状態ファイルをコミットしている例はほぼ無く、実行時の状態はバージョン管理の外に置かれていたと報告しています。状態ファイルはリポジトリに入れ、レビュー対象にしておくのが安全です。

Claude Code・Codexでループを動かす/loop・/goal・ルーティンの使い分け

Claude Codeチームは2026年6月30日の公式ブログ「Loop engineering: Getting started with loops」で、ループを起動のされ方と止まり方で4種類に分けています。人がプロンプトを送るたびに回るターン型、完了条件まで回る/goal、時間間隔で回る/loopと/schedule、人がリアルタイムに関わらずイベントや予定で回るプロアクティブ型です。どれも「単純な手段から始め、必要な場面にだけ使う」ことが前提です。

既定のHaikuが会話ログだけで下す/goalの完了判定

/goalは、ターンが終わるたびに小型高速モデル（Claude APIでは既定でHaiku）が条件を満たしたかを判定し、未達なら次のターンを始めさせる仕組みです。公式ドキュメントによると、この評価役はコマンドを実行せずファイルも読みません。会話に表示された内容だけで判断するため、条件は「Claude自身の出力で示せる形」に書く必要があります。

/goal test/auth のテストが全て通り lint が警告なしで終わること。他のテストファイルは変更しない。20ターンで打ち切る

評価役が達成不可能と判定すると/goalは自動で解除され、数ターン続けてツールを使わず進展が無い場合はゴールを残したまま止まって操作を返します。条件に入れるのは、測れる終了状態（テスト結果・終了コード・空のキュー）、その確かめ方（npm testが0で終わる等）、途中で変えてはいけない制約の3種類で、長さは4,000文字までです。Osmani氏は、この評価役は成果物の良し悪しを見る検証役ではなく、書いたルールが守られたかを記録から確かめるだけだと注意しています。1セッションで有効なゴールは1つで、無人で回すならパーミッションモードをautoにして使います。Codexにも同名の/goalがあり、Codex 0.128.0以降で/goal pause・resume・clearで一時停止・再開・解除でき、予算の上限でも止まります。

/loopの7日失効と毎日回すループの置き場所

/loop 5m 〜のように間隔とプロンプトを渡すと、Claude Codeがcron式に変換して登録します。間隔を省くと、1分〜1時間のあいだで次の待ち時間をClaudeが選びます。落とし穴は寿命です。タスクはセッションに属し、新しい会話を始めると消えます。繰り返しタスクは作成から7日で最後に1回実行して自動削除され、1セッションに置けるタスクは最大50件です。

このため/loop 1dで毎日のトリアージを登録すると、1週間で止まります。後述するloop initの雛形が勧める/loop 1dもこの制約を受けます。--resume・--continueで再開すれば7日以内の繰り返しタスクは戻りますが、失効日は延びません。PRの見張りやデプロイ待ちのような数時間〜数日の用途は/loop、毎日・毎週続けたい仕事はデスクトップアプリの定期実行、ルーティン、GitHub Actionsへ置く、と分けるのが実務的です。ルーティンは2026年9月時点でリサーチプレビューで、Pro・Max・Team・Enterpriseプランで使え、アカウントの1日あたりの実行枠を消費します。クラウドでは新しくクローンしたリポジトリで動くため、手元のファイルは読めません。

/loopと/goalを組み合わせる定番の形

続編の記事で紹介されている組み合わせは、/loopで定期的に見に行き、見つかった仕事を/goalで完了まで回す形です。

/loop every 24h "Check GitHub for issues labeled 'bug'. If one exists, use /goal to implement a fix until all local tests pass and push the branch."

ただしこの形も/loopの繰り返しタスクなので、作成から7日で失効します。また公式ドキュメントは、定期実行で動くのはClaudeが自分で呼び出せるスキルだけで、組み込みコマンドはテキストとして渡ると定めています。プロンプト中の/goalが評価役付きで動くかは事前に1回確かめ、確実に回したいならGitHub Actionsなどからclaude -p "/goal …"で起動する形（非対話実行として公式に記載）を使います。

Osmani氏は、スター数8万超の自身のリポジトリ（Agent Skills）に最近まで1日80〜90件届いていたプルリクエストの確認を、定期実行の例に挙げています。「翻訳は受け付けない」といった貢献ガイドラインに反するものを閉じる判定は、定期実行に向く仕事だとしています。OSSのTAKTで作業役とレビュー役のループを手元で試す手順は、AIエージェントを指揮するOSS「TAKT」とは｜v0.51で押さえる決定論的オーケストレーションと使い方にまとめています。

最初のループをL1のレポートのみで始める手順とloop-auditの実測

パターン別の実行頻度とコストの目安

リファレンス実装は、用途別のパターンと最初の1週間に使う自律段階を次のように示しています。L1はレポートのみ、L2は検証役付きの自動修正、L3は人の承認ゲートを残した無人運用です。

最初の1本はDaily Triageにします。マージ事故が起きず、状態ファイルの運用だけを先に身につけられるからです。リファレンス実装は「本番リポジトリで新しいパターンのL1を飛ばさない」「検証役が1週間正しかった後にL2へ上げる」ことを明記しています。

loop initとloop-auditで準備度を測る手順と実測スコア

リファレンス実装のCLIは、雛形生成と準備度の採点を分けています。loop-auditは状態ファイル・トリアージ用スキル・検証役・LOOP.md・予算ファイル・実行ログ・人への引き継ぎ経路などを調べ、0〜100の点数とL0〜L3の段階を返します。

npx @cobusgreyling/loop-audit . --suggest
npx @cobusgreyling/loop init . --pattern daily-triage --tool claude
npx @cobusgreyling/loop-audit . --json

2026年9月29日に当社の検証環境で、loop-audit 1.9.0を空のGitリポジトリへ実行すると、結果は7点・L0で、終了コードは2でした（40点未満で2を返す仕様のため、CIのゲートに使えます）。続けてloop init（@cobusgreyling/loop 0.2.0。雛形生成の実体はloop-init）でDaily Triageの雛形を入れると、状態ファイル・LOOP.md・検証役・トリアージと予算と制約のスキル・制約ファイル・AGENTS.mdなど10ファイルが生成され、点数は100点に上がります。それでも段階はL2止まりで、「ループが実際に回った証拠が無い。L3の前にL1を1周回して状態をコミットせよ」と表示されました。

点数が満点でもL3にならないのは、1.4以降の採点が状態ファイル内の最終実行時刻やループ関連のコミットといった稼働の証拠を重く見るためです。ファイルを揃えるのは数秒で済みますが、無人運用に進めるかどうかは、実際に回した記録で決まります。

loop-costで見るトークン試算と早期終了の効き方

実行前の費用見積もりにはloop-cost（1.2.0）を使います。Daily TriageをL1で見積もると、実行間隔の短い側の2時間を採って1日12回とし、現実的な見込みを1日27.6万トークンと出しました。推奨上限の10万トークンを超えるため、間隔を広げるか対象を絞るよう警告が出ます。15分間隔のCI Sweeper（L2）は1日96回で、何もせず抜ける回だけでも48万、全回で修正まで走れば1,920万トークンになり、推奨上限100万に対して現実的な見込みでも180万です。

数字の開きを決めるのは早期終了です。運用ガイドは、見るべき項目が無い回は5,000トークン未満で抜け、サブエージェントは状態ファイルが「対応が必要」と示したときだけ起動するよう定めています。予算の書き方の例として、1日200万トークン上限・超過時はスケジューラを止めて人に通知・1回あたりのサブエージェント起動は3体まで、を挙げています。

暴走を止める停止条件と予算・権限の決め方

減速・一時停止・廃止を判断する基準値

リファレンス実装の運用ガイドは、ループを止める判断を3段階の基準で決めています。

• 減速：週の半ばで予算の80%超、トリアージの誤検知率30%超、同じ項目が48時間で2回以上人へエスカレーションされた、メジャーリリースの週
• 一時停止：本番障害の対応中、破壊的なスキーマ移行の最中、主要レビュアーが不在なのに自動マージが有効
• 廃止：失敗モード一覧で深刻度S2に分類される失敗が続く、2週続けて費用が価値を上回る、チームが通知を全てミュートしている

回り続けるだけのループを見分ける目安として、Osmani氏は「同じコマンドを3回目に試して2回目と結果が変わらなければ止め時」と書いています。/goalには「20ターンで打ち切る」のような上限を必ず入れ、定期ループには予算の80%で報告のみへ切り替える規則を持たせます。

拒否リストと試行回数の上限で権限を絞る設計

リファレンス実装が毎回の実行開始時に読ませる制約ファイル（loop-constraints.md）は、次の規則を拘束力のあるものとして定めています。.env・auth/・payments/・secrets/を編集しない、人の承認なしにmainへ自動マージしない、CIを通すためにテストを無効化しない、1項目あたりの修正は3回までで超えたら人へ回す、の4つが中核です。

この試行上限は、プロンプトの指示だけに頼らず台帳ファイルに試行を記録して機械的に止める作りになっています。同じ規則をClaude Codeで強制するなら、プロンプトではなくClaude Code Hooksで編集前に拒否するほうが確実です。Osmani氏も、認証・セキュリティ・金融に触れる作業やシステムへのアクセス権を渡した作業は、ループに任せても自分で注視すると述べています。

ループエンジニアリングが向かない仕事と人が持ち続ける判断

完了条件を機械で確かめられない仕事はループにしません。Osmani氏の例では「このUIデザインが良くなるまで続けて」は、誰にとって良いのか、どう評価するのかが決まっていない曖昧なゴールです。好みの判断、主観的なデザイン、自由な探索もループには向きません。利用者も積み上がった経緯も少ない新規コードベースと、銀行の既存システムのようなコードベースとでは、同じループでも許せる自律の幅が違います。

ループがうまく回るほど、次の3つの問題はむしろ大きくなると同氏は指摘しています。

• 検証：無人で回るループは、無人で間違えるループでもある。「完了」は主張であって証明ではない
• 理解負債：自分が書いていないコードが速く出荷されるほど、存在するものと理解しているものの差が広がる
• 認知的降伏：ループが勝手に回ると、意見を持つのをやめて出てきたものを受け入れたくなる

同氏自身、競合製品との差分を調べて修正案を作らせたとき、調査結果は読んだものの実装を細かく見ないままプッシュしかけ、後で見直すと得るものの割に利用者へ大きな複雑さを持ち込む変更だったと書いています。任せるのは作業であって、良し悪しの判断ではありません。ループが出した差分を読む時間を、ループを増やす前に確保しておくことが前提になります。

よくある質問

ループエンジニアリングとハーネスエンジニアリングの違いは何ですか？

ハーネスエンジニアリングは、1体のエージェントが動く環境（ツール・権限・記憶・スキル・テスト）を設計する手法です。ループエンジニアリングはその一つ上の層で、ハーネスの上で動くエージェントを定期的に起こし、仕事を割り振り、別のエージェントに検証させ、進捗を状態ファイルに残す仕組みを設計します。ハーネスが整っていない状態でループだけ作っても、失敗が速く繰り返されるだけです。

Claude Codeでループエンジニアリングを始めるには何から手を付けますか？

毎朝手でやっている確認作業を1つ選び、レポートのみのループにするところからです。続編の記事も「毎朝手で回している確認があるなら、それが最初のループ」と結んでいます。数時間で終わる見張りなら/loop、テストが通るまで直させたいなら/goal、毎日続けるならルーティンかGitHub Actionsを使います。検証役のサブエージェントと状態ファイルは、自動修正を始める前に用意します。

ChatGPTやCodexでもループエンジニアリングはできますか？

ChatGPTのチャット画面ではなく、OpenAIのCodex（アプリ・CLI）で組めます。CodexアプリのAutomationsタブでプロジェクト・プロンプト・実行間隔・実行環境を選ぶと定期実行になり、何か見つかった結果はTriageの受信箱に届きます。完了条件まで回し続ける/goalはCodex 0.128.0以降で使え、一時停止・再開・解除ができます。サブエージェントは.codex/agents/にTOMLで定義し、Skills（SKILL.md）とMCPのコネクタもClaude Codeと同じ形式です。部品の形が同じなので、設計はツールをまたいで使い回せます。

ループエンジニアリングのトークン消費はどのくらいですか？

実行間隔と、1回あたりにサブエージェントを起動するかどうかで桁が変わります。リファレンス実装の運用ガイドは、軽いトリアージ1回を約5万トークン、実装役と検証役まで走る回を約20万トークンと見積もっています。loop-costの試算では、15分間隔（1日96回）で全回が修正まで走ると1日1,920万トークン、何もせず抜ける回だけでも48万トークンになります。対応が必要な項目が無い回を早く抜けさせる早期終了と、1日の上限を最初から入れておきます。

ループエンジニアリングの具体例にはどんなものがありますか？

代表例は、毎朝CI失敗と未処理のissueを読んで優先度を付けるDaily Triage、5〜15分おきにPRを見てレビューコメントや失敗したCIに対応するPR Babysitter、最初の週はパッチ更新だけに絞るDependency Sweeper、タグ付け時にリリースノートの下書きを作るChangelog Drafterです。Claude Codeチームは、バグ報告・issueのトリアージ・移行作業・依存関係の更新を、無人で回すループに向く仕事として挙げています。

関連記事

• ハーネスエンジニアリングとは？AIエージェントの成果を決める環境設計を実例で解説
• AIエージェントを指揮するOSS「TAKT」とは｜v0.51で押さえる決定論的オーケストレーションと使い方
• コンテキストエンジニアリングとは？Prompt Engineeringとの違いと4つの実装手法【2026年8月時点】
• Claude Codeのgit worktreeで並列エージェント開発を行う方法｜仕組み・使い方・注意点【2026年版】
• Claude Code Hooksの設定方法｜全33イベント一覧とsettings.jsonの書き方【2026年9月版】