GitHub Copilot に Kimi K3 が追加：Business / Enterprise は既定オフで管理者の有効化が必要

要約

GitHub Copilot のモデル選択肢に Kimi K3 が追加されました。公式の説明は「オープンウェイトモデル」であり、エージェント的なコーディングにおいてフロンティア級の能力を持つ、というものです。

対象プランは Pro / Pro+ / Max / Business / Enterprise の5つ。使えるサーフェスは広く、Visual Studio Code、Visual Studio、Copilot CLI、GitHub Copilot cloud agent、GitHub Copilot アプリ、github.com、GitHub Mobile（iOS / Android）、JetBrains、Xcode、Eclipse が挙げられています。Copilot が展開しているほぼ全面です。

ただし配布の仕方に条件が付きます。Business / Enterprise では既定でオフです。Copilot 設定で管理者が Kimi K3 のポリシーを有効化するまで、メンバー側にはモデルが現れません。個人向けプラン（Pro / Pro+ / Max）はこの制約を受けません。

課金は従量制です。入力 100万トークンあたり $3、出力 100万トークンあたり $15、キャッシュ済み入力 100万トークンあたり $0.30。

ロールアウトは段階的に行われます。公式には、GitHub Actions の incident 対応のためロールアウトを一時停止しているという付記があります。つまりchangelog に載っていても、自分の環境にまだ来ていない可能性があるということです。

何が変わったか

• Copilot のモデル選択肢に Kimi K3 が追加された（Pro / Pro+ / Max / Business / Enterprise）
• VS Code、Visual Studio、Copilot CLI、cloud agent、Copilot アプリ、github.com、GitHub Mobile、JetBrains、Xcode、Eclipse で選択できる
• Business / Enterprise は既定オフ。管理者が Copilot 設定でポリシーを有効化する必要がある
• 従量課金（入力 $3 / 出力 $15 / キャッシュ済み入力 $0.30、いずれも 100万トークンあたり）
• 段階ロールアウト中。GitHub Actions の incident 対応のため一時停止されている旨が公式に付記されている

業務インパクト（一般企業向け）

モデルが1つ増えたというニュースとして流すこともできますが、企業にとって効いてくるのは配布モデルのほうです。

Business / Enterprise で既定オフということは、開発者が「使いたい」と思っても管理者が有効化するまで使えない、という構造です。これは制約であると同時に、判断が管理者に降りてくるということでもあります。そして今回のモデルはオープンウェイトです。ここで管理者は、従来のモデル追加とは少し違う検討を求められます。どこが開発したモデルか、推論がどこで実行されるのか、自社のコードがどう扱われるのか。GitHub 経由で提供されている以上、実行基盤は GitHub 側ですが、社内の調達方針やセキュリティポリシーによっては、モデル提供元の所在が審査項目に入ることがあります。

現実的な進め方としては、モデルごとに個別の稟議を回すのは持たない、という前提から入るのが良いはずです。モデルは今後も増え続けます。1件ずつ判断していると管理者が詰まり、結果として「面倒だから全部オフ」という運用に落ち着きます。それは開発者にとって最悪の状態です。代わりに、モデルを有効化する条件をあらかじめ定義しておくアプローチが機能します。提供元の種別、データの取り扱い条件、コストの上限。この3つくらいを基準として文書化しておけば、新しいモデルが来たときの判断が機械的に済みます。

コスト面では、従量課金であることと単価がモデルごとに違うことを、開発者側に共有しておく必要があります。単価は変動しますので数値そのものを覚える意味は薄いのですが、「モデルによって同じ作業のコストが数倍違いうる」という原則は共有すべきです。特にエージェント的な使い方は入出力トークンが伸びやすく、モデル選択の影響が体感より大きく出ます。Copilot 側にはコストセンターや予算の管理機能が揃ってきているので、有効化とセットで上限を設定しておくのが安全です。

最後に、段階ロールアウトの扱いです。「有効化したのに使えない」という問い合わせが来ることを見込んでおいてください。changelog に載っていても自分の環境に来ているとは限らない、というのは Copilot 全般に当てはまる一般則で、今回は incident による一時停止まで公式に書かれています。管理者側で有効化した事実と、実際に配信された事実は別物です。

副業・個人活用視点

個人プラン（Pro / Pro+ / Max）を使っているなら、Kimi K3 は管理者の承認を挟まずそのまま選べます。ここは個人の身軽さが効く場面です。

試す価値があるのは、エージェント的な使い方の部分です。公式が強調しているのがまさにそこで、複数ファイルにまたがる変更やツール呼び出しを含む作業での性能が売りになっています。ただし公式の性能主張をそのまま信じるのではなく、自分の実際の作業で比べるのが結局のところ確実です。同じリポジトリの同じタスクを、普段使っているモデルと Kimi K3 で流して、通った回数と修正の手間を比べる。この比較を数件やれば、自分の用途での位置づけは掴めます。

コスト感覚も個人のほうが直結します。従量課金でモデルごとに単価が違う以上、「重い作業は高性能モデル、定型作業は安いモデル」という使い分けが素直に効きます。エージェントに長時間走らせる使い方をしているなら、モデル選択の差はそのまま月末の請求に出ます。ここを意識せずに一番強いモデルを固定で使い続けるのは、個人事業としては単純に損です。

受託案件で使う場合は、クライアントの環境を確認してください。相手が Business / Enterprise なら、あなたが個人環境で使えているモデルが相手側では有効化されていない可能性が高いです。自分の環境で出せる成果と、納品先で再現できる成果がずれるという状況は、モデル選択が広がるほど起きやすくなります。開発手順を納品物に含めるなら、モデル依存の部分を明示しておくと後の揉め事を減らせます。

学習の観点では、オープンウェイトモデルが商用の統合先に入ってくる流れ自体を押さえておくと役に立ちます。個別のモデル名を追うより、「どういう条件のモデルが、どういう配布の仕方で企業に届くのか」という構造を理解しておくほうが、提案の場で使える知識になります。