Chroma（ChromaDB）とは？読み方・使い方と日本語検索の実測、pgvectorとの違い

Chroma（ChromaDB、読み方はクロマ）は、文章や画像を埋め込みベクトルとして保存し、意味の近い順に取り出せるオープンソースのベクトルデータベースです。RAG（検索拡張生成）で、質問に関係する文書の断片を探す検索層として使われます。Pythonならpip install chromadbの1行で動き、文書を渡すだけで埋め込みも自動で作られます。

この記事は、2026年10月19日時点でPyPIの最新版である1.5.9を基準に、仕組みとchroma_dbフォルダの中身、導入から追加・検索・更新・削除までのコード、日本語の文書で既定モデルと多言語モデルを比べた実測、料金、pgvectorとの選び分けを順に説明します。

まとめ：Chromaの正体・使い方・選び方の要点

• 正体：Apache 2.0ライセンスのベクトルデータベース。アプリに組み込むライブラリとしても、HTTPサーバーとしても動き、ローカル利用は無料。「Redisベース」という説明は誤り。
• 仕組み：ローカル・シングルノードでは文書とメタデータをSQLite、ベクトルをHNSW索引に持つ。PersistentClientの保存先にはchroma.sqlite3と、コレクションごとのHNSWファイルが並ぶ。
• 使い方：get_or_create_collection→add→queryが基本。既存IDへのaddはエラーにならず無視されるので、上書きはupsertを使う。
• 日本語：既定のall-MiniLM-L6-v2は日本語に弱い。言い換えの質問10問で1位正解は4問、multilingual-e5-smallに替えると9問だった（本記事の実測）。日本語のRAGでは最初から多言語モデルを指定する。
• 選び方：約1千万件未満はChromaのシングルノード構成の目安。採用前に次元数・メモリ容量・同時検索数を含めて負荷試験を行う。業務データがPostgreSQLにあり権限やバックアップを一元管理したいならpgvector。

Chroma（ChromaDB）とは：読み方・ライセンス・保存できるデータ

Chromaは、非構造化データを埋め込みベクトルに変えて格納し、類似度で取り出すためのデータベースです。公式ドキュメントの概要ページは、メタデータ付きの埋め込みの保存、密ベクトル・疎ベクトルでの検索、メタデータでの絞り込みを主な機能に挙げています。リレーショナルデータベースが完全一致や範囲で行を探すのに対し、Chromaは「質問文に意味が近い文書」を上から数件返す近似最近傍探索を担います。ベクトルデータベース全般の仕組みと製品の並びはベクトルDBとは？仕組み・インデックス構造・製品比較とpgvectorで動かす手順【2026年版】で整理しています。

読み方「クロマ」とApache 2.0で無料・商用可の扱い

読み方は「クロマ」で、DBを付けて「クロマDB」とも呼ばれます。開発元は米Chroma社で、コードはGitHubのchroma-core/chromaで公開され、ライセンスはApache 2.0です。商用利用を含めて無料で使えます。Chromaのサービス利用料が発生するのはマネージド版のChroma Cloudを選んだ場合で、ローカル実行とセルフホストに利用料はかかりません。

保存できるデータ：ID・文書・埋め込み・メタデータの4種類と表データの扱い

Chromaの1件のレコードは、一意のID、文書（文字列）、埋め込みベクトル、メタデータ（キーと値の組）の4つで構成されます。文書だけを渡せば埋め込みは自動で作られ、自前で計算したベクトルをembeddings引数で直接入れることもできます。メタデータの値には文字列・数値・真偽値と、同じ型の要素からなる配列を入れられ、絞り込みの条件に使います。

表形式の業務データそのものを入れる用途には向きません。売上の集計や行の結合のような処理はSQLの領分で、Chromaに入れるのは「意味で探したい文章」と、その文章を絞り込むための属性（部署・日付・文書種別など）です。表データも横に並べて扱いたい場合は、後半のpgvectorとの比較が判断材料になります。

埋め込み生成の内蔵とPython・JavaScriptクライアント

Chromaの特徴は、文書を渡すだけで埋め込みベクトルを生成する点です。埋め込み関数のドキュメントによると、既定はSentence Transformersのall-MiniLM-L6-v2で、手元のマシンで動きます。OpenAI・Cohere・Google・Hugging Face・Jina AIなど外部モデルへの差し替えも公式に用意されています。クライアントはPython（pip install chromadb）とJavaScript/TypeScript（npm install chromadb）があり、npmのchromadbパッケージは2026年10月時点で3.5.0と、Python版とは別の版番号で配布されています。

