現場でLLMを扱う際、特にAnthropic Claudeのような大規模モデルを使うと、API利用料が青天井になるリスクと戦うことになります。私もRAGシステムをスケールさせる過程で、予測と実績のトークン数にズレが生じ、コスト管理に頭を悩ませました。
※この記事は、個人技術ブログ CodeArchPedia.com の技術メモ（要約）です。
何が起きたか（課題）
大規模なプロンプトや長いコンテキストを扱うと、以下の問題に直面します。
- APIコール後に、想定していなかった量のトークンが課金される。
- コンテキストウィンドウ制限（例：200,000トークン）をローカルで正確に把握できず、意図しないエラーで処理が停止する。
- サードパーティ製のトークナイザーを使うと、日本語やコードを含むテキストで数パーセントの誤差が発生し、見積もりが破綻する。
どう解決したか（概要）
コスト誤差をゼロにする唯一の方法は、Anthropic公式SDKが提供する組み込み関数を使い、APIコール前にローカルで正確にトークン数を事前測定することです。これにより、プロンプトの冗長性を排除し、安定稼働を目指しました。
主要なアプローチは2つです。
-
事前測定:
client.count_tokens(text=full_prompt_text)メソッドを利用し、システムプロンプトとユーザー入力を結合した全文を渡し、ローカルでトークン数を計算します。これにより、コンテキストウィンドウ超過を防ぐバリデーション層を設けることが可能になります。 -
事後確認: 実際にAPIコールが成功した後、レスポンスオブジェクトに含まれる
response.usageフィールドからprompt_tokensとcompletion_tokensを抽出し、最終的な課金額の裏付けを取ります。
経験則や他モデル用のトークナイザーはモデルのバージョンアップで動作が変わるリスクがあるため、Claudeを使う際は公式のツールに限定することが肝要だと分かりました。
効果（Before/After）
公式SDKによる正確な事前チェックを導入した結果、以下のような改善が見られました。
- コスト見積もり精度: 計画値と実績値の乖離がほぼ解消され、月次予算のブレが大幅に減少しました。
- 安定稼働: 大規模RAG処理におけるコンテキスト超過エラー発生率がゼロになりました。
🚀 詳細な設定とコードはこちら
具体的なWAFのルール設定や、より詳細なログ解析データは元のブログで公開しています。