目次

巻頭言「持続的な研究開発組織に向けて」

1

秋葉原ラボのあゆみ

2

1 大規模データ処理システム

3

1.1

データ処理基盤 Patriot における継続的改善の取り組み

4

1.2

メディアサービスにおける検索システム基盤の構築と運用

12

1.3

リアルタイムのデータ活用を支援するストリーム処理エンジンの開発

17

2 機械学習システム

26

2.1

大規模リアルタイムレコメンデーションを支えるスケーラブルなシステム基盤の構築

27

2.2

直積量子化に基づく高速な類似文書の探索

32

3 データ分析37

3.1

インターネットテレビサービス AbemaTV におけるユーザアクティビティ分析

38

3.2

音楽ストリーミングサービス AWA における聴取傾向変化の分析

44

3.3

Web 社会の科学

51

発表一覧

59

1

巻頭言「持続的な研究開発組織に向けて」

秋葉原ラボ 研究室長 福田 一郎

2011 年 4 月にサイバーエージェントの研究開発組織を秋葉原の地に設立して，丸 7 年が経とうとしている．
この時に至って初めて秋葉原ラボとしての技術報告書を作成するのは「遅いのではないか？」と思われるところであろう．
言い訳をさせてもらえば，私達のラボは一般的な研究
開発組織とは異なり，インターネットメディアを対象とした大規模データの利活用を主軸としており，メンバー
も初期は研究者というよりは開発者ばかりであった．そのためアウトプットは全般的にシステムやライブラリという形で，実際にインターネットメディアサービス内で利用されることに重点を置いていた．そのため，まとまった報告書をアウトプットするよりは，それぞれのシステムの実用性などの報告を個々に行ってきた経緯がある．
しかし，会社の規模も拡大し，部署・社員数が増えてくると，秋葉原ラボが何をやっているのかが見えづらくなり，部署内の知見も暗黙的になってきていると感じることが増えてきた．
そこで，社内外に知見を共有し，さらには将来の秋葉原ラボへ知見を残していくべく，秋葉原
ラボの現在の技術状況を報告書としてまとめることとした．
多少の改変や改称はあれど，7 年間単独の部署として存在しているというのは，移り変わりの激しいインターネット業界にある当社においてはかなり稀な組織であるといえる．しかし，そもそも根幹をなす技術というのはサービスやプロジェクトの盛衰に左右されてはならず，そのためにも研究開発組織を持続的な形で維持することは重要であるという考えのもと，私は秋
葉原ラボとその活動に取り組んできた．
この技術報告書はインターネットメディアサービスにおけるデータ活用のために何が必要
で，そのために私達が何に取り組んできて，どう発展させてきたのかを著したものになる．報告書という形でまとめることによって新たな示唆や発展を見出し，多くの人々と知見の共有および議論ができるようになり，さらなる秋葉原ラボの持続性につながることを期待している．

2

秋葉原ラボのあゆみ

秋葉原ラボ 研究室長 福田 一郎

秋葉原ラボは 2011 年 4 月に JR 秋葉原駅前にある秋葉原ダイビル内に開設された Ameba

Technology Laboratory を前身組織としている．「なぜ秋葉原に作ったのか？」という問いを受けたことは何度となくある．その問いに対する明確な答えは存在しないのだが，どのようにしてラボができてきたかを見ていくことで，答えに類するものは見えてくるだろう．

Ameba Technology Laboratory ができる 2011 年より以前，2009 年頃にさらなる前身組織であるインキュベーションラボラトリという部署が存在した．そこでは原初的なブログコメントのスパムフィルタシステムやブログ閲覧履歴からの芸能人ブログ推薦システムなどを提供していた．また，同時期にブログ全文検索システムも既に内製で存在していた．
さらに 2010 年 3 月からはモバイルゲームなどを中心にユーザ課金のメディアサービスが増加することを見込んで，ユーザ行動ログを分析する基盤が必要であるという考えから

Hadoop/Hive をコアコンポーネントとするログ集計・分析基盤 Patriot の開発が始まった．
これらのデータを活用したシステムを対象に 2010 年夏季学生インターンを実施したところ好評であり，またインターネットサービス企業としてはデータ活用が強みに繋がるという議論から，データ活用を主軸とした研究開発組織があったほうが良いという議論に発展していった．
単に組織を作るだけでなく，サービスとは切り離されたところで集中する環境と斬新さを出すためにも場所を渋谷ではない場所にということでオフィスの場所が秋葉原になった．

2011 年 4 月に秋葉原にラボを開設し，2014 年 10 月に Ameba 事業本部の改変に伴い名称をAmeba Technology Laboratory から「秋葉原ラボ」へと変更し，現在に至っている．オフィス
も当初は秋葉原ダイビル 8 階にあったが，社員数の増加によって現在は 13 階へと増床移転している．
ラボができるまでの経緯からも，データ集約・集計するデータ分析基盤を中心に機械学習シ
ステム構築やデータ分析，当初から引き続きブログの全文検索を中心に各種検索システムを主な対象としている．メディアサービスの発展に伴い，データの種類も増加し，当初のアクセス
ログや行動ログだけでなく，現在はサービス内の画像や音楽情報データなども対象となってき
ている．

3

1. 大規模データ処理システム

現在，インターネット上でサービスを運営する上でデータを活用することの重要性が増している．データの活用によって，ユーザの行動ログや Web サイトへのアクセスログを分析することで適切なサービス改善につなげることや，検索・推薦などのサービスの価値を高める機能を実現できる．また，近年はインターネット上の広告配信などでもデータ活用により品質を向上させることが求められている．
当社では Ameba ブログや AbemaTV など様々なインターネットサービスを運営しており，
それらの改善にデータ活用が重要となっている．例えば，Ameba ブログは国内最大規模のブロ
グサービスであり，当社の提供するサービスは多くのユーザに利用されている．このため関連するデータの量も膨大となり，大規模データを効率的に処理するシステムが必要となる．
秋葉原ラボは当社のメディア事業におけるデータの有効活用を目的としており，そのために様々な大規模データ処理システムを開発し，運用している．大規模データ処理の分野は技術の進歩が著しく，またネットサービスは機能改善などが頻繁に行われる．このような変化の多い環境では，システムの開発から運用までを一貫して行い様々な要件に対して柔軟に適応することが重要と考える．
大規模データ処理の分野では様々な技術が提案されており，OSS やクラウドサービスとして実装されているものが多い．そこで秋葉原ラボでは最新の OSS の導入や様々なクラウドサー
ビスとの連携を視野にいれてシステム開発を行っている．また，ストリーム処理など要件が多様で標準的な実装が提供されていないものについては，独自のシステムを研究開発し，実用化している．
本稿では，秋葉原ラボにおけるシステム開発の例として以下を紹介する．まず，当社のデー
タ解析基盤において最新の OSS やクラウドサービスを活用しながら継続的な改善を実現するための取り組みについて 1.1 章で述べる．1.2 章では，様々なサービスに検索機能を提供する
ための検索基盤システムについて解説する．最後に，1.3 章では，当社のメディアサービスにおける広告配信などに利用されているストリーム処理エンジンを紹介する．

4

1.1

データ処理基盤 Patriot における継続的改善の取り組み
梅田 永介，飯島 賢志，斎藤 貴文

概 要 秋葉原ラボでは当社が提供するメディアサービスのデータを有効活用するためのデータ処理基盤の開発・運用を行っている．大規模データ処理の分野は技術の進歩が著しいため，オープンソースソフトウェ
ア (OSS) やクラウドサービスをうまく活用していくことが重要となる．本稿では Patriot を継続的に改善していくための，OSS 活用や他システムとのデータ連携などの取り組みについて紹介する．

Keywords

データ処理基盤，データ管理，OSS

1 はじめに本稿では，最新の OSS の導入やパブリッククラ
ウドなど他システムとの連携により，データ処理

当社のメディア事業では AbemaTV や Ameba

基盤 Patriot を継続的に改善していくための取りブログなど多種多様なサービスを提供しており，組みについて記述する．2 節では Patriot の概要

ユーザの行動ログなど様々なデータが大量に発生を示す．3 節では継続的なソフトウェアアップグ

している．このようなデータの活用はサービスのレードを行うための取り組みを，4 節では様々な改善にかかせなくなっており，秋葉原ラボでは大他システムとの連携を実現し，データ品質を改善量のデータを管理，処理するためのデータ処理基盤

するためのログ転送管理システムについて説明す

Patriot の開発・運用をおこなっている．Patriot

る．また，5 節では機能改善の例として Massive

はメディア事業の様々なサービスにおいて，各種

Parallel Processing (MPP) やカラムナストレー

レポートの作成やレコメンデーション機能の実現

ジの導入について説明し，6 節ではまとめと今後に活用されている．

の取り組みについて述べる．

大規模データ処理の分野は技術の進歩が著しく，
またオープンソースソフトウェア (OSS) やクラ2 データ処理基盤 Patriot の概要

ウドサービスとして利用可能になるものも多い．
データを有効活用するためには，最新のツールや

図 1.1.1 にデータ処理基盤 Patriot の概要を示

手法を効率的に取り込むことが重要となる．そこす．Patriot は Apache Hadoop などの OSS を利で，秋葉原ラボでは日々進化する OSS の新しいコ用して構築された分散システムであり，当社のメンポーネントや最新バージョンを効率的に調査・ディア事業のデータを収集し，各種レポートの生導入するための環境整備や運用改善を進めている．

成やレコメンデーションのためのデータ処理など

また，クラウドサービスとの連携を効率的に行うを行っている．

ためのデータ転送管理ツールや WebUI などの開発を行っている．

図 1.1.2 に Patriot のソフトウェア構成を示す．
サービスから生成されたデータはデータ転送機能

2 データ処理基盤 Patriot の概要

5

図 1.1.1 データ処理基盤の概要

図 1.1.2 Patriot のソフトウェア構成を利用して収集され，ストレージに格納される．

クで処理される．Patriot は社内の様々な部署とパブリッククラウドやレコメンデーション基盤な

連携しているため処理すべきバッチジョブも多様

ど他のシステムとの連携を柔軟に行うために，独であり，複雑な依存関係を管理する必要があるが，自の転送管理システム (Mine) を導入している．

内製のワークフロースケジューラによりこれらのMine では Apache Flume のプラグイン機構など

依存関係をワークフローとして管理している．

を用いてデータの内容に応じたルーティング設定を実現している．

リソース管理機能は分散処理フレームワークが使用するリソースを管理し，リソースを最大限に

ストレージに格納されたデータはワークフロー

活用できるように各処理にリソースを割り当てる．

スケジューラ [2] に従って分散処理フレームワー

レポーティングのための集計結果はデータストア1.1 データ処理基盤 Patriot における継続的改善の取り組み

6に保存され，BI・分析ツールを通じてユーザに利用

Patriot でもベンダ提供の OSS パッケージを利用される．秋葉原ラボでは，Patriot に蓄積したデーしていたが，以下のような問題があり継続的なバー

タを活用するために Patriot FDC という WebUI

ジョンアップを行うには不十分な状況にあった．

の開発もおこなっている．

• ソフトウェアの組み合わせやバージョンがコーディネーションサービスは，ストレージ，限定されており，新しいソフトウェアを追

データストア，分散処理フレームワークの高可用加で導入したり，特定のソフトウェアのみ性を実現するために用いられている．

バージョンアップすることができないため柔軟性に欠ける

3 継続的なシステム改善のための取り• 標準的なテスト環境での動作確認は行われ組みているため，ある程度の品質は保証されてはいるものの，Patriot と同等のデータや動

大規模データ処理の分野は技術の進歩が著しく，作環境でのテストではないため不具合を十継続的に新しいソフトウェアの導入やバージョン

分に検出できていない可能性がある

アップを行わなければシステムの陳腐化を避ける• ベンダ側の独自の修正によりソースコード

ことができない．システムの陳腐化により，先進が大幅に変更されている場合があり，バグ的な機能への対応が遅れることにもつながる．

が発生した場合にバグトラッキングシステ

Patriot が利用している Apache Hadoop やそのムや GitHub などで公開されているパッチ

周辺システムは，複数のソフトウェアで構成されを適用するのが困難であるており，それらの組み合わせによって正しく動作
しないこともある．ソフトウェア構成の検証や標これらの問題を回避するため，Patriot では，

準的な動作確認をしたものをベンダが OSS パッ

Apache Bigtop *1 を利用して OSS パッケージをケージとして提供しており，これらを利用するの内製して利用している．Apache Bigtop は OSSが一般的になっている．Patriot でもベンダ提供

ビッグデータコンポーネントのパッケージング，の OSS パッケージを利用していたが，一部のソテスト，設定などを行うための OSS である．主要フトウェアのみバグがあった場合のパッチの適用

な Linux のパッケージを作成するための設定ファやバージョンアップが難しかったため，OSS パッ

イルや，デーモンプロセスを起動するためのスクケージを内製することでこの問題を解決した．まリプトが含まれており，Bigtop を用いることで導た，システムの品質を保証するためのテスト環境

入が容易なパッケージを作成できる．また，設定を整備することで，新しいソフトウェアの導入やファイルで利用するバージョンをソフトウェアごバージョンアップで発生しうる問題を事前に検知とに設定でき，パッチの管理もできることから目できるようにしている．

的に応じたパッケージの作成が可能である．

Patriot の内製 OSS パッケージでカスタマイズ
3.1

OSS パッケージの内製化

ベンダ提供の OSS パッケージを利用する場合，されたパッケージとしては，例えば以下のようなものがある．

先進機能のバックポートやベンダ独自の修正によりある程度の品質が保証されていたり，OSS パッ
ケージを構成するソフトウェアの組み合わせの検証も行われているという利点がある．そのため，*1 http://bigtop.apache.org/*2 https://issues.apache.org/jira/browse/HIVE-15239• Apache Hive 2.1.1
HIVE-15239*2 などの処理結果が不正となるバグの修正を適用

4 データ転送管理• Apache Hadoop 2.8.1
YARN-5807*3 などローカルキャッシュを削

7
ための環境として小規模なサンドボックス環境を運用している．

除しないバグの修正を適用• Presto 0.190
Apache Kafka の新しいバージョンとの互換性がない問題*4 を修正
この他にも，OSS に新機能やバグ対応に関する情報収集・管理を効率的に行うための手法 [5] についても取り組んでいる．

4 データ転送管理
当社の Web サービスから生成されるデータはレポーティングやレコメンド機能など，様々な用
途で活用できる可能性がある．用途に応じて SLA
や管理部門などの違いがあるため，データの転送先を柔軟に設定できる必要がある．

システムの品質を保証するための取り組み

秋葉原ラボでは，この目的のために独自のデー

継続的に新しいソフトウェアの導入やバージョ

タ転送管理システム Mine を開発している．Mine

ンアップを実現するためには，システムの品質保は転送されるデータのヘッダ情報に転送設定を付証が重要な課題となる．そのためには本番環境と与することでデータの転送先を制御する．転送設

同等のデータやシステム構成を用いて動作確認を

定はデータベース上で管理され，管理ツール（図行うのが理想的である．そこで Patriot では，図1.1.4）を用いてブラウザから変更できる．また転1.1.3 に示すように本番環境と同等のデータをス

送先ごとに転送データのフィルタリングや外部

テージング環境にも転送し，本番環境になるべくAPI による情報の付与なども設定可能である.

3.2近い状態でテストができるようにしている．

Mine のほぼ全てのデータは Patriot に転送さ本番環境と同規模のステージング環境を用意す

れ，一つの Hive テーブルに格納される．他にはレることはコスト的に困難であるが，アクセスログ

コメンデーションやストリーム処理など準リアルの集計など他のサービスで提供している機能で確タイムのデータを必要とする集計システムや他部

認できるものに関してはサンプリングし，アクセ

署でデータを必要とするシステム等に転送を行う．

ス頻度の低い過去のデータの削除などを行うなど

オンプレミスやパブリッククラウドなど様々なの工夫により本番環境と同等のスペックのサーバ環境に対応するために Mine では様々な転送方法

構成で，かつ同等の定期バッチの実行を実現してをサポートしている．たとえば，オンプレミス環

いる．また，新しいソフトウェア導入やバージョ境におけるデータ転送には Flume の利用を推奨

ンアップ時の動作確認を効率的に行えるようにししている．AWS や GCP などのクラウド環境をている．

利用して Web サービスを構築・運用するケース

この取り組みにより，ステージング環境での新では Amazon Kinesis Streams や Google Cloud

しいソフトウェアの導入検証やバージョンアップ

Pub/Sub などクラウドネイティブなサービスが利検証で，ソフトウェアの互換性などの問題を事前用される．スマートフォンの SDK のようなストに検知することが可能となった．5 節で紹介する

レージやネットワークに制約が有る環境に対して

Apache ORC を検証する際にもステージング環境

HTTP のエンドポイントを用意している．

で本番環境と同等のデータを用いて動作確認を行

スマートフォン向け SDK などのネットワーク

い，本番環境に適用する前に問題を検知すること

接続が不安定な環境のデータ転送は，転送されるができた．

までの最大遅延時間が決定できないため，データ

また，各サービスが転送するデータを確認する*3 https://issues.apache.org/jira/browse/YARN-5807*4 https://github.com/prestodb/presto/pull/8394のべき等性を実現することがむずかしい．そこで，

1.1 データ処理基盤 Patriot における継続的改善の取り組み

8

図 1.1.3 Patriot の各環境

図 1.1.4 ログ転送設定の管理

Mine では Google の DataFlow Model [1] などの先に到達した時刻（Arrival Time）を分けてあつ導入も進めている．

かう．これにより各ログの遅延時間を把握するこ

また，Mine ではログの品質を保証するためのロとができる．また，データを処理する際に Water-

グバリデーション機能を導入することでデータのmark という許容可能な最大遅延時間を設定する．

品質改善にも取り組んでいる．

Watermark を基準として遅延したログを集計に含めるかを判別することが可能になり，集計のべき

4.1

DataFlow Model の導入

等性を実現することが可能になる．

スマートフォン向け SDK などのネットワーク

Mine における Arrival Time は，Mine のスト接続が不安定な環境のデータ転送においては，最リーミング転送フローに到着した時点で付与され大遅延時間が決定できないという問題がある．スる．前述のスマートフォンのネイティブアプリのマートフォンのネイティブアプリにおけるオフラ

例で考えると，オンライン環境になり SDK からイン時に発生するログは一時的にアプリ内でバッログが送信され Patriot で管理している HTTP の

ファリングされ，オンライン環境になったタイミ

エンドポイントにログが到達した時点で Arrival

ングでまとめて転送をされるためである．このよTime を付与する．

うなケースでは転送先に届く時刻が，ログが実際

Arrival Time を考慮した集計の SQL の擬似に生成された時刻から遅延する．また，遅延の大

コードを記す．図 1.1.5 は 2017/1/1 のページビ

きさも対象のネイティブアプリがオンラインにな

ューを集計する HiveQL を簡略的に表したものでるタイミングに依存するため予測が難しい．

ある．このとき Watermark は 1 時間としている．

この問題を解決するために Google の DataFlow

WHERE 句の前半の部分 (行 4-8) は対象の集計期

Model [1] の導入を行った．DataFlow Model で間に Event Time が含まれるかを判別しており，は，ログが生成された時刻（Event Time）と転送

5 探索的データ分析への取り込み
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

9

SELECT count ( 1 )FROM t e s t t a b l e
WHERE
to unix timestamp ( event time )BETWEENt o u n i x t i m e s t a m p ( ” 2017−01−01T00 : 0 0 : 0 0 + 0 9 : 0 0 ” )ANDt o u n i x t i m e s t a m p ( ” 2017−01−01T23 : 5 9 : 5 9 + 0 9 : 0 0 ” )AND
to unix timestamp ( a r r i v a l t i m e )BETWEENt o u n i x t i m e s t a m p ( ” 2017−01−01T00 : 0 0 : 0 0 + 0 9 : 0 0 ” )ANDt o u n i x t i m e s t a m p ( ” 2017−01−02T00 : 5 9 : 5 9 + 0 9 : 0 0 ” )ANDa c t i o n t y p e = ” view ”

図 1.1.5 Arrival Time を考慮した PV の集計例

後半の部分 (行 10-14) では Arrival Time から導出される遅延が Watermark の範囲内に含まれているかを判別している．図 1.1.5 では 2017/01/01

23:59:59 であるので Arrival Time の範囲は Watermark の 1 時間を加えて 2017/01/02 00:59:59になる．

5 探索的データ分析への取り込み
ここでは，Patriot における機能拡張として Mas-

sive Parallel Processing (MPP) エンジンとカラ
ム指向型ファイルフォーマットの導入について紹介する．サービスの改善など特定の目的のために集計すべき指標の選定や機械学習のアルゴリズムを考える過程で，発行した処理に対して小さいレ

4.2

ログバリデーション

データを活用する際にはデータの品質が重要となる．データのフォーマットが統一されていな
い場合，追加のクレンジング処理などが必要となりデータ活用プロセスが煩雑になる．またフォー
マットが統一されていても，予期しないデータが混ざってしまうと同様の問題が発生し，データの活用が困難になる．

Mine では，処理するデータのフォーマットを
JSON Schema で管理し，各ログデータのバリデー

イテンシで結果を返すことができれば，対話的に探索的なデータ分析を進めることができる．このように探索的なデータ分析ができれば，より速いサイクルで仮説検証を繰り返すことができ大いに有用である．

Patriot では探索的データ分析を実現する処理エンジンとして，Hadoop クラスタ上で動作する

MPP エンジンの 1 つである Presto，および，MPPの性能を引き出す上で大きな役割を果たすカラム
指向型ファイルフォーマットである Apache ORCを導入した．

