ループエンジニアリング

2026年9月5日

🐧 要するにどういう話か

AI（LLM）は当初、いかにうまくほしい結果を出力させるか、いかに楽をできるかが問題だった。そのうち、AIが勝手に考え、行動できるようになるにつれ、それにいかに必要最低限の文脈を与えるか、いかに便利で安全な枠組みを与えるかが問題になった。それを考えるのがコンテキストエンジニアリング、ハーネスエンジニアリングである。その結果、AIにいかに長時間、安全・確実に意図したタスクをさせ続けられるかを考えることが重要になってきた。それがループエンジニアリングである。

1. ループエンジニアリングとはなにか

ループエンジニアリングとは、AIエージェントのプロンプト・チェック・記憶・再実行を、人が1ターンずつ手動で行う代わりに、そのすべてを担うシステムを設計する実践である。

Peter Steinberger氏はこう述べている。「コーディングエージェントにプロンプトを書く時代は終わった。プロンプトを書くループを設計すべきだ。」AnthropicでClaude Codeを率いるBoris Cherny氏はより直接的に言っている。「もうClaudeにプロンプトは書かない。ループがClaudeにプロンプトを書いて、何をすべきか判断している。僕の仕事はループを書くことだ。」

核心となる概念は再帰的目標（recursive goal）である。次のステップを1つずつ打ち込む代わりに、目的を定義する——「テストスイートを通す」「未対応のissueをすべてトリアージする」——そしてエージェントがその目的を達成するか、停止条件がトリガーされるまで自分で反復する。

これはチェーン（あるいはパイプライン）とは根本的に異なる。チェーンは固定順序で動く。ステップA、B、C、終わり。ループは動的である。AからBに進み、Bがうまくいかなかったと気づき、方針を修正して戻ってくる。検証可能な条件が満たされるまで繰り返す。

2. 登場した背景

2.1 用語が定着するまで

2026年6月、「ループエンジニアリング」という用語がニッチなフレーズから業界の語彙に変わったのは約1週間のことだった。

• 6月7日 — OpenClawエージェントプロジェクトの作者Peter Steinberger氏がXに投稿。関連するスキルが変化した、プロンプトを書くのではなくループを設計すべきだ、と。その投稿は数日で650万ビューを超えた。
• 6月8日 — Addy Osmani氏が「Loop Engineering」を公開。アイディアに具体的な解剖学を与えた。Automations、Worktrees、Skills、Connectors、Sub-agents、そして外部メモリ。バイラルな主張を、他者が積み上げ・議論できる語彙に変えた。
• Claude Codeを率いるBoris Cherny氏が、もう直接Claudeにプロンプトを書いていないと発言。市場で最も使われているコーディングエージェントの一つを作る人がそう言うなら、この考えはもうニッチな意見とはいえないだろう。

このタイミングは説明がつく。2026年半ばまでに、コーディングエージェントは自分のミスを自分で回復しながら、長時間無監督で実行できるようになっていた。1回のエージェント実行が1時間続き、何十ものファイルに触れるようになったら、ボトルネックはもはやプロンプトの鋭さではない。ある時間中、誰も見ていない時間帯も含めて、エージェントを生産的に、チェックされ、正しい目標に向かせ続けるサイクルを作れているかどうかが問題である。

2.2 技術の進化（階層の積み重ね）

ループエンジニアリングは突然現れたのではない。各層が内側の層を包む、一貫した進化の上に成り立っている。

• プロンプトエンジニアリング（2022–2024）: 表現の最適化。モデルに役割を与え、タスクをステップに分解し、例を示し、段階的に推論させる。完璧に構成されたプロンプトでも、モデルに与えられたことのない事実を伝えることはできない。
• コンテキストエンジニアリング（2025）: モデルが応答する瞬間に実際に見るものすべて。会話履歴、取得したドキュメント、ツールの出力、そのステップのために集めたあらゆる情報。プロンプトはコンテキストエンジニアリングの一部となった。
• ハーネスエンジニアリング（2026）: エージェントの周囲の環境全体。スケルトン、与えられたツール、制約、ミスを捕まえるフィードバックループ。エージェントを「できる」から「頼れる」にするもの。ハーネスはコンテキストを含み、コンテキストはプロンプトを含む。
• ループエンジニアリング（2026）: ハーネスエンジニアリングが「エージェントに必要な環境は何か」を問うのに対し、ループエンジニアリングはより狭く、より操作的に問う。エージェントを目標に向かせるサイクルは何か、そしてそのサイクルはいつ止まるのか。それ以前のすべての層を動かし、リズムを与える層である。

