なぜGitHub Copilotのスタックセッションが開発を変えるのか。AIの文脈管理を徹底解説

10年以上放置されたコードを前に、AIへ一括で最新化を頼む。プロンプトを工夫しても、AIは途中で過去の文脈を失い迷子になる。

ここで差がつくのが文脈の管理だ。GitHub Copilotが導入したスタックセッションは、タスクごとに状態を積み重ねる設計で、この問題を解決する。

AIを「状態を持つ開発パートナー」に変える構造化と文脈管理の設計を、僕の視点から解説する。

SNS運用を自動化しませんか？

ThreadPostなら、投稿作成・画像生成・スケジュール管理までAIがサポート。

無料で始める

タスクを重ねるスタックセッションと出力の構造化

AIに大規模なコード改修を依頼したとき、途中で前言撤回されたり謎のコードが混ざったりする。この課題に対して開発現場で注目されているのが、GitHub Copilot Appに導入されたスタックセッションだ。

2014年に作成された古いWebアプリの刷新プロセスが公開されている。対象コードはReact 15やLess、Bootstrapなど、10年前の依存関係が絡み合っていた。

最初はプロンプト1発で全リファクタリングを試みたが、失敗に終わった。大規模なコードベースにおいて、単一の対話枠だけで全体の文脈を維持するのは今のAIでも困難だ。

そこで効果を発揮したのがスタックセッションだ。1つの巨大な指示を一括で実行するのではなく、スタイルの整理、依存関係の更新、コンポーネントの分割といった形でタスクごとにセッションを独立させて積み重ねる。

各セッションが前のタスクで生成されたコードと状態をバトンとして受け取る。AIは最新のコンテキストを途切れさせずに保持し、10年分の技術的負債を解消した。

しんたろー：
10年前のコードをプロンプト一発で最新化しようとして爆死した経験がある。AIが途中で諦めて適当なコードを生成し始める。文脈の切り分けと状態の持たせ方が気になる。

また、こうしたセッション管理と並行して、AIの出力を構造化データとして管理する設計パターンが普及している。AIが生成したテキストをそのまま処理に流すのではなく、JSONスキーマを用いて出力形式を固定し、システムが機械的に検証を行う。

さらに、バッチ処理や自動投稿のような実務システムにおいては、生成物のタイトルや本文からSHA-256ハッシュ値を生成する。公開済みデータと照合することで二重処理や誤作動を防ぐ冪等性を確保する。

処理の各工程ごとに中間成果物をディスクへ永続化する。ネットワークエラーや外部APIの不具合でプロセスが中断しても、メモリ上の記憶に頼らず直前の状態から再開できる。

AIとの対話を使い捨てで終わらせない。積み重ね可能なセッションと決定的な構造化データとして設計に組み込む。

この2つのアプローチによって、AI開発は確率に頼る実験から再現性と信頼性を備えたエンジニアリングへと進化する。

コンテキストの分離と「非決定性」をねじ伏せる実装設計

React 15やLessで書かれた古のコードを、Tailwind CSSや最新環境へ一括で移行させようと巨大なプロンプトを投げても、途中で破綻する。単一のセッションに全文脈を詰め込む手法には限界がある。

ここで重要になるのがスタックセッションだ。タスクを単一の対話で完結させず、機能単位や依存関係の解決ごとにセッションを分離して積み重ねる。新しい作業は前のセッションの成果物を引き継いで実行するため、コンテキストウィンドウの枯渇や注意力の散逸を防げる。

しんたろー：
Claude Codeに長文コードを渡して「全部リファクタリングして！」と投げたとき、途中で矛盾し始める。タスクを細かく刻んでセッションを分けるようになってから、エラー率が下がった。文脈の渡し方が雑だったと思った。

開発者が向き合うべきもう一つの課題が、LLMの持つ非決定性だ。AIの出力は確率論であり、同じプロンプトを入力しても毎回異なるレスポンスが返ってくる。僕らが作るシステムには、100%確定的な再現性が求められる。

確率的なAIの出力を確定的なシステムへ組み込むには、システム的な厳格な契約が必要になる。