ションを行うことでデータの品質改善を行っている．JSON Schema は JSON データの内部データ

5.1

Presto の導入を規定するためのスキーマである．JSON Schema

Presto は Facebook 社が開発した分散型クエリを用いることで，ログデータに必須なフィールドエンジンであり，中間データをディスクに書き込

や，各フィールドのデータ型やフォーマットを規

まずメモリに持つことにより高速な処理ができる．

定できる．

自身でデータソースを持たず，コネクターの機能に

バリデーションを行うことで意図せぬ値が入っより複数の外部のデータソースに接続できる特徴

たログを集計から除くことができるだけでなく，がある．Presto クラスタは Presto Coordinator

スキーマ規約に違反したログをエラーレポートとと複数の Presto Worker から構成される． Co-

してサービス側に提供することで，バグを早期に

ordinator はユーザから受け取ったクエリをパー検知することが可能になりデータ改善のサイクル

ス・解析し実行計画を立て，各 Worker が実行すを円滑に進められるような仕組みになっている.

る処理をスケジューリングする． Worker はデー

1.1 データ処理基盤 Patriot における継続的改善の取り組み

10

タソースからデータを取得し，それぞれが独立しフォーマンスの低下を招きやすいが， 必要なカラて処理を実行する．最終的に 1 台の Worker が実

ムのみを読み込むことで大きくディスク I/O を低

行結果をマージしてユーザに返す役割を担う．

減できる．加えて Presto はインメモリで処理をPresto を利用する際の課題としてリソース管理行うため，特定のカラムのみをメモリに持つことがある．Presto は CPU コアとメモリともに多で使用メモリ量を大幅に低減できる．ORC ファ

くのリソースを消費する．Patriot では，Spark，

イルはストライプという小さな単位に分割でき，Hive などの他のジョブも多く動作するため，適切

ストライプが各カラムのデータを分割して保持しなリソーススケジューリングが必要となる．また，ている．また，インデックスデータとして件数，最OutOfMemory などの原因で Presto の Worker

小値，最大値，合計といった情報があり，これらがダウンする可能性があることも考慮する必要がを利用することでストライプなどの単位で読み飛ある．

ばしができ，さらなるパフォーマンスの向上が見

Patriot では YARN 上で Presto を動作させる

込める．

こと（Presto on YARN）でこの問題を解決した．

Patriot では Hadoop など各種コンポーネント

YARN の動的なリソース管理によって，Presto がをバージョンアップし，ORC が利用できるように比較的利用されていない時間帯でのリソース割りなったため，ファイルフォーマットを従来の Se-

当てを小さくすることができ，余剰リソースを他

quence File から ORC への変換を行った．そののアプリケーションに有効活用することが可能で結果，Presto，Hive などのジョブに大幅な性能のある．次に，YARN が Presto をコンテナとして改善が見られた．

起動するため，Presto YARN を起動するサーバの

ORC の導入においても第 3 節で説明したステー

セットアップのみ必要で，実際にコンテナが起動

ジング環境でのテストを行うことで，HDFS 上にされるサーバに設定を含めた事前のセットアップ

小さなファイルが多数生成され HDFS のメタデーが不要である．そのため， Presto のアップグレー

タを肥大化させる問題を事前に検知し，ORC を操ドも容易にすることができる．Presto のプロセス

作する Hive パッケージの修正などを行った上でが予期せぬ停止をしたときは YARN が Presto を本番環境に導入できた．

再起動するため，OutOfMemory などの原因でダウンすることがあっても自動的に復旧することができる．

Presto on YARN は，Coordinator と Workerのうちどれを YARN 上で動作させるかによって様々な構成が可能であるが，Patriot ではステージ
ング環境での調査などを通じて Presto コンテナを同一サーバに複数配置することで起動に失敗する問題などを事前に特定し，安定した構成で本番環境に導入することができた．

6 まとめ
本稿では，秋葉原ラボにおけるデータ処理基盤

Patriot における継続的改善の取り組みについて紹介した．Patriot では最新の OSS の導入やパブリッククラウドとの連携を効率的に行うために

Hadoop パッケージの内製化やログ転送管理シス
テムの開発を行っている．現在は，運用改善をさらに進めるための環境改善や，より多様なデータ活用をサポートするための独自のデータ可視化ツー

5.2

Apache ORC の導入

Apache ORC はパフォーマンスやストレージル [4] の開発，Apache Zeppelin の導入を進めている．

効率の向上を図るために開発されたカラム指向型

当社は様々なインターネットサービスを提供しファイルフォーマットである．ファイル全体を読ているため，扱うデータも多様で複雑になりやす

み込むとディスク I/O がボトルネックとなりパ

い．このため秋葉原ラボでは様々なデータを統合

参考文献

11

的に扱うためのツールの開発 [3] や複雑な依存関

aging a complicated workﬂow based on

係を管理するワークフロースケジューラー [2] のdataﬂow-based workﬂow scheduler. In 2016

改善など分散システムやデータベースに関する研IEEE International Conference on Big Data,

究開発も行っていく予定である．

BigData 2016, Washington DC, USA, December 5-8, 2016, pp. 1658–1663, 2016.

参考文献[3] 善明晃由, 津田均. スキーマ定義に基づく SQL
ライクな Key-Value ストアクライアント. 第[1] T. Akidau, R. Bradshaw, C. Chambers,
S. Chernyak, R. J. Fernández-Moctezuma,
R. Lax, S. McVeety, D. Mills, F. Perry,
E. Schmidt, and S. Whittle. The dataﬂow
model: A practical approach to balancing
correctness, latency, and cost in massivescale, unbounded, out-of-order data processing. Proceedings of the VLDB Endowment,
8:1792–1803, 2015.
[2] T. Zenmyo, S. Iijima, and I. Fukuda. Man-

8 回データ工学と情報マネジメントに関するフォーラム (DEIM2016).

[4] 善明晃由, 津田均, 田中克季. 可視化のための非構造データの表化手法. 第 9 回データ
工学と情報マネジメントに関するフォーラム(DEIM2017).
[5] 大内裕晃，林 晋平，善明晃由，佐伯元司. イ
シュー上の議論構造の可視化とその理解支援
ツール. 電子情報通信学会技術研究報告.

12

1.2

メディアサービスにおける検索シ
ステム基盤の構築と運用
弘瀬 健

概 要 秋葉原ラボでは当社のメディアサービス向けにオープンソースの検索システムである Solr を使用して検索システム基盤を構築し運用している．検索システム基盤の運用方式と検索システム基盤を構成する各コンポーネントについて紹介する．

Keywords

検索システム, 大規模データ

1 はじめに• 検索スコアを調整することができるいくつかの機能が用意されており，必要に応じて当社ではさまざまなメディアサービスを提供し検索結果の順序を調整することができる．

ているが，サービス毎にコンテンツの内容やユー

検索システム基盤では機能毎にコンポーネント

ザのサービス利用パターンが異なっているためそを作成してシステムを構築している．サービスとれぞれの検索ニーズが存在する．秋葉原ラボではSolr の間に，サービスからのリクエストを受け付

オープンソースの検索システム Solr*1 を使用してける api コンポーネント，サービス側データソー

検索クラスタを構成しサービス毎のニーズに沿っ

スからデータを取得し加工する batch コンポーネ

た検索システム基盤を構築し運用している．

ントを置くことでサービス側には検索エンジンを

主に以下の観点により Solr を使用することとなった．

意識させずに検索サービスを提供できている．また，秋葉原ラボ側に Solr 関係の処理を集中させる• Solr は内部でオープンソースの検索エンジ

ことで Solr を使った検索精度改善や更新効率化とンライブラリ Lucene*2 を使用して検索イン

いった知見を，検索システム基盤を利用しているデックスを作成・管理しているが，設定ファサービスに反映しやすくなっている．

イルにより容易にその検索インデックスを調整することができる．

• Solr の機能である SolrCloud を使用すると容易に検索クラスタを構築・運用することができ，検索・更新負荷が上がった場合でも検索サーバを増設することでスケールすることができる．
*1 http://lucene.apache.org/solr*2 https://lucene.apache.org/core/

以降の節では検索インデックスの管理・更新に関する運用方式，及び検索基盤システムのシステ
ム構成について紹介する．

2 運用方式

2 運用方式
検索システム基盤の検索インデックス管理方式と更新について紹介する．

2.1

検索インデックスの管理方式

検索システム基盤では複数のサービスに検索機能を提供している．サービス毎に要件がことなる
ため，Solr のアップグレードなど影響が大きい運用作業はサービス単位でできることが望ましい．
また，特定サービスの検索の負荷が高騰した場合に，他のサービスへの影響を最小限にすることも必要となる．これらの要件を実現するために，検索システム基盤では，Solr の SolrCloud 機能を使用して検索インデックスを管理している．SolrCloud
ではコレクションという単位で検索インデックス

13
サービス毎にコレクションを分けていた方が容易である．
さらに，SolrCloud ではコレクションの単位でクラスタが管理されるため，サービスごとに利用リソースを分離することが可能となる．これにより，いずれかのサービスの検索負荷が高騰した際の影響を局所化できる．検索負荷高騰に対応する
ためにはサーバを追加してスケールする必要があ
るが，利用リソースをサービス毎に分離することで，必要な追加サーバの見積もりを単純化できる．
各サービスのコレクションは，メインとバック
アップの SolrCloud クラスタを構築して運用されている．これは障害に対する冗長化と，ローリン
グアップグレードによるサービス無停止でのアッ
プグレードを可能とするためである．

が管理される．コレクションをサービス単位で運用することで，サービス毎に柔軟な検索インデッ
クスの管理が可能となる．

2.2

検索インデックスの更新

検索インデックスの更新は，後述する batch コ

まず，サービス毎にコレクションを管理するこンポーネントで実行されるサービス毎の Java プとで各コレクションで扱うデータを単純にできる．

ロセスによりそれぞれのデータソースから更新対1 コレクションで複数サービスのデータを管理す

象データを取得して行っている．更新対象データる場合，保持しているデータが複雑になるためアッは，基本的にはブログ記事といったサービス毎のプグレードの動作確認が難しくなる．特定のデー

コンテンツ情報であるが，サービスによっては検タ型のみ Solr の仕様変更があったような場合，汎索スコア調整で使用するための追加情報も検索イ

用的なスキーマだと対象のデータ型が実際に使用

ンデックスに登録している．スコア調整用のデーされているかの判断が難しい．

タとしてはコンテンツ毎の読者数や売り上げ額な

次に，アップグレードの影響範囲を小さくできるため，Solr のアップグレードを行いやすくなる．

どがあるが，これらはログ解析基盤に送られたサー
ビス毎のログから取得している．

1 コレクションに複数サービスをまとめてしまう

更新対象となるコンテンツ情報はタイムスタンと，アップグレード時にそのコレクションで管理

プをもとに判定しており前回のインデックス更新

されているサービス全てを一括でアップグレード

処理実行以降に更新のあったコンテンツ情報が対することになる．スキーマに関する互換性が保障象となる．コンテンツ情報は数分から数時間以内されないアップグレード時はインデックスの再構には検索インデックスに反映される．これに対し築が必要になるが，サービス全てを一括アップグ

スコア調整用のデータはログベースでの連携といレードする場合，全サービスのデータ再構築が完

うこともあり基本的には日次での更新となってい了するまでアップグレードの内容が反映されない．

る．

1 サービス 1 コレクションとしていた場合は，サー

スコア調整用のデータ更新処理はコンテンツ情

ビス毎にアップグレードを実行でき完了したサー報更新処理とは別プロセスとして実行する．Solr

ビスからアップグレードをサービスに反映できる．

では更新時に commit 処理を行う必要があるが，アップグレードに問題があった場合の切り戻しもcommit 処理は負荷が高く頻繁に行うものではな

1.2 メディアサービスにおける検索システム基盤の構築と運用

14

い．上述のように 1 サービスで複数の更新プロセ

では batch が各サービス毎に用意されているデースを並行して実行することがある場合は Solr のタソースよりデータを取得しサービス要件に応じauto commit 機能を使い，commit 処理が頻発して加工する．加工したデータは node に対して送ないように制御している．

信する．node で受け取ったデータは SolrCloud

検索インデックスの管理方式の項で述べたように，各サービス毎にメインとバックアップの Solr-

により Lucene 形式のインデックスファイルとして保管される．

Cloud クラスタを構築して運用しているが，それぞれのクラスタに対する更新処理は別プロセスとして実行している．これは障害に対する冗長化とアップグレード時の運用を考慮してのものである．

3.2

api

api では主に以下の処理を行う．
• リクエストパラメータの Solr クエリへの変

3 システム構成
3.1

概要

検索システム基盤は複数のコンポーネントより構成されている. それぞれの概要を以下に示す．

• api: サービスからの検索リクエストを受け付け，Solr 用クエリを作成し node に対してリクエストするコンポーネント．

• node: 検索インデックスを保持している
コンポーネントであり，Solr を SolrCloud
モードで起動している．

• batch: サービス毎のデータソースからデータを取得・加工し node に対して更新リクエ
ストを送るコンポーネント．

• zookeeper*3 : SolrCloud で使用されている
分散システムのコーディネートを支援する
サービス.batch で使用する更新情報も管理している．

換及び検索リクエスト送信• 検索クエリログの出力• node の死活監視api では各サービスからの検索リクエストを受け付ける. 受け取ったリクエストをもとに Solr 用の検索クエリを生成し，Solr を起動している node
へリクエストし検索結果を取得する．取得した検索結果の表示順についてはサービス毎にさまざまなニーズがあり個別に調整を行う必要がある．例
えば，コンテンツ作成日の新しい順といった単純なものから，検索を実行したユーザにお勧めのコンテンツを優先して表示など単純なソート機能では実現できないものなどさまざまなニーズが存在する．単純な表示順に関しては Solr のソート機能で対応できるが，特定条件のコンテンツのみ優先
表示といったことに関しては Solr の eDisMax*4 機
能を使い検索スコアを調整することで実現する．
またお勧めのコンテンツといったユーザに対する推薦の部分に関しては，検索クエリ作成時に api

検索システム基盤には検索処理とデータ登録から推薦システム基盤にリクエストして推薦結果処理が存在する．検索処理では api がサービスを取得し検索クエリに反映することもある．この側の窓口となりリクエストを受け付ける．受けような検索スコア調整に関する処理は Solr 用の検付けたリクエストをもとに Solr 用クエリを作成

索クエリ作成時に api で行っている．

しし node に対して検索リクエストを送信する．

また api では各サービスからの検索リクエスト

node では受け取ったリクエストをもとに Solr-を受け取り処理実行した際に検索クエリログをCloud を使って検索処理を行う．データ登録処理

出力している. 出力したクエリログは Flume*5 を*3 https://zookeeper.apache.org/*4 https://lucene.apache.org/solr/guide/6_6/the-extended-dismax-query-parser.html*5 https://flume.apache.org/

3 システム構成15

図 1.2.1 検索システム基盤全体図

使ってログ解析基盤に転送し管理している．ログ

3.3

node

解析基盤に送られたクエリログは，サービス側のnode は検索対象データを管理し検索処理を実検索画面で利用されるワード補完システムで補完行するコンポーネントである．node では Solr を候補キーワードの優先度やキーワードの組み合わ

SolrCloud モードで起動しており，検索・更新リせを作成する際に利用される．

クエストは Solr によって処理される．Solr は内

検索システム基盤の node では，各サービス毎に部で Lucene を使用しており，検索対象データはメインとバックアップ用 SolrCloud クラスタを作

Lucene 形式のインデックスファイルとして管理成して運用しており通常はメインの SolrCloud ク

される．node ではサービス毎に複数のサーバを使ラスタで検索処理を受け付けるようになっている．

用して SolrCloud クラスタを構築して運用していただし，何らかの障害によりメインの SolrCloudる．

クラスタが使えなくなった場合はバックアップのSolrCloud を使用することになる．このメイン・バックアップそれぞれの SolrCloud コレクショ
ンの死活監視を api では行っている．死活監視の結果メインの SolrCloud が使えないと分かった場
合は，自動的にバックアップの SolrCloud コレクションに対して検索リクエストを送るように apiで制御している．

3.4

batch

batch はサービス毎に用意されたデータソース
よりデータを取得し node へ送信する Java プロセスである．取得したデータは node へ送信する前に検索に適した形に加工する．その際にログ解析
基盤経由で取得したサービス側ログを使用することもある．batch の Java プロセスは，各システム共通で使用している Mesos*6 クラスタ上で実行す*6 http://mesos.apache.org/*7 https://jenkins-ci.org/

1.2 メディアサービスにおける検索システム基盤の構築と運用

16

る．また Mesos と連携した Jenkins*7 によって実用して更新対象データを取得するが，batch で使行スケジュールは管理している．

用する更新処理に必要な情報も zookeeper で管理
している．

3.5

zookeeper

分散システムのためのコーディネションサービ
スであり，Solr が SolrCloud の各種情報を管理す

4 まとめるために使用する．api/batch は直接対象となる当社で提供しているメディアサービス向けの検node の情報を保持していないため，検索/更新時

索システム基盤の構成と運用について紹介した．

には zookeeper より対象となる node の情報を取Solr を使うことでサービス毎の検索ニーズを満た得し処理を実行する．

しつつスケーラブルな検索システム基盤を構築で

また batch では実行時にタイムスタンプ等を使

きた．

17

1.3

リアルタイムのデータ活用を支援するストリーム処理エンジンの
開発
佐藤 栄一

概 要 本稿では，リアルタイムのデータ活用を支援するために開発・運用されているストリーム処理エンジン（開発コード: Zero）について紹介する．本システムは，SQL ライクな独自のクエリ言語「ZeroQL」
を事前に記述しておくことで，様々なサービスで発生したログをリアルタイムに処理し，データベースに記録する．記録されたデータは API 経由で数ミリ秒〜数十ミリ秒の低いレイテンシで取得でき，レコメ
ンデーションや広告配信などの配信制御及び精度向上，また，各種指標のリアルタイムのレポーティングなどに活用されている．

Keywords

ストリーム処理，SQL

1 背景
様々なサービスなどから出力されるログをリア
ルタイムに活用したいというニーズは多い．まず
は，速報値のレポーティングのように，リアルタ

まとめと今後の展望を述べる．

2 システムの設計
はじめに，本システムではイベントの転送について次のような前提を置いている．

イムの集計値を直接利用するものが挙げられる．
また，レコメンデーションや広告配信においては，

配送保証 イベントの転送過程において，欠損を防ぐために，再送が行われることがある．結ユーザーに対するコンテンツの表示回数を制限す

果的に複数回，イベントが届くことがある．

るフリークエンシーキャップを行ったり，機械学
習のモデルにユーザーに関するリアルタイムの素

配送順序 イベントの到着順序は保証されていな
い．イベントが時刻順など何らかの意味の性を含めたりすることで，よりユーザーに最適化

ある順序で届くとは限らない．

したコンテンツを表示することができる．これらの実現には，発生したログ（イベント）をストリー

この前提から，イベントの重複や到着順序に影ム処理により即時に処理し，データとして利用可

響を受けない処理を考える必要がある．詳細は後能な状態にすることが必要である．

述するが，前者は重複を除外する仕組みを設ける

一方で，必要とされるデータに応じてシステム
をそれぞれ開発，継続運用するには，多大な労力こと，後者は可換モノイドというデータ構造を用いることにより解決している．

を要する．汎用的なストリーム処理システムが必
要である．

2.1

ZeroQL

2 節では，システムの設計について述べる．3 節

ストリーム処理を汎用的なシステムとして実装

では，システムの実装について述べる．4 節以降，する場合，どのような処理を行うのか，簡潔に記1.3 リアルタイムのデータ活用を支援するストリーム処理エンジンの開発

18

述できる必要がある．また，当社では主に JSONを行うことができる．この基準時刻は，後述する

形式のログが扱われており，本システムにおいて[GROUP BY] INTERVAL 句や一部の集約関数で使も JSON 形式のイベントから必要なフィールドを用される．

取り出すなどの変換操作を簡潔に記述できなければならない．

また，DISTINCT 句を指定することで，重複して届いたイベントの重複排除を行うことができる．

このため，本システムでは SQL に類似した言再送などにより同一のイベントが複数回届く可能

語「ZeroQL」を独自に定義した．また，JSON ド

性のある状況で count(*) など冪等*3 ではない集

キュメントの変換を行うコマンドラインツールと約関数を用いる場合には必要となる．なお，重複して jq*1 がよく知られており，同言語を ZeroQL

排除はすでに処理したイベントの ID などを記録に組み込む形で採用した．ただし，本システムはしておくことで行うが，記憶容量の制約から保存

Java 言語で記述しており，C 言語で実装されたコ

期間を続く FOR 句で指定する．

マンドラインツールである jq はそのままでは利用に適さないため，JVM 上で動作するライブラリとして jackson-jq*2 を実装して用いた．

ZeroQL の記述例をリスト 1.3.1 に示す．以降，
本項では ZeroQL の構文について簡単に説明する．
SELECT
count (*) AS total ,sum ( ` if . type == " click "then 1 else 0 end `) AS click ,FROM flume ( `. time `)DISTINCT ON `. uuid ` FOR 10 m
WHERE ` headers . service == " foo " `GROUP BY `{user_id : . user_id}`
PARTITION BY user_id
INTERVAL 1 d

