「タップル誕生」の両思い請負人は機械学習エンジニア 技術・デザイン ~機械学習エンジニアがマッチング成功率を1.6倍にするためのプロセス~

趣味でつながる恋活マッチングアプリ「タップル誕生」では、男女の出会いの質を改善させるために情報推薦技術を活用し、マッチング成功率を1.6倍にすることができました。これを成功させた立役者が秋葉原ラボの機械学習エンジニア・内藤遥です。今日は内藤にこのプロジェクトを成功させた秘訣について話を聞いてみました。   Profile   内藤遥 (ナイトウ ヨウ) 2012年サイバーエージェントに新卒入社。秋葉原ラボにてレコメンド基盤・検索基盤の開発・運用に従事。「タップル誕生」のほか「Amebaブログ」や「Amebaマンガ」のレコメンド導入・運用も担当している。 1つでも多くの”良い出会い”を提供したい ――自己紹介をお願いします。 内藤: サイバーエージェントのメディア事業における研究開発組織「秋葉原ラボ」に所属しており、私はその中でレコメンド基盤の開発・運用に携わっています。 「秋葉原ラボ」で開発しているレコメンド基盤は2011年からスタートしており、「タップル誕生」をはじめ「ABEMA」「Amebaブログ」など様々なサービスに対して推薦機能を提供しています。その中で私は、マッチングアプリ「タップル誕生」における男女の「マッチング成功率向上プロジェクト」に注力していました。 「タップル誕生」では、男女がお互い気になる相手に”いいかも”を贈ることができ、相互に”いいかも”が贈られると「マッチング成立」とみなされ、メッセージのやり取りが可能になります。 この「マッチング成立」の割合である「マッチング成功率」は「タップル誕生」で非常に重要視しているKPIの1つです。売上や継続率など様々な指標と関連していることはもちろん、せっかく「タップル誕生」を始めてくれたユーザーに、1つでも多くの”良い出会い”を提供したいという思いを背負っています。 以前より豊富なドメイン知識を基にしたルールベースのアルゴリズムが存在し「マッチング成功率」を上げるべく運用していたのですが、秋葉原ラボの強みでもある機械学習の知識と、サイバーエージェントのメディア事業で培ったノウハウを活用したら、さらにユーザーのニーズに応えられる可能性を感じ、今回のプロジェクトがスタートしました。 双方向の嗜好を考慮した推薦が難しい理由 ――このプロジェクトにおいて難しかった部分はどんなところですか? 内藤: 難しかったのは、自分から相手への嗜好だけでなく、相手から自分への嗜好、つまり双方向の嗜好を考慮した推薦アルゴリズムを考える必要があることです。 極端な言い方かもしれませんが、複雑なことを考えなければ、その人にとって好みそうな人を推薦することは、そこまで難しい話ではありません。しかし、どれだけ”いいかも”を押しても「マッチング成功」しなければ、その”いいかも”は無駄になります。 「Amebaブログ」や「Amebaマンガ」など、これまでサイバーエージェントのメディアで活用してきた推薦アルゴリズムは基本的に一方向の嗜好のみを考えればよかったのですが、「タップル誕生」の場合、似たような手法を適用して自分が”いいかも”を押す回数が増えたとしても、相手も”いいかも”を押さないと「マッチング成立」に至らないのです。 「マッチング成功率」改善の難しさは2つありました。1つ目は「マッチング成立」のデータが教師データとして扱いづらかったことです。 機械学習のアプローチを検討する上で、まずはじめに 「マッチング成立」したか、しなかったかのラベルをつけてモデルを学習させることを検討しましたが、「マッチング成立」したデータは”いいかも”や”いまいち”に比べてかなり少なく、また「マッチング成立」したことがない、もしくはほとんどないユーザに対する推薦が困難なため、教師データとしてそのまま利用するのは難しいと考えました。 2つ目は、素直にアルゴリズムを設計しようとすると、一部の人気ユーザに”いいかも”が集中しすぎることです。こうなると、マッチングの機会損失が発生してしまい、全体の最適化を図るうえでカバレッジを考慮する工夫も必要になりました。 ――結果的に「マッチング成功率」をあげた施策はどんなものだったのでしょうか? 内藤: そもそものルールベースから機械学習の手法への切り替えによるところもありますが、最終的に”いいかも”と”いまいち”のデータを使って男性から女性、女性から男性への嗜好のスコアをそれぞれ予測するモデルと、それぞれの嗜好のスコアを結合するコンポーネントの組み合わせでアルゴリズムを設計したことが「マッチング成功率」の大幅な上昇につながりました。 アルゴリズムの設計・開発に関しては同じ「秋葉原ラボ」のレコメンドチームのメンバーによる貢献が大きいです。シンプルさや拡張のしやすさを重視していて、予測のモデルやスコアを結合するコンポーネントはそれぞれ疎結合で入れ替え可能な作りになっているため、早いサイクルでPDCAを回すことができました。また相手からの嗜好情報も自分の推薦結果に反映されるため、全体として極端に推薦結果が偏ることがなくなり、カバレッジを担保することができています。 加えて、自分に贈られた”いいかも”リストの並び替えのような、一方向の嗜好のみを考慮した推薦も片方の予測モデルを利用するだけで可能であり、今後様々な応用先を検討しています。   ――研究開発組織である「秋葉原ラボ」とサービス側の「タップル誕生」、共同でプロジェクトを進めるうえで役割分担はどのようにしていましたか? 内藤: 「秋葉原ラボ」では持続可能なサービス連携を意識して取り組んでいます。豊富なドメイン知識を持つサービス側でしか分からないこともありますし、サービス側で調整したい細かいロジックというものがあるかと思います。そういったものを「秋葉原ラボ」で持ってしまうと、変更の度にコミュニケーションコストがかかってPDCAを回すペースが遅くなる懸念があったので、「秋葉原ラボ」ではサービス側から与えられた数千~数万単位の推薦候補をランク付けする機能にあえて限定することで、「マッチング成功率」を上げるための機械学習のロジック部分にのみ責任を持つようにしました。 これにより、サービス側は固有のビジネスロジックを多く含む推薦候補の生成やフィルタなどの処理、「秋葉原ラボ」は推薦アルゴリズムのチューニングにお互い注力でき、役割分担が明確になりました。   これからの目標はMLOpsを強化すること ――「レコメンド基盤」の紹介と、今後実現したいことを教えてください。 内藤: 今回「タップル誕生」でも活用したレコメンド基盤は「ABEMA」「Amebaブログ」など様々なサービスに対して推薦機能を提供する基盤となっています。 レコメンド基盤ではサービスの多種多様な要望に向き合い、新規サービスの導入コストや運用コストの削減を実現するために、汎用性を考慮したフレームワーク化を進めています。これにより共通部分の処理を再利用できたり、モデル学習時や推論時の処理のパイプラインを設定で管理できるようになっています。 近年では種類の異なる様々なコンテンツをフィードとして一列に並べたいという要件が増えてきており、基盤としてどう吸収していくかということが求められているので、今年はこの課題に向き合いたいと思っています。 また、 MLOps についても強化をしていくつもりです。MLOps は継続的に機械学習モデルの学習とデプロイを行うための方法論とその基盤を表しており、「秋葉原ラボ」全体でも注力している分野になります。具体的にはモデルの管理方法やサービング周りの標準化を進めることで、開発者が本質的な改善作業に集中できる環境を整えていければと思っています。 「タップル誕生」については、アルゴリズムを継続的に改善していきたいです。直近では今年リリースされた趣味タグのデータやユーザのプロフィール画像のデータを活用して、よりリッチな推薦機能を提供していきたいと考えています。   「Love Tech(ラブテック)ラボ」とは オンライン恋活・婚活マッチングサービスの市場の発展に寄与することを目的に、その関連する調査を行う専門組織です。様々なテーマで意識・実態調査を行い、恋活・婚活の手段の一つとしてマッチングサービスの可能性を社会に届けることで、日本が抱える社会課題、未婚率の上昇や少子化問題の解決に取り組んでまいります。   趣味でつながるマッチングアプリ「タップル誕生」について マッチングアプリ「タップル誕生」は、スマートフォン向けマッチングサービスとして2014年5月にサービスを開始いたしました。グルメや映画、スポーツ観戦など、自分の趣味をきっかけに恋の相手が見つけられるマッチングサービスとして、20代の若い男女を中心にインターネットに慣れ親しんだ世代からの支持を受け、会員数500万人突破、「タップル誕生」を通して成立したマッチング数は延べ2億組と、国内最大規模のマッチング数となります。2020年4月1日より「オンラインデート」を推奨するプランを公開し、オンラインデートで使いたいマッチングアプリNo.1※となりました。 ※2020年4月17日~4月20日の間、全国の18歳~30代男女2,000人を対象に実施した  […]

