タグ: ローカルLLM

社内文書を検索できるRAGやAIチャットを作った直後は、問題なく回答できていた。

ところが数か月後、料金表を更新したのに旧料金を答える。業務マニュアルを差し替えたのに、以前の手順を案内する。廃止した資料を共有フォルダから削除したのに、AIの回答には残っている。

このような問題は、AIモデルの性能だけが原因ではありません。元のファイルを更新しても、RAG側の検索データが自動で最新になるとは限らないためです。

RAGを業務で使い続けるには、導入時の文書登録だけでなく、導入後の「追加・差し替え・削除・期限切れ」を管理する必要があります。

結論から言うと、最初に決めたいのは次の4点です。

• どの文書が正式版か
• 更新を誰がRAGへ反映するか
• 旧版を検索対象から外す条件は何か
• 反映後に何を質問して確認するか

この記事では、小規模事業者や少人数チーム向けに、RAGの文書更新を無理なく続けるための実務設計を整理します。

ファイルを上書きしただけではRAGが更新されないことがある

RAGは、元のPDFやWordファイルを毎回そのまま読んで回答しているとは限りません。

一般的には、文書を一定の長さに分割し、検索用のデータへ変換して、ベクトルデータベースや検索インデックスへ登録します。利用者が質問すると、その登録済みデータから関連部分を探し、AIが回答を作ります。

そのため、共有フォルダのファイルを上書きしても、検索用データの作り直しや再登録が行われなければ、RAG側には古い内容が残ることがあります。

反対に、元ファイルを削除しても、登録済みの分割データが残っていれば、検索結果に出続ける場合があります。

RAGの文書更新では、元ファイルと検索データを別々に考えることが重要です。

• 元ファイル: PDF、Word、Excel、Markdown、Webページなど
• 検索用データ: 分割した文章、埋め込みデータ、メタ情報、検索インデックス
• 回答画面: 利用者が質問し、参照元と回答を見る場所

元ファイルだけ最新でも、検索用データが古ければ、AIの回答は古いままです。

RAG運用で管理したい4つの更新イベント

文書更新を「ファイルを入れ直す作業」とだけ考えると、削除や期限切れが抜けます。

最低限、次の4つに分けて管理します。

1. 新しい文書を追加する

新しいマニュアル、FAQ、料金表、規程、提案資料などを検索対象へ追加するケースです。

追加時には、ファイルを登録するだけでなく、次の点を確認します。

• 誰が見てよい文書か
• 正式版か、作業中の文書か
• どのカテゴリや部署に属するか
• いつから有効な情報か
• 似た内容の旧文書が残っていないか

新しい料金表を追加しても、旧料金表が同じ検索対象に残っていれば、AIは両方を見つける可能性があります。

追加と同時に、置き換える旧文書がないか確認することが大切です。

2. 既存文書を差し替える

内容を修正したPDFやWordを上書きするケースです。

差し替えでは、同じファイル名でも内容が変わっていることがあります。更新を検知したら、古い検索データを削除し、新しい内容で再登録する流れが必要です。

この時、旧データを消さずに新データだけ追加すると、同じ文書の新旧が両方検索されることがあります。

差し替え時に確認したい項目は次の通りです。

• 文書IDは同じか
• 版数や更新日は変わったか
• 旧データを削除してから再登録したか
• 参照元リンクは新しいファイルを指しているか
• 変更した項目を質問して、新版の回答になるか

3. 不要な文書を削除する

元ファイルを削除しただけでは、検索用データが残る場合があります。

削除時には、元ファイル、検索インデックス、ベクトルデータ、キャッシュ、参照元リンクの状態を確認します。

完全に削除する必要がない場合は、検索対象から外す「無効化」でも構いません。監査や履歴のために旧版を残すなら、保管場所と検索対象を分けます。

• 保管はするが、AI検索では使わない
• 管理者だけが検索できる
• 過去資料として明示し、通常回答では優先しない
• 一定期間後に完全削除する

「保管すること」と「回答に使うこと」を同じにしない設計が必要です。

4. 期限切れや旧版として無効化する

削除できない文書でも、現在の回答には使いたくないことがあります。

たとえば、過去の料金表、旧契約条件、終了したキャンペーン、改定前の就業ルール、以前の製品マニュアルです。

このような文書には、次のような情報を持たせます。

• 有効開始日
• 有効終了日
• 最新版かどうか
• 置き換え先の文書ID
• 検索対象に含めるか

日付や版数をファイル名だけに頼ると、表記の揺れや入力漏れが起きます。RAG側で扱えるメタ情報として持たせる方が、後から確認しやすくなります。

最低限持たせたい文書管理項目

大きな文書管理システムを導入しなくても、最初はスプレッドシートやCSVで管理できます。

最低限、次の項目があると更新状態を追いやすくなります。

• 文書ID
• 文書名
• 元ファイルの保存場所
• カテゴリまたは対象業務
• 版数
• 最終更新日
• 有効開始日・有効終了日
• 文書の責任者
• 閲覧できる利用者・部署
• RAG登録状態
• 最終登録日時
• 検索対象に含めるか
• 置き換え元・置き換え先の文書ID
• 確認用のテスト質問

特に重要なのは、文書ID、版数、RAG登録状態、テスト質問です。

ファイル名が変わっても同じ文書だと判断できるIDがあれば、旧データの削除と新版の再登録を対応づけやすくなります。

小さく始める更新フロー

最初からGoogle DriveやNotionの全更新を自動同期する必要はありません。

まずは、更新頻度が高く、古い回答の影響が大きい文書だけを対象にします。

1. 更新対象の文書を3種類程度に絞る
2. 正式版の保存場所を1つ決める
3. 文書ID、版数、更新日、担当者を記録する
4. 追加・差し替え・削除の申請方法を決める
5. RAGへ再登録する担当者を決める
6. 反映後にテスト質問を実行する
7. 回答と参照元が新版になったことを確認する
8. 確認日時を更新履歴へ残す

対象にしやすいのは、料金表、問い合わせFAQ、業務マニュアル、サービス説明、製品仕様などです。

これらは更新内容が明確で、テスト質問も作りやすいため、小さな運用を試すのに向いています。

更新頻度は文書ごとに分ける

