Pinecone完全ガイド — Claude Code/DifyなどAIエージェントにベクトルDBを組み込む【2026年版】
PineconeをAIエージェント開発に組み込む方法を実践ベースで解説。料金プランの実額、Python SDKでのRAG構築手順、Claude CodeのMCPサーバー経由での接続設定、他のベクトルDBとの使い分けまで。フリーランスエンジニアの実体験ベース。
※ 本記事にはアフィリエイトリンクが含まれています。記事内リンクから申し込みがあった場合、筆者に紹介報酬が発生します。内容は独自調査に基づいており、報酬によって評価が変わることはありません。 #PR
エンジニアのゆとです。
「ベクトルDB」という言葉、AIエージェント界隈にいると1日1回は耳にすると思う。でも実際に自分の手で組み込んだことがある人は、想像してるより少ない気がする。僕もそうだった。RAG（Retrieval-Augmented Generation）の概念は知ってたけど、じゃあ実装しろと言われたら「何から手をつければいいんだっけ」となる状態が半年くらい続いてた。
この記事はPinecone単体にフォーカスして書く。DifyのRAG機能については以下の記事で軽く触れたけど、あれはあくまで「Difyの外部ベクトルDB設定」の話。今回は「なぜベクトルDBが必要なのか」から「Claude CodeのMCP経由でPineconeを叩く」まで、Pineconeそのものを主役にして書く。
なぜベクトルDBが必要なのか — 個人開発でRAGアプリを作った時の話
きっかけは、自分が書いた過去の記事とクライアントワークのドキュメントを横断検索したいと思ったことだった。ローカルにMarkdownファイルが200本くらい溜まってて、「あの案件でSlack連携どう実装したっけ」を毎回grepで探すのが限界だった。
最初はChromaでローカルに済ませようとした。pip install chromadbして、埋め込みを作って、SQLiteベースでローカル保存。これは無料だし手軽で、個人利用ならこれで十分だった。
問題が起きたのは、このツールをクライアント向けの社内検索ツールとして納品する話が出た時だ。ローカルファイルベースのChromaだと、複数人が同時にアクセスする本番環境での運用に不安が残る。スケーラビリティ、バックアップ、可用性——自分でインフラを面倒見る前提になる。
ここで初めて「マネージドのベクトルDBに移行する」という判断が必要になった。自分でインフラを持たずに、検索性能とスケーラビリティを外部に任せる。これがPineconeを触った理由だ。抽象的に言うと「ベクトル検索基盤をマネージドサービスに切り出す」だけど、実感としては「インフラ管理から解放されて実装に集中できる」というシンプルな話だった。
ちなみに個人のPoCレベルなら無理にPineconeに移行する必要はない。pgvector（PostgreSQL拡張）やChromaのローカル運用でも十分なケースは多い。「複数人が同時アクセスする」「本番で落ちたら困る」「データ量が数百万件を超えそう」——このあたりの条件が揃ってきたら検討する、くらいの温度感でいいと思う。
Pineconeの料金プラン（2026年7月時点の実額）
料金は変動するので、最新情報は必ず公式で確認してほしい。とはいえ「だいたいいくらかかるのか」の感覚がないと検討すら始まらないので、確認できた実額を載せておく。
| プラン | 月額 | ストレージ | 用途 |
|---|---|---|---|
| Starter | 無料 | 2GBまで | 検証・小規模アプリ |
| Builder | $20〜 | 10GBまで | ソロ開発者・小チーム |
| Standard | 最低$50/月 | 無制限（$0.33/GB/月） | 本番環境全般 |
| Enterprise | 最低$500/月 | 無制限 | SLA必須のミッションクリティカル案件 |
Starterプランは月間書き込み200万ユニット・読み込み100万ユニットまで無料で使える。個人開発のRAGアプリなら、このStarterプランの枠内で運用できてしまうケースがかなり多い。僕が最初に作った検索ツールも、Starterのまま半年以上運用してる。
Standardプラン以降は読み込みが100万ユニットあたり$16〜18、ストレージが$0.33/GB/月という従量課金になる。ここで注意したいのは「ユニット」の考え方が独特なこと。書き込みユニットはベクトルの次元数やレコードサイズで変わるし、読み込みユニットはクエリのtop_k（何件返すか）やフィルタの複雑さで変わる。EnterpriseはSLA 99.95%が付く代わりに最低$500/月からなので、個人開発の範囲ではまず検討しなくていい。
バックアップ保存は$0.10/GB/月、復元は$0.15/GBで別途課金される。本番運用するなら、この分も含めてコストを見積もっておいた方がいい。
Python SDKでインデックス作成からRAG検索まで実装する
実装の流れを追ってみる。まずはPineconeが提供している「統合埋め込み」を使うパターン。埋め込みモデルの管理をPinecone側に任せられるので、自前で埋め込みAPIを叩く手間が省ける。
from pinecone import Pinecone
pc = Pinecone(api_key="YOUR_API_KEY")
# インデックス作成（埋め込みモデルを指定するだけ）
pc.create_index_for_model(
name="my-knowledge-base",
cloud="aws",
region="us-east-1",
embed={"model": "llama-text-embed-v2", "field_map": {"text": "content"}}
)
index = pc.Index("my-knowledge-base")
# データの投入(テキストをそのまま渡せる。埋め込み変換はPinecone側で実行)
index.upsert_records(
namespace="docs",
records=[
{"_id": "rec1", "content": "Claude CodeはCLIベースのAIコーディングツール", "category": "tools"},
{"_id": "rec2", "content": "Pineconeはマネージド型のベクトルデータベース", "category": "infra"},
]
)
# セマンティック検索 + リランキング
results = index.search(
namespace="docs",
query={"top_k": 5, "inputs": {"text": "AIコーディングツールについて知りたい"}},
rerank={"model": "bge-reranker-v2-m3", "top_n": 3, "rank_fields": ["content"]}
)もう一つ、自前の埋め込みモデル(OpenAIやClaude経由のembedding API等)を使う従来型のパターンも紹介しておく。実務ではこちらの方が使うケースが多い。すでに社内で使ってる埋め込みモデルがあったり、日本語精度を重視したい場合はこっちを選ぶことになる。
from pinecone import Pinecone, ServerlessSpec
pc = Pinecone(api_key="YOUR_API_KEY")
# 次元数は使う埋め込みモデルに合わせる(例: text-embedding-3-smallなら1536次元)
pc.create_index(
name="my-docs",
dimension=1536,
metric="cosine",
spec=ServerlessSpec(cloud="aws", region="us-east-1")
)
index = pc.Index("my-docs")
# 自分で作った埋め込みベクトルを直接アップサート
index.upsert(vectors=[
{"id": "rec1", "values": embedding_vector, "metadata": {"content": "元のテキスト", "category": "tools"}}
])
# ベクトルで直接クエリ
results = index.query(vector=query_embedding, top_k=5, include_metadata=True)upsert_recordsを使う統合埋め込みの方が実装は楽だけど、対応してる埋め込みモデルが決まってるのでモデル選択の自由度は下がる。「とりあえず動くものを早く作りたい」なら統合埋め込み、「精度を追い込みたい」なら自前埋め込み、という使い分けになる。
Claude CodeのMCPサーバー経由でPineconeに接続する
ここが今回一番書きたかった部分。Claude CodeからPineconeを直接操作できるMCPサーバーが公式に提供されてる。RAGアプリの開発中に、ターミナルを行き来せずにClaude Code内でインデックスの中身を確認したり検索を試したりできるのが地味に便利だ。
前提として、PineconeのAPIキーとNode.js（npxが使える状態）が必要になる。
設定手順
claude mcp add-json pinecone-mcp \
'{"type": "stdio",
"command": "npx",
"args": ["-y", "@pinecone-database/mcp"],
"env": {"PINECONE_API_KEY": "YOUR_API_KEY"}}'設定後、Claude Code上で/mcpを実行すると接続状態が確認できる。うまく繋がっていれば、Claude Codeに「pineconeのインデックス一覧を見せて」と話しかけるだけでインデックス管理ができるようになる。検索・インデックス操作・レコードの読み書き・複数インデックス横断検索・リランキングまで、ツールとして一通り揃ってる。
僕がこれを一番使うのは、RAGアプリのデバッグ中だ。「このクエリで期待した結果が返ってこない」時に、Claude Codeに直接「このクエリでPineconeを検索して、返ってきたスコアを見せて」と頼める。ターミナルでPythonスクリプトを都度書いて実行する手間がなくなるので、チューニングのイテレーションが速くなる。
Claude Desktopでも同様の設定ができる。「Settings」→「Developer」→「Edit Config」からmcpServersに同じ設定を追加すればいい。
Dify のRAG機能との使い分け
Difyにはナレッジベース機能があり、デフォルトではQdrantが内部のベクトルDBとして動いている。ここで「じゃあPineconeはいつ使うのか」という疑問が出てくる。
僕の判断軸はシンプルで、Difyのビジュアルエディタで完結する範囲ならDifyのデフォルト設定のままでいい。ノーコードでチャットボットやワークフローを組んで、その中でRAGも使いたいという要件なら、わざわざPineconeに切り替える理由は薄い。
Pineconeに切り替える判断が必要になるのは、以下のようなケースだ。
- データ量が増えてレイテンシが気になり始めた（Difyの内部DBはスケール前提の設計ではない）
- PineconeのRAG機能を、Dify以外の自作アプリからも共通で使い回したい
- 独自の埋め込みモデルやリランキングロジックを細かく制御したい
- 複数のサービス(Difyアプリ、Claude Codeでのデバッグ、社内ツール)から同じベクトルDBを参照する構成にしたい
要は「DifyというプラットフォームのRAG」で完結するか、「アプリをまたいで使い回せるベクトル検索基盤」が必要かの違いだ。後者を選ぶなら、DifyのシステムベクトルDB設定からPineconeに切り替えられる。手順はDifyの「システム設定」→「ベクトルデータベース」→「Pinecone」でAPIキーを入力するだけなので、移行コストは低い。
他のベクトルDBとの比較
個人開発〜中規模の案件で候補に上がりやすいベクトルDBを比較しておく。
| DB | ホスティング | 特徴 | 向いてる用途 |
|---|---|---|---|
| Pinecone | フルマネージド | インフラ管理不要、スケール前提の設計 | 本番運用、複数アプリからの共通利用 |
| Qdrant | OSS/クラウド両対応 | セルフホスト可能、Dify標準搭載 | データ主権重視、Difyとの統合前提 |
| Chroma | ローカル/OSS | 軽量、Pythonで即座に使える | 個人のPoC、プロトタイピング |
| pgvector | PostgreSQL拡張 | 既存DBに相乗り、追加インフラ不要 | すでにPostgreSQLを使ってる案件 |
正直に言うと、すでにPostgreSQLを使ってる案件ならpgvectorが一番手軽なケースは多い。新しいインフラを増やさずに済むし、既存のトランザクションと同じDBでベクトル検索できるメリットは大きい。ただし数百万件を超える規模になると、専用設計されたPineconeのようなサービスとの性能差が見えてくる、というのが僕の体感だ。
まとめ
ベクトルDBの選定は「とりあえずPineconeにしとけばOK」という話ではない。個人のPoCならローカルのChromaやpgvectorで十分なことが多いし、Difyでノーコード完結するならDify標準のQdrantのままでいい。
Pineconeを選ぶ判断軸は以下に整理できる。
- 本番運用でスケーラビリティ・可用性が必要になったタイミング
- 複数のアプリ・サービスから同じベクトル検索基盤を共通利用したい時
- インフラ管理をせずに検索性能のチューニングだけに集中したい時
無料のStarterプランで小規模なら十分検証できるので、まずは自分の手で触ってみるのが一番早い。Claude CodeのMCP連携を使えば、実装しながらインデックスの中身を確認できるので、RAGアプリの開発体験としてもかなり快適だった。
