コンテキストエンジニアリングの全体像：RAG・MCP・Agent Skillsの役割比較と設計判断【2026年版】

対象: RAGパイプラインの採用・見直しを検討しているアーキテクト／「RAG不要論」に反論の軸が欲しいエンジニア

「RAGはもう要らない」「ベクトルDBは終わった」——コンテキストウィンドウの拡大やエージェント技術の進化とともに、こうした議論がSNSで繰り返されています。しかし、議論が噛み合わない原因はほぼ毎回同じです。コンテキストエンジニアリングという上位概念を踏まえずに、手段同士を排他的に比較していること。

本記事では、Anthropicが公式に定義した「コンテキストエンジニアリング」を軸に、ベクトルDB・MCP・Agent Skills・長文コンテキストなど各手段の位置づけを整理し、「vs」ではなく「どう組み合わせるか」の設計判断を提示します。 読了時間 約6分

この記事のポイント

• 上位概念としてのコンテキストエンジニアリング

  ---

  LLMに渡す文脈全体を設計・管理する概念。ベクトルDBはその中の手段の一つに過ぎない

• 各手段は排他関係ではなく併用が現実解

  ---

  ベクトルDB・MCP・Skills・長文コンテキストは同じパイプラインの中で組み合わせる

• RAG不要論はカテゴリエラー

  ---

  判断すべきは「自分のユースケースでどの手段を、どの比率で組み合わせるか」

この記事で学べること

• コンテキストエンジニアリングの公式定義と、なぜ今この概念が重要なのか
• ベクトルDB・MCP・Agent Skills・長文コンテキストのレイヤーの違い
• 各手段のコスト・レイテンシ・取得遅延の比較表
• 「RAG不要論」がカテゴリエラーである理由
• 10年後にベクトルDBが残る条件・残らない条件

---

1. コンテキストエンジニアリングとは何か

Anthropicの公式定義

2025年9月、Anthropicは「Effective context engineering for AI agents」と題した公式ブログで、この概念を明確に定義しました。

要点を整理すると：

• Context（コンテキスト） = LLMへの推論時に含まれるトークンの集合
• Context Engineering = そのトークンの効用を最大化し、LLMの制約の中で一貫した望ましい結果を得るための設計・管理
• 対象はシステムプロンプト・ツール定義・MCP・外部データ・メッセージ履歴など文脈を構成するすべて

Anthropicは明確にこう述べています：プロンプトエンジニアリングが「何をどう聞くか」に焦点を当てるのに対し、コンテキストエンジニアリングは「推論時に何のデータ・知識・ツール・メモリ・構造をモデルに提供するか」を設計する、より広い概念である、と。

なぜ今この概念が重要なのか

初期のLLMアプリケーションでは、プロンプトが文脈のほぼ全てでした。しかしエージェントが複数ターンの推論を行い、長時間のタスクを実行するようになった今、「文脈全体の状態管理」が必要になっています。

エージェントはループの中で次々とデータを生成し、その情報は次の推論に反映される必要がある。どの情報を残し、どの情報を捨て、どの情報を新たに取得するか——これがコンテキストエンジニアリングの本質です。

---

2. コンテキストを構成する手段の分類

ここが本記事の核心です。「RAG vs MCP vs Skills」という議論がなぜ不毛かを理解するには、各手段がコンテキストパイプラインのどのレイヤーに位置するかを把握する必要があります。

コンテキストパイプラインの構造

