「2.8T」「Fable 5超え」だけでは導入判断できない

Kimi K3(Moonshot AI)は、総パラメータ約2.8兆、コンテキスト最大1,048,576トークン、ネイティブ vision を備えるフラッグシップです。

📑目次
  1. 「2.8T」「Fable 5超え」だけでは導入判断できない
  2. Kimi K3 とは何か|スペックと位置づけ
  3. ベンチと第三者指標の読み方
  4. 料金・提供経路と導入チェックリスト
  5. よくある質問(FAQ)
  6. まとめ|次にやること

公式は「open 3T級」を掲げ、kimi.com / Kimi Work / Kimi Code / Kimi API から利用でき、2026年7月27日までにフルウェイト公開を予定しています。一方で公式ブログは、総合性能では Claude Fable 5 や GPT-5.6 Sol に及ばないと明記しています。

まず押さえる四点

開発者が今すぐ必要なのは、見出しの数字そのものではなく次の四点です。

  1. どの経路で試すか(公式 API / OpenRouter / Cloudflare / プロダクト UI / 重み待ち)
  2. 1Mトークンあたりの料金とキャッシュの効き方
  3. thinking / マルチターン / vision まわりのハーネス制約
  4. 「一部ベンチ首位」と「総合未達」をどう読み分けるか

本記事の根拠とゴール

本記事は、公式 docs と独立報道を突き合わせ、導入前チェックリストに落とします。

主な根拠:

読み終わったら、次のどれかに振り分けられる状態を目指します。

  • 今すぐ API で1タスク測る
  • Kimi Code で試す
  • 7/27の重みとライセンスを待つ

Kimi K3 とは何か|スペックと位置づけ

結論から言うと、Kimi K3 は「総合置換モデル」ではなく、長時間コーディング・知識労働・推論向けの超大規模オープン志向フラッグシップです。公式の自己評価でも、UX や総合スコアは Fable 5 / GPT-5.6 Sol にギャップがあると書かれています。

公式スペックの要点

項目 公式の位置づけ(2026-07-18時点)
総パラメータ 約 2.8T
コンテキスト 1,048,576 tokens
モダリティ テキスト + ネイティブ vision
アーキテクチャ Kimi Delta Attention (KDA) + Attention Residuals。MoE で 896 experts 中 16 を実効アクティブ
スケーリング効率 K2 比で約 2.5x(公式主張)
提供面 kimi.com / Kimi Work / Kimi Code / Kimi API
第三者経路の例 OpenRouter slug moonshotai/kimi-k3、Cloudflare Workers AI
重み公開 2026-07-27 までに full weights(ライセンス条件はブログ時点で未詳)

スペック出典とアーキテクチャの読み方

出典(2026年7月時点):

アーキテクチャ面では、公式が KDA と Attention Residuals を強調し、長時間エージェントやカーネル最適化デモを事例として出しています。ただしデモは「できる可能性」の証拠であり、自社ワークロードでの再現は別問題です。


提供経路の分け方

  • プロダクト UI: kimi.com / Kimi Code で体感を掴む。ハーネス互換を先に見る用途向き。
  • 公式 API: OpenAI SDK 互換。base_url=https://api.moonshot.ai/v1model=kimi-k3
  • OpenRouter: slug moonshotai/kimi-k3。請求・観測を一本化したい場合。容量制限と 429 注意バナーあり。
  • Cloudflare Workers AI: エッジ側ルーティングを既に使うチーム向けの掲載経路。
  • 自前ホスト: 7/27 以降。ライセンス・推論要件・エコシステムが公開時点で揃うかを確認してから計画する。

独立報道との突き合わせ

独立報道も、2.8T・7/27オープン・米ラボとの競争文脈を伝えています。

数値の一次根拠は公式 docs を優先し、報道はクロスチェックに使います。

BBCによるKimi K3報道ページのスクリーンショット
BBCなど独立報道は規模・公開予定・競争文脈のクロスチェックに使う(数値の一次は公式docs)

出典