Chromaの仕組み：SQLiteとHNSWで動く構造とchroma_dbフォルダの中身

Chromaの内部は2種類の記憶でできています。アーキテクチャ概要は、SQLiteやクラウドのオブジェクトストレージのような実績ある仕組みに処理をできるだけ任せる設計だと説明しています。「Redisをベースにした高速DB」という紹介を見かけますが、実装と一致しません。

SQLiteとHNSWの2層構造と、PersistentClientが作るファイル

ID・文書・メタデータはSQLiteに入り、ベクトルはコレクションごとにHNSW（Hierarchical Navigable Small World）の索引として持たれます。HNSWは近いベクトル同士をグラフでつなぎ、グラフをたどって全件を総当たりせずに近傍へ到達する仕組みです。Chromaはこれをhnswlibのフォークで実装しています。

実際にPersistentClient(path="chroma_db")で200件を入れたところ、保存先は次の構成になりました（chromadb 1.5.9・2026年10月19日に実測）。

chroma_db/
├── chroma.sqlite3                      # 716,800バイト：文書・メタデータ・全文検索用の索引
└── 6c539072-5237-4974-a629-7a01aff48c66/  # コレクションごとのHNSW索引（名前はUUID）
    ├── data_level0.bin                 # 167,600バイト：ベクトル本体と近傍リンク
    ├── header.bin
    ├── length.bin
    └── link_lists.bin

同じ手順で1,100件を入れると、UUIDのフォルダにindex_metadata.pickleも加わりました。ファイルの数は件数で変わります。chroma.sqlite3の中にはcollections・embeddings・embedding_metadataのほか、embedding_fulltext_searchで始まる全文検索用のテーブル群がありました。後述のwhere_documentによる本文の絞り込みはこの索引を使います。バックアップや別マシンへの移動は、プロセスを止めてからこのフォルダごと複製します。pathを省略した場合の保存先は、1.5.9のソースで./chromaと定義されています。

ローカル・シングルノード・分散の3形態とHNSW／SPANNの使い分け

公式は配置形態を3つに分けています。アプリへ組み込むローカル、1台のサーバーで動かすシングルノード、複数のサービスに分かれる分散です。アーキテクチャ概要はシングルノードの典型を「少数のコレクションで1,000万件未満」の小〜中規模としています。索引も形態で変わり、コレクション設定のドキュメントではローカル・シングルノードがHNSW、分散とChroma CloudがSPANNを使うと明記されています。手元で調整したHNSWのパラメータは、Cloudへ移すとそのままは効きません。

v1.0.0のRust書き直しで変わった性能とスレッドの扱い

2025年4月3日に正式公開されたv1.0.0で、Chromaのコアの大部分はRustで書き直されました。公式の告知は、一般的な読み書きとクエリで約4倍の高速化をうたい、PythonのGIL（グローバルインタプリタロック）に縛られず複数スレッドから同時に使えるようになったと説明しています。Chromaの速さは、Redisではなくこの索引とRust実装から来ています。

Chromaのインストールとクライアント・サーバー接続

導入はpipで完結し、PyPIの記載ではPython 3.9以上が必要です。

pip install chromadb==1.5.9

最初に既定の埋め込みモデルを使った時点で、モデルファイルonnx.tar.gz（79.3MB）が~/.cache/chroma/onnx_models/all-MiniLM-L6-v2へダウンロードされます。手元の計測では、ダウンロードを含めた初回の埋め込みに32.7秒かかり、展開後のフォルダは177MBでした。インターネットに出られない環境で使う場合は、このフォルダを事前に配置しておくか、後述の方法で別の埋め込みモデルを指定します。

クライアントは用途で選びます。クライアントのドキュメントに沿うと、テストならメモリ上、開発や小規模運用ならディスク保存、複数のプロセスから共有するならサーバー接続です。

import chromadb

# メモリ上のみ。プロセス終了で消える（テスト向け）
client = chromadb.EphemeralClient()

# ディスクに保存。再起動後も残る（ローカル開発・小規模運用向け）
client = chromadb.PersistentClient(path="./chroma_db")

