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

第2回SBM研究会見てきた。それぞれのSBMサービス担当の話聞けて良かった

SBM研究会 カンファレンス

第1回のSBM研究会は全くもってスルーしてたので第2回SBM研究会はちゃんと見に行ってきました。
と、言っても先輩に第2回やるみたいだよって教えてもらったのですけど。
他の人の感想とかはここに集まるのかな?[SBM研究会]でタグ付けしてって周知されてるみたいだから検索すればすぐ探せるとは思うのだけど。

感想とか

  • アンケートの中に「どのSBMサービスを利用していますか?」ってのがあったけど、やっぱり「@niftyクリップ」は「ニフティクリップ」のまま認識されてるのか。
  • 2番目の上野さんの発表のセレクトブクマは「何度も利用するページランキング」ってことだったのだけど、ランキングをサービスとして表に出してしまうとSBMのトップに出すのと同じでブクマ数がきっと増えるよね。そうするとブクマする日付が伸びるから、長期的に見るとランキングが動かなくなるってことはないのかな?
  • 発表の中でもいろんな人が話してたけど、SBMが多種多様になってきてて、「SBM」って言い方で納まらなくなってる気がする。発表自体がシステム的な話だったり、ユーザ視点だったり、新しいものを生み出そうとしてたり。もうそれ時点が研究になりそうだよねっていう。

以下はメモ。間違ってたらまた修正します。

挨拶

  • 開催の目的
    • 参加者同士の仕事・プライベートでの人脈形成を支援する

SBMがつくるコミュニティ、SBMでつくるコミュニティ - 研究・サービスの両面から - 大向 一輝氏 国立情報学研究所/株式会社グルコース

自己紹介
  • 論文検索エンジン「CiNii」
  • glucose/goo RSS リーダー
  • SBM研究の源流は2001〜
    • 違う人のブックマーク研究の支援
    • Bookmarkからの共通話題ネットーワークの発見手法の提案
      • 被験者として手伝う
      • 教授の「誰も共有しないからそんな研究意味ない」でバッサリ
  • 未踏時代2002〜
    • RNA:日本初(世界初?)のRSS対応アンテナ
      • クリップ機能がついていたが先進的すぎていまいち上手く作用しなかった
  • セマンティックウェブからのアプローチ2004〜
    • 論文を書いたがdeliciousの「Ontologies are us」に全部もってかれた
  • SBMに関しては敗北ばかりだけどやっぱり研究を続けている
なぜ研究するか?
偏りを知るために
    • 全人類の興味・関心の平均との距離を測ればよいのだけどそれは無理
      • 「偏りがないと意味をなさない仕組み」の有用性を検証する
研究のアプローチ
  • 既存の数理モデルをあてはめるのが目的ではない
  • フィールドワーク的
    • コミュニティにどっぷりつかる
    • シンプルに仮説を作って検証、改良
データセット
  • Buzzurl(当時はECナビ人気ニュース)
    • 期間は2005年10月から1年くらい
SBMと推薦について
  • 内容ベースの場合
    • コンテンツの類似度を計算し、高いものを推薦
    • 人が介在しない
  • 協調フィルタリングの場合(今回はこっちを採用した)
    • 同じブックマークをもつユーザを見つけ、そのブックマークを推薦
      • 似たユーザのデータを推薦
    • ユーザの嗜好データを事前に取得(計算)
予備実験
  • シミュレ−ション
    • 期間を前半、後半に分ける
    • 前半のデータで協調フィリタリングのモデルを作成
    • 後半のデータとの一致を見る
      • (実際の推薦ではなく、測定をしてみるだけ。なので、ホントに推薦していたらブックマーク受理率はあがるかもしれないけど、シミュレーションでその実験はできないので)
  • 結果はまったく効果がなかった
    • 10,000の推薦データのうち4つくらいしかヒットしなかった
    • SBMの性質上、ニュース性があるものは瞬間的にブックマークされるため、期間をわけても昔のURLはブックマークされない
SBMのための協調フィルタリング
  • 最新のコンテンツを推薦するために考察
    • 富豪的アプローチ(これをやるのは難しい)
      • リアルタイムに新規のデータを取り込み、モデルを再計算
      • 膨大な計算コストがかかってしまう
    • 「偏り」を仮説としてもっておくと上手くいきそう
      • SBMにはイノベータとフォロワーがいる
      • いち早くコンテンツをブックマークする人のブックマークを他の人に推薦する
SBMのイノベータ
  • 1ゲッターに着目
  • 1ゲッターの回数と人数と傾向(全ユーザは3503人)
    • 100回以上83人:全体の91.9%のブックマークをカバー
    • 10回以上:266人:98.4%
  • ECナビ人気ニュースの「スクープ記者」の性質のせいかもしれないが、少人数が9割以上をカバーしている
