こんにちは。この記事では、アクセスログから
「このアイテムを閲覧した人はこちらのアイテムもよく閲覧しています」
APIを作成する方法をご紹介します。
GitHubで公開されている Product-Recommendations というオープンソースを使用します。 コーディングは不要です。
できるもの
- ある
アイテムID(「商品ID」や「スポットID」など)をパラメータに渡すと、関連度の高いアイテムIDのリストを返却する - 学習データはアクセスログを使用します
- これを Azure 上に作成し、APIとして利用できるようにします
用意するもの
-
Azure アカウント( 無料作成方法はこちら )
-
アクセスログから
ユーザID,レコメンドしたいアイテムのID,タイムスタンプを抽出したCSVファイル (詳細は Tips 参照)
ユーザID,アイテムID,タイムスタンプ
USER0001,02301-1301284,2018-01-16 17:42:11
USER0002,02301-130087,2018-01-16 17:58:46
USER0001,07008-0000001047,2018-01-17 00:01:14
(以下略)
今回は ナビタイムのスポットページ へのアクセスログから、ユーザID、スポットID、タイムスタンプを使用しました。
10分クッキング
Azureサーバ構築&デプロイ(3分)
-
Product Recommendations の デプロイページ へアクセスし、上部の
Deploy to Azureボタンをクリック

-
必要事項を入力し、
購入ボタンをクリック (参考:費用について)

-
確認
- リソースグループ > [先ほど作成したリソースグループ名] > デプロイ >
Microsoft.Templateを選択 - 出力 を選択。以下3つの値をコピーしておきます
| KEY | 内容 |
|---|---|
| RECOMMENDATIONSUI | モデル作成やテストに使えるWebツールのURL |
| RECOMMENDATIONSSWAGGER | Swagger のURL |
| ADMINPRIMARYKEY | 上記2つのWebツールの使用時に要求されるキー |
ログをアップロード(1分)
1.先程作成したストレージアカウントの Blob Storage に任意の名前(ここでは「input-files」)のコンテナを作成します

ログからモデルを作成(5分)
-
先程コピーした
RECOMMENDATIONSUIのURLをブラウザで開きます。**そう、先程デプロイしたサーバに、必要なWebツールやSwaggerがすでに用意され使える状態になっています。**キーが要求されるので、同じく先程コピーしたADMINPRIMARYKEYの値を入力しLOGINボタン押下

確認する(1分)
UIツールで確認
関連するアイテムIDと関連度(SCORE)が返却されました!
上から、
伏見稲荷大社、金閣寺、嵐山、八坂神社、京都タワー
のIDです。
「清水寺」を検索した人が検索していそうなスポットですね。
Swaggerで確認
-
先程コピーした
RECOMMENDATIONSSWAGGERのURLをブラウザで開きます。右上のボックスに同じく先程コピーしたADMINPRIMARYKEYの値を入力します -
Operationsの文字をクリックするとAPI一覧が表示されるので、GET /api/models/default/recommendを選択

-
関連するアイテムIDと関連度(SCORE)の返却を確認できました!
上から、
大通公園、さっぽろテレビ塔、サッポロビール博物館、小樽運河、白い恋人パーク
のIDです。
こちらは「札幌時計台」を検索した人が検索していそうなスポットが返却されました。
以上で 「このアイテムを閲覧した人はこちらのアイテムもよく閲覧しています」 APIが完成しました。
Tips集
料金は?
- GitHubで公開されている Product-Recommendations は無料で使用できます。(LICENSEについて)
- 通常と同じくAzure上に新規作成したリソース(
AppServiceなど)の使用料金のみかかります。
精度は?
- 精度はデータ量やデータのばらつきに依存するので一概には言えません。ただ、既存のアクセスログを使用しただけのモデルでも実用に耐えうるというのが個人的な所感です。
- 精度や評価方法については Product-Recommendationsの評価解説ページ
どういう仕組?
- Product-Recommendations の内部では、ユーザの行動ログを機械学習し関連度を算出しています。
- 今回は 「ユーザの行動ログ」 = 「アクセスログ」 = 「学習データ」 です。
- 詳しいアルゴリズムは Product-Recommendationsの解説 参照
ログについて詳しく!
- こちらも Product-RecommendationsのAPIリファレンス が詳しいです
- アクセスログ以外の、アプリログなどから抽出したデータでも全く構いません。アクセスログはどのサービスでも蓄積されている既存資産だと思うので、今回例として使用しました
- たとえば、NAVITIMEのスポットページのURL https://www.navitime.co.jp/oi?spt=02301.1301284 にはスポットのIDが含まれます。(どのウェブサイトにもこういったアイテム表示ページがあると思います) 今回はアクセスログからこのスポットID、ユーザID、タイムスタンプを使用しました
「あなたにオススメ」(Personalize)はできないの?
- 今までインプットが「アイテムID」、アウトプットが「インプットのアイテムIDに関連するアイテムID」のパターンを説明してきました
- 実はインプットが「ユーザの行動ログ」、アウトプットが「ユーザの行動ログに関連するアイテムID」 取得用のAPIも、これまでの過程ですでに作成されてます
- 詳しくは Product-RecommendationsのAPIリファレンス 参照
URLがダサいんだけど…
- リソース名の末尾に無作為の文字列がつくのは仕様です。
- 本番リリース時には API Management を使ってURLをリダイレクトしましょう。すでにSwaggerJsonファイルが生成されているので、Importも楽ちん! (上記ドキュメントの
OpenAPI Specificationに Swagger の上部に表示されているjsonURLを指定します。一瞬で全APIがImportできます)
まとめ
以上、10分でAzure上にレコメンデーションAPIを作成する方法でした。
機械学習と聞くとデータの収集で頓挫しがちですが、会社に眠る既存資産(アクセスログ)でお手軽に作成できる点が魅力ですね。










