Twitter関連サービスを10年作ってきて思ったこと

ご無沙汰してます、私です。 最近、Twitterに関連するサービスをシュッとリリースしたのですが、そういえば2008年あたりからTwitter関連サービスを作り続けて、10年くらい経っとるなと気付いたので、その振り返りとサービス告知をしておくか、という文章です。

2008年頃：Tweetまとめ支援ツール

TwitterのつぶやきURLをまとめて入力すると、status_idたちを取り出し、APIに投げてname,screen_name,img_url,text,あたりを取得して、はてなダイアリーに貼るとまあまあいい感じに見えるhtmlのテーブルタグを吐き出すというツールをPHPで雑に作っていました。 つぶやいたものをまとめたいという欲求がこの頃からあったことが伺えますね。まなめさんに褒めてもらって承認欲求を満たしていた記憶があります。

2012年頃：RT直後のつぶやきを見に行くやつ(RtRT)

リツイート(RT)という機能が公式に実装されて幾ばくかしたころ、RTの後に自分の意見を言うユーザーが増えてきました。Replyと違ってその意見が通知として上がってくるわけではないので、ある程度バズった（数RTされた）つぶやきの反応が気になった場合、RTしたユーザーのタイムラインをそれぞれ見に行くということをしていました。 この動きはAPIを使えば自動化できそうだなーと思ったので、PHPでめちゃくちゃ雑に作りました。動いていたのが今では奇跡に思えます。 自分が使う用に実装して動かしたのをTwitterにつぶやいてみたら1000RTされて作るしかないなーという気持ちになって作りました（当時の1000RTは現在の10000RTに相当する…と思う）

ねとらぼさんにも取り上げていただき、今となっては当時を振り返る貴重な資料となっています。本当にありがたい。

その後、TwitterのAPI変更や借りていたサーバーの閉鎖に伴い、サービスは終えることになりましたが、@jz5さんが同等以上の機能を持ったリツイート直後のツイートを表示するやつを運営されることになり、今は私もこちらを使うようになりました。便利です。

2014年頃：コミケやらコミティアに出る人のサークルスペースをがっとまとめるやつ(subcatalog)

コミケの時期が近づくと、Twitterの名前に3日目東A01-aみたいにサークルスペースを入れてくれる人が多くなります。どうせカタログチェックをするときにはフォローしてる人やリストに入れてる人も見たりするので、このへんががっと取れると楽だなーとコミケ会場で知り合いの名前を検索窓に入れながら思ったので作りました。

最初はPython2系を使いGoogle App Engineで作ってましたが、2015年夏コミの頃には利用者が増加し、高負荷でGAEの無料枠を使い果たす事態に陥ったため、リニューアルも兼ねてherokuに引っ越して、Djangoとmithril.jsで作り直しました。

さらに去年にはフロントをVue.jsに刷新し、誰でもイベントを作れるようにしました。私がイベントの時期に合わせてイベントデータを作って運用するのが辛すぎたためです。

新しいサイトのURLはこちらです。今でも大きめのイベントが近づくと、↑のつぶやきがRTされたり紹介するのでちょっと悲しいです。

https://www.subcatalog.net/

2018年：Twitterリストに入ってる人達のReplyの応酬だけ抜き出してSlack等に投稿する(relationship)

Virtual YouTuberが隆盛した2018年。オタク活動として推しのTwitterアカウントをフォローするのは当然ですが、推し同士のやりとりから関係性を見出すことも重要になってきます。そういった関係性は時にとてつもない輝きを放つため、絶対に見過ごせないのですが、告知などに埋もれてしまうのもよくあることです。そのため、濃縮された関係性を効率的に味わい、Slackのチャンネルに投稿することで抜けなくチェックできる体制を作りました。

事前準備としてTwitterリストに対象のアカウントを入れておくと、バッチが叩かれる度にリスト内のつぶやきをチェックし、Replyがあれば対象のつぶやきとReplyのURLを指定したSlackのチャンネルに投げます。

f:id:esuji5:20190121181721j:plain

(実行された様子)

