目次

Claude Code で機能を作り終え、差分は +2,148 −14、ブランチは main。あとは「PRを作成」を押すだけ——そのとき画面上部にこんな赤い帯が出た経験はないだろうか：

⚠ 無効なリクエスト
プルリクエストのステータスを確認できませんでした。
情報が古い可能性があります。

厄介なのは、「PRを作成」ボタンはまだそこにあるのに、現在のPR状態（未作成なのか、もう開いているのか、マージ済みなのか）が分からなくなること。コードの変更とは無関係に、突然「いまこのブランチがGitHub上でどうなっているか」だけが見えなくなる。

結論から書く：これは多くの場合『致命的なエラーではない』。Claude Code が GitHub に問い合わせて PRの最新状態を取りに行ったが、その1回が失敗しただけのことが大半だ。原因は GitHub への接続・認証（多くは gh CLI 経由）が一時的に通らなかったか、そもそもこのブランチにPRがまだ無い／リモートに push されていないかのどちらか。本記事では仕組み・5つの主因・切り分け手順・コマンド早見表・再発防止までを整理する。

CLAUDE CODE · PR STATUS

「PRステータスを確認できませんでした」の全体像

— GitHub に問い合わせて状態を取りに行く、その1回が失敗しただけ

症状
PR状態が不明
作成済みか未作成か 表示が古くなる
原因
GitHub未接続
gh 認証切れ or PR/push 未済
最初の一手
gh auth status
認証が 生きているか確認

本質は 「コードの問題」ではなく「GitHub への通信・認証の問題」。
作業（コード生成・コミット）はたいてい続行できる。慌てて新セッションを切る必要はない。

1. このエラーは何を言っているのか

エラー文を素直に読むと、こうだ：「いまこのブランチに対応するプルリクエストが、GitHub 上でどういう状態になっているのかを確認できなかった。だから画面に出している情報は古いかもしれない」。

ここで大事なのは、2つのことが起きていないと理解することだ。第一に、あなたのコードや差分が壊れたわけではない。+2,148 −14 の変更はそのまま手元にある。第二に、「PRの作成に失敗した」とは言っていない。これは「PRを作る前段として、現在のPR状態（未作成/オープン/マージ済み/クローズ済み）を読み取ろうとして失敗した」という 読み取り側の警告だ。

つまりこのバナーは 「同期できなかった」という性質のメッセージであり、多くは 一時的だ。私の見立てでは、この赤帯を見たときに最初に疑うべきは『自分のコード』ではなく『GitHub との接続状態』——具体的には認証が切れていないか、ネットワークが通っているか、そもそもこのブランチがリモートに上がっていてPRが存在し得る状態か、の3点である。

2. 背景：Claude Code はどうやって PR を見ているのか

なぜ「確認できない」ことが起こるのか。それは Claude Code が PRの状態を自分の中に持っているわけではないからだ。PRの真実は GitHub サーバー側にしか無い。Claude Code は その都度 GitHub に問い合わせて「このブランチのPRはどうなっている？」を取得し、画面のバッジやボタンに反映している。

この問い合わせの経路として、コマンドライン環境の Claude Code は GitHub公式CLI（gh コマンド）を使うのが基本だ。gh は自前で GitHub の認証トークンを保持し（~/.config/gh/hosts.yml など）、API 呼び出しを代行する。Claude Code から見ると 「gh が認証済みで、ネットワークが通っていて、リモートに正しいブランチがある」という前提が揃って初めて、PR状態を正しく取得できる。

正確を期すための注記

Claude Code の GUI が PRバッジを更新する内部処理の詳細（ポーリング間隔・キャッシュ戦略・エラー時の表示ロジック）は公式には文書化されていない。確かなのは「PR状態の取得には GitHub への有効な接続が要る」ことであり、実務上の切り分けは GitHub認証と接続性に集約される。本記事の対処はこの確かな部分に基づいている。

3. なぜ起きるのか——5つの主因

「PRステータスを確認できない」状況に至る経路は、おおむね5つに整理できる。上ほど遭遇しやすい。