イノベータからの推薦を考慮してのシミュレーション
  • 前半データ
    • 各ユーザとイノベータ群の類似度を計算
  • 後半データ
    • 類似度の高いイノベータ群がブックマークしたコンテンツのうち、各ユーザがどの程度受理したかを測定(これも実際に推薦を行うのではなくヒット率ということ)
シミュレーション結果
  • 実際に推薦した訳ではないが前の実験より上手くいった
    • 大体100個推薦で8個くらい
  • 上手くいったのに前の実験より計算量が激減
    • 協調フィルタリングは1回走らせるだけ
      • 嗜好の変化を考えて何回か計算してみたが、400日程度では人のブックマーク嗜好は変わらないってこともついでにわかった
興味・関心の偏りについて
  • SBMがつくるコミュニティには長期的な興味・関心が存在している
    • これはブックマーク数では判断できないこと
  • それぞれのブックマークが長期的関心に合致するか判断するためには
    • 個々のユーザのタグ付与行動履歴を観察
    • 総体として作られるコミュニティの嗜好を利用
長期的な関心と短期的な関心についての推測
  • 初めて付けられたタグは短期的な関心ではないか?
    • もしそのタグがその後のブックマークに付けられたならば、それは長期的な関心になったと言えないか?
推測を基に短期的指標を定義
  • あるブックマークに「どのくらいの新規タグ」が付いているか
    • 再利用タグ(今まで現れたことのあるタグ)ばかりのブックマークは長期的な関心が強い
コミュニティの興味関心
  • 「短期性指標」下位のコンテンツ(新しいタグが全然つかないブックマーク)
    • ITmediaやCNETやMYCOMなど、ウェブ系のブックマークが大半を占め、「Yahoo!」「Google」「Microsoft」などウェブ系のタグが大半を占める
  • 「短期性指標」上位のコンテンツ(新しいタグばかりがつくブックマーク)
    • 「祝」「おめでとう」のタグなど、統一性がなかった
ここまでのまとめ
  • SBMコミュニティに存在する「偏り」
    • 内部から見えてくるもの
    • この「偏り」が存在するのは避けられない
    • 内部から「偏り」の姿を見たい
    • 「偏り」を積極的に活用したい
  • 「偏り」についてシンプルなアプローチを考える(これが本題)
何のためのSBM?
  • SBMが提供する機能
    • 個人向けとして
      • 保存、整理、投票、コメント、スクラップブック
    • 集合知として
      • 情報の発見、外部からの評価
SBMに期待されるもの(アンケート)
  • 多用途で一つの使い方ではない
    • 自身のため
    • 他のユーザに注目されたい
    • サイトの管理者へのメッセージ
SBMの現在を考えると
  • 多用途に耐えるシステムになっている
    • 使いこなせる気持ちよさ?
  • ひとことで言い表しにくい
    • 母親に説明しようとしたら難しい
    • ブログなら日記、SNSなら井戸端みたいに言えるんだけどSBMってどういう風に言ったらいいか
  • 機能分化の可能性があり、新しい対象や新しい用途がでてきている
現実のコミュニティとは?
  • 研究室、職場、家では?
    • クローズ、半クローズなコミュニティに囲まれている
  • FYIメール(「参考までに」のメール)
    • FYIといいながら強制的に読ませる目的がある
  • 以上のことから求めているものを考えると、
    • 双方向的で複数なコミュニティがある
    • 強制的に読ませる仕組みがある
4dk
  • コミュニティブックマーク
  • FYIメールを現代化する
    • 宛先のある情報のやりとり
      • 重要な情報=誰かに伝えたい情報
    • 宛先=コミュニティ
      • だけど、コミュニティは一つではない
    • 読まれたかどうかがメタ情報となる
      • リアルのコミュニケーションとの連動
  • 名前の由来(オフレコだったけどITmedia?で出ちゃったから)
    • 読んどけ
4dkのデモ
  • たくさんコミュニティを作れる
  • ユーザ自身はトップページを見ることがあんまりない
  • ダッシュボードという機能で複数のコミュニティを管理
  • 検索は?
    • はてなは全部検索があるけどそこまでできない
    • コミュニティがあるので、人の名前で検索できる
    • 「誰が投稿・コメントしたか」の検索
  • グループの中でどのくらいの人が読んだかをパーセンテージで表示している
    • 視聴率機能
  • 仕事場で使うときに「資料読んだかどうか」をチェックするのはめんどう。それをゲーム感覚で解消するようなツールにしたかった
その他4dkの機能
  • 朝刊メール
    • 前日のキャッチアップ
  • 夕刊メール
    • 他のグループからのおすすめ
運用結果
  • 2ヶ月ほど運用して
    • 圧倒的にクローズドグループが多い
      • 公開しているのは少ない(そういうのは他のSBMサービスに任せればいい)
    • 1人グループ、2人グループ(彼氏彼女みたいでやってるみたいな。でも中身は見てないよ)
  • 反省点
    • もっとシンプルで良かった
      • グループ設定とか
    • Ajax使いすぎて一般ユーザがわかりにくい
