「ノープロンプト」ワークフロー：開発者の生産性を高める Boris のループ駆動型理論

「もう Claude にプロンプトは打っていない。動いているのはループのほうで、Claude にプロンプトを打って次に何をするか決めているのもそのループだ。自分の仕事はループを書くことになった」

Claude Code を率いる Boris Cherny が公の場で語った言葉です（The New Stack や Addy Osmani の記事で紹介されています）。

我々の多くがまだ「どう打てば精度が上がるか」とプロンプトを練っている横で、ツールを作っている本人はとっくに「打つ側」から降りていた、という話です。

考えてみると、自分が画面の前に座って、AIの返事を待って、確認して、また指示を出す。この「人間のターン」が毎回はさまる限り、スピードの上限は自分の手の速さで決まります。

Loop Engineering（ループ設計） は、その人間のターンを構造から外そうという発想です。Boris はそれをやり切っている側で、2025年11月に IDE を消し、それ以来開いていないと話しています。直近1ヶ月の Claude Code への自分の貢献は、ほぼ全部 Claude Code 自身が書いたと話しています（報道では PR にして200件超）。

ツールを作っている当人が、自分ではコードを打たず「ループが正しく回っているかを見る」側に回っている。今日はこれを、雰囲気ではなく実仕様レベルで分解します。僕自身もループ側に寄せている途中ですが、寄せるほど手が空くのは実感しています。

https://note.com/nobel/n/n8192ec07d689

Loop Engineering とは、役割が変わること

言い換えると、自分の立ち位置が変わります。これまでは、人間が指示してAIが答え、人間が確認してまた直す、という往復の真ん中に自分が座っていました。ループ設計では、人間は循環の仕組み（ループ）を設計するところまでを担い、試行錯誤も結果の検証もAI側に回します。終わったら通知が来るのを待つ、という形です。

Google の Addy Osmani も Loop Engineering という記事で同じことを書いていて、「自分でプロンプトを打つ人間を、自分の代わりにプロンプトを打つ仕組みに置き換える」と表現しています。レバレッジが効く場所が、良いプロンプトを書く力から、AIに代わりにプロンプトを打たせる仕組みをどう設計するか、に移った。これが核心です。

ただ Addy 本人も「まだ初期段階で、自分も懐疑的なところはある。トークンコストには本当に気をつけたほうがいい」と釘を刺しています。ここは後半の落とし穴でちゃんと戻ってきます。

/loop の実仕様

Claude Code には /loop という組み込みスキルがあります（v2.1.72 以降）。これがループ設計のいちばん手軽な入り口です。ネット上の解説は誤りが混ざっているので、公式のスケジュール実行ドキュメントを基準に要点だけ。

渡すものによって挙動が変わります。

interval と prompt の両方: /loop 5m デプロイが終わったか確認して教えてなら固定間隔で回る
prompt だけ: /loop CIが通ったか見て、レビューコメントに対応してなら、Claude が毎回 1分〜1時間の範囲で間隔を自分で決める（self-paced）
何も渡さない /loop: 組み込みのメンテナンス用プロンプト（未完作業の継続、PRの世話、軽い掃除）か、自分で置いた loop.md が回る

間隔は先頭に 30m と置いても、末尾に every 2 hours と添えても通ります。単位は s / m / h / d。別のコマンドも渡せて、/loop 20m /review-pr 1234 のように保存済みスキルを毎回走らせることもできます。止めたいときは待機中に Esc（自然言語で頼んで作ったタスクは Esc では止まらず、削除を頼む必要があります）。self-paced のときは、タスクが本当に終わったと判断すれば Claude 自身が次の起動を張らずに終わります。

self-paced には地味な良さがあって、ビルドが終わりかけなら短く待ち、何も起きていなければ長く待つ、という調整を勝手にやってくれます。ポーリングの代わりに Monitor という仕組みでバックグラウンドの出力を流させることもあって、固定間隔で毎回プロンプトを撃ち直すより安く済むことが多いです。

ここで、元ネタ記事でよく見る誤解を1つ正しておきます。「作成から3日で自動削除」と書かれていることがありますが、正確には繰り返しタスクは作成から7日で失効します（最後に1回だけ走って消える）。そして /loop は session-scoped で、新しい会話を始めると消えます。閉じても --resume で未失効なら戻ってきます。

スケジュール手段は3系統あって、用途で選びます。

Cloud（Routines）: Anthropic 側で動く。マシンを開いていなくても回る。最小間隔は1時間
Desktop のスケジュールタスク: 自分のマシンで動き、ローカルファイルに触れる
/loop: セッションが開いている間だけ。最小1分で、セッション中のポーリングに手軽

人間が一切介在しない常駐をやるなら Routines か GitHub Actions、セッション中に見張りたいなら /loop、という棲み分けです。

ループが効く定番タスク

自分のルーチンの中で「確認して、ちょっと直す」を繰り返している作業が、だいたいループ向きです。よく挙がる型が3つあります。

不具合の巡回: Issue やテストの失敗を検知して、原因を読み、直して、テストを走らせ、PRを作るところまでを一定間隔で回す
継続的なレビュー: コードの変更を監視して、気になる箇所を指摘し続ける。人間は出てきた指摘を見て採否を決めるだけになる
ドキュメントの同期: ソースの変更を検知して、README や仕様書を最新に保つ

