12 min read

Kimi K3、フロントエンド最強説をReactBenchで検証する

Kimi K3、フロントエンド最強説をReactBenchで検証する

Moonshot AIがKimi K3という新しいモデルを公開し、一部の報道では「第2のDeepSeekショック」などと呼ばれました。Anthropicの最上位モデルFable 5に迫る性能を約3分の1のAPI料金で提供し、モデルの重みも公開すると予告したためです。発表と重なってNVIDIAなどのAI関連株が下がり、中国のAI開発が米国との差を予想より早く縮めたという見方が広がりました。

Kimi K3 Tech Blog: Open Frontier Intelligence
Kimi K3 is the world’s first open 3T-class model — frontier performance across coding, knowledge work, and reasoning, with native multimodality and 1M context.
KimiKimi

そんなニュースを「はいはい」と横目に眺めながら、筆者はこの新しいモデルの性能検証に取りかかりました。

K3の何がそれほど評価されたのかを調べていくと、いくつも並んだ成績のなかに、Frontend Code ArenaでClaude Fable 5を抜いて1位になったという結果がありました。Frontend Code Arenaは、同じ指示から作られた二つのWebアプリをユーザーが実際に触り、見た目や使いやすさを比べて、好きなほうへ投票するベンチマークです。

ただ、筆者の普段の開発では、画面を一から作るより、既存のコードを読み、原因を探して直す作業に多くの時間を使います。Arenaで見栄えのする画面を作れたK3は、既存のReactコードでも正しい場所を見つけて直せるのでしょうか。

そこで、オープンソースのReactプロジェクトを修正するReactBenchを使い、Claude Opus 4.8、Fable 5と比べました。1課題だけなら安く追試できるので、その再現手順も紹介します。

結果は、K3の料金はOpus 4.8の6分の1ほどだったものの、OpusがテストとReact Doctorの両方に通った課題で、K3の修正からはReact Doctorが新しい問題を2件検出しました。噂の「Fable級」の力は、まだ確認できていません。皆さんのご家庭ではどうでしょうか。

どのエージェントで使うか

初めて試すなら、まず公式のKimi Codeでよいと思います。Claude CodeやOpenCodeを使い慣れているなら、そちらへK3をつないでも構いません。CodexだけはAPIに互換性がなく、サードパーティー製の変換プロキシを挟むため、少し癖があります。

Use Kimi API Platform with Kimi Code CLI - Kimi API Platform
Connect, switch, and update Kimi Code CLI with a Kimi API Platform API Key.
Kimi API Platform

K3を使う方法は、Kimi Codeのサブスクと、Kimi Open Platformの従量課金APIに大きく分かれます。サブスクでは月額$19のModeratoからK3を利用できますが、コンテキストは最大256Kです。Open Platformは使った分だけ料金がかかります。ChatGPTのサブスクとOpenAI APIが別であるように、この二つもキー、料金、利用条件が異なります。

Kimi Open Platformの公式ガイドには、Kimi Code、Claude Code、OpenCode、Codexのほか、OpenClawとHermes Agentが載っています。コードを書く用途なら、まずKimi Code、Claude Code、OpenCodeから選ぶのが分かりやすいです。

Kimi Code

Kimi CodeはMoonshot AI自身が提供する公式エージェントです。/loginからサブスクとOpen PlatformのAPIキーを選べるので、どちらの支払い方でも使えます。CLIの/modelからk3へ切り替えます。

公式資料ではK3のthinking effortはlow、high、maxに対応していますが、今回使ったKimi Code 0.27.0の選択画面にはmaxだけが表示されました。そのため、検証もmaxで実行しています。

Claude CodeやOpenCodeでも使える

Claude CodeとOpenCodeにも公式の接続手順があります。ただし、二つのAPIキーで使える範囲は同じではありません。サブスクのAPIキーで使えるツールは、公式一覧ではKimi Code CLI、Claude Code、Roo Codeの三つです。このうちRoo Codeは2026年5月15日に提供を終了しているため、実際に選べるのはKimi Code CLIとClaude Codeの二つです。OpenCodeの接続手順はOpen Platform側のガイドにだけあり、従量課金のAPIキーで接続します。一覧にないツールへサブスクのキーを流用すると、不正利用とみなされて利用を制限される場合があると明記されています。すでにどちらかを普段使っているなら、キーの区別にだけ気をつければ、操作を変えずにモデルだけK3へ差し替えられます。

Codexは変換プロキシを挟む

