ループエンジニアリングとは、プロンプトを卒業する新しい設計思考

「もうClaudeにプロンプトを打っていません」。Claude Codeの開発責任者、ボリス・チェルニー氏がこう語りました。「動いているのはループです。そのループがClaudeに指示を出し、次に何をするか決めています。僕の仕事は、ループを書くことです」。この発言を収めた動画クリップは、6月に24時間で70万回近く再生されたそうです。プロンプトエンジニアリングの次に来る発想として、いま海外の開発者コミュニティで急速に広がっています。その名も「ループエンジニアリング」です。

僕はAIコンサルタントとして、日々クライアントにプロンプトの書き方を教えています。だからこそ、この発言には正直ヒヤッとしました。「プロンプトを書かなくなった」というのは、僕らが教えていることの前提が変わるという意味だからです。たとえば、これまでは「どんな指示文を書けば欲しい答えが返ってくるか」を一緒に考える研修をしてきました。その前提が崩れるとしたら、教える中身そのものを見直す必要があります。今日は、この新しい概念の中身を、公式情報と海外の一次記事から整理します。

プロンプトを書かなくなった開発者が、実際は何をしているのか

チェルニー氏の発言は、Y Combinatorの番組「Light Cone」のインタビューで語られたものです。番組内では「Claudeに指示を出すループが数百個動いている」という説明もありました。それぞれのループが、自分のGitHubやSlack、Twitterのタイムラインを読んでいるそうです。読んだ内容をもとに、次に何をすべきかを自分で判断しているといいます。プロンプトを1つずつ打つのではありません。判断そのものを仕組み化しているということです。

ここで気になるのが、「プロンプトを書かない」という言葉の正確な意味です。誤解しやすいのですが、プロンプトという概念自体がなくなったわけではないと僕は理解しています。プロンプトを「その場でその都度、人間が考えて打つもの」から変えたということです。「あらかじめ設計した仕組みが、自動で生成し続けるもの」に置き換えた、という意味だと僕は読んでいます。人間の仕事が、個別の指示出しから一段上がったわけです。指示を生み出す仕組みそのものの設計へと役割が移った、ということになります。

Developers Digestというメディアの記事では、この変化がもう少し長いスパンで整理されています。開発者たちは18か月に満たない期間で、4つの段階を経てきたという説明です。プロンプトエンジニアリングからコンテキストエンジニアリング、ハーネスエンジニアリング、そしてループエンジニアリングへ。この順番で進んできたといいます。関心の対象は「何を聞くか」から始まりました。次に「何を渡すか」、「どう囲うか」に移り、いまは「いつまで回すか」に至っている。この流れで捉えると、僕にはとても分かりやすく感じられました。

たとえば僕自身、記事のリサーチをClaude Codeに手伝ってもらう場面があります。最初は毎回「この観点で調べて」と細かく指示していました。そのうち、CLAUDE.mdに調べ方の型を書き込む運用に変えています。これはコンテキストエンジニアリングの発想に近いはずです。ループエンジニアリングは、その先にある発想です。「どこまでやったら終わりにするか」まで仕組みに含める考え方だと理解すると、自分の経験とも地続きに感じられます。

読者の中にも、Claude Codeを日常的に使っている方は多いと思います。もし「テストが通るまで直して」とだけ伝える使い方をしているなら、それはループエンジニアリングの入り口です。あとは結果を待つだけの状態に、すでに立っているということです。ただし、その多くはまだ1回きりの指示のはずです。1回のお願いを、繰り返し使える仕組みとして固定していくところに、ループエンジニアリングとの違いがあると僕は考えています。

Claude Codeの/goalコマンドが、「終わり」の判断を仕組みに渡した

この発想を実際に触れる形にしているのが、Claude Code公式の「/goal」というコマンドです。Claude Code公式ドキュメントによると、/goalは「何をもって完了とするか」という問題を解決する仕組みです。この問題への答えを、あらかじめ条件として書いておくということです。

具体的な動き方を説明します。完了条件を/goalで設定すると、Claudeはその条件が満たされるまで作業を続けます。1つのターンをまたいでも、途中で止まりません。1つのターンが終わるたびに、評価役の小さなモデルが「条件を満たしたかどうか」をチェックします。満たしていなければ、Claudeは人間に確認を求めません。そのまま次のターンを自分で始めます。満たしていれば、そこで作業は停止します。人間が毎回「次はこれをやって」と声をかける必要がなくなるわけです。

僕がここで面白いと感じたのは、評価役のモデルの動き方です。このモデルは、自分でコマンドを実行したりファイルを読んだりはしません。あくまでClaude自身の作業記録、つまり会話のやり取りの中に証拠が残っている必要があります。たとえば「テストがすべて成功する」という条件を考えてみます。Claudeが実際にテストを実行し、その結果が会話の中に残っている。この状態になって初めて、評価役はそれを確認できます。条件を作文するだけでは動きません。実際に手を動かした痕跡が要る、実務的な設計だと思います。

