Windsurfに関連するコードレビューは、手元の変更差分を確認するQuick Reviewと、GitHub上のPRへコメントするWindsurf PR Reviewsを分けて選びます。名前が似ていても、対象の製品・エージェント・契約・開始条件は同じではありません。まず、どの差分をどこでレビューしたいかを決めます。
この記事は公式資料を基にした操作経路の整理です。実製品でのレビュー、GitHub連携、コメント投稿、CI実行は行っていません。レビュー依頼と確認ケースは説明用の架空例です。旧Windsurf Docsの対象ページは、確認時にDevin Docsへ転送されています。
目次
ローカル差分とGitHub PRで入口を分ける
表は横にスクロールできます
| レビューしたいもの | 公式で説明される入口 | 結果を確認する場所 |
|---|---|---|
| Devin Desktopでのローカル変更 | Devin LocalのQuick Review | エディター内の指摘と手元の差分 |
| GitHub Cloud上のPR | Windsurf PR Reviewsの連携 | GitHubのレビューコメントとPR差分 |
| 専用機能を使えない差分 | 利用可能なAIへの通常のレビュー依頼 | 返された指摘と対象コード |
通常のAIへのレビュー依頼は、専用機能と同じ独立性や提供条件を持つという意味ではありません。使える入口で確認範囲を明示し、結果をコードとテストへ戻して確かめる方法です。
レビュー前には、変更の目的、比較するベース、対象ファイル、受入条件をそろえます。ローカルには未保存・未反映の変更があり、PRにはまだ載っていない場合もあります。見てほしい変更が実際の対象差分に入っているかを確認してください。
Quick ReviewはDevin Local向けの機能
現行のQuick Review資料は、Devin Localによるローカル変更に対し、別のエージェントが差分を確認してエディターへ指摘を返すと説明しています。legacy Cascadeではサポートしないと明記されています。
対象の変更がある状態でQuick Reviewを選び、ドロップダウンからレビューモデルを選ぶのが公式の入口です。モデルによって費用条件が異なるため、選択画面と現在の契約を確認します。この記事では全モデルを無料とは扱いません。
画面にQuick Reviewがない場合は、同じ名前のボタンを探し続けず、使用中のアプリとエージェントを確認します。公式のDevin Local資料には、エージェントの提供が組織設定で制御される場合もあると説明されています。Quick Review自体の組織設定や利用モデルの制限も別に確認してください。
エージェントを切り替えれば、以前の会話や設定がすべて同じように使えるとは考えません。既存の作業を保ったまま、対象環境で利用可能なレビュー方法を選びます。
GitHub PR向けは、連携済みリポジトリかを確認する
Windsurf PR Reviewsの公式ページは、GitHub Cloudを使うTeams／Enterprise向けのβ機能として説明しています。同ページの冒頭ではDevin Reviewを新しいレビュー製品として推奨していますが、ここで両者を同じ機能とは扱いません。
Windsurf PR Reviewsを使う場合は、組織管理者がGitHub botを接続し、対象リポジトリを選ぶ設定が必要です。チーム設定のGitHub Integrationで、レビューの利用、自動レビューなどの設定を確認します。
個人のエディターに機能があることだけで、組織の全リポジトリにPRレビューが有効になるわけではありません。別のリポジトリで動いた場合も、対象のリポジトリが選択されているかを確認します。
まずは使ってみる
記事の文脈に合うToolへ進めます。報酬の有無で見た目は変えていません。
Windsurf
手動開始と自動開始は、draftの条件が違う
有効なリポジトリでは、PRコメントに次を入力してレビューを依頼する方法が公式に案内されています。
/windsurf-review
これはPRへコメントを投稿する操作です。単に手元の差分を読むQuick Reviewとは異なり、GitHub側のPRを対象にします。
自動レビューは、チームのEnable Auto Reviewsがオンの場合に、非draftのPRを開いたとき、またはready for reviewへ変更したときに開始すると説明されています。draftでは自動開始せず、手動のコマンドで依頼する方法が案内されています。
公式ページは対象を50ファイル以下のPRとしています。利用枠の残りや個別条件はGitHub Integrationと現在の契約で確認してください。対象外の大きなPRを、内容の依存関係を無視して機械的に分割するのではなく、要件と呼出し側を一緒に読める単位を考えます。
表は横にスクロールできます
| 状況の例 | 先に確認すること | 早合点しないこと |
|---|---|---|
| draft PRで待っている | 手動依頼か自動開始か | 自動コメントがないから障害とは限らない |
| 非draft PRで反応がない | bot、対象リポジトリ、自動レビュー設定、利用枠 | 非draftなら必ず自動開始するわけではない |
| 51ファイルのPR | 対象ファイル数とレビュー方法 | 公式の50ファイル以下の条件を満たさない |
| ローカルの変更が指摘されない | その変更がPRへ含まれるか | 手元とPRが同じ差分とは限らない |
この表は設定と範囲を調べるための架空例です。各状況を実製品で再現した結果ではありません。
指摘を受ける前に、受入条件を渡す
どの経路でも、変更の目的が曖昧だと一般的な指摘だけが増える場合があります。レビュー用の説明には、期待する動作と、変えてはいけない部分を入れます。
対象は、商品一覧で非公開の商品を表示しない変更です。
比較対象と対象ファイルは、指定した差分です。
変更は加えず、公開状態の判定、呼出し側、既存テストを確認してください。
指摘には、該当ファイル、行、成立条件、ユーザーへの影響、根拠を付けてください。
欠陥候補、要件の不足、表現上の好み、実行未確認を分けてください。
問題が見つからない場合も、確認した範囲と未確認を示してください。
これは通常の依頼文の例で、PRコマンドへ自動で追加される特別な構文ではありません。Windsurf PR ReviewsにはPR Guidelinesの設定も案内されているため、チーム共通のレビュー方針と、個別PRの目的を分けて伝えます。
指摘は、成立条件とコードの経路で確かめる
たとえば「非公開の商品が漏れる」という指摘があっても、実際には呼出し側で除外しているかもしれません。反対に、一覧だけ直し、検索APIの別経路で残っている場合もあります。指摘の文面だけで修正せず、対象コードと関連する呼出しを確認します。
確認は次の順に進めます。
- 指摘が今回の差分と受入条件に関係するか。
- どの入力・権限・状態で問題になるか。
- 既存の条件分岐やガードで防がれていないか。
- テストまたは手動確認で、期待する動作を確かめられるか。
- 修正後に要件外の変更が増えていないか。
AIの「問題なし」も、テストや承認の代わりにはなりません。レビューが読んだ範囲、実行された検証、未確認の経路を分けて残します。実行していないテストを合格とせず、指摘を採用しない場合も理由を記録します。
レビュー後に変更を追加したなら、以前のレビューが現在の差分を確認したことにはなりません。どの時点の差分へ指摘が付いたかをそろえ、必要な再確認を行ってから、チームの通常の承認手順へ進みます。
確認した公式情報
- Quick Review：Devin Local対象、実行と組織設定（新しいタブで開く）
- Windsurf PR Reviews：β対象、GitHub連携と開始条件（新しいタブで開く）
- Devin Local Agent：エージェントと組織の提供条件（新しいタブで開く）
資料確認日：2026年10月21日。製品名、提供条件、利用モデル、費用、利用枠は更新されるため、使っている環境の公式資料と組織設定を確認してください。