既定値のままでは予算は守れない——GitHub Copilotの従量課金を公費で統制するために

Posted at 2026-09-23

※価格・仕様は2026年9月23日時点。本稿の数量は比較のための仮定であり、自治体の標準的な利用実績や、特定モデルの性能を示すものではない。

はじめに

GitHub Copilot Business／Enterpriseでは、2026年6月1日から、プレミアムリクエストの回数を基準とする課金から、入力・出力・キャッシュのトークン消費量に各モデルのAPI公表単価を当てはめ、GitHub AI Creditsとして消費する方式へ移行した。以前から追加利用の料金はあったが、今後はモデル選択に加え、読み込む情報量やエージェントの作業量が費用により直接反映される。

公費での利用では、支出の原因となる契約その他の行為を、法令または予算の定めに従って行う必要がある。従量課金そのものが禁じられているわけではない。ただ、利用量に応じて債務が増える契約では、契約条件、利用上限、監視・承認の手順を組み合わせ、承認予算を超えない管理を設計しなければならない。

本稿では、GitHubが公表するCopilotのモデル別単価を素材に、その設計上の論点を整理する。先に結論を言えば、Copilotには予算統制に使える機能がひととおり揃っている。しかし主要な既定値は、いずれも「使わせる」側に倒れている。

1. 料金は三層になった

プラン料金は据え置きで、Businessは1ユーザー月19ドル、Enterpriseは月39ドルのままである。付与されるAIクレジットは、1ユーザー・月あたりBusinessで1,900、Enterpriseで3,900。付与分は請求主体となる組織またはエンタープライズで共有され、例えばBusiness 100ユーザーのエンタープライズなら、100個の個別枠ではなく19万クレジットの共有量になる。これは各利用者に保証された個別枠ではない。

既存顧客には移行後の3か月（6〜8月）、通常より多い付与枠が適用されていた。9月分から標準量に戻ったため、本稿では1,900／3,900クレジットを使う。

整理すると、料金は次の三層になる。

第1層：利用者ごとのライセンス料（定額）
第2層：ライセンス料に含まれ、請求主体の中で共有する付与クレジット
第3層：付与分を超えた利用（従量）。1クレジット＝0.01ドルで課金される

なお、コード補完と次の編集候補の提示はクレジットを消費しない。

第1層と第2層は、従来どおり「人数×単価」で積算できる。問題は第3層である。その大きさは、誰が、どのモデルを、どう使うかで決まり、予算編成の時点では確定しない。

2. 素材とする単価表

比較のため、各社の現行モデルから筆者が選んだ10モデルを用いる。価格はGitHubがCopilotについて公表している標準単価で、長文割増は第5節で別に扱う。

図1　比較に用いる10モデルの標準単価（100万トークンあたり、米ドル）

モデル	ベンダー	入力	キャッシュ読込	キャッシュ書込	出力
GPT-6 Astra	OpenAI	$10.00	$1.00	$12.50	$50.00
Claude Fable 5.1	Anthropic	$10.00	$0.25	$12.50	$50.00
Claude Opus 5.5	Anthropic	$4.00	$0.20	$5.00	$20.00
Kimi K3	Moonshot AI	$3.00	$0.30	—	$15.00
GPT-6 Sol	OpenAI	$2.00	$0.20	$2.50	$10.00
Claude Sonnet 5	Anthropic	$2.00	$0.20	$2.50	$10.00
Grok 4.7	xAI	$2.00	$0.50	—	$6.00
Gemini 3.8 Flash	Google	$0.75	$0.075	—	$3.75
MAI-Code-1.1-Flash	Microsoft	$0.20	$0.02	—	$1.20
GPT-6 Luna	OpenAI	$0.10	$0.01	$0.125	$0.50

※Gemini 3.8 Flashは2026年12月31日までのプロモーション価格。
※「—」はCopilotの価格表に別建てのキャッシュ書込単価が掲載されていないことを示し、未キャッシュの入力が無料であることを意味しない。本稿の試算では通常入力単価で計上する。

