2026年2月、社内の標準に自律的な精製ループを実装し、半年近く経ってから利用実績がゼロであることを実測して削除しました。残したのは上限つきリトライ、約20行です。
その4か月後にあたる2026年6月7日に、Addy Osmani が同種の設計を「Loop Engineering」と名付けました。用語ができる前に作って、用語ができた後に畳んだことになります。
一発で回る形は2月に完成していた
ここで言う標準は公開しているので、以下の日付はすべて履歴から追えます。
GitHubGitHub - LabeeHive/standards: Shared standards repository for Labee LLC projects — a Claude Code plugin marketplace of skills, agents, and workflowsShared standards repository for Labee LLC projects — a Claude Code plugin marketplace of skills, agents, and workflows - LabeeHive/standardsこの中に、Swiftの開発をタスクから完了まで通す swift-workflow というスキルがあります。成立した日がはっきりしています。
| 日付 | 入ったもの |
|---|---|
| 2026-02-03 | スキルの新設。同じ日にビルドとテストの段、フェーズ追跡 |
| 2026-02-15 | 並列レビューゲートの必須化 |
| 2026-05-25 | 関連タスク調査の段を必須化 |
| 2026-06-07 | （外部）Loop Engineering の命名 |
「実装して」と一度言えば、タスクを特定し、記憶しているAPIを公式ドキュメントで確かめ、複数のスキルを呼び分けて実装し、レビュアーを2体立てて承認を待ち、ビルドとテストを回し、翻訳を更新してコミットメッセージまで作る。ここまでが2026年2月15日です。関連する既存タスクと設計文書を先に読む段が必須になったのは、3か月後の5月25日でした。
ただし、これはループではない
自律度は高い一方で、形はループではありません。フェーズが固定順に並んだパイプラインで、途中にブロッキングゲートが1つ挟まっているだけです。収束するまで反復する構造を持っていません。
この区別はAnthropicの整理が厳密です。workflow は「LLMとツールがあらかじめ定義されたコードパスで組み立てられるシステム」、agent は「LLMが自分の進め方とツールの使い方を動的に決めるシステム」。この定義だと、フェーズが固定されたものは前者です。
同じ記事は、どちらを選ぶかについてもこう書いています（訳は筆者）。
より複雑なものが正当化される場合、明確に定義されたタスクに対して、workflowは予測可能性と一貫性をもたらす。agentが優るのは、柔軟性とモデル主導の判断が規模を伴って必要になる場合である LLMでアプリケーションを組むときは、できるかぎり単純な解を見つけ、必要になったときにだけ複雑さを足すことを勧める
パイプライン型は、ループの劣化版ではありません。単純なほうから始めて必要なだけ足す、という原則に従った結果です。
消した理由は、使われていなかったから
本物の反復ループのほうは、2026年2月3日に実装しています。実行→検証→診断→修正→再検証→学習の6段で、参照したのは Reflexion や Self-Refine といった当時の研究でした。停止条件も具体的です。最大3回、同じエラーが2回続いたら停止、未知のエラー分類なら停止してユーザーに聞く。アンチパターンとして無限ループ・盲目的リトライ・沈黙する失敗も挙げています。
削除は2026年7月26日でした。そのコミットの本文が身も蓋もありません（原文は英語、訳は筆者）。
自律精製ループには利用者がいなかった。文書とスクリプトで30,249文字あり、これはスキル全体の34%にあたるが、リポジトリのどこからも呼ばれていなかった。「ARL対応」と書かれた唯一のスキルも、ラベルを持っていただけだった。
構想が先行して実体が伴わなかった、という記録です。半年分の実測を根拠に3分の1を捨てています。
残した上限つきリトライは、3条件がよく整理されています。判断ではなくコマンドで検証すること、ハードな上限を置くこと、そして同じ項目が2回続けて落ちたら3回目を試さずに報告すること。3回目を試さない理由は、繰り返し落ちるなら修正の方針が間違っているのであって、運が悪いのではないからです。
外から見ると、この判断は妥当だったようです。AlphaSignal はループが元を取れる条件を4つ挙げ、「1つでも欠けるとループは戻りより高くつく」と書いています。反復頻度、客観的に不合格を出せる自動検証、リトライを吸収できるトークン予算、シニア級のツール。条件が揃っていなければ畳むのが正解になります。
批判の焦点は反復回数ではない
用語ができてから2か月、批判側の議論を追うと、意外なことが分かりました。争点になっているのは反復の有無ではありません。
- 提唱者自身が「そのコードを書いたモデルは、自分の宿題を採点するには甘すぎる」と書いている
- Prefect は「エージェントが自分の進捗を自己申告する構造は、まともな規模で破綻する」と指摘する
- Isaac Hagoel は「実装は終えるが実地の検証を飛ばして、早すぎる完了宣言をする」と書く
全員が同じところを指しています。誰が完了を宣言するかです。反復を何回するかではありません。
実装として意見が割れうるのは1点です。検証役に書き込み権限を与えるかどうか。保守側は明確に「与えない」を推していて、Augment Code は検証エージェントを読み取り系のツールだけに制限し、MakerChecker は不可逆な操作を提案したエージェントが自分の承認者になることを、プロンプトの約束ではなくHTTPの403で拒否します。
ブログコードベースの定期グルーミングをAIに任せるPRのレビューで担保しきれずに漏れるものを拾うため、週次でコードベースを走査するだけのサブエージェントを立てています。修正はさせず検知と報告に限り、報告はレビュー側で裏を取る運用を1か月ほど回した記録です。人に残したのは判断ではなく不可逆な操作
自分たちの形を、この軸に当て直すとこうなります。
自律度は上げました。上げなかったのは反復です。増やしたのは検証の段数のほうで、数値の検査、描画結果の確認、実際の導線での再現、レビュアー2体の承認と、通過しなければ先へ進まない関門を並べています。
そして人間に残した操作は2つだけです。コミットすることと、タスクを完了にすること。どちらも判断が難しいから残したのではなく、取り返しがつかないから残しています。判断が要る部分は、むしろ機械とエージェントに寄せました。
これは偶然そうなったのではなく、批判側の懸念と同じところに着地しています。エージェントの自己申告を信じない、検証役に修正させない、通らなければ止める。3つとも、失敗を先に踏んでから入れたものです。
ブログ「保存した」は検証ではないエージェントに作らせた画面の見た目を、数値ゲート・オフスクリーンのPNG・実際の導線の三段で確認しています。撮影までは自動化できても、撮った絵を見て判断する行為だけは自動化できていません。 ブログレビュアーの判断は黙って失敗する検証の規約を明文化して3週間後、レビュー担当がそれを実行していなかったことが分かりました。答えは規約をもう1つ足すことではなく、検査を人の手から外して、通らなければマージを機械に拒否させることでした。用語を追っていなかった
正直に書いておくと、社内と個人の標準どちらにも「loop engineering」「context engineering」という語は1つも出てきません。提唱者の名前も出てきません。
用語を追って設計したのではなく、失敗を潰していたら形が寄った、という順序です。だから外の議論に照らして初めて、自分たちがどこに立っているかが分かりました。用語は自分の位置を測る道具として役に立ちます。設計を導く道具としては、少なくとも今回は使っていません。
残っている宿題もはっきりしました。上限つきリトライの一般則があるのは1スキルだけで、他は「落ちたら直して再実行」に上限がありません。同じ項目が2回落ちたら止める、という条件は全体に効くはずなので、そこから広げます。