どの層も、その前の層を置き換えなかった。いずれにしてもプロンプトは書くし、コンテキストを整理するし、ハーネスを構築する。

2.3 研究の系譜

ループエンジニアリングの背後にある仕組みは数週間ではなく、約5年前に遡る。系譜を知ることが、トレンドを追いかけることと本質的な理解とを分ける。

• ReAct（2022, Yao et al.）: 推論ステップと行動ステップを交互に実行する。モデルが何をするか考え、行動し、何が起きたか観察し、また考える。この推論→行動→観察→繰り返しの交互が、現代のコーディングエージェントのほぼすべてが今も実行している基本ループである。
• Reflexion（2023, Shinn et al.）: メモリと自己批判を追加。Actorが作業をやり、Evaluatorが結果を採点し、Self-Reflectionが「インポートパスが間違っていたから失敗した」のような言語的な教訓をエピソード記憶に書き込み、次の試行で読み直す。モデルを再訓練せずに、1セッション内で目に見えて改善するループの仕組みである。
• Evaluator-Optimizer / Orchestrator-Workers（Anthropic, 2024）: Evaluator-Optimizerパターンでは、1つのモデルが候補を生成し、別のモデルが明示的な基準でチェックし、評価が通るまで繰り返す。Orchestrator-Workersパターンでは、中心のモデルが大きなタスクを小さなピースに分解し、それぞれをクリーンなコンテキストウィンドウ付きのワーカーに渡し、結果を結合する。これは実務者が今使っている「サブエージェント」「ワークツリー」の形式バージョンである。

ループエンジニアリングは、2022年以来静かに成果を蓄積してきた研究方向のプロダクト名であり、スローガンである。2026年6月の出来事はループを発明したのではない。一般の開発者が、意図的にループを構築し始めるための理由と語彙を与えたのである。

3. ループの構造

3.1 コアループ

どのツール、どのチームが作ったかに関係はなく、実際に信頼できるループには同じ構造がある。

• 推論（Reason）: モデルが現在の状態——目標、これまでに試したこと、蓄積したコンテキスト——に基づいて、何をすべきかを考える。
• 行動（Act）: 1つの具体的なツール呼び出しにコミットする。コードを実行する、ファイルを読む、テストランナーを呼ぶ、PRを開く。
• 観察（Observe）: 環境から結果が返ってくる。ここが、推測ではなく実際のフィードバックを得る場所である。
• 判断（Decide）: 結果を状態に反映する。そして確認する。検証器が通ったか？通ったらループは完了。進捗がなければ、予算を使い切ってしまったら、人間にエスカレーションする。それ以外はもう一度ループする。

本当の出口はちょうど2つある。検証された成功（決定論的なチェックが目標達成を確認）と人間へのエスカレーション（ループが詰まり、人間が引き継ぐ必要がある）。それ以外はただの反復である。

信頼できるループにはさらに以下が必要である。

• 真にテスト可能な終了条件を持つ目標。「アプリを良くする」はエージェントに何をチェックしていいかを与えない。「authモジュールの全テストを通す」は機械的にチェック可能である。
• 実際の環境に触れるツールセット：コード実行、ファイルシステムアクセス、ターミナル、テストランナー、リンター。ループのフィードバックは、それを生成するツールと同じくらいしか信頼できない。
• コンテキスト管理：各反復で記録に追加が増え、コンテキストウィンドウは有限である。
• 明示的な終了とエスカレーションロジック：真の成功条件、真の失敗条件、人間に問題を渡す定義済みの経路。
• エラー処理：回復可能な問題（不正なインポート、失敗するアサーション）とハードブロッカー（認証情報の欠如、未定義のAPI）を区別する。同じエラーの後で同じアクションを繰り返すループは適応していない。回り込んでいるのである。

3.2 ループを構成する部品

実践的なループは小さな部品セットで構築される。CodexもClaude Codeもすべてをネイティブに搭載している。

