1. Twitterクライアントが
この先生き残るには
#twtr_hack
@s17er
2013/2/1

2. 自己紹介
@s17er / 佐々木シンイチ
Janetter for Android
Java / Python / JavaScript / etc...

3. Twitter API 1.1
2013/3/5

4. 対応してますか？

5. エンドポイントの変更
●
呼び出すURLが変わる
– http(s)://api.twitter.com/1.1
– 変更されているものも
●
/blocks/blocking/ids → /blocks/ids

6. エンドポイントの変更
●
廃止されるAPI
– クライアントの仕様変更が発生
●
他人がリツイートしたツイート一覧
●
特定ツイートをリツイートしたユーザ一覧
●
タイムラインでリツイートを受け取らないユーザ一覧
●
ブロックユーザ一覧

7. 検索ツイートの構成変更
●
通常ツイートと同じになった
– 公式RTと非公式RTが区別できる
●
ミュートしやすくなった
●
検索と他のタイムラインの場合で処理をわけなくも
よくなった

8. レートリミットの変更
●
エンドポイントごとに回数制限
– 15分ごとに15回
– 例外的に15分ごとに180回叩けるものも
●
search/tweets
●
status/show/:id
●
user/lookup

9. 15分に15回？
●
すぐにリミットに到達する
●
特にリストはヤバイ
– エンドポイントはリスト毎ではない
●
lists/statuses?list_id=
– リスト5個を同時に更新できるのは15分に3回
●
リストをたくさん管理している人は更新間隔長くなる

10. Display Requirement
https://dev.twitter.com/terms/display-requirements

11. Display Requirement
●
ツイート表示に関するルール
– 表示すべき項目が細かく規程
– 相対時刻
– 名前とscreen_name併記
– リプライ、リツイート、お気に入り追加のボタン
– リツイートの場合の表記
– Twitter Birdをタイムラインに表示
●
一行表示型が出来なくなる (tweenなど)

12. 1.1に対応して待ち受けているもの

13. ユーザからのクレーム
●
screen_nameの左に@はいらない
●
時刻の相対表記は分かりにくい
●
Twitterの鳥が邪魔
●
前のほうが見やすかった、何故変えた
●
すぐにAPIの利用制限に到達する

14. クレームに負けずに
サポート頑張りましょう

15. サポートの難しさ
●
先行して対応したと言っても、
– 「他のクライアントでは出来るのに！」
– 3/5までギリギリ待つほうが得策？
●
API 1.1の変更やDRについて説明…
– 一般の人に砕いて説明するのめんどくさい
– Twitter公式での説明は英語
– あまりTwitterのせいにしすぎると逆に反感買う
●
解決できることではないので、結局「星一つ！」になる

16. それに耐えたとしても…

20. これ以上、
ユーザーを認証できません

21. アプリごとのユーザ数制限
●
新規参入の場合、10万ユーザまで
●
10万を超える場合は、発表時点(2012年9月頃)
のユーザの二倍まで
– 制限に達するとそのアプリ(Consumer Key)での
ユーザ認証が出来なくなる
– 一回認証していても、再認証不可
●
アクセストークンを取得するAPIが使えなくなる
●
再インストールしても再認証できないケースが

22. アプリごとのユーザ数制限
●
到達したクライアントたち
– Tweetro (Windows 8)
– ShootingStar (Android)
– Twitcle (Android)

23. アプリごとのユーザ数制限
●
クライアントビジネスの終焉
– 新規参入にメリット無し
●
ユーザ数の上限
●
サポートコストはかかる
●
10万ユーザでうまくマネタイズできれば…
– 既存クライアントは既得権益にしがみつけ

24. アプリごとのユーザ数制限
●
開発者のモチベーション低下
– 多くの人に使って欲しいから開発する
●
上限設定で先が見えてしまう
– これまでのTwitterとの信頼
●
サードパーティと共に成長してきた
●
信頼と文化の否定、別の価値観の押し付け

25. 回避策はないか？
●
バージョンをたくさん作る
– 2013年春版、2013年夏版…
●
同じアプリばっか作るなってストアから怒られそう
●
そもそもTwitterの規約で禁じられている
– 機能ごとに無料版、100円版、200円版…
●
source名どうするのか？
●
100円版から300円版にアップデートする場合は？
●
せいぜい数種類が限界

26. 暗黒面に堕ちますか？
●
ConsumerKeyのラウンドロビン
– ConsumerKeyをサーバで管理
●
アプリ内にキーを持たない
– ユーザ制限に到達した時点でキーを更新
ブラックです！
もはや倫理の問題

27. 一応iOSはなんとかなる
●
Twitter Framework (iOS SDK)
– ユーザ数の制限気にしなくていい
●
AppleとTwitterと喧嘩しない限り安心
– sourceはiOS
– 現状、REST APIしか使えない
●
モバイルなら許容できる
– DMが扱えない

28. 他のプラットフォームの
サードパーティ製
Twitterクライアントは
座して死すのを待つしかないのか？

29. サードパーティの排除
●
およそ二年前からTwitterはそういう方針を打
ち出していた
●
今更騒ぎ出した所で遅い
●
先見の明があれば足を洗っているはず

30. 受け入れよう

31. 世の中に不満があるなら自分を変えろ！
それが嫌なら、耳と目を閉じ、口をつぐん
で孤独に暮らせ！

