🔄 ループエンジニアリング教科書

Googleのエンジニア Addy Osmani が2026年6月に体系化した概念。一言で言えば:

ループエンジニアリングとは、エージェントにプロンプトを出す自分自身を置き換えること。代わりにそれを行うシステムを設計することだ。
— Addy Osmani「Loop Engineering」

従来は人間がAIに1回ずつ指示を出し、結果を見て、また次の指示を出す — これを繰り返していた。ループエンジニアリングは、この「指示を出す役割」そのものを AIが自律的に次のタスクを考えて実行し続ける仕組み（＝ループ） で置き換える。

「ループ」とは何か

ここでのループは、単なる繰り返し処理ではない。while 文のように、AIが 目標達成まで自律的に回り続けるサイクル を指す。人間は各反復で指示を出すのではなく、ループ全体を設計する。

ループエンジニアリングは突然現れたのではなく、AI活用の進化の到達点。各段階で「人間が工夫する対象」が移り変わってきた。

重要なのは、プロンプトの質だけで差がつかなくなったこと。上手な指示を1回出すより、失敗して自己修正しながら一歩ずつ進むループ を組む方が、不確実な現実では安定する。

Cat Wu（Claude Code Head of Product）の3段階フレーム

BorisとともにClaude Codeを率いるCat Wuは、上記4段階モデルをより実務的に圧縮した3段階で語っている: source code → agent → loop。「最初はコードを直接編集していた。次はエージェントにコード編集を頼むようになった。今は /loop・/goal・routineがClaudeにプロンプトを出してくれる」（Boris Cherny）。4段階モデルに対応させると、②Context・③Harnessが「agent」フェーズに、④Loopがそのまま「loop」フェーズにあたる。

この概念を最も体現しているのが、Anthropicの Boris Cherny — Claude Codeの作者（責任者）。彼は自身の仕事をこう表現した:

私の仕事はプロンプトを書くことではない。ループを書くことだ（My job is to write loops, not individual prompts）。
— Boris Cherny, Anthropic

Claude Codeという製品自体が、この思想の結晶。ユーザーが都度指示を出すチャットツールではなく、hooks・cron・subagent・スキル・MCPを組み合わせて 自律的にタスクを回す基盤 を提供する。

何が変わるか

「良いプロンプトを書く人」から「良いループを設計する人」へ。プロンプトエンジニアリングが「過去の正解」になり、ループ設計がこれからの差別化要因になる。

実数値で見るBorisの「ループ生活」

これは比喩ではない。2025年11月、Borisは「使っていなかったから」自分のIDEをアンインストールしたと明かした。続く12月には、Claude Code + Opus 4.5だけで30日間に259件のPRをマージ（497コミット、+4万行/−3.8万行・全行Claude Code生成）— その間IDEを一度も開いていない。Stop Hookでループを組み、数分〜数日間（最長で1日18時間）連続稼働させるのが日常運用になっている。

自律ループは5つの構成要素で成り立つ。いずれかが欠けるとループは止まるか暴走する。

DataScienceDojo はこれを「trigger + verifiable goal」— エージェントが目標達成まで人間の追加指示なしに回り続ける構造 — と要約している。進化の系譜としては ReAct パターンの延長。

Claude Codeには /goal（条件達成まで自動継続）と Routines（クラウドでスケジュール実行）というネイティブ機能がある。これらは「ループを動かす便利なツール」だが、「ループエンジニアリング」の本体ではない。

ツールが担える範囲

/goal と Routines は「Automations（自動継続・スケジュール）」の1ピースを担うだけで、残り5要素は依然として自分で設計する必要がある。ツールを使えばループが完成するわけではない。

Boris が言う「ループを書く」の実体

「ループを書く」とは、ツールの設定を記述することではない。小さな制御系（control system）を設計することだ。Borisの言う「ループ」は、作業を自ら見つけ・割り当て・検証し・状態を記録し・次の作業を決める自律的な制御の仕組みを指す。

制御系の設計には、3つの問いに答える必要がある。

• 何の作業を、どの順序で、どのエージェントに渡すか（ディスパッチの設計）
• 「完了」とは何かを機械的に証明できる形で定義できるか（停止条件の設計）
• 失敗・暴走をどこで、どう止めるか（安全ガードの設計）

この3つを設計しない限り、/goal を使っても「とりあえず動くが止まり方が分からないループ」になる。

条件文を書くことが核心スキル