GROUP BY . . . 句
GROUP BY 句には，オブジェクトを生成する jqの式を指定する．生成されたオブジェクトの等価性に基づきグルーピングの処理が行われる．また，複数のオブジェクトを生成する jq の式を指定する
ことで，単一のイベントを複数のグループに計上することも可能である．これはイベントに配列として含まれている情報などでグルーピングしたい
ときに有用である．

ソースコード 1.3.1 ZeroQL の記述例: user id
毎のログの件数とそのうち type が click である
件数をそれぞれ total, click として集計している．

[GROUP BY] INTERVAL . . . 句[GROUP BY] INTERVAL 句は時刻の処理に特化した GROUP BY 句である*4 ．集約関数による処理

SELECT . . . FROM . . . 文を一定の期間区切りで行うよう指定でき，例えば，

SELECT 以降には，必要な集約関数を指定する．

全期間 (NONE)，1 日毎 (1d)，1 時間毎 (1h)，10 分

集約関数の詳細については，2.2 節を参照された

毎 (10m) などを複数指定することができる．指定

い．

しない場合は，暗黙的に全期間での集約となる．

FROM 句には，データの取得元を指定する．続

この処理は FROM 句で指定したイベントの基準時

く括弧内には，イベントを処理する際に基準とな刻をもとに行われる．また，INTERVAL を指定しる時刻を jq の式で指定する．本システムでは，たテーブルでは，結果の取得時に期間指定ができ，処理を行っている時点での時刻に限らず，イベ

指定した期間の結果をまとめて取得したり，指定ントの発生時刻など，任意の時刻を基準に処理した期間でさらに集約した結果を取得できる．

*1 https://stedolan.github.io/jq*2 https://github.com/eiiches/jackson-jq*3 対応するモノイド (S, •) が a • a ̸= a (a ∈ S) という意味で使用している．モノイドについては後述する．
*4 [GROUP BY] INTERVAL の GROUP BY 部分は省略可能である．

2 システムの設計
2.2

集約関数

本システムでは，以下の集約関数を提供*5 している．実装上，本システムでの集約関数は実際に19
単位元の存在 ∃e ∈ S, e • a = a • e = a
また，この定義に加え，次の交換則を加えたものを，可換モノイドという．

は集約処理をしておらず，イベントを後述する可換モノイドに変換して出力するだけの関数である．

交換則 a • b = b • a• count(*), count(expr): 件数を求める．

例 え ば ，実 数 全 体 の 集 合 を R と す る と き ，

後者は expr が null ではない件数を求め(R, +), (R, ×) などが可換モノイドである．集る．

合 S も演算 (•) も自由に定義できるため，結合則• sum(expr): expr で指定した数値の合計を求める．

と交換則さえ満たせば，単位元として null などを
集合 S に加えることで，実用上は容易に可換モノ• min(expr), max(expr): それぞれ，expr

イドを構成することができる．例えば，R に nullで指定した値の最小値，最大値を求める．

を加えた集合 R′ を定義したとき，null が単位元

• latest(expr), oldest(expr): expr でとなるように両辺のうち大きい方を返す二項演算

指定した値の最新値，もしくは最も古い値

max を定義すれば，(R′ , max) は可換モノイドであ

を求める．

る．

• latest_n(expr, n): expr で指定した値の最新の n 件を求める．

イベントを集約関数により可換モノイドに変換して扱うことで，イベントの到着順序に関わらず，• latest_set_n(expr, n): expr で指定しまた，複数のサーバーで先に別々に集約しても，最た値の重複を除いた最新の n 件を求める．

終的な結果は変化しない．このような処理の方法• reduce(expr, reduce[, postprocess]):

は，処理のタイミングなどが異なるだけで，バッ

expr で 指 定 し た 値 を reduce で 指 定

チ処理でよく知られている MapReduce に他ならし た 式 で 集 約 し た 値 を 返 す ．こ れ はない*8 ．

jq に よ り 処 理 を 自 由 に 記 述 で き る よう に し た 集 約 関 数*6 で あ り ，例 え ば ，reduce(1, `. + $value`) は count(*)と同じ結果を返す．

2.4

データモデル本システムでのデータの概念図を表 1.3.1 に示す．Record Keys は ZeroQL の GROUP BY 句によって決まる．また，Record Values の col1, col2

なお，一部の集約関数は，FROM 句で指定した時刻を基準に動作する．

2.3

モノイド

集合 S ，その上の二項演算 • : S × S → S が与えられた時，次の条件を満たす組 (S, •) をモノイドという*7 ．ただし，a, b, c ∈ S とする．
結合則 (a • b) • c = a • (b • c)

は，ZeroQL の SELECT 以降の集約関数のリストによって決まる．Record Keys は，内部では 2 つの部分 (hash-indexed, dynamic) に分かれており，

ZeroQL で PARTITION BY 句で指定したものが，hash-indexed 部分になり，残りが dynamic 部分として扱われる．hash-indexed 部分は，結果の取得時など，データにアクセスする際に必須である．

Interval と Timestamp は，INTERVAL 句により

*5 厳密には，現在の実装では latest long(), latest json() など集約関数末尾に型名を表す接尾辞が付く場合がある．将来的には統合され，接尾時が削除される予定である．
*6 関数型言語によく見られる reduce や fold 関数に近い．
*7 Haskell の Monoid 型クラスなど，一部の言語ではモノイドに対応する仕組みが用意されていることがある．
*8 集約関数によりイベントからモノイドへ変換する操作が Map，データベースへの書き込み時などに行うモノイドの演算 (•)

が Reduce に対応する．

1.3 リアルタイムのデータ活用を支援するストリーム処理エンジンの開発

20

表 1.3.1 データモデル

Record Keys
(hash-indexed)
gk1
gk2

Interval

foo
foo
foo
foo
foo
foo
foo
bar
bar

1 day
1 day
1 day
1 hour
1 hour
1 hour
1 hour
1 day
1 day

a
a
a
a
a
a
a
c
b

Timestamp(sorted)Record Keys
(dynamic)

Record Values
col1

col2

2017-12-11
2017-12-11
2017-12-12
2017-12-11T10
2017-12-11T11
2017-12-11T12
2017-12-12T07
2017-12-11
2017-12-11{col1: a, col2: b}{col1: a, col2: c}{col1: a, col2: b}{col1: a, col2: b}{col1: a, col2: c}{col1: a, col2: b}{col1: a, col2: b}{col1: a, col2: b}{col1: a, col2: b}

27
31
47
20
31
7
47
23
42

16
94
61
11
94
5
61
29
47

有限の時間区切りを指定した場合のみ，使用され
る．

使用する．

Cache Server Monoid Storage の負荷軽減及びレイテンシの削減のため，モノイドのキャッ

3 システムの実装

シュを行う．Redis を使用する．

Conﬁg Registry ZeroQL や キ ャ ッ シ ュ 設 定 など，テーブル設定の保存を行う．Apache

本システムは，図 1.3.1 に示すコンポーネント

ZooKeeper や MySQL を使用する．

により構成されている．一部のコンポーネントは，必要とされる要件やクラウド環境に応じて切り替

Discovery Service Cache Server, Dedup Serverの発見を行う．Apache ZooKeeper や Ku-

えたり，併用したりしている*9 ．

bernetes の Endpoints API を使用する．

Event Processor イベントを受け取り，モノイドへの変換後，Monoid Storage へ書き込みを行うサーバーである．

Query Server Monoid Storage からモノイドを

3.1

イベントの処理

取得し結果を返す．Event Processor と同

Event Processor の処理の流れを図 1.3.2 に示一のソースコードで動作しているため必ずした．まずは，Apache Flume *10 など*11 のスト

しも分ける必要はないが，負荷の傾向が異リーム転送ミドルウェアからイベントを受け取る．

なるため，運用上の都合上サーバーを分け

その後，ZeroQL で指定した集約関数によってモている．

ノイドに変換される．このとき，すでに処理済み

Monoid Storage モ ノ イ ド の 記 録 を 行 う ．

のイベントかを確認し処理済みの場合は，イベン

Apache HBase などを使用しているが，詳トは破棄する．モノイドは書き込みバッファに追細は 3.2 項で述べる．

加され，最終的にストレージに書き込みが行われDedup Server イベントの重複排除のために，処理済みのイベントの記録を行う．Redis をる．書き込み後，対応するキャッシュエントリが存在する場合は，無効化される．

*9 依存するライブラリの競合が避けられないこともあり，クラスローダーを分離したプラグイン機構を実装している．
*10 https://flume.apache.org/*11 他 に ，ApacheKafka (https://kafka.apache.org/), Amazon Kinesis (https://aws.amazon.com/kinesis/),Google Cloud Pub/Sub (https://cloud.google.com/pubsub/) に対応している．

3 システムの実装

21

図 1.3.1 コンポーネント図

図 1.3.2 イベントの処理の流れ

3.2

Monoid Storage

Monoid Storage は，集約関数により変換されたモノイドを保存するデータベースである．このり提供されている NoSQL データベースサービス
であり，HBase と互換性のあるインターフェース
で使用することができる*15 ．

データベースは大量のランダムアクセスを低いレ

表 1.3.2 に本システムのデータモデル（表 1.3.1）

イテンシで処理できる必要があり，現在は Apacheと HBase のスキーマの対応関係を示した．HBase

HBase, Google Cloud Bigtable 及び，Amazonのセルには，値として各モノイドを byte 列に

DynamoDB を使用している．

エンコードしたものを格納している*16 ．また，

INTERVAL に応じて異なる TTL を設定したいこと
Apache HBase / Google Cloud Bigtable
Apache HBase*12 は，Bigtable*13 をモデルに実もあり，この場合は INTERVAL 毎にカラムファミ
リーを分割している．

装されたスケーラブルな分散データストアである．

行 キ ー の 先 頭 に は ，Record Keys (hash-

また，Google Cloud Bigtable*14 は，Google によindexed) のうち一部のキーのハッシュ値を 1 byte

*12 https://hbase.apache.org/*13 https://research.google.com/archive/bigtable.html*14 https://cloud.google.com/bigtable/*15 Cloud Bigtable の API を直接使用することも出来る．実装上，HBase 1.x の非同期ではない Java API を避けたかったため，本システムでは Cloud Bigtable の API を直接使用している．
*16 latest() 関数により出力されるモノイドなど，一部のモノイドはセルの値だけでなくタイムスタンプも使用して保存している．

1.3 リアルタイムのデータ活用を支援するストリーム処理エンジンの開発

22

表 1.3.2 データモデルとスキーマの対応関係
データモデル

HBase / Cloud Bigtable

Record Keys (hash-indexed)

行キー

Interval

DynamoDB
パーティションキー
（または，部分的にソートキー）

行キー（または，列ファミリー）ソートキー

Timestamp
Record Keys (dynamic)
Record Values の列

行キー

ソートキー

列 (Qualiﬁer)

ソートキー

列 (Qualiﬁer)

属性 (Attribute)

モノイド値

値，タイムスタンプ

属性の値 (Value)

付与している．これは，データを均一に分散させを行うが，リトライでの成功確率を上げるためにるためであるが，一部のみを使うのは，アクセス

ジッター*17 と呼ばれるリトライ間隔のランダム化

パターンを考慮し，例えば，ユーザー毎にデータを行っている．

が連続している方がアクセスの局所性が高くなるためである．

また，HBase では，テーブルへの初回もしくは時間があいてからのアクセスに時間がかかること

モノイドの書き込みには，Increment，Put をから，参照する可能性のあるテーブルには定期的使用するが，一部のモノイドの書き込みでは，セにバックグラウンドで Scan を実行しており，アクルに対する CheckAndPut 操作が必要になる．こセスの少ないテーブルを参照する場合でもレスポの場合，まずはセルのデータの Get を行う．Get

ンスに時間がかかることがないよう注意している．

により取得したモノイドと，これから書き込む内
容とモノイドの演算を行った結果のモノイドをCheckAndPut により書き込むが，このとき HBase

Amazon DynamoDBのサーバーでは，既存の値と比較し，その間に別のAmazon DynamoDB*18 は，Amazon Web Ser-

変更が行われていない場合に限り，CheckAndPut

vices により提供されている NoSQL データベーを処理する．変更が行われていた場合は，Get かスサービスである．HBase との機能的な違いとしらやり直す．複数のサーバーから同時に同じセルて，DynamoDB では単純な byte 列以外にドキュに対して CheckAndPut を行った場合，成功するのメント型などのデータ型を扱うことができ，デーはどれか一つであり非効率であるが，本節の後半

タの更新処理についても，UpdateItem API を使で紹介する書き込みのバッファリングを行うこと

用して更新内容を DSL の式で記述することで複雑により，同じ行への書き込みが発生しづらくなっな処理が可能になっている．また，DynamoDB はている．例えば，ユーザー毎の集計等を行う場合使用するスループットキャパシティを事前に設定には，カーディナリティが高く，書き込む行がよするデータベースである．本システムでは，キャく分散するため競合はそもそも稀であり，一方で，パシティ超過による無駄なリトライを防ぐため，

カーディナリティの低い GROUP BY を行う場合にテーブルに設定された書き込みキャパシティを自は，書き込みのバッファリングが良く効くため，同動で認識して，それを超えないよう書き込みリク

じ行への書き込み回数が少なくなり，競合が抑えエストの送信自体を流量制限している．

られる．また，競合が発生してしまった場合は，指数バックオフにより一定時間待ってからリトライ

本システムのデータモデルと DynamoDB の対応関係は，表 1.3.2 を参照されたい．

*17 https://aws.amazon.com/blogs/architecture/exponential-backoff-and-jitter/ が詳しい．
*18 https://aws.amazon.com/dynamodb/

3 システムの実装

23

書き込みのバッファリング

るため，クライアント側ではリトライもしくは，何イベント処理後のモノイドを毎回ストレージにらかのフォールバック処理を行う必要がある．こ

書き込むのは非効率である．結合則及び交換則がれは，本システムは複数のサービスから使用され成り立つため，事前に演算 (•) を行うことで，書きるため，どれか単一のサービスがすべてのリソー込みの回数を減らしストレージへの負荷を軽減す

スを奪うことを防ぎ，何らかの障害などの際に影ることができる．

響範囲を狭めることを目的としている．

本システムでは，内部でモノイドの演算 (•) を行う仕組みを加えた遅延キューを利用して書き込みのバッファリングを行っている．この遅延キューの実装では，キューの要素がキーと値を持ち，すでにキュー内に存在するキーと同じキーを持つ要

読み込みのキャッシュ
利用する用途に応じて要件や負荷の傾向が異なるため，キャッシュを有効にする場合，テーブル
毎に以下の項目を設定できるようにしている．

素を追加 (enqueue) した場合，既存の要素との間で演算 (•) が行われ値が更新される．また，一旦キャッシュ生存期間 (Time to Live)

キューに追加した要素は，設定した遅延時間を待たキャッシュ一貫性 書 き 込 み 時 無 効 化（Write

なければ取り出すこと (dequeue) が出来なくなっ

Invalidate）の場合は，ストレージへのている．ただし，キューには最大容量が設定され書き込み後，対応するキャッシュエントリ

ており，キュー内の要素数が最大容量の 90% を超が無効化される．

えた場合には，遅延時間を待たなくても要素を取キャッシュ対象期間 INTERVAL 句による集約期間

り出すことができる．最大容量に達した場合には，が過ぎ，一定期間経ったデータのみをキャッ追加操作を実行しているスレッドはブロックされシュ対象にする（リアルタイムに変化する

る．

データはキャッシュ対象外にする）．

3.3

読み込みリクエストの処理

Redis 上での時系列データのキャッシュ

集約結果を取得する読み込みリクエストの処理

本システムのデータモデル（図 1.3.1）のデータの流れを図 1.3.3 に示す．高速に結果を応答するを効率良くキャッシュすることを考える．ソート必要があるため，キャッシュを行っている．クラ済みセットを使用すれば時刻でソートされたままイアントからのリクエストを受け取ることで処理

キャッシュ可能だが，キャッシュされていないこが始まるが，まず必要なデータを計算し，キャッととデータがないこと（ネガティブキャッシュ）をシュに問い合わせを行い，キャッシュミスしたもの

効率よく表現することが難しい．そのため，Redisについては，Monoid Storage に問い合わせを行いのモジュール機能を利用して，時系列データに適その結果をキャッシュする．最終的には，キャッした z-tscache*20 というデータ型を実装し使用しシュヒットしたもの，Monoid Storage から読み込ている*21 ．このデータ型では，キャッシュエン

んだものをマージして，クライアントに返却する．

トリを「時刻範囲 [time_from, time_to) とそ

また，リクエストの実行においては，テーブル毎の範囲内の時刻から文字列へのソート済みマップの同時リクエスト数*19を制限している．制限を超（map<time, string>）の組」のソート済みリス

えた場合，処理を行わず直ちにエラーが返却されトとして保持する．時刻範囲が存在するが，マッ*19 ある瞬間に処理中のリクエスト数という意味で使用している．秒間リクエスト数とは異なる．
*20 Redis のユーザデータ型は 9 文字で命名する必要がある．
*21 ただし，[GROUP BY] INTERVAL 句による期間区切りの集約を行わない場合は，そもそも時系列データとして扱う必要はな

い．この場合は z-tscache 型を使用せず，組み込みの文字列型を使用している．また，データのシリアライズには Java のシリアライザフレームワークである Kryo (https://github.com/EsotericSoftware/kryo) を用いている．

1.3 リアルタイムのデータ活用を支援するストリーム処理エンジンの開発

24

プに対応する時刻がない場合は，データがない（ネ

純にキーのハッシュ値を mod N（N はキャッシュ

ガティブキャッシュされている）ものとして扱う．

サーバーの台数）して担当するサーバーを決めた

リ ス ト 1.3.2 に 使 用 例 を 示 す ．こ の 例 で場合，サーバーが増減した際にほとんどのキーのは ，は じ め に storeex コ マ ン ド に よ り ，範 囲

担当サーバーが変わってしてしまい，大量のキャッ[2017-12-01, 2017-12-05) のキャッシュをキー

シュミスが起きてしまう．Consistent Hashing を

test に TTL を 300 秒として保存している．次の使用することで，サーバーが増減しても，増えた

load では，test キーに対して範囲 [2017-12-01,

サーバーもしくは，減ったサーバーが担当してい2017-12-31) のキャッシュを問い合わせている．

たキーのみ（全体の 1/N）が移動するため，キャッ範囲 [2017-12-01, 2017-12-05) はキャッシュ

シュミスの発生を低減できる．

ヒットとなり，2017-12-02, 2017-12-03 についまた，クラウド環境にデプロイする場合，常にてはデータが存在し，それ以外はデータが存在しな

最大のキャパシティに備えるのは経済的ではない

いことを表すネガティブヒットとなっている．結ため，オートスケーリング機能を使用している．

果のない [2017-12-05, 2017-12-31) は，キャッキャッシュノードが動的に変化してしまうため，

シュミスである．

Apache ZooKeeper や Kubernetes の Endpoints

127.0.0.1:6379 > tscache . storeex test \2017 -12 -01 2017 -12 -05 \300 # time to live \2017 -12 -02 foo \2017 -12 -03 barOK127.0.0.1:6379 > tscache . load test \2017 -12 -01 2017 -12 -31
1) 1) ( integer ) 2017 -12 -01
2) ( integer ) 2017 -12 -05
3) 1) ( integer ) 2017 -12 -02
2) " foo "3) ( integer ) 2017 -12 -03
4) " bar "127.0.0.1:6379 > tscache . invalidate test \2017 -12 -02 2017 -12 -03
OK
127.0.0.1:6379 > tscache . load test \2017 -12 -01 2017 -12 -31
1) 1) ( integer ) 2017 -12 -01
2) ( integer ) 2017 -12 -02
3) ( empty list or set )2) 1) ( integer ) 2017 -12 -03
2) ( integer ) 2017 -12 -05
3) 1) ( integer ) 2017 -12 -03
2) " bar "ソースコード 1.3.2 z-tscache 型の使用例: 実
際は時刻の表現に UNIX 時間 (ms) を使用しているが，読みやすさのためフォーマットしている．

キャッシュサーバーのスケールアウト

Redis は高速ではあるが，1 台では日々増えるト
ラフィックに対応することはできない．そのため
本システムでは，複数のキャッシュノードを起動し，キーのハッシュ値を利用して問い合わせを分散させている．担当するキャッシュサーバーを決める際は，Consistent Hashing を利用している．単API を用いてキャッシュサーバーの一覧を取得している．
また，Redis は複数の CPU を有効に使えないた
め，1 ノード上に CPU の物理コア数分，ポートを変えるなどしてプロセスを起動している．

4 まとめ25

図 1.3.3 リクエストの処理の流れ

4 まとめ

5 今後の展望

本稿では，ストリーム処理エンジン（開発コー

今後の予定として，性能などの特性が異なるミド

ド: Zero）を紹介した．「ZeroQL」により宣言的

ルウェア，例えば，Apache Phoenix, Redis Clus-にストリーム処理を記述することで，即座に結果

ter などへの対応や，JOIN 機能の実装，また，異を取得でき，リアルタイムのデータの活用がよりなり数を計測する集約関数の実装など，機能の充短期間で実現できるようになった．

実を図る予定である．また，性能面での改善も継また，広告配信などリクエスト数の多いサービスでも使用されているため，高速にレスポンスを返すための工夫などについても紹介した．

続的に行っていく予定である．

26

2. 機械学習システム

