社内文書をAIで使えるようにするデータ整備とは、散在する規程・議事録・マニュアルを棚卸しし、機密区分やフォーマット、メタデータを整えてRAGに投入できる状態にする作業を指します。情報システム部門やDX推進担当者が社内AIアシスタントを導入する際、まず何から手を付けるべきか迷う場面は少なくありません。本記事では、優先領域の選び方から更新運用の仕組み化までを実務目線で解説します。全文書を一度に整えようとすると作業が止まりがちですが、利用頻度の高い領域から着手することで、検索精度と導入スピードを両立させやすくなります。

RAGは検索と生成を組み合わせる仕組みです。そのため、投入する文書が古い、重複している、機密情報が混在しているといった状態のままでは、検索段階でノイズを引き当ててしまい、生成される回答も的外れになりやすいです。たとえば半年前に更新が止まった旧規程と最新版が同じフォルダに残っていると、AIはどちらを根拠にすべきか判断できず、古い情報を堂々と提示してしまうことがあります。整備不足は単なる見た目の問題ではなく、回答の信頼性そのものを左右します。まずは整備不足が具体的にどのような弊害を招くのか、順に見ていきます。

RAGは、質問文と文書の断片をベクトル化し、意味的な近さで検索して回答を生成する仕組みです。この検索の土台となるのが投入済みの文書そのものであり、モデルの性能をいくら高めても、元の文書が古い・重複している・表記が揺れていれば的確な断片を拾い出せません。検索エンジンにゴミを入れればゴミが出てくる、という関係がそのまま当てはまります。

同じ規程が改訂前と改訂後の2バージョンで残っていると、検索は両方を「関連度が近い」と判定してしまい、どちらを優先すべきか区別できません。Word・PDF・スキャン画像など形式が混在している場合はテキスト抽出の精度が文書ごとに変わり、同じ内容でも検索にかかりやすい文書とかかりにくい文書が生まれます。ファイル名や見出しだけでは文書の位置づけが分からないケースでは、検索が本文の字面の一致に依存しがちになり、言い換えた質問への対応力が落ちます。

これらはいずれも、文書を投入する前段の整備で解消できる問題です。実際、整備の初期段階でこうした揺れを取り除く作業は、後工程のチャンク分割や検索アルゴリズムの改善よりも検索精度への影響が大きいです。改訂履歴の統合、形式の統一、位置づけを示すメタ情報の付与——この3点を先に済ませておくかどうかで、同じRAGの仕組みでも検索結果の質は大きく変わってきます。文書側の土台を整えることが、AI活用の第一歩になります。

整備が不十分な状態でRAGを稼働させると、決まって同じような症状が現れます。

最も多いのが、旧版の規程やマニュアルを検索結果として返してしまうケースです。改訂前と改訂後の文書が両方ナレッジベースに残っていると、AIはどちらが有効かを判断できず、古い休暇規程や旧料率のまま回答することがあります。改訂日や有効期限のメタデータが付与されていない文書ほどこの症状が出やすく、特に人事・総務系の規程は年に数回の細かい改訂が入るため、旧版が消されずに残存しているケースが目立ちます。

次に多いのが、複数文書の内容が混ざった回答です。似た名称のファイルや、部門ごとに微妙に異なる手順書が並存していると、検索結果が断片的に組み合わされ、実際には存在しない手順が生成されることがあります。営業部の申請フローと管理部の申請フローが別ファイルで存在し、どちらも「申請手順」というタイトルで保存されている場合などが典型で、AIが両者の一部をつなぎ合わせて架空の手順を作り出してしまいます。

もっとも重大なのが、権限のない社員が見るべきでない人事評価や契約条件が回答に混入する事故です。機密区分が未整理のまま全文書を投入したことが原因で発生し、単なる回答精度の問題では済まず、情報漏えいという実害に直結します。役職員限りの人事評価シートや、取引先ごとに異なる契約条件の一覧などがナレッジベースに無区分で置かれていると、一般社員からの質問に対してその内容がそのまま引用されてしまう危険があります。

