RAGはマネージドか、自前か
——AWS Bedrock と pgvector を両方作って分かったこと
社内RAGを作るとき、最初に決めるのがこれです。AWS Bedrock のようなマネージドサービスに任せるか、pgvector で自前に持つか。
調べると「マネージドは楽、自前は安い」という説明が出てきますが、実際に両方作ってみるとそんなに単純ではありませんでした。楽な部分と面倒な部分が、きれいに入れ替わるだけです。
この記事では、両方を本番まで持っていった立場から、何がどう違ったかを書きます。
結論から：判断はこの3つで決まります
| 問い | 答えがYESなら |
|---|---|
| データを社外に出せないか | 自前（ここで決まることが多い） |
| すでにPostgreSQLが本番で動いているか | 自前が有利 |
| インフラを見る人が社内にいないか | マネージド |
1番目が最も強い条件です。データを外に出せないなら、そこで議論は終わります。残り2つは、その制約が無いときに効いてきます。
費用は「どこにかかるか」が違う
総額の話をする前に、お金の性質が違うことを押さえておく必要があります。
| 項目 | マネージド（Bedrock） | 自前（pgvector） |
|---|---|---|
| 初期構築 | やや軽い | やや重い |
| 埋め込み | 文書量に比例して課金 | 0円（ローカルモデル） |
| ベクトルの保管 | 月額が発生 | 0円（既存DBに同居） |
| インフラの運用 | AWSが持つ | 自分で見る |
| 推論 | 使った分 | 使った分 |
マネージドの実装はDjangoからAWS Bedrock Knowledge Bases を呼び出す、運用はKB自動作成・同期・監視の勘所に書きました。自前の実装はDjango × pgvectorです。
マネージドは毎月かかり続けるものが増える代わりに、運用の手間が減ります。自前はその逆です。
作ってみて、いちばん差が出たところ
① 試行錯誤のコスト
これが想像以上に効きました。
RAGは一発で精度が出るものではなく、チャンクの切り方を何度か変えて試すのが普通です。ところが埋め込みが従量課金だと、試すたびにお金がかかります。
結果として起きるのが、「もう一回やり直すと費用がかかるから、この精度で妥協しよう」という判断です。技術の問題ではなく、心理の問題として設計が固定されます。
自前でローカルモデルを動かしていれば、何度やり直しても0円です。納得するまで試せます。金額そのものより、この差のほうが成果物の質に効きました。
② 権限を業務データと結合できるか
社内RAGでは「この人にこの文書を見せていいか」の判定が必ず要ります。
自前なら同じデータベースにあるので、SQLひとつで済みます。ベクトル検索の結果と権限テーブルを直接JOINできる。
マネージドだと、検索結果のIDを持ち帰ってから、アプリ側で権限テーブルと突き合わせる処理を書くことになります。これは書けますが、件数が合わない・権限が漏れる・順序が狂う、というバグが出やすい場所です。テストの手間も含めると、開発費に効いてきます。
別々に置くと、
繋ぐためのコードを毎回書くことになる。
③ 運用で誰が起きるか
ここは逆にマネージドが強い部分です。
自前で持つということは、PostgreSQLのバックアップも監視もバージョン更新も自分で見るということです。すでに本番でPostgreSQLを運用しているなら追加の負担はほぼありませんが、RAGのために初めてDBを持つなら、話が変わります。
マネージドなら、その部分はAWSが持ちます。夜中に起こされる可能性が減るのは、金額に換算しにくいけれど確実な価値です。
④ モデルを差し替える日
どちらの構成でもいずれ必ず発生します。より精度の高いモデルが出る、コストを下げたい、次元数を落としたい。
このとき全チャンクの再計算が必要になります。
| マネージド | 自前 | |
|---|---|---|
| 再計算の費用 | もう一度かかる | 0円 |
| 切り替えの制御 | サービスの作法に従う | 自分で設計できる |
| 切り戻し | 制約を受ける | 並存させれば設定ひとつ |
自前なら新旧のベクトルを並存させて、参照先を切り替えるだけにできます。精度が期待外れだったとき、設定を戻すだけで元に戻る。詳しくは後から効いてくる費用に書きました。
それでもマネージドを選ぶ場面
ここまで自前寄りに読めたと思いますが、マネージドが正解の場面は確かにあります。
- インフラを見る人が社内にいない。これが最大の理由です
- すでにAWSに寄せている。権限管理も監視も同じ仕組みに乗せられる
- 文書量が桁違いに多い。数千万チャンク規模になると、自前のチューニングが本業になってしまう
- まず動かして判断したい。構築が軽いぶん、立ち上がりは速い
特に最後は見落とされがちです。「使われるかどうか分からない段階」では、速く立ち上がることのほうが価値があることがあります。
両方作って分かった、いちばん大事なこと
意外に思われるかもしれませんが、この選択で成果物の精度は変わりませんでした。
精度を決めていたのは、構成ではなく入れる文書の状態とチャンクの切り方でした。マネージドでも自前でも、整理されていない文書を入れれば、同じように使えないものができます。
構成の選択で変わるのは、
費用のかかる場所と、手間のかかる場所だけ。
だから「どちらが優れているか」で悩む時間は、そのぶん文書の整理に使ったほうが効きます。なぜ見積もりが当たらないのかに書いたとおり、ここが唯一まともに予測できない部分です。
まとめ
- 判断は「データを社外に出せるか」でほぼ決まる
- 費用は総額ではなくかかる場所が違う。マネージドは月額、自前は運用の手間
- 試行錯誤が無料になることが、自前のいちばん効いた利点だった
- 権限を業務データと同じDBで結合できるのも自前の強み
- インフラを見る人がいないなら、マネージドが正解
- モデル差し替えはどちらでも必ず来る。自前は切り戻せる形にできる
- 構成の選択で精度は変わらない。精度を決めるのは文書の状態
それぞれの実装記事
この記事では判断の基準を扱いました。実際の実装と運用は、構成ごとに別記事にまとめています。
- 自前：Django × pgvector でRAGを自前構築する — 次元数・インデックス・再インデックス運用
- マネージド【前編】：DjangoからAWS Bedrock Knowledge Bases を呼び出す — 実装
- マネージド【後編】：KB自動作成・同期・監視の勘所 — 運用
- 社内RAGで「他部署の資料が見えてしまう」問題の解き方 — どちらの構成でも必要になる権限設計
POSIIでは、マネージド・自前の両方でRAGを構築しています。「どちらが向いているか」の切り分けからご相談いただけます。小規模な構成であれば30万円台から、保守は月1万円から。まずは対象の文書を見せていただいたうえで、実際にかかる費用をお出しします。
大河原 潤
AI開発専門家
ブーム以前からAI研究に携わる、本物の専門家。「AIに使われる」のではなく、「AIを使いこなす」確かな技術力を提供します。
【アカデミックな裏付け】
- カリフォルニア大学リバーサイド校 博士前期課程修了（研究分野：測度論、経路積分）
- アメリカ数学会のジャーナルに論文発表
【社会的に認められた専門性】
- AI関連書籍：『誤解だらけの人工知能』（2018年）、『AI×Web3の未来』（2023年）
- プログラミング専門書：実務的な技術書を2冊出版（確かな実装力の証明）
- 100社以上のAI導入コンサルティング実績、特許売却経験あり