ループエンジニアリングとは？定義と仕組み

ループエンジニアリングとは

ループエンジニアリングとは、AI エージェントが実行する反復サイクルを設計する実践です。何によって起動するか、何にアクセスできるか、出力をどのように検証するか、何を停止条件にするかを定義します。プロンプトエンジニアリングは、モデルに送る1つのメッセージを設計します。ループエンジニアリングは、ユーザーが眠っている間に数千件のメッセージを送信するプロセスを設計します。作業単位は、プロンプトからループへ移ります。

要点は、指示を書くのではなく、制御システムを書くようになることです。エージェントには引き続き適切な指示が必要ですが、指示は、スケジュールに従って実行され、コードの隔離されたコピーで処理し、テストによって結果を検証し、予算を使い切ると停止するサイクルの1要素になります。

用語が2026年に登場した背景

この名称は、現在まさに公の場で定着しつつあります。GitHub リポジトリ cobusgreyling/loop-engineering は、最初に登場してから2か月以内に9,600スターを超えました（2026年7月時点）。掲げている文言は「プロンプトを繰り返すのではなく、ループを設計し、スコアを得る」です。このリポジトリは、この変化を6つの構成要素に整理しています。スケジューリング、worktree、skills、plugins と connectors、サブエージェント、そして会話の外部に保持する永続メモリです。

Anthropic で Claude Code を率いる Boris Cherny の次の発言を引用しています。

私はもう Claude にプロンプトを入力していません。Claude にプロンプトを入力するループを実行しています。

2つ目のリポジトリ AI-Builder-Club/skills は、約1,100スターを獲得しています（2026年7月時点）。そこでは2つの役割を直接定義しています。1つは、エージェントが安全にリポジトリ内でテストやデプロイを実行できるようにする「codebase harness」です。もう1つは、トリガーで起動し、作業を実行し、学習した内容を共有ファイルに書き込んで次のループから読み取れるようにするワークフローを構築する「loop engineer」です。

どちらのリポジトリも、この実践を発明したわけではありません。夜間ビルド、継続的インテグレーションの linter、チケットを作成する cron job を実行した経験があれば、その構造はすでに理解できます。新しい点は、ループ内で動作するワーカーが非決定的になったことです。そのため、周囲の仕組みに求められる役割が変わります。

ループの4つの構成要素

動作するループには、必ず次の4つの構成要素があります。どれか1つでも欠けると、午前3時に起こされるループになります。

• Trigger. 実行を開始するイベントです。タイマー、webhook、新しい pull request、アラートなどが該当します。
• Boundary. その実行中に agent がアクセスできるファイル、認証情報、ネットワークの範囲です。
• Verification. exit code に基づいて、実行結果を保持するか破棄するかを決めるチェックです。
• Budget. 実行が成功したかどうかにかかわらず、実行を終了させる token、時間、費用の上限です。

この4つを質問の形で読み直せば、起動したままにする予定の agent に対する設計レビューになります。

トリガー: エージェントを起動するもの

タイマーは最も単純なトリガーです。Linux サーバーでは、ログを記録でき、指定した条件で再試行でき、実行中の unit の 2 つ目のコピーを起動しないため、この用途では systemd timer が cron より適しています。この最後の特性により、エージェントのループで最も一般的な重複実行の問題、つまり同じブランチを 2 つの実行が編集する問題を防げます。

unit を /etc/systemd/system/agent-loop.service に記述します。

[Unit]
Description=Agent loop: triage open issues
After=network-online.target
Wants=network-online.target

[Service]
Type=oneshot
User=agent
WorkingDirectory=/srv/agent/repo
ExecStart=/srv/agent/bin/loop.sh
TimeoutStartSec=1800

timer を /etc/systemd/system/agent-loop.timer に記述します。

[Unit]
Description=Run the triage loop every 30 minutes

[Timer]
OnBootSec=5min
OnUnitActiveSec=30min
Unit=agent-loop.service

