GitHub Copilotの従量課金とは、2026年6月1日開始のGitHub AI Creditsによる使用量ベース課金のことです。
2026年6月1日、GitHub Copilotの課金体系が全プランで大きく変わりました。従来の「Premium Requests(回数ベース)」が廃止され、トークン消費に応じた「GitHub AI Credits」へ移行しています。自社ECの開発や運用スクリプトの内製にCopilotを使っている事業者にとって、月額固定のつもりが従量で増える構造になったため、上限設定を怠ると想定外の請求につながります。本記事は、EC支援19年・5,000社超の実績を持ち、AI導入支援は2023年から提供する株式会社オルセル(うるチカラ運営)が、AI Credits制の仕組み・プラン別の付与額・EC開発コストを管理する実務手順を解説します。設定を整理するプロンプトも3本掲載します。
AI Credits制で何が変わったか
GitHub公式ブログが2026年4月28日に発表した変更の骨子は3つです。
第一に、課金単位が「リクエスト回数」から「トークン消費量」に変わりました。旧制度のPremium Requestsは、どのモデルを使っても1回は1回(モデル別の倍率あり)というカウントでしたが、AI Creditsは実際に消費したトークン量に応じてクレジットが減る仕組みです。長いコンテキストを渡す使い方ほど消費が増えるため、大きなコードベースを丸ごと読ませる使い方はコストに直結するようになりました。
第二に、対象機能の線引きが明確になりました。コード補完(completions)とnext edit suggestionsは有料プランで引き続き無制限で、クレジット消費の対象外です。クレジットを消費するのは、Copilot Chatやエージェント系機能など、モデルを明示的に呼び出す操作です。日常のコーディング補完だけなら従来と体感は変わりません。
第三に、プラン別の付与額です。個人向けはCopilot Proが月額10ドルで毎月10ドル分、Pro+が月額39ドルで39ドル分のクレジットを含みます。法人向けは1ユーザーあたりCopilot Businessが月1,900クレジット、Enterpriseが3,900クレジットで、既存顧客には2026年9月1日までの移行期プロモーションとしてBusiness 3,000・Enterprise 7,000へ増量されています。つまり9月1日を境に実質の付与額が下がるため、移行期のうちに自社の消費実態を把握しておくことが重要です。
超過分は従量で加算されますが、支出上限(spending cap)を設定すれば上限到達で止められます。デフォルト設定のまま放置しないことが、この制度変更への最初の対応です。
EC事業者にとっての論点:内製開発の「見えない固定費」が変動費になった
この変更がEC事業者に効くのは、Copilotの用途がコード補完から「エージェントに開発を任せる」方向へ広がっていたタイミングだからです。受注CSVの加工スクリプト、在庫連携ツール、商品ページの一括更新といった内製開発でエージェント機能を多用すると、トークン消費は補完の比ではありません。旧Premium Requests時代の感覚で使うと、Businessの1,900クレジットを月半ばで使い切る事態が現実に起こります。
もう1つの論点はモデル選択です。Copilotは複数のAIモデルを切り替えて使え、上位モデルほどクレジット消費が大きくなります。GitHub Copilotの優先モデルにGPT-5.6が採用された動きのように裏側のモデルは今後も入れ替わるため、「どの作業にどのモデルを使うか」の社内基準を持たない運用は、品質もコストも不安定になります。定型的なスクリプト修正は標準モデル、設計を伴う開発だけ上位モデル、という使い分けが基本形です。
外部の開発会社に頼らず内製する店舗が増えるなか、Copilotの費用は「開発の変動費」として月次で見る対象になりました。エージェント型開発の費用対効果はCodex×GPT-5.6のEC業務自動化の記事でも扱っていますが、ツールが何であれ「消費の見える化→上限設定→モデル使い分け」の3点セットが管理の型になります。
コスト管理を整える3ステップとプロンプト3本
宣言通りプロンプトを3本掲載します。ChatGPT・Claude・Geminiのいずれでも使える形です。
1本目は、自社の利用実態の棚卸しです。誰が何にCopilotを使っているかを整理しないと、上限も使い分けも決められません。
プロンプト1:Copilot利用実態の棚卸しシート作成
あなたはEC事業者の開発コスト管理アドバイザーです。
GitHub Copilotの利用実態を棚卸しするヒアリングシートを作成してください。
条件:
1. 対象者ごとに「利用機能(補完のみ/Chat/エージェント)」
「主な用途」「利用頻度」「使用モデル」を記入する表形式(テキスト)
2. クレジット消費が大きい順に並べ替える基準を提示
3. 「補完のみの利用者」を特定する質問を含める
(この層はクレジット消費ゼロのため対策不要)
チーム構成:{人数と役割(例:開発2名、店舗運用でスクリプトを書く1名)}
現在のプラン:{Pro/Pro+/Business/Enterprise}
2本目は、支出上限とアラートの設計です。9月1日のプロモーション終了を見据えた段階設計にします。
プロンプト2:AI Credits支出上限の設計
以下の条件から、GitHub Copilotの支出上限(spending cap)と
社内アラートルールを設計してください。
条件:
1. 月次の付与クレジット:{Business 3,000(〜2026/8/31)→1,900(9/1〜)}
2. 直近3か月の月間消費実績:{値、不明なら「計測開始月」と記入}
3. 超過を許容できる月額上限:{円}(ドル換算レート{値}円)
4. 出力は「上限値」「50%・80%到達時の社内通知ルール」
「9月1日以降の見直し日程」の3点
チーム人数:{値}
3本目は、モデル使い分けの社内基準づくりです。
プロンプト3:Copilotモデル使い分け基準の作成
GitHub Copilotで使うAIモデルの社内基準を作成してください。
条件:
1. タスクを「定型修正」「新規スクリプト開発」「設計相談」
「大規模リファクタ」の4分類にする
2. 各分類に「標準モデルで十分/上位モデルを許可」の判定と理由を1行
3. 上位モデルの利用は事前申請にするか、事後レポートにするかの
運用案を2パターン提示
4. クレジット消費を月次でレビューする会議体の頻度を提案
主な開発対象:{例:受注CSV加工、在庫連携、商品ページ一括更新}
EC開発の現場でクレジットを守る実装パターン
制度の理解と別に、日々の開発でクレジット消費を抑える実装上の型があります。EC事業者の内製チームで再現性が高かった順に3つ挙げます。
第一に、コンテキストの絞り込みです。エージェントにリポジトリ全体を読ませるのではなく、対象のスクリプトと関連ファイルだけを開いた状態で依頼すると、読み込みトークンが大きく減ります。受注CSV加工のような独立性の高いスクリプト群は、リポジトリ自体を業務別に分けておくと、この絞り込みが自然に効きます。
第二に、会話の使い切りです。1つのチャットセッションで話題を次々に変えると、過去のやり取りが毎回コンテキストとして再送され、消費が雪だるま式に増えます。タスクが変わったら新しいセッションを開く。この習慣だけで、チャット系の消費は体感で目に見えて変わります(消費量は利用状況により変動、運用目安)。
第三に、下書きと仕上げの分離です。仕様の相談やコードの構想は無料のChatGPTやClaudeの画面で済ませ、Copilotにはコードの実装と修正だけを頼む分業です。AIツールを複数使い分けるのは一見遠回りですが、クレジットが減るのは「Copilotでなければできない作業」に絞られるため、月次の消費が読みやすくなります。
この3つに共通するのは、特別な設定ではなく使い方の習慣だという点です。spending capが事故を防ぐ保険だとすれば、習慣は保険を使わずに済ませる日常の運転技術に当たります。
移行期に済ませておく確認リスト
2026年9月1日のプロモーション終了までに済ませておくべき確認を、時系列で整理します。
まず今月中に、GitHubの利用状況画面(Usage)でチーム全員の月間クレジット消費を確認し、増量前の基準値(Business 1,900)と比べます。次に、超過が見込まれるメンバーの内訳を見て、エージェント利用が原因か、モデル選択が原因かを切り分けます。原因がモデル選択なら、プロンプト3で作る使い分け基準の運用開始で吸収できる場合が多く、エージェント利用が原因なら業務そのものの優先順位づけが必要です。
8月中には、spending capの本設定と、9月以降の月次レビューの会議体(15分の定例で十分です)を決めます。9月の初回レビューで実測値と基準値のずれを補正すれば、移行は完了です。ここまでやっても総工数は数時間で、想定外の請求1回分より確実に安く済みます。
失敗例と回避策
現場で繰り返し見るのは、移行プロモーション中の増量クレジット(Business 3,000)を基準に運用を組んでしまい、9月1日の1,900への減少で突然足りなくなるパターンです。回避策は、いまの消費実績を「1,900だったら足りるか」で評価しておくことです。
もう1つのNGは、spending capを無制限のまま放置することです。エージェント機能は1タスクで数十万トークンを消費することがあり、上限なしでは月末の請求で初めて気づくことになります。導入初月は低めの上限で始め、実測を見て緩める順序が安全です。
直近の支援案件で観測したのは、店舗運用担当が善意で「Copilotに全部任せる」使い方を広め、開発者より消費が大きくなっていたケースです。補完のみの利用者と、エージェントを使う利用者を分けて可視化するだけで、対策の対象が明確になります。
KPI設計と費用・工数目安
管理のKPIは3つです。第一に月間クレジット消費率(付与に対する消費の割合)、第二に超過課金額、第三にエージェント利用1タスクあたりの平均消費です。消費率が3か月連続で90%を超えるなら、プラン増強か使い分け基準の見直しのサインです。
費用の目安は、個人利用ならPro 10ドル/Pro+ 39ドル、法人ならBusiness・Enterpriseのシート費用に超過分が加わる構造です(2026年7月時点)。月商5,000万円帯で内製開発を回す店舗なら、開発2〜3名でBusiness+若干の超過という水準が現実的な出発点です(利用量に依存、業界目安)。
代替ツールとの比較検討はすべきか
従量化を機に「Copilotをやめて別のツールへ」という検討も出てきます。判断の枠組みを短く整理しておきます。
結論として、コード補完が利用の中心なら乗り換えの必要はありません。補完は引き続き定額無制限のため、従量化の影響を実質受けていないからです。検討に値するのは、エージェント利用が中心で超過課金が常態化しているケースです。この場合の比較対象は、OpenAIのCodex(ChatGPT経由の共通従量プール)、AnthropicのClaude Code、そしてCursorなどの専業エディタになります。ただしどのツールも従量またはクレジット系の課金へ収斂しつつあり、「定額で使い放題」の選択肢は市場からほぼ消えました。
乗り換え判断で見るべきは単価表ではなく、自社の主要タスクでの消費実測です。同じ「受注CSV加工スクリプトの修正」でも、ツールごとにコンテキストの持ち方が違うため消費量は変わります。主要タスク3つを各ツールで1週間ずつ回し、タスクあたりコストで比べるのが確実です。EC開発でのCodexとの比較観点はCodex×GPT-5.6の記事も参考になります。
もう1点、GitHubにコードとCI/CDが載っている場合、Copilotはリポジトリとの統合が深い分、周辺作業(プルリクエストの説明生成、レビュー支援)まで含めた総合力で優位が残ります。ツール単体の単価だけでなく、開発フロー全体での置き換えコストを含めて判断してください。
今後の展望と独自考察
Copilotの従量化は単独の値上げ策ではなく、業界全体の流れです。エージェントがトークンを大量消費する時代に、回数ベースの定額は提供側が持ちこたえられません。OpenAIのCodexも共通従量プールとSpend Controlsを導入しており、「AI開発ツールは変動費」という前提はベンダーを問わず定着していきます。
EC事業者にとっての本質は、開発の内製化で得た効率を従量コストが食い潰さないよう、消費を業務単位で把握することです。逆に言えば、消費の内訳が見えるようになったことで「どの自動化が割に合っているか」をコストで評価できるようにもなりました。従量化は管理の手間を増やす一方で、投資判断の解像度を上げる変化でもあります。
中長期では、この従量データが「内製と外注の境界」を引き直す材料になると見ています。これまで開発の外注費と内製の人件費は比べられても、内製のAI費用は固定費に埋もれて見えませんでした。タスク単位の消費が見える今は、「この連携ツールの開発は内製AIで数千円、外注なら数十万円」という比較が月次で可能です。従量化を負担と捉えるか、意思決定の材料と捉えるか。管理の型を先に作った事業者ほど、後者の恩恵を受け取ることになります。
よくある質問
GitHub Copilotの従量課金はいつから始まりましたか
2026年6月1日からです。全プランでPremium Requestsが廃止され、GitHub AI Creditsによる使用量ベース課金へ移行しました。
コード補完もクレジットを消費しますか
いいえ、消費しません。コード補完とnext edit suggestionsは有料プランで無制限のまま、クレジット課金の対象外です。消費するのはChatやエージェント系の機能です。
プランごとのクレジット付与額はいくらですか
Pro は月10ドル分、Pro+は月39ドル分です。法人はBusinessが1ユーザー月1,900、Enterpriseが3,900クレジットで、既存顧客は2026年9月1日までBusiness 3,000・Enterprise 7,000に増量されています。
想定外の請求を防ぐにはどうすればいいですか
支出上限(spending cap)の設定が必須です。導入初月は低めに設定し、実測を見て調整してください。50%・80%到達時の社内通知ルールもセットで決めるのが定石です。
EC事業者に影響はありますか
はい、あります。受注処理や在庫連携スクリプトの内製にエージェント機能を使う場合、トークン消費が大きく、旧制度の感覚では月半ばでクレジットを使い切ることがあります。
9月1日以降は何が変わりますか
既存法人顧客への移行期プロモーションが終了し、付与額がBusiness 3,000→1,900、Enterprise 7,000→3,900へ下がります。いまの消費実績を減少後の付与額で評価しておくことをおすすめします。
クレジット消費を減らす一番簡単な方法は何ですか
タスクごとに新しいチャットセッションを開くことです。同じセッションで話題を変え続けると過去のやり取りが毎回再送されて消費が膨らみます。加えて、リポジトリ全体ではなく対象ファイルだけを開いて依頼する絞り込みも効きます。
個人のProプランでもspending capは設定できますか
はい、設定できます。個人・法人を問わず支出上限の設定が可能で、上限到達時には超過課金を止められます。導入初月は低めに設定し、実測を見て調整する順序が安全です。
著者:齋藤竹紘(株式会社オルセル 編集長/5,000社以上のEC支援実績/書籍3冊)
参考文献
- GitHub公式ブログ: GitHub CopilotのUsage-Based Billing移行について
- DevelopersIO: GitHub Copilotの料金体系が2026年6月1日に大改定
- GitHub Copilot 公式ドキュメント
※うるチカラでは、生成AIの導入支援から運用最適化まで、貴社のEC事業に合わせたカスタマイズ提案を行っています。無料相談(30分)も実施中ですので、お気軽にお問い合わせください。
https://uruchikara.jp/contact/

株式会社オルセル代表取締役 / うるチカラ編集長。19年・5,000社以上のEC支援実績を持ち、楽天市場・Amazon・Yahoo!ショッピング・Shopify・Shopee越境ECの実装ノウハウを保有。AI×ECに関する書籍を3冊執筆。「現場で使えるAI実装」を一次情報として発信しています。