Loop Engineering実践ツールキット解説｜Cobus Greylingが示す7パターンとloop-audit

「もうエージェントにプロンプトを打つのをやめよう。エージェントにプロンプトを打つループそのものを設計するのだ」——AnthropicのClaude Code責任者Boris Cherny氏や、開発者Peter Steinberger氏が口を揃えて語るこの言葉が、2026年のAI開発における「レバレッジの移動」を象徴しています。一回のプロンプトを磨くのではなく、エージェントを時間をかけて動かし続ける制御システム（ループ）を設計することへ。これが「ループエンジニアリング」です。

当サイトでは以前、ループエンジニアリングとは｜AIエージェントの反復制御を設計する5つの軸と主要OSS実装 という記事で、この概念の全体像を整理しました。本記事はその実践編として、ループエンジニアリングを「概念」から「クローンして動かせる実装」へと落とし込んだ、Cobus Greyling氏のリポジトリ cobusgreyling/loop-engineering を徹底解説します。

このリポジトリは、単なる読み物ではありません。5つの構成要素、7つの本番パターン、loop-audit/loop-init/loop-costという3つのnpmツール、そしてGrok・Claude Code・Codex向けのスターターキットまでを備えた、実践のためのリファレンスです。AIエージェントを「動かしっぱなしにする」のが怖い、何から始めればいいか分からない——そんな開発者にとっての、確かな足場になります。

1. Loop Engineeringリポジトリとは何か

cobusgreyling/loop-engineering は、AI業界で著名なライター兼エンジニアの Cobus Greyling氏 が公開する、MITライセンスのオープンソースリポジトリです。Grok、Claude Code、Codex、CursorといったAIコーディングエージェントを使う開発者に向けて作られています。

このリポジトリが定義する「ループ」とは何でしょうか。READMEはこう説明します。

ループとは再帰的なゴールである。あなたは目的を定義し、AIが（しばしばサブエージェント・検証・外部状態を伴って）その目的が完了するまで、あるいはループが「あなたに引き継ぐ」と判断するまで、反復する。

ここが従来の「プロンプト」との決定的な違いです。プロンプトは一回きりの指示ですが、ループは目的を達成するまで自走し、必要なら人間にエスカレーションする自律的な仕組みです。Boris Cherny氏の「私はもうClaudeにプロンプトを打たない。Claudeにプロンプトを打って何をすべきか考えるループを動かしている。私の仕事はループを書くことだ」という言葉が、この発想を端的に表しています。

そしてこのリポジトリの真価は、その思想を「クローンして使える」形にまで具体化している点にあります。READMEの末尾には、こう記されています。

ループエンジニアリングのための、実践的でツールを意識したリファレンス——クローンできるパターン、出荷基準にできるチェックリスト、そして「何が壊れたか」を含むストーリー。

概念を語るだけのブログ記事とは一線を画す、動く道具箱。それがこのリポジトリの正体です。

Cobus Greyling氏は、対話AI・LLM・エージェント分野で長年発信を続けてきた著名なライターであり、その知見の蓄積がこのリポジトリの設計思想に色濃く反映されています。リポジトリには、関連プロジェクトとして「Goal Engineering（Grok Buildの /goal による『完了するまで走る』目標設定）」も併設されており、ループエンジニアリングが単発の思いつきではなく、一貫した方法論の体系の一部であることがうかがえます。GitHub Pagesでは対話的なショーケースとパターン選択ツールも公開されており、リポジトリを読むだけでなく、ブラウザ上で「自分にはどのループが合うか」を試せるようになっています。

2. 5つの構成要素 ＋ メモリ

ループを設計するには、その「部品」を理解する必要があります。リポジトリは、ループを構成する 5つの基本要素（Building Blocks）＋メモリ を提示しています。これがループエンジニアリングの語彙の中核です。

それぞれの役割を整理します。

特に注目すべきは、最後の メモリ／状態（Memory / State） です。チャットの会話履歴は、セッションが切れれば消えてしまいます。しかしループは、何日も何週間も動き続ける前提のもの。そこで、会話の外側に STATE.md のような永続的な状態ファイルを置き、ループが読み書きすることで、「前回どこまでやったか」を引き継ぎます。これが、ループに連続性を与える「背骨」になります。会話というのは本質的に揮発的で、コンテキストウィンドウの上限に達すれば古い情報は失われます。状態を外部ファイルに切り出すことは、その揮発性に抗い、ループが長期にわたって一貫した目的を追い続けるための、必須の工夫なのです。

ワークツリーもまた、ループの安全性に直結する要素です。複数のサブエージェントが同じファイルを同時に書き換えれば、衝突して壊れます。Gitのワークツリー機能で各エージェントに隔離された作業領域を与えることで、並列実行しても互いを踏み荒らさない——この「安全な並列性」が、ループの処理速度と安定性を両立させます。そしてスキルは、プロジェクト固有の知識（コーディング規約、ディレクトリ構造、ドメイン知識）をエージェントに持ち回らせる仕組みであり、毎回ゼロから説明する手間を省きます。

