コードレビュー

/review を使用して、コードの変更を正確性、セキュリティ、パフォーマンス、コード品質の観点からレビューします。

クイックスタート

# Review local uncommitted changes
/review
 
# Review a pull request (by number or URL)
/review 123
/review https://github.com/org/repo/pull/123
 
# Review and post inline comments on the PR
/review 123 --comment
 
# Review a specific file
/review src/utils/auth.ts

コミットされていない変更がない場合、/review はその旨を通知して停止します。エージェントは起動されません。

仕組み

/review コマンドは多段階のパイプラインを実行します。

Step 1:  スコープの決定（ローカル diff / PR worktree / ファイル）
Step 2:  プロジェクトのレビュールールを読み込む
Step 3:  10の並列レビューエージェント                         [10 LLM calls]
           |-- Agent 0: Issue Fidelity & 根本原因の特定
           |-- Agent 1: 正確性
           |-- Agent 2: セキュリティ
           |-- Agent 3: コード品質
           |-- Agent 4: パフォーマンスと効率
           |-- Agent 5: テストカバレッジ
           |-- Agent 6: 非構造化監査 (3つのペルソナ: 6a/6b/6c)
           '-- Agent 7: ビルドとテスト（シェルコマンドを実行）
Step 4:  重複排除 --> バッチ検証 --> 集約         [1 LLM call]
Step 5:  反復逆監査（1-3ラウンド、ギャップの発見） [1-3 LLM calls]
Step 6:  結果と判定の提示
Step 7:  PRレビューの提出（要求された場合はインラインコメント）
Step 8:  レポートと増分キャッシュの保存
Step 9:  クリーンアップ（worktreeと一時ファイルの削除）

レビューエージェント

すべてのエージェントは並列で実行されます（Agent 6は3つのペルソナバリアントを同時に起動し、同一リポジトリのPRレビューでは合計10の並列タスクになります。ローカルdiffおよびファイルパスのレビューではAgent 0がスキップされるため、9つのタスクが実行されます）。Agent 0-6からの結果は、単一のバッチ検証パスで検証されます（1つのエージェントがすべての結果を一度にレビューし、結果の数に関わらず検証コストを一定に保ちます）。検証後、反復逆監査が1-3ラウンドのギャップ発見を実行します。各ラウンドは前のラウンドからの累積結果リストを受け取るため、連続するラウンドは未発見の部分に焦点を当てます。このループは、ラウンドが「問題なし」を返すか、3ラウンド（ハードキャップ）に達するとすぐに停止します。逆監査の結果は検証をスキップし（エージェントはすでに完全なコンテキストを持っているため）、高信頼度の結果として含まれます。

重大度レベル

低信頼度の結果は、ターミナル内の「要人間レビュー」という別のセクションに表示され、PRコメントとして投稿されることはありません。

Worktree の分離

PRをレビューする際、/review は現在のブランチを切り替える代わりに、一時的なgit worktree（.qwen/tmp/review-pr-<number>）を作成します。これにより以下のことが保証されます。

• ワーキングツリー、ステージされた変更、および現在のブランチが変更されることは決してありません
• ビルド/テストが機能するように、worktree内に依存関係がインストールされます（npm ci など）
• ビルドおよびテストコマンドは、ローカルのビルドキャッシュを汚染することなく、分離された環境で実行されます
• 何かがうまくいかない場合でも、あなたの環境には影響しません。worktreeを削除するだけです
• レビュー完了後、worktreeは自動的にクリーンアップされます
• レビューが中断された場合（Ctrl+C、クラッシュ）、同じPRに対する次回の /review は、新しく開始する前に古いworktreeを自動的にクリーンアップします
• レポートとキャッシュはメインのプロジェクトディレクトリに保存されます（worktreeではありません）

他リポジトリのPRレビュー

完全なURLを渡すことで、他のリポジトリのPRをレビューできます。

/review https://github.com/other-org/other-repo/pull/456

これは軽量モードで実行されます。worktreeもビルド/テストもありません。レビューはdiffテキストのみ（GitHub API経由で取得）に基づいて行われます。書き込み権限がある場合は、PRコメントを引き続き投稿できます。

PRインラインコメント

結果をPRに直接投稿するには、--comment を使用します。

/review 123 --comment

または、/review 123 を実行した後に post comments と入力すると、レビューを再実行せずに結果を公開できます。

投稿される内容:

