本文へスキップ
Estontinc

公開日 4 分で読めます

小さなプルリクエストで速いリリースを:GitHubのスタック型プルリクエストで変わること

GitHubによると、スタック型プルリクエストを使うリポジトリではマージされるコードが9%増えました。仕組み、小さな変更が速くリリースされる理由、毎週リリースするための習慣をまとめます。

光る矢印とともに階段状に積み上がるガラスのブロック。小さなプルリクエストと速いリリースのイメージ

GitHubのスタック型プルリクエスト(stacked pull requests)が一般提供されました。2026年10月6日に発表されたこの機能では、大きな変更を小さく焦点を絞ったプルリクエストに分割し、個別にレビューしてまとめてマージできます。GitHubによると、プレビュー期間中にスタックを使ったリポジトリでは、同等のリポジトリと比べてマージされたコードが9%増えました。

ソフトウェア製品を運営しているなら、これが重要な理由はシンプルです。リリースが遅れるのは、たいてい大きな変更のところだからです。本記事では、GitHubの発表内容、スタックの仕組み、そして私たちが毎週クライアントに機能を届けるために実践しているレビュー習慣を紹介します。

GitHubが発表した内容

数字で見るスタック型プルリクエスト:スタックを使うリポジトリでマージされたコードが9%増加、上位1%のリポジトリでマージまでの時間が5%改善、上位1%の3分の2以上が利用
  • パブリックプレビュー開始以降、スタックを使うリポジトリでは、同等のリポジトリと比べてマージされたコードが9%増加しました。
  • 上位1%のリポジトリの3分の2以上がスタック型プルリクエストを使い、マージまでの時間が5%改善しました。
  • スタックの自動マージが今後数週間で順次提供され、リポジトリの要件を満たした時点でスタック全体をマージできるようになります。

スタック型プルリクエストの仕組み

スタック型プルリクエストの仕組み:変更を依存し合う小さなプルリクエストに分割し、各部分をレビューし、リベース時も承認を保持し、マージキューでまとめてマージ
  1. 変更を分割する: 大きな機能を、前のものの上に積み重なる複数の小さなプルリクエストに分けます。
  2. 各部分をレビューする: レビュアーは巨大な差分ではなく、焦点を絞った変更を1つずつ確認します。
  3. 承認を保持する: メインブランチが進んだ後に変更のないスタックをリベースしても、承認が保持されるようになり、リベースされたコミットも署名済みのままです。
  4. まとめてマージする: スタックは1つのマージグループとしてマージキューに入ります。スタックのベースブランチが削除された場合は、GitHubが自動的に付け替えます。

ターミナルやAIコーディングエージェントで作業する開発者向けに、GitHub CLIのgh stack拡張機能がGit worktreeに対応しました。

小さな変更が速くリリースされる理由

私たちの経験では、ソフトウェアプロジェクトの遅れの多くは、コードを書く工程ではなく待ち時間にあります。レビュー待ち、テスト待ち、そして誰かがリリースしても大丈夫だと確信できるまでの待ち時間です。数千行に及ぶ変更は誰もすばやく安全に確認できないため、大きな変更ほど長く待たされます。

小さく焦点を絞った変更は、その状況を逆転させます。レビューしやすく、テストしやすく、問題があれば元に戻しやすいからです。スタック型プルリクエストを使えば、各部分のつながりを保ったまま作業を分割できるため、大きな機能でもこの進め方が現実的になります。

リリースを速くするための習慣

リリースを速くするための習慣:変更を小さく保つ、1つのプルリクエストに1つの目的、すべての変更に自動テスト、1営業日以内のレビュー、フィーチャーフラグでのリリース、毎週の進捗デモ

私たちのプロジェクト経験にもとづいておすすめする習慣です。スタックの有無にかかわらず活用できます。

  1. 各変更を小さく保つ: 一度に読み切れる大きさにします。
  2. 1つのプルリクエストに1つの目的: バグ修正と新機能を一緒にしないようにします。
  3. すべての変更に自動テスト: CIパイプラインで実行し、レビュアーが基本的な確認ではなくロジックに集中できるようにします。パイプラインを健全に保つ方法は、GitHub Actionsの変更の記事で解説しています。
  4. 1営業日以内にレビューする: 変更が溜まらないようにします。
  5. フィーチャーフラグでリリースする: 完成までに複数回のリリースが必要な機能に有効です。
  6. 毎週進捗をデモする: 製品にお金を出す人が、形になっていく過程を確認できます。

ビジネスへの影響

プルリクエストが何かを知らなくても、その効果は実感できます。感じられるのはリズムです。小さくレビューされたステップで進めるチームは、毎週新しいものを見せられ、問題が起きてもすぐに直せます。開発パートナーを選ぶ際は、コードを書く速さだけでなく、変更をどうレビューしてリリースしているかを尋ねることをおすすめします。

新しい製品を計画中なら、MVP開発ガイドで、小さく始めて実際のフィードバックから育てる方法を解説しています。

Estontincのサポート

Estontincはマラン(インドネシア)のソフトウェア開発会社で、6年以上にわたり100件以上のプロジェクトと50社以上のクライアントを支援してきました。Web開発とカスタムソフトウェアのサービスでは、小さくレビューされたステップで開発し、すべての変更に自動テストを実行し、毎週のデモで進捗をお見せします。

ソースコードはお客様のものになり、固定価格のプロジェクトにはリリース後30日間の無料サポートが付きます。お問い合わせページから製品についてお聞かせください。24時間以内にご返信します。

よくある質問

GitHubのスタック型プルリクエストとは何ですか?

大きな変更を、互いに依存する小さなプルリクエストに分割できる機能です。それぞれを個別にレビューし、スタック全体をマージキューでまとめてマージします。GitHubは2026年10月6日にこの機能の一般提供を開始しました。

スタック型プルリクエストでチームは速くなりますか?

GitHubによると、プレビュー期間中にスタックを使ったリポジトリでは、同等のリポジトリよりマージされたコードが9%多く、利用している上位1%のリポジトリではマージまでの時間が5%改善しました。小さな変更はレビュー、テスト、取り消しも容易です。

なぜ小さなプルリクエストのほうがよいのですか?

小さなプルリクエストはレビューが速く、テストしやすく、問題があれば簡単に元に戻せます。大きな変更は誰もすばやく確認できないため、レビュー待ちが長くなりがちです。各変更を小さく、目的を1つに保つと、安定して頻繁にリリースしやすくなります。

機能をより速くリリースするにはどうすればよいですか?

変更を小さく目的を1つに保ち、すべての変更に自動テストを実行し、1営業日以内にレビューし、大きな機能にはフィーチャーフラグを使い、毎週進捗をデモします。これらの習慣で、コードを書いてからユーザーに届くまでの時間を短縮できます。

出典

この記事の事実と数値は、以下の公式情報に基づいています。

  • Web development
  • Custom software
  • CI/CD
  • GitHub
すべての記事を見る

アイデアを、動くソフトウェアに。

つくりたいものをお聞かせください。明確な計画、スケジュール、見積もりを無料でご提案します。

  • 無料相談
  • 24 時間以内に返信
  • NDA 締結可