古い記事や動画で /pr-comments を見かけて、今のClaude Codeで使えない理由を知りたい人向け
古い教材に /pr-comments が出てきたときに、今のClaude Codeでは削除済みだと判断し、代わりに「このPRのレビューコメントを確認して」と頼む。
/pr-comments は、GitHubのPRに付いたレビューコメントをClaude Code上で見るために用意されていたスラッシュコマンドです。ただし、現行の公式コマンド一覧では「v2.1.91で削除済み」と扱われています。今から覚えるなら、このコマンドを探すより、Claudeにそのまま「このPRのコメントを見て」と頼む流れを覚えるほうが実用的です。
このページで大事なのは、古い記事や動画に出てくる /pr-comments をそのまま真似しないことです。昔はPR番号やURLを後ろに書いて使えましたが、今のClaude Codeでは同じ操作が残っている前提で作業を組むと止まります。
噛み砕くと
昔の /pr-comments は、GitHubのレビュー欄をClaude Codeの画面内に持ってくるための呼び出しボタンでした。別画面でPRを開き、コメントをコピーして貼る手間を減らすための入口です。
でも今は、その入口ボタン自体が外されています。機能が消えたというより、「専用コマンドを覚えなくても、Claudeに普通に頼めばよい」という形に寄せられています。古い地図に載っている改札口が閉じられ、正面入口へ案内が変わったイメージです。
大事な前提：これは今から積極的に覚えるコマンドではない
公式コマンド一覧では、/pr-comments [PR] は「Removed in v2.1.91」と書かれています。つまり、手元のClaude Codeが新しければ、コマンド一覧に出てこない、または古い説明どおりには動かない可能性があります。
以前の説明では、現在の作業ブランチから対象PRを自動で見つけるか、後ろにPRのURLや番号を書いてコメントを表示する動きでした。さらに、GitHubを文字で操作する gh という道具が必要でした。
「GitHubのレビューコメントを確認したい」を例に、実際の手順を見る
ステップ1: まず今のClaude Codeで使えるか確認する
古い記事を見て /pr-comments を試す前に、Claude Codeの入力欄で / を打ち、候補に出るか確認します。候補に出ないなら、今の環境ではこのコマンドを前提にしません。
/候補一覧に /pr-comments が見当たらない場合、そこで探し続ける必要はありません。公式上も削除済みなので、別の頼み方へ進みます。
ステップ2: Claudeに普通の文で依頼する
次に、コマンドではなく依頼文として伝えます。たとえば、今いる作業フォルダがGitHubのPRとつながっているなら、次のように頼みます。
このブランチのPRについたレビューコメントを確認して、対応が必要なものを優先順に並べてClaudeは必要に応じてGitHubの情報を取りに行こうとします。認証や gh が未設定なら、その時点で「先に何を整えるべきか」を聞けます。
ステップ3: PR番号やURLが分かるなら一緒に渡す
対象のPRが分かっているなら、番号やURLを文の中に入れます。古い /pr-comments 123 の代わりに、普通の依頼として書けば十分です。
PR #123 のレビューコメントを確認して、修正が必要な指摘だけ抜き出してここで初心者が勘違いしやすいのは、「専用コマンドがないとPRコメントを見られない」と思うことです。今は専用入口より、Claudeへの自然な依頼のほうが公式の案内に合っています。
ステップ4: 直す作業まで任せるかを分けて頼む
コメントを読むだけなら「確認して、一覧にして」で止めます。修正まで進めたいなら、「どのファイルを直すか提案してから、私の確認後に進めて」と一段区切ると安全です。
レビューコメントを確認して、対応案だけ出して。まだファイルは変更しないでいきなり修正まで任せると、コメントの意図を取り違えたまま変更が入ることがあります。まず読む、次に方針、最後に修正の順に分けると判断しやすいです。
ステップ5: 自動対応したいなら別の入口を検討する
PRコメントやCI失敗を見張って自動で直したいなら、現行一覧では /autofix-pr という別の入口があります。これは単にコメントを表示するだけでなく、Claude Code on the webのセッションを作って修正を進めるためのものです。
ただし、読むだけの用途には重いです。レビューコメントを確認したいだけなら、まず自然文で頼むほうが軽く済みます。
つまり /pr-comments は何をしてくれるのか
- 以前やってくれた: GitHubのPRコメントをClaude Code内に表示する入口になっていました。
- 今は期待しない: 公式一覧では削除済みなので、新しい手順の中心には置きません。
- 代わりに使う考え方: Claudeに「このPRのレビューコメントを見て」と普通の文で頼みます。
使いどころ3シナリオ（具体題材で再現）
シナリオ1: 古いClaude Code解説を見ながら作業しているとき
YouTubeやブログで「/pr-comments を打てばレビューコメントが見られる」と説明されていても、今の公式一覧では削除済みです。候補に出ない時点で、その教材の該当部分は古いと判断します。代わりに「PR #123 のレビューコメントを確認して」と普通に頼めば、同じ目的に近づけます。
シナリオ2: GitHubレビューの指摘をまとめたいとき
レビューコメントが10件以上あると、どれが必須対応で、どれが相談なのか分かりにくくなります。この場合は「修正必須、質問、参考意見に分けて」と頼みます。/pr-comments を探すより、分類条件を文章で渡したほうが結果が使いやすいです。
シナリオ3: 自動修正まで任せたいとき
コメントを読むだけでなく、CI失敗やレビュー指摘を見て直すところまで進めたいなら、/autofix-pr や /review のほうが近い用途です。ただし、勝手に直してほしくない場面では「まず一覧だけ」と明示します。確認と修正を分けるのが重要です。
初心者が踏みやすい落とし穴
- ハイフン表記とアンダースコア表記を混同する。古い説明では
/pr_commentsと出る場合もありますが、現行一覧では/pr-commentsが削除済みとして載っています。どちらも今から中心にしません。 - 候補にないコマンドを探し続ける。
/の候補に出ないなら、まず公式一覧と現在のバージョンを疑います。 - コメント表示とレビュー実行を混ぜる。コメントを読むだけなら自然文で依頼し、レビューしてほしいなら
/reviewを検討します。 - 自動修正まで一気に頼む。レビューコメントは文脈依存の指摘も多いので、最初は一覧化と優先順位付けで止めるほうが判断しやすいです。
- GitHub認証が済んでいない。ClaudeがPR情報を取れない場合は、先にGitHub接続や
ghの準備が必要になります。 - 削除済みという事実を見落とす。このコマンドは「便利だから覚えるもの」ではなく、「古い情報に出てきたら読み替えるもの」と捉えるのが正解です。
書き方
PR #123 のレビューコメントを確認してやってみるとこうなる
入力
PR #123 のレビューコメントを確認して、修正が必要な指摘だけ抜き出して出力例
ClaudeがPRコメント確認に必要な情報を取りに行き、対応が必要なレビュー指摘を整理する。このページに出てきた言葉
- PR
- GitHubで、変更内容を確認してもらうためのページ
- レビューコメント
- PR上で確認者が残す指摘や質問
- gh
- GitHubを文字入力で操作するための公式道具
- 削除済み
- 公式一覧には残っていても、今から使う前提では案内されていない状態
- /review
- PRや変更内容をレビューしてもらうための現行コマンド
- /autofix-pr
- PRの失敗やレビューコメントを見て、自動修正用のWeb側セッションを作るコマンド
- Claude Code on the web
- ブラウザ側で動くClaude Codeの実行環境