【2026年最新】コサイン類似度・内積・ユークリッド距離の違い

定義と基本

コサイン類似度は、2ベクトルがなす角度から方向の近さを測り、ベクトル長の影響を抑える類似度です。

内積は、対応する各要素の積を合計する類似度で、方向だけでなくベクトルの大きさもスコアへ反映します。

ユークリッド距離は、2点間の直線距離を測る指標です。類似度とは逆に、距離の値が小さいほど近いと判断します。

単位長に正規化したベクトルでは、内積はコサイン類似度と一致します。また、正規化済みベクトル間ではユークリッド距離の二乗が「2−2×コサイン類似度」となるため、順位は対応します。一方、非正規化ベクトルでは長さの情報が結果を変えるため、保存時と検索時で正規化処理を統一し、モデル更新後も同条件で再評価する必要があります。

公式情報からわかる特徴

Qdrant公式資料から確認できるのは、設定されたベクトル空間でクエリに近い点をTop-K取得し、ペイロード条件による絞り込み、密・疎ベクトルのハイブリッド検索、全文検索、再ランキングを組み合わせられることです。密ベクトルは文脈を捉える一方、専門用語や固有識別子を取りこぼす場合があるとも説明されています。

公式情報の事実：Qdrant OverviewとQdrant Searchでは、類似検索、フィルタリング、ハイブリッド検索、検索品質・遅延の調整機能が案内されています。公式情報確認日は2026年08月26日です。

編集上の判断：距離指標だけで製品を選定せず、対象モデルとの整合、権限フィルター適用後の再現率、監査ログ、バックアップ、再インデックス時間をPoCで測るべきです。Qdrantの採否についても、閉域配備要件、運用人員、既存検索基盤との重複を含めて判断してください。

比較と選定ポイント

結論として、一般的な文章RAGではコサイン類似度を第一候補とし、埋め込みモデルが内積を前提に学習されている場合は内積、ベクトルの絶対的な距離に意味がある場合はユークリッド距離を検討します。名称だけで決めず、利用する埋め込みモデルの仕様と、正規化の有無をそろえることが重要です。

ベクトルをL2正規化すると、コサイン類似度と内積は同じ順位になり、ユークリッド距離とも単調な対応関係を持ちます。この条件では検索品質よりも、データベース側の実装、インデックス、スコア表示の扱いやすさが選定要因になります。一方、正規化していない場合は三者の順位が一致するとは限りません。

日本語RAGでの判断基準

日本語検索では距離尺度だけでなく、埋め込みモデルの日本語性能、文書分割、表記揺れ、固有名詞や型番の再現率が結果を大きく左右します。Qdrant公式資料では、dense vectorが文脈検索を担う一方、専門用語や一意識別子を逃す場合があり、sparse vector、全文検索、フィルタリング、ハイブリッド検索を組み合わせられると説明されています。

編集上の推奨は、コサイン類似度によるdense検索を基準線にし、製品番号・契約番号・法令名が重要なら語彙検索を併用する設計です。部署、機密区分、テナント、閲覧可能期間は検索後に除外せず、可能な限り検索時のメタデータフィルターへ組み込みます。

比較試験で固定する条件

同一の埋め込みモデル、次元数、チャンク、Top-K、フィルター条件で三方式を比較し、Recall@K、MRR、回答根拠の適合率、P95遅延を記録します。稟議では平均値だけでなく、権限外文書の混入件数、固有名詞検索の失敗例、インデックス再構築時間も示してください。Qdrantを含め、利用製品の対応距離尺度や設定方法は採用バージョンの公式資料で再確認が必要です。

導入形態・料金・責任分界

Qdrantは公式概要上、オープンソース版とCloudを選択できます。閉域接続、データ所在、暗号鍵、監査ログ、バックアップ要件を先に定義し、自社運用の自由度とクラウド運用負荷のどちらを優先するかで判断します。

公式資料ではHTTP・gRPCインターフェースと複数言語の公式クライアントが案内されています。また、埋め込みはQdrant Cloud Inferenceによるサーバー側生成、またはFastEmbedなどによるクライアント側生成を選べます。機密文書では、原文がどのサービス境界を通過するか、ログや一時データが残るかを責任分界図に明記します。

料金はクラスタ構成、保存量、計算資源、通信、推論利用、サポート条件などで変動し得るため、固定額は置けません。2026年8月26日時点として公開する際は、Qdrant公式料金ページと見積条件を再確認し、埋め込みAPI、再ランキング、監視、バックアップ、運用要員まで含む月額・年額を比較してください。

