目次

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

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

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

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

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 を見ているのか

PRの状態（未作成・オープン・マージ済み・クローズ済み）は GitHub のサーバー側にしか無い。Claude Code は その都度 GitHub に問い合わせて取得し、画面のバッジやボタンに反映している。問い合わせの経路は、Anthropic のデスクトップアプリのドキュメントと Claude Code の CHANGELOG に書かれていて、どちらも GitHub CLI（gh）が要になる（2026年9月30日に原文で確認）。

画面PR の状態の取り方出典
デスクトップアプリの Code タブ（「PRを作成」・CI の状態バー）gh でチェック結果を定期的に取りに行く／gh がインストール済み・認証済みであることが前提（未導入なら、最初にPRを作ろうとしたときにインストールを促される）デスクトップアプリのドキュメント「Monitor pull request status」
ターミナル版（CLI）の入力欄の下の PR バッジ通常は gh pr view／Bedrock・Vertex・Foundry 経由のとき、またはテレメトリを切っているときは gh auth token・GH_TOKEN・GITHUB_TOKEN のトークンで GitHub API を直接呼ぶCHANGELOG 2.1.251
同じ PR バッジの確認の頻度PR が変わらない間は確認の回数を減らす／push や gh pr のコマンドの実行ですぐ更新／ターミナルに戻ったときの再確認は、前回から1分未満なら省くCHANGELOG 2.1.248・2.1.247

つまり 「gh が入っている・gh が認証済み・ネットワークが通る・リモートに対象のブランチとPRがある」の4つが揃って初めて PR の状態を取れる。どれか1つが欠けると冒頭の赤帯になる。なお gh のトークンは、既定のブラウザ認証では OS の資格情報ストアに保存され、使えないときだけ平文のファイルに書かれる（保存先は gh auth status で分かる。GitHub CLI マニュアル gh auth login）。

公式に書かれていないこと

デスクトップアプリが どの間隔で問い合わせるか、どの失敗で「無効なリクエスト」と出すかの細部は、2026年9月30日時点の公式ドキュメントには書かれていない。本記事の切り分けは、上の表の 書かれている部分（gh の有無・認証・接続）に基づいている。

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

「PRステータスを確認できない」状況に至る経路は、おおむね6つに整理できる。上から順に確かめると早い。

6 ROOT CAUSES

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

CAUSE 1 · gh が入っていない
デスクトップアプリの PR の監視は gh が入っていて認証済みであることが前提（公式）。gh --version が通らなければ未導入。cli.github.com から入れる。
CAUSE 2 · 未ログイン・トークンの失効
gh に ログインしていない、またはトークンが失効している。GitHub は 1年使われていないトークンを自動で失効させ、PAT は作成時に決めた期限で失効する（GitHub Docs）。gh auth status で分かる。
CAUSE 3 · PRがまだ無い／push未済
ブランチが リモートに上がっていない、または PR を作成していない。「状態」が存在しないので取得できない。作業ブランチが既定ブランチ（main など）そのものなら、比較先と同じなので PR は作れない。
CAUSE 4 · ネットワーク/プロキシ
社内プロキシ・VPN・オフライン・DNS で api.github.com に届かない。他のGit操作も失敗するなら、ほぼこれ。
CAUSE 5 · トークンの権限不足（PAT のとき）
既定のブラウザ認証の gh auth login なら repo・read:org・gist は最初から付く（公式の最低限）。足りなくなるのは PAT を --with-token や GH_TOKEN で渡しているとき。fine-grained PAT は許可したリポジトリにしか届かない。
CAUSE 6 · 一時的な失敗（無害なことが多い）
GitHub の API レート制限・一過性の通信エラー・古い表示。gh も認証もネットも生きているなら、たいてい 少し待って再試行で消える。

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

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

赤帯が出たら、上から順に4ステップで切り分ける。STEP 1 と STEP 2 で CAUSE 1〜3 を確かめられる。

4 STEPS

切り分けの順番