# chroma run で起動したサーバーへ接続（複数プロセスで共有）
client = chromadb.HttpClient(host="localhost", port=8000)

サーバーはchroma runコマンドで起動します。既定はホストlocalhost・ポート8000で、--pathで保存先を指定します。

chroma run --path ./chroma_db --host localhost --port 8000

コレクション名には制約があります。2文字の名前で作ろうとしたところ、「3〜512文字で、英数字・ピリオド・アンダースコア・ハイフンのみ、先頭と末尾は英数字」という検証エラーで拒否されました。日本語のコレクション名も使えないので、articles_jaのような英字名にします。マネージド版を使う場合はchromadb.CloudClient()に、テナント・データベース名・APIキーを渡します。

Chromaの使い方：コレクション作成・追加・検索・更新・削除のコード例

基本の流れは、コレクションを作り、addで文書を入れ、queryで意味の近い文書を取り出す3ステップです。以下のコードはすべてchromadb 1.5.9で動作を確かめています。

addとqueryの基本と、n_resultsで返す件数を決める書き方

埋め込みはChroma側が作るため、ベクトルを自前で計算する必要はありません。n_resultsで返す件数を決めます。RAGではこの件数がLLMへ渡す文脈の量になるので、3〜5件から始めて回答の質を見ながら調整します。

import chromadb

client = chromadb.PersistentClient(path="./chroma_db")
collection = client.get_or_create_collection(name="articles")

# 文書を追加（ID・本文・メタデータ。埋め込みは自動生成）
collection.add(
    ids=["doc1", "doc2"],
    documents=["Chromaはオープンソースのベクトルデータベースです", "RAGの文脈保存に使えます"],
    metadatas=[{"category": "db", "year": 2025}, {"category": "rag", "year": 2026}],
)

# 類似検索（上位2件）
results = collection.query(query_texts=["ベクトルデータベースとは"], n_results=2)
print(results["documents"])
print(results["distances"])

文書をどの単位で区切って入れるかは、検索の精度を大きく左右します。区切り方の設計はチャンクとトークンの違いとは？チャンク分割の手法とRAGのサイズ設計を日本語で実測【2026年版】で扱っています。

upsert・update・get・deleteでデータを直す書き方と、addの落とし穴

同じIDでaddをもう一度呼ぶと、エラーにならずに無視されます。実際に"dup"というIDへ「x」を入れたあと「y」でaddし直したところ、取り出せた文書は「x」のままでした。文書を差し替える処理をaddで書くと、更新したつもりで古い内容が残り続けます。上書きはupsert（無ければ追加）かupdate（あるものだけ更新）を使います。

# 無ければ追加、あれば上書き
collection.upsert(ids=["doc1", "doc3"], documents=["更新後の文書", "新規の文書"])

# 既存IDのメタデータだけを更新
collection.update(ids=["doc2"], metadatas=[{"category": "rag", "year": 2027}])

# IDを指定して取り出す（類似検索ではなく直接参照）
print(collection.get(ids=["doc1", "doc2"], include=["documents", "metadatas"]))

# IDか条件で削除
collection.delete(ids=["doc3"])
collection.delete(where={"year": {"$lt": 2026}})
print(collection.count())

社内規程のように改訂がある文書では、文書の版や更新日をメタデータに入れておき、改訂時にdelete(where=...)で旧版を消してから入れ直すと、古い記述が検索に残りません。

whereのメタデータ条件とwhere_documentの本文条件で絞り込む書き方

類似度に加えて、属性と本文で結果を絞り込めます。メタデータフィルタのwhereは、1.5.9のソースで$eq・$ne・$gt・$gte・$lt・$lte・$in・$nin・$contains・$not_containsを受け付け、$and・$orで組み合わせられます。本文条件のwhere_documentは$contains・$not_contains・$regex・$not_regexです。

# category が rag かつ 2026年以降、本文に「RAG」を含む文書だけを対象に類似検索
results = collection.query(
    query_texts=["検索クエリ"],
    n_results=5,
    where={"$and": [{"category": "rag"}, {"year": {"$gte": 2026}}]},
    where_document={"$contains": "RAG"},
)

