グラレコ
はじめに
Loop Engineering（ループエンジニアリング）は、AI エージェントに毎回プロンプトを書くのではなく、「エージェントが停止条件を満たすまで作業サイクルを繰り返す仕組み＝ループ」そのものを設計する、という考え方です。Anthropic は 2026年6月に公式ブログ「Getting started with loops」を公開し、ループを4つの型に整理して、どの型をいつ使うべきかの指針を示しました。
この記事では、その公式ブログを主軸に、Anthropic が考えるループ設計の全体像を整理します。具体的には、ループの定義と基本構造、4つのループ型（ターン型・ゴール型・時間型・プロアクティブ型）と使い分け、ループの品質を保つ4つの施策、そしてトークン消費の管理方法です。Claude Code を日常的に使っている方はもちろん、「エージェントに任せる範囲をもう一段広げたい」と考えている方に役立つ内容になっています。
一つだけ先に補足しておきます。「Loop Engineering」という呼び名自体は Anthropic の公式な製品名ではなく、2026年6月に Google の Addy Osmani 氏のエッセイをきっかけにコミュニティで広まった言葉です。Anthropic 公式ブログのタイトルはあくまで「loops」ですが、中身は同じ潮流を指しているので、本記事では通りの良い「Loop Engineering」の呼び名で進めます。
Loop Engineering とは：プロンプトの次に来た考え方 🧭
公式ブログはループをこう定義しています。
ループとは、停止条件が満たされるまで、エージェントが作業のサイクルを繰り返すこと。
単発のプロンプトとの違いは、反復・検証・自己修正が「構造」として組み込まれている点です。1回の指示で完璧な出力を引き出そうと言葉を磨くのがプロンプトエンジニアリングだとすれば、ループエンジニアリングは「多少の失敗はループが吸収する前提で、回り続ける仕組みと止まる条件を設計する」営みになります。
この転換を象徴するのが、Claude Code を率いる Boris Cherny 氏の発言です。The New Stack の記事によれば、氏はもう Claude に直接プロンプトすることはほとんどなく、「私の仕事はループを書くことだ（my job is to write loops）」と語ったとされています。エンジニアの仕事が「指示を出す人」から「指示を出す仕組みを作る人」へ一段メタに上がった、と言い換えられます。
この図のポイントは、人間の関与が「毎ターン」から「設計時と例外時」に移ることです。Addy Osmani 氏のエッセイにある「あなたはそれを一度だけ設計した。個々のステップには一切プロンプトしていない」という一文が、この状態をよく表しています。
ただし Anthropic は、なんでもループ化せよとは言っていません。公式ブログは「すべてのタスクに複雑なループが要るわけではない。最もシンプルな解から始めて、これらのパターンは選択的に使う」と明記しています。ここは読み飛ばされがちですが、いちばん実務的な注意点だと思います。
ループの基本構造：回る仕組みと止まる条件 ⚙️
具体的な型に入る前に、ループの共通構造を押さえておきます。どの型でも、中身は「トリガー → 作業 → 検証 → 停止判定」のサイクルです。
この図でいちばん大事なのは、真ん中の作業ではなく「停止条件」の菱形です。ループ設計の失敗は、たいてい「いつ止まるか」が曖昧なまま回し始めることから起きます。テストが全部通ったら、スコアが90を超えたら、5回試してだめだったら。こうした判定可能な条件を先に決めておくことが、後述するトークン管理にも直結します。
もう一つ、図に描かれていない大事な要素が「メモリ」です。モデルは実行のたびにコンテキストを忘れるので、ループをまたいで引き継ぐべき状態は markdown ファイルなどディスク上に残します。Osmani 氏も「メモリはディスクに置くしかない」と、外部メモリをループの必須部品に挙げています。
Anthropic が整理する4つのループ型 🔀
ここからが公式ブログの本題です。公式ブログは、ループを人間の関与が深い順に4つの型へ整理しています。
上から下に行くほど自律性が上がり、人間がループの外に出ていきます。まとめの表を先に置いてから、1つずつ見ていきます。
| 型 | トリガー | 停止条件 | 向いているタスク |
|---|---|---|---|
| ① ターン型 | ユーザーのプロンプト | Claude が完了 or 要確認と判断 | 短い・繰り返さないタスク |
② ゴール型（/goal） |
手動のプロンプト | ゴール達成 or 最大ターン数 | 検証可能な終了条件があるタスク |
③ 時間型（/loop /schedule） |
指定した時間間隔 | ユーザーの停止 or 作業完了 | 定期作業・外部システムとの連携 |
| ④ プロアクティブ型 | イベントやスケジュール | タスクごとにゴール達成で終了 | バグ triage・issue 管理・移行・依存更新 |
① ターン型：ふだんの対話も、実はループ 💬
いちばん身近な型です。ユーザーがプロンプトを送ると、Claude がコードを読み、編集し、テストを実行して結果を返す。ユーザーが確認して次のプロンプトを送る。この1往復がすでに小さなループになっています。
図の左側、「人が確認 → Claude が作業」へ戻る矢印がこの型のループです。1周ごとに人間が輪の中に入って確認するので、自律性は低いぶん安心感は最大になります。
ターン型を強くするコツとして、公式ブログは検証手順を SKILL.md に符号化することを勧めています。たとえばフロントエンドの変更なら、「開発サーバーを起動する → 変更箇所を実際に操作する → ブラウザコンソールのエラーを確認する → パフォーマンストレースを取る」という手順をスキルとして書いておくと、Claude が毎ターン自分で検証してから結果を返すようになります。人間の確認コストが1段減るわけです。
② ゴール型：/goal で「どこまでやるか」を渡す 🎯
ゴール型は、検証可能な終了条件を最初に渡して、達成するまで Claude に自走してもらう型です。Claude Code では /goal コマンドがこれにあたります。
/goal get the homepage Lighthouse score to 90 or above, stop after 5 tries.
（ホームページの Lighthouse スコアを90以上にする。5回試してだめなら止める、という指定です）
この型の良さについて、公式ブログは「Claude が『どこまでやれば十分か』を自分で判断しなくてよくなる」と説明しています。エージェントに任せると「このくらいでいいだろう」と早めに切り上げられてしまうことがありますが、ゴールを数値で渡せばその判断ごと外せます。逆に言うと、テストの通過数やスコアの閾値のような決定的な基準を用意できるタスクほど、この型が効きます。
図のポイントは「未達なら改善へ戻る」矢印です。改善 → 計測 → 判定の輪を人間なしで回り続け、条件を満たした（または上限に達した）瞬間だけ輪から抜けます。この「止まり方が保証されている」ことが、安心して放置できる根拠になります。
③ 時間型：/loop と /schedule で定期実行 ⏰
時間型は、決まった間隔でループを回す型です。Claude Code には2つのコマンドがあり、/loop はローカルマシンで、/schedule はクラウドで実行されます。
/loop 5m check my PR, address review comments, and fix failing CI
（5分ごとに PR を確認し、レビューコメントに対応し、落ちている CI を直す、という指定です）
PR のレビュー対応や CI の babysitting のように、「自分が張り付いて見ている必要はないが、放置もできない」作業と相性が良い型です。外部システム（GitHub、Slack、モニタリングツールなど）の状態が変わるのを待つ作業全般に使えます。
この型のループは「待機 → 起動」へ戻る外側の矢印です。1周の中身は毎回同じチェックの繰り返しで、ユーザーが止めるまで時計が回し続けます。
④ プロアクティブ型：人がいなくても動き出す 🤖
最後は、人間がリアルタイムで関与しないまま、イベントやスケジュールを起点に動く型です。バグ報告の triage、issue の整理、コードベースの移行、依存パッケージの更新といった「継続的に発生し続ける運用作業」が主戦場になります。
各タスクはゴールを達成すれば終わりますが、ルーチン自体は無効化するまで動き続けます。ここまで来ると、エージェントは「呼べば来るアシスタント」ではなく「常駐しているチームメイト」に近い存在です。
この図の外周が、プロアクティブ型のループです。個々のタスクはゴール達成で終わりますが、「タスク終了 → イベント待ちに戻る」の矢印によって、ルーチン全体は止まらずに回り続けます。
図の中にもう一つ仕込んであるのが、公式ブログが強調するモデルの使い分けです。定型的な仕分けは小さいモデルにルーティングし、判断が要る場面だけ高性能なモデルを使う。無人で回り続けるループはトークン消費も無人で積み上がるので、この設計がコストを大きく左右します。
どの型を選ぶか：選定の考え方 🗺️
4つの型は排他的ではなく、タスクの性質で選び分けます。公式ブログの整理を選定フローにするとこうなります。
迷ったら、シンプルな側（図の左上）に倒すのが公式の推奨です。ターン型で十分なタスクにプロアクティブ型を持ち出すのは、通勤に飛行機を使うようなもので、準備コストと運用コストが釣り合いません。
ループの品質を支える4つの施策 🧱
ループを長く回すほど、1回あたりの品質のブレが積分されて効いてきます。公式ブログは、ループの外側で効く4つのシステムレベルの施策を挙げています。
とくに4つ目の「二次レビュー」は、コミュニティ側で Verifier（検証者）パターンとして知られている考え方と重なります。Osmani 氏の言い方を借りると、「コードを書いたモデルは、自分の宿題を採点するには甘すぎる」。同じモデルでも、別の指示を持った第二のエージェントに見せると、書いた本人が理屈をつけて見逃した問題を拾えます。ループのボトルネックはモデルの能力ではなく検証の質だ、というのがこの界隈の共通見解になりつつあります。
そして公式ブログには、この4施策を貫く原則が書かれています。
結果が基準に届かなかったとき、個別の問題を直すだけで終わらせず、それをシステムに符号化して、以後のすべての反復を改善する。
レビューで同じ指摘を2回したら、その指摘はスキルか CLAUDE.md に書く。ループ運用の経験値を「人間の頭の中」ではなく「ループの部品」に貯めていく、という発想です。
トークン消費の管理：ループは回り続ける 💸
ループは便利な反面、回り続けるぶんトークンを消費し続けます。公式ブログが挙げる管理策を表にまとめます。
| 施策 | 内容 |
|---|---|
| 道具をタスクに合わせる | プリミティブ（型）とモデルをタスクの複雑さに合わせる。仕分けは小型モデル、判断だけ高性能モデル |
| 停止基準を具体的に | 成功・停止条件が曖昧だと探索が長引く。決定的な基準ほど早く収束する |
| 小さく試してから広げる | 動的ワークフローはまず小さいデータ片でパイロットし、それからスケールする |
| 決定的な作業はスクリプトに | 手順が決まっている処理は、モデルに推論させずスクリプトで実行する |
| 間隔を実態に合わせる | 定期ループの間隔は、監視対象が実際に変化する頻度に合わせる（5分ごとに見る必要がないものを5分ごとに見ない） |
計測の道具も用意されています。/usage でスキル・サブエージェント・MCP 別のトークン内訳を確認でき、/goal を引数なしで実行すると、そこまでのターン数・トークン使用量が表示されます。試行回数の上限をかけたいときは、先ほどの例のように「stop after 5 tries」とゴール文の中に書きます。複数エージェントを走らせる場合は /workflows でエージェント別の消費を追えます。
💡 個人的には「決定的な作業はスクリプトに」がいちばん費用対効果が高いと感じます。たとえばファイルのリネームや定型的な集計をエージェントの推論でやらせると、同じ結果に毎回数千トークン払うことになります。1回スクリプト化すれば、以後はゼロです。
実践レシピ：型を合成して1つの運用ループを作る 🍳
4つの型と部品は組み合わせられます。公式ブログに載っている合成例が、到達点のイメージとしてわかりやすいので紹介します。
/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.
（毎時 #project-feedback チャンネルのバグ報告を確認し、見つけた報告がすべて triage・対応・返信されるまで止まらない。バグ修正では、並列の worktree で3案を探索し、判定役のエージェントに敵対的にレビューさせる、という指定です）
この1つの指定の中に、これまでの要素が全部入っています。
時間型（/schedule）が外側の起動を担い、ゴール型（/goal)が「どこまでやるか」を保証し、ワークフローと worktree が並列探索を、判定エージェントが検証を担う。1時間ごとに、この一連の流れが人間の同席なしで回ります。まさに「一度設計すれば、個々のステップにはプロンプトしない」状態です。
とはいえ、最初からこれを組む必要はありません。ターン型で手応えを確かめ、検証をスキルに落とし、/goal で自走させてみて、うまく回る実感が持てた作業だけを /schedule に昇格させる。この段階を踏むのが、公式ブログの「シンプルから始める」哲学とも整合する進め方です。
まとめ
この記事でいちばん持ち帰ってほしいのは、「ループの設計とは、作業の自動化ではなく停止条件と検証の設計だ」という点です。4つの型（ターン型・ゴール型・時間型・プロアクティブ型）はどれも、「いつ止まるか」「どう検証するか」が決まっていて初めて安心して回せます。逆にそこさえ決まれば、人間はループの中から外へ、設計者の位置に移れます。
次のステップとしては、いま毎日手でやっている作業を1つ選んで、/goal に渡せる終了条件を書いてみるのがおすすめです。条件が書ければゴール型に、書けなければまだターン型に留める。その判断自体が、Loop Engineering の最初の一歩になります。
本記事では扱いませんでしたが、ループを支える個々の部品（Skills・サブエージェント・MCP・hooks）の設計や、長時間ループにおけるメモリ管理も深いテーマです。公式ドキュメントとあわせて掘ってみてください。