┌─────────────────────────────────────────────────┐
│         コンテキストエンジニアリング（上位概念）          │
│                                                   │
│  ┌───────────────────────────────────────────┐   │
│  │ 1. コンテキストの取得（何を持ってくるか）      │   │
│  │                                             │   │
│  │  ・ベクトルDB検索（semantic retrieval）     │   │
│  │  ・Agentic Search（grep/ls/read ループ）   │   │
│  │  ・MCP経由のデータ取得（外部API接続）       │   │
│  │  ・Web検索 / Deep Research                 │   │
│  │  ・全文投入（長文コンテキスト）              │   │
│  └───────────────────────────────────────────┘   │
│                                                   │
│  ┌───────────────────────────────────────────┐   │
│  │ 2. コンテキストの構造化（どう整えるか）       │   │
│  │                                             │   │
│  │  ・Agent Skills（ベストプラクティス注入）    │   │
│  │  ・要約 / 圧縮                              │   │
│  │  ・チャンク分割・再ランキング               │   │
│  │  ・構造化マークアップ（XML / JSON）          │   │
│  └───────────────────────────────────────────┘   │
│                                                   │
│  ┌───────────────────────────────────────────┐   │
│  │ 3. コンテキストの管理（どう維持するか）       │   │
│  │                                             │   │
│  │  ・プロンプトキャッシュ                      │   │
│  │  ・メッセージ履歴の圧縮・剪定               │   │
│  │  ・Memory（会話間の記憶保持）                │   │
│  │  ・Context Compaction                        │   │
│  └───────────────────────────────────────────┘   │
│                                                   │
│  ┌───────────────────────────────────────────┐   │
│  │ 4. コンテキストのガード（何を除外するか）     │   │
│  │                                             │   │
│  │  ・権限管理 / 秘密情報除外                  │   │
│  │  ・トークン予算の上限設定                   │   │
│  │  ・ノイズフィルタリング                      │   │
│  └───────────────────────────────────────────┘   │
└─────────────────────────────────────────────────┘

この図を見れば明らかなように、ベクトルDBは「1. 取得」の手段の一つ、MCPも「1. 取得」の手段の一つ、Agent Skillsは「2. 構造化」の手段です。これらは同じレイヤーにすら位置していない場合がある。排他的に語ること自体がカテゴリエラーです。

---

3. 各手段の特性比較

実務で「どれを使うか」を判断するには、コスト・レイテンシ・取得遅延・適用条件を比較する必要があります。

取得手段の比較

手段	コスト/クエリ	レイテンシ	取得遅延	適用条件
ベクトルDB検索	低（$0.001以下）	低（ms単位）	中（再embedding・インデックス更新が必要）	大量ドキュメントからの意味検索
長文コンテキスト全文投入	高（100万トークン=$3〜6）	高（prefill数秒〜数十秒）	低（ファイルを直接読み込み）	ドキュメント数が限定的
Agentic Search	中〜高（ループ回数依存）	中〜高（複数ターン）	低（ライブ探索）	コード検索、構造化データ
MCP経由取得	中（API呼び出し依存）	中（API応答時間依存）	接続先次第（Slack=低、静的DB=中）	外部サービス連携
Web検索	中	中	低（検索エンジン経由で最新取得）	最新情報、一般知識

「取得遅延」について

「取得遅延」は、元データが更新されてから取得可能になるまでのラグを指します。ベクトルDBでは再チャンク・再embeddingという中間処理が入るため遅延が生じますが、他の手段でもデータソース自体の更新管理は別途必要です。取得メカニズムの差であり、元データの鮮度はいずれの手段でも共通の課題です。

コスト試算の具体例

よく議論になる「ベクトルDB vs 長文コンテキスト」のコスト比較を具体的に試算します。

前提：社内ドキュメント10万件（平均500トークン/件）から、1日1,000回の検索

パターンA：ベクトルDB + Claude Sonnet 4.6パターンB：全文を長文コンテキストに投入

• ベクトルDB月額：約$50〜100（Pinecone Standardの最低額は$50/月。10万件・1536次元のインデックスでストレージ約0.6GB + read units）
• 検索結果をLLMに投入：上位5件×500トークン = 2,500トークン/クエリ
• LLM入力コスト：2,500 × 1,000 × 30日 × $3/MTok = **$225/月**
• 合計：約$275〜325/月（※LLM出力コストは両パターン共通のため省略）

• 10万件 × 500トークン = 5,000万トークン → コンテキストウィンドウ超過（1Mが上限）
• 物理的に不可能。 100件に絞っても5万トークン × 1,000回 × 30日 × $3/MTok = **$4,500/月**
• プロンプトキャッシュ適用時（毎回同じ100件を投入する場合）：cache hits $0.30/MTokが適用され **約$450/月** まで下がる。ただしドキュメントが頻繁に入れ替わる場合はキャッシュヒット率が下がり、この恩恵は薄れる

キャッシュを最大限活用しても$450 vs $275〜325で、ベクトルDB側のコスト優位は変わりません。一方、ドキュメント数が数十件程度なら長文コンテキストの方がシンプルで中間処理の遅延もない。規模と頻度で最適解が変わるのです。

