【Java】Twitter4jを使ってひなっちのおはっちをさーちして遊んだっち！

別にここであえて語るまでもないことだが、「ひなっち」とは、
ロックバンド「ストレイテナー」「Nothing's Carved In Stone」「Fullarmor」「Killing Boy」のベーシスト「日向秀和」氏の愛称である。
（以後、本項では「ひなっち」と記載させていただく）
ひなっちは基本毎日ツイッターで「おはっち」という挨拶を心がけており、
それに対してファン（フォロワー）のアカウントの方から「おはっち」と返信（リプ）をすると、
リプした順番に応じて（大体５位くらいまで？）ひなっちから「１番おはっちおめでとう！」というようなメッセージがもらえる。
フォロワーの方たちはひなっちのおはっちでいっちばん（一番）を取るべく
気合いをいれてツイッターでまちかまえているのだ。
これはライブ会場で先頭に赴く心情と近いものがあるのだろう（勝手な予想）。

で、この「ひなっちのおはっち」に対して、

• 一体どれほどの人が「おはっち」しているのか？
• 最短でどれほどの時間で「おはっち」しているのか？

というのを知りたくなったので、
Twitter4jというJavaのツイッターAPIを使ってひなっちのおはっちをさーちし、集計してみることにした。
本項ではそのためのTwitter4jのメモと、それをもとに作成した趣味用プログラム「ひなっちおはっちさーち」について記述する。

Twitter4j公式ページ：
http://twitter4j.org/ja/index.html

※ちなみに、Twitter4jを使うにあたっては、大前提で「APPアカウント登録」みたいな作業が必要になる。
ググれば出てくるが、https://apps.twitter.com/に行って、
指示に従って「APPアカウント登録」を行い、認証に必要な以下４つのプロパティ情報を取得のうえ、
Java実行環境と同階層に「twitter4j.properties」という名前で保存する。

oauth.consumerKey=*************************  
oauth.consumerSecret=**************************************************  
oauth.accessToken=**************************************************  
oauth.accessTokenSecret=*********************************************  

あるいは-Dのシステムパラメータで設定するとか、
Java内でConfig設定用クラスを用いて設定するとか、
いくつか方法があるみたいではあるが、とりあえずこれで。

 
Twitter4jは割と昔からあるみたいだが、登場からしばらく経ちいろいろ仕様が変わっているようで、
ググって出てくる記事やページも、２０１７年７月１６日現在のTwitter4j最新Ver(4.0.4)に照らし合わせると、そのまま適用できない事例やサンプルコードが多い。
Twitter4jのダウンロードパッケージにも一応申し訳程度（？）にJavaDocはついてるが、全部英語なので読めるわけがない
まあそんなわけで重要なポイントでは手さぐりでの実装・実験が必要になった。
参考にしたサイトのURLを載せておく。
■http://www.mwsoft.jp/programming/java/twitter4j_2016.html
Twitter4jでのsearchの基本的な使い方が載っている。
いろいろ調べた中では一番参考になった。
■https://dev.twitter.com/rest/public/search
twitter APIの公式ページ。
クエリに指定するパラメータの記述方法がサンプルを含めていくつか載っている。
リプライの検索方法を知りたかったのだが、まあ、見つけたからいいや。

Twitter4jにおけるsearchの基本的な実装は以下の通りだ。

// (1)Twitterのインスタンスをつくる  
Twitter twitter = new TwitterFactory().getInstance();  
// (2)Queryオブジェクトをつくる

Query query = new Query();
// (3)クエリをセットする

query.setQuery(“おはっち”);
// (4)結果件数をセットする

query.setCount(100);
// (5)検索する

QueryResult result = twitter.search(query);
// (6)検索結果を取り出す

List resultList = result.getTweets();
// (7)総ナメする

for (int i=0; i < resultList.size(); i++) {

Status tweet = resultList.get(i);

…（省略）…

}

冒頭書いた「APPアカウント登録」が済んでいないとか、
済んでいてもpropertiesの設定に誤りがある、
認証できない（インターネット接続できない）、
というような場合は、(1)の段階で実行エラーになって先に進めない。

(3)が、特に今回の「ひなっちおはっちさーち」におけるキモ。
ここで検索条件の詳細を記述（指定）するのだが、ここは後述する。

(4)における、Query#setCountの引数はintだが、Twitter APIのsearchメソッドの仕様上、100以上与えても意味ないらしい。
（実際1000とか与えても100件しか返却してくれない。実はこれが最大のネックである。詳細は後述する。）

