ループエンジニアリングとは？定義とAI開発への影響

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

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

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

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

この名称は、現在まさに公の場で定着しつつあります。GitHub リポジトリ cobusgreyling/loop-engineering は、最初に登場してから 2 か月以内に 9,600 スターを超え（2026 年 7 月時点）、2026-10-27 には約 11,600 スターに達していました。「プロンプトを続けるのではなく、ループを設計し、スコアを得る」という文句を掲げています。2026 年 7 月の README では、この変化を 6 つの構成要素に整理していました。スケジューリング、worktree、skills、plugins と connectors、sub-agents、そして会話の外部に保持する永続メモリです。現在の README にはこの一覧はありません（2026-10-27 に確認）が、ループの状態を会話の外部にあるファイルへ保存する構成は引き続き採用しています。

このリポジトリでは、Anthropic で Claude Code を率いる Boris Cherny を、着想の 1 人として挙げています。広く報じられた彼の発言は次のとおりです。

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

2 つ目のリポジトリ AI-Builder-Club/skills は、2026-10-27 時点で約 1,300 スターを獲得しており、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 つ目のコピーを起動しないため、cron より systemd timer が適しています。この最後の特性により、エージェントループで最も一般的な重複実行の問題、つまり同じブランチを 2 つの実行が編集する問題を防げます。

まず、エージェント専用のユーザーを作成します。このユーザーは境界の一部であり、/srv/agent だけを所有します。

sudo useradd --system --home-dir /srv/agent --shell /usr/sbin/nologin agent
sudo chown -R agent:agent /srv/agent

次に、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 は見た目以上に重要です。Type=oneshot サービスは、スクリプトが終了するまで起動中として扱われます。systemd は oneshot unit の start timeout をデフォルトで無効にするため、この行がないと、入力待ちで停止したエージェントが unit を activating 状態のまま永久に保持します。その結果、後続の timer tick は unit がまだ実行中だと判断し、何も起動しません。この行を設定すると、systemd は 30 分後に実行を終了させ、failed として記録します。unit をデフォルトの Type=simple に変更した場合、TimeoutStartSec は実行自体を制限しなくなり、実行時間の上限を設定するのは RuntimeMaxSec= です。実行結果は 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 worktrees はこの問題を低コストで解決します。各実行環境は独自のディレクトリとブランチを持ちつつ、単一のオブジェクトストアを共有します。

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 はワークツリーを削除しますが、削除対象はクリーンな状態のものに限られます。ツリー内に追跡対象外のファイルや変更された追跡ファイルが存在する場合、あるいはサブモジュールが含まれている場合、--force を追加しない限り git は削除を拒否します。そのため、以下のゲートスクリプトでは、実行結果を破棄するパスに対してのみ強制的に削除を行うようにしています。git worktree prune は、ディレクトリが消失したエントリをクリアします。この時点で並列ループは安全になります。これは、2つのブランチ上の2つのディレクトリで動作する2つのエージェントが、互いに上書きすることができないためです。

境界には認証情報も含まれます。無人で実行されるループは長期有効なトークンを保持するため、実行のたびにログ、コミット、モデルのコンテキストへトークンが漏洩するリスクがあります。トークンのスコープはループが操作するリポジトリのみに限定してください。可能な限り、エージェントのシェル環境からトークンを隔離し、ループに本番環境へのアクセス権を与える前に AIエージェントからシークレットを保護する方法 を確認してください。より強固な壁を作るには、ループ全体を 実行後に破棄可能な使い捨てVM 上で動作させます。どのツールを使用するかも、コードを書く前の境界設定の一部となります。必要な隔離レベルを判断する前に、Coworkのマネージドサンドボックスとローカル環境の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 がなければ、変数名のタイプミスは空文字列として展開され、失敗を明示することなく誤ったパスに対してクリーンアップが実行されてしまいます。最後の行に意図的に --force を含めていないのは、追跡されていないファイルやコミットされていないファイルがツリーに残っている場合、git が削除を拒否するようにするためです。これにより、-e は誰にもコミットされていない作業を黙って削除するのではなく、プッシュ後にエラーで終了します。

