GitHub Copilot 従量課金時代のコスト設計：Skills・MCP・外部参照で何が課金対象になるか¶

対象 / ポイント

対象: GitHub Copilot を Skills・MCP・外部ドキュメント参照と組み合わせて使う開発者およびチーム。

ポイント:

課金の境界は「情報を取得したか」ではなく「モデルの文脈へ入れたか」にある。
出力単価は入力より高いが、巨大な入力は入力側だけで支配的になる。
Skills は大量知識の注入口ではなく、必要な情報だけ取りに行かせる制御プレーンとして設計する。

2026年6月1日、GitHub Copilot の料金設計で見るべき数字が「リクエスト数」から「トークン量」へ移った。短い依頼でも、Agent が Skills を読み、GitHub の Issue や Pull Request を取得し、外部ドキュメントを文脈へ積めば、その分だけ入力トークンが増える。

この記事の問いは一つだ。 Skills・MCP・外部参照を使うとき、どこから AI Credits の課金対象になるのか。

結論：課金境界は「文脈への投入」にある¶

課金が始まるのは、情報を取得した瞬間ではなく、モデルが参照できる文脈へ入れた瞬間だ。 GitHub Copilot は 2026年6月1日に Premium Request Units から GitHub AI Credits へ移行した。新方式では、入力トークン・出力トークン・キャッシュトークンの消費量をモデル別単価で換算する¹。 GitHub Docs も、モデルへ送られる入力、生成される出力、再利用または保存されるキャッシュ済み文脈がトークンとして価格計算されると説明している²。

ローカルに存在するだけのファイルや、GitHub に存在するだけの Issue は、それ自体では AI Credits を消費しない。 gh や MCP でデータを取得しても、Agent がその結果を要約・引用・判断材料としてモデルへ渡さなければ、直接のトークン課金対象にはならない。

逆に、ユーザーが入力した短いプロンプトだけが課金対象という理解は誤りだ。 Skill 本文、tool の取得結果、会話履歴、中間生成、system/tool 定義も、文脈へ入れば入力側の消費に効く。

この境界を誤ると、「GitHub API を叩いたから高い」のか「取得結果を丸ごと読ませたから高い」のかを切り分けられない。コスト設計は、API 呼び出し数ではなく、モデルに渡したテキスト量から始める必要がある。

出力は高いが、巨大入力も普通に高い¶

出力単価は入力単価より高いが、長い参照文脈は入力だけで請求を支配する。たとえば GPT-5.5 の公開単価は、100万トークンあたり入力 5.00 USD、キャッシュ入力 0.50 USD、出力 30.00 USD である²。出力が入力の6倍という比率だけを見ると、「読み込みは軽い」と感じやすい。

同じ GPT-5.5 単価で計算すると、差は明確だ。

20万入力トークン: 0.2M x 5.00 USD = 1.00 USD = 100 AI Credits
2千出力トークン: 0.002M x 30.00 USD = 0.06 USD = 6 AI Credits
同じ20万をキャッシュ入力扱いにできた場合: 0.2M x 0.50 USD = 0.10 USD = 10 AI Credits

最終回答が短くても、大量に読ませた文脈のほうが16倍以上高くつく。キャッシュが効けば10分の1まで下がるが、何がキャッシュ入力として扱われるかをユーザー側が完全に制御できるわけではない。 Anthropic 系モデルではキャッシュ入力に加えて cache write 単価も別に計上されるため、「キャッシュされるから安い」を前提に設計するのは避けたい²。

読み込みは無料ではない。安く見える入力も、桁が増えれば主要コストになる。

Agent は1プロンプトでも複数回モデルを呼ぶ¶

短い依頼でも、Agent の内部処理は単発のモデル呼び出しとは限らない。ユーザーから見える入力は「このルールに従って GitHub を見てレビューして」の一文でも、内部では次のような連鎖が走る。

ユーザープロンプトを読む
→ Skill を選ぶ
→ SKILL.md を文脈へ入れる
→ MCP で Issue や Pull Request を取得する
→ 取得結果を文脈へ入れる
→ 中間判断を生成する
→ 追加でファイルを読む
→ さらに文脈へ入れる
→ 最終回答を生成する

各矢印の先で、モデルへ渡す入力やモデルからの出力が増える。 GitHub Docs も、agent mode や Copilot cloud agent のような agentic 機能は、 1つのタスク内で複数のモデル呼び出しを含むと説明している。大規模コードベースをまたぐ複雑なセッションは、短い質問より消費が大きくなる³。

さらに会話が文脈の約80%に達すると、Copilot CLI は自動で compaction を行う。この処理では現在の会話履歴をモデルに送り、構造化された要約を生成して古い履歴を置き換えるため、圧縮処理そのものもモデル呼び出しを伴う⁴。