(6)で取り出すのはjava.util.Listであり、型は「Status」というオブジェクト。
この「Status」というのがTwitterの「投稿文（つぶやき）」そのものを表しており、
普通のツイートも、リプも、リツイートも、中身のフィールドの値の有無はあれど、全て「Status」というので表現されている。
それのリストを取り出してグルグル回すだけなので、検索の考え方的には至ってシンプルで、直感的にわかりやすい。

(3)のクエリ指定文字列について。

「ひなっちおはっちさーち」において実現したい機能性は主に下記２点。

1. ひなっち本人がおはっちツイートをした時間・ふぁぼ数・「おはっち」リプの数等
2. １番おはっちリプの時間（特にひなっち本人の「おはっち」ツイートからの経過時間）平均、最大、最小等

細かくいうともっといろいろ知りたいのだが、一旦最低限実現したい機能としてこのあたりを盛り込みたい。

↑で書いた「実現したい機能性」のうち、
１．は「ひなっち本人から発信された"おはっち"という文言を含むツイート」を検索する必要があり、
２．は「ひなっち本人に向けて発信された"おはっち"というツイート（リプ）」を検索する必要がある。（※）
つまり最低でも２つのクエリが必要だ。

いろいろ試した結果以下の記述で目当てのツイートを抽出できそうだとわかったので、ここにメモとして載せておく。
Query#setQueryの引数に、半角スペース区切りで条件を記述していくのが基本となる。

No用途クエリ記述内容説明

おやつはゴマ団子！…はっ、ち、違うぞぅ！？これは、ボクが用意しておいたものだからね！！  

@aimomo5831 4番おはっちリプでしたぁ！！！  

なお、公式サイトによれば、「クエリに渡す文字列は必ずURLエンコードしろ」みたいなことが書かれているが、
↑の実装の通りで、URLエンコードしないで渡してもちゃんとそれっぽく動作する。
これはTwitter4jがやってくれているのだろうか？

プログラムの考え方としては、ざっくり以下の通りとなる。

（１）「ひなっち本人から発信された"おはっち"という文言を含むツイート」（※本人のリプ除く）を検索する（実現したい機能性１）  
　┗取得した検索結果がなくなるまで以下を繰り返す。  
　　（２）（１）の結果を１件取得し、ひなっちのおはっちの「ツイート日付」、ツイートIDを取得する  
　　（３）（２）をもとに、untilとsinceを設定する（untilは翌日、sinceは同日）  
　　（４）「ひなっち本人に向けて発信された"おはっち"というツイート（リプ）」を、（３）を動的に適用しつつ実行す（実現したい機能性２）  
　　　┗取得した検索結果がなくなるまで以下を繰り返す。  
　　　　（５）（４）の結果を１件取得し、ツイートのID、リプライ元ID（inReplyStatusID）を取得する  
　　　　（６）（５）のリプライ元ID＝（２）のツイートID　かつ　ツイートIDが「（４）の結果の中で最小のツイートID」かどうかを検査する。（最小のツイートID＝１番おはっちリプ、と見做す）  
　　　　（７）「ひなっちのおはっち」と「１番おはっちリプ」に関する情報を内部的にVOに編集・保持し、ObjectOutputStreamでファイル出力する（ファイル名はひなっちのおはっちのツイートID）  
（８）過去出力分を含め、（７）で出力した（今回出力分含む）全オブジェクトを読み込み、集計する  

ポイントしては。。。

• 結果をどっかに出力しておこうとはもともと思っていたので、本当はCSVとかTSVとか、扱いやすいテキストファイルにしたかったのだが、
  ツイートには得てして改行が入り込むもので、フラットなテキストファイルにするには（後々読み込んで集計することを考えると）ちとやりづらいところがあった。
  面倒くせえからSerializable継承してオブジェクトのまま出力しちまえと思い、（６）ではObjectOutputStreamを用いた。
  （DBにブチ込めればもっと楽なのだが…）