すべての文書を毎日再登録すると、処理時間や確認作業が増えます。

文書の性質に合わせて、更新方法を分けます。

手動更新が向いている文書

料金表、契約条件、社内規程など、変更頻度は低いものの、間違える影響が大きい文書です。

更新時に人が内容を確認し、RAGへ反映した後、決めた質問で回答を確認します。

定期更新が向いている文書

週次レポート、月次資料、定期的に追加される議事録などです。

毎日、毎週、毎月など決まった時間に変更ファイルを確認し、追加分だけ登録します。

変更検知が向いている文書

頻繁に更新されるFAQ、サポート文書、商品情報などです。

ファイルの更新日時、ハッシュ値、版数などを使って変更を検知し、変更があった文書だけ再登録します。

ただし、自動更新した後も、重要な文書は回答確認を省略しない方が安全です。

RAG更新後はテスト質問で確認する

再登録が成功したというログだけでは、回答が正しくなったとは限りません。

検索では旧データが残っている、参照元リンクが切れている、似た文書が優先されている、といった問題が起きることがあります。

文書ごとに1から3個のテスト質問を用意しておくと、更新後の確認がしやすくなります。

たとえば料金表なら、次のような質問です。

• 現在の基本料金はいくらですか
• 追加費用が発生する条件は何ですか
• この料金はいつから有効ですか

マニュアルなら、変更した手順を直接聞きます。

確認するのは、回答文だけではありません。

• 最新版の内容を答えているか
• 旧版の内容が混ざっていないか
• 正しい文書名やURLが参照元に出ているか
• 更新日や版数を確認できるか
• 答えがない時に無理に作っていないか

よくある失敗は「新しい文書を足すだけ」

RAGの更新で多いのは、新版を追加して終わることです。

旧版が残っていると、検索結果に新旧両方が出ます。AIが新版を必ず選ぶとは限りません。

ほかにも、次のような失敗があります。

• 同じ文書を何度も登録し、重複データが増える
• ファイル名を変えたため、旧データと別文書として登録される
• 削除した文書の分割データだけ残る
• 更新担当者が不明で、誰も再登録しない
• 自動同期は動いているが、回答確認をしていない
• 参照元URLが旧ファイルのままになっている
• ローカル環境と本番環境で登録内容が違う

更新処理は、追加だけでなく、旧データの特定、削除、再登録、確認までを1セットにします。

小型ツール化するなら最初に必要な機能

文書数が増え、手作業での更新確認が難しくなったら、小型ツール化を検討できます。

最初から複雑な管理画面は必要ありません。まずは次の機能で十分です。

• 文書一覧
• 版数と更新日の表示
• RAG登録済み・未登録・更新待ちの状態管理
• 追加・差し替え・削除の実行
• 登録エラーの表示
• テスト質問と確認結果の記録
• 参照元リンクの確認

その後、必要に応じて次の機能を追加します。

• Google Driveや共有フォルダの変更検知
• 更新担当者への通知
• 期限切れ文書の警告
• 重複ファイルの検出
• 更新前後の回答比較
• 部署や利用者ごとの権限制御

重要なのは、自動化の範囲を広げることではなく、古い文書が回答へ混ざった時に原因を追えることです。

相談前に整理するとよい情報

RAGの文書更新や小型管理ツールを相談する場合は、次の情報があると範囲を決めやすくなります。

• 現在使っているRAGやAIチャットの構成
• 元文書の保存場所
• ファイル形式と文書数
• 更新頻度が高い文書
• 削除できない旧版があるか
• 古い回答が出た具体例
• 文書を更新する担当者
• 誰がAIチャットを使うか
• クラウドへ出せない情報があるか
• 手動更新と自動同期のどちらを希望するか

完璧な仕様書は必要ありません。古い回答の例と、本来参照してほしい最新版が分かるだけでも、原因の切り分けを始められます。

YOSHIO.devで相談できること

YOSHIO.devでは、ローカルLLM・RAG環境構築、業務自動化、小型ツール開発について相談できます。

「RAGが古い料金表を参照している」「文書を差し替えても回答が変わらない」「Google Driveの更新を小さく反映したい」「追加・削除・テスト確認を管理する画面が欲しい」といった段階でも、現在の文書と運用を見ながら整理できます。

最初から全社文書を自動同期するのではなく、更新頻度が高い文書や、間違える影響が大きい文書だけに絞って試すことも可能です。

まとめ

RAGや社内AIチャットは、最初に文書を登録して終わりではありません。

元ファイルを更新しても、検索用データが古いままなら、AIは旧版を答え続けることがあります。文書の追加、差し替え、削除、期限切れを分け、旧データの処理と更新後の質問確認までを運用に含める必要があります。

小さく始めるなら、料金表、FAQ、業務マニュアルなど数種類に対象を絞り、文書ID、版数、更新日、RAG登録状態、テスト質問を管理します。

RAGの品質は、モデル選びだけでなく、どの文書が現在有効なのかを継続して管理できるかで変わります。

よくある質問

ChatGPTや社内AIを業務に使うとき、多くの人が最初に不安になるのが個人情報の扱いです。

問い合わせメールをAIで要約したい。顧客対応の返信案を作りたい。社内文書をRAGで検索したい。スプレッドシートの行を見て次の対応を判断したい。

どれも便利そうですが、そこには氏名、メールアドレス、電話番号、会社名、住所、契約内容、相談内容、社内メモなどが含まれていることがあります。

「AIにそのまま貼り付けてよいのか」
「ローカルLLMなら全部安全なのか」
「どこまで伏せれば実用性が残るのか」

このあたりを曖昧にしたままAI業務自動化を始めると、便利さより不安が勝ってしまいます。

この記事では、小規模事業者や少人数チーム向けに、AIへ情報を渡す前に決めたいマスキング設計を整理します。ローカルLLM、RAG、問い合わせ対応AI、小型ツール開発を検討する前の準備メモとして使える内容です。

AI導入で最初に決めるべきは「何をAIに見せないか」

AI活用の相談では、「AIに何をさせるか」から話が始まりがちです。

• 問い合わせ内容を要約したい
• 返信文の下書きを作りたい
• 社内文書を検索したい
• 営業メモから次のアクションを出したい
• スプレッドシートの内容を分類したい