Codexにも公式ガイドがあります。こちらもOpen Platform側だけにあり、サブスクの対応ツール一覧には載っていません。さらに、そのままAPIへ接続する構成でもありません。Codexが使うResponses APIと、Kimiが提供するChat Completions APIの形式が異なるため、CC Switchというサードパーティー製のオープンソースプロキシをローカルで動かして変換します。利用中はCC Switchを起動したままにする必要があり、APIキーとCodexの送受信もこのプロキシを通ります。

送ったコードは保存や学習に使われるのか

Kimi Open Platformの公式FAQには、APIへ送った入力と出力をモデルの学習や改善に使わないと書かれています。ただし、ログをまったく保存しないとは書かれていません。どれくらいの期間残すのかも、公開されたFAQからは分かりませんでした。

Kimi Codeサブスクリプションの専用APIに、Open Platformと同じ条件が当てはまるかも確認できませんでした。一般向けのプライバシーポリシーには、サービスの改善に情報を使う場合があると書かれています。したがって、Kimi Codeへ送ったコードが学習に使われないとは、この記事では断言しません。公開前のコードや機密情報を送るなら、保存期間と利用目的をMoonshot AIへ確認する必要があります。

なぜフロントエンド最強と呼ばれているのか

Frontend Code Arenaで1位

Kimi K3はFrontend Code Arenaで1,679点を記録し、Claude Fable 5の1,631点を上回って1位になったとArena.aiが発表しました。

Arena.aiの説明によると、モデルはファイルの作成、編集、読み取りを繰り返してWebアプリを作ります。投票する利用者にはソースコードも表示され、機能、使いやすさ、指示どおりにできているか、デザインが判断材料になります。それでも画面を触って選ぶ以上、見た目の華やかさが投票を左右することも考えられます。

そこで、画面の印象ではなく、既存のコードを正しく直せるかを調べるためにReactBenchを使いました。

ReactBench

ReactBenchは、React DoctorやReact Scanを開発するMillion Softwareが公開したコーディングエージェント向けベンチマークです。公開されているReactプロジェクトの実際の変更をもとに、51の課題が用意されています。

ReactBenchは新しいアプリを一から作るのではなく、既存のオープンソースを読み、指定された問題を直します。隠されたテストで動作を確かめ、React DoctorでReactコードに問題を残していないかも調べます。

ReactBenchのリーダーボード(2026/07/18)

今回使った修正課題では、指定された問題を残すか、変更によって新しい問題を増やすと不合格になります。

API料金はFable 5の約3分の1

K3のAPI料金は、100万トークンあたり入力$3、出力$15です。Fable 5は入力$10、出力$50なので、K3は入力、出力ともに30%の料金です。これはSonnet 5の通常料金と同じです。Opus 4.8と比べると入力、出力ともに4割安く、GPT-5.6 Solと比べると入力は4割、出力は5割安くなります。Fable級に届かなくても、Opus 4.8やGPT-5.6 Solと同じくらいの仕事ができるなら、料金に対する性能はかなり高いことになります。

モデル 入力 キャッシュから読む入力 出力
Kimi K3 $3 $0.30 $15
Claude Fable 5 $10 $1 $50
Claude Sonnet 5 $2※ $0.20※ $10※
Claude Opus 4.8 $5 $0.50 $25
GPT-5.6 Sol $5 $0.50 $30

100万トークンあたりの料金です。※Sonnet 5は2026年8月31日まで入力$2、出力$10で提供され、その後はK3と同じ入力$3、出力$15になります。つまり、現在のSonnet 5はK3より安く、通常料金へ戻ると同額です。料金表だけでは一つの修正にいくらかかるか分からないため、この記事ではReactBenchを1回実行した料金も比べます。

筆者は約$5のクレジットから始め、疎通確認や実行環境の調整を含めて数時間検証しました。終わった時点の残高は約$2で、使ったのは約$3です。APIは時間ではなくトークン量に応じた従量課金なので、同じ数時間でも依頼する作業や試行回数によって料金は変わります。

まずOpus 4.8と比べる

Fable 5はK3の3倍以上の料金なので、すべての課題で比べるには高すぎます。そこで、まずFable 5の半額で使えるOpus 4.8を比較相手にしました。ゲームでいえば、四天王を倒してからラスボスへ進む順番です。Fable 5には、最後の追加2課題だけ登場してもらいます。

1課題だけ実行する

ReactBenchは評価フレームワークのHarborで実行します。エージェント、Docker環境、課題、採点結果を共通形式で扱えるため、モデルを差し替えて比較したり、自分の開発課題から小さなベンチマークを作ったりする際にも便利です。

