Amazon Personalizeとは？レシピ選定とデータ要件・料金の見積もり【2026年版】

Amazon Personalizeは、ユーザーの行動ログを渡すとレコメンド結果をAPIで返すAWSのマネージド機械学習サービスです。モデルを自分で書く必要も、GPUを手配する必要もありません。ただし学習を始めるには1,000件のインタラクションと25人のユーザーが要り、リアルタイム用のキャンペーンを1本立てた時点でアクセスがゼロでも月数百USDの固定費が走ります。リソース構成、レシピの選び分け、スキーマ設計、boto3での実装手順、公開単価から逆算した月額の下限、選ばない方がよい場面までを実装の順序で並べました。

まとめ：導入可否を分けるデータ量・レシピ選定・最低課金の3条件

つまずく箇所は機能の理解ではなく、必要データ量と課金構造の見誤りです。着手前に確かめるのは3点。行動ログが月5万件に届くか、返してほしい出力がどの形か、リアルタイム応答が本当に要るのかどうか。

学習を開始できる下限は1,000件のユニークなアイテムインタラクションと25人のユニークユーザーですが、AWSが良質なレコメンドの目安に挙げるのは1,000ユーザー以上からの50,000件以上です。この差を埋めないまま学習を回すと、人気順とほとんど変わらない結果が返ってきます。

費用の主役は推論でしょう。v2レシピは1,000リクエストあたり0.15 USD。しかもキャンペーンには最低プロビジョニングTPSがあり、既定値の1でも30日分で約259万リクエスト相当、およそ389 USDが下限になります。数時間の遅れを許せる用途なら、キャンペーンを作らずバッチ推論へ寄せてください。同じ100万件でも150 USD、常時起動分はゼロです。

Amazon Personalizeの定義｜学習済みモデルをAPIで返すレコメンド基盤

何を引き受け、何が手元に残るのか。線引きから始めます。

フルマネージドの推薦API｜モデル構造とGPU調達を任せられる構成

行動ログとアイテム情報を渡すとAWS側で推薦モデルを学習し、その結果をHTTPS APIとして公開するサービスです。アルゴリズムの実装にも学習インスタンスの選定にも触れません。特徴量の設計もモデル構造もサービス内部に隠れています。

返る形は2系統。GetRecommendationsで受け取るアイテム側の出力と、Item-Affinityなどでバッチ実行するユーザーセグメントの出力です。後者はメールやプッシュ通知の配信先を絞る用途に向きます。

裏返すと、モデルの重みは取り出せません。エッジ端末やオンプレミスの推論基盤へ載せ替える使い方はできない設計です。行動ログを社外へ出せない案件では、この一点で候補から外れます。

自前実装との境界｜Personalizeが引き受ける範囲と残る作業

引き受けてもらえるのは学習と推論、そのスケーリングまで。残るのは行動ログをS3へ届ける経路、スキーマ設計、フィルタ定義、再学習の実行管理です。供給が止まればモデルは静かに陳腐化するため、データパイプラインの構成要素と冪等性から考える設計を先に固めておくと運用が軽くなります。

マネージドAPIとSaaS型ツール、スクラッチ開発のどれを取るかから迷っている段階なら、レコメンドエンジンの方式とSaaS・受託開発の選び分けを先に読んでから戻ってきてください。

データセット3種からキャンペーンまでのリソース構成と処理の流れ

単一のAPIではなくリソースを積み上げる構造です。依存関係を先に押さえます。

Interactions・Items・Usersという3データセットの役割分担

データセットグループの下に置くのは、アイテムインタラクション、アイテム、ユーザーの3種類が基本です。必須はアイテムインタラクションだけ。USER_ID、ITEM_ID、TIMESTAMPの3列があれば学習は始まります。

アイテム側にはカテゴリや価格帯、ユーザー側には会員種別や地域を入れます。v2レシピはこのメタデータを追加費用なしで学習に含められる仕様。従来レシピが1,000リクエストあたり0.0167 USDを取っていた部分が無料になりました。

