Kimi K2.6 API、K2.5、K2 Thinking：どのモデルIDを使うべきか

新しく公式 Kimi API を組み込むなら、最初に選ぶモデルIDは kimi-k2.6 です。kimi-k2.5 は K2.5 固有の互換性、既存ベンチマーク、移行前後の比較を残したいときに使います。kimi-k2-thinking は古い専用 thinking モデルを明示的に呼びたい場合のモデルIDであり、K2.6 の thinking 設定を表す別名ではありません。provider のページ、Bedrock やワーカー系のホスト名、無料 API を紹介する記事や動画は入口として役立ちますが、公式 Kimi/Moonshot API のモデル契約そのものではありません。

日本語でこのテーマを調べる読者が最初に欲しいのは、長い比較論ではなく「コードの model に何を書くのか」です。だから最初の判断は、公式ルートのモデルID、provider が持つ別名、thinking の扱いを分けることです。ここを混ぜると、サンプルは動いても本番ドキュメントの責任者が分からなくなります。

最初の決定はモデルIDです

Kimi K2 系の名称は似ています。K2.6 は最新の公式 API モデルに見え、K2.5 は旧世代に見え、K2 Thinking は reasoning を強くするスイッチのように見えます。しかし API 呼び出しは曖昧な商品名を受け取りません。model 文字列、base URL、認証、パラメータ、レスポンス形式を受け取ります。

新しい公式実装の既定値は kimi-k2.6 です。公式 K2.6 quickstart は OpenAI 互換クライアントの形を取り、base URL は https://api.moonshot.ai/v1 です。これは、リポジトリ内の古い K2 文字列をすべて一括置換せよという意味ではありません。「現在の公式 Kimi モデルを使う新規実装」なら、古いモデル文字列から始めないという意味です。

kimi-k2.5 はまだ役割を持ちます。既存の評価セットが K2.5 を前提にしている、provider が K2.5 ルートだけを提供している、K2.6 への移行前後で挙動を比較したい、といった場合です。そのときは K2.5 を残してよいですが、なぜ残すのかを設定や runbook に書くべきです。理由がなければ、単なる古い default なのか意図的な互換性なのか分からなくなります。

kimi-k2-thinking はさらに狭い意味を持ちます。これは専用モデルIDです。K2.6 や K2.5 の thinking behavior を制御したい場合は、リクエスト設定、reasoning フィールド、tool-call の継続処理を確認する話になります。kimi-k2.6-thinking のような文字列を、provider ページや記事の表現だけで公式モデルとして扱うのは危険です。

公式 API ルートから確認する

モデルID、価格、コンテキスト、パラメータ、retirement note の責任者は公式 Kimi/Moonshot API です。provider ページは実用的な入口を示せますが、公式モデル一覧の代わりにはなりません。AWS、ワーカー系、各種 gateway、ローカル記事の表記は、それぞれの route owner が持つ契約として読む必要があります。

最小コードは、どのルートを使うのかを隠さない形にします。

hljs ts复制
import OpenAI from "openai";

const client = new OpenAI({
  apiKey: process.env.KIMI_API_KEY,
  baseURL: "https://api.moonshot.ai/v1",
});

const response = await client.chat.completions.create({
  model: "kimi-k2.6",
  messages: [
    { role: "user", content: "Summarize the routing risk in this Kimi setup." },
  ],
});

console.log(response.choices[0]?.message);

最初はこの程度で十分です。アカウント、API key、base URL、モデルIDが公式ルートで動くことを確認してから、tool call、streaming、multimodal input、長い context、provider proxy、fallback routing を足します。公式ルートでは成功し、provider では失敗するなら、調査先は Kimi のモデル契約ではなく provider の alias mapping、課金、制限、機能ラッパー、データポリシーに移ります。

2026年5月8日時点で、公式 platform は K2.6 と K2.5 を 256K context の multimodal models として表示し、K2.6 は cache hit $0.16/MTok、input $0.95/MTok、output $4.00/MTok、K2.5 は cache hit $0.10/MTok、input $0.60/MTok、output $3.00/MTok として表示していました。これは日付付きの事実です。価格、制限、コンテキスト、提供状況を記事や予算に使うときは、現在の公式ページで再確認してください。

K2 Thinking と thinking 設定は別の層です

「thinking」という単語は二つの層で使われます。一つは kimi-k2-thinking という専用モデルIDです。もう一つは、K2.6 や K2.5 のルートで reasoning output や tool call をどう扱うかという実装上の問題です。ここを同じものとして扱うと、モデルIDの選択もレスポンス処理も壊れます。

