Grok 4.5 Copilot提供、モデル統制の実務点

GitHub は 2026年7月28日、xAI の Grok 4.5 を GitHub Copilot で段階提供すると発表した。Grok 4.5 は、fast agentic coding と complex multi-step workflows 向けの reasoning model として説明され、最大 500,000 tokens の context window、text / image input、low / medium / high の reasoning effort を持つ。

これは単なる「選べるモデルが1つ増えた」話ではない。Copilot GPT-5.6モデルポリシー で見たように、Copilot は OpenAI、Anthropic、Google、Microsoft、xAI などのモデルを client と plan に応じて出し分ける段階に入っている。さらに Copilot app統制 のように、agent app、cloud agent、CLI、IDE の統制面も広がっている。Grok 4.5 は、そのモデル選択と実行面の両方に関わる更新である。

日本企業にとっての焦点は、Grok 4.5 が強いかどうかだけではない。Business / Enterprise では管理者が Grok 4.5 policy を有効化する必要があり、既定は off である。さらに、GitHub は provider list pricing under usage-based billing と説明している。つまり、モデルを開ける判断は、品質評価、対象 client、利用者教育、AI Credits、下流 provider 料金、監査ログを同じ表で見る判断になる。

事実: Grok 4.5はCopilotの複数clientへ出る

GitHub Changelog によると、Grok 4.5 は Copilot Pro、Pro+、Max、Business、Enterprise SKU で利用できる予定だ。選択面としては Visual Studio Code、Visual Studio、Copilot CLI、GitHub Copilot cloud agent、GitHub Copilot app、JetBrains、Xcode、Eclipse が挙げられている。ただし rollout は gradual で、すべての利用者に同時に表示されるとは限らない。

GitHub は内部テストで、Grok 4.5 が terminal-based coding tasks、特に Visual Studio Code と Copilot CLI の作業で強い結果を示したと説明している。parallel tool dispatch と direct action に向くとも書いている。ここから読み取れる実務上の意味は、Grok 4.5 をまず ask-only の軽い相談ではなく、探索、詰まりの解消、時間制約のある agentic coding workflow で試すべきだということだ。

xAI 側の発表も、GitHub Copilot の model picker から Grok 4.5 を選ぶ流れを示している。xAI は Grok 4.5 を「smartest coding model」と呼び、VS Code や GitHub products を使う開発者に提供されると説明している。さらに、直接 API でも利用でき、xAI console では input 100万 tokens あたり 2ドル、output 100万 tokens あたり 6ドルという価格を示している。

ただし、Copilot 上での実費は単純な xAI API 価格だけでは読めない。GitHub は、Copilot では provider list pricing under usage-based billing と説明し、詳細は Copilot の models and requests pricing を見るよう案内している。GitHub Docs も、モデルごとに AI Credits 消費率が異なると説明している。したがって、管理者は「xAI APIが安いからCopilotでも同じ」と短絡しないほうがよい。

事実: Business / Enterpriseでは既定オフである

今回の更新で重要なのは、Business と Enterprise の管理者が Grok 4.5 policy を有効化する必要がある点だ。GitHub は、この policy が off by default だと明記している。これは企業導入では自然な設計である。新しい provider model を、管理者確認なしに全社へ開けないためだ。

この扱いは、最近の Copilot モデル運用と一貫している。新しい高機能モデルは、plan、client、管理者ポリシー、rollout、料金、場合によっては provider 固有のデータ条件を組み合わせて扱う必要がある。Claude Opus 5のCopilot提供 や GPT-5.6 のときも、モデル名だけではなく、どの面で使えるか、誰が有効化するか、費用倍率はどうなるかが実務上の論点だった。

Grok 4.5 でも同じである。Visual Studio Code で見えるか、JetBrains で見えるか、CLI で見えるか、cloud agent で選べるかは、モデル全体の発表とは別に確認する必要がある。GitHub Docs の supported models は Grok 4.5 を GA として一覧に入れているが、client や IDE version の表では rollout や minimum version が絡む。たとえば Visual Studio では minimum version として 17.14.19 が示され、他 client では未定の項目もある。

日本企業のヘルプデスクでは、「Grok 4.5 が発表されたのに表示されない」という問い合わせが出る可能性がある。原因は、不具合、license 不足、管理者 policy off、client 未対応、extension version、gradual rollout のどれかである。利用者に任せるのではなく、管理者向けに切り分け表を用意したほうがよい。

分析: モデル選択は用途別の承認線で見る

ここからは分析である。

Grok 4.5 の価値は、Copilot 内で選べる frontier coding model の選択肢が増える点にある。開発者にとっては、同じ Copilot 画面から、OpenAI、Anthropic、Google、xAI などのモデルを仕事に合わせて試せる。一方、管理者にとっては、同じ Copilot 契約の中で provider、料金、性能、データ条件、監査説明が増えるということでもある。

