レコメンドとサジェストは、何が違うのか

結論：違いは「手がかりが文字か、行動か」

レコメンドを入れる話になると、この質問が出ます。「検索の候補表示と、何が違うんですか」。どちらも「候補を出す」機能なので、同じ仕組みに見えます。

レコメンドとサジェストの違いは、候補を出すときに何を手がかりにするかです。サジェストは打った文字、レコメンドは利用者の行動を手がかりにします。

• サジェストとは、打った文字と見た目が似ている語を返す機能です。ECサイトの検索窓に「スニ」と打つと「スニーカー」「スニーカー メンズ」と候補が並ぶ、あれです
• レコメンドとは、利用者の行動の記録（クリックした・カートに入れた・買った）から関連するアイテムを返す機能です。商品ページの下に「この商品を見た人は、こちらも見ています」と並ぶ、あれです

レコメンドには、行動の記録がまだ無いときに商品の属性（タイトルや説明文）を手がかりにする方式もあります。どちらにしても、打った文字は使いません。この2文は各社の定義から私たちがまとめたもので、各社がこの対比を書いているわけではありません。どちらを入れるかを決める前に、何を手がかりにするかを1つ決める話です。

具体：検索窓の候補と、商品ページの「こちらも」は、見ているものが違う

検索窓に「スニ」と打ったときに出る候補は、打った文字を手がかりにしていて、誰が打っても同じ候補が並びます（候補の元になる語をどう作るかは各社で違います）。商品ページの下に並ぶ「こちらも見ています」は、その人を含む利用者たちが何を見て何を買ったかの記録を手がかりにしていて、打った文字は使いません。

まぎらわしいのが「検索結果の並べ替え」です。検索という言葉が付くのでサジェストの仲間に見えますが、Amazon Personalizeでは、検索結果の並べ替えがレコメンドのレシピの1つ（PERSONALIZED_RANKING）として用意されています。並べ替えとは、検索で出てきた商品の順番を、その人に合わせて入れ替えることです。手がかりが「打った文字」ではなく「その人の関心」なので、この記事の線の引き方でもレコメンド側に入ります。

役割も逆を向いている、というのが私たちの読み方です。サジェストは打った文字に近いものを出すので候補を絞る方向に、レコメンドは、Algoliaの言葉では「ユーザーが検索を広げ、より多くのアイテムを探索するのを助けます」（原文［5］）。役割が逆を向いている以上、片方でもう片方を代替する設計にはなりにくい、というのが私たちの読み方です。

どちらを入れるか、どう決めるか

ここからは私たちの進め方です。3つあります。

• 手がかりを1つ決める。打った文字を使うのか、利用者の行動を使うのか。行動を使うなら、いま計測ツールで、クリック・カート追加・購入の記録が取れているかを先に確かめます。必要な量は公開されていて、Algoliaでは行動を使う Related Items はクリック・購入などの記録が最低10,000件、商品の属性を使う Related Content は属性を持つ商品が最低10件です（原文［2］の同じページ。Algoliaの表で Related Items の対象は「クリックとコンバージョンのイベント」で、閲覧は挙がっていません）。行動の記録がまだ無ければ、商品の属性から動かす方式（コンテンツベース）から入れます
• 出す場所を先に決める。サジェストは検索ボックスの周辺に出すのが基本形で（私たちの読み方です）、レコメンドはページごとに枠を選びます。Google Cloudはモデル選定について「ビジネス上のニーズと、結果のレコメンドをどこに表示する予定か」に依存すると書いています（原文［9］）。場所から決めたほうが、モデルは選びやすくなります（この言い換えは私たちのものです）
• 「検索結果の並べ替え」をやりたいなら、レコメンド側で探す。Amazon Personalizeの分類ではレコメンドのモデルの型です。今回見たサジェスト側のページ（Elasticsearch・OpenSearch・Algolia Query Suggestions）には、この型は出てきません

製品を比べる前に、手がかりを決めるほうが先です。レコメンドの精度をどう測るかはレコメンドの精度が上がっても、売上が動かない理由で、渡すデータの形の話は出し分けができないのは、データが足りないからではないで扱いました。

根拠：各社は、それぞれ何と書いているか

上の整理の根拠です。専門用語が続くので、要点を先に書いてから引用し、あとで言葉を補います。

サジェスト側（Elasticsearch）── 文字の距離で測っている

要点は「打った文字に見た目が似ている語を返す。term suggester では、似ているかどうかを文字を何個直せば同じになるかで測る」です。

検索APIの suggest パラメータは、suggester を使って、与えられたテキストにもとづいて見た目の似た語を提案します。（中略）スコアの意味は、使われる suggester によって変わります。term suggester のスコアは、編集距離にもとづきます

中略は複数の段落をまたぎます。── Elasticsearch公式ドキュメント「Suggester examples」（2026年8月28日取得）。原文は原文［1］に置きました。

• suggesterとは、候補を出す部品の名前です。Elasticsearchには何種類かあり、term suggester はそのうちの1つです
• 編集距離とは、文字をいくつ直せば別の語になるか、という距離です。「スニカー」と「スニーカー」なら1文字なので、距離は1です（この説明はこの記事のもので、日本語でこの通りに動くかは、今回見たページには書かれていません）

同じドキュメントには「term suggester は、リクエストの一部であるクエリを考慮しません」とも書かれています。つまり、同じリクエストに書いた検索条件も見ておらず、打った文字だけを見ています。その人が誰かを見る仕組みは、このページには出てきません（私たちの読み方です）。

レコメンド側（Algolia）── 行動の回数を数えている

要点は「利用者ごとにどの商品に何回触れたかを数え、同じ人たちが触れた商品どうしを関連づける」です。

