入門から実践 -「🔁 ループエンジニアリング」

前書き

最近 X やブログで 「Loop Engineering（ループエンジニアリング）」 という言葉をやたら見るようになりました。
「もう Claude に指示は出していない、私の仕事はループを書くことだ」 みたいな、ちょっと面白い言い回しで流れてくるアレです

最初は「また新しい “XX エンジニアリング” か……」と斜めに構えていました。
コンテキスト エンジニアリングの本もまだ売られているし、ハーネス エンジニアリング も、ついこの前見たばかりです

でも、これは少し毛色が違いました。今までのは 「どう上手くやるか」 を教えてくれるものでしたが、ループエンジニアリングは 「あなたが手を動かす位置から、そもそも降りろ」 という話だったんです。

この記事では

• そもそも ループエンジニアリング とは何か
• ループは何でできているのか
• 一番ハードルの低い Claude Code で最初のループを組む（入門・手を動かす）
• 自分で開発するなら：Mastraでループを回す
• 回しっぱなしの 代価

を、順に紹介していきます。
深掘りのハンズオンは後編に回して、まずは全体像をさらっと掴むのが目的です

内容は 2026/06 時点の情報です。ツール名やコマンド、対応バージョンは変わりやすいので、最新は各公式ドキュメントを確認してください

ループエンジニアリング とは

一言でいうと「指示する人」を仕組みに置き換える

定義として一番よく引用されるのは、Google Chrome チームの Addy Osmani の一文です。

Loop engineering is replacing yourself as the person who prompts the agent. You design the system that does it instead.

ざっくり訳すと 「あなた自身を、“エージェントにプロンプトを打つ人” から外す、代わりに、それを打ってくれる仕組みを設計する」。

ポイントは「プロンプトを上手く書く」でも「コンテキストを整える」でもなく、あなたという人間をその場所からどける、という点です。

今まではエンジニアが作業者の一員だったが、これからは 作業フローを設計する人 になる、という立ち位置の転移なんですね。

自分を 組織のリーダー に置き換えると腹落ちしやすいです。メンバーに都度マイクロマネジメントしていると組織は回りませんが、かといって 丸投げでも回りません 良いリーダーがやるのは、目標・レビュー体制・引き継ぎの仕組みを整えて、自分が逐一口を出さなくても回る状態を作ること。
AI エージェントを使うのもまったく同じで、これがループエンジニアリングです

この言葉、2026 年 6 月にほぼ同時多発で生まれ、定着しました。

• Peter Steinberger（OpenClaw の作者）が「コーディングエージェントに直接指示するな。エージェントに指示を出す “ループ” を設計しろ」と投稿
• Boris Cherny（Anthropic、Claude Code の責任者）も「もう Claude に指示は出していない。私の仕事はループを書くことだ」と発言
• Addy Osmani がそれらをまとめてブログで Loop Engineering と命名

3 人が口にしていたのは、結局おなじ動作でした。
あなたが設計する対象が、「エージェントの 1 回の振る舞い」から、「エージェントを動かし続けるシステム全体」に上がった ということです。

積み上がる 4 層：Prompt → Context → Harness → Loop

このループエンジニアリングと、ここ2年でよく聞いた『XXエンジニアリング』との関係は、実は置き換わるのではなく、積み上がるものです。

一段ずつ上に乗っていて、上の層ほど面倒を見る範囲が広くなります。

層	何を管理する	中心の問い
Prompt engineering	一回の指示文	モデルに何を伝えるか
Context engineering	この瞬間、ウィンドウに何を入れるか	何を検索し、何を要約し、何を捨てるか
Harness engineering	単発実行の “装備”	どのツールを許し、何を以て完了とするか
Loop engineering	harness の上で自動で回す	どうやって自分で何度も回らせるか

ループは ハーネス の一つ上の階 という言い方がしっくりきます。
下の ハーネス が「AIエージェントの 1 回の実行」を装備する係で、上の ループ が「それを自動で何度も回す」係です

ループは何でできているのか

ループの 5 つのアクション

ループといっても「同じコードがぐるぐる回る」あの空回りとは違います。
1 周ごとにちゃんと具体的な仕事をしていて、分解すると 5 つのアクション になります。

