読者です 読者をやめる 読者になる 読者になる

宇治川ビール #1

急に高まって深夜にiOSアプリつくった

※当方iOSアプリ開発経験無し

「Kyoto.なんか #2」というイベントで、amakanにおける書籍のシリーズ判定方法について話しました

Kyoto.なんか

「Kyoto.なんか」というのは「プログラミングに関する発表をしあってみんなでわいわいする勉強会」で、今回含めて過去2回行われているイベントです。

amakan

amakan というのは、自分が開発している、新刊・蔵書管理をサポートするためのWebサービスです。https://amakan.net/ からアクセスできます。今回は、amakanの中で使われているシリーズ判定の仕組みについて話しました。

シリーズ判定界隈

コミックやライトノベルに対してシリーズ判定をやっている事例というのは少なく、Amazon楽天国立国会図書館Google ブックスなどを調べてみた限りでは利用できそうなデータはありませんでした。調べている中で唯一、1kkan.com というサービスがこれに近いことをやっているのを発見したんですが、正規化などで取り組んでいるという情報ぐらいしか得られませんでした。

このような話をしていたところ、発表中に会場から「あ、それつくってるの私です」という話が出ました。日本のシリーズ判定界隈のメッカは、この瞬間、間違いなく京都にあると言えるでしょう。やあやあ我こそはシリーズ判定者なりという方が他にもおられましたら、是非名乗りを上げてください。

シリーズとは何か

シリーズ判定の難しさの1つに、シリーズという概念の曖昧さが挙げられます。例えば、18巻まで刊行されている著名なライトノベルをとってみても、アインクラッド編、フェアリィ・ダンス編、ファントム・バレット編のような分類や、第1章、第1章 外伝集、第2章 上巻、第2章 下巻、外伝、第4章 1幕、第4章 7幕 (第4章新章 1幕)、第1・2層、第3層、など別の分類も存在します。補足しておきますが、これは ソードアート・オンライン という作品の例です。

「この一連の作品は1つのシリーズものである」ということを正確に決められるのは、恐らくそれを制作した作者や出版社ぐらいしか存在しないはずですが、特にそういう分類を主張する文化は存在しないので、見方によって様々なシリーズの捉え方があるような状態です。しかしこのままでは非常に都合が悪いので、amakan ではシリーズとして成立する集合の条件を次のように定めました。シリーズ名という条件により、単純に集合に分類するだけでは上手くいかず、問題が難しくなっています。

  • シリーズ名を付けられる
  • 同じような名前を持っている
  • 同じ作者の作品である (作者が複数人いる場合は全員一致すべき)
  • 同じカテゴリの作品である (例えばラノベとコミックは別ということです)
  • 2冊以上の本が含まれる

シリーズ判定方法

シリーズ判定方法については、発表資料上で説明している通りです。amakan で利用している実装は https://github.com/amakan/amakanize に置いてあります。

今回説明したようにパインプライン状にフィルタを適用していく処理というのは、以前に自分が開発したMarkdownプロセッサに着想を得ています。これは Markdownを拡張して独自記法をつくる - Qiita という記事に内容をまとめており、ソースコードhttps://github.com/increments/qiita-markdown に置いてあります。複数の独立した処理を順々に適用していくような内容で、かつそれぞれに適切な順序が存在するという場合、初期段階ではこういう設計にするとそこそこ具合が良くなると思います。

今後のシリーズ判定戦略について

とりあえずElasticsearchを導入してシリーズ判定に利用してみようと思っています。いま現在はMySQLを利用しており、抽出したシリーズ名からタイトルで検索して候補を取得した後、更に作者が一致するものに絞り込むということをやっています。しかし、正規化しきれない表記揺れがタイトル・著者ともに数多く存在し、また著者についてはそもそも巻によって漏れがあることも少なくありません。

