2026年7月、Moonshot AIが2.78兆パラメータのオープンウェイトモデル「Kimi K3」を公開しました。誰でも入手できる巨大モデルの登場は、オンプレミスでのAI内製化を目指す企業に何をもたらすのでしょうか。
この記事は会員限定です。会員登録すると全てご覧いただけます。
AIやデータ分析の分野では、毎日のように新しい技術やサービスが登場している。その中にはビジネスに役立つものも、根底をひっくり返すほどのものも存在する。本連載では、ITサービス企業・日本TCSの「AIラボ」で所長を務める三澤瑠花氏が、データ分析や生成AIの分野で注目されている最新論文や企業発表をビジネス視点から紹介する。
2.78兆パラメータを持つオープンウェイトモデル「Kimi K3」。公開後には、単一CPUと約8GBのRAMでも使えたという実装がコミュニティで報告されました。しかし、生成速度は1トークン(〜1文字)当たり数十秒規模です。
この極端な事例が示すのは、巨大モデルを「動かせること」と、必要な速度、同時実行性、可用性を備えた業務サービスとして使えることは同じではないという事実です。本記事では、Kimi K3の2.78兆パラメータ、100万トークン、疎なMoEを支える設計を読み解き、企業が巨大AIの導入で本当に比較すべきものを考えます。
これまで、LLMの性能を向上させるにはモデルが公開される前の「事前学習」の段階で、より大きなモデルをより多くのデータで訓練することが主流でした。これはモデル公開前にいかに多くの計算コストをかけるかという競争でした。
しかし最近、「推論時」(モデル利用時)にどれだけ計算コストをかけるかという第2の性能向上の道筋が登場しました。これは、モデルがユーザーの質問に答える際に、より深く思考するための計算時間を増やすというアプローチです。
技術レポートはこの流れの代表例としてOpenAIの「oシリーズ」、Anthropicの「拡張思考モデル」を挙げています。そして大規模な強化学習によってモデルから高度な推論能力を引き出せることを示したDeepSeek-R1など、さらに複数のエージェントが並列で協調してタスクをこなす方向へと発展してきた流れを紹介しています。
問題はここからです。オープンモデルはこの第2の軸では急速に進歩した一方で、第1の軸では歩みが遅く、多くのモデルが1兆パラメータ程度にとどまってきました。
そのため、同程度の規模のモデルの上に、いくら第2の軸の推論(reasoning)を洗練させていっても、オープンモデル同士の進歩は似たような性能へと収束してしまいます。一方で、潤沢な資産とインフラを持つ非公開モデル(プロプライエタリ)は、巨大な脳(第1の軸)に深い思考力(第2の軸)を掛け合わせ、両方の軸を同時に引き上げ続けています。このままでは、オープンと非公開モデルの実力差は開く一方になります。
この構造的な限界を打破すべく、2つの軸を同時に押し上げる狙いで開発されたのが、中国のAI開発企業Moonshot AIのKimi K3です。2.78兆のパラメータを持ち、高度な強化学習と推論、そして100万トークン(文庫本にして数冊分)に及ぶ長い対話を融合させました。
Kimi K3はKimi K2と比べ、モデルの構成を大幅にスケールアップさせたことで、「学習の効率(スケーリング効率)」を約2.5倍に向上させることに成功しています。
(注)効率「2.5倍」とは、ベンチマークのスコアが2.5倍になったという意味ではありません。レポートのスケーリング則に基づく比較において、一定の検証損失に達するための学習計算効率がKimi K2比で約2.5倍に改善したことを示しています。
そもそも、オープンモデルが1兆パラメータ級で頭打ちになってしまうなら、データの秘匿性やセキュリティの観点から「オンプレミスでの高度な内製化」を志向する企業にとって重大な制約となります。
社外にデータを出せない以上、オープンモデルを使うしか選択肢がないにもかかわらず、その実力が頭打ちになれば、高度な専門業務を自社の安全な環境で自律処理させるという未来が、技術的な制約により閉ざされてしまうからです。結果として、利便性をとってリスクを冒しながら商用APIを頼るか、安全性を取って性能の劣るモデルで妥協するかという二者択一を迫られます。
Kimi K3が2.78兆パラメータのオープンモデルとして公開されたことは、単なる性能表の順位争いを超えた意味を持ちます。それは、巨大な最先端モデルを自社のオンプレミス環境で検証するという選択肢を与えたことです。ただし、後述するように、モデルの重みや技術詳細が公開されていることと、それを自社のインフラで実際に動かせることは別の問題です。
レポート第5章は、Kimi K3が単一のモデルで同時に抱えた3つのシステム課題を挙げています。それは、「ハイブリッドな注意機構」「2.78兆パラメータの疎なマルチモーダル学習と推論」、そして「100万トークン規模のエージェント作業負荷」を、いかにインフラを破綻させずに現実的なコストで商用サービスとして成り立たせるかという高い障壁です。
従来のAIは、文脈が長くなるたびに「どこに何が書かれていたか(位置情報)」を見失うため、いわば「その場しのぎの延命措置(チューニング)」を重ねて長い文脈に対応していました。Kimi K3はこの限界を、記憶と処理のハイブリッド設計で根本から解決しました。
技術のすごさ(KDA 3層 + Gated MLA 1層のハイブリッド)
伸び続ける記憶(キャッシュ)の代わりに、固定サイズのメモ帳(再帰状態)で情報を混ぜ合わせる「KDA」を69層。そして、キーとバリューの表現を極限まで低次元に圧縮して保持する「MLA」を24層配備しました。
これによって、位置情報について自己解決できるようになりました。MLA層には、位置を表す情報を別途持たせていません。順に処理して状態を更新し、チャネルごとに減衰をかけるKDAの構造そのものに「順序と近さ」が自然に埋め込まれているためです。
結果として、従来のような位置情報の修正(RoPE)に頼ることなく100万トークンの長文へ適応できる設計を実現しました。実際の訓練では、短い文書から段階的に文脈を伸ばす手順が必要になります。ただし、文脈を伸ばすたびに生じていたアーキテクチャ上の挙動の不安定さは解消されました。
次に特徴的なのが、マルチモーダルモデルの訓練方法です。これまでのマルチモーダルAIは、「画像を理解するモデル(ビジョンモデル)」と「テキストを書くモデル(言語モデル)」が別々に分かれており、事後的にそれらを統合する設計が主流でした。
Kimi K3は、テキスト、画像、動画を単一のバックボーンが1つの文脈の中で処理し、事後にモダリティ(入力方法)を整合させる段階を置いていません。
技術のすごさ(同一トークン列での処理)
描画結果(ビジュアル)と、それを生成したコードが、全く同じ情報の配列(トークンストリーム)の中に存在します。
つまり、長期にわたる「視覚を伴う自律エージェント挙動」の圧倒的な基盤となります。AIがコードを書き、その出力を自ら検査し修正する、という人間と全く同じ「作って、見て、手直しする」の反復が、外部モデルへのデータ受け渡しを一切挟まずに、1つのモデル内で高速に完結します。
最後に、2.78兆パラメータという巨大な脳を常にフル稼働させていては、どれだけインフラがあっても足りず、電気代とサーバコストで運用が自滅します。Kimi K3は、いかにモデル全体を使わずにさぼらせるかの設計を主眼にしました。
技術のすごさ
これらの手法により、全2.78兆パラメータを毎回一律に使うのではなく、必要な部分だけを限定して動かすことで、巨大な知能と効率的実行を両立しています。
ただし、動かすパラメータが減った分だけ推論コストが下がるという単純な話ではありません。実際の推論原価は、演算量だけではなく、ノード間の通信、メモリアクセス、キャッシュ効率、そして並列化方式など、インフラ全体の作り込みに大きく左右されます。
商用サービスとして成立させるためのインフラ記述において、最も実務的なのは「キャッシュ(記憶の再利用)」と「要求の分離」についての言及です。
100万トークン規模のコーディング要求では、「40万トークンは既存のコードを読み込ませた上で、新規に4000トークン程度の修正計算を要求する」といった状況があるとします。
この時、毎回40万トークンをゼロから再計算してはインフラ原価が高額になります(同じチャット画面内でやり取りを重ねるほど、裏側に送られる過去の会話データは膨れ上がり続けます。これを適切なキャッシュ設計なしで処理しようとすれば、膨大な再計算が発生してしまいます)。
既にある情報(過去の会話や読み込ませたコード)の再計算を避け、キャッシュから再利用し、新規に追加された約4000トークン分を中心に処理する。この「会話の組み立て方」と「文脈の持たせ方(キャッシュのきかせ方)」の設計次第で、同じ業務でもコストは桁違いとなります。
本番環境には「2000トークン未満の短い要求」と「最大100万トークンの超長文要求」が混在し、1回当たりの計算コストには約1000倍の開きが生まれる可能性があります。こうした要求を同じ資源プールで無制限に受け付けると、重い長文要求が資源を占有し、短いチャットの応答速度まで悪化する可能性があります。
Kimi K3は、要求を負荷別に分類し、それぞれに独立した計算予算を割り当てて制御しています。企業のAI基盤でも、即時応答が必要な対話と、時間をかけられる長文分析やエージェント処理を分け、それぞれに求める応答時間と計算資源の上限を別々に設計することが重要です。
レポートによると、Kimi K3の総合成績は、AnthropicのClaude Fable 5とOpenAIのGPT-5.6 Solに及びません。一方でコーディングやブラウジング、自律実行といった一部のエージェント系評価では、この2モデルに近い、または上回るスコアを示しています。
ただし、これらのスコアはMoonshot AIが自社で測定して公表した値です。全モデルを最大の推論設定で評価しており、評価環境や設定が変われば結果も変わります。
ここで見るべきなのは、スコアの順位ではなく「1タスク当たりの推論コスト」です。
レポートでは主要ベンチマークのスコアを開示しています。Webブラウジングやコーディングといったエージェント系の評価では、Kimi K3はClaude Fable 5やGPT-5.6 Solと数ポイント差の範囲に収まっています。ベンチマークによっては上回る項目もあります。
Webブラウザを操作して情報を検索し、回答をまとめるエージェントタスクの比較。Kimi K3のコストはKimiチームが計測。ClaudeとGPTのコストについては、AnthropicやOpenAIが公式に発表している技術資料やシステムカードから引用(技術レポートの図13 (b)より)(筆者作成)しかし、この「低コスト」の恩恵を日本の企業がそのまま享受できるわけではありません。
第1の理由は地政学的要因を含むガバナンス上のハードルです。Moonshot AIは中国企業です。セキュリティやガバナンス、各社の調達方針などによっては、日本企業が機密性の高い業務を中国ベンダーの商用APIに委ねることが難しい場合があります。
商用APIが自社の要件に適合しない場合、セルフホストや閉域環境での運用が選択肢になります。ただし、モデルの重みを取得できることと、企業の本番サービスとして運用できることは別問題です。
Kimi K3の公開後には、有志のコミュニティ実装として、必要な重みをストレージから逐次読み出し、単一CPUと約8GBのRAMで推論を成立させた事例も報告されています(論文外の非公式報告。生成速度は1トークンあたり数十秒規模とされる)。この事例が示すのは、「動かせること」と「業務サービスとして使えること」は違うという点です。
必要なインフラは、総パラメータ数だけでは決まりません。量子化方式、メモリとストレージの使い分け、応答速度、同時実行数、可用性によって大きく変わります。また、論文が一部の評価で示した低い「1タスク当たり推論コスト」は、セルフホストに伴う設備費、電力、運用要員まで含む総保有コストではありません。
Kimi K3の技術レポートは、オープンウェイトモデルが、一部のエージェント業務やコーディング業務でClaude Fable 5やGPT-5.6 Solに近い性能を示し得ることを報告しました。一方、モデルの重みを取得できることは、企業が必要とする応答速度、同時実行性、可用性、セキュリティを満たして運用できることを意味しません。セルフホストの可否は、総パラメータ数だけではなく、量子化方式、メモリとストレージの使い分け、必要な応答性能、運用体制を含むシステム全体で判断する必要があります。
Kimi K3が示したのは「巨大オープンモデルは企業には使えない」という単純な結論ではありません。全ての重みを高速メモリへ常駐させず、ストレージから必要な部分を読みだせば小さいメモリでも動きます。一方でその代償として反応速度は大きく低下します。
つまり、モデルの総パラメータ数や最低メモリ量だけでは企業利用の可否も経済性も判断できません。企業が比較すべきなのは、最小構成で一度動かせるかではなく、対象業務で求める品質を、必要な時間内に、想定する利用者へ、必要な可用性の下で提供できるかです。
「動く」と「企業で使える」は違います。Kimi K3は企業にこれを考えさせた点に価値があります。
AIは本当に「考えている」のか Apple論文が問いかけた推論モデルの限界とその行方
AIエージェントを手元で常時稼働 Meta「Muse Glimmer」公開
メインフレーム離脱プロジェクトの7割超が失敗、理由は「生成AIの過大評価」
なぜ本番環境のAIは失敗するのか? Datadog調査で判明した「運用の壁」と打開策Copyright © ITmedia, Inc. All Rights Reserved.