• 調べてみると、時分秒まで一致している「おはっちリプ」がある。(2017/7/19には実際それが見られた)
  当たり前だが、特に１番おはっちリプ付近で発生しがちである。
  ⇒見つけたおはっちに対して、みんながみんな我先にと即効でリプりに行くのでアクセスが集中するためだ。
  最初は「検索したリプの中で一番若い時間＝１番おはっちリプ」と判定すればいいと、短絡的に考えていたが、
  このようなケースではどれを「１番おはっちリプ」とするかわからない（というより不正判定になる可能性がある）
  ただ、このようなケースでも、それぞれの「ツイートID」が異なっているので、
  （６）では「一番若い（最小の）ツイートID＝１番おはっちリプ」と見做すようにした。
  見ている限りでは問題なさそうだが、ツイートIDの採番＝シーケンシャルで昇順というルールを暗黙の前提にしているため、
  このルールが崩れると（あるいはそもそもそんなルールがないとか）この判定ロジックは破たんする。
  （2017年7月現在で887826634841006080くらいまできており、long型の最大値9223372036854775807に近づいてきているので、なんとなくサイクリックに採番してそうな気もするが）
  
  余談だが、Status#getCreatedAt()で取得できるツイートの投稿日時は、Date型なのにミリ秒部分が全部0になっている。
  これがTwitter4jの仕様なのかTwitter APIの仕様なのかわからないが、Twitterでは投稿日時をミリ秒まで保持していないように見える。
  ミリ秒まで保持しているからといって↑の問題が解決するわけではないが（劇的に少なくなりそうではあるが）、
  なんとなく気になったので記録として残す。
• 「ひなっちは１日に必ず１回だけおはっちツイートする」という風になんとなく思っていたが、
  調べてみるとどうもそうではないらしい。（そんなのひなっちの自由だから当たり前っちゃ当たり前なんだが。。。）
  （３）の日付編集と、それをもとにした（４）のクエリ実行は、上記の想定から「日別」に行われることを考えていたため、
  ひなっちが１日に２回以上「おはっち」すると、（４）で実行するのと同じクエリが複数回流れるので、
  複数の「おはっち」に対するおはっちリプをまとめて検索することになり、結果的に「１番おはっちリプ」の判定が正しく出来ない可能性がある。
  このため、（６）の判定では、リプのツイートに持つ「リプライ元のツイートID」（getInReplyStatusId）が、
  検査対象となっているひなっちのおはっちツイートのIDと一致しているか？
  つまり、「確実にそのおはっちに対するリプか？」というのを改めてチェックするようにしている。
  
  ただ、これは、「１日複数回投稿されたおはっち」に対し、そのそれぞれの「おはっちツイート」に対する「１番おはっちリプ」を特定するやり方なので、
  それが「１番おはっちリプ」という考え方と厳密な意味でマッチしているかどうかは議論の余地があるところだろう。
  ⇒例えば、
  8:01に「おはっち」（ID:1）
  8:02にもう一度「おはっち」（ID:2）
  8:03にID:2に「おはっちリプ」（ID:3）
  8:04にID:1に「おはっちリプ」（ID:4）
  となった場合、
  ↑のロジックだと「ID:1の１番おはっちリプはID:4」「ID:2の１番おはっちリプはID:3」というように、
  ツイートごとの「１番おはっちリプ」を特定するよう動くわけだが、
  同一日付内という意味ではID:3が唯一無二の「１番おはっちリプ」であり、総合的にみてID:4は「２番おはっちリプ」というように見ることもできる、
  という意味である。
  そもそも”何をもって「１番おはっちリプ」と見做すのか”は最早ひなっち自身に委ねられており、論理的な定義は存在していない（という認識である）。
  単なる遊びに難しい話を持ち込んでも話が混乱するだけだから（そもそもこれも俺の”遊び”だ）、まあ今はこれで良しとしておこうかなと思った。
• たぶん俺が知らないだけでやり方があるのだろうが、「特定のツイートに対するリプ」というような切り口の探し方ができない。
  ↑に挙げたやり方も、「クエリ実行結果をＪａｖａで判断する」というなんとも微妙な実装である（できればすべてクエリに委ねたかった）。
  そして、これが「実現したい機能性２．」の大きな弊害の１つになっている。
  というのも、「実現したい機能性２．」では、「日付」と「おはっち」というキーワード、「リプ」という条件だけを与えて検索しているため、
  ↑で挙げたように１日複数回ひなっちがおはっちした場合に、「どのおはっちへのリプなのか」が即座に（クエリ実行段階では）判断できないのである。
  加えて、「searchの検索結果上限は100件まで」という制限のため、１日５０～６０件単位で「おはっちリプ」のつく現状を考えると、
  ひなっちが１日に２回おはっちした時点で、それぞれの「おはっち」に対する１番おはっちリプの特定は極めて困難になる。
  （ある日の「おはっち」のうち、１回目で５５件、２回目で５０件の「おはっちリプ」がつくと、同日内での「おはっちリプ」は１０５件になるので、１００件超えた先の５件分が検索できない）
  まあ「おはっちリプ」自体もツイートなので、それぞれにＩＤがついているわけだから、
  リプを辿るごとに手に入るＩＤをクエリのmax_idに指定して辿っていけば、１００件以上先もいけるっちゃいけるんだが、
  ＡＰＩの実行回数制限などもある中ではおよそ現実的な対応とは言えんだろう。
  これは割と心残りになっている部分である。ちょこちょこ追求していきたい。

