ループエンジニアリング——Claude Codeで自律エージェントを継続的に走らせる設計パターン

Claude Codeのリードエンジニア Boris Chernyはこんなことを言った。「自分の仕事は、もうモデルをプロンプトすることではなく、ループを書くことになった」。

プロンプトを1回投げる時代は終わった。今、設計の腕の見せどころはループにある。そしてそのループをどう止めるかを設計しなかったとき、どうなるか——2026年6月、Uberがエンジニアひとりあたり月1,500ドルのAIコスト上限を導入したというニュースが出た。年間AI予算を4ヶ月で使い切ったからだ。ループを設計したが、停止条件を設計しなかった。

この記事では、Claude Codeで自律エージェントを継続的に走らせるための設計パターンを整理する。/loop と /goal の使い分け、5つのループパターン、暴走対策とコスト管理、そしてEMが踏みやすい落とし穴まで、実装に使える形で書いた。

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

「ループエンジニアリング（Loop Engineering）」という言葉を広く知らしめたのは、Googleで14年間にわたりChromeおよびCloud AIの開発者体験をリードしたAddy Osmaniが2026年6月に公開した同名の記事だ。O'Reilly Radarにも転載され、2026年上半期のAIエンジニアリング界隈でもっとも議論されたパラダイムシフトの一つになっている。

Osmaniはこう定義する。「自分がエージェントにプロンプトを送るのではなく、そのプロンプト送出システム自体を設計すること。AIが条件を満たすまで反復実行するシステム（ループ）を作る技術」。

なぜ今なのか。Claude Fable 5（2026年6月9日リリース）は「前のどのClaudeモデルよりも長く自律的に動作できる」とAnthropicが発表した。モデルが長く走れるようになったからこそ、走らせ続けるループの設計が現実的な意味を持ち始めた。

ただし同時に、Osmaniは重要な警告も発している。「ループが高速化するほど、コード理解のギャップが拡大する」「認知的降伏——ループに依存しすぎることでエンジニアとしての判断力が失われる」。速度と理解のトレードオフは、ループエンジニアリングの核心にある問いだ。

Claude Codeのループ機能を理解する

Claude Codeには、ループを実現するための機能が3種類ある。

PCを閉じても動かし続けたいならRoutines一択。ローカルファイルへのアクセスが必要な定期タスクはDesktop scheduled tasks。今開いているセッション中にポーリングしたいなら/loopを使う。

/loop——時間間隔で繰り返す

Claude Code v2.1.72以降で使えるコマンドで、基本構文は以下のとおりだ。

/loop [interval] [prompt]

インターバルを指定すれば固定スケジュールで動き、省略するとClaudeが毎イテレーション後に状況を観察して1分〜1時間の間で次の待機時間を動的に選択する。ビルドが終わりかけている、PRが活発——なら短く待機。何も変化がない——なら長く待つ。

/loop 5m check if the deployment finished

インターバルなしの/loopだけで起動すると、組み込みのメンテナンスプロンプトが動く。未完了の作業を続行し、現在ブランチのPRをケアし、保留タスクがない場合はバグハントやクリーンアップを走らせる。.claude/loop.md（プロジェクトスコープ）または~/.claude/loop.md（ユーザースコープ）を作成することで、このプロンプトを自分のチーム向けにカスタマイズできる。

繰り返しタスクは作成から7日で自動削除される。緊急停止したいときはEscキー、スケジューラを完全に無効化したいときは環境変数CLAUDE_CODE_DISABLE_CRON=1を設定する。

/goal——条件を満たすまで走り続ける

Claude Code v2.1.139（2026年5月12日）で追加されたコマンドで、完了条件を設定するとClaudeがそれを満たすまでターンをまたいで作業し続ける。

/goal all tests in test/auth pass and the lint step is clean

