cross-model-review

クロスモデルレビュー

新しいレビュアーを使って、成果物を元の依頼と照らし合わせて検証します。異なるモデルファミリーを使うと有益な多様性が得られることがありますが、意見の一致は証明にはなりません。ユーザーが明示的に変更を求めない限り、ユーザーが設定したモデルと推論量を維持してください。スキルのガイダンスは、タスクの範囲、既存の権限、ホストの許可を上書きしません。

レビュー対象を選ぶ

状況	方法
Claude が作成し、Codex が利用可能	範囲を限定した codex review、またはカスタムの質問には codex exec
Codex が作成し、Claude が利用可能	範囲を限定し、ツールアクセスを制限した依頼で claude -p
xreview 拡張機能を備えた Pi	スコープのセマンティクスを確認してから、インストール済みの /xreview インターフェースを使用
異なるモデルファミリーのネイティブレビュアー	許可されている場合は公開されている委任ツールを使用し、実際のスキーマを確認
異なるファミリーが利用できない	新しいコンテキストでのレビューも有効です。ただし、コンテキストの独立性のみを提供することを明示してください

フラグを使用する前に、選択した CLI の --version と関連する --help を実行してください。ツール名、待機時間の制限、権限、モデルの利用可否は、現在のホストに依存します。外部 CLI の使用も委任にあたります。ホストによる禁止を回避するものではありません。

CLI の詳細とコピーして使えるランチャーについては、references/cli-flags.md を参照してください。依頼されたレビュー方式には references/prompts.md を使用してください。起動に失敗したり停止したりした場合に限り、references/failure-recovery.md を読み込んでください。

レビュー可能な成果物を固定する

元の依頼、リポジトリのパス、レビューのベース、ヘッド SHA、担当ファイルの一覧を記録します。作業ツリーをレビューする場合は、ステージ済み、未ステージの変更、および関連する未追跡ファイルを含めます。SHA だけでは未コミットの作業内容を示せません。差分とファイル内容、または内容ダイジェストも保持してください。無関係な作業はレビュー用パケットに含めないでください。

範囲	取得する証拠
ブランチ	正確なベースとヘッド、および git diff <base>...<head>
単一コミット	親とコミット、および git show <sha>
作業ツリー	git status --short、ステージ済みと未ステージの差分、関連する未追跡ファイルの内容
ドキュメントまたは診断	成果物の正確なバージョン、主張の一覧、裏付けとなる資料
修正の検証	以前の指摘の原文、主張された修正、新しい成果物、回帰テストケース

レビュアーが確認している間は、レビュー対象のファイルを変更しないでください。独立した作業は別の場所で続けてください。成果物が変更された場合は、その差分を特定し、影響を受ける動作を再レビューしてください。メタデータのみのコミットであれば、ツリーが同一であることを条件に実行時の証拠は失われません。ただし、内容を比較せずに、以前のレビューが新しい SHA を対象にしたと説明してはなりません。

反論できるブリーフを作成する

解釈を示す前に、ユーザーの実際の依頼と成果物をレビュー担当者に提示してください。必要な制約と、関連するリポジトリの指示も含めます。提案する説明には仮説であることを明記してください。独立した最初のレビューでは、確認してほしい結論を提示するのは避けてください。

有用なブリーフには、次の内容を含めます。

• 問いと、レビューの正確な範囲。
• 確認すべき重要な動作、インターフェース、または障害モード。
• 利用できる証拠と、再現に必要な環境。
• 許可される操作と、求められる出力。

既存のテスト結果は記録であり、作成者を信頼せよという指示ではありません。決定的な確認をレビュー担当者に再実行してもらうか、独立した調査方法を選んでもらいましょう。数値による確信度のしきい値、検出件数の必須指定、欠陥があると決めつけるプロンプトは避けてください。読み取り専用のレビューでも、テストが無害とは限りません。信頼できないコードには、認証情報のない隔離環境が必要です。

コードの場合は、各指摘について、発生条件、影響、箇所、証拠を求めてください。仕様の場合は、満たされていない要件または具体的な反例を求めてください。ファクトチェックの場合は、各主張について一次情報源を示した判定を求めてください。設計相談の場合は、推奨案と、その判断を変える証拠を求めます。相談では PASS は必要ありません。

一度起動して、ハンドルを保持する

時間のかかる Claude CLI レビューでは、scripts/run_claude_review.py を使用し、保存されたステータスを scripts/review_status.py で確認してください。起動、認証、範囲、復旧の詳細は references/observable-reviews.md を参照してください。このヘルパーは、別のレビュープロセスを必要とせずにイベントと標準エラー出力を保持します。十分な可視性が得られる場合は、ホスト標準の進捗確認ツールや、CLI の出力を直接取得する方法も適切です。

出力全体を一意のファイルに保存し、起動前にそのパスを表示してください。プロンプトの内容はファイルまたはシングルクォートで囲んだヒアドキュメントに保持してください。信頼できないテキストをシェルコードに展開しないでください。"$(cat "$review_prompt")" のように引用符で囲めば、信頼できるプロンプトファイルを単一の引数として読み込めます。一方、引用符で囲まないヒアドキュメントでは、埋め込まれたシェル構文が実行される可能性があります。

実行中のプロセスやセルの ID は、ジョブが進行中であることを示します。ホストがサポートする待機操作で、同じハンドルをポーリングしてください。待機時間はホストが制御を戻すタイミングを決めるものであり、レビューが成功するかどうかを決めるものではありません。有効な待機時間を使い、ユーザーへの更新時間も確保してください。どのハーネスでも、最初の待機時間を一律に5分へ固定しないでください。

