📚ごまかしなしのRAG · どんなときに本当に必要か（そしてどんなときにお金の無駄か）

いつ必要になるのか？（その正確な瞬間）

必要性はとても具体的な瞬間に生まれます。AIが大量の情報を一度に扱わなければならなくなり、失敗し始めたときです。典型的なサイン：30個のPDFをアップロードするとAIが半分を「忘れる」；長いマニュアルを貼りつけると内容を混ぜて答えたり作り話をする；あるいは同じ長大な文書を毎回の会話で貼り直さなければならない、保持してくれないから。そういうときに誰かがこう言うのです、「RAGが必要だね」と。

やさしい言葉でのRAG（専門用語なしで）

RAGは「検索拡張生成（retrieval-augmented generation）」を意味します。ひどい響きですが、考え方はシンプルです：AIに毎回すべての文書を突っ込む（多いと高すぎて不可能）代わりに、文書は別に保管しておき、何かを質問したときに検索エンジンが関連する小さな断片だけを取り出してAIに渡し、それをもとに答えさせるのです。まず検索、それから回答。

大きな追加の利点：AIはあなたの文書の具体的な断片をもとに答えるので、出典を引用できます（「これはマニュアルの12ページから」）。これこそが作り話を殺すのです：あなたの文書になければ、でっち上げません。

大きなメリット：RAGは（コーパスが大きいとき）大量のトークンを節約する

ここにRAGが存在する主な理由があり、それは小さくありません：お金の節約です。AIに入れる一語一語がトークンを消費し、トークンはお金がかかります。5,000ページの文書があって、それを毎回の質問に丸ごと貼りつけたら、大金を払うことになります（しかも多くの場合そもそも収まりません）。RAGはそれを解決します：5,000ページを送る代わりに、あなたの質問に本当に答える3、4個の小さな断片だけを送るのです。

なぜ「チャンク」と呼ばれるのか？（RAGの鍵となる部品）

チャンク（chunk）は英語で「かけら」や「一片」を意味します。RAGの中心的な部品なので、理解しておく価値があります。あなたの文書は丸ごと保管されるのではありません：小さな断片に切り刻まれ—各チャンクは通常一段落かその数段落くらい—各断片は一種の「その意味の指紋」とともに保管されます。

黄金律・本当にRAGが必要か？

ここに、ほとんどどの「グル」も教えてくれないデータがあり、それはAnthropic自身（Claudeの作り手）から来ています。ルールは驚くほど寛大です：

なぜそんなに重要なのか？なぜなら500ページは、ほとんどのプロジェクトにとって膨大だからです。あなたのブランドマニュアル、テンプレート、事業のポリシー、本を数冊…普通は収まります。そして収まるなら、RAGを組むのは理由なく人生を複雑にすることです。RAGは本当にそのサイズを超えるときのためのものです：巨大な図書館、何千もの文書、絶えず変わるデータ。

完全なはしご（RAGがどこにはまるか見えるように）

RAGは最初のステップでも最後のステップでもありません—はしごの一段です。順番に上がりましょう、流行で段を飛ばさずに：

RAGを実装する3つの方法（あなたのレベルに応じて選ぶ）

RAGを組む方法は一つではありません：三つあり、手間と力が少ないものから多いものへと並びます。大事なのは、もっとも見栄えのするものではなく、本当にあなたに合うものを選ぶことです。それらを挙げて、あとで一つずつ見ていきます：

方法1 · コードを一切書かずにRAGを組む（かんたんな道）

もしフィルターを通り抜けて、本当にRAGの番になったなら、良い知らせです：プログラミングもデータベースの構築も不要です。文書をドラッグするだけで、引用付きの賢い検索エンジンが手に入るツールがあります。今日、誰でも使える二つを：

方法2 · オープンソースのリポジトリで（よりコントロール）

プロジェクトが成長したり、自前のサーバーでコントロールを握りたくなったりしたら、強力で無料のオープンソースツールがあります。非専門家に最もやさしい二つ（あなたのAIがインストールを手伝ってくれます）：

