arena

Arena

同じタスクに対して、N 個の試行を並行して実行します。すべての候補を最初から最後まで読み、最も優れたものをベースとして選びます。他の候補から優れたアイデアを取り込み、合成した結果を検証します。

開始

何かを起動する前に、各フェーズを 1 項目ずつ記載した ToDo リストを作成します。Arena は自律的に実行され、このリストによってフェーズがいつの間にか抜け落ちるのを防げます。

1. 枠組みを決める
2. 並行して実行する
3. 相互評価する
4. 選ぶ
5. 取り込む
6. 検証する

フェーズ A：枠組みを決める

N 個の候補には同じプロンプトが渡されるため、プロンプトが契約となります。何かを起動する前に、プロンプトを適切なものにしてください。

1. 各候補が作成する成果物を明示します。
2. 評価基準を導き出します。今回のタスクで何を成功とするかを述べ、それを採点可能な具体的な基準 3～6 個に落とし込みます。具体例：Adds a --dry-run flag that skips writes。曖昧な例：code is correct。フェーズ D では評価基準が選定者の判断材料となります。候補にはタスクだけが提示されます。
3. 実行役を選びます。デフォルトの実行役は、設定済みの Arena リスト（デフォルトは claude-opus-4-8-thinking-xhigh、gpt-5.5-high-fast、composer-2.5-fast）です。Arena が複数の設計方針を扱う場合は、実行役を追加します。判断よりも生成が中心のタスクでは、同じモデルを N 回使います。
4. 出力先を割り当てます。各候補はそれぞれ別の場所に書き込みます（可能であれば Git のワークツリー、そうでなければ /tmp/arena-<slug>/candidate-<n>/）。N 個の候補が同じパスに書き込むと、状態が共有されて変更可能になり、「共有状態を直列化する前に分離する」という原則に違反するスキルテストとなります。

フェーズ B：並行して実行する

すべての N 個のサブエージェントを、run_in_background: true を指定して 1 つのメッセージ内で起動します。各エージェントには、タスク、共有の根拠資料へのパス、個別の出力先、および成果物と簡潔な根拠の両方を作成する指示を渡します。

根拠の提示は必須です。根拠がなければ、親エージェントは候補の構成が原則に基づくものか、偶然の産物なのかを判断できず、フェーズ E での取り込みの信頼性が損なわれます。それぞれの根拠には、候補が検討した代替案と、採用しなかった案を記載します。

候補が出力を作成できなかった場合は、N-1 個で続行し、統合記録に脱落したことを記載します。

フェーズ C：相互評価する

フェーズ B のすべての候補が完了した後、親エージェントとは異なるモデルファミリーの読み取り専用評価サブエージェントを 1 つ起動します。評価サブエージェントには評価基準とラベル付きの候補パスを提示し、各基準を採点させ、根拠とともにベースを推奨させます。評価サブエージェントはフェーズ D で親エージェントが候補を読むのと並行して動作させ、候補の作成中には動かしません。候補がまだ書き込み中に起動すると、評価サブエージェントが不完全または空の出力を読み取り、脱落と報告してしまう可能性があります。

フェーズ D：ベースを選ぶ

選ぶ前に、すべての候補を最初から最後まで読みます。N 個の候補を流し読みすると、表面的に最も見慣れた候補しか見つけられません。

全体的な印象ではなく、評価基準ごとに各候補を採点します。相互評価の結果とも比較します。ベースについて意見が一致すれば、その選定を確認できます。意見が分かれた場合は、どちらかの判断に偏りがあるか、評価基準が曖昧だったことを意味します。決定する前に、両方の根拠を読みます。

不変条件を壊すことなく、将来の保守担当者が最も容易に拡張できる候補をベースに選びます。判断が分かれる場合は、「怠惰のプロトコル」に従い、境界がより明確で、表面積がより小さい方を優先します。

選んだベースの成果物とともに、選定理由を簡潔な統合メモに記録し、相互評価の結論も含めます。

Phase E: 統合

敗れた候補をそれぞれもう一度確認し、ベースに取り込む価値のある要素を特定します。通常、各候補から見つかるのは1つか2つで、大部分ではありません。

redesign-from-first-principles 原則スキルに従い、要素を1つずつ手作業で統合します。機械的に貼り付けてはいけません。結果は、1つのメンタルモデルのもとで一貫している必要があります。

何を、どの候補から取り込んだのか、また何を、なぜ却下したのかを記録します。却下理由の記録が、最も価値の高い情報です。後から読む人が学べるのは、採用したものだけでなく、検討して見送ったものからです。

N個の候補が同じ形に収束した場合、それは強い合意を示すシグナルです。記録に収束したことを記し、合意された形を採用します。統合は不要です。N個の候補が大きく食い違う場合、Phase Aの仕様が不十分でした。食い違いを平均化するのではなく、問題を捉え直して再実行します。

Phase F: 検証

合成された成果物は、prove-it-works 原則スキルに従い、ほかの出力と同じ厳しい検証に耐える必要があります。アリーナを通過したからといって、検証を免除されるわけではありません。

検証でアリーナが見つけられなかった問題が明らかになった場合、Phase Aが誤っていた（問題を捉え直して再実行する）か、ある候補が問題を捉えていたのに、その要素を取り込めなかった（Phase Eに戻る）かのどちらかです。問題を取り繕ってはいけません。

成果物

合成された成果物を1つ。その横に、ベース、取り込んだ要素（出典となる候補を含む）、却下した要素、あれば脱落した候補、検証結果を記した短い合成メモを1つ。