社内ナレッジアシスタントのRAGアーキテクチャ：根拠ある回答を支える設計上の意思決定

このガイドは、従業員向けアシスタントの背後にある検索パイプラインを設計するアーキテクトとエンジニアリングリードを対象としています。設計上の意思決定とそのデフォルト値を説明します。エンジニアリングの実装をご希望の場合は、エンタープライズナレッジとRAGサービスをご覧ください。パッケージ製品については、AIナレッジアシスタントをご参照ください。ナレッジアシスタントは、業務オートメーションのためのAIガイドで取り上げているAIステップの一つです。

このガイドの内容

• なぜ検索品質が全体の品質を決めるのか？
• パイプラインの意思決定：一覧
• 取り込みとチャンキング
• 検索：キーワード、ベクター、またはハイブリッド
• 権限管理：モデルが参照する前にフィルタリングする
• 鮮度管理と削除
• 根拠ある回答と拒否応答
• RAGシステムの評価
• RAG、ロングコンテキスト、ファインチューニング、検索：代替手段と選択基準
• RAGパイプラインにおけるAI
• 実績として存在するもの、存在しないもの
• このガイドの限界
• よくある質問
• 次のステップ

なぜ検索品質が全体の品質を決めるのか？

Retrieval-Augmented Generation（RAG）は、2020年にLewisらによって提案されました。言語モデルと外部インデックスを組み合わせ、まず質問に関連する文節を見つけ、それをもとにモデルが回答するアーキテクチャです。企業のナレッジ管理においては、この仕組みが特に重要です。モデルは自社の契約書や業務手順書で学習しておらず、それらのドキュメントは毎週更新されるからです。

見落とされやすい点があります。アシスタントが誤った回答をする場合、原因はたいていモデルの上流にあります。正しい文節がインデックス化されていない、分割箇所が誤っている、ノイズの下位にランク付けされている、またはフィルタリングで除外されているのです。モデルを交換しても、それらの問題は解決しません。以下の意思決定こそが、品質の勝負どころです。

パイプラインの意思決定：一覧

取り込みとチャンキング

クロールではなくソースインベントリから始めてください。各システムについて、所有者・アクセスモデル・更新頻度・最新版が存在するかどうかを記録します。重複や古いコピーは、自信満々な誤回答の最も一般的な原因です。何かをインデックス化する前に、どのソースを正とするかを決めてください。

チャンキングは、検索に最も大きな影響を与える意思決定です。固定サイズのウィンドウはシンプルですが、手順やテーブルを途中で切ってしまいます。構造対応チャンキングは見出し・リスト項目・テーブル行で分割し、各チャンクに見出しパスを保存します。これにより、「返金 ＞ 破損品 ＞ EU域外」と題された文節を単独で検索・引用できます。長い手順の場合は、マッチング用に小さなチャンクをインデックス化しつつ、モデルには親セクションを渡すことで、ステップリスト全体を把握した回答が得られます。すべてのチャンクにドキュメントメタデータ（ソース・所有者・アクセス権・バージョン・日付）を保持してください。

検索：キーワード、ベクター、またはハイブリッド

ベクター検索は、異なる表現でも同じ意味の文節を見つけます。キーワード検索は完全一致を見つけます。製品コード・契約番号・名称・埋め込みがぼかしてしまう社内用語などです。企業の質問はその両方が混在するため、ハイブリッド検索が推奨デフォルトです。MicrosoftのAzure AI Search向けドキュメントは、一般的なパターンを説明しています。全文検索とベクタークエリを並列で実行し、Reciprocal Rank Fusionで2つのランキングリストを統合するというものです。

次にリランカーが各候補を質問とともに読み込み、順序を入れ替えます。第1段階の検索より遅いため候補にのみ実行しますが、回答品質に対する最も費用対効果の高い単一の改善策であることが多いです。最終セットは短く多様に保ってください。Liuらの「Lost in the Middle」では、モデルは長いコンテキストの中間部分よりも先頭と末尾の情報をより活用することが示されており、コンテキストが多いほど良いわけではありません。

権限管理：モデルが参照する前にフィルタリングする

