RAGの構築費用はいくらか——なぜ30万円台から始められるのか

社内向けのRAGをいくらで作れるか調べると、「小規模で50〜200万円、本格導入なら300〜800万円」という数字がよく出てきます。運用は月5〜50万円。相場観として間違ってはいません。

ただ、50万円と800万円を分けているのは、開発の腕でも工数でもありません。「毎月かかり続けるもの」を構成に入れたかどうか、渡される文書の状態、そして後から足せないものを最初に決めたかどうかです。

私たちは小規模な構成であれば30万円台から、保守は月1万円からお受けしています。安くしているわけではなく、増えるはずだった固定費を最初から作っていないだけです。

RAGの記事一覧はRAG導入ガイドにまとめています。

費用は4つに分かれる

見積もりを比べるとき、多くの人は1番目だけを見ます。ですが総額を決めているのは2番目と3番目です。この2つは、構成の選び方でゼロにできます。

固定費を作らない構成

① 埋め込みを自前で動かす

埋め込みAPIを使う構成では、処理した文書量に比例して課金されます。問題は一度きりで終わらないことです。

• 文書を追加するたびに、追加分の費用
• チャンクの切り方を変えるたびに、全件やり直し
• モデルを差し替えるたびに、全件やり直し

私たちは multilingual-e5-small をサーバー上で直接動かしています。何万件処理しても、何度やり直しても課金は発生しません。納得できる精度が出るまでチャンク設計を何度でも試せます。社内文書の検索では日本語の精度も十分で、「請求書」「有給」のような単語ひとつの質問でも安定しています（選定の経緯）。

② ベクトルDBは既存のPostgreSQLに同居させる

専用のベクトルDBは、使っていなくても毎月お金がかかります。すでにPostgreSQLが動いているなら、拡張機能 pgvector を入れるだけで同じことができます。

384次元 × 4バイト × 100,000チャンク ≒ 150MB

10万チャンクでも150MB。既存DBに同居させて問題になる大きさではありません。さらに同じDBにあれば、権限テーブルや業務データとの突き合わせがSQLひとつで済みます。別サービスに置くと、件数が合わない・権限が漏れる・順序が狂うといったバグの出やすい突き合わせを自分で書くことになり、初期費用も変わります。

③ インフラを増やさない

Djangoなどで社内システムが動いているなら、その中に組み込めます。サーバーが増えなければ、監視もバックアップも増えません。保守が月1万円から可能なのは、維持すべきものが増えていないからです。

④ 毎回ゼロから作らない

左側の工数は見積もりに乗りません。そのぶん、お客様ごとに違う右側に時間を回せます。

結果として

推論は 入力トークン数 × 単価 ＋ 出力トークン数 × 単価 で計算できるので、想定の質問数から事前に見積もれます。社内利用の規模なら、月数千円に収まることがほとんどです。

見積もりを決めるのは、文書の状態

実装部分はかなり正確に見積もれます。それでも見積もりが外れるのは、渡される文書が想定と違う状態だったときです。

RAGは、入っている文書を
すべて等しく正しいものとして扱います。

意味が近ければ、3年前に廃止された規程でも根拠として使います。だから作業の大半は「何を入れて、何を入れないか」を決めることになります。

同じ「1万件の社内文書」でも、状態によって作業量が数倍変わります。だから私たちは金額をお出しする前に実際の文書を見せていただいています。

費用を抑えたいなら、ここが一番効きます。

1. 正の版を決める。古い版を別フォルダに移すだけでも効果があり、社内でできます
2. スキャンPDFの元データを探す。元のWordやExcelがあればOCRの工程がまるごと不要になります
3. 対象を絞る。状態の良い文書がまとまっている部署から始めます

後から効いてくる費用：権限と、モデルを差し替える日

予算を壊すのは初期費用ではなく、「まず動くものを作って、あとで足そう」とした部分です。足せないものを後回しにすると、作り直しになります。

権限は、後から足せない

権限は文書単位ではなく、チャンク単位で必要になります。議事録の前半は全社共有、後半は人事の話、ということがあるからです。文書単位では「全部見せるか、全部隠すか」の二択になり、正しくやるには分割の仕方から変えて全件を再ベクトル化することになります。

権限モデル → チャンク設計 → インデックス → 検索
この順番でしか作れない。

検索してから権限で落とす方式の落とし穴は社内RAGの権限問題に書きました。

モデルの差し替えは、必ず来る

より精度の高い日本語モデルが出た、コストを下げたい、次元数を落としたい。理由は何であれ、モデルを変えれば全チャンクを計算し直します。上書きしながら変換すると、距離の尺度が違う新旧のベクトルが混ざり、その間の検索結果は意味を失います。

削ってはいけないもの、後から足せるもの

小さく始める順番と、最初にやめること

最初にやめるべきは「全社の文書を全部入れる」ことです。文書の状態がバラバラになり、部署 × 役職 × プロジェクトの権限を最初から設計する羽目になります。しかも「何でも聞ける」は「何を聞けばいいか分からない」と同じです。

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

1. 対象をひとつに絞る。最も費用に効きます。同じことを何度も聞かれていて、文書の状態が良い業務から。「情シスへの問い合わせ」「経理への申請方法の質問」「新人からの手続きの質問」がよくある良い出発点です
2. 既存のPostgreSQLを使う。最初の一歩で足りなくなることはまずありません
3. 埋め込みはローカルモデルで試す。足りなければ、そのとき有料APIに切り替えれば済みます
4. 権限だけは最初に設計する。1部署の中にも人事評価・給与・進行中の契約があります

RAGは作ってみないと使われるかどうか分かりません。確かめるための投資と、広げるための投資を分けるべきです。最初から数百万円をかけると、使われていないと分かったときに引き返せなくなります。

うまくいったら、同じ部署の別の文書 → 隣の部署 → 全社共通の文書 → 横断検索の順で広げます。全社共通の文書ほど版の重複が多い傾向があるので、勢いがついてからのほうが安全です。

まとめ

• 相場の幅を作っているのは工数ではなく、「毎月かかり続けるもの」を構成に入れたかどうか
• 埋め込みを自前で動かし、pgvectorで既存DBに同居させれば、API費用とDB月額がゼロ。やり直しも無料になる
• 見積もりを外すのは文書の状態。版の重複だけは人間にしか整理できない
• 権限モデルと再インデックスの仕組みは後から足せない。監査ログも削らない
• 全社一斉に入れず、ひとつの業務から。数十万円で確かめられることに、数百万円をかける必要はない
• 結果として小規模で30万円台から、保守は月1万円から

よくある質問