これら三つの症状に共通するのは、モデルの性能

全文書を一斉に整備しようとすると作業量が膨らみ、導入自体が止まりがちです。数百フォルダを一度に洗い出そうとして、結局どこも手つかずのまま数か月が過ぎるケースは少なくありません。優先すべきは利用頻度が高い領域と、AIに読ませてはいけない機密文書の見極めです。ここでは対象範囲を絞り込む視点を整理します。

全文書を棚卸し対象にすると作業が終わらないまま導入計画が停滞します。優先領域は「利用頻度」と「更新頻度」の二軸で絞り込むのが実務的です。

利用頻度が高い文書とは、問い合わせや検索が集中する領域を指します。就業規則、経費精算のルール、製品仕様書、よくある質問への回答集などが該当することが多く、ここを整備すると利用者が早期に効果を実感しやすくなります。逆に年に数回しか参照されない古い企画書や過去の会議資料は、後回しにしても業務への影響が小さいです。

更新頻度は別の観点で優先度を左右します。頻繁に改訂される規程やマニュアルは、整備しても短期間で内容が古くなるため、更新の仕組みが整っていない段階で投入すると誤情報の温床になりかねません。一方、法令や社内規程のように更新が少なく安定している文書は、一度整備すれば長く使えるため投資対効果が高いです。

この二軸を掛け合わせると、着手すべき順番が見えてきます。「利用頻度が高く更新頻度が低い」文書群は最優先領域であり、就業規則や社内規程の類がこれに当たることが多いです。「利用頻度は高いが更新頻度も高い」文書は、整備を急ぐよりも先に更新運用の仕組みを用意すべきであり、ここを飛ばして投入すると数ヶ月で内容が実態と食い違い、AIが古い情報を答えてしまう事態を招きます。逆に両方低い文書は、整備対象から一時的に外しても業務への影響はほとんどありません。まずは「利用頻度が高く更新頻度が低い」領域から着手し、成果を確認しながら範囲を広げていくのが現実的な進め方です。

文書整備で見落とされがちなのが、AIに読ませてはいけない文書の選別です。全文書をRAGに投入すると、本来は限られた人しか見られない情報まで検索結果に紛れ込む恐れがあります。鍵のかかる部屋の中身をすべて廊下に並べてしまうような状態であり、便利さと安全性が引き換えになりやすい領域といえます。

機密区分の設計では、まず「公開可」「社内限定」「特定部署限定」「アクセス禁止」のような段階を決め、文書ごとにラベルを付けます。人事評価や給与情報、取引先の契約条件、個人情報を含む文書は、原則としてAIに読ませない対象に置くのが安全です。個人に関する情報を扱う場合は、匿名加工情報や仮名加工情報に関するガイドラインが定める識別子の扱いを参考に、氏名や連絡先などを機械的に除去できるかどうかも判断軸になります。

規程やマニュアルのように社内全体で参照頻度が高い文書は公開区分にしやすいです。反対に、契約書や人事関連の文書は個別の事情によって機密度が揺れやすく、部署によって扱いの感覚が異なることも多いです。区分設計の初期段階では、こうした判断に迷う文書を一旦除外し、公開区分がはっきりしたものから投入を始めるという保守的な運用が現実的です。除外した文書は放置せず、誰がいつまでに区分を決めるかを決めておかないと、いつまでも「保留」のまま溜まっていくことになります。

区分ルールは一度決めて終わりではありません。部署異動や組織変更のたびに、担当が変わった文書の区分が古いまま残っていないかを見直す前提で設計しておくと、後の運用負荷を抑えられます。

棚卸しから検索テストまでを5段階に分けると、作業の抜け漏れを防ぎやすい。まず棚卸しと重複除去を行い、続いてフォーマット統一とメタデータ付与を進め、最後に検索テストで仕上げる。この順序を守ることで、途中で対象範囲がぶれるのを避けられる。特に最初の棚卸しで対象を絞り切れていないと、後工程すべてに手戻りが発生しやすいため、ここに時間をかける価値がある。次のH3から各ステップの具体的な進め方を順に見ていく。