もちろん目的を決めることは重要です。ただし、業務で使うなら同じくらい大切なのが「AIに何を見せないか」です。

たとえば問い合わせ対応であれば、AIが内容を理解するために必要な情報と、必ずしも見せなくてよい情報があります。

• 相談内容の要約には、氏名そのものは不要なことが多い
• 返信案の作成には、メールアドレスは不要なことが多い
• 緊急度の分類には、電話番号は不要なことが多い
• 見積もり前の整理には、具体的な住所を伏せても進められることが多い

AIに渡す情報を減らしても、業務上の判断に必要な意味が残るなら、先に減らすべきです。

マスキング設計とは、単に黒塗りすることではありません。AIが仕事をするために必要な文脈を残しながら、個人情報や機密情報を渡しすぎない形へ変換する設計です。

まず分けたい3種類の情報

AIに渡す前の情報は、次の3種類に分けると整理しやすくなります。

• そのまま渡してよい情報
• 置き換えれば渡せる情報
• AIに渡さない情報

この分類をせずに「全部危ない」または「全部そのままでよい」と考えると、AI活用が進みにくくなります。

そのまま渡してよい情報

個人や取引先を特定しない一般的な説明、公開済みのサービス情報、社内で共有して問題ない業務手順などは、そのままAIに渡せる場合があります。

例:

• 公開中のサービスページ本文
• 一般的なFAQ
• 個人名を含まない業務手順
• テンプレート化された返信文
• 公開前チェックリスト

ただし、公開情報に見えても、社内用の価格条件や未公開のキャンペーン情報が混ざっていることがあります。公開済みかどうかだけでなく、外部に出してよい内容かを確認します。

置き換えれば渡せる情報

AIに内容を理解してほしいが、具体的な個人情報までは必要ない場合は、置き換えが有効です。

例:

• 山田太郎 → 顧客A
• example@example.com → メールアドレス
• 東京都渋谷区の具体住所 → 東京都内
• 株式会社〇〇 → 取引先A
• 090-xxxx-xxxx → 電話番号
• 注文番号や契約番号 → 管理番号

ここで大切なのは、意味を残すことです。

たとえば「東京都渋谷区神南…」という住所を完全に消すと、地域対応の判断ができなくなるかもしれません。その場合は「東京都内」「関東エリア」のように粒度を落として残します。

氏名を「顧客A」「顧客B」に置き換えると、会話の流れは保ちながら個人名を出さずに済みます。

AIに渡さない情報

AIに渡さなくても業務が進む情報、漏れると影響が大きい情報、社内ルール上入力できない情報は、最初から除外します。

例:

• 本人確認に使う情報
• 詳細な住所や電話番号
• クレジットカードや銀行口座
• パスワード、APIキー、認証情報
• 未公開の契約条件
• 医療、法務、労務など慎重な扱いが必要な相談内容

AIに入力する前に、人が毎回判断する運用では抜け漏れが起きやすくなります。できればフォーム、スプレッドシート、社内ツール側で自動的に除外・置換する仕組みを作る方が安定します。

マスキングで実用性を落とさないための考え方

個人情報を伏せるときに起きやすい失敗は、伏せすぎてAIが判断できなくなることです。

たとえば、問い合わせ文を次のようにすべて伏せてしまうと、AIは何も判断できません。

「□□□について□□□したいです。□□□までに□□□をお願いします。」

これでは個人情報は消えていますが、業務自動化には使えません。

実用性を残すには、次のように置き換えます。

「LP制作について相談したいです。来月中旬までに公開したいです。現在のサイトURLと参考LPがあります。」

この文章なら、個人名や連絡先がなくても、相談カテゴリ、希望時期、必要資料は分かります。

マスキングでは、次の3点を意識します。

• 誰かを特定する情報は伏せる
• 業務判断に必要な属性は粒度を落として残す
• AIの出力に戻してはいけない情報は最初から渡さない

AIに渡す文章は、元データのコピーではなく、業務判断用の安全な要約にするイメージです。

問い合わせ対応AIでのマスキング例

問い合わせ対応は、AI業務自動化の入り口になりやすい領域です。

ただし、問い合わせには個人情報が入りやすいため、そのままAIへ渡す前に変換を考えます。

元の問い合わせ:

「山田太郎です。example@example.com から連絡しています。東京都渋谷区で美容室を運営しています。今のLPから予約が増えず、7月末までにリニューアルしたいです。予算は50万円前後です。」

AIに渡す形:

「顧客Aからの問い合わせ。業種は美容室。課題はLPから予約が増えないこと。希望は7月末までのLPリニューアル。予算感は50万円前後。返信案では、現状LPのURL、予約導線、参考サイト、希望する撮影有無を確認する。」

この形なら、氏名やメールアドレス、詳細住所を渡さずに、返信案の作成に必要な情報を残せます。

AIに任せる処理は、次のような範囲に絞ると始めやすくなります。

• 相談カテゴリの分類
• 不足情報の抽出
• 返信案の下書き
• 担当者向けメモの作成
• スプレッドシート用の要約

最終返信や見積もり確定は、人が確認する運用にしておくと安全です。

RAGや社内文書検索では「文書ごとに伏せ方」を変える

RAGや社内文書検索では、PDF、議事録、マニュアル、FAQ、契約関連資料などをAIが参照することがあります。

このとき、すべての文書を同じ扱いにすると危険です。

まずは文書を次のように分けます。

• 公開してよい資料
• 社内共有してよい資料
• 部署や担当者を限定する資料
• 個人情報や契約情報を含む資料
• AI検索に入れない資料

RAGでは、検索対象に入れた文書が回答の根拠になります。AIの回答だけをチェックしても、検索対象の文書が広すぎると事故が起きます。

個人情報を含む文書は、次のような対策を検討します。

• AI検索用に個人情報を削除した版を作る
• 顧客名や担当者名をIDに置き換える
• 参照できるユーザーを制限する
• 回答に原文を長く引用させない
• 参照元リンクを出し、人が確認できるようにする
• 質問ログと回答ログを保存し、危険な回答を見直せるようにする

ローカルLLMを使う場合でも、文書の整理や権限設計が不要になるわけではありません。外部送信の不安は下げられますが、社内の誰が何を見られるか、ログをどう扱うかは別問題です。