ソリューションとソリューションバージョンで学習を管理する仕組み

ソリューションは「どのレシピでどのデータを学習するか」の設定、ソリューションバージョンはその設定で実際に学習した成果物です。再学習するたび新しいバージョンが積み上がります。アクティブなソリューションはデータセットグループあたり10個まで。

2025年4月11日付で追加されたイベント設定を使うと、閲覧と購入で重みを変えられます。購入イベントの少ないメディア系サイトでは、ここを触るだけで傾向が変わりました。

推論の受け口となるキャンペーンとバッチ推論ジョブの使い分け基準

キャンペーンはソリューションバージョンをデプロイしたリアルタイム推論の受け口で、常時起動しているぶん常時課金されます。バッチ推論ジョブはS3の入力を読んで結果をS3へ書き出す都度実行型で、待機コストがありません。

分かれ目は、推薦結果が何分前のものまで許容できるかという一点です。ログイン直後の行動を即座に反映したいならキャンペーン、夜間に作り置きできるならバッチ。

レシピ選定の指針｜v2レシピとドメインユースケースの適用範囲と使い分け

レシピは12種類ほどありますが、実務で最初に検討するのは4つに絞られます。

User-Personalization-v2の適用条件と500万アイテムの上限

ユーザーごとのおすすめを出す標準解がUser-Personalization-v2です。Transformerベースの構成で、AWSの発表値では従来版に対し精度が最大9%改善、推薦カバレッジが1.8倍に広がったとされます。ハイパーパラメータ探索（HPO）は常時有効。

扱えるのは最大500万アイテム、30億インタラクションまで。従来レシピの上限は750,000アイテム・5億インタラクションなので、大規模カタログではv2以外の選択肢が実質ありません。

探索の重み（既定0.3）は、インタラクションの少ない新規アイテムをどれだけ混ぜるかを決めます。背景の考え方は多腕バンディット問題における探索と利用のバランス調整と同じ。露出を優先しすぎると既存ユーザーの体感精度が落ちるため、動かすときは指標を見ながら小刻みに。

Personalized-Ranking-v2とSimilar-Itemsの出力の違い

Personalized-Ranking-v2は、渡したアイテム候補をユーザー向けに並べ替えて返します。在庫や配送可否で絞った結果を個人向けに並べる検索結果ページや特集で使う形。ゼロから候補を作るUser-Personalization-v2とは入力が違います。

Similar-ItemsとSIMSはユーザーIDを取らず、指定したアイテムに近いものを返すレシピです。ZOZO NEXTがFashion Tech Newsの記事下レコメンドで採用したのもSimilar-Itemsで、ログイン機能がないためGA4のクライアントIDをユーザー識別子に充てたと同社の技術ブログが公開しています。

Trending-NowとSemantic-Similarity｜新しい2レシピ

Trending-Nowは直近の伸び率が高いアイテムを返し、ユーザーIDを必要としません。ニュースや動画のように鮮度が効く領域で、パーソナライズ枠の隣に置く使い方が向きます。

Semantic-Similarityは、AWSのドキュメント更新履歴で2025年11月30日付の追加とされる新しいレシピです。行動ログではなくタイトルや説明文からアイテムの類似を定義し、人気度やタイムスタンプによる並べ替えを任意で加えられます。増分学習にも対応するため、商品が頻繁に入れ替わるカタログと相性がよい構成でしょう。生成モデルで推薦系列そのものを出す潮流は別方式で、Generative Recommendationの仕組みと従来手法との違いに整理しました。

ドメインレコメンダーとカスタムリソースのどちらを選ぶかの判断基準

ドメインデータセットグループを選ぶと、ECOMMERCEとVIDEO_ON_DEMANDの2ドメインで用意されたユースケースを、レシピを意識せずデプロイできます。ECOMMERCEならMost Viewed、Best Sellers、Frequently Bought Together、Customers Who Viewed X Also Viewed、Recommended For Youの5つ。

