Loop Engineering（ループエンジニアリング）入門¶

作成日: 2026-06-25 出典 / きっかけ: GitHub cobusgreyling/loop-engineering、Cobus Greyling の Medium/Substack 解説記事関連: agentic_reference_architecture_評価ループ ai_agent_9社_本番運用アーキテクチャ llm_agent_sandbox_隔離技術

0. 要点（3行）¶

一言で言うと: 「AIに毎回プロンプトを打つ人」を、あなた自身から仕組み（ループ）に置き換えること。あなたの仕事は「打つ人」ではなく「打つ仕組みを設計する人」になる。
何が効くか: レバレッジの効く場所が 1回のプロンプト → 時間をまたいでエージェントを回し続ける制御システム に移る。チャットを開いて待つ必要がなくなる。
実用上の勘所: ループは「プロンプト」ではなく「メモリ・検証・境界（ガードレール）を持った繰り返しプロセス」。だから止め方と人間ゲートの設計が9割。コスト爆発と「理解の負債」が最大のリスク。

あなたは既にこれをやっている。 ~/temporal-workflows（Temporal で Claude API を定期実行）、~/research-orchestrator（cron で3リポジトリ横断リサーチ）、~/ai-engineering-digest（GitHub Actions が毎朝07:00にダイジェスト生成）はすべて「ループエンジニアリング」の実例。この資料は、自分が手探りでやってきたことに名前と語彙と型を与えるもの、と思って読むと早い。

1. そもそも何の話か — 直感から入る¶

1-1. 「プロンプトを打つ人」をやめる、という発想の転換¶

提唱の核になっている一文がこれ。

"Loop engineering is replacing yourself as the person who prompts the agent. You design the system that does it instead." （ループエンジニアリングとは、エージェントにプロンプトを打つ「あなた」を置き換えること。代わりにそれをやる仕組みをあなたが設計する）

つまり、主役の交代である。

【従来】 あなた → プロンプト → エージェント → 出力を読む → 次のプロンプト → …
          ↑ あなたがループの中で手を動かし続けている

【ループエンジニアリング】
          あなた → 「ループ」を設計する
                      ↓
          ループ → エージェントにプロンプト → 検証 → 状態保存 → 次の判断 → 繰り返す
          ↑ あなたはループの「外」にいて、設計と監督だけする

Claude Code を率いる Boris Cherny（Anthropic）の言葉がこの転換を象徴している。

"I don't prompt Claude anymore. I have loops running that prompt Claude and figuring out what to do." （もう自分で Claude にプロンプトを打たない。Claude にプロンプトを打ち、次に何をやるか考えるループを走らせている）

1-2. キャッチコピー（提唱者たちの言葉）¶

人物	立場	主張
Peter Steinberger	開発者	"You should be designing loops that prompt your agents."（個々のプロンプトではなくループを設計せよ）
Boris Cherny	Head of Claude Code, Anthropic	"I have loops running that prompt Claude."（ループに Claude を打たせている）
Addy Osmani	Google, 著名フロントエンドエンジニア	後述の「監督であり続けよ」。この概念の canonical エッセイの著者

注: このリポジトリ自体は Cobus Greyling が、Addy Osmani・Boris Cherny の概念を土台に「実践パターン集」として整理したもの。概念の出どころ（Addy Osmani / Boris Cherny）と、それを型録化した実装（Cobus のリポジトリ）は別物として捉えると混乱しない。

2. 3段階の進化 — どこに位置する概念か¶

ループエンジニアリングは突然出てきた概念ではなく、AIエージェント活用の「積み上げ」の最上層にある。下の層が上の層の前提になっている。

層	名前	やること	対象の単位
1	Context Engineering（コンテキストエンジニアリング）	プロンプトに入れる情報を構造化する	1回の入力
2	Harness Engineering（ハーネスエンジニアリング）	1回のエージェント実行に、ツール・構造・ガードレールを装備させる	1回の実行（run）
3	Loop Engineering（ループエンジニアリング）	エージェントをスケジュールで・ゴール達成まで自律的に回す仕組みを作る	時間をまたいだ繰り返し

リポジトリ内の表現を借りると:

"The harness equips a single agent run; the loop is what keeps poking agents on a schedule, spawning helpers, and feeding itself." （ハーネスは1回の実行を装備する。ループは、スケジュールに沿ってエージェントを突き続け、ヘルパーを生成し、自分自身に餌（入力）を与え続けるもの）

Context Engineering  : 「何を伝えるか」を整える        … 入力の質
        ↓ その上に
Harness Engineering  : 「1回の実行」を頑丈にする        … 1ランの質（ツール・検証・型）
        ↓ その上に
Loop Engineering     : 「回し続ける仕組み」を作る        … 時間軸・自律性

参考: agentic_reference_architecture_評価ループの「評価ループ」は、この3層目（Loop）の中核部品である「検証（verify）」を扱っている。