[Install]
WantedBy=timers.target

sudo systemctl daemon-reload
sudo systemctl enable --now agent-loop.timer
systemctl list-timers agent-loop.timer

systemctl list-timers には、将来の時刻を示す NEXT 列と、残り時間を示す LEFT 列が表示されます。結果が空の場合、timer は有効化されていません。enable を --now なしで実行すると、次回の boot に対してのみスケジュールされるためです。TimeoutStartSec=1800 は見落とされがちですが重要です。入力待ちでハングしたエージェントは、unit を無期限に active のままにするため、timer が再び実行されなくなります。実行結果は journalctl -u agent-loop.service -n 50 で確認します。

cron でループを駆動する場合は、独自の重複実行防止策を追加してください。cron は 2 つ目のコピーを問題なく起動するためです。

*/30 * * * * /usr/bin/flock -n /tmp/agent-loop.lock /srv/agent/bin/loop.sh

ロックが保持されている場合、flock -n は status 1 で直ちに終了します。そのため、2 つ目の実行は最初の実行と競合せず、静かに終了します。同じ systemd service と timer の設定 は、エージェントに限らず、サーバー上の長時間実行ジョブにも適用できます。

境界: 実行ごとに専用のコピーを用意する

作業ツリーを編集するエージェントは、未コミットの作業を失う可能性があります。Git worktree を使えば、1 つのオブジェクトストアを共有しながら、実行ごとに専用のディレクトリとブランチを低コストで用意できます。

cd /srv/agent/repo
git worktree add -b loop/triage-01 /srv/agent/work/triage-01 origin/main
git worktree list

git worktree list は、各ツリーについてパス、コミット、ブランチを 1 行ずつ表示します。実行が終了すると、git worktree remove /srv/agent/work/triage-01 がディレクトリを削除し、git worktree prune が存在しなくなったディレクトリのエントリを消去します。2 つのエージェントが 2 つのブランチ上で 2 つのディレクトリを使うため、互いの変更を上書きできません。この時点で、並列ループを安全に実行できます。

この境界は認証情報にも関係します。非対話で実行するループは長期間有効なトークンを保持するため、実行のたびにログ、コミット、またはモデルのコンテキストへトークンが漏えいする可能性があります。トークンの権限を、ループが扱う 1 つのリポジトリに限定してください。可能であれば、エージェント自身の shell から見える環境にトークンを置かないでください。ループに本番環境へのアクセスを与える前に、AI エージェントから Secret を遠ざける方法を読んでください。さらに強い隔離が必要な場合は、実行ごとに破棄できる使い捨て VM 上でループ全体を実行します。どのツールを使うかも、作成前から境界の一部を決めます。そのため、自分で構築すべき隔離の程度を判断する前に、Cowork の管理対象 sandbox と自分のマシン上で実行する Claude Code の比較を読むとよいでしょう。

検証: ループを安全にするゲート

ここが、単に入力を送る cron ジョブとループを分ける部分です。エージェントの出力は提案です。ゲートが判断します。

#!/usr/bin/env bash
set -euo pipefail

repo=/srv/agent/repo
branch="loop/$(date -u +%Y%m%dT%H%M%SZ)"
tree="/srv/agent/work/$(basename "$branch")"

cd "$repo"
git fetch --quiet origin
git worktree add -b "$branch" "$tree" origin/main
cd "$tree"

# the agent's own command runs here, in non-interactive mode

if ! npm test; then
  echo "gate failed: discarding $branch" >&2
  cd "$repo"
  git worktree remove --force "$tree"
  exit 1
fi

git push origin "$branch"
cd "$repo"
git worktree remove "$tree"

このスクリプトでは、set -euo pipefail が実際の処理を担っています。-e がないと、git fetch の失敗が無視され、古い origin/main を対象に処理が続行されます。-u がないと、変数名の入力ミスが空文字列に展開され、クリーンアップが明示的に失敗せず、誤ったパスを対象に実行されます。

