Kimi K3発表──2.8兆パラメータ「オープン3Tクラス」はFable 5に何で勝ち、何で負けたのか¶
対象 / ポイント
対象: フロンティアLLMの採用・乗り換えを判断する開発チームの技術リーダー
ポイント:
- Frontend Code Arenaでは首位だが、総合性能とUXではFable 5／GPT-5.6 Solに届かない
- API価格は入力3・出力15で、前世代より3倍超高く、格安モデルとは呼びにくい
- ウェイト公開前であり、thinking history依存など3つの制約を移行計画に入れる必要がある
2026年7月16日、Moonshot AIは2.8兆パラメータのKimi K3を公開した。 同日、K3はArena.aiのFrontend Code部門で1,679を記録し、Claude Fable 5を上回って首位に立った123。 しかしMoonshot自身は、総合性能がFable 5とGPT-5.6 Solにまだ届かないと明記している1。
本記事の問いは、Kimi K3はどの仕事なら乗り換え候補になり、どの仕事では待つべきかである。
結論──フロントエンドでは勝ち、総合評価とUXでは負ける¶
K3の勝利は本物だが、全面勝利ではない。 人間が生成結果を比較するFrontend Code Arenaでは首位であり、公式評価でも長時間コーディング、Web探索、文書理解に強い。 一方、難問推論、総合ナレッジワーク、ユーザー体験ではFable 5かSolが上にいる。
| 判断軸 | K3の位置 | 実務での読み方 |
|---|---|---|
| フロントエンド生成 | Arena.aiで1位 | UI生成なら優先して試す |
| 長時間コーディング | SWE Marathonで比較内首位 | 自律実行の候補になる |
| Web探索・文書理解 | BrowseComp／OmniDocBenchで比較内首位 | 調査・文書処理と相性がよい |
| 難問推論 | HLE-FullでFable 5に約10ポイント差 | 最難関タスクは移行を急がない |
| 総合ナレッジワーク | GDPval-AA v2で3番手 | 単一モデルへの統一根拠には弱い |
| UX | Moonshot自身が差を認める | 本番導入は操作感まで評価する |
この分布を見れば、モデル名だけで勝敗を決める意味は薄い。 次に、何がこの性能を支えているのかを確認する。
2.8兆パラメータの中身¶
K3は大規模だが、毎回2.8兆パラメータをすべて動かすモデルではない。 896エキスパートのうち16を使うスパースMoEで、100万トークンのコンテキストとネイティブな視覚理解を備える。 Moonshotは「世界初のオープン3Tクラスモデル」と位置づけているが、ウェイトはまだ公開されていない1。
| 項目 | Kimi K3 | 注意点 |
|---|---|---|
| 総パラメータ | 2.8兆 | スパースMoE |
| エキスパート | 896中16を活性化 | Stable LatentMoE |
| コンテキスト | 最大100万トークン | Kimi Codeでは契約階層により256K／1M |
| 入力 | テキスト、画像、映像理解を公式が訴求 | APIごとの対応形式は別途確認が必要 |
| 推論モード | maxのみ | low／highは後日対応予定 |
| API価格 | キャッシュ0.30、入力3、出力$15 | 100万トークンあたり |
| ウェイト | 7月27日までに公開予定 | 7月17日時点では未公開 |
アーキテクチャの柱はKimi Delta AttentionとAttention Residualsである。 前者は長い系列、後者は深い層をまたぐ情報の流れを改善する設計だ。 Moonshotは高スパース化と合わせ、K2比で約2.5倍のスケーリング効率を主張している1。
学習後半ではMXFP4重みとMXFP8活性を使う量子化前提学習を適用した。 推論には64アクセラレーター以上のスーパーノードを推奨し、KDA向けprefix cache実装をvLLMへ提供するとしている。 ここまではベンダーの設計主張であり、技術レポート公開後に再検証すべき領域だ。
公式35項目で見える勝ち筋と負け筋¶
主要10項目だけでも、K3の得意領域ははっきり分かれる。 下表はMoonshotが公開した35項目のうち、実務判断に効く10項目を抜粋したものだ1。 太字は各行の最大値を示す。
| ベンチマーク | Kimi K3 | Claude Fable 5 | GPT-5.6 Sol | Claude Opus 4.8 |
|---|---|---|---|---|
| DeepSWE | 67.5 | 70.0 | 73.0 | 59.0 |
| Program Bench | 77.8 | 76.8 | 77.6 | 71.9 |
| Terminal-Bench 2.1 | 88.3 | 84.6 | 88.8 | 84.6 |
| SWE Marathon | 42.0 | 35.0 | 39.0 | 40.0 |
| FrontierSWE | 81.2 | 86.6 | 71.3 | 66.7 |
| BrowseComp | 91.2 | 88.0 | 90.4 | 84.3 |
| GDPval-AA v2（Elo） | 1,668 | 1,760 | 1,748 | 1,600 |
| GPQA-Diamond | 93.5 | 92.6 | 94.1 | 91.0 |
| HLE-Full | 43.5 | 53.3 | 44.5 | 49.8 |
| OmniDocBench | 91.1 | 89.8 | 85.8 | 87.9 |
K3は仕様からの再実装、長時間の自律コーディング、Web探索、文書理解で最大値を取る。 反対にDeepSWE、FrontierSWE、GDPval、HLEでは他モデルを下回る。 「フロントエンドでFable 5超え」と「総合ではFable 5未満」は両立する。
独立評価も同じ方向を示す。 Artificial AnalysisではK3がIntelligence Index 57で189モデル中4位となり、価格帯の近いモデルより遅く、出力が多いと評価された4。 Simon Willisonの単純なSVG生成でも、推論トークン13,241を含む16,658出力トークンを消費し、約$0.25かかった5。
ベンチマーク表の読み方
K3は主にKimiCode、他社モデルはClaude CodeやCodexなど、 項目ごとに異なるハーネスで測られている。 Fable 5にはOpus 4.8へのfallbackを含む行もある。 BrowseComp 91.2は300Kでコンテキスト圧縮する条件で、 1Mをそのまま使う条件では90.4になる。 個別数値は同一ハーネスの再評価が出るまで、ベンダー主張として扱うのが安全だ。
性能差が狭まったからこそ、次の差は価格になる。
価格はSonnet級──格安モデルではない¶
K3のAPI単価は入力3、出力15で、前世代K2.6の0.95／4から3倍超へ上がった。 入力は約3.2倍、出力は3.75倍であり、Simon WillisonはAnthropicのSonnet系と同水準だと指摘している5。 「中国モデルへ移れば安い」という前提は、K3にはそのまま当てはまらない。
Artificial Analysisの測定では、K3は低速かつ多出力で、Intelligence Index全体の実行費用は$2,690.80だった4。 単価だけでなく、完了までに使う推論トークンと再試行回数が実効費用を決める。 コスト削減目的なら、自社タスクの成功1件あたり費用を測る必要がある。
ただしキャッシュは有力な反論材料だ。 Moonshotはコーディング用途で90%超のキャッシュヒット率を主張し、ヒット入力を$0.30に設定している1。 長いリポジトリ文脈を繰り返し使うなら、表面単価より安くなる余地がある。
「オープンウェイト」はまだ予定¶
7月17日時点のK3は、利用できるがダウンロードはできない。 Moonshotは完全なモデルウェイトを7月27日までに公開し、 技術レポートも今後出すとしている1。 同社のHugging Face組織にはK3チェックポイントがなく、Artificial Analysisも現在はproprietary modelに分類している49。
したがって、いま確認できるのはホストされたモデルの性能と料金である。 商用利用条件、配布物の完全性、自社環境での必要メモリーと実効速度は、ライセンスとウェイトが出るまで確定しない。 「オープン3Tクラス」は現在の配布状態ではなく、公開予定を含む表現として読む必要がある。
その公開待ちの間に、先に評価できる情報がLimitationsである。
公式が明記した3つの制約¶
MoonshotのLimitationsは、ベンチマーク表より移行計画に効く。 公式発表は、thinking history依存、過剰な自律性、UX格差の3点を明記している1。
thinking historyへの依存 K3は思考履歴を保持する前提で学習されている。ハーネスが履歴を完全に返さない場合や、別モデルのセッション途中でK3へ切り替えた場合、品質が大きく不安定になる。
過剰な自律性 長時間タスク向け訓練の副作用として、曖昧な指示や小さな問題に遭遇すると、ユーザーに代わって想定外の判断を下す場合がある。システムプロンプトや
AGENTS.mdで境界を明記する必要がある。UXの格差 総合的には競争力がある一方、ユーザー体験ではFable 5とSolに目に見える差があるとMoonshot自身が認めている。
ここは誤読しやすい。 MoonshotはClaude CodeやCodexなど第三者ハーネスでの利用自体を禁止しておらず、Kimi Code文書にも連携手順がある6。 問題はモデル差し替えそのものではなく、既存セッションの途中で切り替えることと、思考履歴を欠落させる実装だ。
既存資産があるチームは、新しいセッションで始め、コンテキスト上限と履歴保持を設定し、自社タスクで互換性を確認する。 この一手間が、K3をモデル単体ではなくハーネス込みで評価する理由になる。
どう試し、何で判断するか¶
最初の評価は、小さな代表タスクを3経路で同じ条件にそろえる。 Kimi Codeは公式検証済みの基準、Kimi APIは本番統合候補、OpenRouterはアカウントを増やさず試す経路になる。
公式APIをOpenAI Python SDKから呼ぶ最小例は次の通りだ。
import os
from openai import OpenAI
client = OpenAI(
api_key=os.environ["MOONSHOT_API_KEY"],
base_url="https://api.moonshot.ai/v1",
)
response = client.chat.completions.create(
model="kimi-k3", messages=[{"role": "user", "content": "自己紹介を3行で"}]
)
print(response.choices[0].message.content)
ワークロード別の初期判断は5つに絞れる。
- フロントエンド・UI生成: Arena首位を根拠に優先評価する
- 文書理解・Web探索: 有力候補だが、公式値を自社データで再検証する
- 難問推論・総合エージェント: Fable 5とSolを残して比較する
- コスト削減: トークン単価ではなく成功1件あたり費用で測る
- 既存ハーネス: 新規セッション、履歴保持、権限制約を同時に検証する
まとめ──7月27日までに決めず、7月27日から確かめる¶
Kimi K3は、オープンウェイトモデルがフロンティアへ近づいた有力な事例である。 ただし現在の勝ち筋はフロントエンド、長時間コーディング、探索・文書処理に集中し、難問推論とUXには差が残る。
7月27日前後に確認すべき項目は3つある。
- 実際のウェイト、ライセンス、配布ファイルの範囲
- 技術レポートが示すKDA、AttnRes、2.5倍効率の検証根拠
- 同一ハーネスと自社タスクによる成功率、費用、修正回数
ここから得られる新しい示唆は、モデル選定がハーネス契約の選定になったことだ。 K3のthinking history制約は、モデル名だけを差し替える比較の限界を示す。 どの仕事を、どの履歴と権限で渡すかを決めてから、ランキングを見る必要がある。
関連記事¶
- Sol vs Fable 5 — K3が追う2モデルの実務比較
- Kimi K2 Thinking — 前世代からの変化を確認
- Claude Fable 5公開 — Fable 5の提供条件とfallback