LLM・RAG・ベクトルデータベースを徹底解説！Claude Codeをもっと理解するための基礎知識

Claude Codeを使っていて「なぜこんなに賢いの？」「でも時々間違えるのはなぜ？」と疑問に思ったことはありませんか？その答えは、LLM（大規模言語モデル）、RAG（検索増強生成）、そしてベクトルデータベースという技術にあります。この記事では、これらの技術を「直感的に、かつ網羅的に」解説し、Claude Codeをより深く理解するための基礎知識を提供します。

この記事のポイント

• LLMは「次のトークンを予測する機械」であり、真の理解や推論はしていない
• RAGは「閉じた本での試験」を「開いた本での試験」に変える技術
• ベクトルデータベースは「意味」で検索できる記憶装置
• ほとんどのAI失敗は「生成の前」に起きている

LLMの本質：「次のトークン予測機械」

LLM（Large Language Model）とは何でしょうか？元記事では「An LLM is a next-token prediction machine」と明快に定義しています。つまり、与えられたテキストから「次に来そうな単語（トークン）」を予測するだけの機械なのです。

ここで重要なのは、LLMには以下の能力が「ない」ということです。
– メモリ機能がない: 過去の会話を「覚えている」わけではなく、毎回コンテキストとして与えられた情報だけを使います
– ファクトチェック機能がない: 生成した内容が事実かどうかを確認する機構がありません
– 真の推論能力がない: 論理的に考えているように見えますが、実際は「推論っぽいテキスト」を生成しているだけです

記事では「信頼度は訓練データの副作用であり、正確性ではない」と指摘しています。Claudeが自信を持って回答しているからといって、その内容が正しいとは限らないのです。これを理解することは、Claude Codeを使う上で非常に重要です。

コンテキストウィンドウの限界を知る

各LLMには「コンテキストウィンドウ」という制限があります。これは一度に処理できるテキスト量の上限であり、いわば「短期記憶」のようなものです。Claude 3ではこのウィンドウが大幅に拡大されましたが、それでも無限ではありません。

記事では「more context is like opening 40 browser tabs（コンテキストを増やすのは40個のブラウザタブを開くようなもの）」と表現しています。単にコンテキストを増やせばいいというものではなく、適切な情報を適切な量だけ与えることが重要なのです。

Claude Codeを使う際も、プロジェクト全体を読み込ませるのではなく、関連するファイルやコードスニペットに絞って提供することで、より精度の高い回答を得られます。

RAGとは何か？「閉じた本」から「開いた本」へ

RAG（Retrieval-Augmented Generation：検索増強生成）は、LLMの限界を補う重要な技術です。記事では「RAG turns an LLM from a closed-book exam into an open-book one（RAGはLLMを閉じた本での試験から、開いた本での試験に変える）」と説明しています。

通常のLLMは、訓練時に学んだ知識だけで回答します（閉じた本の試験）。しかしRAGを使えば、質問に回答する前に関連する情報を検索し、それを参照しながら回答できます（開いた本の試験）。

RAGの主なメリットは以下の通りです。
– ハルシネーション（幻覚）の減少: 実際のドキュメントを参照するため、でっち上げが減ります
– コスト削減: 必要な情報だけを取得するため、コンテキストの無駄遣いを防げます
– レイテンシ改善: 効率的な情報取得により、応答時間を短縮できます

これは単なるプロンプトの調整ではなく、システムレベルの改善を実現する技術なのです。

エンベディング：「意味」を数値に変換する

RAGを実現するための鍵となるのが「エンベディング（Embedding）」です。エンベディングとは、テキストの「意味」を数値のベクトル（数字の配列）に変換する技術です。

キーワード検索では「refund didn’t work（返金がうまくいかなかった）」と「billing is broken（請求がおかしい）」は全く別の検索結果を返します。しかし、エンベディングを使えば、これらが「意味的に近い」ことを認識し、関連するドキュメントを見つけられます。