本音と課題
  • ソーシャルってなんだろう?
    • 「不特定多数と私」だけではないはず
    • 「私を取り巻くコミュニティ」の集まりもある
      • コミュニティの1つに不特定多数がある
      • これを補うのが4dk
  • 切実な情報共有の問題
    • 「読んでもらわないと困る」と「あとで読みたい」は質的に異なる
  • 課題
    • コミュニティの本質的な面倒さを軽減したい
    • 既存のコミュニティを取り込む
質疑応答
  • 営業の例のように「読んどけ」と言いたいので会社で使えそう。社内のサーバで使えないか?
    • パッケージ化はできるので、それをそのまま持っていけるようにできたらいいかも
  • イノベータのブックマークを推薦するのと、イノベータのブックマークを定期購読しているのと何が違う?
    • 「自分ととても似ている1人の人間」はほぼ存在しない
    • 仮想イノベータをシステム的に作らないと上手くいかない
    • 例えば4人定期購買していて、そのうちの3人ブックマークしたコンテンツなら推薦、1人なら推薦しないなどのようにしないと上手くいかない

ソーシャルブックマークデータの時間情報を用いた情報フィルタリングと検索 - 上野 大樹氏 慶應義塾大学大学院

SBM研究の種類は大きく4つある
  • SBM,FolkSonomyの分析
    • ユーザ、タグ、ブックマークの性質について分析
  • webページ推薦
  • ブックマーカーの発見
  • Webページ検索(これが今回の話)
    • SBRank(ブクマ数の多さ)をPageRankと融合して有用なページを探す
Webページ検索
  • blogやwikiなど自動的にページ間を結びつける場合は人々の意思が入ってないのでリンクだけのRankではダメ
    • SBMのブクマ数を利用する
  • ただし、SBMの場合、トップに出るとブクマ数が急激にあがるからそのまま使うのはまずい
    • 一時的にブクマ数が増えたページが後で見て有用か?
    • また、個人の嗜好が入る
ブクマ数と時間の関係
  • 3つのタイプがある
    • 瞬間的にブックマークされる
      • ニュースなど
    • 急激にブクマ数が増える時期があり、ブクマされ続ける
      • 「〜の使い方」のようなページ
    • 急激に増えず、ブクマ数が増える
      • ポータルサイトなど
2つに分類

Type1:瞬間的にブクマされる - ブクマされた日数/ブクマ数=0.2以下
Type2:長期的にブクマされる - ブクマされた日数/ブクマ数=0.8以下

セレクトブクマの開発
セレクトブクマのランキングロジック
  • ブクマ数*日数^α(α=0,1,2)
    • 日数は2008/11/01,2008/11/08,2008/12/01にブクマとかなら3日とか
考察
  • ブクマ数の多いタグによる1単語検索で有用
  • 一時的、暫定的なページをフィルタ
  • Google検索と比較して、その単語について詳しく知りたい場合に有用
今後の課題
  • ロジックの改良
    • 現時点だと古いページが有利になってしまう
      • ブクマされた時期などによる重み付け
    • タグを付ける行為の意味(フィールドワーク)
      • タグ率の利用
(おまけ)ブクマストリーム
  • 月刊ランキング
    • ブクマ数順にランキング化して表示
  • ブクマ数の多いページをまとめてチェック
  • 過去のブクマ数の多いページを発見
質疑応答
  • 評価の基準は何?
    • 被験者が有用、面白いと思ったかどうか(定量的な方法ではない)
  • 一時的なブクマかどうかの基準は?
    • 基準がないのでもう少し考えたい
  • タグの意味は判断してるか?「Java」「ひどい」の両方がついたタグが定期的についてたらランキングに影響しなくていいのか?
    • そういうのは見ていてあまりなかったが、特殊なタグなどについては考えた方が良いかも
  • googleのランキングと比べていたが、自分とはてなユーザとの相関が高かっただけではないか?
    • その重みも考慮すると面白いかも
  • 計算式はまずはこのシンプルな式にしたのか、それとも他の方法も試して、この式にしたのか?
    • 一番シンプルなこの式をまず試した

普通のヤツらのメタをゆけ - 広木 大地氏 日本野望の会

フロント技術の話
Social Graphe
  • 現実あるいはその延長線上の社会的関係グラフ、これらを用いたサービスに対してのNeeds
    • 知人、他人のブックマークを見たい、自分のブックマークを見せたい
    • (SBMの場合、要は)記事への意見を見たい、見せたい
      • つまりSBMの場合、記事を介して他人とつながっているので、記事Authorが介在している
Overlay Web
  • ある記事に対してSBMのページがかぶさっている
    • Bという人が記事をブクマし、コメントを書き、それを他人のAという人が読む
    • SBMはWeb上の記事のOverlay
