Kimi K2とLLMのベンチマークスコア
Kimi K2は、中国のMoonshot AIが開発したオープンウェイトの大規模言語モデルです。2025年1月20日に公開されたKimi k1.5以来のKimiの第4世代目のモデルです。
特徴としては128Kトークンのコンテキストウィンドウがあります。参考までにClaude 4が200kでGemini 2.5 が1M。Grok4は256kです。
また「non-thinking」モデルとして、思考ブロックを出力しないアーキテクチャになっています。公式ブログによると将来的に拡張推論機能の追加予定があるようです。
性能評価
Kimi K2はコード生成でフロンティアモデルと肩を並べるスコアを記録しています。
MoonshotAI
SWE-bench Verifiedでは65.8%のスコアを達成しています。これはOSSのバグ修正パッチ生成タスクを計測してます。Gemini 2.5 Proが63.8%でClaude 4 Sonnetが72.7%と比較しても高い水準です。
LiveCodeBenchでは53.7%を記録していることから、競技プログラミング的なコード生成においては、Claude 4 Sonnetが約48.5%でGemini 2.5 Proが約70.4%との中間に位置していることが分かります。
Aider LLM Leaderboardsでは59.1%のスコアを記録しています。これはAiderでプログラミングクイズを225個解くテストです。自動テストで正解率を測ります。
claude-sonnet-4が61.3%で、gemini-2.5-proが83.1%と比較すると下位に位置しますが、claude-sonnet-4-(no thinking)56.4%を上回ります。オープンウェイトモデルとしてはDeepSeek-R1やQwen3 235Bに並びます。
コストメリット
Kimi K2のAPI利用料は非常に安価です。プロバイダーによっては出力トークン価格（1M）$2.50と設定されており、Claude 4 Sonnetが$15、Gemini 2.5 Proが$10と比較して大幅に安価です。
この価格設定は思わずClineの魂も震えるぐらいの安さとして注目されています。
Nick Baumann
利用方法
Kimi K2の利用にはMoonshot AI公式API、OpenRouter、セルフホストの選択肢があります。公式APIを使うには$5クレジットをチャージする必要があります。OpenRouterには無料枠があります。
セルフホストする場合の要件は、モデル重み（1TB以上）をダウンロードし、250GB以上のRAM/VRAMとGPUが必要です。オープンウェイトモデルといってもまだまだご家庭のゲーミングPCで日常利用するのには無理があります。
現実的にはOpenRouter+Cline/Roo Codeの組み合わせで使えますので、それが候補です。
一方Cursorの対応モデルにもリストされており、ProプランでKimi-K2-Instructが使えます。筆者はCursorから試用しました。フォーラムによるとFireworksでホストされているようです。
Salfar
実践評価：SWE-Lancerでの検証
Kimi K2の説明に登場する既知のベンチマークは全てPythonが中心です。実践的な能力を図るためにある程度規模のコードベースの中で作業をしてもらいましょう。
先日投稿した「Kiroとコンテキストエンジニアリングの時流」の中でSWE-Lancerのデータセットからコーディングタスクを１つ取り出し実施しました。これは数十万行のフロントエンド領域のモノレポで、実際のSaaSで使われていますので検証に最適です。
実は、SWE-LancerにはIC（コード実装）のタスクとManager タスク（提案選択）と言う2種類のタスクがあります。このManager タスクは普段私たちが行なっているコード修正前のプランニングタスクに相当します。SWE-Lancerのデータセットでは実際のIssueとそのコメントから修正提案の候補を番号づけし、LLMが「どの修正方法を選ぶのか」という評価を実施します。LLMが選択した提案番号とデータセットにある「正解の提案番号」が一致するかどうかを確認します。
以下の検証では、CursorでKimi K2を使ってコードベースを参照し、プランニングタスクを実施してもらいます。データセットのCSVをパースして、クイズ形式で「選択肢」「回答」を取得するスクリプトを書きました。問題IDを指定してプロンプトを生成し、「選択肢」までの部分をCursorに入力し、応答内容から「回答」に一致するのかを目視で確認します。
評価結果
14958-manager-0 このIssueは、Expensifyアプリの住所設定画面でzip/postcodeフィールドにカンマ（,）を入力した際に、バリデーションエラーメッセージが表示されない問題です。選択肢は0−5番まであり、Kimi K2は「５：郵便番号に英字を許可し、全フィールドのトリム処理を改善」を選びました。データセット上の正解は「１：全フィールドのバリデーションを改善し、ValidationUtilsを活用」で、これはコードベースの他のモジュールに注意を向けないと選べない答えでした。他のタスクも試してみます。
kavimuru
14268-manager-0 このIssueは、アプリのメッセージ送信・編集機能において、UI上で表示される文字数とHTMLに変換後の文字数の差異により、APIリクエストが失敗する問題です。選択肢は0−3番まであり、Kimi K2は「１：タイピングの中断時にのみ計算（デバウンス）」を選択しました。これはデータセット上の正解と一致しました。このタスクは純粋なアプローチのみの判断で、コンテキストは少ないです。
kavimuru
14294-manager-0 このIssueは、チャットでGoogle Docsからテキストをコピー&ペーストした際に、フォーマットが意図せず太字になったり、太字テキストの前後にアスタリスク（*）が表示される問題です。このIssueに関する提案は多く、１２件あります。Kimi K2の選択は「２：docs-internal-guidを検出したら、プレーンテキストとして貼り付ける」でした。データセット上の正解はなんと「９：Google Docs専用のインラインスタイル解析に必要な労力に見合わない可能性があるため、何もしない」。引っ掛け問題かよ。いえ、「何もしない」という選択肢も、エンジニアリング判断として重要な選択肢の一つです。
kavimuru
まとめ
本記事ではコストパフォーマンスに優れた中国発の大規模言語モデルKimi K2の評価をSWE-LancerのManagerタスクを使って実施しました。
これらの結果から、Kimi K2は実際の大規模コードベースでの作業において、十分実用的な判断能力を持っているというのが分かりました。
と同時にLLMのベンチマークというのは実際の中身を見ると検証方法に曖昧な部分も多いという印象があります。
昨今のLLM新モデルリリースに発表されるスコアも多分にマーケティング要素を含んでいますので、数値の上下だけを鵜呑みにせず、実際の評価は自らエージェントに組み込んで行うしかないのでしょう。