機械学習を記事配信に採用したママリ - 0から構築したレコメンドエンジンのアーキテクチャ設計
コネヒト株式会社が運営する女性向け情報サービス「ママリ」では、2019年12月に記事配信で機械学習によるレコメンドエンジンを構築、2020年初頭にテストが完了しました。 機械学習を採用した背景、設計したアーキテクチャとテストの結果について伺いました。
コネヒト株式会社が運営する、女性を対象とした情報サービス「
ママリ」は、2014年のリリース以降、着実にユーザーを増やし、2020年3月現在、アプリ会員数は240万人（日本で2019年に出産した中で3人に1人が利用）、ママたちが集まるオンラインコミュニティとして定着しています。
ママリでは2019年12月、サービス内に掲載する記事の配信について機械学習を採用したレコメンドエンジンへ変更し、2020年初頭にテストが完了、いよいよ正式リリースとなりました。
機械学習を採用した背景、設計したアーキテクチャとテストの結果、そして今後の展望について、コネヒト株式会社執行役員CTOの伊藤翔さん、機械学習エンジニアの野澤哲照さんにお話を伺いました。
- 伊藤 翔（いとう・しょう／写真左）
- コネヒト株式会社 執行役員CTO
1986年生まれ、慶應義塾大学卒。学生時代からプログラミングに興味をもち金融系のSIerに新卒入社。その後、Web系の受託会社を経験する中で、自社サービスをつくりたいと思うようになり、Supershipに入社。2017年にグループ会社であったコネヒトに出向し、「ママリ」のAPI開発や「ママリプレミアム」の立ち上げを経験。リードエンジニアや開発部部長を歴任し、2019年6月にCTOに就任。 - 野澤 哲照（のざわ・たかのぶ／写真右）
- コネヒト株式会社 機械学習エンジニア
新卒でSlerに入社。主に薬品や食品などを扱うメーカー企業向けのERPパッケージを扱い、要件定義から開発・導入・保守まで幅広く経験。2019年3月に機械学習エンジニアとしてコネヒトに入社。機械学習（NLP・推薦システム）のモデリング・API開発をメインとしつつ、インフラ（AWS）も勉強中。
“ママの一歩を支える”サービスとして
――ママリはどのようなサービスでしょうか？
伊藤 「ママの一歩を支える」をブランドミッションとした、女性向けのQ&Aアプリ・情報サイトです。「ママに寄り添う」をモットーに、日本全国のプレママ・ママに役立つさまざまな情報を発信し、専門性の高い医学的な記事については専門家の監修を付けてお届けしています。
2014年のサービス開始以来、“スマホファースト”で開発を進めてきました。その後、順調にユーザー数が増えていったのですが、2018年2月にテレビCMを公開して一気に認知度が上がり、2020年2月現在、アプリ会員登録数は240万人となり、その年に出産をしたママ3人のうち1人にご利用いただけている規模感まで成長しています。
コネヒト株式会社によるアプリ会員数の資料
――現在の開発体制はどれくらいの規模ですか？
今の体制は、プロダクト開発のエンジニアが8名ほど、今回お話しする機械学習およびインフラを横断的に見るエンジニアが2名です。
レコメンドエンジンアップデートの舞台裏
ルールベースでの限界を感じた
――それでは、新機能の目玉である記事配信のレコメンドエンジンについて詳しく教えてください。まず、どのような背景で機械学習の採用を決めたのでしょうか？
野澤 私たちが考える理想の記事配信方法は、「検索しなくても、その時ユーザーが欲しい情報をお届けできること」です。検索するには検索のためのキーワードが必要になります。サービスの成長とともに記事数も増加してきており、ユーザー自身の考え方や前提知識によっては、本来欲しい情報にたどり着くことが難しくなってきています。
加えて「子育て層のユーザー」という切り口1つとっても、0才児と2才児のママでは、悩みや欲しい情報がまったく異なります。
このような背景から、これまで人的に行っていたルールベースでの記事配信に対し限界を感じていました。それが、機械学習を採用したレコメンドエンジン開発のきっかけです。
機械学習が与える「気持ち悪さ」を防ぐ
――採用に当たって課題などはなかったのでしょうか。
伊藤 野澤が申し上げたように、ユーザー数の増加、記事数の増加、そして、世の中の変化に合わせて、アイデアを出し合い、議論しました。その中でルールベースのまま進めていくことも考えとしてはありましたが、そうすると、新しい要件が増えるたびにif文を増やす……なんていうことになりかねません（苦笑）。
また、すでにカスタマーサクセスチームによるコミュニティ運営では、運用コスト削減の観点から機械学習を利用し、一定の成果が出ていました。単純なルールベースの運用を機械学習に置き換えて成功している事例も増えてきており、今後サービスをグロースさせるため機械学習を活用することは必要不可欠だと判断して、導入に踏み切りました。
伊藤 翔さん
伊藤 一方で、機械学習をはじめ、AIに関する技術はコモディティ化してきているものの、実サービスに導入してみないと分からないことも多いと思います。例えばユーザーが住んでいる場所の近くの情報ばかりがレコメンドされるなど、自分としては何も入力していないのに極端に先回りされた情報が届くと、「気持ち悪さ」を感じさせてしまいます。
機械学習を採用するに当たって、この「気持ち悪さ」を感じさせないためにはどうするか。これを最初の課題の1つとして開発を進めました。
行動ログ、クラスタ、ユーザー属性による構造化
――世の中の流れ、技術の進歩、そして、ママリが目指す理想形、それらを組み合わせた結果としての機械学習型レコメンドエンジンの開発がスタートしたわけですね。それでは、実際にどのようなアーキテクチャで設計をしたのか、詳しく教えていただけますか。
野澤 プロダクション環境では、下記のような構成に切り替えました。Step Functionsで囲まれた部分が機械学習ワークフローです。
野澤 ママリのアプリでは、ユーザーひとりひとりの行動ログがBigQueryに蓄積されています。そこから「行動ログ取得バッチ」を使って構造化前の生データを集計・加工し、機械学習で扱えるデータ構造に変形した上で、一度ストレージに保存します。そのデータを「クラスタ単位」と「クラスタ×ユーザー単位」の2種類に分け、推薦記事を計算しています。
ここでいうクラスタとは、あるルールに基づきユーザーをハードクラスタリングしたものを指します。
レコメンドエンジンを構築する際、まずはデータの理解を深めるためにログの分析を行いました。その結果、ユーザー属性単位で閲覧する記事の種類についてある程度偏りがあることが判明し、その結果をもとにユーザーを10種類ほどのクラスタに分類しました。
上図のクラスタ単位における計算部分では、以下のようにクラスタ粒度でRatingテーブルを作成し、推薦記事を計算しています。こうすることで、新規ユーザーに対してもある程度嗜好性を考慮した記事を推薦できるようにしています。
クラスタ単位の推薦記事計算例
野澤 一方、ユーザー単位の計算部分では、ユーザーごとにそれぞれのクラスタ内で推薦記事を計算しています。
クラスタ×ユーザー単位の推薦記事計算例
野澤 これら2種類の単位で計算された記事をデータベースに格納し、その中から記事を配信するという仕組みです。
伊藤 機械学習を含むバックエンドは、すべてAWSを利用しています。BigQueryから取得し加工したデータの格納先にはAWS S3を、推薦記事の格納データベースにはAmazon DynamoDBを、そして、各種機能はすべてAWS Fargate（コンテナ）による、サーバレスアーキテクチャで構築しています。
登録のメリット