if ! npm test ブロックこそが、この概念の核心です。すでに信頼しているチェック（テストスイートや型チェッカーなど）の終了コードが、ブランチをプッシュするか破棄するかを決定します。ゲートのないループは、誰もレビューする時間のない成果物を生成するだけであり、何もしないよりも悪質です。ゲートのあるループは、人間のコントリビューターが通過しなければならない基準をすでにクリアしたブランチを生成します。ゲートが「緑（成功）」であっても、エージェントがそこに到達するためにどれだけのコードを修正したかは分かりません。そのため、エージェントに最小限の変更で動作させるルールのような恒久的な指示をチェックと組み合わせる価値があります。これにより、差分が小さく保たれ、レビューのコストを低く抑えられます。

正直に失敗を報告するゲートを選んでください。空の差分でもパスしてしまうテストスイートは、ループに対して「何もしないことが成功である」と教えてしまいます。テストが脆弱なリポジトリではループも脆弱になります。そのため、トレンドとなっているリポジトリでは「ループを書く」ことよりも先に「コードベースをエージェント対応にする」ことが優先されています。テストスイートが単にコード行を実行するだけでなく、実際にリグレッションを検知できるかを知りたい場合は、ミューテーションテストがその答えを導き出します。また、差分を読ませるのではなく、再実行可能な証拠レポートを返すエージェントを活用すれば、その答えをあなた自身で確認可能なものにできます。

予算: 実行を止める条件

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

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

トレンドのリポジトリが整理したパターン

loop-engineering リポジトリは、2026-10-27 時点で 8 つの本番パターンを挙げています。これらはマニフェストではなく、選択肢の一覧として読む価値があります。毎日のトリアージ。GitHub Action として実行し、状態ファイルを保持しない軽量なループ。レビューコメントを監視して回答する pull-request babysitter。失敗したビルドを処理する継続的インテグレーションの sweeper。依存関係の sweeper。変更履歴の草案作成。マージ後のクリーンアップ。Issue のトリアージです。

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

もう 1 つの共通点は、記録を残すことです。どちらのリポジトリも、状態を会話の外部へ移し、リポジトリ内のファイルに保存します。何を実行し、何を見つけ、何を決定したかを記録します。そのファイルがループのメモリになります。これにより、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 つのメッセージを最適化します。対象は文面、例、出力形式です。ループ設計は、メッセージの周囲にあるサイクルを最適化します。対象は、実行を開始するトリガー、実行環境の sandbox、出力を受け入れるか拒否するかを判断するチェック、そして実行を終了させる予算です。ループ内には、引き続き適切なプロンプトが必要です。ただし、結果に与える影響は gate とトリガーの方が大きいため、日々調整する中心はプロンプトではなくなります。

エージェントループの構築に framework は必要ですか？

いいえ。systemd timer、実行ごとの git worktree、test command で終了する shell script、そして provider アカウントの spend cap があれば、定義に含まれるすべての要素をカバーできます。framework は、複数のループを実行する段階で役立つスケジューリングインターフェース、共有メモリ形式、複数エージェントのルーティングを追加します。ただし、最初のループを構築するための必須条件ではありません。

codebase harness とは何ですか？

人間が付き添わなくてもエージェントが repository で作業できるようにする一連の仕組みです。1 つのコマンドで実行できるセットアップ、非対話的に実行して明確に失敗する test、linter、そして変更を deploy または preview する方法が含まれます。この用語は、loop engineering と同じ 2026 年の repository の流れから生まれました。実用上の判定は単純です。新しい人間の contributor が 1 つのコマンドで clone から green test まで到達できないなら、エージェントも到達できません。

エージェントループが大きな請求額を発生させないようにするにはどうすればよいですか？

3 か所で上限を設定します。上記のような Type=oneshot systemd unit で TimeoutStartSec を設定し、停止した実行を強制終了できるようにします。Type=simple サービスでは、同等の設定は RuntimeMaxSec です。再試行回数は、成功するまでループさせるのではなく、script 内で制限します。API アカウントには hard spend limit を設定します。これは、エージェントが説明によって回避できない唯一の上限です。さらに、実行ごとのコストを記録します。コストが 2 倍になるループは、通常、対象範囲がいつの間にか広がったループだからです。

どのジョブから最初にループ化すべきですか？

機械的に判定できる成功条件があり、影響範囲が小さいジョブを選びます。red build の修正、依存関係の更新、changelog の再生成はいずれも適しています。test suite または diff によって結果を検証できるためです。refactoring や design のような範囲の定まらない作業は、まだ適していません。gate が確認できる対象がないためです。gate のないループは、review debt を高コストで増やすだけです。