そこで、完全一致に頼ることは諦め、一致度によってスコアリングし、検索結果から特定の閾値以上のスコアの本を同じシリーズとして許可する、という戦略を試してみようとしています。この方法を採用することで、例え作者の内の1人が抜けていたり、表記揺れにより別の作者と判定されたり、10巻からいきなりBLACK LAGOONブラック・ラグーン表記に変わるようなことがあったとしても、スコアリング計算制度と閾値設定次第で上手く判定できるんじゃないかというねらいです。しかし誤判定が増える可能性も上がるので、安易な導入は危ぶまれます。

集合への分類という点・教師データが用意しやすいという点から機械学習の導入も検討していますが、判定ルールの説明が難しくなること、推薦アルゴリズムなどと違い誤判定のリスクが大きいことから、まずは前述したスコアリング時の係数や閾値などの比較的簡単な部分から導入できたらと考えています。

今後のamakanについて

今週まではコミックとライトノベルしか扱っていませんでしたが、つい先日から amazon.co.jp で購入できるほとんどの和書や洋書を扱えるようになりました。現在はコミック・ライトノベル以外の本の解禁に対応して、シリーズ判定戦略やサイト構造を変更している最中です。また、いまはChrome拡張を使えばAmazonの注文履歴や別サービスの読書履歴から一括登録できるようになっていますが、これをFirefoxなど他のブラウザに対応しようとしているのと、iPhoneアプリAndroidアプリをつくろうとしているところです。

今後も使いやすさを重視して改善を続けていこうと思っているので、ぜひご利用ください。 https://amakan.net/

SoundCloudの曲を一緒に聴けるやつに思いのほか反響があったので改良した

https://syncbeats.herokuapp.com というのを適当につくって SoundCloudの曲を一緒に聴けるやつをつくってみた - ✘╹◡╹✘ という記事を投稿してみたところ、思いのほか反響があり、折角なのでもう少し改良してみることにしました。

再生済みの曲も聴き直せるように

初期バージョンでは、一度再生し役割を終えた曲は消えてしまうという諸行無常な造りだったが、流石に無情すぎるということでこの仕様は廃止。一度再生した曲も後から聴き直せるようにした。同時に、大量の曲をキューに詰めて埋め込みプレイヤーの数が増えると重くなってしまうという話を承けており、再生後の曲も表示する仕様に変更したことで問題が露見し始めたため、とりあえず再生中の曲以外はプレイヤーを埋め込まないことに。

過去に利用された部屋も訪れられるように

前述した変更により、現在利用されていない部屋にも利用価値が生まれることになったので、過去に利用された部屋もトップページから最大100件まで遡って閲覧できるようにした。また閲覧履歴を設け、最近見た部屋にはトップページから簡単に戻れるようになった。これは多分便利。

image

部屋に名前を付けられるように

色々な部屋が見られるようになったので、部屋を作成するときに名前を付けられるようにした。こういう系の曲を流しますとか、誰が主に垂れ流してますとか、今から終戦記念mixやりますとか書くと捗るんじゃないでしょうか。

image

曲が再生されるたびに再生数が更新されるように

部屋の右上に再生数 (その部屋で曲が何回再生されたか) を表示して、曲が再生されるたびに更新されるようにした。本当は「いまXX人がこの部屋にいます」的な情報を出しても良かったんだけど、それを表示するにはまだ少し準備が整ってなかったので、とりあえず再生数を出すことにしてみた。自分が再生している分も含めて徐々に増えていくので、まあ増え方を見ていれば大体何人ぐらい一緒に聴いてるか把握できないこともない。

image

その他細かい変更

ロゴ部分を若干まともにしたり、faviconを用意したり、サイト構造が分かりやすいようにパンくずリストつけたり、あとは部屋のURLをTwitterにつぶやくボタンを地味に端っこのほうに追加したり、ということをやりました。現時点でも作業用BGMとして非常に重宝しているんですが、ユーザが増えると曲のレパートリーが増えてもっと嬉しいので、SoundCloud使える人は是非使ってみてください。

https://syncbeats.herokuapp.com/