Claude CodeにQodoプラグインを入れてローカルレビューとPR指摘対応を回す

Qodoのskillsは、Claude Codeに「差分をQodoでレビューしてから引き渡す」「PRに付いたQodoの指摘を片付ける」という動きを足すプラグインです。レビューするのはQodoのサービスで、Claude Codeはその結果を読んで修正する側に回ります。

入れるだけでは動きません。Qodo CLIの導入とログインが別に要ります。この記事では、4つのskillの役割、Claude Codeへの入れ方、レビューから指摘対応までの流れ、そして勝手に進めさせない線引きを順に説明します。

Qodoのskillsは何を足すのか

配布元のリポジトリ(qodo-ai/qodo-skills)は、Qodoのローカル向けコーディングエージェントskillの正本です。Qodoがskillを1か所で書き、マーケットプレイスがプラグインを更新し、CLIが実行環境を更新するという分担になっています。

各skillには、レビュー済みの作業手順がすべて入っています。エージェントがタスクの指示をQodo CLIから取ってくることはなく、CLIが担うのは認証、管理されたツール、オフラインのツールヘルプ、実行環境の更新などです。

パッケージは2つに分かれます。

qodo-standardsは別途の任意導入です。コア側を更新しても勝手には入りません。

4つのskillの役割

コアのqodoパッケージにあるskillは、名前で役割がほぼ決まります。

任意のqodo-standards側には、ルールを検索して実装に反映するqodo-get-rulesと、標準を管理するqodo-manage-standardsがあります。

Claude Codeへの入れ方

入手経路は、Claude Codeの場合はQodo公式のマーケットプレイス掲載です。インストールと更新はマーケットプレイス側が持ちます。Qodo CLIは別に入れ、初回に qodo login を済ませます。

skills.sh経由の導入手順(npx skills add ...)もリポジトリにありますが、そちらが対象にするのは、公式掲載のない他のエージェントです。Claude Code、Codex、Kiroはマーケットプレイスが管理するため、検出対象から外れます。Claude Codeで npx skills add を使う場面は想定されていません。

セットアップを通す

プラグインを入れたら、qodo-setupが踏む順に確認すると詰まる場所が分かります。

qodo --version
qodo read whoami --json
qodo tools --refresh --json

2段目が通っても3段目が失敗することがあります。その場合の扱いも決まっていて、「サインインは成功したがツールが使えない」とエラーを添えて報告し、再試行は qodo tools --refresh で行います。ログインをやり直しはしません。

ローカルレビューをClaude Codeに回させる

qodo-reviewは、コミット前の変更も対象にしたレビューです。qodo review は追跡中の差分に加えて未追跡の新規ファイルを集め、ブランチ名、HEAD、コミットメッセージから作った説明、チケット参照、セッションの文脈を付けてQodoに送ります。シークレット、バイナリ、巨大ファイル、gitignore対象は除外され、除外したことも報告されます。

比較の基点になるコミットがリモートにあれば足り、ローカルの変更はpushもPR作成も要りません。

深さの選び方

レビューの深さは3通りです。

フラグなしの場合、深さはレビュー側が決めます。標準を固定する --standard というフラグはなく、自動の結果が深くなることもあります。自動が費用の上限を設けるわけでもないので、頻繁に回すとコストが読みにくくなります。

差分の大きさやセッションの長さ、セキュリティ関連のファイル名だけでは --deep の理由になりません。「競合状態を念入りに見てほしい」のような依頼や、複数サービスが使う契約を変える場合が該当します。

非同期の結果は1時間で消える

--async で投げた結果は、完了後1時間で破棄されます。期限を過ぎると、期限切れなのか最初から存在しないのかは区別できません。受け取りは qodo review status <operation-id> で行い、終了コード2は「まだ実行中」、1は失敗・取消・期限切れ・該当なしです。

チェックポイントは同時に1つだけにする運用です。進み具合を見たいからと新しいレビューを投げ直さず、status で確認します。

「なぜそうしたか」を渡す

qodo-reviewの要点は文脈です。コードを書いた直後のエージェントだけが持つ「なぜ」を、JSONで添えます。

{
  "summary": "ordersの書き込みに楽観ロックを入れ、二重課金の競合を直す",
  "decisions": [
    "ホットパスの競合を避けるため、テーブルロックではなくversion列を採用した",
    "リトライは3回までとし、超えたら呼び出し元にエラーを返す"
  ],
  "recent_work": ["楽観ロックを追加。この回から新しい挙動を含む"],
  "context_refs": [
    { "kind": "ticket", "url": "https://acme.atlassian.net/browse/PAY-412" }
  ]
}

(例示です。値は公式の書式例に沿って作った架空のものです。)

書き方には規則があります。「設計書のとおり」「先ほど話したとおり」のような参照は、レビュー側から見えないので役に立ちません。理由を1文で自己完結させます。また、この文脈は指摘を黙らせるためのものではなく、意図を説明して誤検知を減らすためのものです。「この実装は安全です」と主張する文は書かず、何を変えてなぜ選んだかだけを書きます。

.qodo/session-context.json に同じ形で置くと、--context-file を指定しない実行すべてに自動で添付されます。このファイルはレビュー対象の差分には含まれませんが、コミットはしない扱いです。.gitignore か .git/info/exclude に .qodo/ を足しておきます。

PRの指摘をClaude Codeに片付けさせる

PRを開いてQodoのレビューが付いたら、qodo-review-resolverの出番です。指摘を読むには、PRのコメントを gh や curl で拾うのではなく、構造化された読み出しを使うのが前提です。

