社内RAGの相談でいちばん多いのが、「全社の文書を全部入れたい」という出発点です。気持ちは分かるのですが、これが費用を最も膨らませます。

そして厄介なのは、お金をかけた案件ほど使われなくなることです。この記事では、何から手を付けるべきかを順番で書きます。

最初にやめるべきこと：全社一斉に入れる

全社の全文書を対象にすると、3つが同時に起きます。

3番目が見落とされがちです。対象を広げるほど、一人ひとりにとっては使う理由が薄くなります。

全社に配ったものは、
誰のものでもなくなる。

検討する順番

1. 対象をひとつに絞る

ひとつの部署、ひとつの業務から始めます。ここが最も費用に効きます。

選ぶ基準は2つです。

• 同じことを何度も聞かれている業務。問い合わせが多いほど効果が見えやすい
• 文書の状態が良い部署。整理されたテキストがまとまっているところ（なぜ状態が効くのか）

2. 既存のPostgreSQLを使う

専用のベクトルデータベースを契約する前に、すでに動いているデータベースで足りないかを確かめます。

10万チャンクでも150MB程度なので、最初の一歩でこれが足りなくなることはまずありません。必要になってから移せば十分です（費用の内訳はこちら）。

3. 埋め込みはローカルモデルで試す

有料APIを使う前に、サーバー上で動くモデルで精度を見ます。ここで十分なら、文書量に比例した費用が丸ごと発生しません。

それ以上に効くのが、やり直しが無料になることです。分割の仕方を何度でも試せるので、妥協せずに精度を追い込めます。足りなければ、そのとき有料APIに切り替えれば済みます。

4. 権限だけは最初に設計する

1〜3は後から変えられますが、これだけは後回しにできません。

権限は文書単位ではなくチャンク単位で必要になるので、後から足すと分割のやり直しになります。後から効いてくる費用に詳しく書きました。

小さく作ると、判断できるようになる

順番の話をしましたが、本当の理由は費用よりこちらです。

RAGは、作ってみないと使われるかどうか分かりません。精度が想定より出ない、想定と違う質問ばかり来る、そもそも誰も使わない。どれも実際に起こります。

だからこそ、確かめるための投資と、広げるための投資を分けるべきです。

最初から数百万円をかけると、「使われていない」と分かったときに引き返せなくなります。投じた額が大きいほど、やめる判断が難しくなるからです。

数十万円で確かめられることに、数百万円をかける必要はありません。

広げるときに考えること

最初のひとつがうまくいったら、次はこの順で広げます。

1. 同じ部署の別の文書を足す。権限の設計を変えずに済むので最も簡単
2. 隣の部署に広げる。ここで初めて部署をまたぐ権限が必要になる
3. 全社共通の文書を足す（就業規則、経費規程など）。誰でも見てよいので権限は単純
4. 横断検索を有効にする

3番を先にやりたくなりますが、全社共通の文書ほど版の重複が多い傾向があります。整理の手間が読めないので、勢いがついてからのほうが安全です。

まとめ

• 全社一斉に入れない。対象を広げるほど、一人あたりの使う理由が薄くなる
• 順番は ①対象を絞る → ②既存のDBを使う → ③ローカルモデルで試す → ④権限は最初に設計
• ①が最も費用に効く。同じことを何度も聞かれている業務から始める
• ④だけは後から変えられない
• 確かめるための投資と、広げるための投資を分ける
• 大きく作るほど、やめる判断ができなくなる