棚卸しの第一歩は、対象領域に存在する文書を洗い出し、一覧化することです。ファイルサーバー、共有ドライブ、社内Wiki、メールの添付ファイルなど保管場所が分かれているケースは多く、まず「どこに何があるか」を可視化しないと整備の範囲が定まりません。

洗い出した文書は、タイトル・保管場所・最終更新日・作成部署を並べた棚卸しリストにまとめます。この段階で気づくのが、同じ規程が複数の場所に別名で保存されていたり、旧版と改訂版が両方残っていたりする状態です。実際に手を動かしてみると、「最新版だと思っていたファイルが実は3世代前だった」というケースにほぼ必ず遭遇します。担当者の記憶と実態がずれているのは珍しくありません。

重複や旧版をそのままRAGに投入すると、AIが古い情報と新しい情報を両方参照し、矛盾した回答を返す原因になります。ここが整備作業全体の中でも最も工数がかかる部分であり、判断を誤ると後工程のフォーマット統一やメタデータ付与がすべて手戻りになります。同一内容の文書は最終更新日が新しいものを残し、他は削除またはアーカイブ扱いにします。発効日や改訂履歴が記載されていない文書は、担当部署に現行版かどうかを確認します。個人のPC内にしかない文書は、正式な管理対象かどうかをこの段階で判断する必要があります。特に個人PC由来の文書は、作成者本人しか経緯を知らないことが多く、確認を後回しにすると誰も判断できなくなります。

この棚卸しと除去を先に済ませておくことで、次のフォーマット統一やメタデータ付与の作業対象を絞り込めます。逆に言えば、ここを丁寧にやらないまま次工程に進むと、整備全体をやり直す羽目になります。

棚卸しが終わった文書は、まずフォーマットを統一します。Word、PDF、パワーポイント、スキャン画像が混在した状態のままRAGに投入すると、テキスト抽出の精度がファイル形式ごとに変わり、同じ内容でも検索に引っかかる文書とヒットしない文書が生まれます。テキスト主体の文書はPDFまたはプレーンテキストに統一し、表や図が多い文書は構造を保てる形式を選ぶと安定します。

ここで手を抜きやすいのがメタデータ付与ですが、実際に検索精度を左右するのはファイル形式よりもこちらです。タイトル・部門・発効日・機密区分・文書種別といった項目を各文書に付与しておけば、検索結果の絞り込みや回答の根拠表示が格段にしやすくなります。発効日は後述する規程・マニュアルの版管理と直結する項目なので、この段階で入力ルールを決めておくと後工程の手直しが減ります。項目は欲張らず5つ程度に絞るのが現実的で、増やすほど入力漏れが増え、整備自体が滞る原因になります。

テキスト分割やチャンク設計の詳細は、ラオス語対応 AI チャットボットの作り方で扱っている内容も参考になります。

文書整備が完了した段階で終わりにせず、実際にRAGへ投入して検索テストを行う工程が欠かせません。整備した文書が検索エンジンやAIから正しく引き出せるかは、実際に質問を投げてみるまで分かりません。

テストの方法は単純です。現場でよく聞かれる質問を10〜20問程度リストアップし、実際にAIへ入力して回答を確認します。想定する回答が返ってくるか、根拠として引用された文書が正しいか、古い版や重複文書が混入していないかを一つずつ確認します。

回答が的外れな場合、原因は主に3パターンに分かれます。文書自体に必要な情報がない場合は追加整備が必要です。情報はあるのに検索に引っかからない場合は、メタデータやタイトルの見直しが有効です。情報も検索も問題ないのに回答が不正確な場合は、検索アルゴリズム側の調整が必要になることがあります。