SBMを解体すると
メタ構造
  • ブックマークの集合記事もまたOverlayされる対象になりうる
    • 例えば、何かの記事がブクマされ、そのコメントなどに対してコメントを付けるために「元記事のブクマページ」をブクマされることがある
      • 「元記事」→「ブクマ」→「メタブクマ」
  • 記事をブクマして、そのブクマコメントページをさらにブクマして、それが繰り返されて…
    • メタメタメタブクマなんていうのもあり得る(URLにどんどんブクマされたURLがつながる)
  • URLのLength制限はあるか?
    • HTTP/1.1によると特に制限はない。「要はがんばれ」
    • メタ×32ブクマもあり得る
  • メタ(メタ…)ページの作成&コメント構造は既に見受けられる
    • 2chのまとめとか:「ニュース」→「そのニューススレッド」→「まとめサイト」→「まとめサイトブクマ」→「まとめサイトメタブクマ」
      • そもそもニューススレッドからまとめサイトも「手動メタ構造」
さて、SBMサービスは、SBMでのSocial Graphに介在している記事Authorへの通知や連携を前提としていない
  • 元記事を考慮しないことによるリスクがある
    • イントラネットブックマーク
      • ユーザがローカルホストやルータの機種などをブックマークしていたりするが、そのユーザのイントラが見えてくる
      • 情報がわかるとなおさら攻撃しやすくなる
      • セッション情報をGETパラメータに含んだままユーザがブックマークしてしまう
      • イントラネットブックマークを防ぐためには、SBM側でGETしてとれなかったらブックマークしないなどの対策が必要
話は変わってブックマークレット
  • div+iframeのはてなブックマークレットが少し前に話題になったけど、window.openもlocation.hrefもフック可能なブラウザが存在する
    • 閲覧しているサイト側でブックマークレットを押されたことを検知して偽物のscriptを実行してユーザをだませる
  • 標準的なものを決めてセキュリティリスクをみんなで負いましょう
質疑応答
  • ブックマークレットのセキュリティについて詳しく
    • location.hrefでリダイレクトする以外は全部JavaScriptでフックできちゃう
    • window.openはアドレスバーが見えるから安全と思われているが、ブックマークレットはそれ自体に安心感があるから、ブックマークレット押した時点でアドレスバーなんて普通見ないよね
    • だからリスクをまとめてみんなで対策をとるのが良いんじゃないか?

ソーシャルブックマークサービスSEO力 - 美谷 広海氏 楽天株式会社

SBMのSEO
SBMは現代のページランク
  • ポータルサイト同等のPageRank
  • ユーザが情報をどんどん追加してく
外部サイトのブックマークボタン
  • ニュースサイトなどにおいてある「ブックマーク追加リンク」による被リンク
  • はてなはサービスが密に連携していて被リンクが多い
RSSの持つ力
  • RSSによってサーチにIndexしてもらうことの価値
    • ポストすることが1秒でも速いことよりも、グーグルの検索結果に1秒でも速くあがることが大事
    • いち早く情報を広げることが重要
より速くインデックスされるメリットの意味
  • 2つのサイトがあったとき、速くインデックスされたサイトはもう片方より価値が低いサイトだったとしても被リンクを得られやすい
    • 速くインデックスされるということは、それだけ速く検索結果に出るということ
    • もう一方が検索結果に上がる前に人が訪れる可能性が高く、訪れた人はそのサイトが有用だと思えば、その時点でリンクを付ける
    • もう一方が検索結果に上がるようになった頃には、元々検索結果に出ていたページは既に被リンク数が増えている
はてブはてなダイアリーの相乗効果
  • RSSによってより速くインデックスされる
    • これはどのサイトにでも言えること
  • ただ、はてなはブックマークとダイアリー両方のサイトを備えている、かつ、自動リンクやIDリンクなどで蜜にリンクをしているため効果が高い
    • さまざまなRSSを配信しており、それぞれのサービスのURLがインデックス化されやすい
速くインデックスしてもらうことはGoogle Webmaster Toolsで個人でもできる
GoogleRSSの購読数をランキングに考慮しているか?
  • RSSGoogleに食わせたとして、意味があるのか?
    • Webmaster Toolsで購読数が表示されるので考慮しているのではないかと推測
質疑応答
  • はてブの中の古いブックマークページは404があったりする。googleがそれをクロールすることでサイトのランキングを下げてしまうんではないか?
    • googleはそこを無視してくれるんじゃないかと楽観的に判断している
    • 「有用なものを速く提供している」という意思が見えればgoogleはそっちを重くおいてくれるんじゃないか?
  • 研究的にはgoogleはキーワードを重要視していて、ランキングはそんなに使っていないのではというのが通説なので、リンク数を増やしても効果があるのか?
    • ひとつのパラメータだと思っている
    • 作る側はキーワードをしっかり作るのは前提としてあり、それに加えて被リンク数を増やす作業もやると良いという話

