はじめに

「今月もう Copilot のクォータが残り少ない…」

GitHub Copilot を使い込むほどぶつかるのが、プレミアムリクエスト（premium requests） の上限です。
月初にチャットを使いまくって、月末には「モデルを切り替えてください」と言われた経験がある人も多いのではないでしょうか。

この記事では、プレミアムリクエストの仕組みを理解した上で、実際に消費を抑えられる具体的な方法をまとめます。

この記事でわかること

✅ プレミアムリクエストとは何か、何が消費されるか
✅ プランごとの月間クォータと確認方法
✅ モデルの「乗数」の仕組みと節約に使えるモデル
✅ VS Code での消費を抑える5つの実践Tips
✅ ドキュメント整備 × SKILL で「往復回数」を減らす構造的アプローチ
✅ 組織・チーム向けの管理方法

対象読者

GitHub Copilot を日常的に使っていてクォータが気になる方
チームで Copilot を導入している管理者の方
Free/Pro プランで賢く使いたい方

プレミアムリクエストとは？

GitHub Copilot のリクエストには2種類あります。

種別	内容	クォータ
通常リクエスト	インライン補完（コードのサジェスト）	有料プランは無制限
プレミアムリクエスト	Chat・Agent mode・Code review など	月次クォータあり

つまり、コードを書いているときに出てくる グレーのサジェスト（インライン補完）は消費しません。
消費するのは主に Copilot Chat にメッセージを送ったとき です。

💡 重要: エージェントモードでは、ユーザーが送信したプロンプトのみがカウントされます。
Copilot が自律的に実行するツール呼び出し（ファイル読み込み・コマンド実行など）はカウントされません。

プランごとの月間クォータ

プラン	月間クォータ	価格
Copilot Free	50件/月	無料
Copilot Student	300件/月	無料（学生認定が必要）
Copilot Pro	300件/月	$10/月
Copilot Pro+	1,500件/月	$39/月
Copilot Business	300件/ユーザー/月	$19/シート
Copilot Enterprise	1,000件/ユーザー/月	$39/シート

クォータは毎月1日 00:00:00 UTC にリセットされ、未使用分の繰り越しはありません。
クォータ超過後は $0.04/リクエストで追加購入できます（Free プランは不可）。

⚠️ 2026年4月以降の変更: Pro/Pro+/Student プランには週間・セッション制限も追加されています。
使用量が上限に近づくと VS Code や CLI に通知が表示されます。

消費量を確認する方法

VS Code で確認する

VS Code のステータスバー左下の Copilot アイコンをクリックすると、現在の使用状況が表示されます。

GitHub.com で詳細を確認する

なぜ消費量が変わるのか？ — モデル乗数の仕組み

プレミアムリクエストは「1送信 = 1リクエスト」ではありません。
使用するモデルによって「乗数（multiplier）」が掛かります。

有料プランのモデル乗数（2026年4月時点）

モデル	乗数（有料プラン）	用途の目安
GPT-4o / GPT-4.1 / GPT-5 mini / Raptor mini	0（無消費）	日常的なコード補完・Q&A
Grok Code Fast 1	0.25	コード生成・デバッグ
GPT-5.4 nano	0.25	—
Claude Haiku 4.5 / Gemini 3 Flash / GPT-5.4 mini	0.33	軽量タスク・高速応答
Claude Sonnet 4 / 4.5 / 4.6	1	汎用・エージェントタスク
Gemini 2.5 Pro / Gemini 3.1 Pro	1	深い推論・複雑なデバッグ
GPT-5.2 / GPT-5.2-Codex / GPT-5.3-Codex / GPT-5.4 / GPT-5.5	1〜7.5	高度な推論・アーキテクチャ設計
Claude Opus 4.5 / 4.6	3	複雑な問題解決
Claude Opus 4.7 / GPT-5.5	7.5	⚠️ 最高性能・高消費
Claude Opus 4.6 fast mode（プレビュー）	30	⚠️ 1回で30消費

⚠️ Claude Opus 4.7 は乗数7.5。Pro プランの場合、40回で月間クォータ（300件）が尽きます。
Claude Opus 4.6 fast mode は乗数30。Pro プランで10回使うだけでクォータの1/3が消えます。

プレミアムリクエストを節約する5つの実践Tips

Tip 1: 「消費ゼロ」モデルを積極的に使う

有料プランでは GPT-4o・GPT-4.1・GPT-5 mini はプレミアムリクエストを消費しません。
日常的なコード補完やQ&Aには、これらのモデルで十分な場合がほとんどです。

VS Code のモデル選択欄で明示的に指定するか、オート選択を使うと自動的に最適なモデルが選ばれます。

Tip 2: オートモデル選択で10%割引を得る

VS Code の Copilot Chat で「Auto」（オート選択）を使うと、選択されたモデルの乗数から 10%の割引が適用されます。

