カスタマーサポート / ワークフロー

社内 RAG ナレッジ QA

社内の規程・マニュアル・議事録を検索できる形にして、質問に「根拠つき」で答えるワークフローです。回答に必ず出典を付け、ハルシネーションを抑えます。

社内文書
→
知識化
→
質問検索
→
根拠付き回答

対象：サポート・情シス・管理部門読了：約 10 分難易度：中級〜上級更新：2026年10月13日

このワークフローで解決できることPROBLEMS

次のような状態に心当たりがあれば、このワークフローが効きます。

社内ルールの確認に、毎回詳しい人へ聞いている
古いマニュアルが更新されず、誤った運用が続いている
ナレッジが個人の PC の中に閉じている
質問への回答に、根拠（どの文書のどこか）を示せない

ねらい：人の作業を「ゼロ」にするのではなく、人が判断すべき工程だけを残すことです。単純作業を自動化し、確認と意思決定に時間を使えるようにします。

全体像（フロー）OVERVIEW

処理は大きく 5 つの工程に分かれます。最初はすべてを自動化せず、1 と 2 の工程だけをつなぐところから始めるのがおすすめです。

社内 RAG ナレッジ QA の処理フロー

構成ツールと役割COMPONENTS

各工程を担うツールの例と、選ぶときのポイントです。同じ役割は、無料ツールや既存の業務システムで置き換えられます。

役割	ツール例	ポイント
文書の集約	Google ドライブ／SharePoint／Notion	まず「どこに何があるか」を棚卸しする
前処理・分割	自作スクリプト／Dify の取り込み	見出し単位で切ると、検索精度が上がる
ベクトル化	埋め込みモデル（OpenAI 等）	日本語に強いモデルを選ぶ
検索・生成	RAG（Dify／自作）	上位 k 件の選び方と、引用の強制が肝
運用・更新	更新担当と定期棚卸し	古い文書の削除ルールを決める

※ ツール名は一般的な選択肢の例です。特定製品の推奨ではありません。

導入手順SETUP STEPS

1 つの業務・1 つのチームを対象に、この順で進めます。各ステップの「完了条件」を満たしてから次へ進むと、手戻りが減ります。

扱う文書を絞る
最初から全社の文書を入れると、精度も保守も破綻します。「問い合わせが多い領域」から始め、対象を絞ります。
完了条件：対象領域と、対象文書の一覧が決まっている
文書を前処理する
見出し単位で分割（チャンク化）し、ページ番号や見出し名をメタデータとして付けます。ここが、検索精度を最も左右します。
完了条件：各チャンクに、出典情報（文書名・見出し）が付いている
ベクトル化して登録する
埋め込みモデルでベクトル化し、ベクトルデータベースに登録します。日本語の検索精度を、必ずテストします。
完了条件：代表的な 20 問で、正しい文書が上位に来る
根拠を明示する回答を作る
回答には必ず「出典：文書名／見出し」を付け、根拠がなければ「該当する文書が見つかりません」と答えさせます。
完了条件：根拠のない質問をすると「不明」と答える
更新と棚卸しの運用を決める
文書の更新者・更新頻度・古い文書の削除ルールを決めます。運用が決まっていない RAG は、半年で使われなくなります。
完了条件：更新担当と、棚卸しの頻度が決まっている

つまずきやすいポイントPITFALLS

導入時に実際に起きやすいつまずきと、その対処です。先に知っておくと回避できます。

古い文書を回答してしまう

更新日をメタデータに持ち、回答時に「いつの情報か」を示します。廃止済みの文書は削除するか、明示的に除外します。

根拠のない回答を作る

「見つからなければ不明と言う」を徹底します。テストで、存在しない質問を投げて確認します。

チャンクの切り方が悪く、検索に失敗する

文章の途中で切れると、意味が失われます。見出し単位・段落単位で切り、重複を持たせる（オーバーラップ）のが定石です。

アクセス権を無視してしまう

部署限定の文書が全員に検索されると問題です。文書ごとの権限を、検索時に反映させる設計が必要です。

