Kimi K3 Context Cachingは本当に得か？2026年費用試算

毎回ほぼ同じシステムプロンプトを送っているのに、Kimi K3 APIの入力料金が下がりません。

今週は、まずログから「繰り返し送っている初期コンテキスト」と「実際にキャッシュ扱いされた入力」を分けて集計してください。Kimi K3 Context Cachingは、安定した初期コンテキストを複数リクエストで再利用できる場合にだけ、入力コストを大きく下げる可能性があります。前置きの頻繁な変更、再利用率の低い処理、失敗リトライが多いAgentでは、自動的に安くなるわけではありません。

この記事を読むべき人

毎回、大型のシステムプロンプトやツール定義を送信するコードAgent開発者向けです。自動キャッシュが実際に命中しているかを確認したい人に適しています。

固定された文書集やコード規約を使うチームにも役立ちます。ユーザー数を増やすAI SaaSの責任者は、モデル料金、タスク再試行、常時稼働する実行環境を分けて計算してください。

最終的な判断は、キャッシュ命中率ではなく、成功したタスク1件あたりの総コストで行います。

最終更新：2026年8月3日。キャッシュの自動適用、請求項目、エラー時の扱いは、執筆日に確認した公式API料金ページ、公式APIトラブルシューティング、公式請求・決済案内を基準にしています。料金や請求項目が変更された場合は再計算が必要です。 (kimi.com)

まず仕組みを確認する

Kimi APIのContext Cachingは、利用者がキャッシュIDやTTLを発行して管理する方式ではありません。公式案内では、繰り返される初期コンテキストをAPI側が自動的にキャッシュしようとし、追加のキャッシュ用パラメーターも不要とされています。 (kimi.com)

ここでいう初期コンテキストは、一般にシステムプロンプト、ツール定義、固定された長文資料などです。ただし、「同じ文書を含めた」だけで命中が保証されるわけではありません。先頭からの並び、区切り、前置きの文言、バージョン情報などが変わると、再利用できる共通部分が小さくなる可能性があります。

Kimi K3 APIのログでは、少なくとも次の項目を分けて保存してください。

リクエストごとの入力Token
キャッシュ扱いの入力Token
通常料金の入力Token
出力Token
request_id
HTTPステータス
再試行回数
最終的なタスク成功・失敗

公式トラブルシューティングでも、クライアント側に結果が表示されなくても、サーバー側で処理が完了し請求記録が残る場合があると説明されています。レスポンスのusage、request_id、管理画面の請求記録を突き合わせることが重要です。 (kimi.com)

固定プロンプトを安定させる

最もキャッシュ効果を確認しやすいのは、複数のリクエストで同じ初期部分を使うコードAgentです。

たとえば、次のような順番にします。

変更しない役割定義
固定された出力形式
ツール名と引数の定義
文書やコード規約の共通部分
今回のユーザー依頼
今回のツール結果

ユーザーの質問やツール結果を先頭に置くと、リクエストごとに初期部分が変わりやすくなります。固定情報を前方に寄せ、変動する情報を後方にまとめる設計のほうが、共通プレフィックスを保ちやすくなります。

ただし、固定化しすぎると別の問題が出ます。古いツール仕様、不要な全文資料、現在のユーザー権限と合わない指示を残すと、入力料金以前に回答品質や安全性が落ちます。キャッシュのために更新を止めるのではなく、更新単位を明確にしてください。

手動でキャッシュを有効にする必要はありますか

通常、専用のキャッシュID、TTL、追加リクエストパラメーターを手動で設定する必要はありません。公式説明の範囲では、APIが繰り返される初期コンテキストを自動判定します。 (kimi.com)

必要なのは、キャッシュ機能をオンにする作業ではなく、命中しやすいメッセージ構造を作り、請求結果を検証する作業です。SDKの設定だけを変えて、ログを見ないまま節約効果を断定するのは避けてください。

どの入力Tokenがキャッシュ対象になりますか

候補になるのは、複数リクエストで同じ位置から始まる初期コンテキストです。システムプロンプト、ツール定義、固定ドキュメントは候補になります。一方、毎回変わる質問、現在時刻、ユーザー固有の権限、直前のツール結果は、共通部分として扱いにくい情報です。

「入力Token全体」と「キャッシュ命中入力Token」は別の数値です。請求画面やレスポンスに分かれた使用量がある場合は、必ずそのフィールド単位で集計してください。

