コンテキストエンジニアリングとは、AIに渡す情報(コンテキスト)全体をどう組み立てるかを設計する考え方です
プロンプトの言い回しを磨くプロンプトエンジニアリングの先にある、いま急速に広まっているテーマなんです

AIに仕事を頼んで、指示じたいは悪くないはずなのに答えがズレる
そんなとき、原因は聞き方よりAIに渡している情報そのものの側にあることが多いです

この記事では、コンテキストエンジニアリングとは何かを、プロンプトエンジニアリングとの違い・具体的な構成要素まで初心者向けにまとめます
読み終えるころには、次の3つがつかめているはずです

• コンテキストエンジニアリングの意味:AIに何を渡すかの設計だと分かる
• プロンプトとの違い:どちらが上位で、なぜ置き換えではないのか
• 6つの構成要素:コンテキストに積むものを1つずつ噛み砕く

ジャベ雄

ざっくり言うと「AIの机の上に何を並べておくか」を考える話です

コンテキストエンジニアリングとは?まず全体像

結論から言うと、コンテキストエンジニアリングとは、AIが一度に読み込む情報のかたまり(コンテキスト)に、何をどう積むかを設計する技術です
単発の指示文だけでなく、AIが答えを作るために参照する材料をぜんぶひっくるめて整える、という捉え方なんです

AI(正確にはLLM=大規模言語モデル、文章を予測して作るAIの中身)は、渡された材料をもとに次の一手を組み立てます
だから材料が薄かったり、ノイズだらけだったりすると、聞き方をどれだけ工夫しても答えが決まりきらないんです

ここで前提になるのがコンテキストウィンドウという言葉です
下のメモにまとめておきます

Claudeの開発元である Anthropic は、コンテキストエンジニアリングをプロンプトエンジニアリングの自然な発展形と位置づけています
プロンプトを捨てる話ではなく、プロンプトも材料のひとつとして、コンテキスト全体を面倒みる、という広げ方なんです

もう少し身近にたとえると、新しく入ったメンバーに仕事を任せる場面に近いです
どれだけ優秀な人でも、必要な資料や過去の経緯を渡さなければ良い動きはできません
コンテキストエンジニアリングは、AIに対してこの「引き継ぎ資料の準備」を丁寧にやる作業だと考えると、とっつきやすいはずです

ここまでの話を1枚の図にすると、こんなイメージになります
窓というひとつの器を、性格の違う6種類の情報が分け合っている、という構図で見てもらえると分かりやすいはずです

なぜいま生まれた言葉なのか

コンテキストエンジニアリングは、2025年に一気に広まった比較的あたらしい言葉です
ざっくりした流れをおさえておくと、単なるバズワードではなく背景のある概念だと分かります

• 提唱:Shopify CEO の Tobi Lütke 氏が2025年6月ごろ、「LLM がタスクを解けるだけの文脈をぜんぶ渡す技術」として言い出したのが起点とされます(正確な日付は諸説あり、ここでは断定しません)
• 拡散:AI研究者の Andrej Karpathy 氏が同じ時期に賛同し、言葉として一気に広まりました(命名者というより後押し役の立場です)
• 体系化:Anthropic が2025年9月に「Effective context engineering for AI agents」で整理し、実務の枠組みとして定着させました

背景にあるのは、AIの使い方が単発の質問から自分で何ステップも作業するエージェントへ移ってきたことです
1往復で終わって、必要な前提もその場で書き添えられる用事なら、うまい聞き方でだいたい足ります

ところが、AIが道具を使って何度も往復しながら進むようになると、途中でどんな情報を持たせ続けるかが結果を左右します
この「持たせ続ける材料の設計」に名前がついたのが、コンテキストエンジニアリングなんです

ジャベ雄

AIが「単発の相棒」から「作業する部下」に変わったから、渡す資料の設計が要る、という流れです

プロンプトエンジニアリングとの違い

ここが多くの人のつまずきどころなので、プロンプトエンジニアリングとの違いを表で整理します
ポイントは、片方がもう片方を置き換えるのではなく、プロンプトはコンテキストの一部という包含の関係だという点です

