まず理解しよう：「ループ」とは一体何か

公式な定義はたったひと言だ：ループとは、agentがある停止条件を満たすまで、作業を何度も繰り返し実行することである。ここでの肝心な違いは、「いつ完了とみなすか」があらかじめ決められていてシステムの判断に委ねられている、ということだ——あなたが一回一回張り付いて急かすのではない。

筆者はループを4つの軸で分類しており、この4つの軸が以降の各ループタイプに共通する参照系となる：誰がそれをトリガーするか、いつ止めるべきかをどう判断するか、Claude Codeのどの機能で実現するか、どんなタスクに最も向いているか。まずこの座標系を立ててから、4種類のループをそこに当てはめていく。

筆者はこうも念を押している：すべてのタスクに複雑なループが必要なわけではない。最もシンプルな方法から始め、これらのパターンは必要に応じて使い分ければいい。

あなたが一言尋ねると、それが一回分の作業をこなす

これはあなたが毎日使っているデフォルトのモードだ。あなたが送るプロンプトのひとつひとつが、あなた自身が各ラウンドを手ずから導くループを開始する：Claudeがコンテキストを集め、手を動かし、自分の作業を確認し、必要なら繰り返し、そして返答する。公式にはこれを「agentic loop」と呼んでいる。

原文にある例を挙げよう：あなたがClaudeに「いいね」ボタンを作らせるとする。Claudeはあなたのコードを読み、ファイルを編集し、テストを走らせ、それから「自分では使えるはず」と思うものを返してくる。その後はあなたが手動で検収し、次のプロンプトを書く。トリガーとなるのは一言のプロンプトで、止めるかどうかの判断権はClaude自身が握っている。決まった手順に属さず、スケジュールにも縛られない短いタスクに向いている。

もっと徹底的に自己確認させるには

「検証」というステップを強化することができる：普段あなたが手動で検収している手順をSKILL.mdとして書き出せば、Claudeがエンドツーエンドでより多くのことを自分でチェックできるようになる。ポイントは、Claudeに見える・測れる・触れるツールやコネクタを与えることだ——チェックが定量化されているほど、Claudeは自己検証しやすくなり、必要なラウンド数も少なくなる。

原文では verify-frontend-change というスキルの例が挙げられている：どんなフロントエンドの変更も、「編集が成功した」というだけで完了扱いにしてはならず、人間のレビュアーと同じように一連の流れを最後まで通す必要がある。

1. dev serverを起動し、ブラウザで変更したページを開く
2. 変更点と直接やり取りする：ボタンをクリックし、状態変化を確認し、前後のスクリーンショットを比較する
3. ブラウザのコンソールを確認する：新たなエラーや警告が一切ないこと
4. Chrome DevTools MCPでパフォーマンスtraceを実行し、Core Web Vitalsを監査する

いずれかのステップが失敗したら、修正してから第1ステップからやり直す。中途半端な成果物を渡すことは決してない。

---
name: verify-frontend-change
description: Verify any UI change end-to-end before declaring it done.
---

# Verifying frontend changes
Never report a UI change as complete based on a successful edit alone.
Verify it the way a human reviewer would:

1. Start the dev server and open the edited page in the browser.
2. Interact with the change directly. For a new control (button,
   input, toggle): click it, confirm the expected state change,
   and screenshot before/after.
3. Check the browser console: zero new errors or warnings.
4. Use the Chrome Devtools MCP, run a performance trace and audit
   Core Web Vitals.

If any step fails, fix the issue and rerun from step 1 — do
not hand back partially verified work.

先に「合格ライン」を決めておいて、初めて止まることを許される

時には一回のラウンドでは足りないことがある、特に複雑なタスクでは。agentは何度も反復できる状態のほうがパフォーマンスが良い。/goalを使って「どうなったら完了とみなすか」を明確に定義すれば、Claudeが反復する時間を延ばすことができる。

言い換えれば、判定の権限はClaudeの手から取り上げられ、基準の照合だけを専門に行う評価モデルに委ねられる。だからこそ「決定的な基準」が特に使いやすい——通過したテストの数や、ある点数のしきい値をクリアするといった基準なら、評価モデルは曖昧さなくはっきりとチェックを入れられる。

具体的な例を挙げよう：

/goal get the homepage Lighthouse score to 90 or above, stop after 5 tries.

ゴール制は検証可能な終了基準があるタスクに向いている。あなたが引き渡すのは「停止条件」であり、使う機能は/goalだ。コストを管理する方法は、完了基準と再試行の上限を具体的に定めること——たとえば「5回試したら停止」のように。

時刻になったら自分で様子を見に行く

中には周期的な作業もある：タスクの内容は変わらず、入力だけが変わる——たとえば毎朝Slackのメッセージをまとめて要約するような作業だ。また外部システムに依存する作業もある。最もシンプルな連携方法は、一定間隔でチェックしに行き、変化に応じて反応することだ。たとえばあるPRは、レビューコメントが付くこともあれば、CIが失敗することもある。

このような作業は/loopでトリガーする。一定間隔で同じプロンプトを再実行してくれる。停止条件は、あなたがキャンセルするか、作業が終わる（PRがマージされた、キューが空になった）ことだ。例：

/loop 5m check my PR, address review comments, and fix failing CI