3つに共通しているのは、ゴールが「テストが通る」「PRができる」のようにはっきり判定できることです。逆に、判定基準が曖昧なタスクはループに向きません。止め時が決まらないと、ただ回り続けてトークンを食うだけになります。最初に任せるなら、合否が一目で分かるタスクを選ぶのが安全です。

暴走と物忘れを防ぐ「状態ファイル」

ループで怖いのは2つです。同じ失敗を繰り返すことと、トークンを延々と食うこと。

ここで効くのが、プロジェクトに状態ファイルを1枚置く設計です。STATE.md でも todo.md でも名前は何でもよくて、現在の目標 / 完了したこと / 次にやること / 詰まっている点を、ループのたびにAIが読み書きします。セッションが切れても、AIは「今どこにいて、何を目指しているか」を見失いません。

これは思いつきの作法ではなくて、Anthropic 自身がEffective harnesses for long-running agents（2025年11月）でほぼ同じ結論に行き着いています。彼らの構成は、環境を整える initializer エージェントと、毎セッション1機能ずつ進める coding エージェントの2役。セッション間は git commit と claude-progress.txt という進捗ファイルで引き継ぐ。長いジョブでは要約による圧縮では不十分。構造化したファイルに一度書き出してコンテキストを作り直す、という方針です。

僕の運用でも tasks/state.md を共有状態のハブにしていて、壁打ち側と実装側がそこを読んでから動きます。やっていることは論文と同じで、「コンテキストを信用せず、ファイルを信用する」だけです。地味ですが、これが無いとループは2周目で迷子になります。

Ralph式と、作る側・見る側を分けること

ループの過激版に「Ralph」と呼ばれる手法があります。Geoffrey Huntley が広めたもので、原典の最小形はただの bash ループです。

同じプロンプトを延々と食わせ続け、計画を書いた Markdown ファイルを disk 上の共有状態にして、AIが毎回それを読んで「次に何をやるか」を自分で決める。乱暴に見えますが、状態ファイルがあるから周回するほど前に進みます。Claude Code には公式の ralph-loop プラグインもあって、終了条件（completion promise）を満たすまで同じプロンプトを再投入し続けます。完了の宣言は本当に達成したときしか出してはいけない、という縛り付きで。

ただ、1体のAIに全部任せると、自分の書いたコードを自分で「OK」と言ってしまいます。そこで効くのが、作るAI（Maker）と検査するAI（Checker）を分けることです。僕は自分の運用でも実装と検証を別エージェントに分けていて、検証側には実装意図を渡さず、要件だけ見せて独立評価させます。同じセッションのセルフレビューはどうしても甘くなる、というのは何度かやらかして学びました。

ループの中に「別の視点のレビュー専用エージェント」を組み込む。この多重チェックの設計が、人間が残すべき仕事のひとつです。

自律度は3段階で設計する

いきなり全部任せると事故ります。関与度をレイヤーで分けると安全に寄せられます。

L1（手動）: 人間がプロンプトを打ち、1つずつ確認する。今までのやり方
L2（半自律ループ）: 状態ファイルに沿って、特定のタスク群を /loop で完遂まで見守る
L3（常駐）: Routines や GitHub Actions で、人間が介在せず回し続ける

最初は L2 から入るのが現実的です。/loop で1つのタスクを終わりまで回して、挙動を観察する。信用できる範囲が見えてから L3 に上げる。僕も最初の数回は、隣の画面でログを眺めながら「どこで判断を間違えるか」を確認していました。

落とし穴（先に知っておく）

良い面ばかり書いてきたので、詰まりやすい点を3つ。

トークンコスト: ループは回るほど食います。Addy が念を押していたのもここで、間隔を詰めすぎると一晩でそこそこの額になります。固定間隔より self-paced のほうが、待つべきときは待つので無駄が減ります
不可逆な操作: 組み込みのメンテナンスプロンプトは、push や削除のような戻せない操作は「会話ですでに許可された範囲」しか踏みません。自前プロンプトを書くときも、破壊的操作の線引きは自分で書いておくのが安全です
7日で消える: /loop の繰り返しは作成7日で失効します。長く回したいなら Routines か Desktop タスクに移してください

中級者向けの補足

/loop と /goal は別物です。/loop は間隔で回す。条件を満たすまで毎ターン続けたいなら /goal。イベントが起きた瞬間に反応させたいなら Channels で push させる、という使い分けがあります
loop.md（.claude/loop.md か ~/.claude/loop.md）を置くと、素の /loop のデフォルトプロンプトを自分用に差し替えられます。「リリースブランチのCIが赤かったら直す」みたいな定常作業を書いておく使い方が便利です
セッションあたりのスケジュールタスクは50個まで。一覧は CronList、ID指定の削除は CronDelete でできます

まとめ

以前は、自分が画面の前にいる時間がそのまま進捗の上限でした。今は、寝ている間に状態ファイルを読んだループが1機能ずつ進めていて、朝はそれを確認するところから始まります。

中身（プロンプトの精度）を上げる前に、回し方（ループと状態管理と検証の分離）を設計する。レバレッジが移ったのはそこだ、というのが Boris や Addy、そして Anthropic の harness の話に共通している点です。難しい理論というより、止め時を決めてから回す、という地味な設計の積み重ねだと思っています。