{"meta":{"title":"プル要求で AI によって生成されたコードをスタックする","intro":"迅速に確認できる小規模な依存プル要求のスタックを作成します。","product":"GitHub Copilot","breadcrumbs":[{"href":"/ja/copilot","title":"GitHub Copilot"},{"href":"/ja/copilot/tutorials","title":"チュートリアル"},{"href":"/ja/copilot/tutorials/stack-ai-generated-code-in-pull-requests","title":"STACK AI pull requests"}],"documentType":"article"},"body":"# プル要求で AI によって生成されたコードをスタックする\n\n迅速に確認できる小規模な依存プル要求のスタックを作成します。\n\n> \\[!NOTE]\n> スタック プル要求は パブリック プレビュー であり、変更される可能性があります。\n\n大規模なプル要求は、特に AI が短時間で大量のコードを生成するのに役立つ場合に、ボトルネックを確認して作成することは困難です。 pull request サイズが大きくなると、レビューの品質も低下します。 レビュー担当者は、結果、ミスの問題、または先延ばしを回避し、古くなりマージ競合が発生するまで pull request を残すことができます。\n\nスタック プル要求では、大きなコード変更をレビュー可能な状態に保ちます。\n\nスタックは、同じリポジトリ内の一連のプル要求です。各プル要求は、その下のプル要求のブランチを対象とし、1 つのブランチ (通常はメイン ブランチ) に配置される順序付きチェーンを形成します。 1 つの大きなプル要求の代わりに、一連の小さなプル要求を取得します。 各プル要求には独自のフォーカスされた差分があるため、チームメイトは各レイヤーを個別に確認して承認できます。\n\nこのチュートリアルでは、エージェントと共にスタックプル要求を使用して、個別にレビュー可能なレイヤーに機能を構築する方法について説明します。 この例では、アプリにユーザー認証を追加する方法を検討します。\nGitHub Copilot CLIと`gh-stack` エージェント スキルを使用します。\n\n## 前提条件\n\nエージェントで `gh-stack` スキルを使用するには、まず、 GitHub CLI と `gh-stack` CLI 拡張機能をインストールする必要があります。 以下のものが必要です。\n\n* GitHub CLI (`gh`) 2.90.0 以降、および Git 2.20 以降。\n  * GitHub CLIを使用して`gh auth login`を認証します。\n* プッシュできる GitHub リポジトリ。\n* GitHub Copilot CLI インストールおよびサインイン済み。\n\nGitHub CLIで、`gh-stack`拡張機能とスキルをインストールします。\n\n```shell\ngh extension install github/gh-stack\ngh skill install github/gh-stack\n```\n\n> \\[!NOTE]\n> このチュートリアル全体を通して、 Copilot 実行するのではなく、自分でスタック コマンドを実行する場合は、 GitHub CLIを使用する必要があります。\n\n## 1. コードを生成する前にスタックを設計する\n\n良いスタックは、家を建て、強い基盤から始めて、壁をフレームに入れ、配線を取り付け、それからドライウォールを仕上げるようなものです。 構築された各レイヤーは、以下のものに依存します。 最後に、レビュー担当者は、下から上にプル要求を読み取り、一緒に表示される機能に従うことができる必要があります。\n\n* フィーチャをレイヤーに分割します。 各レイヤーは、単独で確認できる単一の一貫性のある変更である必要があります。\n  * 各レイヤーは、プル要求が簡単に読み取れるほど小さくします。 レイヤーがレビューに長い説明が必要だと感じる場合は、おそらく大きすぎる可能性があります。\n  * 自分で境界を決定するか、プランで Copilot を操作します。 どちらの方法でも、スタックの形状を所有します。\n* 依存関係別にレイヤーを並べ替える。 基本的な変更は下部に表示されます。 それらに依存するものは、より高くなります。 認証の場合、次のようになります。\n  * レイヤー 1: データ モデルと移行\n  * レイヤー 2: CRUD エンドポイント\n  * レイヤー 3: JWT ミドルウェアとガード\n  * レイヤー 4: 統合テストと単体テスト\n\n### プロンプトの例\n\n* `Propose a layered approach to add user authentication to this app. Order the layers by dependency, keeping each layer independently reviewable.`\n* `Review my planned layers and flag any that are too large or that depend on a branch above them.`\n\n## 2. 最初に下部レイヤーを構築する\n\n基盤を使用してスタックを開始します。 上記のすべては、このレイヤーを正しく取得することに依存します。\n\n* スタックプル要求を作成 Copilot 通知し、プランに基づいて最初のレイヤーを構築するように依頼します。 エージェントは、 `gh-stack` スキルを使用してスタックの最初のブランチを作成します。\n* スタックを自分で作成する場合は、 `gh stack init`で直接作成し、プレフィックスを使用してブランチ名を整理します (例: `gh stack init BRANCH-NAME-1`)。\n* 次に進む前に、生成された変更を自分で確認してください。 下位レイヤーの間違いは、その上のすべてのブランチに反映されるため、次に進む前にレビューを行ってください。\n\n### プロンプトの例\n\n* `Start the pr-stack and build only the first layer: the user data model and migration.`\n* `Conduct a review of the generated code and confirm this branch contains only the data model and migration, and nothing that belongs in a later layer.`\n\n## 3. 新しい各コード レイヤーを上に積み重ねる\n\n基盤を整えた状態で、フィーチャの残りの部分を一度に 1 レイヤーずつ構築します。\n\n* Copilotに次のレイヤーを追加し、以下のレイヤーのコンテキストで実装するように依頼します。 エージェントは、スタックの一番上に分岐を追加し、そこで作業をコミットします。\n* ブランチを自分で追加する場合は、 `gh stack add BRANCH-NAME-NEXT`を使用します。\n* レイヤーが大きくなりすぎる場合は、プランの外側にドリフトしたか、1 つではなく 2 つのレイヤーが実際に必要かどうかを検討します。\n* レイヤーごとに新しいブランチを作成し、すべてのブランチがクリーンで自己完結型の差分を維持するようにします。\n* プル要求を作成する準備ができたら、スタックの送信を Copilot に要求するか、自分で実行する場合は、 `gh stack submit`を使用します。\n* 各プル要求を単独で実行します。 通常は、重点を置いたタイトルと、レイヤーの簡潔でわかりやすい説明で十分です。\n\n### プロンプトの例\n\n* `Add the next layer in a new branch on top: the CRUD endpoints that use the user model from the branch below.`\n* `This branch is getting large. Suggest how it could be split into two independently reviewable layers.`\n\n## 4. レビューを依頼する前に pull request を自分で確認する\n\n各レイヤーは小さく、自己レビューも簡単になります。 チームメイトを巻き込む前に、すべてのブランチにパスを渡します。 レビュー担当者は、既に信頼している変更を受け取る必要があります。\n\n* 各ブランチでテスト、リンター、コード スキャンを実行します。 レビュー Copilot 要求する前に、各レイヤーを標準に照らして確認できるようにします。\n* AI によって生成された変更を徹底的に確認する手法については、 [AI によって生成されたコードを確認する](/ja/copilot/tutorials/review-ai-generated-code) を参照してください。\n\n## 5. スタックのレビューを一番下から要求する\n\nレイヤーを構築すると、校閲者はコードの大きな壁ではなく、小さな差分を取得します。\n\n* 依存関係が厳密に統合されている場合は、スタックの下部からレビューを依頼して、後続のレビューの前に変更をスタックに統合できるようにします。\n* 異なるレイヤーの個別のユーザーからのレビューが必要な場合は、レビュー担当者が並行して作業できます。 1 人のユーザーがデータ モデルを確認し、別のユーザーがエンドポイントをレビューし、どちらも機能全体を確認することはできません。\n\n## 6. フィードバックを反復処理する\n\nフィードバックは、機能全体ではなく、レイヤーに個別に反映されます。 スタックを使用すると、適切なレイヤーを所定の位置に固定し、変更を上に移動できます。\n\n* レビュー担当者がフラグを設定したレイヤーを変更するように Copilot に依頼します。 エージェントは右ブランチに移動し、変更を行い、そこでコミットします。 次に、上のレイヤーをリベースして修正プログラムを取得します。\n* 各修正は、それが属するレイヤーに保持します。 間違ったブランチで行われた変更により、エラーが混乱し、エラーが発生する可能性があります。\n* 修正を行う際は、上記のブランチをリベースし、変更を反映するように Copilot に依頼してください。\n* スタック内を自分で移動する場合は、 `gh stack down`、 `gh stack up`、または `gh stack checkout BRANCH-NAME`を使用してブランチ間を移動します。 次に、変更をコミットし、 `gh stack rebase --upstack` を実行して変更をスタックに反映します。\n\n### プロンプトの例\n\n* `A reviewer flagged that the auth service doesn't handle expired tokens. Fix that on BRANCH-NAME and test the changes.`\n* `I've rebased the layers above onto this fix. Check that the branch with endpoints still works with the change and flag anything that needs updating.`\n\n## 7. 下のレイヤーから結合する\n\nスタックは、メイン ブランチを指すレイヤーから順にマージされます。 レイヤーを一度に 1 つずつマージし、GitHub自動的にメインをポイントするように次のレイヤーを再ターゲットします。\n\n* スタックを一度に 1 つずつ、またはスタック内の任意の場所からマージすると、マージするプル要求の下にあるすべてのブランチが一番下からマージされます。\n* 各レイヤーの差分は親に対してまったく同じままで、基本の変更のみであるため、進行中の作業やレビューに影響を与えることなく、一度にレイヤーを簡単にマージできます。\n* 自動マージまたはマージ キューを使用して、各レイヤーが承認され、そのチェックが成功するとすぐにマージされるようにします。 スタック全体を一度に待機する必要はありません。\n\n最上位レイヤーがマージされると、フィーチャ全体が着陸します。 すべての部分は、1 つの大きなプル要求ではなく、小さな意図的な変更としてより効果的にレビューされました。\n\n## 詳細については、次を参照してください。\n\n* [AI によって生成されたコードを確認する](/ja/copilot/tutorials/review-ai-generated-code)\n* [スタックされたプル要求の管理](/ja/pull-requests/how-tos/create-pull-requests/managing-stacked-pull-requests)"}