ローカルLLMなら個人情報の問題は解決するのか

ローカルLLMは、社内PCや自社管理の環境でAIを動かせるため、クラウドAIにデータを送ることへの不安を下げやすい選択肢です。

ただし、「ローカルLLMなら何を入れても大丈夫」という意味ではありません。

注意したい点は次の通りです。

• 端末やサーバーに誰がアクセスできるか
• 入力ログや回答ログを保存するか
• 保存したログに個人情報が残らないか
• RAG用の文書フォルダに不要な資料が混ざらないか
• バックアップや共有フォルダから漏れないか
• モデルやツールの更新時に設定が変わらないか

ローカルLLMは、個人情報対策の選択肢の一つです。マスキング、権限、ログ、運用ルールと組み合わせて考える必要があります。

クラウドAIを使う場合も、ローカルLLMを使う場合も、最初に「AIへ渡す前の形」を決めておくことが重要です。

小さく始めるなら「AIに渡す前の変換ツール」を作る

個人情報対策を毎回手作業でやると、続きません。

最初の小型ツールとしておすすめしやすいのが、AIに渡す前の変換ツールです。

たとえば、次のような流れです。

1. フォームやメール本文を貼り付ける
2. 氏名、メール、電話番号、住所、管理番号を検出する
3. 顧客A、メールアドレス、電話番号、地域名などに置き換える
4. AIに渡す用の要約文を作る
5. 必要なら元データと置換後データを別々に保存する

このような小型ツールがあると、担当者ごとに伏せ方が変わる問題を減らせます。

スプレッドシート連携にするなら、個人情報列をAI処理から除外し、必要な列だけをAIへ渡す形にできます。

問い合わせフォームと連携するなら、送信直後にAI処理用の安全な要約を作り、担当者通知には元情報とAI要約を分けて表示できます。

重要なのは、AIそのものを大きく作り込む前に、AIへ渡す入力を整えることです。

マスキング設計のチェックリスト

AI業務自動化やRAG導入を検討する前に、次の項目を確認します。

• AIに渡す情報の種類を一覧化したか
• 氏名、メール、電話番号、住所、契約番号などを検出できるか
• そのまま渡す情報、置き換える情報、渡さない情報を分けたか
• 置き換え後も業務判断に必要な意味が残るか
• AIの出力に個人情報を再表示しない設計になっているか
• ログに元データを残すか、残すなら誰が見られるか
• RAGの検索対象に入れる文書を選別したか
• ローカルLLMとクラウドAIの使い分けを決めたか
• 最終送信や見積もりなど、人が確認する工程を残したか
• 運用中に危険な入力や回答を見直す仕組みがあるか

このチェックリストが埋まっていない状態でAIに本番データを渡すと、あとから運用を止めることになりやすくなります。

逆に、最初に小さく決めておけば、問い合わせ対応、社内文書検索、スプレッドシート自動化などへ広げやすくなります。

YOSHIO.devで相談できること

YOSHIO.devでは、小規模事業者や少人数チーム向けに、AI業務自動化、ローカルLLM・RAG環境構築、小型ツール開発、LP制作の相談を受けています。

個人情報や社内情報を扱うAI活用では、最初から大きなシステムを作るよりも、次のような小さな設計から始める方が現実的です。

• AIに渡す情報の棚卸し
• 個人情報のマスキングルール整理
• 問い合わせ文のAI要約・返信案作成フロー
• スプレッドシートからAIへ渡す列の整理
• RAGに入れる文書と入れない文書の分類
• ローカルLLMとクラウドAIの使い分け設計
• 小型の変換ツールや管理画面の試作

「AIを使いたいが、個人情報をどこまで入れてよいか分からない」「社内文書検索を試したいが、情報の扱いが不安」という段階でも相談できます。

まずは、AIに任せたい業務、今使っているフォームやスプレッドシート、AIへ渡すのが不安な情報を整理しておくと、具体的な提案につなげやすくなります。

ローカルLLM・RAG環境構築サービス、業務自動化サービス、お問い合わせページから、現在の業務内容に合わせてご相談ください。

まとめ

AIに個人情報を渡してよいかどうかは、AIツールの種類だけで決まるものではありません。

大切なのは、AIへ渡す前に情報を分けることです。

• そのまま渡してよい情報
• 置き換えれば渡せる情報
• AIに渡さない情報

この3つを決めるだけでも、AI業務自動化の不安はかなり減らせます。

ローカルLLMやRAGを使う場合でも、マスキング、権限、ログ、文書選別は必要です。クラウドAIを使う場合は、なおさら入力前の変換が重要になります。

最初から完璧なAIシステムを作る必要はありません。まずは、問い合わせ文やスプレッドシートの一部を安全な形に変換し、AIに要約や分類を任せる小さな流れから始めてみてください。

「社内のPDFや議事録をAIで検索できるようにしたい」
「Google DriveやNotionの資料をRAGで社内チャット化したい」
「ローカルLLMで安全にナレッジ検索を作れないか」

こうした相談は増えています。社内文書をAIで検索できるようになると、過去の提案書、問い合わせ対応履歴、業務マニュアル、議事録、仕様書を探す時間を減らせます。新人への説明、営業資料の再利用、問い合わせ対応、社内FAQの整備にもつながります。

ただし、いきなりRAGやAIチャットを作り始めると、思ったほど便利にならないことがあります。理由はモデルの性能だけではありません。AIに渡す前の文書が散らかっていると、検索結果も回答も散らかります。

この記事では、社内文書をAI検索する前にやるべき文書棚卸し、権限整理、更新ルール、最初のPoC範囲の決め方を解説します。

社内文書AI検索でよくある失敗

社内文書AI検索の失敗は、技術選定より前の段階で起きていることが多いです。

よくあるのは、次のような状態です。

• 古い資料と最新資料が同じ場所にある
• 同じ意味のファイルが複数存在する
• ファイル名だけでは中身が分からない
• 閲覧権限が部署や案件ごとに整理されていない
• 議事録、チャット、PDF、スプレッドシートが別々に散らばっている
• 正式なルールと個人メモが混ざっている
• どの文書をAIに読ませてよいか判断できない

この状態でRAGを組むと、AIは「社内文書を読んでいる」ように見えても、古い情報や関係ない情報を根拠に回答してしまいます。結果として、検索はできるが信用できない、便利そうだが業務では使いにくい、という状態になります。

