Code Review

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

クイックスタート

# ローカルの未コミット変更をレビュー
/review
 
# プルリクエストをレビュー（番号または URL を指定）
/review 123
/review https://github.com/org/repo/pull/123
 
# PR にインラインコメントを投稿しながらレビュー
/review 123 --comment
 
# 特定のファイルをレビュー
/review src/utils/auth.ts

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

仕組み

/review コマンドはマルチステージのパイプラインで動作します:

Step 1:  スコープの決定（ローカル差分 / PR ワークツリー / ファイル）
Step 2:  プロジェクトのレビュールールを読み込み
Step 3:  決定論的解析の実行（リンター、型チェック）    [LLM コストなし]
Step 4:  9 つの並列レビューエージェント                [LLM 呼び出し 9 回]
           |-- Agent 1: 正確性
           |-- Agent 2: セキュリティ
           |-- Agent 3: コード品質
           |-- Agent 4: パフォーマンスと効率性
           |-- Agent 5: テストカバレッジ
           |-- Agent 6: 無指定監査（3 ペルソナ: 6a/6b/6c）
           '-- Agent 7: ビルドとテスト（シェルコマンドを実行）
Step 5:  重複排除 --> バッチ検証 --> 集約              [LLM 呼び出し 1 回]
Step 6:  反復リバース監査（1〜3 ラウンド、ギャップ検出） [LLM 呼び出し 1〜3 回]
Step 7:  検出結果と判定の提示
Step 8:  自動修正（ユーザー確認、オプション）
Step 9:  PR インラインコメントの投稿（要求された場合）
Step 10: レポートの保存 + 増分キャッシュ
Step 11: クリーンアップ（ワークツリーと一時ファイルの削除）

レビューエージェント

すべてのエージェントは並列で動作します（Agent 6 は 3 つのペルソナバリアントを同時に起動し、同一リポジトリレビューでは合計 9 つの並列タスクになります）。Agent 1〜6 の検出結果は 単一バッチ検証パス で検証されます（1 つのエージェントがすべての検出結果を一度にレビューし、検出数に関わらず検証コストを一定に保ちます）。検証後、反復リバース監査 が 1〜3 ラウンドのギャップ検出を実行します — 各ラウンドは前のラウンドの累積検出リストを受け取るため、後続ラウンドはまだ未発見のものに集中します。ループはあるラウンドで「問題なし」が返されるか、3 ラウンド（上限）後に停止します。リバース監査の検出結果は検証をスキップし（エージェントはすでに完全なコンテキストを持っているため）、高信頼度の結果として含まれます。

決定論的解析

LLM エージェントが実行される前に、/review はプロジェクトの既存のリンターと型チェッカーを自動的に実行します:

標準パターンに合わないプロジェクト（例: OpenJDK）の場合、/review は CI 設定ファイルを読み込んで、プロジェクトが使用するリント/チェックコマンドを検出します。ユーザーによる設定は不要です。

決定論的な検出結果には [linter] または [typecheck] のタグが付き、LLM 検証をスキップします — これらはグランドトゥルースです。

• エラー → Critical 重大度
• 警告 → Nice to have（ターミナルのみ、PR コメントとしては投稿されない）

ツールがインストールされていない、またはタイムアウトした場合はスキップされ、情報メモが表示されます。

重大度レベル

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

自動修正

検出結果を提示した後、/review は明確な解決策がある Critical および Suggestion の検出結果に対して自動修正を提案します:

Found 3 issues with auto-fixable suggestions. Apply auto-fixes? (y/n)

• 修正は edit ツールを使用して適用されます（ファイル全体の書き換えではなく、ターゲットを絞った置換）
• 修正後にファイル単位のリンターチェックが実行され、新たな問題が発生していないことを確認
• PR レビューの場合、修正はワークツリーから自動的にコミットされプッシュされます — ローカルの作業ツリーはクリーンなまま保たれます
• Nice to have と低信頼度の検出結果は自動修正されません
• PR レビューの送信には常に 修正前の判定（例: 「Request changes」）が使用されます。自動修正のプッシュが完了するまでリモート PR は更新されていないためです

ワークツリーの分離

PR をレビューする際、/review は現在のブランチを切り替える代わりに、一時的な git ワークツリー（.qwen/tmp/review-pr-<number>）を作成します。これにより:

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

クロスリポジトリ PR レビュー

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

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

これは軽量モードで実行されます — ワークツリーなし、リンターなし、ビルド/テストなし、自動修正なし。レビューは差分テキストのみ（GitHub API 経由で取得）に基づきます。書き込みアクセスがあれば PR コメントは引き続き投稿できます。

PR インラインコメント

--comment を使用して、検出結果を PR に直接投稿します:

/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 レビューには自動修正（Step 8）を使用してください — レビュー後にワークツリーがクリーンアップされるため、レビュー後の対話的な修正はできません。

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

プロジェクトごとにレビュー基準をカスタマイズできます。/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 レビューエージェント（1〜6）に追加基準として注入されます。PR レビューの場合、悪意のある PR がバイパスルールを注入するのを防ぐため、ルールはベースブランチから読み込まれます。

.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 コメントで既に議論された問題（人間のフィードバックの重複を避けるため）

設計哲学

沈黙はノイズより優れています。 すべてのコメントは読者の時間に値するものであるべきです。

• 問題かどうか不明な場合 → 報告しない
• リンター/型チェックの問題はツールで処理し、LLM の推測に頼らない
• N 個のファイルにわたる同じパターン → 1 つの検出結果にまとめる
• PR コメントは高信頼度のみ
• コードベースの規約に合致したスタイル/フォーマットの問題は除外