Core Message

Loop Engineering は「良いプロンプト」ではなく「仕事が回る仕組み」を設計する話。

人間が毎回エージェントに指示するのではなく、発見、割り当て、実行、検証、記録、次アクションまでを小さなループとして組み立てる。

automation worktree skills connectors verification memory/state
Origin

言葉として広めたのは Addy Osmani。背景には Peter Steinberger と Boris Cherny の発言がある。

1

Addy Osmani

2026年6月7日の記事で「Loop Engineering」として整理。人間がプロンプト係でいる代わりに、プロンプトする仕組みを設計する、と説明している。

2

Peter Steinberger

「coding agent に毎回プロンプトするより、agent にプロンプトする loop を設計する」という趣旨の投稿が、用語の火種になった。

3

Boris Cherny

Claude Code の文脈で、自分の仕事は Claude へ直接プロンプトすることではなく loop を書くこと、という趣旨の発言が引用されている。

注: 現時点では厳密な学術用語というより、実践者コミュニティで共有され始めた運用概念として扱うのが安全。

Shift

Prompt Engineering との違い

Prompt Engineering

  • 人間が毎回、入力文を工夫する
  • 会話ごとに文脈を渡し直す
  • 出力を読んで、次の指示を書く
  • 成果はその場の対話品質に依存しやすい

Loop Engineering

  • 仕事の発見から検証までの反復を設計する
  • 記憶、権限、ツール接続、停止条件を外側に置く
  • 複数エージェントや worktree で並列化する
  • 成果は loop の設計品質と検証品質に依存する
Anatomy

Loop は、だいたいこの6部品でできている。

1Scheduleいつ起動するか。毎朝、CI失敗時、Issue追加時など。
2Discovery何を見るか。Issue、PR、ログ、顧客要望、監視など。
3Act何をするか。修正、要約、調査、ドラフト、PR作成。
4Isolate作業を分ける。worktree、権限、環境、サンドボックス。
5Verify完了条件を判定する。テスト、lint、別エージェントレビュー。
6Persist状態を残す。Markdown、Issue、Linear、ログ、KB。
Example

例: 毎朝、Issue から修正候補を拾って PR の手前まで進める。

Loop の流れ

  • 朝に GitHub Issues と CI 失敗を確認
  • 小さく直せそうな候補を選ぶ
  • 別 worktree で実装エージェントが修正
  • レビューエージェントがテスト、差分、仕様を確認
  • 通ったものだけ PR 化し、状態を記録

人間の役割

  • 最初に loop の権限と停止条件を決める
  • 失敗した候補、判断が必要な候補だけ見る
  • 最終的な品質責任は人間が持つ
  • うまくいった手順を skill や plugin に昇格する
Adoption

いきなり完全自動化しない。まずは「読むだけ loop」から始める。

A

Read-only loop

定期的に情報を集め、候補を出すだけ。外部送信、PR作成、書き込みはしない。

B

Draft loop

下書き、修正案、PR本文、調査メモまで作る。人間が採用判断する。

C

Action loop

検証済みの範囲だけ、PR作成やチケット更新まで実行する。権限境界を明確にする。

Risks

Loop は楽にするが、責任は消さない。

失敗も自動化される

検証条件が弱い loop は、間違いを高速に積み上げる。停止条件、予算、権限を先に決める。

理解の負債が増える

自分が読んでいないコードや判断が増えるほど、後から直すコストが上がる。

監査できる記録が必要

何を見て、何を変え、何で完了としたか。loop の外に状態を残さないと運用できない。

設計対象は「プロンプト」から「仕事の循環」へ移った。ただし、最後に品質を引き受けるのは人間のまま。

社内説明向けの要約
Sources

主な外部ソース

Peter 発言

Peter Steinberger の X 投稿。Addy 記事内で「agent にプロンプトする loop を設計する」趣旨の発言として参照。

このページは公開共有を前提に、非公開チャット本文や内部ログは掲載していません。