モデル選択欄 → "Auto" を選択

モデルを指定せず Copilot に任せるだけで、自動的に節約になります。

Tip 3: Chat の送信回数を減らす工夫

1回のプロンプトで必要な情報を引き出せるよう工夫すると、送信回数が減り消費が抑えられます。

❌ 消費が多いやり方（3回送信）

「このコードを改善して」
「テストも追加して」
「コメントも付けて」

✅ 消費が少ないやり方（1回送信）

「このコードを改善し、ユニットテストを追加して、
 各関数にコメントを付けてください」

Tip 4: 用途に合わせて機能を使い分ける

やりたいこと	おすすめの使い方	消費
短いコード補完	インライン補完（Tab）	0
ファイル内の修正	Chat の Edit モード	少
設計相談・Q&A	Chat の Ask モード	少
ファイルをまたぐ大きな変更	Agent モード	多め（ただしツール実行はカウント外）

Agent モードは「ユーザーが送信したターン数」しかカウントされません。
複数ファイルを一気に変更させる大きなタスクは、むしろ1回のプロンプトで済むため効率的です。

Tip 5: 予算アラートを設定する

クォータが75%・90%・100%に到達したときにメール通知を受け取れます。

github.com/settings/billing を開く
「Budget & alerts」 を選択
アラートのしきい値と通知先を設定

月末に「あと少しだった…」と後悔しないための習慣として設定しておくことをおすすめします。

デモ: 現在の消費量を確認してみよう

実際に VS Code でクォータを確認する手順を示します。

手順

VS Code を開く
右下ステータスバーの Copilot アイコンをクリック
メニューから 「View premium request usage」 を選択
現在の使用状況がポップアップで表示される

組織・チーム向け: 管理者ができること

Business/Enterprise プランの管理者は、追加の管理機能が使えます。

超過課金のポリシー設定

Organization の Settings → Copilot → 「Premium request paid usage」 で、クォータ超過後の追加課金を許可するかどうかをユーザー単位で制御できます。

ユーザー別使用量の確認

Enterprise プランでは、ユーザー別の使用量データをCSVでダウンロードして分析できます。

確認できる項目
ユーザー別の消費リクエスト数
機能別（Chat / Agent / Code Review）の内訳
モデル別の内訳

【上級Tips】ドキュメント整備 × SKILL で消費を構造的に減らす

ここまで紹介したTipsは「1回の送信を賢くする」アプローチでした。
しかし最も効果が大きいのは、「そもそも往復回数自体を減らす」 設計です。

往復が増える本当の原因

「何のフレームワーク？」「DBは？」といった単純な質問は、copilot-instructions.md を1枚書けば解決します。
しかし往復が本当に増える場面はそこではありません。

実際に往復が爆発するのは、「判断が必要な場面」 です。

❌ テスト追加を頼んだら往復地獄になるケース

ユーザー:「この関数にテストを追加して」
Copilot: 「どのテストフレームワークですか？」
ユーザー: 「Vitest」
Copilot: 「モックはどう書きますか？vi.fn() ですか？」
ユーザー: 「はい、でも外部APIは msw でモックします」
Copilot: 「テストファイルはどこに置きますか？」
ユーザー: 「__tests__/ ディレクトリです」
Copilot: 「カバレッジは境界値テストも含めますか？」
ユーザー: 「正常系・異常系・境界値すべて書いてください」
→ ここまでで 4〜5 消費

これは「技術スタック」の問題ではなく、プロジェクト固有の意思決定ルール を Copilot が知らないことが原因です。

ケース1: テスト生成を SKILL 化する

テストの追加は毎回同じ判断（モックの方針・ファイル配置・カバレッジ方針）が繰り返されます。SKILL に決定木を埋め込むと、質問が1回になります。

.github/skills/add-tests/SKILL.md

---
name: add-tests
argument-hint: 'テストを追加したいファイル名またはコンテキストを説明してください'
---

## Step 1: テスト対象の確認

このスキルが呼び出されたら、以下を確認する：

1. **テスト種別** — `単体テスト` / `統合テスト` / `E2E`
2. **カバレッジ方針** — `正常系のみ` / `正常系＋異常系` / `全網羅（境界値含む）`（デフォルト: 正常系＋異常系）

## Step 2: 実装ルール（毎回聞かない情報）

以下はプロジェクト標準として固定する：
- フレームワーク: Vitest
- ファイル配置: テスト対象と同階層の `__tests__/` ディレクトリ
- 外部API: msw でモック、内部関数: vi.fn()
- describe/it ブロックの日本語命名
- beforeEach でモックをリセット

## Step 3: 出力

Step 1 の選択と Step 2 のルールに従ってテストコードを生成する。

効果:

Before: 4〜5往復（約4〜5消費）
After: 1往復（1消費）

ケース2: PRレビューの観点を固定する