2020.07.30

タップル誕生「利用者の声」から生まれた機能

マッチングアプリ「タップル誕生」では、ご利用の皆様からいただいたご意見をサービスの運営に反映し、より安心・安全にご利用いただけるように改善に取り組んでおります。 ご利用のみなさまからのご意見をもとに生まれた事例を紹介します。   ご意見を取り入れるための仕組み ■ご意見をもとに施策を実現する「CREチーム」 タップル誕生には「CRE」と呼ばれるエンジニアチームがあります。「CRE」はCustomer Reliability Engineering(顧客信頼性エンジニアリング)の略で、会員からのご意見・お問い合わせ内容を踏まえて、その本人自身も気づいていない潜在的ニーズを探し当て、問題定義し、解決方法を考えることに向き合うチームです。   ■会員の声を日々チーム全員が目にする「ご意見フォーム」の設置 タップル誕生では、使い方がわからないなどの「お問い合わせ」以外にも、よりライトに感想をいただける「ご意見」フォームを設定しております。 こちらのフォームにていただいた内容は、タップル誕生の運営が全員見られるようなチャットツールに自動で流れてくるようになっており、日々ご利用のみなさまの声をもとに何が課題なのか、どういう解決策があるのかなどを運営チームが議論しています。 ■CSチームと連携した月1回のVOC(Voice Of Customer)レポートの共有 会員からいただく「お問い合わせ」の内容をもとに、カスタマーサポートチームが月に1回お問い合わせ内容を分析したレポートを作成し、運営チームに共有しています。 例えばその月に公開した新機能について、どういった会員の方からどんなお問い合わせが届いたのかなどを分析し、原因を考え、次の一手につなげていく動きを行っています。     ご意見から生まれた事例 メッセージ画面の色変更 利用者からのご意見 人前でタップル誕生を開くとマッチングアプリだとバレてしまって開きづらい 設定からメッセージの色を変更できるようにしました。 ベーシックを選択するともとの色合いのピンク色となりますが、グリーンやブルーなどお好きな色をお選びいただくことで、抵抗感なくご利用いただけるようにと考えました。   ■マッチングする前にお相手を非表示に 利用者からのご意見・知り合いが出てきた際に自分を表示させたくない ・知り合いを見つけたときに相手から表示されないようにしてほしい 知り合いを見つけた際に、「相手に表示しない」を選べるようになりました。こちらを選択すると、お相手の画面に表示されなくなりますので、もし知り合いなどを見つけた際にご自分を表示させたくない場合にご利用いただけます。        ■こだわり条件のチュートリアルを追加 利用者からのご意見お相手を居住地や年齢などで絞り込めるようにしたい もともとタップル誕生には、お相手を居住地や年齢などお好きな条件で絞り込むことができる機能があるのですが、その機能が会員の方にうまく伝わっておらずお問い合わせをいただくことがありました。 それを受けて、登録後のアプリの使い方を説明するチュートリアルの際に、どこからこだわり条件で検索できるのかを追加してわかりやすくすることにしました。     ■退会時の自動更新停止導線 利用者からのご意見退会したのに月額プランの自動更新が解約されていない タップル誕生を退会することと、月額プランの自動更新を停止することは異なる作業となりますが、その違いがわかりづらいというご意見を多くいただいていました。それを受け、退会時に有料プランの期間が続いている方にはプランの自動更新を停止するかどうかを確認する画面をはさむことで、月額プランの自動更新に気づかないまま退会することがないようにしています。       今後も「タップル誕生」では、ご利用の皆様からいただいた声に耳を傾け、安心して恋活・婚活をしていただくために機能追加など積極的にサービス開発を行ってまいります。   ■「タップル誕生」安心・安全の取り組みについて https://www.cyberagent.co.jp/way/info/detail/id=20561

