第2回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対応アンテナ
- クリップ機能がついていたが先進的すぎていまいち上手く作用しなかった
- RNA：日本初（世界初？）のRSS対応アンテナ
- セマンティックウェブからのアプローチ2004〜
- 論文を書いたがdeliciousの「Ontologies are us」に全部もってかれた
- SBMに関しては敗北ばかりだけどやっぱり研究を続けている
なぜ研究するか？
偏りを知るために
-
- 全人類の興味・関心の平均との距離を測ればよいのだけどそれは無理
- 「偏りがないと意味をなさない仕組み」の有用性を検証する
- 全人類の興味・関心の平均との距離を測ればよいのだけどそれは無理
研究のアプローチ
- 既存の数理モデルをあてはめるのが目的ではない
- フィールドワーク的
- コミュニティにどっぷりつかる
- シンプルに仮説を作って検証、改良
SBMと推薦について
- 内容ベースの場合
- コンテンツの類似度を計算し、高いものを推薦
- 人が介在しない
- 協調フィルタリングの場合（今回はこっちを採用した）
- 同じブックマークをもつユーザを見つけ、そのブックマークを推薦
- 似たユーザのデータを推薦
- ユーザの嗜好データを事前に取得（計算）
- 同じブックマークをもつユーザを見つけ、そのブックマークを推薦
予備実験
- シミュレ−ション
- 期間を前半、後半に分ける
- 前半のデータで協調フィリタリングのモデルを作成
- 後半のデータとの一致を見る
- （実際の推薦ではなく、測定をしてみるだけ。なので、ホントに推薦していたらブックマーク受理率はあがるかもしれないけど、シミュレーションでその実験はできないので）
- 結果はまったく効果がなかった
- 10,000の推薦データのうち4つくらいしかヒットしなかった
- SBMの性質上、ニュース性があるものは瞬間的にブックマークされるため、期間をわけても昔のURLはブックマークされない
SBMのための協調フィルタリング
- 最新のコンテンツを推薦するために考察
- 富豪的アプローチ（これをやるのは難しい）
- リアルタイムに新規のデータを取り込み、モデルを再計算
- 膨大な計算コストがかかってしまう
- 「偏り」を仮説としてもっておくと上手くいきそう
- SBMにはイノベータとフォロワーがいる
- いち早くコンテンツをブックマークする人のブックマークを他の人に推薦する
- 富豪的アプローチ（これをやるのは難しい）
SBMのイノベータ
- 1ゲッターに着目
- 1ゲッターの回数と人数と傾向（全ユーザは3503人）
- 100回以上83人：全体の91.9%のブックマークをカバー
- 10回以上:266人：98.4%
- ECナビ人気ニュースの「スクープ記者」の性質のせいかもしれないが、少人数が9割以上をカバーしている
イノベータからの推薦を考慮してのシミュレーション
- 前半データ
- 各ユーザとイノベータ群の類似度を計算
- 後半データ
- 類似度の高いイノベータ群がブックマークしたコンテンツのうち、各ユーザがどの程度受理したかを測定（これも実際に推薦を行うのではなくヒット率ということ）
シミュレーション結果
- 実際に推薦した訳ではないが前の実験より上手くいった
- 大体100個推薦で8個くらい
- 上手くいったのに前の実験より計算量が激減
- 協調フィルタリングは１回走らせるだけ
- 嗜好の変化を考えて何回か計算してみたが、400日程度では人のブックマーク嗜好は変わらないってこともついでにわかった
- 協調フィルタリングは１回走らせるだけ
興味・関心の偏りについて
- SBMがつくるコミュニティには長期的な興味・関心が存在している
- これはブックマーク数では判断できないこと
- それぞれのブックマークが長期的関心に合致するか判断するためには
- 個々のユーザのタグ付与行動履歴を観察
- 総体として作られるコミュニティの嗜好を利用
長期的な関心と短期的な関心についての推測
- 初めて付けられたタグは短期的な関心ではないか？
- もしそのタグがその後のブックマークに付けられたならば、それは長期的な関心になったと言えないか？
推測を基に短期的指標を定義
- あるブックマークに「どのくらいの新規タグ」が付いているか
- 再利用タグ（今まで現れたことのあるタグ）ばかりのブックマークは長期的な関心が強い
コミュニティの興味関心
ここまでのまとめ
- SBMコミュニティに存在する「偏り」
- 内部から見えてくるもの
- この「偏り」が存在するのは避けられない
- 内部から「偏り」の姿を見たい
- 「偏り」を積極的に活用したい
- 「偏り」についてシンプルなアプローチを考える（これが本題）
- メタデータの分析のみ
- 計算量を押さえて実用化
何のためのSBM？
- SBMが提供する機能
- 個人向けとして
- 保存、整理、投票、コメント、スクラップブック
- 集合知として
- 情報の発見、外部からの評価
- 個人向けとして
SBMに期待されるもの（アンケート）
- 多用途で一つの使い方ではない
- 自身のため
- 他のユーザに注目されたい
- サイトの管理者へのメッセージ
SBMの現在を考えると
- 多用途に耐えるシステムになっている
- 使いこなせる気持ちよさ？
- ひとことで言い表しにくい
- 母親に説明しようとしたら難しい
- ブログなら日記、SNSなら井戸端みたいに言えるんだけどSBMってどういう風に言ったらいいか
- 機能分化の可能性があり、新しい対象や新しい用途がでてきている
現実のコミュニティとは？
- 研究室、職場、家では？
- クローズ、半クローズなコミュニティに囲まれている
- FYIメール（「参考までに」のメール）
- FYIといいながら強制的に読ませる目的がある
- 以上のことから求めているものを考えると、
- 双方向的で複数なコミュニティがある
- 強制的に読ませる仕組みがある
4dk
- コミュニティブックマーク
- FYIメールを現代化する
- 宛先のある情報のやりとり
- 重要な情報=誰かに伝えたい情報
- 宛先=コミュニティ
- だけど、コミュニティは一つではない
- 読まれたかどうかがメタ情報となる
- リアルのコミュニケーションとの連動
- 宛先のある情報のやりとり
- 名前の由来（オフレコだったけどITmedia?で出ちゃったから）
- 読んどけ
4dkのデモ
- たくさんコミュニティを作れる
- ユーザ自身はトップページを見ることがあんまりない
- ダッシュボードという機能で複数のコミュニティを管理
- 検索は？
- はてなは全部検索があるけどそこまでできない
- コミュニティがあるので、人の名前で検索できる
- 「誰が投稿・コメントしたか」の検索
- グループの中でどのくらいの人が読んだかをパーセンテージで表示している
- 視聴率機能
- 仕事場で使うときに「資料読んだかどうか」をチェックするのはめんどう。それをゲーム感覚で解消するようなツールにしたかった
その他4dkの機能
- 朝刊メール
- 前日のキャッチアップ
- 夕刊メール
- 他のグループからのおすすめ
運用結果
- 2ヶ月ほど運用して
- 圧倒的にクローズドグループが多い
- 公開しているのは少ない（そういうのは他のSBMサービスに任せればいい）
- １人グループ、２人グループ（彼氏彼女みたいでやってるみたいな。でも中身は見てないよ）
- 圧倒的にクローズドグループが多い
- 反省点
- もっとシンプルで良かった
- グループ設定とか
- Ajax使いすぎて一般ユーザがわかりにくい
- もっとシンプルで良かった
本音と課題
- ソーシャルってなんだろう？
- 「不特定多数と私」だけではないはず
- 「私を取り巻くコミュニティ」の集まりもある
- コミュニティの1つに不特定多数がある
- これを補うのが4dk
- 切実な情報共有の問題
- 「読んでもらわないと困る」と「あとで読みたい」は質的に異なる
- 課題
- コミュニティの本質的な面倒さを軽減したい
- ソーシャルグラフ作り
- グループ設定
- 既存のコミュニティを取り込む
- コミュニティの本質的な面倒さを軽減したい
質疑応答
- 営業の例のように「読んどけ」と言いたいので会社で使えそう。社内のサーバで使えないか？
- パッケージ化はできるので、それをそのまま持っていけるようにできたらいいかも
- イノベータのブックマークを推薦するのと、イノベータのブックマークを定期購読しているのと何が違う？
- 「自分ととても似ている1人の人間」はほぼ存在しない
- 仮想イノベータをシステム的に作らないと上手くいかない
- 例えば4人定期購買していて、そのうちの3人ブックマークしたコンテンツなら推薦、１人なら推薦しないなどのようにしないと上手くいかない
ソーシャルブックマークデータの時間情報を用いた情報フィルタリングと検索 - 上野 大樹氏 慶應義塾大学大学院
SBM研究の種類は大きく4つある
- SBM,FolkSonomyの分析
- ユーザ、タグ、ブックマークの性質について分析
- webページ推薦
- ブックマーカーの発見
- アルファブックマーカーを利用する
- Webページ検索（これが今回の話）
- SBRank（ブクマ数の多さ）をPageRankと融合して有用なページを探す
Webページ検索
- blogやwikiなど自動的にページ間を結びつける場合は人々の意思が入ってないのでリンクだけのRankではダメ
- SBMのブクマ数を利用する
- ただし、SBMの場合、トップに出るとブクマ数が急激にあがるからそのまま使うのはまずい
- 一時的にブクマ数が増えたページが後で見て有用か？
- また、個人の嗜好が入る
ブクマ数と時間の関係
- 3つのタイプがある
- 瞬間的にブックマークされる
- ニュースなど
- 急激にブクマ数が増える時期があり、ブクマされ続ける
- 「〜の使い方」のようなページ
- 急激に増えず、ブクマ数が増える
- ポータルサイトなど
- 瞬間的にブックマークされる
2つに分類
Type1:瞬間的にブクマされる - ブクマされた日数/ブクマ数=0.2以下
Type2:長期的にブクマされる - ブクマされた日数/ブクマ数=0.8以下
セレクトブクマの開発
- 長期的にブクマされるタイプのページType2を優先的に収集する
- 何度も利用するタイプのページ、いつ見ても有用なページを抽出したい
- β版公開:http://plazman.chi.mag.keio.ac.jp/sbm/summary.jsp
セレクトブクマのランキングロジック
- ブクマ数*日数^α（α=0,1,2）
- 日数は2008/11/01,2008/11/08,2008/12/01にブクマとかなら3日とか
考察
- ブクマ数の多いタグによる1単語検索で有用
- 一時的、暫定的なページをフィルタ
- Google検索と比較して、その単語について詳しく知りたい場合に有用
今後の課題
- ロジックの改良
- 現時点だと古いページが有利になってしまう
- ブクマされた時期などによる重み付け
- タグを付ける行為の意味（フィールドワーク）
- タグ率の利用
- 現時点だと古いページが有利になってしまう
（おまけ）ブクマストリーム
- 月刊ランキング
- ブクマ数順にランキング化して表示
- ブクマ数の多いページをまとめてチェック
- 過去のブクマ数の多いページを発見
質疑応答
普通のヤツらのメタをゆけ - 広木 大地氏 日本野望の会
フロント技術の話
- ソーシャルグラフとは何か
- 既存のWebにオーバレイすることと問題点
Social Graphe
- 現実あるいはその延長線上の社会的関係グラフ、これらを用いたサービスに対してのNeeds
- 知人、他人のブックマークを見たい、自分のブックマークを見せたい
- （SBMの場合、要は）記事への意見を見たい、見せたい
- つまりSBMの場合、記事を介して他人とつながっているので、記事Authorが介在している
Overlay Web
- ある記事に対してSBMのページがかぶさっている
- Bという人が記事をブクマし、コメントを書き、それを他人のAという人が読む
- SBMはWeb上の記事のOverlay
SBMを解体すると
- SBMはWeb上の記事のURLを持っているURLのサービス
- URL on URLサービス
- http://b.hatena.ne.jp/entry/＜記事のURL＞
- URL on URLサービス
メタ構造
- ブックマークの集合記事もまたOverlayされる対象になりうる
- 例えば、何かの記事がブクマされ、そのコメントなどに対してコメントを付けるために「元記事のブクマページ」をブクマされることがある
- 「元記事」→「ブクマ」→「メタブクマ」
- 例えば、何かの記事がブクマされ、そのコメントなどに対してコメントを付けるために「元記事のブクマページ」をブクマされることがある
- 記事をブクマして、そのブクマコメントページをさらにブクマして、それが繰り返されて…
- メタメタメタブクマなんていうのもあり得る（URLにどんどんブクマされたURLがつながる）
- URLのLength制限はあるか？
- HTTP/1.1によると特に制限はない。「要はがんばれ」
- メタ×32ブクマもあり得る
- メタ(メタ…)ページの作成＆コメント構造は既に見受けられる
- 2chのまとめとか：「ニュース」→「そのニューススレッド」→「まとめサイト」→「まとめサイトブクマ」→「まとめサイトメタブクマ」
- そもそもニューススレッドからまとめサイトも「手動メタ構造」
- 2chのまとめとか：「ニュース」→「そのニューススレッド」→「まとめサイト」→「まとめサイトブクマ」→「まとめサイトメタブクマ」
さて、SBMサービスは、SBMでのSocial Graphに介在している記事Authorへの通知や連携を前提としていない
話は変わってブックマークレット
- div+iframeのはてなブックマークレットが少し前に話題になったけど、window.openもlocation.hrefもフック可能なブラウザが存在する
- 閲覧しているサイト側でブックマークレットを押されたことを検知して偽物のscriptを実行してユーザをだませる
- 標準的なものを決めてセキュリティリスクをみんなで負いましょう
質疑応答
- ブックマークレットのセキュリティについて詳しく
- location.hrefでリダイレクトする以外は全部JavaScriptでフックできちゃう
- window.openはアドレスバーが見えるから安全と思われているが、ブックマークレットはそれ自体に安心感があるから、ブックマークレット押した時点でアドレスバーなんて普通見ないよね
- だからリスクをまとめてみんなで対策をとるのが良いんじゃないか？
ソーシャルブックマークサービスのSEO力 - 美谷 広海氏 楽天株式会社
外部サイトのブックマークボタン
- ニュースサイトなどにおいてある「ブックマーク追加リンク」による被リンク
- はてなはサービスが密に連携していて被リンクが多い
より速くインデックスされるメリットの意味
- 2つのサイトがあったとき、速くインデックスされたサイトはもう片方より価値が低いサイトだったとしても被リンクを得られやすい
- 速くインデックスされるということは、それだけ速く検索結果に出るということ
- もう一方が検索結果に上がる前に人が訪れる可能性が高く、訪れた人はそのサイトが有用だと思えば、その時点でリンクを付ける
- もう一方が検索結果に上がるようになった頃には、元々検索結果に出ていたページは既に被リンク数が増えている
SBMコメント機能によるコミュニケーション形態の考察 - 西谷 智広氏
考察の背景
- 自分のブログのはてブのコメントが気になってる
- 通勤のときにチェックするくらい気になってる
- SBMのコメントとは？
- 分類用のためだったと思うのだが、最近はコミュニケーションに使われる
BlogコメントからSBMコメントへ移り変わっていってる？
コメントコミュニケーションの分類
- 自分のため（これは本来のSBMコメント）
- ブロガーとのコミュニケーション
- 他のSBMユーザとのコミュニケーション
- 受け狙い
- ブロガーがセルクマでコミュニケーションをとることも
SBMコメントの時系列概念
- はてブは1人1回のコメント
- 後のSBMコメントを受けて修正する人はいる
- ブックマークの順番を修正するのは面倒
- ブックマークの順番によってコメントは影響される？
- 同じコメントは書けないような雰囲気がある
コメントのクオリティをあげるためにはどういう仕組みがあると良い？
- SBMユーザへのインセンティブ
- コメント記述のフィルタリングとリコメンド
- 良くないものは見えないようにする、良いものは見えるようにする
はてなブックマーク2 - 伊藤 直也氏 株式会社はてな
- 11/25にリニューアルしたはてブについて
統計で見る現状
- 3,000,000 UU/月
- 検索サイトからの一見さんも含む（Google Analytics）
- 206,000ユーザ
- 今月20万になった
- 1,168,160(何の数字か見逃した…)
ブックマーク数比較（国内主要サイト）
- ほぼはてなが占めてる
- IT系に偏ってるイメージがあると思われてるけど、金融とかのカテゴリーの方が多く、ITがずば抜けてるわけではない
PVカテゴリー別
- IT、ゲーム、エンターテイメントという順番で、ITが一番見られてはいるが、分布は平均的
リニューアル前後の数値
- ユーザ数純減
- リニューアル前は300人前後、リニューアル後は400人くらい
- お気に入り数
- ベータリリース直後から上がった
- 広告収益も3倍くらいに上がった（googleなど特定の広告）
- 今のままでは数値的に微増なので、目標の半年で2倍になるようにもっと施策を打つ
- UUを300万→600万
- 国内新聞社と同じくらいなのだけど、そのくらいSBMというメディアを広げたい
- UUを300万→600万
リニューアルの方針
- 既存ユーザの使い勝手を第一に
- ドラクエ→ドラクエ2にできたら成功、ドラクエ→ファイナルファンタジーにしてしまったら失敗
- 同じRPGだけど別物になっちゃったらダメ
- ドラクエ→ドラクエ2にできたら成功、ドラクエ→ファイナルファンタジーにしてしまったら失敗
リニューアルの流れ
- 初期：基本的なコードベースを作る
- ここは１人でやった
- 今後のことを考えてコアを決めたかったのでぶれないように１人で
- レイヤーや部品の作り方など
- 中期：新しい機能の整理、方針固め
- 初期が作れれば後は組み合わせて作れる
- 後期：スケジュールに沿って実装
- はてなのユーザを使ってユーザテストも行った
成果
- システムの作り直しは成功
- 検索、テキスト分類、お気に入り機能
- チーム体制→10倍の体力
- ベータ以降実装したアイディア：ユーザ要望120件以上（バグ修正なども含めば200件以上）
なぜ「お気に入り」を強化？
- 衆愚問題
- ワイドショー化
- コミュニティは分散するべき
- ワイドショー化はさけられない問題だからその方向に行っちゃうのは仕方ない前提で解決策をみつけようとした
「便利ですよ」では使ってもらえない
- SBMで一番重要だと思ってた機能が全然使われていなかった
- お気に入りはある程度増えないと面白くない機能だった
- 1人が3000個ブックマークしたらその人のブックマークだけで埋まっちゃう
- 増やしたくなるインセンティブが必要
- 自然と増やしたくなる施策
- 友達、グループ、スターフレンド、増やすためのUI
- 自然と増やしたくなる施策
リニューアルの結果
- お気に入り機能の利用率向上
- グラフ（どういうユーザとやり取りがあるか）が見られる
- これは重要だと思っている
- グラフ（どういうユーザとやり取りがあるか）が見られる
「お気に入り」機能の今後
検索の今後
- より一層の精度向上
- クエリログからのフィードバック
- これはリニューアルしてからでないととれないので今からだからできること
- クエリログからのクエリ補正（「もしかして」検索）
- クエリログからのフィードバック
- ブックマークからウェブへ一歩広げる
- リンク解析→ブックマークにフィードバック
テキスト分類エンジン"BDog"
- Complement Naive Bayesを利用
- もともと"BCat"（Bayesかな? + Category）という名前だったが不評だったのでCatをDogにした（発表の中でネタ的な部分だったのに会場あんまり笑わず）
- 現在のカテゴリは8種類
- ある程度ヴォリームがないと人気エントリーが作れないのでこれまでの利用傾向から決めた
今後
- カテゴリごとの新着表示
- トピックスページ
- IT系を見る人は
- カテゴリの細分化
- デザイン、料理、恋愛、お役立ち
関連エントリーエンジン"BSim"
- タグの情報を使った類似度検索
- タグのセマンティクスには踏み込まない（そっちの方が精度が高いという論文を基に）
BSimができるまで
- 誰が何をブックマークしたか
- 精度：中
- ページに含まれるキーワードの類似度
- 精度：低
- 逆に下がった
- タグの類似度
- 精度：高
- ダメもとでやってみたら精度が高かった→採用
なぜ内容に踏み込むのか？
- ブックマーク数だけの評価の限界
- テキストを扱う企業としての取り込みのアピール
- 内容に踏み込まない限り新しい道は開けない（という思い込みをしてます）
今後の予定
- 「はてなブックマーク市民」
- 画像を変えたり、タイトルを変えたりするのはある程度使い続けた後のユーザの方が良い
- ガイドラインは設けてあるのだけど、新しく初めた人みんなが読むわけではないので
- 画像を変えたり、タイトルを変えたりするのはある程度使い続けた後のユーザの方が良い
フィルタリングに関する基本方針
- 表現の自由は原則維持
- 見たくないものを見なくてすむ
- 見たければすべて見られる
- 強制消去、特定の表現の入力制限は実装しない
- 「死ね」とか「馬鹿」とかあっても消さない
- 削除ガイドラインに沿って運営する
- 蛸壺化（良いものだけ見たい）に対する懸念
- 個人的な考えとしては「分散せずに前回」が最も蛸壺化になると思う
- 古参問題（新しい人が入って来れない）
- 個人的な考えとしては「分散せずに前回」が最も蛸壺化になると思う
予想されうる問題への基本姿勢
- ある程度問題が顕在化し始めたところで対応する
- コミュニティ運営のコツ
- はじめからすべての問題を想定してもその通りにならない、効果的な対応策を練ることができない
- コミュニティ運営のコツ
- 今後も起こりうるであろう問題
- 手の込んだspam対策
- ワイドショー化
- コミュニティの蛸壺化
- ベテランユーザと新規ユーザの衝突
質疑応答
- 関連エントリーの検索について
- 検索の詳細条件があった方がユーザは使いやすいんじゃないか？
- それは今のところやる予定はなく、検索のポリシーとしては「一つの窓に入力すると上手い具合に結果が出てくる」が良いと思っている
- エントリーページのコメントの日付の昇順降順ソートは変える予定はないか？スターの数でソートもしたい
- コメントのソートは変えるつもりない
- greasemonkeyで使ってみたのだけど、自分は使い勝手がよくなかったので
- ユーザ要望が多ければまた考える
- スターの性質上、今すぐ並べ替えはできないのだけど、要望があるのでやりたいとは思っている。まずは世の中になるgreasemonkeyを使ってみて
- コメントのソートは変えるつもりない
- お気に入り機能について何かある？
- スターフレンドの友達関係をそのままお気に入りにもってくるユーザもいたので
- 自動カテゴリー機能が良すぎるのだけど、何か工夫してるんじゃないの？
- 細かい実装部分は自分がやったわけではないのでわからないが、そんなに特殊なことはやってないはず
- ユーザの伸びとコストパフォーマンスは？
- 良くて1/10、悪くて1/2のコストでマシンを用意できるのであまり問題視はしていない
Kikker の Map/Reduce 化 - 藤田 昭人氏 IIJ−II/大阪市立大学大学院 創造都市研究科
Kikkerのおさらい
- はてブの新着リストを自分好みの順序で表示するサービス
- 新しいネタを知るにはとっても便利
- 第1回ソーシャルブックマーク研究会でRyo氏が発表
Kikkerをやる気になった理由
- 第1回ソーシャルブックマーク研究会でRyo氏が発表が面白かったので
- 仕事のこともあり、Map/Reduceで実装しようと思った
- まだ誰もやってない様子
Map/Reduce版Kikkwer
- 大量のクローリングと解析ならMap/Reduce
- Googleも使ってる
パネルディスカッション - SBM研究を加速・拡大するために−SBM事業者には何ができるのか
パネラー
事業者からの研究 井原郁央氏（株式会社ライブドア）
- SBMの役目は何か？
- 情報に付加価値を与える
- 第三者による評価：人のつながり
- 情報間の関係性：情報のつながり
- 情報に付加価値を与える
- つながりが増える結果得られるもの
- 個人・分野に特化した外部記憶・検索エンジン
- また利用者の興味や目的が絞り込めてるということは高い広告マッチ率が得られる（ぶっちゃけここを研究してもらいたい）
- 個人・分野に特化した外部記憶・検索エンジン
- 冗談っぽく話をしているが、コンテンツマッチ広告はSBMビジネスを成り立たせるために必要
- 統計学などの技術も重要
- だけど、作りたいのはガス水道電気などのような身近なもの
- SBMの役目に対するlivedoorクリップの3つのhome
- マイクリップ
- ウォッチリスト
- 人のつながり
- オススメクリップ
- 情報のつながり
- プログラマ視点で見たSBM
- 「大量のデータ」と「複雑な関連性」
- 550万clips,330万urls,12万users,1000万tagsを使って、様々な集計（タグの絞り込みなど）やソートの組み合わせを行う
- 誰かが新しいクリップを追加したらすべてのデータに影響がある→キャッシュの更新
- この辺りの「検索技術」「キャッシュ技術」は良い研究対象になるのでは？
- 「大量のデータ」と「複雑な関連性」
- 研究者の方々に提供できるもの
- 公開情報は何でも
- 以前色々提供できるものを考えていたんだけど、いざ公開して使ってもらったら寂しいから逆に聞きたい
- 実サービスも使っていいよ
- インターンで来てもらって勝手に実験的機能を作ってもらって勝手に論文書いてもらうとかでもいい
- 京都（はてな）より近いからインターンに来やすい
- インターンで来てもらって勝手に実験的機能を作ってもらって勝手に論文書いてもらうとかでもいい
Yahoo!ブックマーク 澤田 哲也氏 （ヤフー株式会社）
SBM事業者には何ができるのか 須藤 洋一氏 （株式会社ECナビ）
今回のパネルディスカッションの目的 岡本氏 （ヤフー株式会社）
- SBMのデータへのニーズは感じている
- そもそも追試不可能な研究はサイエンスではない
- 個別にクロールやスクレイプなどをして研究している
- SBM事業者を集めて何かしら研究についての関係ができると良い
- また、自分は複数SBM利用者であり、個人的にはユーザはそれぞれのSBMの使い分けをしてると思う
- この部分の研究はすごく面白そうなのだけど、これをやるためには事業者間で足並みをそろえた方が良さそう
研究者から見たSBM研究 上野氏
- データを全部もらうためにクローリングなどをしなくてはいけなくなる
- はてなの伊藤氏に連絡して何とかなった
- コミュニティの分野の研究やspamの研究は面白そう
SBM研究の現在 大向氏
研究に期待するもの
- 須藤氏：個人的に今日のような場は楽しい。なるほどなと思う。
- アカデミックとビジネスとのずれが感じられる
- 澤田氏：みんなが持っているものと、Y!が持っているものを合わせて新しいものが生まれるとうれしい
- ビジネスに縛られずに研究をしてもらって新しいものを生み出したい
- 井原氏：さっき言った通り、SBMをもっと広げてガスなどのような日常品のようにしてもらいたいけど、それを研究者の方にやってもらいたいのかどうなのかと考えるとよくわからない
- 伊藤氏：webサービスはすぐ横並びになってしまう。spamや検索などの技術的なところは優越が生まれる部分だからそこは事業者ががんばるところだと思う。
- そういう研究よりも事業者が気づいていないような研究の方を教えてもらいたい
どういう条件だったら協力できるか
最低限欲しいもの
- 大向氏：10万件欲しいとか30万件欲しいとかは特にない
- 説明できるデータなら1000件でも全く問題ない
- スクレイピングしたデータは説明ができないので。「なぜこのページをスクレイプしたの？そもそもそのデータであってるの？」
- 説明できるデータなら1000件でも全く問題ない
- 上野氏：個人的にはユーザ数をもっと増やして全部もらいたい
- webの研究をしていると、実用的な新しい研究をやりたくなるため、そういう考えになってしまう
共通フォーマットについて
- 須藤氏：企業間でサービスの中身が違うので共通化が難しいのかな？と思うのだけどどうだろう？
- 伊藤氏：技術的な部分よりも政治的な障害の方が大きいと思う。誰が音頭をとるかとか。
- 大向氏：共通化は各社が共通する部分を取り出せば良いのかなと思ってる
- タグの編集は機械的でなく、ユーザがやっているので、その傾向をとるなどでも研究になる
データを提供するために何か研究者が助けられる？
- 澤田氏：Y!がデータを提供していない理由は2つ
- APIの準備がまだできない
- 今までのオンラインブックマーク時代が長かったため、ユーザの非公開部分の傾向が出てしまいそうで心配
研究のためのクロール
- 伊藤氏：機械的なクロールをするロボットは別セットが受けている（そっちのマシンの方が多い）
- あと、クロールしなくてもサポートなどに連絡くれればデータをあげますよ
企業間の同一ユーザという情報は取得できるか？
- 伊藤氏：会社によってIDの重みが違うからリスクを考えると難しいと思う
できごと単位でSBMを使っている。同じニュースが新聞ごとにあるときにどういう扱いをしているのか知りたい
コメント（PFIの太田さんかな？）
- 米国Netflixのレーティング機能の賞金1億円をかけた研究はとても上手くいった。それでリコメンド機能は確立されたが、そのデータと他のWebサイトを示し合わせてユーザの個人情報がバレバレになったから共通フォーマットも考えもの
