結局、Twitter API 1.1で何が変わる？ 5つのポイント：Twitter APIと開発者規約変更のインパクトまとめ

変更による影響範囲や、一部APIの廃止、レートリミット方式の変更、アプリケーション当たりのユーザー数、ツイート表示方式の厳格化などを5つのポイントにまとめて解説

» 2012年09月26日 20時12分公開

[山本裕介，フリーランスエンジニア]

開発者のはしご外し？ Twitter API狂騒曲

　Twitterは2012年8月から9月にかけて開発者向けのブログで、APIや開発者規約の変更を立て続けにアナウンスしました。一部APIの廃止やレートリミット方式の変更、ツイート表示方式の厳格化など、影響は多岐にわたり、物議を醸しています。

　一部では「開発者のはしご外し」とも取れる一連の変更を受けて、Twitterを古くから支えてきた開発者からは不安な、そして悲観的な声が聞かれます。Twitter APIから離反する開発者の動きも話題になっており、ユーザーとして、そして開発者としてTwitterの今後に不安を覚える方も多いのではないでしょうか。

　本稿では、やや錯綜している情報をまとめ、その影響範囲について説明します。

3者の視点で見る―誰にどのような影響があるのか？

　＠ITの読者は、Twitterとのかかわり方はさまざまだと思われます。まずは「Twitterのユーザー」「Twitterと連携するサービス、アプリケーションの開発者」「Twitterクライアントアプリケーションの開発者」と3つに分けて今回の変更点がどのように影響するか簡潔に説明します。

【1】Twitter一般ユーザーへの影響

　Twitterを利用している一般のユーザー層（サードパーティクライントを利用者も含む）への影響はほとんどありません。今回の一連の変更は、あくまで開発者向けのAPIや利用規約のものであり、一般ユーザーに及ぶものではないためです。

　「サードパーティクライアントが締め出されている」と見る向きもありますが、少なくとも現在使っているアプリケーションが近々利用できなくなるということはなさそうです。

　ただし、ツイートの表示の仕方については今後細かい規約が強制される（後述）ようになるため、お気に入りのサードパーティクライアントの見栄えが変わってしまう可能性については覚悟しておいた方が良さそうです。

【2】アプリケーション・サービス開発者

　＠ITの読者層にも多数いると思われるのがTwitter APIを利用するアプリケーション（クライアントアプリを除く）・サービスの開発者です。この層には、それなりの影響があります。

　これまでのAPIのエンドポイントは2013年3月にも廃止され、レートリミット方式も変わってくるため、コードの改修が必要です。一番楽なケースではTwitter APIの呼び出し先のエンドポイント（URL）を変更するだけで済みます。

　また、APIで取得したツイートをアプリケーション内で表示している場合は、後述の「Display Requirements」に従う必要があります。この点は、以前からあった「Display Guidelines」に沿った作りになっていれば、多くの場合改修は必要ないでしょう。

【3】クライアントアプリ開発者

　今回の騒動で一番影響を受けるのがクライアントアプリケーションの開発者です。「クライアントアプリケーション」とは、つまりTwitterのタイムライン、@ツイート、DMの送受信などを行ういわゆる「公式Web」「公式クライアント」の代替となるアプリケーションを指します。

　「モバツイ」「ついっぷる」「Twicca」「チャーハン諸島」「Tween」「Janetter」など日本発のクライアントアプリケーションも数多くありますが、これらを含むクライアントアプリケーションが今回標的にされたとも言えるでしょう。

　とりわけ開発者を悩ませるのがツイートの表示方式を細かく規定する「Display Requirements」（後述）です。クライアントアプリケーションは、もちろんTwitterの基本機能を変えるわけにはいかないので、特に見栄えやフィーリングをユニークなものにチューニングしてきました。

　「Display Requirements」に沿うことで、アプリケーションごとの特徴が出しにくくなるとの声が上がっています。

　以下、大きな変更点のポイントを5つに分けて解説します。

REST APIの変更点
検索APIの変更点
レートリミットの変更点
アプリケーション当たりのユーザー数
ツイート、タイムライン表示方式の厳格化

【1】REST APIの変更点

　REST APIはTwitter APIの一番伝統的で中核となるAPI群です。これまでREST APIを呼び出す際のエンドポイントURLは「http(s)://api.twitter.com/1/*」でしたが、Twitter API 1.1では「http(s)://api.twitter.com/1.1/*」となります。

