TL;DR: さくらのAI Engineの無料枠(3,000リクエスト)を、コーディングエージェント(opencode)経由の利用で使い切り、超過分の実課金が発生した。原因を調べる過程で、opencode組み込みの使用量集計コマンドを確認したところ、Sakura(Kimi-K2.7-Code)経由の呼び出しだけプロンプトキャッシュが一度もヒットしていないことが分かった。同じ期間に使った別ベンダーの呼び出しではキャッシュ読み込みが記録されていたのに対し、Sakura側の呼び出しは集計上、常にキャッシュ読み込み・書き込みともにゼロだった。無料枠の間はコストとして顕在化しなかったため、超過課金が発生するまで気づけなかった。
結論: 無料だからこそ、気づけなかった非効率があった
無料枠を使い倒すつもりで、コーディングエージェント経由のさくらAI利用を続けていたところ、3,000リクエストの無料枠を超え、超過分の実課金が発生した。締切当日にこの請求を見て、「思ったより高い」と感じたのがきっかけで原因を調べ始めた。
たどり着いた結論は、キャッシュが一度も効いていなかったこと。無料枠の間はこの非効率が金額として表面化しなかったため、気づく機会自体がなかった。
経緯: 自作の使用量集計ツールと、公式コンソールの数字が合わなかった
以前の記事で、自作の使用量集計ツール(呼び出しのたびにトークン数と概算コストをローカルのDBへ記録する仕組み)を紹介した。今回、超過課金が発生した後、公式コンソールの実際の請求内容とローカル集計を突き合わせてみたところ、数字が大きく食い違った。
具体的には、公式コンソールでは該当モデル(Kimi-K2.7-Code)の入力トークンが数千万単位だったのに対し、ローカル集計はその一部しか捉えていなかった。この差の少なくとも一部は、コーディングエージェント経由の呼び出しが、そもそもローカルの集計対象に入っていなかったことによるものだった——この計測ツール自体、コーディングエージェントとは別の呼び出し経路(討議・脚本生成用のスクリプト)を対象に作ったものだったため、対象外の経路があることは把握していたが、そちらの実際の消費量までは見ていなかった。
発見: コーディングエージェント側の使用量集計コマンドで、キャッシュの内訳が見えた
そこで、コーディングエージェント自体が持っている使用量集計コマンドを実行してみた。全期間・モデル別の内訳を出せる機能があり、そこにCache ReadとCache Writeの列があった。
結果、Sakura(Kimi-K2.7-Code)経由の呼び出しは、全期間を通じて集計上のCache Read・Cache Writeともにゼロだった。一方、同じ期間・同じコーディングエージェントで使った別ベンダー(ai&経由のKimi系モデル)は、Cache Readの数値が実際に記録されていた。この集計だけから「Sakura側でキャッシュが物理的に一度も機能しなかった」とまでは断定できないが、少なくとも同じツールの同じ集計軸で見て、ベンダー間に明確な差があったことは確かだ。
入力対出力のトークン比率で見ても違いは明確だった。Sakura経由は入力が出力の100倍前後というかなり偏った比率になっていたのに対し、討議・脚本生成用のスクリプト経由(こちらは元々の集計対象で、キャッシュを使わない設計)の入力対出力比は数倍程度だった。コーディングエージェントは1ターンごとに会話履歴やファイル内容をまるごと再送する構造のため、プロンプトキャッシュが効いていれば「変わっていない部分」を安く再利用できることが多い、という一般的な理解がある。今回観測された極端な入力偏重は、その再利用が働いていなかった場合に生じうる形と整合している。
詰まった点: 原因の切り分けは、まだできていない
キャッシュが効いていなかったという事実は分かったが、原因がさくらのAI Engine自体の仕様(プロンプトキャッシュ非対応)にあるのか、それともコーディングエージェント側のSakura向け実装がキャッシュ機構を使っていないだけなのかは、この時点では切り分けられていない。締切を優先し、この記事では「効いていなかった事実」までを報告し、原因の特定は次の課題として持ち越すことにした。
続報: 原因が判明した
その後、さらに調査を進めた。
まず、opencodeのローカル記録を全モデル分確認したところ、Sakura経由で使った3モデル(Kimi-K2.7-Code・Kimi-K2.6・gpt-oss-120b)すべてで、Cache Read・Cache Writeが常にゼロだった。特定モデルに限った現象ではなく、Sakura全体で共通の挙動だとわかった。
次に、さくらの公式APIドキュメントを確認した。APIリファレンスにはキャッシュ制御のためのパラメータが見当たらず、利用ガイドのレスポンス例でもキャッシュ関連のフィールド(prompt_tokens_details)がnullになっていた。料金ページにも、キャッシュ利用時の単価は掲載されていない。いずれも本記事執筆時点(2026年8月)で確認した内容であり、ドキュメントは今後更新される可能性がある。
一方、同じopencodeで使った別サービス(ai&経由のKimi系モデル)では、Cache Readの数値が実際に記録されていた。opencode自体はキャッシュ情報を検知・記録できることになる。
これらを踏まえると、opencode側の設定の問題ではなく、公式ドキュメント上、Sakura側のAPIレスポンスにキャッシュ関連の情報が含まれていることを確認できなかった、というのが現時点で言える範囲だ。
会話履歴やファイル内容を毎ターン再送するタイプのコーディングエージェント用途では、キャッシュの有無がコスト構造に大きく影響する。同種のサービスを選ぶ際、キャッシュ対応の有無を事前に確認しておくと、想定外のコスト差を避けやすくなりそうだ。
何が変わったか
| 項目 | 無料枠の間 | 超過課金後に判明した実態 |
|---|---|---|
| キャッシュの状態 | 意識していなかった(コストに出ないため) | Sakura経由の呼び出しはCache Read/Writeともにゼロ(3モデル共通) |
| 気づくきっかけ | なし(無料なので問題として顕在化しない) | 超過分の実課金額を見て初めて疑問を持った |
| 入力対出力比 | 把握していなかった | Sakura経由は100倍前後、他経路は数倍程度と大きな差 |
| 原因の特定 | — | Sakura側のAPIレスポンスにキャッシュ関連情報が含まれていないことが直接の要因 |
まとめ
無料枠は「コストを気にせず使い倒せる」という利点がある一方、コストという形での異常検知が働かない期間でもある。今回のキャッシュ関連の集計値の異常は、もし最初から従量課金だったら、もっと早い段階で気づく可能性があったのではないかと感じている。無料枠を使い切る過程そのものが、普段は見えない非効率を可視化する機会にもなった。
コーディングエージェント経由で使う機会がこれからも増えていきそうなので、今後キャッシュ対応が加わると、より安心して使い倒せるサービスになりそうだと感じている。