運用チェックリストCHECKLIST

運用に乗せたあと、月に一度はこの項目を確認してください。1 つでも外れていると、自動化が「使われない仕組み」になっていきます。

対象文書と対象領域が、絞られている
各チャンクに、出典情報が付いている
日本語での検索精度を、テストした
根拠がない場合に「不明」と答える
回答に、引用元が必ず表示される
文書の更新・削除の運用が決まっている
文書ごとのアクセス権が反映される

よくある質問FAQ

どのくらいの文書量から、効果が出ますか？

数十本程度でも、「探す時間」の削減効果は出ます。逆に、文書が数本しかない場合は、単純に検索窓で足りることも多いです。

ファインチューニングとの違いは？

RAG は「外部の文書を参照して答える」方式で、情報の更新に向いています。ファインチューニングは「振る舞いを覚えさせる」方式で、知識の更新には向きません。社内規程の QA なら、RAG が適しています。

回答が間違っていたら、どう気づきますか？

引用元を必ず表示するのが対策です。利用者が「出典を見る」習慣を持つと、誤りに気づけます。フィードバックのボタンも有効です。

社外秘の文書を、外部サービスに預けて大丈夫ですか？

データの取り扱い規約と、保存場所を必ず確認します。機密性が高い場合は、自社サーバーで動かす構成（ローカル LLM ＋ローカルベクトル DB）を検討します。

構築には、どれくらいかかりますか？

対象を 1 領域に絞った試作は、数日で作れます。実運用には、文書の整備と更新運用の設計に、別途時間が必要です。

コピーして使えるプロンプトPROMPTS

そのままコピーして、[ ] の中を自社の情報に置き換えてください。いずれも「推測させない」「根拠を明示させる」制約を入れています。

根拠つき回答

参照文書だけを根拠に回答させます。

あなたは社内文書に基づいて回答するアシスタントです。以下の【参照文書】だけを根拠に、質問に回答してください。

【必ず守ること】
・参照文書に書かれていないことは、絶対に答えない
・答えられない場合は「該当する記載が見つかりませんでした」とだけ返す
・回答には必ず「出典：文書名／見出し」を添える
・推測や一般論を混ぜない

【参照文書】
[ここに検索結果を貼り付け]

【質問】
[ここに質問を貼り付け]

チャンク分割の設計

文書を、検索しやすい単位に分割します。

次の社内文書を、検索しやすい単位（チャンク）に分割してください。

【分割のルール】
・見出し単位を基本とする
・1 チャンクは 400〜800 字を目安とする
・前後の文脈が切れないようにする
・各チャンクの冒頭に「文書名／見出し」を付ける

【出力】
分割したチャンクを、番号付きで列挙してください。

【社内文書】
[ここに文書を貼り付け]

テスト質問の作成

RAG の精度を測る、質問セットを作ります。

次の社内文書をもとに、RAG システムの精度を確認するためのテスト質問を 10 個作成してください。

内訳は「文書に答えがある質問」7 個、「文書に答えがない質問（正しくは不明と答えるべき）」3 個とします。各質問について、期待される答えと、根拠となる見出しを添えてください。

【社内文書】
[ここに文書を貼り付け]

※ 出力は必ず人が確認してください。数値・固有名詞の誤りは、自動では検出できません。

このワークフローで出てくる用語TERMS

理解を深めたい用語は、AI 用語辞典の詳細ページへ。定義・仕組み・出典をまとめています。

用語の意味から確認する

125 語のAI用語を、定義・仕組み・出典つきで解説しています。

用語一覧を開く →

他

ほかのワークフロー

戻

ワークフロー一覧へ

シーン別のワークフローを、検索と絞り込みで探せます。

ワークフロー（シーン別）を開く →

社内 RAG ナレッジ QA

このワークフローで解決できることPROBLEMS

全体像（フロー）OVERVIEW

構成ツールと役割COMPONENTS

導入手順SETUP STEPS

扱う文書を絞る

文書を前処理する

ベクトル化して登録する

根拠を明示する回答を作る

更新と棚卸しの運用を決める