近年，学術界と産業界の両方で，ユーザ体験の向上を目的としたレコメンデーションシステ
ムの開発に関心が集まっている．例えば，世界最大のインターネットオークションサイトを運営する eBay は，社内で開発したレコメンデーションシステムの学術報告に取り組んでおり，新しいアルゴリズムやシステムにより CTR の向上などサービス改善に寄与していることが報告されている．また，動画ストリーミング配信サービスを展開する Netﬂix は，Netﬂix Prize と呼ばれるコンペティションを開催し，自社のレコメンデーションシステムを最も改善するアルゴ
リズムを提案した参加者に賞金を授与している．このように，様々な企業がサービスの競争力を高める上でレコメンデーションシステムの開発を重要視しており，積極的に投資を行っている．
そうした状況下で，秋葉原ラボにおいても，Ameba ブログ・AbemaTV・AWA や広告プロダ
クトなどから日々生成される大量のデータを活用したレコメンデーションシステムを開発し，サービス改善に貢献している．当社は数多くのサービスを運営しており，中には Ameba ブロ
グのように国内有数の規模を誇るものもある．これらの要件に対応するために，秋葉原ラボではレコメンデーションシステムについて次の課題に取り組んでいる．
第一に，サービスからの多種多様な要望に対する汎用的なレコメンデーションシステムの開発である．サービスごとのデータソースの取得方法や類似したロジックを共通化することで，運用・管理コストや新たなサービスへの導入コストが改善できる．加えて A/B テストやバン
ディットアルゴリズムを用いたコンテンツのリランキング，CTR など各種指標のレポーティン
グの機能などを提供することで，サービスが抱える様々な要求を満たしている．
第二に，大規模データに耐えうるスケーラブルなレコメンデーションシステムの実現である．
レコメンデーションシステムが扱うデータ量はサービスの成長に伴って増加するため，システ
ムのスケーラビリティは必須である．また，大規模データに対して高速なレコメンドを実現するためにはアルゴリズムの計算量やメモリ効率についても最適化が求められる．

2.1 章では，秋葉原ラボが開発するレコメンデーション基盤のシステムアーキテクチャについて解説する．2.2 章では，A.J.A. Recommend Engine で用いている高速な探索アルゴリズムについて紹介する．

27

2.1

大規模リアルタイムレコメンデー
ションを支えるスケーラブルなシ
ステム基盤の構築
Juhani Connolly, 内藤 遥, 福田 鉄也

概 要 レコメンデーションシステムを開発する上で，最新アイテムのオンラインでの取り込みやモデルの定期更新，CPU やメモリなどのリソース管理は重要なファクターとなっている．また数多くのメディアサービスを抱える大規模なシステムを考えた場合，新規メディアサービスやデータセットの増加に応じてシステムが自動でスケールできる状態が望ましい. 本稿では上記を解決するためのシステムアーキテクチャ，およびシステムの様々な処理を効率化する各コンポーネントについて紹介する．

Keywords

レコメンデーションシステム, スケーラビリティ, リソース管理

1 背景

ディアサービス導入にあたる運用コストが問題となった．これらの問題を解決するために，本シス

秋葉原ラボでは様々なメディアサービスに対しテムは頻繁に行われるメディアサービスの追加にてレコメンデーションシステムを提供している．

おけるデータセットの更新の自動化，およびリソー

レコメンデーションシステムが扱うデータ量はシ

ス管理の効率化を目指して開発されている．具体

ステムを利用するメディアサービスの成長に伴っ的には，次のような要件を定めた．

て増加するため，データ規模に対するスケーラビ• 新規メディアサービスの導入コスト削減

リティが必要とされる．特に当社の文書推薦シス• 文書の追加，更新，削除時におけるリアル

テムは数百のメディアサービスに対し推薦を提供しており，そのために柔軟にスケールできるようタイムなデータセットの更新• 新規ワード抽出のための定期的なモデルのに設計されている．

更新，およびダウンタイムが生じないシス

文書推薦システムは文書に対してそれと類似している文書をメディアサービス内から検索し，推テムへの反映• 一部のサーバがダウンしてもフェイルオー

薦結果として提供するものである．本システムはバーできる冗長化構成

一般的な類似文書探索と同様に，文書のテキストデータをベクトル化して次元圧縮を行い，それを本章ではこれらの要件を満たすレコメンデー

基に文書間の類似度を計算している．ラボが従来

ションシステムのアーキテクチャについて紹介す提供していた文書推薦システムはキャッシュ効率

る．

などの観点から，メディアサービスごとにサーバを設置してベクトル化や次元圧縮の処理を行っていた．しかし，システムを利用するメディアサー
ビスの増加に伴って，サーバ維持コストや新規メ2.1 大規模リアルタイムレコメンデーションを支えるスケーラブルなシステム基盤の構築

28

2 システム構成
本システムは複数のコンポーネントで構成されている．主なコンポーネントとその役割について
次に示す．

API 文書ベクトルを保持し，クエリに対して類似文書を返す窓口

Diﬀstore 各メディアサービスのデータセットを
リアルタイムで更新するシステム

Model Manager メディアサービス追加時などのリソースの自動割り当てや，API 群のモデて中間生成物を API サーバ上で保持していたが，本システムでは API サーバは類似度計算に必要なデータのみを保持し，ベクトル化や次元圧縮の処理を Diﬀstore に分離した．定期的に Diﬀstore 上のデータセットと同期をとることで API サーバの保持するデータを最新に保っている．
また，冗長化および負荷分散のため，1 つのメ
ディアサービスに対して複数の API サーバが推薦を提供している．各 API サーバが担当するメディアサービスはリソースの空き状況などを元にModel Manager によって決定される．

ル更新のタスク管理を行うシステム

ZooKeeper API など分散システムのコーディ
ネートを支援するサービス*1

2.2

Diﬀstore

直積量子化によって文書をベクトルに変換する

スケールアウトを自動化するために AWS*2 の際，特異値分解による次元圧縮が行われるが，こオートスケーリング機能を使っており，またサーのためには巨大な行列をメモリ上に展開する必要

バ間のメッセージングには Avro*3 を利用していがある．旧システムではモデルはデータセットとる．システム構成の全体図を図 2.1.1 に示す．

ともに API サーバに保存されており，これによって以下に挙げる問題が生じていた．

2.1

API

API はメディアサービスからのリクエストを処理し，推薦結果を提供するコンポーネントである．
推薦結果を作成するため文書のベクトル表現を保持しており，近傍探索によって推薦結果となる文書を選択する．
本システムではベクトル量子化を採用し，圧縮した文書のベクトル表現をすべてメモリ上に展開している．量子化によって 1 文書あたり数 10 バ
イトで文書ベクトルを表現することで，効率的に• データセット以上にモデルのデータ量が増大する場合があり，その場合メモリが圧迫される• 各 API サーバでデータセットの追加や更新を行っており，処理が非効率である• API サーバ間でデータの整合性を保つことが困難で，データセットの更新に失敗した
際のリカバリなど含め API は互いの状態を把握する必要がある

メモリ空間を利用している．詳細については「直これらの問題を解決するために開発されたのが積量子化に基づく高速な類似文書の探索」の章をDiﬀstore である．Diﬀstore では各メディアサー

参照されたい．

ビスのモデルと，直近で更新されたデータセット

量子化されたベクトル間の類似度を比較するたのみを持つ．前回の取得から更新のあったデータ

めには，量子化したベクトルとコードブックが必セットを定期的にダウンロードし，各文書のベク要である．一方，ベクトル化や次元圧縮の過程でトル化，および量子化を行う．それぞれのデータ発生する中間生成物は類似度の比較には不要であはデータベースへの書き出しに加えて一時的にメる．従来のシステムでは新しい文書の追加に備え

モリ上に保存され，各 API サーバからのポーリン*1 https://zookeeper.apache.org/*2 https://aws.amazon.com/jp/*3 https://avro.apache.org/

2 システム構成29

図 2.1.1 アーキテクチャの全体図．詳細は一部省略している．Batch process は定期的にメディアサービスのモデルを生成するコンポーネント，Cache はクライアントと API 間のキャッシュを行う
コンポーネントである．

グを受けて転送される．このアプローチによってが増えリソース不足に陥る場合に備え，API と同処理がモジュール化され，API サーバの役割を類様のメディアサービスの自動割り当てを導入する

似文書の探索に限定でき，容易にスケールできることを検討している．

ようになった．
また，Diﬀstore はメモリ使用量削減のため，ロー

2.3

Model Manager

カルディスクに保存してあるデータを必要に応じ背景で述べたように，本システムでは数百のメてメモリに展開している．頻繁にデータセットがディアサービスが動く想定でスケールを考える必更新されるメディアサービスのモデルはメモリ上要がある．全ての API サーバが全メディアサービ

に残り，逆に更新頻度の少ないメディアサービス

スのベクトルデータを保持するとメモリなどのリのモデルはディスクに戻される．これによって，ソース効率が悪いので，メディアサービスごとのメモリ空間が効率的に利用できるようになった．

リソース使用量に応じて適切な API サーバの数がところで，Diﬀstore がダウンした場合，最新の割り当てられている状態が望ましい．さらにはそ

文書はデータセットに追加されなくなる．ブログの割り当ての自動化までできていると，運用でのやニュースなどのメディアサービスでは，最新の負担が軽減される．Model Manager は上記の要望

記事がもっともアクセスされやすい傾向にあるたを元に開発された API のリソース管理，およびメ

め，新規文書が推薦結果に反映されないことは大ディアサービス割り当てのスケジューリングを行きな問題となりうる．このため Diﬀstore はマスうシステムである．Model Manager は API サー

ター・スレーブ構成で冗長化されている．現状はバのアプリケーションから各 API サーバ単位，もこの構成で充分だが，将来的にメディアサービス

しくは API サーバ内のメディアサービス単位でリソース使用状況をリアルタイムで収集しており，

2.1 大規模リアルタイムレコメンデーションを支えるスケーラブルなシステム基盤の構築

30

これを基にメディアサービスの割り当てを決定している．

API サーバのメディアサービスへの割り当ては
3 つの構成要素で実現されている．それぞれの役
割について下記に示す．

Trigger 割り当ての発動条件を表す．例えば「メディアサービスが追加されたとき」「メディアサービスの CPU 使用率が閾値より高いとき」などのような設定が可能である．

Action 割り当ての内容を表す．例えば「トリガ対象のメディアサービスを CPU 使用率の低
い API サーバに追加する」などのようなアクションを設定する．

を削除

4. serving ノード配下の旧モデル ID を削除
5. Model Manager に通知
6. assigned ノード配下に新規モデル ID を登録

7. API に通知
8. DB から新規モデルおよびベクトルデータを取得

9. serving ノー ド 配 下 に 新 規 モ デ ル ID を
登録

3 オートスケーリング
メディアサービスが頻繁に追加された場合，特Restriction Action の制限事項を表す．API サーにデータセットが大きいメディアサービスではリバのトータルメモリ使用量の上限や，メディ

ソース管理やそれに伴うサーバの増設をマニュア

アサービスに割り当てられた API サーバ数

ルで行うのは困難であり，運用コストがかかる．

の下限などを設定できる．

以上の内容を考慮して AWS のオートスケーリン

これらの構成要素はそれぞれ管理画面上で設定可能であり，柔軟かつ強固なリソース管理を実現
している．

グ機能を API とキャッシュ層で使用している．
リソースの使用量が閾値を超えた際に，サーバの増設からアプリケーションのデプロイ・起動までが必要に応じて自動で行われる．新たに起動され

2.4

ZooKeeper

ZooKeeper は分散システムのためのコーディネたサーバは Model Manager によって直ちにディ
スカバリされる．

ションサービスであり，階層的な名前空間へのデー
タ保存や書き込み結果の通知機能などを有してい
る．本システムでは各 API のメディアサービスへの割り当てやモデル更新の際に発生するタスクの制御で ZooKeeper を利用している．ZooKeeper
ではタスク管理用の assigned ノード，モデル管理用の serving ノードをそれぞれ保持しており，

assigned ノード配下に追加したモデル ID を持つモデルの更新が完了すると，assigned ノード配
下から serving ノード配下へモデル ID が移動する仕組みとなっている．モデル更新のタスク制御
フローを図 2.1.2 に示す．各処理の内容は次の通りである．

4 今後の課題
本章で紹介したシステムの一部はマスターとなるノードのリソース不足がボトルネックになりうる．API のノード数はクラウドプロバイダの限界までスケールできるが，現状ではリソースの割り当てを担う Model Manager のスケーラビリティには限界があるため，さらなる高負荷が予想される場合は分散処理構成に変える必要がある．
同様に Diﬀstore はモデルをローカルのメモリやディスク上に持つ必要があり，冗長化はされているがスケールできない現状にある．データ量の大きなモデルはディスク上に書き込んでおき，必1. assigned ノード配下の旧モデル ID を削除

要に応じてメモリに昇格させているが，メディア

2. API に通知サービスが増えるとディスク I/O の限界に陥る可

3. API 上から旧モデルおよびベクトルデータ

能性があるため，長期的には Diﬀstore も分散させ5 まとめ31

図 2.1.2 ZooKeeper によるモデル更新のタスク制御る必要がある．

ベクトル量子化によるデータ圧縮と近傍探索の高

また，本システムはバックエンドでベクトルデー

速化を始め，Diﬀstore による差分更新データの処タを持つデータベースに強く依存しており，DB理の分離や Model Manager によるリソース管理の負荷高騰などに起因して全体のレスポンスも遅によって旧システムの非効率な処理を改善できた．

れてしまう点も課題である．対策としてはデータ

またオートスケーリングを使って各コンポーネン

ベースを介さず量子化ベクトル同士の類似度を計トの冗長化をしており，耐障害性を担保している．

算することが考えられるが，文書の近傍探索の精

これらの仕組みによって新規メディアサービスの度は下がってしまうため現状では採用していない．

導入コストも改善でき，安定したシステムを提供する事が可能になった．

5 まとめ
本章では数百のメディアサービスが利用可能な
レコメンデーションシステムの構成を紹介した．

32

2.2

直積量子化に基づく高速な類似文
書の探索
福田 鉄也，Juhani Connolly，内藤 遥

概 要 本稿では，AJA Recommend Engine における類似文書の探索アルゴリズムについて紹介する．本システムが扱う問題では，探索対象の文書は頻繁に追加，または削除されるため，ある文書に対する類似した文書のリストはリクエストの都度計算される必要がある．一方で，数百のメディアサービスに対してそれぞれ数万から数十万の文書を保持する必要があるため，リクエストの都度すべての文書を素朴に走査することは計算量などの観点から現実的ではない．そこで我々のシステムでは，文書の tf-idf を特異値分解
によって低次元の密なベクトルとして表現した後，直積量子化と呼ばれる手法で省メモリかつ高速に近似探索できる形に変換して保持することで，これらの問題に対応している．また，実サービスのデータセッ
トに対して適用した際の精度について確認し，その結果について述べる．

Keywords

類似探索，次元圧縮，ベクトル量子化

1 はじめに類似文書の探索問題は，それぞれの文書を何らかの方法でベクトルとして表現した後，ベクトル*1

AJA Recommend Engine は株式会社 AJA が間の「類似度」の上位を返却する形で扱われるこ

提供する推薦システムのパッケージである．同レとが多い．我々のシステムにおいて，文書は頻繁

コメンドエンジンはニュースサイトやウェブマガに追加，あるいは削除されるため，返却する文書

ジンのようなメディアサービス向けに提供されてのリストはリクエストの都度計算される必要があおり，各メディアサービスにおける記事コンテンるが，数万のベクトルを素朴にすべて走査するこツの推薦などを実現している．本稿で紹介するシとは計算量の観点から現実的ではない．また，高ステムは AJA Recommend Engine のコンポーネ速に結果を計算するためベクトルの情報はすべてントとして開発された，文書の類似度に基づいた推メモリ上に保持したい一方で，256 次元のベクト薦システムである．このシステムはメディアサー

ルの各要素を 64 ビットの倍精度浮動小数点数の形

ビスの特性から次のような要件を満たすものとしで扱った場合 10 万件で 200MB 程度となるため，て設計されている．

これを数百のメディアサービスに対して保持する

1. 単一のシステムで数百のメディアサービス

ことはメモリ消費の面からも効率的ではない．
そこで我々のシステムでは，文書の tf-idf を特まで対応できる拡張性を持つこと

2. 1 つのメディアサービスあたり，数万から数十万件の文書を保持できること

3. 文書の頻繁な追加と削除に対応できること

異値分解によって低次元の密なベクトルとして表現した後，直積量子化と呼ばれる手法で省メモリかつ高速に近似探索できる形に変換して保持する*1 https://aja-kk.co.jp/service/aja-recommend-engine

2 ベクトル空間モデルに基づく文書表現

33

ことで，これらの問題に対応している．

2.2

特異値分解による次元圧縮

以降，2 節では，文書をベクトルとして表現する

前節で述べたベクトル空間表現では，全ての用ことで類似した文書を探索するための枠組みにつ語は全く異なる意味を持っているとして扱われる．

いて述べ，3 節では，直積量子化に基づくベクトル

しかし，たとえば同義語や類義語のような，異なる空間上で類似したペアを高速に近似探索するため意味として扱うべきではない用語も存在する．このアルゴリズムについて紹介する．また，4 節でこでは，同義語や類義語を考慮したより適切なベは，直積量子化を実際のサービスのデータセット

クトル表現を得る方法について説明する．

に対して適用した場合の精度について確認する．

用語数を m として，各列に式 (2.2.1) によって

なお，これらのアルゴリズムを活用した実際の与えられる文書ベクトルを持つ m × n の行列を考システム構築については「大規模リアルタイムレ

える．いま，任意の行列 C ∈ Rm×n に対する特異

コメンデーションを支えるスケーラブルなシステ

値分解が次の形で存在する．

ム基盤の構築」の章を参照されたい．

2 ベクトル空間モデルに基づく文書表

C = UΣV⊤

現
2.1(2.2.4)ベクトル空間モデル

例えば，ある用語が文書の中で繰り返し出現しているとき，その文書はその用語に強く関連していると考えられる．また，複数の文書に出現する
用語よりも，一部の文書のみに出現する用語の方が文書を特徴付ける上で重要であると考えられる．
これらを表現するため，tf-idf と呼ばれる各用語の各文書に対する複合的な重みを考える．tf-idf は，
用語 i，文書 j に対して次式で与えられる．

tf-idf i,j = tf i,j × idf i
ni,jtf i,j = ∑′′i ∈i ni ,jn
idf i = log
df i

ただし，U は m × m，V は n × n の直交行列であり，Σ は m × n の対角行列であるとする．また，

Σ の対角成分は大きい順に並んでいるとする．これらの対角成分は特異値と呼ばれる．
ここで，Σ から大きい順に d 個の特異値のみを残した d × d の対角行列 Σ̃ と，U と V から Σ̃ に対応する部分以外を取り除いた行列 Ũ ∈ Rm×d ，Ṽ ∈ Rn×d を考える．再構成行列 C̃ = ŨΣ̃Ṽ⊤ は(2.2.1)

ランク d の行列のうち，C との差分行列のフロベ(2.2.2)

ニウスノルムが最小のものになっている．

(2.2.3)

文書行列 C に特異値分解を適用した結果を考えると，Ṽ の各行は，それぞれ対応する文書を d 次

ただし，ni,j はある用語 i の文書 j 内での出現回

元の空間で表現したものといえる．C̃ は C に対し数，n は全文書数，df i は用語 i が出現する文書のて良い近似となっていることから，それぞれの文

数とする．

書間のコサイン類似度の相対的な値は保たれていこれにより，各文書を式 (2.2.1) で与えられる要ることが期待できる．加えて，用語と文書をそれ素を持ったベクトルと見なすことができる．このぞれ d 次元の空間で表現するにあたって，似たよ

ように，文書集合を共通のベクトル空間においてうな共起を持つ用語が 1 つの次元として表現されベクトルとして表現する方法はベクトル空間モデることで，前述の同義語の問題に対応できること

ルとして知られる．2 つの文書の類似度は，それが期待される．

ぞれのベクトル表現の間の類似度によって与えら

なお，特異値分解の計算コストは著しく大きい

れる．類似度としては，コサイン類似度などが利ため，我々のシステムでは乱択アルゴリズムに基用されることが多い．

づく方法 [2] を採用している．

2.2 直積量子化に基づく高速な類似文書の探索

34

3 直積量子化による近傍探索の高速・表現することを考えよう．このときセントロイドの数は C = 264 となり，最適化に C の数倍の学習

省メモリ化

データを必要とする k-means アルゴリズムを適用

2 節では文書をベクトルとして表現する手法について説明した．ここで，類似文書の探索は，あるベクトルに対してコサイン類似度が最大となるベクトルを探索する問題へと置き換えて考えるこ

することは現実的ではない．直積量子化 [4] はこのような問題に対応するための方法の 1 つである．
直積量子化では，入力ベクトル y を K 個の部分ベクトルに分割することを考える．

とができる．また，すべてのベクトルが単位ベク

y = [y(1) ; y(2) ; · · · ; y(K) ]トルに正規化されているとき，ユークリッド距離(2.2.7)を最小にするベクトルと，コサイン類似度を最大

ただし，y(k) ∈ Rd/K とする．すべてのベクトルにするベクトルは同一のものとなっている．すなの k 番目のブロックを含む部分空間は，コード

わち，ベクトルの集合 Y ⊂ Rd , |Y| = n から，ク

ブック C (k) によって量子化される．コードブック

エリベクトル x ∈ Rd とのユークリッド距離が最全体はその直積 C = C (1) × · · · × C (K) によって表小となるベクトル y∗ を見つけたい．

される．いまコードブック C (k) が任意の k についy∗ = arg min d(x, y)て C ∗ のセントロイドを持つとき，直積量子化に(2.2.5)y∈Yたといえる．