if ! npm test ブロックが要点です。すでに信頼しているチェック、つまりテストスイートや型チェッカーの終了コードによって、ブランチを push するか破棄するかを決めます。ゲートのないループは、誰もレビューする時間のない作業を生成します。これは、作業がないより悪い状態です。ゲートのあるループは、人間のコントリビューターのブランチにも求められる基準をすでに通過したブランチを生成します。ただし、ゲートが成功しても、エージェントがそこに到達するまでにどれだけコードを変更したかは分かりません。そのため、エージェントに動作する最小限の変更を選ばせるルール のような常時適用する指示とチェックを組み合わせる価値があります。これにより diff が小さく保たれ、レビューの負担を抑えられます。

正直に失敗するゲートを選んでください。空の diff でも成功するテストスイートでは、ループは何もしないことが成功だと学習します。テストが弱いリポジトリでは、ループも弱くなります。そのため、注目されているリポジトリでは「ループを書く」前に「コードベースをエージェント対応にする」ことを優先します。テストスイートが単に行を実行するだけでなく、実際にリグレッションを検出できるか確認したい場合は、mutation testing がその答えを示します。さらに、diff を読むよう求める代わりに再実行可能な証拠レポートを返すエージェント と組み合わせれば、その結果を自分で確認できます。

予算: 実行を止める条件

無限に再試行するエージェントは、請求額に上限がないエージェントです。すべてのループに実時間の上限を設定し、TimeoutStartSec で強制します。スクリプト内では再試行回数も制限します。さらに、プロバイダーのアカウント側で利用額の上限を設定します。そのうえで、各実行にかかった費用を記録してください。請求書に反映される前に、ループの逸脱を把握できます。常時稼働エージェント用 VPS のコスト管理では会計面を説明し、ターン間でエージェントが引き継ぐコンテキストの管理では、1 回の実行あたりのコストを左右する最大の要因を説明します。ループが 30 分ごとに同じリポジトリを読み直す場合、そのたびに費用が発生するためです。

コストが理由で、通常は 1 回の長時間セッションよりループのほうが適しています。実行ごとに初期状態から開始し、1 つの狭い範囲の作業を行って終了すれば、コンテキストを小さく保てます。8 時間開いたままのセッションでは、それまでのすべての誤りが履歴に残り、ターンごとにトランスクリプト全体の料金が発生します。

トレンドのリポジトリが体系化するパターン

loop-engineering リポジトリには、本番環境向けの7つのパターンが示されています。これは宣言書ではなく、選択肢として読む価値があります。毎日のトリアージ。レビューコメントを監視して回答する、プルリクエストのフォローアップ。失敗したビルドを処理する継続的インテグレーションのスイーパー。依存関係のスイーパー。変更履歴の下書き作成。マージ後のクリーンアップ。Issue のトリアージです。

共通しているのは、対象が限定された作業であり、明確な判定条件があることです。「失敗したビルドを修正する」なら、マシンが判定できる成功条件があります。「コードベースを改善する」にはそれがないため、ループにはなりません。スケジュールだけが設定された混乱になります。

また、どれにも記録が残ります。どちらのリポジトリも、状態を会話の外に出し、リポジトリ内のファイルに記録します。何を実行し、何を検出し、何を判断したかを残します。そのファイルがループのメモリになります。これにより、2つ目のループは1つ目の作業を再発見せず、その結果を基に処理できます。これは、後からエージェントを監査する方法でもあります。実行が終了した時点で、モデルのコンテキストは失われるためです。実行中の連携は別の通信経路です。同じマシン上で、1つの Claude Code セッションから別のセッションへ作業を渡すこともできます。ただし、そのやり取りはどちらかのセッションが終了すると残りません。そのため、後から読み返せる部分はファイルになります。

ループが失敗する場合

失敗の原因は単純で、チームが変わっても同じです。

