フレームワーク＆API 5-07
Twitter APIのバージョンアップによる仕様変更

2012年8月にTwitter APIのバージョンアップが発表された。その内容には、今後の使用に大きな影響を与えるものが含まれている。クライアントワークはもちろんのこと、自社サービスであっても場合によっては終了しなければならないサービスも出てくる可能性があるので注意が必要だ。

解説／井形信

Twitter APIが v1.0から1.1へ

「2013年3月に、Twitter APIがv1.0からv1.1へ更新される」と公式に発表された【01】。

現在は移行のための猶予期間であり、上記期限が来ると共に本APIはv1.1へ更新される。

Twitter API v1.1 の仕様はTwitter Developersのサイト【02】にまとまっている。

今回の発表で世間を騒がせたのは、APIの仕様変更はもちろんのことだが、それ以上にAPIの利用制限に関する内容だった。

具体的には、英語の公式ブログ（http://blog.twitter.com）で発表されている通りだが、特に注目すべきなのは以下の4点である。なお、日本語の公式ブログでは省略されている部分があるので要注意だ。

(1) すべてのAPIエンドポイントの利用に承認が必要。
(2) 10万ユーザー以上のTwitterクライアントアプリは別途承認が必要。
(3) 呼び出し制限がIPからAPIエンドポイントごとに。
(4)ディスプレイガイドラインがディスプレイ要求に。

では、それぞれ順に見ていこう。

【01】Twitter 公式ブログで発表された「Twitter API v1.1 でのAPI 利用ルールの変更について」のお知らせ。（http://blog.jp.twitter.com/2012/08/twitter-api-v11aip.htmll）

【02】https://dev.twitter.com/docs/api/1.1

すべてのAPIエンドポイントの利用に承認が必要

現在、Twitterを使った組み込みアプリケーションには、さまざまなものがある。

具体的には、プロモーション用のbotアプリ、特定の条件に当てはまったTweetのみを表示するアプリ、TwitterにTweet表示のためのワークフロー機能を追加したアプリ、スマートフォンアプリ用のTwitterクライアントアプリなどがある。

TwitterはTweetが拡がりやすいというプラットフォームの性質上、プロモーションに使われていることが多く、クライアントワークの中で受託制作されているものも少なくない。

しかし今回の変更によって、すべてのAPI 呼び出しに関して、Twitter 側の承認が必要となった。

クライアントワークであれば、Twitterアプリを提案する際には、承認を通すための事前の検証やスケジュールの調整、さらにはクライアントだけではなくプロジェクトに関わる各社との合意形成が必要になってくるだろう。

恐らくよほど特殊な使い方でない限り非承認になることはないと思われる。だが万が一のことを考えると、事例が蓄積するしばらくの間は様子を見た方が賢明かもしれない。

10万ユーザー以上のTwitterクライアントアプリは別途承認が必要

前述した承認に加え、Twitterクライアントアプリについては、さらに制限がかかるようになる。

具体的には、1クライアントアプリ当たりのユーザー数は10万を限度とし、それ以上のユーザーが利用する場合は個別にTwitter 側の承認が必要となった。

Twitterクライアントアプリを主体として展開するベンチャーなどには、アプリそのものの存在が脅かされるということであり、サービスの存続に関わる大きなビジネスインパクトと言えるだろう。

既に本変更に起因してクローズしたサービスもちらほら出てきている。

呼び出し制限がIPからAPIエンドポイントごとに

APIの呼び出し制限に関しては、v1.0ではOAuthありの場合は1IP当たり1時間350 回だった。

これが今回、APIのエンドポイントごと（たとえば Tweer 検索、返信、RTごと）の制限に変更になり、1時間60回もしくは720回となった。これは、使い方によっては制限が緩和される形になる。

この仕様変更は、Twitter側で統計を取った結果の上限に制限が設定されている。つまり、通常の利用範囲であれば、v1.0となんら変わらずAPIを利用できると考えてよいだろう。

ディスプレイガイドラインがディスプレイ要求に

Twitterにより定義されたディスプレイガイドライン【03】がディスプレイ要求へと変更され、これに従わないアプリはアプリケーションキーを取り消されてしまうこととなった。かなり細かい部分まで決められており、すべての要求をクリアすると、アプリごとの特色を出すことが以前と比べて難しくなるだろう。

具体的には、＠ユーザー名やリツイート、返信、お気に入りなどのアクションほか、ツイートを本要求に従って表示するように厳格化された。

たとえば、現在は旧式のRTが許容されているが、今回の変更で許容されなくなるだろう。

本変更は、どのTwitterアプリからアクセスした場合でもユーザーには共通のエクスペリエンスを体験して欲しいから、ということだ。

【03】これまでは「Developer Display Guideline」だったが「Developer Display Requirements」に変更された（https://dev.twitter.com/terms/displayrequirements）。今後は、この表示形式に従うことが義務づけられる。

今日のTwitterエコシステムについて

今回の変更においては、Twitterのスタンスを明示するためにTwitterを取り囲むエコシステムを紹介している【04】。

左をビジネス、右を消費者、上をエンゲージメント、下をアナリティクスと分けたエコシステムの分類を提示し、その中で「右上の象限において、特定の使用を制限しようとしている」と明示している。つまり、調査分析以外の商用使用については、許可や承認が必要になる可能性が高くなるということだろう。

気になるのは、右上の象限に属するアプリケーションだ。

ここの例としてTwitterキュレーションサービスの「Storify」【05】やTweetディスカバリーサービスの「Favstar.fm」【06】が紹介されている。

今回の仕様変更で排除されるリスクが明示されているアプリは伝統的なTwitterクライアントである「Tweetbot」【07】や「Echofon」【08】であるとし、このようなオリジナルTwitterのエクスペリエンスを模倣もしくは再生産するようなアプリを構築してはならないとガイダンスし続けてきたと主張している。

一方、それ以外の象限に関しては積極的に奨励すると明言している。現状は制限される領域にあるとされているアプリも、Twitter側と協働で新たなエコシステムをつくりあげる必要があるだろう。

何にしても、今回の仕様変更はTwitterの商用使用に大きな影響を与えることが予想される。今後も動向を慎重に見守っていく必要があるだろう。

【04】changes coming in Version 1.1 of the Twitter API（https://dev.twitter.com/blog/changes-coming-to-twitter-api）。
Twitter エコシステムについての解説はここに掲載されている。

【05】http://storify.com

【06】http://favstar.fm

【07】http://tapbots.com/software/tweetbot/

【08】http://www.echofon.com

[目次に戻る]

【本記事について】
2013年1月29日発売のweb creators特別号「いますぐ悩みが解決する! Webデザイン仕事で役立つ54のアイデア」から、毎週記事をピックアップしてご紹介! 近年さかんに目にするパララックス効果やMasonryを利用したレイアウトをはじめ、見やすくて使いやすいナビゲーション、フォームや製品紹介ページのユーザビリティを向上するインタラクション、表現の可能性を広げるHTML5+CSS3の機能、制作効率を向上するフレームワークの紹介、スマートフォンサイト制作のポイントとTipsなど、Web制作の仕事に役立つ54のアイデアが満載です。

※本記事はweb creators特別号『新世代Web制作テクニック総特集』からの転載です。この記事は誌面でも読むことができます。