SBMコメント機能によるコミュニケーション形態の考察 - 西谷 智広氏

考察の背景
  • 自分のブログのはてブのコメントが気になってる
    • 通勤のときにチェックするくらい気になってる
  • SBMのコメントとは?
    • 分類用のためだったと思うのだが、最近はコミュニケーションに使われる
BlogコメントからSBMコメントへ移り変わっていってる?
  • ブログにコメント欄がなくてもコメントが書ける
  • ブロガーから干渉がない
    • でもアクセス解析からたどって、ブロガーはコメントを見ちゃうんだよね
  • コメントアグリゲーターとしての役割
    • 自分のコメントの整理
      • いろんなブログにコメントするよりも、SBMにまとめておいた方があとで見つけやすい
コメントコミュニケーションの分類
  • 自分のため(これは本来のSBMコメント)
  • ブロガーとのコミュニケーション
  • 他のSBMユーザとのコミュニケーション
    • 受け狙い
    • ブロガーがセルクマでコミュニケーションをとることも
ブロガーからのSBMコメント誘導
SBMコメントの時系列概念
  • はてブは1人1回のコメント
    • 後のSBMコメントを受けて修正する人はいる
    • ブックマークの順番を修正するのは面倒
  • ブックマークの順番によってコメントは影響される?
    • 同じコメントは書けないような雰囲気がある
コメントのクオリティをあげるためにはどういう仕組みがあると良い?
  • SBMユーザへのインセンティブ
  • コメント記述のフィルタリングとリコメンド
    • 良くないものは見えないようにする、良いものは見えるようにする
性善説v.s.性悪説
  • SBMユーザ母集団の大多数は一般的な常識を持っている
  • しかし問題が出てるのも事実→どうしたらいいのかな?
質疑応答
  • SBMはなぜ上にコメントが伸びていくのが多いんだろう?
    • 須藤氏(株式会社ECナビ):Buzzurlは下に伸びていく。はてブとかdeliciousを使っていたときに下から上にスクロールして見ていたので
    • id:naoya氏:あのページは何回も見るため、新しいのが常に見えるようにした。というのは後付けで初めにそうしたからそうなってる

はてなブックマーク2 - 伊藤 直也氏 株式会社はてな

  • 11/25にリニューアルしたはてブについて
統計で見る現状
  • 3,000,000 UU/月
  • 206,000ユーザ
    • 今月20万になった
  • 1,168,160(何の数字か見逃した…)
ブックマーク数比較(国内主要サイト)
  • ほぼはてなが占めてる
  • IT系に偏ってるイメージがあると思われてるけど、金融とかのカテゴリーの方が多く、ITがずば抜けてるわけではない
PVカテゴリー別
  • IT、ゲーム、エンターテイメントという順番で、ITが一番見られてはいるが、分布は平均的
リニューアル前後の数値
  • ユーザ数純減
    • リニューアル前は300人前後、リニューアル後は400人くらい
  • お気に入り数
    • ベータリリース直後から上がった
  • 広告収益も3倍くらいに上がった(googleなど特定の広告)
  • 今のままでは数値的に微増なので、目標の半年で2倍になるようにもっと施策を打つ
    • UUを300万→600万
      • 国内新聞社と同じくらいなのだけど、そのくらいSBMというメディアを広げたい
リニューアルの方針
  • 既存ユーザの使い勝手を第一に
    • ドラクエ→ドラクエ2にできたら成功、ドラクエ→ファイナルファンタジーにしてしまったら失敗
      • 同じRPGだけど別物になっちゃったらダメ
リニューアルの流れ
  • 初期:基本的なコードベースを作る
    • ここは1人でやった
    • 今後のことを考えてコアを決めたかったのでぶれないように1人で
    • レイヤーや部品の作り方など
  • 中期:新しい機能の整理、方針固め
    • 初期が作れれば後は組み合わせて作れる
  • 後期:スケジュールに沿って実装
    • はてなのユーザを使ってユーザテストも行った
成果
  • システムの作り直しは成功
    • 検索、テキスト分類、お気に入り機能
    • チーム体制→10倍の体力
      • ベータ以降実装したアイディア:ユーザ要望120件以上(バグ修正なども含めば200件以上)
はてなブックマークソーシャルブックマーク)の三軸
  • メディア
    • 新しい情報を発見できる
  • コミュニティ
    • コメントなど

ー機能(今回のリニューアルで強化した場所)

    • 検索できる、お気に入り機能など
なぜ「お気に入り」を強化?
  • 衆愚問題
    • ワイドショー化
  • コミュニティは分散するべき
    • ワイドショー化はさけられない問題だからその方向に行っちゃうのは仕方ない前提で解決策をみつけようとした
