AX Code を入手 · 無料ドキュメント
AX Code.
ja
English繁體中文简体中文日本語한국어FrançaisDeutschBahasa IndonesiaItalianoPortuguês (Brasil)РусскийEspañolTürkçeTiếng Việt
始める

このページは英語版ドキュメントの翻訳です。コマンド、識別子、例はそのままです。ランタイム 7.24.4 · SDK 2.6.7。 英語版

検証済みの複数モデル変更

状態: 有効 範囲: 現行状態 最終確認: 2026-08-21 担当: AX Code ランタイム

「影響の大きい変更があり、複数の試みが欲しく、どの試みを残す価値があるかをリポジトリ自身のチェックに決めさせたい」という仕事のためのワークフローページです。

モードのリファレンス、つまりフラグ、設定キー、順位付けの入力については、実行モード を参照してください。このページは、端から端までの作業です。

これが価値を持つとき

複数のモデルを動かす費用は、1 つを動かす費用の数倍です。変更の影響が大きく、失敗を後から見つけるコストが高いときに見合います。モジュール境界をまたぐリファクタ、移行、セキュリティに敏感なコードの修正、またはどのアプローチが正しいか本当に分からない変更です。

1 行の編集、名前の変更、読むだけで確認できるものには見合いません。

2 つの異なるツール

ツール 生み出すもの ファイルを書き込むか
council 独立したレビュー意見の集約 いいえ
arena 順位付けされた実装候補 隔離された worktree 内だけ

何をするかを決めるには council を使います。設計またはレビューの質問を、接続された複数のプロバイダーへ広げ、回答を合意、厳格多数、少数、単一の所見へ集約し、任意で匿名の討論ラウンドを付けます。これは助言です。モデル間の一致は正しさの証明ではなく、その質問がどれだけ争われているかの信号です。

どの実装を残すかを決めるには arena を使います。

アリーナの実装ワークフロー

1. 準備する

実装モードには、少なくとも 1 つのコミットがある Git プロジェクトと、きれいなプライマリ worktree が必要です。競技者の worktree は正確なベースコミットから作られ、未コミットの変更を継承できないため、先にコミットするか stash してください。

接続されたプロバイダー上に、選択可能な互いに異なるモデルが少なくとも 2 つ必要です（共有ゲートウェイに対応しています）。また modes.arena.enabled: true も必要です。

2. 実行する

/arena <task description>

各競技者は、記録されたベースコミットから作られた独自の Git worktree を持ち、その中で実装エージェントが動きます。プライマリの作業ツリーは競技者によって変更されません。

3. AX Code が各候補に対して行うこと

  • 競技者の追跡対象および未追跡の変更を、エージェント自身が作ったコミットも含め、耐久性のあるブランチコミットへスナップショットします。
  • 検出されたプロジェクト検証コマンド、つまり型チェック、テスト、lint を実行しますが、空でないパッチが取得されたあとに限られます。空のパッチは勝てません。
  • 既定では 検証優先で順位付けします。完了し、空でなく、検証に合格したパッチだけが勝利の対象です。合格した候補の中では、より低いリスクと、より多様なパッチを優先します。

4. 決める

レポートには、worktree のパス、ブランチ名、コミット範囲が示されます。

AX Code は勝者をマージしません。 自分で検査、マージ、または cherry-pick してください。これは意図的です。検証は「このパッチに対して、設定されたチェックが合格した」ことを意味し、それは実際の信号ですが、レビューの代わりではありません。

5. レビューし、必要なら戻す

候補が自分のツリーに入ったら、証拠コマンドは通常どおり適用されます。

ax-code graph <sessionID>       # what the winning run actually did
ax-code risk <sessionID>        # heuristic risk signals for the change
ax-code session rollback <sessionID> --dry-run

実行証拠 を参照してください。

ここで「検証済み」が正確に意味すること

それは、その候補のパッチに対して、プロジェクトが検出した型チェック、lint、テストのコマンドが実行され、合格したことを意味します。

変更が正しい、完全、安全、またはよく設計されているという意味ではありません。テストスイートが変更された振る舞いを覆っていない場合、合格した候補が証明するのは、すでに覆われていたものが壊れていないことだけです。検証は下限を上げます。上限を保証しません。

通常の対話的な編集には及びません。アリーナの候補とゲート付きリファクタの適用はチェックを実行します。通常のセッションでの通常の edit または write は自動ではありません。通常の実行についてその証拠を記録したいときは、verify_project を実行してください。

費用と失敗の形

  • 費用は競技者の数に比例します。 それぞれが完全な実装エージェントを実行します。
  • 汚れた worktree は、他のことが起こる前に実行を止めます。 設計どおりです。
  • 互いに異なるモデルが 2 つ未満だと比較は無意味になり、ツールは順位を作り出さず報告します。
  • すべての候補が検証に失敗することがあります。 それは有用な結果です。通常、タスクの指定が不足していたか、リポジトリのチェックがエージェントの想定より厳しかったことを意味します。