2020.07.10

【技術勉強会】Matching Dev Meetup#1 – iOS / Android開催のお知らせ

この度、マッチング業界のアプリ開発に携わるエンジニアによるミートアップを開催いたします。 Matching Dev Meetup#01と称して、第一回目となる今回は マッチング業界のアプリ開発に携わるiOS / Androidエンジニアによる、技術・知見を共有するミートアップです。 マッチング業界のアプリケーション開発を行っている方 、 マッチング業界のアプリケーション開発に興味がある方、 iOS / Androidの技術に興味がある方、ぜひ奮ってご参加ください!マッチング業界以外のエンジニアの方のご参加も歓迎しています。 イベントのお申込みはこちら イベント詳細 https://matching-dev-group.connpass.com/event/104675/ ・開催日:2018年11月14日(水)19:00受付開始 19:30スタート ・場所:株式会社サイバーエージェント 渋谷プライムプラザ4F クリエイティブラウンジ ・参加費:無料 会場へのアクセス 株式会社サイバーエージェント  クリエイティブラウンジ 東京都渋谷区円山町19番1号 渋谷プライムプラザ4F https://www.cyberagent.co.jp/access_print/id=7037 GoogleMap ※ エレベーターにて直接4Fまでおあがりください。 注意事項 ・技術交流が目的の勉強会ですので、知識の共有および、参加者同士の交流を目的としない参加はお断りしています。 ・参加目的が不適切だと判断される場合には、運営側で参加をキャンセルさせていただく場合がございます。 ・会場は禁煙となっております。

