AIトークン予算はなぜ足りなくなるのか：クレジット制時代の資源配分設計¶
個人上限を決める前の判断
| 共有プールの状態 | 先に置く制御 |
|---|---|
| 最低限の利用を全員へ残したい | 保証枠を先に確保する |
| 余った枠をヘビーユーザーへ回したい | 共有バースト枠を分ける |
| 月半ばの集中利用を平準化したい | 時間減衰つき優先度を使う |
| 障害対応を止められない | 業務別の優先度クラスを置く |
個人の利用画面では上限まで余裕があるのに、会社の共有AIクレジットはすでに空になっている。 この矛盾は、個人上限が「使いすぎない量」を決めても「必ず使える量」を確保しないために起きる。 企業は上限の一覧ではなく、保証枠、共有バースト枠、混雑時の優先度を持つスケジューラとしてAI予算を設計する必要がある。
AI支出は座席管理から共有資源の管理へ移った¶
FinOps Foundationの2026年調査は全体で1,192人から回答を得た。 AI支出の管理に関する設問では回答者693人の98%が管理対象にしており、2024年の31%、2025年の63%から増えた。1 AIコスト管理は今後追加したいスキルの首位にもなった。
GitHub AI Creditsは共有効率と枯渇を同時に持ち込む¶
GitHub Copilotの月次プランは2026年6月1日にGitHub AI Creditsへ移行し、BusinessとEnterpriseでは各席の含みクレジットを組織全体で共有する設計になった。 既存顧客向けの増量は6月から8月までで、9月からは通常の含み額へ戻る。2 含みクレジットが尽きた後は、追加利用を許可して従量課金を続けるか、次の請求周期まで利用を止める。3 共有は未使用分を活用するが、配分の公平性や業務上の優先度までは決めない。
個人上限だけでは配分が先着順になる¶
従業員1,000人が月間100万クレジットを共有する企業を考える。 利用しない社員の余剰を見込み、一人あたりの上限を2,000クレジットに設定したとする。
月の前半に500人が上限まで使えば、500 × 2,000 = 1,000,000となり、共有プールは空になる。 残りの500人は個人上限へ達していなくても利用できない。
ここで壊れているのは計算ではなく、上限の意味である。 上限は最大消費量であり、最低利用可能量ではない。 プールに空きがある間は両者の違いが見えず、需要が集中した時点で先着順だったことが表面化する。
GitHubはEnterprise、コストセンター、ユーザーの各階層に予算を置けるが、予算機能そのものが全利用者の最低枠を予約するわけではない。2 最低利用可能量を守るには、利用要求を受け付ける共通ゲートウェイ側で、個人上限とは別の配分規則を実装する必要がある。
Kubernetesは上限と配置判断を分けている¶
クラスタスケジューラは、有限の計算資源へ複数の仕事を載せる問題を長く扱ってきた。 Kubernetesではrequestがスケジューラの配置判断に使う量、limitが実行中のコンテナへ適用する上限である。 スケジューラはrequestの合計がノード容量を超えないように配置し、kubeletはlimitを実行時に適用する。4
ただし「Kubernetesでlimitだけを設定すればrequestは空になる」という説明は正しくない。 既定requestが別途適用されていない場合、Kubernetesは指定されたlimitをrequestへコピーする。4 AI予算へ借りるべきなのは設定の表面ではなく、配置に使う量と実行時の上限を別の機能として扱う設計である。
この対応関係を企業のAIクレジットへ移すと、次のようになる。
| スケジューラの機能 | AIクレジットでの役割 | 守るもの |
|---|---|---|
| request相当 | 一定期間の保証枠 | 最低限の利用可能量 |
| limit相当 | ユーザーや業務の最大消費量 | 暴走の停止 |
| spare capacity | 共有バースト枠 | 未使用分の活用 |
| priority | 混雑時の実行順 | 業務継続 |
この表はKubernetesの機能をそのまま課金システムへ移植する手順ではない。 CPUやメモリと異なり、AIリクエストは実行前に最終消費量を確定しにくく、ベンダーをまたぐクレジットは交換できない場合もある。 Kubernetesは語彙と分離原則の参照先であり、完成済みのAI予算機能ではない。
保証枠とバースト枠は可用性と利用率を両立させる¶
先の例では、100万クレジットのうち30万を保証枠、70万を共有バースト枠にする構成を試せる。 一人あたり300クレジットを保証し、それを超える利用だけを共有枠から差し引く。
この数値は推奨比率ではなく、仕組みを説明する例である。 実際の保証総量は、最低限通したい業務、同時利用の集中度、超過課金の可否、利用データの遅延から決める。 全員に同じ保証を置く必要もなく、部署または業務単位の保証にしたほうが需要を予測しやすい場合がある。
未使用の保証枠は永久に固定しない。 たとえば週の初めは利用者へ予約し、期限を過ぎた未使用分を共有バースト枠へ戻せば、最低限の可用性と死蔵の抑制を両立できる。 ただし回収後も同じ期間の保証を名乗るなら、再要求時に戻せる容量または超過予算を残しておく必要がある。
フェアシェアは混雑している時間だけ順番を変える¶
保証枠を超えた要求は、単純な先着順にしない。 直近で多く使った部門の優先度を混雑時だけ下げ、時間経過とともにその影響を減らす。
SlurmのFair Treeは、アカウント階層のLevel FSを使って利用者のfairshare順位を計算し、優先度計算で過去利用の半減期を扱う。5 AIクレジットでも、直近のバースト利用を時間減衰させれば、月初の大量利用が月末まで永久的な罰にならない。
初期設定では履歴をコストセンター単位に持ち、減衰後のバースト消費 ÷ 割当shareが小さい順に通す。 半減期は24時間とし、同じ値なら到着順にする。 24時間は普遍的な推奨値ではなく、日中の集中利用を翌日までに弱めるための開始値であり、実測した待ち時間から調整する。
フェアシェアは総量削減策ではない。 共有枠に余裕があれば全要求を通し、競合した瞬間だけ順番を調整する。 同じ部門内の個人暴走は個人上限で止め、部門間のバースト競合だけをfairshareで調整する。
優先度クラスは業務影響を配分へ反映する¶
同じクレジット消費でも、本番障害の原因調査と探索的な実験では、待たせたときの損失が異なる。 共通ゲートウェイは、次の初期規則で要求を三つへ分類できる。
| クラス | 登録条件 | 利用できる枠 | 待ち時間の扱い |
|---|---|---|---|
| 継続必須 | 事故番号または顧客影響ID、承認、有効期限24時間 | 全体の5%を緊急予備枠として分離 | 他クラスから昇格不可 |
| 標準 | 登録済みの通常業務 | 保証枠と緊急予備を除くバースト枠 | 同一クラス内fairshare |
| 余裕時 | 実験、学習、再開可能バッチ | 上位クラスの待ちがない時だけ | 2時間後に標準へ一段階だけ昇格 |
5%と2時間は初期値であり、事故対応の実績と待ち時間から調整する。
優先度は役職ではなく業務の失敗影響へ結び付ける。 役職をそのまま優先度にすると、高い権限を持つ人の低重要度な利用が、現場の障害対応を押し出すためである。
待ち行列では優先度クラスを先に比較し、同じクラスの中をfairshare順に並べる。 余裕時から標準への昇格は緊急予備枠へ入れず、継続必須クラスを侵食しない。
利用者が自分で継続必須を選べる設計にはしない。 業務責任者が事故番号または顧客影響IDと有効期限を登録し、AI基盤チームが承認し、期限切れの分類を標準へ戻す。 継続必須の更新は別の承認を必要とし、誤分類が判明した要求は標準へ戻して責任者へ通知する。 月次監査では緊急予備枠の利用率と誤分類を確認する。
AI処理では、実行中の低優先度ジョブを途中停止しても、消費済みトークンは戻らない。 そのためプリエンプションは、可能な限り実行開始前の待ち行列、次のエージェント反復、再開可能なバッチ境界で行う。
原子的な仮押さえが保証枠の使い過ぎを防ぐ¶
保証枠を台帳に表示するだけでは、同時に到着した複数要求が同じ残高を読み、合計で保証を超える。 認証、見積もり、仮押さえ、優先度、実績精算を扱う共通ゲートウェイを制御点にする。 以下は実装判断に必要な不変条件であり、特定ベンダー向けの完成コードや障害処理を網羅する仕様ではない。
ゲートウェイは要求ごとに次の順序で判断する。
- 業務責任者が用途、優先度クラス、有効期限、最大出力を登録し、エージェント反復は一回ずつ別要求にする。
- ゲートウェイが確定済み入力、モデル単価、最大出力から、その一回で発生し得る最大額を仮押さえする。
- 呼出側がbilling entity、業務、論理操作の組み合わせで安定したidempotency keyを渡し、ゲートウェイが一意制約で同じ結果を再生する。
- 残高が足りなければ、クラス間の順序とクラス内fairshareに従って待機、縮小、例外承認、拒否へ分岐する。
- 実行終了後に実消費を精算し、未使用分を戻し、見積もり超過分を専用の安全余裕から差し引く。
安全余裕は、価格表との差やベンダー計測の遅延を照合するため、利用可能枠として配らない。 ゲートウェイは最大出力をプロバイダー呼び出しにも渡し、エージェントの次の反復には新しい仮押さえを要求する。 これにより、通常の実消費は仮押さえを超えず、価格変更などで超えた場合は新規バースト要求を止め、安全余裕から精算して価格表を更新する。
ゲートウェイはidempotency keyへrequestidを一つだけ割り当て、再送には既存の状態または結果を返す。 仮押さえ台帳は、保証枠、バースト枠、緊急予備枠、安全余裕から取った額を別々の列に記録する。 仮押さえの正常系はHELD → DISPATCHED → SETTLEDとする。 外部呼び出し前にHELD → DISPATCHEDを比較交換で所有し、同じトランザクションでoutboxへ送信予定を記録する。 dispatcherは、プロバイダーが冪等キーに対応する場合だけ、同じrequestidでoutboxを再送する。 非対応の場合は不明応答を自動再送せずDISPATCHEDで隔離し、期限切れ処理との競合では状態遷移に勝った側だけが実行する。 dispatch前の期限切れまたは拒否だけはHELD → CANCELEDへ移し、その原子的な遷移と同時に容量を戻す。 DISPATCHED → CANCELEDは、プロバイダーの最大計測遅延を過ぎ、利用がなかったと確認できた場合だけ許可し、その遷移時に容量を戻す。 利用実績が見つかればDISPATCHED → SETTLEDへ進み、SETTLEDとCANCELEDは終端状態にする。 DISPATCHEDをHELDへ戻す遷移や、照合前の容量解放は許可しない。 DISPATCHED → SETTLED、精算、返金、枠別残高の更新は一つのトランザクションにし、request_idとプロバイダー利用IDで冪等にして重複callbackを無視する。 dispatch結果が不明な間はDISPATCHEDのまま隔離する。 CANCELED後に遅延利用が届いた場合は安全余裕へ計上し、台帳に記録した各資金枠の新規バーストを凍結して人が照合する。
公平性は均等配分ではなく成果と学習機会で測る¶
均等配分は説明しやすいが、現在のヘビーユーザーだけへ集中すると、AIをまだ使いこなせない職種の学習機会を奪う。 通常業務の保証枠は利用機会を守り、教育は余裕時クラスで待機可能にする。 業務価値の測定とモデルルーティングは、既存のAI FinOps設計で扱っている。
この設計が機能しない条件も残る¶
保証枠とfairshareは、共有プールをリアルタイムに観測し、要求を一つの入口で制御できる場合に機能する。 各部門が別々のSaaS契約を持ち、使用量データが数日遅れ、クレジットを移せないなら、共通スケジューラは帳簿上の配分にとどまる。
定額制への回帰もあり得る。 軽量な補完や短い質問は定額に含め、高性能モデルや長時間エージェントだけを従量化する二層構造なら、すべての要求を細かくスケジュールする費用を減らせる。
生成量より人間のレビュー能力が先に尽きる業務では、トークン予算を増やしても成果は増えない。 その場合はクレジット配分より、検証待ち行列、承認者、テスト自動化を先に改善する。
実装仕様で四つの合否例を固定する¶
| 例 | 初期値とイベント順 | 合格条件 |
|---|---|---|
| 同一操作の同時再送 | 保証300、同じkeyで最大100の要求を同時に2回、実績80のcallbackを2回 | request_idは1件。プロバイダー冪等キーがある場合は課金対象操作も1件。精算後の保証残高は220で、callback再送は残高を変えない |
| dispatchと期限切れの競合 | 保証300、hold 100で比較交換を同時実行 | dispatch勝利なら残高200のまま照合し呼出1件。cancel勝利なら残高300、呼出0件 |
| 枯渇と優先度 | burst 0、別部門の保証50、A/B share各1、減衰後利用A=200・B=100 | 保証50は通る。同一クラスはB、A、同値なら到着順。継続必須は5%予備だけを使う |
| agingと遅延計測 | 余裕時要求を1時間59分と2時間で評価し、dispatch後に利用あり／なしを返す | 2時間未満は余裕時、2時間で標準。緊急予備へは入らず、利用ありはSETTLED、最大計測遅延後の不使用確認だけCANCELED |
この表は受け入れ例であり、障害注入、永続化、プロバイダー別の計測仕様を含む完全なテスト計画ではない。
個人上限は、この四つを通した後に暴走防止として置く。 上限だけでは先着順を隠すが、仮押さえ、保証、共有、優先度を検証すれば、枯渇時に守る業務を説明できる。
関連記事¶
出典¶
FinOps Foundation, State of FinOps 2026, 2026-02-19。 全体回答者1,192人、AI管理設問のN=693、管理率の推移、スキル要望を参照した。 ↩
GitHub, GitHub CopilotのUsage-Based Billing移行について, 2026-04-28。 月次プランの移行日、法人プランの含み額、6月から8月の増量、使用量プール、予算階層を参照した。 ↩↩
GitHub Docs, Usage-based billing for organizations and enterprises, 2026-08-09参照。 プール枯渇後の追加利用または停止を参照した。 ↩
Kubernetes Documentation, Resource Management for Pods and Containers, 2026-08-09参照。 request、limit、スケジューリング、limitのみ指定した場合のrequest補完を参照した。 ↩↩
SchedMD, Slurm Workload Manager: Fair Tree Fairshare Algorithm, 2026-08-09参照。 fairshare順位と半減期による減衰を参照した。 ↩