パーソナルRAGを構築する：自分の文書と対話する

RAG（Retrieval-Augmented Generation、検索拡張生成）とは、質問に関係する資料をシステムが検索し、モデルが回答を生成するときに渡す仕組みです。一般向け製品でも検索基盤を自作せず、文書に基づく対話を利用できます。構成可能なプラットフォームやAPIは制御性を高めますが、開発、評価、ガバナンスの作業も増えます。

有用な目標は、すべてをアップロードすることでも、汎用チャットボットに自分のファイルを添付することでもありません。情報源群、権限、検索動作、引用、制限を検査できる、対象範囲を限定したアシスタントを作ることです。

該当するサービス、アカウント、地域、保持設定、共有管理、組織ポリシーで承認されるまで、契約書、顧客記録、人事ファイル、ソースコード、認証情報、健康情報、秘匿特権の対象資料、その他の機密または規制対象情報をアップロードしないでください。タスクに必要な最小限の情報源だけを使います。

パーソナルRAGの仕組み

一般的な検索ワークフローには四つの段階があります。

1. 取り込み。 文書を読み込むか、承認済みの情報源に接続します。
2. 索引作成。 テキストを抽出して分割し、検索可能な表現を作るなど、検索用に資料を準備します。
3. 検索。 質問を使って関連性が高いと判断した箇所を選びます。
4. 生成。 質問と検索した箇所を使ってモデルが回答し、引用または情報源リンクを付ける場合もあります。

すべての製品が同じ方法で実装しているわけではありません。小規模な知識群をモデルのコンテキストへ直接置き、拡大後に検索へ切り替えるプロジェクトワークスペースもあります。ここでは「パーソナルRAG」を対象範囲の限定された文書アシスタントという実用的な分類として扱い、実際の仕組みと制御は選んだ製品で確認してください。

検索により、基盤モデルが知らない最新、非公開、専門的な資料を利用できます。検索と生成が適切に動作すれば、範囲内の質問に対する根拠のない回答を減らせます。ただし、適切な箇所の検索、資料の鮮度、正しい解釈、回答内の全文章の裏付けは保証しません。

成功は観察可能な条件で定義します。関連する情報源を見つけ、裏付け箇所を引用または特定し、原文の意味と不確実性を保ち、廃止された資料を正しく扱い、権限を守り、承認済みコーパスでは答えられない質問を拒否または明示することです。

三つの実装方法

以下は、ホステッド情報源ノートブック、プロジェクトワークスペース、構成可能な検索パイプラインです。順位ではありません。

方法1：Gemini Notebook

Gemini Notebook（旧NotebookLM）は、選択した情報源を中心に構成するホステッド調査ノートブックです。Googleの情報源ドキュメントには対応する読み込み形式が記載され、Driveの情報源は自動同期できる一方、ほかの形式では読み込み動作が異なると説明されています。チャットは本文内の引用を返せますが、Googleの説明では、箇所単位の引用がない回答もあり、システムが誤る場合もあります。

適する場合： 対象を限定した情報源群を扱う対話型ノートブックが必要で、情報源箇所の確認や、学習用・ブリーフィング用形式の生成画面を重視する場合です。

使用前の確認： プランごとの情報源と質問の上限、各情報源がコピーか自動同期版か、ウェブページやファイルのどこが読み込まれるか、アカウント固有のデータ処理と共有、実際の文書形式と質問で引用が表示されるかを確認します。

方法2：Claude Projects

Claude Projectsには、プロジェクト指示、ナレッジファイル、プロジェクト内チャットがあります。Anthropicは、対象となる有料プランで拡張されたプロジェクト知識に自動RAGを使うモードを説明しています。アップロードした知識はコンテキストになりますが、有効にした機能によっては、回答が会話、指示、コネクタ、ウェブ結果、モデル知識も反映します。

適する場合： 指示、文書、会話をまとめておく反復利用のプロジェクトワークスペースが必要な場合です。

使用前の確認： プランと組織の管理機能、プロジェクトの公開範囲、対応ファイル、知識容量、検索が有効か、出典表示の動作、コネクタまたはウェブ検索、保持、共有を確認します。追跡できない限り、流暢な回答がプロジェクトファイルに基づくと想定しないでください。

方法3：マネージドまたは独自の検索パイプライン

構成可能なパイプラインは、取り込み、解析、分割、embedding、検索索引またはvector store、検索、再順位付け、モデル、画面を組み合わせます。コード、n8nのようなワークフロープラットフォーム、LangflowやFlowiseのような視覚的フレームワーク、マネージドAPIで構築できます。たとえばOpenAIのfile searchドキュメントは、vector store内のファイルを検索するホステッドResponses APIツールを説明しています。ほかの提供元には異なる検索とデータ管理の契約があります。

適する場合： 自動同期、メタデータフィルター、アプリ連携、独自のアクセス確認、観測可能な検索、またはホステッドノートブックでは実現できない反復評価が必要な場合です。

