2015年05月15日
※2019.8.15更新。Twitter検索の新UI適用に伴う修正
※2016.2.21追記：現在、この方法は利用できなくなっているようです（発言内容を指定せずユーザだけを指定する検索は不正な検索と扱われるようになったようです）。またOKになったようです。
※2015.5.22更新。Twitter検索の新UI適用に伴う修正
【まずは結論から】
https://twitter.com/search?f=live&q=from%3A[Twitterのユーザ名(screen_name)]
（※2019年までの旧UI向けのURL: https://twitter.com/search?vertical=default&f=tweets&q=from%3A[Twitterのユーザ名(screen_name)]）
（※2015年までの旧UI向けのURL: https://twitter.com/search?f=realtime&q=from%3A[Twitterのユーザ名(screen_name)]）
でできる。例えば私（@h_hiro_）の発言一覧ならhttps://twitter.com/search?vertical=default&f=tweets&q=from%3Ah_hiro_でよい。
【注意点】
Twitterの検索機能にひっかかる発言に限定されるため、古い発言の取得には限りがある。
【補足】
Twitterの検索では、「from:ユーザ名」と入力すると（検索窓でも同様）そのユーザの発言のみが検索される。
また、検索条件を「Top」ではなく「Live」にする（上記のURL上では「f=live」というパラメータがそれを担う）ことで、そのユーザの最近の発言を、重要性や人気などは関係なく、単に時系列に並べている。
【余談：なぜこれが欲しかったのか】
私は、Twitterでフォローされたときに返すかどうか「考えて決める」ほうなので、その際に「その人はどんな発言をしているか」が基準となっている。
ただ最近は、発言のかなりの割合をRTを占めるというユーザも多いため（私もそうなってしまうことがよくありますが）、その場合に「本人が発した言葉のみ抽出する」ということがしたかったのである。
2012年08月17日
以下の記事を見つつ、ポイントをまとめていくとともに、私の考えを述べていく。
●原文：Changes coming in Version 1.1 of the Twitter API | Twitter Developers（基本的にはこれを参照します）
●日本語での要約：Twitterブログ: Twitter API v1.1でのAPI利用ルールの変更について
●参考記事：Twitter、開発者向けガイドラインとAPI変更について説明 ユーザー数制限など厳しい内容 - ITmedia ニュース
【Authentication required】（認証が必須になります）
現行では、statuses/user_timeline（一人のユーザを指定して発言を取得）のような「Twitterにログインしていなくても見られる情報」に関するAPIは、認証情報を送らなくてもアクセスすることが可能であった。しかし仕様変更後は、どのAPIでも認証情報を送る必要が生じる。現在、私がHHiro.net内で動かしているTwitter向けツールでは、TwiPieces以外すべて改修が必要になる。あと個人的に動かしているボットとかツールとかも。
でこの改修なのだが正直面倒である。OAuth対応は本当に面倒くさい。方針としては、私自作のTwitterボットライブラリ「twbot2.rb」からOAuth関連部分だけ切り出して対応しようと考えている。
【Per-endpoint rate limiting】（API呼び出し対象ごとの規制）
簡単に言えば、statuses/user_timeline と statuses/home_timeline はそれぞれ別枠でAPI呼び出し回数の規制をしますよ、という話。ユーザごとにAPIを使うサービスならあまり影響はないものの、ふぁぼったーのような「多数のユーザから取得する」サービスがつらい、という話も。参考：F's Garage @fshin2000 ：Twitter api ver1.1、痛いところ、痛くないところ
ちなみにこれは、あくまでタイムライン取得系APIの規制の話で、発言数規制やふぁぼ規制は（現行のスキームが維持されるなら）別枠で計算される。
【Changes to the Developer Rules of the Road】（開発者が従うべきルール）
【Display Guidelines will be Display Requirements】（「表示ガイドライン」は「表示の必須要件」に）
Twitterでは、ツイートを表示する場合のガイドラインとしてDisplay Guidelines（英語）を用意していて、「アイコンは必ず表示する」「ユーザの名前とユーザのアカウント名はアイコンの隣に表示する」「ツイートを選択したりしたときは、返信・お気に入り・リツイートが必ず出来るようにする」などのガイドラインが存在している。これは現状では推奨される表示方法という位置づけであったが、これが必須になる。ここで大きな問題があって、例えば「動作を軽くしたいからアイコンを読み込まない、というのは認められないのか」とか、「表示する情報量を増やしたいから、オプションとしてユーザの名前は表示しないようにする、というのは認められないのか」といったことが挙げられる。ちなみにDisplay Guidelinesで個人的に気に入らないのは、発言時刻の表示について「24時間以内の発言の場合は"●●時間前"などの表示を、それ以前のものは日にちのみを表示」と決められていること。個人的にはどんな場合でも、日時と時刻で見えていて欲しいので。
ちなみに、「この要件を守らないアプリケーションの許可を取り消す権利が我々にはある」（原語：If your application displays Tweets to users, and it doesn't adhere to our Display Requirements, we reserve the right to revoke your application key.）とあるので、サードパーティのクライアントもこのガイドラインを強制される、すなわち「自分の好きなUIでTwitterを楽しむ」ことが出来なくなってしまうんじゃないかという懸念がある。
【Requiring pre-installed client applications to be certified by Twitter】（Twitterを利用するプリインアプリは許可を受ける必要あり）
パソコンやスマフォなどのプリインアプリが対象。理由としては「プリインアプリが更新されるには時間がかかるから」とのこと。【Requiring developers to work with us directly if you need a large amount of user tokens】（大量のトークンが必要な場合はTwitterと直接協業する必要あり）
ここでトークンというのは、OAuth認証における、ユーザとアプリの組に対して与えられる認証用文字列のことで、つまりは「大量のユーザを対象とする場合は」という話である。1つのアプリが、Twitterに許可を得ずに受け入れられるアカウントの数は10万に制限される。ただしすでに10万を超えているアプリなら、その2倍までは拡大が認められる。
【API v1.1 migration period】（API v1.1への移行期間）
6か月待ちますよ、とのこと。【Today's Twitter ecosystem】（現在のTwitter界の体系）
結論から言うと、Twitter社としては「Twitterクライアントはあまり作って欲しくない」とのこと。現在のTwitter APIの使われ方を「ビジネス向けか一般利用者向けか」（Business/Consumer）「Twitterを利用するのか分析するのか」（Engagement/Analytics）という軸で分け、そのうち右上の項目 "Consumer+Engagement" についてはAPIをあまり使って欲しくない、とのことであった。（原語：limit certain use cases that occupy the upper-right quadrant）
で、このConsumer+Engagementに含まれるものとして、「traditional Twitter clients」（これまでのTwitterクライアント）や、「Syndication」（発言を見せたり広めるためのサービス、という意味と思われる。Favstarなど）が入っている。
確かに現在だと、ブラウザのインターフェイスが多機能化してブラウザだけでもかなり使いやすくなったし、モバイルアプリも公式で揃っているというのはあるけど、歴史的経緯からすれば「色々な人が知恵を出して＆技術を身につけて作った」から多数のクライアントアプリがあるわけで、そういう開発者にとってはもちろん面白くないし、「様々なクライアントがあるから自分にあったものを見つけられて、それによってTwitterを楽しめている」人にとっても面白くないと思う。
ただTwitter社の意向としては、どうも「どんなユーザエクスペリエンスを提供するかは、Twitter社がコントロールしたい」ようなのである。上記の表示ガイドライン然り。
（参考記事：Twitterの将来を握っているとされる"Twitter Cards"とは：InstagramへのAPIも閉鎖したTwitterの将来像 - the Public Returns - 続・広報の視点）
【Looking ahead】（前を見て）
Twitter Cardsの話。上記のリンクにも書いてあるのだが、ユーザ側で「Twitterで見ると画像などが表示される」ようなサービスを作るための仕様である。ちなみにこの節の最初の一文を訳すると、「API v1.1以降では、Twitterにあるコンテンツを使って何かするだけではなく、Twitter Cardsへの対応も考えて欲しい」という内容。言い換えれば、Twitterから情報をもらうだけじゃなくて、Twitterへ情報を渡すこともして欲しい、とのことだろうか。
【結論】
結局のところ、「今までは外部サービスに支えられてきたけど、今後は徐々に、Twitterが主要な部分を握った上でAPIを使ってもらいますよ」という方向転換をしたというのが見て取れる。上記のthe Public Returnsの記事で言われている通りなのだが。でこの構図、どこかで見たことあるなーと思ったのだが、考えてみたら「プラットフォームの主要な部分はユーザに使わせず、それによってユーザエクスペリエンスを向上させるiPhone」vs「ユーザに自由に使わせることで、使い方自体をどんどん広げてもらうAndroid」がそれだった。
なので、この舵の切り方がうまく行けば、Twitterという世界に統一感が生まれてユーザにとっても分かりやすくなるとは思う（それでも私は快く思わないけど）。ただ一方で、現行の開発者の離反を招くのは確かなので、そこでコケないのかという懸念も感じるのである。
【余談】
交流ツール、情報収集ツールとしてTwitterを使うのはしばらくやめそうにないけど、自分がTwitterに対して開発者魂が疼かなくなっていきそうなのは確かなので、自分は何か代わるサービスを探した方がいいかもしれない。2010年12月20日
参加してきました。
今年の参加者は44人。昨年（参加者50人）では初顔の方も多かったのですが、今回は逆に大半が一度顔を合わせている方でした。この1年で新たに知り合った方も多かったなと感じました。
思えば自分がTwitterを始めてから3年。その間に多くの方とお会いし、多くのことを教わり、多くの思い出が出来ました。
道民部の中ではかなり古株ということになりましたが、これからも過去にやってきたことのみに満足しないで、新しいことを学んだり新しく来た方と交流したりするよう心がけます。
【追伸】
宴会の写真を全然撮ってませんでした…orz 人の写っているものしかないためアップはしません。
2010年05月05日
●OAuth非対応版のtwbot.rbからの移行を容易にする
●ブラウザが使えない環境でも認証が出来る
という利点からxAuthを利用したかったのだが、非常に残念。
以下、その時のやり取りの内容。（原文は英語。大雑把な意訳です）
Twitter APIの管理者（以下「管」）：「xAuthの利用許可を1週間だけ出しました」
私：「ライブラリが完成したら継続的に利用できる、ということなのでしょうか？」
管：「いいえ、それは出来ません」
私：「それだと、ライブラリ利用者に不便を強いることになるので、出来ればxAuthを継続的に使いたいのですが…」
管：「xAuthの仕組みは、ライブラリに対して適用するには適していないので、現状ライブラリに対してはxAuthを継続的には使わせないことにしています」
私：「ライブラリだとどこが都合が悪いのですかね？デスクトップで利用するTwitterクライアントと比べて違わないと思うのですが」
管：「コンシューマトークン(*1)がソースコード中に生で書かれますよね？なので他のユーザが容易に、そこだけ置き換えて利用出来る（＝Twitter投稿時に表示されるアプリケーション名を勝手に置き換えて利用出来る）のが問題なのです」
私：「とりあえずそちらの運用については分かりましたが、それって、デスクトップで利用するTwitterクライアントであろうとも、それがオープンソースで開発されてたら同じ問題抱えてますよね？今はxAuth使わないことにしますが、とりあえず、そちらの運用には納得行かない、ということは明言しておきます」
てことで、かなり不満を抱えつつも、twbot.rbのOAuth版はxAuthなしで使えるような形でリリースします(*2)。
----
(*1)アプリケーション単位に割り当てられるOAuthトークン
(*2)xAuthを使う部分のコードは残したままリリースします。ただしそれを用いてアクセスしても、xAuth利用の許可が出ていないため「401 Unauthorized」のエラーになります。
2010年04月15日
Twitter API プログラミング著者：辻村 浩
販売元：ワークスコーポレーション
発売日：2010-04-21
クチコミを見る
拙作「RubyによるxAuth実装」が、@tsupo氏の著書「Twitter API プログラミング」に掲載されました。
「2 Twitter APIを使ったサンプルプログラム」→「2.2 OAuth、xAuth関連」→「2.2.5 Rubyの実装例」として取り上げていただきました。
このコードが、より多くのTwitter向けサービスを制作される方のお役に立てば幸いです。
2010年02月20日
Maraigue風。:[Twitter][ふぁぼったー] 現在開いているユーザのふぁぼられを見るブックマークレット
Maraigue風。:[Twitter] 現在開いているユーザのふぁぼられをFavstar.fmで見るブックマークレット
以前「ふぁぼったー」「favstar」という、Twitterのお気に入りを集計するサービスへジャンプするためのブックマークレットを作ったのだが、同様のサービス「ふぁぼるっく」「Twistar」への対応版も作ってみた。
●[ふぁぼったー]
●[favstar]
●[ふぁぼるっく]
●[Twistar]
上記リンクのうちお好きなものを、ブックマーク領域にドラッグ＆ドロップするか、右クリックしてブックマークに追加するメニュー（「お気に入りに追加」など）を選択するなどして、ブックマークとして使えるようにして下さい。
そしてブックマーク領域に作成されたこのリンクを、Twitterのユーザページあるいは発言のページを開いた状態でクリックして下さい。
2010年02月15日
タイトル長めですが、大事なことなので全部書きました。
コードはこちら：
- メインのライブラリ/タイムラインを取得するサンプル
- gist: 304123 - GitHub（最終更新：2010.02.15 11:26）
- 発言を投稿するサンプル（上記ライブラリと組み合わせてご利用下さい）
- gist: 306853 - GitHub（最終更新：2010.02.18 3:09）
概要
Twitterでは、OAuthという認証のシステムが利用できる。
従来は、（ユーザ認証を伴う）TwitterのAPIを利用する際、APIの呼び出しのたびにユーザ名・パスワードを送信する必要があった。一方OAuthでは「トークン」と呼ばれる、ランダムに生成された文字列を、APIへのアクセス権限を証明するものとして発行する。実際にAPIを利用する際には、このトークンを用いてアクセスすれば、ユーザ名やパスワードを送信する必要はない。（詳しくはAPIアクセス権を委譲するプロトコル、OAuthを知る − ＠ITを参照）
なお、「あるユーザAの出来る行為」に対応するトークンを発行するためには、(1)ユーザAがTwitterにログインした状態でトークン発行ページにアクセスするか、(2)ユーザAのユーザ名およびパスワードを送信してトークンを直接取得する(xAuth)必要がある。
トークンを介する利点として、Twitterと連携するウェブサービス（例えば、アップロードした写真をTwitterに通知する）が、Twitterユーザのパスワードを直接記録せずにTwitterの機能を利用できるということが挙げられる（(1)の方法を使えば、ウェブサービス側にはトークンしか通知されないため）。これはセキュリティ上も、ユーザの心理という面でも便利である。
経緯
上記(1)の方法でのトークン取得が、Twitterと連携するウェブサービスに適した方法であるのに対し、(2)の方法は、各個人のコンピュータにインストールされるTwitterクライアントなどに適しているといえる。これらのクライアントは、ブラウザと無関係に動くほうが当然便利であるし、またユーザがパスワードをクライアントに伝えずに利用することはそもそも不可能だからである。
(1)の利用法はすでに多く用いられている一方、(2)の利用法はあまり広まってはいないのが現状である（後述）。これは(2)の方式が後で追加された仕様であること、また従来の「APIの呼び出しのたびにユーザ名・パスワードを送信する」方法（具体的には、Basic認証）で事足りていたというのが大きいと思われる。
しかしつい先日、TwitterがBasic認証でのAPI利用を6月ごろに終了するというアナウンスを出した。そのため、今後はBasic認証を用いていたサービス・アプリケーションは、OAuthを用いるものに移行する必要が生じた。
さて、私はtwbot.rbという、RubyでTwitterボットの制作を補助するライブラリを作っている。これはxAuth、つまり(2)の方法でのトークン取得が適しているケースといえる。しかしWeb検索を利用しても、RubyにてxAuthでトークン取得を行うためのコードが見つからなかった。それを書いたのがこのコードである。
これまでのコードと解決法
これまでにも、RubyにてOAuthを利用するコードはいくつか公開されていたものの、いずれも(1)の方法、すなわちブラウザを介してトークンを取得するものであった。
Twitterでこのことについて投稿したところ、@rokudenashi氏から「xAuthでのトークン発行はすでに実現できている」との情報をいただき、そのPythonコードを拝見させて頂いた。そこで、これをRubyに移植することにした。
さらに調べたところ、xAuthはHTTPヘッダに追加の情報を加えることで行うことが分かった（参考：OAuthでデスクトップアプリがブラウザを経由させたくないときのxAuth - Codin’ In The Free World）。これを踏まえ、RubyのOAuthライブラリのリファレンスや、xAuthを利用しているコードの一部とにらめっこしながら、前述のコードを書き上げるに至った。
コードの解説
大した内容ではありませんが、念のため解説。
最初のconsumer = OAuth::Consumer.new …の部分は、他のサンプルなどでも見られるコードである。ただし、アクセス先を「https://」と「api.twitter.com」にしないとならない模様（「http://」では403エラーになった）。
次のconsumer.get_access_token …の部分で、いきなりアクセストークンを取得する（(2)の方式でなく(1)の方式を用いる場合は、その前に「リクエストトークン」という別のトークンを取得する必要がある）。この際、HTTPヘッダにユーザ名やパスワードを書いておく必要があるため、第3引数にユーザ名・パスワードおよび、「:x_auth_mode => "client_auth"」（xAuthを利用している、という情報）を加えてある。
追記：OAuthのアプリケーション登録方法
（2010.02.18 3:09追記）
本コードは、利用される皆様がそれぞれOAuthのアプリケーションを登録する、という想定のもとで書かれています。お手数ですが、OAuthのアプリケーション登録を行い（参考：TwitterのbotをOAuthに対応させる - しばそんノート→「OAuthクライアントを登録する」）、そのConsumer key/secretを用いてお試し下さい。
（2010.04.15 23:14追記）
遅ればせながら。
Twitter APIにおけるxAuthの正式サービス開始に伴い、メールで申請されたアプリケーション以外はxAuthが利用できなくなりました。（参考：Twitter API Wiki / Twitter REST API Method: oauth access_token for xAuth）
このためxAuthを用いるアプリケーションを作成するには、上記方法でアプリケーションの登録を行ったのち、api@twitter.com に「アプリケーション●●をxAuthでも使えるようにして下さい」という内容のメールをしないとなりません。
おわりに
xAuthの利用方法について貴重な情報を下さった@rokudenashi氏、IRCで議論して下さった@niku_name氏・@onodes氏、更にインターネット上の各情報に感謝の意を表します。
このコードが、皆様のRubyでのxAuth利用の助けになれば幸いです。
2009年12月15日
ただ、私はよくこれを開いたまま放置してしまい、ブラウザを重くしてしまうこともあった。なのでこの機能を切りたかったのだが、設定画面を見た感じでは切るのは不可能そうだった。
そんなとき情報提供者が。
Twitter / Azusa HSB: @h_hiro twitter.com/home?since_id=[wildcard]&refresh=true を切ればなくなるですよ
ということだったので実験。
Firefoxで特定URLへのアクセスを禁止するアドオン「BlockSite」を導入し、Blacklistの欄に「http://twitter.com/home?since_id=*&refresh=true」を指定。この状態でタイムラインのページを開いておくと
という通知が出て、「new tweets」の機能がブロックされた。
なおこの通知が不要なら、BlockSiteの設定で「Enable warning messages」を無効にすればよい。
「ブラウザで表示されるURLだけでなく、ページ内部でアクセスするURLも制限できる」アドオンであれば、他のブラウザでも同様の対応が出来るであろう。
2009年10月09日
今まで、私管理のTwitter botは自宅にあるサーバ（HP ProLiant ML115）を利用して運用していたが(*1)、家で回していると電気代が結構かかるということもあり、Webサーバもろともさくらインターネットのレンタルサーバへ引っ越すことにした(*2)。
さくらのレンタルサーバは、cron（UNIX系OSで、プログラムを定期的に実行する機構）が利用できる上、プログラムの新規導入も制限があるものの（ユーザのホームディレクトリにインストール出来るものならよい）可能なため、それまでの自宅のサーバに近い環境でTwitter botを動かすことが出来る。
移転の際のキーポイントをいくつか。
- コントロールパネルからはcronで動かすプログラムの数に制限があるため、それ以上動かしたい場合はサーバにSSHログインし、
crontabコマンドを使って自動実行するプログラムを直接指定する必要がある。 - 私のTwitter botを動かすに際して、Rubyはサーバに最初から導入されているものを使ってもよかったのだが、RubygemsやJSONを楽に利用したかったこともあり、自分のホームディレクトリ以下にRuby1.9をインストールした。
（参考：Ruby Install Guide::UNIX全般）
私は、Ruby1.9の実行ファイルを「ruby」ではなく「ruby1.9」にしたかったので、./configureは以下のようになった。$ ./configure --prefix=$HOME/local --program-suffix=1.9
- とりあえず家にあるプログラム・データをすべてさくらのサーバにコピーし動かしたところ、@gankaiだけがかなりの頻度でプロセスを強制終了させられていた。
調べたところ、データファイルがかなり大きくなっている上に毎回これをすべて読み込む仕様になっていたため、これがメモリ使用量を引き上げていて、サーバ側から規制されたものと思われた（手元の環境で試したところ、1プロセスでメモリを約20MBもし使っていた）。これはデータファイルを分割して対処した。
ということで、これからさくらのサーバにお世話になります。
(*1) オープンソースカンファレンス2008 Hokkaidoでの抽選会で頂いた景品
(*2)以前はXREAを使っていた。一部のコンテンツは引き続きXREAで運用します。
2009年09月29日
ツイッター始めて変わったこと - さまざまなめりっと - はてなグループ::ついったー部より。
http://twitter.g.hatena.ne.jp/maname/20090927/1254012089
ツイッター始めて変わったことは、読んでみて、自分にも当てはまってるかな…と思ったら、あまり当てはまってなかった。
1.ブログを書かなくなった、
2.mixiにログインしなくなった、
3.iPhoneを買った、
4.本や漫画を読まなくなった、
5.友人知人が増えた
Twitter / 島田美帆
自分に当てはまっているもの。
3 → iPhoneではないけど、携帯を買い換えた理由の一つに「Twitterを快適に行いたい」というのがある。
5 → Twitter経由で北海道開発オフに参加したのを皮切りに、多くのイベントに参加し知り合いも増えた。
自分に当てはまらなかったもの。
1 → 自分のコンピュータ関連の行動の幅が広がり、ブログを書く頻度が増えた。
2 → mixiはTwitterと別枠のコミュニケーションツールとして生かしている。
4 → Twitterで情報が流入して、逆に漫画などの興味が広がった。けいおん！とか買ったし。
自分の場合、送受信する情報量がTwitterによって大きく増えたので、その結果としてこのようなことになったのだろう。
(2009.10.5 若干修正)
