プルリクエストとは?変更を提案する仕組み

プルリクエストって何をするもの?

プルリクエスト(Pull Request、略して「PR」と呼ばれます)は、「自分が書いたコードの変更を、みんなが使っている本流のコードに取り込んでほしい」と提案するための仕組みです。GitHubなどのコード共有サービスで使われています。

ポイントは、いきなり本流を書き換えるのではなく、いったん「提案」として出すところ。提案が出されると、他のメンバーがその中身を見て、コメントしたり質問したり、直してほしい箇所を指摘したりできます。納得できる形になったら、本流に取り込む(マージする)。この一連の流れの入り口がプルリクエストです。

雑誌の原稿にたとえると

雑誌の記事を書いて編集部に渡すときのことを想像してみてください。書いた原稿をそのまま印刷機に流し込む人はいません。まず編集者に渡して、「ここの表現が分かりにくい」「事実確認をしてほしい」といったやりとりをしてから、掲載が決まります。

プルリクエストはこの「原稿を編集部に出す」行為にあたります。原稿(コードの変更)、なぜこの原稿を書いたかの説明(PRの説明文)、編集者からの赤入れ(レビューコメント)、そして掲載決定(マージ)。この構造がそっくりなので、初めて触る人にはこのイメージで捉えてもらうと分かりやすいと思います。

だいたいの流れ

「ブランチ」は、本流のコードをコピーして作る作業用の枝分かれのことです。枝の上で作業しているあいだは本流に影響を与えないので、失敗しても安心。その枝の成果を本流に戻したいときにプルリクエストを出す、という関係になっています。

プルリクエストに書くこと

PRを作るときは、コードの差分だけでなくタイトルと説明文を書きます。ここが雑になると、レビューする人は「何のための変更なのか」を差分から推測するしかなくなり、レビューがとても大変になります。

• 何を変えたか:変更の要点を一言で
• なぜ変えたか:直したいバグ、追加したい機能、関連する課題のリンクなど
• どう確認したか:動作確認の手順やテスト結果

正直、最初のうちは「コードを見れば分かるでしょ」と思いがちなんですが、レビューする側は他の作業もしていて文脈を共有していません。説明文が丁寧なPRはレビューが早く回る、というのは経験的にかなりはっきり出ます。

よくあるつまずき

ひとつは、変更を詰め込みすぎること。バグ修正とリファクタリングと新機能を1つのPRに混ぜると、レビューする人はどこを見ればいいのか分からなくなります。目的ごとに分けて小さく出すほうが、結果的に早く終わります。

もうひとつは、レビューコメントを「否定された」と受け取ってしまうこと。指摘の対象はコードであって書いた人ではありません。逆に自分がレビューする側になったときも、「ここはこうした方がいい理由はこうです」と根拠を添えると受け取りやすくなります。

Claude Codeとの関わり

Claude Codeのようなターミナル上で動くコーディング支援ツールを使う場面でも、成果物の出し方としてプルリクエストが登場します。コードを直してもらったあと、その変更をブランチにコミットしてPRを作り、人間がレビューして取り込む。AIが書いたコードでも人のレビューを通すという点で、プルリクエストは変更内容を確認する関門として機能します。用語自体はGitやGitHubの世界のものですが、AIにコードを書かせる開発でも避けて通れない基本語彙です。