K3 vs Opus 5：2026年はどちらのモデルを選ぶべきか

繰り返し使う巨大なプロンプトを扱い、キャッシュヒットが見込めるならK3が有力です。一方、組み込みのthinking制御を活用したいエージェントにはClaude Opus 5が向いています。本記事では、公開されている制限値と統合時の挙動を比較します。同一プロンプトによるベンチマークなしに、品質面でどちらが上かは断定しません。

結論：用途ごとに選ぶ

100万トークンのコンテキストウィンドウと、キャッシュ状況で変わる入力料金を重視するならKimi K3です。最大コンテキスト長よりも、デフォルトのthinkingとeffort制御を優先するチームにはClaude Opus 5が適しています。

料金とコンテキスト長がコスト構造を左右する

2026年8月7日に確認したKimi K3の公式料金ページでは、入力100万トークンあたりの料金はキャッシュヒット時が¥2、キャッシュなしが¥20、出力は¥100です。同ページには、コンテキストウィンドウとして1,048,576トークンも記載されています。アプリケーション側で実際にキャッシュヒットを得られるなら、この組み合わせは長大なプロンプトを繰り返すワークロードに有利です。

2026年8月7日に確認したClaude Opus 5の公式モデルドキュメントには、標準API料金として入力100万トークンあたり$5、出力100万トークンあたり$25、コンテキストウィンドウは200kと記載されています。

通貨ごとのトークン単価で計算すると、入力180k・出力8kのリクエストは、K3ではキャッシュヒット時に¥1.16、ヒットしない場合は¥4.40です。Opus 5の標準料金では$1.10となります。このリクエストはOpus 5のコンテキストウィンドウ内に収まりますが、実際の請求額は契約上の為替、キャッシュ適用条件、課金対象となる出力に左右されます。

統合で差が出るのはツール呼び出しとthinking

KimiのK3 APIドキュメントでは、tool calling、tool choice、動的なツール読み込み、JSON mode、structured outputが明示的に扱われています。スキーマに厳密に従うアプリケーションや、ツール振り分けを行うアプリケーションでは、こうした制御が重要になります。

Claude Opus 5ではthinkingがデフォルトで有効です。各ターンでどの程度考えるかはモデルが判断し、深さはeffortパラメータで制御します。Anthropicは破壊的変更となる制約を文書化しています。高いeffortではthinkingを無効化できず、thinkingを無効化した場合、モデルがtool_useブロックを出力せず、可視テキスト内にツール呼び出しを書いてしまうことがあります。

ツール呼び出しを構造的に安定させる必要があるなら、Opus 5ではthinkingを有効にしておくべきです。明示的なツール制御とスキーマ指向の出力が最優先なら、K3を選ぶのがよいでしょう。

代表的なワークロード別の選び方

長文ドキュメントとナレッジワーク

対象のソース群がOpus 5で文書化されている200kのコンテキスト上限を超える場合は、K3が適しています。

コーパスが200k以内に収まるなら、コンテキスト長そのものよりも、Opus 5のthinkingがデフォルトで有効な点が重要な違いになります。

コーディングと長期実行エージェント

リポジトリ全体を1つのプロンプトに収めることより、文書化されたデフォルトthinkingとeffort制御を重視するなら、新しいエージェントにはOpus 5を選びます。

大きく、かつキャッシュ可能なエージェントコンテキストにはK3が候補になります。ただし、本番に近いタスクでツールプロトコルを検証してください。

コストを重視するAPIワークロード

キャッシュ可能で入力量の多いワークロードではK3の料金を検証し、キャッシュあり・なしで入力料金に大きな差があるため、キャッシュ状態も記録します。

Opus 5はthinkingがデフォルトで有効なため、代表的なワークロードで課金対象の出力を測定してください。

導入を決める前に、代表的なプロンプトを両APIで実行し、キャッシュヒット率、ツール呼び出しの妥当性、レイテンシ、課金対象の出力を記録しましょう。