ループエンジニアリングとは何か：「プロンプトを書く」から「ループを設計する」へ¶

-- AIエージェントを自走させる仕組みは、検証と停止条件で決まる

対象 / ポイント

対象: Claude Code や Codex を使い、単発プロンプトの先にある自律実行・定期実行・エージェント運用を設計したい開発者・技術リード。

ポイント:

ループエンジニアリングは、人間が都度プロンプトを打つ代わりに、AIエージェントを動かし続ける仕組みを設計する考え方だ。
2026年6月、Peter Steinberger氏のXポストを発端に、Addy Osmani氏が5つの構成要素とメモリとして体系化した。
本体は自律化ではなく、検証、停止条件、Human in the Loop の設計にある。

2026年6月8日、Peter Steinberger氏の2文のXポストがAIコーディング界隈に広がった。趣旨は端的だ。コーディングエージェントに人間が毎回プロンプトを打つのではなく、エージェントにプロンプトを与える「ループ」を設計するべきだ、という主張である¹。

この記事の問いは一つだ。 ループエンジニアリングとは何を設計する仕事で、なぜ検証と停止条件が中心になるのか。

発端は2文のポストだった¶

発端は短かったが、反応は大きかった。 ExplainXは、このポストが650万ビューに達し、AIコーディング界隈で大きく議論されたと報じている²。同じ文脈で、Claude Codeを率いるBoris Cherny氏も、Claudeへ直接プロンプトを打つのではなく、Claudeに指示を出して次にやることを決めるループを書いている、と語った³。

この流れを「Loop Engineering」として体系化したのが、GoogleのエンジニアであるAddy Osmani氏の記事である⁴。同記事は、ループを「人間がプロンプトを打つ席に、小さなシステムを置くこと」として説明する。日本でも公開直後から解説記事や実践レポートが出ており、用語として急速に定着しつつある⁵⁶。

ここで重要なのは、流行語としての新しさではない。人間が会話のたびに判断していた「次に何をするか」を、どこまで仕組みに移すかが問われている。

定義：プロンプトを打つ人間を仕組みに置き換える¶

ループエンジニアリングの中核は、役割の交代だ。これまで人間は、エージェントに指示を打ち、返答を読み、次の指示を打つ往復の中に常にいた。ループエンジニアリングでは、その席に小さなシステムを置く。

Osmani氏は、ループを「再帰的なゴール」として説明している⁴。目的を一度定義すれば、AIが完了まで反復する。仕事を見つけ、割り振り、結果を検査し、終わったことを記録し、次にやることを決める。この一巡をシステム側が回し、人間の代わりにエージェントを動かし続ける。

国内の実践者は、ループを6つの設計要素に分解している⁶。

要素	設計上の問い
Trigger	何をきっかけに動くか。定期実行か、イベント駆動か
Context	どの情報を渡すか
Action	何を実行するか
Verification	成功をどう確認するか
Memory	結果と学びをどこに残すか
Escalation	AIだけで判断できないとき、どう人間に戻すか

「いい感じに処理して」と頼むだけではループにならない。成功条件と停止条件まで設計して初めて、エージェントは安全に反復できる。

系譜：プロンプト、コンテキスト、ハーネス、ループ¶

ループエンジニアリングは突然変異ではない。ここ数年で、設計対象は単発の文面から、モデルの外側にある実行環境へ広がってきた。

国内の解説では、次の階段として整理されている⁵。

レイヤー	時期	設計対象
プロンプトエンジニアリング	2024年ごろまで	1回のやり取りの質
コンテキストエンジニアリング	2025年	モデルが見るトークン全体
ハーネスエンジニアリング	2026年前半	1つのエージェントが走る実行環境
ループエンジニアリング	2026年6月以降	ハーネスを定期・自律的に駆動する仕組み

Osmani氏も、ループはハーネスの一階層上にあると述べている⁴。ハーネスが「動く主体の外側に置かれた制御構造」だとすれば、ループはそのハーネスにタイマー、補助エージェント、状態管理を足したものだ。レイヤーが置き換わるのではなく、積み上がっている。