/goal も Stop Hook も、条件文の質でループの信頼性が全部決まる。 評価モデルは「会話のトランスクリプト」しか見ないため、条件文は「Claude 自身の出力で証明できるもの」に限られる。ファイルシステムの直接参照やコマンドの独立実行はできない。

「完了」を書けなければ、ループではなく願望だ。
— Addy Osmani（意訳）

補足: /goal は Claude Code v2.1.139 以降で利用可能。Stop Hook の session-scoped ラッパーとして実装されており、disableAllHooks が設定されている環境では使用不可。また ANTHROPIC_BASE_URL を外部プロバイダに差し替えた構成（GLM/MiniMax等）での動作は未確認。

5要素を支える 土台。AIはセッションごとに記憶を失うため、この土台が無いと文脈維持（②）も自己修正（③）も成り立たない。

記憶の外在化

「今どこまで進んだか」「次に何をやるか」「何に失敗したか」を 外部ファイル（状態ファイル） に書き残し、次の反復・次のセッションがそれを読み込んで引き継ぐ。AIの記憶を、AIの外側に置く設計。

ループを回すのはAIだが、ループを繋ぐのはファイルだ。

これが無いと、毎セッション「前提を説明し直す」無駄が発生し、ループの自律性が崩れる。

具体例: Ralph Wiggumテクニック

「記憶の外在化」を最も極端な形で実践したのが Ralph Wiggumテクニック。Geoffrey Huntleyが考案した、while :; do cat PROMPT.md | claude-code; done という単純な無限ループで、AI自身のコンテキストウィンドウには何も保持させず、進捗・仕様・修正計画はすべてファイルとgitコミット履歴に外在化する。2026年初頭、Ryan Carsonがこの手法をスレッドで紹介し（86万ビュー超）、界隈に爆発的に広まった。

このテクニックは不確実な世界において、決定論的に「下手」であることを選ぶ。予測不能に成功するより、予測可能に失敗する方がいい。
— Geoffrey Huntley（意訳）

ループ設計における最重要ベストプラクティス。

なぜ分けるか

同じAIに「コードを書かせて、それをそのままチェックさせる」と、どうしても 判断が甘くなる。自分の書いたものに甘くなるのは人間と同じ。だから役割を物理的に分ける:

• 作るAI — 修正案・コードを生成する
• 検証AI — プロジェクトの規約・既存テストに照らして、厳しく採点する

検証AIは「作るAIとは別のコンテキスト・別の指示」で動く。これで初めて、本物のコードレビューと同じ緊張感が生まれる。Claude Code では subagent（code-reviewer・silent-failure-hunter 等）がこの役割を担う。

/goal 自体もこの原則の適用例。作業したClaude が「完了か否か」を自己判定せず、別モデル（Haiku等）が判定する。

自律ループが1日をどう回すか、概念図（元動画の実演）。

🌅 朝 — 自動実行とタスク抽出

人間の指示なしにタイマーで起動。「状況整理AI」が前日の失敗ビルド・残課題・最近のコード変更を読み込み、「今日やることリスト」を自動生成してファイルに書き出す。

☀️ 昼 — 作業部屋の分離と相互検証

各タスクに独立した作業部屋（干渉しないコンテキスト）を用意。作るAIが実装 → 完了後 検証AI が規約とテストで厳格に自動検証。

🌇 夕 — 外部連携とエスカレーション

検証通過したものを MCP 経由でチケット更新・PR作成・チャット通知。AIだけでは解けない難題は「人間の判断を仰ぐボックス」に仕分け（無理に進めない）。

🌙 夜 — 状態の保存

1日の成果・うまくいったこと・残課題を状態ファイルに保存。翌朝、AIがそれを読み込んで記憶が引き継がれる。

「ループエンジニアリング」という概念は遠い存在ではない。自分のClaude Code環境は 既にこのループを実践している。5要素と土台を、実際の実装に対応させた。

つまり Boris の「write loops, not prompts」は、自分の環境の ~/.claude/ の中に既に書かれている。この教科書は、その実践を言語化し直す作業でもある。

第6章の観点から補足すると、ツール（/goal・Routines）の有無にかかわらず、上記の制御系を設計できていることがループエンジニアリングの本質。ネイティブ機能はあくまで「Automationsの自動継続」を楽にする道具であり、state.json・next-issue.py・Stop Hook連鎖による自前実装は、それと同等かそれ以上の制御系を構成している。

Tier A（端末ハーネス）/ Tier B（プラットフォームランタイム）— 自分の環境はどちらか