qodo read pr-review-session findings --pr-url <PR_URL> --json

返ってくるものは2つです。review_session にはレビューの状態、レビュー対象のコミットSHA、開始時刻が入ります。findings には各指摘のID、タイトル、説明、カテゴリ、重大度(action_level)、現在の対応状況(attribution_status)、場所、根拠の引用が入ります。

読む前に確かめること

指摘を信じてよいのは、レビューが completed で、そのコミットSHAが今のPRのHEADと一致するときだけです。実行中(started)や、HEADより古いコミットを対象にした結果は、最新のコードを反映していません。review_session が null ならレビュー自体がまだ付いていないので、そこで止まります。

未対応か済みかは対応状況で見る

重大度と対応済みかどうかは別の軸です。

• 未対応として扱う: pending、partial_implementation、not_implemented、focus_areas_edited
• 対応済みとして触らない: implemented、full_implementation、dismissed、detected_after_merge、outdated

action_required の指摘でも、すでに implemented なら対応済みです。重大度の高い順は action_required、remediation_recommended、informational で、informational は任意扱いです。

修正はClaude Codeがコードを編集するだけなので、新しいコミットがpushされると、Qodoが新しいコミットを再レビューします。直した指摘は、次のレビューで自動的に対応済みに更新されるのが想定された経路です。

どこまで任せるか — 権限の線引き

このskillの設計で一番はっきりしているのは、勝手に閉じさせないことです。

記録系の2つのコマンドは意味が違います。

qodo pr-review-session mark-implemented --finding-ids <id>,<id> \
  --explanation "何を変えたか" --json
qodo pr-review-session dismiss --finding-ids <id> \
  --reason intentional --explanation "なぜ閉じるか" --json

mark-implemented は「コードを直した」、dismiss は「コードは直さず、理由があって閉じる」です。取り違えると、直っていない指摘が直ったことになります。--reason は false_positive(指摘が誤り)、intentional(意図したとおり)、deferred(正しいがこのPRの範囲外)、rejected(理解したうえで見送り)の4つで、--explanation も添えます。

どちらも、次のレビューで再判定されるまで待つ手が優先です。次のレビューが走らないままマージ判定を通す必要があるときだけ、記録で閉じる選択肢が出てきます。

Claude Code側に置く設定の例

ここからは、skillが書いていることをClaude Code側の設定に落とした例です。公式の文面そのものではなく、運用の組み立て方の一例です。

CLAUDE.mdには、いつレビューを呼ぶかと、何を勝手にしないかを書いておくと、skillの規則と食い違いにくくなります。

## Qodoレビュー
- 実装が一区切りついたら、`--fast --async` のチェックポイントを1つだけ出す。
- PRを開く前の最終レビューは深さのフラグを付けず、結果を読んでから引き渡す。
- `--deep` は理由を一文添えてから使う。
- 指摘のdismissとmark-implementedは、私が指示したときだけ実行する。
- 文脈JSONの `decisions` は、判断と理由を一文で完結させる。

権限は、読み取りと審査の実行だけを許可し、書き込みの2つは含めない形にできます。

{
  "permissions": {
    "allow": [
      "Bash(qodo --version)",
      "Bash(qodo read:*)",
      "Bash(qodo review:*)"
    ]
  }
}

これなら dismiss と mark-implemented の実行時には、Claude Code側の許可確認が出ます。skill側の「明示されなければ書かない」規則と二重になり、どちらかが緩んでも、片方が止めます。CLIのセットアップの手順(qodo-setup)には、ホストの権限ファイルを書き換えたり、無制限のコマンド許可を勧めたりしないという定めもあります。広く許可する設定は、skillの想定とは逆です。

更新はマーケットプレイス側で

プラグインの更新は、マーケットプレイスで取り込み、そのあと新しいセッションを始めます。CLIは qodo update で別に更新されます。skillの更新通知(QODO_NOTICE)は標準エラー出力に出る受け身の通知で、作業を止めて更新を勧めることはありません。

CLIの更新はskillの更新とは独立で、skillの更新を許可しただけではCLIのアップグレードは許可されません。2.0.0未満から入れ直す場合も、自動更新は同じメジャーバージョン内に限られるため、明示的な導入が要ります。

他のレビュー系プラグインとの置き場所

Claude Codeには、同じように「レビューを外部サービスに任せる」型のプラグインが他にもあります。

• Optibotプラグインはコードレビューの自動化を目的にしています。
• GreptileプラグインはPRレビューと知識ベースの参照を引けます。

Qodoの特徴は、レビューを受ける側(qodo-review)と、PRに付いた指摘を片付ける側(qodo-review-resolver)が、同じパッケージの別skillとして分かれ、指摘の状態をIDで追える点です。Claude Code自身のレビューとの比較はClaude Code ReviewとCodeRabbitの違いのようなサービス間比較の記事が参考になります。社内のレビュー体制全体の考え方はClaude Codeチームのコードレビューにあります。

まとめ

Qodoのskillsは、レビューの中身をQodo側に置き、Claude Codeを「差分を渡して結果を読み、直す」役に固定する作りです。使い始めるうえで先に決めておくと楽なのは、CLI 2.0.0以上とログインの準備、最終レビューを自動の深さに任せるか、そしてdismissの権限を誰が持つかの3点です。

自動で直させるのはコードの修正まで、指摘を閉じる操作は人が指示する。この分け方は、レビューの信用を保つための線として、設定の例のように権限側にも写しておけます。