hdknr blog
戻る

ループエンジニアリング：プロンプターからループデザイナーへの14ステップ・ロードマップ

開発者の大多数は、コーディングエージェントを今でも手動でプロンプトしている。タイプして、待って、差分を読んで、また次のプロンプトを書く。「ループエンジニアリング」は、その繰り返し作業そのものをシステムに任せる考え方だ。

@0xCodez が公開した記事「Loop engineering: the 14-step roadmap from prompter to loop designer」は、Anthropicのエンジニアリングドキュメント、Addy Osmaniのループエンジニアリング論文、最近の計測研究を元に、プロンプターからループデザイナーへ移行するための14ステップをまとめたロードマップだ。

既存記事との棲み分け：ループエンジニアリングの概念そのものは プロンプトからループへ と 2026年AI必須スキル「ループエンジニアリング」とは で扱った。本記事が焦点を当てるのは、作るべきかどうかの判断基準（4条件テスト）、撤退ライン、そして失敗の回避である。Step 05〜10 の構成要素はロードマップの通し道として一巡するが、各部品を深く知りたい場合は 6コアモジュールの解説 を正典として参照してほしい。

ループエンジニアリングとは何か

ループエンジニアリングとは、自分自身をプロンプターから置き換えることだ。

従来の使い方では、エージェントはツールであり、あなたがずっとそれを握っていた。ループエンジニアリングでは、次の処理を自律的に行う小さなシステムを構築する：

Anthropicのエンジニアは現在、2024年比で1日あたり8倍のコードをマージしている——ただしこの数字自体、Anthropic自身が「真の生産性向上を誇張している可能性がほぼ間違いなく高い」と留保をつけている。数字の是非はさておき、主因が「より良いプロンプト」ではなく「プロンプトするシステムの設計」にあるという点は動かない。

PART 1: なぜループが必要か、そのテスト方法

Step 01: ループエンジニアリングはプロンプターの置き換え

従来のやり方では、人間が毎回プロンプトを書き、差分を確認し、次の指示を出す——つまり人間自身がループの制御装置になっている。ループエンジニアリングでは、システムがタスクを見つけ、エージェントを走らせ、検証し、状態を記録して次のアクションを決める。人間はその設計者に回る。

Addy Osmaniが定義する6つの要素（オートメーション・ワークツリー・スキル・コネクタ・サブエージェント・ステートファイル）がループを構成する。設計するのは一度だけで、あとはシステムがプロンプトを生成し続ける。

Step 02: 何かを作る前に「4条件テスト」を実行せよ

ループは4つの条件が揃ったときにコストに見合う。1つでも欠けていれば、ループはリターン以上のコストがかかる。

条件内容
タスクが繰り返されるループはセットアップコストを多くの実行に分散する。週次未満なら設定する意味がない
検証が自動化されているテストスイート、型チェッカー、リンター、ビルドが必要。自動ゲートがなければ、あなたは結局すべての差分を読むことになる
トークン予算が無駄を吸収できるループはリトライや探索でトークンを消費する。予算が十分でなければコスト面でリスクが大きい
エージェントにシニアエンジニアのツールがあるログ、再現環境、コードを実行して何が壊れるかを確認する能力が必要

Step 03: 誰が得をし、誰が損をするか

ループから本当に恩恵を受けるのは：

今すぐスキップすべき人：

Step 04: 30秒ループチェック

具体的なタスクをループにする前のチェックリスト：

  1. タスクは少なくとも週次で発生する
  2. テスト、型チェック、ビルド、またはリンターが不正な出力を拒否できる
  3. エージェントが変更したコードを実行できる
  4. ループにはハードストップがある（トークン予算、イテレーション回数、時間制限）
  5. マージ・デプロイ・依存関係変更の前に人間のレビューが入る

良いファーストループ:

悪いファーストループ（人間が必要）:

PART 2: 5つの構成要素

Step 05: オートメーション — ループの心臓部

オートメーションはループを「一度だけ実行するスクリプト」ではなく「実際のループ」にする要素だ。スケジュール、イベント、またはトリガー条件で発火する。

2つの主要ツールでの実装：