STEP 1 · gh と認証を確認
gh --version で gh が入っているか、gh auth status で認証を確認。問題があれば終了コード1で理由が出る。gh auth login で再ログイン。
STEP 2 · push と PR の有無
git push -u origin <branch> でリモートに上げ、gh pr view か gh pr status で PRが存在するかを確認。無ければ作ればよい。
STEP 3 · 接続と権限
VPN/プロキシを切る・別回線で試す。PAT を使っているなら 権限を見直す（classic は repo・read:org・gist）。ブラウザ認証なら gh auth refresh で最低限のスコープに整え直せる。
STEP 4 · 待つ／再試行
1〜3 が問題なければ 一過性。少し待って再操作、または Claude Code を 最新版に更新して再起動。

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

補足：このバナーが出ても 手元のコミットや作業ツリーは無事だ。慌てて git reset したり、セッションを破棄したりする必要はない。まず接続を直し、改めて「PRを作成」を押す。どうしてもGUIで作れないときは、ターミナルで gh pr create を実行すれば、Claude Code の画面操作を介さずにPRを作れる。ブランチがまだ push されていなければ、gh pr create がどこへ push するかを尋ねてくる（GitHub CLI マニュアル）。

5. コマンド早見表

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

目的コマンド見るポイント
gh が入っているかgh --versionバージョンが出るか（出なければ cli.github.com から入れる）
認証が生きているかgh auth status「Logged in to github.com」が出るか／問題があれば終了コード1
再ログインgh auth login既定はブラウザ認証（repo・read:org・gist が付く）
スコープを整え直すgh auth refresh最低限のスコープ（repo・read:org・gist）を揃え直す
リモート設定の確認git remote -vorigin が正しい GitHub リポジトリを指すか
ブランチを上げるgit push -u origin <branch>PRが存在し得る前提を満たす
今のブランチのPRgh pr viewターミナル版の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 view が正常に応答するなら、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. 再発防止チェックリスト

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

① 新しい端末では、Claude Code でPRを作る前に gh を入れて gh auth login まで済ませる。② gh auth status を 時々確認する習慣をつける（GitHub はトークンを1年使わないと失効させ、PAT は作成時に決めた期限で失効する）。③ PAT を使うなら、classic は repo・read:org・gist を付けて作る。fine-grained PAT は対象のリポジトリを許可に含める。④ 環境変数 GH_TOKEN・GITHUB_TOKEN に 古いトークンを残さない（保存済みのログインより優先される。GitHub CLI マニュアル）。⑤ 新しいブランチで作業を始めたら、早めに git push -u origin <branch>。⑥ 社内ネットワーク（プロキシ・VPN）では gh api rate_limit で 疎通を一度確認。⑦ Claude Code を 最新版に保つ——PR バッジの取り方は CHANGELOG のとおり何度も変わっている。⑧ どうしてもGUIが不安定なら、PR作成は gh pr create に切り替える。

まとめ

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

最短の切り分けは ① gh --version と gh auth status で gh と認証を確認、② git push ＋ gh pr view で 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を一時的に切って切り分けるのも有効です。

Q. ターミナル版の入力欄の下にある PR バッジが古いままです。
A. CHANGELOG によると、このバッジは PR が変わらない間は確認の回数を減らし、push や gh pr のコマンドを実行するとすぐ更新します（2.1.248）。更新されないなら、ターミナルで gh pr view が通るか確かめてください。Bedrock・Vertex・Foundry 経由やテレメトリを切っている場合は gh pr view ではなく gh auth token・GH_TOKEN・GITHUB_TOKEN のトークンで API を直接呼ぶので（2.1.251）、そのトークンが有効かを確かめます。

Q. gh auth status は正常なのに PR の状態が取れません。
A. 使われているトークンの範囲を疑ってください。fine-grained PAT は許可したリポジトリにしか届かないので、ログインが有効でも対象のリポジトリの PR は読めません。また gh は環境変数 GH_TOKEN・GITHUB_TOKEN があると 保存済みのログインより優先して使います（GitHub CLI マニュアル）。意図しないトークンが入っていないか確認しましょう。

関連するClaude Codeエラー：Claude Codeエラー大全、Unable to connect、529 Overloaded / 500。