RAG（社内文書を検索してAIに答えさせる仕組み）は、どの業務でも同じ部品で作れるように見える。文書を集め、検索できるようにし、AIに答えさせる、という流れ自体は共通だからである。だが実際には、扱う文書の性質、見せてよい範囲、求められる正確さ、根拠の示し方が業務ごとに大きく異なる。同じ作りを横展開すると、ある業務では十分でも、別の業務では使い物にならない、ということが起きる。
本記事は「RAG導入・連携の実務チェック」連載の一編として、業種・業務別のRAGの作り分けを発注者の視点で整理する。読者として想定しているのは、中小企業の経営者、DX担当、情シス担当、事業責任者である。例として、製造ナレッジ、法務、カスタマーサポートの三つを取り上げる。いずれも社内にRAGを置きたい代表的な業務であり、それぞれで何が変わるかを比べると、作り分けの勘所が見えてくる。RAG全体の仕組みは社内ナレッジを活かすRAGとAI検索の実務ガイドでも扱っている。
結論：部品は同じでも、文書・権限・出典の出し方が業務で変わる
RAGの構成部品は業務をまたいで共通だが、それぞれをどう設計するかは業務で変わる。GXOが業種別の作り分けで重視するのは、次の3点である。
- 対象文書の性質（用語の固定度、図や表の多さ、更新頻度）に合わせて、検索方式とチャンク設計を変える
- 見せてよい範囲（権限）と、間違いが許されない度合いに応じて、出典の出し方と確認の厳しさを変える
- 一つの作りを全業務に横展開せず、業務ごとに「何を確かめたいか」を先に決めてから設計する
業種別RAGの失敗の多くは、技術ではなく「業務の違いを設計に反映しなかったこと」から生じる。まずは自社のその業務が、どんな文書を、誰に、どこまで正確に答えてほしいのかを言葉にすることから始めたい。
なぜ業務ごとに作り分けが要るのか
RAGの精度や安全性は、どのAIモデルを使うかよりも、対象文書と業務要件にどれだけ合わせ込んだかで決まることが多い。業務が違えば、その合わせ込みの中身が変わる。
文書の性質が違えば、検索方式やチャンク（文書の分割単位）の設計が変わる。用語が固定された規程と、自由に書かれた問い合わせ履歴とでは、向く探し方が異なる。見せてよい範囲が違えば、権限設計の厳しさが変わる。誰が見ても問題ない情報と、限られた人しか見てはいけない情報とでは、扱いが別物になる。求められる正確さが違えば、出典の示し方や、回答前の確認の厳しさが変わる。参考程度でよい回答と、判断の根拠になる回答とでは、間違いの重みが違う。
つまり、業務の違いは「文書・権限・正確さ・出典」という設計の各所に効いてくる。横展開で失敗するのは、ある業務向けに最適化した設定を、前提の違う別業務にそのまま当てると、どこかにずれが出るからである。
製造ナレッジ：型番・図表・現場の言葉が混ざる
製造業の社内ナレッジは、製品仕様、作業手順、不具合事例、保全記録などが中心になる。ここでのRAGの特徴は、型番・品番・規格番号といった固有の語句が頻繁に出ること、図面や表が情報の本体になりやすいこと、そして現場の言葉と正式な用語が混在することである。
型番や規格番号は、意味で探すよりも語句の一致で探したほうが確実に拾える。似た型番と取り違えないためにも、キーワード検索の比重を高めたい。検索方式の使い分けは検索方式の選定（ベクトル・キーワード・ハイブリッド）で整理している。一方で、不具合事例のように「現場が自由な言葉で書いた文書」も多いため、意味で探す検索も併せて使う、ハイブリッドが現実的になりやすい。
図面や表が情報の本体になる場合、テキストだけを切り出すと肝心の情報が落ちる。この扱いは図面・画像を含むマルチモーダルRAGの論点に重なるため、マルチモーダルRAG（図面・画像・PDFを扱う）で別途整理する。作業手順のように章立てがはっきりした文書は、章や手順の単位で区切るチャンク設計が向きやすい。文書の分割の考え方はチャンク設計の基本で扱っている。
製造ナレッジでは、現場が安心して使えるよう、回答がどの手順書・どの図面に基づくかを示せることが重要になる。出典が確認できないと、現場は回答を信用しきれない。
法務：正確さと出典が最優先、見せてよい範囲も厳しい
法務に関わる文書（契約書、社内規程、過去の対応記録、ガイドラインなど）を対象にするRAGは、求められる正確さと、出典の厳しさが他業務より高い。条文や規程の解釈は、わずかな言い回しの違いが意味を変えることがあり、AIがそれらしくまとめた回答をそのまま判断に使うのは危うい。
このため法務RAGでは、回答だけでなく「どの条文・どの規程のどこに基づくか」を必ず示し、利用者が原文を確認できる作りが前提になる。出典提示とAIの作り話への向き合い方は出典提示とハルシネーション対策で扱っている。RAGはあくまで「該当箇所を素早く見つける補助」と位置づけ、最終判断は人が原文を確認して行う、という運用にしておくのが安全である。
見せてよい範囲も厳しい。契約や法的対応の情報は、限られた担当者しか見てはいけないものが多い。誰がどの文書を参照してよいかを、既存の権限と整合させて設計する必要がある。権限の考え方はアクセス制御の設計で整理している。法務情報を社外のサービスで処理してよいか、ログをどこまで残すかといったセキュリティ面も、他業務より慎重に詰めたい。
カスタマーサポート：問い合わせの言い回しに強く、鮮度が要る
カスタマーサポート向けのRAGは、FAQ、製品マニュアル、過去の問い合わせ対応履歴などを対象にする。ここでの特徴は、利用者（オペレーターや顧客）が自由な言い回しで質問すること、そして製品の仕様変更や価格改定などで情報が頻繁に変わることである。
問い合わせは「正式な用語」ではなく「困っている状態の言葉」で来ることが多い。「動かない」「つながらない」といった表現から、該当するマニュアルやFAQを見つけられる必要がある。このため、意味で探すベクトル検索の比重が効きやすい。ただし製品名や型番が混ざる場面もあるため、語句一致も併用するのが安全である。
鮮度の維持は、サポートRAGで特に重い論点になる。古い価格や仕様で回答すると、顧客対応の現場で直接の問題になる。文書が更新されたときに、いつ・どう反映するかという運用を最初から設計に含めたい。更新の流れは更新フローと鮮度の維持で整理している。また、誤った案内を返さないよう、回答の根拠となったFAQや手順を示し、オペレーターが確認できる作りにしておくと、現場の信頼を得やすい。
三業務の違いを一覧で整理する
ここまでの違いを、発注者が比較しやすいよう表にまとめる。あくまで傾向であり、自社の実態に合わせて読み替えてほしい。
| 観点 | 製造ナレッジ | 法務 | カスタマーサポート |
|---|---|---|---|
| 主な文書 | 仕様・手順・不具合事例・図面 | 契約・規程・対応記録 | FAQ・マニュアル・問い合わせ履歴 |
| 向く検索方式 | キーワード比重高め＋ハイブリッド | 語句一致重視＋出典厳格 | 意味検索比重高め＋語句併用 |
| 求める正確さ | 高い（現場作業に直結） | 最も高い（判断の根拠） | 高い（顧客対応に直結） |
| 出典の出し方 | 手順書・図面の該当箇所 | 条文・規程の原文を必ず確認 | FAQ・手順の該当箇所 |
| 権限の厳しさ | 中（一部は機密） | 高（限定担当のみ） | 中（顧客情報の扱いに注意） |
| 鮮度の要求 | 中（改訂時に反映） | 中〜高（改正・規程変更時） | 高（仕様・価格変更が頻繁） |
この表が示すのは、同じRAGでも「どこに重みを置くか」が業務で変わるということである。製造は語句一致と図表の扱い、法務は出典と権限、サポートは意味検索と鮮度、というように、力を入れる場所が異なる。
業種別RAGの作り分けでよくある失敗
業種別にRAGを作るとき、次のような失敗が起きやすい。いずれも、業務の違いを先に整理しておけば避けられる。
- 一つの作りを全業務に横展開する：ある業務向けの設定を前提の違う業務にそのまま当て、検索や権限がかみ合わない。
- 正確さの要求度を業務でそろえてしまう：参考程度でよい業務と、判断の根拠になる業務を同じ厳しさで扱い、過不足が出る。
- 図面や表をテキスト化で済ませる：製造ナレッジで図表が情報の本体なのに、そこを落として精度が出ない。
- 鮮度の運用を後回しにする：サポートで仕様・価格が変わるのに反映の仕組みがなく、古い案内を返す。
- 権限を業務横断で甘く設計する：法務など限定情報を含む業務まで、緩い権限のまま広げてしまう。
業務ごとに「何を、誰に、どこまで正確に答えてほしいか」を先に決めておけば、作り分けの方針は自ずと定まる。
GXOに相談する前に整理するとよい情報
業種別のRAGを一緒に設計するために、相談の前に次の情報を整理しておくと話が早い。すべて揃っていなくても問題ない。
- 対象にしたい業務と、その業務で扱う主な文書の種類（仕様・規程・FAQなど）
- 文書に型番・固有名詞・略語がどれくらい出るか、図面や表が情報の本体になるか
- 回答が「参考程度」でよいのか、「判断の根拠」になるのか
- 見せてよい範囲（誰がどの文書を参照してよいか）と、機密・個人情報の制約
- 文書がどれくらいの頻度で変わるか、更新を誰が反映するか
これらが見えていれば、業務に合った検索方式・権限・出典の出し方を一緒に設計できる。発注者が技術の細部まで理解している必要はなく、業務の前提を共有できれば十分である。
参考にした外部観点
業種別にRAGを作る場合でも、品質と同時にリスク管理を業務単位で見る必要がある。NIST AI Risk Management FrameworkはAIのリスクを組織的に扱う枠組みであり、業務ごとにリスクの重みが違うことを整理する助けになる。OWASP Top 10 for Large Language Model ApplicationsはLLMアプリケーションの代表的なリスクを整理しており、法務やサポートのように機密・個人情報を扱う業務で特に参照価値が高い。情報の取り扱い全般は、IPA（情報処理推進機構）が公開する各種ガイドも、中小企業が自社の制約を確認する出発点になる。
実務では、まず一つの業務に絞り、想定質問と正解例を業務ごとに用意してから設計に入ると、業務の違いを設計に反映しやすい。
関連記事
よくある質問
Q1. 業務ごとにRAGを別々に作る必要がありますか
必ずしも別システムにする必要はない。検索や権限の部品は共通化しつつ、対象文書・検索方式の比重・権限・出典の出し方を業務ごとに設定で分ける、という作り分けが現実的である。重要なのは、業務の違いを設定に反映できる作りにしておくことであって、一つの設定を全業務に当てないことである。
Q2. まずどの業務から始めるとよいですか
文書が整理されていて、間違いの影響が比較的小さい業務から始めると、確かめながら進めやすい。たとえば社内FAQや手順書のように、用途が明確で被害が限定的な業務である。逆に、法務のように正確さと権限の要求が最も高い業務は、他業務で運用の勘所をつかんでから着手するほうが安全なことが多い。
Q3. 製造の図面や法務の条文は、RAGで本当に扱えますか
扱えるが、業務に応じた工夫が要る。図面や表は、テキストだけ切り出すと情報が落ちるため、画像やPDFを含めて扱う設計が必要になる。これはマルチモーダルRAGで整理する。法務の条文は、AIの要約をそのまま使わず、出典として原文を必ず確認できる作りにし、最終判断は人が行う運用にしておくのが前提である。
業務に合ったRAGの作り分けを一緒に整理しませんか
GXOでは、製造ナレッジ・法務・カスタマーサポートなど、業務の性質に応じたRAGの設計を、対象文書・権限・出典の出し方まで含めてご支援します。
※ 初回相談では、営業資料の説明よりも現状整理とリスク確認を優先します。