32. 結論
●
Twitterの方針変更を待とう
– 待てるのならば
●
ビジネスでやるのはやめよう
– 限られたユーザ、ニッチを攻めるならアリ
●
趣味でやろう
– 悪ノリしてBANされてもネタになる

33. 完

34. それでもTwitterクライアントを
作りたい

35. これからTwitterクライアントを作る上で
考慮したいポイント

36. タイムライン
●
リアルタイムでのタイムライン更新
– Streamは公式Webでは使えない
●
専用アプリの強み
– モバイルはRESTのほうがよい
– あまり流速が速すぎると読めない
●
適度にさっぴく
●
同じRTは一定時間表示しない
●
表示ユーザの調整（グルーピング）

37. ユーザのグルーピング
●
今まではリストで振り分けていた
– リストにはStreamがない
– レートリミットにより実用でなくなる
●
ミュートユーザー機能
– ピンポイント
– リムーブの代わり（大人の事情）
– グルーピングとはちょっと違う

38. ユーザのグルーピング
●
レーティング、タグ付け
– 状況に応じて、特定タグユーザを表示/非表示
– 星3つ以上のユーザだけ表示
– 俗に言う「タブ分け」に近い
●
一つのタブで切り替えるか、複数タブで見るか
の違い
– そのグルーピング情報を共有できると便利
●
TweetMarkerみたいなゲートウェイサービス

39. ホットな話題を追いかける
●
トレンド
– ニュース性
●
トレンド一覧だけでなんとなく何が起きてるか分かる
– 勢いとかランキングとか
●
クライアントで集計
●
その日のトレンド
– API廃止されてしまった
– 独自集計
●
タイムライン内のトレンド
– ハッシュタグ大喜利とか興味無い人とか

40. 雑音排除
●
目にしたくない言葉
– ワードでミュート
●
スパム、BOT
– sourceでミュート
●
初見でも目にしたくないユーザ
– 思想が違う人
– いろいろ面倒と感じる人
– アイコンでミュート
– ワードでミュートされたらそのユーザもミュート

41. 知能的な情報集約
●
興味ある人のツイートを集約
– フォローしている人の発言を効率よくまとめる
●
フォロー＝興味ある
– どうでもいい呟きは弾く
– たくさん出る話題、URL、RTをまとめる
●
その日の話題になったツイートも集約
– トレンドに上がった発言をまとめる
●
クライアントだけの領域ではないんじゃないの？
– ただAPIを叩くだけじゃ生き残れないのではないか

42. コミュニケーション
●
返信
– in_reply_to付き
– 引用返信
– 複数返信
●
DM
– もう必要性が薄い？
●
Twitter自身、不要と思っているフシが
– LINEとかSkypeとかFacebookに任せようか
●
ふぁぼ
– なるべく近寄らないようにしよう

43. RTと言及
●
公式RTによるデマ拡散
– RT制限回数を設けては？
●
人の口には戸は立てられぬ
●
代わりにWebとかでやるだけ
●
公式にある機能の制限は反発を生む
– クライアント側で受け取るRTの制御

44. RTと言及
●
非公式RT問題
– 会話が追いかけづらい
●
in-reply-toつけると公開範囲が狭まる
– USの”replies=all”で、フォロワーへの返信を全部取る
●
有名人をフォローしているとその人への全リプライが流れて
くるので負荷が高くなる
●
in-reply-to付きでも、@の前に文字があれば全員に公開
– 公開返信として機能化しては
●
返信の種類多すぎる…
– 話題にするとたいてい荒れる
●
機能を削除すると炎上
●
思想が無いなら、そのままでいい

45. RTと言及
●
言及
– 返信する必要は無いけどあるツイートに言及したい
●
はてブのコメントみたいな感覚
– RTしてから「◯◯と思う > RT」
●
RTとの連続性が切れるからよくない
– ということを言った人がこないだ炎上した
– パーマリンクがあればその内容を展開
●
公式Webだと展開される

46. 場の共有
●
実況
– リアルタイムな流れに参加
●
テレビ
●
スポーツ
●
Ustream
– 一体感
●
バルス

47. マルチアカウント
●
諸刃の剣
– ユーザ数制限がある以上、無制限には出来
ない
●
気にしなければそれでもいい
●
業者でなくても10個以上使う人はいる
●
UserStreamを使う場合、ネットワーク負荷に
注意

48. Twitterそのものについて

49. 信頼
●
安定して使えるようになった
– 昔はよく落ちた
●
落ちるとクライアント作者にまず文句が行く
●
猫がサーバ直してた
●
API Status見る機会減った
●
日本では完全に定着
– テレビで普通にその名が流れるようになった
– 東日本大震災で信頼度が上がった
●
プラットフォームとしての確立

50. 心配事
●
マネタイズの問題
– どこかに買収される危惧
– やっぱり無くなって欲しくはない
●
代わりが無い
– 有料API
– 広告ツイート
●
使いにくくならないで欲しい
– DRによる多様性の排除が、ただの競合の排除
だったということでありませんように

51. まとめ
●
作る自由も作らない自由もある
●
引き際を考えておく
●
どうせならTwitterにパクられるもの作ろう
●
楽しんで作ろう

52. 最後に

53. 最後にこれだけ言わせて
「足あと」はないわ…

54. ご清聴ありがとうございました