公開2026.06.09更新2026.09.25 AI

Generative Recommendation（生成型推薦）とは？Semantic IDの仕組みとTIGER・HSTU・OneRecの違い

Generative Recommendation（生成型推薦）は、ユーザーの行動履歴を入力として、次のアイテムや行動の予測を系列生成の問題として扱う推薦方式です。TIGERのように識別子を複数トークンで生成する方式と、HSTUのように行動系列から候補生成やランキングを行う方式があります。従来の大規模推薦は、ユーザーとアイテムを同じベクトル空間に埋め込み、近いアイテムを近傍検索で拾う方式が中心でした。TIGER型の生成的検索では、検索インデックスの役割をTransformerのパラメータに持たせます。

本記事では、2023年のTIGER論文から2025年のOneRec・PLUMまでの原典を読み、Semantic IDの設定値、各モデルの公表値、論文自身が認めている弱点を整理しました。Semantic IDの作り方は、そのまま実行できるPythonコードで示しています。レコメンドの仕組み全体や種類の整理が先に必要な場合は、レコメンドエンジンとは？仕組み・種類と導入判断（SaaS/受託開発の選び分け）を分かりやすく解説を先に読むと位置づけがつかみやすくなります。

まとめ：Generative Recommendationの要点と採用判断

推薦を「スコアの高い候補を探す問題」から「次のアイテムや行動を系列として生成する問題」に置き換えた方式です。文書IDを直接生成する代表例がDSI（2022年）で、Semantic IDを用いた推薦の代表例がGoogleのTIGER（NeurIPS 2023）です。
TIGERは、アイテムの説明文の埋め込みを3段の残差量子化（各段256コード）で離散化し、衝突解消用の4番目のコードを足した4トークンをSemantic IDとして使います。
「生成型推薦」と呼ばれるモデルは一枚岩ではありません。MetaのHSTUはSemantic IDを使わず、行動の系列をそのまま扱って1.5兆パラメータまで拡大し、オンラインA/Bテストで指標を12.4%改善したと報告しています。
弱点は論文自身が書いています。TIGERは上位20件の生成で約0.3%〜6%の実在しないID（無効ID）を出し、ビームサーチを使うため近傍検索より推論コストが高くなり得ます。
初回の導入検証では、候補生成の「追加ソース」として試すことを勧めます。OneRecのように既存の多段構成を置き換えた事例もあります。HSTUの産業実験でも、既存ソースへの追加と置き換えを分けて評価しています。

Generative Recommendationの定義と従来の候補生成との違い

大規模な推薦システムは、数百万〜数億のアイテムから数百件に絞る候補生成（retrieval）と、その候補を精密に並べ替えるランキング（ranking）の2段で組むのが一般的です。TIGER論文もこの構成を前提に、候補生成の段を置き換える提案として書かれています。

従来の候補生成では、ユーザー表現とアイテム表現の内積が大きいものを最大内積探索（MIPS）や近似最近傍探索（ANN）で取り出します。ここで使うインデックスの構造や精度の調整は近似最近傍探索とは？HNSW・IVF・PQの選び分けとRecall調整を実装目線で解説【2026年版】で扱っています。TIGER型の生成的検索は、ANNインデックスを別に持たず、系列モデルが次のアイテムのIDを1トークンずつ出力します。TIGER論文の結論部は、この性質を「Transformerのメモリがアイテムの意味的なインデックスとして働く」と表現しています。

DSIによる文書IDの直接生成と検索インデックスの学習

IDを直接生成する発想は、推薦より先に文書検索で提案されました。Googleが2022年に発表したDSI（微分可能な検索インデックス、arXiv:2202.06991）は、検索クエリから関連文書のIDへの対応をtext-to-textモデルに丸ごと学習させます。検索対象のコーパスをモデルのパラメータに埋め込むやり方で、文書IDを直接生成する生成的検索（generative retrieval）の代表例です。TIGERはこの方式をSemantic IDと組み合わせて推薦に持ち込みました。論文は、Semantic IDを使った生成的検索を推薦システムに提案したのは自分たちが最初だとしています。

「生成型推薦」に含まれる3つの系統

同じ名前で呼ばれていても、何を生成するかで系統が分かれます。論文を読むときは、どの系統の話かを最初に確かめると混乱しません。

