セッション境界の設計（Session Boundary Design）

会話が伸びるほど、最初に伝えた指示や制約が効かなくなる。圧縮は避けられない — こちらが引かなければ、道具が容量の閾値で引くだけである。選べるのは切るかどうかではなく、いつ・何を残して切るかである。消えるのは会話の過程であって、成果ではない。

問題

対話を重ねるうちに、最初に伝えた制約はいつの間にか効かなくなっている。原因は容量オーバーだけではない — 入力が長くなること自体で性能が落ちる（研究、18モデルのベンチマーク。具体例節）。

しかも、境界を設計しなければ境界が無くなるわけではない。勝手に引かれるだけである。容量が尽きかければ、道具の側が自動で会話を要約して詰める（公式、具体例節）。要約は不可逆であり、何が落ちたかをこちらは選んでいない。

先週決めた方針も、さっき読んだ制約も、仕事の切れ目とは無関係なところでまとめて畳まれる。

コンテキスト

適用する条件（この3つは公式が判断基準として書いているものに対応する。出典は具体例節）:

無関係なタスクへ移る — 次の仕事が、前の会話を必要としない
やり直したい — 方向を間違えたとき、前の判断との辻褄合わせをさせるより、白紙から始めるほうが速い
要約を重ねすぎた — 何度も畳まれ、要るはずのものが既に落ちていると感じるとき。その会話はもう費用だけを運んでいる

適用しないケース:

単一の短い作業。 境界を作るコスト — 渡し直し、前置きの作り直し — が上回る
積み上げた理解そのものが資産のとき。何を試して何が駄目だったかを保持させたい反復では、切ると資産ごと消える（公式、具体例節）
位相は変わるが、依存が切れないとき。一つの機能を足場・実装・テスト・PR と進める仕事は、位相が変わり続けても、後の位相が前の位相の中身を必要とする（公式、具体例節）

隣接パターンとの境界:

読み捨ての隔離 — 捨てる単位が会話そのものなら本パターン、会話の中の一区画なら同パターン
常駐物の棚卸し — 本パターンは積み上がる側（会話）を切り、同パターンは毎ターン載る側（常駐物）を減らす。同じコンテキストウィンドウの別の部分を扱う
前置きを壊さない（キャッシュ） — 同パターンは「切ると作り直しになる」と言い、本パターンは「切らないと壊れる」と言う。正面から緊張する

解決

境界の引かれ方には二通りある。

観点	容量が引く境界	依存が引く境界
引き金	容量の閾値。仕事の切れ目と無関係	依存が細る瞬間
落ちるもの	実装の途中までまとめて畳まれる	依存していないものだけ
持ち越しの指定	道具が選ぶ	こちらが指定して渡す

依存が細る瞬間に境界を引けば、畳まれるのは調査の過程だけであり、持ち越すものを指定して渡せる。これがなぜ効くのかは、境界の本質から説明できる。境界とは要約による不可逆な圧縮であり、圧縮そのものは、こちらが選ばなくても起きる。

これは道具の欠陥ではない。畳まなければ、入りきらなくなった古いメッセージが要約も記録も無しに落ちるだけである（公式、具体例節）。自動的な圧縮は安全網であり、無いよりはるかに良い。

しかし安全網は、落ちる場所を選んでくれない。 閾値は容量で決まり、容量は仕事の切れ目と無関係である。したがって選べるのは引くかどうかではなく、いつ・何を残して引くかだけである。

いつ引くか。 手がかりは位相の変わり目である — 調査が終われば、調査の過程はほぼ全部要らなくなる。だが位相は条件そのものではない。見るべきは依存である。

次の仕事が前の会話を必要とするか、それだけが問題であり、位相が変わっても依存が切れないことがある。一つの機能を足場・実装・テスト・PR と進める仕事では、位相は変わり続けるのに、後の位相が前の位相の中身を必要とする。公式がまさにこれを「長いセッションが向く場合」の筆頭に挙げている（具体例節）。「調査が終わったから切る」という位相の規則は、ここで正面から反例に当たる。

位相は依存が細りやすい場所を教える手がかりにすぎず、依存が細っていない継ぎ目で切れば、単に必要なものを捨てることになる。裏返しもある — 前の会話が次の仕事の負債になっているとき、つまり方向を間違えたのに、それまでの判断と新しい方針の辻褄合わせが始まってしまうとき、依存は保つべき資産ではなく断つべき対象そのものになる（公式が「clean slate」を新セッションの理由に挙げている。具体例節）。