3. ループの「5つの構成要素 + メモリ」¶

ループを作るには、最低限これらの部品（プリミティブ）が要る、という整理。これが本リポジトリの一番の幹。

部品	ループの中での役割	あなたの環境での対応物（例）
Automations / Scheduling（自動化・スケジューリング）	一定の周期で「仕事の発見＋仕分け（triage）」をする	cron、GitHub Actions の `schedule`、Temporal の schedule
Worktrees（ワークツリー）	並行作業を安全に隔離する（互いに干渉させない）	`git worktree`、隔離コンテナ（llm_agent_sandbox_隔離技術）
Skills（スキル）	プロジェクト固有の知識を永続化して毎回与える	`~/.claude/skills/`、CLAUDE.md
Plugins & Connectors（プラグイン・コネクタ）	実際のツール（GitHub・チケット・DB）に手を伸ばす	MCP サーバー（Zotero MCP 等）、`gh` CLI
Sub-agents（サブエージェント）	作る人（maker）と検査する人（checker）を分ける	Claude Code のサブエージェント（実装役＋レビュー役）
+ Memory / State（メモリ・状態）	会話の外に残る永続的な背骨。run をまたいで情報を運ぶ	状態ファイル、`MEMORY.md`、DB

ポイントは最後の Memory / State。

"A loop is not a prompt, it is a recurring process with memory, verification, and boundaries." （ループはプロンプトではない。メモリ・検証・境界を持った繰り返しプロセスだ）

チャットは閉じれば消える。ループは「次の run」が必要なので、会話の外に状態を持たないと続かない。ここが普通のプロンプト利用との決定的な違い。

4. ループの解剖図（Loop Anatomy）¶

1回のループが内部で何をしているかの標準フロー。「人間ゲート（Human Gate）」が入っているのが肝。

┌─────────────────────────────────────────────────────────────┐
│  Schedule / Automation（スケジュールで起動）                  │
│        ↓                                                       │
│  Triage Skill（仕分け：今回やるべき仕事を決める）             │
│        ↓                                                       │
│  Read + Write STATE / Memory（前回の状態を読み、更新する）    │
│        ↓                                                       │
│  Isolated Worktree（隔離した作業場を用意）                    │
│        ↓                                                       │
│  Implementer Sub-agent（実装役が手を動かす）                  │
│        ↓                                                       │
│  Verifier Sub-agent（検査役がチェックする）← maker/checker分離│
│        ↓                                                       │
│  MCP / Git / Tickets（実ツールに反映）                        │
│        ↓                                                       │
│  Human Gate?（人間の承認が要るか判定）                        │
│     ├─ 安全・許可済み → Commit / PR / Action を実行           │
│     └─ 危険・曖昧     → Escalate（人間にエスカレーション）    │
│        ↓                                                       │
│  Repeat（次の周期へ）                                         │
└─────────────────────────────────────────────────────────────┘

maker/checker 分離（実装役と検査役を別エージェントにする）が品質の要。1人のエージェントに「作って・自己採点して」とやらせるより、別人格に検証させた方が見落としが減る、という発想。会計の「作成者と承認者を分ける」内部統制と同じ。

5. 7つの本番パターン（Production Patterns）¶

「で、具体的に何をループにするの？」への回答が、この7パターン。周期（cadence）とコストが全然違うので、コスト×頻度の組み合わせで選ぶ。

パターン	周期	何をする	初週レベル	トークンコスト
Daily Triage（日次仕分け）	1日〜2時間	issue/PR/タスクの発見と仕分け	L1 レポートのみ	低
PR Babysitter（PR子守り）	5〜15分	自分のPRのCI・レビュー・コンフリクトを見張る	L1 監視のみ	高
CI Sweeper（CI掃除屋）	5〜15分	CIの失敗を検知して直す	L2 慎重に	非常に高
Dependency Sweeper（依存更新）	6時間〜1日	依存パッケージの更新・パッチ	L2 パッチのみ	中
Changelog Drafter（変更履歴起草）	1日 or タグ時	CHANGELOG のドラフト生成	L1 ドラフト	低
Post-Merge Cleanup（マージ後掃除）	1日〜6時間	マージ後のブランチ削除・後片付け	L1 閑散時間帯	低
Issue Triage（issue仕分け）	2時間〜1日	issue のラベリング・優先度付け・提案	L1 提案のみ	低

あなたの pr-watch スキルや ~/research-orchestrator は、上の PR Babysitter / Daily Triage とほぼ同型。既にこのパターン表の住人。

5-1. 段階的ロールアウト（L1 → L2 → L3）¶

いきなり全自動にしないのが鉄則。信頼を積み上げてから権限を上げる。

レベル	名前	挙動
L1	Report（報告のみ）	提案するだけ。自動修正しない。初週はここから
L2	Assisted（補助つき）	ガイド付きで修正するが、危険な変更には人間ゲート
L3	Unattended（無人）	完全自動。ただし denylist・MCPスコープ・検証で固める

