猫でもわかるループエンジニアリング
最近、「ループエンジニアリング」という言葉をよく聞くようになりました。
気になったので、自分の個人プロジェクトでも始めてみました。
参考にしたのは以下のloop-engineeringリポジトリです。
ただ、いかんせんコレが何なのかイマイチわかりにくい。。。
初心者向けのわかりやすい記事もなさそうだ。。。そうだ、作ってしまおう。
この記事は、自分の「ループエンジニアリング」理解をまとめたものです。
誰かの役に立てれば幸いです。間違いなどありましたらご指摘ください。
プロンプトを打つのをやめた人たち
ループエンジニアリングを一言でいうと、「AIエージェントに毎回プロンプトを打つのをやめて、エージェントが勝手に動き続ける仕組みのほうを作る」という考え方です。
著名な開発者のPeter Steinberger氏が「エージェントにプロンプトを打つのではなく、打たせる側に回れ」と語り、Claude Codeを率いるBoris Cherny氏も、もうClaudeに直接プロンプトは打っていないと明かしています。
というわけで、ルンバの例えで説明します。
- ルンバ(＝AIエージェント)
- ネコ(＝人間)
です。
ルンバのある生活で仕事はどう変わったか
手で掃除機をかける生活から、ルンバのある生活に変わったときを思い出してください。
ルンバを導入しても、掃除という仕事は消えません。
ただ、床にモノを置かないよう部屋を整え、スケジュールを組み、ときどきブラシの髪の毛を取る。
人間の仕事が「掃除をする」から「掃除が回り続ける環境を整える」に変わります。
ループエンジニアリングは、これの開発版です。
ルンバにあたるエージェントはすでに十分賢いので、人間は環境を用意する側に回るということです。
従来の開発と何が変わるのか
従来のやり方では、人間がループの中にいました。
エラーログをAIに貼り、修正案を確認して適用し、また落ちたら次のプロンプトを打つ。
AIがどれだけ速くても、人間が次の指示を打つまですべてが止まります。
ループエンジニアリングでは、人間がループの外に出ます。
タスクの発見も実装も検証もエージェントが行い、人間は「危ない変更を止める門番」と「ループの設計者」に回ります。
| 従来の開発 | ループエンジニアリング | |
|---|---|---|
| 指示の単位 | タスクごとにプロンプトを書く | ループを一度設計する |
| 動く時間 | 人間が席にいる間だけ | 24時間、スケジュール駆動 |
| 状態の管理 | 会話の文脈が頼り | 状態ファイルに永続化 |
| 検証 | 人間が毎回目視 | 検証エージェントと人間ゲートの二段構え |
| 人間の役割 | 指示者 | 設計者と門番 |
ループの一周は以下のように流れます。
図の中の状態ファイルは、バイトの申し送りノートだと思ってください。
AIエージェントはセッションが終わると文脈をきれいさっぱり忘れるので、各エージェントがループの終わりに「どこまでやったか」を書き残し、次のエージェントが最初にそれを読みます。
状態ファイルのおかげで、作業がセッションを超えて何日でもつながります。
ループエンジニアリングはじめの一歩
第一歩は新しいツールの導入ではなく、自分のプロンプト履歴の観察です。
同じ形のプロンプトを2回打っていたら、それが自動化の候補です。
繰り返しのプロンプトは、4つの部品に分解すると仕組みに置き換えられます。
- 手順書：毎回同じ部分をファイルに明文化する(「CIが落ちたらログを読み、修正PRを作る。マージはしない」)
-
起動条件：打っていたタイミングを時刻やイベントに翻訳する(cronやGitHub Actionsで
claude -pを定期実行) - 記憶：毎回添えていた文脈は状態ファイルが肩代わりする
- 合格判定：「OK、次はこれ」の打ち返しを、テストと数値の終了条件に置き換える
暴走が不安なら、ガードレールの柵を立てます。
触れる場所とコマンドを許可リストで絞り、トークン予算を決め、取り返しのつかない操作の手前に人間ゲートを置く。
柵の外に物理的に触れなければ、張り付いて監視する必要はありません。
まずは現実的なL1から始める
loop-engineeringリポジトリでは、いきなり無人運転を目指すなと繰り返し警告されています。
推奨は三段階です。
- 報告だけさせるL1
- 修正案は作らせるが人間が承認するL2
- 限定した範囲を無人で回すL3
Boris Cherny氏のいうような完全無人のループ(L3)にはあこがれますが、トークン代は青天井ですし、日本の組織では「AIが無人でマージしてよいか」を通すだけで品質保証、セキュリティ、監査の壁が立ちはだかります。
幸い、L1の報告ループなら壊れるものもなく、誰の承認も要りません。
実際、私が最初に組んだのは、毎朝PRとissueの詰まりを一覧で報告するだけのループです。
朝イチに「今日はこの3件が詰まっています」と出てくるだけで、朝会前の30分が浮きます。
慣れた頃、CIが落ちたら修正PRを作るところまで任せました(マージは必ず人間)。
落ちたテストの大半は依存ライブラリの更新やflakyなテストが原因の単純作業で、AIの修正はだいたい妥当。
人のやりたくない仕事から順に、ループへ吸い込まれていきます。
リポジトリには、毎朝の状況整理、PRの子守り、CIの失敗対応など実運用パターンが7つ、実行頻度とトークンコストの目安つきで載っています。
最初の一本は、頻度もコストも低い報告系をやるのがよいです。
loop-engineeringリポジトリは道具箱
loop-engineeringリポジトリは、読み物というより道具箱です。
状態ファイルはSTATE.md、ループの定義と制約はLOOP.mdに書く流儀で、npxで動くCLIツールが6つ付属しています。
- loop-init：パターンを選ぶと、手順書、状態、予算のファイルを一式生成
- loop-audit：ループを回せる状態かをLoop Readyスコア(0から100)で採点
- loop-cost：回す前にトークン消費を見積もり
ほかに、定義と実態のずれを検出するloop-sync、予算超過でループを止めるサーキットブレーカーのloop-contextなどがあります。
無人で回すものには、無人で止まる仕組みを対にするのがよいでしょう。
前回の「ループ設計」の話との関係
実はこの話、以前書いたエンジニアのAgent Loopを整える技術 ─フィードバックループ is All You Need─の続きです。
前回はセッションの中のループ(達成条件を数値で決め、テストという「誤差を測るセンサー」を用意する)の話でした。
ループエンジニアリングは、それをセッションの外側に拡張したメタループです。
正直、ハーネスエンジニアリングの焼き増しでは？
ここまで紹介しておいてなんですが、ループエンジニアリングという言葉、ハーネスエンジニアリングの焼き増しでは？ という気がしています。
多くのエンジニアは名前を知る前から、CIで自動テストを回し、cronで定期ジョブを動かし、依存関係の更新はRenovateに任せてきました。
そこにAIエージェントが加わっただけで、革命的な技術が発明されたわけではありません。
プロンプト、コンテキスト、ハーネス、ループエンジニアリングと数ヶ月ごとに新しい横文字が生えてきますが、中心は一貫して「AIが自走できるように環境とフィードバックを設計する」ことです。
ハーネスエンジニアリングのときにも感じた、あのハリボテ感があります。
とはいえ、名前は旗になり、旗の下に道具とパターンと失敗談が集まります。
言葉は焼き増しでも集まった知見は本物なので、名前には振り回されず、中身だけ持ち帰るのがよいと思います。
トークン代はむちゃくちゃかかる。サブスク必須
ループエンジニアリングは、無茶苦茶お金がかかります。
CIの失敗対応のような高頻度ループはリポジトリの分類でもコスト「非常に高い」で、MAXのサブスクのlimitもすぐ使い切ります。
そして、無人のループは無人のまま間違え続けます。
検証の最終責任が人間にあることは、ループを組んでも変わりません。
一番怖いのは、Addy Osmani氏の言葉として引用されている 「理解の借金」 です。
ループが出荷したコードを読まずにいると、自分のプロダクトなのに「なんかわからないけど動いてるからいっか」という箇所が静かに増えていきます。
開発者の仕事はどこへ移るのか
工場に生産ラインが入ったとき、職人の仕事は消えず、ラインを設計し監視する仕事に変わりました。
いま開発者に起きているのも同じことです。
仕事はなくなるのではなく、一段上のレイヤーに移ります。
どのループを回すか、どこに門番を置くか、出てきたコードをどこまで読むか。
これを決める仕事は、プロンプトを打つより地味で、難しく、面白い仕事です。
つまり、ルンバの上のネコになれ！ということです。
試すなら、まずはコードに触らせない、日報を報告するだけのループをひとつ組んでみてください。
朝の30分が浮いたとき、ループエンジニアリングの意味が体でわかるかも（？）
Discussion
AI界隈値上げの波来てるしenterpriseプランとかは特にひどい
ccodexもclaudeもcopilotもみんな従量課金になっちゃった
ぶっちゃけループエンジニアリングはpro契約できるユーザか、金持ち企業の遊びでしかないので流行らないと思う