「プロンプトエンジニアリングはもう古い」という煽りを見かけますが、そこは冷静に受け止めたいところです
実務では指示文の作り込みはいまも必要で、コンテキストという大きな器の中でプロンプトが担う役割が明確になった、と捉えるのが無理のない理解なんです

言い換えると、聞き方(プロンプト)を磨くのは点の改善、渡す材料ぜんぶ(コンテキスト)を設計するのは面の改善です
点をいくら磨いても面が崩れていると結果は安定しないので、両方を行き来する感覚が実用的です

たとえば「この関数のバグを直して」と頼む場面を考えます
プロンプトの工夫は、頼み方を「エラー内容も添えて原因から説明して」と具体的にすること
コンテキストの設計は、そもそも該当のコードやエラーログ・関連する仕様まで一式を渡しておくことです
後者が抜けていると、聞き方をどれだけ整えても的外れな答えになりがちなんです

Claude・生成AIを学べる本PR

面倒なことはChatGPTにやらせよう

カレーちゃん・からあげ

Amazonで見る楽天で見る

実践Claude Code入門

西見公宏・吉田真吾・大嶋勇樹

Amazonで見る楽天で見る

Claude CodeによるAI駆動開発入門

平川知秀

Amazonで見る楽天で見る

私のおすすめからランダムで3冊を表示しています

コンテキストに積む6つの構成要素

では、コンテキストには具体的に何が入るのか?
代表的なものを6つの構成要素に分けて、1つずつ噛み砕きます

• システムプロンプト:AIの役割やルールを決める土台の指示、「あなたは○○の担当です」のような前提
• ツール定義と実行結果:AIが使える道具(検索・ファイル読み書きなど)の説明と、実際に動かした結果
• RAG(外部知識の検索):手元の資料やデータベースから関連情報を引っぱってきて渡す仕組み
• メモリ:過去のやり取りやユーザーの好みを覚えておいて、あとで再利用する情報
• 会話履歴:ここまでの往復のログ、いま何を話しているかの流れ
• エージェント状態:いま何の作業の途中か、次に何をする予定かという進行の記録

この6つが、同じひとつのコンテキストウィンドウ(限られた窓)を分け合います
だからこそ、何を厚く積んで何を削るかの配分の判断が、コンテキストエンジニアリングの中身になるわけです

6つのうち、初心者がイメージしにくいのはツール定義と実行結果・エージェント状態あたりでしょうか?
前者は「AIが検索や電卓を使えるように渡す取扱説明書とその使用結果」、後者は「作業のしおり(いまどこまで進んだか)」だと思うと近いです

言葉の説明だけだとイメージしにくいので、実際にどんな中身が窓に載るのかをミニ例で並べてみます
同じ「情報」でも、要素ごとに質がぜんぜん違うのが伝わるはずです

こう並べると、6要素は「知識(RAG)」「記憶(メモリ)」「いまの流れ(会話履歴)」のように役割が分かれていると分かります
ぜんぶ同じ袋に放り込むのではなく、種類ごとに何をどれだけ載せるかを考えるのが、コンテキスト設計の勘どころなんです

RAG(外部知識の検索)とは

初めて聞く方向けに、RAGだけ少し補足します
RAG(Retrieval-Augmented Generation)とは、AIが答える前に関連資料を検索し、それを取り込んでから答えを作る仕組みです

AIの中身が最初から知っていることには限りがあり、社内マニュアルや最新の情報までは覚えていません
そこで、外から必要な資料を引っぱって窓に載せてあげると、AIはその場で参照しながら答えられます

身近な例だと、手元のPDFを読ませて質問に答えてもらう使い方がRAGの発想に近いです
言葉としてのRAGや周辺用語はAI用語集にもまとめているので、あわせてどうぞ

メモリと会話履歴の違い

メモリと会話履歴は似ていますが、役割が少し違います
会話履歴は「いまのやり取りの流れ」、メモリは「別の機会にも持ち越したい情報」というイメージです

会話が長引くと履歴が増えて窓を食いつぶすので、要約して圧縮するのもコンテキスト設計の一部です
全部を抱え込むより、要るものだけ残す引き算のほうが、じっさいには効いてきます

コンテキストは多いほどいいわけではない

ここまで読むと「とにかく情報を積めば安心」と思えますが、そこは落とし穴です
窓には上限があるうえ、関係ない情報が混ざると、AIがどこを見ればいいか迷って精度が落ちます