• Automations（自動化）— 心臓部。スケジュールやイベントに応じて発火し、人が起動しなくても実行を開始するもの。CodexではAutomationsタブで、プロジェクト、プロンプト、頻度、ローカルまたはバックグラウンド環境を選ぶ。結果はトリアージインボックスに入る。Claude Codeでは、セッション内の区間は /loop、クラウド上の定期タスクは /schedule、cronタスク、フックが同等の役割を担う。
• Worktrees（ワークツリー）— 並行エージェントの分離。git worktreeは同じリポジトリ履歴を共有する別ブランチ上の独立した作業ディレクトリであり、1つのエージェントの編集が物理的に別のエージェントのものを上書きできない。Codexはスレッドごとにworktreeを内蔵。Claude Codeは git worktree、--worktree フラグ、サブエージェント向けの isolation: worktree 設定を提供する。
• Skills（スキル）— 会話の外に書き留めたプロジェクト知識。SKILL.md を持つフォルダで、規約、ビルド手順、「あの1回のインシデントのためにこうはしない」のような知識を保持する。一度書けば、以降のすべての実行で読み込まれ、毎回ゼロから再導出されない。
• Plugins / Connectors（プラグイン/コネクタ）— MCPを基盤に、ループがファイルシステムの外、issueトラッカー、データベース、ステージングAPI、Slackチャンネルに到達させる。これらがなければ、ループは「こうします」と言うことしかできない。これらがあれば、PRを開き、チケットをリンクし、CIがグリーンになった時点でチャンネルに通知する。
• Sub-agents（サブエージェント）— 書く者とチェックする者を分ける。コードを書いたモデルは自分の課題を採点する際に見栄えがいい。別のエージェント、場合によって別のモデルで、1つ目の出力を仕様に照らしてレビューする。Codexでは .codex/agents/ にTOMLファイルとして定義する。Claude Codeでは .claude/agents/ に置くか、エージェントチームを使う。
• External state（外部状態）— Markdownファイル、Linearボード、ログ。モデルは実行間でメモリを持たないため、ループが学んだことは、次の実行が自分で読み戻せる耐久性のある場所に置かなければならない。エージェントは忘れるが、記録は忘れない。

3.3 ループのタイプ

すべてのタスクに同じ形のループが必要なわけではない。Claude Codeのドキュメントは4つのタイプを特定している。それぞれがより多くの作業を委譲していく。

• ターンベース — ユーザーのプロンプトでトリガーされる。Claudeがコンテキストを集め、行動し、作業をチェックし、応答する。各ターンを自分で指図する。定期的なプロセスの一部ではない、短いタスクに向く。チェックを委譲する。
• ゴールベース（/goal） — 自分が書いた条件が検証で真になるまで、Claudeが反復を続ける。各ターン後、別々の評価者モデルが目標達成を確認し、未達成なら作業に戻す。「全テストが通っていてlintがクリーン」という、検証可能な終了条件を持つタスクに向く。停止条件を委譲する。
• 時間ベース（/loop, /schedule） — プロンプトを間隔で再実行するか、定期タスクをクラウド上でスケジュール実行する。PRがレビューを受けたりCIが失敗したりするなどの、外部的に変化するシステムとやり取りする定期的な作業に向く。トリガーを委譲する。
• 能動型（Proactive） — 人間がリアルタイムにいない状態で、イベントやスケジュールでトリガーされる。上記すべてのプリミティブを組み合わせた長時間実行の定期タスク。バグレポート、issueトリアージ、マイグレーション、依存関係のアップグレードなどの、繰り返し定義済みの作業ストリームに向く。プロンプト自体を委譲する。

3.4 ループのスタッキング

本番システムは単一のループを1回実行するのではない。ループを何層も積み重ねる。LangChainは内部のドキュメント作成エージェントを例に、4つのレベルを説明している。

• Level 1: Agent loop — モデルがタスク完了までツールを繰り返し呼び出す。
  • 役割：作業自体を自動化する。
  • ドキュメントエージェントの場合：改善のリクエストを受け取り、変更を計画し、リポジトリをクローンし、ファイルを読み、ドキュメントを書き、PRを開く。
• Level 2: Verification loop — 評価者（グレーダー）が評価基準（ルーブリック）でエージェントの出力を採点し、不合格なら具体的なフィードバック付きで戻す。
  • グレーダー（grader）: 出力を評価するもの。テスト実行などの決定論的なコードでも、別モデル（LLM as a judge）でもよい。
  • ルーブリック（rubric）: 評価基準のチェックリスト。例：「全リンクが解決すること」「CIが通ること」「diffが要求範囲内であること」。
  • ドキュメントエージェントの場合：すべてのリンクが解決するか、すべてのCIチェックが通るか、diffが要求された範囲内に収まるかを確認する。
  • トレードオフ：検証は実行ごとにレイテンシとコストを加える。品質が速度より重要な場合、つまりほとんどの本番ユースケースでは、その価値がある。
• Level 3: Event-driven loop — イベント（新しいドキュメントの到着、スケジュールのトリガー、webhook）が発火するとエージェントが実行する。
  • 役割：エージェントを手動で呼び出すものではなく、より大きなシステムの中で連続して動くコンポーネントにする。
  • ドキュメントエージェントの場合：Slackチャンネルにメッセージが届くと、その場で実行するかを決める人間なしにエージェントが発火する。