もう1つ、Claude Code自体をまだよく知らない方のために補足します。Claude Codeは、Anthropicが提供するコーディング支援ツールです。以前にできることを8用途に整理した記事を書きました。ファイルの読み書きやコマンドの実行を、人間の代わりに担ってくれるのが基本の役割です。今回の/goalは、その延長線上にある新しい命令の1つだと捉えると位置づけがつかみやすいと思います。

エンジニアではない方には、少し遠い話に感じられるかもしれません。ですが、この仕組みが解こうとしている問題自体は、実はとても身近です。「この作業、どこまでやったら終わりにしていいのか」という迷いは、誰の仕事にも存在するはずです。たとえば資料作りであれば「情報を集め切ったらいいのか、それとも一定の分量に達したらいいのか」で迷うことがあると思います。ループエンジニアリングは、この迷いを先に言語化しておく発想です。そう捉えると、職種を問わず応用できる考え方に見えてきます。

良い停止条件と、動かない停止条件を分ける3つの要素

ここで気になるのが、どんな条件を書けば/goalがうまく機能するのかという点です。Anthropic公式ブログでは、機能する停止条件が備えている要素が3つ整理されています。

1つ目は、測定可能な終了状態です。テストの実行結果、ビルドの終了コード、ファイルの数、処理待ちの件数がゼロになったこと。こうした、はっきり数えられる状態を指します。2つ目は、証明の方法です。「どうやってその状態を確認するか」を具体的に書くということです。たとえば「npm testの終了コードが0であること」のように書きます。3つ目は、途中で崩してはいけない制約です。目的を達成する過程で守るべき前提条件があれば、それも条件に含めておく必要があります。

僕はこの3要素の整理を読んで、これはプログラミングの話に限らないと感じました。たとえば記事のリサーチをエージェントに任せる場面を考えてみます。「一次ソースを3件見つけたら終わり」という条件だけでは弱いはずです。証明の方法が抜けているからです。「一次ソースを3件、公式サイトか一次発表のURLの形で見つけたら終わり」まで書く必要があります。ここまで書いて初めて、証明可能な条件になるわけです。

逆に、うまくいかない条件の例も考えてみます。「読者にとって分かりやすい記事構成を考えたら終わり」という条件は、一見もっともらしく見えます。ですが、これは測定できません。「分かりやすい」の基準が人によって変わるからです。評価役のモデルも、何をもって分かりやすいと判断すればよいか分からず、いつまでも条件を満たせない可能性があります。書き換えるなら「見出しを5本以上作り、各見出しに具体例を1つ以上入れたら終わり」のように書きます。数えられる形に落とし込む必要があるということです。良い条件と動かない条件の差は、結局のところ「数えられるかどうか」に尽きると僕は思います。

長さを稼ぐために時間を区切ることも有効だといいます。公式ドキュメントには「20ターンで停止する」という書き方も紹介されていました。ターン数や時間で上限を切る書き方です。無限に回り続けるループを作らないための、実務的な安全弁だと思います。この安全弁の発想は、後の章で触れる「怖さ」への対処にもつながる話です。

「/routines」と組み合わせると、スケジュール任せの自律ループになる

/goalだけでも、「条件を満たすまで自動で続ける」という動きは実現します。ここに「/routines」という別のコマンドを組み合わせると、話がもう一段変わります。

公式ドキュメントの説明によると、/routinesはスケジュールに従って自動でタスクを起動する仕組みです。この中に/goalを埋め込むとどうなるでしょうか。決まった時間になるたびにClaude Codeが起動します。ゴールが達成されるまで自律的に作業を続けます。達成したら、そこで止まります。つまり「毎回、目的を達成するまで自分で回り、終わったら次の呼び出しまで待つ」というループが完成するわけです。チェルニー氏が語っていた「数百個のループが動いている」という状態があります。この組み合わせを大量に、かつ様々な目的別に走らせている状態だと僕は理解しています。

ここまで読んで、「結局は全自動化の話か」と身構える方もいるかもしれません。僕自身、正直に言うと少し怖さも感じています。判断を仕組みに渡すというのは、便利さと引き換えに何かを見落としたときに気づきにくくなる、ということでもあるからです。以前、みずほFGの導入事例を取材ベースで整理した記事を書きました。40人のチームが25本のプロダクトを並行開発している現場でも、任せる範囲と守るべき境界線を先に設計してから量産に進んでいたのが印象的でした。ループを増やせば増やすほど、同じ設計判断がそのまま個人にも降りてくるはずです。だからこそ、ゴールだけでなく壊してはいけない境界線を最初に決めておく順番が重要になってきます。

