AI レビュー

レビューの全体像

AI レビューとは、シード済みの pr_review パイプラインを、開いている 1 つのプルリクエストに対して 1 回実行したものです。パイプラインは PR のレビュースペースを開き、レビュアーエージェントをファンアウトしてそのスペースの隔離されたチェックアウトで diff を読ませ、各エージェントが指摘を構造化されたレビューノードとして登録し、リードエージェントがそれらをウォークスルーに統合し、ファイナライザーが 1 つの判定 — Ship、Hold、Block — を算出します。パイプラインが決して行わないのは公開です。 GitHub への投稿は、人間が行う別個の意図的なステップです。

このページの残りでは、それぞれの部品と、なぜこの形になっているのかを説明します。

PR ごとに 1 つのレビュースペース

PR のレビューコンテキストはメッセージングスペースであり、モード review、種類 pr で、 レビュースペース関連付けによってプルリクエストにリンクされます。これは冪等に作成されます。PR ページ、レビューパイプライン、チャットの各サーフェスはいずれも、同じコードパスを通じて PR の_唯一の_基盤スペースを解決するため、PR をレビューするテンプレートと、それを開く人間が、別々のチェックアウトを見る別々のルームに分かれることは決してありません。

スペースの隔離されたワークツリーには、そのヘッド ref の時点の PR がチェックアウトされています。1 つのルームは 1 つのチェックアウトでもあります。つまり、各レビュアーがワークスペースのクローンを個別に持つのではなく、全員が同じスペースで作業します。

各レビュアーは、その 1 つのスペース内にある自分の名前付きストリームに投稿し、指摘は単なる散文ではなく review_node メッセージになります。最後にスペース全体を集約するのは意図的です。1 つのスレッドの指摘から算出された判定は、黙って 1 人のレビュアーについての判定になってしまうからです。

関連付けはステータスのはしご — requested → in progress → awaiting approval → completed — を持ち、これが PR のレビュータブで GitHubに公開の可否を決めます。

レビューレベル

レビューの深さは 3 つのレベルを持つワークスペースポリシーで、 設定 → ワークスペース → 全般のワークスペースポリシーカードで設定します：

レベル	ファンアウトするレビュアー	報告
`light`	エンジニアのみ	本当に重要なものだけ
`balanced`	エンジニア、QA、アーキテクト（デフォルト）	標準のパス
`thorough`	5 名全員（セキュリティとパフォーマンスを含む）	何も格下げされない

レベルは 2 つのダイヤルを同時に動かします。1 つはどのレビュアーがファンアウトするかで、これはプロンプトの文言ではなくパイプラインテンプレートの runWhen ステートゲートによって強制されます — プロンプトの文言は無視できますが、ゲートは無視できません —。もう 1 つは、しきい値未満の指摘をどこに表示するかです。どちらのダイヤルも指摘を削除することはありません。報告が少ないレベルでも、登録する量はまったく同じで、残りをグループ化するだけです。

セキュリティとパフォーマンスのパスは、新しいエージェントを導入するのではなく、シード済みのアーキテクトエージェントとエンジニアエージェントを再利用します。専門性とは、レビュアーがディスパッチされる際のブリーフであり、軸ごとの別個のエージェントではありません。軸ごとにエージェントを置けば、追加の能力もないまま、すべてのワークスペースに行が 5 つ増えるだけです。レビュアーの選択が、言語やドメインのために diff を検査することはありません。

レビューノード：指摘は散文ではなくデータ

add_review_node で登録された指摘は、PR 上のレビューノードになります。これは レビュータブが表示するものであり、判定の算出元であり、「GitHubに公開」がインラインコメントに変換するものです。散文しか返さないレビュアーは、成功したように見えるパイプライン実行と、空のレビューサーフェスを生みます。登録こそが要となる部分です。

各ノードは次を保持します：

フィールド	値
種別	`bug`、`suggestion`、`recommendation`、`question`、`ticket`
優先度	P0（重大）→ P3（些細な指摘）
トリアージの三点	カテゴリ（`security`、`stability`、…）、重大度、工数
アンカー	ファイルパス、開始行と終了行
修正案の同梱	置換後の行の提案、任意の diff、任意の修正プロンプト
確信度	[0, 1] のスコア
推論	指摘より前に書かれる分析

2 つの細部は意図的です。ワンクリックの GitHub 提案が提供されるのは、レビュアーが正確な置換行を提示した場合だけです — 統一 diff からそれらを推測すると、静かに間違えます。そして、誤った推測をワンクリックでコミットするのは、ボタンがまったくないより悪いことです。また、add_review_node のスキーマは指摘より前に reasoning を提示するため、オブジェクトをスキーマの順序で埋めるモデルは分析を先に書きます。このフィールドは任意です。省略してもノードが拒否されることはありません。ペイロードが不正なノードは、レビューを汚染するのではなく消えます。

ピアのコンセンサス

ノードは open → consensus-ready → resolved または dismissed と進みます。中間のステップがこのモデルの核心です：指摘は、ピアのレビュアーが確認したときにだけ昇格し、エージェントが自分の指摘を確認することは決してできません。 MCP ツール publish_review_to_github と RPC のデフォルトは、今もピアが確認した指摘のみを公開します。一方、レビュータブの GitHubに公開 ボタンは、残っているすべてのオープンな指摘を送信します。

このルールは 3 つの独立した場所 — 確認ツール、ファイナライザー、公開処理 — で強制されるため、そのうち 1 つに不具合のある呼び出し元がいても生き残ります。ステータスの変更はすべて 1 つのサービスを通ります。これがステータスを意味のあるものにしています。それ以前は、2 つの中途半端な経路が、同じ指摘が解決済みかどうかで食い違う可能性がありました。

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

