この記事で分かること・分からないこと
- 分かること: 再構築が必要になるきっかけと、それをどう検知するか
- 分かること: 全件再構築と差分再構築で、繰り返し発生する費用の構造がどう変わるか
- 分からないこと: 「何日ごとに再構築すべきか」という具体的な頻度の数値(ファクトシートに無い)
再構築が必要になるきっかけ
自社実装のビルド時費用≈¥1,500/テナントは一回限りの費用として説明されているが、それは「原本が変わらない限り」という前提つきである。原本データが更新されれば、生成・検証をやり直す必要が生じる(出所: docs/STORAGE_AND_BILLING.md、確認日2026-09-06)。この更新をどう検知するかが、再構築の頻度を左右する。
差分検知の仕組みと費用への影響
自社実装は差分判定用のchecksumをD1に持ち、原本そのものはR2に置く構成を取っている(出所: docs/STORAGE_AND_BILLING.md、確認日2026-09-06)。checksumが変わった箇所だけを検知できれば、変更されていない部分まで含めて全件を作り直す必要がなくなる。全件再構築を選ぶと、テナント単位の≈¥1,500という費用が再構築のたびにそのまま発生する。差分再構築を選ぶと、変更された範囲だけが対象になるため、繰り返し発生する金額は変更の規模に応じて小さくなりうる。自社実装が「差分再生成で再発を抑える」と明記しているのは、この違いを踏まえたものである(出所: docs/STORAGE_AND_BILLING.md、確認日2026-09-06)。ただし、差分再生成で具体的に何円減るかという実測値はファクトシートに無く、本記事でも金額としては示さない。
頻度をどう決めるか
「何日ごとに再構築すべきか」という具体的な頻度は、原本データの更新頻度や、古い情報を配信し続けることをどこまで許容できるかという業務側の判断に依存する。ファクトシートにはこの頻度を直接示す数値が無く、本記事でも特定の日数は推奨しない。言えるのは、差分検知の仕組みがあれば、頻度を上げても再構築のたびにビルド時費用の全額が発生するわけではない、という構造上の関係だけである。検討にあたっては、原本データがどのくらいの周期で変わるかを把握し、古い情報のまま応答することがどこまで許容できるかを業務側で確認する必要がある。差分検知の粒度(どの単位でchecksumを取るか)は、ビルド時費用全体の構造とも関わるため、ビルド時と実行時の費用構造の記事とあわせて確認してほしい。
よくある質問
Q1. RAGの再構築はどのくらいの頻度で行うべきですか？
ファクトシートに具体的な頻度の数値は無く、本記事でも特定の日数は推奨しない。原本データの更新頻度と、古い情報の許容度を業務側で確認したうえで判断する必要がある。
Q2. 差分再生成によって費用はどれだけ減りますか？
減る方向に働く構造であることは自社実装の説明から言えるが、具体的に何円減ったかという実測値はファクトシートに記録されていない(出所: docs/STORAGE_AND_BILLING.md、確認日2026-09-06)。
Q3. 差分検知はどのような仕組みで行われていますか？
原本はR2に置き、差分判定用のchecksumをD1に持つ構成である。checksumが変化した範囲だけを検知できれば、全件を作り直す必要がなくなる(出所: docs/STORAGE_AND_BILLING.md、確認日2026-09-06)。
RAGの再構築頻度・費用構造について相談したい場合は、お問い合わせフォームからご連絡ください。
- ハブ記事: RAGサービス比較15選
- 関連記事: RAGの評価コストと実行コストは別物
- 関連記事: 初期のデータ整備が費用の見えない大部分になる理由
- 関連記事: ビルド時と実行時の費用構造