5つの機能を組み合わせれば、人の手を借りずに自分で動く

これまでのいくつかのプリミティブに加えて、auto mode（オートモード。ステップごとに止まって続けるか確認する必要がない）とdynamic workflows（ダイナミックワークフロー、リサーチプレビュー版）を組み合わせることで、長期的な作業を処理するループを作ることができる。トリガーとなるのはイベントやスケジュールで、全過程を通じてリアルタイムで人が立ち会うことはない。

プロアクティブ制ループの停止ロジックは2層に分かれている：個々の具体的なタスクは自分の目標を達成すれば終了するが、routine全体はあなたが手動で止めるまでずっと動き続ける。これは、繰り返し発生し定義が明確なワークフロー——bugレポート、issueトリアージ、マイグレーション、依存関係アップグレードなど——に最も向いている。

すべてを組み合わせると、完全なプロンプトはこのようになる：

/schedule every hour: check #project-feedback for bug reports.
/goal: don't stop until every report found this run is triaged,
actioned, and responded to. When fixing a bug, use a workflow to
explore three solutions in parallel worktrees and have a judge
adversarially review them.

平たく言えば：1時間ごとに#project-feedbackチャンネルをチェックしてbugレポートを探す。今回見つかったレポートはひとつ残らず、トリアージ・対応・返信が終わるまで止めない。あるbugを修正するときは、workflowを使って3つの独立したブランチ（worktree）で3通りの解決策を並行して試し、さらに1体の審査役agentに互いのミスを対抗的に探させる。ここで言うdynamic workflowsは、一度に数百体規模のサブagentを起動して手分けして作業させ、互いに連携させることができる。

コストを管理する方法：routineはより小型で高速なモデルに任せて動かし、判断が必要な重要なポイントでのみ最も強力なモデルを使う。

ループを自分勝手に暴走させない

ループのアウトプットの質は、それを取り巻くシステム全体によって決まる。システムを設計する際、公式は4つのポイントを挙げている：

• コードベース自体をきれいに保つ

  Claudeはあなたのコードベースにすでにあるパターンや慣習に沿って動く。土台がきれいであってこそ、それに沿って作られるものもきれいになる。

• Claudeに自己確認の手段を与える

  「どうなったら良いとみなすか」をskillsとしてあなたとチームの基準に固定化し、Claudeがエンドツーエンドで自分をチェックできるようにする。

• ドキュメントをすぐ手に取れるようにする

  フレームワークやライブラリの公式ドキュメントには最新のベストプラクティスが載っている。古い記憶を頼りに当てずっぽうさせてはいけない。

• 2体目のagentにコードレビューをさせる

  コンテキストがまっさらなレビュアーはバイアスが少なく、メインagentの推論に影響されない。組み込みの/code-reviewを使ってもいいし、GitHubのCode Reviewと連携させてもいい。

ループにこっそりtokenを使い尽くされないように

tokenを管理するには、ループに明確な境界が必要だ。原文では実行可能な6つのチェック項目が挙げられている：

4種類のループをどう選ぶか、1枚の表でわかる

具体的なタスクを前にしたら、3つのことをはっきりさせる必要がある：何を引き渡すか、いつ使うか、どの機能を使うか。原文にあるこの一覧表は4段階のループを行ごとに対照させたもので、各カードを開くと具体的な例を見ることができる。

/goal get the homepage Lighthouse score to 90 or above, stop after 5 tries.

/loop 5m check my PR, address review comments, and fix failing CI

/schedule every hour: check #project-feedback for bug reports.
/goal: don't stop until every report found this run is triaged,
actioned, and responded to. When fixing a bug, use a workflow to
explore three solutions in parallel worktrees and have a judge
adversarially review them.

考えがまとまったらループを実際に動かしてみて、どこで詰まるか、どこで一線を越えるかを観察し、そこから思い切って改善を重ねていこう。

これは新製品の発表ではない。チームがやったのは、もとからあった5つの機能（/goal、/loop、/schedule、dynamic workflows、auto mode）を、「自律度」に沿って並べた4段階のループとして統一的に整理し、そのままコピーして使える組み合わせテンプレートまで示したことだ。

そこで疑問が出てくる：あなたが張り付かなくていいなら、一体何を根拠に「もう止めどき」と判断するのか？4つの段階の違いは、すべてこの一点にかかっている。

同じ作業で見てみよう——小互（シャオフー）が次々と届くbugレポートを処理するとして、4段階のループはこう動く。違いはたった2点だ：誰が「開始」を告げるか、誰が「止める」と判断するか。

ループが節約するのは処理時間ではなく、「小互が画面に張り付く回数」だ。同じ繰り返し発生する作業（1時間ごとに新しいbugレポートを処理する）で、旧来のやり方と新しいやり方の違いはここにある：

tokenを節約する2つの心得も覚えておく価値がある：決定的なステップはスクリプトに任せて動かすほうが、Claudeに毎回推論し直させるより安く済む。ある回の結果が基準に達しなかったときに直すべきなのはシステムのルールであり、そうすれば以降のすべてのラウンドが恩恵を受けられる——その1回だけを取り繕うのではなく。

以上の数字はすべてAnthropic公式ブログの定義と例に基づくものであり（/schedule、dynamic workflowsはいずれもリサーチプレビュー版機能）、第三者による再現はない。