ただし d(·, ·) はユークリッド距離である．
式 (2.2.5) を総当りで計算した場合の計算量はO(nd) であり，n が大きいとき現実的ではない．
また，Y の空間計算量も O(nd) となり，メモリ上に保持するのは難しい．

3.1

よって C = (C ∗ )K 個のセントロイドを表現でき
直積量子化の利点は，コードブック全体を複数の小さなコードブックから構成していることである．小さなコードブックにおけるセントロイド数は少数で良いので，現実的な学習データ量で最適化することができる．また，各コードブックのセントロイド数 C ∗ = 256 のとき，これは 8 ビット

ベクトル量子化

ベクトル量子化は，ベクトルを圧縮して表現すで表現できる．ベクトルの分割数 K = 16 であれること で空 間計 算量の削減を図る手法 であ る．

ば 1 つのベクトルあたり 128 ビットで表現できる

量 子 化 器 q は ，ベ ク ト ル y ∈ Rd を ベ ク ト ル

ので，各セントロイドを保持することによるオーq(y) ∈ C = {ci ; i ∈ I} に写像する関数である．た

バーヘッドを考慮しても良いメモリ効率を得られ

だし，インデックスの集合 I = 1, . . . , C は有限でる．

あるとする．ci をセントロイドと呼ぶ．また，そ

3.3の集合 C をコードブックと呼ぶ．コードブック C
および関数 q は次式で定義される量子化誤差 E を最小化するものとして計算される．

E=

1 ∑
n

d(y, q(y))2

探索

クエリベクトル x とのユークリッド距離が最小となるベクトルを Y から近似探索する方法について，x の量子化を行う方法と，行わないものの 2 つ(2.2.6)y∈Y

これは k-means アルゴリズムによって局所解の 1つを求めることができる．

が考えられる．ベクトル x と y ∈ Y のいずれも量子化を行うとき，2 つのベクトル間の距離は次式で近似される．

d(x, y) ≈√∑d(q (k) (x(k) ), q (k) (y(k) ))2

k

3.2

直積量子化

(2.2.8)ベクトル量子化によって 128 次元のベクトルを

ただし q (k) は k 番目の部分空間における量子化器

64 ビット，すなわち，1 次元あたり 0.5 ビットでである．すべてのデータベースベクトル y に対し

4 精度評価

35てユークリッド距離を近似計算するときの計算量

クエリベクトル x の近似近傍探索は，qc (x) 近

は，セントロイド間の距離を事前計算すれば x の

傍のいくつかのパーティションに割り当てられた∗

量子化について O(C d)，各ベクトルに対する距

データベースベクトルのみを走査することによっ離の計算について O(nK) となる．

て実行される．

一方，データベースベクトル y については量子化するが，クエリベクトル x は量子化しない場合，

2 つのベクトル間の距離は次式で近似される．
√∑
d(x, y) ≈d(x(k) , q (k) (y(k) ))2(2.2.9)k

3.5

ベクトル分割の最適化

最小のユークリッド距離を持つベクトルを探索する問題は，入力空間の移動，回転に対して不変であるので，事前に入力空間を直交行列 R によって変換することで，より量子化誤差を小さくするようこの方法ですべてのデータベースベクトルに対しなベクトル分割を得られることが期待できる [1]．

てユークリッド距離を近似計算すると，先述の方

具体的には，下記のような最適化問題を考える．

法に比べて近似精度は良くなる一方，探索時のメモ
リ消費量は大きくなる．計算量については x と全min∗

R,C (1) ,...,C (K)てのセントロイドの距離の計算について O(C d)，
各ベクトルに対する距離の計算について O(nK)s.t.

q ∈ C = {c|Rc ∈ Cとなり，先述の方法と等しい．

3.4

粗い量子化による高速化∑

d(y, q(y))2

y∈Y
(1)

× · · · × C (K) , R⊤ R = I}
(2.2.12)

紙 幅 の 都 合 上 ，詳 細 は 省 略 す る が R と3.3 項で述べた方法は総当りの計算と比較して高速であるが，依然として計算量は n に依存しC

(1)

, . . . , C (K) を交互に更新することで局所解の1 つを求めることができる．

ている．そこで，事前に探索空間をパーティショ
ンに分割することで n に依存した探索時間を避けることを考える．ここでは，探索空間の分割にもベクトル量子化を利用する．まず，セントロイ
ド数が 1, 000 から 1, 000, 000 程度の粗量子化器

qc による粗い量子化を行う．その後，粗い量子化によって得られたセントロイドとの残差ベクトルr(y) = y − qc (y) に対して直積量子化を実行する．
つまり，データベースベクトル y は次式によって近似される．

y ≈ qc (y) + q(y − qc (y))

実サービスのデータセットにおけるパラメタ設定，およびベクトル分割の最適化の影響を確認するため，簡単な実験を行った．対象データとして，

Spotlight*2 からランダムに抽出した 10,000 件の文書データを用いた．アルゴリズム PQ が直積量子化によるもの，OPQ が直交行列 R によってベクト
ル分割を最適化した直積量子化である．クエリベ
クトルとの距離計算は，クエリベクトルの量子化(2.2.10)

また，クエリベクトル x と y の距離は次式にを行わない方法によって計算した．また，いずれの場合も特異値分解後のベクトルの次元数は 256に設定した．各設定における Recall@10 および

よって近似計算される．

Recall@100 を表 2.2.1 に示す．C ∗ , K が上がるに

d(x, y) ≈ d(x − qc (y), q(y − qc (y)))√∑
d((x − qc (y))(k) , q (k) ((y − qc (y))(k) ))2=k(2.2.11)*2 http://spotlight-media.jp/

4 精度評価

つれて近似精度が高まり，Recall@10，Recall@100が改善していることを確認できる．また，ベクト
ル分割の最適化によってもそれぞれの値が改善していることを確認できる．

2.2 直積量子化に基づく高速な類似文書の探索

36

表 2.2.1 各設定における MSE と Recall

アルゴリズムC∗

K

Recall@10

Recall@100

PQ

256

16

0.356

0.709

PQ

1024

16

0.439

0.777

PQ

256

32

0.673

0.943

PQ

1024

32

0.790

0.979

PQ

256

64

0.933

0.999

PQ

1024

64

0.982

1.000

OPQ

256

16

0.478

0.833

OPQ

1024

16

0.549

0.861

OPQ

256

32

0.747

0.966

OPQ

1024

32

0.814

0.987

OPQ

256

64

0.952

0.999

OPQ

1024

64

0.985

1.000

5 まとめ
本稿では，文書をベクトルとして表現することで類似した文書を探索するための枠組みと，ベク
トル空間上で類似したペアを高速に近似探索するための直積量子化と呼ばれるアルゴリズムについて紹介した．なお，文書を低次元のベクトル空間
で表現するための，より精緻な方法 [3, 5] の採用は今後の課題である．

参考文献[1] Ge, T. et al.: Optimized product quantization, IEEE Trans. Pattern Analysis andMachine Intelligence, Vol.36, No.4, pp.744–755 (2014).

review, Vol.53, No.2, pp. 217–288 (2011).
[3] Hill, F., Cho, K. and Korhonen, A.: Learning Distributed Representations of Sentences from Unlabelled Data, Proc. of the2016 Conference of the North American
Chapter of the Association for Computational Linguistics: Human Language Technologies, pp.1367–1377 (2016).
[4] Jégou, H., Douze, M. and Schmid, C.:
Product quantization for nearest neighborsearch, IEEE Trans. Pattern Analysis andMachine Intelligence, Vol.33, No.1, pp.117–
128 (2011).
[5] Kenter, T., Borisov A. and Rijke M.:
Siamese CBOW: Optimizing Word Embed-[2] Halko, N., Martinsson, P.G. and Tropp,dings for Sentence Representations, Proc.

J.A.: Finding structure with randomness:of the 54th Meeting of the Association

Probabilistic algorithms for constructing

for Computational Linguistics, pp.941–951

approximate matrix decompositions, SIAM

(2016).

37

3. データ分析

近年，Google や Yahoo!を初めとした Web サービスを運営している企業は膨大な数のユーザの行動をログデータとして収集し分析することで，サービスの改善やユーザターゲティングなどへの応用を進めている．また，Facebook などのソーシャルネットワーキングサービスでは，データをサービスの運営に役立てるだけでなく，サービスの使われ方を社会科学の観点から分析する研究も行われている．
当社はアメーバブログ・ピグパーティをはじめとした Web サービスに加えて，ソーシャル
ゲームや AbemaTV・AWA などの数多くのメディアサービスを開発・運用している．ユーザ行動の性質や解決すべき課題はサービス毎に異なるため，それぞれに応じた分析を行う必要がある．我々は日々生成される大量のログデータの記述統計的な分析に加えて，解決すべき課題に応じた統計的モデリングによる行動分析を行っている．これらの研究開発を通して, ユーザ行動を理解しサービスの改善や発展に貢献するとともに，ヒトや社会の理解に寄与し Web サー
ビスの活発な利用を促進する研究開発に取り組んでいる．

3.1 章では，インターネットテレビサービス AbemaTV におけるユーザの視聴行動のログについて，MARS モデルを適用してユーザのアクティブ度と継続離脱分析を行った事例について紹介する．

3.2 章では，音楽ストリーミングサービス AWA におけるユーザの聴取行動のログについて，
隠れマルコフモデルを適用して聴取トレンドの変化分析を行った事例について紹介する．

3.3 章では，Web サービスが生み出すビッグデータを用いてヒトや社会の理解にアプローチ
する社会科学の研究事例として，ソーシャルゲーム上での協調行動の分析および社会構造のモデル化と，ピグパーティにおけるソーシャルサポートの研究について紹介する．

38

3.1

インターネットテレビサービス
AbemaTV におけるユーザアクティビティ分析和田 計也

概 要 本稿では，株式会社 AbemaTV がインターネット上で展開している AbemaTV サービスを例にとり，サービスの継続・離脱分析を週単位で行う方法および，同時にユーザのアクティブ度を定量化する方法を提案する．具体的には分析モデルとして multivariate adaptive regression splines（MARS）を用い，翌週
アクティブ化日数を目的変数とした二項分布を仮定することで翌週単位での継続・離脱分析を実現しており，二項分布での成功確率 p をユーザのアクティブ度と定義することで定量化を実現している．また実ビ
ジネス上のデータでよく直面する，正規分布ではない分布のデータであっても MARS を用いることでうまくモデル化できることが示された．

Keywords

離脱分析，MARS，インターネットテレビ

1 はじめにのようなインターネット上のサービスは据置型のゲームやテレビと比べて，ユーザにとっては初期

インターネットの発展に伴い，インターネット

費用がかからないなどの理由により導入が簡単な上で展開されるサービスは従来の単純な Web サ

反面，サービス利用継続率が時間とともに低下しイトから Facebook*1 や Twitter*2 等の SNS に至ていきやすいという問題を抱えている [2]．そのたるまでたくさんの種類のサービスが出現してきた．

めユーザのサービス内での行動を分析することで最近では Netﬂix*3 や Hulu*4 , YouTube*5 などイン離脱しないような要因を発見してサービス改善に

ターネット上で動画を視聴できるサービスも展開

役立てることができれば，ユーザにとってもサーされており，80% 以上の人が利用したことがある

ビス運営側にとってもお互い良いことだといえよと答えるほど一般的になってきている [1]．株式会

う．本稿では AbemaTV サービスにおけるユーザ

社 AbemaTV でもインターネットテレビサービスのアクティブ度定量化およびユーザの継続・離脱

である AbemaTV サービス*6 を展開している．こ

行動を分析した事例を紹介する [3]．

れはインターネット上で，オリジナルの生放送コンテンツや，ニュース，音楽，スポーツ，アニメな本研究においてサービス側から求められた要件は以下の 2 件であった．

ど多彩な番組が楽しめる約 20 チャンネルをすべて無料で視聴することが可能なサービスである．こ*1 https://www.facebook.com*2 https://twitter.com*3 https://www.netflix.com*4 https://www.happyon.jp*5 https://www.youtube.com*6 https://abema.tv

1. 人が見て解釈可能であること

2 先行研究
2. 変数選択ができること
またその他に，AbemaTV の視聴データは正規分
布に従わないため以下の点も考慮する必要があった．

39
データをランダムサンプリングしたものである．

Hadoop*7 上の Hive テーブルに蓄積された AbemaTV の行動ログから，データ分析として用いることができるように HiveQL で集計・抽出・整形を行いデータを得た．ログ収集・解析システムの1. 正規分布を仮定しないこと
これらの要件を満たす手法として multivariate

概要を図 3.1.1 に示す．

3.2

モデル

adaptive regression splines（MARS）[4] を本研

ある週のユーザのアクティブ度を p とすると，究では用いた．また，AbemaTV はリニア配信で翌週アクティブ日数 Y は以下のような二項分布に

かつ 1 週間単位の番組表に従ってコンテンツを提従うと仮定する．

供するサービスであることから，翌週のアクティ

Y ∼ Binom(7, p)

ブ日数（≒サービス利用日数）を目的変数とした継続・離脱分析を行った．

アクティブ度 p は関数 f (x) で得られる実数値
を logit 変換することで 0.0 から 1.0 の範囲の確率

2 先行研究片岡らは POS データに Classiﬁcation by ag-

gregating emerging pattern（CAEP）を適用させて優良顧客の離脱予測モデルを構築した [5]．また，佐藤らはオンラインソーシャルゲームの行動
ログを混合正規分布によるクラスタリングにより，ユーザの離脱傾向を研究した [6]．藤井らは決定木値となる．

logit(p) = f (x)ここで，x は説明変数を並べた列ベクトルである．
関数 f (x) は線形和の場合では一般化線形モデ
ルとなるが，本研究で用いた MARS モデルでは各説明変数の効果量 βm に対しさらに hinge 関数からなる hm (x) が乗算されたものとなっている．

を用いて，CD 購買 POS データから継続購入すf (x) = β0 +るユーザのモデリングを行った [7]．このように，さまざまなデータに対して分類器を用いてユーザの離脱分析を行う事例は従来から行われている．

Chou らは MARS モデルで変数選択を行いニュー
ラルネットワークで予測モデルを構築する手法を用いて，乳がんの術後再発症パターンを腫瘍サイ
ズ等の所見データから作成した変数を用いてマイ
ニングを行った [8]．このように分類器に MARS
モデルを適用する事例も行われている．

M∑

βm hm (x)m=1

ここで，hm (·) は基底関数，M は分割後の説明変数の数（基底関数を有するモデルの個数）である．

1 つの変数 x に対して 1 つの境界点 c が設定され
h+ (x) = max(0, x − c) と h− (x) = max(0, c − x)の 2 つの基底関数となるが，まず全ての変数に対して機械的に境界点 c が多数設定され次に下記

Generalized Cross Validation（GCV）の値が最小になるように境界点 c と共に変数選択が行われる．

∑N

3 方法

GCV(m) =2
i=1 (yi − fm (xi ))(1 − m+e·(m−1)/2)2
N

利用したデータおよびデータ収集の方法

ここで，N はデータの総数，fm (·) は m 個の基底

本研究に利用したデータは表 3.1.1 に示す通り，関数を有するモデルである．また，e を含む項はペAbemaTV サービスの 2016 年 5 月 1 日から 2016

ナルティ項であり通常は e = 2 か e = 3 が使われ

年 6 月 2 日までの利用者のうち約 110 万人分の

る．

3.1

*7 http://hadoop.apache.org

3.1 インターネットテレビサービス AbemaTV におけるユーザアクティビティ分析

40

表 3.1.1 データの概要

サービス名AbemaTV

利用データ期間2016 年 5 月 1 日〜2016 年 6 月 2 日

分析利用ユーザ数

約 110 万人をランダムサンプリング

MARS モ デ ル の ﬁtting は 統 計 分 析 ソ フ ト ウ*8*9ブ日数から成る．構築されるモデルはこれらの説

ェア R の earth ライブラリ を用いて行った

明変数から，明日以降の翌週 1 週間のアクティブ[9, 10]．

化日数を予測するモデルとなっている．

本モデルは，ある日のアクティブ度が翌週のア
クティブ日数を決めるというやや強めの仮定を置いている．この仮定を置くことでユーザの継続・離脱につながる要因を示唆できるとともに，ユー
ザ毎にアクティブ度を算出できるようになる．こ4 結果
データの記述統計を表 3.1.3 および表 3.1.4 に示
す．

のアクティブ度はサービスの現状把握などにも利

総視聴時間に着目すると，平均値と中央値とに用できるためビジネス現場で使い勝手の良いモデ

大きな乖離が見られることと負の値をとらない量

ルとなっている．

であるにも関わらず標準偏差が平均値の 2 倍弱であることから，正規分布ではない分布形状である

3.3

利用した変数ことが容易に想像できる．したがって，この説明

MARS モデルで翌週のアクティブ化日数をモ

変数を用いたパラメトリックな線形モデルを使う

デリングする際に利用した変数を表 3.1.2 に示す．

べきではない．これが，本研究で分布形状によら翌週アクティブ日数が目的変数であり．それ以外ないノンパラメトリックな MARS を選択した理の変数は全て説明変数である．変数の概念図を図

由の 1 つである．

3.1.2 に示す．説明変数は，ある特定の 1 日の中でMARS モデルに ﬁtting した結果を表 3.1.5 に示の行動と，その日からみて前週 1 週間のアクティ

1
す．大まかな傾向として，○PC
視聴ではない (=図 3.1.1 ログ収集・解析システム概要*8 https://www.R-project.org*9 https://CRAN.R-project.org/package=earth

4 結果

41
表 3.1.2 利用変数の一覧

変数種別

変数詳細

変数レンジ

目的変数

翌 7 日間アクティブ化日数

0 〜 7(day)

前 7 日間アクティブ化日数

0 〜 7(day)総視聴時間

0 〜 1437(min)

視聴チャンネル数

0 〜 20(ch)番組予約数

0 〜 508

プラットフォーム

PC or スマートフォン

視聴チャンネルカテゴリ

ニュース系 or ドラマ系

説明変数

or アニメ系 or 音楽系
or スポーツ系 or バラ
エティ系 or 麻雀系 orその他
表 3.1.3 連続値変数の記述統計

平均値

中央値

標準偏差

最小値

最大値

翌週アクティブ日数

2.81

2

2.36

0

7

前週アクティブ日数

2.64

2

2.40

0

7

総視聴時間 (分)

43.80

12

88.19

0

1437

視聴チャンネル数

2.06

1

1.63

0

20

予約チャンネル数

0.34

0

2.96

0

508

2 アニメ系チャンスマートフォンアプリで視聴) ○えば PC でスポーツ系チャンネルとバラエティ系

3 総視聴時間 35 分以上 ○4 前週アクネルの視聴 ○

チャンネルと音楽系チャンネルとを合計 60 分視

5 視聴チャンネル数 2 つ以
ティブ日数 1 日以上 ○聴していて前週アクティブ日数が 2 日，予約数が6 予約番組数 2 つ以上の，○
1 ○
6 の特徴をもつ
上○

0 のユーザの場合は表 3.1.5 に記載の効果量を用いユーザのアクティブ度が高い（≒つまり翌週アクた計算によりアクティブ度 0.329（32.9%）である

ティブ日数が増加する）ということがわかる．例と算出される．

図 3.1.2 利用変数の概要

3.1 インターネットテレビサービス AbemaTV におけるユーザアクティビティ分析

42

表 3.1.4 カテゴリカル変数のデータ割合

TRUE

FALSE

プラットフォーム PC ﬂag

13.5%

86.5%

ニュース系番組視聴 ﬂag

23.7%

76.3%

ドラマ系番組視聴 ﬂag

11.9%

88.1%

麻雀系番組視聴 ﬂag

11.2%

88.8%

アニメ系番組視聴 ﬂag

51.5%

48.5%

バラエティ系番組視聴 ﬂag

21.9%

78.1%

音楽系番組視聴 ﬂag

12.9%

87.1%

スポーツ系番組視聴 ﬂag

19.9%

80.1%

その他番組視聴 ﬂag

18.1%

81.9%

表 3.1.5 MARS モデルによる変数の効果量

変数名

効果量

（切片）

−0.164プラットフォーム PC ﬂag−0.406

アニメ系番組視聴 ﬂag

0.172

h(35 − [総視聴時間])−0.018h([総視聴時間] − 35)

0.002h(1 − [前週アクティブ日数])−0.220h([前週アクティブ日数] − 1)

0.347h(2 − [視聴チャンネル数])−0.225h([視聴チャンネル数] − 2)0.055h(2 − [予約数])

5 まとめ−0.297

investgation/detail 1453.html (2015).
[2] 野島豪太，中村陽介，遠藤雅伸，三上浩司，

本 稿 で は MARS モ デ ル を 用 い て AbemaTV

近藤邦雄：アクションポイント制ソーシャル

サービスにおけるユーザの継続・離脱分析を行

ゲームにおける離脱要因の実証実験による検いユーザの離脱につながるような行動を示唆す

証，2014 年年次大会予稿集，日本デジタルることができた．また，同時に個々のユーザのア

ゲーム学会 (2014).

クティブ度を定量化する方法を提案した．今後も[3] 和田計也，福田一郎：インターネットテレビにユーザ行動の分析を通してサービスのさらなる発おけるユーザの視聴行動分析，日本マーケィ

展に貢献していきたい．

ング学会カンファレンス・プロシーディング
ス，Vol. 5, pp. 62–65 (2016).

参考文献[4] Friedman, J. H.: Multivariate adaptive regression splines, The annals of statistics,[1] MMD 研 究 所：無 料 動 画 ア プ リ に 関 する 利 用 実 態 調 査 ，https://mmdlabo.jp/