2018.10.22

【技術勉強会レポート】CA.io #1「マッチングサービスを支えるElasticsearch」

河野 智則 「タップル誕生」リードエンジニア 2011年サイバーエージェント中途入社。サーバーサイドエンジニアとして、コミュニティサービス「アメーバピグ」や「ピグライフ」の運用・開発を担当したのち、オンラインRPG「ピグブレイブ」、美少女バトルRPG「オルタナティブガールズ」等ゲーム事業の立ち上げに従事。 2016年7月に株式会社マッチングエージェントに出向後は、同社のリードエンジニアを担当 みなさま、こんにちは。マッチングエージェントの河野です。 筆者は毎年かかさず夏フェスに行くのですが、今年は都合がつかずで参戦できず、”まだ夏が終わっていない”と感じてしまう今日この頃です。 さて、そんな中(?)、9/11(月)にCA.ioの第一回を実施いたしました。当日は100名を超える方に足を運んでいただき、ありがたいことに満員御礼となりました。 今回はこの勉強会の開催レポートを紹介したいと思います。 CA.ioとは CA.ioとは、サイバーエージェントのメディアサービスを運営しているエンジニアによる、エンジニアのための勉強会です。毎回特定の領域にテーマを絞って勉強会を実施する予定です。 第一回のテーマは”マッチングサービスを支えるElasticsearch”。 CAが運営しているマッチングサービスでのElasticsearchの活用ノウハウを発表しました。 また、当日はelastic社からDeveloper AdvocateであるJun Ohtani 様をゲストに迎えての開催となりました。 ゲストセッション Elasticsearch 6.0 is coming / Jun Ohtani ゲストのOhtani様からは現在(2017/09/22時点)、β版をリリース中のElasticsearch 6.0に関して発表をしていただきました。 _typeがDeprecatedになる。 5.xから6.xへのupgradeはこれまでと比べてかなり楽になる。 sort条件をindexのタイミングで設定が可能。 内部のLuceneが7にアップデートされている。 など、Elasticsearch 6.0の詳細について知ることが出来ました。 「これまで誤った使われ方をされることが多かった」という_typeがDeprecatedになり今後なくなる予定という話が特に印象的でした。 セッション タップル誕生がElasticsearchを導入した3つの理由 / Valverde Antonio なぜタップル誕生でElasticsearchを導入したのか、導入当時を振り返りながら発表してもらいました。 パフォーマンスの向上や複雑な検索の実現など、マッチングサービスとElasticsearchがいかに相性がよいかをわかりやすく説明してくれました。 位置情報を用いたElasticsearchの活用事例 / 川田 浩史 “すれ違い”機能が押しのCROSSMEからは、位置情報の活用事例についてです。 すれ違いをどう定義しているかからはじまり、緯度経度から住所を検索するための逆Geocoding、カバー画像を現在地によって変えるためのGeo Shapeの活用など、実践的な事例を紹介してくれました。 Elasticsearch活用&運用事例〜mimiの場合〜 / 矢崎 亮太 好きなタイプ(顔)で検索できるマッチングアプリ mimiからは、基本的な検索事例とインデックス再構築事例を発表してもらいました。 re_indexでは実現できなかったインデックス再構築を、アプリ側で同期ツールを用意して工夫するなど独自の運用をしているそうです。 […]