何を残すか。 ここが本パターンの要点である。「捨てるか残すか」ではなく何を持ち越すかを決める。

道具が引いた境界では、持ち越されるものを道具が選ぶ。自分で引いた境界では、こちらが指定できる。要約は不可逆なので、この指定は一度きりである。

⚠ 消えるのは会話の過程であって、成果ではない。 境界を引くとは、書いたコードやコミットを消すことではない。消えるのは、そこへ至る会話だけである。

裏返せば、持ち越したいものが会話の中にしか無いなら、それは境界の前に会話の外へ出しておくべきものである。 境界の設計とは、その仕分けを事故が起きる前に済ませておくことでもある。

トレードオフ

利点

落ちるものをこちらが選べる。 圧縮そのものは避けられないが、圧縮の時点と、要約に何を残すかは選べる。道具任せの境界は、容量という仕事と無関係な基準で引かれる。
入力長を短く保てる。 入力が長くなること自体が性能を下げる範囲では（研究、具体例節）、短く保つこと自体に値打ちがある。ただし根拠が示すのは傾向であって閾値ではない — 「何トークンで切れ」はこの研究からは出ない（具体例節）。

代償

要約は不可逆である。 公式は「fine-grained details … may not be included」と明記している（具体例節）。細部は戻らない。これは自分で引いた境界でも同じであり、本パターンが変えるのは何が落ちるかであって、落ちること自体ではない。
前置きの作り直しを招く。 公式は境界の引き直しを "rebuild from a short summary instead of the full history" と書いており（具体例節）、作り直しが起きること自体は前提になっている。ただし公式が新セッションを推しているのは、休止によってキャッシュが既に失効している場面である。 キャッシュが生きている最中に切る損得は、この原文からは出ない。「前置きを壊さない（キャッシュ）」との緊張が解けるのは、失効した場面だけである。

GitHub Copilot での具体例

Copilot は単一の製品ではない。新しいセッションと /compact は Copilot CLI と VS Code の双方の公式に現れるが、原文がどこまで書いているかは面によって違う。

Copilot CLI — 境界の判断基準が公式に書かれている

出典: Copilot CLI のコンテキスト管理（取得日: 2026-07-16）。

放置したときに何が起きるか公式:

When your conversation reaches approximately 80% of the context window's capacity, Copilot CLI automatically starts compacting the context in the background. This leaves a buffer of approximately 20% so that tool calls can continue to run while compaction is in progress. If the context fills to approximately 95% before compaction finishes, Copilot CLI pauses briefly to wait for compaction to complete before continuing.
〔訳〕会話がコンテキストウィンドウ容量の約80%に達すると、Copilot CLI はバックグラウンドで自動的にコンテキストの compaction を開始する。これにより約20%のバッファが残り、compaction 進行中もツール呼び出しを実行し続けられる。compaction が終わる前にコンテキストが約95%まで埋まった場合、Copilot CLI は compaction の完了を待つために一時的に停止してから続行する。

境界は容量で引かれる。約80%・約20%・約95% — どれも仕事の構造とは無関係な数である。ただしこれを欠陥として読んではならない。同ページは代案を書いている公式:

Without compaction, once the context window filled up, Copilot would have to fall back to simply dropping old messages from the conversation history—removing them without any summary or record.
〔訳〕compaction が無ければ、コンテキストウィンドウが埋まった時点で、Copilot は会話履歴から古いメッセージを単純に落とすしかなくなる — 要約も記録も残さずに取り除く、という形である。

要約も記録も無しに古いメッセージが落ちる — 自動の compaction はこれを防ぐ安全網である。本パターンは安全網を外す話ではなく、安全網を設計の代わりに使わない話である。

何が失われ、残ったほうに何という名が付くか公式:

Compaction is a summarization process, so some detail is inevitably lost. The summary captures the key points, but fine-grained details—such as the exact wording of every message, the full output of every command, or minor decisions made early in a long conversation—may not be included.
〔訳〕Compaction は要約処理であり、一部の細部は必然的に失われる。要約は要点を捉えるが、あらゆるメッセージの正確な文言、あらゆるコマンドの完全な出力、長い会話の早い段階で下された細かな判断といった細部は含まれないことがある。

Every time compaction happens—whether automatically or manually—a checkpoint is created. A checkpoint is a saved copy of the compaction summary, stored as a numbered, titled file in your session's workspace.
〔訳〕compaction が起きるたびに — 自動でも手動でも — checkpoint が作られる。checkpoint とは compaction の要約を保存した写しであり、セッションのワークスペース内に番号とタイトルの付いたファイルとして保存される。