系統	生成するもの	代表例
テキスト生成型	アイテム名や回答の文字列	P5（RecSys 2022）
Semantic ID型	量子化で作った離散ID	TIGER、OneRec、PLUM
行動系列型	次の行動・アイテムID	HSTU

P5は、購買履歴やレビュー、アイテムのメタデータを自然言語の文に変換し、評価予測や系列推薦など複数のタスクを1つのtext-to-textモデルで扱います。ChatGPTのようなLLMに「おすすめを教えて」と聞く使い方もテキスト生成型に近いものの、本記事で扱う研究の中心はSemantic ID型と行動系列型です。

Semantic IDの作り方：残差量子化と衝突の処理

Semantic IDは、アイテムの内容から作る数個のトークンの並びです。連番のIDと違い、内容の近いアイテムは先頭のトークンを共有します。先頭が大分類、後ろほど細かい違いを表す階層になるため、モデルは大まかな方向を決めてから絞り込む形でIDを生成できます。

TIGERのRQ-VAEの設定値

TIGER論文（Recommender Systems with Generative Retrieval、arXiv:2305.05065）の実験設定は次のとおりです。アイテムのタイトル・価格・ブランド・カテゴリなどの文をSentence-T5に通して768次元の埋め込みを作り、RQ-VAE（残差量子化を使う変分オートエンコーダ）で3段に量子化します。

エンコーダは512・256・128の3層で、32次元の潜在ベクトルへ圧縮します。
各段に、32次元のコードベクトルを256個収めたコードブックを1つ持ちます。1段目で最も近いコードを選び、元のベクトルとの差（残差）を2段目で量子化し、さらにその残差を3段目で量子化します。
3段のコードが一致するアイテムが複数あるときは、4番目のトークンで区別します。衝突が無くても4番目には0を入れるため、IDの長さは全アイテムで4に揃います。
語彙はアイテム用の1,024トークン（256×4）と、ハッシュでユーザーIDを割り当てる2,000トークンです。
コードブックの大半が使われず少数のコードに入力が集まる「codebook collapse」を防ぐため、最初の学習バッチにk-meansをかけてコードブックを初期化しています。

論文は付録で、各コードブックに64個のコードを持つ6トークンの構成も試しています。推薦精度はほとんど変わらなかった一方、IDが長いほど入力系列が伸びて計算が重くなると書いています。TIGERの実験では構成変更による精度差が小さかったため、段数とコードブックの大きさは、自社データで精度と推論コストを比較して選ぶのが妥当です。

RQ-VAEを使わず残差k-meansで作る選択（OneRec）

KuaishouのOneRec（arXiv:2502.18965）は、RQ-VAEではコードの割り当てが偏る「hourglass phenomenon」が起きるとして、段ごとに割り当て件数を揃えるBalanced K-meansを使った残差k-meansでSemantic IDを作っています。Snap Researchの公開実装GRIDも、残差k-means・RVQ・RQ-VAEの3方式を切り替えて比較できる作りです。オートエンコーダの学習を挟まない残差k-meansは、手元で仕組みを確かめる出発点に向いています。

残差k-meansとプレフィックス木つきビームサーチを試すPythonコード

次のコードは、500件のダミー埋め込みから3段×8コードのSemantic IDを作り、衝突を4番目のトークンで解消したうえで、実在するIDだけを辿る幅5のビームサーチで、探索中に残った候補から5件を出します。全アイテムでの厳密な上位5件は保証しません。TIGERのデコーダの代わりに、各段のコード中心とユーザーベクトルの内積を対数確率に見立てています。依存はNumPyだけで、Python 3.9とNumPy 2.0.2で実行しました。

import numpy as np
from collections import defaultdict

rng = np.random.default_rng(0)

def kmeans(x, k, iters=20):
    c = x[rng.choice(len(x), k, replace=False)]
    for _ in range(iters):
        a = ((x[:, None, :] - c[None]) ** 2).sum(-1).argmin(1)
        for j in range(k):
            if (a == j).any():
                c[j] = x[a == j].mean(0)
    return c, a

def residual_kmeans(emb, levels=3, k=8):
    """埋め込みを段ごとにk-meansで量子化し、残差を次の段へ渡す"""
    codes, books, r = [], [], emb.copy()
    for _ in range(levels):
        c, a = kmeans(r, k)
        codes.append(a)
        books.append(c)
        r = r - c[a]
    return np.stack(codes, 1), books

