Kimi K3の実務利用：実際に使ってみた体験とClaude Codeとの比較

著者の実験はどうなったか#

Kimi K3は2026年7月16日に公開された。パラメーター数は2.8兆、コンテキストウィンドウは100万トークンで、オープンウェイトを採用し、ブラインドのフロントエンド比較で首位に立った。アーキテクチャ、ベンチマーク、価格の詳細はKimi K3とClaude Codeの完全レビューにまとめたので、ここでは繰り返さない。

そのレビューの最後に、こう書いた。リスクは設定に1日費やすこと、見返りは2週目以降に請求額が下がることだ。私は自分のタスクで実験した。

最初の数時間は確かにわくわくする。モデルは意欲的にタスクに取り組み、筋の通ったフロントエンド作業を生成し、大きなファイルにもためらわない。だから私はチャンネルに、うれしい驚きを感じたと投稿した。問題が表面化したのは、長時間のセッション、複数エージェント、編集の反復、そして夜のターミナル作業だった。

結局、私は元に戻した。決断に至った経緯を、誰でも確認できるよう数値と一次情報へのリンクを添えて説明する。

ベンチマークでKimi K3がClaudeを上回るのはなぜ？#

Kimi K3がClaude Fable 5を上回るベンチマークを以下に示す。

llm-statsがベンチマークを集計しており、すべての行でClaude Fable 5と比較している。

数値は実際のものだ。同じ集計に含まれる35件すべてのベンチマークでは、Claude Fable 5が22勝、Kimi K3が12勝、引き分けが1件だ。

さらに興味深いのは、Kimi K3が劣る分野だ。コーディングベンチマークでの差は小さく、4〜5ポイントだ。知識と推論では差が開く。HLEではClaudeがほぼ10ポイント先行する。長いタスクが行き詰まるのは、まさにこの部分だ。まず理解し、その後で初めて書ける。

Moonshotはリリース告知のメインセクションで、次のように述べている。

実際の作業でKimi K3が2倍遅く感じるのはなぜ？#

数値は、Kimi K3とClaude Opus 4.8を比較したベンチマークに基づく。完全な速度計測があるClaudeのバージョンがこれだからだ。

Kimi K3は早く応答を始めるため、短いチャットでは主観的に速く感じる。実作業では別の点が重要になる。応答全体がどれだけゆっくり届くかだ。ここではほぼ半分の速度で、長い応答ではその差が数分に積み重なる。

Kimi Codeは毎秒180〜260トークンをうたっており、私の34.7と比べると説得力のある数字に見える。これは前世代の高速版、K2.7 Code HighSpeedの速度を指している。Kimi K3にはそのようなビルドはなく、独立ベンチマークが測定しているのもKimi K3そのものだ。

7回目のエラーでセッションが止まり、反復呼び出しでトークンを浪費するなら、それはコンテキストエンジニアリングの失敗だ。ここではモデル選択は二次的な問題にすぎない。完全なセットアップは3つの柱に支えられている。AIクローン + セカンドブレイン + コンテキストエンジニアリング。これはAIが幻覚を起こさないために欠かせない3つの柱だ。

推論をオフにできないなら、トークンはどこへ消えるのか？#

努力レベルを下げることはでき、ドキュメントにはlow、high、maximumの3段階が記載されている。ただし、推論を完全にオフにはできない。Kimi K3では推論とその履歴の保存が常に有効だと明記されている。APIを直接呼び出す場合、デフォルトは最大レベルで、多くのラッパープログラムは変更しない。

各ターンで、100万トークンあたり$15の出力トークンが数千個追加される。さらにMoonshotは、推論履歴を含むアシスタントのメッセージ全体を返すよう求めており、それらの出力トークンは次のターンで再び入力トークンになる。

つまり、同じ推論に対して2回支払う。最初にモデルが書いたとき、次にそれをモデルに送り返したときだ。

全体指標では、Kimi K3の出力トークン数は前世代のK2.6より21%少ない。自社の前バージョンと比べれば、モデルは効率的になった。それでも同じタスクではClaudeのほうが少ない。

プロンプト「hi」は86トークンとして課金される。内部では約85トークンの非表示システムプロンプトが使われており、リクエストごとにその分も支払う。

利用量の計算方法や残高の確認先については、Claude ProとMaxで使えるトークン数の別レビューで説明している。計算方法は同じで、価格だけが変わる。

モデルが推論にはまり込むとどうなるか？#

実際にはこう見える。モデルは考え始めるが、思考を発展させず、同じ単語、次に音節の断片という具合に、テキストが延々と繰り返しに陥る。トークンカウンターが回り続ける一方で、タスクは止まる。