そして同ページは、本カタログの他の領域では滅多に見つからないもの — いつ切るべきかという判断基準そのもの — を書いている公式:

Starting a new session is better when:
You're switching to an unrelated task. Copilot doesn't need the context of your previous work, and a clean context window means more space for the new task.
The conversation has gone through many compactions, and you feel that important context is being lost in the summarization process.
You want a clean slate—for example, if work went in a wrong direction and you'd rather start over than have Copilot try to reconcile earlier decisions with a new approach.
〔訳〕新しいセッションを始めたほうがよいのは次の場合である。無関係なタスクに切り替える場合(Copilot は前の作業のコンテキストを必要とせず、コンテキストウィンドウが空いているほど新しいタスクの余地が増える)、会話が何度も compaction を経ており、重要なコンテキストが要約の過程で失われていると感じる場合、そして白紙の状態(clean slate)を望む場合 — 例えば、作業が誤った方向に進んでしまい、Copilot に以前の判断と新しい方針を辻褄合わせさせるより最初からやり直したい場合である。

逆側も書いている公式:

You're working on a multi-phase task, such as building a feature that requires scaffolding, implementation, testing, and then creating a pull request.
You're iterating on a problem and want Copilot to retain the context of what's been tried and what hasn't worked.
〔訳〕複数の位相からなるタスクに取り組んでいる場合(足場作り・実装・テスト・プルリクエスト作成を要する機能開発など)、また問題に対して反復している最中で、何を試して何がうまくいかなかったかというコンテキストを Copilot に保持させたい場合である。

この2つを並べると軸が読める。 5つの条件はどれも位相の話ではない。unrelated task は依存が無い。clean slate は依存が負債に変わっている。many compactions は依存先が既に落ちている。逆に multi-phase task と iterating は、位相が変わっても依存が切れない側である。「調査→実装で切れ」のような位相の規則が公式の multi-phase の例と衝突するのはこのためであり、「解決」で位相ではなく依存を見ると書いたのはこの衝突を踏まえてのことである。

操作（出典: Copilot CLI のコマンドリファレンス、取得日: 2026-07-16）公式:

| /clear [PROMPT], /new [PROMPT], /reset [PROMPT] | Start a new conversation. |
〔訳〕新しい会話を開始する。

| /compact [FOCUS-INSTRUCTIONS] | Summarize the conversation history to reduce context window usage. Optionally provide focus instructions to steer the summary—for example, /compact focus on the auth module. … |
〔訳〕コンテキストウィンドウの使用量を減らすため、会話履歴を要約する。要約の向きを定める focus instructions を任意で指定できる — 例えば /compact focus on the auth module のように。

| /context | Show the context window token usage and visualization. … |
〔訳〕コンテキストウィンドウのトークン使用量と、その可視化を表示する。

/compact が引数を取ることが、本パターンの要点そのものである。 「何を持ち越すか」は比喩ではなく、focus on the auth module のように指定できる。自動で畳まれた要約と、focus instructions を添えて畳んだ要約の差が、設計されなかった境界と設計された境界の差である。/context はその判断を前倒しする材料になる — 閾値が近いと分かれば、道具に引かれる前にこちらが引ける。

⚠ 原文の限定を落とさない — 本カタログの初期メモは /fork を制約なしで挙げていた公式:

| /fork [NAME], /branch [NAME] | Fork the current session into a new session, optionally with a name. Only available in experimental mode. |
〔訳〕現在のセッションを、任意で名前を付けて新しいセッションへ分岐(fork)する。experimental mode でのみ利用可能である。

/fork は experimental mode 限定である。 境界の張り方として魅力的だが、この限定ごと紹介しないなら紹介しない。

VS Code — キャッシュの側から境界に着く

出典: Cache Explorer（取得日: 2026-07-16）。プロンプトキャッシュを最適化するためのページが、5つの推奨の1つとして新しいセッションを挙げている公式:

Start fresh after a break: Caches expire after inactivity. Start a new session or run /compact to rebuild from a short summary instead of the full history.
〔訳〕休止の後は新しく始めよ — キャッシュは非活動状態が続くと失効する。新しいセッションを始めるか /compact を実行し、全履歴からではなく短い要約から作り直せ。

