TwitterAPI1.0 の廃止によるアプリケーションへの影響の分析
2010SE078 梶田裕紀

2010SE220 高井亮輔 2010SE226 高須健
指導教員：横森励士

はじめに

1

近年のソフトウェア開発では，第三者が提供するコードや API を利用してソフトウェアを開発することは珍しくどのようにコピーペーストされて利用されているか，ライブラリ側の更新があった場合にどのように対応しているかを，ファイル名やリポジトリの更新履歴の分析に基づいて調査を行った．

ない．ソフトウェアの保守が長期にわたる場合，開発の間その結果，130 個ほどのオープンソースプロジェクトがにフレームワークが新しいバージョンに更新されることもコピーによる利用を行っており，そのうち zlib で 3 割，考慮する必要がある．また，API などを通じて提供される

libpng では 9 割のオープンソースプロジェクトが何かの問サービスの内容が変わったり不具合に対して対策を行った

題を抱えているライブラリのバージョンをコピーして利用結果，その変化に対応することが必要となる場合も考えらしていることがわかった．全体の 8 割ほどのプロジェクトれる．これらの更新や変更に対して，実際の開発プロジェがライブラリのコードをそのまま取り込んでいる一方で，クトがどのように対応しているかを分析することは，ノウ残りの 2 割ではコピーペースト後に修正を加えていることハウの蓄積の観点から有益であると考えられる．

がわかった．全体では，15 ％ほどのプロジェクトはしっ
本研究では TwitterAPI1.0 が廃止された事例を題材に， かりとライブラリ側のアップデートにそってアップデート
実際にその API を利用しているオープンソースアプリ されている一方で，約 70 ％のプロジェクトは取り込んだケーションがどう対応したかを調査する．どの程度の量のソースコードの更新を行っていないことがわかった．これ

プロジェクトが対処を行ったか，対処を行ったプロジェクらの結果について，開発者は機能の実現に優先的に関心をトに対してはどのように対応を行ったかを調査する．これ

持っており，セキュリティ面において問題が起こる頻度はらの調査を通じて，フレームワークや API によって提供低いと考えられることからあまり関心がないのではないかされる機能が廃止された時に，開発者側がどのようなことと考察を行っていた．

を考慮して対応を行うべきか考察する．これらの知見を得ることで, オープンソースのプロジェクトを扱うときに考3

研究内容慮しなければならないこと, 一般的な保守作業において考3.1

動機慮すべきことを提案し, 近年のソフトウェア開発や保守における知見を得る.

API やライブラリの移行という事例に対して，分析を行っている研究はあまり多くなく，先行研究 [3] で述べた

2

背景技術論文くらいである．実際には，重大なバグや不具合やサー

2.1

TwitterAPI

TwitterAPI[1] と は Twitter 社 が 提 供 し て い る
Twitter[2] における API の総称である．Twitter でのツビス提供側の変化によって対応を余儀なくされることが想定される．このような更新や変更に対して，実際の開発プロジェクトがどのように対応しているかを分析すること

は，プロジェクト開発におけるノウハウの蓄積の観点からイートやフォローなどといった機能がまとめられている． 有益であると考える．
Twitter 社は開発者に向けて API を公開しており，各プロ
3.2 目的ジェクトはこれに沿って開発されている．TwitterAPI はweb 経由でサービスにアクセスする方式を採用しており，オープンソース開発において，今まで提供されていたweb アプリケーションとの親和性が高い．開発者の視点か API が機能しなくなった場合にどのような対応が取られる
ら見ると，各 API が提供するサービスを利用したアプリ のかを調査する．また，API が機能しなくなった場合に，ケーションの開発が容易である．公開された TwitterAPI 新たに利用可能な API への対応がなされているか，なさを利用して Twitter のほとんどの機能を呼び出すことがで れている場合にはどのような対応がなされているのかを調きるが，そのためには様々なプログラミング言語にあった 査する．オープンソース開発において API が機能しなくライブラリが必要になる．このライブラリを自分で組み合なった場合に，開発者がどのように対応を取るのか調査す