thinking guide が重要なのは、単にモデルが内部で考えるからではありません。レスポンスには reasoning_content が含まれる場合があり、tool-call workflow では reasoning content を次のメッセージへ引き継ぐ必要があります。streaming、temperature、max token の設定も出力の安定性に影響します。クライアントラッパーが非標準フィールドを捨てる、途中メッセージを要約する、tool-call の戻し方を変える、といったことをすると、モデルではなく統合側が失敗します。

本番向けには、モデルID、thinking の状態、reasoning_content の保存、tool-call の再送、max token の値を明記します。これにより、K2 Thinking が強いか弱いかという抽象論ではなく、自分の呼び出しパスが意図した挙動を保っているかを確認できます。

古い K2 文字列は移行ルールで扱う

公式モデル一覧には古い kimi-k2 系列に対する retirement note がありました。ただし、それは K2.5 や K2.6 が消えたという意味ではありません。古い設定、サンプル、provider alias、評価スクリプトを点検すべきという意味です。

安全な移行ルールは単純です。新しい公式実装は K2.6 を既定にする。既存テストは意図があるなら維持する。古い K2 文字列は route owner を確認してから置き換える。これなら、必要な比較を壊さずに stale default を減らせます。

provider と無料 API の表記は route owner ごとに検証する

provider route は実用的です。特定のクラウドランタイム、既存の請求、地域、OpenAI 互換 endpoint、playground、worker integration が必要なら、公式 API より合う場合もあります。問題は、provider route が公式 Kimi 契約を置き換えないことです。

確認する層は次の通りです。

無料 Kimi K2.6 API という表現を見たら、まず検証対象として扱います。低リスクの実験なら役立つかもしれません。しかし本番コード、顧客向け資料、予算判断、社内標準には、現在の route owner が示す条件が必要です。証拠がなければ、無料、無制限、返金、安定性、アカウント保証のような表現は使わない方が安全です。

Kimi と Claude の比較は別タスクです

K2.6 を調べる人の一部は、Claude Code や Opus の代替になるかを知りたいだけかもしれません。その比較は重要ですが、モデルID選択とは別です。Kimi route guide は、kimi-k2.6、kimi-k2.5、kimi-k2-thinking、公式 base URL、provider alias、thinking handling を決めるためのものです。Claude 代替の判断には、コード修正能力、tool use、agent loop、失敗時の回復、latency、cost、repository context を同じ条件で測る必要があります。

境界は次のように置くと迷いません。

• Kimi のモデル文字列を選ぶなら、このルート表を使う。
• Claude workflow の代替可能性を見るなら、同じタスクで別途 benchmark を走らせる。
• provider を使うなら、モデル比較より先に provider route を確認する。
• 本番文書を書くなら、公式 model ID と route owner を両方書く。

話題性のある比較記事だけでモデルIDを変えると、コードは動いても責任境界が壊れます。API 統合では、流行よりも呼び出し契約の方が先です。

本番前のチェックリスト

最終的には、次の表を repository や runbook に残すのが一番確実です。

この表は地味ですが、将来の障害対応で効きます。どのモデル文字列がなぜ残っているのか分かれば、移行、価格更新、provider 切り替え、評価比較がずっと楽になります。

FAQ

新しい Kimi API 実装では kimi-k2.6 を使えばよいですか？

公式 Kimi API を使い、K2.5 固有の比較、旧 thinking モデル、provider alias の理由がないなら、はい。まず kimi-k2.6 を使い、現在のモデル一覧、価格、context、limits を確認します。

kimi-k2-thinking は K2.6 の thinking mode と同じですか？

同じではありません。kimi-k2-thinking は独立したモデルIDです。K2.6 や K2.5 の thinking behavior は、リクエスト設定とレスポンス処理の問題です。

Kimi K2.5 を今もテストする意味はありますか？

あります。K2.5 の挙動、既存 benchmark、互換性が目的なら保留できます。ただし新しい公式 API 実装の既定値にするなら、理由を書いてください。

無料 Kimi K2.6 API は本番で使えますか？

route owner が無料範囲、制限、データ条件、モデル同一性、可用性を現在示している場合だけ、低リスク用途で検討できます。証拠なしに無料、無制限、不凍結、安定性、返金、保証を前提にしないでください。

古い kimi-k2 文字列はどう扱えばよいですか？

config、wrapper、example、provider setting を検索します。新しい公式 route は K2.6、K2.5 評価は理由付きで保持、kimi-k2-thinking は専用モデルとして保持、provider alias は別 mapping として管理します。