このうち検索アルゴリズムの精度改善は、文書整備とは別の専門領域です。ハイブリッド検索やリランキングといった手法の詳細は、検索精度を改善するハイブリッド検索の記事で扱っているため、本記事では文書側の準備が整っているかの確認に留めます。テストで洗い出した課題は、優先領域を広げる際の改善リストとして蓄積しておくと、次の棚卸しサイクルで役立ちます。

文書の種類によって、注意すべき整備ポイントは異なります。規程・マニュアル、議事録・日報、スキャンPDFの3タイプについて、それぞれで見落としやすい落とし穴を確認しておきましょう。

規程やマニュアルは改訂が繰り返される文書であり、RAGに投入する際は「どの版が最新か」を明確にしておくことが欠かせません。最初は最新版だけをフォルダに残せば十分と考えがちですが、実際は旧版を完全に削除するより、発効日と失効日をメタデータとして残したまま検索対象から除外するほうが効きます。改訂履歴の追跡や、過去の運用根拠を確認したいという問い合わせに対応できなくなるためです。

具体的には、ファイル名やメタデータに「発効日」「版番号」「承認者」「改訂理由」を必ず含める運用が有効です。例えば就業規則であれば、施行日が明記されていない版をAIが参照すると、すでに廃止された休暇制度を回答してしまうケースが起こり得ます。改訂前後で内容が矛盾する条文がある場合は、旧版に「参照不可」のタグを付け、検索インデックスから物理的に外す運用が望ましいです。

また、規程は部門ごとに独自のローカルルールが存在することも多く、全社規程とローカル規程を区別するタグ付けも重要です。版管理のルールを整えておくことで、AIが常に有効な規程だけを根拠として回答できる状態を維持できます。

議事録や日報は、規程やマニュアルと違って作成者ごとに書式や粒度がばらつきやすく、個人名・評価コメント・取引先情報がそのまま記載されているケースが少なくありません。人事評価に関する発言や、特定の顧客への不満・クレーム内容が議事録に残っていると、AIが検索結果として無関係な質問にまで引用してしまう恐れがあります。

整備の際は、まず記載内容を「業務上の決定事項」と「個人の発言・評価」に分けて考えることが有効です。決定事項はナレッジとして価値がありますが、発言録や個人評価はRAGに投入する必要性が低い場合が多く、機密区分を分けて除外する判断が求められます。

日報も同様に、個人の勤怠や体調に関するメモが混在しやすい文書です。氏名や顧客名が本文に含まれる場合は、匿名加工情報に関するガイドラインが示す考え方を参考に、投入前にマスキングや要約への置き換えを検討します。個人情報保護委員会のガイドラインでは、特定の個人を識別できないように加工した情報を作成した場合、含まれる情報の項目を公表する義務が定められており、社内文書でも同様に「どの情報を残し、どの情報を落とすか」を明文化しておくと運用がぶれません。

議事録・日報は更新頻度が高い一方で再利用価値が低いものも多いため、全件を整備対象にせず、社内規程の根拠になり得るものだけを選別する運用が実務的です。

紙の規程集や過去の申請書をスキャンしたPDF、写真で撮影した掲示物などは、そのままRAGに投入しても文字として認識されず、検索に一切ヒットしないケースがあります。OCR（光学文字認識）で テキスト化してから初めて、検索対象として機能する状態になります。

ここで見落とされやすいのが、OCR処理後の品質確認です。OCRは手書き文字、罫線が多い表組み、かすれた印影付近の文字を誤認識しやすい傾向があります。「日」を「目」、「1」を「l」と読み違えるような誤変換が起きると、検索キーワードと本文の文字列が一致せず、該当文書が検索結果に出てこなくなります。

対策としては、OCR処理後のテキストを目視でサンプル確認し、重要な数値・日付・固有名詞が正しく変換されているかをチェックする工程を組み込むことが有効です。特に契約書の金額欄や日付欄など、誤りが業務判断に影響する箇所は優先的に確認します。

古いスキャン機材で作成した低解像度PDFは再スキャンを検討し、可能であれば元の電子データを探して差し替えるほうが、OCR精度を上げる工数より効率的な場合もあります。