実行中のレビューを head や tail にパイプでつなぎ、それだけを保存先にしないでください。head は早い段階でパイプを閉じることがあり、tail は通常、EOF まで出力を保留し、先行する指摘を破棄します。完了後に保存済みの結果を読み取ってください。無出力、文字起こしのサイズ、経過時間だけでは、判定の根拠になりません。

認証は、ユーザーが意図したプロバイダーと課金経路に従う必要があります。サブスクリプション経由の Claude レビューでは、継承された ANTHROPIC_API_KEY によって意図しない API 課金が選択される場合、子プロセスからその環境変数を削除してください。明示的に API 経由で実行するワークフローでは、その環境変数を保持します。認証情報を表示したり、レビューを実行するために永続的な認証設定を変更したりしないでください。

指摘事項を判定する

指摘は、根拠として示されたパスとトリガーが反証を試みても成立するまでは、単なる主張です。コードを変更する前に、レビュー対象の実際の成果物を確認してください。レビュアーは、名前が似た別のファイルを誤って特定したり、存在しない CLI フラグをでっち上げたり、HEAD ですでに修正済みの動作を指摘したりすることがあります。

判定	必要な根拠
修正	許可された範囲内に実在する不具合であり、再現可能または原因を完全にたどれること
却下	指摘に反する反例、契約、または意図的なトレードオフ
フォローアップ	変更の因果的な範囲外にあることが確認された問題
未解決	不足している環境、事実、または判断と、それを確定するための確認事項

レビュアーの意見が一致すれば調査の優先度は上がりますが、候補が確定事項になるわけではありません。grep で一致が見つからなくても、存在しないことの証明にはなりません。変更によって不具合が持ち込まれたと主張する場合は、ベースと HEAD を比較してください。完全な経路をたどれれば、静的な追跡で決定論的なエラーを確認できます。実行していないのに実行したかのように装わず、実際の証拠の段階を報告してください。

確認済みの問題を修正し、新たなリグレッションが生じていないか修正内容を点検してください。レビュアーの独立性を保ってください。ユーザーがレビューと実装の両方を許可した場合は、レビューから実装へ明示的に切り替えてください。読み取り専用のレビュアーが、自分の評価対象である成果物を黙って編集してはなりません。

根拠に基づいて収束させる

複数回のレビューが必要な場合は、簡潔な指摘事項一覧を維持してください。各項目には識別情報、根拠、判定、検証状況を含めます。後続のブリーフには、以前の指摘をそのまま記載し、変更された成果物も含めて、レビュアーが会話を再発見するのではなく、解決を確認できるようにしてください。

新たな確認済み不具合が見つかるか、修正が検証される間は続けてください。新しい根拠なしに同じ異議が繰り返される場合は、根底にある契約を確定するか、残る意見の相違を報告してください。提案数がゼロでないことを理由に、終わりのないループに陥らないようにしてください。ブロックしない好みの問題によって、許可された修正の範囲を再設計に広げてはなりません。

判定結果	意味
PASS	要求されたレビューが完了し、必要な確認が実施され、レビュー対象範囲にブロックする指摘が残っていません
NEEDS_CHANGES	根拠のあるブロック対象の不具合が少なくとも1つ残っています
INCONCLUSIVE	必要な範囲の確認または根拠を得られません。不足分を補う有用な部分的指摘を含めてください

中断されたレビューでは、未確認の内容について PASS を出すことはできません。終了コード 0 は CLI の処理が完了したことを意味します。レビューの判定を決めるのは、実質的な報告内容です。モデルレビュー、静的解析、実行した確認を受領報告で区別してください。どれも他の代わりにはなりません。

根拠とメンテナンス

2026-09-04 時点で確認したところ、Claude の CLI リファレンスは、利用可能なツールと事前承認済みのツールを区別しています。OpenAI の非対話型ドキュメントには、捕捉された実行出力について記載されています。ディスパッチの前に、どちらもインストール済みバージョンに照らして確認してください。

結果とトレースを分けて調べるという推奨は、Anthropic のエージェント評価ガイダンスに基づいています。異なるファミリーを組み合わせることは有用なレビュー戦略ですが、このライブラリで測定された保証ではありません。誤検知率や精度の向上について、普遍的な値はここでは主張していません。

アンチパターン

アンチパターン	修正
--allowedTools をサンドボックスとして扱う	利用可能なツールを制限し、ホストの実際の隔離境界を適用します
yield の後に再起動する	既存のハンドルをポーリングし、再試行を検討する前に出力を復旧します
特定のモデルや最大限の努力を必須とする	ユーザー設定を維持し、リソースを変更する前に対象範囲を改善します
合意を確認済みと見なす	反証を試みるか、動作全体をトレースします
必須チェックが不足したままレビューに合格させる	残っている証拠の不足を示して、INCONCLUSIVE と報告します
すべての提案を必須と見なす	対象範囲内で裏付けのある欠陥を修正し、任意の改善は別途記録します
ユーザーの依頼を作成者の要約に置き換える	元の依頼を含め、解釈への異議を促します

このスキルではないもの

• 承認されていないプロバイダーへのソースの送信、レビューの公開、他者のブランチの変更を許可するものではありません。
• 共有されている古い知識や誤解を招く概要から保護するものではありません。
• 実行時の検証、プロダクトに関する判断、指摘内容の理解に代わるものではありません。