Anthropic も、コンテキストで大事なのは量ではなくその一手にとって過不足のない情報だと強調しています
だから実務では、足す設計と同じくらい、要らないものを削る・要約する設計が効いてきます

具体的には、窓に情報を詰め込みすぎると次のような実害が出ます
どれも「たくさん渡したのに、かえって精度が落ちた」という形で表れるのがやっかいなところです

• 古い情報の混入:更新前の仕様と最新版を両方渡すと、AIがどちらを正として答えればいいか迷う
• トークンの浪費:使わない資料まで窓の席を占めるぶん、肝心のやり取りに割ける余白が減っていく
• 精度の低下:関係の薄い情報が増えるほど、AIが要点を見失って答えがぼやけやすくなる

だから上限ギリギリまで詰めるより、その一手に要らない資料は思い切って外すほうが、結果的に答えが安定します
足し算より引き算のほうが効く場面は、じっさいに手を動かすとよく出くわします

「agent failures = context failures」という見方

コンテキストエンジニアリングを語るとき、よく引かれる整理があります
それがagent failures = context failuresという見方です

これは、エージェント(自分で作業するAI)の失敗の多くは、モデルの頭が悪いからではなくコンテキストの失敗が原因だ、という捉え方です
渡すべき情報が抜けていた、古い情報が混ざっていた、ノイズが多すぎた、といった材料側のほころびが結果を崩す、というわけなんです

この見方の便利なところは、AIがコケたときに直す先が具体的になる点です
「なんか賢くしてほしい」ではなく、「どの材料が足りなかったか」を点検すればいい、と切り分けられます

ジャベ雄

私も「AIが悪い」と思った失敗の大半は、渡す情報の抜けが原因でした

Claude Code の CLAUDE.md はコンテキストエンジニアリングの実例

抽象的な話が続いたので、私が日常的に触れている実例を挙げます
それが、AI開発ツールのClaude Codeで使うCLAUDE.mdというファイルです

CLAUDE.md は、プロジェクトの決まりごとをまとめておく設定ファイルで、AIが作業を始めるときに読み込みます
私はここに、使う言葉づかいのルールや、触ってほしくないファイル、フォルダの構成などを書いておくんです
ただし CLAUDE.md はAIへのお願いを書く場所で、アクセスを止める仕組みではありません
本当に触らせたくないファイルは、権限の設定側(settings.json の permissions.deny)で止めておくのが安全です

これはまさにコンテキストエンジニアリングそのもので、毎回おなじ前提を打ち直す代わりに、AIが読み込むコンテキストを先に整えておく、という発想です
先ほどの6要素で言えば、システムプロンプトやメモリに近い役割を、1枚のファイルで担わせている感じです

私の場合、CLAUDE.md を整えるほどに、指示が短くても意図どおり動いてくれるようになりました
逆に、ここが薄いと同じ説明を何度も繰り返すことになり、それこそ先ほどの「context failures」を自分で作ってしまいます

具体的には、CLAUDE.md を用意する前は「ですます調で、句点は控えめに」と毎回説明していたことが、いまは一言も添えずに文体がそろいます
渡す前提を一度ファイルに固定するだけで、往復のたびに積もっていた手間がまとめて消えた感覚です

CLAUDE.md をはじめとした設定ファイルの種類はClaude Code 設定ファイル早見表に、ツール全体の仕組みはClaude Code 拡張機構入門にまとめています
コンテキストの設計を手を動かして体感したい方は、そのあたりから触ってみるのがおすすめです

まとめ 次はハーネスエンジニアリングへ

コンテキストエンジニアリングとは、AIに渡すコンテキストウィンドウ全体に何を積むかを設計する技術でした
プロンプトを置き換えるものではなく、プロンプトを内側に含む上位の設計だと押さえておくと迷いません

• コンテキスト=AIが一度に読み込む材料のかたまり、窓には上限がある
• 積む要素は システムプロンプト・ツール・RAG・メモリ・会話履歴・状態 の6つ
• AIの失敗はcontext failuresとして捉えると直す先が具体的になる
• CLAUDE.md は身近なコンテキストエンジニアリングの実例

