AIコーディングの「ループ」4種類を完全入門 Anthropic公式が分かりやすく整理して解説Deep Insider Brief ― 技術の“今”にひと言コメント

Anthropicが、Claude Codeにおける「ループ」を4種類に整理して解説した。AIコーディングで何をAIに任せ、どこで止めるべきかを、初心者にも分かるようにかみ砕き、筆者なりの視点も添えて紹介する。

» 2026年07月07日 05時00分 公開
[一色政彦デジタルアドバンテージ]

この記事は会員限定です。会員登録(無料)すると全てご覧いただけます。

「Deep Insider Brief ― 技術の“今”にひと言コメント」のインデックス

連載目次

 AIコーディングツール「Claude Code」の開発チームが、「ループ」の使い方を解説した記事「Getting started with loops(ループ入門)」を2026年6月30日付けで公開した。最近、AIコーディングの文脈では「エージェントにプロンプト(AIへの指示文)を打つ」のではなく「ループを設計する」という言い回しを見かけるようになったが、その「ループ」が具体的に何を指すのかは、語る人によってまちまちだ。今回の記事は、そのあいまいになりがちな言葉を、4種類に整理して解説しているので紹介したい。

 とはいえ、新しい機能が発表されたわけではない。この記事の価値は、これまでぼんやりと「ループ」とひとくくりにされてきたものを、起動の仕方止まり方という切り口で分類し、共通の言葉として語れるようにした点にある。AIエージェントの自律性(人間の指示なしに自分で判断して動く度合い)を、制御しやすい4つのデザインパターン(設計の型)として言語化した、と言い換えてもよい。また、それぞれがClaude Codeのコマンドや機能と結びつけて説明されているのも分かりやすい。

4種類のループを、起動方法・繰り返す作業の内容・停止条件の観点で整理したまとめ図(本記事オリジナル) 4種類のループを、作業の進め方・起動方法・自律性の観点で整理したまとめ図(本記事オリジナル)

 元記事ではまず、ループを「停止条件(stop condition:処理を止める条件)が満たされるまで、エージェントが作業のサイクルを繰り返すこと」と定義する。その上で、次の4つの観点でループを分類している。

  • どう起動するか: トリガー(きっかけ)
  • どう止まるか: 停止条件
  • どの機能を使うか: プリミティブ(Claude Codeでループを構成する基本機能)
  • どんな作業に向くか: 用途

 図に示した4種類のループは、2つの軸で見ると分かりやすい。縦軸は「指示・設定に従って動くか、AIの自律性が高いか」、横軸は「1つの作業を進めるか、作業を起動・監視するか」である。普段のやりとりである「ターンベース(Turn-based)」、完了条件を決めて自走させる「ゴールベース(Goal-based)」、一定間隔で繰り返す「タイムベース(Time-based)」、人間がリアルタイムで関与しない「プロアクティブ(Proactive)」という4つは、この2軸で整理すると違いが見えやすい。

――ここで、この4分類をどう受け止めればよいか。『Deep Insider Brief』恒例の“ひと言コメント”として、筆者の考えを先に述べておきたい。その後で、4種類のループを一つずつ、できるだけかみ砕いて整理していく。


一色政彦

 Deep Insider編集長の一色です。こんにちは。

 今回の記事で面白いのは、AIコーディングにおける「ループ」の種類を、Claude Codeですぐに試せるスラッシュコマンドや実行パターンに対応させて、かなり実務的に整理している点です。

 私自身は先週公開した記事で、AIエージェント自らが内部で自律的に回す「内側ループ」と、AIエージェントの外部にあるハーネス(エージェントを動かす実行レイヤー)がスケジュールやキューを見るなどしてプロアクティブに回す(=人間のその場の指示を待たずに、必要なタスクを起動する)「外側ループ」という見方を紹介しました。今回のAnthropic記事は、その考え方ともかなり整合すると感じました。

 具体的には、「ターンベース」と「ゴールベース」は内側ループに近く、「タイムベース」と「プロアクティブ」は外側ループに近いと考えられます。先ほど掲載した図に従うと、「1つの作業(タスク)を進める=目標まで続けて完了させる」サイドが内側ループ寄りで、「作業を起動・監視する=次の実行を起動し続ける」サイドが外側ループ寄りです。

 もちろん、これは筆者なりの読み替えです。Anthropicの記事そのものは、「内側ループ/外側ループ」という言い方ではなく、turn-based、goal-based、time-based、proactiveという4分類で説明しています。つまり、ループの概念を別の角度から見た整理です。先週の記事で「ループエンジニアリングが少し難しい」と感じた人でも、今回のAnthropic記事の観点なら理解しやすいという場合もあるかもしれません。だからこそ、別の角度からもう一度書く価値があると思いました。

 ただし今回、私が特に気になったのは、停止条件Stop Condition)をかなり前面に出していることです。AIエージェントは、放っておくとトークン(AIが処理する文字の単位)や実行時間をどんどん消費します。だからこそ、「どこまでやったら止めるか」を先に決めておくことが大事だと思います。

 一方で、/scheduleコマンドのような仕組みでは、個々のタスク(ターンベース/ゴールベースに近い内側の作業)は止まりますが、ルーティン(定期実行される処理)自体はユーザーが止めるまで動き続けます。/loopコマンドも一定間隔で処理を繰り返しますが、ローカル環境で動くため、どちらかといえば簡易的なハートビート(定期的な実行)に近い印象です。

 つまり、外側の仕組みは次の実行を待ち続けるが、内側の1タスクは必ず止まる、という二層構造で理解すると分かりやすいです。いずれにせよ、前回の記事で紹介した内側ループ/外側ループという見方に、今回の4分類という補助線が加わることで、ループエンジニアリングをより多角的に捉えられるようになったと思います。こうしてループの種類をはっきり分けて考えられるようになったこと自体が、Anthropicの記事の一番の功績ではないでしょうか。


 それでは、記事が挙げた4種類のループを、初心者にも分かるように順に整理していく。