わせて TwitterAPI を呼び出すのは困難であるが，オープることで，オープンソース開発におけるフレームワークやンソースなどでたくさんのライブラリ API が公開されてAPI 利用の特徴が得られると考える．

いる．

2.2

関連研究

3.3

アプローチXia の研究 [3] では，zlib，libpng などなどのライブラ

TwitterAPI が 1.0 から 1.1 に完全移行した事例を題材に，TwitterAPI を利用しているオープンソースアプリ

リとして提供されているソースコードを題材に，それらがケーションを列挙し，開発履歴やリリースノート，実際の成果物をもとにする．以下の項目について調査する．とにどのような API が利用されているかを調査できるようになった．

Q1：どれだけ TwitterAPI の移行に対応しているソフトウェアが存在するか．

開発者ディスプレイ要件

Q2：API1.1 へ対応しているアプリケーションが存以前のサードパーティー製クライアントでは開発者在している場合に，どのように対応しているか，また独自の見た目を自由に生かしたものになっていた．し何か特別な処置を施しているか．

かし，Twitter 社は API を通じて取得したコンテン

これらの事例からオープンソース開発プロジェクトのツを「Display Guidelines」で決められたフォーマッ

特色や，API の移行に関して考慮すべきことなどを考察

トに従って表示するよう開発者に要請をした．いままでは強制することはなかったが，今回からアプリケーする．

4

TwitterAPI の移行

4.1

現在までの流れ2006 年に TwitterAPI のサービスが開始されてからしばらくの間 API1.0 が継続して使われていたが，API1.0 が廃止されることが 2012 年 8 月 16 日に発表され，最終的に 2013 年 6 月 12 日には API1.1 へ変更された．2012 年
8 月にバージョン 1.0 の廃止が告知されてから約 1 年間の移行期間が存在した．現在はバージョン 1.1 に完全移行しており，API1.0 は全く機能していない．公式の発表よりションは必ずそのフォーマットに従ってツイートなどの表示をしなければいけなくなった．この制約を守らずに API を利用していた場合は，アプリケーションの動作は不可能となる．
新しい Twitter クライアントポリシー

API1.1 ではユーザー 1 人 1 人にトークンが割り振られ，そのトークンにより認証を行うが，サードパー
ティ製クライアントには 10 万人ユーザーの制限がつけれた．上限を超えてしまったアプリケーションでは，インストールをすることはできてもユーザー認証主要な変更内容を列挙したものを以下に示す．これらの変を行うことができなくなる．こちらはクライアントの更は全て適応保守に分類される [5]．

み適応されるもので，Twitter と連携するサービスなどでは関係を持たない．

4.2

変更内容

API1.0 対応のエンドポイントの廃止
REST API を 呼 び 出 す 際 の エ ン ド ポ イ ン ト はhttp(s)://api.twitter.com/1/* だったが，API1.1 で http(s)://api.twitter.com/1.1/* へ変更
さ れ た ．検 索 API 呼 び 出 し 用 の エ ン ド ポ イ ン ト
は http://search.twitter.com/search.json だった，AP1.1 では REST API と統合され https://api.twitter.com/1.1/search/tweets.json へ変更された．

5調査

5.1

プロジェクトの抽出と分類

SourceForge[4] で公開されている Twitter に関連するオープンソースアプリケーションを中心に，TwitterAPIを利用しているものを対象として抽出し，分析した．それぞれのアプリケーションについて開発履歴，リリースノート，最終更新日，実際の成果物の情報を集めた．さらにア
プリケーションをファイルの有無，リリースノートの有無，で分類を行う．

レートリミットの改良
サードパーティ製クライアントの API1.1 のメイン