公式WEB・クライアントで使われている、特定のつぶやきへのReplyが取得できるAPIを使えればいいのですが、一般には開放されていないのでin_reply_toなんかの情報を駆使してまとめるのがなかなか大変です。

ツールのおかげ化Slack内の人々が関係性に敏感になったことで、30分に1度の起動より先にURLが書き込まれてしまうことが何度かありました。それだけ速報で伝えたいほどに関係性は強烈なのです。

Pythonバッチを雑に作ったものなので、需要があればコード公開したいと思います。

最近のやつ：Twitterに画像を4枚ずつ貼ったものをリプライツリーで読めるようにしてるをWEBの1ページでまとめて読むやつ(sucrose)

最近、漫画家や同人作家の方が過去に描いた漫画などを4枚ずつ貼ったリプライツリーを形成することでTwitterに投稿されるものをよく見ます。つぶやきが2、3個ならさっと読んでしまいますが、けっこう長いものもあり、ありがたいのだけど読むの大変で、でもリプライツリーを辿ればウェブサービスでなんとかまとめて読めそうだなと思ってとりあえずの実装を行いました。とりあえず、以下のリンクから読んでもらうと話が早いです。

リプライツリーと言いつつ、前述の通りリプライを取得するAPIは使えないので、起点になるつぶやきIDを投げると、ユーザータイムラインをsince_id=つぶやきIDよりちょっと過去で指定して取得、画像がないつぶやきがあるまでまとめていくという感じになってます。 とりあえずの実装なのでドメインはsubcatalogに間借りし、画像が何十枚あってもサーバーサイドレンダリングしてますが、需要があれば逐次読み込みなどの高速化をやっていくかという気持ちです。こんなんでも意外と体験がいいのでしばらくは運用する予定です。

この10年で気付いたこと

まとめツール以外は、そもそもなんでこのツールが必要なのかを他人に説明するのが大変で、色々と込み入った使い方をされるTwitterはすごいなあと改めて思いました。

とはいえ、最後のsucroseなんかは、私がツールを作るよりも、Twitterの機能としてユーザーが画像をまとめられるアルバムを作れるようにすれば良さそうな話でもあります。Facebookを例に上げると、こちらには既にそういった機能がありますし、有用なサービスは買収し、それができなければより良い模倣サービスを開発することで大きく成長してきました。もっとも、Twitter社が同様のことをしなかったからこそ私達はTwitterを使い続けてきたのかもしれないので、それは良いとも悪いとも言えません（モーメント機能については見なかったことにします。APIもないですしね…）。

Flickr等の外部サービスを使えばよいとTwitterの経営陣は思っているのかもしれませんが、私はとにかくTwitter外部に遷移したくない・Twitter内で全てを済ませたい人間です。画像を上げたらすぐにRTやFav（現在のLike）で反応がもらえますし、見る側のときは画像や漫画を見るのにpixivにさえ飛ばされたくないです。そしてまあまあの割合で同様に考えているユーザーがいるのではないかと思っています。

sucroseを公開した時に、「ジャンプルーキー等の然る場所にシュッと応募しつつ、Twitter上では最初の4ページを簡単に確認できるようになっている状態があると、作家も読者もプラットフォームも嬉しいのではないか」という意見およびお気持ちをいただきました。 これはけっこうハッとさせられるもので、僕が真に解決すべきはTwitterのしょぼくれた機能を補助することではないと気付いてしまいました。とはいえ、Mastodonを改造して最高のプラットフォームを作るという気持ちがあるわけでもなく、今のTwitter社にAPIの拡充や制限解除など期待するのも無駄だと思うので、せめて現状維持を願うのですが、それもどうかと思うことがなくもなく、なんとも言えない気持ちになりました。

まとめ

  • なんだかんだ使われ続けるTwitterすごい
  • でも、もうちょっとユーザーの声を反映した機能追加があっても良いと思う
  • Twitter関連ツールを作るのは楽しいけど、しょぼくれた機能を補助することが真のゴールじゃないよ
  • 期待もできないが、諦めてばかりいるのもなんだかなあ、なんとも言えねえ

ところでこれはいい感じのsucroseページなので読んでくださいお願いします。 www.subcatalog.net