メディア事業で取り扱っているデータ
藤坂祐介氏（以下、藤坂）：こんばんは。みなさん大勢お集まりいただきましてありがとうございます。私のほうからマルチメディア機械学習の取り組みについてお話しさせていただきたいと思います。当初のタイトルと微妙にずれてますけど、だいたい同じです（笑）。だいたい同じことを話そうと思っておりますので、よろしくお願いします。
まず自己紹介をさせてください。私は藤坂と申します。
弊社の技術本部秋葉原ラボに2012年新卒入社して、そのままずっと勤めております。もうすぐ7年目になります。今まで何をしてきたかをお話しすると、最初入社当初は検索エンジンの開発をしておりました。そのあとはContent Moderationシステム、あまり聞き慣れないかもしれないんですけれども、いわゆるスパムフィルタリングだとかスパムの投稿を排除するための監視システムといったソリューションシステムを開発していました。
今現在は、今回もお話させていただく画像認識とか、音楽を取り扱うシステムとか、僕がマルチメディア機械学習と呼んでいる基盤の開発にシフトしているというかたちです。最初に福田がお話しさせていただいたように、弊社にはいろんな事業がありまして、我々はとりわけその中のメディア事業に技術や基盤サービスを提供するお仕事をしています。
かと言ってほかの事業にまったく関わりがないというわけではなくて、メインとしてはメディア事業にコミットしているというかたちです。
メディア事業の各サービスをざっくり俯瞰して見ていきますと……俯瞰していくというよりは、どういうデータを取り扱っているかということで見ていくと、例えばアメブロに代表されるAmeba事業はテキスト、画像、最近だとなんとかログっていうので動画も投稿できるようなサービスになっています。
あとはAbemaTVとかFRESH!はいわずもがな動画サービスです。右下にあるAWAは音楽の聞き放題サービスなので、音楽を取り扱っていると。タップル誕生に代表されるようなマッチングサービスについてはプロフィールのテキストも投稿されていますし、本人を表すプロフィール画像を投稿していただくのが大前提になっています。
現在取り組んでいる3つのプロジェクト
このように、メディアサービスとメディアの種類とその関係性についてざっくり特徴を挙げていきますと、方向性が微妙に違うというか、ぜんぜん違う多種多様なサービスが存在しています。メディアの種類も種々あるので、それをいっしょくたに取り扱っていくのが、例えばレコメンデーションなどを行うのには必須であると。それゆえサービスからの開発要望も幅広いです。
先ほど内藤が紹介したレコメンドシステムももちろん重要なんですけれども、1つの方法で開発できる範囲はそれほど大きくないと言えると思います。マルチメディア機械学習ということで、いくつかのプロジェクトに取り組んでいます。簡単にリストにまとめてみたんですけれども、今回は下線を引いている3つについてざっくりお話できればと思います。
では順番に1つずつプロジェクトについて見ていきたいと思います。成功・失敗かかわらず載せてあります。まず1つ目のプロジェクトということで、アメブロの画像のカテゴライズというプロジェクトについてご紹介をしたいと思います。アメブロの各ブログ、書かれている方はいますか？
（会場挙手）
あんまりいないな（笑）。書かれなくてもたぶんご覧になっている方は多数いらっしゃると思うので……いらっしゃると信じて先に話を進めていきますけれども。
各ブログにはそれぞれジャンルがついています。ジャンルというのはもともとはユーザーさんの自己申告をベースに決めています。そうすると、例えば実際の記事はいろんなジャンルについて書かれているんだけれども、ブログのジャンル自体はユーザーさんに決めていただいているというような、実際の記事との乖離があったりします。
それを課題として、昨年ごろより公式ジャンルというページを設けて、ジャンルごとにブログの記事を自動的に解析してオートマチックにジャンル分けしようというプロジェクトがスタートしました。テキスト解析のプロジェクトに合わせて画像も一緒に解析したいよねということで私もプロジェクトに参加したということです。
どうやって画像をカテゴライズするのか
ざっくりとした概念図を用意したんですけれども、青い左側の線が学習の流れ、右側が推論の流れになっています。このあといくつか出てくる概念図もこの色分けで表示している感じです。
左側、まず学習について見ていきますと、とりあえずみなさんが投稿したアメブロの画像を30万枚用意して、それに64種類のラベルを子会社等々のリソースを使ってラベルを付与しました。PFN（Preferred Networks）の方がいらっしゃるので本当はChainerの話をしたかったんですが、我々はKerasを使っています（笑）。KerasにResNetのモデルを構築して、とりあえず30万枚学習させました。
推論についてなんですけれども……推論というよりは一連のソリューションを合わせて説明していきますと、みなさんがブログを投稿します。投稿した中から投稿した画像を抽出します。
Pythonで全部書いているんですけれども、画像については画像のURLを入力とするAPIを用意して、画像を入力にしてResNetを通して一番もっともらしいタグを出力します。それと投稿したテキストによるカテゴライゼーションと画像のカテゴライゼーションを組み合わせて、最終的に記事のカテゴリーを出力するという流れを作っています。
たぶんみなさんは「ラベル付け大変だよね」ってお思いになっているでしょうが、そこの苦労をある程度軽減させるために、ラベル付けの管理ツールを内製で作っています。内製というか私が作っています。
特徴としましては、複数のタグを複数の画像にタグ付けができるようなかたちにしているというのと、あとは一覧で画像を表示できるようにしているということが1つのキーになっています。タグ付けしたものに対してt-SNEをかけてみると、だいたいそれっぽい感じで分類できてることがわかります。
ただ、男性のカップルとか一部判然としないカテゴリーもあるんですけれども、だいたい良好な結果が出ていることがわかります。
カテゴリーを最初に決めたときに「一旦このカテゴリーでいこう」というかたちでプロデューサー側とすり合わせをしたんですが、例えば人間の性別についてカテゴライズするのはなかなか難しい。向こう側にそれを理解していただくというのがなかなか厳しいというのが現実です。一旦決まってしまったカテゴリーはだいたい固定化されてしまうので、そこを組み直すのはなかなか難しいということが1つ反省点としてあります。ここまでは1つ目のプロジェクトでした。
スパム画像検知の難しさ
次にスパム画像検知というプロジェクトについてお話をしたいと思います。最初自己紹介のところでお話しさせていただいたContent moderation、要はスパムの排除みたいなところです。そのシステムと画像解析を組み合わせてより精度の良いスパムの排除、自動化を目指してやっています。
画像検知を自動化したいのには1つ大きな理由があって、一般的にほかのサービスさんやアプリケーションでどれくらいの割合でスパム画像が投稿されているかというのはあまり聞いたことがないんですけれども、弊社の場合だとだいたい投稿画像に対して0.1パーセント程度がスパム画像と呼ばれる画像になっています。
現状、それを排除するためには有人で多くの画像をチェックしないといけないという課題があります。これに対してオペレーターが何人か張り付いて画像をチェックしているというのが現実です。これをなんとか自動化できないかということで、開発の図にいきます。こちらが監視のオペレーターさんです。シーエー・アドバンスという弊社の子会社が監視業務も運営しています。
人が見た画像の結果をOKかそうでないかでラベル付けしています。一般の監視業務なので結果的に画像は消さないみたいな話なんですけど、それと同時に消すべき画像というのが自動的に嫌でもラベル付けがされます。それが1日何千枚か、4年分で400万枚くらい貯まる。オッケーのデータはもっと貯まる。それをデータベースに突っ込んで、それからResNetでモデルを作ると。
一方で推論はどうするかというと、投稿された画像を同時にAPIに投げて、モデルから結果のスコアを出します。スコアをスレッショルドしてオペレーターさんを補助するようなかたちで「これはおそらくスパムですよ」と監視ツールに表示するような仕組みで開発をしています。
しかしこれはあまりうまくいっていないというのが現状です。t-SNEを取ると、なんというか判然としない。
これは紫のほうがエログロにカテゴリーを絞ったスパム、あとはそれ以外というかたちでt-SNEを取っているんですが、スパムと一口に言ってもなかなか幅広いのが現状です。そもそも画像自体を見るのが心理的になかなか厳しい。あとはデータセットの整理がすごく難しいというのがここから見てとれます。
類似画像の検知で悪質業者をあぶり出す
じゃあニューラルネットは諦めて、類似画像検知が使えるんじゃないかなということで、次を見ていきます。
作っている経緯ということで概要をお話すると、さっきお話ししたタップル誕生だとかマッチングアプリ全般ですね。プロフィール画像を使いまわしているユーザーさんがいらっしゃいます。
ユーザーさんというよりはどちらかと言うと業者さんなんですけど。一般人を騙って登録をして、弊社のアプリでマッチングをして、他社のアプリに誘導しようとする輩がいると。あとはそうじゃなくて、単純に悪質な出会い目的で複数のアカウントを保持している奴がいる。そういったユーザーさんに対して、どうにかそれを自動的に検知できるようにならないかということでシステムをまた組み直しています。
類似画像なので、どのように検知するかで見ていくと、画像の画素を元に64次元のベクトルに圧縮します。細かいアルゴリズムについてはdHashってググっていただけるとたぶん出てくると思います。
これをまた何千枚か登録して、今度は実際の画像との類似度をどうやって測るか見ていくと、画像入力としたAPIでベクトルのHamming距離、先に登録したベクトルと今度入力するベクトルのHamming距離、ビット単位の違いで類似画像かどうかを判断する。
何ビットまで合っていれば類似画像とみなすというようなスレッショルドをかけて結果を出力する仕組みを作っています。
実際にまず確か500枚を登録して実験してみたところ、もちろんデータセットとかにもよるんですけど、だいたい7ビットか8ビットくらいのビットのずれで結果が一番いいっぽいと。だいたい98パーセントから99パーセントくらい検知できるということがわかりました。
これは実際にサービスインしていて、悪質な業者のあぶり出しに貢献しています。ここまでがスパム画像検知のお話でした。
曲のサビを自動検知する
最後、これは「やってみた」的なプロジェクトになるんですけれども、楽曲の盛り上がり検知です。盛り上がりというよりは、サビ検知ですね。楽曲のサビを自動で抽出したい。なぜかと言うと、AWAのサービスをお使いになっている方いらっしゃいますか？ ……あ、いない。ぜひ使ってください（笑）。
AWAのサービスには無料プランと有料プランがあります。有料プランは普通にいろんな楽曲をフルで聴けるんですけれども、無料プランは楽曲のうちの最初の30秒だけ聴けるっていう感じになっています。ですが、最初の30秒をサビの30秒にしたほうがユーザーさんの満足度は絶対に高いと思います。
サビを（判断するために）人が聴ければいいんですけれども、膨大な時間を費やさなければいけないので、自動で検知できたほうがいいよねということで、実際に楽曲の波形情報を使ってできないかなということで見てみました。
これは概念図というよりはアルゴリズムの流れになるんですけれども、音楽データをレコードして、実験なので、それをレコードする前に音楽データにタグを付けます。
何が書いてあるかわかんないと思うんですけれども（笑）。イントロと、ここがコーラスで、メロディーがここで、というようなタグを付けます。その波形情報を今度はフーリエ変換して周波数情報に変換します。
その変換した強度を画像化して、それをコンボリューショナル、畳み込みネットワークにかけるという仕組みで作っていました。
ここは結果のパーセントだけ載せているんですけれども、とりあえず3クラスに分類して調査して、いろいろいじって、結果として51パーセントくらい検知できるという結果が得られました。
51パーセントということは、半分の楽曲についてはサビが検知できるけれども、もう半分についてサビが検知できないということなので、まだ導入はできていません。もちろん高精度化したいんですけれども、なかなか時間がないというのが現状です。
ということで、いくつかプロジェクトを見てきました。最後にまとめになります。今回お時間をいただきましてマルチメディア、主に画像と音楽の機械学習の実例を示しました。今後テキストはもちろん、マルチメディアに関わる機械学習の需要というのはどんどん伸びていくことが考えられます。それは例えば動画に関わる機械学習、AbemaTVやFRESH!といった動画に関わる機械学習の分野はまだまだフロンティアというか、やるべきことがたくさんあると考えています。
あとは検索とか、最新の技術がどんどん出てくるので、そのキャッチアップです。これまでにご紹介したプロジェクトの高精度化とか、そういったことなどがあります。今後も引き続きこの機械学習の分野を続けていきたいなと考えています。
最後に宣伝なんですけれども（笑）、キャリア採用募集中ですので、こちらからに応募していただくのもそうなんですけど、社員さんにぜひ話しかけてみてください。ということで、宣伝も含めて以上になります。ありがとうございました。
（会場拍手）
自転車の画像とケーキの画像が載ったブログには何のラベルが付く？
司会者：それでは質問がある方は挙手していただければと思います。
（会場挙手）
質問者1：発表ありがとうございます。最後の楽曲の盛り上がりのことについて質問があるんですけれども、曲のジャンルや歌手によってサビが当たった場合と当たらなかった場合の例があれば教えていただきたいと思います。
藤坂：ちょっと具体例がここに書けなくて申し訳ないんですけれども、一般的にJPOPとされる楽曲はわりと検知率が良くて、それ以外は検知率が悪いというのが正直なところですね。
質問者1：データセットはどのジャンルもある程度均一的にサビなどのラベル付けをしたって感じなんですか？
藤坂：そうですね。一通りはカバーしているはずです。
質問者1：ありがとうございます。
質問者2：お話ありがとうございます。ちょっと細かいことなんですけれども、ブログのジャンル分けの話のときに、ジャンルってバイクとか物だったんですけど、実際はたぶんもうちょっと抽象的なジャンルを付けるのかなと思って。複数の画像があったときに、どうタグ付けしているかというのが気になりました。
例えば、自転車の画像とケーキの画像とかいろいろ映ってたんですけど、「さてこのブログは何のラベルが付きますか？」というとき、全部に付けるのか、それとも1個選ぶのか、どうしているのかなと思っていて。それをお願いします。
藤坂：いい質問でした。ありがとうございます。実際にカテゴライズするにあたっては、テキストに引っ張られるかたちになるのが一般的です。それはなぜかと言うと、画像をカテゴライズしてカテゴリーのテキストに変換した上でテキストの解析をかけるような仕組みをとっています。なので実際に複数の種類の画像が投稿されることはもちろんありますが、その結果はテキスト解析に引っ張られるというのが答えになるかなと思います。
質問者2：ありがとうございます。
スパム検知を改善するには
質問者3：質問というわけではないんですけれども、スパム検知のところで、スパムってけっこうある瞬間にわーっとユーザーが来るみたいな、時間的なものとか、爆発的に広がるみたいなポイントがあるような気がするんですね。
画像だけで見るのではなく、なにか別の、例えばこのへんのIPからのアクセスがこの瞬間にピークを迎えるみたいな、そういう複数の情報を使うと見分けやすくなるんじゃないかなと思いました。
藤坂：ご指摘ありがとうございます。実際その通りで、1人の人間が複数のスパムを投稿するケースがわりと多いというのが事実なんですけれども、そうじゃないケースというのももちろんありますし。
あと最近はそういうスパムもなかなか高性能化してきて、いろんなところから……例えばIPを偽装したり、イタチゴッコが続いているというのが現状です。もちろんそういった取り組みも今後やらなければいけないというのはあります。
質問者3：ありがとうございます。逆にいつまでユーザーの目に触れていいのかというのもあると思うんですけれども。触れたあとで広がる瞬間ってあると思うんですね。探している人とか載っけたい人というのもいるわけじゃないですか。そっち側、後ろ側から攻めることもできるんじゃないかなという指摘でした。ありがとうございます。
藤坂：ありがとうございます。
質問者4：細かいところの話なんですけど、サビ検知のところで、フーリエ変換したあとに周波数ごとの画像を画像のかたちでニューラルネットに食わすのはどういう理由なんでしょうか？
藤坂：ニューラルネットを使いたかったというのが正直なところなんですけど（笑）、いくつか論文を拝見しまして、音楽についてニューラルネットをかけるという研究がいくつかなされていまして。それについては実際に周波数領域のベクトルを行列化するという手法がよく取られています。僕らはそれを採用したという感じです。
質問者4：ありがとうございます。
サビがない曲は判別できるのか？
質問者5：実験中のプロジェクトにばかり質問してしまって申し訳ないんですけれど。クラシックだとか賛美歌だとか、サビ自体がない曲もあると思いますけれど、サビがあるかないかを判別するような技術ってできそうでしょうか？
藤坂：そうですね。この場でパッと考えるような話になってくるんですけども。例えば、ピークとそうではない時間……時間というかレシオというか、音楽の強度の強い部分と弱い部分がはっきりしている曲であるか、もしくはそうじゃない曲であるかというのは、わりと音楽のパケだけから取れるものではないかなというのは1個思います。
ただクラシックと言ってもなかなか一口では言えない。『運命』みたいな曲だったらどうするかとか（笑）。盛り上がりがだんだんあるような曲だったら、それはサビじゃないのかとか。いろいろ音楽と言っても幅が広いなと思いますね。そこはAWAの人と一緒に考えたいと思います（笑）。
質問者5：ありがとうございます。
質問者6：私もサビのところに興味があります。サビを検知して、今のところ50パーセントということでしたけれども、とりあえずわかっている範囲で、「こういう特徴がサビの判別に効いてる」みたいなところって、何か知見はあったのでしょうか？
藤坂：えーっとですね、あんまり覚えてないな（笑）。ちょっとあとでデータチェックします（笑）。
質問者6：ありがとうございます（笑）。ピークとピークの差があったところとかいうお話があったので、果たしてそういった特徴が見えたのかなということに少し興味があったんですけれども。
藤坂：そうですね、t-SNEとかで特徴を出せればよかったんですけど、なにせちょっとプロジェクトが古いもので（笑）。データが散逸してるというのが正直なところです（笑）。
質問者6：ありがとうございます。
司会者：質問が尽きないかもしれませんが、お時間もありますのでここで一旦締めさせていただきたいと思います。質疑応答にご参加いただきましたみなさんありがとうございました。
（会場拍手）