手数は少なく済みます。ただしレコメンダーは合計5個まで、調整範囲もユースケースごとの設定に限られる制約付き。判断は「標準的なECの5枠で収まるか」の一点で構いません。収まらないならカスタムリソース側です。

学習に必要なデータ量とスキーマ設計｜1,000件の下限とコールドスタート

検証が止まる原因の大半はデータ側です。数量、列設計、初期状態の順に潰します。

1,000インタラクション・25ユーザーという学習開始の下限値

学習を開始する条件は、1,000件のユニークなアイテムインタラクションと、2件以上のインタラクションを持つユニークユーザー25人。この数字は実行可能になる下限にすぎず、AWSが良質な推薦の目安として示すのは1,000ユーザー以上からの50,000件以上です。

Happy Elementsが公開した導入検証でも、開発環境の履歴が下限に届かず取得範囲を広げる必要があったと報告されています。本番相当のログを匿名化して持ち込んでください。

EVENT_TYPEとEVENT_VALUEの設計がレシピの選択肢を決める

アイテムインタラクションのEVENT_TYPEには閲覧や購入といったイベント名を入れます。この列を最初から埋めておかないと、後からBest SellersやFrequently Bought Togetherへ進めません。これらのユースケースは購入イベントが1,000件以上あることを前提にしているためです。

EVENT_VALUEは数値で、視聴完了率や購入金額のような強度を表します。ソリューション側でしきい値を設ければ、途中離脱を学習から除外する絞り込みも可能。取得コストがほぼゼロなので、使う予定がなくても列だけは用意しておく判断が無難です。

コールドスタート対策｜新規アイテムと新規ユーザーで異なる打ち手

新規アイテム側は、User-Personalization-v2の探索の重みとアイテム期間カットオフ（既定30日）で露出量を制御するのが基本線。メタデータだけで類似を測るSemantic-Similarityを併用する手もあります。

新規ユーザー側は履歴がないため個人向けの推論が成立しません。初回セッションはTrending-NowやPopularity-Countで人気順を返し、PutEventsで数件の行動が溜まった時点でパーソナライズ枠へ切り替える二段構えが実装しやすい形でしょう。同一セッション内で送ったイベントは、その場の推論に反映されます。

boto3による実装手順｜データ取り込みから推論エンドポイント公開まで

各ステップが非同期で完了を待つ設計になっている点が他のAWSサービスと違います。

データセットグループの作成からインポートジョブが完了するまでの流れ

最短経路は次の順序です。

1. データセットグループを作成する
2. スキーマをJSONで定義しデータセットを作る
3. CSVをS3へ置きIAMロールに読み取り権限を与える
4. データセットインポートジョブを実行する
5. ソリューションを作成し学習を走らせる
6. キャンペーンまたはバッチ推論ジョブで結果を受ける
7. PutEventsで以降の行動ログを流し込む

スキーマはAvro形式のJSONで列名と型を宣言する仕様。一度作ると変更できないため、迷ったら列を多めに定義しておく方が手戻りは少なく済みます。インポートジョブのモードはFULLとINCREMENTALの2つで、日次の差分投入には後者を。

create_solutionとcreate_campaignの実行と待ち時間の目安

create_solutionでレシピとデータセットグループを紐づけ、create_solution_versionで学習を起動します。完了はdescribe_solution_versionのステータスをポーリングして確認する流れ。

所要時間の実測例として、Happy Elementsの検証記事ではインポート5分、モデル構築35分、推論25分の合計65分という数字が公開されています。日次なら夜間バッチに収まりますが、1時間ごとの再学習は成立しません。キャンペーン作成時のmin_provisioned_tpsは既定の1から始め、CloudWatchメトリクスを見ながら引き上げるとAWSも推奨しています。

