RAG 構築で業務が詰まる箇所と設計の勘所
社内文書をLLM（大規模言語モデル）につないで質問に答えさせるRAG（検索拡張生成＝関連文書を検索して回答に使う仕組み）は、業務導入の相談で最も多いテーマの一つです。ところが実際にRAG 構築を業務へ載せようとすると、精度やチャンク分割よりずっと手前で止まります。止まる場所はほぼ決まっていて、「誰にどのデータを見せてよいか」という権限とデータ参照範囲の設計です。私たち日本FDE協会は、Forward Deployed Engineer（顧客の現場に入り込んで課題を技術で解くエンジニア。以下FDE）の実践者が集まる中立の立場から、この統制側の詰まりに向き合ってきました。この記事を読めば、RAGを業務に載せる際に典型的に詰まる箇所を事前に把握でき、自社の導入計画でどこを先に決めるべきかを洗い出せるようになります。
RAG 構築が精度より先に権限で止まる理由
RAGの解説記事の多くは、埋め込みモデルの選定やチャンクの切り方といった精度改善に紙面を割きます。もちろん大事ですが、現場で本当に導入が止まるのはそこではありません。動くプロトタイプを見せた次の瞬間に、「この回答、経理の資料が混ざっていないか」「この人がこの文書を検索できていいのか」という問いが必ず出てきます。
誰がどの文書を検索できるかを先に決めていない
RAGは検索対象の文書をまとめてベクトル化（意味の近さで探せる形に変換）し、質問に近い断片を引いてきます。この「まとめて」が曲者です。全社文書を一つの検索対象に入れてしまうと、人事評価や契約書、他部署の機密が、権限のない人の質問に対しても回答の根拠として引かれてしまう。精度が高いほど、見せてはいけない情報を的確に引いてくるという皮肉が起きます。
アクセス制御が検索の外側に置き去りにされる
既存の業務システムには、フォルダ単位・役職単位のアクセス権が長年かけて積み上がっています。RAGを別レイヤーで組むと、この権限が引き継がれず、検索インデックスだけが無防備な状態になりがちです。元のファイルは見られないのに、RAG経由なら中身が答えとして返ってくる、という抜け道が生まれます。ここを設計段階で塞いでおくことが、後戻りを防ぐ最初の勘所です。
参照範囲の切り分けとログの扱いをどう設計するか
権限で止まらないためには、実装に入る前に「範囲の切り分け」と「ログの扱い」という二点を決めておく必要があります。この二つは精度改善とは別の、統制側の設計判断です。
利用者の属性で検索対象を分ける
実務では、質問した人の役職・部署・案件担当といった属性に応じて、検索できる文書の集合を切り替える設計が要になります。全員が同じインデックスを叩くのではなく、属性でフィルタをかけてから検索する、あるいは属性ごとに検索対象を分ける。どちらを採るかは、文書の機密度と運用負荷のバランスで決まります。金融機関の現場では、顧客情報を含む文書とそうでない文書で参照経路を完全に分け、担当外の案件が回答に混ざらないよう境界を引いた例があります。この境界設計を後回しにすると、稼働後に「見えてはいけないものが見えた」というインシデントで作り直しになります。
検索ログを誰がどこまで見られるか
見落とされがちなのが検索ログです。RAGは「誰が何を質問し、どの文書が引かれたか」を記録できますが、この質問文自体が機密になり得ます。医療分野に近い機密文書を扱う現場では、質問ログにも参照制限をかけ、ログ管理者と業務利用者を分ける職務分掌が必要でした。ログは監査の証跡として価値がある一方、誰でも見られる状態にすると新たな漏洩経路になります。ログを取るか、誰が見るか、どれだけ残すかを、導入計画の早い段階で決めておくべきです。
範囲外情報の漏れを検知する仕組み
完璧に境界を引いても、想定外の質問で範囲外の断片が引かれることはあります。回答が生成される前に、引いてきた文書が利用者の権限内かを最終チェックする層を挟む、あるいは範囲外の参照が起きたら記録して見直す運用を組む。この「漏れを前提に検知する」発想があるかどうかで、稼働後の安心感は大きく変わります。
属人化させない設計判断と社内の担い手
ここまでの権限・範囲・ログの設計は、一度決めれば終わりではありません。組織や案件が変わるたびに見直しが要ります。だからこそ、この設計を一人の頭の中だけに置かないことが重要です。
設計判断を文書に残す
製造業のクライアントの現場でRAG導入を支援したとき、最初に手を動かしたのは実装ではなく「どの図面を誰が検索してよいか」という参照範囲の一覧づくりでした。設計部と製造部で見せてよい図面の範囲が違い、その線引きの根拠を文書にしておかないと、担当者が代わった瞬間に判断がぶれます。私たちは、なぜこの境界にしたのかという判断理由まで残すことを勧めています。RAGの権限設計は業務ルールそのものなので、属人化するとメンテナンスが止まります。
社内で誰がこの役割を担うか
権限設計・参照範囲の切り分け・ログの統制は、純粋なエンジニアだけでも、業務担当者だけでも決めきれません。業務の機密度を理解しつつ、検索の仕組みも設計できる人が現場に要る。これはFDEが担う領域そのものです。「話が早い、技術の話も業務の話も同じ人に相談できる」という反応を現場でいただくことがありますが、RAGの権限設計はまさにこの両面を一人が握ることで前に進みます。自社にこの役割を置けるか、外部の実践者と組むかは、早めに決めておきたい論点です。判断の考え方はAI導入の内製化と外部活用の判断軸も参考になります。RAGの前段にあたるワークフローとデータ連携の設計は業務ワークフローとデータ連携の設計手順で、必要なスキルの全体像はFDEに必要なスキルの全体像｜8領域で解説で整理しています。
よくあるご質問
Q. RAG 構築ではまず精度を上げるべきではないのですか。
精度改善は重要ですが、業務に載せる段階で本当に止まるのは「誰にどの文書を見せてよいか」の権限とデータ参照範囲です。境界を後から引くと作り直しになりやすいため、精度チューニングより先に参照範囲とログの扱いを決めることをお勧めします。
Q. 既存システムのアクセス権はRAGに引き継げますか。
自動では引き継がれません。RAGは検索インデックスを別レイヤーで持つため、元ファイルは見られないのにRAG経由で中身が返る抜け道が生まれがちです。利用者の属性で検索対象を切り分ける設計を、実装前に組み込んでおく必要があります。
Q. この権限設計は社内の誰が担うべきですか。
業務の機密度を理解しつつ検索の仕組みも設計できる人が適任で、これはFDEが担う領域です。純粋なエンジニアや業務担当者だけでは決めきれないため、両面を握れる人材を社内に置くか外部と組むかを早めに検討するとよいです。
RAGの権限設計や社内体制づくりのご相談はお気軽に
日本FDE協会
FDE（Forward Deployed Engineer）の認知拡大・人材育成・コミュニティ形成を目的とした協会です。技術とビジネスの双方を現場で実践するエンジニアを支援しています。