emb = rng.normal(size=(500, 16)).astype(np.float32)   # 500アイテムの内容埋め込み（ダミー）
codes, books = residual_kmeans(emb)

# 衝突解消: 同じ3桁コードのアイテムに4桁目の通し番号を振る
seen, sem_ids = defaultdict(int), []
for row in map(lambda r: tuple(int(v) for v in r), codes):
    sem_ids.append(row + (seen[row],))
    seen[row] += 1
print("重複した3桁コード:", sum(v > 1 for v in seen.values()), "/ 4桁目の最大値:", max(seen.values()) - 1)

# 実在するSemantic IDだけを辿れるプレフィックス木
trie = defaultdict(set)
for sid in sem_ids:
    for i in range(len(sid)):
        trie[sid[:i]].add(sid[i])

def constrained_beam(logprob, beam=5, length=4):
    beams = [((), 0.0)]
    for _ in range(length):
        cand = [(p + (t,), s + logprob(p, t)) for p, s in beams for t in trie[p]]
        beams = sorted(cand, key=lambda x: -x[1])[:beam]
    return beams

user = rng.normal(size=16)   # デコーダの代わりに「ユーザー表現との近さ」を対数確率として使う
def logprob(prefix, tok):
    d = len(prefix)
    return float(books[d][tok] @ user) if d < 3 else 0.0

for sid, s in constrained_beam(logprob):
    print(sid, round(s, 2), "実在" if sid in set(sem_ids) else "無効")

重複した3桁コード: 132 / 4桁目の最大値: 4
(6, 1, 4, 0) 4.99 実在
(5, 3, 4, 0) 4.92 実在
(6, 3, 2, 0) 4.35 実在
(6, 1, 2, 0) 4.27 実在
(5, 3, 2, 0) 4.2 実在

出力から読み取れることは2つあります。1つ目は衝突の多さです。500件を8×8×8＝512通りに割り振っても、3桁が重なる組が132あり、同じ3桁に最大5件が集まりました。コードの組み合わせ数がアイテム数を上回っていても、埋め込みの分布が偏ればIDは重なります。4番目のトークンが必要になるのはこのためです。

2つ目は、プレフィックス木で候補を絞ると無効IDが原理的に出ないことです。trie[p]には実在するIDの続きしか入っていないため、生成途中で存在しない枝に進めません。TIGERは無効IDをビーム幅を広げて後から捨てる方法で扱い、途中の一致で近いアイテムを拾う方法は今後の課題としていました。なお、全500件を同じスコアで採点し直すと、(5, 1, 4, 0)や(0, 1, 4, 0)が上位5件に入り、ビームの結果とは一致しません。幅5のビームは各段で上位5本の枝しか残さないため、途中の段で順位の低かった枝を捨ててしまいます。ビーム幅は精度と計算量の釣り合いで決める値で、OneRecが本番で128を使っているのもこのためです。上位の結果には共通のプレフィックスが見られます。ただし、この例は乱数の埋め込みを使っているため、商品カテゴリのような意味的な大分類が形成されたことは確認できません。

主要モデルの比較：TIGER・HSTU・OneRec・PLUM

モデル	発表	アイテムの表し方	担う段	公表値
TIGER	Google／NeurIPS 2023	Semantic ID（RQ-VAE）	候補生成	NDCG@5 最大+29%
HSTU	Meta／ICML 2024	アイテムIDの行動系列	候補生成・ランキング	A/Bで+12.4%
OneRec	Kuaishou／2025年2月	Semantic ID（残差k-means）	候補生成とランキングを統合	総視聴時間+1.68%
PLUM	Google DeepMind・YouTube／2025年10月	Semantic ID（SIDv2）	候補生成	Panel CTR：長尺+0.76%／Shorts+4.96%

TIGER：1,300万パラメータでの系列推薦精度

TIGERの系列モデルはエンコーダ4層・デコーダ4層のTransformerで、パラメータは約1,300万です。AmazonレビューデータのBeauty・Sports and Outdoors・Toys and Gamesで評価し、Beautyでは2番手の手法に対してNDCG@5で最大29%（SASRec比）、Recall@5で17.3%（S3-Rec比）上回りました。Transformerの構造そのものはTransformerとは？自己注意の仕組みとBERT・GPTの違いを実装目線で解説で説明しています。

