結論: RAG は整った文書を前提に設計された仕組みであり、 分類・更新・権限が曖昧なまま投入すると、 古い情報や顧問先資料の混在が回答に表れます。
2019年マニュアルが 2026年の回答に混ざる構図
2024 年から 2025 年にかけて、 国内のいくつかの企業情報漏えい事例で、 社内検索 AI 経由で「公開すべきでないファイル」 が他部署の検索結果に表面化したという事案が断片的に報じられています。 経路はさまざまですが、 共通項として「文書のアクセス権限の整理が、 社内検索 AI の導入前に追いついていなかった」 という構造が観察されます。
士業事務所でも、 「過去の議事録や所内マニュアルをまとめて AI で検索できるようにしたい」 というテーマで RAG (Retrieval Augmented Generation) を検討する局面が出始めています。 大手プロバイダの提供する業務統合型 AI アシスタント、 ナレッジ管理向けの SaaS、 自前で組む RAG ——選択肢はここ数年で一気に増えました。 「ChatGPT に毎回コピペするのが面倒です」「所内に散らばっているナレッジを一発で引きたいです」 という動機は健全で、 方向性として間違っていません。
一方、 実際に導入を進めると「期待していた回答が返ってこない」「明らかに古い情報がヒットする」「顧問先 A の話を聞いていたら顧問先 B の資料が出てきた」 といった事象が発生し、 立ち上げ後数か月で稼働が止まるケースも観察されています。 原因の多くは AI 側ではなく、 検索対象として読み込ませた文書側にあります。 RAG は「すでに整っているデータベース」 を前提に設計された仕組みであり、 「とりあえず全部のフォルダを食わせれば良い感じに整理してくれる」 道具ではないという認識が出発点になります。
RAG が依存している前提
RAG は、 利用者の質問に対して、 (1) あらかじめベクトル化しておいた文書群から関連箇所を検索し、 (2) 検索結果を LLM のプロンプトに添えて回答を生成するという 2 段階の仕組みです。 LLM 単体では「学習データに含まれない最新情報」「事務所固有の情報」 には答えられませんが、 RAG を挟むことで「事務所のドライブにある資料に基づいて回答する」 運用が可能になります。
ここで押さえておきたいのは、 回答品質が「検索ステップで適切な根拠文書が拾えるか」 に強く依存する点です。 検索で誤った文書を拾ってしまえば、 LLM はその誤った前提で自信を持って回答を組み立てます。 RAG は「検索の精度」 と「文書の品質」 が同じくらい重要な仕組みであるという構造を最初に押さえておきたいところです。
整っていない文書を投入した場合に起きること
整っていない文書を RAG に投入すると、 典型的に次のような事象が発生します。
古い情報が回答に混ざります 2019 年の所内マニュアル、 改正前の税制に基づく解説メモ、 退職した職員が下書きで残した議事録など、 「いつの情報か」 が判別できない状態で混ざっていると、 検索ステップで新旧を区別できません。 LLM は出てきた文書を疑わず回答に組み込むので、 利用者には「もっともらしい古い情報」 が返ってきてしまいます。
矛盾する内容が同じ確度で扱われます ひな形 A と ひな形 B、 所長メモと職員メモ、 社内勉強会の発表資料と公式マニュアル ——同じテーマで複数バージョンが残っていると、 検索結果も矛盾したまま LLM に渡ります。 LLM はそれらしく折衷した回答を作るので、 現場では「結局どっちが正しいのか分からない回答」 が返ってきてしまいます。
権限を超えた情報が出ます 顧問先 A の業務メモが、 顧問先 B 担当の職員の質問に対して出てきてしまうというのは設計上は防げる事象ですが、 「フォルダ権限を整理せずに全部の Drive を RAG に食わせた」 場合に起きやすい構造です。 守秘義務上、 顧問先間で見せてはいけない情報が混ざる状態は、 AI 導入というより情報管理そのものの設計の見直し対象になります。
機微情報がベンダー側のログに残ります 利用するサービスのプランによっては、 入力されたプロンプトや検索対象の文書が学習やログとしてベンダー側に保持される設定になっている場合があります。 たとえば一部の大手プロバイダの法人向けプランでは、 プロンプト・応答・データソース経由で取得したデータが基盤モデルの学習には使われないと公式情報で明示されています。 一方で、 これは特定プランの仕様であり、 すべての RAG ツール・すべてのプランで同じとは限りません。 契約前にベンダーの公式ページで確認することが前提になります。
文書整理の 6 軸
「では何を整えればよいか」 を 6 軸で整理しておきたいと思います。 すべてを一気に完成させる必要はなく、 「自分たちの文書がどの軸でどれくらい弱いか」 を点検する目線として使うのが現実的です。
1. 分類 (カテゴリ・タグ) 業務領域 (税務 / 労務 / 登記 / 顧問先別)、 文書種別 (マニュアル / 議事録 / ひな形 / 個人メモ)、 信頼度 (公式 / 下書き / 個人見解) が、 フォルダ構造かタグで区別できる状態にしておきたいところです。
2. 更新 (日付・有効期限) 作成日と最終更新日が分かることが前提です。 さらに「いつまで有効か」「税制改正で失効したか」 というステータスが明示できると、 古い情報が混ざるリスクを大きく減らせます。
3. 権限 (誰が見てよいか) ファイル単位・フォルダ単位で、 誰がアクセスできるかが整理されている状態を指します。 大手プロバイダの法人向け AI サービスでは、 利用者の元々のアクセス権限が AI の回答にも引き継がれる設計が一般的になっています。 元のフォルダ権限が雑なままだと、 AI を通しても雑なまま機微情報が露出する構造になります。
4. 引用元 (出典・根拠) 文書内の主張が何を根拠にしているかが書かれている状態を指します。 法令引用・公式ガイドライン引用・所内判断であることが区別できると、 AI 回答の信頼度評価が容易になります。
5. 形式 (機械可読性) スキャン画像のみの PDF、 文字認識されていない FAX、 複雑な Excel 結合セル ——これらは RAG の検索ステップで「中身を理解できない」 状態になります。 テキスト化された PDF・Word・Markdown 等にしておくことが前提になります。
6. 暗号化・保管 (機微情報の扱い) マイナンバー・口座情報・特定個人情報を含む文書は、 そもそも RAG の検索対象に入れるべきかから議論が必要です。 入れる場合でも、 テナント分離・アクセスログ・保持期間設定など、 ベンダー側のデータ取り扱いを確認しておく必要があります。
この 6 軸は「全部 100% やれ」 ではなく、 「自分たちの文書が各軸でどれくらいの状態か」 をスコア化する道具として使うのがおすすめです。
棚卸ししないと見えない文書
文書整理を始めると、 「見えていなかった文書」 が次々と出てきます。 RAG 投入前に必ず棚卸ししておきたい代表例を 3 つ挙げておきます。
顧問先別フォルダの混在 顧問先 A の業務メモが、 所内の共有フォルダに置きっぱなしになっている、 あるいは複数顧問先の情報が同じファイルに同居しているケースがあります。 RAG 設計の前に、 「顧問先単位で物理的に分離されているか」「アクセス権限がプロジェクト単位で設定されているか」 を確認する必要があります。
退職者作成の議事録・メモ 退職した職員の議事録・下書き・個人メモが、 共有フォルダに残ったままになっていることがあります。 内容の正確性が担保されていない、 責任の所在が不明、 最新の所内判断と矛盾するという性質を持つことが多く、 そのまま RAG に投入すると後から検証コストがかかります。
古いひな形・改正前の解説資料 税制改正・労働基準法改正・登記制度改正のたびに、 過去のひな形は使えなくなります。 「念のため残してある」 フォルダに眠っていると、 検索結果で同じ確度で表示されてしまいます。 改正前ひな形は「アーカイブ」 として明示的にフォルダを分けるか、 ファイル名・先頭に「旧版」「YYYY時点」 を入れて区別する運用が現実的です。
守秘義務・規約の論点
文書整理は「使いやすくする話」 ではなく、 セキュリティとコンプライアンスの中核にあります。
個人情報保護委員会は 2023 年 6 月 2 日付の「生成AIサービスの利用に関する注意喚起等について」 で、 生成AIサービス利用時の個人情報の取り扱いに関する注意点を公表しています。 利用者側が「入力する情報の範囲」 と「サービス提供者側でのデータ取り扱い」 を理解した上で利用することを促す内容です。 RAG は「事務所のドライブ全体を AI に渡す」 性質を持つため、 注意喚起の趣旨を踏まえると、 何を渡し、 何を渡さないかの設計を導入前に決めておく必要があります。
具体的に整理しておきたい論点は次のとおりです。
- 顧問先データの扱い: 顧問先との契約上、 第三者 (クラウドベンダー含む) にデータを渡す前に明示同意・通知が必要かを確認しておきたいです
- 特定個人情報 (マイナンバー): 番号法上、 利用目的に必要な範囲を超えた取り扱いは制限されます。 RAG の検索対象に入れるかは個別に判断します
- 守秘義務: 弁護士法・税理士法・社労士法などの守秘義務条項との整合性を確認しておきたいです
- ベンダー側のデータ取り扱い: 学習除外・データ保持期間・テナント分離・暗号化・監査ログの仕様を、 契約前にベンダー公式ドキュメントで確認しておきたいです
大手プロバイダの法人向け AI サービスでは、 暗号化・テナント分離・機密ラベルの継承・保持ポリシーの適用・監査ログ提供などが公式に整理されています。 ただしこれらはベンダー側で用意された機能であり、 自社の運用に組み込まれていることはまた別の話です。 機能の存在と運用への組み込みを切り分けて点検しておきたいところです。
視点の置きどころ
RAG の評価は「賢いかどうか」 ではなく「整った文書を前提にできているか」 で行うというのが本稿で伝えたい主張です。 一方で、 すべての文書を完璧に整えてから RAG を導入するという順序は現実的ではありません。 整理コストが導入を無限に遅らせてしまいます。
筆者が運用上ありえそうだと見ているのは、 次のような中間解です。
RAG の検索対象を、 整理済みの文書だけに限定するところから始めます 所内マニュアルのうち「公式版」 とラベルづけされたもの、 改正後のひな形、 顧問先共通の研修資料 ——このあたりだけを対象に絞って稼働させます。 顧問先別フォルダや個人メモは、 整理が追いつくまで対象外にします。 検索範囲を狭くすると体感が落ちますが、 誤った情報が混ざるリスクと引き換えなら受け入れやすいはずです。
「対象外」 を明示する仕組みを最初に作ります 全部入れて後から除く、 ではなく、 入れるものを明示的に登録する方式に倒します。 ホワイトリスト型の方が、 文書増加時の事故率が低い構造になります。
整理対象をローテーションで進めます 顧問先別フォルダのうち、 上位 20 社を 3 か月で整理するという単位で進めます。 全件を待っていると永遠に終わりません。
「導入してから整える」 より「整えてから導入する」 ほうが、 結果的にコストも事故率も低くなりやすい領域だと見ています。
参考
- 個人情報保護委員会「生成AIサービスの利用に関する注意喚起等について」 (2023年6月2日)
https://www.ppc.go.jp/news/careful_information/230602_AI_utilize_alert/ - Microsoft Learn「Enterprise data protection in Microsoft 365 Copilot and Microsoft 365 Copilot Chat」
https://learn.microsoft.com/en-us/microsoft-365/copilot/enterprise-data-protection - 経済産業省・総務省「AI事業者ガイドライン」関連審議会ページ
https://www.soumu.go.jp/main_sosiki/kenkyu/ai_network/02ryutsu20_04000019.html