入力・キャッシュ読込・出力の共通項目がベンダー自身のAPI価格と一致する例は確認できるが、キャッシュの保存時間料金や書込区分など、各社API固有の料金体系までCopilotと同一とは限らない。

3. 論点1　許可するモデルが、費用の前提を決める

単価表だけでは予算感がつかみにくいので、1作業あたりのクレジットに換算する。ここでの「1回」は、利用者が依頼する1つの作業を指す。

試算Aは、多量の資料やコードを参照する相談を想定し、入力10万トークン、出力1万トークン、キャッシュなしとした。試算Bは、複数回のモデル呼出しを伴う作業を想定し、その累計としてキャッシュ読込90万、未キャッシュの入力10万、出力3万トークンとした。書込単価が公表されているモデルでは、この10万トークンをすべて新規のキャッシュ書込として計上し、通常入力料とは重ねて数えない。各呼出しは、利用環境の入力上限と長文割増の閾値を超えないものとする。出力には、課金対象となる推論トークンも含む。

計算式は「消費クレジット＝Σ（単価×トークン数）÷100万×100」である。

図2　1作業あたりの消費クレジット

モデル	試算A	試算B	1,900cr以内で完了できる試算Aの回数
GPT-6 Astra	150	365	12回
Claude Fable 5.1	150	297.5	12回
Claude Opus 5.5	60	128	31回
Kimi K3	45	102	42回
GPT-6 Sol	30	73	63回
Claude Sonnet 5	30	73	63回
Grok 4.7	26	83	73回
Gemini 3.8 Flash	11.25	25.5	168回
MAI-Code-1.1-Flash	3.2	7.4	593回
GPT-6 Luna	1.5	3.65	1,266回

Businessの1ライセンスが共有量に加える1,900クレジットだけで換算すると、試算Aを全額まかなえる回数は、GPT-6 Astraで12回、GPT-6 Lunaで1,266回になる。1作業あたりの消費クレジットの比は、この仮定では100倍である。ただし共有プールのため、個人の利用可能量が1,900クレジットに固定されるわけではない。また、各モデルが同じ成果を同じトークン量で達成するとは限らないので、これは成果あたりの費用の比ではない。

次に部署単位で見る。ここでは、Business 20ライセンスのみで構成される請求主体を仮定し、他部署や他機能によるクレジット消費はないものとする。月初の共有量は3万8,000クレジット。20人が1日3作業、月20営業日利用すると、月1,200作業になる。

図3　20ライセンス・月1,200作業の消費と超過額

モデル	試算A 月消費（cr）	試算A 超過額	試算B 月消費（cr）	試算B 超過額
GPT-6 Astra	180,000	$1,420	438,000	$4,000
Claude Fable 5.1	180,000	$1,420	357,000	$3,190
Claude Opus 5.5	72,000	$340	153,600	$1,156
Kimi K3	54,000	$160	122,400	$844
GPT-6 Sol	36,000	$0	87,600	$496
Claude Sonnet 5	36,000	$0	87,600	$496
Grok 4.7	31,200	$0	99,600	$616
Gemini 3.8 Flash	13,500	$0	30,600	$0
MAI-Code-1.1-Flash	3,840	$0	8,880	$0
GPT-6 Luna	1,800	$0	4,380	$0

※超過額＝max（0、月消費−38,000）×0.01ドル。ライセンス料、税、為替、GitHub Actions等の別料金は含まない。

この条件では、ライセンス料は月380ドルで一定だが、AIクレジットの超過額は月0〜4,000ドルとなる。この月額差を単純に12倍すると4万8,000ドルになる。ただし、これは同じ価格と利用条件を置いた比較であり、実際の年間支出の予測や上限を示すものではない。

それでも言えるのは、どのモデルの利用を許可するかは、技術選定であると同時に、費用の前提を決める行為でもあるということだ。モデルの許可は、通常エンタープライズ全体または組織単位で設定する。加えて2026年7月31日に公開プレビューとなった機能では、エンタープライズ全体の基準を定めたうえで、特定のエンタープライズチームに追加のモデルを許可できる。いずれかのチームで許可されたモデルは、その利用者がどこでも使える扱いになり、この方式を有効にすると組織単位のモデル設定は適用されなくなる。

