【ITニュース解説】PSA: How shady LLM API proxies fake Claude Prompt Caching (and how to audit yours)

大規模言語モデル（LLM）の利用が広がる中で、そのAPI（Application Programming Interface）にかかる費用は、開発者や企業にとって無視できない問題となっている。特に、Anthropicが提供するClaudeのようなLLMを日常的に使う場合、APIの利用料金をいかに効率的に管理するかが重要になる。ここで「プロンプトキャッシング」という仕組みが大きな役割を果たす。これは、一度送信したプロンプト（LLMへの指示文）をシステムが記憶し、後で同じ、あるいは非常に似たプロンプトが送られた際に、以前の処理結果を再利用することで、処理時間とコストを大幅に削減する技術だ。Anthropicの場合、このキャッシュ機能が適切に動作すれば、大規模なコンテキスト（文脈）を持つプロンプトでも、最大90%ものコスト削減が可能になる。具体的には、キャッシュを新たに作成する際には通常の料金の1.25倍がかかるが、一度作成されたキャッシュを読み込む際には、わずか0.1倍の料金で済む。キャッシュを使わない場合は通常の1倍の料金となる。

多くの開発者は、複数のLLMを利用したり、APIの管理を効率化するために、サードパーティ製のAPIプロキシやゲートウェイを利用することがある。これらは、ユーザーとAnthropicのようなLLMプロバイダの間に立つ仲介役だ。しかし、中にはプロンプトキャッシングの機能を正しく提供しなかったり、あるいは意図的にその機能を妨害したりする「悪質な」プロキシが存在する。これらのプロキシは、ユーザーがせっかくコスト削減のためにキャッシュを利用しようとしても、それを無効化してしまう。

よくある悪質なプロキシの罠はいくつかある。一つ目は「素朴なキー・プーリングの罠」と呼ばれるものだ。Anthropicのプロンプトキャッシングは、通常、APIキーごとにキャッシュを管理し、キャッシュが保持される期間（TTL：Time To Live）も5分間と設定されている。しかし、安価なプロキシの中には、コスト削減や負荷分散のために、多数のAPIキーをプールし、ラウンドロビン方式でリクエストごとに異なるキーを割り当てることがある。例えば、最初のプロンプトがキーAで処理され、キャッシュが作成されたとする。次に同じプロンプトを送っても、プロキシがキーBを割り当ててしまうと、キーBにはキャッシュが存在しないため、再度キャッシュ作成のための1.25倍の費用がかかってしまう。このように、セッション（一連の処理の流れ）の連続性が保たれないと、毎回キャッシュ作成費用が発生し、90%の割引を受けるどころか、常に125%の料金を支払うことになってしまうのだ。

二つ目は「一時的キャッシュ制御の剥奪」だ。一部のプロキシ提供者は、50%オフといった割引を謳いながら、完全な互換性を主張することがある。しかし、裏側では、ユーザーが指定した「cache_control」ブロック、つまりキャッシュの使用を制御する設定情報をプロキシが意図的に削除し、キャッシュ機能のない安価なチャネルにリクエストを転送している場合がある。その後、プロキシはユーザーにキャッシュなしの通常の料金を請求し、ユーザーがキャッシュを作成するはずだった費用分を不当に利益として得ているのだ。

三つ目は「偽の利用状況テレメトリー」だ。プロキシはLLMからの応答JSONを制御できるため、この特性を悪用することがある。例えば、プロキシはプロンプトの冒頭部分を記憶し、同じ部分が繰り返されると検知する。すると、LLMからの実際の応答ではなく、あたかもキャッシュがヒットしたかのように「usage」オブジェクト内の「cache_read_input_tokens」という項目に偽の数字を注入してユーザーに返すのだ。ユーザーのCLI（コマンドラインインターフェース）にはキャッシュヒットを示す表示が出ても、実際にはバックエンドではフル料金で請求されており、ユーザーは騙されていることに気づかない。

四つ目は「動的なシステムプロンプトの挿入」だ。Anthropicのプロンプトキャッシングは非常に厳格で、プロンプトのプレフィックス（先頭部分）が1バイトでも異なるとキャッシュがヒットしないようになっている。しかし、一部の仲介ゲートウェイは、内部的なトラッキングタグやセキュリティ対策のためのプロンプト、あるいは動的なタイムスタンプなどを、ユーザーのシステムプロンプトにこっそり挿入することがある。たとえごくわずかな変更であっても、これによりキャッシュのブレークポイント（キャッシュが有効になる箇所）が無効化され、毎回完全なコンテキストの再読み込みが強制されてしまう。結果として、キャッシュは機能せず、ユーザーは無駄な費用を支払うことになる。

これらの問題を避けるためには、プロンプトキャッシングが実際に効果を発揮する「損益分岐点」を理解しておくことも重要だ。キャッシュ作成費用が1.25倍、読み込み費用が0.1倍、キャッシュなしが1.0倍の場合、キャッシュのヒット率が低いと、かえってキャッシュを無効にするよりもコストが高くなることがある。具体的に計算すると、キャッシュのヒット率が約21.7%を下回ると、プロンプトキャッシングを有効にしている方が費用が高くついてしまう。もしプロキシのルーティングの不安定さなどでキャッシュヒット率がこの22%を下回るようなら、キャッシュ機能を無効にする方が経済的だ。

自分の利用しているプロバイダが正しくキャッシング機能を提供しているか監査する方法がある。まず、静的な（変化しない）テキストブロックで1024トークンを超える長さのプロンプトを含むリクエストを、2秒間隔で2回連続で送信する。

1. 最初のリクエストでは、「cache_creation_input_tokens」が1024より大きい値として返ってくるはずだ。これはキャッシュが新規に作成されたことを示す。
2. 2回目のリクエストでは、「cache_read_input_tokens」が1024より大きい値として返ってきて、かつ応答速度が初回よりも速いはずだ。これはキャッシュが正しく読み込まれたことを示す。

これらの確認に加え、プロバイダのダッシュボードや利用履歴を確認し、2回目のリクエストが通常の入力料金ではなく、キャッシュ読み込みの0.1倍の料金で請求されていることを検証する必要がある。提供されたPythonスクリプトは、この検証プロセスを自動化するためのものだ。スクリプトは、長い固定のプレフィックスを持つシステムプロンプトを使って2つのリクエストを送信し、それぞれの応答時間と「usage」情報、特に「cache_creation_input_tokens」と「cache_read_input_tokens」が期待通りになっているかを確認する。

どのようなサードパーティのゲートウェイを利用する場合でも、ユーザーは以下の点を確認すべきだ。まず、リクエストごとの透明性をプロバイダに要求すること。具体的には、個々のリクエストID、どのアップストリームルート（AnthropicのどのAPIキーやエンドポイント）が使われたか、そしてキャッシュの読み書きカウンタといった詳細なログ情報が提供されるべきだ。これらの情報が隠されているプラットフォームは、不当な請求のリスクがある。まずは少額（例えば1ドルから5ドル程度）のデポジット（預金）で試してみて、実際の利用ログと請求額が一致するかを十分に確認してから、本格的に利用を開始することが重要だ。これにより、悪質なプロキシによる不当な請求から自分の利用料金を守ることができる。プロンプトキャッシングは非常に強力なコスト削減ツールだが、それを正しく機能させるためには、信頼できるプロバイダ選びと定期的な監査が不可欠なのだ。