といったところか。
細かいことを言うと、なぜか途中日のリプがまったく検索できない（結果が０件になる）とか、
API側が原因不明のよくわからん謎の動きをしている部分もあり、
実際に動かしてみた感じの感想では、理論的には問題なさそうでも、
決して精度の高い結果が得られるようなものではないというのが第一印象である。
残念なことだが、「個人の趣味」の範疇ではこの辺が限界かもしれない。
とりあえず、2017/7/21を基準に、直近の「おはっち」及び「おはっちリプ」をこのプログラムで検索した結果を以下に掲載する。

おはっちIDおはっちテキストおはっちタイムいいね！数おはっちリプ数１番おはっちリプタイムひなっちおはっちからの経過時間１番おはっちID１番おはっちユーザ名１番おはっちテキスト最終更新日時

「ひなっちおはっちからの経過時間」が10分を超えているものは、
何らかの理由で検索結果がすべて取得できていないために、「検索結果の中で一番若いＩＤのツイート」に相当するというだけで
プログラム都合上「１番おはっちリプ」にされてしまったデータであるといえる。
つまり、１番おはっちリプではない。
これは「おはっちリプ数」の数値の精緻さも同様である（信用してはならない）。
実際ひなっちのツイッターみて結果を照らし合わせてみると、それが明らかである。

「１番おはっちリプタイム」～「１番おはっちテキスト」までが空白になっているのは、
なんだかわからないがsearchの実行結果が０件になった日である（↑で言っていた内容）。
前後の日がちゃんと検索できているのに、特定の日だけが０件になるのは謎でしょうがない。
まあ前後が取れてるならいいか、ということで、深く考えないようにしてそっとしておく。

経過時間が６秒前後のリプは「１番おはっちリプ」として実態と合致しており、正しく判定ができているといえる。
むしろあまりにも６秒前後のリプが多くて疑いたくなるが（ツイッターのリプ反映が最少でも６秒おいてから行われるとかいう仕様があったりするんじゃねえのかみたいな疑り）、
この短期間の結果だけを見ると
ひなっちのおはっちに対する１番おはっちリプは、ひなっちがおはっちしてから大体６～７秒で行われる
というのが見て取れる。
逆に言えば、ひなっちのおはっちを見つけたら、６秒以内におはっちリプしないと１番が取れないということである。
ひなっちがおはっちするまでずーっと監視していればもっと早くおはっちリプするのも可能だろうが、そんなの実質不可能なので、
大抵の１番おはっちリプは、そのタイミングでツイッター見てた人が運よく見つけてリプした偶然の賜物なんだろう。

なお、今回実装したプログラムを少し改良すれば、
”無限ループしながら常に当日の「ひなっちのおはっち」を探し続け、 　結果が１件以上あったら＝ひなっちがおはっちしたら、
　「おはっち」という文言でひなっちのおはっちに対してリプする”
というプログラムもおそらく実装可能だ。
ＡＰＩの実行回数制限があるので間を空けずにsearchし続ける（監視を行う）ことは不可能だが、
５秒に１回なら回数制限にはひっかからないので、(15分で180回実行可能だから)
理論上最速5秒で１番おはっちリプができる。
直近の傾向を見るに6秒が最速のおはっちリプだから、
おそらく何度か試せば比較的高確率で１番おはっちリプを取り続けることが可能となるだろう。
（やらねーけど）

Twitter4jを使った基本的な実装の利用でこの辺のことが実現できるのはわかったが、
上述したように諸々の理由や実装背景等から決して精度の高い結果ではない。
もう少し詳細な実装ポイント等を抑えて再挑戦したいところである。