pp. 1–67 (1991).
[5] 片岡弘貴，森田裕之：異常検知を利用した優

参考文献

43

良顧客離脱予測モデル，2011 年秋季全国研究

adaptive regression splines, Expert Systems

発表大会要旨集，経営情報学会，p. 78 (2011).

with Applications, Vol. 27, No. 1, pp. 133–[6] 佐藤哲：計算統計を用いたオンラインゲーム

142 (2004).

ユーザのゲーム内行動解析，情報科学技術[9] Ihaka, R., and R. Gentleman: R: a lan-

フォーラム講演論文集（FIT2013）, Vol. 12,

guage for data analysis and graphics, Jour-

No. 3, pp. 229–230, (2013).

nal of Computational and Graphical Statis-[7] 藤井仰，森田裕之：年代別購買モデルを用い

tics, Vol. 5, No. 3, pp. 299–314, (1996).

た CD 購買データの分析，経営情報学会 全国[10] Milborrow, S.: earth: Multivariate Adap-

研究発表大会要旨集 2006 年度秋季全国研究

tive Regression Splines, (2017). R pack-発表大会, p. 8 (2006).

age version 4.6.0, Derived from mda:mars[8] Chou, S., Lee, T., Shao, Y. E. and Chen,by Trevor Hastie and Rob Tibshirani. Uses

I.: Mining the breast cancer pattern using

Alan Miller’s Fortran utilities with Thomas

artiﬁcial neural networks and multivariate

Lumley’s leaps wrapper.

44

3.2

音楽ストリーミングサービス
AWA における聴取傾向変化の
分析
高野 雅典

概 要 人は音楽聴取行動において，本来の趣味趣向に加え，気分や状況によって聴取する音楽を変える．その聴取傾向は大きな変化から小さな変化までありうる．サブスクリプション型音楽配信サービスにおいてユーザの聴取傾向を定量的に評価することは，ユーザの行動理解や，機能改善・推薦アルゴリズムのユー
ザ行動に与える影響を知るために重要である．そこで本研究では，ユーザの行動理解を目的とした楽曲聴取行動系列を階層的に分析する手法を提案する．この手法によって，聴取音楽タイプが変わる要因を複数の粒度で把握できる．提案手法は楽曲聴取の系列データについて階層的に隠れマルコフモデルを適用し，聴取行動の大きな変化と小さな変化を検出する．そして検出した楽曲聴取傾向の変化を利用してユーザの行動を分析する．

Keywords

音楽ストリーミングサービス，隠れマルコフモデル，ユーザモデリング1 はじめに「聴取傾向の変更はよいことなのか？」について知ることが目的である．

サブスクリプション型音楽配信アプリケーショ
ンは楽曲単位の購入ではなく，1 か月単位の定額契約で大量の楽曲聴取を提供する．したがって従来のビジネスモデルに比べて，ユーザは莫大な量の音楽に容易にアクセスできるようになった．ユー
ザに膨大な選択肢がある中で快適な楽曲聴取体験を提供するためには，ユーザの聴取行動を知ることが重要である [1]．
本研究はこの “聴取傾向の変更” の検出に焦点を当てる．ユーザの楽曲選択には様々な要素が影響する．同じユーザでも本来持つ趣味趣向に加えて様々な外因・内因によって，楽曲の聴取傾向を変える．例えば，いつもはジャズを聴いているが，昨日のテレビ番組の影響で J-POP を聴くなどである．
「どのぐらいの頻度でいつ起きるのか？」「アプ
リケーションのどの機能に起因して起きるのか？」

例えば，これによって推薦アルゴリズムの発見
性・多様性の評価 [2, 3] が期待できる．音楽聴取にクラウドサービスやサブスクリプション型のサービスを利用するユーザはデータをサービスサイドが持っていることから，未知の好みの音楽に出会うことを期待しており [4]，適切なタイミングで適切な楽曲やアーティストを推薦することは重要である．
そこで本研究はユーザの楽曲聴取ログから，そのユーザの聴取傾向とその変化を検出するモデルを提案する [5, 6]．サブスクリプション型音楽配信
アプリケーション “AWA*1 ” の聴取ログを利用した．一般に人の行動傾向は様々な粒度で解釈・考察することができる．楽曲聴取行動であれば，1 つの楽曲聴取が最も詳細な粒度であり，最も大きな
粒度は邦楽や洋楽などの聴いた楽曲の大きなジャ*1 株式会社 AWA が運営するサブスクリプション型音楽配信サービス（https://awa.fm/）．

2 データと手法

アーティストの
系列

45

西野カナ

状態 - 第2階層

浜崎
あゆみ

加藤
ミリヤ

清水翔太

邦楽女性

状態 - 第1階層

ONE OKROCK

平井大Metallica

邦楽男性

邦楽

Helloween

Queen

メタル

ロック

洋楽

図 3.2.1 モデル概要．第 1 階層はユーザの聴取系列を粗くモデル化し，第 2 階層は第 1 階層の各状態（ここでは邦楽と洋楽）を詳細化したモデル化をする．

ンル分類であろう．したがって人の行動傾向の理向をモデル化した．学習に利用する系列データは

解には階層的にモデル化が有効である [7, 8]．

ユーザ i の状態 zih が同じ状態を維持し続けた間

本研究では隠れマルコフモデル（HMM）[9] をを 1 つの系列とした．すなわち，あるユーザの第 1使ってユーザの聴取傾向とその変化をモデル化す

階層の状態の推移が {1, 1, 1, 2, 2, 1, 1} であった場

る．複数の粒度を階層的にモデル化するために，合，状態 1 に対する系列データが 2 つ（{1, 1, 1}，

HMM を階層的に作成する（図 3.2.1）．構築した{1, 1}），状態 2 が 1 つ（{2, 2}）が得られることにモデルを用いて，聴取傾向の変化について分析すなる．ユーザ i の j 番目の状態 z に対する第 2 階

る．

′
層の状態を zi,zと書く．こちらも第 1 階層と同様
jに AIC で状態数を決定する．

2 データと手法

本手法は再帰的に適用することでアーティストと状態が 1 対 1 に対応するまで階層を深くするこ本研究では HMM を階層的に用いることによっとができる．本研究では階層を 2 とした．HMMてユーザの聴取傾向を階層的にモデル化した（図の学習には Baum–Welch アルゴリズム，推定に3.2.1）．系列データとして各ユーザ i の各日時 hは Viterbi アルゴリズムを用いた．モデルの作成に最も聴いた*2 アーティストのリスト xi を用いに使用したデータは月額課金登録ユーザの内，聴た（h は月-日-時間，xi = {xih }）．例えば，ある

取系列長が 70 以上であるユーザからランダムサン

ユーザの系列は “[{5/11-10: 西野カナ }, {5/11-

プリングした後，その中から典型的なユーザとし

11: 加藤ミリヤ }, {5/11-17: KISS}, {5/13-11:て系列長が 25%ile から 75%ile の範囲のユーザのQUEEN}, {5/13-24, AAA}, …]” である（1 つめ

系列データを用いた（ユーザ数：2, 186）．期間はの項目は 5 月 11 日 10 時台に西野カナ氏の楽曲を

2017/03/01 から 2017/05/10 の 71 日間である．

最も聴いたことを表す）．音楽を聴取していない時間については系列データに含まない．

3 結果

最初に大きな粒度として第 1 階層の聴取傾向をモデル化した．学習に利用する系列データは前述

3.1

モデルの学習結果の xi である．HMM の隠れ状態数は 2 から 15 の

前節の方法でモデルを構築した結果，第 1 階層

内，最も AIC [10] が小さいものを採用した．ユー

は 11 状態，第 2 階層は各第 1 階層の状態に対して

ザ i の系列 xih に対応する第 1 階層の状態を zih

それぞれ 4，5，7，7，6，8，8，10，8，8，7 個のと書く．

状態の HMM が得られた．第 1 階層の各状態の代

次に第 1 階層の結果を用いて，第 2 階層の聴取傾*2 楽曲を最後まで再生した場合，聴いたと定義した．

表的なアーティストを表 3.2.1 に示す．

3.2 音楽ストリーミングサービス AWA における聴取傾向変化の分析

46

表 3.2.1 各状態の代表的なアーティスト
状態

1
2
3
4
5
6
7
8
9
10
11

3.2

Relax α Wave
Zedd
Bruno Mars

超特急

BIGBANG
Ms.OOJA

Ed Sheeran
Justin Bieber
CREAM
Twice
globe

Madonna
AviciiAriana Grande
AK-69
SHINeeSuperﬂy

浜崎 あゆみ加藤 ミリヤ倖田來未

清水 翔太
三代目 J Soul Brothers

ケツメイシ
西野 カナ

ちゃんみな

from EXILE TRIBEAAAONE OK ROCK

Acid Black Cherry
乃木坂 46

基本的な聴取傾向

このモデルを用いユーザの聴取傾向を分析する．

矢沢永吉

Coldplay
Flo Rida
Ed Sheeran
ANARCHY

Rihanna
Maroon 5
KREVA

防弾少年団

少女時代

クリス・ハート

JUJU

lecca
BENI

GReeeeN

平井 大

西野 カナ

Flower
AKB48
UVERworld

EXILE
Da-iCE
欅坂 46

EXILE THE SECOND
Aimer[Alexandros]のに対し，休日はライフスタイルが多様であるため傾向が弱まったと考えられる．

分析で使用したデータは，系列長が 2 以上である
月額課金登録ユーザからランダムサンプリングを

3.4

楽曲選択機能による聴取傾向への影響したユーザの系列データである（対象ユーザ数：

ではどのようにして聴取傾向の変化は発生して19, 929）．期間は 2017/04/01 から 2017/05/21 のいるのか？ AWA を含むサブスクリプション型

51 日間である．

音楽配信サービスでは，複数の楽曲選択機能を提ユーザの聴取傾向変化の典型例を図 3.2.2 に示供する．表 3.2.2 に機能ごとの聴取傾向変化数のす．聴取傾向の変化が検出されたことと，それが平均値を示した．各系列の状態にその状態で最もユーザの振る舞いの違いを表現可能であること

ユーザが利用した機能を紐付け，その状態と 1 つがわかる．聴取傾向推移率の頻度分布を図 3.2.3

前の状態が異なったときに，その機能によってに示す．状態をほとんど変えないユーザと変える状態が変化したとみなした．同表から第 1 階層・ユーザに 2 分化していたことがわかる．

第 2 階層ともに，オフラインライブラリからの再生（Oﬄine (Track)），自作プレイリスト（My3.3

曜日・時間による聴取傾向への影響

Playlist），ブックマーク（Favorite）によって聴取ではユーザはいつ聴取傾向を変化させるのか？

傾向の変化が発生しやすかったことがわかる．こそれについて知るために図 3.2.4 に各曜日の各時

れらはユーザが “自分自身で作成したリストから間ごとの状態推移回数の平均値を示す．同図から楽曲やプレイリストなどを選択し聴取する” 機能

平日の午前 7–9 時には聴取傾向の変化が発生しやである．推薦（Recommend）は中間よりやや聴取

すく，平日の深夜には発生しにくいことがわかる．

傾向を変化させやすい傾向にあるといえる．一方

これは通勤・通学時には多様な楽曲を聴く傾向にで検索（Search）や関連項目*3 といったユーザ自あること，または，朝には昨日の聴取傾向とは異身が未知の楽曲・アーティスト・プレイリストをなる傾向があることによると考えられる．休日は探索する行動によっては，聴取傾向の変化は発生

基本的には平日と同様であるが変化の程度は弱い．

しにくかった．また，第 1 階層・第 2 階層の変化

これは平日は多くのユーザが通学・通勤している

しやすさには強い相関があり，どちらか一方のみ*3 AWA では楽曲・アーティスト・プレイリストの詳細画面から関連したアーティスト・プレイリストの画面に遷移することが

できる．

3 結果

47

State

State

2−3
2−2
2−1
4 01

4 15

5 01

4−4
3−7
3−5
2−5
2−4
2−3
2−2
2−1
1−4
1−3
1−2

5 15

4 01

4 15

Datetime

5 01

5 15

Datetime(a) 安定した聴取傾向のユーザ(b) 頻繁に変化する聴取傾向のユーザ

図 3.2.2 聴取傾向推移の典型例．縦軸は状態を表す（第 1 階層の状態–第 2 階層の状態）．

3000

Frequency

Frequency

3000

2000

2000

1000

1000

0

0
0.0

0.2

0.4

0.6

State Change Ratio in Layer 1(a) 第 1 階層

0.0

0.2

0.4

0.6

0.8

State Change Ratio in Layer 2(b) 第 2 階層

図 3.2.3 状態変化率（系列長に対する状態推移頻度の比率）の分布．

を変化させやすい機能はなかった．以上からユー

ここで，B(n, p) は試行数 n，確率 p の二項分布，ザの聴取傾向変化は，ユーザが既知の楽曲・プレm は系列長，s は第 1 階層の聴取傾向変化数，s′

イリストの中から能動的に今まで聴いていたもの

は第 2 階層の聴取傾向の変化数である．m はサーとは異なる傾向のものを選択することに起因してビスの利用頻度を調整するための共変量である．

いたといえる．また，現状の AWA の機能には聴表 3.2.3 に式 (3.2.1) の分析結果を示す．第 1 階

取傾向の変化の大小どちらかのみが発生しやすい層の変化頻度 s の増加に応じて利用頻度は減少しような機能は存在しないといえる．

た一方で，第 2 階層の変化頻度 s′ の増加に応じて利用頻度も増加したことが分かる．すなわち大き3.5

聴取傾向変化の利用頻度への影響

な聴取傾向の変化ではなく，小さな聴取傾向の変聴取傾向の変化はユーザにどのような影響をおよぼすのか？ ここでは「次の 7 日間の楽曲聴取頻度 y 」に焦点を当て，次の一般化線形モデル（GLM）
を考える．

化をユーザに提供することがユーザの利用頻度を高めることに重要であることが示唆される．
では多様な楽曲を聴取することはユーザにどのような影響を与えるのか？ 前述のモデルと同様に次の 7 日間の楽曲聴取頻度 y に焦点を当て，次のy ∼ B(n, p)logit(p) = β1 m + β2 s + β3 s′(3.2.1)(3.2.2)

3.2 音楽ストリーミングサービス AWA における聴取傾向変化の分析

48

Mon

Tue

Wed

Fri

Sat

Sun

Thu

0.4

Number of State Change (Mean)

0.3
0.2
0.1
0.0
0

5

10

15

20

0.4
0.3
0.2
0.1
0.0
0

5

10

15

20

0

5

10

15

20

0

5

10

15

20

Time

図 3.2.4 各曜日の時間変化（黒: 第 1 階層，赤: 第 2 階層）．集計範囲は 2017/04 である．5 月は祝日を多く含むため除外した．

GLM を考える．
y ∼ B(n, p)logit(p) = β1 m + β2 c + β3 c′

ただし，聴取傾向変化とユーザの次週の利用頻(3.2.3)(3.2.4)度の分析によって，楽曲聴取傾向の大きな変化（例
えば邦楽女性歌手から洋楽への変化など）はユー
ザの利用頻度を下げ，小さな変化はユーザの利用

ここで c は第 1 階層の期間内に経験した状態の数，′

頻度を上げることが示された．したがって小さなc は第 2 階層の期間内に経験した状態の数である．

音楽の出会いを促進し続けることでユーザの満足

それ以外は式 (3.2.1) と同様である．

度を上げ，継続的な利用を促せると考えられる．

表 3.2.4 に式 (3.2.3) の分析結果を示す．第 1 階

これは小さな聴取傾向の変化を発生させやすく層の経験状態数 c の回帰係数 β2 は有意ではなかっする機能の重要性を示唆する．本研究の分析ではた．一方で，第 2 階層の経験状態数 c′ の増加に応小さな変化だけを発生させやすい楽曲選択機能はじて利用頻度も増加したことが分かる．すなわち存在しなかった．一般的な楽曲選択機能はブックある程度類似した範囲の楽曲群で様々な楽曲を聴マークなどの自作のリストや検索などの探索機能

取することがユーザの利用頻度を高めたといえる．

である．それらはシンプルで直感的にもわかりやすい機能であるため，“聴取傾向の小さな変化を発4 まとめ
本研究ではユーザの聴取傾向の変化について分析するために，HMM を階層的に構築するモデルを提案した．その結果，複数の粒度でユーザの聴取傾向の変化を検出できた．
検出した結果を用いて，ユーザ行動を分析した．
その結果，ユーザは通学・通勤時に楽曲聴取傾向を変化させがちであること，深夜には楽曲聴取傾向を変化させにくいことがわかった．したがって，
平日の午前 7–9 時に普段とは異なった楽曲やアーティストを推薦した場合，ユーザはその楽曲を受け入れやすいことが示唆される．そのためユーザの音楽との出会いを促進するには，この時間帯に施策を実行することが有効であろう．

生させやすくする” という仕組みを組み込むことは難しい．そのようなユーザの聴取傾向の制御はサービスサイドで提供するほうが容易であろう．
例えば聴取傾向の変化を目的とした推薦アルゴリ
ズムの導入などである．
本手法は推薦アルゴリズムの比較・評価にも用いることができる．推薦アルゴリズムにとって「ユーザに新たな情報を提供できるか？」という発
見性・多様性の評価は重用である [2, 3]．提案手法
を用いることで，推薦アルゴリズムのユーザの聴取傾向をどのように変化させやすいか（ユーザに音楽の出会いを提供できるか）を評価できる．それは推薦アルゴリズムの選択や改善の際に有効な指標になるであろう．

参考文献

49

表 3.2.2 再生機能ごとの聴取傾向変化数．全系列データ中に 2000 回以上登場した機能のみ示している．

Function

Layer 1

Layer 2Oﬄine (Track)

5.17

10.83

My Playlist

4.41

8.88

Favorite (Track)

3.94

8.37

Favorite (Playlist)

2.18

4.09

Recommend

1.70

3.46

Favorite (Album)

1.47

2.66

Favorite (Artist)

1.13

2.10

Genre Rankings

1.04

1.82

Featured Playlists

0.78

1.30

Search (Artist)

0.74

1.31

Artist’s Album

0.59

1.06

Search (Playlist)

0.51

0.89

Search (Album)

0.44

0.77

Track Information

0.42

0.78

Search (Track)

0.37

0.65

New Arrivals

0.36

0.66

Artist Information

0.35

0.63

Related Artists

0.31

0.62

Related Playlists

0.19

0.37

表 3.2.3 式 3.2.1 モデルによる分析結果

Explanation Value

CoeﬃcientStandard Error

t-valuep-valuem0.0147455

0.0001773

83.157Less than 2.0 × 10−16s−0.0049439

0.0011958−4.134

3.56 × 10−5s′0.0045396

0.0014170

3.204

1.36 × 10−3Intercept−1.0551538

0.0111014−95.047

Less than 2.0 × 10−16

参考文献[2] Ziegler, C., McNee, S. M., Konstan, J. A.
and Lausen, G.: Improving recommenda-[1] Zhang, B., Kreitz, G., Isaksson, M., Ubil-tion lists through topic diversiﬁcation, Pro-los, J., Urdaneta, G., Pouwelse, J. A.

ceedings of the 14th international conference

and Epema,

D.:on World Wide Web - WWW ’05, New

behavior

Spotify,

inUnderstanding user
2013

Proceedings

IEEE INFOCOM, IEEE, pp. 220–224,
doi:10.1109/INFCOM.2013.6566767 (2013).

York, New York, USA, ACM Press, p. 22,
doi:10.1145/1060745.1060754 (2005).
[3] Hurley, N. J.: Towards diverse recommen-

3.2 音楽ストリーミングサービス AWA における聴取傾向変化の分析

50

表 3.2.4 式 3.2.3 モデルによる分析結果

Explanation Value

CoeﬃcientStandard Error

t-valuep-valuen0.0141416

0.0001451

97.438Less than 2.0 × 10−16c0.0052646

0.0067718

0.777

4.36 × 10−1c′0.0071810

0.0025364

2.831

4.64 × 10−3Intercept−1.0903282

0.0146133−74.612

Less than 2.0 × 10−16

dation, RecSys Workshop: Novelty and Diversity in Recommender Systems (Keynote)(2011).

(2017).
[7] Kawazu, H., Toriumi, F., Takano, M., Wada,
K. and Fukuda, I.: Analytical method of web[4] Lee, J. H., Kim, Y. and Hubbles, C.: A Look

user behavior using Hidden Markov Model,

at the cloud from both sides now: an analy-

2016 IEEE International Conference on Big

sis of cloud music service usage, Proceedings

Data (Big Data), IEEE, pp. 2518–2524,of the 17th International Society for Music

doi:10.1109/BigData.2016.7840891 (2016).

Information Retrieval Conference, pp. 299–

[8] 垣内 弘太, 鳥海 不二夫, 高野 雅典, 和田 計也,

305, (2016).
[5] 高野 雅典, 鳥海 不二夫, 和田 計也, 福田 一郎:
楽曲聴取行動系列の階層化による聴取傾向変化の検出と行動分析, 第 188 回知能システム
研究発表会, (2017).

[6] Takano, M., Mizukami, H., Toriumi, F.,

福田 一郎： 潜在状態を用いたコミュニティ
サービスの分析，

人工知能学会全国大会，

4N2–OS–01b–3in2 (2017).
[9] Rabiner, L.: A tutorial on hidden Markov
models and selected applications in speech
recognition,

Proceedings

of

the

IEEE,

Takeuchi, M., Wada, K., Yasuda, M., andVol. 77, No. 2, pp. 257–286 (online),