• Level 4: Hill-climbing loop — 各実行が生成するトレースを分析し、発見からハーネスを書き直す。
  • 役割：作業を自動化するのではなく、改善自体を自動化する。
  • トレース：モデルが何をし、どのツールを呼び、グレーダーがどのようなフィードバックを与えたかの記録。
  • 改善の内容：プロンプトの調整、グレーダーの厳格化、ツールの説明文の修正など。
  • ドキュメントエージェントの場合：複数のトレースが同じ問題を指し示すと、該当するプロンプトやツールの変更をリクエストするissueが起票される。
  • 重要な点：フィードバックは同じサイクルのトップに戻ってくるだけではない。内側のループに直接達して更新するため、外側のループを1周するたびに内側のループが目に見えて良くなる。

ほとんどのチームはLevel 1と2に時間を費やしてきた。まだ掘られていない価値はLevel 3と4にある。そこでエージェントは呼び出すものから、実際のシグナルに応じて継続的に良くなる、システムに組み込まれたものとなる。

4. 設計上の3つの難題

この3つのうち1つでも誤ると、1時間クリーンに動き続けるループと、溢れたり、回り込んだり、静かに嘘をついたりするループの違いが生まれる。

4.1 コンテキスト管理

コンテキストウィンドウはエージェントのワーキングメモリとして機能し、ハードリミットがある。長時間のループでは、各ステップで記録への追記が増える——推論、ツール出力、エラー——管理されない限り、その記録は溢れるか、品質が劣化する。モデルが、どんどん長くなるトランスクリプトの奥に埋もれた本当に重要なことに確実に注目しなくなる。これをコンテキスト劣化（context rot）と呼ぶ。

対策は、ループの中でコンテキストエンジニアリングを適用することである。古いステップを短い要約に圧縮し、陳腐化した出力を剪定し、サブエージェントを分離して副次タスクを独自のクリーンなウィンドウで実行させ、結論だけ報告させる。

4.2 終了判定

ループには、いくつかの独立した出口を積み重ねる必要がある。

• 実際の目標が達成されたことを確認する検証器
• 反復回数にハードキャップ
• トークンまたは実時間の予算
• 無進捗検出：直前の数ステップが同じエラーを生成したか、状態が機能的に変化していない

この多層の出口がなければ、ループは永遠に走り続けるか、推測で恣意的に止まる。

4.3 検証

ゴールドスタンダードは決定論的検証——テスト、型チェッカー、コンパイラ、リンター——である。これらはモデルが言い逃れできない客観的な合格/不合格を返すからである。

LLMが自分の判定官になるのは柔軟で、機械的にチェックできないものには本当に必要な場合があるが、自分に甘くなりがちである。自分が生成した作業を自分で採点するのは構造的に弱いチェックである。最強のループは、決定論的検証器が存在する限りそれに頼り、モデルの判断は本当に他の方法では定量化できない部分に限定して使う。

これが、作成者とチェックする者を分けるのが重要な理由でもある。ループはあなたが見ていない間に動くため、実際に信頼できる検証者がいることが、離席できる唯一の理由なのである。

4.4 失敗モード

上記の3つの問題の処理が不適切だと、予測可能な失敗が起こる。

• コンテキスト溢れ・破断： ウィンドウが埋まり、エラーメッセージもなしに出力品質が劣化する。
• 無進捗ループ： エージェントが同じ失敗する手順を無限に繰り返す。
• Reward hacking： ループが本当の目標ではなくチェック可能な代替指標を最適化する。典型的な例は、失敗するテストを削除してCIをグリーンにするエージェントなど。
• 幻覚的成功： 実質的な検証なしに「完了」と報告する。
• コスト爆発： 長いループが、タスクに本来必要だったものよりはるかに多くのトークンを静かに燃やす。

これらすべてに共通する根本的な対策は、ループの内部に、エージェント自身の言葉ではなく、真の・外部の・決定論的なチェックを置ることである。

5. 人間の役割

5.1 ループが解決しないこと

