選択肢が 1 つ増えた

Moonshot AI のオープンウェイトモデル Kimi K3 が、GitHub Copilot で一般提供 になりました。

コスパで言うと、まず押さえるのは 3 点です。どこで使えるか、いくらか、すぐ使えるか。 この順に見ていきます。

なお、Kimi K3 そのものは以前から公開されているモデルです。今回の発表は「Copilot から選べるようになった」という提供チャネルの話 で、モデルが新しくなったわけではありません。ここを混同すると、性能の話とアクセス手段の話が混ざります。

使えるサーフェス

公式に挙げられているのは次のとおりです。

  • Visual Studio Code
  • Visual Studio
  • Copilot CLI
  • GitHub Copilot cloud agent
  • GitHub Copilot app
  • GitHub.com (Web)
  • GitHub Mobile (iOS / Android)
  • JetBrains
  • Xcode
  • Eclipse

主要なところはひととおり揃っています。 特定の環境だけ使えない、という心配は要りません。

ただし順次ロールアウトされるため、選択肢に出るまで時差がある場合があります。 出ていないからといって設定を疑う前に、少し待ってみてください。

なお、同じアカウントでも環境によって出るタイミングがずれることがあります。エディタでは選べるのに CLI では出ない、といった状態は一時的なものと考えて構いません。

料金

100 万トークンあたりの単価です。

区分単価
入力3.00 ドル
出力15.00 ドル
キャッシュ入力0.30 ドル

コスパで見ると、注目すべきはキャッシュ入力です。 通常の入力の 10 分の 1 になっています。

同じ前提を繰り返し渡す使い方では、ここが効いてきます。長い仕様書や大きなコードベースを毎回読ませるような作業では、2 回目以降の費用が大きく変わります。

逆に、毎回まったく違う内容を投げる使い方では、この差は出ません。 自分の使い方がどちらに近いかで、効き目が変わります。

もう 1 点、この単価は Copilot 経由での利用に関するもの です。Kimi K3 を別の経路で使う場合の条件とは分けて考えてください。同じモデルでも、どこから使うかで条件が変わります。

コツ

キャッシュが効くのは、同じ内容を続けて渡す場合です。日をまたいで別のセッションを立てると、キャッシュから外れることがあります。

Business と Enterprise は管理者の操作が要る

ここが実務でいちばん引っかかる点です。組織で使っている場合、既定ではオフになっています。

公式にはこう書かれています。

Kimi K3 is off by default for Copilot Business and Copilot Enterprise. Plan administrators must enable the Kimi K3 policy in Copilot settings before anyone in their organization can select it.

管理者がポリシーを有効化するまで、組織の誰も選べません。 「選択肢に出ない」という問い合わせがあったら、まずここを確認してください。

個人プランで使っている場合は、順次使えるようになります。

契約使えるようになるまで
個人プラン順次ロールアウト
Business管理者がポリシーを有効化する
Enterprise管理者がポリシーを有効化する

管理者が有効化するかの判断

「とりあえず有効にしておく」でよいのか、という質問も出ます。コスパで言うと、有効にしておいて損はありません。

理由は 2 つです。選択肢が増えるだけで、既定が変わるわけではないこと。そして、使わなければ費用も発生しないことです。

ただし、次の場合は先に確認してください。

状況確認すること
利用してよいモデルを社内で定めている一覧に追加してよいか
取引先との契約に委託先の指定があるホスティング先の扱いが範囲内か
費用を厳密に管理している単価の違いが予算の前提を崩さないか

真ん中の行が引っかかる組織はあります。Copilot 経由とはいえ、実際の処理は別の事業者の基盤で動きます。 契約で委託先が限定されているなら、そこに触れる話になります。

該当しないなら、有効化して選べる状態にしておくのが素直です。使うかどうかは各自が決めれば足ります。

どう使い分けるか

使い分けの目安を言うと、次のどちらかに当てはまるなら試す価値があります。

長い文脈を扱う作業がある。 大きなファイルや複数のファイルをまとめて読ませる場面です。Kimi K3 は長い文脈を扱う設計のモデルなので、ここは素直に効きます。

同じ前提を繰り返し渡している。 キャッシュ入力の単価が低いので、費用面で差が出ます。社内のルールや設計方針を毎回添えているような使い方が該当します。

逆に、短いやり取りが中心なら、いま変える理由は弱いです。 数行の修正を頼むような使い方では、モデルによる差はそこまで出ません。

FIXITFIXIT

新しいモデルが増えるたびに試したほうがいいの？

HayateHayate

そこはコスパで言うと、困っていなければ後回しで大丈夫です。

FIXITFIXIT
どういうときに試すの？
HayateHayate

使い分けの目安は 2 つで、長い文脈か、繰り返しの多さですね。

試し方

試すときの手順を置いておきます。大事なのは、比較になる形で試すことです。

  1. 自社の実作業を 2〜3 件選ぶ。ベンチマークではなく普段の作業から
  2. 今使っているモデルと同じ指示で流す。指示を変えると比較になりません
  3. 差が出た点を記録する。速さ、正確さ、指示の解釈のどこが違ったか
  4. 費用を並べる。同じ作業でかかった量を比べます

