Claude Codeの /loop の本当の使い方 プロンプトを毎回書かない設計術
監修: 寺師 岳見(株式会社タレントクラウド 代表取締役)
「Claude Codeでもう何も指示しなくなりました。代わりに、ループを書いています」。AnthropicでClaude Codeを率いる Boris Cherny の今月の発言です(The New Stack ほか複数メディアで報じられました)。文字どおりに読むと挑発的ですが、現場のエンジニアの間ではこの言葉、思ったよりすんなり受け止められています。「プロンプトを書く時代は終わる」「これは年内に広く起きる移行だ」と Boris は続けています。
少し前まで、AIにうまく仕事を頼むコツは「いいプロンプトを書くこと」でした。プロンプトエンジニアリングという言葉も定着しました。ところがここ数ヶ月、Claude Codeを業務で使い込んでいる人たちの間で、別の流儀が広まっています。毎回プロンプトを書くのではなく、AIに「何をどう繰り返すか」を事前に設計しておき、loopとして動かす。プロンプトを書く側から、loopを書く側へ。今日のテーマはここです。
この記事では、Claude Codeの /loop を素材に、「毎回プロンプトを渡す」従来の使い方と、「loopを事前に設計する」新しい流儀の違いを整理します。そのうえで、中小企業が小さく試すための手順と、暴走させないための落とし穴までを一通り押さえます。
「プロンプトを書く時代が終わる」とClaude Code責任者が言った
まず発言を正確に引きます。Boris Cherny は2026年6月、複数の技術メディアの取材で次のように述べました(The New Stack ほか)。
「私はもうClaudeにプロンプトを与えていません。Claudeにプロンプトを与えて何をすべきかを判断するloopを動かしています。私の仕事はloopを書くことです」
「これは今年(2026年)残りの期間で、業界全体に起きていく移行だと思う」
「Claude Code を作っている本人」が、もう自分の手では指示を書いていない、と言っています。Xでも日本語圏のエンジニア・実務家が即座に反応し、「Loop Engineering(ループ・エンジニアリング)」という新しい呼び名で議論が広がっています。プロンプト・エンジニアリングの次の段階、というニュアンスです。
「自分はそんな技術者じゃないし」と引いてしまいそうな話に聞こえますが、根っこの考え方は中小企業の業務AIにもそのまま効きます。これからその意味を見ていきます。
従来の /loop vs 新流儀の /loop
Claude Code には標準で /loop という機能が入っています(公式ドキュメント)。指定した間隔でプロンプトを繰り返し実行してくれる、というシンプルな仕組みです。
従来の使い方(プロンプトを毎回渡す):
/loop 30m お客様からの新着メールを読んで、要約をSlackに投げて
30分ごとに、その都度同じプロンプトを Claude に渡して実行させる。これでも便利です。ただし、内容を変えたければプロンプトを書き直すしかありません。判断基準もプロンプトの一文に押し込めるしかなく、複雑になるとすぐ破綻します。
新流儀(loopそのものを事前に設計する):
/loop の中身を、毎回書くプロンプトではなく 事前に作り込んだ設計 に置き換えます。Claude Code には、設計を仕込むための仕組みが標準で揃っています。
CLAUDE.md: そのプロジェクトでClaudeが常に守る前提・ルール・参照すべき情報を書いた、いわばこのプロジェクトの就業規則- Skills: 業務手順をフォルダにまとめて、Claudeに「資格」として持たせる(10本目Claude Skills記事で詳しく扱いました)
- Subagent: 1つの大きな仕事を、複数の役割(計画役・実行役・レビュー役)に分担させる
- Hooks: 「この条件を満たしたら処理を止める」「ここで人間の確認を必ず挟む」などの硬い制御を仕込む
これらを組み合わせて、/loop 自体には簡単な開始合図だけ渡す。あとはClaudeが事前設計に従って、自分で次に何をするかを判断しながら動く。これが「プロンプトを書かない loop」の正体です。Boris の言葉どおり、人間は ループを書く側、つまり業務の設計図を渡す側 に回ります。
なお、/loop には loop.md という専用ファイルもあります。.claude/loop.md(または ~/.claude/loop.md)に標準の巡回手順を書いておくと、引数なしの /loop だけでその手順を繰り返せます。毎回プロンプトを打つのではなく、loop側の「定常運転の説明書」をファイルとして置けるわけです。今回の記事の主題に直結する仕掛けで、CLAUDE.md / Skill / Subagent / Hooks とあわせて押さえておくと、設計の幅がぐっと広がります。
新流儀が支持されている3つの理由
「面倒くさそう」と感じる方も多いと思います。ただ、すでに業務で本気で使っている層が、なぜこちらに寄っていくのか。Xでの議論や、報道されている Anthropic 関係者の声から整理すると、理由はおおむね3つです。
1. 自律性・持続性が上がる。プロンプトを毎回書かなくていいので、loopが回っている間は人手が空きます。Anthropic関係者からは「8倍のコードが書ける」という事例も出ています(The New Stack)。実務的には「人がいないと止まる」状態から「人がいなくても進む」状態への移行です。
ただし、ここはひとつ大事な前提を補足します。Claude Code の /loop は基本的に現在のセッション内で動く仕組みです。PCを閉じる、Claude Codeを終了するといった場合は止まりますし、見逃した実行の「追いつき」もありません(公式ドキュメント)。PCやセッションを閉じても確実に動かしたい用途では、Anthropic公式が用意する Routines(Anthropic管理のクラウド基盤で動くため、ノートPCを閉じても継続できる)、Desktop scheduled tasks(ローカルファイルが必要なとき)、または GitHub Actions などのスケジューリング方法を、用途に合わせて使い分けます。
2. 一貫性と品質が安定する。プロンプトを毎回書くと、書き手の調子やその日の言葉選びで結果がぶれます。CLAUDE.md と Skills、Subagent で やる手順・やめる条件・人間が必ず見る場所 をあらかじめ硬めておけば、誰がどの時間に動かしても、似た品質の結果が返ってきます。AI特有のハルシネーション(ぶれた回答)や、コンテキストの散逸を抑える効きもあります。
3. 人間の役割が「職人」から「設計者」になる。プロンプトを毎回うまく書く「プロンプト職人」は、書き手1人の頭の中に知見が閉じます。loopを設計する側に回れば、設計図(CLAUDE.md, Skill)が会社の資産として残ります。担当が代わっても、引き継ぎがしやすい。Boris は「人間は何をさせるかを設計する側へ」と表現しています。
ここまでくると、AIが業務をやってくれるかどうかではなく、業務の設計図をどう書くかが会社の競争力になる、という景色が見えてきます。
中小企業が小さく試すなら 設計の手順
ここで一つ、大事な前提を書かせてください。loopは「Claude Codeに慣れている人」向けの一手です。プロンプトの書き方、権限モードの挙動、Skillの作り方など、Claude Code単体での動かし方が頭に入っていないうちにいきなりloopに手を出すと、何が起きているのか追えず、ズレた動作に気づかない・止め方が分からない、という事故に繋がりやすくなります。
もしClaude Code自体がまだ初見であれば、まずClaude Code始め方記事で日常の単発操作に慣れ、Skills記事で「自分の業務手順をAIに渡す」感覚を掴んでから、loopに進むのが現実的な順番です。loopは設計と任せたい業務が噛み合えば、新しい仕事のさせ方として非常に強い手段になります。ただし順番をひっくり返すと痛い目を見やすい、というだけのことです。
そのうえで、私たちがお客様にお勧めしている手順は3ステップです。中小企業が今日から触る方法は、意外と地味です。
ステップ1: 毎日繰り返す「人を待たせる業務」をひとつ選ぶ
「毎朝、お客様からの問い合わせメールに目を通して、急ぎ案件をSlackに転送する」「日報の下書きを15時に作る」「競合のIRページを週次でチェックする」のような、人が止まると業務が滞る作業です。最初は小さくていい、というか 小さくしてください。
ステップ2: CLAUDE.md と Skill に「やる手順」を書く
選んだ業務について、人間がいつもやっている流れを文章で書きます。たとえば「急ぎ案件」の判断基準、Slack転送のフォーマット、見落とせない顧客名のリスト、迷ったときの逃げ道(=人間に振る)。これを CLAUDE.md(プロジェクトのルール)と Skill(具体的な業務パッケージ)に分けて置きます。Claude Skills記事で書いた手順がそのまま使えます。
ステップ3: /loop で繋いで、最初の1週間は隣に座って動かす
設計したSkillを呼び出すだけのシンプルな loop を /loop で組みます。たとえば /loop 1h /morning-mail-triage のような形(/morning-mail-triage は自作したSlash CommandやSkill)。最初の1週間は、必ず人間が結果を確認しながら回します。ズレた挙動があれば、プロンプトをいじるのではなく、CLAUDE.md か Skill のほうを直す。これが新流儀のリズムです。
落とし穴 暴走と過剰設計を避ける
便利な話ばかり書きましたが、実務で痛い目を見やすい落とし穴も合わせて挙げておきます。
1. API課金が想定外に跳ねる。loopは止めなければ動き続けます。試している段階で「夜の間も30分おきに重い処理」を回し続けると、月末の請求書で目が覚めます。最初は実行回数の上限と、月のコスト上限を必ず別の場所に書いておきます。
2. 「自動送信」「自動公開」「自動振込」を最初から任せない。loopの中で 取り返しのつかない操作 は、Hooks(Claude Codeのライフサイクル上の特定タイミングで通知や編集ブロックなどを実行できる仕組み)、権限モード、通知を組み合わせて、人間の確認なしに送信・公開・削除へ進まない設計にします。お客様にメールを自動送信するくらいなら、「下書きをSlackに投げて、人間がボタンを押したら送信」の二段構えにする。AIエージェント記事で書いた「人間の最終承認」の原則は、loopでも同じです。
3. 最初から複雑な設計を組まない。CLAUDE.md+Skill+Subagent+Hooks全部入りの大作 loop は、たいてい最初の1週間で破綻します。1機能・1Skill・1人間チェックの最小構成から始めて、動いてから増やす。Boris たちの世界観は派手に見えますが、その下では小さなloopを丹念に積み重ねた結果です。
4. プロンプトを書くスキルがゼロになるわけではない。CLAUDE.md と Skill 自体が、結局は文章(自然言語)で書きます。「プロンプトを書かない」というのは、毎回その場で書かなくてよくなるという意味で、文章で意図を伝える能力は依然として要ります。新流儀でも、書き手の言葉の精度はそのまま品質に出ます。
5. /loop の定期タスクは作成から7日で自動失効する。Claude Code の公式仕様で、recurring taskは作成から7日経つと止まります(公式ドキュメント)。継続的に長く回し続けたい業務は、期限前に作り直すか、最初から Routines(クラウド側)や Desktop scheduled tasks(ローカル側)に移す前提で設計します。「業務にloopを組み込む」ときに最初にハマる落とし穴のひとつです。
さいごに
Boris Cherny の「ループを書く」発言は、現場の感触として「言われてみればたしかにそう」というものです。AIに毎回お願いするのは便利ですが、繰り返すたびに人が止まる構造を残してしまう。最初に設計図を渡せば、AIは続きを自分でやってくれる時代に入ってきました。
すぐ試したいなら、来週の業務カレンダーから「毎日同じ手順を踏んでいる5分間」を1つ選んで、CLAUDE.md と Skill に手順を書き、/loop で繋いでみてください。最初の1つが回り始めると、「自分の仕事の中で、loopにできるものはどれか」を探す視点が、自然と身につきます。プロンプトの一行を磨くより、その視点のほうが、たぶんこれからの数年は強い武器になります。