Claude Code Agentic Loops:Prompt を書く段階からループを設計する段階へ、4 つのエンジニアリング実践

·Toolin 編集部

1 回きりの Prompt を、繰り返し可能で停止条件を持つ自動化ループへ引き上げます。Claude Code 公式が提示する 4 種類の Loop パターンについて、それぞれのトリガー方式、受け入れ基準、token 節約のテクニックを解説します。

Claude Code Agentic Loops:Prompt を書く段階からループを設計する段階へ、4 つのエンジニアリング実践

Prompt を何度も書き直して Claude Code にもう少しだけ働いてもらう——それは多くの人が Agent を使うときの日常です。Anthropic 公式の答えはこうです。Prompt を書き続けるのではなく、最初から「ループ(Loop)」を設計し、Agent を定められたルールに沿って自動で走らせ、目標に達するか停止条件に触れるまで回す。これは「指示を書く」から「システムを設計する」へのパラダイム転換です。本記事では、公式が提示する 4 種類の Loop、各ループに必須の 5 要素、そして token を節約するためのエンジニアリングのコツを一気に解説します。すでに Claude Code を使い、日常タスクをエンジニアリングしたい開発者に適した内容です。

4 種類の Agentic Loop

Loop の本質は、Agent にトリガー方式と停止条件を与え、「対話」を「プロセス」に変えることです。トリガーの仕組みによって 4 種類に分けられます。

1. ターン制ループ(Turn-based)

最もよく見る形です。ユーザーが 1 つ指示を出し、Agent が 1 段落返し、ユーザーが続けるかどうかを決めます。

  • トリガー方式:ユーザーの毎回の入力
  • 停止条件:ユーザーが能動的に終了する
  • 適用シーン:日常の開発、質疑応答型の協業、コード review

これがデフォルトのモードで、ほぼ全員が使っているのは Turn-based です。長所は制御しやすいことで、短所は人から離れられないこと。真の自動化はできません。

2. 目標駆動ループ(Goal-driven)

/goal のようなコマンドで起動します。明確な受け入れ基準を与えると、Agent は反復とセルフチェックを続け、目標が達成されるまで止まりません。

  • トリガー方式:1 回だけ下すコマンド + 受け入れ基準
  • 停止条件:目標の達成 / 予算の超過
  • 適用シーン:「完了の定義」(Definition of Done)が明確なタスク。たとえば「すべてのテストをパスさせる」「ドキュメントを英語に翻訳して校正する」

💡 ヒント:目標駆動ループの成否は、受け入れ基準が検証可能かどうかだけで決まります。「コードをもう少しよく」のような曖昧な目標ではなく、「pytest 全緑、lint 警告ゼロ」のような実行可能なチェックを与えてください。

3. 時間駆動ループ(Time-driven)

/loop、/schedule のようなコマンド、あるいは cron / heartbeat との組み合わせで定時トリガーします。Agent は周期的に目を覚ましてタスクをこなします。

  • トリガー方式:固定の時間間隔(毎時、毎日、毎週)
  • 停止条件:手動キャンセル / 回数上限への到達
  • 適用シーン:定期点検(依存パッケージの脆弱性スキャン、ログ監視)、定期レポート(毎日のスタンドアップ要約)、周期的なメンテナンス(デッドコードの掃除)

この種のループは CI/CD と運用のシーンに最も向いており、Agent が「バックグラウンド常駐」に入る鍵となる形です。

4. イベント駆動ループ(Event/Hook-driven)

Git commit、Pull Request、ファイル変更などの外部イベントでトリガーされます。

  • トリガー方式:webhook、ファイルシステムイベント、CI イベント
  • 停止条件:イベント処理の完了
  • 適用シーン:コミット後の自動テスト実行、PR の自動 review、設定ファイル変更後の自動 reload

イベント駆動は最も徹底したエンジニアリングの形で、既存の DevOps パイプラインに Agent を組み込むことに相当します。

有効なループに必須の 5 要素