固定資料と長文ドキュメントを分けて扱う

知識ベースの質問応答では、資料が同じでも質問が毎回違います。この場合、資料部分だけは共通化できますが、次の条件で効果が変わります。

文書のチャンク順序が毎回同じか
文書の版数や更新日時を先頭に挿入していないか
検索結果の件数や並びが毎回変わっていないか
テナントごとの権限情報を共通部分に混ぜていないか
参考資料の前に動的な説明文を追加していないか

特に、検索結果を関連度順に並べるRAGでは、質問ごとに資料の並びが変わります。文書自体が同じでも、先頭から一致するコンテキストが短くなれば、キャッシュの効果は限定的です。

対策は、全文を毎回固定資料として送ることではありません。変更頻度の低い規約、製品仕様、APIスキーマを共通レイヤーに分け、質問に応じた検索結果は後段に置きます。資料の更新時は、古い版と新しい版を同じキャッシュ前提で扱わず、バージョンを切り替えた日から別の入力系列として集計してください。

長い会話は必ずしも安くならない

長時間のAgentでは、会話が伸びるほど入力Tokenも増えます。初期のシステムプロンプトが再利用されても、その後に追加されたユーザーメッセージ、ツール結果、エラー履歴まで全て安くなるとは限りません。

費用は次のように分解します。

総費用
= キャッシュ命中入力Token × キャッシュ命中単価
+ 未命中入力Token × 通常入力単価
+ 出力Token × 出力単価
+ 再試行リクエストの費用

実際の単価は、必ず執筆時点の公式料金表から取得してください。Kimi APIは入力Tokenと出力Tokenを別々に課金する方式であり、入力だけを見てタスク費用を判断できません。 (kimi.com)

また、キャッシュ命中率とタスク成功率は別の指標です。初期プロンプトが毎回命中していても、ツール選択を誤って再実行が増えれば、成功1件あたりのコストは上がります。

シナリオ別に選択肢を比較する

下表では、料金の固定値ではなく、運用上の判断軸を比較します。実際の金額は、あなたの請求記録にある入力・出力単価と使用量を入れてください。

運用シナリオ	共通化しやすい部分	主なコスト増要因	先に行う対策	判断
コードAgent	システム指示、ツール定義、コード規約	ツールループ、長い差分、再試行	固定指示を先頭、結果を後段へ配置	ログで命中を確認できれば最適化
固定文書のQA	規約、製品資料、用語集	検索結果の順序変更、版更新	共通資料と検索結果を分離	文書が安定するほど検証価値が高い
長時間の会話	初期の役割定義	毎ターンの履歴、ツール結果	要約と履歴削減を導入	長さだけを理由に導入しない
多租户SaaS	全テナント共通の基礎指示	権限、個別資料、個人設定	共有前置きと専用領域を分離	機密情報の混在を避けられる場合のみ
失敗が多いAgent	一部の初期プロンプト	無限リトライ、重複ツール呼び出し	上限、タイムアウト、停止条件を設定	先に再試行率を下げる

多租户構成では、全顧客に共通するルールだけを共有部分に置き、ユーザー名、権限、契約情報、個別資料はテナント単位で隔離してください。キャッシュによる費用削減より、別テナントの情報が同じ文脈に混ざらない設計を優先します。

ログから削減効果を試算する

実装前に、次の変数を1つの集計表へまとめます。

R：総リクエスト数
P：1リクエストあたりの入力Token
C：キャッシュ命中入力Token
U：通常料金の入力Token
O：出力Token
F：失敗・再試行を含む追加リクエスト数
S：成功タスク数

まず、入力側の再利用比率を次で確認します。

再利用可能比率 = C ÷ (C + U)

次に、成功タスク単価を計算します。

成功タスク単価
= (入力費用 + 出力費用 + 再試行費用) ÷ S

ここで重要なのは、Cを設計上の期待値ではなく、請求に反映されたキャッシュ入力Tokenとして扱うことです。キャッシュ命中をレスポンスの使用量で確認できない場合は、推測値として分けて保存し、確定値と混ぜないでください。

提示文を変更した後もキャッシュは有効ですか

