コードレビュー
/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: Determine scope (local diff / PR worktree / file)
Step 2: Load project review rules
Step 3: Run deterministic analysis (linter, typecheck) [zero LLM cost]
Step 4: 9 parallel review agents [9 LLM calls]
|-- Agent 1: Correctness
|-- Agent 2: Security
|-- Agent 3: Code Quality
|-- Agent 4: Performance & Efficiency
|-- Agent 5: Test Coverage
|-- Agent 6: Undirected Audit (3 personas: 6a/6b/6c)
'-- Agent 7: Build & Test (runs shell commands)
Step 5: Deduplicate --> Batch verify --> Aggregate [1 LLM call]
Step 6: Iterative reverse audit (1-3 rounds, gap finding) [1-3 LLM calls]
Step 7: Present findings + verdict
Step 8: Autofix (user-confirmed, optional)
Step 9: Post PR inline comments (if requested)
Step 10: Save report + incremental cache
Step 11: Clean up (remove worktree + temp files)レビューエージェント
| エージェント | 焦点 |
|---|---|
| Agent 1: 正確性 | 論理エラー、エッジケース、null 処理、競合状態、型安全性 |
| Agent 2: セキュリティ | インジェクション、XSS、SSRF、認証バイパス、機密データ漏洩 |
| Agent 3: コード品質 | スタイルの一貫性、命名規則、重複コード、デッドコード |
| Agent 4: パフォーマンスと効率 | N+1 クエリ、メモリリーク、不要な再レンダリング、バンドルサイズ |
| Agent 5: テストカバレッジ | 差分内の未テストコードパス、欠落している分岐カバレッジ、弱いアサーション |
| Agent 6: 無指向性監査 | 3つの並列ペルソナ（攻撃者 / 深夜オンコール / メンテナー）— 多次元的な問題を捕捉 |
| Agent 7: ビルドとテスト | ビルドおよびテストコマンドを実行し、失敗を報告 |
すべてのエージェントは並列で実行されます（Agent 6 は 3 つのペルソナバリアントを同時に起動し、同一リポジトリのレビューでは合計 9 つの並列タスクになります）。Agent 1～6 からの発見事項は、単一のバッチ検証パスで検証されます（1 つのエージェントがすべての発見事項を一度にレビューするため、発見事項の数に関係なく検証コストは一定に保たれます）。検証後、反復逆監査が 1～3 ラウンド実行され、ギャップの発見を行います。各ラウンドは前のラウンドからの累積発見事項リストを受け取るため、後続のラウンドは未発見の事項に集中します。ループは、ラウンドが「問題なし」を返した時点、または 3 ラウンド（ハードキャップ）に達した時点で停止します。逆監査の発見事項は検証をスキップします（エージェントは既に完全なコンテキストを持っているため）され、高信頼度の結果として含まれます。
決定論的分析
LLM エージェントの実行前に、/review はプロジェクトの既存のリンターと型チェッカーを自動的に実行します：
| 言語 | 検出されるツール |
|---|---|
| TypeScript/JavaScript | tsc --noEmit, npm run lint, eslint |
| Python | ruff, mypy, flake8 |
| Rust | cargo clippy |
| Go | go vet, golangci-lint |
| Java | mvn compile, checkstyle, spotbugs, pmd |
| C/C++ | clang-tidy (if compile_commands.json available) |
| Other | Auto-discovered from CI config (.github/workflows/*.yml, etc.) |
標準パターンに一致しないプロジェクト（例：OpenJDK）の場合、/review は CI 設定ファイルを読み取り、プロジェクトが使用する lint/check コマンドを特定します。ユーザーの設定は不要です。
決定論的分析の発見事項には [linter] または [typecheck] タグが付けられ、LLM 検証をスキップします。これらは確実な事実として扱われます。
- エラー → 重大度：Critical
- 警告 → Nice to have（ターミナルのみ表示、PR コメントには投稿されません）
ツールがインストールされていないかタイムアウトした場合、情報メッセージを添えてスキップされます。
重大度レベル
| 重大度 | 意味 | PR コメントとして投稿されるか？ |
|---|---|---|
| Critical | マージ前に修正必須（バグ、セキュリティ、データ損失、ビルド失敗） | はい（高信頼度のみ） |
| Suggestion | 推奨される改善 | はい（高信頼度のみ） |
| Nice to have | 任意の最適化 | いいえ（ターミナルのみ） |
低信頼度の発見事項は、ターミナル内の「Needs Human Review」セクションに個別に表示され、PR コメントとして投稿されることはありません。
自動修正（Autofix）
発見事項の提示後、/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 worktree（.qwen/tmp/review-pr-<number>）を作成します。これにより：
- ワーキングツリー、ステージされた変更、現在のブランチは一切変更されません
- 依存関係はワークツリー内にインストールされるため（
npm ciなど）、lint やビルド/テストが正常に動作します - ビルドおよびテストコマンドは分離された環境で実行されるため、ローカルのビルドキャッシュを汚染しません
- 何か問題が発生しても、ローカル環境には影響しません。ワークツリーを削除するだけで済みます
- レビュー完了後、ワークツリーは自動的にクリーンアップされます
- レビューが中断された場合（Ctrl+C、クラッシュなど）、次回同じ PR を
/reviewすると、古いワークツリーが自動的にクリーンアップされてから新規に開始されます - レビューレポートとキャッシュはメインのプロジェクトディレクトリに保存されます（ワークツリー内ではありません）
リポジトリ横断 PR レビュー
完全な URL を渡すことで、他のリポジトリの PR をレビューできます：
/review https://github.com/other-org/other-repo/pull/456これは軽量モードで実行されます。ワークツリー、リンター、ビルド/テスト、自動修正は使用されません。レビューは差分テキストのみ（GitHub API 経由で取得）に基づきます。書き込み権限がある場合、PR コメントの投稿は引き続き可能です。
| 機能 | 同一リポジトリ | リポジトリ横断 |
|---|---|---|
| LLM レビュー（Agent 1-6 + 検証 + 反復逆監査） | ✅ | ✅ |
| Agent 7: ビルドとテスト | ✅ | ❌ (no local codebase) |
| 決定論的分析（リンター/型チェック） | ✅ | ❌ |
| ファイル横断の影響分析 | ✅ | ❌ |
| 自動修正 | ✅ | ❌ |
| PR インラインコメント | ✅ | ✅ (if you have write access) |
| 増分レビューキャッシュ | ✅ | ❌ |
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 | LLM が各発見事項を対話的に修正 |
| 発見事項がある PR レビュー | post comments | PR インラインコメントを投稿（再レビューなし） |
| PR レビュー、発見事項なし | post comments | GitHub で PR を承認（LGTM） |
| ローカルレビュー、問題なし | commit | 変更をコミット |
注：fix these issues はローカルレビューでのみ利用可能です。PR レビューの場合は Autofix（ステップ 8）を使用してください。レビュー後にワークツリーはクリーンアップされるため、レビュー後の対話的な修正は不可能です。
プロジェクトレビュールール
プロジェクトごとにレビュー基準をカスタマイズできます。/review は以下のファイルからルールを読み込みます（優先順）：
.qwen/review-rules.md（Qwen Code ネイティブ）.github/copilot-instructions.md（優先）またはcopilot-instructions.md（フォールバック — 両方ではなく片方のみ読み込まれます）AGENTS.md—## Code Reviewセクション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 は前回のレビュー以降の変更のみを検査します：
# First review — full review, cache created
/review 123
# PR updated with new commits — only new changes reviewed
/review 123クロスモデルレビュー
モデルを切り替えて（/model 経由）同じ PR を再レビューする場合、/review はモデルの変更を検出し、スキップせずにフルレビューを実行します：
# Review with model A
/review 123
# Switch model
/model
# Review again — full review with model B (not skipped)
/review 123
# → "Previous review used qwen3-coder. Running full review with gpt-4o for a second opinion."キャッシュは .qwen/review-cache/ に保存され、コミット SHA とモデル ID の両方を追跡します。このディレクトリが .gitignore に含まれていることを確認してください（.qwen/* のような広いルールでも問題ありません）。キャッシュされたコミットが rebase で消去された場合、フルレビューにフォールバックします。
レビューレポート
同一リポジトリのレビューの場合、結果はプロジェクトの .qwen/reviews/ ディレクトリに Markdown ファイルとして保存されます（リポジトリ横断の軽量レビューはレポートの永続化をスキップします）：
.qwen/reviews/2026-04-06-143022-pr-123.md
.qwen/reviews/2026-04-06-150510-local.mdレポートには、タイムスタンプ、差分統計、決定論的分析の結果、検証ステータス付きのすべての発見事項、および判定が含まれます。
ファイル横断の影響分析
コード変更がエクスポートされた関数、クラス、またはインターフェースを変更する場合、レビューエージェントはすべての呼び出し元を自動的に検索し、互換性をチェックします：
- パラメータ数/型の変更
- 戻り値の型の変更
- 削除または名前変更されたパブリックメソッド
- 破壊的 API 変更
差分が大きい場合（>10 個の変更されたシンボル）、分析はシグネチャが変更された関数を優先します。
トークン効率
レビューパイプラインは、生成される発見事項の数に関係なく、LLM 呼び出し数を一定範囲内に抑えます：
| ステージ | LLM 呼び出し数 | 備考 |
|---|---|---|
| 決定論的分析（ステップ 3） | 0 | シェルコマンドのみ |
| レビューエージェント（ステップ 4） | 9（または 8） | 並列実行。リポジトリ横断モードでは Agent 7 をスキップ |
| バッチ検証（ステップ 5） | 1 | 1 つのエージェントがすべての発見事項を一度に検証 |
| 反復逆監査（ステップ 6） | 1-3 | 「問題なし」が返されるか、3 ラウンドの上限に達するまでループ |
| 合計 | 11-13（10-12） | 同一リポジトリ：11-13。リポジトリ横断：10-12（Agent 7 なし） |
ほとんどの PR は範囲の下限（逆監査 1 ラウンド）に収束します。上限は、異常なケースでのコスト暴走を防ぎます。
フラグが立たない項目
レビューは意図的に以下を除外します：
- 変更されていないコード内の既存の問題（差分のみに焦点を当てます）
- コードベースの規約に一致するスタイル/フォーマット/命名
- リンターや型チェッカーが捕捉する問題（決定論的分析で処理済み）
- 実際の問題がない主観的な「X を検討してください」という提案
- バグやリスクを修正しない軽微なリファクタリング
- ロジックが実際に分かりにくい場合を除く、ドキュメントの欠落
- 既存の PR コメントで既に議論されている問題（人間のフィードバックの重複を回避）
設計思想
沈黙は雑音に勝る。 すべてのコメントは、読者の時間に見合う価値があるべきです。
- 問題かどうか不明確な場合 → 報告しない
- リンター/型チェックの問題はツールで処理し、LLM の推測に頼らない
- N 個のファイルにまたがる同じパターン → 1 つの発見事項に集約
- PR コメントは高信頼度のみ
- コードベースの規約に一致するスタイル/フォーマットの問題は除外