ベンチと第三者指標の読み方

「一部で Fable 5 超え」と「総合では未達」は両立します。見出しの一点突破を全面置換の根拠にする前提はリスクが高く、公式が示す総合・UXの限界を先に織り込むのが安全です。

公式ブログの Limitations も、総合・UX ギャップを隠していません。読者がやるべきは、自社スイートの一点突破候補かどうかを測ることであり、見出しの首位表記を置換決定に使うことではありません。

比較の見方|総合とコーディング系

観点 公式の主張(blog 等) 第三者・経路 読み方
総合 vs Fable 5 / GPT-5.6 Sol 及ばないと明記。UX gap も Limitations 独立報道も競争文脈を報じる 置換前提にしない
Program Bench 77.8%(Fable 5 76.8% / Sol 77.6%) 公式評価 コーディング系の一点突破候補
SWE Marathon 42.0%(35.0% / 39.0%) 公式評価 長時間タスクのシグナル

比較の見方|ブラウズ・難問・第三者指標

観点 公式の主張(blog 等) 第三者・経路 読み方
BrowseComp 91.2%(88.0% / 90.4%)。1M無管理で 90.4 の注記も 公式 harness / context 条件を併記する
HLE-Full 43.5% vs Fable 5 53.3%(約10pt差) 公式 / 報道 難問 reasoning の弱点候補
AA Intelligence / Coding / Agentic OpenRouter 掲載 57.1 / 76.2 / 50.1 時点スナップショット。順位は変動
Arena frontend coding 等 リード報道あり AP / BBC / 分析記事 リーダーボード依存。再現条件を確認

表の出典

表の出典(2026年7月時点):


運用メトリクスの扱い

OpenRouter ページ上の運用メトリクスは、その時点のスナップショットです。

  • structured output error 平均が相対的に高め、という報告例
  • cache hit が高いと実効 input 単価が下がる、という傾向

本番判断では自前の10〜20本回帰を優先してください。


実務での読み分けルール

  • 公式自社ベンチと Artificial Analysis / Arena を同じ表の「勝者」列に混ぜない
  • BrowseComp など harness 依存指標は、コンテキスト長・ツール有無・管理有無を併記する
  • HLE など苦手領域が出ているなら、その領域を主戦場にするワークロードでは採用を遅らせる
  • コーディング長時間タスクが主なら、SWE Marathon / Program Bench と自社リポジトリタスクをセットで測る

Ken Huang 氏の技術解説(Substack)は、MoE / KDA や AA・Arena の枠組み整理に使えます。アーキテクチャ理解の補助であり、採用決裁の単独根拠にはしません。


料金・提供経路と導入チェックリスト

料金は「list price」と「cache 後の実効単価」を分けて見ます。公式 pricing(1M tokens)は次のとおりです。

モデル 単位 Input cache hit Input cache miss Output Context
kimi-k3 1M tokens $0.30 $3.00 $15.00 1,048,576

出典:Kimi API pricing (chat-k3)(2026年7月時点)

ポイントは次です。

  • コンテキスト長によるティアはなく flat の pay-as-you-go
  • キャッシュ設計が効けば input 実効単価は list の $3 より大きく下がる
  • OpenRouter のリストも $3 / $15、cache read $0.30 前後で整合。ただし upstream 容量制限・429 に注意
  • web_search は公式が更新中で近々の production 非推奨と明記

最小手順(公式 API)


セットアップ

  1. 用途を1つに固定する(API 単発検証 / エージェント長時間 / ローカル重み待ち)
  2. pip install --upgrade 'openai>=1.0'
  3. OpenAI SDK で base_url="https://api.moonshot.ai/v1"model="kimi-k3"

ハーネス制約

  1. thinking は常時 ON。reasoning_effort は現状 "max" のみ(K2 系の thinking パラメータは使わない)
  2. マルチターンでは assistant メッセージを 完全なまま 返却する(content だけ残さない)
  3. vision は公開 URL 不可。base64 または ms://<file-id>
  4. structured output は final content のみ parse(reasoning_content を JSON として扱わない)

