対象読者：VS CodeでGitHub Copilot Chat・Agentモードを日常的に使う開発者
確認日：2026年10月8日
注意：料金・モデル・UIは変更されるため、最新の公式ドキュメントも確認してください。
はじめに
GitHub CopilotのAgentモードは便利です。実装からテスト、修正まで一気に進められる一方で、次のような使い方はAI利用コストが膨らみやすくなります。
- 「プロジェクト全体を調べて」と毎回依頼する
- 何十回もやり取りしたチャットで、別の機能の開発を始める
- 巨大なログや設計書を無条件に貼り付ける
- 高性能なモデルを単純な変更にも使う
- エージェントが対象外のファイルまで探索・修正する
ここでは、生成品質を犠牲にせず、不要な入力・出力トークンやツール呼び出しを減らすための実践的な方法を紹介します。
最初に：トークンとGitHub Copilotの課金単位は同じではない
2026年6月1日、GitHub Copilotは原則として、モデルとトークン使用量に基づくGitHub AI Credits方式に移行しました。 一部の既存年間契約者は旧プレミアムリクエスト方式のままです。どちらが適用されるかは契約条件によって異なります。
| 項目 | 意味 | 節約するには |
|---|---|---|
| 入力トークン | 指示、履歴、参照ファイル、ツール出力など | 対象ファイルと必要な情報を絞る |
| 出力トークン | AIが生成する説明やコードなど | 出力形式と必要範囲を指定する |
| コンテキストウィンドウ | モデルが1回で扱える情報量の上限 | 履歴を圧縮し、タスクを分割する |
| GitHub AI Credits | 新しい使用量ベース課金で利用する単位 | モデル・トークン・キャッシュ効率を意識する |
| プレミアムリクエスト | 一部の旧年間契約に残るリクエストベースの単位 | モデル倍率とリクエスト回数を意識する |
つまり、チャットの文字数を減らせば必ず同じ割合で請求額が下がるわけではありません。参照ファイル、履歴、キャッシュ、モデル選択も関係します。
参考：GitHub公式：課金方式の変更 / GitHub公式：AI Creditsの使用状況
1. 「全部調べて」ではなく、調査対象を限定する
NG例
このリポジトリを全部確認して、ログインできない原因を調べて修正してください。
改善例
ログインAPIで403が返ります。
対象は accounts/views.py、accounts/urls.py と関連テストです。
まず認証・CSRFまわりの処理を確認し、原因候補を最大3件示してください。
他のディレクトリは、必要性を説明できる場合のみ参照してください。
修正は原因を確認してから行ってください。
Agentモードではファイル検索やファイル読み取りの結果もコンテキストに入ります。最初から対象を限定すると、探索の回数や無関係な読み取りを減らせる可能性があります。ただし必要なファイルまで禁止すると精度が落ちるため、例外を許すルールが有効です。
VS Codeでは # メンションや「Add Context」で特定ファイル・シンボルを指定できます。#codebase は便利ですが、毎回必要なわけではありません。
2. 大きな開発依頼は「調査→方針→実装→検証」に分ける
「全部やって」という一文は簡単ですが、認識違いによる作り直しが起きると高くつきます。
おすすめの進め方は次のとおりです。
- 調査：対象ファイル、現状仕様、関連処理を特定
- 方針：変更範囲と実装案を短く示す
- 実装：決まった範囲だけ編集
- 検証：関係するテスト・静的解析のみ実行
最初のプロンプト例：
今回は調査のみ行ってください。コード変更は禁止です。
目的：退居日の判定条件を変更する箇所の特定
出力：対象ファイル、現在の判定、変更候補、影響するテスト
説明は箇条書きで簡潔にしてください。
注意：タスクを細かく分けすぎると、会話回数とコンテキストの再送が増える場合があります。小規模な変更は一括で、仕様確認が必要な変更は段階的に進めるのがよいでしょう。
3. 長いチャットは /compact で圧縮する
何十ターンも続いたチャットには、解決済みのエラーや古い設計案も残ります。その情報が後続リクエストのコンテキストを圧迫します。
VS Codeでは /compact で会話履歴を要約し、重要情報を残してコンテキストを整理できます。
/compact 現在の仕様、確定した設計判断、変更済みファイル、残タスク、テスト結果を保持してください。
圧縮後は、細部が省略される可能性があります。API契約や重要な要件などは、別ファイルに明記しておく方が確実です。
参考：VS Code公式：セッションの管理とコンテキスト圧縮
4. 別タスクになったら新規チャットを使う
ログインAPIの不具合調査が終わった後、同じチャットで画面レイアウト修正を始めると、前の話題の履歴まで引きずることがあります。
使い分けの目安は次のとおりです。
| 状況 | 推奨 |
|---|---|
| 同じ不具合の追加修正 | 同じチャット |
| 長い会話だが設計判断の継続が必要 | /compact |
| 独立した機能開発 | 新規チャット |
| 仕様が完全に変わった | 新規チャット |
新規チャットを始める際は、必要な決定事項だけ短く引き継ぎます。
前提：ログインはJWT認証。API仕様書は doc/api-specification.md。
今回の対象はパスワード再設定画面のみです。
なお、新規チャットが常に最安とは限りません。長い会話でも安定した前半コンテキストがキャッシュされる場合があります。会話の長さだけでなく、話題の切り替わりと実測値で判断しましょう。
5. copilot-instructions.md を短く保つ
.github/copilot-instructions.md には、リポジトリ全体で守ってほしいルールを記述できます。毎回説明しなくて済む反面、長すぎる指示は、関係のないタスクにもコンテキストを追加してしまいます。
例：
# Project rules
- 回答、コメント、コミットメッセージは日本語とする。
- 既存の命名規則とディレクトリ構成を優先する。
- 修正前に対象範囲を確認し、無関係なファイルは編集しない。
- DBスキーマ変更は実施前に承認を得る。
- 実装後は変更範囲に関係するテストを実行する。
- 最後に自己レビューを行い、重複処理や不要な複雑さを確認する。
詳細な業務仕様や長いAPI一覧は、常時読み込む共通指示ではなく、必要なときに参照する資料として分離しましょう。
6. ファイル種類ごとに指示を分ける
共通指示にReact、Python、SQL、テスト、インフラのルールを全て書くより、対象パスに適用する指示ファイルを作る方が整理しやすくなります。
例：.github/instructions/frontend.instructions.md
---
applyTo: "frontend/src/**/*.{ts,tsx}"
---
- Reactの既存コンポーネント設計を優先する。
- 既存のMUIテーマと共通部品を利用する。
- propsと状態管理は必要最小限にする。
対象外の作業にまでフロントエンド固有のルールを読み込ませない設計です。指示ファイルの適用範囲や機能サポートはIDE・エージェントによって異なるため、公式ドキュメントで確認してください。
7. ログは全文ではなく「再現条件＋エラー周辺」を渡す
ビルドログを数千行貼る代わりに、まずは以下を渡します。
実行コマンド：npm run build
発生時刻：直近の変更後
エラー：TS2322（該当箇所の前後20行を添付）
直近の変更：LoginForm.tsx の props 型を変更
目的：型エラーの原因特定と最小修正
必要な場合だけ追加ログを提供する方式なら、無関係なログの読解を抑えられます。エラーが複数箇所にまたがる場合は、全体像を削りすぎないことも重要です。
8. モデルは難易度で切り替える
すべての依頼に最も高性能なモデルを選ぶ必要はありません。
| タスク | 選び方の目安 |
|---|---|
| コメント修正・命名変更 | 軽量・低価格モデルを試す |
| 単純な型エラー・局所的な修正 | 標準モデルを試す |
| 複数ファイルの実装 | 標準〜高性能モデル |
| 複雑な設計判断・難しい原因分析 | 高性能な推論モデル |
ただし、安いモデルで何度も失敗すると、結果的に割高になることがあります。1回の単価ではなく、タスクを完了するまでの総コストを比較しましょう。
モデルごとの料金や対応状況は変わります。固定の倍率一覧を記事中に載せるのではなく、利用時点の設定画面や公式ドキュメントで比較するのがおすすめです。
9. エージェントの出力を「必要な差分」に限定する
コードを変更するたびに全ファイルを貼り直す必要はありません。
変更後の報告は、以下だけにしてください。
1. 変更したファイルと要点
2. 実施したテストと結果
3. 残課題・注意点
コード全文は出力しないでください。
もっとも、出力を短くするだけでAgent内部の探索やツール実行まで減るとは限りません。コストを抑えるには、調査範囲や実行する検証コマンドも指定すると効果的です。
10. GitHub AI Creditsとセッションの消費量を見て改善する
節約策の効果は実測して確認しましょう。
GitHubの個人向けCopilotでは、Billing and licensing の AI usage から、モデル別の利用量やAI Creditsの消費状況を確認できます。VS CodeのCopilotアイコンからも利用枠の状況を確認できます。
VS Codeのセッション画面では、コンテキスト使用量やトークン内訳、利用したAI Creditsを確認できる機能も案内されています。利用可能な表示はバージョンや契約によって異なります。
比較するなら、例えば次のようにします。
- 同程度の複雑さの開発タスクを選ぶ
- 使用モデルとタスク条件を記録する
- 従来の指示と、対象範囲を限定した指示を比較する
- AI Credits、完了時間、手戻り回数、テスト結果を記録する
コストだけが低くても、品質が悪化したり人間の修正時間が増えたりすれば失敗です。
参考：GitHub公式：AI Creditsの確認方法 / VS Code公式：セッション管理
コピペ用：Agentモードの省コストプロンプト
最後に、日常開発で利用できるテンプレートを置いておきます。
目的：［実現したい変更］
対象：［ファイル・ディレクトリ・機能］
前提：［必要な仕様や制約］
進め方：
1. まず関連箇所を確認し、変更方針を簡潔に整理する。
2. 対象外の大規模な探索は避ける。必要な場合は理由を示す。
3. 既存実装を優先し、変更差分を最小限にする。
4. 関連するテスト・静的解析を実行する。
5. 実装後に自己レビューし、重複やリファクタリング余地を確認する。
制約：
- 無関係なファイルを変更しない。
- DBスキーマの変更は事前承認を得る。
- 調査ログやコード全文を最終回答に転載しない。
報告形式：
- 変更点
- テスト結果
- 残課題
まとめ
GitHub Copilotの節約で最も大切なのは、短いプロンプトを書くことではなく、AIに不要な仕事をさせないことです。
特に効果を狙いやすいのは、(1) 対象ファイルの限定、(2) 会話履歴の整理、(3) 指示ファイルの適用範囲の最適化、(4) モデルの使い分け、(5) 実際の消費量の計測です。
節約のために確認やテストを削りすぎず、品質・作業時間・AIコストの3つを合わせて最適化していきましょう。