TL が 15 分で利用できる回数は 15 回である．公式クライアントの API1.1 のメイン TL が 15 分に利用できる回数は 180 回ととても大きな差が生まれ，サードパーティ製クライアントでの API 呼び出し回数には非常に大きい制限がかけられた．
取得可能データの変更

Twitter 社 は ，プ ラ ッ ト フ ォ ー ム 間 で 共 有 さ れ る
JSON フ ォ ー マ ッ ト を 支 持 す る こ と を 選 択 し た ．
API1.0 では，「XML」「Atom」「RSS」でも取得可能だったが API1.1 では利用することができなくなった．
すべてのエンドポイントで認証は必須

総数
成果物あり
リリースノートあり
成果物なし

個
171個
29個
67個
238

図 1 プロジェクトの分類

238 個のオープンソースプロジェクトが分析対象としてリストアップされたが，その中で成果物が存在したオープ
ンソースプロジェクトは 171 個であった．また成果物がAPI1.1 では，アプリケーションすべてのリクエストはOAuth 1.0a で認証することを要求している．API1.0

あるプロジェクトのうち，リリースノートが残されていたでは，認証を通すことなく利用できたアプリケーショ

オープンソースプロジェクトは 29 個であった．

ンも存在していたが，悪質な行為を防止するための措

以下では最終更新日が TwitterAPI1.0 廃止の発表が行置が行われた．この変更により，アプリケーションごわれた 2012 年 8 月以降かつ API の移行に対応しているソフトウェアはどのくらいあるのかを調査し，アプリケー• さまざまなエンドポイントの変更

ションが API1.1 に対応がなされていた場合には，対応し• OAuth 認証必要化の対応た内容と特別な処置を施しているかを確認する．

5.2

これらの変更とともに，「Twitter4J」における変更点として，Java1.4X サポートの廃止といった点がアナウンス

対応状況の調査抽出できたオープンソースプロジェクト 171 個のうち，されており，利用者はこれらの対応も求められた．

この「Twitter4J」を利用したアプリケーションとして1 種類の成果物のみしか公開されておらず，保守のフェー「Twitch」と「characterbot」の 2 つのアプリケーション
ズに含まれないオープンソースプロジェクトが 63 個存在がある．これらの 2 つのプロジェクトは，「Twitter4J」がした．そのうち API1.0 廃止後に新規公開されたオープン提供する jar ファイルを，ver2.0 台の jar ファイルからソースプロジェクトは 7 つであった．
Ver3.0 台の jar ファイルへ利用する jar ファイルを変更す
残りの 111 個は 2 種類のバージョン以上の成果物が公開ることで，API1.0 から API1.1 への移行に対応していた．
されていた．その中で API1.0 廃止後に新たに公開された
残りの 3 つのプロジェクトは直接 TwitterAPI を呼びオープンソースプロジェクトは 7 つであった．残りの 104出す形で利用していた．「OpenTween」においては Twit個は，プロジェクト開発中に API1.0 の廃止がアナウンスterAPI1.1 への移行期間中に更新が行われており，「Openされたプロジェクトであると考えることができる．
Tween」内でも移行期間中は TwitterAPI1.0 と API1.1 の『プロジェクト開発中に API1.0 の廃止がアナウンスさ利用コードが両方存在し，TwitterAPI1.0 の廃止後にはれたプロジェクトである』と考えられる 100 個に対し分析
API1.0 向けのコードが廃止されていた．
を行った結果，11 個のプロジェクトがアナウンス後に更新
一方で「TWinLite」の API1.1 への対応は，API1.0 のを行っており，そのうち 6 つのプロジェクトが API1.1 へ廃止がアナウンスされてから 4 ヶ月ほどで対応しているの対応を行っていた．以下ではこの 6 つのプロジェクトにが，API1.0 向けのファイルを直接書き換えられ，API1.0おける API1.1 への対応方法を説明する．
向けのファイルはこの時点で無くなっており API1.0 とAPI1.1 の両方を利用できる期間は設けられていなかった．
また，「MusicTweetMessenger」は API1.1 への対応が238個
総数67個
成果物なし
API1.0 が廃止されて 4 日ほど経ってからの 2013 年 6 月
56個
成果物が1個のみありに，API1.1 対応の Ver.1.0.3.3 がリリースされており，こAPI1,0廃止前で更新が停止
ちらも「TWinLite」と同様に，API1.0 と API1.1 の両方7個成果物が1個のみあり
API1， 0廃止後に開発を利用できる期間は設けられていなかった．いずれの 3 つ成果物が2個以上ありAPI1，0廃止前で更新が停止
成果物が2個以上ありAPI1，0とAPI1，1の両方の期間に更新
成果物が2個以上あり
API1,0廃止後に開発