Recommendは2種類のアルゴリズムを使います。協調フィルタリングと、コンテンツベースフィルタリングです。協調フィルタリングは、直近30〜90日のユーザーイベントを分析します。Recommendは userToken と objectID のあいだの相互作用テーブルを作り、各ユーザーが各レコードとどれくらいの頻度でやり取りするかを数えます

── Algolia公式ドキュメント「Algolia Recommend overview」（2026年8月28日取得）。原文は原文［2］に置きました。

• 協調フィルタリングとは、「この商品を見た人は、あの商品も見ている」という、たくさんの人の行動の重なりから関連を見つける方式です
• ユーザーイベントとは、クリックした・カートに入れた・買った、といった行動の記録のことです（何を数えるかはサービスによって違います）
• userToken と objectIDとは、「誰が」と「どの商品を」を区別するためのIDです。相互作用テーブルとは、その2つを組み合わせて「誰がどの商品に何回触れたか」を数えた表のことです

片方は文字の距離を測り、もう片方は人の行動を数えています。なおレコメンドにはもう1種類、コンテンツベースフィルタリングがあります。こちらは行動ではなく「タイトルや説明といったアイテムの主要な属性を分析して、類似性を見つける」方式で（原文［6］）、手がかりは商品の属性です。

検索結果の並べ替え（Amazon Personalize）── レコメンドの型の1つ

要点は「検索結果をその人向けに並べ直す型（PERSONALIZED_RANKING）が、レコメンドのモデルの1つとして用意されている」です。レシピとは、Amazon Personalizeでのモデルの型の呼び名です。

ユーザーのためにアイテムを並べ替える（PERSONALIZED_RANKING レシピ）── 厳選したリストや検索結果の順序をユーザーに合わせてパーソナライズするには、PERSONALIZED_RANKING レシピでモデルを学習させます。PERSONALIZED_RANKING レシピは、与えられたユーザーの予測された関心度にもとづいて、入力アイテムの集合を並べ替えることで、パーソナライズされたリストを作ります

── Amazon Personalize公式ドキュメント「Choosing a recipe」（2026年8月28日取得）。原文は原文［7］に置きました。

なお5つのサービスの公式ドキュメント14ページを確認した範囲では、レコメンドとサジェストを並べて比べた文章は1文も見つかりませんでした（確認したページは末尾に挙げています）。各社にとってこの2つは別の製品か別の機能で、同じページで比べる動機がない、というのが私たちの読み方です。

よくある質問

レコメンドとサジェストは、何が違うのですか？

手がかりが違います。サジェストは打った文字を見て、続き（補完）や打ち間違いの直し（編集距離）を候補にします。レコメンドは利用者の行動の記録（クリックした・カートに入れた・買った）を見て、関連する商品を選びます。検索窓の候補表示がサジェスト、「この商品を見た人はこちらも」がレコメンドです。この整理は各社の定義から私たちが導いたもので、各社がこの対比を書いているわけではありません（出典：Elasticsearch公式ドキュメント／Algolia公式ドキュメント）。

各社のドキュメントに、違いは書かれていないのですか？

5つのサービスの公式ドキュメント14ページを確認した範囲では、両者を対比した文章は見つかりませんでした。Google Cloudの「Autocomplete for search」のページに `recommend` という語は出てこず、「About recommendation models」のページに `autocomplete` という語は出てきません。Algoliaは両方を製品として持っていますが、Recommend のドキュメントに `Query Suggestions` は0回です。各社にとっては別の製品か、同じ製品でも別の機能で、別のドキュメント系統にあります。Google Cloudでは呼び口も completeQuery と予測系に分かれていますが、Elasticsearchの suggest は検索APIの中のパラメータです。違いを気にしているのは、両方を検討している利用者側だけだ、というのが私たちの読み方です。（この記事の検証。確認したのは Elasticsearch 1／OpenSearch 1／Algolia 2／Amazon Personalize 8／Google Cloud 2 の計14ページです。出典は末尾／いずれも2026年8月28日取得）

検索結果の並べ替えは、レコメンドですか、サジェストですか？

Amazon Personalizeの分類ではレコメンドです。ほかの各社は、この分類を書いていません。Amazon Personalizeは「厳選したリストや検索結果の順序をユーザーに合わせてパーソナライズするには、PERSONALIZED_RANKING レシピでモデルを学習させます」と書いています。検索の話に見えますが、レコメンドのレシピタイプの1つです。入力が「その人の予測された関心度」なので、今回見たサジェスト側のページ（Elasticsearch・OpenSearch・Algolia Query Suggestions）には、この型は出てきません。（出典：Amazon Personalize公式ドキュメント）

レコメンドを入れるのに、何が必要ですか？

方式によって、必要なものが違います。Algoliaは各モデルの最低件数（イベント数、または属性を持つアイテム数）を公開しています。行動を使う Related Items はクリック・購入などの記録が最低10,000件、商品の属性を使う Related Content は属性を持つ商品が最低10件です。単位が違ったうえで、1,000倍の差があります。コンテンツベース側は「タイトルや説明といったアイテムの主要な属性を分析する」とされており、クリック・コンバージョンのイベントが十分に無くても表示できる、と書かれています。なお「30〜90日」は要件ではなく、「直近30日で足りなければ90日に延ばす」という、Frequently Bought Together と Related Items の2モデルについての記述です。（出典：Algolia公式ドキュメント）

サジェストは1種類ではないのですか？

Elasticsearchの分類では複数あります。completion suggester の説明には「これは、term suggester や phrase suggester のような、スペル修正や「もしかして」の機能を意図したものではありません」とあります。補完と、スペル修正が別の機能として分かれています。各社が対比しているのはこの内部の違いで、レコメンドとの対比ではありません。（出典：Elasticsearch公式ドキュメント）

出典と、書けなかったこと

引用した原文