7月28日のMoonshot既知の問題に関する報告では、Kimi K3が同じファイルを6回連続で読み、前回の読み込み以降ファイルが変更されていないため「no-op call」として7回拒否された後、何事もなかったかのようにターンを終了したと説明している。Kimi CLIのissue trackerでは、報告者が読み取り、置換、テスト、分析という同種の停止を4種類挙げ、次の一文にまとめている。

Moonshotは原因を明確に述べている。モデルは推論履歴を保持するモードで学習されており、過去の推論をすべて受け取る必要がある。履歴が不完全な状態で届くと、モデルは答えを再構築しようとして同じツール呼び出しを行い、再びループを始める。

サードパーティ製リクエストルーターでの分析の著者も同じ診断を示している。Kimiは推論履歴が不完全なリクエストを拒否するほど厳格だ。外部ラッパーはこの厳格さを把握していないため、履歴を切り詰めてしまう。

Kimi K3でマルチエージェント環境が崩れるのはなぜ？#

Moonshotの公式ドキュメントには、同社のAPIはまだWebFetchをサポートしていないと明記されている。つまり、通常はページを取得するためオンラインに接続するClaude Codeも、Kimi K3ではそれができない。回避策は、内容を手作業で貼り付けるか、サードパーティのツールを接続することだ。

Claude Codeはツールをオンデマンドで読み込み、履歴にtool_reference型のサービスブロックを置く。Kimiはこの型を受け付けず、400を返す。フィールド名も理由も示さず、黙って失敗する。

{"error":{"type":"invalid_request_error","message":"Invalid request Error"},"type":"error"}

比較のため、AnthropicのネイティブAPIで同じエラーがどう見えるかを示す。こちらは少なくともフィールド名と受け付ける型を列挙する。

messages.166.content.0.tool_result.content.0: Input tag 'tool_reference' found
using 'type' does not match any of the expected tags: 'document', 'image',
'search_result', 'text'

この違いは重要だ。最初のメッセージからは原因を診断できない。クライアントにも、その背後にいる人にも、どのブロックが拒否されたのか分からない。報告者たちが問題にしているのはまさにこの点だ。プロバイダー切り替えツールの開発者は、Kimiではツールの遅延読み込みをデフォルトで無効にするか、Moonshot APIをこれらのブロックを受け付けないものとして指定することをすでに提案している。

その結果は、7月17日に立てられ、今も回答がない別の報告に記されている。報告者は1回のセッションでこのエラーに7回遭遇した。最初の6回はセッションが持ちこたえたが、7回目で完全に停止した。その後はプレーンテキストの「continue」と入力しただけでもクラッシュした。報告者は、コンテキスト上限にはまったく近づいていなかったと別途記しているため、「履歴が長すぎた」という説明は成り立たない。

Moonshot APIが受け付けるブロック型と拒否するブロック型を以下にまとめる。

ここでの「互換性」は、リクエスト形式だけを指す。それ以外はすべて異なる。受け付けられるブロック型、履歴に必要な内容、そして利用可能なツールの種類も違う。

Kimi K3では何が引き継がれないのか？#

リリース告知の制限事項のセクションには、次のとおり記されている。

モデルの開発元は、こう言っている。自社のクライアントを使ってほしい。他社のクライアントの振る舞いは保証しない。

同じセクションの2つ目の点では、私がモデルの頑固さだと思っていたことについて、さらに説明している。

私のCLAUDE.mdは反対の習慣に合わせて書かれていた。質問し、計画を示し、確認を待つというものだ。指示は今もそこにあるが、今は気質の異なるモデルがそれを読んでいる。

複数のエージェントで1つのルールファイルを使いたい場合は、Claude Code、Codex、Cursor向けの共通指示ファイルで別途説明している。

Kimi K3の実際の費用はいくらか？#

まず、Kimi K3に有利な価格を示す。

Kimiの価格はコンテキストキャッシュのドキュメントに基づく。右列は2026年7月30日時点のClaude Opus 5の価格だ。

Kimiのキャッシュは自動で、無効化できず、リクエスト冒頭のハッシュによって識別される。システムプロンプトやツール一覧を編集すると、メッセージキャッシュが完全にクリアされる。

通常の作業日にClaude Codeが行うことを見てみよう。

1. タスクの進行に応じて外部ツールを接続したり切断したりする。
2. 必要に応じてツールをオンデマンドで読み込む。
3. 異なるツールセットでサブエージェントを起動する。
4. 指示ファイルをシステムプロンプトに追加する。
5. コンテキストを圧縮するときに履歴を再構築する。

この一覧の各項目によってリクエストの冒頭がリセットされ、キャッシュも消える。入力トークンは100万あたり30セントではなく、再び$3になる。10倍の価格だ。さらに、出力トークン100万あたり$15で推論が続き、同じトークンが次のターンで入力として戻ってくる。そのため、表示価格の低いモデルでも、予想外の請求額になり得る。