93個

11個

7個

図 2 プロジェクトの分類のプロジェクトも，取得データの変更とエンドポイントの廃止という 2 種類を変更し，API1.0 から API1.1 への変更に対応していた．

考察

6

前節の調査をもとに，調査項目として挙げられた 2 つの項目について考察を行う．

5.3

対応内容の調査成果物が 2 つ以上あり，API1.0 と API1.1 の両方の

6.1

Q1：どれだけ TwitterAPI の移行に対応している
ソフトウェアが存在するか期間に更新があったアプリケーションで，API1.0 からTwitterAPI1.0 の廃止が告知された時点で 104 個のオー
API1.1 への変更に対応していたのは「Twichi」「charac- プンソースプロジェクトが保守の段階，もしくは保守後のterbot」「OpenTween」「MusicTweetMessenger」「TWin- 休眠状態にあったと考えられ，これらのプロジェクトは，Lite」「Twitter4J」の 6 つのプロジェクトであった．
移行への対応がなされる可能性があったと考える．それら「Twitter4J」とは，TwitterAPI の Java ラッパであり， のプロジェクトのうち 6 つのプロジェクトが必要な対応を
JSON や HTTP に詳しくなくても容易に TwitterAPI を 行っており，全体では約 6 ％のプロジェクトが対応を行っ使用するアプリケーションを作成する際に利用される．旧ていたことがわかる．関連研究 [3] では，セキュリティなAPI である API1.0 に対応するバージョンとして ver2.2.x どに問題を含むソースコードを取り込んだプロジェクトのまでの開発が行われていたが，API1.0 廃止後の更新では， うち，15 ％がライブラリ側の更新に合わせて更新を行っver3.0.x としてメジャーバージョンを切り替えて API1.1 ていたという報告がある．今回与えられた結果は、API1.1への対応が表現されていた．「Twitter4J」での，API1.0 へ移行しないと機能が引き続き利用できないなど移行を強から API1.1 への変更への対応は以下に示す．
く促すものであったにも関わらず，この事例よりも低い値•「xml」から「JSON」への取得データの変更の対応率であった．値が低くなった原因として以下のこと

が考えられる．

きに既存のオープンソースのソフトウェアを利用する際に• Twitter を利用したプロジェクトは，zlib などを利用は，利用するソフトウェアがどの程度保守されているか，するプロジェクトよりもコミュニティができにくいソフトウェアの生存期間中にどの程度までメンテナンスす可能性がある．「OpenTween」のようなユーザの多い
Twitter クライアントについては，コミュニティがる必要があるかを検討することがコストの見積もりとしてしっかりと形成され，きちんと対応がなされている．

必要不可欠であると考える．

6.4• 一方で公開されていたプロジェクトを見てみると，プログラムを作ることを中心に行っているというよりは，『こういう機能を作成したいので人を集めている』などのプロジェクトがよく見られた．このように現状プログラム開発コミュニティが成り立っているプロジェクトが多くないということを感じた．

保守作業において考慮すべきこと