• ゲートがない。 出力が蓄積するだけで、誰もレビューしません。信頼が失われ、ループは停止されます。
• 競合する。 1 つのブランチで 2 つの実行が並行したり、1 つの作業ツリーで 2 つの agent が動作したりして、競合が発生します。その後、agent が競合の解決まで試みます。
• 気付かないまま乖離する。 チェックが弱すぎて失敗しないため、ループは通過し続けます。
• 範囲に上限がない。 利用頻度の高い repository でコミットのたびに実行される trigger は、1 日以内にコストの問題になります。

どの場合も対策は同じです。処理を小さくし、チェックを厳密にし、実行をログに記録します。合格条件を 1 文で説明できない場合、その処理は自動化する準備ができていません。

専門用語を使わずに始める

フレームワークは必要ありません。常時稼働する小規模な Linux サーバー、テストスイートが本来失敗すべきときに失敗する git リポジトリ、1 つの systemd timer、そして if を含む 1 つの shell script があれば、完全なループを構成できます。多くの人は、まずこの構成から始めるべきです。設計上の問題はツールを選ぶことではなく、実際に動かして解決するものだからです。1 つのループが安定したら、2 つ目のループの実行は、別の timer と別の worktree を追加するだけでほぼ完了します。基本構成については VPS で coding AI agent を実行する方法 を参照してください。管理下にあるハードウェア上で agent 自体を実行したい場合は、現在利用できる self-hosted AI agent の選択肢 を参照してください。

FAQ

ループエンジニアリングはプロンプトエンジニアリングと異なりますか？

プロンプトエンジニアリングは、文言、例、出力形式という 1 つのメッセージを最適化します。ループエンジニアリングは、メッセージの周囲にあるサイクルを最適化します。具体的には、実行を開始するトリガー、実行環境となるサンドボックス、出力を受け入れるか拒否するかを判定するチェック、実行を終了させる予算を対象にします。ループ内に適切なプロンプトは依然として必要です。ただし、結果に対してゲートとトリガーの影響が大きいため、日々調整する対象はプロンプトそのものではなくなります。

エージェントループの構築にフレームワークは必要ですか？

必要ありません。systemd timer、実行ごとの git worktree、テストコマンドで終了する shell script、provider account に設定した支出上限があれば、定義に含まれるすべての要素をカバーできます。フレームワークは、スケジューリング用インターフェース、共有メモリ形式、複数エージェントのルーティングを追加します。これらは複数のループを実行する場合に役立ちます。ただし、最初のループを始めるための必須条件ではありません。

codebase harness とは何ですか？

人間が常駐しなくてもエージェントがリポジトリで作業できるようにする一連の仕組みです。1 つのコマンドで実行できるセットアップ、非対話的に実行でき、失敗時に明確に終了するテスト、linter、変更をデプロイまたはプレビューする方法が含まれます。この用語は、loop engineering と同じ 2026 年のリポジトリ群の流れから生まれました。実用上の判定は簡単です。新しい人間のコントリビューターが 1 つのコマンドで clone からテスト成功まで到達できないなら、エージェントも到達できません。

エージェントループによる高額な請求を防ぐにはどうすればよいですか？

3 か所で上限を設定します。systemd unit に TimeoutStartSec を設定し、停止しない実行を強制終了します。スクリプト内でリトライ回数に上限を設け、成功するまでループさせないようにします。さらに、API account に厳格な支出上限を設定します。これは、エージェントが交渉して超えることのできない唯一の上限です。そのうえで、実行ごとのコストを記録します。コストが 2 倍になるループは、通常、対象範囲が気付かないうちに広がったループです。

最初にループ化する価値があるジョブはどれですか？

機械可読な合格条件があり、影響範囲が小さいジョブを選びます。失敗している build の修正、依存関係の更新、changelog の再生成はいずれも該当します。テストスイートまたは diff によって結果を検証できるためです。refactoring や design などの範囲が明確でない作業は、まだ適していません。ゲートが確認できるものがないためです。ゲートのないループは、レビュー待ちの作業を増やすだけで、コストの高い方法です。