PutEventsによるリアルタイム反映とイベントトラッカーの設定

行動ログをリアルタイムに送るには、先にイベントトラッカーを作成してトラッキングIDを取得します。PutEventsにはこのIDとセッションIDを添えて送信し、ログイン前はセッションIDだけで扱い、ログイン後にUSER_IDと結びつけます。レートはデータセットグループあたり毎秒1,000リクエスト、1コール10イベント、1イベント10KBまで。

一方でPutItemsとPutUsersは毎秒10リクエストのみ。カタログの一括更新はS3経由のインポートで流します。送信したイベントはその場の推論に反映されるだけで、モデル自体の更新には再学習が要ります。

料金の見積もり｜取り込み・学習・推論の3項目とキャンペーン固定費

単価そのものより、キャンペーンの下限をどう扱うかで総額が決まります。

取り込み0.05USD・学習0.002USD・推論0.15USDという単価

2026年7月時点の公開単価は次のとおりです。v2レシピと従来レシピで学習と推論の課金単位が違う点に注意してください。

無料利用枠は最初の2か月に限られ、月20GBの処理、v2レシピで月500万インタラクションの学習と月50,000件の推論が含まれます。キャンペーンを立てたまま3か月目に入ると請求が跳ねます。

最低1TPSという固定費｜アクセスが無くても発生する月額の下限

キャンペーンには最低プロビジョニングTPSがあり、実リクエストが下回っても設定値分が課金されます。既定値の1で30日を計算すると、毎秒1件×2,592,000秒＝約259万リクエスト相当。v2レシピの単価0.15 USDを掛けて、月およそ389 USDが下限になります。

この計算は実測値とも整合します。従来レシピの0.0556 USDで同じ計算をすると月約144 USDとなり、ZOZO NEXTが公開したキャンペーン費用「月約144 USD」とほぼ一致するためです。同社はトレーニング費用を月約72 USDと報告しました。

設定値を上げればコストは比例して増え、低いままだと急なトラフィック増加時にスケールアップ中の遅延でトランザクションを取りこぼす可能性があります。

月額の試算例｜小規模ECサイトで発生する費用の内訳と削減の余地

アイテム3万点、月間行動ログ200万件、推薦呼び出し月100万回、v2レシピで週1回の再学習という条件で置いてみます。取り込みは約0.4GBで0.02 USD、学習は200万件×4回で16 USD、推論は実リクエストが月100万回でも下限に飲み込まれて約389 USD。合計およそ405 USDです。

削りどころは明白でしょう。推薦を夜間に作り置きしてバッチ推論へ寄せれば、常時起動費が消えて100万件×0.15 USDの150 USDだけになり、学習と合わせて月約166 USDに収まります。リアルタイム性の要否を金額に換算すると、この差額240 USDが判断材料。SaaS型ツールとの総額比較に入るなら、AIレコメンドエンジンの比較と選び方で各サービスの課金形態を並べています。

採用条件と見送り判断｜Personalizeを選ばない方がよい3つの場面

ここまでの制約を踏まえて採否の線を引きます。玉虫色にせず条件で切ります。

採用してよい条件｜月5万件以上の行動ログと再学習を回せる運用体制

採用してよいのは、月間のインタラクションが50,000件を超え、かつ再学習と指標確認を定期的に回せる担当がいる場合です。ログが十分でも、学習を一度回して放置する体制では効果が数か月で薄れます。

もうひとつの条件が、既にAWS上でサービスを運用していること。S3とIAMが整っていれば取り込み経路は短く済み、ZOZO NEXTの事例では2人で約1.5か月、AWS経験者なら1〜2週間で実装可能と見積もられています。未導入の環境へこのためだけに入れるならSaaS型の方が早いでしょう。ログ設計から推薦ロジックまでまとめて外部に任せたい場合は、AIエンジン開発（レコメンド）の受託で要件整理から引き受けています。