ソフトウェアを保守する際には，ソフトウェアが置かれている立場に応じて考慮しなければならないことが生じることがある．例えば，そのソフトウェアを利用して他のソフトウェアが実現されている場合は，そのソフトウェアの利用者に対してアナウンスすることが重要な作業の１つとなる．例えば「Twitter4J」では廃止されるメソッドなど• TwitterAPI1.0 の廃止から約半年しか経過しておらが告知されており，利用者が新バージョンに移行するためず，まだプロジェクトの中に移行しきっていないもののガイドラインなどで合わせた告知が行われている．これがあるかもしれない．

らの告知は，利用者のスムーズな移行に必要不可欠なもの• 今後休眠していたプロジェクトについてユーザが定着である．別な立場として，利用するライブラリが更新されし，保守が再び行われるようになれば，実際の対応率るときに移行期間が設けられることがある．その移行期間はもう少し高いモノになるかもしれない．

中に更新を行うときには，問題の所在などを明らかにしや

6.2

Q2：どのように対応しているか，また何か特別な処置を施しているか実際に対応がなされた事例を考察すると，対応時に考慮すくするために，「OpenTween」のように新しいライブラリに対応する部分と古いライブラリに対応する部分で共存させ，切り替えることができるようになることに価値がある場合もあると考えられる．ただし，これらの変更には設すべき事項として，次のような方針が考えられる．

計変更などのコストが生じる可能性も高いので，どう変更

1.「Twitter4J」のように外部から利用されることを想定するべきかを検討する必要があると考えられる．

したアプリケーションは，明確にバージョンを区切るなどの対応をもって利用者への周知を行うことが必要であると考えられる．

2.「Twitchi」「characterbot」のような外部のラッパクラスなどを利用している場合には，ラッパクラスにおける対応も十分に理解した上で，新しく置き換えることが必要である．

おわりに

7

本研究では TwitterAPI1.0 が廃止された事例を題材に，どれだけのプロジェクトが移行を行ったか，どのように移行が行われたかを調査した．調査した結果として，移行が行われたプロジェクトが約 6 ％であるなど，関連研究での移行率より低い値が得られた．また，それぞれのプロジェ
クトごとに移行時のアプローチの仕方が異なるなどを確3. 移行期間中に更新を行う場合は，新旧両方に対応でき認することができた．オープンソースのプロジェクトを扱る形で対応しておくと，移行についての問題が整理しうときに考慮しなければならないこと, 一般的な保守作業やすくなるなどメリットがあると考えられる．

において考慮すべきことを提案し, 近年のソフトウェア開4. 旧バージョンが廃止された後に更新を行う場合は，す発や保守における知見を得る．今後の課題としてプロジェ

でに旧コードは意味を成さないので，いきなり新コークトへの聞き取り調査などを行い，なぜこのような結果にドに切り替わっても大きな問題にはならい．今後更新なったかを詳細に分析することなどが挙げられる．

されるプロジェクトは単に切り替えるだけの対応で十分だと思われる．

6.3

オープンソースプロジェクトについての考察

オープンソースプロジェクトの場合，コミュニティが成立して開発が活発に行われているプロジェクトがある一方で，ソースコードが公開されているだけのプロジェクトも多かった．そのようなオープンソースのプロジェクトの場合は、利用者がメンテナンスを行う者になることが求められる．新しい機能を持つソフトウェア開発を行う際には，新規にプロジェクトを立ち上げてから行うか，既存のプロジェクトを利用して行うかを検討する必要がある．そのと参考文献[1] 山本裕介：『TwitterAPI ポケットリファレンス』．技術評論社，2011．
[2]

Twitter ,https://twitter.com/[3] Pei Xia， An Empirical Study of Out-dated Thirdparty Code in Open Source Software ，大阪大学修士論文，2013．
[4]

SourceForge.JP ，http://sourceforge.jp/[5] S．L．ブリーガー：『ソフトウェア工学』．ピアソン・
エデュケーション，2001．