企業導入の設計・実装

選定基準は「どの距離が高性能か」ではなく、Embeddingモデルの学習条件、正規化の有無、検索目的に合うかです。コサイン類似度はベクトルの向き、内積は向きと大きさ、ユークリッド距離は空間上の直線距離を評価します。単位長に正規化したベクトルでは、コサイン類似度・内積・ユークリッド距離の順位は原理上ほぼ同等になるため、同一データでの評価なしに方式だけを比較しても導入判断には不十分です。

実装では、Embeddingモデル名、バージョン、次元数、正規化処理、距離指標をコレクション単位で固定し、Payload／Metadataにembedding_versionとchunk_versionを保存します。異なるモデルのベクトルを同じ検索空間へ混在させると、スコアの意味が揃いません。モデル変更時は別コレクションまたは別ベクトル領域へ再Embeddingし、旧版と並行評価する設計が安全です。

チャンクは「見出しを含む段落」「条項」「FAQ単位」など、回答根拠として提示できる境界にします。長さだけで機械分割すると意味が薄まり、どの距離指標でも改善しにくいため、チャンク長・重複幅・Top-Kを組み合わせてRecall@K、根拠適合率、応答時間を測定します。Qdrant公式資料では、検索は設定されたベクトル空間で近い点をTop-K取得し、denseとsparseを組み合わせたHybrid Retrievalも扱えると説明されています。固有の製品番号や法令条文が重要なら、ベクトル距離だけでなく全文・sparse検索との併用を比較対象にします。

日本語検索・セキュリティの実務

日本語RAGでは、距離指標の変更より先に、Embeddingの日本語性能、表記揺れ、固有名詞、アクセス権の評価が必要です。「有休／年休」「ＡＢＣ／ABC」などを含む社内クエリでテストセットを作り、完全一致が必要な文書番号や型番はdense検索だけに依存しない設計にします。

公式資料では、dense vectorが文脈を捉える一方、技術用語や一意識別子を取りこぼす場合があり、sparse vector、全文検索、Hybrid Queriesを利用できるとされています。また、Payload条件によるFilterでベクトル検索結果を絞り込めます。これは検索機能について確認できる事実であり、自社の認証・認可要件を自動的に満たすことを意味しません。公式情報の確認日は2026年08月26日です。

Payloadにはtenant_id、department_id、classification、allowed_group_ids、valid_from、valid_to、原本IDを持たせ、権限Filterを検索前提条件として強制します。クライアントが送った部署IDをそのまま信用せず、認証済み利用者の属性からAPI層でFilterを生成してください。取得後に権限外チャンクを除外する方式は、候補集合やログへ機密情報が露出し得るため避けます。

閉域利用では、文書投入、Embedding生成、ベクトルDB、生成モデルまでの通信経路と外部送信有無をデータフロー図で確認します。Qdrant Cloudのサーバー側推論と、クライアント側で生成する方式が公式資料に示されていますが、機密文書を外部推論へ送れるかは契約、保存条件、リージョン、社内規程を別途確認します。厳格な閉域、既存DBだけで十分な小規模検索、SQLの行レベル制御を最優先する案件では、セルフホスト、pgvector、既存検索基盤も比較対象です。

監視・更新・バックアップ

運用では検索スコアの平均値だけを監視せず、距離指標とモデルの組み合わせごとに品質、遅延、権限逸脱、復旧可能性を管理します。コサイン類似度と内積は値の解釈が異なり、ユークリッド距離は小さいほど近いため、共通の固定閾値を流用してはいけません。

ログには、日時、利用者またはサービス主体、クエリID、コレクション、モデル版、距離指標、Top-K、適用した権限Filterの要約、取得した文書ID、スコア、応答時間、再ランキング版を記録します。原文やクエリ本文は機密情報を含み得るため、監査目的との必要性を確認し、マスキング、保存期間、閲覧権限、改ざん防止を定めます。Filterなし検索や想定外tenantへの照会は、件数がゼロでもセキュリティイベントとして検知対象にします。

モデル更新時は、代表質問に加えて日本語の略語、誤字、長文、権限境界を含む回帰試験を行い、旧版とのTop-K重複率だけでなく、根拠の正しさを人手評価します。編集上の推奨は、検索品質の悪化時に距離指標だけを切り替えず、正規化、チャンク、Hybrid検索、再ランキングを切り分けて検証することです。

