Pineconeとは？サーバーレス型ベクトルDBの料金・制限値・実装と選び分け【2026年版】

Pineconeは、ベクトル検索に特化したマネージドデータベースです。2026年7月時点の公式ドキュメントはサーバーレス構成を前提としており、容量を確保して定額を払う旧来のpod方式は現行の制限一覧から姿を消しました。この記事では4プランの実額と月額の概算手順、名前空間あたり毎秒100リクエストという本番で先に当たる制限値、pgvectorやS3 Vectorsとの選び分け基準、そして日本国内案件で最初に確認すべき東京リージョンの扱いを整理しました。

まとめ：Pinecone採用の判断基準と見送る条件

選ぶ条件は3つです。ベクトル件数が数千万を超える見込みがあること、検索レイテンシに数十ミリ秒台の要件があること、インデックス再構築やレプリカ配置を自前で運用する工数を持たないこと。この3つが揃えば、ストレージ0.33ドル毎GB毎月と読み取りユニット100万あたり16〜18ドル（Standardプラン）という従量課金は自前運用の人件費を下回ります。

見送る条件も明確です。PostgreSQLをすでに運用し、対象が数十万件規模で、検索が管理画面の裏側にとどまるならpgvector拡張で足ります。テナント分離やハイブリッド検索の調整余地まで自分で握りたい案件では、自社ホスト型のWeaviateが対抗馬になります。もう1つの関門が地理です。2026年7月時点でサーバーレスリージョンに東京はなく、アジア太平洋はap-southeast-1（シンガポール）が最短。国内にデータを置く契約要件がある案件は、この1点で採否が決まります。

ベクトルデータベースとしてのPineconeの位置づけと提供形態

マネージドサーバーレス構成が引き受ける運用範囲と手元に残る作業

サーバーレスインデックスでは、シャード配置・レプリカ数・インデックス再構築・スケールアウトの判断がすべて製品側に入ります。2026年3月26日には、バックアップと復元、オブジェクトストレージからの一括取り込み、監査ログ、顧客管理鍵（CMEK）、Prometheus形式の監視エンドポイントが一斉に正式提供へ移りました。

手元に残るのは検索品質を決める工程です。文書をどの粒度で切るか、どの埋め込みモデルを使うか、結果を再並べ替えするかどうか。この3つが精度の大半を決めます。内部構造から押さえたい場合はベクトル化とインデックス構造から理解するベクトルデータベースの仕組みから入ってください。

密ベクトル・疎ベクトル・文書スキーマという3種類のインデックス

インデックスは3系統です。密ベクトル（dense）は意味の近さを扱い、次元上限は20,000。疎ベクトル（sparse）は語の一致を扱い、1ベクトルの非ゼロ要素は2,048まで、次元空間は42億まで取れます。3つ目の文書スキーマインデックスは、密ベクトル・疎ベクトル・全文検索対象の文字列フィールドを1レコードに同居させる構成です。

文書スキーマと全文検索は2026年5月4日にパブリックプレビューとして公開され、BM25とLucene相当のクエリ構文に対応しました。7月21日には~演算子によるあいまい一致とn-gram部分一致が加わっています。対応APIバージョンは2026-01.alphaで、提供状態はプレビューのまま。密と疎の組み合わせ方はBM25とベクトル検索を統合するハイブリッド検索の仕組みとRRFで整理しています。

名前空間によるテナント分離とメタデータ絞り込みを併用する設計

名前空間（namespace）は1インデックス内をレコード単位で分割する仕組みで、upsert時に指定すれば自動で作られます。明示的な作成APIも2026年3月26日に正式提供へ移りました。読み書きは必ず1つの名前空間を対象に実行されるため、マルチテナントの分離境界としてそのまま使えます。上限は1インデックスあたりStarter100、Builder1,000、StandardとEnterpriseが100,000です。

もう1つの絞り込み軸がメタデータです。フラットなキー値をレコードに持たせ、$eq $gte $lt $in $nin $exists $and $or などで条件を組みます。1レコードあたり40KBまで、$inと$ninの値は各10,000個までで、この上限は2026年1月23日から強制されました。混ざってはいけない境界は名前空間で切り、同一検索の中で絞りたい属性はメタデータに置く。名前空間を属性の数だけ増やすと、後述するレート制限の分母を細切れにします。

Starter・Builder・Standard・Enterpriseの料金と課金単位

4プランの月額下限とストレージ・名前空間の上限を並べた一覧表

実装判断に効く列だけを並べました。金額は米ドル建て、2026年7月時点の値です。

Standardより上は単価に幅があり、クラウドとリージョンで変わります。Enterpriseは単価が5割前後高い代わりに、1組織100プロジェクト・1プロジェクト200インデックスという枠が付きます。下り転送は月100GBまで無償で、超過分が0.10ドル毎GB。見落としやすいのがBuilderで、2026年5月4日に月20ドル定額で新設され、6月3日からAWS・GCP・Azureをまたぐ構成にも対応しました。