• 検証の最終責任は人間にある。 無監督で動くループは、無監督でミスをやるループでもある。作成者と検証者を分ける理由は、ループの「できた」に意味を持たせるためだが、それでも「できた」は主張であり証明ではない。あなたの仕事は、自分が確認したコードをリリースすることである。
• 理解は劣化する。 ループが、あなた自身に書かれなかったコードを高速にリリースするほど、存在しているものと実際に理解しているものとの間のギャップは大きくなる。これを理解負債（comprehension debt）と呼ぶ。滑らかなループは、ループが作ったものを読まなければ、その成長をただ速くするだけである。
• 快適な姿勢が最も危険な姿勢である。 ループが自分で動くと、意見を止め、何でも受け取ってしまう誘惑が生まれる。これを認知委譲（cognitive surrender）と呼ぶ。判断を込めてループを設計すれば認知委譲という病の防止になるが、考えることを避けるために設計すればその病を加速させてしまう。同じループの設計なのに、真逆の結果を得る。

5.2 各層での人間のチェックポイント

• Agent loop： 本当に敏感なツール呼び出し——金融取引、データベース書き込み——の前に明示的な人間の承認を要求する。
• Verification loop： ルーブリックだけではリスクの高い作業では、人間がグレーダーになる。
• Event-driven loop： 出力がエンドユーザーに届く前に人間が承認する。
• Hill-climbing loop： ハーネスの改善はデプロイ前に人間のレビューを通過する。

これらのチェックポイントはどれもしつこいものではない。ループの他の部分と同じ、意図的な設計選択である。

5.3 ループエンジニアリングは何でないか

• すべての作業に必須なものではない。真に一回性のタスクでは、能力のあるエージェントとの対話セッションの方が、フルのループを設計するオーバーヘッドより速く安全なことが多い。
• 人間の判断をなくすものではない。判断が適用される場所を移すだけである。誰かがまだ目標を所有し、「完了」の定義を持ち、出力が本当に正しいかどうかの最終判断を下す。
• 間違って指定された目標を最適化するループは、間違ったものを本当に効率的に追う。真の検証なしの速いループは、遅いループより速く間違った答えを生成するだけである。

6. はじめ方

6.1 まずシンプルなループから

最も有用な出発点は、上記のすべての中で最もシンプルなバージョンである。

• 1つの目標、チェック可能に十分具体的に述べる
• 1つの決定論的検証器——モデルの自己評価ではなく、実際のテストスイート
• 反復回数のハードキャップ
• ループが詰まった場合のエスカレーション経路を1つだけ（半端なものを複数作る代わりに）

最初に選ぶタスクは、定期的で本当にリスクが低いものであるべきである。毎晩のissueトリアージ、週のアクティビティを要約する定期タスクレポート、単一ディレクトリのlint&fix。最初のシンプルなループが数週間クリーンに動く前に、並行ワークツリー、サブエージェント、フルのヒルクライミングレイヤーに手を伸ばす衝動を我慢する。スタッキングされたバージョンは、ベースループの検証器が自分が思っている意味を持つことを確認した後にチームが構築するものであって、初日に構築するものではない。

6.2 トークン使用量の管理

• 適切なプリミティブとモデルを選ぶ。 小さいタスクに複数のエージェントやループは不要である。一部のタスクは安くて速いモデルで十分である。
• 明確な成功条件と停止条件を定義する。 「完了」がどういうものかを具体的にすることで、エージェントが解決策に速く、しかし早すぎず到達できる。
• 大規模実行前にパイロットする。 ダイナミックワークフローは数百のエージェントを起動できる。まず作業の小さなスライスで用量を測る。
• 決定論的な作業はスクリプトを使う。 スクリプトを実行するのは、毎回ステップを推論するより安価である。
• 必要以上に頻繁に定期タスクを実行しない。 監視しているものが実際に変わる頻度と間隔を合わせる。

7. まとめ

これらの背後にある本当の変化は、作業が楽になったことではない。レバレッジポイントが移動したことである。モデルが自分でコードを書けるようになった今、希少スキルは「非常に良い一文を構成する力」から、「誰も能動的に監視していない間も、正しい・検証され・正しい目標に向かい続けるサイクルを設計する力」に変わった。それはシステムエンジニアリングの習慣であり、一文を書くよりサーモスタットを設計する方に近く、まさにこれがこの作業に最も近い人々がそれをトリックではなくエンジニアリングと呼ぶ理由である。

2人が全く同じループを構築しても、全く反対の結果が得られる。一方は深く理解している作業を速く進めるために使う。もう一方は作業を理解することを避けるために使う。ループは違いを知らない。違いを知るのはあなたである。

ループを構築せよ。しかし、エンジニアであり続けるつもりで構築せよ。ただ「スタート」を押す者でなく。

📚 参考文献

• Loop Engineering (Addy Osmani).
• The Art of Loop Engineering (LangChain).
• Loop engineering: Getting started with loops (Anthropic).
• An Introduction to Loop Engineering (Machine Learning Mastery).