動作	やること
発見（discovery）	この 1 周で何をやるべきかを自分で見つける
受け渡し（handoff）	タスクを隔離して、作業役のエージェントに渡す
検証（verification）	別のエージェントが「これでいいか」をチェックする
記憶（persistence）	状態を会話の外（ファイル等）に書き出す
スケジューリング（scheduling）	タイマー等で、放っておいても回り続けさせる

個人的に「これが無いとループにならない」と思うのは 検証 です。
ここが甘いと、ただ生成を垂れ流すだけの装置になります

ループを組む 6 つのパーツ

次に、5 つのアクションを実際に動かすには、対応する道具立てが要ります。
開発に落とし込むと、Addy はループに必要なものを 6 つのパーツ に整理しています。

パーツ	何か	対応する動作
Automations	時間表／トリガーで自動起動	スケジューリング
Worktrees	並行エージェントの作業ディレクトリ隔離	受け渡し
Skills	知識を SKILL.md に固定して再利用	発見
Connectors（MCP）	issue tracker・DB・Slack など外部接続	記憶 / 発見
Sub-agents	生成役と評価役を分ける	検証
Memory	ファイルに残る状態（MEMORY.md 等）	記憶

「ファイルしか見えないループは、できることが少ない小さなループ」で、タスクチケット、DB、ブラウザに手が届いて初めて代わりに働くが成立します。

MCP / Skills は、ループのためのハーネス だと思っておくと分かりやすいです

ループの中、一番大事なのは「ダメと言える評価役」

コードを書いた本人は、自分の作業に甘いからです。

自分で書いた文章の誤字に気づけないのと一緒で、書いた本人に採点させると「いい感じ」と自分を説得してしまいます だから 書く側（生成役）とチェックする側（評価役）を分け、評価役は別の指示・できれば別モデル にする。

Claude Code には、条件成立まで回し続ける /goal があり、完了判定を、作業した本人ではない別のモデルにやらせます。

仕組みとしては、/goal の内部実装は prompt ベースの Stop フック です。毎ターンの最後に判定役が条件を確認し、通らなければ完了させずにもう 1 周回す——次の章で、これを手で組んでみます

入門：Claude Code で最初のループを組む

こまでの話で、ループの概念については皆さん完璧に理解できたと思います。次は、実際にコーディング作業に使えるループを組んでみましょう。
最初のループは、Claude Code に「完了の定義」と「逃げ場のないチェック」を渡すだけ で組めます。

ここでは、コーディングタスクを「直線」ではなく「ループ」として回す最小構成を、3 つのファイルで作ります。

なお、ここからはご自身のプロジェクトで試す前提で話を進めます。
想定しているのは、ReactもしくはNext.js、TypeScriptで書かれたプロジェクトです。

① CLAUDE.md に「ループ協議」を書く（＝完了の再定義）

プロジェクト直下の CLAUDE.md に、タスクの回し方そのものを書きます。
ポイントは 「完了」を勝手に名乗らせない ことです

CLAUDE.md

## ループ協議

各タスクは「直線」ではなく「ループ」として走らせる:

1. 変更を書く
2. チェックを走らせる: テスト + linter + 型チェック
3. 失敗した? エラーを読み、原因を特定し、直して、2 に戻る
4. ループは最大 5 回まで

停止条件:
- 全チェック通過 → 「完了」と報告。通過した出力を証拠として添える
- 5 回使い切った → 止まって、何が残っているか報告する
- 同じエラーが 2 回連続 → ループを止め、@fixer を呼ぶよう促す

禁止: チェック出力なしで「完了」と報告すること
禁止: アサーション削除やテスト弱体化で通すこと。直すのはコードで、スコアボードではない

最後の2つの「禁止」が、実はこの設定の中でいちばん効いています。
これを入れずに回したところ、Claudeが3周目でアサーションを1行こっそり消してテストを通してきたことがありました。
テストは通る、でもバグは残ったまま。しかも、いたって自然に。評価基準(停止条件)を曖昧にすると、ループは平気でズルをします

② .claude/settings.json にフックを置く