文書整備は一度きりの作業ではありません。棚卸し直後の状態を維持するには、更新責任者の設置と定期的な見直しサイクル、そして原本とAI側データの同期の仕組みが欠かせません。ここでは運用を継続させる体制づくりを解説します。

文書整備は一度整えても、担当者が変わり更新が止まれば数か月で劣化します。整備を維持する仕組みとして欠かせないのが、更新責任者の明確化と棚卸しサイクルの設定です。

責任者は文書ごとに「誰が正しさを保証するか」を1人に絞ることが基本です。規程類は総務・人事部門、業務マニュアルは各現場のリーダーなど、実際にその文書を使い、変更を把握できる立場の人が適任です。情報システム部門がすべての内容を把握して更新するのは現実的ではなく、内容の正確性は業務側、フォーマットやメタデータの整合性は情報システム側という役割分担が機能しやすい傾向があります。

棚卸しサイクルは文書の更新頻度に応じて分けるのが実務的です。

• 規程・マニュアルなど改定が少ない文書: 半期〜年1回の棚卸し
• 議事録・FAQ・手順書など更新が多い文書: 月次〜四半期での確認
• 法令や社内制度の変更が絡む文書: 変更発生時に都度更新

サイクルを決めずに「気づいたら直す」運用にすると、旧版が残り続け、AIが古い情報を回答する原因になります。棚卸しの結果は簡単な台帳やチェックリストで記録し、次回の担当者が状況を追えるようにしておくことが、整備状態を長期的に保つ土台になります。

原本の文書を更新しても、RAGが参照するインデックスが自動更新されなければ、AIは古い内容を答え続けます。原本と検索用データのあいだに同期の仕組みを組み込むことが、この節の論点です。

理想は、文書格納場所の変更を検知して自動で再インデックスするパイプラインです。クラウドストレージやナレッジ管理システムの更新イベントをトリガーにして、追加・修正・削除を差分反映する構成にすると、手作業の反映漏れを防げます。自動化が難しい場合は、更新頻度に応じた定期バッチ処理でも代用できますが、反映までの時間差（例えば日次バッチなら最大1日）を利用者に周知しておく必要があります。

注意すべきは、削除の同期です。原本を削除・非公開にしても検索用データ側に残っていると、AIが失効した情報を根拠に回答してしまいます。追加・更新だけでなく削除も含めた双方向の同期を設計することが欠かせません。

テキスト分割やインデックス構造そのものの設計については、ラオス語対応 AI チャットボットの作り方 — 低リソース言語×RAG で実用レベルを実現するで詳しく解説しています。

文書整備の現場では、完璧主義による停滞と、整備後の同期切れによる劣化という二つの失敗が繰り返し見られます。どちらも進め方を少し変えるだけで回避できます。次のH3で原因と対策を具体的に整理します。

情報システム部門が全文書の完璧な整備を目指すと、着手前の計画段階だけで数か月が過ぎてしまうケースが見られます。対象文書が数百から数千に及ぶ組織では、機密区分の判定やメタデータ付与を一斉に終えようとすると、判断基準の調整や関係部署への確認に時間がかかり、検索テストにすら到達しません。

この壁を越える現場では、完璧さより着手の速さを優先する判断が効いています。全文書ではなく、利用頻度の高い一部の規程やマニュアルだけを対象に棚卸しと機密区分を終え、先に検索テストへ進める進め方です。実際に検索させてみると、想定していなかった表記揺れや旧版の混入が見つかり、後工程の基準づくりにそのまま反映できます。

判断軸としては、対象文書が数十件程度の小規模な部門であれば範囲を絞らず一括整備でも進められますが、複数部門にまたがり数百件を超える場合は、優先領域を決めて段階的に広げる方が導入が止まりにくくなります。整備計画を先に固めすぎず、小さく検証してから拡張する順序が、結果として整備の完成度も高めます。

