とことんDevOps | 日本仮想化技術のDevOps技術情報メディア

DevOpsに関連する技術情報を幅広く提供していきます。

日本仮想化技術がお届けする「とことんDevOps」では、DevOpsに関する技術情報や、日々のDevOps業務の中での検証結果、TipsなどDevOpsのお役立ち情報をお届けします。
主なテーマ: DevOps、CI/CD、コンテナ開発、IaCなど
読者登録と各種SNSのフォローもよろしくお願いいたします。

GitHub Copilotの従量制移行にともなうAIモデルの賢い使い分け戦略

GitHub Copilotが2026年6月1日より「従量制(使用量に応じた課金)」に移行することが発表されました。この変更により、利用するAIモデルによってコストが大きく変動するため、今後はタスクによってどのモデルを使うかという「使い分け」が非常に重要になってきます。

GitHub Copilotは様々あるAIエージェントの中の一つで、他と比べて色々なモデルを使ってコード開発に使えると言うメリットがあります。たとえばGitHub Copilotで使えるモデルは次の通りです。(※)付きはGitHub Copilot Pro+以降のプランで利用できます。

  • GPT-5.5 (※)
  • GPT-5.4
  • GPT-5.3-Codex
  • GPT-5.2
  • GPT-5.2-Codex
  • GPT-5 mini
  • GPT-4o
  • GPT-4.1
  • Gemini 2.5 Pro
  • Gemini 3 Flash (preview)
  • Gemini 3.1 Pro (preview)
  • Claude Haiku 4.5
  • Claude Sonnet 4.5
  • Claude Sonnet 4.6
  • Claude Opus 4.7 (※)

以前はClaude Opusも月10ドルのGitHub Copilot Proプランで利用できましたが、現在はPro+プラン以降でしか使うことができません。 その主な理由は先のBlog記事にも書かれていましたが、2026年6月1日から適用される「モデル乗数」の表を見ると理由が分かってきそうです。

新しい課金システムとモデル乗数の理解

GitHub Copilotは複数のAIモデルを利用してコード開発を支援しています。利用できるモデルは多岐にわたり、そのモデルによって計算リソース(コスト)が大きく異なります。

現在、モデルごとに「乗数」が設定されています。この乗数は、そのモデルがどれだけの計算リソースを必要とするか、つまりコストが高いかを示しているといえます。Current multiplierが現在のプレミアムリクエストの消費数で、New multiplierが6月から適用されるGitHub AIクレジットの消費数です。特にClaude系のモデルはHaikuを除いて大幅に消費数が増加しています。実質値上げです。

私はかつてはGitHub Copilotを用いて、主なコード生成はClaude Sonnetモデルを、最終的チェックにはClaude Opusモデルを使っていました。最近のアップデートでPro+以降でしかOpusモデルが使えなくなりました。 そのため、最近は初期コードをGPT-4oやGPT-4.1やローカルLLMのモデルで作って、仕上げはGPT-5.3-Codexを使うような使い方に変えています。ドキュメントを書くときはGPT-5 miniやClaude Haiku 4.5のようなライトウェイトなモデルを使うことが多いです。

ただ、Current multiplierとNew multiplierを比べてみると、どのモデルも実質コスト増と言う形になり、特にGPT-5.3-Codexのモデル乗数のついては今の6倍、Claude Sonnet 4.6については今の9倍になることから、もう少し工夫をしないといけないと感じました。プランの価格に変動は今回はありませんでしたが、これまでと同じように使うと、すぐ上限に当たる可能性が想像つくためです。

もちろん、GitHub Copilot Pro+プランも他と比べるとそこまで高価なプランではありませんから、現状のプランで厳しいようであれば上位のプランにアップグレードも検討しますけどね*1

Copilot周りのVSCodeの最近のアップデート

最近のバージョンのVSCodeでは、インラインチャットのデザインがGitHub Copilot CLIライクな感じに変わっています。 以前はこういうデザインでした。

あたらしいデザインはGiHub Copilot CLIのプロンプトに文字入力しているようなデザインになっています。インラインチャットのモデル選択ができるところも分かりやすいです。

これならGiHub Copilot CLIを使わないでも満足できるのでは?...なんて私は思いました。