読み取りユニットと書き込みユニットの単価から月額を概算する手順

従量部分はストレージ量・書き込みユニット・読み取りユニットの3軸で決まります。読み取りユニットはクエリ1回で固定ではなく、走査した対象の規模に応じて増えます。

1. 格納レコード数×次元数×4バイトで生データ量を出し、メタデータ分を加えてGB換算する
2. 初期投入と月次更新のレコード数から書き込みユニットを見積もる
3. 想定クエリ数に、絞り込み後の走査規模から算出した1クエリあたりのユニット数を掛ける
4. 3つの小計にStandard単価を当て、月額下限50ドルと比べて高い方を請求見込みとする

1,024次元100万件なら生データは約4GB、ストレージは月1.3ドル前後です。初期投入の書き込みユニットはStandardで十数ドル。ここに月10万クエリが乗ると読み取りユニットが数千万に達し、支配的な費目になる。請求額を決めるのは格納量ではなく検索回数です。次元数を削るより、同一クエリの再実行をキャッシュで減らす方が効きます。読み取りが常時高い構成には、2026年4月15日に正式提供へ移ったDedicated Read Nodes（読み取り専用ノードの固定確保）もあります。

埋め込みとリランクの推論課金および一括取り込み単価の改定内容

Pinecone内で埋め込みとリランクを実行する場合、データベース課金とは別に推論課金が発生します。llama-text-embed-v2は100万トークン0.16ドル、multilingual-e5-largeは0.08ドル、リランクは1,000リクエスト2ドル（StandardとEnterpriseの単価）。リランクを全クエリに無条件で挟むと、読み取りユニットより先に費用が膨らみます。

初期移行の費用は2026年6月1日に下がりました。一括取り込みが0.25ドル毎GBに改定され、StandardとEnterpriseの組織には250ドルのクレジットが一度だけ付与されます。数十GB規模の初期投入は、APIのupsertで流すよりS3やGCSに置いて一括取り込みを使う方が有利です。リランク側では2026年7月1日にCohere Rerank 4.0 Fastが正式提供となりcohere-rerank-3.5は非推奨。8月1日から新モデルへ自動的に振り替えられるため、モデル名を固定して呼ぶ実装は挙動が変わる前提で見ておいてください。

Python SDKでのインデックス作成から検索までの実装手順

APIバージョンはYYYY-MM形式で四半期ごとに更新され、公式は2026年7月時点で2026-04系を最新の安定版として提示しています。安定版は12か月以上サポートされ、移行期間も9か月以上が確保されます。

統合埋め込みモデルを指定してインデックスを作る最小コードと確認点

もっとも短い経路は、埋め込みをPinecone側に任せるcreate_index_for_modelです。name、cloud、region、そしてembedにmodelとfield_mapを渡します。field_mapはどのフィールドを埋め込むかの対応表で、textキーに対象フィールド名を指定。作成前にhas_indexで存在確認を挟むのが定型です。

この方式ならアプリ側は生テキストをそのままupsertでき、次元数の指定もモデル選定も不要です。密ベクトルはllama-text-embed-v2（既定1024次元。2048・768・512・384も指定可）とmultilingual-e5-large（1024次元固定）、疎ベクトルはpinecone-sparse-english-v0。インデックス作成後にモデルと次元数は変えられないため、モデル比較は検証用インデックスで先に済ませます。

自前ベクトルを使う場合の次元数・距離指標の指定と次元の上限値

埋め込みを自分で持つ場合はcreate_indexを使い、vector_typeにdense、dimensionにモデルの次元数、metricに距離指標、specにServerlessSpecでcloudとregionを渡します。距離指標はcosine、euclidean、dotproductの3つ。学習時に用いた指標に合わせるのが原則で、正規化済みベクトルならcosineとdotproductは同じ順位を返します。

本番ではdeletion_protectionを有効にし、環境やチームを記録するtagsを付けておくと請求内訳を後から切り分けられます。密ベクトルの次元上限は20,000で、市販モデルはおおむね384〜4,096次元なので実務で当たる壁ではありません。ただし次元数はストレージと読み取りユニットの双方に比例するため、次元を選べるモデルでは1024と512で精度を実測し、差がなければ小さい方を選びます。

絞り込み条件付きの検索にリランクを重ねる呼び出し順序と注意点

検索の呼び出しは、対象名前空間、クエリベクトルまたはクエリ文字列、top_k、メタデータのfilterという組み合わせです。リランクを併用する順序は固定されています。まずベクトル検索で候補を広めに取り、その候補集合だけをリランクモデルに渡して並べ替え、上位を生成モデルに渡す。逆順にはできません。