回帰と本番前

  1. 小さく回帰する: ツール呼び出し、JSON schema、レイテンシ、429、structured error
  2. 本番前に system / AGENTS.md で過度な主体性を抑止する(公式 Limitations)
  3. 2026-07-27 前後に weights とライセンスを再確認してから自前推論計画を立てる

出典:Kimi K3 quickstartpricingOpenRouter


導入前チェックリスト

  • 用途を API検証 / エージェント / 重み待ちのどれか1つに固定した
  • 公式 pricing で cache hit / miss を確認した
  • ハーネスが thinking history(assistant 完全メッセージ)を保持できる
  • vision を使うなら base64 / ms:// 経路を用意した
  • 10〜20本の代表タスクで品質・レイテンシ・429・structured error を測る計画がある
  • OpenRouter 利用時は容量制限バナーとエラー率をダッシュボードで見る
  • 7/27 前後の weights・ライセンス再確認日をカレンダーに入れた
  • 総合置換ではなく「追加候補」として評価基準を書いた

エージェント運用の外ループ設計は、エージェントLoopを安全に回すハーネス設計とも接続できます。指示・ガード・検証の分離を先に決めておくと、thinking history 制約と相性が良くなります。


関連記事:

よくある質問(FAQ)

Q1. Claude Fable 5 や GPT-5.6 Sol の置き換えになる?

公式は総合で未達と明記しています。全面置換前提ではなく、コーディングや長時間タスクの追加候補として小さく測るのが妥当です。


Q2. 今すぐ使える経路は?

kimi.com / Kimi Code / 公式 API(kimi-k3)/ OpenRouter(moonshotai/kimi-k3)/ Cloudflare Workers AI です。フルウェイトは 2026-07-27 予定で、ライセンスは公開時に再確認してください。


Q3. 料金の目安は?

公式は 1M tokens あたり input cache hit $0.30 / miss $3.00 / output $15.00 です。キャッシュ設計で実効 input 単価が大きく変わります。


Q4. 実装でハマりやすい点は?

  • reasoning_effort は max のみ
  • assistant 完全返却
  • vision の public URL 不可
  • web_search の近々非推奨
  • thinking 途中切替の非推奨
  • structured output は final content のみ parse

Q5. オープンウェイト後にすぐ自前ホストすべき?

ブログ時点ではライセンス・推論要件・周辺ツールチェーンが未確定です。まず API で価値検証し、公開条件を見てから自前化計画を立てる方が安全です。


Q6. OpenRouter と公式 API のどちらを先に試す?

請求と観測を既存 OpenRouter に寄せたいなら OpenRouter、制約の一次情報に忠実に試すなら公式 API です。どちらでも 429 と structured error は自前で測ってください。


まとめ|次にやること

Kimi K3 は「巨大オープンモデル」の話題性と、API で今日から測れる実務性の両方を持っています。

ただし公式自身が総合未達と UX ギャップを認めており、見出しのベンチ首位だけでの全面置換は危険です。

次のアクション順

  1. 用途を1つに固定する(API検証 / エージェント / 重み待ち)
  2. 公式 pricing と quickstart の制約をチェックリスト化する
  3. 10〜20本の代表タスクで品質・コスト・429・structured error を測る
  4. 価値が出た領域だけルーティング対象に入れる
  5. 2026-07-27 前後に weights とライセンスを再確認する
krona23

著者

krona23

IT業界20年以上の実務経験を持ち、日本国内有数のPVを誇る大規模Webサービスで事業部長・CTOを複数社で歴任。Windows/iOS/Android/Webと技術の変遷を経験し、現在はAIネイティブへの変革に注力。DevGENTでは、AIコードエディタ・自動化ツール・LLMの実践的な使い方を日英西3言語で発信中。

DevGENT について →

コメントを残す

Trending

DevGENTをもっと見る

今すぐ購読し、続きを読んで、すべてのアーカイブにアクセスしましょう。

続きを読む