そして サブエージェントの Maker/Checker 分業 も、ループの信頼性を支える要です。実装を行うサブエージェント（Implementer）と、テストやゲートで検証するサブエージェント（Verifier）を分けることで、「作った本人がチェックする」ことの甘さを排除します。人間の開発でレビュアーを分けるのと同じ発想を、エージェントの世界に持ち込んでいるのです。

3. ループの解剖図 — 部品がどうつながるか

5つの構成要素は、実際にはどう連携して一つのループになるのでしょうか。リポジトリが示す「ループの解剖図（Anatomy of a Loop）」を、当サイト向けに再構成して示します。

この図が示すのは、ループの「一周」です。スケジュールが起動し、トリアージスキルが「いま何をすべきか」を判断し、状態を読み込み、隔離されたワークツリーで実装サブエージェントが作業し、検証サブエージェントがテストとゲートでチェックし、その結果をGitやチケットに反映する。そして最後に 「人間ゲート（Human Gate）」 が立ちはだかります。

この人間ゲートこそ、ループエンジニアリングの安全性の肝です。安全で許可済みの操作なら、ループはそのままコミットやPR作成へ進む。しかし危険または曖昧な操作なら、全文脈を添えて人間にエスカレーションする。この分岐があるからこそ、ループを「動かしっぱなし」にしても暴走しにくいのです。そして処理が終わると、また次のスケジュールへとループは回り続けます。

注目したいのは、エスカレーションが「全文脈つき（with full context）」で行われる点です。単に「判断できません」と人間に丸投げするのではなく、何をしようとして、なぜ止まったのか、どんな選択肢があるのかを添えて戻す。これにより、人間は瞬時に状況を把握して判断を下せます。エスカレーションの質が低いと、人間は毎回ゼロから状況を調べ直す羽目になり、自動化の意味が薄れてしまいます。「人間に戻すときこそ丁寧に」という設計思想が、この一本の矢印に込められているのです。

4. 7つの本番パターン — どのループから始めるか

「ループを設計せよと言われても、最初に何を作ればいいのか」——この問いに、リポジトリは 7つの本番パターン（Patterns） で答えます。それぞれが、実際の開発現場でよくある自動化タスクに対応しており、スターターキットとしてクローンしてすぐ動かせる形で提供されています。

この表で秀逸なのは、トークンコストと周期を明示している点です。たとえば「CI Sweeper」は5〜15分ごとに走り、トークンコストは「非常に高い」。一方「Daily Triage」は1日周期でコストは「低い」。この情報があることで、財布と相談しながら導入順を決められます。周期が短いループほど反応は速くなりますが、その分だけ起動回数が増え、トークン消費も膨らみます。「速さ」と「コスト」はトレードオフであり、どのタスクにどれだけのリアルタイム性が必要かを見極めることが、ループ設計の腕の見せ所です。たとえばCIの失敗はすぐ直したいので短周期が望ましい一方、変更履歴のドラフト生成は1日1回で十分、というように、タスクの性質に応じて周期を設計します。

リポジトリは、まず「Daily Triage」のようなコストの低い、レポートのみのパターンから始めることを推奨しています。「どれを選べばいいか分からない」人のために、対話的なパターン選択ツール（Pattern Picker）まで用意されている親切設計です。いきなり全自動の高コストループに飛び込むのではなく、低リスクなものから足場を固めていく——これが、ループエンジニアリングを安全に始める王道です。

それぞれのパターンには、専用のスターターキット（starters/ ディレクトリ）が紐づいており、機械可読なインデックス（patterns/registry.yaml）も提供されています。たとえば「PR Babysitter」を選べば、PRのCIや差分を見守るループの雛形がそのまま手に入り、自分のリポジトリに合わせて微調整するだけで動き始めます。さらに各パターンには「Week 1」の推奨運用レベル（多くがL1のレポートのみ、もしくは慎重なL2）が示されており、導入初週に何をどこまでやるべきかまで具体的にガイドされています。「自動化したいタスクはあるが、設計を一から考えるのは大変」という開発者にとって、これらのスターターは時間を大きく節約してくれます。パターンは単なるサンプルではなく、本番で揉まれた知見の結晶なのです。

5. 3つのnpmツール — audit・init・cost

このリポジトリが「動く道具箱」たるゆえんが、3つのnpmツールです。いずれも npx で即座に実行でき、クローン不要で使えます。

第一に、loop-init。スターターキットの雛形を生成するスキャフォールドツールです。「どのパターンを、どのツール（Grok/Claude Code/Codex）で使うか」を指定すると、予算管理と実行ログ（run-log）まで含んだ初期構成を作ってくれます。

