分散するTwitter：誰しもへ訪れるTwitter難民という未来

突然ではあるが、Twitterで著名な論者である白饅頭さんに私の記事を引用して頂くという栄誉を得た。

引用して頂いたのは2020年1月1日にnoteへ公開した記事。

この記事への反響は凄まじく、私見での観測の範疇ではあるものの、1月1日および1月2日でnoteに公開された全ユーザーの全記事の中で最もアクセスを稼いだものと思われる。

同時にコンテストである「#2020年代の未来予想図」へもエントリーしており、本記事執筆の時点で得られたスキ数が「VRおじさんの初恋シリーズ(暴力とも子さん)」「週５で晩ご飯テイクアウトサービスを使い始めて1ヶ月経った(ムラキさん)」に次いで3位であった。

コンテスト入賞は叶わなかったが、読者の皆様からのリアクションは興味深いものばかりであり今後の執筆活動への参考とさせて頂きたいと考えている。本当に深く心より感謝を申し上げたい。

白饅頭さんの記事の評価

さて本題へ移ろう。

白饅頭さんの記事の評価だが、情報技術へ明るい者達と比較しても遜色のない予測であると偉そうにも太鼓判を捺せる。

しかし、白饅頭さんの予測には欠けている部分があり、本記事はその欠けている予測を埋めるものとして執筆した。

前提として白饅頭さんの予測は遠い未来の話ではないが、決して近い未来でも無いのだ。

私は白饅頭さんの予測が到来する前にTwitterでは1つの大きな動きが起こることを予測している。

それこそが記事タイトルにした「Twitter難民という未来」である。

Twitterと他サービスのAPI制限

TwitterのAPI制限
Twitter社は過去にいわゆるTwitterクライアントのAPI制限を実施している。

代表例を挙げれば「APIの呼び出し回数制限」「Twitterクライアントユーザー数制限」「Userstream APIの廃止」など複数回に渡って様々なAPI制限を設けた。

このAPI制限の目的は端的に言えば「Twitter社自身が開発する公式Twitterクライアントのユーザー数を増やすため」に行なわれた。

何故なら、いわゆる「Twitter社以外が開発する非公式のサードパーティTwitterクライアント」では膨大に膨れ上がった運営赤字を減らすため収益化を目指し、その収益化の柱となる広告の表示に非公式サードパーティTwitterクライアントでは難があったからだ。

サードパーティTwitterクライアント開発者はやろうと思えばTwitter社が配信する広告をブロックすることが技術的に可能であったのだ。収益化を目指すTwitter社としてこれは受け入れがたいものであっただろう。

そこで考案されたのが「API制限による公式Twitterクライアントへの移行促進」である。

今や非公式のサードパーティTwitterクライアントユーザーは極わずかしか存在しておらず、その大半が公式Twitterクライアントユーザーであろう。

他サービスのAPI制限
実はこの流れ、何もTwitter社だけが行なったことではない。他の著名なWebサービスでも似たような動きが起きたことがある。

例えば過去の時代に流行した「インスタントメッセンジャー」という種別のWebサービスがあった(メッセやIMなどと略して呼ばれた)。

これは早い話がチャットだ。現代のユーザーにより理解しやすい表現を使えばLINEやWhatsApp、Snapchatである。

インスタントメッセンジャーは大手IT企業であれば何かと参入したがる傾向が当時はあり、Yahoo!やMicrosoft、そしてGoogleなども参入していた。

乱立するインスタントメッセンジャーはユーザーとして不便極まりないのは、現代でもLINE派やFacebook Messenger派などの存在により読者の皆様は認知しているものと考えるが、当時も同様に不便極まりなかった。

そこで当時インスタントメッセンジャーサービスを運営していたJabber社が無償で使えるインスタントメッセンジャーの通信プロトコル規格を公開したのだ。これをXMPP通信プロトコルという。

XMPP通信プロトコルはインスタントメッセンジャーで活用される通信プロトコルとしてデファクトスタンダードの地位を確立し、当時のIT企業としては若くて後発参入だったFacebookやGoogleも採用したのだ。