バックアップ対象はベクトルだけでなく、Payload、コレクション設定、距離指標、Embedding生成コード、原本文書との対応表です。定期バックアップに加え、別環境への復元試験で件数、ベクトル次元、Payload、権限Filter、代表クエリの結果を照合します。原本から再生成できる場合も、モデル提供終了や版違いで同じベクトルを再現できない可能性があるため、目標復旧時間と再Embedding時間を稟議時に明示します。

導入手順

距離関数を先に決め打ちせず、埋め込みモデルの仕様と自社データでの検索評価を基準に選定します。

1. 検索要件を定義する。意味検索、製品コードなどの完全一致、類似画像検索のどれを重視するかを整理します。日本語RAGでは、専門用語・略語・表記揺れを含む質問セットを用意します。
2. 埋め込みモデルの推奨指標を確認する。モデル提供元がコサイン類似度、内積、ユークリッド距離のどれを前提として学習・評価したかを確認します。次元数、ベクトル正規化の有無、利用規約、外部送信の有無も記録します。
3. 候補指標を絞る。方向の近さを重視するならコサイン、ベクトルの大きさにも意味がある学習済みモデルなら内積、座標上の絶対的な近さを扱うならユークリッド距離が候補です。単位正規化済みベクトルでは、コサインと内積の順位は通常一致します。
4. 評価用データを作る。実際の文書と質問について正解文書を付与し、Recall@K、MRR、nDCG、応答時間を比較します。RAGでは検索順位だけでなく、回答根拠の正確性と引用漏れも人手評価します。
5. 検索方式を設計する。公式資料では、Qdrantは設定したベクトル空間でTop-K検索を行い、payloadによる絞り込み、dense・sparseを組み合わせたハイブリッド検索に対応すると説明されています。社員IDや型番を扱う日本語検索では、ベクトル類似度だけでなく語彙一致と権限フィルターを併用します。
6. 小規模検証後に固定する。同じモデル、同じチャンク、同じ質問で三指標を比較し、品質・遅延・メモリ・再現率を稟議資料に残します。指標や正規化方式の変更は再投入や再評価を伴う前提で、モデル版とコレクション版を管理します。

向くケース・向かないケース

一般的な文書RAGではコサインが比較しやすい一方、モデルの学習条件によって内積やユークリッド距離が適するため、名称だけでは決められません。

コサイン類似度が向くケース

文章の長さやベクトルの大きさより、意味の方向を比較したいFAQ・規程検索に向きます。大きさ自体が信頼度や重要度を表すモデルでは、その情報を捨てる可能性があります。

内積が向くケース

内積を目的に学習された推薦・検索モデルや、大きさをランキングへ反映したい場合に向きます。未正規化ベクトルではノルムの大きい文書が上位になりやすいため、分布監視が必要です。

ユークリッド距離が向くケース

画像特徴や数値特徴など、空間上の絶対距離に意味がある用途に向きます。各次元の尺度が不揃いなデータや、高次元で距離差が小さくなるデータには慎重な検証が必要です。

Qdrantが向かない条件

単純な完全一致検索だけで足りる場合、既存RDBや全文検索基盤のほうが運用を簡素化できます。また、閉域要件に対して配置、認証、暗号化、監査ログの設計・検証を行えない組織では導入を急ぐべきではありません。

導入前チェックリスト

品質だけでなく、機密性、権限継承、再構築手順まで確認してから本番化します。

1. 埋め込みモデルの推奨距離関数と正規化仕様を一次資料で確認したか
2. 日本語の固有名詞、表記揺れ、型番、否定表現を含む評価セットがあるか
3. 指標ごとのRecall@K、回答正確性、P95遅延を同条件で比較したか
4. 文書ACLをpayloadへ反映し、検索時に必ず権限フィルターを適用するか
5. 外部埋め込みAPIへ送信できない機密情報を分類し、閉域推論を選べるか
6. 検索者、条件、参照文書、モデル版を追跡できる監査記録があるか
7. モデル変更時の再埋め込み、段階移行、ロールバック手順があるか
8. バックアップ、容量監視、障害復旧、担当者と運用費を明文化したか

結論

コサインは方向、内積は方向と大きさ、ユークリッド距離は座標上の隔たりを評価します。実務上の第一基準は埋め込みモデルの推奨設定、第二基準は自社の日本語データによる検索・回答評価です。

QdrantはTop-K、payloadフィルター、dense・sparseの組み合わせを設計できる選択肢ですが、単純検索には過剰な場合もあります。2026年8月26日確認の公式情報と、個別バージョンの仕様を照合し、閉域配置、権限、監査、再埋め込み費用まで含めて導入判断してください。

一次情報・参考リンク

• Qdrant Documentation – Overview
• Qdrant Search