社内RAGでは、認証済みユーザーの閲覧権限からアプリ側でwhereを生成し、すべての検索に強制適用します。where自体は検索フィルタであり、利用者が条件を省略・変更できる構成ではアクセス制御になりません。語の一致と意味の近さを本格的に組み合わせる設計はハイブリッド検索とは？RAGでBM25とベクトル検索を統合する仕組み・RRF・実装コードを参照してください。

距離関数とHNSWパラメータをconfigurationで指定する書き方

距離関数はl2（二乗L2）・ip（内積）・cosineの3種類です。設定を省いて作ったコレクションのconfigurationを表示すると、spaceがl2、ef_constructionとef_searchが100、max_neighborsが16でした。ef_constructionは主に索引構築時の品質と時間、ef_searchは検索時の再現率と時間、max_neighborsはグラフの接続数とメモリ量に影響します。値を増やしても精度の改善が続くとは限りません。

collection = client.create_collection(
    name="docs_cosine",
    configuration={"hnsw": {"space": "cosine", "ef_construction": 200}},
)

1.5.9のソースで作成後に更新できる項目はef_searchなどに限られ、space・ef_construction・max_neighborsは含まれません。この3つは作成時に決めます。なお、既定モデルのall-MiniLM-L6-v2では、l2とcosineで検索結果の順位が完全に一致しました（次章の10問すべて）。このモデルは長さをそろえたベクトルを出すため、どちらの距離でも並びが変わりません。

日本語の文書検索で既定モデルと多言語モデルを比べた実測

既定のall-MiniLM-L6-v2は英語データで学習されたモデルです。日本語でどの程度崩れるかを、手元で測りました（2026年10月19日・chromadb 1.5.9）。社内規程を模した日本語の文書10件（有給休暇の申請期限、経費精算の締め、出張の宿泊費上限など）を入れ、本文と同じ語を避けて言い換えた質問10問（例：「休みを取りたいときはいつまでに申し込めばいい？」「出張先のホテル代はいくらまで出る？」）で、正解の文書が何位に来るかをn_results=10で数えています。自作の文書10件・質問10問に限った比較で、日本語検索全般の性能を示すものではありません。自社の文書で選ぶときは、実際の利用者の質問を20〜30問集めて同じ数え方で比べてください。

既定モデルで起きた取り違えの中身

既定モデルで最も外したのは「休みを取りたいときはいつまでに申し込めばいい？」で、正解の有給休暇の文書は10件中7位でした。「立て替えたお金を返してもらう手続きの期限」も、経費精算の文書が5位です。一方で「年に一度の健康チェックの時期」「出張先のホテル代はいくらまで出る？」のように、数字や「健康」「出張」といった漢字が本文と重なる質問は1位に来ました。当たった質問はどれも本文と共通する漢字や数字を含み、外した質問は本文と語が重ならない言い換えでした。今回の結果から、既定モデルでは日本語の言い換え質問で関係の薄い文書を取得する場合があると分かります。実際の利用者の質問を使い、多言語モデルと検索精度を比較してから採用します。

multilingual-e5-smallへ差し替える書き方

多言語モデルのmultilingual-e5-smallは、既定モデルと同じ384次元で、手元のCPUでも動きます。ChromaのSentenceTransformerEmbeddingFunctionに名前を渡すだけで差し替わります（別途pip install sentence-transformersが必要）。

from chromadb.utils.embedding_functions import SentenceTransformerEmbeddingFunction

ef = SentenceTransformerEmbeddingFunction(model_name="intfloat/multilingual-e5-small")

collection = client.get_or_create_collection(
    name="docs_ja",
    embedding_function=ef,
    configuration={"hnsw": {"space": "cosine"}},
)

# E5系は文書に「passage: 」、質問に「query: 」を付けて渡す
collection.add(ids=["ja1"], documents=["passage: 有給休暇は3営業日前までに申請します"])
print(collection.query(query_texts=["query: 休暇はいつまでに申請する？"], n_results=1)["documents"])

E5系のモデルは接頭辞付きで学習されており、公式のモデルカードは付けないと性能が落ちると説明しています。今回の10問では接頭辞の有無で順位は変わりませんでしたが、上のコードのように文書にはpassage: 、質問にはquery: を付けて使います。API経由で埋め込みを作るならOpenAIEmbeddingFunctionも使えます。ただし1.5.9のソースではmodel_nameの初期値が旧モデルのtext-embedding-ada-002なので、model_name="text-embedding-3-small"のように必ず明示します。埋め込みの生成そのものはPythonでembedding（ベクトル化）を生成する方法｜OpenAI APIとsentence-transformersで詳しく扱っています。