XMPP通信プロトコルを採用しているとXMPP通信プロトコルを扱えるインスタントメッセンジャークライアントからメッセージの送受信が可能になる。

つまり、Yahoo!チャットを利用するにはアプリαを起動し、MSNメッセンジャーを起動するにはアプリβを起動し、Facebook Messengerを利用するにはアプリγを起動...ということをせずに、たった1つのインスタントメッセンジャークライアントΩからXMPP通信プロトコルを採用するすべてのサービスを利用できたのだ。

インスタントメッセンジャーサービス運営者もユーザーの利便性を考えてXMPP通信プロトコルを採用していた。

会話データという資産
しかし、時代が変わると価値観も変わる。

インスタントメッセンジャーサービス運営者はサービス上でやり取りするユーザ同士の会話というデータが経済的価値のあるものだと言うことに気付いたことが始まり。

あの時の会話を振り返りたいという欲求は当然ながら、現代では本物の人間と見間違えるほど高度な会話AIが存在する。その会話AIの学習データはどこから来ているのか？それは実際の人間同士の会話のはずだ。

XMPP通信プロトコルを採用したままだとユーザーは経済的価値のある会話データを自由に活用できてしまう。それを営利企業が惜しむのは理解できる。

そのため、例えばGoogleはXMPP通信プロトコルを採用していたインスタントメッセンジャーサービスGoogle Talkを廃止して、新たにXMPP通信プロトコルではない独自の通信プロトコルを採用したGoogle Hangoutsの提供を開始した。

同様の事例が情報技術者に人気の高いチャットサービスのSlackでもあった。Slackはその当初はXMPP通信プロトコルを採用していたが後に廃止してしまった。つまり事実上のAPI制限である。

これらの前例をTwitter社が知らないはずがなく、大いに参考としたはずで結果としてTwitterはAPI制限を選択している。

そしてこの試みは成功してしまった。成功してしまったのだ。

情報統制と問題の解法そして回答

完成した情報統制
Twitter社はTwitterクライアントを完全に掌握することによって、ユーザーへ見せたいものも見せ、見せたくないものを見せなくできるようになった。悪い表現を使えば情報統制が可能となった。

他人の内心は真にわからないものだというのは理解しているが、Twitter社の当初の目的は膨らんだ赤字をどうにかするものであったという点について私は疑っていない。

Twitter社と表現しても中で働いている殆どの人は私と同じ情報技術者であり、高効率の数字を好みがちであろうことが予測できる。

問題を解く
Twitter社は広告による収益化を想定した際にまずユーザーという名の母数を増やすことを考えただろう。そして母数を増やすには盛り上がりが必要だと。

我々情報技術者はこういった必要なものを数学等のペーパーテストと同じ感覚で「問題」と捉える。つまり「問題」には「解法」が存在するので活用し「回答」を得るわけだ。

母数を増やすために盛り上がりを演出するシンプルな解法は「最もお気に入りやリツイートされているツイートを他のユーザへオススメする」である。

e=mc2などと同じくシンプルで素晴しい解法だ。

賢明な読者の皆様は既にその後のTwitterを経験しているのでご存知だろう。この解法から得られる回答は長期的に見ると誤りであると。

解けてしまうからこそ
何故なら、最もお気に入りやリツイートされるツイートがすべてポジティブな属性であるとは限らず、この解法にはポジティブやネガティブの評価式が含まれていない。

しかし、この解法の誤りに気付くのは困難であるという点には着目しておかなければならないだろう。

この解法は「広告収入のためにユーザー母数を増やし盛り上がりを演出する」という問題を解いてしまうのだ。

そう、そもそもTwitter社は問題の設定自体へポジティブやネガティブという評価式を検討しておらず、問題の設定が誤っているため解法も誤っているという非常に気付きにくい状態へ陥っていたものと私は想定している。

読者の皆様は「目標数値が達成し、赤字は解消、従業員や株主にも還元できている。しかしサービスの治安が悪くなる」という状況に対してどう考えるだろうか？営利企業として正解している、黒字を出している状況で解法という名の方針を転換できるのだろうか？