使用前の確認： 認証、文書単位の認可、削除と権限取消、テナント分離、暗号化、地域、保持、解析品質、索引の鮮度、検索ログ、モデルのデータ条件、文書からのプロンプトインジェクション、監視、保守担当者を確認します。

要件と根拠に基づいて選ぶ

「最も簡単」「最も柔軟」「最も高機能」といったラベルではなく、判断表を使います。

適切なのは、用途が必要とする確認を通過する最も単純な方法です。

対象を限定した試行を構築する

次の順序は、ホステッドノートブック、プロジェクトワークスペース、構成可能なパイプラインのすべてで使えます。

ステップ1：範囲と権威を定義する

次を書き出します。

• アシスタントが答えるべき質問
• 答えてはいけない質問
• 想定利用者と意思決定の重大性
• 権威ある、補助的、除外対象の情報源
• レビュー担当者とエスカレーション経路
• 情報源分類ごとの鮮度または有効版の規則

鮮度は分野によって異なります。歴史的な論文は研究結果について権威を保つ一方、価格表、セキュリティ手順、税務規則、製品ポリシー、法令は改定時点で危険になり得ます。公開日、該当する発効日、法域、版、レビューを促す事象を記録します。全文書に同じ任意の経過年数を使わないでください。

ステップ2：データ境界を承認する

取り込み前に情報源を分類します。サービス、アカウント、地域、保持、学習利用条件、共有設定を、適切なセキュリティ、プライバシー、法務、データ担当者に確認します。対象者が異なる情報は別の保存先またはプロジェクトに分け、各アシスタントが必要とする内容だけを開示します。

プロジェクトやノートブックによる分離は、アカウントと共有設定が強制する場合にだけ有効です。独自システムでは、文書のアップロード時だけでなく、検索時にも認可を適用します。

ステップ3：情報源台帳を作る

情報源ごとに次を記録します。

• 安定した情報源IDと名称
• 担当者と承認済みの対象者
• 元の場所と取り込み方法
• 権威レベルと法域
• 該当する公開日、発効日、レビュー日、廃止日
• バージョンまたはチェックサム
• 機密区分と削除担当者

この記事からリンクする情報源監査テンプレートが、簡潔な開始用の表になります。

ステップ4：代表的な文書を準備して取り込む

実際の形式と失敗パターンを網羅する情報源群から始めます。抽出されたテキスト、表、見出し、脚注、スキャンページを確認してください。きれいなテキスト変換、小さいファイル、異なる節の境界は、あるコーパスの検索を改善しても、別のコーパスでは悪化させる場合があります。文書準備と分割方法を仮説として、同じ質問で比較します。

説明的なファイル名と出典メタデータは、レビュー担当者が根拠を識別する助けになります。ただし、モデルがファイル名から権威や日付を確実に推測するとは考えず、製品が対応していれば項目として保存します。

ステップ5：回答契約を書く

開始時の指示例です。

承認済みの情報源群から、[audience and purpose]向けに回答してください。

重要な事実主張ごとに：
- 画面が対応していれば、情報源と裏付ける節または箇所を特定する。
- 限定条件、法域、発効日を維持する。
- 推測は推測と明記する。
- 情報源の矛盾を示し、暗黙に片方を選ばない。

承認済み情報源で答えられない場合は、その境界を明記してください。
明示的に有効にしない限り、ウェブまたは一般的なモデル知識を使わず、有効にした場合は別に表示してください。
[high-stakes categories]は[review owner]へエスカレーションしてください。

指示は生成に影響しますが、検索、引用、拒否が機能する証明ではありません。各要件をテストしてください。

ステップ6：日常利用前に評価する

実際のタスクからラベル付きの評価群を作ります。明確な答えがある質問、複数の情報源が必要な質問、矛盾、廃止済み情報源、範囲外の依頼、権限境界を含めます。各ケースについて、期待する情報源、許容する回答要素、禁止する主張、期待するエスカレーションを記録します。

少なくとも三つの層を分けて確認します。

1. 検索： 回答に必要な箇所を取得できたか。
2. 生成： その箇所を強めず、正確に反映したか。
3. ガバナンス： 情報源アクセス、範囲、鮮度、エスカレーション規則を守ったか。

用途の影響に応じて基準を設定します。学習補助と、法務または顧客向け資料を準備するアシスタントに同じ合格基準を使ってはいけません。

ステップ7：担当者を定めて運用する

情報源の更新、アクセスレビュー、評価の再実行、インシデント対応、削除の担当者を指定します。情報源群、解析器、検索設定、モデル、プロンプト、製品プラン、共有ポリシーに重大な変更があれば再評価します。カレンダー通知も役立ちますが、任意の月次作業より変更を契機とするレビューが重要です。

厳密に分離した法務情報の例

エストニアの雇用法とEUのデータ保護を扱うアシスタントを作るとします。