RAG導入前に最初に決めるべきこと

最初に決めるべきなのは、どのAIを使うかではなく「何を探せるようにしたいか」です。

例えば、社内文書検索といっても目的はさまざまです。

• 営業が過去の提案書を探したい
• CSが問い合わせ回答例を探したい
• 経理や総務が社内手順を確認したい
• 開発チームが仕様や議事録を横断検索したい
• 経営者が過去の意思決定の背景を確認したい

目的が違えば、集める文書も、必要な権限も、回答の粒度も変わります。

最初から全社の情報を対象にする必要はありません。むしろ、最初は「問い合わせ対応のFAQだけ」「営業提案書の一部だけ」「社内マニュアルだけ」のように、範囲を狭くした方が成功しやすくなります。

文書棚卸しで見るべき5つのポイント

社内AI検索の準備では、文書をきれいに分類するだけでは不十分です。AIが検索しやすく、利用者が信頼しやすい状態にする必要があります。

1. 最新版がどれか分かるか

AI検索で最も危ないのは、古い資料をもっともらしく引用することです。

まずは、同じテーマの文書が複数ある場合に、最新版がどれか分かる状態にします。ファイル名に日付や版数を入れる、古い資料をアーカイブに移す、正式版と作業中を分けるだけでも効果があります。

「AIに聞けば分かる」状態を作る前に、「人間が見ても最新版が分かる」状態を作ることが重要です。

2. AIに読ませてよい文書か

社内文書には、AI検索に向いているものと向いていないものがあります。

例えば、社内マニュアル、公開済み提案書、FAQ、業務手順書は比較的扱いやすい文書です。一方で、個人情報、未公開の契約条件、人事情報、顧客ごとの機密情報が含まれる文書は、慎重に扱う必要があります。

クラウド型AIを使うのか、ローカルLLMや閉じた環境で処理するのかによっても設計は変わります。機密性の高い文書を扱う場合は、最初からローカル環境やアクセス制御を前提に検討した方がよい場合があります。

3. 誰が見てよい情報か

RAGやAIチャットでは、文書を検索できるだけでなく「その人が見てよい文書だけを検索する」設計が重要です。

営業資料は全員が見てよいが、案件別の見積書は担当者だけ。社内マニュアルは全員が見てよいが、採用候補者の評価メモは一部だけ。こうした違いを整理しないままAI検索を作ると、情報漏えいのリスクが出ます。

最初のPoCでは、権限が複雑な文書を避け、全員が見ても問題ない文書群から始めるのも現実的です。

4. 文書の単位が細かすぎないか、大きすぎないか

AI検索では、文書をどの単位で取り込むかも重要です。

1つのPDFにすべての業務手順が詰まっていると、AIが必要な箇所を見つけにくくなります。逆に、細切れのメモが大量にあると、文脈が足りずに回答が不安定になります。

マニュアルであれば章ごと、FAQであれば質問ごと、議事録であれば決定事項や論点ごとに整理されていると、RAGで扱いやすくなります。

5. 更新ルールがあるか

AI検索は、作って終わりではありません。元の文書が更新されなければ、AIの回答も古くなります。

文書棚卸しの段階で、誰が更新するのか、どのタイミングでAI検索側に反映するのか、古い資料をどう扱うのかを決めておきます。

小さな運用でも構いません。例えば「月1回、社内FAQだけ更新する」「問い合わせテンプレートだけ担当者が確認する」といった形でも、放置されるAI検索よりずっと実用的です。

最初のPoCは小さく作る

社内AI検索は、最初から大きく作るほど難しくなります。

おすすめは、次のような小さな範囲から始めることです。

• よく聞かれる社内FAQを30から50件だけAI検索化する
• 特定部署の業務マニュアルだけを対象にする
• 過去の提案書のうち、公開してよいテンプレートだけを取り込む
• 問い合わせ回答例のうち、個人情報を含まないものだけを対象にする
• 議事録から決定事項だけを抽出して検索対象にする

この段階では、完璧なAIチャットを目指すよりも「本当に探す時間が減るか」「間違った回答が出たときに原因を追えるか」を確認します。

もし小さな範囲で便利にならないなら、全社展開しても便利にはなりません。逆に、小さな範囲で効果が出れば、対象文書や機能を増やす判断がしやすくなります。

ローカルLLMや社内環境が向いているケース

社内文書検索では、クラウドAIだけでなく、ローカルLLMや閉じた環境でのRAG構築が候補になります。

特に次のような場合は、ローカル環境や社内限定の構成を検討する価値があります。

• 顧客情報や案件情報を含む文書を扱う
• 外部サービスに文書を送れない
• 社内ネットワーク内で完結させたい
• 回答ログや参照元を自社で管理したい
• 小規模でも専用の検索UIや管理画面が必要

ただし、ローカルLLMにすれば自動的に安全になるわけではありません。文書の権限、ログの扱い、更新フロー、バックアップ、利用者ごとのアクセス制御は別途設計が必要です。

重要なのは、AIモデル単体ではなく、文書、検索、権限、UI、運用をひとつの業務ツールとして考えることです。

社内AI検索を業務に乗せるための画面設計

社内AI検索は、チャット画面だけ作ればよいとは限りません。

実務では、次のような画面や機能があると使いやすくなります。

• 参照元文書を必ず表示する
• 回答に自信がない場合は断る
• 文書の更新日を表示する
• よく使う質問をテンプレート化する
• 回答結果を保存、共有できる
• 間違った回答をフィードバックできる
• 管理者が取り込み文書を確認できる

特に重要なのは、参照元の表示です。AIの回答だけを見せると、利用者は正しいかどうか判断しにくくなります。どの文書のどの部分を根拠にしたのか分かるだけで、業務利用の安心感は大きく変わります。

まず作るなら「文書棚卸しリスト」から

AI検索の前に、まずは簡単な棚卸しリストを作るのがおすすめです。

項目は複雑でなくて構いません。

• 文書名
• 保管場所
• 内容の種類
• 最新版かどうか
• 閲覧してよい人
• AI検索に入れてよいか
• 更新担当者
• 更新頻度
• 注意点