ここまでで「何を渡すか」の設計は見えてきました
すると次に気になるのが、そのコンテキストを実際に出し入れしたり、道具を動かしたりするAIの周りの仕組みぜんぶです

そこを扱うのが、次回のハーネスエンジニアリングです
コンテキストを含めてAIを取り囲むソフトウェア基盤の話に進みます

あわせて読みたい

ハーネスエンジニアリングとは AIの外殻を設計する話 ハーネスエンジニアリングとは モデル本体を取り囲む外殻(ツール統合・メモリ・状態・コンテキスト管理・ループ・検証・権限)を設計する新しい考え方です Agent=Model+Harnessという定式や scaffold との呼び分け Claude Code が実例である理由を初心者向けにまとめました

連載「AIの○○エンジニアリング」の記事一覧

• 総まとめ(ハブ):AIの○○エンジニアリング4種
• #1 プロンプトエンジニアリング(前回)
• #2 コンテキストエンジニアリング(この記事)
• #3 ハーネスエンジニアリング(次回)
• #4 ループエンジニアリング

Claude・生成AIを学べる本PR

面倒なことはChatGPTにやらせよう

カレーちゃん・からあげ

Amazonで見る楽天で見る

実践Claude Code入門

西見公宏・吉田真吾・大嶋勇樹

Amazonで見る楽天で見る

Claude CodeによるAI駆動開発入門

平川知秀

Amazonで見る楽天で見る

私のおすすめからランダムで3冊を表示しています

AIに自分のPDFや社内ドキュメントを読ませて、その中身から回答してもらう機能、最近よく見るようになりましたよね

Claude Projects にファイルを投げたり、ChatGPT に PDF を渡したり、Notion AI で社内ページを横断検索したり、Perplexity に「最新の話題」を聞いたり、NotebookLM にノートを読み込ませたり、このあたりが全部、似た仕組みで動いています

その裏で動いているのが RAG(検索拡張生成)と呼ばれる仕組みです、名前は地味ですが、これを知っておくと AI製品の挙動が一気に腹落ちするので、押さえておいて損はないと思います

この記事で扱う範囲はざっとこんな感じです

1. RAG が何の略でなぜ生まれたか
2. 事前準備フェーズ + 実行時フェーズの2段階の動き方
3. 精度を左右する「チャンク処理」の話
4. 実際の製品事例と「最近聞かない理由」
5. 自分で試す方法、ローカル/コスト面の話
6. ハマりポイント・安全性・ファインチューニングとの比較

Claudeまわりの基本用語はClaudeを始める前に知っておきたい用語集でまとめているので、LLM や Embeddings あたりがピンと来ない方はそちらと並行して読むと入りやすいです

RAGとは何か 略称と必要になった理由

まずは言葉の意味と、そもそも何でこの仕組みが必要になったのか、というところから整理します

Retrieval-Augmented Generation の略

RAG は Retrieval-Augmented Generationの略で、日本語だと検索拡張生成と訳されます

各単語の意味をバラして見ると、もう少しイメージが湧きやすいかもしれません

つなげると「外部から取り出した情報で補強された文章生成」になります、要するに AIが回答する前に、外部の情報を検索してから答える仕組みのことです

平たく言うと 「カンニング機能付きAI」と捉えるのが一番分かりやすいんじゃないでしょうか

カンニングと聞くとネガティブに響くかもしれませんが、ここでは「手元の資料を見ながら答える」くらいのニュアンスで、むしろ回答の正確性が上がる仕組みとして理解してもらえれば

そもそも生成AIには「知識のスナップショット問題」がある

なぜ RAG みたいな仕組みが必要になったかというと、生成AI(LLM)の知識は学習が終わった時点で止まっているからです

これは 「知識のスナップショット性質」とも呼ばれていて、学習データの締め切り日(カットオフ日)より後の出来事は本体だけだと知りません

正直に言うと私も最初これを実感していなくて、以前 ChatGPT に「去年あった有名なニュース」を聞いたら「すみません、その時期の情報は持っていません」と返ってきて、「あ、AIって本当に時間が止まってるんだ」と妙に感心した記憶があります

これに加えて、もうひとつ大きな壁があります

たとえ最新情報を学習させたとしても、あなたの会社の社内マニュアルや、あなたの個人ファイルは元から学習データに含まれていないので、本体だけで答えるのは原理的にむずかしいです

