社内RAGを「どこまで閉じるか」
——ネット接続あり・社内ネットワーク完結・PC1台完結
社内RAGの相談で、実は最初に確認しているのがこれです。「社内の文書を、外に送っていいですか」
ここの答えで、選べる構成が変わります。そしてあとから変えるのがとても高くつく部分でもあります。「まずクラウドで作って、あとで社内に閉じよう」は、ほぼ作り直しになります。
この記事では、閉じ方を3段階に分けて、それぞれ何ができて何ができなくなるかを書きます。
3つの構成
| 構成 | 外部通信 | 向いている組織 |
|---|---|---|
| ① ネット接続あり | クラウドのAI APIを使う | 一般的な事業会社。制約が特にない場合 |
| ② 社内ネットワーク完結 | 一切しない | 金融・医療・製造・自治体 |
| ③ PC1台完結 | 一切しない | 個人・少人数・検証段階 |
②と③はどちらも「外に出さない」ですが、用途がまったく違います。②は組織で使うもの、③は一人で使うものです。
① ネット接続あり——迷う理由がないなら、これ
クラウドのAIサービスを使う、いちばん一般的な構成です。
| できること | 引き換えに |
|---|---|
| 最新・最高性能のモデルが使える | 文書の内容が外部に送られる |
| サーバーの準備がほぼ要らない | 利用量に応じた課金が続く |
| モデルの入れ替えが容易 | 提供側の仕様変更に影響される |
制約が無いならこれが最も合理的です。性能・コスト・立ち上がりの速さのすべてで有利です。
② 社内ネットワーク完結——外部通信をゼロにする
ここが本題です。金融・医療・製造・自治体では、これが要件になることが多いのですが、対応できる開発会社は限られます。
何を社内に置くことになるか
クラウドに任せていた部分を、すべて社内サーバーに持ってきます。
| 要素 | ネット接続ありの場合 | 社内完結の場合 |
|---|---|---|
| 生成モデル | クラウドAPI | 社内サーバーで動かす |
| 埋め込みモデル | クラウドAPI | 社内サーバーで動かす |
| ベクトルの保存 | 専用サービスも可 | 社内のPostgreSQL等 |
| 文書の保管 | 社内 or クラウド | 社内のみ |
一番の違いは生成モデルを自分で動かすことです。ここでサーバーの要件が跳ね上がります。
何が変わるか(正直な話)
回答の質は落ちます。社内サーバーで動かせる規模のモデルは、クラウドの最上位モデルには及びません。「クラウドと同じものが社内でも動く」という説明を受けたら、それは正確ではありません。
ただし、用途によっては十分です。社内文書の検索と要約であれば、要求される能力はそこまで高くありません。
難しい推論をさせるのではなく、
探して、まとめて、出典を示す。
それなら小さいモデルでも足ります。
逆に「複雑な判断をさせたい」「長い文章を書かせたい」なら、社内完結では期待に届かない可能性があります。用途を先に確認してください。
更新をどうするか
見落とされやすいのがこれです。外部通信を切るということは、モデルもライブラリも自動では新しくならないということです。
- モデルを更新したい → 誰かが持ち込む手順を決めておく
- セキュリティ更新 → 同じく手順が要る
- 「気づいたら2年前のまま」が起きやすい
閉じた環境を作るときは、閉じたあとの更新手順まで一緒に設計します。ここを決めずに納品すると、数年後に誰も触れないものが残ります。
サーバーの要件
ここが予算に直結します。生成モデルを動かすには、それなりの計算資源が要ります。
| 規模 | 目安 |
|---|---|
| 小規模(数人〜数十人) | GPU1枚のサーバー1台で足りることが多い |
| 全社(数百人が同時利用) | 複数台・負荷分散の設計が要る |
| GPUなし(CPUのみ) | 動くが遅い。用途を絞れば実用範囲 |
「まず小さく始めて、使われるようなら増やす」のがここでも正解です。最初から全社規模のサーバーを用意すると、使われなかったときの損失が大きくなります。
③ PC1台完結——検証と、個人利用のために
サーバーすら用意せず、手元のPCだけで動かす構成です。組織で使うものではありませんが、使い道は明確にあります。
何に使うか
- 本当に役に立つかを確かめる。予算を取る前に、自分の文書で試せる
- 社内説得の材料をつくる。動くものを見せるのが最も速い
- 個人の資料整理。人に見せない文書を扱う
数十万円の投資判断をする前に、
0円で確かめられる。
必要なもの
4つの部品が要ります。生成モデルを入れただけではRAGになりません。ここが最も誤解されている点です。
| 役割 | 選択肢 | 補足 |
|---|---|---|
| 実行環境 | Ollama | 導入が最も簡単 |
| 生成モデル | Gemma 3 / Qwen 3系 | Qwenは多言語対応が広い |
| 埋め込みモデル | BGE-M3 / EmbeddingGemma | ここを別に選ぶ必要がある |
| ベクトル保存 | PostgreSQL + pgvector | ②にそのまま上げられる |
PC1台でも、あえてPostgreSQLを使う
1台で試すだけなら、もっと軽い保存先もあります。Pythonのライブラリを入れるだけで動くものもあり、そちらのほうが手軽です。
それでもPostgreSQLに pgvector を入れる形をおすすめしています。理由はひとつです。
③で試したものを、
そのまま②に持っていけるから。
手軽な保存先で試すと、社内サーバーに上げる段階で保存の部分を書き直すことになります。せっかく「使える」と分かったのに、そこから作り直しが発生する。
PostgreSQLは自分のPCにも普通に入りますし、Dockerでも動きます。検証と本番で同じものを使っておけば、上げるときは接続先を変えるだけです。実装の詳細はDjango × pgvector の記事に書きました。
埋め込みモデルの選定が抜けがちです。生成モデルだけ入れて「日本語の精度が出ない」となる原因の多くがこれです。検索の精度を決めているのは、答えを書くモデルではなく、探すモデルのほうです。
実測:手持ちのPCでどこまで動くか
「動きました」で終わる記事は多いのですが、発注を検討している人が知りたいのは実用に耐えるかどうかです。実際に測ります。
① 1問あたりの応答時間(モデルサイズ別)/② 必要なメモリとディスク容量/③ 日本語の検索精度——「請求書」「有給」のような単語ひとつで引けるか/④ 何件くらいから遅くなるか
どれを選ぶか
判断の順番はこうなります。
- 規程を確認する。「社外への送信禁止」と書かれていれば、その時点で②か③
- 用途を確認する。検索と要約なら②で足りる。複雑な判断をさせたいなら①を検討
- まず③で試す。0円で、自分の文書で、本当に使えるかを確かめる
- 使えると分かってから、②か①の規模を決める
3番を飛ばさないことをおすすめします。「役に立つかどうか」は、作ってみないと分かりません。
あとから変えられるもの、変えられないもの
| 項目 | あとから変えられるか |
|---|---|
| ネットワークをどこまで閉じるか | 実質できない。構成ごと作り直し |
| 権限の設計 | できない(別記事) |
| 生成モデルの差し替え | できる(再インデックスは不要) |
| 埋め込みモデルの差し替え | できるが全件再計算が要る |
| 対象文書を増やす | できる |
| 利用人数を増やす | できる(②はサーバー増強が要る) |
上2つだけが「あとから変えられない」ものです。この2つを最初に決めれば、残りは走りながら調整できます。
まとめ
- 最初に確認すべきは「社内の文書を外に送っていいか」
- 制約が無いなら①ネット接続ありが合理的。性能もコストも有利
- ②社内完結は、規程で送信が禁止されている場合の唯一の答え。金融・医療・製造・自治体に多い
- ②では回答の質は落ちる。ただし検索と要約なら足りることが多い
- ②では閉じたあとの更新手順まで設計する
- ③PC完結は、投資判断の前に0円で確かめる手段として価値がある
- ③で見落とされるのは埋め込みモデルの選定。精度を決めているのは探すモデルのほう
- ネットワークの閉じ方と権限設計だけは、あとから変えられない
あわせて読む
この記事はネットワークをどこまで閉じるかの話でした。運用をどこに置くかは別の軸になります。
- RAGはマネージドか、自前か — 運用をAWSに任せるか自分で持つか
- RAGの構築費用はいくらか — 30万円台から始められる理由
- 社内RAGで「他部署の資料が見えてしまう」問題 — 閉じても残る権限の課題
- 社内RAGは、小さく始めたほうが安い — 検討する順番
POSIIでは、社内ネットワークに閉じた構成でのRAG構築をお手伝いしています。「規程で外部送信が禁止されているが、AIは使いたい」という段階からご相談いただけます。まずは対象の文書と、社内の規程を確認したうえで、実現可能な構成をお出しします。