GitHub Copilot 従量課金は「改悪」か：批判の正体とベンダーロックインの避け方¶

対象 / ポイント

対象: GitHub Copilot を業務やチームで使い、2026年6月の従量課金化が開発体験とコストにどう影響するかを見極めたい開発者・技術リード・導入判断者。

ポイント:

批判の核心は値上げそのものではなく、1回の依頼コストがトークン量・モデル・文脈量で読みにくくなったことだ。
長期の論点はコスト以上にロックインで、IDE体験・リポジトリ文脈・Agent実行・課金メーターがGitHub側へ寄る。
解の第一歩は自前LLMではなく、AI Gatewayと境界条件の外部化でCopilot直依存を避けることだ。

2026年6月1日、GitHub Copilot の月額プランは AI Credits へ移った。開発者の反応には「改悪」という言葉が混じるが、その不満は単純な値上げだけでは説明できない。

この記事の問いは一つだ。 Copilot 従量課金への批判は何を問題にしており、チームはどこからロックインを外すべきか。

結論：論点は「値上げ」ではなく「予測不能」と「ロックイン」¶

今回の変更で本当に重いのは、価格表の数字よりも、消費が読みにくくなったことと依存が集中したことだ。 GitHub Copilot の月額プランは、2026年6月1日に Premium Request Units から GitHub AI Credits へ移行した¹。ただし年額の Pro / Pro+ 契約者は、契約満了まで従来のリクエストベース課金が残る例外がある¹。コード補完と Next Edit Suggestions は、有料プランで引き続き AI Credits の対象外だ。一方、Chat・CLI・cloud agent・Spaces・Spark・third-party coding agents は対象になる²。

開発者の反発は強い。ただし中身を分けると、「高くなった」よりも「1回の依頼がいくらになるか事前に読めない」に近い。旧体系ではリクエスト単位の感覚で使えたが、新体系では内部で何トークン使い、どのモデルが動き、どれだけ文脈を読んだかで消費が変わる。

そして、コストより尾を引くのがロックインだ。今回の変更で GitHub は、コードホスティングとIDE体験に加えて、AI Agent、レビュー、課金メーターまでを同じ導線上に統合した。問題の本質は価格表ではなく、この依存の集中にある。

何が変わったか：事実を先に固定する¶

AI Credits は、モデルへ送られる入力、モデルが生成する出力、再利用または保存されるキャッシュ文脈をトークンとして計算する。 GitHub Docs は、各トークンをモデル別単価で価格化し、1 AI Credit = 0.01 USDで換算すると説明している²。

個人向け有料プランでは、base credits と flex allotment の合算が月次枠になる。 base credits は月額料金に対応する固定枠で、flex allotment は AI の経済性に応じて変動する追加枠である³。

プラン	Base credits	Flex allotment	月次合計
Copilot Pro	1,000	500	1,500
Copilot Pro+	3,900	3,100	7,000
Copilot Max	10,000	10,000	20,000

法人向けでは Business が1,900 credits / user、Enterprise が3,900 credits / userで、個人ごとのバケツではなく請求単位でプールされる⁴。既存顧客には2026年6月1日から9月1日までの3か月間、Business 3,000、Enterprise 7,000 credits / user の移行枠が付く⁴。

費用を左右する最大の変数はモデル選択だ。たとえば GPT-5 mini は100万トークンあたり入力0.25 USD・出力2.00 USDだが、GPT-5.5 は入力5.00 USD・出力30.00 USDである²。同じ作業でも、どのモデルで処理したかで請求は一桁変わる。

「改悪」の声を分解する¶

批判は感情的に見えるが、論点ごとに分けるとかなり具体的だ。下表は典型的な不満と、その背後にある構造である。

不満	背後にある構造
予測不能	リクエスト数ではなくトークン・モデル・文脈量に依存する
フロー破壊	コーディング中に残高と単価を気にする思考の中断が生じる
定額の安心感の消失	月額なのに、実質は期限付きクレジットの購入に近い
失敗しても課金	成果物ではなく計算資源への課金で、試行錯誤のトークンも消費する
逃げ道の消失	予算切れ時に低コストモデルへ自動退避する保証がない

実際の反応を見ると、批判は大きく三つに分かれる。第一に、月額プランの安心感がなくなり、Agent 利用時の上振れが読みにくくなったという不満だ。第二に、これまで GitHub 側が吸収していた推論コストが、利用者側に見える形で転嫁されたという冷静な理解である。第三に、料金そのものよりも、GitHub 上の開発体験・Agent・レビュー・課金管理が一体化することへの警戒である。

これは抽象論ではない。あるヘビーユーザーは、2026年5月前半だけで354.63 PRU、31,017.761 AI Credits、310.18 USD相当の利用になったと記録している⁵。これは Pro+ の月次枠7,000 credits と比べても大きい。 Agent や高性能モデルを多用するほど、旧体系の感覚との乖離は大きくなることを示している。

一方で、擁護する見方も無視できない。これまで Copilot が安く見えていたのは、GitHub 側が推論コストを吸収していたからだ、という整理である。 agentic coding の計算量を踏まえれば、補助金つきの時代が終わっただけとも言える。

ここで必要なのは、怒るか擁護するかではない。「どの利用が予測不能で、どの依存が外せないと困るのか」を分けることだ。