各ターンの後、デフォルトではHaikuの「小さくて速いモデル」が条件を評価し、「満たされた（yes）」「まだ（no + 理由）」を返す。noの場合は理由が次のターンのガイダンスになる。評価トークンはメインターンと比較して「通常は無視できるレベル」と公式ドキュメントには書かれている。

上限を設定したいときは条件文にor stop after 20 turnsを含めればよい。

/goal all tests pass or stop after 20 turns

なお、/goalはhooksシステムの一部であるため、組織ポリシーでdisableAllHooksが設定されている環境では動かない。導入前に確認しておく。

Routines——クラウドで完全自律実行

RoutinesはAnthropicのクラウドインフラ上で実行され、PC電源OFFでも継続して動く。トリガーはSchedule（定期実行）・API（HTTPポストで即時起動）・GitHub（イベント連動）の3種類で、1つのルーティンに複数組み合わせることもできる。パーミッションプロンプトなしで完全自律実行されるため、誤って重要ファイルを変更しないよう設計を慎重にする必要がある。

ただし2026年6月時点でresearch previewステータスにある。APIサーフェスは変わりうることを念頭に置いてほしい。

5つのループ設計パターン

Anthropicが「Building Effective Agents」で示したように、ループには目的によって異なるパターンがある。私が実際に使っているものを中心に整理する。

Loop-until-condition（条件を満たすまで）

評価可能な終了状態が存在するループ。Claude Codeの/goalがこれに相当する。

「テストが全件グリーンになるまで修正を続ける」「マイグレーション完了まで全呼び出しサイトをコンパイル可能にする」といった用途に使う。

重要なのはDOER（実装者）とCHECKER（評価者）を分離することだ。同一モデルに「自分の宿題を採点」させると、正しくない状態でも「完了」と判断されるリスクがある。Anthropicもこのパターンを「Evaluator-Optimizer」と命名して推奨している。

Loop-until-dry（枯渇するまで）

処理対象がなくなるまでキューを消化するループ。/loopの組み込みメンテナンスプロンプトに近い考え方だ。

「ラベル付き未解決Issueのキューが空になるまでトリアージを続ける」「積み残しPRが全て処理されるまで続行」のように、終わりが処理量によって決まるタスクに向く。

Polling Loop（外部状態を定期確認）

固定または動的間隔で外部状態を確認し続けるループ。CIステータスの監視やデプロイ完了の検知など、外部システムの変化を待つ場面で使う。

/loop 5m check if the deployment finished

ただしこのパターンはトークンを消費し続ける。バックグラウンドスクリプトの出力をストリーミングで受け取るMonitorツールと組み合わせると、ポーリングよりトークン効率が上がる場合がある。

Self-correcting Loop（自己修正ループ）

生成→評価→修正のサイクルを繰り返すループ。コード生成→テスト実行→失敗したらエラーを反映して再実装、というパターンが典型例だ。

LangGraphでの事例を参考にすると、経験則として3回試行後に有意な改善がほとんど見られなくなることが多い。max_attemptsを3前後に設定することが合理的とされている。

Claude Codeで実装する場合、別セッションのサブエージェントをレビュアーに使う「Writer/Reviewerパターン」がよく使われる。

Budget Loop（予算消化まで）

コストまたはターン数の予算が尽きるまで実行し、その時点の最善の成果を返すループ。「30ターンで可能な限りコードレビューを実施」「5ドル以内で最大限のリファクタリング」のような場面で活用できる。

Agent SDKのmax_turnsとmax_budget_usdを組み合わせて実装する。

import anthropic

client = anthropic.Anthropic()

result = client.beta.messages.create(
    model="claude-sonnet-4-5",
    max_tokens=4096,
    system="You are a code reviewer.",
    messages=[{"role": "user", "content": prompt}],
    max_turns=30,
    max_budget_usd=5.0,
)

安全に走らせる——暴走対策と停止条件

ループを設計するとき、停止条件は実行条件と同じ重みで考える。

3種類の停止条件を設計する

