Datawhaleの実践的コンテンツ
著者：王大鵬、Datawhaleメンバー
先日、私たちは「速報！ループエンジニアリング実践マニュアル公開」を共有し、ループエンジニアリングの6つの中核コンポーネントと実装方法を体系的にまとめました。
今回は補足として、Loopの進化の系譜と、Loopの本質に対する理解を深めていきます。最近の2つの見解から話を始めましょう。
2026年6月、Anthropic Claude Codeの責任者であるBoris Cherny氏が、驚くべき発言をしました。
「私はもうClaudeにプロンプトを出していない。動いているループがある。それらがClaudeにプロンプトを出し、何をすべきかを判断している。私の仕事はループを書くことだ」
興味深いことに、多くの開発者が完璧なプロンプトを作ることに注力する一方で、ツールを作る側の人々はプロンプトを完全に放棄しているのです。
同じ週に、OpenClawの創設者であるPeter Steinberger氏も、別の言い方で同じことを表現しました。
「もうコーディングエージェントにプロンプトを出すべきではない。エージェントにプロンプトを出すループを設計すべきだ」
異なる場所、異なる製品で、2人が同じ結論に達したのです。これは偶然ではなく、ある種のエンジニアリング手法が自然な転換点を迎えたように見えます。
この記事で議論する問題は、Loopはどこから来たのか？ いったい何を解決するのか？ そして、多くの人にとって、今それを作り始めるべきかどうか？です。
一、プロンプト → コンテキスト → ハーネス → ループ
ループエンジニアリングを理解するには、その前に何が起きたか、つまり一連の流れ全体で何が起こったのかを理解しなければなりません。
話は2024年に遡ります。当時のAIとの協働方法はシンプルで、プロンプトを書き、モデルが結果を返すというものでした。プロンプトエンジニアリングという言葉は、この段階で発明されました。適切な言い回し、例示、書式指定によって、モデルに望み通りの出力をさせられる、というものです。
この手法には根本的な限界があります。モデルが必要とするすべてを、1つのメッセージの中で事前に予測しなければならないのです。背景、ルール、例、制約をすべて詰め込む必要がありました。モデルは見たものだけを知り、見えないものについては推測するしかありませんでした。
2025年初頭になると、問題はプロンプトの言い回しにあるのではなく、モデルが受け取る情報量が少なすぎることにあると認識されるようになりました。ここでコンテキストエンジニアリングが登場します。もはや「どう問うか」にこだわるのではなく、モデルが「見る」ものを注意深く構築するようになったのです。システムプロンプトで役割とルールを提供し、フューショットの例で出力形式を調整し、RAG検索でリアルタイムの知識を注入し、構造化された入力でモデルが要件の境界を正確に理解できるようにします。
コンテキストが整えば、モデルは推測しなくなります。しかし、ここで新たな問題が浮上します。情報が完璧でも、複雑なタスクは一度では完了しないのです。モジュールのリファクタリングには、まずコードを読み、次にインターフェースを変更し、呼び出し元を更新し、テストを実行して検証する必要があります。これは1つのプロンプトで完了できることではありません。モデルは複数ステップの実行、ツールの使用、中間結果を観察して次の一手を決めることを必要とします。
そこでハーネスエンジニアリングが登場しました。この名前は少し奇妙ですが、非常に具体的なことを指します。エージェントにツール（シェルコマンド、ファイルシステムの読み書き、MCPコネクタ、サンドボックス環境）を装備し、リトライ機構と権限制御を与えて、1回のセッション内で複数ステップの操作を完了できるようにするのです。Claude Code、Cursor、Codexといった製品は、本質的にすべてハーネスです。タスクを与えると、エージェントは自らステップを計画し、ツールを呼び出し、結果を観察し、失敗したら再試行します。
ハーネスは「単一セッション内での実行能力」の問題を解決しました。しかし、より大きなボトルネックである「人間」は解決しませんでした。
あなたは装備の整ったエージェントを持っています。コードを読み、書き、テストを実行し、PRを作成できます。しかし、毎朝、あなたはPCを開き、CIのステータスを確認し、エラーログをコピーし、そのログをエージェントに貼り付け、修正が終わるのを待ち、結果をレビューし、マージを承認します。翌日も同じことです。3日目にはうんざりするかもしれません。
この時点で、エージェントの能力はボトルネックではなく、人間こそがボトルネックなのです。
ループエンジニアリングの出発点はまさにここにあります。「人間がエージェントをトリガー → 人間が結果を判断 → 人間が次の一手を決める」というループから人間を排除し、自動化システムに置き換えることです。このシステムは、定期的にトリガーをかけ、結果を検証し、前回どこまで進んだかを記憶し、続行するか、停止するか、報告するかを決定できます。
あなたはもはやプロンプトを書く人ではありません。プロンプトシステムを設計する人なのです。
二、Loopを動かすために必要なもの
業界で一般的なLoopは6つのコンポーネントから成ります。具体的なシナリオで見ていきましょう。
あなたのチームが毎日CI（継続的インテグレーション）でテストが失敗する問題に直面しているとします。特定のテストが失敗したり、型チェックでエラーが発生したりする状況です。Loopがない場合のフローはこうです。朝PCを開き、CIが失敗しているのを確認し、エラーログをコピーしてエージェントに貼り付け、修正を待ち、テストを実行し、PRを作成します。これを毎日繰り返します。
Loopがある場合のフローはこうなります。毎朝8時、システムが自動的に起動します。次に起こることは、1回の完全な実行サイクルです。
1. やるべきことを見つける（Automations）。システムがCIのステータスをチェックします。すべて成功していれば何もしません。失敗があれば、エラーログを読み取り、その日の作業目標を決定します。これはトリガー層です。Loopは、cronのようなタイマー、CI失敗時のwebhookのようなイベント、あるいはエージェント自身のヘルスチェックなど、何かがLoopを「起こす」必要があります。これがなければ、Loopは自ら開始しません。
2. 隔離：クリーンなワークスペースを開く（Worktrees）。システムは独立したgit worktree内で修正を開始します。なぜメインブランチで直接修正しないのでしょうか？それは、もし3つの修正タスクを同時に実行する場合、それらが同じコードディレクトリ内で互いに上書きし合うことができないからです。各サブタスクは、互いに干渉しない自分自身のコピーを必要とします。
3. ルールを読む：ゼロから始めない（Skills）。エージェントは起動時に、まずプロジェクトの知識ファイルを読み込みます。CodexではAGENTS.md、Claude CodeではCLAUDE.md、より詳細なスキルファイルはSKILL.mdと呼ばれます。名前が何であれ、やることは同じです。コーディング規約、アーキテクチャの取り決め、よくある落とし穴などを書き留めておき、エージェントが起動するたびに自動的に読み込むようにします。そうしなければ、毎回のセッションでプロジェクトを「学習」し直すことになり、トークンと時間を無駄にします。
4. 行動する：実世界と接続する（Connectors）。エージェントがコードを修正した後、PRを作成し、チケットをクローズし、あなたに通知する必要があります。これには、MCPを通じてGitHub、Linear、Slack、データベースなどの外部システムにアクセスし、外部とやり取りしたり通知したりする能力が求められます。
5. 検証する：別の評価者に採点してもらう（Sub-agents）。修正後、自動的にテストを実行します。しかし、ここで重要な設計上のポイントがあります。コードを書いたエージェントは、自分のコードを自分で検証することはできません。学生が自分の答案を採点するようなもので、犯した間違いこそが、発見できない間違いなのです。別のエージェントを使ってチェックする必要があります。
6. 記憶する：今日何が起こったかを書き留める（Memory/State）。テストが成功すればPRを作成し、状態ファイルを更新します。失敗した場合は、「今日何を試し、どこで行き詰まったか」を状態ファイルに書き込みます。次回Loopが起動したときにこのファイルを読み込むことで、前回どこまで進んだか、何を試して失敗したかを把握できます。エージェントのコンテキストウィンドウは毎回クリアされますが、ディスクを使用して知識ベースを記憶できます。
これが1回の完全なLoopの実行です。あなたが朝PCを開いたときに見るのは、もはや「CIが失敗しました」ではなく、「レビュー待ちのPRがあります」とか、「この問題は2日間解決できていません。確認が必要です」といったものです。
ここで疑問が湧くかもしれません。これはcronジョブと何が違うのか？ 単にスケジュール実行されるタスクのように見える、と。
違いは、cronのロジックは書き込み時に決定されているという点です。「もしCIが失敗したら、修正スクリプトを実行し、コミットする」といったハードコードされたif-elseです。Loop内部の意思決定者はLLMです。同じ「CIが失敗した」という状況でも、「これは不安定なテストだからスキップしよう」と判断するかもしれませんし、「これは3つのファイルにまたがる依存関係の変更を伴うため、段階的に処理する必要がある」と判断するかもしれません。その動作は実行時に初めて決定されます。なぜなら、意思決定者に判断力があるからです。
三、Loopの本質：サイバネティクス（制御理論）
これまで、ループエンジニアリングに関する議論のほとんどは、Worktreesで隔離し、Connectorsで接続し、Memoryで記憶する、といったオーケストレーションの問題として扱われてきました。これらは「どのように組み立てるか」に答えるものであり、「なぜそのように組み立てるのか」には答えていません。
先ほどのCIトリアージの例に戻りましょう。そのプロセスが何をしているのかを注意深く見てみると、「目標（全テストが成功すること）」、「実行アクション（エージェントがコードを修正すること）」、「チェック（テストスイートを実行して偏差を報告すること）」、「フィードバック（失敗情報をエージェントに送り返し、再度実行させること）」という構造があります。
この構造には見覚えがあります。自宅のエアコンは設定温度を25度にすると、コンプレッサーが冷房を開始し、温度センサーが室温を測定し、まだ25度に達していなければ冷房を続け、達したら停止します。車のクルーズコントロールは速度を120km/hに設定すると、エンジンが出力を調整し、速度センサーが実際の速度を測定し、低ければ加速し、高ければ減速します。
これらは本質的に同じ構造です。目標 → 実行 → 偏差の測定 → フィードバック修正 → 再測定。
この構造には共通の名前があります。サイバネティクス（制御理論）です。これは、「システムがフィードバックを通じて目標状態をどのように維持するか」を研究する学問分野で、1940年代に誕生しました。その核心的な問いは、「システムが外乱を受けたときに、どのように自動的に目標へと修正し戻すか」という一点に尽きます。この理論は、そのようなシステムを「コントローラ（制御器）：何をするかを決定する」、「アクチュエータ（操作部）：実行する」、「センサー：実行がどれだけうまくいったかをチェックし、偏差をコントローラに送り返す」という3つの役割に分解し、この3つが閉ループを構成します。
まずコントローラを見てみましょう。
閉ループには意思決定センターが必要です。偏差信号を読み取り、次にどのように修正するかを決定します。これがコントローラです。エージェントのシナリオでは、コントローラはオーケストレーションロジック全体にあたります。検証結果を読み取り、目標に達したか判断し、達していなければ次のプロンプトを構築して再度実行します。
コントローラが適切な判断を下すには、2つの困難があります。第一に、プロジェクトがどのように動くか（コーディング規約、アーキテクチャの取り決め、ツールの使い方）を知りません。毎回ゼロから推論するのは遅く、不安定です。そこで、これらのルールを書き留めておき、コントローラが起動時に直接入手できるようにする必要があります。これがSkillsの存在理由です。第二に、前回どこまでやったかを覚えていません。コンテキストウィンドウは毎回クリアされ、今日は昨日何を試したかを知りません。そこで、セッションを超えて存続する永続的な状態が必要になります。これがMemory/Stateの存在理由です。
次にアクチュエータを見てみましょう。
閉ループには、決定を実世界へのアクションに変える役割が必要です。これがアクチュエータです。エージェントのシナリオでは、アクチュエータはツール呼び出し層にあたります。ファイル編集、シェルコマンド、API呼び出しなどです。
アクチュエータが正確に操作するには、やはり2つの困難があります。第一に、外部世界にアクセスできません。コントローラが「PRを作成せよ」と言っても、実際にGitHubに接続できなければなりません。そこで、アクチュエータの手を遠くまで伸ばす必要があります。これがConnectors（MCPプロトコルを通じて接続される外部サービス）の存在理由です。第二に、複数のエージェントが並行して動作するときに互いに上書きし合う可能性があるため、隔離された操作スペースが必要です。これがWorktreesの存在理由です。
最後にセンサーを見てみましょう。
閉ループには、実行完了後に結果を測定し、偏差を報告する役割が必要です。これがセンサーです。エージェントのシナリオでは、センサーは検証にあたり、目標からどれだけ離れているかという誤差信号を生成します。
センサーは「独立性」という構造的な困難に直面します。もし実行するエージェントが同時に検証者も務める場合、エラーには相関が生じます。バグを引き起こした盲点は、まさにそのバグを見えなくしている盲点と同じだからです。問題を解いた後、同じ考え方で見直しても、間違いを発見できない可能性が高いのと同じです。そこで、別のエージェント、あるいは別のモデルを使ってチェックする必要があります。これがSub-agentsの存在理由です。
これら3つのいずれにも属さないものがもう一つあります。Automations（タイマー、イベントトリガー、ヘルスチェック）です。これは閉ループの開始条件、つまり誰がスタートボタンを押して回路を回し始めるかです。これがなければ、3つの役割がどれほど完璧でも、自ら能動的に動作することはありません。
ここに至り、ループエンジニアリングの6つのコンポーネントには帰属先ができました。これらは寄せ集めの部品ではなく、制御が自然に必要とする基盤なのです。コントローラには知識と記憶が必要だからSkillsとMemoryが生まれ、アクチュエータにはリーチと隔離が必要だからConnectorsとWorktreesが生まれ、センサーには独立性が必要だからSub-agentsが生まれ、閉ループは自ら起動しないからAutomationsが生まれたのです。
ここで、制御工学がずっと以前から問いかけてきた問いを投げかけましょう。この閉ループが動き出したら、どうなるでしょうか？
エアコンが制御する対象は安定しています。加熱能力と温度の関係が突然変わることはありません。しかし、あなたが制御しているのは言語モデルです。同じ入力を2回与えても、出力はまったく異なる可能性があります。ランダム性が強いほど、フィードバックによる修正は不可欠になります。
このシステム上でLoopを実行すると、3つの結末があります。
正しい状態に収束する。エージェントが目標を達成し、検証が成功し、かつ検証に偽りやハルシネーションがない場合です。これが唯一望ましい結末です。
誤った状態に収束する。Loopは停止します。センサーが「成功」と報告したからですが、そのセンサーが間違っているのです。テストが成功したのはテスト自体の記述が間違っているからか、ビルドが成功したのは問題のあるパスが実行されなかったからか、レビューエージェントが成功したのは簡単に同意しすぎたからかもしれません。これは永遠に停止しないよりも悪いことです。自信を持って停止してしまうからです。
発散する。Loopがセンサーの受け入れる状態に達せず、修正すればするほど目標から逸れてしまい、最終的に上限に達して終了します。
AIに、より複雑なことをさせたいが、品質にも要求がある場合、「固定された計画」でこのシステムをコントロールすることはできません。そこで制御理論が提供するフレームワークは、「正しく収束する」結末の確率を高めるか、後者2つの結末による損失を制限することです。
では、これら3つの役割の中で、収束速度を決定するのはどれでしょうか？ それはセンサーです。
同じ検証を行うにしても、あるセンサーは合格/不合格だけを返します。コントローラはそれを受け取ると、「まだだめだ」とはわかっても、どこがだめなのかわからないため、次の修正はほぼ当てずっぽうになります。しかし、センサーが「どのテストケースが失敗したか、どのアサーションが失敗したか、どのdiffが原因か」を返せば、コントローラは推測するのではなく、特定の欠陥に対して修正を行うことができます。探索空間がさらに圧縮されるのです。
多くの人の直感は逆です。コードを書かせるために最も高価で強力なモデルに大金を投じ、検証には簡単なチャットを使い、最終的にハルシネーションを繰り返して目標からどんどん逸れていきます。高いレバレッジが効く方法は、より豊かな信号を返す優れたセンサーを設計することであり、単にモデルを賢くすることだけに注力しないことです。
このロジックはまさにこれです：「優れたプロンプト + 弱い検証」は失敗する。「平凡なプロンプト + 強力な検証」は収束する。センサーこそが設計そのものなのです。
四、Loopが必要かどうかをどう判断するか
センサーが鍵であるならば、「Loopを構築すべきかどうか」を判断する問題は、より具体的な問いに変換されます。
あなたは、自分の目で監視しなくても、悪い出力を拒否できる自動チェックを書けますか？
書けるなら、閉ループの前提条件を満たしています。書けないなら、「完了」とは主観的な判断になります。
たとえ閉ループが可能でも、いくつかの現実的な制約があります。タスクは反復的でなければなりません。少なくとも週に1回は発生するものでなければ自動化する価値はありません。そうでなければ、非常に高価な使い捨てスクリプトを作っていることになります。トークン予算が無駄を許容できる必要があります。Loopはコンテキストを再読み込みし、失敗した経路を再試行します。成果が出るかどうかに関わらず、探索の各ステップがトークンを消費します。エージェントは結果を観察するための十分なツールを持っていなければなりません。そうでなければ、盲目的な修正になります。
私たちがよく犯す間違いの一つに、目標が測定不可能なタスクの設計があります。例えば、「このコードをリファクタリングしてもっとエレガントにしてくれ」「良い技術ブログを書いてくれ」「良いAPIを設計してくれ」といったものです。これらには客観的な合格/不合格の基準がありません。「エレガント」「良い」は主観的な判断です。別のLLMに採点させることはできても、LLMの採点自体が信頼できません。高得点をつける傾向があり、基準もドリフトします。このような状況でLoopを構築すると、センサーは「合格」と言いますが、その「合格」には客観的な基準が何もないため、偽の閉ループとなります。
もし自分が条件を満たしていると判断したなら、着手する順序はこうです。まずSkillsを書き（意図を明確にし、エージェントに毎回ゼロからあなたの基準を推論させない）、次にセンサーを書き（「何をもって完了とするか」を正確に定義できるようにする）、最後にcronトリガーを適用します。Inspector（検証器）を先に構築し、それからLoopを構築するのです。
Loopは、それを操作する人が誰かを気にしません。「センサーを読む → 判断する → もう一度やる」というサイクルを回すだけです。しかし、センサーはあなたが書きます。あなたのシステムへの理解が深ければ深いほど、センサーはより正確に書けます。Loopが増幅するのは、あなたの判断力なのです。
付録、参考資料
- Loop Engineering: The New Way to Use Claude Code & Codex — Addy Osmani
- Loop Engineering Is NOT What Everybody Thinks It Is — Agent Native Dev
- How Claude Code, Codex, and Cursor Do Loop Engineering
- Loop Engineering — Cobus Greyling
- Why Is Loop Engineering Trending
- Loop Engineering Is Replacing Prompt Engineering
- What is Loop Engineering? How it is different than Harness Engineering — Akshay Kokane
- Loop Engineering Is Here. Most of You Should Not Build One Yet
- How To Build a Claude Loop Engineering Better Than 99% of People
一緒に「いいね」「三連」をお願いします↓