これらのリポジトリのどれかを使って、私の文書についてオープンソースのRAGを組みたい：
- RAGFlow (https://github.com/infiniflow/ragflow) — ビジュアルなRAG、完全なものが欲しいなら理想的。
- AnythingLLM (https://github.com/Mintplex-Labs/anything-llm) — デスクトップアプリ、ローカルでプライベート。

プログラミングを知らない前提で、簡単な言葉で一歩ずつ導いて：
1. 私のケースに応じてどちらが向くか選ぶのを手伝って：[あなたの文書を説明、すべてをローカル/プライベートにしたいか、あなたのOS]。
2. どうインストールするか教えて（その要件、例：Docker）、できるところは君がやって。
3. 私の文書をアップロードしてナレッジベースを作るのを手伝って。
4. 私の文書にあることだけで答え、常に出典を引用するように設定して。
5. 私の文書をちゃんと読んでいるか確認するためのテスト質問を3つちょうだい。

もし手作業でやらなきゃいけないステップがあれば、正確な指示とともに教えて。

方法3 · スーパーアプリケーションのRAG（私たちのものはこう動く）

三つ目の方法は最も本格的です：スーパーアプリケーション—膨大な情報と多数のユーザーを持つプラットフォーム—を作るとき、どんな出来合いのツールも間に合いません。そこでは自前のRAGエンジンをオーダーメイドで構築します。エンジニアレベルです（あなた、またはコードエージェントを指揮するあなたのチームがやります）が、どこまで到達しうるか見えるように、ごまかしなしで内側を見せます：私たちのアプリケーションで使っているRAGエンジンはこう動きます。

オーダーメイドのRAGを構築するとき、コピーしてあなたのコードエージェント（Claude Code、Cursor）に貼りつけてください。私たちに効いている決定が組み込まれているので、即興ではなく堅い地盤の上から出発できます：

大規模なアプリケーション向けにオーダーメイドのRAGを構築するのを手伝ってもらう。まだコードは書かないで。まず私と一緒に設計して、なぜなら一番高くつく間違いはアーキテクチャを決めずにコードを書くことだから。

ステップ1 — 私にインタビューして（一度に一つの質問、簡単な言葉で）：
- RAGは何の情報をどれくらいインデックスする？（文書の種類、おおよその量）
- 何人のユーザーと、一日あたり何回のクエリを見込む？
- データは頻繁に変わる？チャンクを削除/更新する必要はある？
- マルチテナント（複数の顧客がデータを分離）？機密データはある？
- すでに使っているスタックは？（データベース、言語、どこにホスティングされているか）

ステップ2 — アーキテクチャを提案して、これらの実証済みの決定を出発点として使い（私のケースで変えたほうがいいか、なぜかも教えて）：
- ベクトルベース：PostgreSQL ＋ pgvector、HNSWインデックス付き（すでにPostgres/Supabaseを使っているなら再利用）。
- エンベディング：安価か無料のモデル（例：Gemini）、選んだ次元を保存する。
- チャンキング：約200トークンの断片、少し重なりを持たせ、メタデータ（出典、日付、セクション）を保存。
- ハイブリッド検索：ベクトル＋正確なテキストを組み合わせ、最も関連性の高いものを上げる再ランキング。
- 分離：マルチテナントなら、各クエリで常に顧客のidでフィルタする。

ステップ3 — フェーズごとの計画をちょうだい（まず何を作り、何を後回しにするか）、最適化の前にエンドツーエンドで動く最小フェーズ付きで。

ステップ4 — 本番RAGでもっとも一般的な5つの間違いと、初日からそれを避ける方法を挙げて（例：テナントでフィルタしない、チャンクの切り方が悪い、更新を扱わない、出典を引用せず信じる、回答の質を測らない）。

計画を承認したら、そのときこそフェーズ1を一歩ずつ作り始め、動いた各フェーズでGitHubに進捗を保存する。

プロンプト1 · 診断 — RAGが必要か、それとも不要か？

何かを組む前に、あなたが本当にどのステップにいるかAIに言わせましょう。コピーしてChatGPT、Claude、あるいはあなたのエージェントに貼りつけてください：

本当にRAGが必要なのか、それとも自分が話をややこしくしているだけなのか知りたい。次の質問を一つずつして、私の答えを待って、最後に私がどのステップにいてなぜかを教えて：

1. 文書はおおよそ何個、どれくらいのサイズがある？（全ページ数のざっくりした見積もり）
2. その情報は頻繁に変わる、それとも安定している？
3. 各回答の出典を引用してほしい？
4. 自分だけのため、それとも多くの人が使うアプリのため？
5. 今日どのAIツールを使っている？

君の推奨のためのルール：
- 私の資料全部が約500ページ（およそ200,000トークン）に収まるなら、RAGは要らないと言って：全部コンテキストに貼れば、そのほうがシンプルで精密。
- 明らかにそれより多い、もしくは頻繁に変わる、もしくは多くのユーザー向けなら、RAGを勧めて、コードなしの道（NotebookLM / Custom GPT）で間に合うか、オープンソースが要るか教えて。
- 過剰設計に押しやらないで。私のケースを解決する最もシンプルなステップを勧めて、それを正当化して。

プロンプト2 · コードなしで作り話を防ぐミニRAGを組む

診断が「はい、コードなしのRAG」と言ったなら、このプロンプトが組み方を、そして何より本当にあなたの文書を読んでいて作り話をしていないかを検証するよう導きます：

私の文書を参照するためにコードなしのRAGを組もうとしている。プログラミングを知らない前提で、簡単な言葉で一歩ずつ導いて。

1. 私のケースに応じてNotebookLM（無料）とChatGPTのCustom GPTのどちらがいいか勧めて：私は[あなたの文書を説明：何個、どんな種類、何のために参照するか]を持っている。
2. スペースを作って文書をアップロードする正確な手順（クリック付き）を教えて。
3. 私の文書にあることだけで答え、出典を引用し、作り話をする代わりに「文書にありません」とはっきり言うために設定すべき指示を書いて。
4. 本当に私の文書を読んでいる（一般的な記憶で答えていない）ことを確認するためのテスト質問を3つちょうだい。
5. 作り話をしているかどう気づくか、もしそうなったら何を調整すべきか教えて。

シンプルにして。もし何かを私がウェブでやるしかないなら、正確なクリック付きで教えて。

よくある間違い（あなたが陥らないように）

次のステップ · 一つの部品から脳全体へ

RAGは強力な部品ですが、それは一つにすぎません：あなたの文書の中を検索する。本当のアプリを作るとき、そのアプリはさらに各ユーザーを覚えることと、時にはすべてがどうつながっているか理解することも必要とします。この三つを合わせたもの—RAG ＋ 記憶 ＋ グラフ—が、brainと呼ばれるもの、あなたのアプリ自身の脳を形づくります。それが次のリソースで、あなたが見てきたすべてを集めます。