つまり「入力が短い = 安い」は成立しない。実際のコストは、Agent が内部で何回モデルを呼び、どれだけ tool 結果を文脈へ積み、どのモデルで処理したかで決まる。

Skills・MCP・外部参照で課金対象になるもの¶

Skills は無料で大量知識を読ませる仕組みではない。 GitHub Copilot の Agent Skills は、Copilot が対象 Skill を使うと判断したときに SKILL.md を agent の文脈へ注入する仕組みである⁵。長い SKILL.md を雑に書けば、使われるたびに長い指示が文脈を埋め続ける。

要素	課金上の扱い
Skill の `description`	Skill 選択の判定に参照され得る
`SKILL.md` 本文	使用時に文脈へ注入されるため入力トークン
補助 Markdown・スクリプトの出力	文脈へ読み込んだ分は入力トークン
GitHub API や MCP の取得結果	そのまま渡せば入力トークン
ローカルで絞った後の要約	渡した小さいテキスト分だけ入力トークン
ローカルの `grep` / 取得処理そのもの	直接の AI Credits 対象ではない

Repository-wide custom instructions も同じ発想で扱う必要がある。 GitHub は copilot-instructions.md を「リポジトリ内のリクエストに自動で加えられる」文脈として案内し、長すぎずタスク固有にしすぎない制約も示している⁶。

文脈は共有資源だ。常時入るもの、必要時だけ入るもの、ローカルで処理してから入るものを分けなければ、役に立たない説明が毎回の入力トークンを消費する。

見落としやすい二つの課金¶

トークン換算だけ見ていると、二つの追加コストを見落としやすい。どちらも GitHub の価格仕様に明記されている。

Copilot code review の二重課金: レビューはトークン分が AI Credits で課金される。さらに、レビューを動かす agentic インフラが GitHub Actions minutes を消費する²。
ロングコンテキスト割増: GPT-5.4 の表示単価はプロンプトが272Kトークン以下のとき、Gemini 2.5 Pro と Gemini 3.1 Pro は200Kトークン以下のときに適用される²。

「大きい context window を選べば賢くなる」という発想は、この割増と相性が悪い。標準的なコンテキストと推論レベルを既定にし、複雑なタスクだけ拡張するほうが、支出を読みやすい。

ベストプラクティス：LLM に読ませる前に絞る¶

従量課金時代の基本は、LLM に渡す前に絞ることだ。 Skills は大量知識の注入口ではなく、必要な情報だけ取りに行かせる制御プレーンとして設計する。

最小の実装例として、SKILL.md は長い手順書ではなくルーティング定義に寄せる。いつ・何を・どう出すかだけを書く。

---
name: github-pr-review
description: GitHub の Pull Request をレビューする。PR レビュー依頼時に使う。
---
steps:
  - gh で対象 PR を絞り込む（state=open, 直近更新, 自分担当）
  - 変更ファイルと関連コメントのみを抽出する
  - 抽出結果を JSON で受け取り、リスク観点でレビューする

取得を絞り込む処理はローカル側に置く。 100件の Issue をそのまま渡すのではなく、条件で絞ってから渡す。次の例は100件を取得し、ローカルで絞った上位だけを LLM に渡す。

gh issue list --state open --limit 100 --json number,title,labels,updatedAt,url \
  --jq '[.[] | select(.labels[].name == "review")] | .[0:5]'

設計の勘所は四つに集約できる。

GitHub 情報は文脈へ入れる前に labels・state・path・date で絞る。
自由文100KBより、構造化JSON 10KBのほうが扱いやすく安い。
大量文書は全文投入ではなく、検索や索引で抜粋してから根拠付きで渡す。
調査・抽出は軽量モデルやスクリプトに任せ、高性能モデルは最終判断だけに使う。

ここで重要なのは、精度とコストが必ずしも対立しない点だ。不要な文脈を削るほど、モデルは判断に使うべき情報へ集中しやすくなる。

実測：`/context` で見える化する¶

設計の良し悪しは、実測で確かめるのが早い。 Copilot CLI の /context は、System/Tools の固定オーバーヘッド、会話履歴、残り容量、compaction を誘発するバッファを表示する⁴。

検証は段階的に行う。小さい Skill で1回実行し、GitHub 情報を10件渡した場合と100件渡した場合を比べる。さらにモデルを軽量・高性能で切り替え、消費の傾きを見る。 SKILL.md の長さを変えて、注入分の差を測るのも有効だ。

従量課金は「使った分だけ」という公平さと引き換えに、設計の巧拙がそのまま請求額に出る。 Skills と MCP を制御プレーンとして組み、LLM に渡す手前で絞り込む習慣が、コストと出力品質の両方を支える。