Pinecone：概要と使い方

私たちの利害はほぼゼロですが、それでも書いておきます。私たちは Geonode でプロキシを売っており、ベクトルデータベースとは無関係です。唯一の接点は、検索システムには検索対象が必要で、そのコンテンツが公開ウェブ由来なら誰かが収集しなければならない、という点です — それがパイプラインにおける私たちの側であり、データベースとは完全に別です。この記事のどこにも当社から何かを買う必要はなく、マネージドベクトルDBに反対する節を入れたのは、それがしばしば正しい答えだからです。

ベクトルデータベースがすること

普通のデータベースは完全一致します。ベクトルデータベースは類似度で一致します。

仕組みはこうです。embedding モデルがテキスト、画像、その他のコンテンツを数値のリスト — ベクトル — に変換し、似たものが近くに来るよう配置します。関連結果を見つけることは近くの点を見つけることになり、文字列照合ではなく幾何の問題になります。

Pinecone は自らを “the vector database for AI agents and applications, built for semantic search, knowledge retrieval, and long-term memory at scale” と述べ、能力をミリ秒で “through billions of items for similar matches to any object” と位置づけています。

これがライブラリではなくインフラになった理由は規模です。クエリを100万ベクトルと総当たりで比べるのは単純で遅い。ミリ秒でやるには近似最近傍 indexes が必要で、それを規模で安定運用するのはオペレーションの問題です。マネージドサービスが売っているのはそれです。

支配的な用途は検索拡張生成です。ユーザーの質問に対し、自前ドキュメントから最も関連する箇所を見つけ、言語モデルに文脈として渡します。データベースが担うのは「関連箇所を見つける」ステップです。

Indexes、ドキュメント、records

Pinecone のデータモデルは形を変えており、現状のまま理解する価値があります。

Index がデータの置き場です。 ドキュメント は “a serverless index holds your data as documents or records, depending on how the index was created: an index created with a document schema holds documents, while an index created with a dense or sparse vector type holds records” と説明します。

ドキュメント schema は1つの index に複数の仕事をさせます。 ドキュメントによれば “a single index with a document schema can mix multiple ranking field types: a dense_vector field for semantic search, a sparse_vector field for sparse-vector retrieval, and one or more string fields with full_text_search enabled for full-text search with BM25 and Lucene queries.”

メタデータに宣言は不要です。 “Any other fields you upsert are stored as metadata, automatically indexed for filtering — no schema declaration required.”

設計指針ははっきりしています。“One index per use case is the typical pattern. Because a document can combine vectors, text, and metadata in the same record, a single index often covers what previously required two — pick the ranking signal per query with score_by.”

最後の点が本質です。全文検索は同じ index でベクトル検索と並んで使えます — “BM25 token matching with Lucene query syntax over text fields in your schema”。Pinecone が “tokenization, IDF, and length normalization at index time and BM25 scoring at query time” を担います。別の検索エンジンは不要で、キーワード側にモデルも不要です。

実務上の帰結は、ハイブリッド検索 — 意味的類似と正確なキーワード一致の組み合わせ — がアーキテクチャではなくクエリ時の選択になることです。これは重要です。純ベクトル検索は正確な識別子、製品コード、稀な固有名詞に弱いことで知られ、BM25 はまさにそこに強いからです。

Namespaces

マルチテナントアプリの設計に最も効く機能です。

ドキュメント: “Within an index, records are partitioned into namespaces, and all upserts, queries, and other data read and write operations always target one namespace.”

利点は2つ挙げられています。マルチテナンシー — “when you need to isolate data between customers, you can use one namespace per customer and target each customer's writes and queries to their dedicated namespace.” そして より速いクエリ — “when you divide records into namespaces in a logical way, you speed up queries by ensuring only relevant records are scanned.”

運用上の注意は3つ。

暗黙に作られます。 “Namespaces are created automatically during upsert. If a namespace doesn't exist, it is created implicitly.” 便利ですが、namespace 名の打ち間違いはエラーではなく、静かに空の検索になります。

上限はプラン次第です。 “Namespaces per serverless index vary by plan. On the Standard and Enterprise plans, Pinecone can accommodate million-scale namespaces and beyond for specific use cases. If your application requires more than 100,000 namespaces, contact Support.”

隔離が要点です。 複数顧客のデータを持つなら、顧客ごとに1 namespace がパターンです。クロステナント漏洩はフィルタを正しくすることではなく、パラメータを1つ正しくすることになります。

Embeddings：自分のものか相手のものか

2つのやり方があり、選択には実害があります。

統合 embedding。 ドキュメントは4ステップで説明します。“Create an index that is integrated with one of Pinecone's hosted embedding models. Upsert your source text. Pinecone uses the integrated model to convert the text to vectors automatically. Search with a query text. Again, Pinecone uses the integrated model to convert the text to a vector automatically.”

より簡単です — テキストを送り結果を受け取り、自前の embedding パイプラインは不要です。文書化された制限: “Indexes with integrated embedding do not support updating or importing with text.”