じゃあプロンプトに全部詰めて渡せばいいかというと、コンテキストウィンドウ(AIが一度に読める量)に上限があるのでこれも現実的じゃありません

そこで生まれた発想が 「都度、必要な情報だけ検索して渡す」というもので、これがまさに RAG の発想ベースになります

RAGには「事前準備」と「実行時」の2段階がある

ここから RAG の仕組みに入ります、ポイントは 2つのフェーズに分かれていることです

まずは事前準備フェーズ、これは 文書をAIが検索できる形に変えておく作業のことです

1. 元の文書を取得(PDF / Word / Webページ / Notion / Slack ログなど)
2. 文書を チャンク(かたまり)に分割する
3. 各チャンクを Embeddings(埋め込み表現)でベクトル(数値の配列)に変換
4. 変換結果を ベクトルDB(意味の近い文章を取り出すのに特化したデータベース)に保存

Embeddings は「文章を意味の似た方向に並ぶ数値に変換する処理」とイメージしておけばOKです、ここで 「意味が近い文章は近いベクトルになる」という性質を利用します

ベクトルDBは「意味の近さで文章を取り出すのに特化した専用データベース」のことです、ふだん使う MySQL のようなデータベースが文字列の完全一致や ID で引くのに対して、ベクトルDB は 近い意味の文章を効率よく見つけるのが得意です、有名どころでは Chroma・Pinecone・Qdrant・Milvus などがあります

続いて実行時フェーズ、これは 質問が来たら関連チャンクを引っ張ってきて回答に使う作業です

1. ユーザーの質問も Embeddings でベクトル化
2. ベクトルDBから意味が近いチャンクを検索
3. 上位N件(3〜10件くらい)を取得
4. 取り出したチャンクをプロンプトに合体させてAIに渡す
5. AIが「渡された資料」をベースに回答を生成

つまり AI本体は最終的な文章生成だけ担当していて、その手前で 「カンペを取り出す処理」が裏で走っているのが RAG の本質、というわけです

事前準備フェーズで使うベクトル化と、実行時フェーズの質問のベクトル化は、原則として 同じ Embeddings モデルで揃えるのがコツです、ここがズレると意味の近さの判定がおかしくなります

チャンク処理がRAGの精度を決める

ここは中級者向けに少し厚めにいきます、結論から言うと RAG の精度はチャンク処理でほぼ決まると言っても言いすぎじゃないくらい大事なポイントです

なぜわざわざチャンクに分けるのか

「文書まるごと1つのベクトルにすればよくない?」と思うかもしれません

ただ、ベクトル検索は 短い単位の方が精度が出る性質があります、長すぎるテキストをまとめて1つのベクトルにすると、いろんな話題が混ざって「意味の中心」がぼやけてしまうためです

料理本まるごと1冊を1ベクトルにしても、「カレーの作り方」のような具体的な質問に対して効率よく該当ページを引っ張れません、適度な単位でバラしておく必要があります

チャンクサイズは大きすぎても小さすぎてもダメ

じゃあどのくらいの大きさで分割するのがいいか、というところですが、ここはトレードオフです

一般的な目安は 500〜1,000トークン(日本語で約1,000〜2,000文字)と言われていて、迷ったらこの範囲から始めるのがおすすめです

2026年現在の海外のベストプラクティス記事を見ても 「まずは 300〜500トークン + 10〜15% の重なり(オーバーラップ)から試そう」という推奨が多くて、実運用してから上下に振って調整する流れが主流ですね

チャンクオーバーラップで文脈ロスを防ぐ

分割するときによく使われるテクニックが チャンクオーバーラップです、隣り合うチャンクの端を少し重ねて分割します

たとえば 1,000字でチャンクを切るときに 100字くらい重ねておくと、文の途中で切れたときに前のチャンクの末尾と次のチャンクの先頭で同じ部分が読めるので、検索でどちらに引っかかっても文脈が補える、というのがメリットです

目立たないですが、これだけで 「PDFを入れたけど回答が変な感じで切れる」みたいな失敗が結構減ります

分割方法のバリエーション

チャンクをどう切るかは、文書の種類によって向き不向きがあります