コールドスタートの実験では、テスト用アイテムの5%を学習データから外して「未見アイテム」とし、学習済みのRQ-VAEでそれらにもSemantic IDを付けています。生成された先頭3トークンが一致する未見アイテムを候補に混ぜる割合をεで制御し、ε≧0.1の全設定で、同じ意味空間の近傍探索（Semantic_KNN）を上回りました。行動実績の無い新商品を候補に入れられる点は、連番IDには無い性質です。

HSTU：Semantic IDを使わない行動系列モデルの拡張性

MetaのHSTU（Hierarchical Sequential Transduction Units、arXiv:2402.17152）は、推薦を「ユーザー行動の系列を生成する問題」として定式化し直したものです。TIGERのように内容から量子化IDを作るのではなく、アイテムIDと行動の系列を直接扱います。主な公表値は次の3つです。

1.5兆パラメータのモデルで、オンラインA/Bテストの指標を12.4%改善し、数十億ユーザー規模のプラットフォームの複数の画面に導入されました。
長さ8,192の系列では、FlashAttention2を使うTransformerより5.3〜15.2倍高速です。推論ではM-FALCONという手法で候補の採点をまとめて処理し、従来モデル（DLRM）の285倍の計算量を持つモデルでも、1,024件／16,384件の採点で1.50倍／2.99倍のQPSを出しました。
品質が学習計算量のべき乗則に沿って、3桁にわたり伸び続けました。従来のDLRMは約2,000億パラメータで性能が頭打ちになったとしています。

同じ論文の候補生成の比較表には、見落とされやすい数字があります。内容の特徴だけを入力にした「GR (content-based)」はHR@100が11.6%で、行動履歴だけを使う「GR (interactions only)」の35.6%や、既存のDLRMの29.0%を大きく下回りました。LLMのように内容の意味を理解させれば行動データは要らなくなる、という期待はこの結果と合いません。

OneRecとPLUM：2025年の産業実装

OneRecは、エンコーダ・デコーダ構成に疎なMixture-of-Expertsを組み合わせ、1本ずつではなくセッション単位の動画リストを生成します。候補生成とランキングの多段構成を1つの生成モデルで置き換えることを狙った設計です。本番に載せたOneRec-1Bは、Semantic IDを各段8,192クラスタ×3段で作り、ビーム幅128で生成し、MoEのおかげで推論時に動くのはパラメータの13%です。DPO（Direct Preference Optimization）を用いるIPA（Iterative Preference Alignment）で好みに合わせ込んだうえで、主要トラフィックの1%を使ったA/Bテストで既存の多段システムと比べ、総視聴時間が1.68%、平均視聴時間が6.56%伸びたと報告しています（要旨では1.6%と丸めています）。

PLUM（arXiv:2510.07784）は、既存の事前学習済みLLMをYouTubeの推薦へ転用する枠組みです。Semantic IDによるアイテムのトークン化、推薦ドメインのデータでの継続事前学習、推薦タスク向けのファインチューニングの3段階で構成されます。CPTと入力の視聴履歴を除いた900M MoEモデルでの比較では、SIDv2はSIDv1に比べてSemantic IDの一意性を94.0%から96.7%へ、動画のRecall@10を12.3%から14.4%へ上げました。

生成型推薦の弱点：無効ID・推論コスト・人気バイアス

導入を検討する際に効いてくるのは精度より弱点の側です。いずれも各論文が自ら記述しているものです。

無効ID：TIGERが生成した実在しないSemantic IDは、上位10件で約0.1%〜1.6%、上位20件で約0.3%〜6%でした。表示枠を必ず埋めるには、ビームを広げて捨てるか、先のコードのようにプレフィックス木で生成を制約する必要があります。
推論コスト：TIGERの付録は、自己回帰のビームサーチを使うため、推論時にANNベースのモデルより計算コストが高くなり得ると明記しています。IDを長くするほど系列が伸びる点も先に触れたとおりです。ミリ秒単位の応答を求める画面では、ビーム幅を変えながらレイテンシを最初に測るべきです。
人気バイアス：2026年5月のGhost論文（arXiv:2605.16825）は、生成型推薦も人気アイテムに偏ると指摘し、トークン単位の最適化の欠陥とアイテムのトークン化の性質が重なって深刻化すると分析しています。従来の偏り補正を持ち込んでも効果は小さいとしています。
IDの固定：TIGERはRQ-VAEの学習後に「アイテムID→Semantic ID」と「Semantic ID→アイテムID」の2つの対応表を作り、系列モデルの学習中は固定します。埋め込みモデルやRQ-VAEを学習し直すとIDの割り当てが変わり得るため、その場合は系列モデルも学習し直すことになります。