　多くのAPIはエンドポイントURLが変わるだけですが、一部廃止・変更もあるので、注意が必要です。公式ドキュメントに廃止・変更になるAPIのリストがないので、以下にまとめました。

　なお、廃止対象に挙げているAPIでもAPI 1.1のエンドポイントで実際呼び出せてしまうものがいくつかありますが、ドキュメントには記載されておらず、今後呼び出せなくなる可能性がありますので使うべきではないでしょう。

廃止になるAPI

　　/statuses/retweeted_by_me
　　/statuses/retweeted_to_me
　　/statuses/retweets_of_me
　　/statuses/retweeted_to_user
　　/statuses/retweeted_by_user
　　/statuses/:id/retweeted_by
　　/statuses/:id/retweeted_by/ids
　　/friendships/exists
　　/friendships/no_retweet_ids
　　/account/totals
　　/notifications/follow
　　/notifications/leave
　　/trends/daily
　　/trends/weekly
　　/blocks/blocking
　　/help/test

変更になるAPI

　　/blocks/blocking/ids → /blocks/ids
　　/direct_messages/destroy/:id.json → /direct_messages/destroy.json?id=:id
　　/favorites/create/:id.json → /favorites/create.json?id=:id
　　/favorites/destroy/:id.json → /favorites/destroy.json?id=:id
　　/account/rate_limit_status.json → /application/rate_limit_status.json
　　/lists.json → /lists/list.json

＠IT編集部より：おわびと訂正のお知らせ

上記廃止になるAPIについて、/blocks/destroyは含まれないため、記述を削除しました。内容について正確を期せずに混乱を招いた点、読者の皆様におわび申し上げます（2012年10月1日）。

　また、これまで一部のAPIはOAuth認可なしで呼び出せましたが、Twitter API 1.1では全てOAuthが必須となります。

　スムーズに移行できるよう、現在はAPI 1.0とAPI 1.1が平行して稼働しています。API 1.0は2013年3月5日に廃止される予定なので、できるだけ早い段階で移行を済ませましょう。

REST APIの変更のポイント

エンドポイントURLが「http(s)://api.twitter.com/1/***」から「http(s)://api.twitter.com/1.1/***」へ変更
一部廃止のAPIも
全てOAuth認可が必要になる

【2】検索APIの変更点

　従来検索API呼び出し用のエンドポイントは「http://search.twitter.com/search.json」でしたが、API 1.1ではREST APIと統合され、「https://api.twitter.com/1.1/search/tweets.json」となります。

　また、従来検索APIのレスポンスの構造はREST APIのレスポンスと異なっていましたが、API 1.1で統一されることになります。つまり、呼び出しエンドポイントを書き換えるだけではなく、レスポンスをパースする部分についても、コードの改修が必要になります。

　レートリミットについては、これまでIPアドレス単位であったのが、REST APIと同じくアカウント単位となります。他のサービスとIPアドレスを共有しているクラウドにデプロイしたアプリケーションが予測できないタイミングでレートリミットに達してしまうようなことはなくなります。

検索API変更のポイント

エンドポイントURLが変更
レスポンスの構造がREST APIと統一
レートリミットはIPアドレス単位ではなくアカウント単位へ

【3】レートリミットの変更点

　Twitter APIを利用する上で忘れてはならないのがレートリミットです。従来REST APIのレートリミットはOAuthなしの場合はIPアドレス当たり1時間150回、OAuthありの場合は1アカウント当たり1時間350回でした。

　API 1.1では、1アカウント当たり15分で“エンドポイントごとに”15回または180回となります。単純に1時間当たりにならすと、60回または720回になるので、多数のエンドポイントを利用するアプリケーションにとっては350回以上呼び出せることになります。よって実質、制限が緩くなったことになります。

　しかし、特定のエンドポイントを集中的に呼び出すようなアプリケーションにとっては幾分制限が厳しくなります。レートリミットにシビアなアプリケーションでは、呼び出せる残り回数をX-Rate-Limit-Remainingヘッダで、また呼び出しカウントがリセットされる時間をX-Rate-Limit-Resetヘッダで確認するようにしましょう。従来のX-RateLimit-*と違いRateとLimitの間にハイフンが入っていることに注意してください（参考：公式ドキュメントの「レートリミットの詳細（英語）」）。

