コードレビュー

/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コスト0]
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設定ファイルを読み取り、プロジェクトが使用する lint/check コマンドを検出します。ユーザーによる設定は不要です。

決定的解析の結果には [linter] または [typecheck] のタグが付き、LLMによる検証をスキップします。これらは信頼できる事実です。

• エラー → Critical 重要度
• 警告 → Nice to have (ターミナルのみに表示、PRコメントには投稿されません)

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

重要度レベル

低信頼性の所見は、ターミナル内の別セクション「要人的確認 (Needs Human Review)」に表示され、PRコメントとして投稿されることはありません。

自動修正

所見を提示した後、/review は明確な解決策がある Critical および Suggestion の所見に対して自動修正の適用を提案します。

3つの自動修正可能な提案が見つかりました。自動修正を適用しますか？ (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レビュー

別のリポジトリのPRをレビューするには、完全なURLを渡します。

/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) に新しい所見がある) の場合のみ確認を求めます。これは同じコード行に視覚的な重複が発生する場合です。古いコミットのコメント、返信済みのコメント (解決済みとみなす)、新しい所見とまったく重複しないコメントはサイレントにスキップされ、フィルタリングされたことを示すターミナルログ行が出力されます。

承認前のCI/ビルドステータスチェック: 判定が「Approve」の場合、/review は送信前にPRのcheck-runsとcommit statusesを照会します。いずれかのチェックが失敗している場合 (または全チェックが保留中のままの場合)、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 の例:

# レビュールール
 
- すべてのAPIエンドポイントは認証を検証する必要がある
- データベースクエリはパラメータ化されたステートメントを使用する必要がある
- Reactコンポーネントはインラインスタイルを使用してはならない
- エラーメッセージは内部パスを公開してはならない

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

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

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

モデル間レビュー

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

# モデルAでレビュー
/review 123
 
# モデル切り替え
/model
 
# 再レビュー — モデルBで全レビュー (スキップなし)
/review 123
# → "前回のレビューでは qwen3-coder を使用しました。gpt-4o で全レビューを実行し、セカンドオピニオンを得ます。"

キャッシュは .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ラウンド) に収束します。上限は病的なケースでのコスト暴走を防ぎます。

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

レビューでは以下の項目は意図的に除外されます。

• 変更されていないコードの既存の問題 (差分のみに焦点)
• プロジェクトのコーディング規約に沿ったスタイル/フォーマット/命名
• リンターや型チェッカーがキャッチする問題 (決定的解析で処理)
• 本当の問題がない主観的な「〜を検討してください」といった提案
• バグやリスクを修正しない軽微なリファクタリング
• ロジックが本当に混乱しない限り、ドキュメントの欠如
• 既存のPRコメントですでに議論されている問題 (人間のフィードバックの重複を避ける)

設計思想

ノイズより沈黙を。 すべてのコメントは読者の時間に見合う価値があるべきです。

• 問題かどうか確信が持てない場合は → 報告しない
• リンター/型チェックの問題はツールが処理するものであり、LLMの推測ではない
• Nファイルにわたる同じパターン → 1つの所見に集約
• PRコメントは高信頼性のみ
• コードベースの規約に沿ったスタイル/フォーマットの問題は除外