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 のような永続メディアを、チャット駆動の一時的な作業とどう接続するか。

11 KiB Raw Permalink Blame History

Loop Engineering

設計上の要点

Failure Modes

Open Questions

11 KiB

Raw Permalink Blame History