5 ROOT CAUSES

PR状態を取れない5つの主因

CAUSE 1 · 認証切れ（最多）
gh のトークンが 期限切れ・失効・未ログイン。再起動やOS更新の後に起きやすい。gh auth status で一発で分かる。
CAUSE 2 · PRがまだ無い／push未済
ブランチが リモートに上がっていない、または PR を作成していない。「状態」が存在しないので取得できない。git push が先。
CAUSE 3 · ネットワーク/プロキシ
社内プロキシ・VPN・オフライン・DNS で api.github.com に届かない。他のGit操作も失敗するなら、ほぼこれ。
CAUSE 4 · 権限スコープ不足
ログインはできても、トークンに repo / read:org スコープが無い。プライベートリポジトリや組織で起きやすい。gh auth refresh で付与。
CAUSE 5 · 一時的な失敗（無害なことが多い）
GitHub の API レート制限・一過性の通信エラー・古い表示キャッシュ。認証もネットも生きているなら、たいてい 少し待って再試行で消える。

CAUSE 1〜4 は 設定・状態の問題（直せば再発しない）。
CAUSE 5 は 一過性。まず CAUSE 1（認証）と CAUSE 2（push/PR有無）から疑うのが最短。

4. 今すぐ直す——切り分けの手順

赤帯が出たら、上から順に4ステップで切り分ける。ほとんどは STEP 1 か STEP 2 で確定する。

4 STEPS

切り分けの順番

STEP 1 · 認証を確認
gh auth status を実行。「Logged in」が出なければ認証切れ。gh auth login で再ログイン。これで大半が解決。
STEP 2 · push と PR の有無
git push -u origin <branch> でリモートに上げ、gh pr status で PRが存在するかを確認。無ければ作ればよい。
STEP 3 · 接続とスコープ
VPN/プロキシを切る・別回線で試す。スコープ不足なら gh auth refresh -s repo,read:org で 権限を付与。
STEP 4 · 待つ／再試行
1〜3 が問題なければ 一過性。少し待って再操作、または Claude Code を 最新版に更新して再起動。

鉄則：「コードを疑う前に、GitHub への接続を疑う」。
STEP 1 の gh auth status が、最も速く真因に近づく一手。

補足：このバナーが出ても 手元のコミットや作業ツリーは無事だ。慌てて git reset したり、セッションを破棄したりする必要はない。まず接続を直し、改めて「PRを作成」を押す——それで通ることがほとんどだ。どうしても作成できないときは、CLI から手動で gh pr create を実行すれば、Claude Code の画面操作を介さずにPRを作れる。

5. コマンド早見表

切り分けに使うコマンドをまとめる。上から順に叩けば、どのCAUSEに該当するか自然に絞り込める。

目的コマンド見るポイント
認証が生きているかgh auth status「Logged in to github.com」が出るか／トークンスコープ
再ログインgh auth login対話式。ブラウザ認証が確実
スコープ追加gh auth refresh -s repo,read:orgプライベート/組織リポジトリで不足しがち
リモート設定の確認git remote -vorigin が正しい GitHub リポジトリを指すか
ブランチを上げるgit push -u origin <branch>PRが存在し得る前提を満たす
PRの有無・状態gh pr status現在のブランチにPRがあるか／open・merged
PRをCLIで作成gh pr createGUIを介さず直接作成（回避策）
疎通確認gh api rate_limit応答すれば接続OK／remaining でレート制限を確認

gh auth status が「Logged in」を返し、gh pr status が正常に応答するなら、Claude Code 側の表示が古いだけの可能性が高い。最新版に更新して再起動すれば、バッジは正しく同期し直す。

6. 「情報が古い」は無視していいのか

「情報が古い可能性があります」という一文は、状況によって意味が変わる。無視してよい場合と、対処すべき場合を見分けたい。

✅ 無視してよい（無害）

  • gh auth status が正常
  • 他のGit/push操作は問題なく通る
  • 少し待つ・再操作で消える
  • PRバッジが一瞬古く見えるだけ