自分のベクトルを持ち込む。 embedding モデルを自分で動かし、その特性に合う index を作り、ベクトルを直接 upsert し、“the same external embedding model to convert a query to a vector” を使います。

手間は増え、制御も増えます。Pinecone がホストしないモデルを使え、プライバシーやコストのためにローカルで embedding でき、何より自分のスケジュールでモデルを変えられます。

多くの人にとって決め手になる考慮点: embedding モデルを変えることは、すべてを再 embedding することです。異なるモデルのベクトルは比較できないので、切り替えは完全な再 index です。統合 embedding は初期構築を簡単にし、判断をベンダーのモデルカタログに縛ります。自分で持ち込むと構築は難しくなり、選択は自分のものです。どちらも誤りではなく、最初に見たチュートリアルではなく意図して決める価値があります。

大規模なデータ投入

見落としやすく、発覚すると高いコストの注意です。

ドキュメントは具体的です。“To control costs when ingesting large datasets (10,000,000+ records), use import instead of upsert.”

取り込み経路は2つ。Upsert は API 経由で records を送ります。Import はオブジェクトストレージから Parquet ファイルを読み、ドキュメントはそれを “the most efficient and cost-effective way to load large numbers of records into an index” と呼んでいます。

書き込みは百万 write units ごとに課金されるので、大規模な初回ロードにおけるこの2経路の差は丸め誤差ではなく実数です。数百万 records の index を作るなら、最初から import 経路を計画してください。高い初回ロードの後で付け替えるのは、二度払う必要のない教訓です。

実践での始め方

最初の実装の形と、そこに埋め込まれた判断です。

Index を作り upsert する。 統合 embedding なら流れは短く、ベクトルには触れません。

from pinecone import Pinecone

pc = Pinecone(api_key=API_KEY)

index = pc.Index(host=INDEX_HOST)

index.upsert_records(
    namespace="customer-42",
    records=[
        {"_id": "doc-1", "chunk_text": "Refunds are processed within 14 days.",
         "source": "policy.pdf", "page": 3},
        {"_id": "doc-2", "chunk_text": "Shipping to the EU takes 3-5 working days.",
         "source": "shipping.pdf", "page": 1},
    ],
)

source と page は一度も宣言されていません。ランキングフィールド以外はメタデータとして保存され、フィルタ用に自動 index されるので、後からフィールドを足してもマイグレーションは不要です。

フィルタ付きクエリ:

results = index.search(
    namespace="customer-42",
    query={"inputs": {"text": "how long do refunds take?"}, "top_k": 5,
           "filter": {"source": {"$eq": "policy.pdf"}}},
)

このスニペットには、意図して決めるべき判断が3つあります。

Chunk サイズ。 upsert するテキストが返ってくる単位なので、チャンク分割がモデルの見え方を決めます。小さすぎると意味をなす文脈を失い、大きすぎると関連文の横に無関係なテキストが戻ります。万能解はありません。数百語で少し重ねるのが妥当な出発点で、推測より測定です。

メタデータがフィルタ面です。 後で絞り込みたくなるものをすべて保存してください。元ドキュメント、日付、節、言語、アクセスレベル。upsert 時に足すコストはゼロで、後から足すと再 upsert になります。

テナントごとに namespace。最初から、常に。 単一 namespace の index に後から隔離を入れることは、正しい対象へすべて再 upsert することです。namespaces で始めるコストはパラメータ1つで、将来の事故の一カテゴリを消せます。

そしてソーステキストを残す。 元ドキュメントを自分が制御できる場所に、チャンク分割コードと一緒に置いてください。embedding モデル、chunk サイズ、分割戦略を変えるとき — 変えることになります — index の再構築は考古学ではなく再実行です。

料金、確認済み

Pinecone 自身の 料金ページ より、2026年9月に確認。予算前に再確認してください。

計画に効く観察は4つ。

無料枠は評価に本当に使えます。 ストレージ2 GB と月100万 read units は、かなりの文書集合の上に本物のプロトタイプを作るのに足ります。

Builder は定額であり、最低利用額ではありません。 月20ドルで上限固定なので、従量プランにはない予測可能性があります。請求を見通しやすい小規模本番アプリに向きます。

Standard と Enterprise は超過付きの最低額です。 50ドルと500ドルは下限であり上限ではありません。実際の費用はその上の従量です。

読み取りは書き込みのおよそ4倍、百万 units あたり。 読み取りが百万あたり16–18ドル、書き込みが4–4.50ドルなので、読みが多いアプリ — ほとんどの検索システム — ではクエリが請求を支配します。頻出クエリのキャッシュは遅延だけでなく、直接のコストレバーです。

Enterprise は 99.95% 稼働 SLA、bring-your-own-cloud 配備、private endpoints、監査ログを足します。調達プロセスでは意味があり、プロトタイプでは全く意味のない一式です。

マネージドベクトルDBが不要なとき

ベンダーが書かない節です。しばしばそれが答えだから入れています。

コーパスが小さいとき。 およそ10万ベクトル未満なら、メモリ上の総当たり類似検索は普通のハードウェアで十分速い。NumPy 配列と内積はミリ秒で答え、コストはゼロで、外部依存をアーキテクチャから外せます。近似 index が必要になる閾値は、多くの人が思うより高いです。

