1. 「1回指示して終わり」の限界

本記事で扱う機能名・仕様は2026年7月時点でclaude.comが公開しているClaude Code公式ドキュメントの記載に基づきます。今後のアップデートで名称・挙動が変わる可能性があるため、実際に使う際は必ず公式ドキュメントで最新情報をご確認ください。

普段AIを使うとき、ほとんどの人がやっているのは次のようなやり取りです。指示を出す、AIが答える、内容を見て次の指示を出す。これは1つのタスクを1回のターン（やり取り）でやり切る、ごく普通の使い方です。プロンプトの精度を上げれば、この1回のやり取りの質は上がります。

しかし、次のような仕事は「1回の指示」では完結しません。

• 達成条件は分かっているが、そこに至るまでに何度も試行錯誤が必要な仕事（例:あるスコアや基準を満たすまで直し続ける）
• 定期的に状況を確認し、変化があれば対応する仕事（例:一定間隔での監視・チェック）
• 人が毎回張り付いていなくても、条件が整えば自動的に走らせたい仕事

こうした仕事に対して「毎回自分で指示を出し直す」のは非効率です。かといって、条件も上限もないまま「あとはよろしく」と丸投げするのは危険です。AIをどう繰り返し働かせるか、そしてどこで止めるかを設計する必要があります。これが本記事で扱う「ループ」の考え方です。

2. ループとは何か

ループとは、「作業する→結果を自分で確認する→不十分ならやり直す→停止条件を満たしたら終わる」という一連の流れを、人が毎回指示を出さなくてもAIが繰り返す仕組みです。

「ループエンジニアリング（loop engineering）」という呼び方自体は、2026年6月ごろに開発者向けブロガーのAddy Osmani氏が公開した記事で広まり始めたばかりの、まだ新しい言葉です。長年使われてきた確立済みの業界用語ではありません。同記事では、Anthropic社でClaude Codeを率いるBoris Cherny氏の「もうClaudeに直接プロンプトを書くことはない。Claudeにプロンプトを出し、次に何をすべきか判断するループを動かしている。自分の仕事はループを書くことだ」という趣旨の発言（Osmani氏の記事内での引用として伝えられているもの）が、この考え方の出発点の一つとして紹介されています。Osmani氏は、ループエンジニアリングを、記事161で扱った「ハーネスエンジニアリング（環境・足場の設計）」や、その前段にある「プロンプトエンジニアリング(指示文の設計)」の先にある発展形として位置づけています。

つまり「ループエンジニアリング」は、本記事が独自に作った呼び方ではありませんが、業界で完全に定着し切った標準用語でもありません。「AIを1回のやり取りで使うのではなく、繰り返しの構造として設計する」という考え方が、2026年半ばになって具体的な言葉を与えられ始めている、という段階だと捉えるのが実態に近いでしょう。

言葉の新しさとは別に、この「繰り返しの構造」自体は、Claude Codeにおいて具体的な機能としてすでに実装されています。次の章で、その中身を見ていきます。

3. ループの種類と使い分け

Claude Codeの公式ドキュメント（code.claude.com/docs、2026年7月時点）を確認すると、「繰り返し」を実現する仕組みは、性質の異なる複数の方式として提供されています。それぞれ次のターンが始まるタイミングと、止まるタイミングが異なります。

/goal ─ 達成条件を満たすまで回す

/goal <条件> で完了条件を文章で設定すると、Claude Codeは1ターンごとの作業のあと、その内容を軽量なモデル（既定ではHaiku)に見せて「条件を満たしたか」を判定させ、満たしていなければ自動的に次のターンを始めます。判定は会話に実際に現れた内容だけを見て行われ、判定モデル自身がツールを実行するわけではありません。たとえば「テストが通った」と判定させたいなら、Claudeが実際にテストを実行し、その結果が会話の中に残っている必要があります。(引数なし)で進行状況を、で解除できます。

4. 停止条件の設計 ─ ここが実務で一番効く

ループを扱ううえで最も注意すべきなのが「どうやって止めるか」の設計です。放っておいても回り続ける仕組みは便利である一方、止め方を誤ると、無駄な作業が延々と続いたり、意図しないコストがかかったり、取り返しのつかない操作が実行されてしまうリスクを伴います。Claude Codeの各方式には、この点で明確な違いがあります。