この概念はまだ生まれたてで、日本語の実践知見はこれからだ

正直に書いておきます。僕自身は、この/goalと/routinesの組み合わせを、まだ自分の手で試せていません。この記事は、公式ドキュメントと海外メディアの報道をもとにした整理です。チェルニー氏の発言が拡散したのは6月です。まだ2か月も経っていません。日本語での紹介も、エクサウィザーズの記事や、noteやZenn、Qiitaにいくつか実践記事が出てきた段階です。実際に手を動かした人の知見の蓄積は、これからだと思います。

だからこそ、僕がふだん大事にしている「実際にやってみた」という言い方は、今回はできません。代わりに、僕がこれから何を試すつもりかを書きます。まず試すのは、大掛かりな自動化ではありません。自分が毎日繰り返している小さな作業を1つだけ選びます。/goalで「この作業が完了したと言える条件」を言葉にしてみるところから始めるつもりです。たとえば「今日集めた参考記事のURLをすべてメモにまとめ終えたら完了」という条件を考えています。小さくて測定可能な条件から始めるということです。いきなり大きな自律ループを組もうとすると、条件があいまいになりやすいはずです。小さな作業で条件の書き方に慣れてから、範囲を広げていく方が安全だと考えています。

以前、AIエージェントの作り方を3つのルールに整理した記事を書きました。あの記事では、権限の範囲を先に決める大切さを紹介しました。今回のループエンジニアリングも、根っこにある考え方は同じだと思います。仕組みを作る前に、任せる範囲と守るべき境界線を決めておくこと。この順番を守れるかどうかが、安心して任せられるかどうかの分かれ目になるはずです。

今日から動くなら、まず1つの作業をループ化候補として選ぶ

ここまでの話を、今日から動ける形に落とし込みます。着手する順番は、自分の作業の中から候補を探すことから始まります。探すべきは「毎回同じ判断基準で終わりを決めている作業」です。判断基準が毎回変わる作業は、まだ条件として書き出しにくいはずです。逆に、判断基準が固定されている作業ほど、条件を言葉にしやすくなります。

候補が見つかったら、その条件を3つに分けて書き出す練習に移ります。「測定可能な終了状態」「証明の方法」「守ってほしい制約」の3つです。Claude Codeの/goalコマンドを実際に使うかどうかは、この段階では気にしなくて構いません。紙やメモの上で、自分の作業の終わりをこの3つの型に落とし込んでみてください。この練習自体が、プロンプトエンジニアリングからループエンジニアリングへの発想の転換だと僕は考えています。

書き出しに慣れてきても、いきなり複数の作業を同時にループ化しないでください。チェルニー氏のように数百個のループを動かす段階は、相当な試行錯誤の先にあるはずです。1つの小さな作業を選び、条件を書く、動かす、想定と違う動きをしたら条件を直す。この繰り返しに慣れることが、遠回りに見えて一番早い道だと思います。

想定と違う動きの具体例も挙げておきます。条件があいまいだと、Claudeが「もう終わった」と自己判断してしまうことがあり得ます。実はやり残しがある状態のまま、止まってしまうということです。逆に条件が厳しすぎると、いつまで経っても止まらず、無駄にターンを消費し続けることもあり得ます。どちらの失敗も、最初の条件設定に立ち返って直せばよいだけです。失敗を恐れて小さく試すことこそが、この新しい仕組みと付き合う一番安全な方法だと僕は考えています。僕自身も、まずは自分のリサーチ作業1つから始めるつもりです。試した結果は、あらためて別の記事で正直に報告します。

まとめ

ループエンジニアリングは、プロンプトを都度打つ発想から、判断の仕組みそのものを設計する発想への転換でした。

• Claude Code開発責任者ボリス・チェルニー氏の「もうプロンプトは書かない」という発言がきっかけで広がった概念
• Claude Codeの/goalコマンドは、完了条件を先に書いておき、評価モデルがターンごとに満たしたかを確認する仕組み
• 良い停止条件は「測定可能な終了状態」「証明の方法」「守るべき制約」の3要素で構成される
• /routinesと組み合わせると、スケジュールに従って自動で起動し、条件を満たすまで動いて止まる自律ループになる
• 概念自体がまだ新しく、日本語の実践知見はこれから蓄積される段階

僕自身、この記事を書きながら「便利そうだ」という気持ちと「怖さ」の両方を感じました。それでいいのだと思います。不安を抱えたまま試してみることでしか、本当に使える技術かどうかは分からないはずです。まずは自分の作業を1つだけ選んでください。終わりの条件を3つの型で書き出すところから、一緒に始めてみませんか。