社内規程や過去案件をRAGで検索できるようにするには、何から始めればいいですか？
文書の棚卸しから始めます。ベクトル検索の精度チューニングは最後です。
RAG（検索拡張生成）とは、社内文書を検索して見つけた本文をAIに読ませ、その内容に基づいて回答を生成させる仕組みです。裏を返せば、検索でヒットした文書が古ければ、AIは古い内容を自信を持って回答します。
不動産・建設会社の共有サーバには、ほぼ例外なく次のものが混在しています。
重要事項説明書_ひな形_最新.docxと重要事項説明書_ひな形_最新2_修正版.docx- 部署フォルダと、退職者の個人フォルダのコピー
- 現場ごとに命名規則が違う施工計画書（
○○様邸_計画書/20220711_計画/計画書_田中） - 原本が紙で、スキャンPDFしか残っていない要領書
_old_backup旧フォルダに退避された前年度版
この状態のフォルダをまるごとベクトル化すると、検索は「文言が近いもの」を返します。日付の新旧は判断してくれません。 結果として「古い規程が正解として返る」事故が起きます。
エクサテックが株式会社イーリアルティ様に転記エージェントを構築したときも、業務マニュアルが未整備の状態からのスタートでした。契約の前段階から何度も現場に足を運び、困りごとを理解するところから着手しています。社内ナレッジのRAG化も同じで、整った文書があることを前提にした設計は、現場では成立しません。
工程は次の順で進めます。
| 工程 | やること | 完了条件 |
|---|---|---|
| 1. 棚卸し | 対象フォルダの文書を一覧化 | 文書名・保管場所・最終更新日・作成部署が埋まった表ができる |
| 2. 選別 | RAG対象／対象外を仕分け | 全フォルダが「対象」「対象外」のどちらかに分類済み |
| 3. 正本決定 | 同名文書を1つに絞る | 同じ内容の文書が2つ以上残っていない |
| 4. メタデータ付与 | 発効日・所管部署・根拠法令を付ける | 全対象文書にメタデータあり |
| 5. 責任者設定 | 文書群ごとに更新責任者を個人名で決める | 責任者不明の文書がゼロ |
| 6. 実装・精度調整 | 分割単位、OCR、ハイブリッド検索の調整 | 想定質問に対する回答が原本と一致 |
工程1〜5は情シスではなく、業務部門が主体になります。ここを飛ばして工程6から入るプロジェクトは、ほぼ確実に「AIが間違ったことを言うから使わない」で終わります。
なぜ「古い規程が正解として返る」事故が起きるのですか？
ベクトル検索は意味の近さで文書を選ぶため、改訂前後の文書はどちらも高スコアで並ぶからです。
改訂版と旧版は、文言の9割が同じです。だからこそ意味的距離が近く、検索結果として両方が上位に来ます。AIは提示された両方を読み、どちらかを採用するか、悪い場合は混ぜて回答します。
実務で被害が出やすいのは、法令・基準に紐づく文書です。
例1：重要事項説明書のひな形
宅地建物取引業法第35条は重要事項の説明について定めており、第5項では重要事項説明書への宅地建物取引士の記名が求められます。2022年5月18日の法改正で押印は不要となり、現在は「記名」のみです。「記名押印」と書かれた改訂前のひな形や社内手引きが共有サーバに残っていれば、RAGはそれを引いて古い運用を回答します（法令解釈の詳細は個別に専門家へご確認ください）。
例2：工事写真の管理基準
国土交通省「デジタル写真管理情報基準」の最新版は令和5年3月（2023年3月）です。社内の写真整理マニュアルが旧版の基準を引き写したままだと、RAGは旧版の分類ルールを返します。この基準では写真を「写真区分 → 工種 → 種別 → 細別」の階層で管理し、入力の要否は写真区分によって異なります。基準への適合可否を最終的に判断するのは発注者・監督員であり、社内文書の記述はあくまで社内の運用整理です。
例3：時間外労働の社内資料
建設業には2024年4月1日から時間外労働の上限規制が全面適用されました（それ以前は適用猶予）。原則は月45時間・年360時間、特別条項がある場合も年720時間以内などの上限があります。猶予期間中に作られた社内説明資料が残っていると、RAGは「建設業は上限規制の適用が猶予されている」と回答しかねません。36協定の具体的な運用は社労士等にご確認ください。
いずれも、技術的なチューニングでは防げません。旧版が検索対象に含まれていることが原因だからです。
RAGに載せる文書と載せない文書は、どう切り分けますか？
次の3つをすべて満たす文書だけを載せます。
- 承認プロセスを経ているか（誰かが内容を確認して発行したか）
- 更新責任者を個人名で特定できるか
- 誤って引用された場合の被害を受容できるか
この基準でフォルダ単位に仕分けます。ファイル単位でやると終わりません。
| フォルダ・文書種別 | 判断 | 理由 |
|---|---|---|
| 承認済みの社内規程・要領書 | 載せる | 承認プロセスあり、所管部署が明確 |
| 業務マニュアル（最新版） | 載せる | 更新責任者を置きやすい |
| 完成した物件資料・竣工図書の説明文 | 載せる | 確定情報。ただし個人情報の除去が前提 |
| 社内FAQ・過去の問い合わせ回答 | 載せる | 質問と回答の対で、検索と相性が良い |
| 個人フォルダ | 載せない | 承認前の私的メモが混在。責任者を置けない |
_old _backup 旧 配下 |
載せない | 定義上、旧版だけが入っている |
| 見積・図面の途中版 | 載せない | 確定値と区別できず、誤引用の被害が大きい |
| 契約書原本のスキャン | 原則載せない | 個人情報・取引条件。閲覧権限の管理が別途必要 |
| 給与・人事評価関連 | 載せない | 権限分離をRAG側で完全に担保するのは難しい |
| メールのアーカイブ | 載せない | 交渉途中の条件が確定情報として返るリスク |
| 工事写真の生データ・CAD | 載せない | テキストではなく、RAGの対象外 |
「とりあえず全部入れて、後から除外する」は最悪の進め方です。一度でも誤った回答を返したRAGは、現場から信用されなくなり、その後どれだけ精度を上げても使われません。 対象は狭く始め、使われている実感が出てから広げます。
「正本」はどうやって決めますか？
同じ内容の文書が2つ以上存在しない状態を作り、ファイル名とメタデータで発効日を機械可読にします。
手順は次の通りです。
① 棚卸し表を作る
列は「文書名／保管場所（フルパス）／最終更新日／作成部署／根拠となる法令・基準／備考」。最終更新日はファイルのタイムスタンプではなく、文書内に書かれた改訂日を採ります。コピーで移動したファイルはタイムスタンプが当てになりません。
② 同名・類似名の文書を突合する
最新 最新2 修正版 rev コピー を含むファイル名を機械的に抽出し、中身を並べて比較します。ここは所管部署の担当者にしか判断できません。
③ 正本を1つに絞り、命名規約を決める
例：規程番号_文書名_v版番号_発効日.pdf（AD-012_重要事項説明業務手順_v3_20250401.pdf）。版番号と発効日をファイル名に持たせると、検索結果の見た目だけで新旧が判別できます。
④ 非正本は「削除」ではなく「移動」する
RAG対象外のアーカイブ領域に物理的に移します。削除すると現場が抵抗しますし、監査上残す必要がある文書もあります。RAGの対象は「削除したかどうか」ではなく「どのフォルダにあるか」で決まる設計にしておくと、後からの復元も除外も簡単です。
⑤ メタデータを付与する
最低限、次の5項目です。
- 発効日
- 失効日（次回改訂予定日でも可）
- 所管部署
- 更新責任者（個人名）
- 根拠となる法令・基準とその版（例：デジタル写真管理情報基準 令和5年3月）
失効日を持たせておくと、検索時に「失効日を過ぎた文書は除外」というフィルタをかけられます。旧版を検索から落とす仕組みは、精度チューニングではなくメタデータで実現します。
更新責任者は誰に置くべきですか？
部署ではなく、個人名で置きます。 「総務部」に置くと誰も動きません。
文書群ごとの割り当ての考え方は次の通りです。
| 文書群 | 責任者の適任 | 更新のトリガー |
|---|---|---|
| 社内規程・就業関連 | 総務・管理部門の担当者 | 法改正、社内制度変更 |
| 宅建業法に関わる書式・手引き | 宅地建物取引士の有資格者 | 法令・様式改正 |
| 施工要領・安全書類の様式 | 工事部門の主任技術者クラス | 発注者要領の改訂、基準改訂 |
| 積算・歩掛・原価の社内資料 | 積算担当 | 単価改定、年度切替 |
| 物件資料・マイソクの作成手順 | 営業事務のリーダー | ポータル仕様変更、社内運用変更 |
そのうえで、運用ルールを2つ決めます。
ルール1：四半期に一度、棚卸し表をレビューする
全文書を読み直す必要はありません。「発効日から一定期間が経った文書」と「根拠法令が改正された文書」だけを見ます。
ルール2：RAGの回答ログをレビュー材料にする
– 「文書内に該当する記述が見つかりませんでした」と返った質問 → 文書が存在しない、または対象フォルダに入っていない
– 同じ質問が繰り返し投げられている → その文書が探しにくい、または内容が不明瞭
回答ログは、社内文書の欠落マップとして機能します。 RAGを入れる副次的な効果として、これが一番大きいことも珍しくありません。
検索精度は、技術的にどうチューニングしますか？
ガバナンスが決まってから着手します。実装側で効いた順に挙げます。
1. 分割（チャンク）単位を文書構造に合わせる
規程は条・項の単位で切ります。固定文字数で機械的に切ると、条文の途中で分断されて「ただし書き」だけが検索に引っかかる事故が起きます。表を含むPDFは、表をまたいで切らないようページ単位で扱います。
2. スキャンPDFはOCRを通し、失敗したものは対象から外す
手書きの注記、青焼き、傾いたスキャンはOCR精度が落ちます。読めなかった文書を「読めたことにして」載せるのが最悪です。OCR結果を目視サンプリングし、精度が出ないものは対象外にして原本参照の運用にします。
3. キーワード検索とベクトル検索を併用する
「35条」「グリーンファイル」「歩掛」のような固有語は、ベクトル検索だけだと取りこぼします。キーワード一致とベクトル検索を組み合わせ、結果を統合します。
4. メタデータでフィルタする
検索時に「失効日 > 今日」「所管部署 = 工事部」といった条件で絞ります。工程4で付けたメタデータがここで効きます。
5. 回答には必ず出典を出す
最低限、ファイル名・ページ番号・発効日・原本へのリンクの4点です。出典が出ない回答は、現場では使えません。「AIがそう言った」では稟議も現場判断も通らないからです。
6. 「わからない」と答えさせる
検索でヒットしなかった場合に、AIが一般知識で答えてしまうと最も危険です。社内文書に記述がなければ「該当する社内文書が見つかりません」と返す設計にします。これは精度を下げる調整ではなく、信用を守る調整です。
RAGでできないこと・限界はどこですか？
導入前に社内で合意しておくべき限界です。
- 法令解釈の断定はできません。 宅建業法・建設業法に関わる判断は、RAGが返した社内文書を人が読み、必要に応じて専門家に確認する前提で運用してください。RAGが返すのは「社内文書にこう書いてある」であって「法的にこうである」ではありません。
- 法改正に自動追随しません。 社内文書が差し替わるまで、RAGは旧内容を返し続けます。追随させるのは人の仕事です。
- 図面・CADは読めません。 数量拾いや納まりの確認には使えません。索引テキストを別途作り、原本は人が開く設計にします。
- 「似た現場」の判断はできません。 検索できるのは文言が似た案件です。地盤条件・近隣状況・工程制約が近いかどうかは、文書に書かれていなければ判断材料になりません。類似案件の抽出は、物件属性を構造化データとして別に持つ必要があります。
- 文書化されていない暗黙知は出てきません。 ベテランが頭の中でやっている判断は、載っていない以上、絶対に返りません。RAGは知識の作成装置ではなく、検索装置です。
- 原本の内容が正しいことは保証しません。 誤りのある社内文書を載せれば、誤りが正確に検索されます。
- 細かい権限分離は不得意です。 「この部署だけ閲覧可」を厳密に担保するには、検索インデックス自体を分ける設計が必要です。人事・給与情報を安易に載せない理由はここにあります。
まとめ
- RAGの成否は、埋め込みモデルやチャンクサイズより文書ガバナンスで決まる。棚卸し → 選別 → 正本決定 → メタデータ付与 → 責任者設定 → 実装、の順を守る。
- 「古い規程が正解として返る」原因は、旧版が検索対象に含まれていること。技術で防ぐのではなく、対象フォルダから物理的に外す。
- 載せる文書の判断基準は「承認プロセスを経ているか」「更新責任者を個人名で特定できるか」「誤引用の被害を受容できるか」の3点。
- 更新責任者は部署ではなく個人名で置き、法改正と年度切替をトリガーに四半期レビューを回す。RAGの回答ログは文書欠落の発見に使える。
- 回答にはファイル名・ページ・発効日・原本リンクを必ず表示し、社内文書に記述がなければ「見つかりません」と返させる。
ご相談について
エクサテックは、不動産・建設の現場に入り込み、仕組みの設計からWebアプリの構築までを同一チームで担当しています。社内ナレッジのRAG化は、「どのフォルダから外すか」を決めるところが最初の山です。
共有サーバの状態が整っていない段階からのご相談で構いません。現状のフォルダ構成を拝見しながら、どこから着手するのが現実的かを一緒に整理します。