指摘を却下すると、低い確信度でソフト抑制ファクトがメモリドメインに書き込まれます。一度の却下は好みであり、ルールではありません。

コホート：レビューが何を基準にまとまるか

レビューコンピュートのパスは、PR の変更ファイルをコードグラフから導かれたコホートにまとめます。変更ファイルはそれらが触れるシンボルに対応し、シンボルは連結されたコンポーネントに対応し、コホートは影響範囲によって順位付けされます。コホートは、平坦なファイルリストではなく、ガイド付きの読み順、図、インサイトを伴います。

2 つの誠実さのルールがこれを形づくります。コホートキーは内容から導かれ、プッシュをまたいで安定しているため、指摘とレビューの進捗は rebase や force-push を越えて生き残り、孤立しません。また、リポジトリにコードインデックスがない場合、グループ化は単純なパスにフォールバックし、その旨を明示します — フォールバックが意味論的な確信度を偽ることはありません。

レビューの軸とゲート

レビュアーの指摘に加えて、レビューは軸の結果を蓄積します。軸は 6 つあり、2 種類に分かれます。

軸	種類	由来
`correctness`、`security`	トークン駆動	レビュアー自身の指摘
`testGap`	トークン駆動	レビュアーの指摘
`visual`、`apiContract`	決定論的	トークンを消費せずに算出
`performance`	決定論的	列挙のみ — プロダクト内で結果を算出するものはない

軸の判定は pass、warn、fail、partial、unavailable のいずれかで、ゲートを通過できるのは pass か warn だけです。fail、partial、unavailable の区別は重要です。完了できなかった、あるいはまったく実行できなかったゲート対象の軸は、全体の判定を通過させるのではなく、引き留めます。証拠がないことは、決してグリーンのゲートには変わりません。

一部の軸が意図的に助言的な扱いなのはそのためです。コホートから導かれるテストギャップの軸は、依存性注入やファクトリのカバレッジを見ることができません — インデックスのないリポジトリでテストスイートが充実していても、テストがまったくなくても、そこから見れば同じに見えるため、どちらかを主張するのは嘘になります。この軸はゲートせずにダッシュボードに表示されます。トークン系の軸が助言的なのは、指摘の優先度がすでに判定を動かしており、それらで再度ゲートすると二重計上になるからです。

判定

ファイナライザーは、ステータスが open または consensus-ready の指摘に対して判定を算出します：

確信度 ≥ 0.7 の P0 の指摘がある → Block
そうでなければ、P0（低確信度）または P1 がある → Hold
それ以外 → Ship

判定は、寄与する確信度のばらつきから導かれる集約確信度を伴います — 一致はそれを上げ、不一致はそれを下げます。

リード（CEO）エージェントによる統合は、再列挙ではなく編集パスです。指摘の 2 つ目の写しを手書きすることこそが、本物からずれていく原因になります。重複した指摘は繰り返すのではなく格下げされます — 複数のレビュアーが、意図的に重なる担当範囲で 1 つの diff を指し示されるため、同じ欠陥が 3 回ファイナライザーに届くのはシステムが機能している証拠です。それを 3 回公開するのは、システムが自分のアーキテクチャを読者の受信トレイに漏らしているだけです。再レビューでは、指摘にフィンガープリントが付与され、前回のラウンドと diff されるため、表示されるのは変化分だけです。

最後に軸が合流し、軸は判定をより厳しくすることしかできません。ゲート対象の軸が失敗すれば Block が強制され — 指摘による多数決で覆すことはできません —、ゲート対象の軸が完了できなかった場合は少なくとも Hold が強制されます。

公開はあなたの手に残る

パイプラインは意図的に GitHub へ投稿しません。公開はユーザーがゲートするため、レビューが二重に公開されることは決してありません。GitHubに公開を押すと：

1 つの GitHub レビューが送信されます。すでに解決済みまたは却下済みの指摘はスキップされます。ボタンは残っているすべてのオープンな指摘を公開します（selection: all_open）。MCP ツール publish_review_to_github は依然としてピアが確認した指摘のみをデフォルトとします（consensus）。
ファイルと行にアンカーされた指摘はインラインコメントになり、それ以外はすべてサマリー本文にまとめられます。それぞれに「— Control Center AI review」というフッターが付き、出所が曖昧にならないようになっています。
アンカーは公開時に、PR の_現在の_ diff に対して再検証されます。すでに書き換えられたコードへのコメントは、レビュアーが残しうる中で最も信頼を損なうものです。それでも GitHub がインラインアンカーを拒否した場合、レビュー全体が、すべての指摘を本文に畳み込んだ形で再送され、何も黙って落とされません。
Block の判定は REQUEST_CHANGES として、Hold は COMMENT として、 Ship はボタンから APPROVE として送信されます（approve_on_ship: true）。 MCP ツールは approve_on_ship を渡さない限り、Ship を COMMENT のままにします。
レビューはサーバーのアプリ ID で投稿されます。誰が公開を押したかはロールゲートと監査ログのために記録されますが、それが GitHub の投稿者になるわけではありません。

公開は prPublish アクションクラスを宣言するため、ガードレールのチョークポイントが他のあらゆる変更操作と同様にゲートします — デフォルトでプロンプトを出し、承認者が接続されていない場合はフェイルクローズします。詳しくはガードレールを参照してください。

レビュアーにできること

レビュアーエージェントは review モードで実行されます。読み取り専用のサンドボックスと、指摘、コメント、チケット、ピアレビューを対象とする厳選されたツール許可リストを使えますが、変更操作はできません。レビュアーは自分が批評するコードを修正できません。人間が適用する修正案を添付することはできます。モードの拒否メッセージは、それでも操作しようとするエージェントに、レビューを完了させ、公開されたサマリーに対してユーザーが行動できるようにするよう伝えます。