同じコーディングタスクを Kimi K2.7 Code と Claude Opus 4.8 に 1つの API 経由で送信し、返ってきた結果を測定しました。正確性では両者は互角で、SemVer の優先順位の落とし穴と、隠れた区間マージのバグの両方を見事に解決しました。しかし、Opus は 3〜9 倍高速で、出力トークン数は 4分の1でした。一方で、Kimi は定価ベースでタスクあたり約 46% 安く済みました。したがって、選択はどのモデルが「賢い」かではありません。コストに敏感な、またはバッチ処理のコーディング作業を行うなら、価格面では Kimi K2.7 が勝ちです。低レイテンシ、100万トークンのコンテキスト、あるいは最終レビューに信頼できるモデルが必要なら、Opus 4.8 はその上乗せ価格に見合う価値があり、多くのチームは最終的にこの 2つを使い分けるようになります。
実地検証: 同じコーディング作業を両方で実行してみた
私がテストした方法: model IDs kimi-k2.7-code と claude-opus-4-8 を、2026-07-13 に 1 つの OpenAI-compatible gateway endpoint 経由で呼び出し、各タスクにつき single-shot、default parameters、prompt caching なしで実行しました。Latency は client-side で wall-clock 測定しているため、generation だけでなく network と queue time も含まれます。採点の前に sanity check として各モデルに自己 पहचानさせたところ（Kimi は "made by Moonshot AI,"、Opus は Anthropic と返答）、それは routing check であって version の証明ではありません。これは 2-task の sample であり、benchmark ではありません。感じ取れる behavior は示せますが、multi-turn の agentic performance は測定できません。
Task 1 では、各モデルに SemVer 2.0.0 仕様に従って compare_semver() 関数を実装するよう求めました。ここには、多くの実装が間違える部分であるプリリリースの優先順位も含まれます。たとえば、1.0.0-alpha.1 < 1.0.0-alpha.beta、数値識別子は英数字識別子より低く順位付けされ、beta.11 > beta.2 は文字列順ではなく数値的に比較されます。私は、仕様の標準的な順序に基づいて作成した 72 件の比較マトリックスに対して各回答を採点しました。Task 2 では、バグのある merge_intervals() 関数を提示しました。本当の欠陥は max(...) ではなく last[1] = cur[1] になっていたことで、この1行のせいで [1,10],[2,3] のような完全に内包された区間が静かに消えてしまいます。私は、その内包された区間を含む 5 つのケースに対して採点しました。
指標 | Kimi K2.7 Code | Claude Opus 4.8 |
|---|---|---|
タスク1の正確性（72件の優先順位 + エッジケース） | 72/72 | 72/72 |
タスク2の正確性（含まれる区間を含む5件） | 5/5 | 5/5 |
タスク1のレイテンシ（クライアント側） | 49.1s | 5.3s |
タスク2のレイテンシ（クライアント側） | 11.5s | 7.6s |
タスク1のトークン数（入力 / 出力） | 172 / 1,907 | 774 / 418 |
タスク1のコスト（標準価格） | $0.0078 | $0.0143 |
コストは、上記のトークン数を基に、各モデルの標準リスト価格（Kimi は入出力ごとに百万トークンあたり $0.95/$4、Opus は $5/$25）で算出されています。Kimi = 172×$0.95/M + 1,907×$4/M ≈ $0.0078; Opus = 774×$5/M + 418×$25/M ≈ $0.0143。入力トークン数が異なる（172 対 774）のは、タスクが異なったからではなく、各モデルのトークナイザーとゲートウェイの課金計算が同じプロンプトを異なる方法で数えるためです。どちらのモデルも、両方のタスクで完全に正しいコードを生成しました。違いは、そこに至る過程でした。Opus は簡潔で高速で、Task 1 で 5.3 秒のうちに 418 トークンを返しました。Kimi は 49.1 秒かかり、1,907 トークンを出力しました。その大部分は、コードとともに返されたステップごとの推論トレースでした。それでも、Kimi のトークンはおよそ 6 倍安いため、冗長な実行でもコストは低く抑えられました。
決闘が証明することと証明しないこと
これは、境界が明確で仕様もはっきりしたコーディング問題において、Kimi K2.7 Code がフロンティアモデルと同じ正解に到達することを示しています。これによって、Kimi が長時間にわたる複数ステップのエージェント的セッションで Opus に匹敵することが証明されるわけではありません。というのも、2つの単発タスクではその能力を試すことができないからです。Kimi 自身の最も強い主張はまさにそのエージェント領域にあり、以下のベンチマークはそれを直接評価しています。
ベンチマーク：サードパーティ製とMoonshot独自の表の違い
こちらが内訳です。各数値には出典を付けています。Moonshotの自己申告の表ではKimiが最も強く見えます。独立評価は、このモデルが新しいためより少なく、まだ第三者によるK2.7の数値がない場合は、公開されている最も近い数値としてK2.6を示しています（下で注記）。
ベンチマーク | Kimi K2.7 Code | Claude Opus 4.8 | 出典 |
|---|---|---|---|
MCPMark Verified（ツール使用） | 81.1 | 76.4 | Moonshot、自己申告 |
SWE-bench Verified | 60.4% | 同じ形式では未公開 | Moonshot、自己申告 |
Intelligence Index | 35（K2.6 proxy） | 56 | Artificial Analysis、第三者 |
Output speed | ~45 tok/s（K2.6 proxy） | 59 tok/s | Artificial Analysis、第三者 |
比較の根拠となっている唯一の数値、MCPMark Verified 81.1 対 76.4 は、独立した研究機関ではなく、Moonshot自身の表に由来します。だからといってこれを退ける理由にはなりません。というのも、MCPスタイルのツール使用こそがまさに Kimi が調整されてきた領域だからです。ただし、「Kimi beats Opus」という見出しは、ベンダー最適化されたベンチマーク上でのベンダー主張として読むべきです。第三者による直接比較で測定された唯一の指標では、Artificial Analysis は Opus 4.8 を Intelligence Index で大きく上位に置いています（56 対 35）。ただし、その行では執筆時点で K2.7 が独立評価されていなかったため、K2.6 を代替として使用しています。
コンテキストウィンドウのギャップが隠すベンチマーク
Opus 4.8 は 1M-token のコンテキストウィンドウを備えています。Kimi K2.7 は 256K が上限です。ベンチマークのスコアではこれが表に出ることは少ないですが、実際の作業では決定的です。256K のウィンドウがあれば、中規模のリポジトリや長いエージェントのトレースは十分に収まり、ほとんどのコーディングセッションには問題ありません。大規模な monorepo 全体、長い文書セット、あるいは数時間分のエージェントのトランスクリプトを 1 つのプロンプトに入れると、上限に達します。そこで、Opus の 4 倍大きいウィンドウが、チャート上の一点ではなく、実務上の違いになります。
価格設定：5～6倍のギャップとキャッシュのレバー
ネイティブAPIの定価では、Kimi K2.7 Codeは入力トークン100万あたり$0.95、出力100万あたり$4.00で利用できます。一方、Claude Opus 4.8は$5と$25です。出力では5～6倍の差があり、これがチームがKimiを評価する最大の理由です。
ほとんどの価格表が見落としているレバーはキャッシュです。Kimiはキャッシュヒット時に100万トークンあたり$0.19を請求し、すでに送信した入力に対して80%の割引となります。同じコードベースを各ステップで読み直すエージェントループでは、キャッシュされた入力が請求額の大半を占めるため、実質コストは表示価格の差を大きく下回ります。BasetenのPhilip Kielyは、Opus 4.8からKimi 2.7 Codeに切り替えた後、サンプルワークロードでおよそ82%の節約があったと報告しました。これは、Kimiの価格設定が効いてくる、キャッシュと入力が重い種類のジョブです。実際の数値は入力対出力比によって変わりますが、傾向は一貫しています。生成する量に対してコンテキストを読み返す量が多いほど、コスト面でKimiが有利になります。
Opusは、出力側でその価格を回収します。私のTask 1では、Kimiが生成したトークン数の4分の1しか生成しなかったので、大きなファイルの作成や冗長なリファクタリングのような生成負荷の高い作業では、トークン単価の差は実際の支出では縮まり、さらにOpusの速度によって、エンジニアが待機する時間に対して支払うウォールクロック時間も短縮されます。
オープンウェイトの約束と577GBという現実
Kimi K2.7は修正MITライセンスのもとでオープンウェイトとして提供されているため、自前でホストし、ファインチューニングできます。Opus 4.8はAPI専用であり、あなたのコードと推論トレースはAnthropicに送られます。表向きには、これはKimiにとって決定的なプライバシーとロックインの優位性です。実際には、まずハードウェアコストを確認してください。
Kimi K2.7は、1兆パラメータのMixture-of-Expertsモデルです（トークンごとに32Bがアクティブ、384エキスパート）。独立したレビュー担当者は、重み、KVキャッシュ、ランタイムのオーバーヘッドを含めると、フルINT4デプロイはおよそ577GBのVRAMになると見積もっており、最低限の実用構成は8× H100 80GB、またはDGX Spark級の筐体になります。単体のRTX 4090（24GB）では、フルモデルを実用的な設定で動かすことはできません。十分な資金を持つごく一部のチームを除けば、「open weights」とは、ホスティング事業者へルーティングする自由や、レンタルGPUでfine-tuneする自由を意味するのであって、社内に立ち上げるモデルという意味ではありません。Kimiを選ぶ理由がオンプレミスでのデータ管理にあるなら、導入を決める前にクラスターの費用を見積もるべきです。ほとんどのチームにとって、self-hostingは依然として理論上のものにとどまります。
どちらを選ぶべきですか
勝者を決めるのではなく、ワークロードに合わせてモデルを選びましょう:
Kimi K2.7 Code を選ぶのは、コスト重視で大規模に使う場合、またはコードベースを繰り返し読み直すエージェント的なコーディングで、レイテンシが重要ではなく、256K のコンテキストで十分なときです。キャッシュ割引が有利に働きます。
Claude Opus 4.8 を選ぶのは、低レイテンシが必要なとき、大規模なリポジトリや長いセッション向けに 1M トークンのコンテキストが必要なとき、より簡潔な出力が必要なとき、または重要度の高い変更を信頼して最終確認させるモデルが必要なときです。特に、独立推論スコアでの優位性が最も重要になります。
ハイブリッド戦略：安価なモデルが下書きし、最先端モデルが仕上げる
両方を使っているチームに最もよく見られるパターンは、どちらか一方を選ぶことではなく、ルーティングです。Kimi K2.7 に大量生成と反復処理を安価に任せ、最終レビューやフロンティア級の判断が必要な部分は Opus 4.8 に引き渡します。Kimi は OpenAI 形式をネイティブに話し、Opus は Anthropic 独自の API を使うため、両者の間を実際にルーティングする方法は、OpenAI 互換の単一エンドポイントの背後に両方をまとめて前面に出すゲートウェイです。たとえば AIReiter のようなプラットフォームでは、両方が単一のキーの下に置かれるため、Kimi から Opus への切り替えは再統合ではなくモデル文字列の変更で済みます。上記の 82% の節約は、Opus を完全に外したことではなく、まさにこの種のルーティングから生まれました。
よくある質問
Kimi K2.7はコーディングにおいてClaude Opus 4.8より優れていますか？
限定的で仕様が明確なタスクでは互角です。私のテストでは、どちらも完全に正しいコードを返しました。Kimiの強みはエージェント的なツール使用です（MCPMark 81.1 対 76.4、Moonshot発表）。Opusは一般的な推論、速度、長文コンテキスト処理で優位です。
Kimi K2.7はOpus 4.8よりどれくらい安いですか？
定価で約5〜6倍安い（100万あたり$0.95/$4対$5/$25）。繰り返しの多いワークロードでは、キャッシュヒット（入力100万あたり$0.19）により、実運用での節約は80%以上に達することがあります。
Kimi K2.7 と Opus 4.8 のコンテキストウィンドウは何ですか？
Kimi K2.7 は 256K トークンを処理できます。Opus 4.8 は 1M を処理でき、4倍大きいです。
Kimi K2.7 をローカルで実行できますか？
本格的なハードウェアが必要です。完全な INT4 デプロイメントには約 577GB の VRAM が必要と報告されています（おおよそ 8× H100 または DGX Spark）。RTX 4090 のような単一のコンシューマー向け GPU では、フルモデルを実行できません。
Kimi K2.7 はオープンソースですか?
修正版MITライセンスのもとでオープンウェイトとして提供されているため、セルフホストやファインチューニングが可能です。Opus 4.8はクローズドで、API専用です。
要するに
ボトルネックが予算なら、デフォルトは Kimi K2.7 Code にして、あとはキャッシュに任せましょう。レイテンシー、コンテキスト長、あるいは絶対に失敗できない変更が問題なら、Opus 4.8 にお金を払う価値があります。open-weights ライセンスは、GPU を所有している場合にのみ活用できるおまけとして扱いましょう。そして、迷うなら両方を接続し、ワークフロー全体を一つの賭けに載せるのではなく、タスクごとに振り分けてください。後で解きほぐさなければならなくなる賭けに出るよりずっと良いです。