■ 1. 背景と概要
- Boris Cherny（Claude Code 責任者）の発言「もう Claude にプロンプトは出していない。Claude にプロンプトを出す『ループ』を走らせている」が本記事の起点
- Addy Osmani のブログ「Loop Engineering」、Peter Steinberger の連投を踏まえ、Loop Engineering の考え方を以下の3レイヤーで整理する
- ニュース要約
- 実装の中身
- チームへの導入時の注意点
■ 2. AIパラダイムの4世代変遷
- 世代ごとの特徴:
- 第1世代（2022-2024）: Prompt Engineering、1つの指示を磨き上げる、価値の源泉は指示の質
- 第2世代（2025）: Context Engineering、十分な情報・前提・例を与える、価値の源泉は文脈の質
- 第3世代（2026年初）: Harness Engineering、エージェントに馬具（ハーネス）を着ける、価値の源泉は実行環境の質
- 第4世代（2026年現在）: Loop Engineering、エージェントを自律稼働させるシステムを設計、価値の源泉はサイクルそのもの
- 前の世代が消えるわけではなく、Prompt・Context・Harness は Loop の部品として組み込まれる
■ 3. Loop Engineering の定義と Harness との違い
- 定義: 自分がエージェントを叩く役を辞め、エージェントを叩く役を機械にやらせること（Addy Osmani）
- 1つの Loop の基本構造:
- 人間が目的を定義する
- AI が完了まで反復する
- 次のラウンドが自動的に始まる
- Harness と Loop の違い:
- Harness Engineering: 単一エージェントを対象、実行環境レイヤー、人間がプロンプトで起動、エージェントが完了を宣言
- Loop Engineering: 複数エージェント＋スケジューラを対象、制御プレーンレイヤー、時刻・イベント・条件で自律起動、検証ゲートが合格を判定
- Harness は Loop の前提であり、Loop が Harness を置き換えるという話ではない
■ 4. Loop を構成する6つのコアモジュール
- Automations（ハートビート）:
- 定期的またはイベントをきっかけに自動起動し、タスクを拾い上げる
- CI 失敗・未処理 issue・最近のコミットに混入したバグなどを人間に代わって検出する
- Worktrees（防護壁）:
- 複数エージェントを並行で走らせるための分離レイヤー
- 各エージェントが独立した git ブランチを持ち、コンフリクト事故を防ぐ
- Codex と Claude Code はネイティブで対応している
- Skills（記憶チップ）:
- プロジェクトの仕様、ビルド手順、過去の意思決定を1ファイルに記録する
- Loop が起動するたびに読み込まれ、ゼロからの推論が不要になる
- Sub-agents（牽制メカニズム）:
- Explorer（コードベース調査・前提収集、高速モデル推奨）
- Implementer（実装案を起草、主力モデル推奨）
- Verifier（spec/test に照らし受け入れ判定、別モデル推奨）
- Verifier をあえて別モデルにすることで、盲点の見逃しを防ぐ
- Connectors（腕）:
- MCP（Model Context Protocol）経由で Linear・GitHub・データベース・Staging API・Slack などのツールと Loop を接続する
- 「提案」にとどまらず、PR の作成・チケット更新・Slack へのメンションまで自律的に実行する
- Memory（最も過小評価されている部品）:
- markdown ファイル、Linear のボード、会話の外にある状態記録を外部に保持する
- 外部状態がないと翌日の Loop はゲームを最初からやり直す羽目になる
■ 5. 検証可能な Loop の5ステップ方法論
- Step 1. 目標契約（完了基準を決める）:
- 明確な目標と範囲、定量化できる受け入れ基準、制約と境界条件、成果物の形式を設定する
- 数字に落ちないものは Loop で扱わない方が無難
- Step 2. Agent の実行（複数ツール・複数インスタンスで進める）:
- タスクを分解して計画を立て、ツールを呼び、必要に応じて複数インスタンスで並列実行する
- 思考と行動の軌跡を記録する
- Step 3. 証拠によるフィードバック（テスト・ログ・スクリーンショット・CI）:
- 自動テスト結果、実行ログとエラースタック、スクリーンショット・UIスナップショット、パフォーマンス指標、CI/CD のステータスを証拠として出させる
- 「動きました！」という自己申告を信用しない
- Step 4. 停止条件（合格・ロールバック・人間への引き渡し）:
- 合格: 受け入れ基準を全て満たせばデリバリー
- ロールバック: リスク発生または目標逸脱で変更を取り消す
- 人間への引き渡し: 人間の意思決定や介入が必要な場合はエスカレーション
- タイムアウト: 最大イテレーション回数または時間超過で中断・現状報告
- Step 5. 経験の還元（ルール・skills・harness の更新）:
- 成功体験はルールやテンプレートに落とし、失敗の教訓はネガティブルールやチェックポイントに落とす
- skills と harness を更新し、ナレッジベースと同期する
- 積み重ねることで次回の Loop が速く、安定する
■ 6. Loop vs Cron: 4つの実行方式の比較
- 手動 Prompt: コンテキストを毎回人間が補足・履歴消失、探索・ブレスト・計画評価に適する
- Loop: セッション記憶を保持・自動継承、作業中の継続的状態監視・完了までに適する、コストと脱線リスクがある
- システム Cron: コールドスタート・記憶なし、固定の定期タスク（ログ清掃・バックアップ）に適する
- GitHub Actions: コールドスタート（ログは追跡可）、クラウドの信頼性パイプラインに適する
- 選択基準:
- 短期サイクルには Loop
- 長期で信頼性が要るなら GitHub Actions
- 固定された機械的タスクには Cron
■ 7. チームへの導入: 6ステップと2つの品質ゲート
- 導入の基本方針: いきなり全部を Loop 化せず、小さく始める
- 6ステップ:
- タスクを選ぶ: CI 修復・リグレッション検証・ログ巡回点検などの小さく明確なタスクから着手する
- 目標契約を書く: 入力・出力・合格基準（数字で）・禁止領域を明記する
- ツールへつなぐ: repo・テストフレームワーク・lint・MCP・issue トラッカーを接続する
- センサーを足す: テスト結果・スクショ・録画・パフォーマンス指標・エラースタック・カバレッジを設定する（＊品質ゲート#1: 証拠が揃わない限り次に進まないラインを引く）
- 停止条件を決める: 合格・タイムアウト・コスト上限・リスクトリガー・人間への引き渡しを設定する（＊品質ゲート#2: 条件が曖昧だとサイクルが終わらないか、終わったのか分からないものが量産される）
- 経験を貯める: ルール・テンプレート・skill・eval ケース・改善点を蓄積する
- 優先順位: 検証可能 > 自動化可能 > 拡張可能
■ 8. Loop 導入チェックリスト
- Loop に向いているタスク:
- CI の赤信号修復（ビルドとテストの失敗を自動特定・修復）
- テストの補完（単体テストを生成・補完して通す）
- ログの巡回点検（異常検知・分類・修復提案）
- ドキュメント同期（API・README・インターフェースの自動更新）
- 依存関係のアップグレード（バージョン確認・PR・リグレッション）
- 注意したほうがいいタスク:
- 広範囲のリファクタリング（ロールバックが重い）
- 本番環境の権限操作（事故の影響が大きい）
- セキュリティに敏感な変更（権限ポリシー・キー・アクセス制御）
- 純粋な美的判断（客観基準がなく検証ができない）
- Loop 開始前に決めておくべき設定項目:
- Owner（責任者）: 追跡可能性の保証
- 締め切り時間: 無限ループの回避
- 最大ラウンド数: コストの暴走を防ぐ
- 証拠の出力: ログ・スクショ・テスト・CI 結果の必須化
- 停止理由: デリバリーまたはロールバックの明示
■ 9. Loop の3つの罠
- 罠1: 検証の死角:
- Loop は無人で動くため、無人のままミスを犯す
- 「done（完了）」は自己申告であり証明ではない
- 証拠が出ない Loop は自信過剰な乱数発生機と同義
- 罠2: Comprehension Debt（理解の負債）:
- Loop がスムーズであるほど、自ら生成させたコードに対して疎遠になりやすい
- デリバリーを加速させる一方で、コードへの乖離も加速させる
- 罠3: Cognitive Surrender（認知的降伏）:
- Loop を走らせ、自分の判断基準を持つことをやめ、もたらすすべてを受け入れてしまうこと
- 「AI がそう言うので…」が口癖になりはじめたら危険
■ 10. 結論: レバレッジポイントの移動
- レバレッジポイントの変化:
- Before: 良いプロンプトを書く人、個別の答えを出す力、自分が動く
- After: 良いループを設計する人、答えを出し続ける機械を作る力、自分の代わりに動くシステムが動く
- 同じ Loop を組んでも出てくる結果は異なり、差を分けるのは仕事を本当に理解しているかどうか
- Loop Engineering は Prompt Engineering より難しく、1つの答えを出すことと答えを出し続ける機械を作ることは別の能力
- スムーズに回ること自体が危険というパラドックスがあり、薄ら寒さを自覚した上で付き合っていくことが当面の正解