一方、予算管理に使うコストセンターは、それ自体ではモデルを制限できない。高単価モデルの利用者を絞るなら、組織単位またはチーム単位のモデル設定と、コストセンターの対象者を対応させる設計が必要になる。利用目的の限定は、別途、運用ルールで定める。積算根拠には許可モデルの一覧を含め、モデルを変更する際は積算への影響を確認し、必要な承認・予算措置を行うのが筋である。

4. 論点2　利用パターンで、単価の順位が入れ替わる

図2の試算Aと試算Bを比べると、順位が入れ替わる箇所がある。

試算Aでは同額のGPT-6 AstraとClaude Fable 5.1が、試算BではFable 5.1のほうが約18.5%少なくなる。また、試算AではGPT-6 SolやClaude Sonnet 5より少ないGrok 4.7が、試算Bでは約13.7%多くなる。

背景にあるのは、以前に処理した入力を再利用するキャッシュ読込の単価差である。図1の10モデルでは、キャッシュ読込単価が通常入力単価の10%となるものが7モデルある一方、Fable 5.1は2.5%、Opus 5.5は5%、Grok 4.7は25%である。これに出力単価や書込条件が重なって、総額の順位が変わる。いずれも固定したトークン量に各単価を当てはめた結果で、性能や仕事の達成費用の比較ではない。

積算には、単価表に加えて想定する利用パターンが必要であり、その利用パターンは組織ごとに違う。実際の予算編成では、試行利用の記録を基に、通常月と多用月の両方を見積もる方法が有効である。

5. 論点3　事前に積算しにくいコスト、年度内に動く単価

第一に、コードレビューである。使用モデルが自動選択され開示されないため、特定モデルのトークン単価だけから事前に積算することは難しい。さらにAIクレジットに加え、GitHub Actionsの実行時間も消費する。レビュー件数あたりの実績とActionsの利用量を別々に集計し、追加請求の有無をそれぞれの契約条件で確認する必要がある。

第二に、長い入力を扱う際の割増である。GitHubの価格表では、図1のOpenAIの3モデルは1回の呼出しの入力が27万2,000トークンを超えると、入力とキャッシュの各単価が2倍、出力単価が1.5倍になる。Grok 4.7は20万トークン超で、入力・キャッシュ読込・出力が2倍になる。各社のAPI説明では、キャッシュ読込も閾値の判定に含まれ、割増は超過分だけでなく、その呼出し全体に適用される。仮に試算Bのすべての呼出しが割増対象になれば、GPT-6 Astraの1作業あたり消費は365から655クレジットに上がる。

第三に、年度途中の単価変動である。Gemini 3.8 FlashのCopilotでの価格は2026年12月31日までのプロモーション価格で、Googleは自社APIについて、2027年1月1日から入出力単価を2倍にすると公表している。GitHubの価格表には終了後のCopilot単価が掲載されていないため、年度後半の積算では更新情報の確認が必要になる。

第四に、通貨と支払条件である。AIクレジットの換算基準は1クレジット＝0.01米ドルだが、実際の請求通貨・支払方法は調達経路と契約で異なる。GitHubはAzure経由の請求に対応しており、日本円で請求される契約形態もある。ただし円建て請求でも、為替換算や価格改定の影響がなくなるとは限らない。また、カード／PayPal払いの既存Business／Enterprise顧客には、2026年10月1日から、請求サイクルの開始時に全席分を前払いで課金する変更が適用される予定である。請求書払いやAzure経由等を含め、採用する経路の支払条件を個別に確認したい。

6. 論点4　既定値のままでは、承認予算に収まらない

Copilotの予算統制で最も注意すべきは、3つの既定値である。

既定値1：付与分を超えた有料利用は、既定で有効。
組織・エンタープライズでは超過利用が既定で認められており、付与分を超える支出を防ぐには、管理者がAI Controlsで有料利用のポリシー（AI credits paid usage）を明示的に無効にする必要がある。