Cobus Greylingは続編「Loop Engineering Playbook」で、ループの実行環境を2段階に分類している。

自分の環境（Claude Code をターミナルで運用）は Tier A。第13章のStep 4〜5は依然Tier Aの範囲内であり、複数テナント・本番SaaS化が必要になった時点でTier Bへの移行を検討する、というのが現実的な判断基準になる。

2026年時点で、ループエンジニアリング・パターンを組み込んだ主な実装の比較。

The AI Corner の分析では、Claude Code と Codex は どちらも2026年にループエンジニアリング・パターンを出荷済み。違いは、Claude Code が hooks/cron/skill/MCP を ユーザー側で組み立てられる基盤 として公開している点（自分の環境がまさにそれ）。

ループは強力だが、放っておくと3つの罠に落ちる。

① 検証 — 人間の目が必須

AIの自己検証は甘くなる（第8章）。最終的な「これで出してよいか」の判断は人間が持つ。自動化が進むほど、この最終チェックをサボりたくなるが、そこが一番危ない。

Peter Steinbergerはこれを 「the agentic trap人間が早すぎるタイミングでループから手を引くと、tasteのない大量のslop（低品質量産物）が生まれる罠（エージェント的な罠）」 と呼ぶ — 人間が早すぎるタイミングでループから手を引くと、AIは一晩中動き続けても「テイスト（taste）」を持たないため、結局は大量の「slop（質の低い量産物）」しか生まれない。仕様を最初に全部書き切って後は丸投げ、という発想そのものが罠になる。

AIはスパイキーに賢く優秀だが、うまく導かなければ結局slopになる。正しい問いを投げかけなければ、それもslopになる。
— Peter Steinberger（意訳）

② コスト — 並行処理で計算コスト増大

ループは（特にマルチエージェントで）並行して回る。サブエージェントを多数起動すると、トークン消費が爆発する。停止条件（第5章⑤）と予算上限の設計が必須。

③ 理解の借金AIが高速生成したコードを人間が説明できない状態。放置すると利息がつき、最終的に破産する — AIが超高速生成し、人間がシステムを説明できなくなる

これが最も恐ろしい。AIが人間を置き去りにしてコードを生成し続けると、人間側が「システムが中で何をやっているか説明できない状態」に陥る。この 理解のギャップ（借金） は利息がつく。返済（コードを読む力）をサボると、いずめ破産する。

ループが自動化を担うほど、コードを読む力（Python基礎学習等）が重要になる。自動化と理解はトレードオフではない — 自動化を安全に回すために理解が要る。

いきなり完全自律ループは組めない。段階的に5ステップで移行する。

自分の環境は Step 4〜5 に到達している。残る課題は「理解の借金」の返済（Step 3 の検証を人間が追える程度に、コードを読む力を保つこと）。

本番パターン7選（頻度・コスト目安）— どのStepから始めるか

Cobus Greylingの続編「Loop Engineering Playbook」では、実際に本番投入されているループを7パターンに整理し、頻度とリスク（≒コスト）目安を示している。

頻度が高い（5〜15分間隔）パターンほど暴走時のトークン消費リスクが大きく、「3回失敗したら人間にエスカレーション」という上限設計（第12章②）が必須になる。Step 2〜3（状態記録・自己検証）が固まっていないうちは、まず低頻度・低リスクのDaily Triage / Changelog Drafterから始め、Tier A環境（第10章）で実績を積んでからPR Babysitter等の高頻度パターンに広げるのが安全。

ループが実行を担うからこそ、人間は 「ただ実行ボタンを押すだけの人」に退化してはならない。

人間の新しい役割

• 全体の俯瞰 — ループの健全性・方向を監視する
• 最終判断 — 「これで出してよいか」の最後の砦
• ループの設計改善 — 止まったループの原因究明・再設計
• 審美眼 — 何を実行し、何を差し止めるかの倫理的・品質的判断

AIが高速に仕事をこなすようになればなるほど、何をさせるかを決める人間の判断が、最大の武器になる。

これは「コードを読めない素人だから関係ない」ではない。むしろ、非IT出身でループを組んでいるからこそ、コードを読む力を意図的に鍛え続ける ことが、理解の借金を防ぐ唯一の道。

関連ガイド（自分の環境）

• OpenClaw Stack Guide — ループの象徴的実装
• Claude Code Guide — hooks/skill/MCP/subagent の機能詳細
• Python基礎Guide — 「理解の借金」返済の道具