2 番を守ってください。新しいモデルに合わせて指示を書き直すと、変わったのがモデルなのか指示なのか分からなくなります。

差が出なければ、変える理由はありません。これは Kimi K3 に限らず、新しい選択肢が増えるたびに同じ手順で判断できます。

かける時間の目安は、合計 1 時間 です。作業を 3 件、2 つのモデルで流して結果を並べる。これ以上かけると、比較そのものが本業を圧迫します。判断がつかないなら、そのまま今のものを使い続けるのが正解です。 差が小さいということなので。

費用の見え方が変わる点

もう 1 つ、実務で効いてくる話です。Copilot 経由で使うと、費用の内訳が Copilot 側にまとまります。

複数のモデルを別々の経路で契約している組織では、請求が分散します。どこにいくら使っているかを把握するだけで手間がかかる状態です。

その点、同じ環境の中でモデルを切り替えられると、使用量の把握が 1 箇所で済みます。 モデルごとの内訳も、同じ画面で見られます。

コスパで言うと、この「見えやすさ」は地味に効きます。使いすぎに気づくのが早くなるので、結果として費用が下がることがあります。 単価の差より、把握できているかどうかのほうが効く場面は珍しくありません。

契約全体を見直したい場合は 法人向け生成 AI 契約プラン比較 2026 を参照してください。

オープンウェイトであることの扱い

Kimi K3 はオープンウェイトのモデルですが、Copilot 経由で使う限り、その点は実務に効きません。

GitHub が Fireworks AI 上でホストする形なので、データの流れは他のモデルと同じです。自社環境で動かしているわけではありません。

オープンウェイトであることが効くのは、ウェイトを取得して自分の環境で動かす場合です。データを外へ出せない制約がある場合の選択肢として意味を持ちます。

使い方オープンウェイトの意味
Copilot 経由で使う実質的な違いはない
自社環境で動かすデータが外へ出ない

Copilot の中で選ぶ話としては、性能と料金で判断すれば足ります。 出自を理由に避ける・選ぶという議論は、この文脈では噛み合いません。

Kimi K3 そのものの解説は Kimi K3 とは に、同じくオープンモデルの動きとしては Qwen3.8-Max とは にまとめています。

モデルが増えすぎたときの整理

Copilot で選べるモデルは、この 1 年で目に見えて増えました。選択肢が多いこと自体が、別の問題を生み始めています。

現場でよく見るのは、次の状態です。

  • 選択肢が多すぎて、結局いつも同じものを選んでいる
  • 人によって使っているモデルがばらばらで、話が噛み合わない
  • どれが速くてどれが正確なのか、誰も把握していない

コスパで言うと、この状態は選択肢が 1 つしかない場合と実質的に変わりません。 選べるのに選んでいないからです。

対処としては、チームで 既定を 1 つ、例外を 1〜2 つ 決めておくのが現実的です。

用途使うモデル
普段の作業既定として決めた 1 つ
長い文脈を扱う作業長文脈に強いもの
費用を抑えたい定期処理単価の低いもの

3 行くらいで足ります。全部のモデルを評価して表を作る必要はありません。 使う場面が 3 つに分かれていれば、実務は回ります。

その 3 行に Kimi K3 が入るかどうかが、今回の判断です。長い文脈と繰り返しの多さ、この 2 点で当てはまるなら候補になります。

決めたら、どこかに 3 行書いておいてください。 口頭で共有しただけの取り決めは、モデルが増えるたびに崩れます。書いてあれば、次に選択肢が増えたときも「この 3 行を見直すか」で議論が始まります。ゼロから話し直すより速く終わります。

選択肢が増えること自体の意味

個別の性能とは別に、Copilot で選べるモデルが増えていること自体 に意味があります。

同じ環境の中で複数のモデルを切り替えられると、乗り換えのコストがほぼゼロになります。エディタも設定も変えずに、モデルだけ変えて比べられる 状態です。

この状態では、提供側が条件で競うようになります。実際、この 1 年で同じ性能帯の料金は下がり続けています。

発注する側から見ると、ここが実利です。1 つのモデルに寄せた作り込みをしないでおくと、この動きの恩恵を受け取れます。 特定のモデルでしか動かない書き方は、次に条件の良いものが出たときの移行コストになります。

なお、Copilot では 9 月 1 日に 6 モデルの廃止も予定されています。選択肢が増える一方で、古いものは順次消えます。詳細は GitHub Copilot で 6 モデルが 9/1 廃止 を参照してください。

まとめ

  • Kimi K3 が GitHub Copilot で一般提供に。主要なサーフェスはひととおり対応
  • 料金は 100 万トークンあたり入力 3.00 ドル・出力 15.00 ドル・キャッシュ入力 0.30 ドル
  • キャッシュ入力が通常の 10 分の 1。同じ前提を繰り返し渡す使い方で効く
  • Business と Enterprise は既定でオフ。管理者がポリシーを有効化するまで選べない
  • 試すなら、実作業 2〜3 件を同じ指示で流して比べる。指示は変えない
  • Copilot 経由で使う限り、オープンウェイトであることは実務に効かない
  • 選択肢が増えたら、チームで「既定 1 つ・例外 1〜2 つ」に整理しておく