OpenCodeの集計データによると、約280,000件の実稼働セッション全体で、Kimi K3の平均セッション費用は$1.86、平均トークン量は3.1 millionだ。この数値は入力トークンの93%がキャッシュに当たることを前提としている。リクエストの冒頭を変えれば、この数値は当てはまらなくなる。

Kimiのプランは$19、$39、$99、$199だ。利用枠は会員全体で共有するプールから割り当てられ、未使用分を繰り越さずに毎週リセットされ、ローリング方式の5時間枠を使う。プランレビューでは、推論が常時有効なKimi K3を4つのターミナルで動かすと、5時間枠はすぐに使い切られると説明している。

$99プランのコーディング利用枠はAnthropicの$200プランに匹敵し、これは私自身の見解とは相容れない。Kimiはトークン単価では安いが、夜の請求額にはもうその安さが見えない。

Kimi K3が客観的に得意なのはどこか？#

1. フロントエンド。 現役の開発者によるブラインド比較で首位。整ったレイアウトを、なかなかのセンスで作る。
2. 処理量。 コンテキストウィンドウは100万トークンで、長いファイルにもひるまない。大規模なリポジトリを分析し、全体像を描くのは得意なタスクだ。
3. 初回応答。 最初のトークンまでの時間はClaudeの半分。短い会話では、その差がはっきりと心地よく感じられる。
4. トークン単価。 Claude Opus 5の価格の約60%。リクエストの冒頭が変わらなければ、大量の反復作業で実際に節約できる。
5. オープンウェイト。 1つのプロバイダーに縛られない。

最後の点には注意点がある。この規模のモデルを自宅で動かすのは現実的ではない。圧縮しても、ウェイトの容量はテラバイト単位になる。ここでのオープン性は、単一プロバイダーに依存しないことを意味する。

一晩でこれらを自分で試す方法#

1. 説明に従ってアクセスを設定する。 3つの環境変数と、階層ごとのモデル置換についてはKimi K3とClaude Codeのレビューで説明した。/statusコマンドで設定を確認する。Kimiはモデル選択メニューに表示されない。エイリアス一覧が組み込み式で、変更する必要はないためだ。
2. 古いキーを削除する。 以前にANTHROPIC_API_KEYを設定していた場合は削除する。ANTHROPIC_AUTH_TOKENと併用すると競合し、理由もなく認証エラーになる。
3. ツールの遅延読み込みをすぐにオフにする。 最初の実行前に行う。最初のセッションが停止してからでは遅い。
4. タスクの途中でモデルを切り替えない。 Kimi K3で始めたら、最後までKimi K3で進める。逆の場合も同じだ。これはMoonshotの直接的な要件で、上で引用した。
5. 自分の実タスクを使う。 昨日取り組んだ、混乱や未完了の作業がそのまま残るものを選ぶ。スネークゲームでは違いが見えない。差は長時間使って初めて現れる。
6. 2つの数値を記録する。 何分かかったか、そしてその夜にいくら使ったか。Claudeで過ごす普段の夜と比べる。
7. 待ち時間は別に記録する。 エージェントが停止したり、同じファイルをループで読んだり、エラーを返したりする時間も、コストの一部だ。

夜の請求額が予想より高ければ、ほとんどの場合はキャッシュが原因だ。その夜にリクエストの冒頭が何回リセットされたか数えてみよう。トークン単価はあまり関係ない。

最終的に残した構成#

チャンネルで一緒にモデルを試した読者も、独自に同じ構成にたどり着いた。Kimi K3にはリポジトリを調べてセカンドオピニオンを出させ、メインの作業は使い慣れたエージェントに任せる。この構成ならラッパーを移行する必要も、すでに動いているものを壊す必要もない。

こう言い換えられる。完結したタスク1つならKimi K3へ。ツールやサブエージェントを使う長い連鎖ならClaude Codeへ。タスク内でツールを切り替える回数が多いほど、Kimi K3のコストは上がり、セッションが壊れる可能性も高まる。

2つのエージェントに役割を割り当て、混同しない方法については、2つのエージェントを使う3つの方法で別途説明している。

ベンチマークが答えるのは「実験室の条件ではどちらが強いか」という問いだ。その夜の請求額と完了した作業の一覧が答えるのは「あなたにとってどちらが強いか」という問いだ。答えが異なるなら、後者を信じよう。マーケティング部門ではなく、自分で計算した結果だからだ。

すべてを見たうえで、私は自分なりに結論を出した。新しいモデルについて何と言われようと、リーダーはやはりリーダーだ。Claude Codeは引き続き私のメインエンジンだ。

完全なバイブコーディング構成：AIクローン + セカンドブレイン + コンテキストエンジニアリング。