---

4. 「RAG不要論」はなぜカテゴリエラーか

SNSで定期的に燃える「RAG不要論」の典型的な主張を整理すると：

1. コンテキストウィンドウが拡大したからベクトルDBは不要
2. MCPやSkillsが出たからRAGの恩恵を受けられない
3. LLMのコスト低下は確定路線だから長文投入が最適解になる

関連記事

コード検索に特化した「狭義RAG vs Agentic Search」の詳細分析は、RAG不要論争を整理：Claude Codeが「狭義RAG（ベクターDB）」を捨てた理由と、コード検索の現実解で掘り下げています。本記事はその議論を包含する上位フレームワークです。

主張1への反論：規模の壁は消えていない

Claude Sonnet 4.6の1Mトークンコンテキストは画期的です。しかし、エンタープライズの現実は「数百万〜数千万件のドキュメント」です。100万トークンに収まる世界は、個人開発や小規模プロジェクトに限られます。

さらに、200Kトークンを超えると長文コンテキスト料金（$6/MTok）が適用されます。毎クエリで長文を投入するコストは、ベクトルDBのクエリコストとは桁が違います。

主張2への反論：レイヤーが違う

前述の通り、MCPは「外部APIへの接続プロトコル」、Agent Skillsは「タスク実行のベストプラクティス集」です。ベクトルDBは「大量データからの意味検索エンジン」。これらは機能が重複していないので、「代替」という関係にそもそもなりません。

むしろ実務では併用が自然です：

• MCPでSlackから最新メッセージを取得
• ベクトルDBで関連する過去のナレッジを検索
• Agent Skillsでその情報の統合方法をLLMに指示

これがコンテキストエンジニアリングの実態です。

主張3への反論：前提が楽観的すぎる

LLMのコスト低下は過去のトレンドからは支持されます。しかし「確定路線」と断言するには以下のリスクを無視しています：

• エネルギーコストの上昇リスク
• 規制環境の変化（EU AI Act等）
• 計算資源の物理的制約

仮にコストが10分の1になっても、数百万件のドキュメントを毎回全文投入する世界は、物理的な制約（レイテンシ、コンテキスト上限）が残ります。

---

5. 10年後にベクトルDBが残る条件・残らない条件

残る条件

• データ規模がコンテキストウィンドウを超え続ける — エンタープライズのドキュメント総量は増加の一途。モデルのコンテキスト長が伸びても、データ量はそれ以上に伸びる可能性が高い
• レイテンシ要件が厳しい — リアルタイム応答が求められるカスタマーサポートや検索UIでは、ms単位で結果を返すベクトルDBの優位性は当面続く
• コスト効率が求められる — 高頻度・大量クエリの環境では、毎回長文コンテキストを投入するコストに耐えられない
• マルチモーダルRAGの進化 — 画像・音声・動画を含むドキュメント検索は、テキストの長文投入では代替できない
• データガバナンス要件がある — エンタープライズではデータをそのままLLMに渡せない制約があり、検索結果だけを渡すRAGアーキテクチャが規制対応の観点で選ばれ続ける

残らない（縮小する）条件

• 個人・小規模プロジェクト — ドキュメント数が数百件以下なら、長文コンテキストやAgentic Searchで十分
• コードベース検索の一部 — Claude Code開発者が示したように、grepやファイル読みのループで精度・鮮度ともに勝るケースがある
• LLMのコストが2桁下がった場合 — 仮に$0.03/MTokの世界が来れば、中規模ドキュメントの全文投入が現実的になり得る（ただしベクトルDB側の運用コストも同時に下がる点は考慮が必要）

変数としてのメモリ技術

「全部メモリに入れれば解決するのでは」という発想は自然ですが、現時点では成立しません。LLM文脈でのメモリには大きく3つの形態があります。

会話メモリ（Claude's Memory等）は会話間で要約情報を保持する仕組みですが、容量は極めて小さく、ドキュメント検索の代替にはなりません。エージェントメモリ（MemGPT等）はエージェントが長期記憶を読み書きできる仕組みで、最も「全部解決するのでは」に近い発想ですが、このメモリの保存先と検索手段に結局ベクトルDBやKVストアが使われます。つまりメモリはベクトルDBの代替ではなく、ベクトルDBの上に乗る抽象レイヤーです。ファインチューニング（モデルの重みに焼き込む）は確かに外部検索が不要になりますが、更新のたびに再訓練が必要で、リアルタイム性がありません。

