従来の仕組みの組み合わせでできる使いやすいアルゴリズム
今回のアルゴリズムは他のサービスへの展開が容易となっています。1に関しては、従来のItem to Itemのレコメンドのため、外部APIを活用しています。2に関しては新たに実装しましたが単純なソーシャルグラフ・ランキングのためFacebookのソーシャルグラフ用API(以下、Graph API)からデータを取得すれば誰にでも作れるものです。
また、クリック結果をウェイトに反映させる方式も外部APIの従来の機能の組み合わせです。よって、ほとんどが従来の仕組みの組み合わせからできているため、実装が容易であり、今回のホットペッパーフレンズ以外のサービスにも展開しやすいのです。
しかし、このレコメンド機能をリリースまでの道のりは、決して容易なものではありませんでした。
ソーシャルグラフ・レコメンド実現における3つの課題～Graph API関連
ホットペッパーフレンズのソーシャルグラフ・レコメンドをリリースするまでには多くの課題がありました。
2012年2月にホットペッパーフレンズに今回のレコメンドを実装することが決まり、アルゴリズムの検討、システム実装がはじまりました。レコメンドのシステム実装自体は3～4か月程度で完了しましたが、ホットペッパーフレンズアプリが2012年4月にリリースされてから約5か月間ソーシャルグラフ・レコメンド機能はリリースできませんでした。それはなぜか？ 原因は様々ありましたが主な要因は次の3点となります。
- Graph APIの経験値・仕様変更
- ソーシャルグラフデータのセキュリティレベル
- コールドスタート問題
1：Graph APIの仕様経験・仕様変更
今回のソーシャルグラフデータ取得には、FacebookのGraph APIを活用しました。Graph APIとは、"https://graph.facebook.com/ID" のようなフォーマットでFacebookにリクエストを投げることで、ユーザーが許諾した範囲でユーザー名や友人名、チェックイン履歴などのソーシャルグラフの情報を取得できる仕組みです。
非常に便利な機能ですが、社内でもまだまだ経験者が少なく、英語のドキュメントから仕様を手探りで確認する状態からはじまりました。まずは何が取得できて、何が取得できないかを整理するところから始める必要があったのです。Graph API取得項目リストなども作成、社内で共有し、要件定義や開発を行っていきました。
ここまでも比較的苦労しましたが、開発中はFacebook側の仕様変更に何度も悩まされました。例えば、特定情報の取得期間が変更になったときは、これまで一度の問い合わせで取得していたものが複数の問い合わせでしか情報を取得できなくなり、プログラムの改修が必要になったこともありました。
また、特にプロジェクト内で騒ぎになったのがOffline_accessの廃止です（※）。レコメンデーションの計算はバッチ処理で行うため、ソーシャルグラフデータもバッチ処理で取得する必要がありました。
しかし、Offline_accessが廃止されるとバッチでソーシャルグラフデータを取得できないため、設計そのものを見直す必要が生じます。当時はFacebookからの公式情報も少なく、その中での検討は試行錯誤でした。今でこそ、アクセストークン（Facebookのソーシャルグラフ情報を取得するためのキー）の有効期間を延長することで、回避できることが一般になっていますが、当時は仕様変更に苦労しました。
