はじめに
前編では、社内のことに答えるChatBotの最短ルートは自前実装ではなく、Google Drive / SharePointの権限を整えて付属のAI（Gemini / Copilot）につなぐことだと書いた。大半のケースはそれで完成する。
後編は、それでは届かない場合の話だ。既製品の外に出なければならない4条件を再掲する。
- 完全閉域が要件
- 文書がSaaSに移せない
- 社外ユーザーに答えさせたい
- 文書とDBを横断したい
このどれかに該当して初めて、自前構築の検討に入る。本記事では条件ごとの現実的な構成と、作る場合に職人芸の沼へ落ちないための設計を書く。
その前に：本当に該当しているか
着手前に、条件そのものを一度疑う。特に条件2だ。
「文書がSaaSに移せない」の実体は3種類ある。
- ファイルの形をしていない — 基幹システム内の見積書や図面。実体はDBのレコードで、書き出すと「どの案件の何版か」という文脈が失われる。これは本物の「移せない」
- 構造ごと縛られている — 旧グループウェアの文書DB。エクスポートすると添付やリンクの構造が壊れる。これも移行が難しい
- 移す作業が大きいだけ — ファイルサーバーの10TB、紙スキャンの山。技術的には移せる
実務で出会う「移せない」の多くは3番目だ。この場合、自前RAGの見積もりの前に移行の見積もりを取る。移行した方が安く、しかもバックアップやリモート参照といったAI以外の恩恵まで付いてくるケースが少なくない。移行してしまえば前編の構成に合流でき、この記事の残りを読む必要がなくなる。それが一番良い結末である。
構成は「梯子」で選ぶ
構築が確定したら、次は構成だ。いきなりベクトルDBを立てない。選択肢を運用負荷の軽い順に並べると、こうなる。
- マネージド検索 — Vertex AI Search、Amazon Bedrock Knowledge Basesなど。文書の取り込み・分割・検索・引用をサービス側が持つ
- エージェント検索 — LLMにファイル検索ツール（grep相当や全文検索）を持たせ、検索→読む→足りなければ再検索、を反復させる
- 完全自前 — 埋め込みモデル、ベクトルDB、チャンク分割、リランキングを自分で組む
上から順に検討し、下に降りるのは上で要件が満たせないときだけ。この順序には理由がある。
なぜ完全自前を最後にするのか
自前RAGの精度問題は、生成モデルではなくほぼ検索側で起きる。そして検索品質の中核であるチャンク分割には構造的な性質がある。「この系統の文書はこの粒度が良い」という調整は、その現場限りのナレッジにしかならない。汎用的な正解がなく、全体の精度を上げる変更が特定の質問の精度を下げることも普通に起きる。改善を回すには想定質問セットでの評価が必須になるが、その運用自体が重い。
要するに、完全自前を選んだ瞬間に「チャンク職人」の稼働が恒常的に発生する。職人が生まれる過程は決まっていて、利用者から「精度いまいちだよね」という声を何度も聞かされ、そのたびに分割粒度をいじるうちに出来上がっていく。この泥仕事を肩代わりしてくれるのがマネージド検索であり、そもそもチャンクという概念を捨てたのがエージェント検索だ。実際、コーディング支援の世界では、ベクトル検索だけに依存せず、grepやファイル検索などのツールをLLMに使わせる方式が一般的になっている。文書量がコンテキストウィンドウに収まる規模なら、検索パイプラインなしで全文を渡す選択すら現実的になった。
もう一つ注意がある。ClaudeなどのLLMにRAG構築を相談すると、まずチャンク分割前提の実装を案内されることが多い。学習データに蓄積されたRAG解説の大半がその型だからで、2026年8月時点でもこの傾向は続いている。AIの提案に乗ってそのまま組むと、気づけばチャンク職人への道を歩いている。構成の選択だけは、AIに聞く前に本章の梯子で決めておくべきだ。
自前でベクトル検索を組むのが正当化されるのは、閉域でマネージドが使えず、かつ文書量がエージェント検索や全文投入で捌けない規模のときだ。つまり次の章である。
条件1：完全閉域 — ローカルLLM構成
クラウド不可が規程・契約で決まっている現場では、選択の余地なくローカルLLM＋自前検索になる。
先に費用の話をする。品質を求めるなら生成モデル用のGPU投資は避けられない。ただし内訳は分けて考える。
- 生成 — 回答文を作る部分。ここがGPUを食う。モデルのサイズと同時利用者数で要求が決まる
- 検索・埋め込み — 埋め込みモデルは生成モデルよりはるかに小さく、CPUや小規模GPUでも動く。全文検索（キーワード検索）に至ってはGPU不要
つまり「閉域だから全部重い」わけではない。検索側は軽く作れるので、投資判断は生成モデルに集中する。最初から大型モデルを買わず、検証段階では小型モデル＋ハイブリッド検索（キーワード＋ベクトル）で想定質問への回答品質を測り、足りない分だけモデルサイズを上げていくのが安全だ。
予算の目安だけ書いておく。検証段階（7〜14B級）でマシン込み数十万円、部署で実用に載せる27〜32B級で100万円前後、70B級の本格運用なら300万円超を見る。ただし2026年8月時点はメモリ不足でGPU実勢価格が定価の1.5〜2倍に張り付いており、変動が激しい。機種選定やモデルの選び方の詳細は、ローカルLLM導入を主題にした別記事で扱う予定だ。
構成の型は前章の梯子がそのまま縮小して適用される。閉域版マネージドは存在しないので、エージェント検索（ローカルLLM＋全文検索ツール）をまず試し、文書量で破綻したらベクトル検索を足す。順序は同じである。
条件3：社外ユーザー向けボット
既製品のAIは自社テナントのユーザーにしか動かないため、取引先や一般顧客向けは作るしかない。ただしここは技術より設計の要求水準が一段上がる。
外向けボットの回答は、企業の公式回答として扱われうる。海外にはチャットボットが誤案内した補償条件について企業側の責任を認めた判例もある。免責表示を置けば済む、という前提では設計できない。
指針は一つ。間違いが「約束」にならない設計にする。
- 使ってよい形：正解の場所へ導くナビゲーション。「その手続きはこのページ」「必要書類はこの3点、詳細はこちら」と原文リンクとセットで示す。間違えても被害は「遠回り」で済む
- 使ってはいけない形：金額・納期・契約条件・返金可否をボットが断言する。精度99%でも残り1%が事故になる
数字と条件に触れる質問はボットに答えさせず、該当規定の提示と人間の窓口への誘導に倒す。回答の正確さを上げる努力と同じくらい、「答えない範囲」を決める設計に時間を使うべき領域だ。
条件4：文書とDBの横断 — Text-to-SQL
「この製品の在庫と納期は？」のような質問は、文書検索では答えられない。社内の質問の半分は文書ではなく数字（売上、在庫、未回収）であり、需要は大きい。閉域ならローカルLLMとの組み合わせにもなる。SQL生成自体は文書要約より小さいモデルでも案外成立する。
ただしここにも職人の沼がある。Text-to-SQLの精度を決めるのはモデルではなく、「業務用語をDBのどのカラム・どの計算式に対応させるか」という辞書だ。「顧客名は customers.name」程度の単純な対応ならスキーマ定義を渡せばLLMも当てる。厄介なのは計算定義である。「粗利」と言われたとき、単価から原価を引くのか、値引き後なのか、返品を差し引くのか。「先月の売上」は暦月か締め日基準か、計上は受注日か請求日か入金日か。これらはDBのどこにも書かれておらず、経理と営業で答えが違うことすらある業務知識だ。
そして定義を取り違えてもSQLは正常に実行され、もっともらしい別の数字が返ってくる。文書検索の誤回答は読めば違和感に気づけるが、数字の誤りは検算しない限り気づけない。Text-to-SQLの怖さはエラーではなく、静かに間違うことにある。
結果、利用者の「数字が合わない」という指摘のたびに定義を1つずつ辞書へ足していく作業が恒常化する。現場限りのナレッジを積み続けるという意味で、チャンク職人と同じ構造だ。名付けるならスキーマ辞書職人である。
処方箋は、自由質問から始めないこと。
- よく聞かれる質問トップ20を定型クエリとして固定する
- AIの仕事は「どの定型に該当するか＋パラメータ抽出」だけに絞る
- 実行は読み取り専用ビューに限定し、生成SQLはログに残す
- 定型で拾えなかった質問がログに溜まってから、自由質問への拡張を検討する
この構成なら精度は実質100%で、SQLは全件レビュー済み、権限もビューで絞れる。「AIがSQLを書く」より地味だが、業務システムとして信頼される順序はこちらだ。
共通：作った後に必要になるもの
前編の既製品構成と違い、自前構築では次が自分の責任になる。着手前に運用体制まで含めて見積もる。
- 想定質問セット — 30〜50問でよいので、正解付きの質問集を作り、変更のたびに流す。これがないと「直したら別が壊れた」に気づけない
- 文書の更新経路 — 誰がいつ新文書を取り込み、旧版を外すか。前編で書いた文書オーナー制は自前構築でも同じく必要
- 権限 — 既製品ならストレージの権限がそのまま効いたが、自前では検索範囲と利用者の対応を自分で実装・維持する。前編の「権限が同質な単位で分ける」原則は、自前ではさらに重要になる
- 外部由来データの分離 — 問い合わせメールなど外から来たテキストを、社内の信頼済み文書と同じ検索対象に混ぜない
チェックリスト
- 4条件のどれに該当するか特定した（該当しないなら前編の構成に戻る）
- 「移せない」が本物か確認し、移行の見積もりを先に取った
- 構成はマネージド→エージェント検索→完全自前の順で検討した
- 閉域の場合、生成と検索のリソースを分けて見積もった
- 外向けボットは「答えない範囲」を先に定義した
- Text-to-SQLは定型クエリからで、実行権限は読み取り専用に絞った
- 想定質問セットと文書オーナーを用意した
おわりに
後編の結論も、突き詰めれば前編と同じだ。作る技術よりも、作らずに済む範囲を見極める判断と、作った後を回す運用の設計が価値の中心になる。AIを現場に配備するFDEの仕事は、コードを書く時間より、この見極めに使う時間の方が長い。
次回からはFDEの他の業務に移る。議事録・会議まわり、問い合わせ対応、バックオフィス業務あたりを順に扱っていく。