2つの重要なプリミティブ：

Step 06: ワークツリー — 並列でも混乱しない

複数エージェントを同時実行した瞬間、ファイルが衝突し始める。git worktree はこれを解決する。同じリポジトリ履歴を共有しながら、独立したブランチで作業する別々のディレクトリを提供する。

ワークツリーは機械的な衝突を取り除くが、レビュー帯域幅があなたの上限になる。並列エージェントの数はツールではなく、あなたがレビューできる量で決まる。

Step 07: スキル — プロジェクト知識を一度書いて毎回参照

スキルは、同じプロジェクトのコンテキストをセッションごとに最初から説明するのを止める仕組みだ。両ツールとも同じ形式：SKILL.md を含むフォルダ（手順、メタデータ、オプションのスクリプト・参照・アセット）。

ループにとって特に重要な理由：スキルがないループはサイクルごとにプロジェクトのコンテキスト全体をゼロから再導出する。スキルがあればインテントが積み上がる。慣習、ビルド手順、「あの事件のせいでこのやり方はしない」という知識が一度書かれ、すべての実行で参照される。

Step 08: コネクタ — ループがリアルなツールに触れる（MCP経由）

ファイルシステムしか見えないループは小さなループだ。Model Context Protocol（MCP）上に構築されたコネクタによって、エージェントはIssueトラッカーを読み、データベースに問い合わせ、ステージングAPIを叩き、Slackにメッセージを送れる。

最も早く見返りのあるコネクタ（優先順）：

  1. GitHub — リポジトリ読み取り、ブランチ作成、PRオープン、Issueコメント、Webhookイベントへの反応。コードループの初日最大のメリット
  2. Linear / Jira — ループの進行に合わせてチケット更新、PRとIssueの紐付け、検証が通ったらアイテムを自動クローズ
  3. Slack — トリアージ結果の投稿、エスカレーションでの人間への通知、夜間実行の朝のサマリ
  4. Sentry / エラートラッカー — ライブアラートを調査し、頻度の高いものの修正下書きを作成

Step 09: サブエージェント — 作成者と検証者を分離する

ループで最も有用な構造的な工夫は、書くエージェントとチェックするエージェントを分離することだ。

Addy Osmaniの言葉が正確だ：「コードを書いたモデルは自分の宿題を採点するとき非常に優しくなりすぎる」。異なる指示（場合によっては異なるモデル）を持つ2番目のエージェントが、最初のエージェントが自分に言い聞かせて通過させたものをキャッチする。

これはAnthropicの2024年12月エンジニアリング記事の「evaluator-optimizerパターン」だ。1つのモデルが生成し、別のモデルが批評し、繰り返す。2026年にバズっている語彙が18ヶ月前にドキュメント化されていた。

典型的な分割：

PART 3: 正しく構築するか、構築しないか

Step 10: ステートファイル — エージェントは忘れる、ファイルは忘れない

シンプルすぎて重要に思えないが、実際にはすべての動作するループの背骨だ。会話の外に存在し、何が完了して何が次かを保持するもの（マークダウンファイル、Linearボード、JSONステートなど）。

2つのパターン：

長期実行ループでゴールがずれるリスクには、ステートファイルと高レベルスペック（VISION.md または AGENTS.md）を組み合わせる。ステートはエージェントに「今どこにいるか」を教え、スペックは「どこへ向かうか」を教える。

Step 11: 最小実行可能ループ

4条件テストを通過したなら、派手なものの前に動く最小のループを構築せよ。4つの部品、スワームは不要。

部品内容
1つのオートメーションケイデンスで発火し、明確な条件で停止するスケジュール実行
1つのスキルエージェントがゼロから再導出するプロジェクトコンテキストを保存するSKILL.md
1つのステートファイル何が完了して何が次かを記録するMarkdownファイルまたはLinearボード
1つのゲート不正な作業を自動的に失敗させるテスト、型チェック、またはビルド

順序が重要： まず1つの手動実行を信頼できるものにする → スキルにする → ループに包む → スケジュールする。先に進みすぎると誰も理解しないシステムへの支払いが発生する。