Anthropic直伝「4種類のループ」

ターンベース: 人が都度指示して進める

 最もシンプルで、普段のClaude Code利用がこれに当たる。プロンプトを1回送るたびに、AIが情報を集め、実行し、自分の作業を確認し、必要なら繰り返して、結果を返す。その後は人間が結果をチェックし、次のプロンプトを打つ。この人間とAIの1往復が基本の単位だ。

ターンベースのループ(元記事の図を引用し、日本語に加工) ターンベースのループ(元記事の図を引用し、日本語に加工)

  • 起動: あなたのプロンプト
  • 停止: AIがタスク完了と判断した時点、または追加の文脈(コンテキスト:作業に必要な追加情報や判断)が必要だと判断した時点
  • 向く作業: 定型の手順に乗らない、短めのタスク
  • コツ: 確認の手順をSKILL.mdファイル(AIに作業のやり方を教える設定ファイル)に書いておくと、AIが自分でより多くのチェックをこなせるようになる

ゴールベース: ゴールを決めて自走させる(/goal)

 1回のやりとりでは足りない、少し複雑なタスク向け。人間が「完了とはどういう状態か」を決めると、AIはそれを満たすまで反復する。ポイントは、AIが「もう十分だろう」と勝手に早く切り上げないよう、達成したかどうかの判定を別の小さなAIモデル(評価モデル)に任せる点にある。だからこそ、テストが通る、スコアが基準を超える、といった測定できる条件を設定すると、とても効果的に働く。

ゴールベースのループ(元記事の図を引用し、日本語に加工) ゴールベースのループ(元記事の図を引用し、日本語に加工)

  • 起動: 手動のプロンプト
  • 停止: ゴール達成、または決めておいた最大ターン数(往復回数)に到達
  • 向く作業: 合否をはっきり判定できるタスク
  • コツ:/goal ホームページのLighthouse(Webページの品質を測るGoogleのツール)スコアを90以上にする。5回試したら停止」のように、達成条件と試行回数の上限をセットで指定する

タイムベース: 一定間隔で繰り返す(/loop・/schedule)

 作業の中身は同じで、入力だけが変わっていくような、繰り返しの作業に向く。例えば毎朝Slack(チャットツール)のメッセージを要約する、といった用途だ。あるいは、PR(プルリクエスト:コード変更の提案)にレビューが付いたり、CI(自動テストの仕組み)が失敗したりといった、外部の状況の変化に反応させる使い方もできる。

 /loopコマンドは、指定した間隔でプロンプトを再実行する。ただし、これは自分のPC上で動くため、PCを閉じると止まる。クラウド側で動かし続けたい場合は/scheduleコマンドでルーティン(定期実行)にする。

 ちなみに、ClaudeデスクトップアプリのClaude Code画面には「ルーチン(Routines)」という機能がサイドバーに用意されており、スケジュール実行でClaude Codeの処理を起動できる(実行はローカル/クラウドから選べる)。元記事はCLIコマンドを中心に説明しているが、画面から定期実行を作れる機能もあると覚えておくとよい。筆者もこの定期実行機能を愛用している(……いつの間にか筆者もループエンジニアリングしていました)。

タイムベースのループ(記事内容から独自に起こした図) タイムベースのループ(記事内容から独自に起こした図)

  • 起動: 指定した時間間隔
  • 停止: あなたがキャンセルするか、作業が完了したとき(PRがマージ《反映》された、キューが空になった、など)
  • 向く作業: 定期的な繰り返し作業や、外部システムとの連携
  • コツ:/loop 5m PRを確認し、レビューコメントに対応し、失敗したCIを修正」のように、間隔(この例では5分)と作業を指定する

筆者注: /loopと/scheduleの分類について

 元記事は/loop/scheduleの両方を、同じ「タイムベース」に分類している。ただし本稿では、クラウドでスケジュールに従って起動する自律性の高さに注目し、まとめ図では/scheduleを次の「プロアクティブ」寄りに置いて整理した。/loopはローカルで動く簡易な“ハートビート”、/scheduleは外側ループを支える“ハーネス”、という違いを意識すると分かりやすい。