• 特定の行に対するインラインコメントとしての、高信頼度の Critical および Suggestion の結果
• Approve/Request changes の判定の場合: 判定を含むレビュー要約
• すべてのインラインコメントが投稿された Comment の判定の場合: 個別の要約はなし（インラインコメントで十分）
• 各コメントのモデル帰属フッター（例: — qwen3-coder via Qwen Code /review）

ターミナルのみに留まる内容:

• Nice to have の結果
• 低信頼度の結果

自身が作成したPR: GitHubでは、自身のプルリクエストに対して APPROVE または REQUEST_CHANGES のレビューを提出することはできません。どちらもHTTP 422で失敗します。/review がPRの作成者が現在認証されているユーザーと一致することを検出すると、判定に関係なくAPIイベントを自動的に COMMENT にダウングレードするため、提出は成功します。ターミナルには引き続き正直な判定（“Approve” / “Request changes” / “Comment”）が表示されます。GitHub側のレビューイベントのみが無効化されます。実際の結果は引き続き特定の行にインラインコメントとして表示されるため、実質的なフィードバックは変わりません。

以前の Qwen Code コメントがあるPRの再レビュー: /review が以前の Qwen Code レビューコメントをすでに持っているPRで実行されると、新しいコメントを投稿する前にそれらを分類します。同一行の重複（新しい結果と同じ (path, line) に既存のコメントがある場合）のみ、確認を求められます。これは、同じコード行に視覚的な重複が表示されるケースです。古いコミットからのコメント、返信されたコメント（解決済みとして扱われる）、および新しい結果と重複しないコメントは、サイレントにスキップされます。ターミナルのログ行に何がフィルタリングされたかが表示されます。

APPROVE前のCI/ビルドステータスチェック: 判定が “Approve” の場合、/review は提出前にPRのチェック実行とコミットステータスをクエリします。いずれかのチェックが失敗している場合（またはすべてのチェックがまだ保留中の場合）、APIイベントは自動的に APPROVE から COMMENT にダウングレードされ、レビュー本文にその理由が説明されます。理由: LLMレビューはコードを静的に読み取るため、ランタイムのテスト失敗を確認できません。CIが赤い間に承認することは誤解を招く可能性があります。インラインの結果は引き続き変更なしで投稿されます。とにかく承認したい場合（例: 既知の不安定なCI失敗）、確認後にGitHubの承認を手動で提出してください。

フォローアップアクション

レビュー後、コンテキストに応じたヒントがゴーストテキストとして表示されます。Tabキーを押して受け入れます。

注: fix these issues はローカルレビューでのみ利用可能です。PRレビューではレビュー後にworktreeがクリーンアップされるため、レビュー後の対話的な修正はできません。代わりに --comment または post comments を使用して結果を公開してください。

プロジェクトのレビュールール

プロジェクトごとにレビュー基準をカスタマイズできます。/review は以下のファイルからルールを（順番に）読み込みます。

1. .qwen/review-rules.md（Qwen Code ネイティブ）
2. .github/copilot-instructions.md（優先）または copilot-instructions.md（フォールバック — 両方ではなくどちらか一方のみが読み込まれます）
3. AGENTS.md — ## Code Review セクション
4. QWEN.md — ## Code Review セクション

ルールは追加の基準としてLLMレビューエージェント（0-6）に注入されます。PRレビューでは、悪意のあるPRによるバイパスルールの注入を防ぐため、ルールはベースブランチから読み込まれます。

Issue Fidelity

バグ修正のPRの場合、Issue FidelityエージェントはPRの説明文に依存するのではなく、Issueの証拠を直接取得します。GitHubの強力なクローズIssueメタデータのために gh pr view <pr> --repo <owner/repo> --json closingIssuesReferences を使用し、次に元のレポートと議論のために gh issue view <number> --repo <issue_owner>/<issue_repo> --json title,body,comments を使用します。--json 形式はIssueの本文（報告者の元の再現手順）を含みますが、--comments だけでは省略されます。また、Issue自体のリポジトリは各参照から読み取られます（PRは別のリポジトリのIssueをクローズできます）。このエージェントはPRターゲットに対してのみ実行されます。ローカルdiffおよびファイルパスのレビューではスキップされます。