このリストを作るだけで、AI検索に向いている文書と、まだ整理が必要な文書が見えてきます。

RAGやローカルLLMの構築は、この棚卸しがあるとかなり進めやすくなります。取り込む文書の優先順位、権限設計、PoC範囲、画面設計を具体的に決められるからです。

YOSHIO.devで相談できること

YOSHIO.devでは、社内文書をAI検索するための小さなRAG環境、ローカルLLM検証、社内AIチャット、文書整理を前提にした小型業務ツール開発を相談できます。

例えば、次のような相談に対応できます。

• 社内文書AI検索のPoC範囲を決めたい
• RAGに入れる文書の整理方法を相談したい
• ローカルLLMで社内資料を検索できるか試したい
• Google Drive、Notion、PDFなどを横断検索する小型ツールを作りたい
• 参照元付きの社内AIチャットを作りたい
• AI検索に入れてよい文書、入れない文書を整理したい

いきなり大規模なAI導入をするのではなく、まずは小さな文書群で「業務で使えるか」を確認する進め方が現実的です。

関連サービス:

• ローカルLLM・RAG環境構築
• 業務自動化・小型ツール開発
• YOSHIO.devへの相談

FAQ

ローカルLLMやRAGを試すとき、多くの人が最初に気にするのは「クラウドに情報を送らずに使えるか」です。たしかに、手元のPCや社内環境で動かせることは大きな安心材料です。

ただし、ローカルで動くからといって、何も決めずに安全になるわけではありません。特に見落とされやすいのが、質問履歴やログの扱いです。

誰が、いつ、どんな質問をしたのか。AIがどの資料を参照したのか。回答に機密情報が含まれていなかったか。こうした履歴を残すべきか、残すならどこまで残すかを決めないまま運用を始めると、あとから不安が大きくなります。

ローカルLLMでも「履歴が残らない」とは限らない

ローカルLLMは、ChatGPTなどのクラウドAIとは違い、モデルを手元のPCやサーバーで動かせます。そのため、入力内容を外部サービスへ送らずに試せる場合があります。

しかし、実際の環境では次のような場所に履歴が残ることがあります。

• チャットUIの会話履歴
• アプリケーションのログファイル
• RAGの検索ログ
• 参照された文書名やスコア
• ブラウザやツール側の一時保存データ
• エラー発生時のデバッグログ

つまり、「ローカルだから履歴は残らない」と考えるのではなく、「どこに何が残る設計なのか」を確認することが重要です。

ログを残すメリットもある

質問履歴やログは、危ないものとして全部消せばよいわけではありません。運用改善には役立ちます。

たとえば、次のような確認ができます。

• よく聞かれる質問は何か
• 回答できなかった質問はどれか
• 参照資料が古くなっていないか
• 期待と違う回答が出ていないか
• 社内で実際に使われているか

ログがまったくないと、RAGの精度改善や資料整備が難しくなります。小規模導入では、最初から完璧なAIを作るより、実際の質問を見ながら改善する方が現実的です。

一方で、質問内容そのものは機密になりやすい

注意したいのは、質問履歴には利用者の関心や業務内容がそのまま出ることです。

たとえば、次のような質問は履歴として残るだけでも慎重に扱う必要があります。

• 特定顧客の契約条件を確認する質問
• 未公開サービスや価格に関する質問
• 社内の人事・評価に関する質問
• トラブル対応やクレーム対応に関する質問
• 個人情報を含む問い合わせ文の貼り付け

AIの回答そのものだけでなく、「何を聞いたか」も情報です。ログ管理では、回答内容だけでなく質問文も保護対象として考える必要があります。

最初に決めたいログ管理ルール

小規模なローカルLLM・RAG環境では、最初から大きな監査システムを作る必要はありません。まずは次の項目だけでも決めておくと、運用しやすくなります。

• 質問履歴を保存するか
• 保存する場合、誰が見られるか
• 保存期間を何日にするか
• 個人情報や顧客名を含む質問をどう扱うか
• 削除依頼があったときの対応方法
• 改善用に使うログと、残さないログを分けるか

おすすめは、最初からすべてを長期保存しないことです。検証段階では短期間だけ保存し、改善に必要な項目だけを見る運用の方が安心です。

RAGでは「どの資料を参照したか」もログになる

RAG環境では、質問文と回答文だけでなく、AIがどの資料を参照したかも重要です。

たとえば、AIが古い料金表を参照していた場合、回答内容だけを見ても原因が分かりにくいことがあります。参照元の文書名や更新日が分かれば、資料側を直せます。

一方で、参照ログには「その人がどの顧客資料にアクセスしたか」という情報が含まれる場合もあります。アクセス権限とログ閲覧権限を分けて考える必要があります。

ログに残さない方がよい情報

改善のためにログは便利ですが、何でも残すのは危険です。特に次の情報は、残さない、伏せる、短期間で削除するなどの対応を検討します。

• 氏名、住所、電話番号、メールアドレス
• 顧客名や案件名
• 認証情報、APIキー、パスワード
• 未公開の見積金額や契約条件
• 社内評価や個別トラブルの詳細

ログを改善に使う場合も、個人名や顧客名を置き換える、質問文を要約して保存する、参照文書名だけ残すなどの工夫ができます。

小さく始めるなら「短期保存＋手動確認」でよい

小規模事業者や個人事業の段階では、最初から複雑なログ基盤を作るより、シンプルなルールで始める方が続きます。

たとえば、次のような形です。

• 検証中の質問履歴は7日から30日だけ保存
• ログを見られる人は管理者に限定
• 個人情報を含む質問は禁止ルールとして明記
• 改善に使う場合は質問を要約して残す
• 本番運用前にログ保存範囲を見直す

最初の目的は、完璧な監査ではなく、安心して試せる状態を作ることです。

相談前に整理しておくとよいこと

ローカルLLMやRAG環境の相談をする前に、次の情報を整理しておくと設計が進めやすくなります。

• 誰がAIチャットを使うのか
• どんな資料を参照させたいのか
• 質問履歴を残したい目的は何か
• 残したくない情報は何か
• 管理者が確認したい項目は何か
• 保存期間の希望はあるか

ここまで決めておくと、ローカルLLMが向いているのか、クラウドAIと併用する方がよいのか、RAGをどこまで作るべきか判断しやすくなります。