npx @cobusgreyling/loop-init . --pattern daily-triage --tool grok

第二に、loop-cost。ループのトークン消費を見積もるツールです。周期とレベル（後述のL1/L2/L3）を指定すると、そのループがどれだけのトークンを消費しそうかを事前に試算できます。「動かしてみたら課金が爆発した」という事故を防ぐための、転ばぬ先の杖です。

npx @cobusgreyling/loop-cost --pattern daily-triage --level L1

第三に、そして最も特徴的なのが loop-audit。これは、あなたのプロジェクトが「ループを動かす準備ができているか」を採点する Loop Readiness Score（ループ準備度スコア） のCLIです。状態ファイルや予算設定、実行ログの有無などをチェックし、改善提案（--suggest）まで出してくれます。READMEに貼れる「Loop Ready バッジ」も生成できます。このツールが面白いのは、「準備度」という曖昧になりがちな概念を数値スコアとして可視化する点です。空の状態から始めて、状態ファイルを整え、予算を設定し、実行ログを残していくと、スコアが「empty → L1 → L2」と段階的に上がっていきます。リポジトリには before-after-demo.sh というデモスクリプトまで用意されており、スコアが実際に climb（上昇）していく様子を体験できます。改善が数字で見えることは、チームでの取り組みを継続させる強力な動機づけになります。

npx @cobusgreyling/loop-audit . --suggest
npx @cobusgreyling/loop-audit . --badge

6. L1→L2→L3の段階導入と、運用・安全の現実

ループエンジニアリングの実践で最も重要なのは、「いきなり全自動にしない」ことです。このリポジトリは、段階的なロールアウト（Phased rollout） を明確に定義しています。

・L1（レポートのみ）：ループは状況を観測し、レポートを書くだけ。自動修正はしない。まずここから始める
・L2（補助つき修正）：人間の確認を前提に、ループが修正案を実行する。許可リストに沿った安全な操作のみ
・L3（無人運用）：ループが人間の介在なしに動く。最も強力だが、最もリスクも高い

「最初の1週間はL1のレポートのみで、自動修正は一切しない」——READMEのGetting Startedにあるこの一文が、ループエンジニアリングの慎重な思想を象徴しています。エージェントを信頼するのは、その挙動を観察し、安全性を確認してからでも遅くありません。この「信頼は段階的に積み上げる」という発想は、人間の新人教育とよく似ています。いきなり重要な意思決定を任せるのではなく、まず観察させ、次に補助つきで実行させ、実績を確認してから独り立ちさせる。エージェントに対しても同じ段取りを踏むことで、取り返しのつかない失敗を避けながら、自動化の範囲を着実に広げていけます。

リポジトリは、運用と安全に関するドキュメントも充実させています。失敗モードのカタログ（Failure Modes）、本番投入前に避けるべきアンチパターン（Anti-Patterns）、ループ同士が衝突したときのマルチループ協調、そしていつループを止めるべきかを論じた運用ガイドまで。これらは、ループを「動かす」ことよりも「安全に運用し続ける」ことの難しさに、正面から向き合っています。

そして、READMEは率直な 注意点（Caveats） も隠しません。

・トークンコストの爆発：サブエージェントと長時間ループでコストが膨らむ
・検証は結局あなたの仕事：無人ループは無人のミスを犯す
・理解の負債（Comprehension debt）：ループが出荷したものを読まないと、理解の負債が溜まる
・同じループを2人が回しても、正反対の結果になりうる。ループはそれに気づかない。気づくのはあなただ

Addy Osmani氏の言葉が、この姿勢を締めくくります。「ループを作れ。ただし、ボタンを押すだけの人ではなく、エンジニアであり続けるつもりの人として作れ」。ループエンジニアリングは判断力を増幅する——良い判断も、悪い判断も。だからこそ、人間がエンジニアであり続けることが前提なのです。特に「理解の負債（Comprehension debt）」という概念は重要です。ループが大量のコードを出荷しても、それを誰も読んで理解していなければ、いざ問題が起きたときに誰も直せなくなります。生産性が上がったように見えて、実は将来の保守不能という負債を積み上げているだけ——この罠を避けるには、ループが出荷したものに人間が目を通し続ける規律が欠かせません。自動化は楽をするためではなく、人間がより高い視座で判断を下すための手段である、という原則を見失ってはならないのです。

7. 既存の概念記事との関係と、誰に向くか

冒頭でも触れたとおり、当サイトにはループエンジニアリングの概念を整理した記事が既にあります。両者の関係を整理しておきましょう。概念記事が「停止条件・再計画・予算ゲート・自己修正・エスカレーションという5つの設計軸」という抽象的なフレームを提示するのに対し、本記事が扱う cobusgreyling/loop-engineering は、その抽象を 「クローンして動かせる7パターン＋3ツール」 という具体に落とし込んだ実装集です。概念で全体像をつかみ、このリポジトリで手を動かす——という順序が理想的です。