Riigi Teatajaのエストニア雇用契約法の現行統合版、EUR-LexのGDPR本文などの現行一次資料と、想定質問について資格を持つエストニアまたはEUの弁護士が承認した指針から、公開法令コーパスを作ります。法域、有効版、統合日、指針が拘束的か解説的かを記録します。

契約書案、顧客との連絡、内部調査ファイル、秘匿特権の対象となる法的助言を、そのコーパスに混ぜないでください。弁護士がAI支援の案件ワークスペースを承認する場合は分離し、承認済みシステムと利用者だけを使い、指定された特権と秘密保持の管理を維持します。生成回答は適用条項を引用し、法律、指針、推測を区別し、拘束的な解釈または行動は有資格の弁護士へ回します。

この設計により、検索が法律上の結論を出したり弁護士を代替したりすると装わず、公開法令アシスタントを資料の探索に使えます。

正常な回答だけでなく難しい挙動をテストする

範囲外の質問への対応は、拒否だけが正解ではありません。用途によっては、コーパスに答えがないことを明示する、承認済み情報源を求める、エスカレーションするほうが適切です。選択した挙動の信頼性を測定します。

よくある失敗を診断する

古いまたは廃止済みの情報源。 現在は適用されない版を正確に引用する場合があります。情報源台帳、有効版規則、同期処理、回答表示を修正します。自動同期は、権威ある情報源を指し、アクセス変更と削除も正しく反映する場合にだけ有用です。

権威性の低い情報源。 特別に設計しない限り、検索は法的または事実上の権威ではなく関連性で順位付けします。一次資料、承認済み二次資料、非公式資料を分け、矛盾の処理をテストします。

範囲の漏れ。 検索ファイルに加え、会話コンテキスト、ウェブ検索、コネクタ、既有知識を使う場合があります。不要なコンテキストは可能な限り無効化し、許可する外部情報を表示し、コーパス外の質問をテストします。

解析と検索の漏れ。 表、スキャン、段組み、脚注、図、コードブロック、特殊な書式は正しく抽出されない場合があります。解析表現と検索箇所を確認し、ラベル付き評価群で準備、分割、検索、再順位付けを比較します。一つの手法を前提にしないでください。

引用への過信。 実在する箇所でも、文章を裏付けない、一部だけを支える、廃止済みの場合があります。主張と箇所の対応を抽出し、重大な出力には人による確認を必須にします。

権限のずれ。 元の情報源へのアクセスが変わった後も、コピーが検索可能な場合があります。権限取消と削除をテストします。リスク上必要なら、現在の情報源権限を強制できるコネクタまたは構成を選びます。

引き継ぎでも出典を維持する

回答を汎用チャットボット、文書、チケット、意思決定ワークフローへ移すときは、出典も一緒に移します。質問、情報源IDと版、裏付け箇所またはリンク、検索日、生成回答、推測ラベル、未解決の矛盾、レビュー状況を含めます。次のツールに必要で承認された情報源だけを渡します。

このパケットがなければ、丁寧に根拠付けた回答も出典のない段落になり、後のモデルが事実として扱うおそれがあります。パケットがあれば、次のレビュー担当者は原文、生成要約、推測、承認済みの決定を区別できます。

より強い制御を構築するタイミング

次のような実測上の必要性があれば、ホステッドノートブックやプロジェクトを越えてください。

• コーパスの変化に伴い検索品質が低下すると評価で判明した
• 情報源に自動同期、削除、権限継承が必要
• アプリケーションまたは管理されたチャネル内で利用する必要がある
• メタデータフィルター、hybrid search、reranking、構造化検索が必要
• 可観測性、監査、地域、保持、テナント要件がホステッド製品の制御を超える
• 利用費と保守費が開発担当の配置を正当化する

これらは文書数のしきい値ではなく、アーキテクチャ要件です。小規模な機密コーパスには独自のアクセスモデルが必要な場合があり、大規模な公開コーパスはマネージドサービスで十分な場合があります。

構成可能なシステムでは、マネージド検索ツール、ワークフロープラットフォーム、LlamaIndex、LangChain、Haystackなどのコードフレームワークを検討できます。デモの速さではなく、同じ情報源、権限、評価、運用基準で比較してください。

総費用を計算する

費用には購読料またはAPI料金、保存、embeddingまたは索引、更新作業、評価、人によるレビュー、インシデント対応、保守が含まれます。ホステッド製品には無料またはプラン内の利用枠がある場合がありますが、上限はプランに依存します。独自システムの単価は、規模と運用設計によって上下します。

総費用を、アシスタントが実際に改善する文書タスクと比較します。チャットが速く感じるだけでなく、根拠が強く、検証しやすく、適切に範囲が限定された回答を作れるときに試行は成功です。

一つの狭い分野、承認済みで代表的な情報源群、ラベル付き評価から始めます。検索品質、引用の裏付け、有効版の処理、権限の強制、範囲外での安全な挙動が実証されてから拡大してください。この規律によって、ファイルの集まりが責任を持って使える文書アシスタントになります。