Fukuda, I., Analysis of the Changes in Lis-

doi:10.1109/5.18626 (1989).

tening Trends of a Music Streaming Ser-[10] Witowski, V. and Foraita, D. R.: HMMpa:

vice, 2nd International Workshop on Appli-

Analysing accelerometer data using hid-

cation of Big Data for Computational Social

den Markov models, R package version 1.0

Science (workshop at IEEE BigData2017)(2014).

51

3.3

Web 社会の科学

高野 雅典

概 要 Web を介したオンラインコミュニケーションはいまや私達の日常生活の一部になっており，非常に多くのユーザが存在する．そこでは様々な社会現象が発生している．Web で発生する社会現象の理解・課
題解決をするためには，それらに科学的にアプローチしなければならない．我々は Web サービスが生み出すビッグデータを用いてヒトや社会の理解と問題解決に取り組んでいる．本稿では「ヒトの協調メカニズム」，「新たなコミュニケーションツールの登場が社会構造に与える影響」，「仮想社会におけるユーザ間のソーシャルサポート」の 3 つのテーマについて紹介する．

Keywords

計算社会科学，協調行動，社会的グルーミング，ソーシャルサポート，いじめ

1 はじめにを Web 社会のために利用することもできる．
本稿では秋葉原ラボで行っている Web に関わる

Web で発生している社会問題には，例えば炎社会科学研究について紹介する．まず最初にソー

上・ネットいじめ・フェイクニュース・社会的分断

シャルゲームデータを用いた協調行動研究についなどが挙げられる．これらは Web の外の社会にて述べる [36–38]．協調行動は進化生物学，行動経も影響を与える．炎上やネットいじめの被害者は済学，社会心理学などで幅広く研究されている学

精神的・金銭的な被害を被ることもあり [16, 39]，

際的なトピックであり，理論的・実験的な知見がフェイクニュースや社会的分断は選挙の結果にも多く存在する [20, 26]．ソーシャルゲーム上での影響する [18]．これらを解消・緩和し，Web 社会

協調行動を分析することで，それらの知見をゲーを快適にすることは，Web サービスの活発な利用

ムに適用すること，およびゲーム上での協調行動につながるはずである．したがってこれらを研究の知見が既存研究に新たな知見を加えることが期

し改善策を探ることは Web という世界でビジネ待できる．

スをしている当社にとっても重要である．

次にコミュニケーション方法が社会構造に与え

ビッグデータを利用した社会科学研究は “計算る影響の研究について述べる [32, 35]．そこでは社会科学” と呼ばれ，近年大きな盛り上がりを見コミュニケーションの方法がヒトの社会的行動にせている [19, 27, 33]．それは Web 社会を理解す

課す制約とそこから生まれる社会構造をモデル化

るだけでなく，これまで観測が難しかったヒトのする．これによって SNS などの新たなコミュニ

自由意志に基づく行動の詳細な分析を可能にする

ケーションツールの登場がヒトの社会に与える影ため，既存の社会科学を大きく進歩させる可能性

響について知ることを可能にする．

がある（図 3.3.1）．また，既存研究の膨大な知見*1 https://lp.pigg-party.com/

3.3 Web 社会の科学

52
知見の取り込み

シミュレーション

研究室実験

理解がしやすいソーシャル
ビッグデータのデータマイニングフィールドワーク
アンケート

発見した知見をフィードバック

現実に近い

抽象的

数理モデル

理解が煩雑

図 3.3.1 ソーシャルビッグデータの分析研究と既存のアプローチ

最後に仮想社会 “ピグパーティ*1 ” のソーシャル

協調行動の研究では，自分は損をしても相手にサポートの研究について紹介する [34]．ピグパー

利益を与えるという協調行動を定義するために，

ティには，いじめなど深刻な悩みを相談している（囚人のジレンマなどの）個体間の利害が明示的にユーザもいる．そのような場があることはユーザ存在するモデル [29] を作り，その数理・数値解析の Well-being（幸福度）につながっている可能性

や心理学実験をすることが多い．したがって，複がある．この研究では悩み相談がユーザの Well-

数のユーザの協調と競争要素が明示的にゲームのbeing に与える影響を検証し，それを促進するた

仕様に盛り込まれているオンラインゲームは協調

めにいつ・どこで・どのようにして起きているの行動の研究と相性がよいといえる [36–38]．例えかを分析する．

ば，協調行動の維持には，協調するか否かといった協調行動に関する戦略とともに，どの相手と相2 協調行動相互の協調はヒトをはじめとして多くの動物に見られる現象であり，社会を形成する上で重要な要素である [8, 31]．しかし，他個体に協力する利
他的な個体は，利己的な個体と相互作用すると搾取されてしまう．その結果，利己的な個体だけが高い利益を得ることになる．したがって利己的に振る舞うことは最適な戦略であり，相互の協調状
態は不安定なはずである [2]．それにもかかわらず
我々は社会的生活を営む上で相互に協調し合っている．したがって，ヒトは進化の過程において相互の協調関係を維持するメカニズムを獲得してき互作用をするかというパートナー選択が重要であることが，多くの理論研究 [3–5, 17, 28]，実験研
究 [7, 25, 42] で示されている．
そのような協調行動とパートナー選択行動に関する理論・実験研究で得られた知見の，より現実に近い（モデル化されていない・研究者によって動機づけられていない）環境における成立について証拠を得るために，秋葉原ラボではソーシャル
ゲーム「ガールフレンド（仮）」のデータを分析した [36–38]．協調行動を維持するためのメカニズ
ムは複数存在する [20, 26]．我々はそのうち環境応答移住 [17, 22, 23] と互恵的利他主義 [40] の 2
つに焦点を当ててそれぞれ分析した．

たはずである [11]．ヒトやその他の動物の協調行動を説明するために非常に多くの理論的・実験的研究がなされてきた [20, 26]．そのため，安定した

2.1

環境応答移住相互の協調状態を実現する仕組みや，それを促進

環境応答移住とは，個体が所属するグループ環

するような環境に関する知見が多く存在する．こ境に応じてグループを移住するという移住戦略のような協調行動研究は，協調の進化的起源解明である [17, 22, 23]．利他的な個体は利己的な個という理学的な意義があるとともに，ヒトの協調体よりも “利己的な個体の増加という環境悪化が行動の促進という面で社会的にも重要である．

与える悪影響” を受けやすい（搾取される）ため

2 協調行動53

悪い環境から移住をしやすい．その結果，利他的をして協調的な関係を築いていく．前述のようにな個体比率が高いグループと利己的な個体比率がソーシャルゲームではプレイヤーはグループ内で高いグループといった偏りが生まれる．利他的な互恵的な関係を構築しており，また，それがない個体は利他的な個体の多いグループに所属するた

ときには利他的なグループを求めてグループ間移め，利己的な個体からの搾取を避けることができ住をする．移住直後には初対面同士での相互作用

る．ソーシャルゲームではユーザはギルドと呼ばがあるはずである．我々は移住直後にプレイヤーれるグループに所属し，そのグループメンバーとがどのように互恵的な関係を築くいていくかにつ連携してゲームをプレイする．したがってグルーいて分析した [37]．その結果，移住直後のプレイ

プに利他的なプレイヤーがいることは重要である．

ヤーは利他的に振る舞いやすく，また，既存のグソーシャルゲームデータの分析の結果，利己的なループメンバーに対して（互いにコストも利益も個体が多いグループに所属する利他的な個体はグない軽量な方法で）コミュニケーションを頻繁にループを離脱して環境の良いグループを探してい取る傾向があることがわかった．ここからヒトはたこと，それによってグループの利他的な個体比

初対面では軽量なコミュニケーションをすること

率に偏りが生まれたことが示された [36]．すなわ

で相手の協調性に関する不確実性を軽減させていちプレイヤーは環境応答移住をして利他的なプレることが示唆される．これは，送信コストの低いイヤー同士の相互作用（協調）を維持していた．

シグナルはいくらでも嘘がつけてしまうため競合的な環境では成立しないという理論的な知見 [30]2.2

互恵的利他主義と異なる結果であり興味深い．

互恵的利他主義とは，後で見返りが期待できるならば，即座に自分の利益とならなくても，相手に対して利他的に振る舞うという戦略である．ソー
シャルゲームにおいても他プレイヤーに利他的な振る舞いをしたプレイヤーほど，その相手からもまとめ

利他的に振る舞われていた [38]．すなわちプレイ

このように環境応答移住 [36]・互恵的利他主

ヤーは互恵的利他主義に基づいた協調行動傾向が義 [37, 38] ともに，ゲーム内でも有効に働き，ユー示された．また，互恵的利他主義を促進させるもザ間の協調行動を促進させていた．

のとして，相手に直接利益を与える協調行動だけ

SNS における，情報提供（コメントの投稿）とでなく，システム上で明示的な利益もコストも発それに対する反応（投稿に対する Twitter の “リ

生しない単純なメッセージ（社会的グルーミング

ツイート” や Facebook の “いいね” など）に対し（次節参照））も重要であることが示された．

て，メタ規範ゲームという枠組みを適用すること

互恵的利他主義に基づく協調関係を構築するにで，協調行動として扱えるようにした理論研究もは初対面でも互いに利他的に振る舞う必要があ存在する [14, 21]．明示的な競争と協調という要る [2]．しかし初対面の相手に利他的に振る舞う素が存在するオンラインゲームだけでなく SNS 上のはリスクが高い．相手が協調的か否かに関するでの情報拡散現象にも協調行動研究の知見が活か

情報がないからである．このような状況でもヒトせる可能性がある．

は初対面において，一切の相互作用なしに利他的

このようにソーシャルメディアやオンラインに振る舞いがちであることは実験的に示されていゲームのユーザ同士の協力関係について分析する

る [10, 24, 25, 42]．一方で実際にはヒトはまったことで，ヒトの協調行動についての知見が得られく相手の情報なしに利他的行動をする意思決定をる．また，そこで得られた知見や先行研究の知見することはない．相手を観察し，あいさつや雑談をサービスの仕組み作りに活かせるであろう．

3.3 Web 社会の科学

54

3 コミュニケーションツールと社会構
造係の構築・維持のために両者の方法を効果的に使用していると考えられる．ヒトは相手との社会関係が強い（親密である）ほど利他的に振る舞いがヒトの社会構造は，社会関係を構築・維持する

ちであるが，1 人が協力できる回数には限りがある

社会的グルーミングの進化と発明によって変化しためである [12, 13, 37, 38]．一方で，弱くても多てきた．近年の SNS の流行によっても我々の社会は大きく変化したはずである．SNS のような新しいコミュニケーションツールによる社会的グルー
ミングは，対面の会話や毛づくろいなどの原初的な社会的グルーミングと何が異なり，それによっくの社会関係を持つことは情報収集の上で重要である [6, 9]．なぜならば弱い社会関係（弱い紐帯;

weak tie）を持つ 2 者には共通の社会関係が少な
いため，共通の社会関係の多い強い社会関係に比べて新しく多様な情報を獲得しやすいからである．

てどのように社会に影響を与えたのか？ 新しい社
会的グルーミングの出現が社会構造にどのように

4 仮想社会のソーシャルサポート

影響するかを理解することは，ヒト社会の知識を提供する．

社会的生活の中でヒトは他者を様々な形で支援

我々は原初的な方法（対面の会話やチャクマヒヒ

し，また支援を受ける．この物質的・心理的支援の毛づくろいなど）から現代的な方法（SNS や E-

をソーシャルサポートと言う [41]．ソーシャルサmail）までを含む多様なコミュニケーションデー

ポートのうち相手への共感・愛着・尊敬を示すこ

タセットを分析し，それらを説明するモデルを構とによって，相手のストレスが軽減される行為を築した [32, 35]．そのモデルの解析の結果，2 つの“情緒的サポート” と言う．

タイプの社会的グルーミング（手の込んだ方法とソーシャルサポートはコンピュータを介したコ

軽量な方法）を発見した（図 3.3.2） [32]．手の込

ミュニケーションでも発生する [1, 15]．我々はイんだ社会的グルーミングは原初的な方法であり，

ンターネット上の仮想的な社会 “ピグパーティ”

親密な社会関係を構築するのに有効である．一方（図 3.3.3）におけるソーシャルサポートに焦点をで，軽量な社会的グルーミングは多くの弱い社会当てて研究した [34]．特にユーザの “現実社会の関係を持つことを容易にする近代的な方法である．

いじめ” に関する相談に着目した．ピグパーティ

各方法において構築・維持される社会関係の数は若年層に利用者が多く，また，解決すべき非常と強さのトレードオフ C = N ma [35] によって両に重大な問題だからである．

者は区別される．ここで，C は社会的グルーミン

若年層において日本でよく使われている LINE

グに掛けるコスト，N は社会関係の数，m は平均や Facebook は現実の社会関係を多く含み現実の的な社会関係の強さ，a が N と m のトレードオ

延長線上にある．一方でピグパーティは両者に比フの強さである．手の込んだ社会的グルーミング

べて現実社会とは切り離されており，独自の社会は a < 1，軽量な社会的グルーミングは a > 1 に関係が多い．

なった．

いじめ相談の効果を分析した結果，相談をした

このトレードオフはその社会的グルーミング方

ユーザ・されたユーザともにピグパーティの利用法を使うヒトの微視的な振る舞いに制約を与える．

頻度が高くなることがわかった．これはいじめ相

その結果，社会的グルーミングの種類によって巨談をする・される行動がユーザにとってよい経験

視的な社会構造も影響を受ける．軽量な社会的グであることを示すといえる．

ルーミングによる社会構造は手の込んだ社会的グ

既知の社会関係（友人）が多い閉じたチャット

ルーミングによるものよりも幅広くかつ薄くなる．

スペースでは，“泣く・生きる・逃げる・嫌・お母

現代の複雑な社会において，ヒトは多様な社会関さん・お父さん” など感情的な言葉や家族に関す5 まとめ55
C%>(&/)AB.#/)*%+,(4(5!

?&,.,4@()AB.#/)*%+,(4(5);)?&,.#'(5)*%+,(4(5!
:#&&%1);)<((6)*%+,('=!
8,>();)*2#""%1)*%+,('=!

!"#$%&#'()*%+,#")-&%%.,/0)1,'2)*'&%/0)*%+,#")3("#4%/52,65!

7,02'1(,02')*%+,#")-&%%.,/0)1,'2)8(#9)*%+,#")3("#4%/52,65!

図 3.3.2 コミュニケーション方法と社会構造の関係

図 3.3.3 ピグパーティ

る単語を含む発言が多く見られ，踏み込んだ内容

したがって，これらの基礎研究で得られた知見はの会話がなされていることが示唆された．一方でソーシャルサポートによる Well-being 向上に活か

比較的開いたチャットスペースでは初対面同士のすことができる．また基礎研究による一般性の高会話が多く，“いじめ・殴る・学校・先生” などのい知見は他の Web 社会においても利用可能であ

説明的な単語が多く見られた．

ろう．

このように仮想的な社会においてもソーシャル

Web はごく最近にヒトが作った社会的空間であサポートが自発的に発生し，それがユーザにとっり，それがヒトの行動や社会に与える影響は未知てよい影響を与えていることがわかった．さらになことが多い．またそれを知るためのデータは多研究を進めこれらを促進する要因が分かれば，そくは企業が管理しており，多くはユーザの個人情れによるユーザの Well-being 向上が期待できる．

報を含むため，外部で研究に利用可能なデータはまた，深刻な問題を抱えるユーザに対しては臨床限定的である．したがって，運営企業においても心理士などの専門家による介入というアプローチ

売上やユーザ体験の向上を狙った応用研究だけでも考えられる．

なく，ヒトや Web 社会の性質理解を目的とした基礎研究を進め，その知見を論文として公開するこ5 まとめとが重要であると考えている．その知見によって安全で快適な Web 社会を実現することは，Web

本稿では秋葉原ラボで実施している計算社会科

上でビジネスをする企業にとっても良い効果をも学研究について紹介した．ヒトや Web 社会理解

たらすはずである．それは基礎・応用研究を発展のための基礎研究として協調行動研究と社会構造させうるオープンデータ化にもつながると考えらとコミュニケーションツールの研究を挙げ，ユーれる．

ザの Well-being 向上を狙った応用研究としてソー
シャルサポートの研究を紹介した．

参考文献

協調行動はソーシャルサポートの一種であるため，協調行動研究は相互にソーシャルサポートし合[1] Ando, R., Takahira, M. and Sakamoto,う関係構築のためのヒトの社会的振る舞いについA.: Eﬀects of Internet Use on Junior Highて知見を与える．また，社会構造とコミュニケー

School Students’ Loneliness and Social Sup-

ションツールはそのソーシャルサポートに向いて

port, The Japanese Journal of Personality,

いるコミュニケーションツールの条件を示唆する．

Vol. 14, No. 1, pp. 69–79 (2005).

3.3 Web 社会の科学

56[2] Axelrod, R.: The Evolution of Cooperation:[12] Haan, M., Kooreman, P. and Riemersma,

Revised Edition, Basic Books (2006).

T.: Friendship in a Public Good Exper-[3] Chen, X., Fu, F. and Wang, L.: Social Tol-

iment, IZA Discussion Paper, Vol. 2108

erance Allows Cooperation to Prevail in an
Adaptive Environment, Physical Review E,
Vol. 80, No. 5, p. 051104 (2009).

(2006).
[13] Harrison, F., Sciberras, J. and James, R.:
Strength of Social Tie Predicts Cooperative[4] Chen, X., Szolnoki, A. and Perc, M.: Risk-

Investment in a Human Social Network.,

Driven Migration and the Collective-Risk

PLOS ONE, Vol. 6, No. 3, p. e18338 (2011).

Social Dilemma, Physical Review E, Vol. 86,[14] Hirahara, Y., Toriumi, F. and Sugawara,

No. 3, p. 036101 (2012).

T.: Evolution of Cooperation in SNS-norms[5] Damore, J. A. and Gore, J.: A Slowly

Game on Complex Networks and Real So-

Evolving Host Moves First in Symbiotic In-

cial Networks, Proceedings of The 6th Inter-teractions, Evolution; International Jour-

national Con- ference on Social Informatics

nal of Organic Evolution, Vol. 65, No. 8,(SocInfo), Springer International Publish-

pp. 2391–8 (2011).

ing, pp. 112–120 (2014).

[6] Eagle, N., Macy, M. and Claxton, R.: Net-[15] Hobbs, W. R. and Burke, M. K.: Connec-

work Diversity and Economic Development,

tive Recovery in Social Networks after the

Science, Vol. 328, No. 5981, pp. 1029–31

Death of a Friend, Vol. 1, p. 92 (2017).

(2010).

[16] Hosseinmardi, H., Raﬁq, R. I., Li, S., Yang,[7] Fehl, K., van der Post, D. J. and Semmann,Z., Han, R., Mishra, S., Lv, Q., A Compari-

D.: Co-Evolution of Behaviour and Social

son of Common Users across Instagram andNetwork Structure Promotes Human Coop-

Ask.fm to Better Understand Cyberbully-

eration, Ecology Letters, Vol. 14, No. 6, pp.

ing, 2014 IEEE Fourth International Con-

546–51 (2011).

ference on Big Data and Cloud Computing,[8] Fehr, E. and Fischbacher, U.: The Nature of Human Altruism, Nature, Vol. 425,
No. 23, pp. 785–791 (2003).
[9] Granovetter, M.: The Strength Of Weak
Ties,

American Journal of Sociology,

Vol. 78, pp. 1360–1380 (1973).

pp. 355-362 (2014).
[17] Ichinose, G. and Arita, T.:

The Roleof Migration and Founder Eﬀect for the
Evolution of Cooperation in a Multilevel
Selection Context, Ecological Modelling,Vol. 210, No. 3, pp. 221–230 (2008).

[10] Grujić, J., Röhl, T., Semmann, D., Milin-[18] 小林哲郎, ソーシャルメディアと分断化する

ski, M. and Traulsen, A.: Consistent Strat-

社会的リアリティ, 人工知能学会誌, Vol. 27,

egy Updating in Spatial and Non-Spatial

No. 1, pp. 51–58 (2012).

Behavioral Experiments Does Not Promote[19] Lazer, D., Pentland, A., Adamic, L., Aral,

Cooperation in Social Networks, PLOS

S., Barabasi, A.-L., Brewer, D., Christakis,

ONE, Vol. 7, No. 11, p. e47718 (2012).

N., Contractor, N., Fowler, J., Gutmann,[11] H, Barkow, J., Cosmides, L. and Tooby, J.:

M., Jebara, T., King, G., Macy, M., Roy,The Adapted Mind: Evolutionary Psychol-

D. and Van Alstyne, M.: Computationalogy and the Generation of Culture, Oxford

Social Science, Science, Vol. 323, No. 5915,

University Press (1995).

pp. 721–723 (2009).

参考文献

57

[20] Nowak, M. A.: Five Rules for the Evolution[31] Smith, J. M. and Szathmáry, E.: The Ori-of Cooperation, Science, Vol. 314, No. 5805,

gins of Life: From the Birth of Life topp. 1560–1563 (2006).

the Origin of Language, Oxford University[21] Okada, I., Yamamoto, H., Toriumi, F. and

Press (2000).

Sasaki, T.: The Eﬀect of Incentives and[32] Takano, M.: Two Types of Social Groom-Meta-incentives on the Evolution of Co-

ing discovered in Primitive and Modern

operation, PLOS Computational Biology,

Communication Data-Sets (2017). arXiv:

Vol. 11, No. 5, p. e1004232 (2015).

