プルリクエスト（Git のブランチとレビュー）とは｜仕組みと試験のポイント・予想問題

シラバスの用語例には無い最終更新日 2026年10月3日予想問題へ ↓

プルリクエストは，Git を使った開発で，ブランチで行った変更を主となるブランチ（main など）に取り込む前に，レビューを依頼して承認を得る仕組みです。変更の内容・理由・議論・承認の記録が1か所に残り，自動テスト（CI）の結果もそこで確かめられます。サービスによってはマージリクエストとも呼びます。

シラバスでの扱い

「プルリクエスト」という語は，最新の応用情報技術者試験シラバス Ver.7.2（2026年1月8日公開）の用語例にもありません。土台になる語はそれより前から載っています。Git は「大分類2：コンピュータシステム」の OSS（システム開発・運用支援）の用語例に， 継続的インテグレーション（CI）は「大分類4：開発技術」のアジャイルの用語例に，2023年12月の改訂より前の Ver.6.3 の時点で載っています。

用語例は出題の範囲を限るものではなく，ゼロトラストやパスキーのように，用語例に無いまま出題された語もあります。当サイトが収録している過去問（令和7年度秋期まで）では，プルリクエストはまだ出題されていません。一方，Git と継続的インテグレーションは午前の選択肢に出ており，情報処理安全確保支援士の午後令和7年度春期問1（サプライチェーンのリスク対策）では，バージョン管理・CI/CD パイプライン・SBOM 作成の機能をもつ開発プラットフォームが事例の題材になっています。

出典：応用情報技術者試験シラバス Ver.6.3， IPA「試験要綱・シラバスについて」（いずれも2026年10月3日に確認）

Git の基本：コミットとブランチ

リポジトリ：ファイルと，その変更の履歴をまとめて管理する場所。Git は各開発者の手元にも履歴の全体を持つ分散型のバージョン管理システム
コミット：変更をひとまとまりとして履歴に記録すること。誰が・いつ・何を・なぜ変えたかが残る
ブランチ：履歴を枝分かれさせ，ほかの人の作業に影響を与えずに変更を進める仕組み
マージ：ブランチの変更を別のブランチに取り込むこと。同じ箇所を別々に変えているとコンフリクト（競合）になり，人が解消する

名前に「プル」とありますが，プルリクエストは「取り込んでほしい」という依頼のことです。リモートのリポジトリの変更を手元に取り込む Git の操作（pull）とは別物なので，取り違えないようにしましょう。

プルリクエストの流れ

作業用のブランチを作り，変更をコミットする
主となるブランチへの取込みを依頼するプルリクエストを作る（変更の目的・確かめたことを書く）
CI が自動で動く：ビルド，自動テスト，静的解析，依存するライブラリの脆弱性の検査など
レビュー：ほかの開発者が差分を読み，指摘や質問をする。直したらまたコミットする
承認を得て，CI もすべて成功したらマージする。必要なら続けて自動で配備する（CD）

多くのサービスでは，主となるブランチを保護し，「変更した本人以外の承認」と「CI の成功」をマージの条件にできます。これで，1人の判断だけで本番につながる変更が入ることを防げます（職務の分離）。 AI エージェントに作業させるときも，変更はプルリクエストとして出させ，人がレビューしてから取り込むのが基本です。

試験での問われ方（予想）

午前：プルリクエストの説明を，Git の pull・clone・revert などの操作と見分ける形。CI／CD の説明
情報処理安全確保支援士：ソフトウェアのサプライチェーン対策として，レビューの必須化，CI での自動検査，リポジトリの権限管理。 DevSecOps と結び付けて問われやすい
プロジェクトマネージャ・システムアーキテクトの午後：アジャイル開発の事例で，品質を確保する仕組みとしてのレビューと CI

近い論点で出題された過去問

Git や継続的インテグレーションが選択肢に出てくる問題です。

情報処理安全確保支援士午前Ⅱ 令和7年度春期問22アジャイル開発のプロジェクトで，ソースコードの品質を向上させるために，バグ，コードの重複，脆弱性…
午前Ⅰ（高度試験共通）令和5年度秋期問5IaC（Infrastructure as Code）に関する記述として，最も適切なものはどれか…
午前Ⅰ（高度試験共通）令和5年度秋期問16アプリケーションソフトウェアの開発環境上で，用意された部品やテンプレートを GUI による操作で…

予想問題（オリジナル）

当サイトが作ったオリジナルの問題です。IPA の過去問ではありません。

問1Git を用いたソフトウェア開発におけるプルリクエストの説明として，適切なものはどれか。

ア作業用のブランチで行った変更を主となるブランチに取り込む前に，変更内容の確認とレビューを依頼し，承認を得てから取り込むための仕組み
イ過去のある時点のコミットの変更を打ち消す新しいコミットを作り，誤った変更を取り消す操作
ウリモートリポジトリにある最新の変更を，手元のリポジトリに取り込む操作
エリポジトリ全体を変更の履歴ごと複製し，手元で作業できるようにする操作

正解と解説

正解：ア

プルリクエストは「この変更を取り込んでほしい」という依頼で，レビューと承認，CI の結果の確認がそこで行われます。

イ：revert の説明です。
ウ：pull（または fetch とマージ）の説明です。名前は似ていますが，プルリクエストとは別物です。
エ：clone の説明です。

問2主となるブランチに，不具合や悪意のある変更が1人の判断だけで取り込まれることを防ぎたい。リポジトリの設定として，最も適切なものはどれか。

ア主となるブランチへの直接の書込みを全開発者に許可し，問題が見つかった時点で変更を取り消す。
イ主となるブランチへの取込みはプルリクエストからだけとし，変更した本人以外の1名以上の承認と，CI による自動テストの成功を取込みの条件にする。
ウレビューは手間が掛かるので，リリースの直前にまとめて1回だけ行い，日々の取込みは条件を設けずに行う。
エ自動テストはリリース前の最終確認として1回だけ実行し，取込みのたびには実行しない。