top_kの上限は10,000ですが、クエリ結果は4MBまでという別の制約があるため、メタデータが大きいレコードでは10,000件に届く前に上限へ当たります。リランクの1,000リクエスト2ドルは「1クエリ1リクエスト」の積み上がりなので、絞り込みで十分な精度が出るクエリでは呼ばない分岐を入れてください。モデルの種類と選び方はリランクモデルの種類・仕組み・選び方にまとめています。

pgvector・Chroma・S3 Vectorsとの選び分けの判断基準

運用負荷・レイテンシ要件・データ量で4製品を切り分ける判断軸

切り分けはデータ量ではなく運用体制から入ります。専任のインフラ担当がいない体制で数千万件を扱うならPinecone。既存のPostgreSQLに業務データがあり、検索結果をSQLの結合や集計と混ぜたいならpgvector。ローカルで仕様を固める段階ならChroma。検索頻度が低く容量が大きい保管寄りの用途なら、格納コストの安いAmazon S3 Vectors APIの操作一覧と料金が有利です。

既存PostgreSQL資産がある場合にPineconeを選ばない条件

次の3条件がすべて当てはまる案件では、Pineconeを採用しません。対象ドキュメントが数十万件以下。検索がユーザー向けのリアルタイム機能ではなく社内画面や日次バッチの一部。PostgreSQLをすでに運用していて、検索結果を権限テーブルや履歴テーブルと結合する必要がある。

理由は3点です。この規模ならpgvectorのインデックス性能で要件を満たせます。DBを2つに分けると「ベクトル側は消したのに本体が残る」型の不整合を自力で防ぐ実装が増える。月額下限50ドルとは別に、埋め込み生成と同期処理の開発工数も乗ります。到達点はpgvectorによるPostgreSQLでのベクトル検索で確認してから越境の是非を判断してください。

本番運用で最初に当たる制限値とレート制限への具体的な回避設計

名前空間あたり毎秒100リクエスト上限に当たった際の分割方針

2026年1月16日から、データ操作にレート制限が入りました。クエリ・upsert・deleteはいずれも1名前空間あたり毎秒100リクエスト。インデックス単位ではdeleteが毎秒5,000レコード、fetchが毎秒100、listが毎秒200という別枠です。

全社共通の1名前空間に全文書を入れる構成は、この上限に真正面から当たります。毎秒100を超える見込みがあるなら、テナントや部署で名前空間を分けて分母を増やしてください。分けられない単一テナントなら、クライアント側のリトライとバックオフに加え、日次の大量投入をupsertで捌かず一括取り込みへ寄せるのが現実的な手当てです。

upsert1,000件とtop_k上限が設計に与える影響の整理

1回のupsertに載せられるのは、ベクトル付きで1,000レコードまたは2MBのいずれか小さい方です。1,024次元の密ベクトルは4KB強あるため、2MBの制約が先に来て実際は400件前後で分割することになります。バッチサイズを1,000で固定した実装は、次元を増やした瞬間に失敗する。バイト数で切る実装にしてください。

読み取り側も名目値ではなくバイト数で先に当たります。fetchは1回1,000IDまでで応答は10,000レコードまで、レコードIDは512文字、メタデータは1レコード40KBという上限。文書本文をメタデータに丸ごと入れる設計は40KBで詰まるため、本文は別ストレージに置き、メタデータには参照キーと絞り込み用の属性だけを持たせます。

失敗パターンとして避けたい全文検索プレビュー機能への本番依存

採用してはいけない構成を1つ挙げます。文書スキーマインデックスの全文検索を、本番のキーワード検索機能の唯一の実装として据えることです。この機能は2026年5月4日にパブリックプレビューとして公開され、7月21日のあいまい一致と部分一致の追加を経ても提供状態は変わっていません。対応APIは2026-01.alphaで、安定版の12か月サポートという保証の外にあります。

プレビュー機能は仕様が変わり、正式提供の時期も約束されません。全文検索が要件に入るなら、疎ベクトル（pinecone-sparse-english-v0や自前のBM25スコア）で組んで安定版APIの内側に収めるか、キーワード検索を別のエンジンに寄せて役割を分けてください。

東京リージョンの不在が日本国内案件の採否に与える影響と代替策

2026年7月時点で選べるサーバーレスリージョンは、AWSがus-east-1・us-west-2・eu-west-1・eu-central-1・ap-southeast-1、GCPがus-central1・europe-west4、Azureがeastus2です。5月1日にフランクフルトとシンガポールが加わりましたが、東京は一覧にありません。

影響は2つに分かれます。往復の数十ミリ秒はRAGの応答時間では生成モデルの推論に埋もれるため、検索1回なら許容範囲に収まることが多い。問題はもう一方です。個人情報や機密文書を国内に置く契約要件がある案件では、ベクトル化した埋め込みも保管データとして扱う判断が一般的なため、リージョン不在がそのまま失格条件になります。