Claude Code公式ドキュメントでは、停止条件を3カテゴリで設計することが推奨されている。

• 成功停止: タスクが完了した（条件を満たした）
• 失敗停止: リトライ上限到達、または回復不可能なエラーが発生した
• 予算停止: ターン数またはコスト閾値を超過した

Agent SDKにはResultMessage.subtypeで終了理由が返ってくる。error_max_turns（ターン上限到達）、error_max_budget_usd（予算上限到達）、error_during_execution（APIエラー等で中断）を確認することで、どの停止条件に引っかかったかをログに記録できる。

CLIから使う場合は--max-turnsフラグで制御できる。

claude -p "Fix all lint errors" --permission-mode bypassPermissions --max-turns 3

最初は15〜20ターン程度で設定して、実データをもとに上方修正していくのが安全だ。

Stop hookによる決定論的ゲート

/goalはモデルが条件を評価する（確率的）のに対し、Stop hookはスクリプトが実行する（決定論的）。両者を使い分けることでより堅牢な設計になる。

Stop hook → スクリプトがテスト実行 → 失敗なら次のターンをブロック

Stop hookが8回連続でブロックするとClaude Codeが強制的にターンを終了させる。暴走防止の安全弁として機能するが、この上限を踏まない設計を意識しておいてほしい。

HITLゲートの組み込み

完全自律実行に不安があるなら、Human-in-the-Loopゲートを設計段階で組み込む。

実装エージェント → diff生成 → 人間レビュー → 承認後にルーティン続行

Anthropicが推奨するパターンとして、実装エージェントを--permission-mode plan（読み取り専用モード）で動かし、変更を提案させた後にVerificationサブエージェントが新鮮なコンテキストでdiffをレビューする方法がある。PRはGitHubのApproval Gateを経由させることで、コードが意図しないタイミングでマージされることを防ぐ。

コスト試算を事前に行う

ループを走らせる前に粗い試算をしておく。例えば100ターン × 平均100Kトークン/ターン × 入力$3/MTokで計算すると$30になる。実際には出力トークンが加わるため、$50〜$100に膨らむことも珍しくない。Uberのケースではエンジニアによっては月$500〜$2,000のトークンを消費していたと報告されている。

実際にどう使われているか——3つの事例

Mozillaが1ヶ月で423件のFirefoxセキュリティ修正

Mozilla Hacksが公開したFirefox事例では、1ヶ月で423件のFirefoxセキュリティバグ修正をリリースしたことが紹介されている。

設計は4段階だ。LLM判定者が各ファイルを「メモリセーフティ問題の可能性」「Webページからのアクセス容易性」の2軸でスコアリングして優先順位付けをする。修正エージェントが1箇所に対処し、ファジング環境で実際のクラッシュを引き起こして検証サブエージェントがバグレポートの妥当性を確認する。最後に人間エンジニアがPRレビューをする（類似箇所3カ所も確認）。

2段階の検証でfalse positiveをほぼゼロに排除し、人間のレビューコストを大幅に削減したとされている。

CrowdStrikeのトリアージ精度98%

CrowdStrikeの公式ブログでは、Charlotte AIのアジェンティックSOCが「継続的ヒューマンAIフィードバックループ」によってトリアージ精度98%を達成したことが紹介されている。エージェント1件あたり15分以上の調査時間を短縮し、アナリストの役割は個別のオペレーターからAIエージェント群を指揮するオーケストレーターへと変わっている。

ループ設計における人間の役割が、「1件ずつ処理する」から「システム全体を監督する」に変化している点が示唆に富む。

メルカリの組織展開——最小権限で安全に

Claude Code Meetup Japan #4でメルカリが公開した事例では、Managed Settingsでエンジニアと非エンジニアで安全レベルを分け、bypassPermissionsなどの危険操作を組織ポリシーで制限している。

