Claude RAG 構築｜Projects 内蔵と自前パイプラインの選び方
Claude に自社データを与えて回答精度を上げたい──そのニーズに応えるのが RAG（Retrieval-Augmented Generation／検索拡張生成） だ。Claude Projects に RAG 機能が組み込まれ、コード不要で大規模ナレッジベースを扱えるようになった一方、API を使って独自パイプラインを組む方法も選べる。本記事では両者の仕組みと使い分けを解説する。
目次 (9)
RAG とは──Claude に長期記憶を与える技術
LLM はコンテキストウィンドウの中の情報しか扱えない。社内規定・商品マニュアル・過去の顧客対応ログを 100 万字分参照させようとすると、トークンコストが膨大になるか、そもそもウィンドウに収まらない。
RAG はこの問題を解く。「まず検索してから生成する」アーキテクチャで、質問の意味に合致する断片だけをリアルタイムに取り出し、コンテキストに追加してから Claude に渡す。余分なテキストをウィンドウに押し込まず、必要な情報だけをピンポイントで供給できる点が最大の利点だ。
Claude の公式ヘルプでは RAG を「AI モデルが応答を生成する前にドキュメントから関連情報を検索する技術」と定義している（出典: Retrieval augmented generation (RAG) for projects | Claude Help Center）。幻覚（不正確な回答）を減らし、実際のビジネスデータに基づいた正確な回答を引き出せる。
Claude Projects の組み込み RAG 機能
最もすぐに使える選択肢が Claude Projects の内蔵 RAG だ。無料・Pro・Max・Team・Enterprise のすべてのプランで利用できる。
仕組みはシンプルだ。プロジェクトにファイルをアップロードするだけで、Claude は「project knowledge search tool」を使って会話中に自動検索する。コード・ベクトルDB・埋め込みモデルは一切不要。
主なメリットは 3 点ある。
- 容量拡張：通常のコンテキストウィンドウの最大 10 倍のコンテンツを保存できる
- 精度維持：検索して取り出した断片をそのままコンテキストに渡すため、全文処理と同等の回答品質を保てる
- 高速応答：必要な部分だけを取り出すので、大規模ナレッジでも応答が速い
RAG が自動起動する仕組みと条件
Projects の RAG は手動でオンにするものではなく、自動で発動する。プロジェクトのナレッジ量がコンテキストウィンドウの上限に近づくと、Claude が自動的に検索モードに切り替わる（出典: Retrieval augmented generation (RAG) for projects | Claude Help Center）。
ユーザー視点では通常の会話と変わらない。Claude が裏側でどのドキュメントを参照したかを把握しているため、追加の設定は不要だ。ファイルを追加して質問するだけで RAG の恩恵を受けられる。
対応ファイル形式は PDF・Word・テキスト・Markdown など主要フォーマット。ソースコードや CSV も読み込める。1 プロジェクトあたりのストレージ上限はプランによって異なり、Max・Enterprise で最大容量となる。
カスタム RAG パイプラインの構築手順
より細かい制御が必要な場合は、Claude API とベクトルデータベースを組み合わせた独自パイプラインを構築する。典型的な構築フローは 4 段階だ。
- インデックス作成：ドキュメントをチャンク（断片）に分割し、埋め込みモデルでベクトル化してベクトル DB に格納する
- クエリ変換：ユーザーの質問を同じ埋め込みモデルでベクトル化する
- 類似検索：ベクトル空間上の類似度（コサイン類似度など）で最も近いチャンクを取得する
- 生成：取得チャンクと元の質問をまとめて Claude API に送り、回答を生成する
Claude API の場合、system prompt にコンテキストを注入するパターンが最もシンプルだ。Python での最小実装例を以下に示す。
import anthropic
client = anthropic.Anthropic()
def rag_query(user_question: str, context_chunks: list[str]) -> str:
context = "\n\n".join(context_chunks)
message = client.messages.create(
model="claude-sonnet-4-6",
max_tokens=1024,
system=f"以下のコンテキストを参考に回答してください。\n\n{context}",
messages=[{"role": "user", "content": user_question}]
)
return message.content[0].text
context_chunks にはベクトル DB から取得した類似断片を渡す。実装の詳細は Anthropic 公式ドキュメント を参照のこと。
ベクトルデータベースの選択肢
カスタムパイプラインで必須となるベクトル DB は複数の選択肢がある。規模・コスト・運用コストで選ぶと判断しやすい。
| サービス | 特徴 | 向く規模 |
|---|---|---|
| Pinecone | フルマネージド・高速 | 中〜大規模 |
| Weaviate | OSS・スキーマ柔軟 | 中規模 |
| Chroma | ローカル開発向け | 小規模・PoC |
| pgvector | PostgreSQL 拡張 | DB 統合優先 |
| Supabase Vector | pgvector ホスティング | スタートアップ |
本番環境では Pinecone や Weaviate のクラウドサービスが安定しやすい。プロトタイプ段階では Chroma をローカルで動かし、スケールアップ時に移行するパターンが多い。Claude が MCP で Supabase と連携する場合は pgvector をそのまま活用できる点も覚えておきたい。
チャンキング戦略のベストプラクティス
RAG の精度を左右する最重要要素がチャンキング（文書分割）の粒度だ。チャンクが大きすぎると無関係な情報が混入し、小さすぎると文脈が失われる。
代表的な分割戦略を 4 種類まとめる。
- 固定サイズ分割：500〜1000 トークン程度で均等に切る。実装が簡単でバランスが良く、まず試すべきアプローチ
- 意味境界分割：段落・節・H2 ごとに切る。文書構造が明確な場合に精度が上がる
- オーバーラップ：チャンク間に 50〜100 トークンの重複を持たせ、文脈の断絶を防ぐ
- パレント検索（小→大）：小チャンクで検索し、ヒットした周辺の大チャンクを実際に Claude に渡す。精度と文脈の両立に優れる
Claude に渡すチャンク数は 3〜10 件が現実的だ。多すぎるとコンテキストが汚染され、少なすぎると回答が薄くなる。
マネージドRAGサービスという第三の選択肢
Projects とフルカスタムの中間に位置するのが マネージドRAGサービスだ。自社ドキュメントや外部データソースと自動同期し、コードなしで本番級の RAG を構築できる。
セットアップ時間の目安は Claude Projects が 5 分、マネージドサービスが 10〜15 分、フルカスタムが数週間〜数ヶ月（出典: RAG for Claude: 3 Ways to Add Your Business Data | Context Link）。コンテンツチームや顧客サポートのように、データが頻繁に更新されるがコード管理は避けたいチームに向いている。
用途別：どの方式を選ぶか
3 つの選択肢を用途で整理すると判断しやすい。
Claude Projects を選ぶケース
- 技術者不要でノウハウ集・マニュアルを社員に使わせたい
- PoC・社内ツールとして素早く立ち上げたい
- データ更新頻度が低く手動アップロードで十分
マネージドRAGサービスを選ぶケース
- データソースが複数あり自動同期が必要
- コードは書けないが Projects より柔軟性が欲しい
- Webサイト・ブログ・CRM など外部サービスと連携したい
カスタムパイプラインを選ぶケース
- リアルタイムでデータが変わる（在庫・ニュース・CRM 連携）
- 社外公開のサービスに組み込む（セキュリティ要件あり）
- 独自のランキングロジック・ハイブリッド検索が必要
まとめ
Claude RAG の選択肢は「Projects 内蔵」「マネージドサービス」「フルカスタム」の 3 段階だ。「すぐ使いたい・コード不要」なら Projects が最速。「本番システムに組み込む・リアルタイム連携が必要」ならカスタムパイプラインを構築する。
RAG で Claude に自社知識を与えることで、幻覚（誤情報生成）を大幅に減らし、信頼性の高い回答を実現できる。まずは Projects で社内ナレッジを試し、要件が合えばカスタム実装に移行する順序が現実的だ。
