Kimi K3.1 Pro 徹底解説：長時間のコーディング、3D 性能、実際の利用コスト

Kimi K3.1 Pro で注目すべきなのは、長いタスクを最後までやり遂げられるかどうかです。プロジェクトを理解し、コードを修正し、ツールを呼び出し、失敗のフィードバックをもとにさらに修正を続けられるか。見栄えのよい最初の画面は、そのごく一部にすぎません。開発者にとってより価値のある問いは、10 回目の修正のあとも元の機能が動いているか、成果物が検収に通るか、です。

本記事で扱う正式なモデルは Kimi K3.1 Pro と、高速版の Kimi K3.1 Pro Highspeed です。資料の確認日は 2026 年 10 月 23 日で、数値は公式の公開資料によるものです。Folkbench は今回モデルを呼び出しておらず、ベンチマークも再実行しておらず、独自のスコアも付けていません。

まずモデルを正しく把握する

モデル名と位置づけは公式モデル一覧、正確なコンテキスト長は課金ドキュメント、API の機能はクイックスタートで確認できます。公式技術ブログはこのモデルを K3 の事後学習版と説明し、重みの公開計画も示しています。したがって、バージョン番号だけで基盤アーキテクチャが変わったと推測すべきではなく、オープンウェイトの計画を、すでにローカルにデプロイできるかのように書くべきでもありません。

2 つのベンチマークは、それぞれ別の問いに答える

下の表と図は、Kimi 技術ブログに掲載された同じ比較値を使っています。競合モデルのデータも同じページからのもので、Folkbench が統一環境で測り直した結果ではありません。

公式の脚注によると、推論強度はデフォルトで max を使っています。Kimi の Terminal-Bench は Claude Code の実行フレームワークを使い、競合の列はリリース資料や公開ランキングのデータを集めたものです。BenchCAD のオープンモデルのテストは 1,000 サンプルのサブセットを使い、ツール使用ありの設定でも Claude Code を使っています。こうした条件は、数値と一緒に残しておく必要があります。

長時間のコーディング：近いスコアでも、プロジェクトの検収の代わりにはならない

65.7% と 66.4% の差は 0.7 ポイント です。この公式表の中では性能が近いと言えますが、同じ実行予算、繰り返し回数、不確実性の範囲がそろっていない以上、「能力が同じ」とは書けません。同様に、ある 1 項目で別のモデルを上回っても、あらゆるコーディングタスクでより強いとは言えません。

実際のプロジェクトで注目すべきなのは、エラーからの回復です。1 つのタスクで、インターフェースを変更し、呼び出し側を更新し、互換性のある挙動を保ち、しかも既存の機能を壊さないことが求められる場合があります。モデルが最初にどれだけのコードを生成したかでは、こうした問いに答えられません。失敗したテストが実際に何を指摘しているのかを理解し、アサーションを削除したり、条件を緩めたり、機能を省いたりして合格を装うことを避ける必要があります。

コードのワークフローに組み込むつもりなら、すでに解決済みで受け入れ基準が明確な過去のタスクを 1 つ選んで再実行するとよいでしょう。リポジトリのバージョンと要件を固定し、候補モデルにそれぞれ独立して処理させ、テスト結果、変更範囲、人手による修正量を確認します。こうした記録のほうが、「うまく書けていそう」という印象よりも、移行するかどうかの判断材料になります。ここで述べたのは推奨する検収方法であり、本記事で実施した実験ではありません。

3D：形状が近くても、成果物として納品できるとは限らない

BenchCAD のこの行が測っているのは Voxel IoU です。92.7% を「モデリングタスクの 92.7% が成功」と言い換えることはできず、芸術的な品質の評価として扱うこともできません。幾何形状の再構成と、マテリアル、ライティング、アニメーション、編集のしやすさ、製造公差は、それぞれ別の検収項目です。

用途が Web ページの Three.js シーンなら、検収にはインタラクションが機能するか、デバイス上でなめらかに動くか、リソースを読み込めるかを含めるべきです。用途が編集可能な部品なら、寸法の関係、パラメーター変更後の形状、エクスポートしたファイルを確認します。ある角度からのレンダリングがきれいでも、裏面の欠け、構造の干渉、使えないトポロジーが隠れていることがあります。

この 2 つの公式データから、Folkbench 編集部は、長時間のコーディングとプログラムによるモデリングのタスクで、このモデルを候補リストに入れる価値があると判断します。既存の手段を置き換えられるかどうかは、対象プロジェクトの成果物で決めるべきです。

100 万トークンのコンテキスト：容量が解決するのは「入るかどうか」

1,048,576 トークンに実際のファイルがどれだけ入るかは、内容とトークン化によって変わります。決まった文字数やコード行数ではありません。さらに重要なのは、容量があっても、モデルが正しい根拠を見つけること、それまでの制約を覚えていること、数十回のツール呼び出しのあとも元の目標を守り続けることが、自動的に保証されるわけではない点です。

大規模なプロジェクトでは、リポジトリ全体をリクエストに入れると便利なこともありますが、生成物、古いドキュメント、互いに矛盾する説明まで一緒に持ち込むことになります。よい入力は、現在のバージョン、対象ファイル、変えてはいけない挙動、検収の入口を明確にします。モデルに必要なのは、単に多いコンテキストではなく、使えるコンテキストです。