どの Loop を選ぶにせよ、公式は次の 5 つを明示的に設計するよう強調しています。さもないと、ループは暴走するか、無限ループに陥ります。

要素役割欠けたときの帰結
明確な目標 + 受け入れ基準Agent に「できた」の形を知らせる永遠に止まらない、産出が逸れる
ツールと権限の境界何を呼べて、何を呼べないかを限定する誤ってファイルを削除、権限越的操作
コスト/支出の上限(spend limit)token の暴走を防ぐ請求が爆発する
停止条件「いつ止めるべきか」を明示的に定義する無限ループ
検証ステップ産出が信頼できるかを確認する間違ったものをそのまま使う

この 5 項目のうち、支出上限と検証ステップが最も見落とされがちです。前者は財布を守り、後者は正しさを守ります。Agent が回した結果は、スクリプトやテストで自動検証できなければならず、「見た感じ正しい」で完成としてはいけません。

token を節約する 4 つのエンジニアリングテクニック

Loop を回し始めると最大のコストはコンテキストです。公式とコミュニティが示す最適化の道は、ほぼすべて「いかに token を少なく食べさせるか」をめぐります。

1. Dynamic Workflows で並列 Agent を編成する

1 つの Agent にすべてを直列にやらせるのではなく、複数の並列 sub-agent に分解します。1 個は分類、1 個は修正、1 個はレビュー。各 sub-agent は自分の小さなコンテキストの中だけで作業し、メインループは結果の収集だけを行います。

2. Auto Mode を有効にする

プロセスに人の介入を不要にさせます。明確な停止条件と組み合わせれば、Agent はあなたを煩わせることなく複数周回を連続で走れます。

3. コンテキストを引き締め、必要なときに読み込む

codebase 全体を流し込んではいけません。Claude Code のツールで必要なファイルだけを必要なときに読み、必要なときに grep し、コンテキストには現在のタスクに関係する部分だけを残します。

4. sub-agent でコンテキストを隔離する

メインループには要約だけを残し、詳細は sub-agent に独立したコンテキストで処理させてから結果だけを返させます。メイン Agent のコンテキスト膨張を抑える核心手段です。

理論的補強:Anthropic の 5 種類の Agent ワークフロー

Loop を設計するとき、土台には Anthropic が『Building Effective Agents』で整理した 5 種類のワークフローパターンを援用できます:

  • Prompt Chaining(プロンプトチェーン):大きなタスクを固定順序の小ステップに分解する
  • Routing(ルーティング):まず分類し、対応するハンドラに渡す
  • Parallelization(並列化):複数のサブタスクを同時に回す
  • Orchestrator-Workers(オーケストレーターとワーカー):中央の LLM がタスクを分解し、worker に割り当て、結果を集約する
  • Evaluator-Optimizer(評価と最適化):1 つが評価し、1 つが改良するフィードバックループ

この 5 パターンは組み合わせて入れ子にでき、複雑な Loop の骨格を構成します。

検証基準

設計の優れた Loop は、3 つの検証基準を満たすべきです:

  1. 観測可能:各ステップの入力、出力、token 消費が見える
  2. 中断可能:いつでも止められる。1 つのエラー状態で無限リトライしない
  3. 検証可能:産出の正誤をスクリプトやテストで自動判定できる

1 周回したあとに結果の正しさを人間が確認する必要がまだあるなら、検証ステップの設計が足りていません。戻って補いましょう。

よくある質問

  • Loop が一向に止まらない:90% は、受け入れ基準が曖昧すぎるか、spend limit がないのが原因です。まず硬い予算上限を加え、次に「完了」を実行可能なテストコマンドとして書き下してください。
  • コンテキストが長くなるほど遅くなる:sub-agent による隔離を採用してください。メイン Agent は要約だけを受け取り、元の内容は sub-agent の中で処理し切ったあと捨てます。
  • イベント駆動 Loop が CI で発火しない:webhook の認証とイベント payload の形式を確認してください。Claude Code のイベントフックは payload の schema に厳格な要求があります。

参考ソース