2026年7月30日、公式GitHubブログではCopilotの「スタックドセッション」作業方法が紹介されました。開発者は同じリポジトリ内に複数の依存セッションを作成し、次のタスクが前のタスクのコンテキストとコード出力を継承し、順番にプルリクエストを統合できるようにします。 問題はモデルがコードを書けるかどうかではなく、AIが一度に多くの変更を加えた後もチームがそれを徹底的にレビューできるかどうかです。
なぜ古いプロジェクトにセッションスタックが必要なのでしょうか?
GitHubのケースは、2014年から継続している個人アプリケーションを示しており、React 15、Less、そして古いReact-Bootstrapを使用しています。 開発者はまずCopilotにフロントエンドの近代化を計画させ、その後段階的に実装します。 React-Bootstrapの削除が現在のタスク範囲を超え始めた際、彼女は元のセッションを拡張し続けませんでした。代わりに、まず既存の作業に対してプルリクエストを作成し、その後新しいセッションを作成して前のコンテキストを引き継ぎました。
Copilotは3つのことを達成しました:現在の改造をプルリクエストとして保存すること; コンポーネント交換用の新しいスタックセッションを作成し、保留中の確認スケジュールを生成します。 前のブランチを基に次のプルリクエストを作成します。 このようにして、各修正は独自のレビュー境界を持ちつつ、依存関係の明確な順序を保つことができます。
AIプログラミングにおける新しいタイプのレンジ暴走をターゲットにしています
AIプログラミングはコード生成コストを削減しますが、同時に「大規模なオーバーホール」を非常に簡単にします。 単一のプロンプトが、機能の混合、リファクタリング、依存関係のアップグレード、スタイルの調整など、数万行もの修正に急速に発展することがあります。 たとえコードが動作しても、レビュアーはどの変更が回帰を引き起こしているのかを特定するのが難しいと感じています。
スタッキングセッションは、長いタスクを段階的な部分に分解し、独立してテスト・レビューできるようにします。まず基礎となる準備を統合し、それに依存している機能を統合します。 問題が特定の階で起きた場合、見つけ出しや撤収も容易になります。 AIエージェントの作業ユニットを、単一の長い会話から、配達関係を持つ小さなタスクのセットへと移行させます。
使用時にこれら4つのチェックポイントを見落とさないでください
- 各セッションは明確な目標だけを保持し、単なるランダムなリファクタリングは避けます。
- 下位レベルのプルリクエストが変更された後は、上位層のブランチを再同期し、競合処理を行う必要があります。
- テストは、スタック全体が終わった後に均一に実行されるのではなく、各修正層の後に行うべきです。
- 合併の順序は明確でなければなりません。 上位層のコード依存関係がまだメインブランチに入っていない場合、それらを独立して再配布可能なものと誤認してはいけません。
スタッキングセッションは、開発者がどの境界を分割すべきかを決める助けにもならず、コードが正しいことを自動的に証明するものでもありません。 その真の価値は、長期間実行するコーディングエージェントが従来のソフトウェア工学の制約、すなわち小規模な修正、独立した検証、明確な依存関係、ロールバックレビューの対象となり続けることです。 レガシーシステムのアップグレードや多段階の移行においては、一度きりの生成と完全な完了を目指すよりもこの方法の方が信頼性が高いです。