1707.08517[22] Pepper, J. W.: Simple Models of Assort-[33] 高野雅典: ソーシャルビッグデータで理解

ment through Environmental Feedback, Ar-するヒトと社会の性質，電子情報通信学会

tiﬁcial Life, Vol. 13, No. 1, pp. 1–9 (2007).

基礎・境界ソサイエティ Fundamentals Re-[23] Pepper, J. W. and Smuts, B. B.: A Mech-view， Vol. 10, No. 4, pp. 275–281 (2017).

anism for the Evolution of Altruism among[34] 高野雅典：仮想社会におけるソーシャルサ

Nonkin: Positive Assortment through En-

ポート効果の検証: ピグパーティにおけるいvironmental Feedback, The American Nat-

じめ相談，教育工学研究会（発表予定）(2017).

uralist, Vol. 160, No. 2, pp. 205–13 (2002).

[35] Takano, M. and Fukuda, I.: Limitations[24] Peysakhovich, A. and Rand, D. G.: Habitsof Time Resources in Human Relation-of Virtue: Creating Norms of Coopera-

ships Determine Social Structures, Palgravetion and Defection in the Laboratory, SSRN

Communications, Vol. 3, p. 17014 (2017).

Electronic Journal (2013).

[36] Takano, M., Wada, K. and Fukuda, I.: En-[25] Rand, D. G., Arbesman, S. and Chris-

vironmentally Driven Migration in a Social

takis, N.: Dynamic Social Networks Pro-

Network Game, Scientiﬁc Reports, Vol. 5,

mote Cooperation in Experiments with Hu-

p. 12481 (2015).

mans, Proceedings of the National Academy[37] Takano, M., Wada, K. and Fukuda, I.:

of Sciences, Vol. 108, No. 48, pp. 19193–

Lightweight Interactions for Reciprocal Co-

19198 (2011).

operation in a Social Network Game, Pro-[26] Rand, D. G. and Nowak, M. A.: Human

ceedings of The 8th International Confer-

Cooperation, Trends in Cognitive Sciences,ence on Social Informatics (SocInfo), pp.

Vol. 17, No. 8, pp. 413–425 (2013).

125–137 (2016).

[27] 笹原和俊：私のブックマーク「計算社会科学[38] Takano, M., Wada, K. and Fukuda, I.:(Computational Social Science)」，人工知能

Reciprocal Altruism-based Cooperation in

学会誌， Vol. 30, No. 6, pp. 856–859 (2015).

a Social Network Game, New Generation[28] Santos, F., Pacheco, J. and Lenaerts, T.:

Computing, Vol. 34, No. 3, pp. 257–271

Cooperation Prevails When Individuals Adjust their Social Ties, PLOS Computational
Biology, Vol. 2, No. 10, p. e140 (2006).

(2016).
[39] 田中辰夫, 山口真一: ネット炎上の研究, 勁草
書房 (2016).

[29] Smith, J. M.: Evolution and the Theory of[40] Trivers, R. L.: The Evolution of Recipro-

Games, Cambridge University Press (1982).

cal Altruism, Quarterly Review of Biology,[30] Smith, J. M. and Harper, D.: Animal Signals, Oxfold University Press (2003).

Vol. 46, pp. 35–37 (1971).
[41] Turner, R. J., Turner, J. B. and Hale,3.3 Web 社会の科学

58
W. B.: Social Relationships and Social Sup-

Partner Updating, Proceedings of the Na-

port, Springer, Cham, pp. 1–20 (2014).

tional Academy of Sciences of the United[42] Wang, J., Suri, S. and Watts, D. J.: Co-

States of America, Vol. 109, No. 36, pp.

operation and Assortativity with Dynamic

14363–14368 (2012).

59

発表一覧

書籍・解説記事• 高野雅典：ソーシャルビッグデータで理解するヒトと社会の性質，電子情報通信学会基礎・境界ソ
サイエティ Fundamentals Review， Vol. 10, No. 4, pp. 275–281 (2017).

• R サポーターズ，安部晃生，市川太祐，酒巻隆治，戸嶋龍哉，福島真太朗，和田計也，里洋平，津田真樹：パーフェクト R，技術評論社 (2017).

• 高野雅典：私のブックマーク 「仮想世界の社会科学」，人工知能， Vol. 32, No. 2 (2017).
• 佐藤洋行，原田博植，里洋平，和田計也，早川敦士，倉橋一成，下田倫大，大成浩子，奥野晃裕，
中川帝人，長岡裕己，中原誠：改訂 2 版データサイエンティスト養成読本：プロになるためのデータ分析力が身につく！，技術評論社 (2016).

• 福田一郎，鈴木俊裕，善明晃由，高野雅典，藤坂祐介：サイバーエージェントのデータ活用のための R&D 体制と取組み（〈特集〉イノベーションと AI 研究），人工知能， Vol. 30, No. 3, pp.

318–324 (2015).
• 鈴木俊裕，梅田永介，柿島大貴：HBase 徹底入門 Hadoop クラスタによる高速データベースの実
現，翔泳社 (2015).

• 高野雅典，和田計也，福田一郎：ソーシャルゲームプレーヤの協調行動の分析（〈特集〉エンター
テイメントにおける AI），人工知能， Vol. 30, No. 1, pp. 74–82 (2015).

• 酒巻隆治，里洋平，市川太祐，福島真太朗，安部晃生，和田計也，久本空海，西薗良太：データサ
イエンティスト養成読本: ビジネスデータ分析の現場で役立つ知識が満載！：R 活用編，技術評論社 (2015).

• 佐藤洋行，原田博植，下田倫大，大成浩子，奥野晃裕，中川帝人，橋本武彦，里洋平，和田計也，早川敦士，倉橋一成：データサイエンティスト養成読本：ビッグデータ時代のビジネスを支えるデータ分析力が身につく！，技術評論社 (2013).

• Sau Sheong Chang(著)，瀬戸山雅人 (翻訳)，河内崇 (翻訳)，高野雅典 (翻訳)，橋本吉治 (翻訳)：R と Ruby によるデータ解析入門，オライリー・ジャパン (2013).

発表一覧

60

論文誌・国際会議• M. Takano, H. Mizukami, F. Toriumi, M. Takeuchi, K. Wada, M. Yasuda, and I. Fukuda:“Analysis of the Changes in Listening Trends of a Music Streaming Service,” 2nd International
Workshop on Application of Big Data for Computational Social Science (workshop at IEEE
BigData2017), 2017.
• M. Murase, M. Takano, R. Suzuki, and T. Arita: “A Statistical Analysis of Behavioral Bursts
Occurring in a Social Network Game,” 2nd International Workshop on Application of Big
Data for Computational Social Science (workshop at IEEE BigData2017), 2017.
• M. Takano and I. Fukuda: “Limitations of Time Resources in Human Relationships Determine
Social Structures,” Palgrave Communications, Vol. 3, 17014, 2017.
• Y. Hirano, F. Toriumi, M. Takano, K. Wada, and I. Fukuda: “Detection of Dangerous Interactions in Online Chat Services,” 4th International Workshop —Transformation of humanbehavior under the inﬂuence of Infosocionomics Society—, 2017.
• T. Zenmyo, S. Iijima, and I. Fukuda: “Managing a Complicated Workﬂow based on Dataﬂowbased Workﬂow Scheduler,” 2016 IEEE International Conference on Big Data (IEEE BigData
2016), short paper, 2016.
• H. Kawazu, F. Toriumi, M. Takano, K. Wada, and I. Fukuda: “Analytical method of web user
behavior using Hidden Markov Model,” Workshop Application of Big Data for Computational
Social Science (workshop at IEEE BigData2016), 2016.
• M. Takano, K. Wada, and I. Fukuda: “Lightweight Interactions for Reciprocal Cooperation ina Social Network Game,” The 8th International Conference on Social Informatics (SocInfo),
2016.
• M. Takano, K. Wada, and I. Fukuda: “Reciprocal Altruism-based Cooperation in a Social
Network Game,” New Generation Computing, 34, pp. 257–271, 2016.
• R. Y. Shtykh: “Apache Ignite as a Data Processing Hub,” In-Memory Computing Summit,2016.
• 高野雅典, 和田計也, 福田一郎：“ソーシャルゲームにおける互恵的利他主義に基づく協調行動”, 人
工知能学会論文誌, Vol.30, No.6, 2016 (New Generation Computing の連携論文; 和訳版).

• T. Suzuki and H. Kakishima: “HBase @ CyberAgent,” HBaseCon 2015, 2015.
• M. Takano, K. Wada, and I. Fukuda: “How Do Newcomers Blend into a Group?: Studyon a Social Network Game,” 3rd International Workshop on Data Oriented Constructive
Mining and Multi-Agent Simulation (DOCMAS) & 7th International Workshop on Emergent
Intelligence on Networked Agents (WEIN) (workshop at WI-IAT 2015), 2015.
• R. Y. Shtykh and M. Makita: “Adopting Semantic Similarity for Utterance Candidates Discovery from Human-to-Human Dialogue Corpus,” Future and Emerging Trends in Language
Technology (FETLT 2015) Workshop, 2015.
• M. Takano, K. Wada, and I. Fukuda: “Environmentally Driven Migration in a Social Network
Game,” Scientiﬁc Reports, 5, 12481, 2015.
• R. Y. Shtykh and T. Suzuki: “Distributed Data Stream Processing with Onix,”IEEE Inter-61
national Conference on Big Data and Cloud Computing, Sydney, Australia, 2014.

国内学会／セミナー• 高野雅典：“ソーシャルビッグデータ・オープンデータによる社会構造変化の発見”, 第 3 回ウェブ
サイエンス研究会（招待講演）, 2017.

• 高野雅典, 角田孝昭：“仮想社会におけるソーシャルサポート効果の検証 〜 ピグパーティにおけるいじめ相談 〜”, 教育工学研究会, 2017.

• 角田孝昭：“アメーバブログの分析事例: もっと読みたくなるサービスを届けるためのエントリ分
析”, 第 10 回 Web とデータベースに関するフォーラム（WebDB Forum 2017）, 2017.

• 高野雅典, 鳥海不二夫, 和田計也, 福田一郎：“楽曲聴取行動系列の階層化による聴取傾向変化の検出と行動分析”, 第 188 回知能システム研究発表会, 2017.

• 水上ひろき, 尾日向洋皓, 横山潤：“スマートフォンのセンサ情報を用いた屋内来訪検知技術”, マル
チメディア，分散，協調とモバイルシンポジウム (DICOMO2017), 5C-2, 2017.

• 高野雅典, 福田一郎：“多様な社会関係維持のための社会的グルーミングの多様性”, 第 31 回人工知能学会全国大会, 4N1-OS-01a-2, 2017.

• 垣内弘太, 鳥海不二夫, 高野雅典, 和田計也, 福田一郎：“潜在状態を用いたコミュニティサービスの分析”, 第 31 回人工知能学会全国大会, 4N2-OS-01b-3in2, 2017.

• 原淳史, 馬場惇, 岩崎祐貴, 田中駿：“Entity Linking を用いたユーザのサイト回遊におけるデモグ
ラフィック推定の検討”, 第 31 回人工知能学会全国大会, 3Q1-9in1, 2017.

• 平野雄一, 鳥海不二夫, 高野雅典, 和田計也, 福田一郎：“オンラインチャットサービスにおける未成
年者検出”, 第 31 回人工知能学会全国大会, 2J1-3in2, 2017.

• 鷹雄健, 白井英, 安田征弘, 水上ひろき, 鈴木元也, 木村衆平：“サイバーエージェントの Tableau 利用事例”, Tableau Conference On Tour, Tokyo, ブレイクアウトセッション, 2017.

• 善明晃由, 津田均, 田中克季：“可視化のための非構造データの表化手法”, 第 9 回データ工学と情報
マネジメントに関するフォーラム (DEIM2017), 2017.

• 高野雅典, 福田一郎：“社会関係の数と親密さのトレードオフが社会構造に与える影響”, 第一回計算社会科学ワークショップ, 2017.

• 高野雅典：“ヒトと社会を理解するための計算社会科学”, 第 23 回社会情報システム学シンポジウ
ム（基調講演）, 2017.

• 數見拓朗, 角田孝昭：“アメーバブログにおけるスプログの特徴と検知手法の検証”, 人工知能学会
合同研究会 第 10 回 データ指向構成マイニングとシミュレーション研究会（SIG-DOCMAS2016）,

2016.
• 和田計也, 福田一郎：“インターネットテレビにおけるユーザの視聴行動分析 —継続・離脱分析とユーザアクティブ度の定量化— ”, マーケティングカンファレンス 2016, Vol. 5, pp. 61–65, 2016.

• 力徳正輝：“楽曲生成モデリングのための音符クラスタリング”, 音楽情報科学研究会（IPSJ-MUS）
ポスターセッション, 19, 2016.

• 高野雅典：“ソーシャルなビッグデータによるヒトの社会性と社会構造の分析”, 第 57 回 GRL 浜
松セミナー, 静岡大学, 2016.

• 和田計也：“AbemaTV でのデータ分析事例”, 第 9 回 Web とデータベースに関するフォーラム

発表一覧

62
（WebDB Forum 2016）, 2016.

• 高野雅典：“ソーシャルゲームのユーザ行動データを使った協調行動研究: 互恵関係構築におけるライトなコミュニケーションの効果分析”, 社会情報学会 学会大会 若手プレカンファレンス「ゲームとしての社会／社会としてのゲーム」, 2016.

• 高野雅典, 一ノ瀬元喜：“社会関係の強さに基づく社会的グルーミング戦略の適応性”, 第 13 回ネットワーク生態学シンポジウム, 3, 2016.

• M. Murase, M. Takano, R. Suzuki, and T. Arita: “A statistical analysis of play data in asocial network game: Eﬀects of communication on cooperative behavior,” 31st International
Congress of Psychology (ICP2016), Poster Presentation in Japanese, RC-05-2, 2016.
• 河津裕貴, 鳥海不二夫, 高野雅典, 和田計也, 福田一郎：“潜在状態ネットワークに基づくソーシャル
ゲームユーザの行動抽出”, 第 30 回人工知能学会全国大会, 4D4-2, 2016.

• 河津裕貴, 鳥海不二夫, 高野雅典, 和田計也, 福田一郎：“隠れマルコフモデルを用いたソーシャル
ゲームユーザの分類”, 第 35 回ゲーム情報学研究会, 2016.

• 善明晃由, 津田均：“スキーマ定義に基づく SQL ライクな Key-Value ストアクライアント”, 第 8
回データ工学と情報マネジメントに関するフォーラム (DEIM2016), 2016.

• 牧田光晴, シュティフ・ロマン：“対話ログとユーザ属性情報を用いたリカレントニューラルネット
ワークによる雑談対話生成方式”, 第 2 回 自然言語処理シンポジウム（ポスター発表）, 2015.

• 高野雅典, 和田計也, 福田一郎：“新参者は如何にして新たなグループになじむのか？ : ソーシャ
ルゲームにおける分析事例”, 第 8 回 Web とデータベースに関するフォーラム（WebDB Forum2015）, 2015.
• 數見拓朗, 内藤遥：“実システムへ適用可能な引用型スプログの検知手法の検証”, 人工知能学会 合同研究会 第 9 回 データ指向構成マイニングとシミュレーション研究会（SIG-DOCMAS2015）,

2015.
• 和田計也, 福田一郎：“音楽聴き放題サービス AWA におけるレコメンド手法の検討（artist2vec の試み）”, 人工知能学会 合同研究会 第 9 回 データ指向構成マイニングとシミュレーション研究会（SIG-DOCMAS2015）, 2015.

• 高野雅典, 福田一郎：“コミュニケーションアプリケーションにおける社会的グルーミングのコスト分配戦略”, 人工知能学会 合同研究会 第 9 回 データ指向構成マイニングとシミュレーション研究会（SIG-DOCMAS2015）, 2015.

• 佐藤栄一：“広告配信やレコメンデーションにおける配信制御・リアルタイム集計での HBase 活用
事例”, Cloudera World Tokyo 2015, 2015.

• 牧田光晴, シュティフ・ロマン：“非タスク指向型対話システムにおける対話ペアの意味的類似性を用いた発話候補の抽出”, 言語理解とコミュニケーション (2015-06-NLC-TL ), IEICE-NLC2015-10,

pp.55–60, 2015.
• 宮西一徳, 高野雅典, 吉田岳彦：“大規模リワード広告システムにおける行動履歴と広告属性を利用したコンバージョン予測モデルの構築”, 第 29 回人工知能学会全国大会, 1H5-4, 2015.

• 和田計也, 増田早紀, 梅林泰孝：“行動クラスタリングと隠れマルコフモデルを用いたユーザの位置予測モデル”, 第 29 回人工知能学会全国大会, 3C4-1, 2015.

• 原淳史, 高野雅典, Roman Shtykh, 川端貴幸：“インターネット広告におけるコンバージョンに近いユーザの抽出方法の検討”, 第 29 回人工知能学会全国大会, 1H5-4, 2015.

63• 平藤燎, 牧田光晴：“形態素解析の動的な辞書拡張によるチャットログからの人名表現抽出”, 第 221
回自然言語処理研究会 (SIG-NL), 2015.

• 高野雅典, 和田計也, 福田一郎：“ソーシャルゲームのプレイヤーデータを使った協調行動メカニズ
ムの研究 〜互恵的利他主義と移住の関連〜”, 「ネットワークが創発する知能研究会」・「データ指向構成マイニングとシミュレーション研究会」合同秋合宿, 2014.

• 高野雅典, 和田計也, 福田一郎：“ソーシャルゲームにおける互恵的利他主義に基づく協調行動”, 第8 回ネットワークが創発する知能研究会（JWEIN2014）, 2014.
• 和田計也, 高野雅典, 福田一郎：“スマートフォンゲームにおけるユーザの離脱・継続行動分析”, 第12 回エンターテイメントコンピューティングシンポジウム（EC2014）, 2014.
• 鈴木俊裕, 梅田永介：“HBase を用いたグラフ DB「Hornet」の設計と運用”, Hadoop Conference
Japan 2014, 2014.
• 福田一郎：“研究所・ラボの作り方”, エンジニアの未来サミット 2014〜働く場所の見つけ方、作り方〜 パネルディスカッション, 2014.

• 數見拓朗：“アメーバブログにおけるスパムブログ検知: 機械学習を用いたスパムフィルタの開発”,
第 7 回 Web とデータベースに関するフォーラム（WebDB Forum 2014）, 2014.

• 善明晃由, 内藤遥：“Ameba における HBase 活用事例”, Cloudera World Tokyo 2014, B-2, 2014.
• 和田計也：“Ameba における大量データ分析、R の活用事例”, データサイエンティストサミット,
2013.
• 高野雅典：“進化ゲーム理論の考え方でソーシャルゲームの “ソーシャル” を分析する”, データサ
イエンティストサミット, 2013.

• ユハニ・コノリー, 飯島賢志：“Flume を活用した Ameba における大規模ログ収集システム”,
Hadoop Conference Japan 2013 Winter, 2013.
• 善明晃由：“Ameba におけるログ解析基盤の変遷”, 第 6 回 Web とデータベースに関するフォーラ
ム 技術報告セッション (WebDB Forum 2013), 2013.

• 和田計也：“Ameba における RHadoop の活用事例”, Cloudera World Tokyo, 2013.
• 善明晃由, 飯島賢志：“Ameba におけるログ解析基盤 Patriot の活用事例”, Cloudera World Tokyo
2013, 2013.
• 高野雅典, 和田計也, 福田一郎：“進化ゲーム理論の枠組みを用いたソーシャルゲームにおけるユー
ザの利他的行動の分析”, 数理モデル化と問題解決研究会報告, 2013-MPS-95(20), pp. 1–6, 2013.

• 福田一郎：“Ameba サービスにおける Hadoop 活用事例”, OSCA Hadoop セミナー, 2013.
• シュティフ・ロマン, 牧田光晴：“Akka を用いたデータストリーム処理・解析プラットフォーム”,
Scala Conference in Japan 2013, 2013.
• 鈴木俊裕：“HBase at Ameba”, Developers Summit 2013, 2013.
• 牧田光晴, シュティフ・ロマン：“大規模データ解析の Ameba サービスへの適用事例”, 第 5 回 Webとデータベースに関するフォーラム（WebDB Forum 2012）, 2012.

• 後藤正樹, 瀬戸山雅人, 高野雅典, 大関正人：“iPad を利用した授業中に使えるデジタル教科書用後
付 LMS「Real-time LMS」の開発と実践”, 日本デジタル教科書学会年次大会発表原稿集, Vol. 1,

pp. 22–23, 2012.
• 関喜史, 福田一郎, 松尾豊：“コミュニティ構造を利用した Web サービスにおけるユーザ推薦手法の検討”, 第 26 回人工知能学会全国大会（JSAI2012）, 3E1-R-6-3, 2012.

発表一覧

64

• 福田一郎, 木村衆平：“大規模データ処理基盤とその適用例”, 日本知能情報ファジィ学会 マルチコ
アとマーケティング研究グループ 第 1 回講演会, 2012.

• 福田一郎：“Ameba サービスにおける Hadoop および関連プロダクトの活用”, 第 4 回 Web とデー
タベースに関するフォーラム 特別セッション (WebDB Forum 2011), 2011.

• 服部司, 和田計也：“Ameba の統合ログ解析基盤を使った応用・解析事例”, 第 4 回 Web とデータベースに関するフォーラム 技術報告セッション（WebDB Forum 2011）, 2011.

• 福田一郎：“Hive を用いた Ameba サービスのログ解析共通基盤”, Hadoop Conference Japan
2011, 2011.