次元数の不一致エラーと、モデルを替えるときの作り直し

384次元のコレクションに768次元のベクトルで問い合わせると、InvalidArgumentError: Collection expecting embedding with dimension of 384, got 768で止まりました。次元の違うモデルに替えた場合は、このエラーで気付けます。危ないのは、今回の2つのように次元が同じモデル同士です。登録時と検索時でモデルが食い違ってもエラーにならず、検索結果だけが崩れます。モデルを替えるときは、新しいコレクションを作って全件を入れ直してください。

バージョンの確認と、0.x系から1.x系へ上げるときの注意点

2026年10月19日時点で、PyPIの最新は1.5.9（2026年5月5日公開）です。1.5系は2026年3月から5月に、撤回済みの1.5.3を除いて6版が公開されました。GitHubのmainブランチには10月13日付で「[RELEASE] 1.6.0」のコミット（説明は「Bug fix release」「Backwards compat.」）が入っていますが、10月19日時点のPyPIにはまだ配布されていません。導入後はpip show chromadbで実際の版を確かめ、依存の版を固定しておきます。

0.x系から上げる場合は、公式のマイグレーションガイドで差分を確認します。1.0.0では次の3点が特に影響します。

• 組み込み認証の廃止：Chroma本体は認証の実装を持たなくなった。
• サーバー設定の渡し方：chroma runの設定は環境変数でなく設定ファイルで渡す。1.5.9のchroma run --helpでは、設定ファイルのパスはchroma run config.yamlのように位置引数で指定する形になっていた。
• Dockerのデータ位置：コンテナ内の保存先が/chroma/chromaから/dataへ移った。ボリュームの割り当てを直さないと、起動後にデータが空に見える。

見落とされやすいのは認証の廃止です。HttpClientで使うサーバーをネットワークに出す場合は、リバースプロキシやAPIゲートウェイで認証と通信の暗号化を前段に置きます。

Chroma Cloudの料金：プラン構成と従量課金の数え方

セルフホストは無料で、運用を任せたい場合にマネージド版のChroma Cloudを使います。料金ページ（2026年10月19日時点）では、月額0ドルのStarter、月額250ドル（100ドル分の利用クレジット込み）のTeam、個別見積もりのEnterpriseの3プランに、次の従量課金が加わります。料金の解説ページによると、新規ユーザーには5ドル分のクレジットが付きます。

一度登録した文書を繰り返し検索する使い方では、検索回数と走査量・返却量が費用を左右します。料金の解説ページによると、メタデータ条件や本文条件は1つごとに1クエリとして加算され、全文・正規表現の条件は検索文字数から2を引いた数で数えられます。whereを多用するRAGでは、想定する検索条件を含めて見積もります。密ベクトルと疎ベクトルの結果をRRFで融合するハイブリッド検索などを扱う検索APIは、公式ドキュメントで「Chroma Cloudのみ」とされ、シングルノード対応は今後の予定です。1.5.9のローカル版で呼ぶとNotImplementedErrorになります。BM25の疎埋め込み関数自体はローカルで動くので、ローカルでハイブリッド検索をするなら融合は自前で書くことになります。他のベクトルデータベースとの料金体系の比べ方はベクトルデータベースの価格とおすすめ｜3タイプの料金体系比較とRAG用途の選び方【2026年版】でまとめています。

Chromaとpgvectorの違いと、本番で採用する条件

「Chromaとpgvectorのどちらを使うか」は、埋め込み生成まで任せたいか、既存のPostgreSQLに載せたいかで決まります。pgvectorはPostgreSQL 13以上で動く拡張で、2026年10月時点の最新は0.8.7（10月1日公開）、索引はHNSWとIVFFlatです。

pgvectorの導入と使い方はpgvectorとは？インストール手順（Windows・Ubuntu・Docker）と使い方【0.8.7対応】で、検索方式そのものの違いはベクトル検索とセマンティック検索の違い：包含関係・仕組み・pgvectorでの実装と使い分けで補足しています。

Chromaを本番RAGで採用する条件と、他製品へ切り替える場面