ReactBench全51タスクを回す必要はありません。必要なのはDockerとuvで、公式リポジトリを取得したら、まず組み込みの正解実装で環境が動くことを確認します。

git clone https://github.com/millionco/reactbench
cd reactbench
uv sync
uv run harbor run -p tasks/hello-react -a oracle

reward 1を確認したら、tasks/から自分の開発に近い課題を1件選びます。Harborでは-pへ課題ディレクトリを指定すれば、1タスク・1試行だけを実行できます。

uv run harbor run \
  -p tasks/hacker0x01-react-datepicker-calendar \
  --agent kimi-cli \
  -m moonshot/kimi-k3 \
  --ae MOONSHOT_API_KEY=$MOONSHOT_API_KEY

APIキーはコマンドへ直接書かず、事前に環境変数へ設定します。--aeはその環境変数をエージェント用コンテナへ渡す指定です。HarborとKimi Codeは更新が速いため、実行前にuv run harbor run --helpでkimi-cliとモデル指定が現在のバージョンで利用できるか確認したいところです。結果はjobs/<timestamp>/へ保存され、verifier/reward.jsonで合否、verifier/model.patchで実際の変更を確認できます。ReactBench公式の手順とタスク一覧はGitHubリポジトリにあります。

今回は4課題を選び、K3とOpusを各課題で1回ずつ実行しました。追加した2課題ではFable 5も試しています。料金を比較する中心の2課題では、K3の利用量または実行前後の残高差から1回あたり約$0.47〜$0.52と求めました。

ReactBenchのhacker0x01-react-datepicker-calendarを、Kimi K3で1回実行しました。

エージェント／モデル コスト Tests React Doctor 判定
Kimi Code／Kimi K3 $0.52 合格 不合格 不合格
Claude Code／Claude Opus 4.8 $3.39※ 合格 不合格 不合格

※ Kimi K3はAPI残高の減少額から算出した実測値です。Claude Opus 4.8はHarborによるAPI利用時の推定額です。両モデルで同じ課題を1回実行しました。

GPT-5.6 Solも参考に試しましたが、結果はOpus 4.8と同程度だったため、比較対象をOpus 4.8に絞りました。

この課題では、K3もOpus 4.8もテストには通りましたが、React Doctorが示した問題を直せませんでした。この1件では、料金以外の差はつきませんでした。

Datepicker課題でK3とOpusが不合格だった理由

採点対象は、配列インデックスから作られたReactのキーでした。

const monthKey = `month-${i}`;

<div key={monthKey}>

正解は、年月をキーにする修正でした。表示位置を表す配列インデックスは、月が入れ替わると同じ要素を指し続けられません。

const monthKey =
  `month-${monthDate.getFullYear()}-${monthDate.getMonth()}`;

両モデルが外した理由は異なります。

  • Kimi K3：問題を認識したが、「固定長で安定している」と判断して意図的に残した
  • Claude Opus 4.8：同じJSXを編集したが、キーではなくインラインrefを修正した

ReactBenchの課題文は「Reactの問題をレビューして修正せよ」という一般的な指示でした。採点用React Doctorはエージェントから隠されているため、別の妥当な問題を修正して全テストに通っても、対象の問題を直さなければ不合格になります。

Opusが成功した課題をKimi K3でも試す

失敗例だけでは相対性能を判断しにくいため、ReactBenchの実タスクcommercelayer-commercelayer-react-components-741を追加検証しました。これは、persistKeyが変わってもHostedCartのiframe URLが以前の注文に固定される問題を直す課題です。

まずClaude Code／Claude Opus 4.8をmaxで1回実行し、成功する課題であることを確認しました。その後、同じベースコミットと課題文をKimi Code 0.27.0／Kimi K3 maxへ与え、生成された製品コードのpatchを同じ隠しテストとReact Doctorで採点しました。

エージェント／モデル コスト Tests React Doctor 判定
Claude Code／Claude Opus 4.8 max $3.1227※1 合格 合格 合格
Kimi Code 0.27.0／Kimi K3 max 約$0.4698※2 合格 不合格（問題が2件増加） 不合格

※1 Harborが算出したAPI利用時の推定額。サブスクリプション料金そのものではない。
※2 K3の利用トークンを公開単価で換算した金額。

K3はpersistKey変更時にsrcをリセットし、現在のキーに保存されたorder IDを優先する修正を行いました。隠し挙動テストには通っており、機能バグの理解と修正には成功しています。

K3が追加したのは、次の処理です。

useEffect(() => {
  setSrc(undefined)
}, [persistKey])