ここに「前置きを壊さない（キャッシュ）」との緊張の答えがある。 境界を引けば前置きは作り直し（rebuild）になるので、キャッシュの観点では境界は費用である。ところが休止を挟めばキャッシュは失効する。失効した後は、どうせ作り直しになる。そのときは全履歴から作り直すより、短い要約から作り直すほうが安い。キャッシュのページが境界を推しているのはこの場面に限った話であり、裏返せば、キャッシュが生きている最中に切る損得はこの原文からは出ない。

面差として書けるのはここまでである。 両面の公式に共通して現れるのは新しいセッションを始めることと /compact であり、閾値の数値・いつ切るべきかの判断基準・focus instructions は Copilot CLI の原文でだけ確認できた。これは「VS Code に無い」という意味ではない — 確認したのは「Copilot CLI の原文にはある」ところまでである。ここは面ごとの製品の差ではなく、面ごとの原文の差として読むのが正しい。

面の外 — 入力長そのものを測った研究

「問題」節の「長くなること自体で性能が落ちる」の出所はベンダーではない。出典: Context Rot: How Increasing Input Tokens Impacts LLM Performance（Chroma Research、取得日: 2026-07-16）研究。

何を測ったかが肝である:

our experiments hold task complexity constant while varying only the input length—allowing us to directly measure the effect of input length alone.
〔訳〕我々の実験はタスクの複雑さを一定に保ちながら入力長のみを変化させており、これにより入力長単独の影響を直接測定できる。

タスクの難度を固定し、入力長だけを変えた。だから示されたのは「長い仕事は難しい」ではなく「同じ仕事でも、長い入力に埋まると落ちる」である。

An evaluation across 18 LLMs, including leading closed-source and open-weights models, revealing nonuniform performance with increasing input length.
〔訳〕主要なクローズドソースおよびオープンウェイトのモデルを含む18の LLM を横断した評価であり、入力長の増加に伴って性能が一様でない(nonuniform)形で変化することを明らかにした。

We demonstrate that even under these minimal conditions, model performance degrades as input length increases, often in surprising and non-uniform ways. Real-world applications typically involve much greater complexity, implying that the influence of input length may be even more pronounced in practice.
〔訳〕このような最小限の条件下でさえ、入力長が増えるにつれてモデルの性能は低下し、それはしばしば意外な、一様でない形で現れることを我々は示す。実際のアプリケーションは通常はるかに大きな複雑さを伴うため、入力長の影響は実運用ではさらに顕著になりうることを示唆している。

⚠ この研究から導けないこと: 主張は「入力が長くなると性能が落ちる。しかも一様にではない」までである。18モデルを横断して測った結果が nonuniform だということは、閾値が引けないということでもある — なめらかな坂でも、きれいな崖でもないなら、「N トークンで切れ」という規則はこの根拠からは出ない。特定のツールの特定の閾値へ変換しない。 最後の一文（実運用ではさらに顕著かもしれない）も著者自身の推測であって、測定結果ではない。

本パターンにとっては、閾値が引けないことのほうが本題である。 数で決められないなら、境界は仕事の側の構造 — 依存が切れるかどうか — で決めるしかない。それは道具からは見えず、人間にしか見えない。

別名

呼称	出典
Compaction	一次 — 会話を要約して詰める処理に Copilot CLI 公式が与えている名（出典は具体例節）
Checkpoint	一次 — その要約の写しが保存されたものに同公式が与えている名（出典は具体例節）
セッション境界の設計 / Session Boundary Design	記述 — 本カタログの記述的呼称であり、一次資料に出典は無い

公式が名前を与えているのは機構（compaction、checkpoint、/clear）までである。「いつ切るか」という判断には、確認できた範囲で確立した呼称が無い。

機構の名を実践の名として流用すると、「compaction がある＝この実践をしている」という誤解になる。実際にはほぼ逆である。 自動の compaction は、こちらが何も判断しなくても勝手に起きる（具体例節）。機構が働いていることは、境界を設計していることを少しも意味しない — むしろ、設計しなかったときに代わりに働くのが機構のほうである。だから機構ではなく、判断の側に名前を与えた。

セッション境界の設計（Session Boundary Design） ​

問題 ​

コンテキスト ​

解決 ​

トレードオフ ​

GitHub Copilot での具体例 ​

Copilot CLI — 境界の判断基準が 公式 に書かれている ​

VS Code — キャッシュの側から境界に着く ​

面の外 — 入力長そのものを測った 研究 ​

別名 ​

関連 ​