まとめ

ローカルLLMやRAGは、情報を外部に出しにくい形でAIを試せる選択肢です。ただし、質問履歴やログの扱いを決めないまま始めると、あとから不安や運用負担が出ます。

導入前には、ログを残す目的、保存期間、閲覧権限、削除ルール、残してはいけない情報を整理しておくことが大切です。

YOSHIO.devでは、ローカルLLM・RAG環境の小規模導入、社内AIチャットの試作、資料整理、ログ運用ルールの設計まで、目的に合わせて相談できます。

ローカルLLMやRAGを試したいけれど、質問履歴、ログ、機密情報の扱いが不安な場合は、導入前の設計からご相談いただけます。現在の資料、使いたい範囲、残したくない情報をもとに、小さく安全に試せる構成を整理します。

よくある質問

RAGを入れれば、社内資料をAIが読んで答えてくれる。そう聞くと、すぐにチャット画面や検索システムを作りたくなります。

しかし実際には、RAGの精度は「AIの賢さ」だけで決まりません。AIに渡す社内資料が古い、重複している、部署ごとに言い方が違う、権限が整理されていない。こうした状態のままRAGを作ると、AIはもっともらしく間違えます。

この記事では、RAGやローカルLLM環境を導入する前に整理しておきたい社内資料のポイントを解説します。

RAG導入で失敗しやすい会社の共通点

RAGの失敗は、モデル選びよりも資料側で起きることが多いです。

たとえば、次のような状態です。

• 最新版と旧版のマニュアルが同じフォルダにある
• PDF、Google Docs、Notion、Excelに同じ情報が分散している
• ファイル名だけでは中身や更新日がわからない
• 部署ごとに用語が違い、AIが同じ意味だと判断できない
• 誰が見てよい資料か決まっていない
• 退職者や前任者しか知らない資料が残っている

この状態でRAGを構築すると、AIは「検索できた資料」を根拠に回答します。つまり、古い資料が引っかかれば古い回答をしますし、重複資料が多ければ回答が揺れます。

まず整理すべき資料の種類

最初から全社の資料をAI化しようとすると失敗しやすくなります。まずは、問い合わせや確認作業が多い領域に絞るのが現実的です。

優先度が高いのは、次のような資料です。

• よく聞かれる業務手順書
• 営業資料、料金表、提案テンプレート
• FAQ、問い合わせ対応履歴
• 社内ルール、申請フロー、権限ルール
• 商品・サービス仕様書
• 過去の議事録や決定事項

特に「人に聞かないとわからない」「毎回Slackやメールで同じ質問が出る」情報は、RAG化の効果が出やすい領域です。

RAG導入前の資料整理チェック

RAG用の資料は、ただ集めるだけでは不十分です。最低限、次の観点で整理しておく必要があります。

1. 最新版を決める

同じ内容の資料が複数ある場合、AIはどれが正しいか判断できません。まずは「正式な最新版」を決め、旧版にはアーカイブ、廃止、参考用などの状態を付けます。

2. ファイル名と見出しを整える

AI検索では、本文だけでなくタイトルや見出しも重要です。資料_final_最新_修正版.pdf のような名前ではなく、内容・対象・更新日がわかる命名にします。

例: 営業提案_料金プラン_法人向け_2026-05.pdf

3. 権限を分ける

RAGでは、見せてはいけない資料をAIが参照しない設計が必要です。人事、契約、顧客情報、未公開情報などは、最初から権限単位を分けておくべきです。

4. 用語を統一する

「顧客」「クライアント」「取引先」が同じ意味で使われている場合、AI検索の精度が落ちることがあります。社内用語集を作るだけでも、回答の安定性は上がります。

5. 更新責任者を決める

RAGは作って終わりではありません。資料が古くなれば、AIの回答も古くなります。部署ごとに更新責任者を決め、月1回でも見直す運用が必要です。

小さく始めるなら「1業務・30資料」から

RAG導入は、最初から大規模に作る必要はありません。むしろ、最初は1つの業務に絞ったほうが成功しやすいです。

• 営業担当向けの提案資料検索
• 社内問い合わせFAQ
• 制作・開発の引き継ぎ資料検索
• 顧客対応マニュアル検索

30から50資料程度でも、検索対象が整理されていれば十分に効果を検証できます。この段階で「AIがどの資料を根拠に答えたか」「回答が業務で使えるか」を確認し、範囲を広げていくのが安全です。

YOSHIO.devで支援できること

YOSHIO.devでは、RAGやローカルLLM環境をいきなり作るだけでなく、その前段階の資料整理や業務フロー確認から相談できます。

• 社内資料の棚卸しとRAG化しやすい分類設計
• ローカルLLM・RAG環境の小規模PoC構築
• 社内FAQボット、検索ツール、小型業務ツールの開発
• 業務自動化や更新チェックの仕組み化
• LP制作や問い合わせ導線とAI活用の接続

「AIを入れたいが、社内資料が散らかっている」という状態でも、最初の整理から始められます。

FAQ

社内資料をAIで検索できるようにしたい。過去の議事録、マニュアル、見積書、FAQ、業務メモを読み込ませて、質問すれば答えが返ってくる仕組みにしたい。

この相談はかなり増えています。

ただ、RAGやローカルLLM環境を作るときに、いきなりツール選定やモデル選びから始めると失敗しやすくなります。理由はシンプルで、AIが読む元データが整理されていないと、どれだけ良い仕組みを入れても回答がぶれやすいからです。

社内RAGの品質は、AIそのものよりも「どの資料を、どの状態で、どの権限で読ませるか」に大きく左右されます。

RAG導入でよく起きる失敗

社内RAGでよくある失敗は、技術の問題に見えて、実際はデータ整理の問題であることが多いです。

たとえば、次のような状態です。

• 同じ内容の資料が複数あり、どれが最新版か分からない
• 古いルールと新しいルールが混ざっている
• PDF、Excel、Google Docs、メモが散らばっている
• ファイル名だけでは中身が分からない
• 社外秘、個人情報、顧客情報が混在している
• 部署ごとに見せてよい情報が違う
• AIに答えてほしくない資料まで入っている