persistKeyが変わるたびにURLを消せば、次のeffectで新しいURLを計算できます。しかし、effect内で同期的にstateを変更するため、React Doctorはset-state-in-effectとして検出しました。また、このコンポーネントにはHookより前に条件付きの早期returnがあります。その後へ新しいHookを置いたため、rules-of-hooksの指摘も1件増えました。機能は直りましたが、K3の変更によって問題が2件増えたため、不合格になりました。

Opusは新しいeffectを増やさず、現在のsrcがどのorder IDから計算されたかをuseRefで記録しました。

const cartOrderIdRef = useRef<string | null>(null)

if (
  targetOrderId != null &&
  targetOrderId !== cartOrderIdRef.current &&
  accessToken
) {
  computeSrc(targetOrderId)
}

対象のorder IDが変わったときだけ既存のeffect内でURLを計算し直しています。機能テストに通り、新しいReact Doctorの指摘も増えなかったため、Opusは合格しました。

ローカル再現には条件差もあります。Harbor 0.18はmacOSのDockerでno-networkを強制できなかったため、一時タスクではネットワーク制約を解除しました。隠しテストとOracleは別コンテナのままですが、公式の完全なclean-room実行ではありません。K3は検証中に不足していたBiomeをnpxで取得しようとしましたが、Web検索やReactBenchの解答取得は行っていません。採点にはK3が変更したHostedCart.tsxだけを使用しました。

さらに2課題を3モデルで試した

結果を見て次に実行するモデルを変えないよう、追加する2課題を先に決め、K3、Opus 4.8、Fable 5をそれぞれ1回ずつ実行しました。

課題 Kimi K3 Opus 4.8 Fable 5
Embeddable Tests合格／React Doctor不合格 Tests合格／React Doctor不合格 Tests不合格／React Doctor不合格
Internxt Tests合格／React Doctor不合格 Tests合格／React Doctor不合格 Tests合格／React Doctor不合格

Embeddableでは、空配列のデフォルト値とeffectの依存関係が採点対象でした。K3とOpusは両方を残し、Fableは依存関係だけを直しましたが、機能テストに失敗しました。Internxtでは、3モデルともeffectの依存関係を直せませんでした。この2課題ではFableも合格できず、Frontend Code Arenaの順位が既存のReactコードの修正へそのまま移る結果にはなりませんでした。

Kimi K3で気になった点

ESLintを早く諦めた

Kimi Codeはeslint-plugin-reactが見つからない状態を「環境の既存問題」と判断し、ESLintを断念しました。一方、Claude Codeは不足していた依存パッケージを入れ、ESLintを実行しました。

環境のせいにして検査を諦めるのは、エージェントベンチマークあるあるです。モデルやエージェントを評価していると、筆者も何度も目にします。今回は、問題が起きたあとも検査を続けたかどうかで差がつきました。

別の問題は発見した

Kimi K3はshowTimeSelectを後から有効にした場合の状態同期問題を見つけ、回帰テストを追加しました。全テストは通過しています。ただし、これはReactBenchの採点対象ではありませんでした。

ほかのReactベンチマーク

別のReact向けベンチマークには、uhyo氏のReact Profession Benchがあります。13個の小さなアプリを実装させ、別のLLMが状態の持ち方、effect、コンポーネント設計、TypeScript、性能、アクセシビリティの6項目を評価します。ReactBenchが実在するコードから指定された問題を見つけて直せるかを見るのに対し、こちらはSuspenseやuseSyncExternalStoreを選ぶといった設計判断を見ます。同じReactのベンチマークでも、評価している力は異なります。

筆者は大規模なTypeScript製アプリを対象にしたts-bench v2も開発しています。ただし、リポジトリが大きくても、1課題で直す範囲まで大きいとは限りません。ReactBenchとの違いは課題の長さより、React Doctorを使ってReact固有の問題を調べる点にあります。

まとめ

Kimi K3は4課題すべてで機能テストに通りましたが、React Doctorではすべて不合格でした。対象の問題を直せなかった課題に加え、CommerceLayerの課題では修正によって問題を2件増やしています。Opus 4.8だけが1課題で合格し、追加した2課題ではFable 5も合格できませんでした。料金を記録できた2課題では、K3は1回約$0.47〜$0.52で、Opus 4.8の約6分の1で実行できました。

ReactBenchには全部で51課題あり、この記事で確かめたのは4課題だけです。自分の開発に近い課題でどうなるかは、紹介した手順でぜひ確認してみてください。

Share
laiso

laiso