2017.09.22

「急成長スタートアップ x 技術的負債」タップル誕生 x Makuake 合同勉強会

2017年6月22日に、「タップル誕生」を運営する株式会社マッチングエージェントと「Makuake」を運営する株式会社サイバーエージェント・クラウドファンディング(現株式会社Makuake)のメンバーが集まり,勉強会を実施しました。 今回の勉強会のテーマは「急成長スタートアップ x 技術的負債」。 「タップル誕生」「Makuake」両サービスとも急成長中,日々様々な技術的負債と戦っているという状況が非常に似ていたこともあり,このようなテーマ選定となりました。   勉強会の開催レポートの様子は以下よりご確認いただけます。 「急成長スタートアップ x 技術的負債」タップル誕生 x Makuake 合同勉強会

2017.06.29

エンジニア発信の施策、“エンジサク“の取り組みについて

ヴァルヴェルデ・アントニオ 「タップル誕生」サーバーサイドエンジニア スペイン出身、現地の大学院を卒業後2013年サイバーエージェント新卒入社。入社後は基盤システムやソーシャルゲームの立ち上げ・運用に携わった後、2015年12月より株式会社マッチングエージェントに出向し、現職。 みなさんこんにちは! マッチングエージェントでサーバーサイドエンジニアをやっているアントニオです。 今回は、マッチングエージェントで実施しているエンジニア発案の施策「エンジサク」について、この記事で紹介します。 きっかけ これまで、エンジニア発案の施策アイデアはいくつかありましたが、実際に施策に落とし込むまでできていない課題がありました。 なぜこういう状態になっていたかを考えて、一因は下記だと判断しました。 そもそも提案する場がない。 エンジニアが提案する文化がない。 チームレベルでも正式に提案ができる場を作ると、上記の問題は解決すると思いました。その理由でエンジサクが生まれました。 また、私自身エンジニアとして新しいチャレンジを求めていたこともありました。個人的にいつも同じことをやるより、色々チャレンジするほうが好ましいです :)。 エンジサクのメリット メリットは大きく三つあります。 1. 名前をつけることでエンジニア発信の施策を促進させる きっかけに書いた通り、提案ができる場が存在するだけで、エンジニア側で提案をする文化は自然に現れます。みんなで施策を考えることが当たり前のことになるのが重要だと思っています。 2. エンジニア目線でのアイディアが出せる エンジニアとプランナーとでは、これまでの社会人としての経験や文化が違うので、思い付くアイディアが異なると考えています。もちろん、エンジニアとプランナーとでどちらのアイディアが優れているという話ではなく、単純にサービスには色々な目線があったほうがいいということです。 3. システムに理解があるため、コスパの良いアイディアが出しやすい エンジニアはシステムの知識を持っているので、自然と低い工数で成果が出せる施策を考えることができます。また、パフォーマンスや実現性を考慮して施策を考えられることもメリットだと思います。 フロー エンジサクの提案からリリースまでの流れは以下の通りです。 提案の準備 提案するまで、下記のようなステップがあります。提案するのに沢山の時間を使うのはあまりよくないと思うので、シンプルにやることが重要です。 ネタ探し : どういう施策をやりたいかを考えること。MTGやユーザの声やたまたま見かけたコードや色々なところからヒントがもらえる。 他のメンバーと相談する : もしやることになったら、それぞれ必要になりそうな担当と相談する。例えば、デザインやクライアントの対応が必要になる施策ならそれぞれの担当に相談する。 データ分析を軽くする: チームで追っているKPIが重要なので、データアナリストが簡単に取れるデータなら頼む。難しいようであれば、相談だけでも大丈夫。 提案書を作成する : シンプルにテキストに書く。基本的に入れる項目は概要、KPIへの影響、そのほか懸念事項、工数など。 提案 作成した提案書を使って、プロデューサーに提案します。プロデューサーと認識を合わせて、提案の内容は変更や調整を行うこともあります。 ジャッジは下記のポイントで行います。 工数・インパクト : コスパのこと。工数に対して予想したインパクトを検討する。 タイミング: タイミングも検討する。他の施策とかぶったり、リソースが足りてなかったり、など。 リリースまでの作業 提案した施策がやることになったら、それで終わりではありません。自分がその施策を実装することになった場合でも、ならなかった場合でも、リリースまでフォローするべきです。主に下記です。 資料を作成 : 資料の作成等を引き継ぐこともある。 KPI設計: データアナリストとプランナーとともにKPI設計する。 責任を持つ : 関わるメンバーをフォローして、デザイン、クライアント、サーバーまで品質担保する。進捗確認、リリース直前の最終操作や資料の確認などのこと。 リリース後の作業 […]