• 固定文字数で切る:単純で実装しやすい、ただし文の途中で切れて意味が崩れることあり
• 改行や句読点で切る:文の途中で切れない、自然な単位になる
• 見出し単位で切る:Markdown や HTML で見出しが明確な文書に強い
• セマンティックチャンキング:Embeddings で意味の切れ目を判定して分ける賢い分割、精度は高いが計算コストもかかる
• 階層チャンキング:章の要約+詳細チャンクを両方持つやり方、長い技術文書で精度が出やすい

セマンティックチャンキングはかっこいい響きですが、素直な構造化文書なら固定 + オーバーラップで十分なことが多いです、海外でもいきなり凝った分割に手を出さず、シンプルな方法で品質が足りないと感じてから段階的に上げる、という推奨が増えています

日本語ならではの注意点

日本語のチャンク処理には、英語にはない少しクセがあります

英語はスペースで単語が区切られているので、機械的に「○○トークン単位で切る」のがやりやすいんですが、日本語はスペース区切りがないので 形態素解析(単語の切り分け)を併用したり、句読点や改行を頼りに分割したりすることが多いです

あと裏方ですが効いてくるのが文字数とトークン数の換算で、日本語は1文字あたり1〜2トークン消費するので、「500トークン = 約500〜1,000文字」くらいで見積もるのが安全です

このあたりは LangChain / LlamaIndex などのライブラリが日本語向けの分割関数を持っているので、自作するよりライブラリに任せる方がトラブルが少ない印象です

実際にどこで使われているか

仕組みの話が続いたので、ここで身近な製品でどこに RAG が使われているかを整理します、意外と毎日触っているサービスの中に隠れていますよ

代表的なRAG搭載サービス

• Claude Projects:プロジェクトにファイルを添付して質問、内部で文書を検索しながら回答
• ChatGPT カスタムGPTs / メモリ機能:添付資料・過去のやりとりを参照しながら応答
• Notion AI:社内ページや個人ノートを横断検索しながら回答するイメージで、まさに業務RAGの典型
• Perplexity:Web情報をその場で検索 → 結果を参照しながら回答するWeb検索型RAGの代表格
• NotebookLM:Googleが提供しているノート型AIサービス、PDFや音声などをノートに登録して質問
• Microsoft 365 Copilot:Officeの社内ファイル(Word・Excel・SharePoint等)を参照

共通点は 「AIが外部資料を参照して回答する」という点、つまり大半のサービスで裏側で RAG 的な処理が走っているということになります

個人用途だと、Claude Projects に1冊分のマニュアルを入れて「○○の手順は?」と聞く使い方は超実用的で、業務用途だと Notion AI で「先月の会議メモから決定事項だけ抜いて」みたいな雑な指示も通るようになっています

「RAG」という言葉、最近あんまり聞かない理由

余談ですが、2023年〜2024年あたりは「RAG構築」という言葉が AI 界隈で連発されていたんですが、ここ最近はわざわざ「RAGを使っています」と書くサービスが減っている印象があります

これは 技術が浸透して当たり前になったため、製品の中で言及しなくなったというのが大きいです、Webアプリを今わざわざ「これはWebアプリです」と言わないのと同じ現象だと思います

製品紹介では「ファイルから回答」「社内データを参照」「ノートを検索」みたいな機能名で呼ばれるようになっただけで、技術的な実体は大体 RAG です

「最近聞かない = 古い技術」と勘違いされやすいんですが、実態は逆で むしろ標準装備になったと捉えるのが正確ですね

もう一歩深く 自分でRAGを試す方法

仕組みが大体わかってきたら「自分でも触ってみたいな」と思うかもしれません、ここでは難易度別の選択肢と、コスト面・ローカル運用について整理します

3つの進化系キーワード

その前にもう少しだけ用語だけ紹介、RAG にも進化系がいくつかあって、覚えておくと最新の記事がだいぶ読みやすくなります

• Hybrid Search(ハイブリッド検索):キーワード検索とベクトル検索を組み合わせて精度を底上げする方式
• Re-ranking(リランキング):1次検索の結果を別のモデルで再評価して並べ替える、上位N件の精度を上げる
• Agentic RAG:AI が検索戦略そのものを判断するタイプ、「もう一回検索し直そう」「別の切り口で検索しよう」といった判断を AI 側に任せる