ループ実行特有のポイントとして、自律実行時は最小権限の原則（必要なツールだけallowedToolsに列挙する）と、コンテナ実行時はタスクロール経由でAPIキーを注入する（環境変数への平文禁止）というアプローチが紹介されている。

EMが踏みやすい落とし穴と対策

コスト爆発

前述のとおり、Uberは2026年のAI予算を4ヶ月で使い切った。ループはコストを指数的に増やす可能性がある。

本番のループには必ずmax_budget_usdとmax_turnsの両方を設定する。内部ダッシュボードでエンジニア別コストを可視化し、ループ開始前に「Nイテレーション × Nトークン × 単価 = 総コスト概算」を計算するルールを設けておくと、コスト爆発を未然に防ぎやすい。

PR洪水

Routinesで「全PRに自動コードレビューを適用」などと設定すると、PRをオープンするたびに新セッションが起動してコメントが大量生成される。

GitHubトリガーのフィルタを活用して、ドラフトPRを除外したりlabels: needs-reviewのラベルゲートを設けたりすることで発火条件を絞る。レビューRoutineの出力も「サマリーコメント1件 + インラインコメント」に制限するプロンプト設計が有効だ。

ノイズ通知

モニタリングループが「何も変化なし」でも毎回Slack通知を飛ばし続けると、チームが通知疲れになる。

プロンプトには「既知の状態は無視し、新しい問題が発見された場合のみ通知する」と明示する。「CIがgreenからredに変化した時のみ通知する」など条件を絞っておくと、「沈黙は成功」という状態が作れて通知の質が上がる。

理解度の低下

Osmaniの指摘を改めて引用するが、「ループが高速化するほど、コード理解のギャップが拡大する」。ループが生成したコードをチームが理解しないまま積み上げていくと、後から誰も全体を把握できない状態になる。

ループが生成したコードのレビューセッションをチームで定期開催してほしい。「AIが変えてよいもの/変えてはいけないもの」の境界をCLAUDE.mdに明文化しておく。この2点が現実的な対処だ。

チーム導入のペルソナギャップ

ループを活用するエンジニアと活用しないエンジニアの間で速度差が開くと、評価の問題にもなる。

順序としては、コスト上限のOrganization Policyを先に設定してから全社展開するのが安全だ。loop.mdをgit管理してチームで共有し、ルーティンのプロンプトをレビューするチェックリストも用意しておく。

最初の一手——今日から試せること

設計の話が続いたが、実際に手を動かしてみると理解が深まる。

まずclaude --versionでバージョンを確認してほしい。v2.1.139以上なら/goalが使える。v2.1.72以上なら/loopも使える。5分で終わる。

次に、CIの監視スクリプトを書いていた部分をループに置き換えてみる。

/loop 5m check if CI on the current branch is passing

動的モードならClaudeが状況を判断して待機時間を自動調整する。10分もあれば試せる。

コードレビューのループはこうだ。

/loop 1h /code-review

1時間おきにブランチの差分をレビューさせる。loop.mdにレビューの観点（セキュリティ・パフォーマンス・可読性）を書いておくと、毎回同じ基準で確認される。

条件付きループを試すなら、テストが落ちている箇所を指定してこれを投げる。

/goal all tests pass or stop after 10 turns

10ターンで強制終了する上限を設けているので、無制限に走り続けることはない。

時間があれば.claude/loop.mdを作ってgitにコミットしておいてほしい。「PRのCIが失敗していたらコメントを残す」「ブランチに未解決のレビューコメントがあれば対応する」など、チームの定型作業をここに書いておくと全員が同じループを再利用できる。

ループを書くことがエンジニアの仕事になった、とClaude Codeのリードエンジニアは言った。だがループは止め方を設計してはじめて完成する。どこで走らせ、どこで止めるか——その設計が、これからのエンジニアとEMが身につけるべき問いだと思っている。

まずは/loop 1h /code-reviewを1日走らせてみてほしい。それが最初の一手だ。