既定値2：支出上限を登録しても、既定では止まらない。
エンタープライズ・組織・コストセンターの支出上限は、既定では到達時に通知を送るだけで利用は止まらない。止めるには、上限ごとに上限到達時の停止設定（Stop usage when budget limit is reached）を有効にする必要がある。なお、利用者ごとの上限はこの設定がなくても常に停止を伴い、付与分と有料分を合わせた消費量を対象とする。上限を0ドルにすると、その利用者は付与分も使えなくなる。他方、エンタープライズの支出上限が抑えるのは、共有量を使い切った後の従量課金であり、ライセンス料を含む総額ではない。

既定値3：新しく一般提供されたモデルは、既定で使える。
2026年8月26日から9月1日にかけて段階的に、管理者が個別に設定していないモデルは既定ポリシーに従うようになり、そのポリシーの既定は「有効」である。つまり、単価の高い新モデルが、設定を変えないまま職員に開放されうる。なお、オープンウェイトのモデルや、GitHubのデータ保持契約の対象外のモデル（例：Fable 5）は、ポリシーにかかわらず既定では無効となる。

上限に達したときに何が起きるかも押さえておく。予算が尽きても低価格モデルへ自動で切り替わる仕組みはなく、チャットやエージェントなどAIクレジットを消費する機能が止まる。一方、コード補完と次の編集候補の提示は引き続き利用できる。

付与分は翌月へ繰り越されず、毎月1日0時（UTC）、日本時間では9時に、その月の付与量へリセットされる。したがって4月1日の日本時間0〜9時の利用はGitHub上では3月分の付与サイクルに含まれ、付与サイクルをそのまま日本の会計年度帰属とみなすことはできない。また、枠を使い切ったBusiness／Enterpriseの利用者には、GitHub.com上で管理者へ追加予算を依頼する案内が表示される。承認の前に、自治体側の予算・契約手続が必要かを確認することになる。

これらの機能を、予算管理上の目的に沿って整理すると次のようになる。

図4　予算管理上の目的と、Copilotで使える補助手段

予算管理上の目的	Copilotの補助手段	別途必要な手続・注意点
契約総額を承認予算に収める	有料利用ポリシー、超過利用の支出上限と停止設定	ライセンス料・Actions等・税・為替も含めて積算
部署別の超過利用を管理する	コストセンター予算	原則として超過課金が対象。付与分の配当とは異なる
付与分の部署別利用を制限する	コストセンターの付与分利用制御	所属ライセンスの付与量から上限を自動計算する別機能
職員別に利用量を制限する	利用者ごとの上限	付与分と有料分を合わせた消費量を制限
単価の前提を管理する	組織／エンタープライズ、またはチームのモデル許可、新モデルの既定ポリシー	価格改定・新モデル追加のたびに確認
追加利用を審査する	利用者から管理者への追加依頼	財源、権限、契約変更等を確認してから設定を変更
年度別の執行を管理する	利用・請求明細	月次リセットとは別に年度帰属を管理

この表は、予算管理を補助する機能の整理である。Copilotの設定や管理者の承認が、自治体の予算・契約・支出の手続を代替するわけではない。

法令との関係も確認しておく。地方自治法第232条の3は、支出の原因となる契約その他の行為を、法令または予算の定めに従って行うことを求めている。また第220条第1項は、長が政令で定める基準に従って予算の執行手続を定め、それに従って執行することを求める。従量課金が禁止されるわけではないが、利用量に応じて債務が増える契約では、支払の段階だけでなく債務を負う段階の管理が必要になる。

調達時の確認事項
単価だけでなく、見込数量、総額上限、価格変更時の取扱い、支払条件を確認する。複数年度の契約では、地方自治法第214条の債務負担行為と、第234条の3の長期継続契約の適用関係を整理する。クラウドサービスであれば当然に長期継続契約にできるわけではなく、施行令第167条の17と当該自治体の条例・契約内容の確認が必要である。

7. 提案　承認予算に収まるよう、技術的上限を設定する

以上を踏まえ、公共部門でCopilotを使う際の要点を5つ挙げる。