日本企業では、モデルを「強い順」に並べるだけでは運用できない。たとえば、軽いコード説明、単体テスト追加、issue の一次整理は、低遅延かつ安価な model で十分な場合がある。大規模な障害調査、複数 repository をまたぐ設計変更、terminal と tool を多用する agentic workflow では、Grok 4.5 のような強い reasoning model を試す価値がある。ただし、そうした作業ほど費用、実行権限、レビュー責任も重くなる。

この判断は Copilot AI Credits課金 と直結する。モデル選択の自由度が上がるほど、利用者は「良さそうなモデル」を選びがちだ。しかし高い reasoning effort、大きな context、tool 多用、cloud agent の長時間作業は、費用とレビュー負荷を増やす。管理者は、Grok 4.5 を全社標準にするのではなく、用途、repository risk、team maturity、予算枠で許可範囲を決めるべきである。

BYOK との違いも整理したい。Copilot JetBrains BYOK で見たように、企業は自社の model provider や gateway を Copilot へ近づけられる。一方、今回の Grok 4.5 は Copilot の supported model として入る。利用者画面ではどちらも model picker に見えるかもしれないが、請求、ログ、provider 契約、サポート境界は同じではない。

実務: 30日でpilotする手順

最初の1週間は、管理者設定と対象 client を確認する。Copilot Business / Enterprise の AI model policy で Grok 4.5 が off のままか、どの organization で pilot するか、対象 client は VS Code、CLI、Copilot app、JetBrains のどれかを決める。全 client を同時に開けるより、まず実行面が分かりやすい VS Code と CLI に絞るほうが検証しやすい。

2週目は、代表タスクを固定する。軽い質問ではなく、Grok 4.5 が得意とされる terminal-based coding、parallel tool use、multi-step workflow に近いタスクを選ぶ。例として、既存テストの失敗調査、複数ファイルの型変更、legacy module の依存関係調査、CI failure の原因分析、PR 前の影響範囲確認がある。

3週目は、費用とレビューを測る。見るべき数字は、完了率だけではない。消費 credits、reasoning effort、tool call 数、context size、PR 差分サイズ、レビュー差し戻し、CI 成功率、利用者が他モデルへ切り替えた回数を見る。Grok 4.5 が速くても、レビューが重くなるなら本番展開の価値は下がる。

4週目は、展開判断を分ける。全社有効、特定 organization のみ有効、特定 repository のみ推奨、CLI だけ許可、cloud agent ではまだ使わない、というように分ける。モデル policy を1つの yes/no にしないほうがよい。Copilot は client ごとに実行面が違うため、model と client の組み合わせでリスクが変わる。

注意: Auto選択と手動選択を混同しない

GitHub Docs は、Auto model selection が task complexity や availability に応じて適切な model を選ぶと説明している。一方、Grok 4.5 は model picker で明示選択するモデルとして発表されている。管理者は、Auto を信頼して任せる作業と、Grok 4.5 を明示的に選ばせる作業を分けるべきだ。

Auto は日常作業の標準化に向く。利用者が毎回モデル名を比較しなくてもよく、費用割引がある場合もある。一方、Grok 4.5 のような新モデルは、pilot 期間中は明示選択にして、どのタスクで選ばれ、どの結果になったかを測るほうがよい。評価データを取らないまま Auto と手動選択を混ぜると、何が効いたのか分からなくなる。

また、Grok Code Fast 1 は GitHub Docs の retirement history で 2026年5月15日に retired とされている。今回の Grok 4.5 はその単純な復活ではない。xAI の新しい reasoning coding model が Copilot の supported model として入った更新であり、古い Grok 系モデルを使っていたチームも、モデル名、policy、pricing、品質評価を改めて確認する必要がある。

まとめ

Grok 4.5 の GitHub Copilot 提供は、モデル選択の幅を広げる実務的な更新である。最大 500K context、reasoning effort、text / image input、terminal-based coding への適性は、複雑な開発タスクで試す価値がある。一方で、Business / Enterprise では policy が既定オフで、provider list pricing under usage-based billing という費用面もある。

日本企業は、Grok 4.5 を「新しい強いモデル」として全社解放する前に、用途、client、repository risk、AI Credits、レビュー責任、BYOK との差分を整理するべきだ。まずは限定 pilot で、どのタスクに効くか、どれだけ費用が動くか、レビュー品質が上がるかを測る。モデル競争を追うより、モデルを仕事単位で統制できるかが導入品質を決める。

出典

• Grok 4.5 is now available in GitHub Copilot - GitHub Changelog, 2026-07-28
• Grok 4.5 in GitHub Copilot - xAI, 2026-07-28
• Supported AI models in GitHub Copilot - GitHub Docs
• AI model comparison - GitHub Docs