コスト構造とプロンプトキャッシュ

「多段階のナビゲーションはコストが高いのではないか」——Corpus2Skillの検討で必ず出る疑問です。本ページでは、ナビゲーション型のコスト構造を分解し、プロンプトキャッシュがなぜ劇的に効くのか、WixQAベンチマークで報告された約48%のコスト削減の内訳とともに解説します。

ナビゲーション型のコスト構造

Corpus2Skillの運用コストは、大きくコンパイルコストとサーブコストに分かれます。コンパイルコストは、Summarize・Label段階でのLLM呼び出しが中心で、コーパスの更新時にのみ発生する一時コストです。一方サーブコストは、クエリのたびに発生する継続コストで、エージェントがツリーを歩く際に読み込むノード（SKILL.md・INDEX.md）と、取得する文書全文、そして回答生成の出力トークンで構成されます。

サーブコストの特徴は、探索ステップごとに「これまで読んだ内容＋新しいノード」を入力として送る点にあります。会話が続くほどプロンプトが長くなるエージェント一般の性質と同じで、素朴に実装するとステップ数に対して入力トークンが累積的に増えていきます。これが「ナビゲーションは高い」という直感の正体です。しかし、この累積構造こそがプロンプトキャッシュの得意領域です。

コンパイルコストについても触れておきます。要約とラベルの生成回数はツリーのノード数に比例するため、コンパイルのLLMコストは文書数そのものよりもツリーの規模に連動します。ただしこれはコーパス更新時にだけ発生する一時コストであり、クエリが積み重なる運用フェーズでは、総コストに占める割合は徐々に小さくなります。会計的には、コンパイルを「ナレッジ資産への初期投資」、サーブを「利用量に応じた変動費」と捉えると、既存RAGのインフラ固定費（ベクトルDBの常時稼働費用など）との比較がしやすくなります。

プロンプトキャッシュの仕組みと相性

プロンプトキャッシュは、LLM APIに送るプロンプトの先頭部分をサーバー側にキャッシュし、同じ内容が再送されたときに通常より大幅に安い料金で処理する仕組みです。Corpus2Skillではcache_controlのephemeral指定を用いて、スキルツリーの読み込み内容をキャッシュ対象にしています。

スキルツリーとキャッシュの相性が良い理由は2つあります。第一に、ツリーの上位ノードはどのクエリでも共通して読まれるためです。鳥瞰ビューやトップレベルスキルの説明は、質問が何であれ最初に読み込まれるので、2回目以降のクエリではほぼ確実にキャッシュが当たります。第二に、探索の各ステップは直前までの文脈をそのまま引き継ぐためです。ステップNの入力はステップN-1の入力の延長であり、共通部分はキャッシュ読み取りで処理されます。累積的に増える入力の大半が、割引価格で供給されるわけです。

ここには、従来RAGとの興味深い対比があります。従来RAGのプロンプトは「質問＋そのとき検索された断片」で構成されるため、クエリごとに中身が大きく入れ替わり、キャッシュの当たる共通部分がほとんどありません。一方Corpus2Skillのプロンプトは、静的なスキルツリーという共通の土台の上に質問ごとの差分が乗る構造です。知識をあらかじめ固定的な構造に蒸留したからこそ、キャッシュという料金体系の恩恵を最大限に受けられる——アーキテクチャの選択とコスト特性が直結している好例といえます。

WixQAベンチマーク：48%削減の内訳

効果は具体的な数値で報告されています。WixQAベンチマークにおいて、プロンプトキャッシュなしの1クエリあたりコストは0.172ドルでした。cache_control: ephemeralによるキャッシュを有効化すると、同じクエリ処理が0.089ドルまで下がります。削減率は約48%です。

内訳を見ると、削減の主因は入力トークンの供給元の変化です。キャッシュ有効時、入力トークンの約70%がキャッシュ読み取り（cache_read）となり、通常の1/10の料金で処理されました。ナビゲーションの「累積的に長くなる入力」という弱点が、キャッシュによって「大半が割引対象になる入力」という強みに反転していることがわかります。

なお、キャッシュには作成コスト（cache_creation）も存在します。最初にキャッシュを作る書き込みは通常入力よりやや高い料金がかかるため、クエリ数が少ないうちは削減効果が小さく、クエリが集中するほど効果が大きくなる構造です。社内QAやカスタマーサポートのように、同じナレッジに対して多数の質問が継続的に届くワークロードは、まさにこの構造に合致します。

月間コストの試算例で規模感を掴んでみます。仮に1日200件の問い合わせを処理するサポート部門であれば、月間約6,000クエリです。キャッシュなしの単価0.172ドルなら月額約1,032ドル、キャッシュありの0.089ドルなら約534ドルとなり、差額は月500ドル近くになります。もちろんこの単価はWixQAベンチマークでの実測値であり、コーパスの規模やツリーの深さ、質問の複雑さで変動しますが、「キャッシュの有効化がそのまま数十パーセントの予算差になる」という構造は共通です。自社の想定クエリ数を掛け算するだけでも、概算の説得力ある材料になります。

コスト最適化の実践ポイント

運用でコストを管理する際の実践ポイントを整理します。第一に、トークン会計で実測することです。内蔵の評価モジュール（python -m corpus2skill.eval）は、input・output・cache_read・cache_creationの4区分でトークンを記録し、USDコストを自動計算します。想定ワークロードに近いQAセットで実測すれば、月間コストの見積もりが現実的な精度で得られます。

第二に、ツリー形状の調整です。探索ステップ数はコストに直結するため、コーパス規模に対して深すぎる木は不利です。小規模コーパスなら--compactでリーフインデックスを統合し、段数を減らすことが有効です。第三に、キャッシュの有効期間とアクセスパターンの整合です。ephemeralキャッシュには有効期間があるため、クエリがまばらな環境では期限切れによる再作成コストが発生します。ピーク時間帯にクエリが集中する業務であれば、自然にキャッシュヒット率が高まります。

最後に、コストと品質のバランスという観点を補足します。コスト最適化はそれ自体が目的ではなく、「許容できる予算内で最大の回答品質を得る」ための手段です。探索段数を切り詰めすぎれば、到達精度が落ちて誤答の業務コストが増え、本末転倒になりかねません。評価モジュールで品質指標とコスト指標を同時に取得し、ツリー形状やモデル選択の変更が両者に与える影響をセットで観察する——この規律を保つことが、ナビゲーション型システムを経済的に運用する要諦です。

モデル選択もコストレバーの一つです。ナビゲーションの各ステップは「要約を読んで枝を選ぶ」という比較的定型的な判断であるため、最上位モデルでなくても十分にこなせる場面が多くあります。一方、最終的な回答生成は品質への影響が大きい工程です。将来的に探索と回答生成でモデルを使い分けるような構成が可能になれば、さらなる最適化の余地があります。現時点でも、コンパイル用とサーブ用のモデル選択を分けて考え、それぞれの品質感度をQAセットで実測しておくことは有効です。

コストの議論をさらに深めた考察は、ブログ記事「プロンプトキャッシュで48%コスト削減」にも掲載しています。あわせてご覧ください。