この記事で分かること／分からないこと
- 分かること: 何をどこに置くかを分ける自社の考え方(原本・生成物・索引)
- 分かること: 実行時に索引だけを参照する構成のもとでの実測コスト
- 分からないこと: 索引を分割したこと自体による費用削減効果(自社に前後比較の実測が無い)
- 分からないこと: どの規模から索引分割を検討すべきかという具体的な閾値
何をどこに置くかで実行時コストが変わる
RAGの運用では、投入した原本、ビルド時に作られる生成物、そして実行時に毎回参照する索引を、同じ場所に置くか分けるかという判断がある。自社の設計では、投入原本(CSVやJSON、規程、PDFなど)、生成物(根拠の全集合や質問バリエーション)、検証レポート(フルJSON)は容量の大きいR2に置き、確定配信の索引、テナントや課金台帳、会話ログ、ビルド索引はD1に置くという分け方になっている(出所: docs/STORAGE_AND_BILLING.md、確認日2026-09-06)。R2側は大容量で実行時に読まない前提のもの、D1側は軽量・低レイテンシで実行時にも構造化・集計の対象になるものという住み分けである。
実行時に触るのは索引だけ、という設計の効果
この分け方のもとでは、実行時に参照する対象は索引に限定される。実際の運用では、実行時コストは概算¥0〜1/会話とされ、実測では0.12円/sessionという値が記録されている(出所: docs/STORAGE_AND_BILLING.md、確認日2026-09-06)。この数値は、実行時に索引以外を読まない構成のもとで観測された値であり、索引を分割する前の状態と分割した後の状態を比較して得られた削減効果ではない。索引を分けなかった場合にどうなるかという実測は自社に無いため、この構成が無い場合との差分は示せない。
索引を分けない場合に起きうること
自社の分け方には、差分判定用のchecksumをD1に置き、原本自体はR2に置くという設計も含まれている。理由として挙げられているのは「比較だけなら軽い」という点である(出所: docs/STORAGE_AND_BILLING.md、確認日2026-09-06)。原本と索引・checksumを分けずに同じ場所にまとめて置いた場合、変更の有無を確認するだけの操作でも、容量の大きい原本側を読みに行くことになりうる。これは自社で実測した比較ではなく、分け方の理由として記録されている構造上の考え方である。
索引分割の判断をいつ行うか
索引をどこまで分けるかは、規模や更新頻度、参照パターンの偏りによって判断が変わる論点である。テナント数や文書量が小さいうちは、原本と索引を厳密に分けなくても実務上の支障は出にくい。一方で、テナントごとに独立した索引を持つ、差分更新を頻繁に行う、実行時の参照と構造化データの集計を両方行う、といった要件が重なるほど、原本(R2)と確定配信の索引(D1)を分けておく設計上のメリットは大きくなると考えられる。ただし、この「メリットの大きさ」を金額で示す自社実測は無い。
よくある質問
Q1. 索引を分けると具体的にどれだけコストが下がりますか
自社にその削減効果を示す前後比較の実測は無い。実行時コストとして概算¥0〜1/会話、実測0.12円/session(出所: docs/STORAGE_AND_BILLING.md、確認日2026-09-06)という値はあるが、これは索引を分けた構成のもとでの実測値であり、分けなかった場合との比較ではない。
Q2. 何をR2に置き、何をD1に置く設計になっていますか
投入原本・生成物・検証レポートはR2、確定配信の索引・テナントや課金台帳・会話ログ・ビルド索引はD1に置く分け方になっている(出所: docs/STORAGE_AND_BILLING.md、確認日2026-09-06)。大容量で実行時に読まないものをR2、軽量で実行時にも参照・集計するものをD1に置く住み分けである。
Q3. 差分判定用のchecksumはどこに置くべきですか
自社の設計ではD1に置き、原本自体はR2に置いている。理由は「比較だけなら軽い」という点であり、原本を読みに行かずに変更の有無を確認できるようにする考え方である。
Q4. どの規模になったら索引分割を検討すべきですか
具体的な閾値の実測は無い。テナントごとの独立した索引、頻繁な差分更新、実行時参照と集計の両立といった要件が重なるほど、分けておく設計上のメリットは大きくなると考えられる。
関連記事
RAGのストレージ設計・索引分割について相談したい場合は、お問い合わせフォームからご連絡ください。