変更後も一部の共通前置きが残る可能性はありますが、以前と同じ命中状態が続くとは限りません。役割文、ツール定義、文書の並び、区切り文字、版数表示を変更したら、変更前後でC、U、Fを比較してください。

改善を急ぐ場合は、固定部分にリリース番号や現在時刻を毎回付けない構造へ変えます。ただし、実際に変えたことで命中率が上がったかは、同じ種類のリクエストを一定期間比較して判断してください。

長いコンテキストなら必ず得になりますか

なりません。長い共通前置きが多数のリクエストで再利用されるなら、入力コストを下げる余地があります。しかし、1回限りの長文処理、質問ごとに大きく変わる検索結果、失敗リトライが多い処理では、出力費用や再試行費用が支配的になる場合があります。

長文を送る前に、固定資料、今回必要な抜粋、履歴要約を分けてください。固定資料を増やすだけでは、成功タスク単価が下がったことになりません。

5段階で検証する

対象リクエストを分類します。
コードAgent、文書QA、長時間会話、多租户処理、ツールループを分けます。全体平均だけでは、どのシナリオで費用が動いたか分かりません。
メッセージ構造を保存します。
機密情報を除外したうえで、先頭の固定部分、動的な質問、ツール結果、出力を識別できる形にします。
使用量と請求記録を照合します。
レスポンスのusage、request_id、管理画面の記録を突き合わせます。401、404、429、500系のエラーは、通常の成功リクエストと別集計にしてください。公式案内では、429で中断されたリクエストは課金されないと説明されていますが、クライアント側のタイムアウトや再試行まで同じ扱いとは限りません。 (kimi.com)
再試行とツール呼び出しを数えます。
1タスクが何回APIを呼んだかを確認します。同じ引数のツール呼び出しが続いていないか、タイムアウト後にサーバー処理が完了していないかも見ます。
成功タスク単価で判断します。
キャッシュ命中入力が増えても、成功率が下がったり再試行が増えたりするなら、提示文の最適化だけでは不十分です。上限回数、停止条件、要約処理、タスク分割を組み合わせます。

ログ集計や実行ノードの確認を行う場合は、まずVPSSparkのサービス概要で運用形態を確認してください。継続稼働するAgentでは、API費用とは別に、キュー、監視、ログ保存、障害対応の時間も発生します。

維持・最適化・構成変更を選ぶ条件

次の条件なら、提示文と入力構造の最適化を先に行います。

同じ初期コンテキストを多くのリクエストで使う
キャッシュ入力Tokenを請求記録で確認できる
再試行が少なく、成功タスク単価も下がっている
テナント間の情報分離を維持できる

次の条件なら、現状維持が安全です。

リクエストごとに前置きが大きく変わる
長文資料が一度しか使われない
キャッシュ命中はあるが、出力やツールループが費用の中心
請求フィールドを確認できていない

次の条件なら、モデル切り替えや実行構成の見直しを検討します。

入力費用より再試行と常時稼働環境の費用が大きい
1タスクの処理が長く、失敗時に全体をやり直している
テナントごとの個別コンテキストが多く、共通化できる範囲が小さい
監視、キュー制御、タイムアウトを追加しないと品質を維持できない

Kimi K3 Context Cachingは、安定した共通前置きを持つAPI運用では有力な最適化手段です。ただし、キャッシュ命中率だけを高める設計では不十分です。入力、出力、再試行、成功件数を同じ表で管理して、初めてTokenコストの削減を判断できます。

現在の構成が自前サーバーや一般的なクラウド実行環境の場合、API単価だけでなく、常時稼働料金、キュー管理、監視設定、障害時の復旧作業が隠れた負担になります。固定プロンプトを整えても、Agentを止めずに動かす環境の管理時間まで増えているなら、節約効果は相殺されます。

一時的な検証環境や、短期間だけ増やすAgent実行ノードが必要なら、VPSSparkの日本向けレンタル環境を候補に入れて、API費用と実行環境費用を分けて比較してください。長期の安定した高負荷処理や物理デバイス接続が必要な場合は、自社設備や専用構成のほうが適することもあります。まずはKimi K3 APIの実請求を確認し、そのうえでノード、キュー、保守時間を含む総額を見て判断するのが安全です。

次に行うべき作業は、料金表を眺めることではありません。直近の成功タスクを抽出し、キャッシュ命中入力、通常入力、出力、再試行、実行環境の各コストを分離して記録することです。