社内文書から回答し、出典も示すAIナレッジベース（RAG）

接続され、同期される情報源

Google ドライブ、SharePoint、Notion、Confluence、またはヘルプセンターに接続します。各段落にはタイトル、日付、リンクが保存され、同期では変更された文書や削除された文書も反映されます。

維持される権限

各段落にはチームやアクセスレベルの情報が付き、検索は質問者に応じて絞り込まれます。検索対象にしてはいけないものはインデックスに入れません。非常に細かい権限をどう反映するかは、お客様と事前に合意します。

出典付きの回答

すべての回答は、根拠となった文書とセクションへのリンクを示すので、誰でも確認できます。アシスタントは、見つからない内容を推測せず、見つからないと答えるよう指示されています。RAG によって作り話は減りますが、なくなるわけではありません。

向いているケース

チームが手順書、仕様書、規程、サポート履歴を毎日確認しており、そのドキュメントが存在し、ある程度最新に保たれている場合。

向いていないケース

• 文書が少数しかない：よくできた FAQ ページで十分です
• 文書同士が矛盾しており、どれが正しいかを決める人がいない
• ライブのデータベースから正確な数値が必要：連携や MCP サーバーのほうが適しています
• 誤りが重大な結果を招き、人によるレビューがない

確認する項目

• 検索が正しい文書を取得しているか
• 回答が取得した内容から逸脱していないか
• 出典が正しい箇所を指しているか
• 情報がないときに、わからないと認めるか

確認の方法

チームが、期待される回答と出典を添えて質問を作成します。当社は人手で確認するとともに、別のモデルを審査役として使います。モデル、分割方法、指示を変えるたびに質問セットを再実行します。稼働後は、ユーザーの評価や回答されなかった質問から、文書の不足箇所が分かります。

準備

• 情報源、担当者、対象外にするものを決める
• 重複した古い版を削除する
• アクセスグループと利用するチャネルを定義する

構築

• n8n またはコードによる取り込みと同期
• ハイブリッド検索に対応したベクトルインデックス（Qdrant、または pgvector を使った Postgres）
• Slack、Microsoft Teams、または社内チャットでのアシスタント
• 評価、チューニング、段階的な展開

納品物

• お客様のサーバー上の取り込み・同期ワークフロー
• お客様名義のアカウントに置かれたベクトルインデックス
• 選択されたチャネルに設定されたアシスタント
• 情報源と権限の対応表
• 評価用の質問セットと、その結果

範囲を絞って測定するアシスタント

たとえば1つの部署の手順書フォルダーなど、1つの情報源と1つのチャネルを、お客様と一緒に選びます。出典付きのアシスタントを構築し、チームの質問で試したうえで、結果を一緒に確認してから情報源を追加します。範囲、日程、条件は、作業開始前に文書で合意します。