結果は現在のTwitterを見るとよく解る。

Twitter難民を生む解法

Twitter難民という歪な存在
結局のところTwitter社は方針を転換できなかった。

しかし、社会からの要請という問題へ対して解法を用意して回答せねばならず、その解法が分散化ということになる。

Twitter社は新たな解法として分散化を選んだ。そしてTwitter社は既にTwitterクライアントによる情報統制の成功を経験しており、分散化でもその成功体験を活用する可能性がある。

そこから予測できるのは「Twitterクライアントのアップデートにより段階的に現在の本家Twitterサーバーに所属するユーザーを他のサードパーティーTwitterサーバーへ強制退去させる」という手法だ。

つまり一部のユーザー、予測するのであればアメリカ合衆国法下にないアメリカ合衆国非居住者が本家Twitterサーバーから強制退去させられ本家Twitterサーバー難民と化す。Twitterを使い続けたくばサードパーティTwitterサーバーを経由して下さいと。

名目上の理由はAPI制限と同様に「サーバーの負荷軽減による運営費の削減」あたりだと思われる。

甘くはない予測
情報技術者ではないがTwitterの分散化をある程度明確に予測できている賢明な読者の皆様は「Twitterが分散化するといってもサードパーティTwitterサーバーを使わなければ今まで通りだ」と考えるかも知れないが、それは甘い予測だと言わざる得ない。

Twitter社はその黎明期を支えた『チーム』を切り捨てても収益化という目標を達成するために動いたという過去がある。ユーザーのみが保護される保証はどこにもないだろう。

Twitterの分散化はシステム的な構成について様々な予測がある(この辺りもいつか語ろう)。

分散Twitterは大きく使い勝手は変わらないと予測できる。Twitter社もそのように喧伝するであろう。多くのユーザーは思ったよりも「Twitter」で拍子抜けするはずだ。

しかし、Twitter社はサードパーティTwitterサーバーを使いたくないユーザーにも退去を強制する。Twitterクライアントをアップデートしなければ本家Twitterサーバーを使い続けられるというノウハウも直ぐに使えなくする。

その後は白饅頭さんが予測する多様性社会の分散Twitterだ、と言いたいところだが前例を見るとそうはいかない可能性がある。

予測されていない別シナリオ

その可能性から見える疑問は「API制限の後に『チーム』へ参加していた情報技術者たちはどこへ行ったのか？」だ。

強制退去させられたユーザーは本当に「Twitter」を使い続けるのだろうか？

そしてインターネット上へは既に分散SNSが確立されて実績があり、どうやら情報技術に明るいイノベーターたちが分散SNSへ集まっており、様々な分散SNSサーバーやクライアントを開発しているようだ。まるで何処かで聞いたような話ではないか。

Twitter黎明期は日本国内ではまだ２ちゃんねるに勢いがあり、Twitterは一部の新しもの好きが利用するマイナーなWebサービスであり、電子掲示板のようなスレッドのないTwitterは理解されにくいものだった。

大多数のインターネットユーザーにとって分散SNSというものはまだ理解されにくいもので、この予測シナリオは大多数のインターネットユーザーの予測シナリオとは別のTwitter難民シナリオである。

実はTwitter分散化の未来予測の話は、運良くもコンテストに入賞したらそのメディアで語り尽くそうと思い温めていたネタだったのだが、残念ながら入賞できなかったので白饅頭さんの引用を良い契機と考え、持っているネタの一部を公開させて頂いた。

再び機会があれば前述したTwitterの分散化システムの構成や、サードパーティTwitterサーバーのマネタイズなどについても語りたいと考えている。

今回は大多数のインターネットユーザーにとっては荒唐無稽かも知れない別シナリオの示唆をしつつ、インターネットの未来へ想いを馳せ、再び読者の皆様からのリアクションを期待しながら、この記事を終えたい。

画像使用のためのライセンス表記

Freepik - jp.freepik.com によって作成された arrow 写真
https://jp.freepik.com/free-photos-vectors/arrow

Jcomp - jp.freepik.com によって作成された pattern 写真
https://jp.freepik.com/free-photos-vectors/pattern