社内ドキュメントをRAGで活用するAIエージェントの構築手順：設計から本番まで

「あの手順書どこだっけ」問題は、技術で解決できる

あなたのチームにも、こんな日常がないだろうか。新しく入ったメンバーが「有給申請の手順を教えてください」と聞いてくる。ベテランが「たしかSharePointに手順書があったはずだけど……」とファイルを探し始めて5分経過する。見つかったファイルは1年前に更新が止まっていて内容が古い——こういった情報へのアクセス問題は、どの規模の組織でも繰り返し起きている。

RAG（Retrieval-Augmented Generation）を使ったAIエージェントは、この問題を根本から解決する。社内の規程・マニュアル・過去の提案書・議事録をベクトルDBに格納しておくことで、「有給申請の手順を教えて」という自然言語の質問に対して、AIが関連ドキュメントを検索して正確な回答を返してくれる。担当者に聞く必要も、ファイルを探し回る必要もなくなる。

RAGがLLMファインチューニングよりも社内利用に向いている最大の理由は、情報の更新が容易な点だ。ファインチューニングは新しい情報を追加するたびに再学習と再デプロイが必要で、コストも時間もかかる。RAGはベクトルDBに新しいドキュメントを追加するだけで即座に参照可能になる。規程が改訂されたとき、新しいPDFをインデックスに追加するだけで翌日から最新情報を回答できる——この俊敏性が、社内ナレッジ管理との相性を良くしている。

構築の難易度は思っているより低い。最小構成のRAGシステムであれば、1日で動くものが作れる。まず小さく動かして、精度を上げながら対象ドキュメントを広げていく段階的なアプローチが成功への近道だ。

チャンキング設計——ここをサボると精度は出ない

RAGの検索精度を決める最大の要因は「チャンキング」、つまりドキュメントをどう分割してベクトルDBに格納するかだ。多くの初学者が最初にハマるのがここで、「なぜか答えが返ってこない」「明らかに関係ある情報なのに拾われない」という問題のほとんどは、チャンキングの設計ミスが原因だ。

単純な固定文字数での分割（たとえば「500文字ごとに区切る」）は一見シンプルだが、見出しや段落の途中で文章が切れてしまい、一つのチャンクとして格納されるテキストが文脈的に不完全になる。検索クエリと意味的に近いはずのチャンクが、文脈の欠落によって検索でヒットしなくなる——これが精度低下の原因だ。

推奨するのは「セマンティックチャンキング」だ。Markdownの見出し・HTMLのセクション・PDFの段落構造を解析して、意味のまとまりごとに分割する。同じトピックについて書かれた段落が一つのチャンクとして格納されることで、検索の精度が劇的に向上する。チャンクサイズは500〜1000トークンが一般的なスイートスポットで、小さすぎると文脈が失われ、大きすぎると関係ない情報が一つのチャンクに混入する。

各チャンクにはメタデータを必ず付与しておくことだ。ドキュメント名・最終更新日・カテゴリ・作成者・所属部門などの情報をメタデータとして格納しておくと、検索時に「経理部門のドキュメントのみを検索する」「2025年以降に更新されたドキュメントのみ」というフィルタリングができる。このフィルタリングが、検索結果のノイズを大幅に減らす。

ベクトルDBの選び方と検索精度の向上——Hybrid Searchが鍵だ

ベクトルDBの選択は、システムの規模と運用コストで決める。小〜中規模（10万ドキュメント以下）にはChromaまたはQdrantが適している。どちらもPythonネイティブで扱いやすく、ローカル環境での開発も容易だ。最初のプロトタイプはChromaで作り、本番環境に移行するタイミングでQdrantに切り替えるというパターンが現実的だ。大規模または管理コストを最小にしたい場合はPineconeやWeaviateのマネージドサービスが向いている。

検索精度の向上に最も効果的な手法は「Hybrid Search」だ。ベクトル検索（セマンティック検索）とBM25（キーワードベースの検索）を組み合わせることで、どちらか単独よりも高い精度が出る。ベクトル検索は「意味の近さ」を捉えるのが得意だが、固有名詞・型番・コード名などの完全一致には弱い。BM25はキーワードの完全一致が得意だが、「有給取りたい」→「年次有給休暇の申請方法」という意味的な言い換えに対応できない。両者の弱点を補い合うHybrid Searchは、実装の複雑さに見合うだけの精度向上をもたらす。

さらに精度を上げたい場合は、LLMによるクエリ書き換え（Hypothetical Document Embeddings）が有効だ。ユーザーの質問をLLMに渡して「この質問に答えるドキュメントはどんな内容を含んでいるか」を想定させ、その想定文章をベクトル化して検索する。ユーザーが短い質問や曖昧な表現をした場合でも、LLMが補完した検索クエリで精度の高い検索ができる。導入した結果、回答精度が20〜30%向上したという報告が複数のチームからある。

Rerankも忘れてはならない。検索で上位10件を取得した後、Rerankモデルで「質問への関連性が高い順」に並び替えてから上位3件だけをLLMのコンテキストに渡す。Rerankを入れることで、LLMに渡すコンテキストの質が上がり、回答精度とコストの両方が改善される。

インデックスを生きた状態に保つ——鮮度管理がRAGの命綱だ

RAGシステムを作って終わりにしてはいけない。社内ドキュメントは常に更新されるため、インデックスの鮮度管理が長期的な品質を決める。古い情報をRAGが参照し続けると、ユーザーは誤った情報を信頼して行動してしまう。これはRAGシステムへの信頼を一気に失わせる最大のリスクだ。

SharePoint・Google Drive・Confluenceなどのドキュメント管理システムとWebhookで連携し、ファイルが更新・削除されたときに自動でインデックスを更新する仕組みを最初から組み込んでおくことを強くすすめる。ドキュメントが更新されたとき、古いチャンクを削除して新しいチャンクを追加する差分更新ロジックを実装しておけば、常に最新の情報がRAGに反映される。月次で全インデックスの再構築も行い、差分更新で漏れた変更を拾う二重の保険をかけておくとより安全だ。

「情報が古い・間違っている」というユーザーフィードバックを収集する導線も最初から設けておこう。RAGの回答の下に「この情報は最新ですか？問題を報告する」というボタンを置くだけで、ユーザーが品質改善に参加できる。このフィードバックを週次でレビューして、インデックスの修正に活かす運用が、長期的なRAGの信頼性を維持する。あるチームでは、このフィードバックループを3ヶ月続けた結果、「情報が古い」というクレームがほぼゼロになったという実績がある。RAGは作って終わりではなく、育てていくシステムだという意識が重要だ。