アシスタントは、質問者が開けないドキュメントを引用してはなりません。これはプロンプトではなく検索で強制してください。各チャンクにアクセス権を保存し、質問者のIDとグループを検索クエリに渡し、生成前にアクセスできないものをすべて除外します。生成後にフィルタリングしたり、制限コンテンツを差し控えるようモデルに依頼したりすると、要約やヒントを通じて情報が漏洩します。

OWASPは、LLMアプリケーション向け2025年トップ10においてLLM08としてベクターと埋め込みの脆弱性を挙げており、インデックスを通じた不正アクセス・共有ベクターストアでのクロステナントリーク・汚染コンテンツなどが含まれます。その対策はこの設計と一致しています。ベクターストアへのきめ細かい権限対応アクセス・信頼できるソースからの検証済み取り込み・アクセスレベル別のコンテンツ分類・検索の不変ログです。アシスタントが回答だけでなくアクションも実行できる場合は、AIエージェントセキュリティガイドのコントロールも適用されます。

鮮度管理と削除

企業のナレッジは変化し、インデックスはそれに追従しなければなりません。ソースシステムが変更イベントを提供する場合はそれに応じて再インデックス化し、提供しない場合はスケジュールに基づいて実施します。各チャンクに最終更新日を保存し、引用の横に表示することで、ユーザーはポリシーの文節が2年前のものであることを確認できます。削除は更新と同様に重要です。ドキュメントが廃止されたり、ユーザーのアクセス権が失効したりした場合、インデックスはデータポリシーが約束する時間内に反映しなければならず、質問と回答の保持についても独自のルールが必要です。

根拠ある回答と拒否応答

生成ステップは契約です。文節から回答し、各主張を文節に引用し、文節が回答を支持しない場合は「わかりません」と言い、ドキュメント所有者を案内してください。NISTの生成AIプロファイルは、捏造（Confabulation）——誤った内容を自信を持って述べること——を生成AIの中核的リスクの一つに挙げており、引用と拒否応答がユーザーの確認手段となります。HR・法務・財務などの規制対象トピックについては、直接回答せずにドラフトレビューキューに転送してください。

RAG、ロングコンテキスト、ファインチューニング、検索：代替手段と選択基準

4つの基準で決まります。ナレッジの更新頻度・異なる人物が異なるドキュメントを閲覧する必要があるか・回答がソースにトレースできる必要があるか・関与するドキュメント数です。実際にはアプローチを組み合わせることが多く、事実にはRAG、フォーマットには軽いファインチューニングや指示、フォールバックには検索という形です。どのナレッジ課題を最初に解決するかは、エンタープライズAIレディネス評価の一部です。

実績として存在するもの、存在しないもの

• 存在するもの。Netbase JSCは、名前を明かせないクライアント向けに検索拡張ナレッジアシスタント・ドキュメントAI・MLOpsパイプラインを納品しています。匿名RAG実績には、システムの種類とNetbase JSCの役割が記載されています。納品はNetbase JSCのセキュリティプラクティス（ロールベースアクセス制御・管理ダッシュボードのMFA・転送中のTLS・保存時のAES・セキュアコードレビュー・脆弱性スキャン）に従います。
• 存在しないもの。実績にはクライアント名・コーパスサイズ・精度・採用率・時間短縮の数字が公表されていないため、ここでも提示しません。このページのデフォルト値は設計ガイダンスであり、そのプロジェクトの測定結果ではありません。

このガイドの限界

• デフォルト値は、1つの組織内のドキュメントとレコードに対する社内アシスタントに適しています。公開チャットボット・マルチテナント製品・規制対象のアドバイスには追加のコントロールが必要です。
• 研究論文とベンダードキュメントは手法の参照として引用しており、推薦ではありません。検索品質はコンテンツに依存し、実際の質問で測定する必要があります。
• インデックス内の個人データは、このガイドが代替するものではないデータ保護義務をもたらします。GDPRやその他のプライバシー法が適用される場合は、法的アドバイスを求めてください。

次のステップ

現在社員が検索しているソース・閲覧権限の設定・実際の質問10件をご共有いただければ、ソリューションレビューのご予約にて検索設計と評価セットの概要をご提案します。AIオートメーションとエージェントや、その他のNetbase JSCインサイトもご覧ください。

関連サービスとソリューション