グラレコ
はじめに 🎯
Loop Engineering（ループエンジニアリング）は、AI コーディングエージェントとの付き合い方を一段引き上げる考え方です。Google のエンジニアである Addy Osmani 氏が 2026 年 6 月のブログ記事で名前を与え、広く知られるようになりました。ひとことで言うと、「エージェントに毎回プロンプトを書く」のをやめて、「エージェントを繰り返し呼び出すシステム（ループ）を設計する」側に回る、という発想の転換です。
きっかけになったのは、現場の実務家たちの発言でした。Claude Code を率いる Boris Cherny 氏は、インタビューやイベントで「もう Claude に直接プロンプトはしない。ループを走らせていて、プロンプトするのはそのループのほうだ。私の仕事はループを書くことだ」という趣旨のことを語ったとされています。同じ時期、OpenClaw の Peter Steinberger 氏も「もうコーディングエージェントにプロンプトするのではなく、エージェントにプロンプトするループを設計すべきだ」と投稿し、この言葉が大きく広がりました。
この記事で分かること:
- 🧭 prompt → context → harness → loop engineering という用語の系譜
- 🔁 ループを構成する 5 つの部品と、6 番目の「メモリ」
- 📅 1 日のループが実際にどう回るか（朝のトリアージから引き継ぎまで）
- 🛠️ Claude Code と OpenAI Codex での実装機能（公式確認の可否つき）
- ✅ なぜ「検証」だけは自動化しきれず、人とサブエージェントに残るのか
- ⚠️ 理解の負債・思考の放棄・コスト暴走という落とし穴
- 🧑⚖️ 「同じループでも、人によって結果は正反対になる」という核心
🧭 prompt → context → harness → loop engineering の系譜
Loop Engineering は突然出てきた言葉ではなく、用語の積み重ねの先にあります。順に見ると位置づけが分かりやすくなります。
この図のポイントは、関心の対象がだんだん「外側」へ広がっていることです。
- Context Engineering は、2025 年 6 月に Shopify の Tobi Lütke 氏が「prompt engineering より context engineering という言葉が好きだ。タスクを LLM が解けるよう、必要なコンテキストをすべて与える技術を指す」と述べ、Andrej Karpathy 氏も賛同したことで広まりました。Simon Willison 氏は、プロンプトを磨く話にとどまらず「モデルが見る入力全体（指示・例示・検索結果・履歴・ツール）を組み立てる実務」を正しく表す言葉だと整理しています。
- Harness Engineering は、Osmani 氏いわく「モデルを取り囲む足場（プロンプト・ツール・コンテキスト方針・フック・フィードバックループ）全体を設計する規律」です。「Agent = Model + Harness」という捉え方が核にあります。
- そして Loop Engineering は、その harness の「一階層上」に立ちます。足場をいつ・どの頻度で・誰が起動するかまで含めて、自走するループとして設計する、というわけです。
💡 整理すると、Prompt は「モデルへの話し方」、Context は「モデルに見せるもの」、Loop は「いつ・何を・誰がプロンプトし、結果が許容範囲かを誰が決めるか」という自律システムの設計、という対比になります。
🔁 ループを構成する 5 つの部品と、6 番目の「メモリ」
Osmani 氏は、ツールに依存しない抽象として、ループを 5 つの部品で説明しています。そして同じ部品が Claude Code にも Codex にも実装されている、という点が重要です。
| # | 部品 | 役割 |
|---|---|---|
| 1 | ⏰ Automations（自動起動） | スケジュールやトリガーでループを起動し、探索・トリアージを自動化する |
| 2 | 🌲 Worktrees（作業ツリー） | 並行実行時にファイル競合を避ける（各エージェントが独立した作業ディレクトリで動く） |
| 3 | 📚 Skills（スキル） | プロジェクト固有の知識を SKILL.md として外部化し、毎回ゼロから再導出させない |
| 4 | 🔌 Connectors / Plugins | Issue トラッカーや Slack など外部ツールと連携する（MCP が基盤） |
| 5 | 🤝 Sub-agents（サブエージェント） | タスクを分割する。とくに「作る役」と「検証する役」を分ける |
これらに加えて、Osmani 氏が 6 番目として強調するのが State / Memory（状態・記憶） です。印象的な一文があります。
"the memory has to be on disk and not in the context. The agent forgets, the repo doesnt."
（記憶はコンテキストではなくディスクに置く必要がある。エージェントは忘れるが、リポジトリは忘れない。）
記憶は Markdown ファイルや Linear のボードのように、コンテキストの外に永続させます。実行済み・進行中・次にやることを書き留め、エージェント間・日をまたいだ実行の「引き継ぎ点」にする、という考え方です。全体像は次のようになります。
この図のポイントは、ループが「賢い 1 体のエージェント」ではなく、起動・隔離・知識・連携・分業・記憶を組み合わせたシステムだということです。Skills について Osmani 氏はこう書いています。「スキルがなければループは毎サイクル、プロジェクト全体をゼロから再導出する。スキルがあれば、いわば積み上がっていく」。
📅 1 日のループが実際にどう回るか
抽象論だけだとイメージしにくいので、Osmani 氏が挙げる「典型的な 1 日のループ」を追ってみます。
この図のポイントは、Osmani 氏の言葉どおり「あなたは一度だけ設計した。これらのステップのどれにもプロンプトしていない」という点です。朝の起動からトリアージ、並行修正、検証、PR・通知、そして翌朝への引き継ぎまでが、自分が設計したループとして自動で進みます。OpenAI Codex の公式ドキュメントでも、Automations の用途例としてデイリーの issue トリアージ・アラート監視・CI/CD 自動化・コミットのブリーフィングなどが挙げられています。
💡 こうした「夜間・無人で回るループ」の元祖としてよく挙げられるのが、Geoffrey Huntley 氏が考案した通称「Ralph Wiggum ループ」です。
while trueの bash ループでPROMPT.mdを毎回フレッシュなセッションに食わせ、進捗ファイルに状態を書き戻すだけ、という素朴な仕掛けでした。これがバイラル化し、Anthropic は後にralph-wiggumを Claude Code の公式プラグインとして取り込んでいます。
🛠️ ツールでどう実装するか — Claude Code と OpenAI Codex
同じ 5 部品が、2 つの主要ツールにそれぞれ用意されています。以下は 2026 年 6 月時点で公式ドキュメントに照らして確認した内容です（一部、ブログ記述のみで公式未確認のものは注記します）。
| 部品 | Claude Code | OpenAI Codex |
|---|---|---|
| ⏰ Automations |
/loop（一定間隔で繰り返し実行。間隔やプロンプトを省略でき、.claude/loop.md で既定動作を上書き）、cron スケジューリング、/schedule（クラウド側 Routines）、Hooks、GitHub Actions の schedule:
|
Automations タブ（時間ベース＋cron 構文。Standalone と Thread の 2 種）。結果は Triage へ |
| 🌲 Worktrees |
--worktree フラグ、サブエージェントの isolation: worktree
|
スレッドごとに worktree を自動取得 |
| 📚 Skills | Agent Skills（SKILL.md、/skill-name で呼び出し。agentskills.io 標準準拠） |
Agent Skills（SKILL.md、.agents/skills を探索） |
| 🔌 Connectors | MCP（stdio / HTTP）。connector は MCP と同一基盤 | MCP（config.toml、codex mcp） |
| 🤝 Sub-agents |
.claude/agents/（Markdown 定義、モデル・ツール権限を個別指定）、Agent Teams |
.codex/agents/（TOML 定義、model や model_reasoning_effort 等を指定） |
とくにループ運用の中心になりそうな 2 つのコマンドは、公式ドキュメントで実在を確認できました。
-
/loop [間隔] [プロンプト]: プロンプトを一定間隔で繰り返します。プロンプトを省略すると、未完作業の継続・PR レビュー対応・CI 失敗対応・バグ掃除といった「組み込みメンテナンス動作」または.claude/loop.mdを実行します。 -
/goal: 完了条件を 1 つ設定すると、達成までターンをまたいで自律的に作業を続けます。注目したいのは、各ターン後に別の小型・高速モデル（既定では Haiku）が会話のトランスクリプトを評価し、未達なら次のターンを自動で始める仕組みになっている点です。検証を別モデルに任せる設計が、コマンドの中にすでに組み込まれているわけです。
💡 補足として、Osmani 氏のブログは Claude Code と Codex の両方に
/goalを挙げていますが、本記事の調査では OpenAI の公式ドキュメント上で Codex の/goalを裏取りできませんでした（Claude Code の/goalは公式に確認済みです）。Codex 側の/goalを引用する際は「公式未確認」と添えるのが安全です。なお Codex の Automations・worktree・サブエージェント（TOML）・Skills・MCP はいずれも公式に確認できています。
ファイル競合を避ける git worktree が並行実行で重宝されるのは、「あるセッションの編集が、別セッションのファイルに一切触れない」状態を作れるからです。1 つのツリーで機能開発をしながら、別のツリーでバグ修正を同時に走らせる、といった使い方ができます。
✅ 検証だけは自動化しきれない — それでも人とサブエージェントに残る
ループを無人で回せるようになっても、Osmani 氏ははっきり釘を刺しています。「検証は依然としてあなたの仕事だ」。無人のループは、無人のミスも生みます。そして「完了しました」はあくまで主張であって、証明ではありません。
ここで効いてくるのが、印象的なこの一節です。
"The model that wrote the code is way too nice grading its own homework."
（コードを書いたモデルは、自分の宿題を採点するには優しすぎる。）
この「自己採点は甘くなる」傾向は、Osmani 氏の別記事でも「モデルは自分の成果を採点すると、信頼できるほど一貫してポジティブに偏る」と指摘されています。だからループでは、作るサブエージェントと、検証するサブエージェントを分けるのが定石になります。
この図のポイントは、検証者を「新しいコンテキストを持つ独立したサブエージェント」にすることです。生成と同じモデル・同じ文脈で自己批評させると、盲点を共有したまま見逃しが起きやすくなります。Anthropic が並列 Claude で C コンパイラを作った事例でも、「タスクの検証器（verifier）はほぼ完璧でなければならない。さもないと Claude は『間違った問題』を解いてしまう」「テストが通るのを見て完了したと思い込みがちだが、実際には完了していないことが多い」と、検証の質がループ全体の質を決めると報告されています。
検証を強くするには、検証者に強い（信頼できる）モデルを割り当てる、敵対的な視点（あらゆる欠陥を探す役）で複数レビューさせる、といった工夫が挙げられています。
⚠️ ループの落とし穴
ループは強力ですが、Osmani 氏も他の論者も、いくつかの落とし穴をはっきり挙げています。
| 落とし穴 | 何が起きるか |
|---|---|
| 🧩 Comprehension Debt（理解の負債） | ループが高速にコードを 生成 するほど、「存在するコード」と「自分が理解しているコード」の差が広がる。技術的負債と違い、警告を出さずに静かに溜まる |
| 🛋️ Cognitive Surrender（思考の放棄） | 自動化が快適なあまり、意見を持つのをやめて、出てきたものをそのまま受け取るようになる |
| 💸 トークンコストの暴走 | 毎ターン検証モデルを走らせるループはトークンを速く消費する。組み込みの予算制御がないと、API 予算を一気に使い切りうる |
| 🚢 レビューせずにそのまま公開（リリース） | 生成の速度が、人間がレビューする速度を追い越し、理解しないままマージしてしまう |
裏づけになるデータもあります。Google の DORA レポート 2025 は、AI 採用が進むなかで「AI はチームを直すのではなく、既存の状態を増幅する（AI as amplifier）」と整理し、レビューを経ずにマージされる変更の増加を指摘しています。METR が経験豊富な OSS 開発者を対象に行った 2025 年前半の実験では、AI ツール使用時にタスクがかえって 19% 遅くなり、しかも開発者本人は「速くなった」と感じていた、という認知のギャップが報告されました（METR 自身が「2025 年前半の一断面であり一般化はしない」と明確に注記しています）。
💡 日本語の事例でも、「Claude Code が 43 コミットを生成したものの、PR の趣旨からズレてほぼ全却下になった」というループ暴走の失敗が共有されています。明確な完了条件・検証方法・ガードレールがないループは、活発に動いているように見えて成果につながらない、という教訓です。
Osmani 氏は処方箋をこう書いています。
"Build the loop. But build it like someone who intends to stay the engineer."
（ループを作れ。ただし、エンジニアであり続けるつもりの人として作れ。）
🧑⚖️ 「同じループでも、人によって結果は正反対になる」
この記事で一番伝えたいのが、Osmani 氏の締めのメッセージです。
"Two people can build the exact same loop and get completely opposite results. One uses it to move faster on work they understand deeply. The other uses it to avoid understanding the work at all. The loop doesn't know the difference. You do."
（2 人がまったく同じループを作っても、結果は正反対になりうる。一方は深く理解している仕事を速く進めるために使い、もう一方は仕事を理解すること自体を避けるために使う。ループはその違いを知らない。あなたは知っている。）
これは精神論ではなく、データの裏づけがあります。Anthropic が 2026 年 1 月に公開したジュニアエンジニア 52 名の実験では、AI を使った群は理解度クイズで手書き群より 17% 低いスコアでした。けれども重要なのは結論のほうで、「すべての AI 依存が同じではない（not all AI-reliance is the same）」とされています。
- スコアが低かった人の傾向: コードを丸投げする / 最初は質問するが徐々に全委任になる / 理解を作らず AI をデバッグの松葉杖にする
- スコアが高かった人の傾向: 生成させたあと追加質問で理解する / コード生成と説明をセットで求める / 概念的な質問は自分の理解に依存する
この図のポイントは、ループという道具自体は中立で、使う人の関わり方が結果を分けることです。シニアエンジニアほど AI の出力を評価・修正・方向づけできるため、AI は差を埋めるどころか広げる（増幅する）という見方も複数のソースで示されています。Osmani 氏の主張を言い換えれば、ループを設計することは、判断力を持ってやれば治療薬になり、考えるのを避けるためにやれば促進剤になる、ということです。
🏁 まとめ
Loop Engineering の要点を 3 つに絞ります。
| # | キーメッセージ |
|---|---|
| ① | 重心が「プロンプトを書く」から「ループを設計する」へ移った。Automations・Worktrees・Skills・Connectors・Sub-agents の 5 部品と、ディスク上のメモリで組む |
| ② | ループは無人で回せても、検証と最終責任は人とサブエージェントに残る。生成と検証を分け、自己採点の甘さを構造で打ち消す |
| ③ | 同じループでも、深く理解して速くする人と、理解を避ける人で結果は正反対になる。理解の負債・思考の放棄・コスト暴走を避ける設計が要る |
導入の判断材料として、ある分析記事は「ループが本当に効くのは、(1) 週 1 回以上繰り返す作業で、(2) 自動検証で不良を弾けて、(3) トークン予算があり、(4) シニア級の使い手がいる、という条件がそろうとき」と整理しています。逆に言えば、まずは小さく・遅いケイデンスで・厳しい完了条件から始め、数日コストを監視してから広げる、という慎重な立ち上げが現実的です。
読み終えて感じたのは、Loop Engineering は「ツールの使い方」というより「エンジニアの仕事の重心がどこに移ったか」の話だということです。レバレッジの効く場所が、個別のプロンプトから、ループの設計と検証へと動きました。だからこそ Osmani 氏は「エンジニアであり続けるつもりの人として、ループを作れ」と念を押しているのだと思います。
参考 📚
- Loop Engineering（Addy Osmani） — 本記事の主軸。ループの 5 部品・1 日のループ・落とし穴・締めのメッセージの一次情報。
- Long-Running Agents（Addy Osmani / O'Reilly Radar） — 長期稼働エージェントの潮流、自己採点バイアス、コスト・検証の課題。
- Comprehension Debt: The Hidden Cost of AI-Generated Code（O'Reilly Radar） — 理解の負債の定義と、未レビュー 公開 のリスク。
- How AI assistance impacts the formation of coding skills（Anthropic Research） — 「すべての AI 依存が同じではない」の実証（ジュニア 52 名）。
- Building a C compiler with a team of parallel Claudes（Anthropic Engineering） — 並列エージェントの分散設計と「検証器はほぼ完璧であるべき」。
- Measuring the Impact of Early-2025 AI on Experienced OSS Developer Productivity（METR） — 19% 遅延と認知ギャップ（注記つきの RCT）。
- State of AI-assisted Software Development 2025（DORA） — 「AI は増幅器」「未レビューマージの増加」。
- Context engineering（Simon Willison） — context engineering の用語整理（Lütke / Karpathy のツイートを含む）。
-
Run prompts on a schedule（Claude Code 公式） ／ Keep Claude working toward a goal（
/goal） —/loop・/goalの公式仕様。 - Automations（OpenAI Codex 公式） — Codex の自動起動の公式仕様。