GitHub Copilotの利用枠とモデル固定の使い方を見直した

ある日、GitHub Copilotの組織利用枠が上限に達しました。

月末までまだ少し日数が残っていましたが、その間はCopilotをほとんど使えない状態になりました。

普段からCopilotをかなり使っているので、使えなくなると想像以上に不便でした。コード補完だけでなく、実装方針の整理、既存コードの確認、ちょっとした調査にも使っていたためです。

私は普段、基本的にAutoモードを使っています。複雑な実装や設計相談など、明確に理由がある場合だけモデルを切り替える程度です。

一方で、組織全体の利用状況を見ると、かなり大きな消費になっているケースもありました。

利用量が多いこと自体が悪いわけではありません。担当しているタスクによっては、長いコンテキストを読ませたり、難しい調査をさせたりすることもあります。

ただ、利用枠が組織全体で共有されている以上、一部の使い方によって全員が使えなくなるのであれば、実際に何が起きていたのかは把握しておきたいところです。

そこで、連続する2か月分の利用データを確認してみました。

先に分かったこと

ざっくりまとめると、次のような傾向でした。

Autoモードの1リクエストあたりの中央値は約100〜130
モデル固定時の中央値は約65〜100
それでも、モデル固定時の平均値はAutoの約2.4〜2.8倍
モデル固定時には、一度に約6,000〜7,000超を消費するスパイクが発生
Autoモードでは、約8割のリクエストでClaude Sonnet以外が選択されていた
固定指定されたClaude Sonnet系は、リクエスト全体の約2割でありながら、消費量の約64〜67％を占めていた

最初は単純に「高性能モデルを固定すると高い」という話だと思っていました。

ただ、実際の分布を見ると、少し違っていました。

中央値では低く見えたモデル固定

2か月分のデータを、公開可能な範囲に丸めると次のようになります。

指定方法	中央値	平均値	最大スパイク
Auto	約100〜130	約100〜140	固定時ほどの極端なスパイクは確認されず
モデル固定	約65〜100	約290〜325	約6,000〜7,000超

意外だったのは、モデル固定の中央値がAutoより低かったことです。

中央値だけを見れば、モデル固定のほうが消費を抑えられているように見えます。

しかし、平均値は逆でした。

モデル固定時の平均消費量は、Autoの約2.4〜2.8倍になっていました。

比較月	モデル固定 ÷ Autoの平均消費量
1か月目	約2.8倍
2か月目	約2.4倍

この差は、少数の大きなリクエストによって生まれていました。

モデル固定時のリクエストには、数文字から1行程度の軽いコード補完が多く含まれていました。こうした処理は消費量が小さいため、中央値を押し下げます。

その一方で、大きなコンテキストを読み込む処理などでは、一度に約6,000〜7,000を超える消費が発生していました。

イメージとしては、次のような分布になります。

Auto
100, 110, 120, 130, 140, 160, ...

モデル固定
20, 30, 50, 70, 90, 6,500, ...

モデル固定時は、常に高いわけではありません。

普段は小さいものの、たまに極端に大きくなります。

その少数のスパイクが、平均値と組織全体の利用枠を大きく押し上げていました。

Autoで選ばれていたSonnet以外のモデル

Autoモードで実際に選択されていたモデルは、主に次のとおりです。

GPT-5.3-Codex
Claude Sonnet 4.6
Claude Haiku 4.5
GPT-5.4
GPT-5.4 mini

2か月とも、最も多く選択されていたのはGPT-5.3-Codexでした。

Autoモード内の選択結果を、Claude Sonnet 4.6とそれ以外に分けると次のようになります。

比較月	Claude Sonnet 4.6	Sonnet以外
1か月目	約18％	約82％
2か月目	約22％	約78％

約8割のリクエストでは、Sonnet以外のモデルが選ばれていました。

もちろん、これだけで「約8割のタスクではSonnetを使う意味がない」とまでは言えません。

Autoモードの判断が、常に品質面でも最適とは限らないためです。

ただ、少なくとも今回の利用状況では、日常的なコーディング支援の多くでCopilotはSonnet以外を選んでいました。

一方で、Autoでも約2割のリクエストではClaude Sonnet 4.6が選ばれていました。

Autoは高性能モデルを避けているわけではありません。

必要な場面では選んでいます。

この点は、単純な節約モードとは少し違います。

固定指定されたSonnet系の消費量

モデル別の消費量を見ると、固定指定されたClaude Sonnet系がかなり大きな割合を占めていました。

指標	1か月目	2か月目
固定指定されたClaude Sonnet系のリクエスト比率	約21％	約20％
固定指定されたClaude Sonnet系の消費量比率	約64％	約67％

リクエスト数では約2割でした。

それでも、消費量では約3分の2を占めていました。

「全員が少しずつ使いすぎた」というより、特定のモデル指定が全体の消費量に強く影響していたことが分かります。

ここで重要なのは、Claude Sonnetが悪いという話ではないことです。

難しい設計や不具合調査、複数ファイルにまたがる変更では、むしろ積極的に使う価値があります。