Chromaのシングルノード構成を候補にする目安は、次の3条件です。データ量が約1千万件未満に収まること。PythonかJavaScriptのアプリから直接使うこと。ネットワークに出す場合に認証を前段で用意できることです。そのうえで件数だけで決めず、ベクトルの次元数・メモリ容量・同時検索数を含めて負荷試験を行います。この範囲なら、埋め込み生成まで内蔵している分だけ立ち上げが速く、試作から小規模の本番まで同じコードで進められます。LangChainから検索層として組み込む手順はLangChainでRAGを構築する手順｜v1.3系のコード例とlangchain-classic移行で扱っています。

業務データがすでにPostgreSQLにあり、権限やバックアップをDB側で一元管理したい場合はpgvectorを選びます。ベクトルと業務データを別々に持つと、削除や権限変更の同期漏れが起きるからです。最初から数億件規模や高可用性が要件なら、分散前提のMilvusとは？v3.0の外部コレクション・インデックス選定・デプロイ形態【2026年版】や、運用を任せられるPineconeとは？サーバーレス型ベクトルDBの料金・制限値・実装と選び分け【2026年版】も比較に入れます。手元で軽く試す段階でMilvus系とも比べたいなら、同じく組み込みで動くMilvus Liteとは？3.x系の対応索引・同時実行の制約・Standalone移行手順が候補です。「試作で使ったChromaをそのまま大規模基盤に」という決め方は避けてください。

社内文書を検索させるRAGの設計や、Chromaとpgvectorのどちらに載せるかの判断から相談したい場合は、一創のRAG構築支援で、データ整備から検索精度の評価まで一緒に進められます。進め方の全体像はRAG構築の手順とは？データ整備から精度向上・本番運用までの進め方にまとめています。

よくある質問

Chroma（ChromaDB）とはどんなデータベースですか？読み方は？

文書を埋め込みベクトルに変えて保存し、意味の近い順に取り出すオープンソースのベクトルデータベースです。読み方は「クロマ」で、ChromaDBとも表記されます。ローカル・シングルノードでは文書とメタデータをSQLite、ベクトルをHNSW索引で持ち、Pythonのライブラリとして組み込むことも、サーバーとして動かすこともできます。

Chromaは無料で使えますか？ライセンスは？

ローカル実行とセルフホストは無料です。ライセンスはApache 2.0で、商用利用も可能です。Chroma Cloudのサービス利用料は有料で、2026年10月時点では書き込み・保存・クエリ量に応じた従量課金に、プランごとの月額（Starterは0ドル、Teamは250ドル）が加わります。

chroma_dbフォルダには何が保存されていますか？

PersistentClientに指定したフォルダで、文書・メタデータ・全文検索の索引を持つchroma.sqlite3と、コレクションごとのHNSW索引（UUID名のフォルダにdata_level0.binなどの索引ファイル）が入っています。Chromaのデータ本体なので、消すとコレクションごと失われます。バックアップはプロセスを止めてからフォルダごと複製します。

Chromaとpgvectorの違いは？

Chromaは埋め込み生成を内蔵した独立のベクトルデータベースです。シングルノードでは少数のコレクションで約1千万件未満が公式の用途目安で、大規模用途には分散構成やCloudもあります。pgvectorはPostgreSQLの拡張で、既存のRDBにベクトル検索を足し、SQLと権限管理を一体で扱いたいときに向きます。業務データがPostgreSQLにあるならpgvector、検索層だけを速く立てたいならChromaが第一候補です。

Chromaは日本語の文書検索にも使えますか？

使えます。ただし既定モデルは日本語の言い換えに弱く、本記事の文書10件・質問10問の比較では、1位正解が既定のall-MiniLM-L6-v2で4問、multilingual-e5-smallで9問でした。日本語のRAGでは、コレクションを作る時点で多言語対応の埋め込み関数を指定し、登録時と検索時で同じモデルを使ってください。

関連記事

• ベクトルDBとは？仕組み・インデックス構造・製品比較とpgvectorで動かす手順【2026年版】
• pgvectorとは？インストール手順（Windows・Ubuntu・Docker）と使い方【0.8.7対応】
• Weaviateとは？ハイブリッド検索・マルチテナンシー・料金と選定基準【2026年版】
• リランクモデルとは？ベクトル検索と組み合わせる種類・仕組み・選び方【2026年版】