重要な指標： cost per accepted change（受け入れられた変更あたりのコスト）。消費トークンでも、試みたタスク数でもない。受け入れ率が50%を下回っているなら、ループが節約するはずだったレビュー作業をあなたがやっていることになる。

Step 12: ラルフ・ウィグムループ — 静かに失敗するループ

エンジニアのGeoffrey Huntleyが記録したこの失敗パターンは命名された。完了トークンを完了時にだけ出力するはずのエージェントが早期に出力し、ループが半分しか終わっていない仕事で終了する。ハードゲートがなければ、ループは静かに失敗しながら支出し続ける。

ラルフ・ウィグムループが起きる条件：

修正方法： Step 11のゲート — 客観的に仕事を失敗させられる何か。通過するか失敗するかのテスト、コンパイルするかしないかのビルド、ゼロか非ゼロを返すリンター。

その他の計測された失敗パターン：

Step 13: 理解負債と認知的降伏

ループが良くなるほど鋭くなる失敗パターン。Osmaniのエッセイからの2つの命名されたリスク：

理解負債: ループが書いていないコードをより速くシップするほど、リポジトリの内容と自分の理解の距離が広がる。「痛い請求書」はトークン代ではない。誰もコードを読んでいないシステムをデバッグしなければならない日だ。

認知的降伏: 意見を形成するのをやめて、ループが返すものを何でも受け入れる引力。ループの設計は判断を持ってやれば解決策であり、考えることを避けるためにやれば加速装置だ。同じ行動で逆の結果。

軽減策（技術的でない）：

Step 14: セキュリティ税 — 無人ループは無人の攻撃面

無人で動くループは、無人で動く攻撃面でもある。

ループが防御すべき脅威モデル：

金銭的損失になるループの失敗パターン

記事がまとめた「やってはいけないこと」リスト：

  1. 4条件テストなしでループを構築する
  2. 客観的なゲートなし（「レビュー」するよう依頼された2番目のエージェントはただの楽観主義者）
  3. 1つのエージェントが書き込みと検証の両方を担当（自己優先バイアス）
  4. ステートファイルなし（翌日の実行がゼロからリスタート）
  5. 曖昧なストップ条件（「良く見えたら完了」は機能しない）
  6. トークン予算上限なし（野心的なループは予想の5〜10倍のトークンを消費する）
  7. 重い検証ループをコンシューマープランで実行する
  8. コミュニティスキルの自動インストール（17,022のスキルのうち520がクレデンシャルを漏洩）
  9. 判断が必要な作業にループを実行する（アーキテクチャ、認証、決済）
  10. 差分を読まない（複利で積み上がる理解負債）

まとめ：レバレッジが移動した。あなたの仕事も変わった

2年間、エージェントとの作業のレバレッジはプロンプトにあった。より良いプロンプト、より良いコンテキスト、より良いワンショット出力。

その段階は終わりつつある。エージェントが十分に優秀になったことで、次のレバレッジポイントは1フロア上にある：エージェントに何を作業させるか、いつ、どんなゲートで、どの状態が実行間で生き残るかを決めるシステムだ。

しかし、この話の正直なバージョンは「みんながすぐにループを構築すべき」ではない。タスクが繰り返されるまで、検証が自動化されるまで、予算が無駄を吸収できるまで、エージェントにシニアエンジニアのツールが揃うまで、ほとんどの開発者はまだループを必要としない。

1つでも条件を欠かせばループはリターン以上のコストがかかる。

テストを通過したなら、小さく構築せよ。1つのオートメーション、1つのスキル、1つのステートファイル、1つのゲート。手動実行を信頼できるものにして、スキルにして、ループに包み、スケジュールする。順序が重要だ。

ループを構築せよ。エンジニアであり続けよ。

この記事は @0xCodez による「Loop engineering: the 14-step roadmap from prompter to loop designer」をベースに、@jrpj2010 のツイートから着想を得て執筆しました。

前の記事
プロンプトからループへ——Claude Codeトップエンジニアが語る「ループエンジニアリング」とは何か
次の記事
llama-launcher：ベイズ最適化でllama.cppの起動パラメータを自動調整するGUIツール