ループ・エンジニアリングを場面から考える

ループ・エンジニアリングは、Agent のターン数を増やすことではない。人が Agent に繰り返し尋ねる作業を、仕事を見つけ、割り当て、結果を検証し、状態を記録し、次を決めるエンジニアリングシステムへ変えることである。このサイトオリジナルの実践章は Addy Osmani の Loop Engineering 解説 に着想を得ているが、以下のループ、テンプレート、ゲートは AI FDE の実際の交付に向けたものだ。

最初に確認する：この作業は Loop に値するか

「Agent を自律化する」ことから始めない。反復的、観測可能、検証可能、エスカレーション可能なタスクから始める。最初の良い Loop には四つの性質がある。

• CI 失敗、SLA 超過チケット、保留中のセキュリティ警告など、明確なシグナルがある。
• 一つの再現可能なテスト修正、提案生成、ドラフト PR 作成など、行動範囲が限定されている。
• 指定テスト、lint、リスク確認など、完了条件を検査できる。
• 安全に処理できない仕事には、明示的な停止と人へのエスカレーション経路がある。

これらが欠けるなら、先にワークフローと受入基準を定義する。長いプロンプトでは不確実性を消せない。

信頼できる Loop の六つの部品

1. 自動発見とトリアージ：一定の周期でシグナルを集め、影響、緊急度、責任者を付ける。
2. 隔離された作業空間：並列修復ごとに独立したブランチと worktree を与え、Agent 同士の上書きを防ぐ。
3. プロジェクト Skill：ビルドコマンド、規約、リリース制限、障害の教訓を Skill に保存し、毎回の会話で説明し直さない。
4. 実ツールへの接続：管理された connector でチケット、状態、CI を読む。権限、監査、確認がそろう場合だけ外部システムへ書き込む。
5. 実装者と確認者の分離：一方の Agent が変更を提案または実装し、別の Agent/チェッカーが仕様、テスト、リスク規則で判定する。
6. 会話外の永続状態：完了した仕事、試した方法、検証出力、阻害要因、次の行動をリポジトリのファイルまたはタスクシステムへ残す。

参照設計：毎日の CI 修復 Loop

これは一つの巨大 Agent ではなく、制御面として扱う。各段階に監査可能な証拠を残す。

定期トリガー → CI 失敗と最近の変更を読む → 状態へトリアージ
      → 安全な項目に隔離 worktree を作る → 実装 Agent が修復候補を出す
      → 独立チェッカーが受入コマンドとリスク確認を実行
      → 合格：PR 作成 / チケット更新、不合格：理由を記録し縮退または人へエスカレーション

初版では自動マージしない。正しい仕事を見つけ、小さく修復し、完全な証拠を残し、安全に止まれることを先に証明する。その後で自律性を上げる。

状態はログではない。次の判断への入力である

小さなリポジトリファイルから始められる。

# Loop state
- finding: CI / auth-smoke / run-184
  owner: platform-oncall
  hypothesis: staging secret is missing
  attempted: added a scoped secret check
  verification: auth-smoke passed; security review pending
  next: open draft PR after reviewer approval
  stop: do not deploy automatically

有用な状態は、次の実行が必要とする情報だけを持つ。無限の会話や、モデルの推測を事実として保存しない。各実行で、何が起きたか、どの証拠で判断したか、次を誰が持つかを更新する。

受入、停止、エスカレーションで「完了」に意味を持たせる

信頼できる停止条件は四つの問いに答える。

• 何が通過か。 指定テスト、lint、依存関係スキャン、独立レビュー。
• 予算はいくらか。 タスクごとの反復、時間、Token 上限。
• いつ継続してはならないか。 権限不足、本番データへの影響、機密情報、失敗理由を説明できない検証器。
• 最終権限者は誰か。 高影響の変更、マージ、デプロイにはリスクに見合う人の承認ゲートが必要である。

検証器の通過はチームの判断を不要にしない。Loop は反復作業を減らせるが、コード、アーキテクチャ、受容するリスクの理解を置き換えられない。

Loop が本当に改善しているかを測る

• 交付品質：独立検証済み成功率、回帰、エラー分類。
• 運用負担：人へのエスカレーション率、平均解決時間、繰り返しアラート率。
• 経済性：リクエスト単価ではなく、成功成果あたりの Token とツール費用。
• 理解とガバナンス：責任者は最新変更、なぜ自動実行を許すか、いつ止まるかを説明できるか。

誰も変更を理解できないまま成功率だけが上がる場合や、高価値タスクの完了率を下げてコストだけが下がる場合、その Loop は重要な意味で改善していない。

30 分の練習：最初の Loop を設計する

週に一度以上起きる低リスクなエンジニアリングシグナルを一つ選ぶ。次の順で一枚に書く。

1. トリガーと放置した場合のコスト。
2. 許可する最小行動と、明示的に禁止する行動。
3. 受入コマンド、失敗分類、停止予算。
4. 実装者、独立確認者、人へのエスカレーション責任者。
5. 状態フィールドを作り、まず読み取り専用の発見とトリアージを一回実行する。

この Loop がチームの次の判断を良くすることを先に証明する。その土台が安定してから、書き込み、並列化、自動マージを追加する。