「便利ですよ」では使ってもらえない
  • SBMで一番重要だと思ってた機能が全然使われていなかった
  • お気に入りはある程度増えないと面白くない機能だった
    • 1人が3000個ブックマークしたらその人のブックマークだけで埋まっちゃう
  • 増やしたくなるインセンティブが必要
    • 自然と増やしたくなる施策
      • 友達、グループ、スターフレンド、増やすためのUI
リニューアルの結果
  • お気に入り機能の利用率向上
    • グラフ(どういうユーザとやり取りがあるか)が見られる
      • これは重要だと思っている
「お気に入り」機能の今後
  • 外部のグラフも取り込む
  • グループ分け
    • プログラマ」と「大学の友人」はSBMを使う頻度も違うけど両方とも自然に見える仕組みが欲しい
はてなブックマーク検索
  • 過去のブックマークにも光を当てたい
    • 自分のお気に入りが見えることで重要度が一目でわかる
  • はてブRank
検索の今後
  • より一層の精度向上
    • クエリログからのフィードバック
      • これはリニューアルしてからでないととれないので今からだからできること
    • クエリログからのクエリ補正(「もしかして」検索)
  • ブックマークからウェブへ一歩広げる
    • リンク解析→ブックマークにフィードバック
テキスト分類エンジン"BDog"
  • Complement Naive Bayesを利用
  • もともと"BCat"(Bayesかな? + Category)という名前だったが不評だったのでCatをDogにした(発表の中でネタ的な部分だったのに会場あんまり笑わず)
  • 現在のカテゴリは8種類
    • ある程度ヴォリームがないと人気エントリーが作れないのでこれまでの利用傾向から決めた
今後
  • カテゴリごとの新着表示
  • トピックスページ
    • IT系を見る人は
  • カテゴリの細分化
    • デザイン、料理、恋愛、お役立ち
関連エントリーエンジン"BSim"
  • タグの情報を使った類似度検索
    • タグのセマンティクスには踏み込まない(そっちの方が精度が高いという論文を基に)
BSimができるまで
  • 誰が何をブックマークしたか
    • 精度:中
  • ページに含まれるキーワードの類似度
    • 精度:低
    • 逆に下がった
  • タグの類似度
    • 精度:高
    • ダメもとでやってみたら精度が高かった→採用
なぜ内容に踏み込むのか?
  • ブックマーク数だけの評価の限界
  • テキストを扱う企業としての取り込みのアピール
  • 内容に踏み込まない限り新しい道は開けない(という思い込みをしてます)
今後の予定
  • はてなブックマーク市民」
    • 画像を変えたり、タイトルを変えたりするのはある程度使い続けた後のユーザの方が良い
      • ガイドラインは設けてあるのだけど、新しく初めた人みんなが読むわけではないので
フィルタリングに関する基本方針
  • 表現の自由は原則維持
    • 見たくないものを見なくてすむ
    • 見たければすべて見られる
    • 強制消去、特定の表現の入力制限は実装しない
      • 「死ね」とか「馬鹿」とかあっても消さない
    • 削除ガイドラインに沿って運営する
  • 蛸壺化(良いものだけ見たい)に対する懸念
    • 個人的な考えとしては「分散せずに前回」が最も蛸壺化になると思う
      • 古参問題(新しい人が入って来れない)
予想されうる問題への基本姿勢
  • ある程度問題が顕在化し始めたところで対応する
    • コミュニティ運営のコツ
      • はじめからすべての問題を想定してもその通りにならない、効果的な対応策を練ることができない
  • 今後も起こりうるであろう問題
    • 手の込んだspam対策
    • ワイドショー化
    • コミュニティの蛸壺化
    • ベテランユーザと新規ユーザの衝突
質疑応答
  • 関連エントリーの検索について
    • 本文も対象にした(RSSから本文を取得していたので)
    • はてなキーワードから抽出していたのでその範囲が狭かったのかもしれない
  • 検索の詳細条件があった方がユーザは使いやすいんじゃないか?
    • それは今のところやる予定はなく、検索のポリシーとしては「一つの窓に入力すると上手い具合に結果が出てくる」が良いと思っている
  • エントリーページのコメントの日付の昇順降順ソートは変える予定はないか?スターの数でソートもしたい
    • コメントのソートは変えるつもりない
      • greasemonkeyで使ってみたのだけど、自分は使い勝手がよくなかったので
      • ユーザ要望が多ければまた考える
    • スターの性質上、今すぐ並べ替えはできないのだけど、要望があるのでやりたいとは思っている。まずは世の中になるgreasemonkeyを使ってみて
  • お気に入り機能について何かある?
    • スターフレンドの友達関係をそのままお気に入りにもってくるユーザもいたので
  • 自動カテゴリー機能が良すぎるのだけど、何か工夫してるんじゃないの?
    • 細かい実装部分は自分がやったわけではないのでわからないが、そんなに特殊なことはやってないはず
  • ユーザの伸びとコストパフォーマンスは?
    • 良くて1/10、悪くて1/2のコストでマシンを用意できるのであまり問題視はしていない