「このPRをレビューして」と送ると、Copilot は何を重視するかわからず網羅的に指摘しがちです。
プロジェクトのレビュー基準を SKILL に書くと、1回のやり取りで欲しい粒度のレビューが返ってきます。

.github/skills/pr-review/SKILL.md

---
name: pr-review
argument-hint: 'レビューしたいコードまたはPRの変更内容を貼り付けてください'
---

## Step 1: レビュー観点の選択

このスキルが呼び出されたら、以下を確認する：

1. **フォーカス** — `セキュリティ` / `パフォーマンス` / `可読性` / `全般`

## Step 2: レビュー基準（固定）

以下の観点は毎回チェックする（コーディング規約より）：
- 入力バリデーションはドメイン層で行う
- エラーは Result 型で返す（try-catch を直接使わない）
- N+1クエリが発生していないか
- テストが追加されているか

## Step 3: 出力形式

指摘事項は以下の形式で出力する：
- 🔴 必須修正（マージブロック）
- 🟡 推奨修正（対応を検討）
- 🟢 提案（任意）

ケース3: 設計ドキュメントをコードへの変換ゲートにする

「仕様書を渡してコードを生成させる」ときの往復は、曖昧な仕様に対する確認が原因です。
AGENTS.md や ADR（Architecture Decision Record）ファイルに判断済みの内容を残しておくと、Copilot が迷わなくなります。

docs/adr/0001-auth-strategy.md

# 認証方式の決定

## 決定
JWT を使用する。リフレッシュトークンは Redis に保存。

## 却下した選択肢
- セッション認証: スケールアウト時に問題があるため
- OAuth only: 社内ツールのため外部IdP依存を避ける

## 実装時の制約
- アクセストークン有効期限: 24時間（変更不可）
- リフレッシュトークン: 30日、1回使い切り

SKILL からこのファイルを参照させると、「なぜこの実装にするのか」を毎回説明する往復がなくなります。

## Step 2: 実装

`docs/adr/` の関連ADRを参照した上で実装する。
ADR で却下された選択肢は提案しないこと。

ケース4: デバッグフローを構造化する

「このエラーを直して」と送るだけでは、Copilot はエラーの背景（どんな操作で再現するか・関連コンポーネントはどこか）を推測するしかありません。

.github/skills/debug/SKILL.md

---
name: debug
argument-hint: 'エラーメッセージまたはスタックトレースを貼り付けてください'
---

## Step 1: 情報収集

以下を確認する：

1. **再現条件** — `常に再現` / `特定条件で再現`（条件を記述）/ `intermittent`
2. **影響範囲** — `単一ユーザー` / `特定環境のみ` / `全体`

## Step 2: 調査

argument-hint のエラー内容と Step 1 の情報をもとに：
1. 根本原因の仮説を3つ挙げる
2. 最も可能性が高い原因と修正コードを提示する
3. 再発防止策（テスト追加案）を1つ提案する

まとめ: ドキュメント × SKILL の役割分担

種類	書く内容	削減できる往復の種類
`copilot-instructions.md`	技術スタック・コーディングルール	「何のフレームワーク？」系
ADR / 設計ドキュメント	採用・却下した設計判断の理由	「なぜこの実装に？」系
SKILL（手順書）	タスク別の決定木・出力フォーマット	「どんな形式で出力する？」系
`.github/agents/*.agent.md`	ロール・振る舞いの定義	「どのペルソナで動く？」系

💡 実践的な導入順序:
まず「毎週同じことを頼んでいるタスク」を1つ選んでSKILL化する → 次に、そのSKILLが依存している知識を copilot-instructions.md に移す、という順番が継続しやすいです。

実際の効果イメージ

アプローチ	同じタスクで必要な往復数	消費リクエスト
ドキュメントなし・SKILLなし	5〜8往復	5〜8
`copilot-instructions.md` あり	3〜4往復	3〜4
SKILL + ドキュメントあり	1〜2往復	1〜2

同じ Pro プランのクォータ300件でも、往復を半分にすれば実質2倍の作業量をこなせる計算になります。

まとめ

ポイント	内容
消費されるのは主にChat	インライン補完はクォータを消費しない
モデル乗数を意識する	GPT-4o/4.1は消費ゼロ、Opus系は高コスト
オート選択で10%割引	VS Code の Auto モデル選択で節約
1回のプロンプトにまとめる	送信回数を減らすことで消費を抑える
アラートを設定する	75%・90%到達時に通知を受け取る
ドキュメントを整備する	`copilot-instructions.md` でコンテキスト共有、往復を減らす
SKILLで手順を再利用する	繰り返すタスクをSKILL化して1〜2往復で完結させる

プレミアムリクエストの仕組みを理解すれば、同じクォータでも体感できる作業量が大きく変わります。
「1回の送信を賢くする」× 「往復回数自体を減らす」の両方を意識して、Copilot をより効率的に活用してみてください。

参考