1つ目は、超過利用の上限を承認予算から逆算することである。
GitHub自身の手順でも、ライセンス数×単価で付与分の総額を出し、想定する最大消費からそれを差し引いた額を、支出上限でまかなう従量分としている。公費の場合は、円建ての承認予算から、ライセンス料、関連サービス料、税・為替等を見込んだうえで超過利用に使える額を算出し、対応する支出上限と停止設定を利用開始前に設定する。契約全体の予算額を、システム上の超過利用上限にそのまま入力してはいけない。また、エンタープライズの支出上限はコストセンターに属さない利用者に適用されるため、コストセンター予算と合わせて全体を覆うように設計する。

2つ目は、許可モデルを積算根拠に含めることである。
高単価モデルは、明示的に有効・無効を設定するか、新モデルの既定ポリシーを無効にして個別承認とする。利用者を絞る場合は、組織単位またはチーム単位のモデル設定を使い、予算管理のコストセンターと対象者を対応させる。

3つ目は、上限到達時の業務を決めておくことである。
停止対象の機能に依存する業務について、追加承認、作業の延期、補完機能や通常の開発作業への切替を事前に決めておく。

4つ目は、執行状況を短い周期で確認することである。
月次の確認に加え、導入直後や多用時は週次の確認やしきい値アラートを使う。付与サイクルと会計年度の帰属は別に管理する。

5つ目は、試行利用の実績を翌年度の積算に反映することである。
作業数だけでなく、モデル、課金対象の通常入力・書込・読込・出力、長文区分、再試行、追加の実行環境料金、モデル変更日を、可能な範囲で記録する。記録の項目は、「おわりに」で紹介するACUS案のトークン種別（通常入力・キャッシュ読込・キャッシュ書込・出力）や長文区分、Actions分の区分に合わせておくと、後で直接APIなど他の経路の利用と横並びで比較しやすい。

なお、停止設定の適用対象、設定前の利用、処理中のリクエストの扱いなどは、契約・導入時に確認しておきたい。設定額と請求額が必ず一致するとは限らないため、承認予算に余裕を持たせた上限とするのが安全である。

国の府省庁向けには、2025年5月27日に決定されたDS-920（行政の進化と革新のための生成AIの調達・利活用に係るガイドライン）があり、2026年6月12日に第2.0版へ改定された。同版は原則として2026年9月1日から施行されている。費用対効果や、モデル更新時の必要コストの変化にも触れる一方、従量料金の月次上限や超過停止の具体的な設計までは定めていない。自治体は政府と同じ適用対象ではないが、必要に応じて参考とすることが期待されている。

おわりに

単価表は、予算統制の出発点にすぎない。同じ単価表から、許可するモデルと利用パターンの組合せ次第で、超過額ゼロの部署も、月に数千ドルの超過が出る部署も生まれうる。そしてCopilotの既定値は、そのどちらも「設定しなければ起こりうる」状態にしている。公共部門に必要なのは、単価を知ることに加えて、既定値を自組織の予算に合わせて設定し直し、使い方を計測して、それを予算と契約に接続する仕組みである。

計測の土台となるのは利用明細である。ただ、利用量や料金を経路やベンダーをまたいで比較するには、明細の項目・単位・課金区分をそろえる作業が必要になる。筆者はこの問題について、FinOps Foundationの請求データ標準FOCUS 1.4を骨格に、各社APIの直接利用もCopilotのクレジット制も同じ表に載せるための共通スキーマ案「ACUS」をQiitaで公開している。付与量やリセット規則、超過利用の可否を利用明細とは別の表で管理する設計としており、本稿で見た「付与分」「超過分」「月次リセット」を記録する際の参考になれば幸いである。

制作クレジット
問題設定・選定：筆者／起草・最終稿：Claude Opus 5.5（Anthropic）／事実検証・検証メモ：GPT-6 Astra Pro（OpenAI）／検証メモの精査と一次資料の再照合：Claude Opus 5.5

参考資料（確認日はいずれも2026年9月23日）

GitHub（料金・課金仕様）