{"meta":{"title":"スタックされたプルリクエストについて","intro":"大規模なコード変更を、個別に確認およびマージできる、より小さな依存プル要求のチェーンに分割します。","product":"Pull Request","breadcrumbs":[{"href":"/ja/pull-requests","title":"Pull Request"},{"href":"/ja/pull-requests/get-started","title":"概要"},{"href":"/ja/pull-requests/get-started/about-stacked-prs","title":"PRを積み重ねる方法について"}],"documentType":"article"},"body":"# スタックされたプルリクエストについて\n\n大規模なコード変更を、個別に確認およびマージできる、より小さな依存プル要求のチェーンに分割します。\n\n> \\[!NOTE] この機能はパブリック プレビュー段階であり、変更される可能性があります。\n\n## 積み重ねられたプルリクエストについて\n\nスタックされたプル要求は、同じリポジトリ内の 2 つ以上のプル要求です。次に示します。\n\n* 最初または一番下の pull request は、スタックのトランク (通常はリポジトリの既定のブランチ ( `main`など) を対象としますが、リリース ブランチなどの任意のブランチを指定できます。\n* 後続の各プル要求は、その下のプル要求の分岐を対象とします。\n\n```text\n ┌── feat/frontend → PR #3 (base: feat/api-endpoints) ← top\n ┌── feat/api-endpoints → PR #2 (base: feat/auth-layer)\n ┌── feat/auth-layer → PR #1 (base: main) ← bottom\nmain (default base branch)\n```\n\n積み上げ分岐は依存関係チェーンを形成し、各分岐は、その下の分岐に基づいて構築されます。 共有型やデータベース スキーマなどの基本的な変更は下位ブランチに配置され、API ルートや UI コンポーネントなど、それらに依存するコードはより上位のブランチに配置されます。\n\nスタック内の各プル要求は、1 つ以上のコミットの個別のレビュー可能な変更を表します。 各プル要求を個別に確認して反復処理できます。各プル要求には、そのレイヤーの差分と、その下のブランチとブランチの間の変更のみが表示されます。\n\n**重要な原則:** あるレイヤーのコードが別のレイヤーのコードに依存している場合、依存関係は同じ分岐または下位の分岐にある必要があります。 これまで作成した内容に依存する別の作業に着手するときは、新しいブランチを作成します。 たとえば、バックエンドからフロントエンドの作業に切り替える場合、コア ロジックからテストに移行する場合、または現在のブランチが既に確認できる大きさである場合などです。\n\n## なぜ GitHub スタックされたプルリクエストを使うのか\n\n### 1 つの変更を完了し、次の変更に直接移動します\n\nスタック プル要求を使用すると、まだ開いているプル要求の上に新しいプル要求を開きます。 大規模なプロジェクトでは、次の変更は、まだマージされていない作業によって異なります。 マージを待つ代わりに、スタックを使用してビルドを続けることができます。\n\nスタック内の各プル要求に 1 つの重点的な変更が含まれていると、レビュー担当者は、大きなプル要求ではなく、レイヤーごとに小さな差分を確認します。 プルリクエストが小さいほど、レビューは速くなり、ざっと目を通される可能性が低くなり、古くなったりマージ競合が発生したりする可能性も低くなります。\n\n### 大量の開発に適しています\n\n多くの場合、AI エージェントを使用して多数のコードを一度に生成すると、スタックによって各変更の実行場所が提供されます。 エージェントは 1 つのタスクを完了し、そのタスクに基づいて次のタスクを開始します。 このシーケンスはスタックに直接マップされます。タスクごとに 1 つの pull request が、それぞれ以下のものに基づいています。 スタックを使用すると、関連のない変更を 1 つのブランチに結合するのではなく、これらの依存関係を明示的に記録できます。\n\n### GitHub で積み重ねられたプル リクエストを使用する利点\n\nプル要求がスタックされていない場合、大きな変更をより小さい依存プル要求に分割すると、追加の作業が作成されます。\n\n* **ブランチ管理。** 依存関係にあるプルリクエスト間でブランチをリベースし、同期を保つのは面倒で、ミスが起こりやすいです。\n* **規則と CI。** ブランチ保護規則と CI チェックは、多くの場合、チェーン内の下位プル要求に対してのみトリガーされるため、残りの部分の真の状態を把握するのが難しくなります。\n* **コンテキストを確認します。** スタック内の他の変更との関連を見ずに単一の変更だけをレビューすると、レビューの品質が低下する可能性があります。\n\nスタック プル要求では、プル要求のチェーンを接続ユニットとして扱い、各レイヤーを小さく集中させ、これらの問題に対処します。\n\n#### リベース\n\nリベイシングはスタックを操作する最も難しい部分であり、 GitHub はそれを自動的に処理します。 プル要求からサーバー側のカスケード リベースをトリガーすることも、`gh stack`の GitHub CLI 拡張機能を使用してローカルのカスケード リベースを実行することもできます。 スタックの下部にある pull request をマージすると、残りのブランチは自動的にリベースされるため、次のプル要求は既定のベース ブランチを対象とします。\n\n## スタックされたプル リクエストを使用できる場所\n\nスタックされたプル リクエストは、次の環境で利用できます。\n\n* GitHub CLI\n* GitHub の Web サイト\n* GitHub Mobile\n* Webhook、REST API、GraphQL を使用したプログラムによるサポート\n* エージェントの場合は、 `gh-stack` スキルを使用します\n\n> \\[!NOTE]\n>\n> * スタック プル要求では、すべてのブランチが同じリポジトリに存在する必要があります。 クロスフォーク スタックはサポートされていません。\n> * GitHub Desktopでは、スタックプル要求はサポートされていません。\n\n### GitHub CLI 内\n\n`gh stack`のGitHub CLI拡張機能は、ローカル開発ワークフローを処理します。 正しい依存関係の順序でブランチを作成および追跡したり、ブランチのリベースを維持したり、ブランチをプッシュしたり、プル要求を作成してリンクしたり、レイヤー間を移動することができます。 「[Stacked pull requests CLI コマンド](/ja/pull-requests/reference/stacked-prs-cli-commands)」を参照してください。\n\n### GitHub Web サイト\n\nプル要求がスタックの一部である場合、次の情報が表示されます。\n\n* プル要求の上部に、表示しているレイヤーを示す番号が付いたスタック アイコンが 。\n* マージ ボックスにスタック マップが表示されます。 スタック内のすべてのプル要求とその状態が表示され、ワンクリックで任意のレイヤーに移動できます。 トランク (既定のベース ブランチ) は一番下にあり、スタック内の各プル要求は、その下のプル要求のブランチを対象とします。\n\n### Webhook、REST API、GraphQL を使用したプログラムによるサポート\n\nスタック プル要求はプログラムで使用できるため、独自のツール、自動化、ダッシュボードに統合できます。\n\n* **Webhook** には、`stack`イベント ペイロードに`pull_request` オブジェクトが含まれているため、プル要求の結合、移動、スタックからの退出時にオートメーションが応答できます。\n* **REST API は** 、プル要求のスタック メンバーシップを読み取り、スタックの一覧表示、作成、拡張、およびディゾルブを行うエンドポイントを提供します。\n* **GraphQL API は** 、読み取り専用の `stack` フィールドをプル要求で公開し、スタックとその中のプル要求の位置を照会します。\n\n## ルール、CI、マージング\n\n### 規則と CI の適用\n\nスタック プル要求では、 GitHub Actions ワークフローがサポートされます。\n\nスタック内のすべてのプル要求のマージ要件は、最下位の pull request のベース ブランチ (通常は `main`) によって決定されます。\n\n* CODEOWNER 承認などのブランチ保護規則は、スタック内のすべてのプル要求 (既定のブランチを直接ターゲットにしていないミッドスタック プル要求でも) に適用されます。\n* 既定のブランチのプル要求によってトリガーされる CI チェックは、一番下の要求だけでなく、スタック内のすべてのプル要求に対して実行されます。\n\nこれにより、スタックのすべてのレイヤーが同じ品質バーを満たしてからマージできるようになります。\n\n### マージ\n\nスタック全体、1 つのプル要求、または複数のプル要求にまたがるスタックの一部をマージできます。 スタック全体を一度にマージする必要はありませんが、プル要求は一番下からマージする必要があります。\n\n* 上位の pull request をマージして、スタック全体を一度にマージします。 その下にあるすべてのプルリクエストは、それに含まれます。\n* スタック中段のプル要求をマージして、スタックの一部を取り込みます。 その下のプル要求もマージされ、上記のプル要求は開いたままになり、スタックのベース ブランチを自動的に再ターゲットします。\n\nスタックはマージ コミット、スカッシュ、およびリベース マージ メソッドをサポートしており、マージ キューに対応しています。 結果のコミット履歴は、一番下から始まる各プル要求を個別にマージする場合と同じです。\n\n> \\[!NOTE]\n> API を使用してマージし、スタックされたプル要求を使用する場合は、スタックに新しいマージ API を使用するように更新する必要があります。 「[Pull request 用 REST API エンドポイント](/ja/rest/pulls/pulls?apiVersion=2026-03-10#merge-a-pull-request-asynchronously)」を参照してください。\n\n## 次のステップ\n\n* [スタックプル要求のクイック スタート](/ja/pull-requests/get-started/stacked-prs-quickstart?utm_source=docs-pr-stacks-quickstart\\&utm_medium=docs\\&utm_campaign=stacked-prs-gtm-public-preview-2026)\n* [積み重ねられたプル要求を組織にロールアウトする](/ja/pull-requests/tutorials/roll-out-stacked-prs?utm_source=docs-roll-out-pr-stacks\\&utm_medium=docs\\&utm_campaign=stacked-prs-gtm-public-preview-2026)"}