この状態でRAGを作ると、AIは「それらしい回答」は返します。しかし、その回答が現在有効なルールなのか、古い資料を元にしたものなのか、人間が判断しづらくなります。

結果として、便利なはずのAI検索が「確認の手間が増えるツール」になってしまいます。

まず決めるべきは「何を答えさせたいか」

最初にやるべきことは、AIに読み込ませる資料を全部集めることではありません。

先に決めるべきなのは、AIに何を答えさせたいかです。

• 社内マニュアル検索
• 顧客対応FAQ
• 営業資料の検索
• 過去案件のナレッジ検索
• 経理・総務ルールの確認
• 制作・開発手順の確認
• 新人向けの業務質問対応

用途が曖昧なまま「社内資料を全部AI化したい」と進めると、対象範囲が広がりすぎます。最初は1つの業務領域に絞ったほうが、回答精度も検証しやすくなります。

ファイル整理で見るべき5つのポイント

1. 最新版が分かるか

RAGに入れる資料は、最新版が明確である必要があります。

同じ名前のファイルが複数あったり、「最終版」「修正版」「最新版2」のようなファイルが残っていたりすると、AIが古い情報を拾う原因になります。

最低限、次のような情報を整理しておくと扱いやすくなります。

• 作成日
• 更新日
• 担当者
• 現在も有効か
• 廃止済みか
• 関連部署
• 文書の種類

RAG構築前に、すべてを完璧に整理する必要はありません。ただし「古い資料かどうか分からない」状態のまま投入するのは避けたほうが安全です。

2. ファイル名で中身が分かるか

AIに読み込ませる前に、人間が見ても分かるファイル名にしておくことも重要です。

悪い例:

• memo.pdf
• manual_new.xlsx
• 2024修正済み.docx
• 社内資料2.pdf

良い例:

• 経費精算ルール_2026年版.pdf
• 顧客対応FAQ_返品交換_2026-04更新.docx
• 営業提案テンプレート_SaaS向け_最新版.pptx

ファイル名は、検索性と運用性に直結します。RAGの回答に参照元を表示する場合も、分かりやすいファイル名のほうが確認しやすくなります。

3. 権限を分けられるか

社内RAGでは、誰がどの情報を見てよいかを必ず考える必要があります。

たとえば、経営資料、人事情報、顧客情報、契約情報、社内マニュアルを同じ扱いで入れると危険です。AI検索画面から、本来見せるべきでない情報が返ってしまう可能性があります。

• 全社員向け
• 特定部署向け
• 管理者向け
• 顧客情報を含む
• 個人情報を含む
• AI検索対象外

RAGは便利ですが、社内検索である以上、情報漏えいリスクもあります。ローカルLLM環境を使う場合でも、権限設計を省略してよいわけではありません。

4. AIに読ませない資料を決めているか

RAG構築では「何を入れるか」だけでなく、「何を入れないか」も大事です。

• 古い価格表
• 廃止済みの手順書
• 未確定のメモ
• 個人情報を含むファイル
• 顧客ごとの機密情報
• 社内議論中のドラフト
• 誤った内容を含む古いFAQ

これらをそのまま入れると、AIが誤情報を元に回答する可能性があります。「AIに聞けば分かる」状態を作るには、AIが参照する資料の範囲を人間側で制御する必要があります。

5. 回答の確認方法を決めているか

RAGは、答えそのものだけでなく「どの資料を元に答えたか」を確認できる設計が重要です。

• 回答の参照元ファイルを表示する
• 該当箇所を引用・ハイライトする
• 更新日を表示する
• 信頼度が低い場合は断定しない
• 参照元がない回答は出さない

社内業務で使うAIは、雑談AIとは違います。それっぽく答えることより、確認できることのほうが重要です。

小さく始めるなら「FAQ型RAG」がおすすめ

最初のRAG導入では、いきなり全社ナレッジ検索を作るより、FAQ型から始めるのがおすすめです。

• よくある社内手続き
• 顧客対応の定型回答
• サービス内容の説明
• 制作依頼時の確認事項
• 新人がよく聞く質問

FAQ型は、質問と回答の品質を確認しやすく、改善もしやすいです。回答が間違っていた場合も、どの資料を直せばよいか判断しやすくなります。

小さく作って、実際に使いながら改善する。この進め方のほうが、RAG導入は成功しやすくなります。

nsd.meで相談できること

nsd.me / YOSHIO.dev では、社内資料や業務ナレッジを活用したAI検索・RAG環境構築の相談を受け付けています。

• 社内資料をAI検索できるようにしたい
• ローカルLLMで社内データを扱いたい
• RAGを導入したいが、何から始めるべきか分からない
• PDFやGoogle Driveの資料を整理したい
• 小規模な社内AIツールを作りたい
• 既存業務に合わせてAI検索画面を作りたい

最初から大きなシステムを作る必要はありません。まずは対象業務を絞り、使える資料を整理し、小さな検索ツールとして試すところから始めるのが現実的です。

FAQ

Q. RAGを作る前に、社内資料を全部整理する必要がありますか？

いいえ。最初から全部整理する必要はありません。まずは対象業務を1つに絞り、その範囲の資料だけを整理するのがおすすめです。

Q. 古い資料が多い場合でもRAGは作れますか？

作れますが、古い資料と有効な資料を区別する必要があります。更新日や有効期限が分からない資料をそのまま入れると、誤回答の原因になります。

Q. ローカルLLMを使えば情報漏えいの心配はなくなりますか？

外部サービスに送信しない構成にはできますが、社内の権限管理や閲覧範囲の設計は別問題です。誰がどの資料を検索できるかは必ず設計する必要があります。

Q. PDFやExcelもRAGに使えますか？

使えます。ただし、表形式やスキャンPDFは抽出精度に差が出ます。必要に応じてテキスト化、形式変換、メタデータ付与を行うと精度が上がります。

Q. まず何から相談すればよいですか？

「どの業務でAI検索を使いたいか」「どの資料を元にしたいか」「誰が使うか」を整理して相談すると、具体的な構成を決めやすくなります。

関連する内部リンク候補

• 小規模事業者はローカルLLMとクラウドAIをどう使い分けるべきか
• 社内資料をAIで探せるようにするには？小さく始めるRAG導入の進め方
• 社内AI検索で「見えてはいけない資料」を出さないためのRAG権限設計