/goalは、上限を自分で書き込まないと際限なく回り得ます。 公式ドキュメントは、条件文の中に「20ターンで打ち切る」といったターン数や時間の上限そのものを書き込むことを推奨しています。自動的に上限がかかる設計にはなっていない、という点は使う前に必ず押さえておくべきポイントです。

/loopには、7日間で自動的に失効するガードレールが標準で組み込まれています。 一定間隔で繰り返す設定にしても、放置すれば永遠に回り続けるわけではなく、1週間で自動的に終了します。待機中にキーを押して次回実行をキャンセルすることもできます。

Routinesは、1日あたりの実行回数に上限があり、利用したプランの消費量としてカウントされます。 つまり「コストの天井」がある設計です。ただし具体的な回数や金額は公式ドキュメント上でも、プランごとの利用状況ページを参照する形になっており、明確な数字としては公開されていません。

いずれの方式であっても、「条件を満たすまで」「時間が来るまで」という設計だけに頼らず、上限(回数・時間・コスト)を自分の側でも意識して設定しておくことが、実務でループを使ううえでの前提になります。自律的に動く仕組みほど、止め方を先に決めておく必要がある、という原則です。

5. どこに人の承認を挟むか

ループを設計するうえで、もう一つ重要なのが「どこで人間が確認するか」という設計です。

/loopの保守用の指示については、公式ドキュメントに「pushや削除といった取り返しのつかない操作は、会話の中ですでに承認済みの作業の延長である場合にのみ実行する」という設計思想が明記されています。つまり、新しく不可逆な操作を勝手に判断させるのではなく、「すでに人が了承した作業の続き」だけを自動化する、という線引きです。

一方でRoutinesは、パーミッションモードの選択や、操作ごとの承認プロンプトなしに完全に自律実行される仕組みです。人が途中で止めるポイントが構造的に存在しないため、代わりに別の形でガードレールを設けています。たとえば既定では、claude/という決まった接頭辞のついたブランチにしかコードを反映(push)できないよう制限されており、それ以外の場所へ反映するには明示的な設定変更が必要です。人の承認を都度挟めない分、「触っていい範囲」自体を狭く区切っておく、という発想です。

自社の業務でループを組む場合も同じ考え方が使えます。送信・公開・削除・支払いなど、後戻りできない操作の手前には必ず人の確認を挟む。逆に、下書き作成・情報収集・チェック・分類のように、間違えてもやり直しがきく作業は、ループに任せる範囲を広げる。「どこまでは自動でよく、どこからは人が見るか」という線引きを先に決めてからループを組むことが、事故を防ぐ最も基本的な設計です。

6. 中小企業の業務で何がループ化できるか

Claude Codeの公式ドキュメントは主にソフトウェア開発の文脈で書かれており、非エンジニアの業務にそのまま当てはめた具体例は公式には示されていません。ただし、3章で見た3つの方式が持つ性質(条件達成まで/時間間隔/クラウド常駐)は、考え方としてそのまま業務に転用できます。

時間ベースの繰り返し(/loopに近い発想): 競合の価格変更や、特定のニュース・制度情報の更新を、決まった間隔で確認する。人が毎回検索しなくても、変化があったときだけ気づける状態を作る。

条件達成までの反復(/goalに近い発想): 「誤字脱字ゼロ」「規定のフォーマットを満たす」といった明確な達成条件がある定型作業(下書きの体裁チェックなど)を、条件を満たすまで自動的に見直させる。

夜間・週次のまとまった作業(Routinesに近い発想): 営業時間外に、たまった問い合わせやログを整理し、翌朝には下書きの状態で確認できるようにしておく。ただしRoutinesは試験提供段階の機能であるため、実務で使う場合は挙動の変化を前提に検証してから取り入れる必要があります。

コードを書かない業務であっても、Claude Codeのようなツールを使える場面については、記事164「Claude Codeは『エンジニアのツール』じゃない」で具体的な領域を扱っています。ループの考え方と組み合わせることで、「1回作業を頼む」から「決まったパターンの作業を任せ続ける」への広がりが見えてきます。

