--- title: Loop Engineering created: 2026-06-29 updated: 2026-07-01 type: concept tags: [agent, automation, workflow, quality] sources: [raw/articles/loop-engineering-anthropic-playbook-2026.md, raw/articles/github-issueops-state-machines-2026.md, raw/articles/horizon-agentic-hardware-design-2026.md, raw/articles/abtop-ai-coding-agent-monitor-2026.md, raw/articles/kiro-ide-1-0-agent-focus-2026.md, raw/articles/arena-ai-leaderboard-business-2026.md, raw/articles/pi-coding-agent-2025.md, raw/articles/github-desktop-3-6-worktrees-copilot-2026.md, raw/articles/agent-oriented-cli-zenn-2026.md, raw/articles/microsoft-learn-agent-architecture-sdlc-2026.md, raw/articles/google-adk-go-2-0-agent-workflows-2026.md, raw/articles/theregister-claude-code-transcript-retention-2026.md, raw/articles/awesome-harness-engineering-2026.md, raw/articles/mastra-typescript-agent-framework-2026.md, raw/articles/claude-code-telemetry-audit-2026.md, raw/articles/github-duplicate-issue-detection-mcp-fields-2026.md, raw/articles/langchain-openwiki-repo-documentation-agent-2026.md, raw/articles/github-copilot-ai-credit-session-limits-2026.md] confidence: medium --- # Loop Engineering Loop engineering は、LLM やエージェントを「人間が毎回プロンプトする道具」としてではなく、自分で次の仕事を見つけ、隔離された実行先へ渡し、別の評価者に検証させ、結果を永続化し、次回実行へつなぐループとして設計する考え方。PDF「Loop Engineering: The Anthropic Playbook for Designing Systems That Prompt Your Agents」は、prompt / context / harness engineering の上に来る第四層としてこの概念を置いている。 中心になる 1 ターンは、discovery、handoff、verification、persistence、scheduling の 5 段階。これは [[wiki-maintenance-loop]] の ingest / query / lint / log / cron にかなり近く、Discord link ingest のような自動キュレーションでは、リンク発見だけでなく評価基準、重複検出、raw 保存、wiki 更新、状態ファイル更新までを同じループの一部として扱う必要がある。 ## 設計上の要点 - **Generator / evaluator separation**: 生成したエージェント自身に採点させると甘くなりやすい。別プロンプト、別モデル、別プロセスの「疑う評価者」を置く方が、[[ai-assisted-reverse-engineering]] の命名・型付け検査や wiki ingest の品質判定にも応用しやすい。 - **Persistence first**: ループの成果はチャットの返答だけでなく、PR、Issue、wiki、state file、log のような再利用可能な場所に残す。残らない自動化は、次回の discovery と評価に使えない。 - **State machine として考える**: GitHub の IssueOps 記事は、Issue、label、comment、approval、Action を状態機械として扱う。これは loop engineering の persistence と scheduling を、監査可能な GitHub timeline に置く方法として読める。GitHub の duplicate issue detection と MCP server の issue fields 対応は、この面をさらに agent-friendly にする。重複検出は人間 maintainer の triage 負荷を下げ、MCP 経由の issue field 読み書きは agent が priority、area、date などを持つ構造化された state を作れるようにする。^[raw/articles/github-duplicate-issue-detection-mcp-fields-2026.md] - **Repository-native loop**: [[agentic-hardware-design]] の HORIZON は、Markdown harness から evaluator / acceptance predicate / git policy を持つ project pack を作り、隔離された worktree 上の diff・commit・log・notes をそのまま探索 trace にする。ループの状態を外部データベースに逃がさず、作業対象の repository 自体に残す設計として重要。 - **Operator observability**: [[abtop]] は Claude Code、Codex CLI、OpenCode の session、token、context、rate limit、child process、open port をローカルで可視化する。複数 agent を同時に回す loop では、成果物だけでなく「いま何が動いているか」「どの資源を占有しているか」も運用対象になる。 - **Agent-native work surface**: [[kiro]] の Agent Focus は、コード編集画面ではなく session、会話、spec、diff を前面に置く。loop を IDE の中に寄せると、人間の仕事は直接編集よりも、仕様・承認・差分確認・権限ルールの管理へ移る。 - **Agent harness minimalism**: [[pi-coding-agent]] は、read / write / edit / bash、tmux、明示的な session file など既存の可視な道具に寄せることで、隠れた sub-agent や巨大な system prompt に頼らない loop を作ろうとする。loop の強さは機能数だけでなく、operator が context、tool result、process、cost をどこまで観測できるかにも依存する。 - **Harness before loop**: [[agent-harness-engineering]] は、context、memory、guardrail、tool boundary、eval、observability を整え、1 回から数回の agent 実行を dependable にする層として読める。loop engineering はその上で discovery、handoff、persistence、scheduling をつなぐので、長期自動化の失敗は loop の設計だけでなく、その下の harness が曖昧なことからも起きる。^[raw/articles/awesome-harness-engineering-2026.md] - **Worktrees as everyday agent infrastructure**: GitHub Desktop 3.6 の worktree support は、agent が複数 branch / sandbox を使う流れを GUI 側にも取り込む。isolated worktree は [[agentic-hardware-design]] や IssueOps 的な repository-native loop と同じく、並列作業を見える単位に分けるための基礎部品になる。 - **Evaluator market pressure**: [[ai-evaluation-infrastructure]] の Arena 事例は、評価が研究用 leaderboard から商用分析・post-training 改善の基盤へ広がっていることを示す。loop engineering でも、実行する agent だけでなく、それを測る evaluator とデータ収集の設計が競争力になる。 - **Agent-oriented tools**: [[agent-oriented-cli-design]] は、JSON first、actionable error、search/read 分離、鮮度情報、少ないフラグを通じて、agent が推測せずに次の行動へ進める CLI を作る考え方。loop の実行単位である tool が曖昧だと、verification や persistence 以前に誤った状態で進んでしまう。 - **Workflow graph as agent**: [[google-adk]] Go 2.0 は、function / agent / tool / join / dynamic node を edge と route でつなぐ graph そのものを `agent.Agent` として実行する。pause/resume、human-in-the-loop、retry、branch isolation、telemetry を framework primitive にすることで、loop を ad-hoc prompt ではなく、状態を持つ観測可能な実行 graph として扱う方向を示している。^[raw/articles/google-adk-go-2-0-agent-workflows-2026.md] - **TypeScript workflow framework**: [[mastra]] は、model routing、agent、graph workflow、HITL suspend/resume、MCP server、eval、observability を TypeScript application stack にまとめる。[[google-adk]] が Go/Python の typed graph runtime 寄りなら、Mastra は web application に agent loop を組み込む入口として見られる。^[raw/articles/mastra-typescript-agent-framework-2026.md] - **Transcript retention is product behavior**: Claude Code の `cleanupPeriodDays` 既定値 30 日をめぐる The Register の報道は、agent loop の会話 transcript が単なる UI 履歴ではなく、設計判断、debugging context、研究上の reasoning trail そのものになりうることを示す。保存しすぎると source code や credential を含む privacy / security risk になる一方、削除が silent で recovery log もないと、operator は永続化されていると思った作業知識を失う。loop engineering では、保存期間、削除ログ、soft delete、backup、state file への要約などを明示的な設計対象にする必要がある。^[raw/articles/theregister-claude-code-transcript-retention-2026.md] - **Telemetry is part of the loop boundary**: [[ai-agent-telemetry-privacy]] は、agent loop の観測性が product/vendor telemetry とどこで重なるかを問う。trace や error stack は debugging に役立つが、repo hash、CI identity、stack frame、session ID が外部へ出るなら、loop の persistence / observability は retention と opt-out まで含めて設計する必要がある。^[raw/articles/claude-code-telemetry-audit-2026.md] - **Repo wiki as loop memory**: [[openwiki]] は、コードベースの理解を `openwiki/` に残し、`AGENTS.md` / `CLAUDE.md` からそこへ案内し、GitHub Actions で差分更新する。これは agent loop の working memory を一回の context window から外へ出し、repository に残る保守可能な知識面へ移す例として読める。^[raw/articles/langchain-openwiki-repo-documentation-agent-2026.md] - **Run budget as loop state**: Copilot CLI / SDK の AI credit session limit は、無人 run の cost を loop state として扱う例である。`--max-ai-credits` のような上限があると、agent は人間が見ていない間に無制限に subagent や compaction を回すのではなく、soft cap 到達時に wrap up して state を返す。これは scheduling と persistence だけでなく、run をいつ止めるかという operator contract でもある。^[raw/articles/github-copilot-ai-credit-session-limits-2026.md] - **Human judgment is scarce**: 生成は安くなっても、何を通し、何を止め、何を記録するかの判断は希少になる。自動化は人間の判断を消すのではなく、判断すべき点を狭く明確にするべき。 ## Failure Modes - **Nodding loop**: 自己承認しているだけで、独立した検証がない。 - **Amnesiac loop**: 前回の状態、失敗、採用・却下理由が保存されず、毎回同じ判断をやり直す。 - **Manual loop**: 実行自体が人間の思いつきに依存し、定期実行・イベント駆動になっていない。 - **Blind loop**: 何を探すか、何を高く評価するかが固定され、発見結果から rubric が改善されない。 - **Tangled loop**: 並列エージェントや自動 PR が同じ資源を同時に触り、検証や rollback が追いつかない。 ## Open Questions - Hermes の scheduled job では、どの変更を即時実行し、どの変更を review item として止めるべきか。 - [[ai-agent-identity-security]] のような認可・監査の標準を、個人用エージェントのローカル自動化にもどう縮小適用するか。 - IssueOps や [[llm-wiki-pattern]] のような永続メディアを、チャット駆動の一時的な作業とどう接続するか。