--from-pr（フロム・ピーアール）

Claude Code に PR を作ってもらって、その後レビューコメントを受けて続きを直してほしい人向け

Claude Code に Pull Request を作ってもらった後、レビューコメントが返ってきた時に「あの PR を作った時の会話の続き」を呼び戻すための起動時指定が --from-pr です。Pull Request の番号（例: 123）か、PR のページ URL を1つ渡すだけで、その PR を作った当時の Claude との会話履歴がそのままロードされて、対話が再開できます。

「あの時 Claude にどういう指示で何を作らせたか」を覚え直さなくていい、というのが一番効く場面です。

噛み砕くと

料理ブログを書いてる人が、レシピ原稿を一度書き終えて担当編集者に渡したとします。数日経って編集者から「材料の単位を g に揃えてほしい」と赤入れが戻ってきた時、原稿の最初から書き直すんじゃなくて、その時の打ち合わせメモを引っ張り出して「あ、あの話の続きね」と再開しますよね。

--from-pr はそれを Claude Code でやる呼び出し方です。「メモを引っ張り出す目印」として PR 番号を使う、というだけ。

大事な前提：Claude が作った PR にしか効かない

これが一番引っかかりやすい点です。--from-pr で呼び戻せるのは「Claude Code が自分で gh pr create まで実行して立てた Pull Request」だけです。

人間が自分の手で立てた PR や、同僚が立てた PR には、Claude のセッション履歴が紐付いていません。Claude が PR を作った瞬間に、Claude Code 側が自動でセッションと PR 番号を結びつけて記録している、という仕組みだからです。

「料理ブログの新作レシピ投稿フロー」を例に、実際の手順を見る

毎週金曜に新作レシピを1本追加するブログを Claude に運用させる、という設定で動かしてみます。

ステップ1: Claude Code に「レシピ追加と PR 立て」を依頼する

自分のパソコンでブログのプロジェクト一式を開いて、ターミナルから claude と打って起動します。そこで次のような依頼をします。

春キャベツのペペロンチーノのレシピを recipes/ フォルダに追加して、
ブランチを切って Pull Request まで立ててください。
タイトルは「新作レシピ: 春キャベツのペペロンチーノ」で。

ステップ2: Claude が一気通貫で PR まで作る

Claude はだいたい次の流れを自動で進めます。

$ git checkout -b new-recipe-spring-cabbage
$ # recipes/spring-cabbage-peperoncino.md を作成
$ git add recipes/spring-cabbage-peperoncino.md
$ git commit -m "Add spring cabbage peperoncino recipe"
$ git push -u origin new-recipe-spring-cabbage
$ gh pr create --title "新作レシピ: 春キャベツのペペロンチーノ" --body "..."
https://github.com/your-name/cooking-blog/pull/123

最後に出てくる pull/123 の 123 が PR 番号です。この瞬間、Claude Code 側で「今のセッション ↔ PR 123」の紐付けが裏で記録されます。

ステップ3: 一旦 Claude Code を閉じて、GitHub 上で人間がレビュー

ターミナルを閉じて、ブラウザで GitHub の PR ページを開きます。担当編集者（または自分）がコードと文章を読んで、レビューコメントを残します。

材料の単位を「大さじ1」じゃなくて「g」で統一してください。
オリーブオイルは大さじ2 → 24g みたいに。

ステップ4: 数時間後、続きをやりたくなる（が、会話履歴は忘れた）

夕方にパソコンに戻ってきて、「さっきの PR の修正をやらないと」と思った時に困るのが、Claude Code のセッション ID（長い英数字の文字列）は覚えていないことです。--resume で再開しようにも、ピッカーには大量の過去セッションが並んでいて、どれが今朝の PR を作った時の会話なのか分かりません。

ここで初心者がやりがちな勘違いがあります。「自分の手で gh pr create した PR でも --from-pr で開ける」と思い込んで、まったく関係ない PR 番号を渡してしまうケースです。Claude が作っていない PR は紐付けが存在しないので、「該当する会話が見つかりません」相当のメッセージで終わります。

ステップ5: claude --from-pr 123 で一発復帰

覚えているのは PR 番号 123 だけ。これで十分です。

$ claude --from-pr 123

Claude Code が「PR 123 を作ったのは今朝のあのセッションだな」と引き当てて、その会話の続きから対話画面が立ち上がります。/resume のピッカーは出ません。PR 番号で一意に決まるからです。

ステップ6: 同じ会話の流れで修正を依頼

復帰した対話画面でそのまま頼みます。

編集者から「材料を g に統一して」と指摘が入りました。
recipes/spring-cabbage-peperoncino.md の材料欄を、
全部 g 表記に書き換えて、同じブランチに push してください。

Claude は朝に切ったブランチ new-recipe-spring-cabbage をそのまま使って、ファイルを修正 → 変更の保存区切りを追加 → push まで実行します。PR ページを再読み込みすると、修正版が反映されています。

つまり --from-pr は何をしてくれるのか