見送るべき3つの場面｜商品数不足・秒間数千・説明責任が要る領域

第一に、アイテム数が数百点規模で行動ログも下限付近のサービス。人気順とルールベースの併用で足り、月400 USDの固定費に見合いません。

第二に、毎秒数千リクエストを捌く必要がある大規模トラフィック。上限はキャンペーンあたり毎秒500リクエスト、データセットグループ合計でも毎秒2,500リクエストです。超えるならキャンペーン分割か結果のキャッシュ、自前推論への移行を検討します。

第三に、金融商品や求人のように「なぜこれを勧めたか」の説明責任が発生する領域。モデルの中身を取り出せない以上、推薦理由を根拠付きで提示する要件は満たせません。ここはルールベースか、説明可能な自前モデルを選ぶべき場面です。

よくある質問

Amazon Personalizeの検討時に実際に検索されている質問へ、実装と費用の観点から答えます。

Amazon Personalizeの料金は最低いくらから発生しますか？

リアルタイム用のキャンペーンを1本立てると、アクセスがなくても最低プロビジョニングTPS分が課金されます。既定値の1で30日換算すると、v2レシピで月およそ389 USD、従来レシピで月およそ144 USDが下限です。キャンペーンを作らずバッチ推論ジョブだけを使う構成なら常時起動費は発生せず、実行した件数分の料金で済みます。最初の2か月は無料利用枠があり、検証段階の費用はほぼゼロに抑えられるでしょう。

Amazon Personalizeは日本語の商品データでも使えますか？

User-Personalization-v2やSimilar-Itemsのように行動ログのIDだけを見るレシピは言語に依存しないため、日本語のサービスでもそのまま使えます。注意が要るのはSemantic-Similarityで、こちらはタイトルや説明文から類似を判定する仕組み。日本語での精度は小規模なデータで確かめてから本採用を決め、カテゴリコードや価格帯のような言語非依存の属性列を併用すると安定します。

モデルの学習にはどのくらい時間がかかりますか？

公開されている検証例では、インポート5分、モデル構築35分、推論25分の合計65分という実測が報告されています。v2レシピはハイパーパラメータ探索が常時有効なぶん長めに振れるでしょう。この所要時間から、現実的な再学習の頻度は日次から週次です。直近の行動を即座に反映したい場合はPutEventsによるリアルタイム反映で対応します。

Amazon SageMakerで自前実装するのとどちらを選ぶべきですか？

推薦アルゴリズム自体を差別化要素にしない限り、Personalizeを選ぶ方が費用も工数も小さく収まります。自前実装は特徴量設計とモデル開発に数人月かかり、推論エンドポイントの運用も自分たちで担うためです。SageMakerを選ぶ理由は、独自の損失関数や複数モデルの組み合わせが要件に入る場合、推薦理由の説明が必要な場合、モデルを社外環境へ持ち出す場合の3つに絞られます。

データが少ない立ち上げ期のサービスでも導入できますか？

技術的には1,000インタラクションと25ユーザーで学習は走りますが、実用的な精度は望みにくい水準です。立ち上げ期はTrending-NowやPopularity-Countで人気順を返しつつ行動ログを溜め、月間5万件を超えた段階でUser-Personalization-v2へ切り替える段取りが現実的でしょう。テキストのメタデータが揃っているなら、Semantic-Similarityで先にコンテンツベースの推薦を出す手もあります。

関連記事

• レコメンドエンジンとは：SaaS型と受託開発のどちらを取るか、方式から決める段階の記事です
• AIレコメンドエンジンの比較：主要サービスの課金形態と選定軸を並べて比べられます
• Generative Recommendation：生成モデルで推薦系列を出す別方式との違いを整理しました
• 多腕バンディット問題とは：探索の重みという設定の背景にある考え方です
• Amazon Rekognitionとは：同じAWSのAIサービス群を実装視点で扱いました