また、以前のバージョンでは機能不足感があったGitHub Copilot周りの各種設定ですが、GitHub Copilot Chatの設定を開くと、次のような画面でカスタムプロンプトだとかMCPの設定などが一つの設定画面の中にまとまっていました。ここから各項目を開いて設定できるようです。もう、テキスト形式のファイルをわざわざ開いて変更する必要も無くなったようです。先の話とともにVSCodeのバージョン1.119.0での話です。だいぶ良い感じになったと思います。

6月からの私のAIモデル使い分け戦略

と言うわけで、自分が考える作業毎のAIモデルの使い分けについて考えてみました。 以下は現在筆者がサブスクしているGitHub Copilot Proで使えるプランをベースに、コストと品質のバランスを取って作業内容に応じて最適なAIモデルを選択する戦略について考えたものです。

コード生成と開発ワークフロー

コードを書く際や初期コードを作成する際には、軽量なモデルを活用し、効率とコストを重視します。

  • 初期コード作成: 軽いモデル(例:GPT-4oやGPT-4.1, GPT-5 mini)を選択。ローカルLLMのコード系モデル(たとえばQwen2.5-coder 7b)も使えそうです。
  • 最終レビューと高精度コード: より複雑なロジックや最終チェックには、コードについてはGPT-5.3-Codex、文章についてはGPT-5.4を選択。

計画・レビュー・ドキュメント作成

プロジェクトの計画やドキュメント作成など、情報整理が主となるタスクには、効率的で読みやすいライトウェイトなモデルを選択します。

  • 計画・初期構想: Claude Haiku 4.5やGPT-4oなど、高速かつコスト効率の良いモデルを選択。
  • ドキュメント作成: 軽めのモデル(例:GPT-5 mini, Gemini 2.5 Pro)を活用し、AIによる文体チェックや軽微な修正を実施。社内でテスト運用中のローカルLLM(例:gemma-4-26b-a4b-it)も、これらのタスクにおいて非常に有効なので併用予定。

つまり最終的には、次のモデルを使い分けていく形になりそうです。GPT-5.5については改正後もPro+以降が必要なのかは現時点では判明していないため、6月1日以降に再度確認でしょうか。 とは言え私はOpenAIのGPT Plusも課金してるので、OpenAIの各ツールを使えばGitHub Copilotで使えないモデルもある程度は使える状況にあるので、そこまで不便なことにはならないと思われます。

モデル 乗数
Claude Haiku 4.5 0.33
GPT-4o 0.33
GPT-5 mini 0.33
Grok Code Fast 1 0.33
GPT-4.1 1
Gemini 2.5 Pro 1
GPT-5.3-Codex 6
GPT-5.4 6
Gemini 3.1 Pro 6
Claude Sonnet 4.5 6
Claude Sonnet 4.6 9
ローカルLLM 0 (電気代だけ)

ローカルLLMのモデルについてはタスクの内容によって、ローカルのOllama上のQwen2.5-coderとGemma e2b、社内で動かしているGemma 4 26b-a4b-itを使い分けていこうと思っています。

高性能モデルの活用

コード作成品質が特に求められる場面や技術的な文章の仕上げなどより高い精度が求められるタスクには、コストを許容してでも高性能なモデルを利用します。賢いモデルを使ったほうが、タスクを早く処理してくれそうですから。

タスク 選択するモデル 理由
最終レビュー/コード生成 GPT-5.3-Codex 最新モデル(GPT-5.5など)ほどの火力がなくても十分な品質を保ちつつ、コストを抑えるため
高度な文章作成 GPT-5.4/Gemini 3.1 Pro 高い品質とコストのバランスが取れているため
技術文書 GPT-5.4/Gemini 3.1 Pro/Claude Sonnet 4.6 賢いモデルを選択することで、一気に質の高いアウトプットを得て時間の節約を図るため

まとめ

GitHub Copilotの従量制移行は、AIモデルの選択を「コスト」と「品質」の視点から再評価することを促しています。

最も重要なのは、「何のためにAIを使うのか」という目的を明確にし、タスクごとに最適なモデルを使い分けることです。これにより、最新の高性能モデルの恩恵を受けつつ、賢くコストを管理することが可能になります。

まずはこのモデル使い分け戦略を確立し、効率的な開発を追求していこうと思います。

最後に、このブログ記事はもうちょっと長かったのですが、OllamaのGemma 4:e2bを使って文書校正してもらい、コンパクトにまとめてもらいました。 Gemma 4:e2bは直近で出てきたローカルモデルの中では非常に優秀なモデルだと思いますね。

*1:現在プランのアップグレード受付は停止中