これは ~/.claude/CLAUDE.md の権限設計（defaultMode: 対話は acceptEdits、無人実行は dontAsk、deny を安全網に）と完全に同じ思想。権限を文脈で分け、無人化は最後という発想が共通している。

6. CLI ツール（足場づくりと監査）¶

リポジトリは npm 公開の CLI を3＋1本同梱。ループを手書きせず scaffold（雛形生成）できる。

ツール	用途	コマンド例
loop-init	パターンの雛形を生成（予算・実行ログ付き）	`npx @cobusgreyling/loop-init . --pattern daily-triage --tool grok`
loop-audit	「ループ準備度スコア」を算出＋活動検知	`npx @cobusgreyling/loop-audit . --suggest`
loop-cost	トークン消費（コスト）見積もり	`npx @cobusgreyling/loop-cost --pattern ci-sweeper --cadence 15m`
goal-audit	「完了まで走らせる」ゴール志向の補助	`npx @cobusgreyling/goal-audit`

対応ツール: Grok / Claude Code / Codex / GitHub Actions。リポジトリ構成は /patterns（7パターン）・/starters（クローンして動く雛形）・/examples（ツール別実装）・/tools（CLI 群）・/docs（失敗モード・アンチパターン・安全・マルチループ調整）・/skills・/stories（実際の成功・失敗談）。

7. リスクと「やってはいけないこと」（最重要・必読）¶

ここを飛ばすと事故る。リポジトリが最も強調している節。

"Loop engineering amplifies judgment — both good and bad." （ループエンジニアリングは判断を増幅する。良い判断も、悪い判断も）

良い設計なら良い結果を量産するが、ダメな設計はダメな結果を量産する。増幅装置である点が怖さの本質。

リスク	中身
コスト爆発	サブエージェント＋長時間ループでトークン消費が指数的に膨らむ。だから `loop-cost` で事前見積もり
検証責任は人間に残る	無人ループは「無人のミス」を生む。検証を仕組みに入れても、最終責任は設計者
理解の負債（comprehension debt）	手動より速く「自分が読んでいないコード」が積み上がる。何が ship されたか監査しないと、自分のコードベースが分からなくなる
同じループ・違う結果	結果はループのロジックだけでなく設計者の意図で決まる。コピペでは再現しない

そして締めの一文（Addy Osmani）。この資料で一番覚えておくべき言葉。

"Build the loop. But build it like someone who intends to stay the engineer, not just the person who presses go." （ループを作れ。ただし「ボタンを押すだけの人」ではなく、「エンジニアであり続けるつもりの人」として作れ）

8. まとめ — いつ・どう使うか早見表¶

状況	推奨アプローチ
1回きりの作業、探索的なタスク	ループ化しない。普通にプロンプトを打つ（過剰設計を避ける）
毎日・定期的に発生する単純作業（仕分け・掃除）	Daily Triage / Post-Merge Cleanup から、まず L1（報告のみ）で導入
自分のPRの面倒を見たい	PR Babysitter（ただし周期が短く高コスト。コスト見積もり必須）
CIの失敗を自動で直したい	CI Sweeper。最も高コスト＆危険なので L2 から慎重に、人間ゲート必須
まず「自分のプロジェクトがループ化に向くか」知りたい	`npx @cobusgreyling/loop-audit . --suggest` で準備度スコアを見る
コストが不安	導入前に `loop-cost` で周期×パターンの消費を試算

結論: ループエンジニアリングは「新技術」というより働き方のOSアップデート。あなたは Temporal / cron / GitHub Actions で既に実践している。この資料の価値は、(1) 5部品＋メモリという部品リスト、(2) 7パターンという型録、(3) L1→L2→L3 という安全な昇格手順、(4) コスト・理解負債というリスク語彙を手に入れること。次にループを1本足すとき、この4つを照らし合わせれば設計の抜けが見える。

参考リンク¶

GitHub リポジトリ本体: https://github.com/cobusgreyling/loop-engineering
Cobus Greyling「Loop Engineering」(Medium): https://cobusgreyling.medium.com/loop-engineering-62926dd6991c
同 (Substack): https://cobusgreyling.substack.com/p/loop-engineering
Loop Engineering Playbook (Medium): https://cobusgreyling.medium.com/loop-engineering-playbook-4460e01e88d8
Addy Osmani による canonical エッセイ: https://addyosmani.com/blog/loop-engineering/
The Rise of AI Harness Engineering (前段の概念): https://cobusgreyling.medium.com/the-rise-of-ai-harness-engineering-5f5220de393e
Goal Engineering（完了まで走らせる派生概念）: https://cobusgreyling.medium.com/goal-engineering-788b5ca00e7f
解説記事 (Codersarts): https://www.codersarts.com/post/loop-engineering-explained-how-to-build-self-running-ai-coding-agents-2026-guide

作成: 2026-06-25 ／最終更新: 2026-06-25