ここまで来ると、論点は「良いプロンプト」から離れる。問われるのは、どの条件で起動し、何を見て、何を変え、何をもって止まるかである。

ただの定期実行ではない¶

ループには定期実行が含まれる。 5分ごと、1時間ごと、毎朝1回のように、Claude CodeやCodexを起動する発想はループの一部だ⁶。ただし、それだけでは説明しきれない。

トリガーは時刻に限らない。 Slackのメッセージ、Gmailの着信、GitHubのPR更新、Stripeの決済イベントを起点にしてAIが動く構成もループの範疇に入る⁶。 Claude Code公式ドキュメントでも、/loop、cron形式のスケジュール、クラウドルーチン、デスクトップのスケジュールタスクが整理されている⁷。 Codex側にも、プロジェクト、プロンプト、実行頻度、実行環境を選ぶ Automations が用意されている⁸。

定期実行との決定的な違いは、停止条件だ。 Claude Codeの/goalは、条件が満たされるまでターンを継続し、各ターン後に小さな高速モデルが完了条件を判定する⁹。 Codexにも同名の/goalがあり、検証可能な停止条件に向けて複数ターンを継続する用途として説明されている¹⁰。

ループを信頼できるかどうかは、ここで決まる。「Noと言える何か」、つまりテスト、型チェック、本物のエラー、レビューキュー、予算上限をループの中に入れられるかが境目になる²。

構成要素は5つとメモリ¶

Osmani氏は、ループに必要な部品を5つとメモリに整理している⁴。注目すべきは、1年前なら自前のbashスクリプト群だったものが、CodexとClaude Codeの標準機能に近づいている点だ。

部品	ループ内での役割	Codex	Claude Code
Automations	定期発火による発見とトリアージ	Automations、`/goal`	スケジュールタスク、`/loop`、`/goal`、hooks
Worktrees	並列エージェントの作業隔離	組み込み worktree	`git worktree`、`--worktree`、subagentの`isolation: worktree`
Skills	プロジェクト知識の文書化	Agent Skills (`SKILL.md`)	Skills (`SKILL.md`)
Plugins / Connectors	外部ツールとの接続	MCPベースのConnectorsとPlugins	MCPサーバーとPlugins
Sub-agents	作る者と検証する者の分離	`.codex/agents/`のTOML定義	`.claude/agents/`、agent teams

6つ目がメモリである。 Markdownファイルでも、Linearのボードでもよい。会話の外に残り、「何が終わり、何が次か」を保持する場所だ。モデルは実行のたびに多くを忘れるため、記憶は会話ではなくディスクや外部システムに置く必要がある⁴。

この中で特に重要なのがSub-agentsだ。 Codexは、専用エージェントを.codex/agents/のTOMLとして定義できる¹¹。 Claude Codeは、.claude/agents/にMarkdown frontmatter付きのサブエージェントを置ける¹²。どちらも、作る者と検査する者を分けるための部品になる。

コードを書いたモデルは、自分の成果物の採点に甘くなりやすい。別の指示、別の権限、場合によっては別のモデルを持つ検証エージェントが、第一のエージェントが見落とした欠陥を拾う。無人で回るループほど、この分離が効く。

1本のループが朝に回るとき¶

部品を組み上げると、ループは一つの作業装置になる。 Osmani氏が示した例では、毎朝のオートメーションがリポジトリの状態を読み、CI失敗、オープンIssue、直近コミットをトリアージする⁴。着手する価値のある項目は状態ファイルやチケットに書き出され、項目ごとにworktreeが切られる。

その後、サブエージェントが修正案を作る。別のサブエージェントが、プロジェクトのスキルと既存テストに照らして検証する。コネクタがPRを開き、チケットを更新する。判断できないものは受信箱に残り、人間を待つ。

