ループエンジニアリングとは？定義と4要素

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

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

要点は、指示を書くのをやめて、制御システムを書くようになることです。エージェントには依然として適切な指示が必要ですが、それらは、スケジュールに従って実行され、コードの分離されたコピーで動作し、テストによって結果を検証し、予算を使い果たすと停止するサイクル内の1つの構成要素になります。

2026年にこの用語が登場した理由

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

同リポジトリは、AnthropicでClaude Codeを率いるBoris Chernyの言葉を引用しています。

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

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

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

ループの4つの要素

正常に動作するループには、次の4つの要素があります。このうち1つでも欠けると、午前3時に起こされる原因になります。

• トリガー。 実行を開始するイベントです。タイマー、webhook、新しい pull request、アラートなどがあります。
• 境界。 その実行中に agent がアクセスできるファイル、認証情報、network です。
• 検証。 exit code に基づいて、実行結果を保持するか破棄するかを決めるチェックです。
• 予算。 実行が成功したかどうかにかかわらず、実行を終了させる 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 なしで実行すると、次回の起動時にのみスケジュールされるためです。TimeoutStartSec=1800 は見た目以上に重要です。入力待ちでエージェントが停止すると、unit が永久にアクティブな状態になり、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 はステータス 1 ですぐに終了します。そのため、2つ目の実行は最初の実行と競合せず、静かに終了します。同じ systemd service と timer の設定 は、エージェントかどうかに関係なく、サーバー上の長時間実行ジョブに適用できます。

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

作業ツリーを編集するエージェントは、未コミットの作業を失う可能性があります。Git worktreeを使うと、各実行に専用のディレクトリとブランチを割り当てられます。オブジェクトストアは共有されるため、低コストで運用できます。

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

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

この境界は認証情報にも関係します。無人で実行するループは長期間有効なtokenを保持するため、各実行でtokenがログ、コミット、またはモデルのコンテキストに漏れる可能性があります。tokenの権限をループが操作する1つのrepositoryに限定してください。可能な場合は、エージェント自身のshellから見える環境にtokenを置かないでください。ループにproductionへのアクセス権を与える前に、AI agentからsecretを除外する方法を確認してください。さらに強固な境界が必要な場合は、ループ全体を各実行後に破棄できる使い捨てVM上で実行してください。

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

ここが、ループとコマンドを入力するだけの cron job を分ける部分です。agent の出力は提案です。判断するのはゲートです。

#!/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 ブロックが要点です。すでに信頼しているチェック、つまり test suite または type checker の終了コードによって、ブランチを push するか破棄するかを決めます。ゲートのないループは、誰にもレビューする時間がない作業を生み出します。これは、作業がない場合より悪い状態です。ゲートのあるループは、人間の contributor のブランチと同じ基準をすでに通過したブランチを生成します。

正しく失敗するゲートを選んでください。空の差分で成功する test suite では、何もしないことが成功だとループに認識させてしまいます。テストが弱い repository では、ループも弱くなります。そのため、trending repository では「ループを書く」前に「codebase を agent-ready にする」ことを優先します。

予算: 実行を停止する条件

無限に再試行するエージェントは、請求額に上限がないエージェントです。TimeoutStartSec によって適用される実時間の上限をすべてのループに設定します。スクリプト内には再試行回数も設定し、プロバイダーアカウントでは支出上限を適用します。さらに、各実行の費用を記録します。これにより、請求書に反映される前にループの費用増加を確認できます。常時稼働するエージェント用VPSのコスト管理では会計面を扱い、エージェントがターン間で保持するコンテキストの管理では、1回の実行コストに最も大きく影響する要素を扱います。これは、同じリポジトリを30分ごとに再読み込みするループでは、30分ごとにその費用が発生するためです。

ループが通常、1回の長時間セッションより優れている理由はコストです。最初から開始し、1つの限定的な作業を実行して終了する実行では、コンテキストを小さく保てます。8時間開いたままのセッションでは、それまでのすべての誤りが履歴に蓄積され、ターンごとにトランスクリプト全体の費用が発生します。

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

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

これらに共通するのは、明確なゲートを持つ限定的な作業です。「失敗しているビルドを修正する」には、マシンが判定できる合格条件があります。「コードベースを改善する」にはそれがないため、ループにはなりません。スケジュール付きの混乱になります。

また、いずれも記録を残します。両方のリポジトリでは、状態を会話の中に留めず、リポジトリ内のファイルに書き出します。何を実行したか、何を検出したか、何を決定したかを記録します。そのファイルがループのメモリになります。これにより、2つ目のループは最初のループの作業を再発見せずに引き継げます。また、実行終了時にモデルのコンテキストは失われるため、後からエージェントを監査する手段にもなります。

ループが失敗する場合

失敗の原因は単純で、チームが変わっても繰り返し発生します。

• ゲートがない。 出力が蓄積し、誰もレビューせず、信頼が失われて、ループが無効化されます。
• 重複実行。 1つのブランチで2つの実行が走るか、1つの作業ツリーで2つのエージェントが動作し、競合が発生します。その後、エージェントが競合の解決を試みます。
• サイレントドリフト。 チェックが弱すぎて失敗を検出できないため、ループは合格し続けます。
• 範囲に上限がない。 忙しいリポジトリでコミットのたびに起動するトリガーは、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 を設定し、ハングした実行を強制終了します。成功するまで繰り返すのではなく、script 内で retry 回数を制限します。さらに API account に hard spend limit を設定します。エージェントが説得して超過できない上限は、これだけだからです。そのうえで、実行ごとのコストを記録します。コストが 2 倍になるループは、通常、対象範囲が気付かないうちに拡大したループです。

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

機械可読な合格条件があり、影響範囲が小さいジョブを選びます。失敗した build の修正、dependency の更新、changelog の再生成は該当します。テストスイートまたは diff で結果を検証できるためです。refactoring や design のようなオープンエンドの作業は、まだ適していません。ゲートが確認できる対象がないためです。ゲートのないループは、レビュー負債を高いコストで生み出すだけです。