AI レビューを使う

このガイドでは、レビュアーエージェントにプルリクエストをレビューさせ、その結果を GitHub に公開する方法を説明します。

AI レビューを開始する

PR を開き、概要タブに移動します
アクション行の ⋯ オーバーフローメニューを開き、AIに質問を選択します

この項目は PR がオープンの間だけ表示されます — マージ前のアクションです。同じボタンは、レビューがまだ存在しないレビュータブの空の状態でも AIに質問 として提供されます。

Control Center はシード済みの pr_review パイプラインを開始し、その様子を確認できるように PR のレビュータブを開きます。パイプラインは次のことを行います：

PR 自身のレビュースペースを開きます。その隔離されたワークツリーには、ヘッド時点の PR がチェックアウトされています
ワークスペースのレビューレベルに応じてレビュアーをファンアウトします — デフォルトでは 3 名（シード済みの qa、architect、engineer エージェントを並列で）。言語やドメインの検出は行いません
リード（CEO）エージェントに、それらの指摘をウォークスルーへ統合させます
ファイナライズします：指摘をコンセンサスのバケットに分類し、判定を算出します。関連付けが awaiting approval に達すると、レビュータブに GitHubに公開 が表示されます

レビューがどれだけ深く進むかは、ワークスペースのレビューレベル — light（レビュアー 1 名）、balanced（3 名、デフォルト）、thorough （5 名全員、セキュリティとパフォーマンスのスペシャリストを追加）— で決まり、 設定 → ワークスペース → 全般のワークスペースポリシーカードで設定します。軽いレベルでも登録される指摘の数はまったく同じで、前面に報告される数が少なくなるだけです。

すべてのレビュアーは PR の単一のレビュースペースに投稿し、それによって彼らの指摘が比較可能になります。各部がどのように組み合わさるかは AI レビューを参照してください。

pr_review には手動トリガーしか用意されていません。公開されたすべての PR で発火させるには、自分でトリガーを追加します — 詳しくはレビュアーエージェントをディスパッチを参照してください。GitHub 側から開始することもでき、パイプライントリガーは不要です：PR でサーバーのボットにメンションするか、ai-review ラベルを追加します — 詳しくは GitHub PR から Control Center に話しかけるを参照してください。

このプルリクエストではレビューがすでに実行中だとトーストに表示された場合、すでに 1 つ進行中です。レビュータブにとどまるか、パイプラインを開いて見つけてください。

指摘を読む

レビュアーは指摘を、レビュースペース内のレビューノードとして記録します。各ノードは次を保持します：

フィールド	説明
種別	`bug`、`suggestion`、`recommendation`、`question`、`ticket`
優先度	P0（重大）→ P3（些細な指摘）
カテゴリ	`security`、`stability`、`data_integrity`、`correctness`、`performance`、`maintainability`
ファイルと行	指摘がアンカーされている位置
元のコード	指摘の対象となるコード
提案コード	提案された修正
確信度	レビュアーがどれだけ確信しているか
ステータス	`open` → `consensus-ready` → `resolved` または `dismissed`

指摘は、_ピア_のレビュアーが確認して初めて consensus-ready に達します。エージェントは自分の指摘を確認できないため、単独のレビュアーの意見がそれだけで昇格することはありません。

レビュータブには、統合エージェントが公開した成果物の隣に、種別とステータスで絞り込める指摘リストが表示され、却下済みの指摘を表示するトグルも付いています。決定論的なビュー — コホート、多次元ダッシュボード、コントラクト diff とビジュアル diff — はサーバー側で算出されますが、アプリに表示面はありません。このパスが何を生み出すかはレビューコンピュートを参照してください。

不一致パネルを確認する

2 人のレビュアーが同じファイルと行に指摘をアンカーしながら、その評価が大きく異なる場合 — 優先度が 2 レベル以上離れている、あるいは一方が bug と呼び、もう一方が suggestion と呼んでいる場合 —、指摘リストの上に不一致パネルが表示されます。まずそれらを読んでください：そこがレビュアーの意見の分かれる場所であり、あなたの判断が最も価値を持つ場所です。

判定を読む

リードエージェントがファイナライズすると、判定を算出します：

判定	意味
Ship	ブロックするものは見つからなかった
Hold	マージ前に対処すべき問題がある
Block	修正しなければならない重大な問題がある

判定は、集約確信度スコアと優先度ごとの指摘件数を伴います。

その後レビューの軸が合流し、軸は判定をより厳しくすることしかできません。ゲート対象の軸が失敗すれば Block が強制され、ゲート対象の軸が完了できなかった（partial）場合、またはまったく実行できなかった（unavailable）場合は、少なくとも Hold が強制されます。証拠がないことは、決してゲートをクリアしません。

レビューを GitHub に公開する

公開は、意図的にユーザーがゲートする別個のステップです。pr_review パイプラインはレビューを Control Center 内にとどめ、GitHub には投稿しません。

レビュータブで、GitHubに公開が表示されるまで待ちます
GitHubに公開を押します

Control Center は 1 つの GitHub レビューを送信します。すでに解決済みまたは却下済みの指摘はスキップされます。このボタンは残っているすべてのオープンな指摘を含み、Ship の場合は APPROVE を送信します。（MCP ツール publish_review_to_github は今もピアが確認した指摘のみをデフォルトとし、 approve_on_ship を渡さない限り承認しません。）ファイルと行のアンカーを持つ指摘はインラインコメントになり、それ以外はすべてサマリー本文にまとめられ、それぞれに「— Control Center AI review」というフッターが付くため、出所が曖昧になりません。 Block の判定は REQUEST_CHANGES として、Hold は COMMENT として、 Ship はこのボタンから APPROVE として送信されます。その後トーストに 公開済み と表示されます。レビューはサーバーのアプリ ID で投稿されます。

行が diff の一部でないために GitHub がインラインアンカーを拒否した場合、レビュー全体が、すべての指摘を本文に畳み込んだ形で再送されるため、何も黙って落とされません。

他の組み込みパイプラインは GitHub に直接投稿します：cross_review、pr_triage、 ticket_to_pr、pre_merge_gate はいずれもコメントステップで終わります。 pr_review だけが、その出力をあなたのために保留します。

レビュアーを自分でディスパッチする

どのロールが PR をレビューするか、各ロールがどのファイルを見るかを制御するには、既存のレビュースペース内で dispatch_reviewers MCP ツールを使うか、パイプラインにレビュアーノードを追加します。どちらの方法も、ツールの正確なシグネチャとともにレビュアーエージェントをディスパッチに記載されています。