どの場合も共通するのは、いきなり複雑な仕組みを組まないことです。まず人が主体で行っている作業の一部を小さく切り出し、単純なループから試し、どこで止まるべきか・やりすぎていないかを見ながら調整していく。ループは一度作って終わりではなく、動かしながら育てていくものだと捉えるのが実務的です。

7. ハーネス(記事161)との関係整理

記事161「AIの成果を分けるのはモデルではなく『ハーネス』」では、AIモデルの性能そのものではなく、その外側に作る「足場(ツール・情報・権限などの装備)」の設計が成果を左右する、という考え方を扱いました。

関連記事: AIの成果を分けるのはモデルではなく「ハーネス」 ハーネスエンジニアリングという思考転換

ハーネスとループは、扱っている軸が異なります。ハーネスはAIに「何を渡すか」の設計(ツール・コンテキスト・権限といった装備の軸)であるのに対し、ループはAIを「いつ・何回・どんな条件で回すか」の設計(時間軸)です。Osmani氏の記事でも、ループエンジニアリングはハーネスエンジニアリングの上に積み上がる発展形として位置づけられています。どれだけ良い装備(ハーネス)を渡しても、それを1回きりで終わらせるか、条件を満たすまで回し続けるかで、実務での使い方は大きく変わります。逆に、ループの設計だけがあっても、渡すツールや権限(ハーネス)が整っていなければ、繰り返す中身が伴いません。両者は対立する考え方ではなく、装備(ハーネス)と時間軸(ループ)という、互いに補い合う2つの設計軸だと捉えるのが正確です。

8. まとめ

• 「1回指示して終わり」の使い方は、達成条件があいまいな仕事や、繰り返しの監視が必要な仕事には向かない。
• ループとは、作業→自己確認→やり直し→停止条件、を人が毎回指示せず繰り返す仕組みであり、Claude Codeでは/goal(条件達成まで)・/loop(時間間隔)・Stop hook(自作判定)・Routines(クラウド常駐、試験提供段階)として実装されている。
• 「ループエンジニアリング」という呼び方自体は2026年半ばに広まり始めたばかりで、まだ確立し切った標準用語ではない。
• 最も重要なのは停止条件の設計。/goalは上限を自分で書き込む必要があり、/loopは7日で自動失効し、Routinesは実行回数に上限がある、という違いを踏まえて使う。
• 送信・公開・削除など取り返しのつかない操作の手前には、必ず人の承認を挟む設計にする。
• ハーネス(記事161、何を渡すか)とループ(本記事、いつ・何回回すか)は対立する考え方ではなく、互いに補い合う2つの設計軸である。
• 機能名・仕様は今後変更されうるため、実際に使う際は必ず公式ドキュメントで最新情報を確認する。

出典・参考

• Claude Code Docs「Keep Claude working toward a goal」
  https://code.claude.com/docs/en/goal
  ※/goalの仕様・判定方式・上限設計の出典。Claude Code公式ドキュメント。2026年7月時点。

• Claude Code Docs「Run prompts on a schedule」
  https://code.claude.com/docs/en/scheduled-tasks
  ※/loopの仕様、self-pacedモード、7日間の自動失効、不可逆操作の扱いの出典。Claude Code公式ドキュメント。2026年7月時点。

• Claude Code Docs「Automate work with routines」
  https://code.claude.com/docs/en/routines
  ※Routines(/schedule)の仕様、Research Preview段階である旨、トリガー種別、ブランチ制限の出典。Claude Code公式ドキュメント。2026年7月時点。

• Claude Code Docs「Hooks reference」
  https://code.claude.com/docs/en/hooks
  ※Stop hookの仕組みの出典。Claude Code公式ドキュメント。2026年7月時点。

• Addy Osmani「Loop Engineering」
  https://addyosmani.com/blog/loop-engineering/
  ※「ループエンジニアリング」という呼び方の出所、Boris Cherny氏・Peter Steinberger氏の発言の引用元、ハーネスエンジニアリングとの位置づけの出典。同記事内での引用であり、両氏本人の一次発言原文には未到達。

• 記事161「AIの成果を分けるのはモデルではなく『ハーネス』 ハーネスエンジニアリングという思考転換」
  https://pronaviai.com/management/article/161
  ※ハーネスエンジニアリングの概念・構成要素の出典。本記事の前提となる関連記事。