この流れの中で、人間は都度プロンプトを打っていない。設計したのは一度だけだ。たとえば、毎朝7時にトリアージ・ループを起動するだけなら、概念的には次の1行に収まる。

0 7 * * * claude -p "$(cat triage-loop.md)" >> loop-state.log

ただし、この1行は心臓の鼓動にすぎない。実運用の本体は、権限、ログ、検証、停止条件、ガードレールである。

129件の成功と43コミットの暴走¶

国内では、すでに実運用レポートが出ている。 MAKE A CHANGE社は、Slack監視からNotionタスク登録、Notionタスクの自動実行、AI情報収集まで、複数のループを常時運用している⁶。

成功例は明快だ。リモートリポジトリを監視して不要ブランチを削除するループは、129件の不要ブランチを自動削除した⁶。読み取り、判断、削除対象の条件が比較的明確だったことが効いている。

一方、PRを監視して自己改善するループは暴走した。 1日で43件のコミットを生成したが、途中から修正範囲が膨張し、本来のPRの趣旨から逸脱した。結果として、生成物のほぼすべてが却下された⁶。

この事例の教訓は、3点に集約できる。

ループの設計を誤ると、無駄な成果物を高速で大量生産する。
トークン消費が増え、コストが膨らむ。
完了条件、検証方法、Human in the Loop がないループは運用に乗らない。

ループの能力と被害の規模は比例する。「自動化できたか」より先に、「どこで止まるか」を決める必要がある。

ループが肩代わりしないもの¶

Osmani氏は、ループが良くなるほど鋭くなる問題を3つ挙げている⁴。

第一に、検証は依然として人間の仕事である。無人で走るループは、無人でミスをするループでもある。検証エージェントを分離しても、ループが言う「done」は主張であって証明ではない。

第二に、理解の腐敗である。自分が書いていないコードが速く出荷されるほど、「存在するもの」と「自分が理解しているもの」の差が開く。滑らかなループは、読まなければこの負債を加速させる。

第三に、認知の明け渡しである。ループが回り始めると、意見を持つことをやめ、出てきたものをそのまま受け取りたくなる。同じループでも、深く理解した仕事を加速する人と、理解を避けるために使う人では結果が変わる。

だから、ループ設計はプロンプトエンジニアリングより簡単になったのではない。レバレッジの効く場所が、プロンプトの文面から、検証可能な仕事の設計へ移っただけだ。

企業導入で見るべき論点¶

個人開発では、まず回してみることに価値がある。企業環境では、無人でコミットし、PRを開き、チケットを更新する主体が増える。それは変更管理の対象が増えるという意味でもある。

導入時の論点は、少なくとも4つある。

変更管理との接続: 無人ループによる変更は、CI/CDパイプラインと同様に監査証跡と承認フローの対象になる。
権限の分離: ループに人間のクレデンシャルを使い回さず、サービスアカウント、最小権限、集中ログを前提にする。
合意の文書化: ループが毎回読むSKILL.mdやAGENTS.mdは、実質的にチームの合意文書になる。
段階的な導入: 読み取り専用ループから始め、Noと言える検証を備えてから書き込み権限を与える。

Verificationを欠いたループは、企業環境では単なる非効率ではない。監査不能な変更、予算超過、意図しない大量コミットを生むインシデント源になる。

まとめ：ループを作る前に、責任を置く¶

ループエンジニアリングは、プロンプト、コンテキスト、ハーネスの上に積み上がった、2026年6月時点の新しい設計レイヤーである。人間の役割は、エージェントに指示を打つ人から、エージェントを駆動する仕組みの設計者へ移る。

ただし、これは省力化だけの話ではない。検証と停止条件を設計する責任、出力を読んで理解を維持する責任は、むしろ重くなる。 Automations、Worktrees、Skills、Connectors、Sub-agentsという部品は揃いつつある。

最後に残るのは、運用者の規律だ。ループを作ること自体は難しくなくなった。難しいのは、作ったループに対して人間が何の責任を持ち続けるかを、先に決めておくことである。