プルリクエスト（PR）とは？目的・登場人物・基本の流れを解説

プルリクエスト（Pull Request、略して「プルリク」「PR」）とは、変更を本体のコードへ取り込む前に、チームへレビューを依頼する仕組みです。GitHubを使う開発チームで「PRを出しました」「レビューをお願いします」と聞いたら、この確認と合意の流れを指しています。

コードを書かないPM・非エンジニアも、PRの目的と登場人物を知ると、「レビュー待ちで進まない」「どの変更が本番に入るのか」といった会話を追いやすくなります。この記事では、作成者、レビュアー、承認する人が何をするのかを、身近な承認フローに置き換えて説明します。

この記事でわかること

プルリクエスト（Pull Request、PR）とは、「この変更をメインのコードに統合（マージ）してください」という申請の仕組みです。

ブランチで作業した変更を本体のコードに取り込む前に、チームメンバーに「確認してください」と申請します。申請を受けたレビュアーが内容を確認し、問題なければ承認・マージします。

GitHubなどのサービスでは、プルリクエストの画面上でコードのコメントや議論ができるため、コードレビューのプラットフォームとしても機能しています。

チームによっては、作成者とマージする人が同じ場合や、テストの自動チェックが承認条件に含まれる場合もあります。役割名よりも、誰が確認し、何がそろえば統合できるのかを確認しましょう。

社内の書類承認フローに例えてみます。

担当者が報告書を作成したら、上長に「確認・承認をお願いします」と申請します。上長が内容を確認して、修正が必要なら赤入れを返します。担当者が修正して再提出し、最終的に承認されたら正式書類として登録される。

プルリクエストの流れはこれと非常によく似ています。エンジニアが変更を申請 → レビュアーが確認・コメント → 修正があれば対応 → 承認 → 本体に統合、という流れです。

たとえばPMが「検索画面に項目を追加してほしい」と依頼した場合、PRには変更した画面、想定する利用者、確認してほしい点が書かれます。レビュアーはコードだけでなく、依頼内容と変更のつながり、影響が出そうな箇所を確認します。承認されてマージされるまで、変更は本体には反映されません。

プルリクエストには、コードの品質を保つための複数の役割があります。

コードレビュー：別のエンジニアが変更内容を見て、バグや設計上の問題を事前に発見する。ひとりでは気づけないミスや改善点を見つける機会になります。

知識の共有：PRを通じて「誰がどこを変更したか」「なぜその実装にしたか」がチームで共有されます。新しいメンバーのオンボーディングにも役立ちます。

変更の記録：PRにはタイトルと説明を書くため、後から「あの機能をいつなぜ変更したか」を追いかけられます。

PMや非エンジニアがPRを直接操作することは少ないですが、「今週はPRが5件マージされました」「レビュー待ちのPRが積んでいます」という状況が、開発の進捗状況を把握する一つの指標になります。

「プル」という言葉の意味が混乱する

プルリクエストの「プル」は「取り込む（pull）」という意味です。「変更を本体に取り込んでください」という申請がプルリクエストです。

レビューとマージが別であることを知らない

「PRを出した」＝「変更が反映された」ではありません。PRを出した後に、レビュー→承認→マージというステップがあります。マージが完了して初めてコードが本体に反映されます。

PRとイシュー（Issue）の違いがわからない

イシューは「やるべきこと・問題」を登録する機能、PRは「変更を申請する」機能です。「イシュー#123に対応するPR#456を出しました」という形で紐づけられることもあります。

PRを含むシステム開発の全体像を、用語と工程から整理したい方には次の講座もあります。