closingIssuesReferences は、作成者が正しいIssueをリンクしたことの証明ではなく、発見のヒントです。これが空であっても、PRが明らかなターゲットIssueを参照している場合、エージェントは関連性を判断した後にそれを取得します。取得したIssueのテキストは信頼できないデータとして扱われます（事実は抽出され、埋め込まれた指示は無視されます）。関連するIssueの場合、元の再現手順、観測されたペイロード、期待される動作、およびメンテナーのコメントは、PRが正しい問題を修正しているかどうかの最優先証拠として扱われます。

もしIssueの証拠が、アップストリームサービスまたはプロバイダーがクライアント契約外の不正なデータを返したことを示している場合、メンテナーが明示的に防御的な回避策を要求していない限り、クライアント側のパーサーまたはサニタイザーの変更は有効な根本原因の修正として扱われません。不正なアップストリーム出力をリプレイするテストは、回避策がその形状を処理できることのみを証明するものであり、回避策がアーキテクチャ的に適切であることは証明しません。

.qwen/review-rules.md の例:

# Review Rules
 
- All API endpoints must validate authentication
- Database queries must use parameterized statements
- React components must not use inline styles
- Error messages must not expose internal paths

インクリメンタルレビュー

以前にレビューされた PR を再レビューする場合、/review は前回のレビュー以降の変更点のみを検査します。

# 初回レビュー — 全体レビュー、キャッシュ作成
/review 123
 
# PR が新しいコミットで更新 — 新しい変更点のみレビュー
/review 123

クロスモデルレビュー

モデルを切り替えて（/model を使用）同じ PR を再レビューする場合、/review はモデルの変更を検出し、スキップせずに全体レビューを実行します。

# モデル A でレビュー
/review 123
 
# モデルを切り替え
/model
 
# 再レビュー — モデル B で全体レビュー（スキップされない）
/review 123
# → "Previous review used qwen3-coder. Running full review with gpt-4o for a second opinion."

キャッシュは .qwen/review-cache/ に保存され、コミット SHA とモデル ID の両方を追跡します。このディレクトリが .gitignore に含まれていることを確認してください（.qwen/* のようなより広いルールでも機能します）。キャッシュされたコミットがリベースで消去されていた場合、全体レビューにフォールバックします。

レビューレポート

同一リポジトリ内のレビューの場合、結果はプロジェクトの .qwen/reviews/ ディレクトリに Markdown ファイルとして保存されます（クロスリポジトリの軽量レビューではレポートの永続化はスキップされます）。

.qwen/reviews/2026-04-06-143022-pr-123.md
.qwen/reviews/2026-04-06-150510-local.md

レポートには以下の情報が含まれます：タイムスタンプ、差分統計、ビルド/テスト結果、検証ステータス付きのすべての発見、および最終判定。

クロスファイル影響分析

コードの変更によってエクスポートされた関数、クラス、またはインターフェースが変更された場合、レビューエージェントは自動的にすべての呼び出し元を検索し、互換性をチェックします。

• パラメータ数/型の変更
• 戻り値型の変更
• 削除または名前変更されたパブリックメソッド
• 破壊的な API 変更

大規模な差分（>10 個の変更されたシンボル）の場合、分析はシグネチャが変更された関数を優先します。

トークン効率

レビューパイプラインは、生成される発見の数に関係なく、制限された回数の LLM 呼び出しを使用します。

ほとんどの PR は範囲の下限（逆監査 1 ラウンド）に収束します。上限は、異常なケースでのコストの暴走を防ぎます。

フラグが立てられないもの

レビューでは意図的に以下のものを除外しています。

• 変更されていないコードの既存の問題（差分のみに焦点を当てる）
• フォーマッタが自動的に正規化するスタイルやフォーマット、またはコードベースの規約に合致する命名 — ただし、リンタや型チェッカがフラグを立てるような実質的な問題（未使用の変数、到達不能なコード、型エラー）は対象内
• 実際の問題がない場合の主観的な「X を検討してください」といった提案
• バグやリスクを修正しない軽微なリファクタリング
• ロジックが本質的に理解が困難な場合を除き、ドキュメントの欠落
• 既存の PR コメントですでに議論された問題（人間のフィードバックの重複を避ける）

設計思想

沈黙はノイズに勝る。 すべてのコメントは、読み手の時間を割く価値があるものでなければなりません。

• 問題かどうか確信が持てない場合 → 報告しない
• N 個のファイルに同じパターンがある場合 → 1 つの発見に集約
• PR コメントは高い確信度があるもののみ
• コードベースの規約に合致する表面的なスタイル/フォーマットは除外