Kikker の Map/Reduce 化 - 藤田 昭人氏 IIJ−II/大阪市立大学大学院 創造都市研究科

Kikkerのおさらい
Kikkerをやる気になった理由
  • 第1回ソーシャルブックマーク研究会でRyo氏が発表が面白かったので
  • 仕事のこともあり、Map/Reduceで実装しようと思った
  • まだ誰もやってない様子
Map/Reduce版Kikkwer
  • 大量のクローリングと解析ならMap/Reduce
Webページのクロール・解析

(…こっから話聞く方に集中しちゃって書けなかった。内容泥臭くて面白かった。はてなへのDDoS攻撃とか。分散リクエストで8万リクエストくらい投げたらしいけど、naoya氏曰く、「RSSというものがありますから、それを使ってもらえるとありがたいです」)

パネルディスカッション - SBM研究を加速・拡大するために−SBM事業者には何ができるのか

パネラー
事業者からの研究 井原郁央氏(株式会社ライブドア
  • SBMの役目は何か?
    • 情報に付加価値を与える
      • 第三者による評価:人のつながり
      • 情報間の関係性:情報のつながり
  • つながりが増える結果得られるもの
    • 個人・分野に特化した外部記憶・検索エンジン
      • また利用者の興味や目的が絞り込めてるということは高い広告マッチ率が得られる(ぶっちゃけここを研究してもらいたい)
  • 冗談っぽく話をしているが、コンテンツマッチ広告はSBMビジネスを成り立たせるために必要
    • 統計学などの技術も重要
    • だけど、作りたいのはガス水道電気などのような身近なもの
  • SBMの役目に対するlivedoorクリップの3つのhome
    • マイクリップ
    • ウォッチリスト
      • 人のつながり
    • オススメクリップ
      • 情報のつながり
  • プログラマ視点で見たSBM
    • 「大量のデータ」と「複雑な関連性」
      • 550万clips,330万urls,12万users,1000万tagsを使って、様々な集計(タグの絞り込みなど)やソートの組み合わせを行う
      • 誰かが新しいクリップを追加したらすべてのデータに影響がある→キャッシュの更新
      • この辺りの「検索技術」「キャッシュ技術」は良い研究対象になるのでは?
  • 研究者の方々に提供できるもの
    • 公開情報は何でも
    • 以前色々提供できるものを考えていたんだけど、いざ公開して使ってもらったら寂しいから逆に聞きたい
  • 実サービスも使っていいよ
    • インターンで来てもらって勝手に実験的機能を作ってもらって勝手に論文書いてもらうとかでもいい
      • 京都(はてな)より近いからインターンに来やすい
Yahoo!ブックマーク 澤田 哲也氏 (ヤフー株式会社)
  • Yahoo!ブックマークの歴史
    • 2001年8月7日
      • オンラインブックマーク
    • 2007年4月17日
      • 大幅リニューアル
      • 登録ページの全文保存、全文検索
      • Y!ツールバーとの連携
    • 2007年6月14日
      • Yahoo!検索結果にブックマークの登録人数表示を開始
    • 2008年9月17日
      • Yahoo!プロフィールとの連携を開始
  • 特徴
    • ブラウザブックマークに近い操作
    • 多機能にした
      • ここは少し反省
  • 研究用データ提供
    • APIはまだ用意していない
    • 知恵袋や検索など、他のY!のサービスでは色々な情報を提供しているので、その流れに乗せて今後提供したい
SBM事業者には何ができるのか 須藤 洋一氏 (株式会社ECナビ)
  • Buzzurl
    • 54,000ユーザ
  • 特徴
    • コミュニケーション指向
      • SBMとTwitterを足して2で割ったもの
      • 長文コメント可能
      • コメントに対する返信が可能
      • 自分のページで他の人のコメントが見える
    • ユーザ層(ざっくり。このためだけに集計するのはコストかかるので)
      • 「ギーク」系少なめ
      • 「スーツ」系多め
      • 主婦多め
    • 意外と古株
      • 2003年にdelicious
      • 2005年にはてな
      • 2005年11月にBuzzurl
  • 情報提供実績
    • いろんな論文へのデータ提供をしている
  • 提供情報
    • タグやコメントなど
    • 大抵はNDAを結んでもらう
  • 学術研究への希望
    • スパム解析はどうですか?
今回のパネルディスカッションの目的 岡本氏 (ヤフー株式会社)
  • SBMのデータへのニーズは感じている
  • そもそも追試不可能な研究はサイエンスではない
    • 個別にクロールやスクレイプなどをして研究している
    • SBM事業者を集めて何かしら研究についての関係ができると良い
  • また、自分は複数SBM利用者であり、個人的にはユーザはそれぞれのSBMの使い分けをしてると思う
    • この部分の研究はすごく面白そうなのだけど、これをやるためには事業者間で足並みをそろえた方が良さそう
研究者から見たSBM研究 上野氏
  • データを全部もらうためにクローリングなどをしなくてはいけなくなる
    • はてなの伊藤氏に連絡して何とかなった
    • コミュニティの分野の研究やspamの研究は面白そう
SBM研究の現在 大向氏
  • 基本的には3部グラフ(情報、知識、人)
      1. α:タイムスタンプ、コメント
    • up-to-dateである必要性はない
  • 基本的に個別で研究者が個別のサービスに問い合わせ
    • 無断クロールの場合もある
  • 現状わかっている問題点
    • 別の研究者が再現できず「このくらい効果が上がりました」が言えない
    • 共通データセットが必要
  • 共通データセットによる研究例
  • 研究側の問題
    • 契約主体
      • NDAとか。どういう契約を行えば良いのか
    • 成果の取り扱い
      • 特許問題。リリースと足並みそろえたり
    • 発表の場
    • 事業者へのメリット
      • これがなければ事業者は協力してくれないよね
研究に期待するもの
  • 須藤氏:個人的に今日のような場は楽しい。なるほどなと思う。
    • アカデミックとビジネスとのずれが感じられる
  • 澤田氏:みんなが持っているものと、Y!が持っているものを合わせて新しいものが生まれるとうれしい
    • ビジネスに縛られずに研究をしてもらって新しいものを生み出したい
  • 井原氏:さっき言った通り、SBMをもっと広げてガスなどのような日常品のようにしてもらいたいけど、それを研究者の方にやってもらいたいのかどうなのかと考えるとよくわからない
  • 伊藤氏:webサービスはすぐ横並びになってしまう。spamや検索などの技術的なところは優越が生まれる部分だからそこは事業者ががんばるところだと思う。
    • そういう研究よりも事業者が気づいていないような研究の方を教えてもらいたい
どういう条件だったら協力できるか
  • 須藤氏:基本的にはNDA結んでもらえれば
  • 澤田氏:NDA結んで変なものにならなければ
  • 井原氏:特に決まりがなく、逆に何か加工してもらいたいとかだとコストかかるので、できれば「こういうもの」って決まった形でみんな要望を出してもらえたらいいなと思う
  • 伊藤氏:パブリックでユーザの著作権がないデータなら提供できる。人件コストの余裕がないのと、ネットワークの余裕がないので、そういう場が欲しい
最低限欲しいもの
  • 大向氏:10万件欲しいとか30万件欲しいとかは特にない
    • 説明できるデータなら1000件でも全く問題ない
      • スクレイピングしたデータは説明ができないので。「なぜこのページをスクレイプしたの?そもそもそのデータであってるの?」
  • 上野氏:個人的にはユーザ数をもっと増やして全部もらいたい
    • webの研究をしていると、実用的な新しい研究をやりたくなるため、そういう考えになってしまう
共通フォーマットについて
  • 須藤氏:企業間でサービスの中身が違うので共通化が難しいのかな?と思うのだけどどうだろう?
  • 伊藤氏:技術的な部分よりも政治的な障害の方が大きいと思う。誰が音頭をとるかとか。
  • 大向氏:共通化は各社が共通する部分を取り出せば良いのかなと思ってる
    • タグの編集は機械的でなく、ユーザがやっているので、その傾向をとるなどでも研究になる
データを提供するために何か研究者が助けられる?
  • 澤田氏:Y!がデータを提供していない理由は2つ
    • APIの準備がまだできない
    • 今までのオンラインブックマーク時代が長かったため、ユーザの非公開部分の傾向が出てしまいそうで心配
研究のためのクロール
  • 伊藤氏:機械的なクロールをするロボットは別セットが受けている(そっちのマシンの方が多い)
    • あと、クロールしなくてもサポートなどに連絡くれればデータをあげますよ
企業間の同一ユーザという情報は取得できるか?
  • 伊藤氏:会社によってIDの重みが違うからリスクを考えると難しいと思う
できごと単位でSBMを使っている。同じニュースが新聞ごとにあるときにどういう扱いをしているのか知りたい
  • 井原氏:ぜひやってもらいたい研究
  • 須藤氏:Buzzurlにはそういうことをやるために関連機能があるのだけど、見せ方がまずかったのか上手くいってない
    • 100件中数件?とかしか登録されていない
  • 伊藤氏:ドキュメントクラスタみたいなことはやってみたいと思ってる
コメント(PFIの太田さんかな?)
  • 米国Netflixのレーティング機能の賞金1億円をかけた研究はとても上手くいった。それでリコメンド機能は確立されたが、そのデータと他のWebサイトを示し合わせてユーザの個人情報がバレバレになったから共通フォーマットも考えもの