→ 単なる 同期遅延・キャッシュ。作業を続けてよい。

⚠ 対処すべき（本物）

  • gh auth status が「not logged in」
  • push も pull も失敗する
  • 何度再試行しても消えない
  • 「PRを作成」を押しても進まない

→ 認証・接続の実害。STEP 1〜3 で修復する。

判定の決め手はやはり gh auth status 一発だ。ここが緑（Logged in）で、かつ他のGit操作が通るなら、バナーは 放っておいて構わない。逆に認証が落ちているなら、PR以外の操作（push・レビュー取得など）も遅かれ早かれ失敗するので、その場で直しておくのが得策だ。

7. 再発防止チェックリスト

同じ赤帯に何度も悩まされないための実践チェックリスト。

① gh auth status を 時々確認する習慣をつける（トークンは数十日で期限が来ることがある）。② プライベート/組織リポジトリを使うなら、最初から gh auth refresh -s repo,read:org で 必要スコープを付けておく。③ 新しいブランチで作業を始めたら、早めに git push -u origin <branch>（PRが存在し得る状態にしておくと表示が安定）。④ 社内ネットワーク（プロキシ・VPN）では gh api rate_limit で 疎通を一度確認。⑤ Claude Code を 最新版に保つ——表示・同期まわりの改善が継続的に入る。⑥ どうしてもGUIが不安定なら、PR作成は gh pr create に切り替える（最も確実）。

まとめ

Claude Code の 「プルリクエストのステータスを確認できませんでした。情報が古い可能性があります」は、コードの不具合ではなく、GitHub への問い合わせ（多くは gh CLI 経由）が一時的に通らなかったことを示す警告だ。多くは 無害な同期遅延だが、背後に 認証切れ・push/PR未済・ネットワーク・スコープ不足が隠れていることもある。

最短の切り分けは ① gh auth status で認証を確認、② git push ＋ gh pr status で push とPRの有無を確認、③ 接続・スコープを点検、④ 問題なければ待って再試行＋最新版更新。どうしてもGUIで作れないときは gh pr create で直接作ればよい。「コードを疑う前に、GitHub への接続を疑う」——これさえ覚えておけば、この赤帯はもう怖くない。

関連記事：GitHub Copilotとは、Claude Agent SDKとは、Claude Code の thinking blocks 400エラー、Claude Code / Cursor デプロイワークフロー も併読してほしい。

FAQ

Q. このエラーが出たら、書いたコードや差分は消えますか？
A. 消えません。これは「PRの状態を読み取れなかった」という通信側の警告で、手元のコミット・作業ツリー・差分（+2,148 −14 など）には一切影響しません。慌てて git reset やセッション破棄をする必要はありません。

Q. まず何を確認すればいいですか？
A. gh auth status です。これ一発で「GitHub認証が生きているか」が分かります。「Logged in」が出れば認証は無事——たいてい一過性なので待って再試行。出なければ gh auth login で再ログインすれば大半が解決します。

Q. 「情報が古い可能性があります」は放置していいですか？
A. 認証もネットワークも生きていれば放置してOKです。単なる同期遅延・キャッシュであることが多く、少し待つか再操作で消えます。ただし gh auth status が「not logged in」だったり、push まで失敗するなら、それは本物の不具合なので修復してください。

Q. 何度試しても「PRを作成」が通りません。
A. GUIを介さず gh pr create をターミナルから直接実行してください。これでPR自体は作れます。それでも失敗するなら git push -u origin <branch> でブランチがリモートに上がっているか、git remote -v で origin が正しいリポジトリを指しているかを確認します。

Q. 社内ネットワークで頻発します。原因は？
A. プロキシ・VPN・ファイアウォールが api.github.com への通信を遮っている可能性が高いです。gh api rate_limit が応答するか確認し、応答しなければネットワーク側の許可設定（GitHubドメインの許可リスト追加）が必要です。VPNを一時的に切って切り分けるのも有効です。