代替策は3つです。国内要件が絶対なら、東京リージョンで動くpgvectorやAWSのマネージドサービスへ寄せる。要件が「日本国内または同等の管理水準」なら、CMEKと監査ログ（ともに2026年3月26日に正式提供）で管理水準を示して承認を取る。組織の管理下にインフラを置く必要があるなら、2026年2月19日にパブリックプレビューへ入ったBring Your Own Cloud（自社クラウドアカウント内での稼働）を検討する。この順で確認すれば、要件定義の段階で採否が確定します。

RAG基盤の一部としてPineconeを採用するまでの判断手順

社内文書RAGの構築を外部に委託する場合の切り分けと相談範囲

社内文書を対象にしたRAGの工程は5つです。文書の棚卸しと権限設計、抽出とチャンク分割、埋め込みとベクトルストア構築、検索と生成の組み立て、精度評価と継続運用。Pineconeが担うのは3番目の一部だけで、費用と工数の大半は前後の工程に乗ります。求めた文書が上位に来ない原因も、チャンクの粗さや埋め込みモデルの選定という製品の外側にあることが多い。分割の設計はチャンク分割の手法とRAGで効くチャンクサイズ、前提となる全体像はRAGの仕組みとLLM・ファインチューニングとの違いにまとめています。

見積りが割れるのは1番目と5番目です。権限設計を後回しにすると、部署をまたいで見えてはいけない文書が検索結果に出る事故が起きる。評価の仕組みがないと、モデルや分割を変えたときに良くなったのか悪くなったのかを言えません。この2工程を含めた設計から相談する場合はRAG構築支援で対応範囲を公開しています。どこを自前で持つかを先に線引きすると、件数・クエリ頻度・データ所在という選定要件が確定します。

よくある質問

導入検討で問い合わせの多い5点をまとめます。

Pineconeは無料で使えますか？

Starterプランが無料で使えます。上限は1組織あたりストレージ2GB、月間の書き込みユニット200万、読み取りユニット100万、インデックス5個、1インデックスあたり名前空間100個。数万件規模のプロトタイプなら十分に収まる範囲です。上限に近づいたら、月20ドル定額で10GBまで扱えるBuilderプラン（2026年5月新設）が次の段になります。

日本語の文書でもPineconeは使えますか？

使えます。Pinecone自体は言語に依存せずベクトルを扱うため、埋め込みモデル側が日本語に対応していれば問題ありません。Pinecone内で埋め込む場合は多言語対応のllama-text-embed-v2またはmultilingual-e5-largeを選びます。疎ベクトル用のpinecone-sparse-english-v0は英語向けなので、日本語の語一致には不向きです。

Pineconeとpgvectorはどちらを選ぶべきですか？

判断軸は件数と運用体制です。数十万件以下でPostgreSQLをすでに運用しており、検索結果を既存テーブルと結合したいならpgvector。数千万件を超える見込みがあり、レイテンシに要件があり、インデックス運用の担当を置けないならPineconeを選びます。国内にデータを置く契約要件がある案件は、東京リージョンがない点だけでpgvector側に決まります。

Pineconeのpod方式は今も使えますか？

2026年7月時点の公式ドキュメントはサーバーレスインデックスとDedicated Read Nodesを前提に構成されており、制限値の一覧にpod方式の記載はありません。新規構築ならサーバーレスを選ぶ前提で設計します。既存のpod方式インデックスの扱いは契約プランごとに案内が異なるため、公式の移行ガイドとサポート窓口で現在の状態を確認してください。

Pineconeのセキュリティ要件はどこまで満たせますか？

2026年3月26日に顧客管理鍵（CMEK）と監査ログが正式提供へ移り、暗号鍵の管理と操作記録の取得ができます。医療情報を扱う場合の選択肢は、Standardプランに付ける月190ドルのHIPAAアドオンです。権限管理は同年7月13日に組織メンバーとプロジェクトメンバーの役割が追加され、7月20日からEnterprise向けにSAMLとSCIMの連携が使えます。

関連記事

• ベクトル化とインデックス構造から理解するベクトルデータベースの仕組み：内部の近似最近傍探索の構造から確認できます
• ChromaDBとは？アーキテクチャ・使い方・pgvectorとの違いまで：ローカル検証段階での対抗軸になります
• ベクトルデータベースとグラフデータベースの違い：ベクトル検索だけで足りるかを判断できます
• チャンク分割とは？手法とRAGで効くチャンクサイズ：Pineconeの外側にある検索精度の主因を分割設計から見直せます
• リランクモデルとは？種類・仕組み・選び方：リランク併用の是非と単価に見合う使い方が分かります