細かい挙動の違いを今すぐ理解する必要はなくて、「RAG にも進化形がいくつかあるんだな」くらいで頭の片隅に入れておけば十分です

手軽派 既製品RAGで試す

一番手っ取り早いのは既製品の RAG にファイルを入れてみるパターンです

• Claude Projects にPDFやMarkdownを投げる
• ChatGPT のカスタムGPTs でナレッジを設定する
• NotebookLM にPDF・YouTube URL・Webページを登録する

このパターンは「自分でチャンクを切る」「ベクトルDBを立てる」みたいな処理を全部サービス側が見えないところでやってくれるので、コードを1行も書かずに RAG を体験できます

仕組みを深く知りたいなら自作の方が学びは大きいですが、「とりあえず触感を掴みたい」だけならここから始めるのが現実的です

自作派 PythonライブラリでRAGを組む

もう一歩踏み込んで自分で組みたいなら、Python ベースのライブラリが定番です

• LangChain:RAG構築の総合フレームワーク、Embeddings/分割/ベクトルDB/プロンプトを一気通貫で扱える
• LlamaIndex:ドキュメントインデックスに強い、特に長文・多種類の文書を扱う用途で人気
• Haystack:検索パイプラインの構築に強い、エンタープライズ寄り

最小サンプルとしては「PDFを読み込んで分割 → OpenAI/Anthropic の Embeddings でベクトル化 → Chroma などのベクトルDBに保存 → 質問が来たら検索して回答」みたいな流れを Python で40〜60行くらいで書けます

ちなみに このコードを書くこと自体も Claude Code Desktop に頼めるので、最近は「自作派とは何だったのか」みたいな話になりがちです

コスト面 Embeddings API は意外と積む

自作 RAG を試すときに見落としがちなのが Embeddings API の呼び出し料金です

1回あたりは安いんですが、社内ドキュメントを全部ベクトル化しようとすると チャンク数 × Embeddings コストでじわじわ積み上がります、大規模な文書を扱う場合は事前見積もりが推奨です

加えて運用時の検索コスト(ベクトルDB のホスティング費)もかかるので、無料で動かしっぱなしというわけにはいかない、というのは知っておくと安心です

ローカルRAG OllamaやLM Studioで完結する選択肢

「API コストを気にせず、社外秘データもローカルで処理したい」というニーズには ローカルRAGという選択肢があります

Windowsユーザーなら次のあたりの組み合わせが現実的です

• Ollama:ローカルでLLM・Embeddingsモデルを動かす定番ツール、コマンド一発でモデルを起動できる
• LM Studio:GUIでローカルLLMを扱える、GGUF形式のモデルを試すならこっち
• ローカルベクトルDB:Chroma・Qdrant をローカル起動して使う
• ローカル Embeddings モデル:multilingual-e5・bge-m3 など日本語対応モデルを使う

動作は API 経由よりは遅いですし、性能もハイエンド商用モデルにはやや劣りますが、データを外に出さずに RAG が組めるのは大きいです、社内ナレッジを扱うユースケースでは選択肢として有力ですね

コードベース版RAG CursorやClaude Codeのインデックス

ちょっと毛色の違う話として、最近の開発者向けAIエディタにも RAG 的な仕組みが入っています

Cursor や Claude Code の コードベースインデックスと呼ばれる機能は、要するにプロジェクト全体のソースコードを RAG 的に検索可能な形に変換しておく仕組みです

AI が「この関数どこで使われてる?」と聞かれたとき、いきなりファイルを全部読まなくても、インデックスから関連箇所だけ引っ張って答えられる、という動き方ですね、これも広い意味で RAG の一形態と捉えていいと思います

Claude Code の各拡張機構(Skills・Hooks・Subagents など)を体系的に整理した話はClaude Code拡張機構入門の記事でまとめているので、開発寄りに興味がある方はそちらも合わせてどうぞ

ハマりポイントと安全性 RAGの限界も含めて

最後に実用面の話を一気にまとめます、RAG あるある・データの安全性・ファインチューニングとの違い、というあたりです

代表的な失敗パターンと対処法

初心者が RAG を試すと、ほぼ全員が同じところでつまずきます、典型例をまとめておきますね

