「社内文書を AI に読ませて、質問すれば答えが返るようにしたい」というご相談が増えています。このとき最初に聞かれるのは、たいてい「どのモデルを使うべきか」「ベクトルデータベースは何がいいか」といった技術選定の話です。しかし実際の開発現場で手が止まるのは、ほぼ例外なくその手前 — 社内文書がどこに、どういう状態で置かれているかという部分です。
この記事では、RAG（Retrieval-Augmented Generation：検索拡張生成。社内文書などを検索し、その内容をもとに生成 AI に回答させる仕組み）を導入する前に決めておくべきことを、技術選定より前の順序で整理します。
RAG は「検索」が先、「生成」は後
RAG の処理はおおまかに二段階です。まず質問に関係しそうな文書を社内データから探し出し（検索）、次にその文書を材料に回答文を組み立てます（生成）。
重要なのは、検索で拾えなかった情報は、どれだけ高性能なモデルを使っても回答に現れないという点です。逆に、古い版の文書を拾ってしまえば、モデルはそれを正しい情報として堂々と回答します。モデルの性能が効いてくるのは「拾った文書を読み解いて自然な文章にする」部分であって、「何を拾うか」の精度にはほとんど寄与しません。
つまり投資判断としては、モデルのグレードを上げる前に、検索対象となる文書側を整えたほうが費用対効果が高い、という順序になります。
文書が散らばっていると何が起きるか
中小企業で典型的なのは、共有サーバー、クラウドストレージ、メール添付、個人 PC のデスクトップ、紙のバインダーに情報が分散している状態です。この状態で RAG を構築すると、次のような症状が出ます。
- 版の混在：「就業規則_最新.docx」と「就業規則_2023改定版.docx」が両方ヒットし、どちらを根拠にしたか分からない回答が返る
- 重複による埋没：同じ内容のファイルが十数個あると、検索結果の上位がそれで埋まり、本当に必要な別文書が押し出される
- 文脈の欠落：議事録の断片だけが拾われ、前提となる決定事項が抜け落ちる
- 対象外の混入：下書き、提案段階の資料、失注案件の見積が正式文書と同列に扱われる
これらはモデルを変えても解決しません。入力側の問題だからです。
着手前に決めておく5つの前提
開発に入る前に、社内で合意を取っておきたい項目を整理します。技術者ではなく、業務を把握している方が決めるべき内容です。
| 決めること | 具体的な内容 | 決めないと起きること |
|---|---|---|
| 正本の所在 | 各文書について「これが唯一の正しい版」という置き場を一箇所に定める | 古い版を根拠にした回答が混ざる |
| 更新の責任者 | 文書種別ごとに、改定時に正本を差し替える担当を決める | 半年後には実態と乖離し、使われなくなる |
| 対象に含める／含めない | 下書き・個人メモ・過去案件などの扱いを線引きする | ノイズで検索精度が落ちる |
| 権限区分 | 全社公開／部門限定／役職限定などの階層を定義する | 見えてはいけない情報が回答に出る |
| ファイル形式の方針 | 新規作成分をどの形式に寄せるか、既存のスキャン PDF をどうするか | 読み取れない文書が穴になる |
権限設計は後付けが効かない
最も見落とされやすく、最も修正コストが高いのが権限です。RAG では文書を細かく分割して検索用のデータベースに格納するため、元ファイルのアクセス権限は自動では引き継がれません。何も設計しなければ、人事評価の資料も役員会議事録も、全社員の質問に対して検索対象になり得ます。
対策としては、文書を取り込む段階で各断片に「どの範囲の人が閲覧できるか」のタグを付け、検索時に質問者の権限と突き合わせて絞り込む設計が基本になります。これを後から追加するには、取り込み処理とデータ構造の両方を作り直すことになりがちです。
また、個人情報や機微な情報を含む文書を扱う場合は、個人情報保護法（2020年改正・2022年全面施行）に照らした取り扱いの確認が必要です。生成 AI 全般の利用にあたっての留意点については、総務省・経済産業省が2024年に公表した「AI事業者ガイドライン」が参考になります。自社のケースが該当するかどうかは、顧問の専門家に確認されることをお勧めします。
実装で詰まりやすい箇所
前提が整ったうえで、技術的に手間がかかるのは次のような点です。
| 詰まりやすい箇所 | 内容と対応の方向性 |
|---|---|
| 分割の単位 | 文書を機械的に一定文字数で切ると、表の途中や条文の途中で分断される。見出し単位・条単位で区切る設計が必要 |
| 表とレイアウト | 料金表や仕様表は、行列の対応関係が崩れると意味を失う。表部分だけ別処理にすることが多い |
| スキャン PDF | 画像として保存された紙資料は、OCR（文字認識）を通さないと一切検索に乗らない。精度も内容次第 |
| Excel 台帳 | セル単位の情報は文章として意味を成しにくい。データベースへの検索と組み合わせる構成を検討する |
| 更新の反映 | 文書を改定したら検索用データも作り直す必要がある。手動運用にすると必ず止まる |
| 精度の確認方法 | 想定質問と正解のセットを数十件作り、改修のたびに同じ質問で比較する。これがないと改善したか判断できない |
たとえば次のような場面です。社内規程を RAG に載せたところ、「有給休暇の繰越は何日までか」という質問に対し、規程本文ではなく過去の社内通達が引用されてしまった — こうしたケースでは、モデルを変えるより「規程を正本として優先する」「通達は検索対象から外す」といった文書側の調整のほうが効きます。
進め方の現実的な順序
全社の文書を一度に整理しようとすると、たいてい頓挫します。おすすめしているのは次の順序です。
- 問い合わせが多い業務を一つ選ぶ（社内規程、製品仕様、業務マニュアルなど）
- その範囲の文書だけ、正本と権限を決めて一箇所にまとめる
- 小規模に RAG を構築し、想定質問セットで精度を確認する
- 運用しながら、更新フローが回るかを見る
- 回ることが確認できたら、次の業務領域に広げる
この進め方なら、文書整理の労力も検証範囲も限定でき、仮にうまくいかなくても損失が小さく済みます。
まとめ
RAG の導入検討では、どうしてもモデルやベクトルデータベースといった技術要素に目が向きがちです。しかし回答の質を左右するのは、その手前にある「何を、どこに、誰の権限で置いているか」という社内の情報管理の状態です。
裏を返せば、文書の正本と権限を決める作業は、AI を導入しなくても価値がある業務改善でもあります。RAG はその整理を進めるきっかけとして使うのが、中小企業にとって無理のない入り方だと考えています。
当社では、技術選定の前段として文書の棚卸しと権限設計の整理からご相談を承っています。どこから手をつけるべきか判断がつかない段階でも、現状を伺ったうえで進め方をご提案します。