Copilot CLI のコンテキスト管理メモ
はじめに
GitHub Copilot CLI で少し長めの作業をしていると、気づいたらコンテキストが膨らんでいることがあります。
なるべく膨らまないようにするにはどうするのが良さそうか、自分のメモも兼ねてまとめておきます。
基本的な内容も多いですが、どなたかの参考になれば嬉しいです！
コンテキストは少しずつ増える
作業を続けていると、以下のようなものが少しずつ会話に積まれていきます。
- 調査で読んだファイル
- 失敗した仮説
- 長いログやテスト出力
- 使わないツールやスキル
いきなり整理しても良いですが、まずは /context で使用量を見るのが良さそうです。
まず /context で使用量を見る
/context は利用状況を確認したい時に使います。
/context
● Context Usage
○ ○ ○ ◌ ◌ ◍ ◉ · · · gpt-5.4 · 22k/304k tokens (7%)
· · · · · · · · · ·
· · · · · · · · · · ○ System Prompt: 8.9k (3%)
· · · · · · · · · · ◌ System Tools: 7.3k (2%)
· · · · · · · · · · ◍ MCP Tools: 3.0k (1%)
· · · · · · · · · · ◉ Messages: 2.5k (1%)
· · · · · · · · · · · Free Space: 236.6k (78%)
· · · · · · · · · · ◎ Buffer: 45.6k (15%)
· · · · · ◎ ◎ ◎ ◎ ◎
◎ ◎ ◎ ◎ ◎ ◎ ◎ ◎ ◎ ◎
| 項目 | 内容 |
|---|---|
System Prompt |
予め指定されたシステムプロンプトの消費 |
System Tools |
ツール定義の固定的な消費 |
MCP Tools |
MCPツールの固定的な消費 |
Messages |
会話履歴の消費 |
Free Space |
まだ使える空き |
Buffer |
自動コンテキスト管理用の予約領域 |
感覚ではなく、どこが増えているかを確認してから整理すると良さそうです。
ちなみに、スキルや MCP の読み込み状況を見たい場合は /env も使えます。
カスタム指示は常時読むものだけにする
カスタム指示は便利ですが、全部を1ファイルに詰めると毎回読む情報が増えます。Copilot CLI では、主に以下のように使い分けられます。
| 用途 | ファイル |
|---|---|
| リポジトリ全体の指示 |
.github/copilot-instructions.md（AGENTS.md） |
| 対象ファイル別の指示 | .github/instructions/**/*.instructions.md |
対象ファイル別の指示は、applyTo で効かせる範囲を絞れます。
---
applyTo: "src/**/*.ts,src/**/*.tsx"
---
アロー関数で書く。
例外を握りつぶさず、呼び出し側でエラーハンドリングする。
全体指示は厚くしすぎず、毎回読む必要があるものだけに絞るのが良さそうです。PRレビュー手順、マイグレーション手順、障害調査手順のような長いチェックリストは、常時読むカスタム指示ではなくスキルに分ける方が扱いやすそうです。
長い手順はスキルに分ける
スキルは「常に全部読ませるもの」ではなく、詳細な例やテンプレートなどを段階的に読ませる設計にするのが効果的です。
例えば以下のような構成です。
skills/
└── pr-review/
├── SKILL.md
└── references/
├── review-guideline.md
└── checklist.md
| 段階 | 役割 |
|---|---|
description |
スキルの説明文。まずここだけで候補を選ぶ |
SKILL.md |
呼ばれた時に読む手順 |
| 参照ファイル | 必要になった時だけ追加で読む例やテンプレート |
長い手順を全部 SKILL.md に置くより、詳細な例やテンプレートは別ファイルに分けて、必要な時だけ開かせる方がコンテキストを抑えやすそうです。
明示的に呼び出す用のスキルは自動呼び出しを切る
スキルは呼ばれると SKILL.md が読み込まれます。
description だけなら大きな消費ではないですが、意図せずスキルが起動すると本文が入ってきます。明示的に呼ぶだけでよいスキルは、フロントマターに disable-model-invocation: true を付けます。
---
name: pr-review
description: Review a PR based on the guideline.
disable-model-invocation: true
---
使う時だけスラッシュコマンドで呼びます。
/pr-review #2026 をレビューして
使うツールを絞る
使えるツールが多いと便利ですが、毎回使わないものまで見えていると System Tools 側の消費が増えます。
最初から使うツールが決まっている時は、--available-tools や --excluded-tools でモデルに見せるツールを絞れます。
copilot --available-tools='view,grep,glob,bash'
ちなみに --available-tools に名前が似ているもので --allow-tool がありますが、自動で実行させるツールを制御する際に使用するものです。
また、組み込み MCP が不要な場面では以下も選択肢になります。
copilot --disable-builtin-mcps
組み込み MCP には便利なものもあるので常に切る話ではないですが、GitHub 操作は gh で代用できる場面も多いです。
後から自分で追加した MCP も、使わない場合は無効にしておくと、最初から見えているツールを減らしやすいと思います。
LSP で全文読みを減らす
コード調査でいきなり全文検索を繰り返すと、読む量が増えがちです。Copilot CLI は LSP サーバーを利用でき、LSP がある場合は定義ジャンプ、参照検索、シンボル一覧などからコードを辿りやすくなります。
GitHub のドキュメントでも、LSP の利点としてトークン効率が上がることが挙げられています。
設定できているかは以下で確認できます。
/lsp show
/lsp test
導入は、Awesome GitHub Copilot にある lsp-setup スキルが楽でした。
公式のものではないため、スキルや外部リポジトリの内容は実行前に確認した方が良さそうです。
LSP が効くと、ファイル全体を読む前に「この関数の定義」「この型の参照」「このシンボルの一覧」のように当たりを付けやすくなります。
大きめの変更は先に方針を合わせる
大きめの変更は、いきなり実装させない方が結果的に楽なことがあります。先に Plan モードで、触る範囲、確認方法、やらないことを揃えておくと、実装後の手戻りを減らしやすそうです。
/plan 認証まわりのリファクタ方針を作って
または Shift + Tab でモードを切り替えられます。
なんでも Plan モードにするというより、「認識がズレると高くつきそうな時だけ先に揃える」くらいがちょうど良さそうです！
独立した調査は別コンテキストで進める
独立した調査や検証は、サブエージェントで別コンテキストに分ける選択肢もあります。
向いているのは、以下のような作業です。
- 独立した成果物がある
- ファイル境界が見えている
- 検証条件が分けやすい
- 並列に調べてもぶつかりにくい
逆に、順番に進める必要が強い作業を無理に分けると追いづらくなります。
まずは組み込みのエージェントで試して、役割が固まってからカスタムエージェントを作るくらいで十分そうです。
カスタムエージェントを作る場合は、.github/agents/*.agent.md や ~/.copilot/agents/*.agent.md に作ります。
.github/
└── agents/
└── reviewer.agent.md
ちなみに /fleet は、大きい実装計画を依存関係つきの小タスクに分け、サブエージェントへ割り当てる入口として使えます。
/fleet 実装計画を見て、依存関係つきの小タスクへ分けて進めて
長い出力は rtk で手前で削る
これは Copilot CLI 本体の機能ではないですが、rtk というツールを最近使っています。
長いシェル出力を LLM のコンテキストに届く前にフィルタリング・圧縮する CLI プロキシです。
ファイル一覧が長くなりそうな時は、以下のように通常のコマンドの前につけて使えます。
rtk find . -type f
README では、Copilot CLI 向けに以下も紹介されています。PreToolUse フックとカスタム指示が自動生成されるようです。
rtk init -g --copilot
test / lint / diff / find などの長い出力を毎回そのまま会話に入れると、地味にコンテキストを圧迫します。
セッション管理の選択肢
コンテキストが増えた時は、同じ流れを続けるのか、別タスクに切り替えるのかで使うコマンドを分けています。
| コマンド | 何をする | 使う時 |
|---|---|---|
/compact |
会話履歴を要約して続ける | 同じ流れを継続する時 |
/clear / /new / /reset
|
新しい会話を始める | 別タスクに移る時 |
/ask (/btw) |
本題とは別の確認・調査をする | 用語確認や軽い調査 |
/fork |
今のセッションから独立した別セッションを作る | 別案を試したい時 |
/undo / /rewind
|
最後のターンを巻き戻す | 迷走した時、意図しない変更を戻す時 |
/compact は同じ流れを続けるために要約するもの、/clear は前の文脈を持ち込まずに新しく始めるもの、という使い分けが良さそうです。
なお、会話がコンテキストウィンドウの約80%に達するとバックグラウンドで自動的にも圧縮が開始されます。
要約や自動圧縮を行うと細かいニュアンスやエラーログ全文が脱落する可能性があるため、必要なログは事前に別ファイルに退避させておくと安心です。
/chronicle cost-tips で次に活かす
/chronicle cost-tips は、セッション履歴をもとにトークンの使い方やコスト削減の推奨事項を出してくれるコマンドです。
/chronicle cost-tips
どの操作でトークンが膨らみやすいか、どのあたりを見直せそうかを振り返る用途で使えそうです。
他にも standup / tips / improve / reindex などのサブコマンドがあります！
まとめ
全部を一気にやる必要はないと思っています。
まずこれだけでも、長めの作業は進めやすくなると思います！
- 全体のカスタム指示を厚くしすぎない
- 大きい変更は Plan モードで先に認識を合わせる
- 独立作業はサブエージェントに分ける
-
/chronicle cost-tipsで使い方を振り返る
読んでいただきありがとうございました！
参考URL
Discussion