出力をJSON形式に固定する（スキーマ定義による型の保証）
中間状態を外部ストレージに永続化する（メモリ上の保持を排除）
二重処理を防ぐ識別子を生成する（ハッシュ値の照合）

例えば、生成されたテキストやタイトルからSHA-256ハッシュを計算し、データベースの既知のハッシュ値と比較する。この仕組みを入れるだけで、AIが同じコンテンツを再生成して二重投稿を引き起こすバグを物理的に遮断できる。

僕がClaude Codeで開発しているThreadPostの裏側でも、この冪等性の確保は重要な意味を持つ。SNSへの自動投稿バッチが外部APIのタイムアウトで停止した際、プロセスを再起動して「どこまで完了したか」を推測させると、重複投稿のトラブルが起きる。

これを防ぐために、投稿文案の生成、画像の生成、APIリクエストの各段階で中間成果物のJSONファイルをディスクに保存し、処理の成功ステータスを記録している。再起動時にはAIに前回の記憶を聞くのではなく、ローカルに残されたJSONファイルの有無を見て正しいフェーズから処理を再開させる。

AIエージェント時代における開発者の役割は、AIにコードを書かせることからAIが失敗しても安全に復帰できる状態管理の枠組みを作ることへと変化している。AIの出力を構造化データとして定義し、確定的なパイプラインに接続するソフトウェアアーキテクチャが求められる。

ここまで読んだあなたに

今なら無料で全機能をお試しいただけます。設定後はAIが投稿案を毎日生成。確認して選ぶだけ。

無料で始める

明日からの開発で僕らが即座に取り入れるべき3つの実装パターン

AIを開発プロセスに組み込む際、実務作業はコードを書かせる作業からAIの出力を安全に受け止める土台を作る作業へとシフトする。明日からの開発現場で取り入れるべき3つの実践的なアプローチを整理した。

1. プロンプトを書く前に「JSONスキーマ」を定義する

AIに命令文を投げて自由テキストを受け取る運用は、今日限りでやめる。AIの出力を後続の処理で自動利用するためには、厳密なJSONスキーマによる出力フォーマットの固定が必須だ。

まずはschema.jsonのように期待するデータ構造を定義し、そのスキーマとセットでAIにリクエストを投げる。返ってきた結果をバリデーションチェックで評価し、型が合わない場合は即座に再試行させる。この1ステップを挟むだけで、後続のプログラムが予期せぬフォーマット崩れで落ちる事故を防げる。

2. メモリ状態を捨てて「中間成果物」をローカルに吐き出す

長時間かかるバッチ処理や複数ステップのAIタスクでは、処理の進行状態をプログラムのメモリ上だけに保持する設計を排除する。各ステップが完了するたびに、結果をローカルのJSONファイルやSQLiteデータベースに即座に永続化させる。

こうしておけば、途中でネットワークエラーが起きてプロセスが死んでも、再起動時に最後に生成されたファイルの存在を確認するだけで済む。AIに「どこまでやったっけ？」と問い直す必要もなく、確定的なファイルキャッシングによって途中のフェーズからノータイムで処理を再開できる。

3. ハッシュ値による「冪等性チェック」を外部実行の直前に挟む

外部APIの呼び出しやSNSへの投稿といった破壊的な処理を行う前には、データの一意性を保証するハッシュ値による照合を組み込む。タイトルや本文の文字列から余白を取り除いて正規化し、そこから算出したSHA-256のハッシュ値を過去の実行ログと比較する。

これによって、同じ内容の二重投稿や二重生成をコード側で物理的にブロックできる。AIエージェントが非決定的な判断で同じタスクを繰り返し実行しようとしても、システム側の安全弁が事故を防いでくれる。

しんたろー：
Claude Codeで開発してると、AIがたまに調子に乗って同じファイルを何度も書き換えようとする。ハッシュチェックと中間ファイルの保存を徹底しておけば、「あ、またやってるわ」とログを眺めながら一瞬でリカバリーできる。AIの賢さに頼るんじゃなくて、AIがミスっても破綻しない仕組みを作るのが楽だ。

これらのパターンを導入するために、大掛かりなフレームワークは不要だ。数行のハッシュ計算ロジックとJSONファイルの読み書きをパイプラインに挟むだけで、AIアプリケーションの信頼性は強固になる。