AnthropicのClaude Codeチームは2026年6月30日、AIコーディングエージェントを使う際のループの考え方を紹介する記事「Getting started with loops」を公開した。この記事ではループを「エージェントが停止条件を満たすまで作業サイクルを繰り返すもの」と定義している。プロンプトを毎回入力する使い方だけでなく、終了条件や実行間隔を設計して作業を継続させるパターンを取り上げている。
記事では、ループの分類にあたって、何をきっかけに動くか、どの条件で止まるか、Claude Codeのどの基本機能を使うか、どの種類の作業に向くかという観点を挙げている。すべての作業で複雑なループが必要になるわけではなく、まずは最も単純な方法から始め、必要な場面で選択的に使うよう勧めている。
ターンベース、 ゴールベース、 時間ベース、 プロアクティブの4分類
ループは大きく4種類に分けられる。各分類は独立した機能一覧ではなく、作業のきっかけ、停止条件、使うClaude Code機能に応じて選ぶものとして紹介されている。
ターンベースのループ
最も基本的なターンベースのループは、ユーザーのプロンプトをきっかけに始まる。ユーザーが依頼すると、Claudeはコードを読み、編集し、テストし、必要に応じて作業を繰り返す。Claudeが作業を完了した、または追加の文脈が必要だと判断した時点で応答し、そこで1回のターンが終わる。作業後の確認や次の依頼はユーザーが行うため、各ターンを人間が進める形になる。そのため、短い作業や定期的でない作業に向く。
Claudeが作業完了前に行う自己検証の精度を上げる方法として、人間が行っている確認手順をSKILL.md に記述する例も取り上げている。この例では、UI変更を編集だけで完了扱いにせず、開発サーバーを起動してUIを操作し、コンソールエラーの有無やパフォーマンスも確認する。手順のどこかで失敗した場合は修正して最初から確認し直し、部分的に検証した状態では完了報告しないようにする。
ゴールベースのループ
1回のやり取りでは足りない複雑な作業には、/goalを使う。完了条件をあらかじめ指定すると、評価モデルが条件を確認する。条件を満たしていなければClaudeは再び作業に戻る。ループは、条件を満たすか、指定したターン数の上限に達した時点で終了する。
この種のループでは、テストの通過数やLighthouseスコアのしきい値のように、機械的に確認できる条件が効果的だとしている。例として、ホームページのLighthouseスコアが90以上になるまで最大5回試す/goalコマンドを紹介している。
時間ベースのループ
定期的な作業や外部システムの変化に反応する作業には、時間ベースのループを使う。/loopは指定した間隔でプロンプトを再実行する機能で、ユーザーがキャンセルするか、プルリクエストのマージやキューの解消のように対象の作業が完了すると止まる。例として、5分ごとにプルリクエストを確認し、レビューコメントやCIの失敗に対応する使い方が挙げられている。
ただし/loopはユーザーのコンピューター上で動くため、そのコンピューターの電源を切ったり、Claude Codeを実行している環境を終了したりすると停止する。クラウド側に移したい場合は、ルーチンを作成する/scheduleを使う。
プロアクティブなループ
ユーザーがその場で促さなくても進めたい作業には、プロアクティブなループを使う。Issue作成やフィードバック投稿、定期チェックのようなイベントやスケジュールをきっかけに動き、人間がリアルタイムで介在しない作業を対象にする。個々の作業は目標達成で終了する一方、ルーチン自体はユーザーが停止するまで継続する。このため、バグ報告、Issueのトリアージ、移行作業、依存関係の更新など、繰り返し発生し、かつ手順を定義しやすい作業に向くとしている。
組み合わせ例では、/scheduleやDynamic workflows（いずれもresearch preview）に、/goalとAuto modeを組み合わせる。これにより、フィードバックの確認、報告の分類、修正案の並行検討、レビューまでを進める流れを紹介している。
品質維持とトークン管理もループ設計の一部
品質を保つうえでは、ループそのものだけでなく、ループを支える仕組みも重要になる。Claudeは既存のコードベースのパターンや慣習に従うため、コードベース自体を整えておく必要がある。あわせて、利用者やチームが考える「よい結果」をスキルに記述し、Claudeがその基準で自己検証できるようにすることも挙げている。フレームワークやライブラリのドキュメントへアクセスしやすくすることや、別のエージェントにコードレビューを担当させることも品質維持に関わる。個別の結果が基準を満たさなかった場合も、その場の修正だけで終わらせず、今後の反復に効く仕組みとして記述していくことを勧めている。
トークン使用量の管理については、作業に合った機能とモデルを選ぶこと、成功条件と停止条件を明確にすること、小さな範囲で試してから大きく回すことを勧めている。手順が決まっていて自動処理できる作業は、推論を重ねるのではなくスクリプトに任せる考え方も挙げている。繰り返し実行する作業では、対象の変化に合わせて実行間隔を調整することも重要になる。Dynamic workflowsでは多数のエージェントを起動する場合があるため、大規模に実行する前に利用量を確認する必要がある。/usage、/goal、/workflowsを使えば、スキルやサブエージェント、MCPを使った外部連携、各エージェントのトークン使用量も確認できるとしている。
最初はボトルネックになっている作業から
記事のまとめでは、まず自分がボトルネックになっている作業を1つ選び、どの部分をエージェントに渡せるかを考えることを勧めている。確認手順を書けるか、ゴールは明確か、作業は決まったタイミングで発生するかを見極める。そのうえで実際にループを回し、どこで止まるか、どこでやり過ぎるかを観察しながら改善していく、という進め方を紹介している。
なお、この解説はClaudeDevsアカウントのXの記事投稿 としても掲載されている。
コラム： ループ設計に関わるモデル選択とeffortレベルAnthropicは2026年7月7日、Claude Codeのモデル選択とeffortレベルを解説する記事も公開した。Claude Codeでループを回す際には、どの機能を使うかに加え、どのモデルを選ぶか、どの程度の作業量で動かすかによっても、結果やコストが変わる。
この記事によると、モデル選択はどのモデルの固定された重みを使うか、つまりモデル自体の能力範囲を選ぶ設定になる。effortレベルは単に考える時間を延ばす設定ではなく、Claudeがどれだけファイルを読み、ツールを使い、検証し、何段階まで進めてからユーザーに戻るかに影響する。
ループがうまくいかない場合は、まずプロンプトが曖昧でないか、CLAUDE.md やスキル、ツール、タスク範囲が適切かを見直すとしている。そのうえで、モデルが十分な知識を持たないのか、十分に試していないのかを分けて考える必要がある。必要な文脈を与え、適切なスキルやツールを使える状態にしても間違うなら、より大きなモデルを選ぶ判断になる。逆に、ファイルを読まない、テストを実行しない、途中で作業を切り上げるといった失敗であれば、effortレベルを上げる判断になる。
また、多くの作業では各モデルのデフォルトのeffortレベルから始め、タスクごとではなく作業の種類に応じた設定として調整することを勧めている。単純な作業では小さなモデルで速度やコストを抑え、曖昧な設計判断や複雑な不具合調査では大きなモデルを選ぶ、という考え方になる。ループの記事で示された「作業に合った機能とモデルを選ぶ」「 小さく試してから大きく回す」という観点を、モデルとeffortレベルの面から補足している。
コラム： AIエージェントのループを支えるハーネスエンジニアリングThinking Machines Lab共同創業者のLilian Weng氏は2026年7月4日、再帰的自己改善（RSI）の文脈からハーネスエンジニアリングを扱うブログ記事を公開した。ここでいうRSIは、AIが自らの能力を高める仕組み自体を改善していくフィードバックループを指す。RSIを主題にした記事だが、AIエージェントをどう動かし、検証し、改善するかを支えるハーネスの設計を論じている。
Weng氏はハーネスを、ベースモデルの周囲で実行を制御し、モデルの思考や計画、ツール呼び出し、文脈管理、成果物保存、結果評価を扱う仕組みと説明している。記事では、Claude CodeやCodexなどを例に、モデル単体ではなく、その周囲の実行システムも重要だと述べている。
そのうえで、初期のエージェントフレームワークに比べ、ハーネスエンジニアリングにはワークフロー設計、評価、権限制御、永続的な状態管理なども含まれるとしている。プロンプトテンプレートだけでなく、モデルが観察し、行動し、記憶し、自己確認し、改善するための実行環境やソフトウェアシステムの設計に近い領域として扱っている。
ワークフロー自動化の例として、計画、実行、観察・テスト、改善、再実行をゴール達成まで繰り返すループを挙げている。このパターンでは、静的なプロンプトテンプレートではなく、実行中の失敗や進捗を見ながら反復する点にも触れている。
また、長い作業ではログや成果物がコンテキストウィンドウより大きくなるため、ファイルシステムを永続的なメモリとして使う考え方も取り上げている。並列実行については、複数のサブエージェントを動かし、実験や検証などのバックグラウンド実行を起動・ログ確認・中断・結果統合できるようにする設計を挙げている。こうした設計は、Claude Codeの記事で触れられたサブエージェントやDynamic workflows、トークン管理とも関係してくる。
記事後半では、最適化対象がプロンプト、構造化された文脈、ワークフロー、ハーネスコード、さらにハーネスを最適化するコードへ広がっていく流れも整理している。この流れの延長で、ハーネス自体を改善対象にする例としてメタハーネスに触れている。メタハーネスは、エージェントが何を記憶し、何を検索し、どの情報をモデルに渡すかを決めるハーネス側のコードを最適化する仕組みで、いわばハーネスそのものを改良するためのハーネスである。
ただし、エージェントによる自己改善の対象を実行基盤まで広げるほど、編集可能な範囲の設計も重要になる。Weng氏は、プログラムがOSのような基盤まで編集できると、何を編集可能にし、何を保護するかという境界が崩れる懸念を挙げている。そのため、権限制御やセキュリティ層はこのループの外に置く必要があるとしている。
Weng氏は、近い将来の現実的な道筋は、モデルの重みを直接書き換えることよりも、ハーネスエンジニアリングを発展させる方向にあると見ている。将来的にハーネスの改善がモデル側の能力に取り込まれていく可能性に触れつつも、エージェントを動かすうえでゴール、制約、文脈、評価を指定する必要は残るとしている。ループを単なるプロンプトの反復ではなく、何を目標にし、何を文脈として渡し、どう検証して止めるかまで含めて設計する問題として扱っている。
コラム： プロンプトからループ設計へエンジニアのAddy Osmani氏は2026年6月7日、ブログ記事「Loop Engineering」で、コーディングエージェントとの関わり方が、個別にプロンプトを書くことから、エージェントを動かすループを設計することへ移りつつあるとの見方を示している。Osmani氏はループを、目的を定義し、AIが完了まで反復する仕組みとして捉えている。
この記事では、ループに必要な部品として、スケジュールで動く自動化、並列作業を分離するworktree、プロジェクト知識を記述するスキルを挙げている。さらに、外部ツールにつなぐプラグインやコネクター、実装と検証を分けるサブエージェント、作業状態を残すメモリにも触れている。
Osmani氏は、こうしたループを、一度きりの実行ではなく、作業を見つけ、割り当て、検証し、結果を記録し、次に何をするかを決める小さなシステムとして見ている。Claude Codeの記事がループの種類や使い分けを示しているのに対し、Osmani氏の記事は、そのループを成り立たせる要素に焦点を当てている。
そのうえで、Osmani氏は7月8日、Xの記事投稿「Own the Outer Loop」で、エージェントが内側で調査、実装、検証、反復を担う場合でも、成果を本番環境や連携先のシステムへ渡すかどうかは人間が判断する必要があると述べている。この人間側の判断領域を外側のループとして捉え、Quality、Verdict、Answerabilityという3つの用語で整理している。
ここでいうQualityは、エージェントの成果をそのまま外へ出さないためのチェックや制約を指す。テスト、ログ、監査記録、サンドボックスの制限などの品質シグナルを集め、Verdictの判断材料にする。Verdictは、その材料をもとに成果を本番環境や連携先のシステムへ渡すかを決める最終判断で、リリース、停止、方向転換、応答範囲の縮小、ガードレール追加、却下などを含む。Answerabilityは、何を変え、なぜ安全と見なしたのか、間違っていた場合に何が起きるのかをあとから説明できる状態を指す。
また、この投稿では、AI支援コードの増加に伴うレビューや検証の不足、AIの出力を無批判に受け入れること、コードへの理解が薄れること、複数エージェントを回す運用負荷などにも触れている。これらの論点は、Claude Codeの記事で扱う実行ループを広げていく際に、判断、検証、説明責任を担う仕組みをどこに置くかという問題にもつながる。
コラム： OpenAI Cookbookが示す修復ループと改善ループOpenAIは2026年5月11日と12日、OpenAI CookbookでCodexやAgents SDKを使ったループの実装例も公開した。Codexを使った例は、単一の成果物を検証しながら直す修復ループの実装例になっている。Agents SDKの例は、実行トレースや評価セット（evals）を使い、エージェントのハーネス改善に戻すループを実装している。Claude Codeの記事がユーザーの作業単位でループをどう回すかを取り上げているのに対し、これらのCookbook記事では、検証結果や実行履歴を次の修正に戻す流れがコード例として具体的に示されている。
Codexを使った修復ループでは、エージェントが成果物を作り、検証し、そのフィードバックを次の修正に使うワークフローを紹介している。具体的には、レビューで構造化された指摘を出し、修復で対象のコピーに必要な変更を加え、検証で残る問題を確認する。検証結果は次の修復入力として戻される。この例では、Codex CLIをヘッドレスモードで実行し、各反復の結果をrecord.json として残す。本番向けの停止条件として、検証の通過、最大試行回数への到達、残る問題が変わらないこと、人間によるレビューが必要になることも挙げている。
Agents SDKの改善ループでは、個別の成果物を直す手順ではなく、エージェント運用から得た情報をハーネスの改善に戻している。実行トレース、ユーザーやモデルからのフィードバック、評価セット、Codexによる実装をつなぎ、実際の挙動から見つかった問題を再実行できる評価セットに変換する。そのうえで、ハーネスの変更候補を作り、Codexに渡すためのハンドオフ文書を生成する。ここでのハーネスは、指示、ツール、ルーティング、出力要件、検証条件など、エージェントの振る舞いを形づくる構成を含む。自動化する構成では、ハンドオフ文書を共有ストレージなどに置き、Codex側の自動化が新しいハンドオフを検知して次の実装処理を起動する方法も紹介している。
どちらの例でも、1回の出力で終わらせず、レビューや検証で得た証拠を次の変更に戻す点が共通している。Agents SDKの例では、トレース確認、評価セットの調整、プルリクエスト承認、マージ、デプロイなどを人間の確認点として残せるとしている。人間は、どのフィードバックを評価項目として残すか、どの変更を実装・展開するかを判断する。
コラム： 評価を改善ループに組み込むReplitの取り組みReplitは2026年6月23日、Replit Agentの評価と改善を大規模に進める取り組みを紹介するブログ記事を公開した。Replit Agentは、ユーザーが自然言語で指示した内容をもとにアプリなどの成果物を作るエージェントで、記事では本番環境での利用から見つかった失敗を評価や修正候補の作成に戻していく製品改善のループを扱っている。
Replitは、Replit Agentの評価をリリース前の判定にとどめず、改善ループの一部として扱う考え方を示している。Replit Agentを使って開発するユーザーは、既存のリポジトリやテストスイートを持ち込むとは限らず、エージェント側が構成や実装を選ぶ。そのため、既存コードや固定テストを前提にした評価だけでは、ユーザーが求める「動くアプリ」かどうかを十分に測れないという。
そこでReplitは、オフラインベンチマーク、本番でのA/Bテスト、本番トレースの分析を組み合わせている。同社のvibe coding向けエンドツーエンド評価ベンチマークViBenchでは、自然言語で書かれた要件をもとに作られたアプリが仕様を満たすかを見る。A/Bテストでは、プロンプト、ツール、ハーネスの変更、モデル変更などが実際のユーザー行動にどう影響するかを確認する。さらにTelescopeという仕組みで本番トレースをクラスタリングし、集計指標だけでは見えない、繰り返し発生する失敗パターンを洗い出す。
測定の仕組みが整うと、次の課題は、見つかった失敗を修正案に変えることになる。Replitの記事で示された改善ループは、おおまかに次の流れになる。
失敗の把握 : 本番ログ、トレースクラスタ、最近の失敗を読み、検証すべき仮説を選ぶ。修正候補の作成 : Replit Agentの修正候補を作り、理由を添えてドラフトPRを開く。候補の検証 : ViBenchやA/Bテストの結果、実行過程のデータ、比較対象となる直近の結果と照らして候補を評価する。 判断材料の準備 : リリースするか、修正を続けるか、破棄するかを判断するための材料を用意する。
ただし、リリース判断は自動化せず、エンジニアが結果をレビューして決める。
Replitの記事では、ループを単に同じ作業を繰り返すものではなく、失敗の発見、失敗パターンの整理、修正候補の作成、評価、人間によるリリース判断までをつなぐ仕組みとして扱っている。Claude Codeの記事にある個々の作業ループとは別に、運用中のエージェントを継続的に改善する流れまでをループとして取り上げている。
