Gauntlet Loop（ガントレットループ）
Claude of Duty の背後にある方法論を、エージェントが検査可能なあらゆる作業に一般化したものです。1つのプロンプトから、人間の操作を一切介さずに、プレイ可能なAAAスタイルのシューティングゲーム（約55,000行）が生成されました。差別化要因はモデルではなく、ループそのものでした。
コアサイクル:
分割 → 構築 → 外部基準に対して評価 → 繰り返し
考案者: Matt Shumer。詳細は references/origin.md を参照してください。
実行契約
このプロトコルを実行するのはあなた（エージェント）です。ユーザーは実行しません。
このスキルが発動したら、プロンプト、承認用の計画、ガントレットループの説明などをユーザーに返してはいけません。品質基準を設定し、目標を分解し、ビルダーと批評家をスポーンし、ラウンドを実行し、完成した成果物を納品してください。
ユーザーは一度だけ目標を与えました。それ以降はすべてあなたの責任です。
- 明確化のための質問はしないでください。 不明点はすべてあなたが判断し、最終サマリーに記録します。
- 基準は自分で選んでください。 一言で基準を述べ、その後はすぐに実行に移ります。どの参照を使用するかユーザーに尋ねてはいけません。
- モデルは自分でルーティングしてください。 ハーネスが提供するモデルと思考努力設定の中から、スポーンするすべてのエージェントに適切なものを選択します。ユーザーにどのモデルを使うか尋ねたり、すべてをセッションのデフォルトに任せたりしてはいけません。
- 実行途中の報告はしないでください。 進捗は会話ではなく、進行ファイルに記録します。
- 割り込むのは、認証情報のブロック、有料リソースの欠如、または害を引き起こす指示がある場合のみです。
ユーザーが明示的にチェックポイントでの相談を求めた場合は、それを尊重します。そのようなシグナルがない限り、完了まで実行します。
適用条件
以下の3つの条件を満たす場合に適用します:
- リクエストが質問への回答ではなく、何かを「作成」または「改善」することである。
- 出力を客観的に検査できる（レンダリング、実行、オープン、測定、テスト、読み取りが可能）。
- 複数ラウンド実行できる予算がある。
検索、1行の修正、説明には適用しません。実際の計算コストがかかるため、スピードよりも品質が重要な場合にのみ効果を発揮します。
実行手順書
1. ハーネスの検出
references/harness-setup.md を読み、他の何よりも先に配線（ワイヤリング）を選択します。これにより、批評家が並列サブエージェント、別セッション、またはハード分離されたパスのどれから来るかが決まります。このステップをアナウンスせず、ただ適応してください。
その際、このハーネスが公開しているモデルと思考努力設定を列挙してください。リスト化されていないものはルーティングできません。
2. 予算とルーティングテーブルの設定
ループは呼び出しを倍増させます。ルーティングされないまま放置すると、すべての呼び出しがセッションのモデルと思考努力を継承し、機械的な編集のファンアウトが最前線モデルで最大思考努力で行われても何の利益も生みません。
references/model-routing.md を読み、構築を開始する前に一度だけ以下のことを決定してください:
- ティア（階層）: 利用可能なモデルを T0（コマンド、モデル不要）、T1（小型・高速）、T2（中級）、T3（最前線・高思考努力）にマッピングします。
- テーブル: どの役割にどのティアを割り当てるか。リードとすべての判断呼び出しはT3、標準的な構築はT2、機械的な編集や記録管理はT1、コマンドで検証できるものはT0。
- 予算: ユーザーが指定した場合はそれを尊重し、そうでない場合は自分で設定します。予算の約4分の1は批評家のために確保しておきます。
2つのルールがいかなる節約よりも優先されます。判断は最も安価なティアにルーティングしてはいけません。 弱い批評家は早期に承認し、手法を無効にしてしまうからです。また、センスや新規性に関する作業は上位のティアから開始します。 安価なビルダーが4ラウンド負け続けるよりも、高価なビルダーが1ラウンドで勝つ方がコストがかからないからです。
ルーティングテーブルを進行ファイルに記録します。アナウンスせず、承認を求めてもいけません。
3. 品質基準（バー）の設定
品質基準が実行の成否を決めます。「素晴らしくする」「プロダクション品質」「ベストプラクティスに従う」といったものは基準ではありません。基準とは、出力を実際に並べて比較でき、負ける可能性のある、現実の外部成果物または測定値です。
references/quality-bars.md を使用して1つ選んでください。このファイルは、ビジュアルワーク、フロントエンド、製品UI、バックエンド、モバイル、ライティング、デザインシステム、リサーチ、データ、マーケティングをカバーしています。
ルール:
- 実行内で検査可能であること。 ワークスペースに保存されたスクリーンショット、開けるURL、実行できるテストスイート、読めるファイル。トレーニングデータから記憶している基準ではだめです。
- 到達可能である必要はない。 Claude of Duty は決して Call of Duty を超えませんでした。基準は、実行が「AIにしては良い」で満足するのを防ぐために存在します。
- 最初のラウンドで基準をクリアした場合は、基準が低すぎたということです。 引き上げて続行します。
基準となる成果物を今すぐ（構築開始前に）取得または生成し、すべての批評家がアクセスできるようにワークスペースに保存します。
4. 目標を取得し、実装方法を指定しない
自分のアーキテクチャを事前に決めつけたり、成果物を見る前に考案された分解を受け入れたりしないでください。目的地を言い換え、具体的な形は後で決まるようにします。
ユーザーがスタックやアーキテクチャを固定した場合、それは実際の制約です。それを尊重し、他のすべてはオープンにしておきます。
5. 作業の分割
目標を個別に改善・評価できる最小の単位に分割し、どれを並列実行するかを決定します。
粒度こそが力です。「サイトを良くする」は手に負えません。「この価格設定セクションを参照価格設定セクションに勝たせる」は、勝つまで攻め続けられる問題です。「この負荷でp95が120msを切るようにする」「この段落を少なくともこの参照段落と同じくらい明確にする」も同様です。
6. 構築と評価は決して同じコンテキストで行わない
各単位について、1人のビルダーと1人の独立した批評家を用意します。常に異なるコンテキストで、決して同じエージェントにしてはいけません。
ビルダーはすべての決定を見ており、なぜその決定を下したかを覚えているため、結果がなぜ「妥当」かを説明するのに長けています。しかし「妥当」は目標ではありません。
ビルダーと批評家には assets/delegation-templates.md を使用して指示を出します。批評家は目標、基準、制約、実際の成果物を受け取ります。ビルダーのトランスクリプト、ビルダーの説明、どちらが私たちの成果物かは決して受け取りません。
スポーンするたびに、ステップ2のテーブルを使用してルーティングします。各ビルダーの前に、3つの質問を自問してください: 成功はコマンドで確認可能か（モデル不要、コマンドで実行）、目標状態はすでに完全に指定されているか（最小モデル、最小思考努力）、またはギャップを埋めるために「何が良いか」の判断が必要か（最前線モデル）。センスを評価する批評家は常に最前線モデル。数値をチェックする批評家は最初にコマンドを実行し、その報告には小型モデルで十分です。
完全な手順は references/critic-protocol.md を参照。要点: 盲目的A/Bテスト、実際の成果物を検査、二値判定、最大のギャップを1つだけ挙げ、差し戻す。
7. ループを続ける
ラウンド数を決して設定しないでください。合意された最終ラウンドは上限になります。
以下のいずれかが真になった時点で停止し、どの条件かを記録します:
- ユーザーが進行ファイルを見て完了を宣言した。
- ラウンドごとの改善が目標に対して重要でなくなった。
- ステップ2で設定した計算予算を使い切った。
ユニットのティアは証拠に基づいてのみ上げてください: 同じギャップで2回連続敗北した場合は思考努力を上げ、3回目でモデルを上げます。勝ち始めたユニットは、残りの実行では元のティアに戻します。予算の80%を使った時点で、勝っているユニットへのラウンド追加を停止し、残りを基準から最も遠いユニットに投入します。
同じギャップが3連続でラウンドをまたいで生き残った場合、そのユニットを停止し、リードレベルで再判断します。構造的な問題であるか、そのユニットにとっての基準が間違っているか、ビルダーと批評家が異なるものを測定している可能性があります。その時点でさらにコストをかけることは、予算を無駄にする最も一般的な方法です。
8. 進行ファイルをライブで維持する
ワークスペースにシンプルなHTMLページまたはMarkdownファイルを維持し、作業が完了するたびに更新します: スクリーンショット、ドラフト、テスト結果、ラウンドごとの判定、未解決のギャップなど。フォーマットを過度に指定せず、最初の出力行でその場所をユーザーに伝えてください。
これにより、ユーザーは割り込まずに進行状況を確認できます。割り込みはコンテキストウィンドウを壊し、ループを中断させます。
9. ウェーブ間のスムージングパス
複数のエージェントが1つの成果物の別々の部分を編集すると、各部分は個別に良くなりますが、全体としては不整合になります。
主要なウェーブの終わりごとに、1つの新しいエージェントをスポーンして結果全体を検査させ、競合を解決し、全体として一貫性のあるものにします。これは再設計ではありません。
有用ではありますが、コアではありません。コアは変わりません: 分割、構築、評価、繰り返し。
実行の終了
成果物を納品し、続けて以下の内容を含む短いサマリーを提供します:
- 使用した基準とその理由。
- 基準に対してどの程度達成できたか。
- 最後の未解決のギャップ（これが次に引き継ぐ人へのハンドオフとなります）。
- 質問しなかった代わりに行った仮定。
- 実行を終了させた停止条件。
- コスト: 実行したラウンド数、予算のおおよその使途、およびほとんど動かなかったのに予算の大部分を消費したユニット。
作品への賞賛は不要です。批評家の判定がすでに重要なことをすべて語っています。
アンチパターン
| 症状 | 修正方法 |
|---|---|
| ユーザーに自分で実行するよう促すプロンプトを渡してしまう | プロトコルを実行する、それがすべてのポイントです |
| ビルダーが「これは素晴らしい！」と言う | クリーンなコンテキスト、履歴なしで批評家をスポーンする |
| 批評家が成果物ではなくレポートを読む | 実際の出力の検査を強制する |
| 主観的な基準（「ワールドクラス」「Appleレベル」） | 開いて確認できる具体的な成果物に置き換える |
| 成果物を見る前に分解が固定されている | 形が作業から現れるのを待つ |
| 「3回の反復を実行」 | 明示的な停止条件でオープンループにする |
| どの参照を使用するか尋ねる | 1つ選択し、一言で正当化し、実行する |
| 会話内でのステータス更新 | ライブ進行ファイルを使用する |
| 良いパーツだが、全体として不整合 | ウェーブの終わりにスムージングパスを実行する |
| 最初のラウンドで基準をクリア | 基準が低すぎた、引き上げる |
| 同じギャップが3ラウンド生き残る | エスカレーション、構造的な問題です |
| すべてのエージェントがセッションのモデルと思考努力を継承する | 各スポーンをルーティングする: 判断には最前線、機械的な作業には小型モデル |
| 変数名の変更に最前線モデルを最大思考努力で使用 | T1最小思考努力、またはモデル不要のコマンド |
| ラウンドを節約するために安価な批評家を使用 | ルールゼロ。弱い批評家は早期に承認し、手法を無効にする |
| センスに関わるユニットに安価なビルダーを使用 | 4回負け続けるラウンドは、1回の高価な勝利よりもコストがかかる |
| 難しいと感じたからといってティアを上げる | 繰り返される判定に基づいてエスカレーションする、直感ではない |
| 批評家の予算を追加の構築ラウンドに使う | 予備費は共通の財源ではない。判断はそれを得る |