• やってくれる: 「Claude が立てた PR の番号 or URL」から、その PR を作った時の会話履歴を引き当てて、続きから対話を再開する
• やってくれない: 人間が立てた PR や、別の担当者の PR を Claude に「読ませて理解させる」こと。それは別の話で、--from-pr の役目ではない
• 意味が薄い場面: そもそも PR を1個も作っていないプロジェクトの初日。まずは claude で普通に始めて、Claude が PR を作るところまで進める必要がある

使いどころ3シナリオ（具体題材で再現）

シナリオ1: 料理ブログの記事追加 PR にレビューが入った

毎週金曜にレシピを1本追加する運用で、Claude が立てた PR に編集者がレビューコメントを返してきた時。コメントは GitHub 上に残っているので、レビューが返ってきてから何時間か経っていても、PR 番号 1 つあれば claude --from-pr 78 で当時の会話に戻れます。レビュー対応を毎回「ゼロから状況説明」する手間が消えます。

シナリオ2: 昨日のゲーム開発の続き、PR 番号は覚えてる

個人ゲーム開発で「当たり判定のバグ修正 PR」を Claude に立てさせた翌朝。session ID は覚えてないけど、ブラウザの履歴に pull/456 が残ってるので番号だけは分かる、というよくある状況。--resume で長いピッカーから当てるよりも、claude --from-pr 456 の方が圧倒的に速いです。

シナリオ3: 副業の在庫管理アプリで複数 PR を行き来する

在庫管理アプリに「商品登録機能の PR」「在庫アラートの PR」「CSV 取り込みの PR」を並行で立てさせていて、それぞれにレビューが返ってきている状態。claude --from-pr 12 → 商品登録の続き、終わったら一旦閉じて claude --from-pr 15 → 在庫アラートの続き、と PR 番号 1 つで切り替えられます。「どの session ID がどの機能だったか」を手元のメモで管理する作業が消えます。

初心者が踏みやすい落とし穴

• 人間が自分で立てた PR は開けない。--from-pr で呼び戻せるのは「Claude Code が gh pr create まで自分で実行した PR」だけ。自分が GitHub 上で「Create pull request」を押して立てたものや、同僚が立てた PR には会話履歴が紐付いていない
• 別プロジェクトの PR 番号を渡すと外れる。番号 123 はどのプロジェクトにもありがちな番号なので、今ターミナルでいる場所が「料理ブログ」なのに「在庫アプリの PR 123」を狙って番号だけ渡すと、別物に当たる or 見つからない。違うプロジェクトの PR を狙うなら、番号ではなく PR ページの URL を丸ごと渡す
• GitHub Enterprise / GitLab / Bitbucket は URL 渡し必須。社内 GitHub Enterprise や GitLab、Bitbucket で運用してる場合、番号だけ渡すと github.com 想定で誤認される可能性がある。claude --from-pr "https://github.your-company.com/team/repo/pull/123" のようにフル URL で渡すのが安全
• agent view の #123 入力欄とは別物。agent view（バックグラウンドで動かしている Claude セッション一覧画面）の指示入力欄に #123 と書くのは「PR 123 を扱うセッションを選ぶ or 新しく走らせる」操作。claude --from-pr 123 は「今のターミナルから PR 123 のセッションに戻る」操作。見た目は似てるけど用途が違う
• 該当セッションが消えていると失敗する。Claude Code のセッション履歴は約30日経つと自動で掃除される仕様なので、半年前の PR を --from-pr で開こうとしても「該当する会話が見つかりません」になる可能性が高い
• URL を渡す時は必ずダブルクオートで囲む。claude --from-pr 123 はそのまま打って大丈夫だけど、URL を渡す時は ? や & が混じることがあるので、claude --from-pr "https://github.com/foo/bar/pull/123" のように " で囲まないと、ターミナルが途中で文字列を切ってしまうことがある
• --continue --resume と同時に使わない。この3つは全部「過去セッションに戻る」系の指定なので、同時に書くと矛盾してエラーになるか、想定外の動きになる。最近の続き → claude --continue、session ID か名前で指定 → claude --resume、PR 番号で指定 → claude --from-pr と、何を起点に思い出すかで1つだけ選ぶ
• Claude が PR をまだ作っていない最初の作業ではそもそも使えない。初日 → 普通に claude で起動 → Claude に PR を立てさせる、まで進めて初めて --from-pr の対象になる。プロジェクト立ち上げ初日にいきなり --from-pr 1 と打っても何も起きない

書き方

claude --from-pr <PR番号 or PRページのフルURL>

やってみるとこうなる

入力

claude --from-pr 123

出力例

該当する Claude のセッションが見つかると、その PR を作った時の会話履歴がそのままロードされて Claude Code の対話画面が立ち上がる。<code>/resume</code> のピッカー（過去セッション一覧）は出ない。PR 番号や URL で1件に絞り込めるため。該当セッションが存在しない（人間が立てた PR、Claude が触っていない PR、約30日経過して掃除済みのセッション）場合は「No session found for PR 123」相当のメッセージで終了する。GitHub Enterprise や GitLab merge request、Bitbucket pull request の URL を渡したときも挙動は同じ

関連項目

• claude -r（クロード・アール）
• claude -c（クロード・シー）
• claude（クロード）
• claude agents（クロード・エージェンツ）
• --session-id（セッションアイディー）

公式ドキュメント

https://code.claude.com/docs/en/cli-reference