ただし10年スパンで見ると、モデル自体がコンテキストウィンドウの中で記憶の圧縮・管理を自律的に行うようになる可能性はあります。Context Compactionやメッセージ履歴の自動要約がその萌芽です。「検索して持ってくる」より「すでに記憶している」世界が実現すれば、外部のベクトルDBへの依存度は下がるかもしれません。これはベクトルDBの存続を左右する最大の変数の一つです。

形を変えて残る可能性

The New Stackは「RAGは死んでいない。コンテキストエンジニアリングにリブランドされただけ」と指摘しています。RAGFlowの2025年振り返りでも、RAGは「検索拡張生成」という特定パターンから、「インテリジェント検索を中核とするコンテキストエンジン」へと進化していると分析されています（なお、これらはRAGエコシステム側からの見解である点は留意が必要です）。

10年後に残るのは「ベクトルDB」という名前ではなく、「大量データから関連情報を効率的に取得する」という機能的需要の方でしょう。その実装が何と呼ばれているかは、今から予測しても仕方がない。重要なのは、自分のユースケースが「検索して持ってくる」と「すでに記憶している」のどちら側に倒れるかを見極めることです。

---

6. 実務者のための設計判断フレームワーク

「で、結局どうすればいいの？」に対する回答として、判断フレームワークを提示します。

ステップ1：データ規模を確認する

データ規模	推奨アプローチ
〜100件（数万トークン）	長文コンテキスト全文投入
100〜10,000件	Agentic Search + 必要に応じてベクトルDB
10,000件〜	ベクトルDB（またはハイブリッド検索）必須

ステップ2：更新頻度を確認する

更新頻度	考慮事項
リアルタイム	MCP経由のライブ取得、またはAgentic Search
日次〜週次	ベクトルDBのインデックス更新で対応可能
ほぼ静的	プロンプトキャッシュの活用でコスト削減

ステップ3：レイテンシ要件を確認する

要件	推奨
ms単位（検索UI等）	ベクトルDB一択
数秒許容（チャットBot）	ハイブリッド（ベクトルDB + Agentic）
分単位許容（バッチ処理）	Agentic Search / 長文コンテキスト

ステップ4：組み合わせを設計する

ほとんどの実務プロジェクトでは、単一の手段で完結しません。設計すべきは「どの手段を、どの条件で、どの比率で使うか」というコンテキストパイプライン全体の構成です。

---

まとめ

コンテキストエンジニアリングは、プロンプトエンジニアリングの上位互換として、LLMアプリケーション設計の中心概念になりつつあります。

その中で、ベクトルDBは「コンテキストの取得手段の一つ」として明確に位置づけられます。MCP・Agent Skills・長文コンテキストとは排他関係ではなく、同じパイプラインの中で併用されるのが実態です。

「RAG不要論」はポジションを立てることで注目を集める効果はあります。しかし、エンジニアリングの設計判断としては、データ規模・更新頻度・レイテンシ要件・コスト制約を踏まえた組み合わせ設計が正解です。

10年後を見据えるなら、特定の実装技術（ベクトルDB）に賭けるのではなく、コンテキストエンジニアリングという設計思想を身につけることが、変化に対応できる最も確実な投資です。

関連記事

• RAG不要論争を整理：Claude Codeが「狭義RAG（ベクターDB）」を捨てた理由と、コード検索の現実解 — コード検索に限定した狭義RAG vs Agentic Searchの詳細分析
• MCP vs Agent Skills論争の本質を整理する：カテゴリエラーに惑わされないために — プロトコルとナレッジのカテゴリエラーを解く

参考リンク

• Anthropic: Effective context engineering for AI agents（公式）
• The New Stack: RAG isn't dead, but context engineering is the new hotness
• RAGFlow: From RAG to Context — A 2025 year-end review
• Towards Data Science: Is RAG Dead? The Rise of Context Engineering
• Towards Data Science: Why Context Is the New Currency in AI
• Claude Pricing（公式）

---

本記事は2026年2月時点の情報に基づいています。

ポスト