Agent時代にコストが読みにくくなる理由¶

短い依頼でも高くなり得る理由は、Agent の内部で複数の処理が走るからだ。ユーザーから見える入力は一文でも、Agent は指示ファイルを読み、関連ファイルを探し、Issue や Pull Request の文脈を取得し、tool call の結果を再びモデルへ渡す。さらに修正案を生成し、必要なら再試行する。

課金対象は、ユーザーが直接入力した文字列だけではない。モデルに送信された入力トークン、モデルが生成した出力トークン、再利用または保存される cached tokens が対象になる²。

したがって、問題は「最終出力が長いか」だけではない。大きなリポジトリ文脈、長い会話履歴、Agent の複数回呼び出し、高性能モデルの選択が重なると、1つの依頼でも消費は大きく上振れする。

本当の論点：課金メーターまで握られるロックイン¶

ロックインされるのはモデルだけではない。作業導線そのものが GitHub に寄る。

IDE体験: VS Code、GitHub、Copilot 拡張に開発フローが集約される。
リポジトリ文脈: Pull Request、Issue、コード文脈を前提に Agent が動く。
Agent実行とレビュー: Copilot code review は、private repository で GitHub-hosted runner 上に実行される場合、 AI Credits と GitHub Actions minutes の二重メーターになる⁷。
課金メーター: AI Credits 単価、Actions 分、モデル選択、予算制御が GitHub の設計に依存する。

public repository では Actions minutes は無料であり、self-hosted runner という逃げ道もある⁷。それでも private repository の標準構成では、レビューが「AI Credits + Actions minutes」の二重メーターになる点を予算に入れる必要がある。

従来は「月額で Copilot を使う」感覚だった。これからは GitHub が定義した単価体系で、モデル、トークン、Agent 実行ごとに消費する。

便利さと引き換えに、コスト構造の主導権までベンダー側へ移った。これが、今回いちばん強まった依存である。

ロックインを外す段階：自前サーバーは最終防衛線¶

「自前サーバーを立てないと逃げられない」は半分しか正しくない。対策には段階があり、最初の一手はモデルの内製ではなく、Copilot に直接依存しない実行基盤を挟むことだ。

レベル	方針	現実性
1	Copilot をそのまま使う	高い
2	補完だけ Copilot、Chat / Agent は別系統へ逃がす	高い
3	AI Gateway を立て、複数 LLM を切り替える	中〜高
4	自前 GPU や推論サーバーを使う	中
5	完全オンプレ LLM 基盤と社内レビュー基盤を持つ	重い

悪い形と良い形を一枚で対比すると、依存の差が見える。

悪い形:
開発者 → Copilot → GitHub の課金・文脈・レビュー・Agent に全面依存

良い形:
開発者 → IDE / Agent → 社内 AI Gateway → 複数 LLM / 自前 LLM
                         → 社内ルール・ログ・予算・品質ゲート

現実的なバランスは AI Gateway を挟む構成だ。 LiteLLM のような Gateway は、OpenAI互換の入出力形式で100以上のLLMを扱い、認証、予算、ログ、フォールバックを中央で持てる⁶。重要タスクだけ高性能モデル、軽微な要約は安いモデル、機密リポジトリは自前推論、という振り分けが可能になる。

いちばん効くのは「境界条件の外部化」¶

ロックイン回避の本質は、AI そのものの内製ではなく、判断の境界条件を特定ツールの外へ出すことだ。言い換えると、「どのAIに頼むか」よりも、「何をもって完了とするか」「何を違反とするか」「どのテストを通れば合格か」を自分たちのリポジトリ側に持つことが重要である。完了条件、レビュー基準、コーディング規約、テスト条件、プロンプト資産は、Copilot の内部ではなくリポジトリ内のファイルとして持つ。

最小の形は、規約と評価をディレクトリとして版管理することである。

.ai/
  instructions/      # コーディング規約・レビュー方針・ドキュメント方針
  skills/            # PRレビュー・設計書レビュー・移行チェック
  evals/             # ゴールデンケース・回帰ケース
  budgets/           # モデルルーティング・予算ポリシー

こうしておけば、同じ境界条件を Copilot でも Claude でも Codex でも自前 LLM でも読ませて動かせる。さらに合否は AI の回答ではなく、markdownlint、textlint、schema 検証、ユニットテスト、セキュリティスキャンといった決定論的チェックで固定する。

AI を最終判定者にしない限り、フロントエンドがどのベンダーでも品質基準は揺らがない。ここを外部化できれば、Copilot は便利な入口であっても、基盤そのものではなくなる。

結び：強力なフロントエンドとして使い、基盤そのものにはしない¶

Copilot は補完、軽い相談、GitHub 内連携では依然として強い。一方で、夜間の無人ドキュメント生成、大規模リポジトリ全体を読む Agent、Pull Request 全件の自動レビューは、成果物が外れてもトークンと実行時間を消費する。予算上限なしで任せるべきではない。

個人や小規模で補完中心なら、Copilot 直利用のままで問題は小さい。だが大企業、機密コード、複数リポジトリ管理、Azure DevOps 併用、大量 Agent 運用が前提なら話は変わる。 Copilot を便利なフロントエンドとして残しつつ、AI 開発基盤そのものは Copilot に寄せない設計が現実的なロックイン回避になる。