複数ターンのタスクには、見落としやすいコストもあります。公式の思考モデルのドキュメントは、過去の assistant メッセージに含まれる推論内容を保持するよう求めています。この部分はコンテキストを占め続け、課金の対象にもなります。1 回の返答が短く見えても、実行全体のトークン消費が少ないとは限りません。

API 連携：わずかなパラメーターで使い勝手が変わる

推論強度のドキュメントによると、K3.1 Pro は常に推論を行い、デフォルトの強度は max です。low は強度を下げる設定であって、思考をオフにするものではありません。速度を比べるときは、まずこのパラメーターを揃えてください。そうしないと、「遅い」という結果が、単に異なる予算を使っていただけということになりかねません。

移行時には、次の 3 点を個別に確認してください。

1. トップレベルの reasoning_effort を使い、K2 の thinking 設定をそのまま流用しないこと。
2. 複数ターンのツール呼び出しでは、reasoning_content と tool_calls を含む assistant メッセージ全体をそのまま保持すること。最終的な本文だけを残すと、API が求める履歴情報が失われます。
3. 画像入力はクイックスタートに従い、base64 か ms:// のファイル参照を使うこと。任意の公開画像 URL をそのまま渡せるとは考えないでください。

中継サービスでは、さらに確認すべき点があります。リクエストのフィールドが保持されているか、レスポンスが途中で切れていないか、モデル名が別のものにマッピングされていないか、usage フィールドが欠けていないか、です。モデル API が正常に返答したからといって、その上で動くエージェントのツールループが正しく機能しているとは限りません。

コスト：まず 1 タスクを計算し、それからコスパを語る

今回取得した公式の価格ページと、その Markdown 版からは、K3.1 Pro について確認できる完全な単価の行が返ってきませんでした。そのため本記事では米ドルの単価を記載せず、K3 や第三者の中継サービスの価格を流用することもしません。この確認結果は、公式が価格を公表していないことを意味するものではありません。本記事には、ある数字を価格表に書き込むだけの十分な根拠がない、ということです。

確認できたのは課金の仕組みです。API は従量課金で、Kimi の会員プランや Kimi Code とは別です。キャッシュ書き込みは TTL によって区分され、キャッシュヒット時の読み取りとキャッシュなしの入力は別々に計算されます。クイックスタートでは、コンテキスト長による料金区分はないと説明されています。再利用のルールと有効期間は、キャッシュのドキュメントで確認できます。

つまり、長いコンテキストのタスクは分解して見る必要があります。どの入力がキャッシュにヒットしなかったか、どれがキャッシュ書き込みを発生させたか、どれがキャッシュ読み取りとして課金されたか、そして最終的にどれだけの出力が生まれたか、です。ツールサービス、実行環境、失敗時の再試行も総支出を増やすことがあります。計算では請求の実際の区分に従い、同じトークンを複数の項目に二重計上しないようにしてください。

調達や移行の議論に向いた指標は、そのタスク群の総支出 ÷ 検収に合格したタスク数 です。失敗した試行も分子に残します。すべて失敗した場合は、報告できる成功タスクあたりの単価はありません。これは本記事が推奨する比較方法であり、Folkbench が測定した結果ではありません。

公式モデル一覧では、Highspeed は同じ能力で約 2～3 倍の速度 を持つバリアントと説明されています。これは提供元の主張であり、ワークフロー全体が 2～3 倍速くなると換算することはできません。モデルの生成が総所要時間の半分を占める場合、その半分が 3 分の 1 に短縮されても、全体は 1 から約 0.67 に下がるだけで、約 1.5 倍の速度にとどまります。これはボトルネックを説明するための仮の計算例であり、Kimi の実測レイテンシではありません。

優先して試す価値のあるタスク

最初の 3 つは公式の位置づけと一致しますが、位置づけは品質の保証にはなりません。特にリサーチのタスクでは、文章の流暢さや引用の多さは、一つひとつの確認の代わりにはなりません。出典が本当に結論を裏づけているか、年と単位が一貫しているか、表の数式を再計算できるかを確かめる必要があります。単純な分類では、デフォルトで max を使うフラッグシップモデルが最も割安な選択とは限りません。

Folkbench の判断

Kimi K3.1 Pro の公式資料は、真剣に検証する価値のある能力のシグナルを示しています。長時間のコーディングとプログラムによるモデリングは、どちらも高水準の比較対象に迫る範囲に入っています。実際の価値は、これらの能力が、ご自身の入力、ツール、予算のもとで、検収できる成果物に安定して結びつくかどうかで決まります。

現時点では、本記事独自の呼び出し記録、繰り返し実験、失敗の分布、確認可能な単価がまだないため、ここでは総合スコアを公開せず、「最強のコスパ」という結論も出しません。クイックスタートの一部のベンチマークの段落にはまだプレースホルダーが残っており、技術ブログとはバージョンの異なる記述もあります。本記事の 2 つの数値は技術ブログの同じページの比較だけを採用しており、異なるバージョンをつなぎ合わせてはいません。

コードのワークフローを評価しているなら、続けて [Folkbench ソフトウェアエンジニアリング評価ガイド](/ja/blog/ai-api-relay-software-engineering-evaluation-guide)をお読みください。ほかのモデルの資料の範囲を比べるには、[Claude Opus 5.5](/ja/blog/claude-opus-5-5-review-pricing) と [GPT-6.1 Sol](/ja/blog/gpt-6-1-sol-review-pricing) を参照してください。後者は上の表の GPT-6 Astra ではないため、モデル名とスコアを混同しないでください。