開発実践ガイド
GitHub Copilotの料金とAIクレジット|補完・チャット・Agentを分けて比較

目次
結論
Copilotはコード補完とAI Creditsを消費する機能を分けて見ます。旧「premium request」前提の記事をそのまま使わず、現在のcredit制と契約移行条件を確認します。
判断の順番は 必須条件→費用/性能の得失→運用条件 です。価格、plan、求人、hardware仕様など時間で変わる事実には 2026-09-13 の観測日を付け、未測定の速度・品質・時間・電力を公式仕様から推測して数値化しません。
判断表:現行課金単位と旧記事の用語を対応させた請求表
| 機能 | 旧情報で見かける語 | 現行確認項目 | 予算への入れ方 |
|---|---|---|---|
| code completion | completion | plan包含/制限 | seat基本費へ |
| chat | premium request等の旧表現 | 現行AI Credits対象か | current docsだけで計算 |
| agent/coding agent | premium request等 | AI Credits消費/倍率 | task頻度×current unit |
| premium model | multiplier/request | model別credit rule | model mixをusage log化 |
| overage | additional requests | 追加purchase/control | org budget capへ |
2026-09-13時点のGitHub公式を正本とし、過去の“premium requests”だけで現在の費用を計算しないことをassetの最重要ruleにします。
判断の前提
開発/自動化ツールは、表示月額だけで比べると課金境界を誤ります。認証経路、含有利用、従量単位、超過、team管理を分けて見ます。
Agent系では「生成できる」ことと「実行してよい」ことを分離します。filesystem書込み、shell実行、外部network、Git操作に承認点を置き、失敗時にdiffとlogから戻れることを必須にします。
価格・plan・creditの名称は変化が速いため、固定ランキングではなく、自分の1週間のusageまたは1workflowを現在の課金単位へ換算する方が再利用できます。
古いpremium request記事を基準にしない
Copilotは料金体系やAI利用単位の名称が変わり得ます。検索で過去の「premium requests」の上限が見つかっても、現在のAI Creditsと同じものとして計算しません。まず現在契約しているplan、利用するmodel、chat/agent/coding agentのどこでcreditを消費するかをGitHub公式で確認します。
team導入では、補完中心のdeveloperとagentを頻繁に使うdeveloperで消費を分け、全員を同じ上位planへ上げる前にusage distributionを見ます。追加creditを許可する場合はorg budget capも同時に設定します。
org導入ではpolicy差も確認します。個人向けとBusiness/Enterpriseで管理、policy、利用できるmodelや機能が異なる場合があるため、個人pricingだけで法人seatを見積もりません。current org settingsでAI Creditsの追加購入や制限を管理できるかも公開前に再確認します。
選ばない・進めない条件
請求経路・利用上限・実行権限・rollbackのいずれかが不明なまま本番導入しない。
これは「慎重に」という抽象論ではなく、比較表の必須条件を満たさない候補をランキングから外すための公開条件です。
一次情報
- GitHub Copilot — Plans
- GitHub Docs — Copilot request-based billing legacy
- Cursor — Pricing
- OpenAI — Business pricing
まとめ
Copilotはコード補完とAI Creditsを消費する機能を分けて見ます。旧「premium request」前提の記事をそのまま使わず、現在のcredit制と契約移行条件を確認します。
変化が速い領域ほど固定ランキングより、同じinputで更新できる現行課金単位と旧記事の用語を対応させた請求表を正本にします。更新時は変化した項目だけを最新の情報源/実際の観測結果で差し替え、同じ判断基準で結論を再計算します。
まとめ
- Copilotはコード補完とAI Creditsを消費する機能を分けて見ます。旧「premium request」前提の記事をそのまま使わず、現在のcredit制と契約移行条件を確認します。 変化が速い領域ほど固定ランキングより、同じinputで更新できる**現行課金単位と旧記事の用語を対応させた請求表**を正本にします。更新時は変化した項目だけを最新の情報源/実際の観測結果で差し替え、同じ判断基準で結論を再計算します。