　各エンドポイントの実際のリミットについては公式ドキュメント「エンドポイントごとの15分当たりのリミット（英語）」をご参照ください。

　1日1アカウント当たりツイート1000件、ダイレクトメッセージ250件といった更新系のAPI、またストリーミングAPIの制限については変更ありません。

レートリミット変更のポイント

リミットはアカウント単位ではなくエンドポイント単位
アプリケーションにより、制限が緩くなる場合と厳しくなる場合とある
ツイート数、DM数については変更なし

【4】アプリケーション当たりのユーザー数

　今回初めて導入されたのが「アプリケーション当たりのユーザー数」という制限です。ここでいう「アプリケーション」はTwitter APIに接続するサービスやアプリごとにdev.twitter.comで登録するものを指しており、1クライアントアプリケーション当たり10万ユーザーが限度となりました。それ以上の数のユーザーが利用するには、個別にTwitterの許可が必要です。

　今回のAPI／規約改定において、後述の「Display Requirements」と併せて、とりわけ大きく話題になっており、また開発者の離反を招く原因ともなっています。

　ただし、このユーザー数の制限は「クライアントアプリケーション」にのみ適用されるもので、単にTwitterと連携するサービスやアプリケーションは関係ありません。いわゆる「Twitterクライアント」を新規に開発するのでなければ気にする必要はないでしょう。

　また、すでに10万ユーザーを超えているクライアントアプリケーションについては現ユーザー数の倍まで許容されるとのことです。実質的には既存ユーザーには影響を与えずに新規のクライアントアプリケーションの開発を抑止するための施策と見てよさそうです。

　そもそもTwitterは1年半以上前、開発者向けにクライアントアプリケーションの開発ではなくTwitterが提供していない領域のサービスの開発を推奨する旨の声明を出しています（参考：「Twitter Development Talk > consistency and ecosystem opportunities」）。

　趣味や習作であれば問題ありませんが、今後ビジネスとして新規にTwitterクライアントアプリケーションを開発するのは賢明ではなさそうです。どれだけ努力をしても安全に到達できるユーザー数は10万であり、それ以上のユーザー数を獲得するのがTwitterによって許可されるのかどうかは不明だからです。

【5】ツイート、タイムライン表示方式の厳格化

　Twitterは従来よりAPIを通じて取得したコンテンツを「Display Guidelines」で決められたフォーマットに従って表示するよう開発者に要請してきました。これまでは「ガイドライン」であり、その適用を強制することはありませんでした。

　今回からガイドラインは「Display Requirements」と改められ、アプリケーションはこのフォーマットに従ってツイートなどを表示する必要があります。技術的に対応できない場合は、個別に問い合わせて許可を得る必要があるとしており、かなり厳密に適用を求める姿勢のようです。

　規定の内容はかなり細かく、例えば「山本裕介 @yusuke」のように@ユーザー名よりも前（または上）に名前を表示すること、ツイートのタイムスタンプが24時間以内であれば相対時刻で表示すること、ツイートのアイコンを左側に必ず表示することなどが決められています。詳しくは、公式ドキュメント「Developer Display Requirements」をご覧ください。

　Webサイトに数個のツイートを張り付ける程度であればTwitterの「このツイートをサイトに埋め込む」機能より取得したHTMLを利用すると良いでしょう。

図　ツイートの埋め込み機能

冷静に情報の情報の真贋を見極めよう

　Twitter APIは柔軟性と自由度の高さから人気があるだけに、いくらかの制約を加える今回の仕様・規約変更はセンセーショナルに受け止められています。しかしTwitterの主張するユーザー体験の統一や、一部の過負荷なアプリケーションの抑制といった目的からは理にかなった変更ともいえるでしょう。

　要点さえ押さえれば、今回の変更に対応するのは難しいことではありません。年々存在感を増しているプラットフォームですから、その強みを生かして今後もAPIを活用してはいかがでしょうか？

　また、今回の騒動に連動してTwitter関連の話題はことさら拡散しやすい状態にあります。中には憶測にすぎない記事も確定事項であるかのように大きく取り上げられていることすらあります。

　Twitter連携アプリケーションを開発・検討している開発者の方はいつも以上に冷静になって、情報の真贋を見極める必要があります。Twitterと連携するビジネスを展開する場合は日ごろから、公式ドキュメント、ブログや掲示板、非公式ですが、Twitter API日本語メーリングリストをチェックしておくと良いでしょう。