開発・エージェント

プルリクエストとは

この記事の結論

プルリクエストとは、別のブランチで行った変更を本流に取り込んでほしいと提案し、差分の確認と話し合いを経てからマージする仕組みです。
1件のプルリクエストには、変更の説明、コミットの並び、ファイルごとの差分、自動テストの結果、レビューのやりとりが1つの画面にまとまります。
AIが作った変更も、いきなり本流に入れずにプルリクエストを通すと、人が差分を読んでから取り込むかどうかを決められます。

ぷるりくえすと／Pull Request

別のブランチで行った変更を本流に取り込むよう提案し、確認と話し合いを経てからマージする仕組みです。

最終更新: 2026-09-26

プルリクエストとは何か（意味と読み方）

プルリクエストとは、ブランチで進めた変更を、本流のブランチに取り込んでほしいと提案するための仕組みです。読み方は「ぷるりくえすと」、英語では pull request と書き、略して「PR」「プルリク」と呼ばれます。

GitHub Docs の「pull request について」では、コードの変更をプロジェクトにマージするための提案と説明されています。Git本体のコマンドではなく、GitHubなどのホスティングサービスが用意している機能です。

GitLabでは同じ役割の機能を「マージリクエスト（MR）」と呼び、チームでコードをレビューし、議論し、変更を追跡する場所と説明しています。名前は違っても、提案してから取り込むという流れは共通です。

プルリクエストの仕組みと画面の見方

プルリクエストは「どのブランチの変更を、どのブランチへ入れたいか」の組で作ります。取り込み先をベース、取り込みたい変更がある側をヘッド（比較元）と呼びます。

作成すると、GitHubでは次のようなタブに情報が分かれて表示されます。

Conversation：変更の説明文、コメント、レビューの経過
Commits：このブランチに積まれたコミットの並び
Checks：自動テストやビルドの結果。CI/CDを設定しているとここに出ます
Files changed：ファイルごとの差分。レビューする人が主に読む場所です

レビューには3つの返し方があります。pull request レビューについて（GitHub Docs）によると、承認も差し戻しもしない「Comment」、マージしてよい状態を示す「Approve」、マージ前に対応が必要な点を示す「Request changes」です。管理者はマージ前の承認を必須にもできます。承認がそろうと、マージして本流に取り込みます。

AI開発でのプルリクエストの使い方

AIコーディングエージェントに作業を頼むときは、次の流れにすると取り込み前に確認の段階をはさめます。

作業用のブランチを作ってからAIに実装を任せる（例：git switch -c fix/login-error）
終わったらブランチをプッシュし、プルリクエストを作る。GitHub CLIなら gh pr create で作れます
説明文に「何のための変更か」「AIに何を頼んだか」「自分で確かめたこと」を書く
Files changed で差分を読み、自動テストの結果を見てから取り込む

説明文に Closes #12 のように書いておくと便利です。issue へのリンク（GitHub Docs）によれば、close・fixes・resolves などのキーワードでissueと結びつき、既定のブランチにマージした時点でそのissueが自動で閉じます。取り込み先が既定以外のブランチだと、このキーワードは無視されます。

複数のエージェントを並行で動かす場合も、1つの作業に1つのブランチと1件のプルリクエストを割り当てると、どの変更がどの依頼から来たかを追えます。役割の分け方は複数のAIコーディングエージェントをどう役割分担させるかで扱っています。

プルリクエストについてのよくある誤解

誤解：プルリクエストはGitの機能 → 実際：Gitそのものにはこの画面はありません。GitHubやGitLabなどのサービスが提供している機能です。
誤解：チーム開発でないと意味がない → 実際：1人でも、差分をまとめて読み直す場、テスト結果を確かめる場として使えます。AIが書いた変更を入れる前の関所にもなります。
誤解：出したらもう直せない → 実際：同じブランチにコミットを足してプッシュすれば、開いたままのプルリクエストに反映されます。
誤解：承認されたら中身は正しい → 実際：承認は、読んだ人がその範囲で問題を見つけなかったという意味です。確かめる観点はコードレビューのページにまとめています。

プルリクエストを出すときのコツ

小さく出す：1件に1つの目的だけを入れます。数十ファイルにまたがる差分は、読む側が細部まで追えなくなります。
途中なら下書きで出す：GitHubの下書き（Draft）プルリクエストはマージできない状態で共有でき、コードオーナーへのレビュー依頼も自動では飛びません。仕上がったら「Ready for review」に切り替えます。
説明文に確認方法を書く：どの画面で何をすれば変更を確かめられるかを書いておくと、レビューする側が迷いません。
自動テストを先に通す：Checks が赤いまま人に読んでもらうと、同じ指摘が何度も繰り返されます。

出典・参考資料

よくある質問

Q1. プルリクエストとは何ですか？
ブランチで進めた変更を、本流のブランチに取り込んでほしいと提案する仕組みです。差分、コミットの並び、自動テストの結果、レビューのやりとりが1つの画面にまとまり、確認が済んでからマージします。GitHubなどのサービスが提供する機能で、略してPRとも呼ばれます。

Q2. プルリクエストとマージリクエストは違うものですか？
呼び名が違うだけで、役割はほぼ同じです。GitHubではプルリクエスト、GitLabではマージリクエストと呼びます。どちらも、変更を提案し、レビューと話し合いを経てから取り込むための場所です。

Q3. プルリクエストを出したあとに修正できますか？
できます。同じブランチに修正のコミットを足してプッシュすれば、開いているプルリクエストにそのまま反映されます。作り直す必要はありません。

Q4. 下書き（Draft）のプルリクエストは何に使いますか？
作業の途中経過を共有したいときに使います。下書きの間はマージできず、コードオーナーへのレビュー依頼も自動では送られません。仕上がったらレビュー可能な状態に切り替えます。

Q5. 1人で開発していてもプルリクエストは使うべきですか？
使うと便利です。AIが書いた変更を本流に入れる前に、差分をまとめて読み直し、自動テストの結果を確かめる場になります。取り込んだ理由も説明文として後に残ります。