プロアクティブ: 人がその場にいなくても動く

 人間がリアルタイムで関与しない、最も自動化された形だ。これまでの機能に加えて、AIに許可を求めさせず自動で進める「auto mode(オートモード)」や、複数のAIを連携させる「dynamic workflows(動的ワークフロー、研究プレビュー段階)」などを組み合わせて、長時間の作業を回す。例えばバグ報告への対応なら、/scheduleで定期的に新しい報告をチェックし、/goalで「完了とは何か」を定義し、SKILL.mdで検証の手順を記し、複数のAIエージェントに調査・修正・レビューを分担させ、auto modeで止まらずに走らせる、という組み立てになる。

プロアクティブなループ(元記事の図を引用し、日本語に加工) プロアクティブなループ(元記事の図を引用し、日本語に加工)

  • 起動: イベントやスケジュール(人間はリアルタイムでは不在)
  • 停止: 個々のタスクはゴールを満たせば終了。ただしルーティン自体は、あなたが止めるまで動き続ける
  • 向く作業: バグ報告、Issue(課題)の仕分け、コードの移行、依存関係の更新など、繰り返し発生する定型作業
  • コツ: 判断が必要な部分は最も賢いモデルに任せ、単純な部分は小さく速いモデルに振り分けてコストを抑える

品質とコストを保つコツ

 ループの成果は、AIそのものよりも「その周り(=ハーネス)をどう作るか」で決まる、と記事は説く。まず、品質を保つためのコツは次の通りだ。

  • コードベースをきれいに保つ: AIは既存のコードの書き方や慣習をまねるため、土台が整っているほど良い出力になる
  • AIが自分の作業を検証できるようにする: 「何を良しとするか」をSKILL.mdなどに書いて渡す
  • ドキュメントに届きやすくする: フレームワークやライブラリの公式文書には最新のベストプラクティスがある
  • コードレビューには第2のエージェントを使う: 実装を担当したメインエージェントとは別に、レビュー担当のエージェントを立てる。新しい文脈で確認するため、メインエージェントの思考(リーズニング)に引きずられにくい
  • 失敗を次回に生かす: 個別の問題を直すだけでなく、同じ失敗を防げるように手順や検証条件へ反映する

 次に、コスト(AIの利用料は「トークン」という単位で消費される)を抑えるコツはこうだ。

  • 作業に合った機能とモデルを選ぶ: 小さな作業に、わざわざ複数のAIや複雑なループは要らない
  • 完了と停止の条件をはっきり決める: 何をもって完了とするかが明確なほど、無駄な反復が減る
  • 大規模に回す前に小さく試す: dynamic workflows(動的ワークフロー)は数百のエージェントを動かすこともあるため、まず一部で試して消費量を見積もる
  • 決まりきった処理はスクリプトにする: 毎回AIに考えさせるより、あらかじめ用意したスクリプトを実行する方が安い
  • 必要以上に頻繁に回さない: 監視する対象が変わる頻度に、実行間隔を合わせる
  • 使用量を確認する: /usageコマンドで、現在の使用量や、このセッション内の入力トークン・出力トークン、キャッシュ読み取り/書き込みのトークン量などを確認できる

どのループから始めればいいか

 記事は最後に、「まず自分がボトルネック(作業の停滞点)になっている作業を1つ選び、その一部を手放せないか考えてみよう」と勧めている。目安になるのは、次の3つの問いだ。

  • 検証のチェックを自分で書けるか: 書けるなら、SKILL.mdで自己検証を仕込んだ「ターンベース」から
  • 「完了」の形がはっきりしているか: はっきりしているなら、「ゴールベース」(/goal)へ
  • 作業は決まった時刻やイベントで発生するか: そうなら、「タイムベース」や「プロアクティブ」(/loop/schedule)へ

 いきなり複雑なループを組む必要はない。まずは一番シンプルな形から始め、どこで詰まり、どこでやり過ぎるかを観察しながら、少しずつ育てていけばよい。種類を知っておくことは、その第一歩になるはずだ。

「Deep Insider Brief ― 技術の“今”にひと言コメント」のインデックス

Deep Insider Brief ― 技術の“今”にひと言コメント

Copyright© Digital Advantage Corp. All Rights Reserved.

アイティメディアからのお知らせ

スポンサーからのお知らせPR

注目のテーマ

その「AIコーディング」は本当に必要か?
Microsoft & Windows最前線2026
4AI by @IT - AIを作り、動かし、守り、生かす
ローコード/ノーコード セントラル by @IT - ITエンジニアがビジネスの中心で活躍する組織へ
Cloud Native Central by @IT - スケーラブルな能力を組織に
システム開発ノウハウ 【発注ナビ】PR
あなたにおすすめの記事PR

RSSについて

アイティメディアIDについて

メールマガジン登録

@ITのメールマガジンは、 もちろん、すべて無料です。ぜひメールマガジンをご購読ください。