ループエンジニアリング入門：賢い一発より、回し続ける仕組みが勝つ

「もっと賢いプロンプトを書けば一発で終わる」──そう思っているうちは、AIエージェントは安定しない。実務で効くのは逆だ。一回の天才的な出力に賭けるのをやめて、観測→気づき→実行→検証→学習を“回し続ける”構造を設計する。これがループエンジニアリングだ。この記事では、その仕組み・方法・適用事例を出典付きで整理する。

そもそもエージェントとは「ループの中のモデル」

Anthropic は “Building Effective AI Agents” で、エージェントをこう定義している。「エージェントとは、LLMが自分のプロセスとツールの使い方を動的に方向づけ、タスクの達成方法を自ら制御するシステムである」。そして実装は驚くほど単純で、典型的には「環境からのフィードバックに基づいてツールを使うLLM」をループで回しているだけだと書く。さらに「各ステップで環境から“ground truth”（ツール呼び出しの結果やコード実行の結果）を得て進捗を評価することが重要だ」と続く（出典: anthropic.com/research/building-effective-agents）。

つまりエージェントの本体はモデルの賢さではなくループそのものだ。だからエンジニアリングの対象も「プロンプト1発」ではなく「ループの回り方」になる。これがループエンジニアリングという言葉の出発点だ。

仕組み：記憶はコンテキストでなくファイルに置く

ループの肝は「健忘症のエージェント」を前提にすることだ。Geoffrey Huntley が2025年半ばに公開した “Ralph Wiggum as a software engineer”（出典: ghuntley.com/ralph）は、その最小実装をこう示す。

while :; do cat PROMPT.md | claude-code ; done

たった1行。同じプロンプトを、タスクが「done」になるまでAIに食わせ続ける。ポイントは進捗をLLMのコンテキストウィンドウでなく、ファイルとgit履歴に溜めること。毎回新しいコンテキストで起動するから、過去の会話を覚えていなくても、ディスク上のファイルを読めば続きから走れる。エージェントは健忘症でも、ファイルシステムは忘れない──これが設計の核心だ。

実際、Huntley の記事では各ループの終わりに fix_plan.md を更新し、変更コードと一緒に git add -A → git commit する流れが示されている（出典: ghuntley.com/ralph）。状態は会話履歴でなくディスクに残る。賢いモデルで一発を狙うのではなく、忘れる前提で何度も回す。記憶を外部化したから、回数を増やしても破綻しない──ここが普通のプロンプト芸との決定的な差だ。

方法：二段ループにして「外さない4点」を仕込む

実務でループを組むときは、二重に入れ子にするのが基本になる。

• 外側ループ（発見役 / Discovery）：観測源（議事録・Slack・ニュース・git log）を定時スキャンして「やるべきこと」を抽出し、backlog.json のようなタスクリストに積む。
• 内側ループ（実行役 / Ralph）：タスクを1件だけ取り、計画→実装→検証→commit してプロセスを終了。次回はまた新しいコンテキストで起動する。Huntley の Ralph は内側ループの最小形そのものだ（出典: ghuntley.com/ralph）。

その上で、ループを回すときに外せない4点を挙げる（これは出典ではなく実運用のルールだが、各点の根拠になる一次事実は併記する）。

1. done条件を先に外部ファイルへ書く。Ralph の最小ループは、同じプロンプトをタスクが done になるまで反復する構造そのものだ（出典: ghuntley.com/ralph）。その「done になるまで回す」性質を活かすために、実装に入る前に「何をもって done とするか」を外部ファイルへ書いておく運用にする（ここは出典ではなく運用ルール）。途中で done を勝手に再定義させない。
2. 生成と検証を分ける。モデルは自分の成果を甘く採点しがちだ。だから別モデル／別プロセスの“検証ゲート”を通し、基準（具体例・数字・出典・結論）を満たさなければcommitさせない。
3. 記憶をファイルに書き戻す。タスク完了後に学びをルールファイルや docs/solutions/ に追記し、次回の計画がそれを読む。Huntley の記事で fix_plan.md を毎ループ更新して commit するのと同じ発想を、コードでなく「学び」にも広げる（出典: ghuntley.com/ralph）。
4. 予算とサーキットブレーカーを置く。無制限に回すとトークンを焼くので、予算上限とアラートで暴走を止める。これは運用上の安全弁で、特定の金額を主張するものではない。

適用事例

事例1：グリーンフィールドのコード生成（Ralph）。Huntley は記事の中で、自身の例として 「$50,000 規模の契約に相当する MVP を、テスト＆レビュー込みで $297（米ドル）で仕上げた」 と書いている（ampcode と組んだケース。著者本人の申告。出典: ghuntley.com/ralph）。第三者監査の数字ではないが、ループでコスト構造が桁違いに変わりうることを示す一例だ。仕組みは PLANNING プロンプト（gap分析→優先度付きTODO、実装はしない）と BUILDING プロンプト（計画前提で実装・テスト・commit）を分離するのが要になる。

事例2：コンテンツ生成。コードだけでなく文章にも同じループが効く。生成役が下書きを書き、別モデルの検証ゲートに「具体例・数字・出典・結論があるか」を反証させ、却下が出たら直して再検証する──という運用が典型だ。生成役と検証役を分けるループが、品質の安全弁になる。

事例3：業務全体の自律運用（二段ループ）。同じループを組織レベルへ広げた例が、自律エージェント基盤による日々の業務運用だ。外側ループが議事録やSlackから気づきを拾ってタスクリストに積み、内側ループが1タスク=1コミットでドラフトを作り、検証ゲートを通してからcommitする。done条件はタスクごとに固定し、学びは学びのファイルに書き戻す──上の4点をそのまま実装した形になる。なお Every の Kieran Klaassen が「compound engineering」と呼ぶ似た運用も公開されているが、その詳細は一次未確認の二次情報として扱う。

結論

ループエンジニアリングとは、賢い一発に賭けるのをやめ、「忘れる前提のエージェント＋外部ファイルの記憶＋done条件＋生成と分離した検証＋予算上限」を一つのループとして設計し、回し続けて成果を積み上げる技術である。

---

出典

• Anthropic, “Building Effective AI Agents” — https://www.anthropic.com/research/building-effective-agents （エージェント＝LLMがツールの使い方を動的に方向づけるシステム／実装は環境フィードバックでツールを使うLLMをループで回すだけ／各ステップで環境からground truthを得る）
• Geoffrey Huntley, “Ralph Wiggum as a software engineer” — https://ghuntley.com/ralph/ （最小ループ while :; do cat PROMPT.md | claude-code ; done、進捗はファイル+git commitに蓄積、done条件まで同一プロンプトを反復、$50k相当MVPをテスト・レビュー込み$297で納品の実績）
• 二次情報（一次URL未確認）: Kieran Klaassen “compound engineering”／「エージェントは健忘症だがファイルシステムは違う」という実践者の比喩。本文では二次情報である旨を明示し、断定的な事実としては用いていない。