CLAUDE.mdに規約を書いても、Claudeは途中で忘れる可能性があります。
そこでsettings.jsonのフックを「硬い制約」として置きます。
Claudeが止まろうとするたびに、システムが強制的にチェックを走らせて、結果を会話に押し戻す仕組みです。

.claude/settings.json

{
  "hooks": {
    "Stop": [{ "hooks": [{ "type": "command", "command": "npm test --silent 2>&1 | tail -20" }] }],
    "PostToolUse": [{ "matcher": "Write|Edit", "hooks": [{ "type": "command", "command": "npx tsc --noEmit --pretty false 2>&1 | head -10" }] }]
  }
}

• PostToolUse：ファイルを編集するたびに型チェック。書きながら即座に直させる
• Stop：Claude が「完了」と言おうとした瞬間に、フルのテストを走らせる。失敗したら出力がそのまま会話に入り、強制的にもう 1 周

これがさっき出てきた 「/goal の正体＝ Stop フック」 の自前版です。
Stop フックが「ダメと言える評価役」を担当していて、ここが通らない限りループは終われません。
Python なら pytest -q + pyright、Rust なら cargo test --quiet + cargo check に差し替えるだけです

③ .claude/agents/fixer.md（行き詰まりを別コンテキストで打破）

同じ会話の中では直せない問題もあります。すでに 4 回試して、コンテキストが失敗ログだらけになり、思考がロックされている状態です。
こういうときは まっさらなコンテキストの別エージェント に渡します。

.claude/agents/fixer.md

---
name: fixer
description: 同じテストが 2 回の修正試行後も失敗したときに使う、行き詰まり打破用エージェント
tools: Read, Edit, Grep, Glob, Bash
model: opus
---

あなたは失敗したチェックを直す。推測は禁止。

1. 失敗したチェックを自分で実行し、エラー全文を読む
2. 失敗パス上のファイルを、頭から終わりまで全部読む
3. 一文で書く: 本当の原因は何か
4. その原因だけ直す。ついでのリファクタはしない
5. チェックを再実行し、修正前後の出力を報告する

禁止: テスト削除、アサーション緩和、try/catch でのエラー握りつぶし、テストの skip 化

メインの会話から呼ばれ、直前の 4 回の失敗の記憶を持たないまま ゼロから診断するので、一発で通ることがよくあります。
これは 6 つのパーツの Sub-agents（生成役と評価役の分離） そのものです。

組み上げると

CLAUDE.md に協議、.claude/settings.json にフック、.claude/agents/fixer.md に fixer。この 3 つを置いて、Claude に実タスクを渡すだけです。

組み終わると、ターミナルのエラーをコピペして貼り直す作業が消えます。
Claude が自分で走らせ、自分で見て、自分で直し、詰まったら fixer を呼ぶ。

あなたは最後に diff を一度見るだけ

自分で開発するなら — Mastra

ここまでの Claude Code は、新しいフレームワークも要らず 手元ですぐ試せる 入口でした。ここからは 自分のサービスやツールにループを組み込んで開発する 側の話に移ります。

Mastraゴール機能

ループの骨格をゼロから書かなくても、さきほどの /goal（条件成立まで回し、完了は別モデルが判定）に相当する Goals 機能がフレームワークに組み込まれています。
Goals は「立ちっぱなしの目標」をスレッドに持たせ、毎周回ごとに別の判定役（judge）モデルが採点し、達成 or 上限到達まで回し続けます。

src/mastra/worker.ts

import { Agent } from '@mastra/core/agent';

const worker = new Agent({
  name: 'worker',
  instructions: 'ソフトウェアタスクを最後までやり切る',
  model: 'openai/gpt-5.5',
  memory, // storage を繋いだ memory が前提
  goal: {
    judge: 'openai/gpt-5-mini', // 作業役とは別の“判定役”モデル
    maxRuns: 30,                // 空回りの上限（＝コストの天井）
    prompt: 'テストが通ったときだけ完了とみなす',
  },
});

// スレッドに対する“立ちっぱなしの目標”をセット（リロードしても残る）
await worker.setObjective('/health エンドポイントを追加してテストする', {
  threadId,
  resourceId,
});