問題になりやすいのは、そうしたタスクが終わったあとも固定したままになり、必要性の低い場面まで同じモデルで続けてしまうことだと思います。

普段の使い方への当てはめ

普段の使い方を思い返すと、Copilotに頼んでいるのは単純な補完だけではありません。

最近は、実装したい内容や前提条件をある程度まとめて渡したうえで、実装や調査を進めることが多くなっています。

たとえば、次のような使い方をよくしています。

既存コードの前提を共有したうえで、実装方針を相談する
変更したい仕様を伝えて、影響範囲や修正箇所を探してもらう
実装案を出してもらい、自分で判断して採用・調整する
テスト観点や確認手順を整理してもらう
レビュー時に見落としや別案を確認する

こうした使い方は、単なる軽作業というより、考える材料を増やしたり、作業の抜け漏れを減らしたりするためのものです。

そのため、「普段の作業だから高性能モデルは不要」と単純には言えません。

ただ、前提が整理されているほど、必ずしも毎回SonnetやOpusを固定しなくても進められる場面はあります。

一方で、次のような場面では高性能モデルを選びたくなります。

新規機能やアーキテクチャの設計
複雑なリファクタリング
再現条件が分かりにくい不具合の調査
複数ファイルを横断する変更
実装案やトレードオフの比較
長いコンテキストを前提としたレビュー

結局、常に高性能モデルを使うか、まったく使わないかの二択ではありません。

前提を渡して任せる場面が増えているからこそ、タスクに応じて使い分けることが大事なのだと思います。

利用者を責めるだけでは難しい

利用枠が尽きたときは、正直かなり困りました。

自分はAutoを使っているのに、モデル固定で大きく消費している人がいると知れば、不満も出ます。

ただ、データを見ていると、個人の意識だけの問題とも言い切れないと思いました。

画面上で高性能モデルを簡単に選べるのであれば、利用者は当然使います。

モデルごとの消費量が普段見えにくく、組織全体の残量も意識しなくてよい状態であれば、固定したまま使い続けてしまうこともあります。

「使いすぎないでください」と呼びかけるだけでは、翌月も同じことが起きそうです。

利用者の善意に頼るより、標準的な使い方を決めておくほうが現実的です。

個人的には、次の程度でも効果はありそうだと感じました。

普段はAuto
明確に必要なときだけSonnetやOpusへ切り替える
作業が終わったらAutoへ戻す
月に一度くらいモデル別の消費量を見る

厳しい制限を設けるというより、戻し忘れを防ぐだけでも違いそうです。

平均値と中央値だけでは見えないこと

今回のデータで面白かったのは、中央値と平均値で印象が逆になったことです。

中央値だけを見ると、モデル固定のほうが小さく見えます。

平均値だけを見ると、モデル固定のほうが大きく見えます。

どちらも間違ってはいません。

ただ、片方だけでは実態を捉えられません。

生成AIの利用状況を見るときは、少なくとも次のような値を合わせて見る必要がありそうです。

平均値
中央値
最大値
上位の高消費リクエスト
モデル別の利用回数
モデル別の総消費量
Autoと固定指定の比率

特に共有枠では、最大値や一部のスパイクが全体へ与える影響が大きいです。

単純に利用回数が多い人を探すより、どのモデルで、どのような分布になっているかを見るほうが意味があります。

今回のデータだけでは分からないこと

今回確認したのは、モデル、利用回数、消費量などのデータです。

そのため、次の点は分かりません。

Autoとモデル固定で生成コードの品質にどの程度差があったか
高性能モデルによって開発時間がどの程度短縮されたか
消費量の増加に見合う成果が得られたか
同じタスクを別のモデルで実行した場合の差
利用者がモデルを固定していた理由

高性能モデルを使ったことで、難しい調査が早く終わっていた可能性もあります。

逆に、簡単なタスクではほとんど差がなかった可能性もあります。

今回の結果だけで、Autoのほうが品質面でも優れているとは言えません。

今回の範囲で言えるのは、Autoのほうが極端な消費を抑えやすく、組織全体の利用枠を安定させやすかったということです。

まとめ

2か月分の利用データを見て、次のことが分かりました。

Autoの中央値は約100〜130だった
モデル固定時の平均値はAutoの約2.4〜2.8倍だった
モデル固定時には約6,000〜7,000超のスパイクが発生していた
Autoでは約8割のリクエストでSonnet以外が選ばれていた
固定指定されたClaude Sonnet系は、約2割のリクエストで消費量の約64〜67％を占めていた

高性能モデルを使うこと自体は悪くありません。

必要な場面では、むしろ使ったほうがよいです。

ただ、必要性が低い場面まで固定したままにする必要はなさそうでした。

しばらくは、普段はAuto、必要なときだけ切り替える、終わったら戻す、くらいの運用でよさそうだと思っています。

利用枠が尽きて困ったことがきっかけでしたが、実際のデータを見ると、単なる使いすぎではなく、モデル選択と消費量の分布の問題でした。

次に同じことが起きたときのために、今回確認したことを残しておきます。