このリポジトリが特に向くのは、次のような人々です。

・AIコーディングエージェントを既に使っている開発者：Grok・Claude Code・Codexのスターターが揃い、すぐ試せる
・自動化を始めたいが暴走が怖い人：L1から始める段階導入と人間ゲートが、安全な第一歩を保証する
・チームでエージェント運用を標準化したい人：loop-auditのスコアとチェックリストが、共通の出荷基準になる
・コスト管理を重視する人：loop-costによる事前見積もりで、課金事故を避けられる

逆に、まだAIエージェントを使ったことがない完全な初心者には、やや前提知識が必要かもしれません。その場合は、まず概念記事や、Claude Code・Grokといったエージェントツール自体に触れてから戻ってくると、このリポジトリの価値がくっきり見えてきます。エージェントを一度でも自分で動かした経験があれば、「これを定期実行して、検証も自動化できたら」という想像が湧くはずで、そこがちょうどこのリポジトリの出番です。

まとめ

本記事では、AIエージェントを動かすループを設計するための実践ツールキット、Cobus Greyling氏の cobusgreyling/loop-engineering リポジトリを解説しました。

その本質は、「プロンプトを打つ自分」を「プロンプトを打つシステム（ループ）」に置き換えるという発想を、動く道具にまで具体化した点にあります。5つの構成要素＋メモリでループの語彙を与え、7つの本番パターンで「最初に作るループ」を示し、loop-audit/init/costの3ツールで準備度の採点・雛形生成・コスト見積もりを支援し、L1→L2→L3の段階導入と人間ゲートで安全性を担保する——理論と実装、そして率直な失敗談までが一つに揃っています。

「ループを作れ。ただしエンジニアであり続けるつもりの人として」というAddy Osmani氏の言葉どおり、ループエンジニアリングは人間の判断を消すものではなく、増幅するものです。まずはL1のレポートのみのループから、安全に第一歩を踏み出してみてください。npx @cobusgreyling/loop-audit . --suggest を一度走らせて、自分のプロジェクトの準備度を測るところから始めるのが、最も手軽な入口です。

よくある質問（FAQ）

Q1. ループエンジニアリングと、普通のプロンプトエンジニアリングは何が違いますか? プロンプトエンジニアリングが「一回の指示を磨く」技術なのに対し、ループエンジニアリングは「目的を達成するまでエージェントを自走させる制御システムを設計する」技術です。レバレッジの中心が、個別のプロンプトから、時間をかけてエージェントを動かす仕組みへと移っています。

Q2. このリポジトリはどのAIツールで使えますか? Grok、Claude Code、Codex、Cursorなどのコーディングエージェントを想定しています。loop-initでは、パターンとツール（Grok/Claude Code/Codex）を指定してスターターを生成できます。

Q3. loop-auditは何を採点するのですか? プロジェクトが「ループを動かす準備ができているか」を表すLoop Readiness Score（ループ準備度スコア）を算出します。状態ファイル・予算設定・実行ログの有無などをチェックし、--suggestで改善提案、--badgeでREADME用バッジを生成します。npxで即実行でき、クローンは不要です。

Q4. いきなり全自動でエージェントを動かしても大丈夫ですか? 推奨されません。リポジトリはL1（レポートのみ）→L2（補助つき修正）→L3（無人運用）という段階導入を明確に定義しており、「最初の1週間はL1で自動修正なし」を勧めています。人間ゲートで危険な操作をエスカレーションする設計も、暴走を防ぐ要です。

Q5. トークンコストが心配です。対策はありますか? あります。loop-costで周期とレベルを指定して事前にトークン消費を見積もれます。また7パターンの表にトークンコスト（低〜非常に高い）が明記されているため、コストの低いパターン（Daily Triageなど）から始めることでリスクを抑えられます。

Q6. 当サイトの既存の「ループエンジニアリング」記事との違いは? 既存記事は概念の全体像（停止条件・再計画・予算ゲートなどの設計軸）を扱う「概念編」です。本記事は、その概念をクローンして動かせる形にした具体的なリポジトリを扱う「実践編」です。概念で理解し、本記事のツールキットで手を動かす、という順序がおすすめです。

参照ソース

・Loop Engineering（Cobus Greyling 公式リポジトリ） — 本記事が解説した一次情報。7パターン・3ツール・段階導入のすべて
・Loop Engineering essay（Cobus Greyling / Substack） — 概念・基本要素・Grokマッピングを論じた本人のエッセイ
・Loop Engineering（Addy Osmani） — リポジトリが「正典」と位置づけるAddy Osmani氏の論考