loop-engineering: AIコーディングエージェントを「毎回のプロンプト」から「ループ設計」へ移すパターン集
Practical patterns, starters & CLI tools for loop engineering with AI coding agents. Design systems that prompt and orchestrate agents (inspired by Addy Osmani and Boris Cherny). Includes loop-audit, loop-init, loop-cost.
ひと目でわかる
- これは何？
- loop-engineering は、リポジトリの保守作業をエージェントに回し続けるためのパターン集とCLIをまとめたTypeScript製のリポジトリである。中核は daily-triage などのパターン、STATE.md に代表される永続状態、そして Loop Ready スコアという3点セットで、README 自身が「これはモジュールを書き換えるボタンではない」と断っている点が率直でよい。
- 誰に向いている？
- 採用を検討すべきなのは、issue・CI・依存更新といった定常作業が既に多く、エージェントに任せる範囲を段階的に広げたいチームである。逆に、単発の機能実装を一撃で終わらせたいだけの使い方には向かない。
- 商用利用できる？
- できます。MIT は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。最後のコミットは 1 日前です。
- 何の言語で書かれている？
- 主に TypeScript です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
loop-engineering が埋めようとしている穴は「プロンプトを打ち続ける運用」そのもの
AIコーディングエージェントの使い方は、たいてい人間が次の指示を考えるところから始まる。issue を読ませ、修正方針を書き、テストを走らせ、結果を見てまた指示を出す。この方式は一回の作業では機能するが、リポジトリの保守のように毎日繰り返す作業では、人間がボトルネックとして残り続ける。loop-engineering が対象にしているのはこの部分で、README は「You design a system that discovers work, hands it to agents, verifies results, and persists state」と表現している。つまり、仕事の発見、エージェントへの受け渡し、結果の検証、状態の永続化という4段を人間が毎回やるのではなく、仕組みとして設計する。対象読者は、リポジトリを継続的に保守する立場の開発者やプラットフォーム担当であり、単発のコーディングを速くしたい人ではない。README の jobs 表でも「Ship a feature or refactor」は別の refactor.md に切り出されており、日常保守と機能実装が明確に分けられている。
パターン表が示す cadence とコストの対応関係
このリポジトリの中心は patterns/ 以下のパターン文書である。README の表には8つが並び、それぞれ cadence、week 1 の到達レベル、コストの3列で整理されている。Daily Triage は cadence が 1d から 2h、week 1 は L1 report、コストは Low。Thin loop は event と 1d で L1 snapshot、コストは Very low。PR Babysitter は 5 から 15 分で L1 watch、コストは High。CI Sweeper は同じく 5 から 15 分で L2 cautious、コストは Very high。Dependency Sweeper は 6h から 1d で L2 patch-only、Medium。Changelog Drafter は 1d または tag で L1 draft、Low。Post-Merge Cleanup は 1d から 6h で L1 off-peak、Low。Issue Triage は 2h から 1d で L1 propose-only、Low。読み取れる設計思想は単純で、実行間隔が短いほどコストが上がる。5分間隔で回す PR Babysitter と CI Sweeper が High と Very high に分類されているのは、トークン消費が実行回数に比例するためだと README の「Token costs can explode」という記述から推測できる。パターンを選ぶときは、この cadence とコストの列を先に見るのが実用的である。
L1 から L3 への段階移行と Loop Ready スコアの意味
loop-engineering は自律性を3段階で扱う。L1 は report または propose のみ、L2 は assisted、L3 は unattended である。README は「Roll out L1 report → L2 assisted → L3 unattended only after the verifier has been right for a week」と述べており、段階を飛ばすことを明確に戒めている。この順序を強制しているのが Loop Ready スコアで、README には「Loop Ready now weights recent runs harder than files on disk. A 30-day-old STATE.md is not L3.」とある。ここがこのプロジェクトの設計上の要諦である。設定ファイルや STATE.md を置いただけでは高いスコアにならず、直近の実行履歴が重視される。裏を返せば、しばらくループを止めるとスコアは下がる。スコアは静的な成熟度の証明ではなく、直近の運用実績の指標として設計されている。検証役が正しく動いていた期間を測る仕掛けとして読むのが妥当である。
STATE.md と thin loop、永続状態をどこに置くか
状態の永続化は STATE.md というファイルで行う。README の空リポジトリからの導入手順として scripts/empty-to-state-demo.sh が案内されており、何もないリポジトリから最初の STATE.md を作る流れが用意されている。ただし STATE.md は必須ではない。starters/thin-loop/ は「no STATE.md required」と明記されており、GitHub Actions 上でほぼファイルを置かずにループを回す選択肢が示されている。ここは用途で分かれる。ローカルやエージェント側に状態を蓄積して文脈を引き継ぎたいなら STATE.md を持つ構成、CI 上のイベント駆動で完結させたいなら thin loop である。README は thin loop を「event + 1d」の cadence と L1 snapshot に位置づけており、コストは Very low とされている。状態をファイルに持たない分、引き継げる文脈は浅くなるというトレードオフがあると読める。どちらが優れているという話ではなく、エージェントに何を覚えさせたいかで選ぶ。
導入は init、doctor、cost の3コマンドから
README が示す開始手順は短い。まず `npx @cobusgreyling/loop init . --pattern daily-triage --tool claude` でパターンを初期化する。`--tool` は省略すると claude が既定で、grok、codex、opencode に差し替えられる。次に `npx @cobusgreyling/loop doctor .` で状態を診断する。3つ目が `npx @cobusgreyling/loop cost --pattern daily-triage --level L1` で、パターンとレベルを指定してコストを見積もる。CLI は `@cobusgreyling/loop` に統一され、サブコマンドは init、doctor、status、audit、cost の5つである。README によれば旧パッケージ（loop-init、loop-audit など）も引き続きサポートされる。ツール別の例は examples/ 以下に claude-code、grok、codex、opencode、github-actions として並び、Claude Code には plugin.md も用意されている。注意点として README は「Week one is report-only」と述べており、初週は書き込みを伴わない運用が前提になっている。
向かない場面と、失敗モードが文書化されていることの意味
このリポジトリは自分の限界を比較的はっきり書いている。README には「Loop engineering amplifies judgment. Token costs can explode. Unattended loops make unattended mistakes. Read what the loop ships.」とあり、判断力を増幅する道具であって判断力を代替するものではないと位置づけている。docs/failure-modes.md、docs/anti-patterns.md、docs/safety.md、docs/operating-loops.md が用意され、stories/ には「wins and failures」の両方が集められている。失敗を first-class に扱う姿勢は、エージェント運用の文書としては珍しくないが、少なくとも隠していない。向かないのは、単発の機能実装やリファクタを一気に終わらせたい場合である。README 自身が「It is not a 'rewrite the module' button」と断っている。また、5分間隔で回す CI Sweeper のようなパターンは Very high コストと明記されており、トークン予算が限られる環境では現実的でない。cadence を短くするほど検証の手間も増える。
代替となる考え方との違い: エージェント内蔵のループか、外部の設計か
比較対象として分かりやすいのは、Claude Code や Codex といったツール自体に備わる反復実行の仕組みである。これらはセッション内でエージェントが自分で試行錯誤するループを提供する。一方 loop-engineering が扱うのは、リポジトリの外側に置く運用のループである。仕事の発見、受け渡し、検証、状態の永続化を、エージェントのセッションをまたいで設計する。違いは状態の置き場所に出る。ツール内蔵のループはセッションが閉じれば文脈も消えるが、loop-engineering は STATE.md や GitHub Actions のイベントを介して、実行と実行の間をつなぐ。もう一つの違いは検証の位置づけである。README は L1 を report-only、L2 を assisted とし、検証役が一週間正しかったことを L3 の条件に置く。ツール内蔵のループにはこの段階的な自律性の枠組みが標準では存在しない。逆に、外部ループはファイルとワークフローの管理コストを伴う。どちらが優れているかではなく、セッションをまたぐ運用を設計したいかどうかで選ぶ。
ライセンスと保守コスト、そして最初に確かめること
ライセンスは MIT で、リポジトリの LICENSE ファイルに基づく。MIT は商用利用を含めて寛容な条件だが、具体的な法的判断は各自の状況によるため、ここでは条件の種類のみを述べる。保守コストの面で見ておくべきは、このリポジトリが CLI と文書の両方を抱えている点である。CLI は `@cobusgreyling/loop` に統合されつつ旧パッケージも維持されており、README には memory-engineering、harness-foundry、outerloop、fleet-engineering、goal-engineering という companion リポジトリの存在も記されている。ただし README は「Do not add them until a loop has actually run」と明記しており、最初から全部を入れる設計にはなっていない。リリースは v1.6.0 が 2026-07-20、v1.5.0 が 2026-06-30 で、v1.6.0 には Foundry funnel と loop-gate が含まれるとタグに記されている。導入前に確かめるべきは、`doctor` が自分のリポジトリで何を報告するか、そして選んだパターンの cadence とコスト列が自分のトークン予算に収まるかである。
編集部の結論
採用を検討すべきなのは、issue・CI・依存更新といった定常作業が既に多く、エージェントに任せる範囲を段階的に広げたいチームである。逆に、単発の機能実装を一撃で終わらせたいだけの使い方には向かない。README が明言するとおり、これは「モジュールを書き換えるボタン」ではなく、リポジトリの周囲でエージェントを動かし続けるための運転席だからだ。導入前に確認すべきは、`npx @cobusgreyling/loop doctor .` の出力が自分のリポジトリでどう出るか、そして `STATE.md` が実際に更新され続ける運用になるかどうかである。Loop Ready はディスク上のファイルより直近の実行を重く見る仕様なので、STATE.md を置いただけで L3 になるわけではない。まず daily-triage を L1 の report-only で回し、検証役が一週間正しく動いたことを確認してから L2 に上げる、という順序を崩さないことが現実的な判断基準になる。
コミュニティノート