「あの件の資料、どこに保存したっけ」「前に誰かが同じ検討をしていた気がする」「この仕様の経緯を知っている人が退職してしまった」——社内の情報探しに費やす時間は、積み上げると膨大です。ある調査では、ホワイトカラーは労働時間の2割近くを情報探索に使っているとも言われます。
この記事では、この問題に対する現在の有力な答えである「ベクトル検索」と「RAG」について、仕組みと実務上の注意点を書きます。
なぜ社内の検索は使い物にならないのか
ファイルサーバーにもグループウェアにも検索機能はあります。それでも見つからないのには理由があります。
キーワード検索は言葉が一致しないとヒットしないからです。探す側が「経費精算」と打っても、ファイルには「立替金処理」と書いてある。「クレーム対応」を探しても、報告書のタイトルは「お客様対応報告」。社内の言葉は人や部署や時代によって揺れるので、キーワードの一致を前提にした検索は構造的に取りこぼします。結果、検索より「知ってそうな人に聞く」が最速になり、その人が辞めると情報が消えます。
ベクトル検索：言葉ではなく意味で探す
ベクトル検索は、文章を「意味の座標」（ベクトル）に変換して、意味が近いものを探す技術です。「経費精算のやり方」と「立替金の処理手順」は言葉こそ違いますが、意味の座標上では近くにあるため、ヒットします。表記ゆれや言い回しの違いを吸収できるのが、キーワード検索との決定的な違いです。
RAG：検索結果をもとに、AIが答える
ベクトル検索で関連文書が見つかるようになると、その先ができます。それがRAG（Retrieval-Augmented Generation：検索拡張生成）です。
仕組みは単純で、(1) 質問に関連する社内文書をベクトル検索で取ってくる、(2) その文書を根拠としてLLMに渡し、回答を作らせる、という2段構えです。ユーザーは「出張の宿泊費の上限はいくら？」と聞くだけで、規程文書を探して読む代わりに、「国内出張は1泊◯◯円が上限です（出典：旅費規程 第◯条）」という答えを得られます。
ポイントは根拠の文書を一緒に示せることです。LLMが知識から答えるのではなく、社内文書を読んで答えるので、出典を確認でき、ハルシネーション（もっともらしい嘘）のリスクを大きく下げられます。
導入でつまずきやすいポイント
実務では、技術そのものより周辺の設計でつまずきます。
データの状態。 検索対象の文書が古い版と新しい版で混在していると、AIは古い規程を根拠に答えてしまいます。「どの文書を正とするか」の整理は、導入時にある程度必要です。ただし完璧なデータ整備を待つ必要はなく、よく使う領域から始めて広げるのが現実的です。
権限。 人事評価や経営資料など、見られる人が限られる文書があります。検索・回答時に「その人が見ていい文書だけを根拠にする」権限設計は必須です。ここを雑にすると情報漏洩の仕組みになってしまいます。
答えられない質問への振る舞い。 根拠文書が見つからないとき、無理に答えず「該当する文書が見つかりませんでした」と返す設計にします。RAGの信頼性は、答える力より「知らないことを知らないと言える」設計で決まります。
まとめ
社内の情報探しの問題は、キーワード一致という検索の構造に原因があり、意味で探すベクトル検索とRAGで大きく改善できます。鍵は技術よりも、データの正の管理・権限・答えられないときの振る舞いという業務側の設計です。
私たちはベクトル検索・RAGを組み込んだシステムの構築を手がけています。「社内の情報が見つからない」「ベテランの知見が属人化している」という課題をお持ちでしたら、お問い合わせからご相談ください。