judge（作業役と別モデルで採点）と maxRuns（空回りの上限＝コストの天井）の 2 つが効きどころです。Claude Code の /goal でやっていたことが、設定 2 つにそのまま落ちています

Goals は比較的新しい experimental な機能（@mastra/core@1.42.0 追加）で、公式も「将来変わる可能性あり」と明言しています。最新の引数は公式ドキュメントを確認してください。停止条件が コードで True/False を出せる決定的なもの なら、ワークフローの .dountil() を使う手もあります。

回しっぱなしの代価

便利な反面、ループは 放っておくと静かにツケを溜める 側面があります。

A loop running unattended is also a loop making mistakes unattended.（誰も見ていないループは、誰も見ていないまま間違え続けるループでもある）

ざっくり 4 つです。

落とし穴	症状	一言の防ぎ方
検証の積み残し	成果物は溜まるが誰もチェックしていない	作業役とは別の評価役を入れる（＝ Stop フック）
理解の劣化	コードは増えるのに、頭の中の地図が古いまま	定期的にアウトプットを読み、自分で説明できるか確かめる
判断の放棄	ループが回ると、人が「まあいいか」で意見を持たなくなる	実行は任せても、判断は手放さない
トークン暴走	使用量が乱高下し、請求額が読めない	本番投入前に予算・最大再試行回数の上限を決めておく

特に トークン暴走 は文字どおりお金の話です。
1 つのバグで一晩中空回りすると、朝起きたら直ったコードではなく 見慣れない請求書 が待っている、なんてことが起こり得ます

省コストというより 事故防止のため に、本番投入前に必ずハード上限（1 回の予算・1 日の予算・最大再試行回数）を決めておきましょう。さっきの CLAUDE.md の「最大 5 回」「同じエラー 2 回で即停止」も、まさにこの上限の一種です。

最後に — 実はこの記事も、ループで書きました

ここまで「ループはこう作る」という話をしてきましたが、最後にひとつ種明かしを

この記事自体、ここで説明したループに書かせています。 構成はまさに 6 パーツのミニマム版でした。

• 指示書 PROMPT.md（何を書くか・文体・参照先）＝ 発見
• 本文を書く私（生成役） が節ごとに下書き ＝ 受け渡し
• 評価役のサブエージェント 3 体 ＝ 検証
  • 文体チェック役（Sonnet）：私の過去記事に近い文体・構成か
  • コード検証役（Haiku）：載せたコードが実際に動くか
  • 出典チェック役（Haiku）：用語のハルシネーション確認
• MEMORY.md に調査メモと判断を記録 ＝ 記憶
• ゴール（停止条件）は 「3 体の評価役が全部 OK」、主ゲートは文体チェック役の「過去記事に十分近いか」

正直に書くと、この評価役たちにはかなり詰められました。コード検証役に「Mastra のサンプルはここ要確認」、文体チェック役に「過去記事より用語が硬い」、極めつけは出典チェック役に 「その用語、参照元に無い。勝手に作った名前では？」とハルシネーションを指摘 されて、何周も直しています まさに CLAUDE.md の「禁止: スコアボードをいじるな」を、私自身がやられた格好です。

そして、いちばん実感したのがこれです。Addy の締めの一文が刺さりました。

Build the loop. But build it like someone who intends to stay the engineer, not just the person who presses go.

ループは作れ。ただし “起動ボタンを押すだけの人” ではなく、“エンジニアであり続けるつもりの人” として作れ。

ループは生成を無限に安くしますが、「どの方向で書くか・どの産出を止めるか」を決める判断 だけは肩代わりしてくれません。この記事も、評価役の配線（エンジニアリング）より、「どんな記事が良いか」という物差しを CLAUDE.md に書いて評価役に渡した 部分がいちばん効きました。

器はエンジニアリングで作れても、そこに込める良し悪しの基準は、結局やってきた人間の中にしかないんですね

気になった方は、まず難しく考えず、この記事の入門どおり CLAUDE.md に「ループ協議」と Stop フックを置いて、実タスクを 1 つ渡してみる のがおすすめです。

「あ、こういうことか」と、たぶんすぐ腹落ちします