文書整備を一度実施しても、その後の運用でRAGとの同期が切れると、検索精度は徐々に劣化します。典型的なのは、原本の文書を更新したにもかかわらず、RAGに投入済みのインデックスやベクトルデータが古いまま放置されるケースです。この場合、AIは更新前の内容を正解として回答し続けてしまいます。

同期切れが起きやすい場面は、いくつかの条件に分けて考えると分かりやすくなります。

• 手動でRAGに文書を再投入する運用の場合、担当者が更新を忘れると即座にずれが生じます
• フォルダ連携や自動クロールの仕組みがある場合でも、対象フォルダの範囲外に文書が移動・保存されると取り込まれません
• 文書を削除・統合した際に、旧バージョンのインデックスだけが残り、重複回答の原因になります

対策としては、更新のたびに再投入する運用ではなく、文書の保存場所とRAGの取り込み対象を一致させ、更新検知から反映までを自動化する仕組みを組み込むことが有効です。テキスト分割や検索側の精度改善は別の観点であり、エンタープライズRAGを本番運用に乗せるで扱う設計判断とも関わってきますが、ここではまず「原本とRAGの状態が常に一致しているか」を定期的に確認する運用そのものが劣化防止の起点になる、という点を押さえておく必要があります。

Q1. 社内文書の整備はどこから始めればよいですか？ 全文書を一度に整備するのではなく、利用頻度が高く更新頻度も高い領域から着手するのが効率的です。問い合わせが多い規程やマニュアルを優先し、棚卸しと機密区分を先に済ませてから、フォーマット統一とメタデータ付与に進む順序が実務上扱いやすい傾向があります。

Q2. 機密文書はRAGに投入できませんか？ 機密区分によって扱いが変わります。個人情報や人事情報を含む文書は匿名加工やアクセス制御を前提に検討する必要があり、投入対象から外すか、参照範囲を限定した専用領域に分ける運用が現実的です。区分の設計自体は棚卸しの段階で決めておくべき事項です。

Q3. スキャンPDFやOCR文書も整備対象にすべきですか？ OCRの精度が低い文書はそのまま投入すると誤った回答の原因になりやすいため、テキスト化の品質確認を先に行う必要があります。読み取り誤りが多い文書は優先度を下げ、頻度の高い文書から電子化し直す判断も選択肢になります。

Q4. 整備した文書はどのくらいの頻度で見直すべきですか？ 更新頻度が高い規程やマニュアルは、変更が発生した都度AI側の参照データも更新する仕組みが望ましいです。更新頻度が低い文書は定期棚卸しのサイクルに合わせて確認する程度でよく、文書の性質によって見直し頻度を分けるのが実務的です。

Q5. テキスト分割や検索精度の改善は本記事の範囲に含まれますか？ 本記事は投入前の文書整備に特化しており、チャンク分割の設計はラオス語対応 AI チャットボットの作り方 — 低リソース言語×RAG で実用レベルを実現する、検索精度の改善手法はエンタープライズRAGを本番運用に乗せる — ラオス語チャットボットで実証したAgentic RAG と Hybrid検索の実装パターンで詳しく解説しています。

社内文書をAIで使えるようにする整備は、全文書を対象にした一括プロジェクトではありません。利用頻度の高い領域から棚卸しし、機密区分とフォーマットを整え、検索テストで確認しながら範囲を広げるほうが、導入までの時間も検証の質も安定します。

完璧な整備を目指して着手が遅れるより、優先領域だけを整えて早めに検索テストへ進み、回答の外れ方から不足を洗い出すほうが実務的です。整備が止まる最大の要因は「全部やってから始める」という発想そのものにあります。

整備後は、更新責任者と棚卸しサイクルを決め、文書の修正がナレッジベースに反映される同期の仕組みを維持することが欠かせません。同期が切れれば、整えた文書もすぐに劣化します。テキスト分割や検索精度の改善など投入後の技術的な最適化は、目的に応じて別の専門的な手順に委ねる領域です。まずは小さく整え、検索テストで品質を確認しながら、対象範囲と運用体制を段階的に広げていくことが、ナレッジベース構築を成功させる現実的な進め方です。