ただし、記事では「embeddings don’t fix bad structure（エンベディングは悪い構造を直せない）」という警告も示しています。テキストの分割（チャンキング）が不適切だと、いくらエンベディングが優秀でも問題は解決しません。

ベクトルデータベースの役割

ベクトルデータベースは、エンベディングを保存し検索するための専用データベースです。重要なのは「記憶装置であって、知能ではない」という点です。

従来のSQLデータベースが「完全一致」や「部分一致」で検索するのに対し、ベクトルデータベースは「意味的な類似性」に基づいて検索します。「このコードと似た処理をしているコードを探して」といった検索が可能になります。

記事によれば、小規模なデータセットではPostgres + pgvectorで十分対応できるとのこと。スケーリングが必要になって初めて、Pinecone、Weaviate、Chromaなどの専用ツールを検討すればよいでしょう。

RAGパイプラインが失敗する5つのパターン

記事では、RAGシステムがうまくいかない5つの主要な失敗パターンが紹介されています。

1. 不適切なチャンキング: テキストの分割が大きすぎると不要な情報が混入し、小さすぎると文脈が失われます。適切なサイズ設定が重要です。

2. 過度なコンテキスト追加: top_k（取得するドキュメント数）を増やしても、LLMはそれらを適切にランク付けできません。「とりあえず多く取得」は逆効果です。

3. 矛盾したドキュメント: 新旧のポリシーが混在していると、AIは混乱して不正確な回答を生成します。情報の一貫性管理が必要です。

4. レイテンシの蓄積: 検索、取得、生成の各ステップで遅延が累積し、ユーザー体験を損なうことがあります。

5. プロンプトインジェクション: 取得したテキスト内に悪意のある指示が含まれていると、システムが乗っ取られるリスクがあります。

最も重要な指摘は「most failures happen before generation（ほとんどの失敗は生成の前に起きている）」ということです。AIの出力がおかしいとき、多くの場合、モデル自体ではなく、情報の取得段階に問題があるのです。

ファインチューニングとエージェント：いつ使うべきか

ファインチューニング（追加学習）は「モデルの話し方を変える」技術であり、実行時の知識は増えません。特定の口調やフォーマットでの回答が必要な場合に有効ですが、新しい知識を教えたいならRAGの方が適しています。

エージェント（AIにツールを使わせる仕組み）は、ワークフローが複雑な場合に有効ですが、基本的な検索品質が悪いと導入は逆効果です。

実装の推奨順序は以下の通りです。
1. まず検索品質を改善する
2. RAGを導入する
3. 必要に応じてファインチューニング
4. ワークフローが複雑な場合のみエージェント追加

知っておくと便利なTips

• Claude Codeへの指示は具体的に: LLMは「予測機械」なので、曖昧な指示より具体的な指示の方が精度の高い回答を得られます。

• 関連コードだけを共有する: コンテキストウィンドウには限りがあるため、プロジェクト全体ではなく、関連するファイルやスニペットに絞りましょう。

• 回答は必ず検証する: Claudeの回答がどんなに自信に満ちていても、それは「もっともらしいテキスト」であり、必ず正しいとは限りません。

• 失敗時は入力を見直す: AIの回答がおかしい場合、多くは入力情報（コンテキスト）に問題があります。プロンプトや提供した情報を見直してみましょう。

まとめ

LLM、RAG、ベクトルデータベースを理解することで、Claude Codeの動作原理がより明確になります。Claudeは「次のトークンを予測する機械」であり、真の理解や推論をしているわけではありません。しかし、適切な情報を適切に与えれば、非常に有用なアシスタントとして機能します。

重要なのは「AIの失敗の原因は、モデルの能力ではなく、システム設計にある」という視点です。Claude Codeを使いこなすためには、どんな情報をどう与えるかを意識し、出力を必ず検証する姿勢が大切です。

これらの基礎知識を持つことで、Claude Codeをより効果的に活用し、その限界も適切に理解できるようになるでしょう。

📎 元記事: https://dev.to/dev_tips/llms-rag-and-vector-databases-intuitively-and-exhaustively-explained-441j