とくに「PDFを入れたのに回答できない」は かなりの確率で PDF パース問題です、表が画像として埋め込まれていたり、二段組のレイアウトがあったりすると、テキスト抽出の時点で内容が崩れていて、後段のベクトル化もうまくいきません

裏ワザ的には PDFをいったん人間が読める Markdown に変換してから RAG に投入すると、精度が一段上がることが多いです、ここは地味な作業ですが効きます

機密データを入れていいの データの安全性

業務利用で気になるのが「社内データを RAG に入れて大丈夫?」という安全性の話です

• ローカル動作のRAG:データが外に出ない構成にできるので原則安全、機密データ向き
• クラウドサービス系:各社の 学習利用ポリシーとデータ保持期間を確認する
• 商用契約:Claude for Work / Enterprise などの法人プランは 原則として学習に使われない規約になっている

Anthropic の場合は ユーザーデータを既定では学習に使わない方針が明示されています、最新の方針は Anthropicのプライバシーポリシーページと Claudeプライバシーセンターに整理されているので、業務利用するときは目を通しておくのが推奨です

2026年に入って 消費者向けプラン(Free / Pro / Max)では学習利用を任意でオン/オフできるオプションが追加されました、デフォルトはオフですが、自分でオンにした覚えがないか設定画面で確認しておくと安心です

Claude Code Desktop を業務で使うときのセキュリティ全般の話はClaude Code Desktop初心者向けセキュリティの記事でも触れているので、合わせて読むと安心材料が増えると思います

RAGの限界 検索精度に全てが乗っかる

RAG は強力な仕組みですが、万能ではありません

最大の制約は 「検索でヒットしなかった情報は使えない」という点で、ベクトル検索が外すと回答も外します、つまり検索段階の精度がすべての品質を決めると言ってよくて、ここを軽視すると後段がいくら賢くても結果が出ない、という現象が起きます

あとは大量のチャンクの中から本当に必要な数件を見抜く能力が問われるので、文書数が増えるほど検索チューニングの難しさが上がります

RAGとファインチューニングの使い分け

もう一つの相補技術が ファインチューニングです、これは AI自体に追加学習をさせて、特定の用途や知識を埋め込む方式で、RAG とは別のアプローチになります

どっちを使うべきか、というのはよく聞かれるトピックなので、表で比較しておきます

整理すると、RAG = 知識を都度参照する・ファインチューニング = モデルに知識や癖を埋め込む、という違いになります

たとえば「自社の最新マニュアルを参照したい」なら RAG が向いていますし、「自社特有の口調で常に応答してほしい」ならファインチューニングが向きます、両者を組み合わせる構成も実用ではよくあるパターンです

まとめ RAGが分かると AI 製品の見え方が変わる

長くなったので、ポイントをぎゅっと再掲して締めます

• RAG は Retrieval-Augmented Generation の略、外部情報を 検索してから生成する仕組み
• LLM の知識は学習時点で止まっているので、最新情報や社内固有情報を扱うには外部参照の仕組みが要る
• 動きは事前準備フェーズ(文書→チャンク→ベクトル化→DB)と実行時フェーズ(質問→検索→上位N件→AI回答)の2段階
• 精度の鍵は チャンク処理、サイズ500〜2,000文字+10〜15%オーバーラップから始めるのがおすすめ
• Claude Projects / Notion AI / Perplexity / NotebookLM など身近なAI製品の裏側でだいたい動いている
• 自分で試すなら Claude Projects / NotebookLM が手軽、自作なら LangChain / LlamaIndex、ローカルなら Ollama + Chroma
• ハマりポイントは PDF パース問題・チャンクサイズ・検索精度、ファインチューニングとは役割が違う相補関係

RAG という言葉自体は技術が浸透して目立たなくなりましたが、知っていると「あ、これ裏でRAG動いてるな」と AI 製品の見え方が一段クリアになるはずです

関連用語についてはClaudeを始める前に知っておきたい用語集に「埋め込み」「コンテキストウィンドウ」「ファインチューニング」あたりがまとまっているので、AI記事を読むベース知識を補強したい方はぜひ覗いてみてください

長文にお付き合いいただきありがとうございました、それでは、よい AI ライフを