すでに Postgres を動かしているとき。 pgvector 拡張は、すでに運用・バックアップしているデータベースにベクトル類似検索を足します。多くのアプリではこれが正解です。システムが1つ減り、他データとトランザクション一貫性があり、別請求もありません。

埋め込みライブラリで足りるとき。 FAISS などのライブラリやローカル vector store は、単一プロセスで数百万ベクトルを扱います。データが1台に収まりクエリ量が控えめなら、マネージドサービスは持っていない運用問題を解いています。

キーワード検索で足りるとき。 「セマンティック検索が必要」のかなりの部分は BM25 でよく足ります。安く、速く、完全に説明可能で、正確な識別子に強い。まず試してください。そして Pinecone に着地しても、全文検索は同じ index でこれをカバーします。

検索品質を測っていないとき。 データベースは通常、検索システムの制約要因ではありません。チャンク戦略、embedding モデルの選択、クエリの立て方のほうが遥かに重要で、インフラ判断の前に百行のローカルコードで三つとも試せます。

マネージドサービスを選ぶ理由は現実的で具体的です。何百万ものベクトル、安定した低遅延が必要なクエリ量、マルチテナント隔離、分散 index を運用したくないチーム。このうち2つ以上が当てはまるなら、費用に見合います。

よくある質問

Pinecone は何に使いますか？

AI アプリ向けのセマンティック検索、知識検索、長期記憶です。支配的なパターンは検索拡張生成で、質問に最も関連する自前ドキュメントの箇所を見つけ、言語モデルに文脈として渡します。

Pinecone は無料ですか？

無料の Starter プランがあり、ストレージ最大 2 GB、月 2M write units と 1M read units、egress 1 GB です。有料プランにコミットする前に本物のプロトタイプを作り評価するのに、本当に足ります。

Pinecone の料金は？

Starter は無料。Builder は上限固定の月額20ドル定額。Standard は月額最低利用 50ドル、Enterprise は 500ドル。どちらもストレージは月 0.33ドル/GB、書き込みは百万 units あたり 4–4.50ドル、読み取りは百万あたり 16–18ドル、egress は 100 GB 以降 0.10ドル/GB です。

Pinecone の namespace とは？

Index 内のパーティションです。すべての読み書きはちょうど1つの namespace を対象にし、顧客ごとに1 namespace というマルチテナント隔離の標準機構であり、クエリが関連パーティションだけを走査する性能最適化でもあります。

統合 embedding と自前ベクトル、どちらを使うべき？

統合 embedding のほうが簡単です。テキストを送れば Pinecone が変換します。自前ならモデル選択と移植性があり、embedding モデル変更はすべて再 embedding になるので重要です。統合 indexes はテキストでの update や import もサポートしません。

Pinecone はベクトル検索だけでなくキーワード検索もできますか？

できます。full_text_search を有効にした文字列フィールドは Lucene クエリ構文の BM25 ランキングを、dense および sparse ベクトルと同じ index でサポートし、スコア方法はクエリごとに選べます。純ベクトル検索は正確な識別子や稀な語に弱いので、これは重要です。

何百万もの records を効率よく載せるには？

upsert ではなくオブジェクトストレージからの import を使ってください。ドキュメントは1000万 records 超のデータセットに明示的にこれを勧め、最も費用対効果の高い経路だと述べています。書き込みが百万 units 課金なので重要です。

ベクトルデータベースはそもそも必要ですか？

しばしば不要です。およそ10万ベクトル未満ならメモリ総当たりで十分速く無料です。すでに Postgres を動かしているなら pgvector で別システムを避けられます。「セマンティック検索」要件のかなりの部分は、より安く説明しやすいキーワード検索で足ります。

まとめ

Pinecone はマネージドのベクトルデータベースですが、より広いものに成長しました。1つの index が dense ベクトル、sparse ベクトル、全文字フィールドを同時に持て、ランキング方法はクエリごとに選べます。この統合が最近いちばん有用な変化で、ハイブリッド検索はアーキテクチャ判断ではなくパラメータになります。

設計を決めるのは3つです。Namespaces は隔離と性能の機構で、暗黙に作られます — 打ち間違えた namespace はエラーではなく空結果を返します。Embedding の選択は見た目より粘着します。モデル変更はコーパス全体の再 embedding だからです。読み取りは書き込みの数倍かかるので、読みが多いシステムではクエリキャッシュが直接のコストレバーです。

料金は透明で、無料枠は本当の問い — 検索品質がユースケースに足りるか — に答えるのに十分大きい。その問いはデータベースの話ではありません。チャンク、embedding 選択、クエリの立て方が支配し、インフラが存在する前にローカルで答えられます。

それが率直な締めです。マネージドベクトルDBは規模、マルチテナンシー、分散 index を運用したくないときに場所を得ます。それ以下なら、メモリ上の配列か、すでに動かしている Postgres の拡張が無償で仕事をします。どちらかに申し込む前に、自分がどちらにいるかを確かめる価値があります。