導入判断：生成型推薦を試す条件と見送る条件

OneRecは多段構成の置き換えを実証しましたが、比較対象は数億人規模の自社システムで、実験には主要トラフィックの1%を使っています。同じ条件を用意できない事業者が最初から置き換えを狙う必要はありません。HSTUの産業実験でも、候補生成の既存ソースに生成モデルを追加した場合（HR@100は36.9%、オンライン+6.2%／+5.0%）と、既存の主ソースを置き換えた場合（+5.1%／+1.9%）を分けて報告しており、追加の方が上回っています。まず候補生成の1ソースとして並べ、既存の候補との重複率とオンライン指標で評価するのが筋です。

Semantic ID型を検討する動機には、次のようなものがあります。これらは必須条件ではなく、学習データと推論予算を別途確認する必要があります。

新商品や新着コンテンツの入れ替わりが速く、行動実績の無いアイテムを候補に入れられないことが損失になっている。
アイテムごとにタイトル・説明文・カテゴリなど、埋め込みに使える内容情報が揃っている。
数百万件以上のアイテムがあり、埋め込みテーブルと近傍検索インデックスの運用が負担になっている。

逆に、アイテムが数万件以下で、行動ログも内容情報も薄いサービスでは、生成型推薦を最初の選択肢にする理由がありません。HSTUの産業実験では内容特徴だけのモデルが行動系列を使うモデルを下回りました。ただし、この結果だけでは、自社データで必要なログ量や達成できる精度は判断できません。この規模なら、Amazon Personalizeとは？レシピ選定とデータ要件・料金の見積もり【2026年版】で扱うようなマネージドサービスのデータ要件を確認し、要件を満たす方式を比較候補にしてください。行動ログが乏しい場合は、協調フィルタリングだけで必要な精度が得られるとは限りません。国内のSaaS型レコメンドとの比較はAIレコメンドエンジンの比較｜選び方と主要サービス【2026年版】にまとめています。

検証に公開実装を使う場合はライセンスを先に確認してください。HSTUの実装であるmeta-recsys/generative-recommendersはApache License 2.0で、2026年9月25日時点でGitHub上のリリースは1件もありません。TIGER型の再現に便利なsnap-research/GRIDは、ライセンスが非商用の研究目的に限られており、別契約が無い限り商用のPoCにはそのまま流用できません。

よくある質問

Generative Recommendationと、生成AIに商品を推薦させることは同じですか？

同じではありません。研究で言う生成型推薦の中心は、行動履歴を入力にして次のアイテムのSemantic IDや行動を生成する専用モデルです。ChatGPTのようなLLMに文章でおすすめを答えさせる方法は、P5に近いテキスト生成型にあたり、実在しない商品名を返すことがある点で扱いが異なります。

Semantic IDとは何ですか？

アイテムの内容の埋め込みを残差量子化して作る、数個のトークンの並びです。TIGERでは各段256コードの3段量子化に衝突解消用の1トークンを足した4トークンで、内容が近いアイテムほど先頭のトークンを共有します。

HSTUはSemantic IDを使っていますか？

使っていません。HSTUはアイテムIDと行動の系列をそのまま扱う行動系列型です。論文では、内容の特徴だけを入力にした場合（HR@100で11.6%）が、行動履歴を使う場合（35.6%）を大きく下回ったと報告しています。

generative retrievalとgenerative recommendationの違いは何ですか？

generative retrievalは、検索対象のIDをモデルが直接生成する検索方式の総称で、2022年のDSIは文書IDを直接生成する代表例です。generative recommendationはそれを推薦に適用したもので、クエリの代わりにユーザーの行動履歴を入力にします。TIGERの論文タイトルも「Recommender Systems with Generative Retrieval」です。