2017.05.30

位置情報を使った「すれ違い」機能の実装 [server]

川田 浩史 「CROSS ME」エンジニアリーダー兼スクラムマスター 2011年サイバーエージェント新卒入社。入社後は、サーバーサイドエンジニアとして数々のコミュニティサービスやソーシャルゲームの立ち上げ・運用に携わる。2015年11月よりグループ会社の株式会社プレイモーションに出向し、現職。 CROSS MEというアプリのサーバーサイドを担当している川田です。 iOSの記事の続編的立ち位置で書かせていただきます。 サービス概要 CROSS MEは、すれ違いを恋のきっかけにしてもらうためのカップリングサービスです。 このアプリでは、すれ違いがサービスのキモなので、極力ユーザーにストレスのないすれ違い体験をしていただけるように設計しています。 本記事では、CROSS MEのメイン機能のすれ違い機能の概要を紹介させていただきます。 CROSS MEにおける「すれ違い」の定義 まずはCROSS MEにおける「すれ違い」の定義を説明します。 CROSS MEではすれ違い機能を実現するためにGPSを採用しています。 一般的にすれ違いと聞くと、2ユーザー間の、時間軸に連続的な位置の情報を使って、一定距離の幅を持たせたときにぶつかった場所をすれ違ったポイントとすることを想像します。 一般的にすれ違いというと、上記のようなイメージを持つのではないでしょうか。 UserAとUserBにそれぞれ幅を持たせて、ぶつかった場所(赤い部分)がすれ違いポイントとなります。 しかしGPSのデータは常に送信されているわけではなく、特定の間隔で送信されるので、時間・緯度・経度がセットになった点のデータになります。 点のデータのみでは上記方法は実現できないため、別の方法を採用する必要があります。 いくつかやり方が考えられますが、CROSS MEでは、最後に送った位置情報の地点に一定時間滞在しているものとし、時間、距離の2軸について一定の幅を持たせてすれ違い判定をしています。 CROSS MEにおけるすれ違いのイメージは上の図のようになっています。 UserCとUserDはそれぞれ、特定のタイミングで位置情報を送信します。 UserCは15:30以降位置情報を送信していませんが、しばらくその地点に居続けると推定し、15:45にUserDが位置情報を送ったタイミングですれ違い発生としています(時間は分かりやすく入れただけなので、実際の挙動は例とは異なります)。 すれ違い処理概要 それではCROSS MEのすれ違い処理の概要を説明していきます。 構成としては、大きく3つのフェーズに分かれています。 位置情報取得: Kinesisで位置情報を受け取る すれ違い判定: Lambdaですれ違ったかどうか判定 すれ違い履歴の保存: DBにすれ違った履歴を保存 という構成ですれ違い判定を行っています。 すれ違い処理部分を簡素化した図です。 それぞれをもう少し詳しく説明します。 位置情報取得: Kinesisで位置情報を受け取る クライアントから、特定のタイミングで位置情報を送信してもらっています。 Kinesisは複数シャードで運用しており、CROSS MEアカウントとKinesisシャードの紐付きは変わらないように設計しています。 シャード分割について、投げるデータと割り当てられるシャードの関係が分かりづらかったので、別の記事で自分なりにまとめてみました。興味がある方は見てみてください。 Kinesisの役割は、クライアントに投げてもらった位置情報を時系列に保持しておくだけです。 以下はKinesisで受け取ったレコード数を時系列に並べたグラフです。 平日にKinesisが受け取ったレコードと、 休日にKinesisが受け取ったレコードです。 CROSS […]

2016.12.12