17いいね！
読み込み中...はじめに
世界中のPROGRESSの皆様、おはこんばんちは！フラーシア所属（だけど診断結果はラグ寄りのアリス）の石井理（いしいさとる）です。
いつもTwitter Checkerをご愛顧くださいまして、ありがとうございます。
本当に嬉しいことに、たくさんの方々にご利用していただいているのですが、その反面、Twitter社提供のAPI（データベースの窓口のようなもの）の使用制限回数を超えてしまって、正常に動作しないケースが発生しています。
その場合、最大15分お待ちいただくと正常に動作するはずです。ご不便をおかけしてしまい申し訳ないですが、よろしくお願いいたします。
というか、これまであまり、Twitte Checkerがどういう原理で動いているのかをご説明していなかったので、まず、その点について簡単に（怖い、寝たい、にならないように簡単に）説明させてください。
Twitter Checkerが利用している「API」について
Twitter Checkerは各アカウントのフォロー・フォロワーについての情報を表示するプログラムですが、自力で情報をかき集めているわけではありません。Twitter社のデータベースからデータをもらうことによって動作しています。技術的にいえば、Twitter社が提供しているAPIを通じてリクエストしています。
で、ここがネックになるのですが、それは15分間に15回という回数制限があります。それを上回る数のリクエストを送ると、APIエラーという形で返ってきてしまい、欲しい情報がもらえなくてTwitter Checkerとしては期待される結果が表示できないという流れになってしまいます。
簡単にいうと、Twitter社の玄関に立っている、たったひとりのペッパー君に「データ頂戴！」「データ頂戴！」「データ頂戴よ！」と矢継ぎ早に要求し続けていたら、突然「こっちは世界中を相手にしてんだから、ちょっと待ってなさいよ！」と怒られる…という仕組みなわけです。
「ロボットなのにオコなの？」と思いますが、ドラえもんみたいで可愛いですね。というかペッパー君はテンパっても布団やヤカンを投げつけてはこず、ただただ粛々とエラーメッセージのみを返してきます。
対応
そこで、Twitter Checkerでは、以下のような対応をしています。
・API回数制限オーバーの時にメッセージを表示するようにしました
・実行ログを取り、どういう場合にAPI制限オーバーが起こりやすいのかを調べてみています
・その上で、ちょっとだけお願いがあります
API回数制限オーバー時のメッセージ表示
まずひとつめ。Twitter APIからエラーメッセージを受け取ったときに、このような画面で「APIエラーです、少々お待ちください」という表示が出るようにしました。
この場合、最も簡単な方法は、上述のように「待つ」ということなのですが、それだけだと単なる対症療法的な処置に終わってしまい、根本的な問題把握および解決にはつながりません。
実行ログについて
そこで、このたび、Twitter Checkerを実行してくださったタイミングで逐一ログをとるようにし、APIエラーがいつ、どれくらいの頻度で発生しているのかを調べてみています。
もちろん、ログと言っても、個人情報は取得しておりませんので、ご安心ください！
取得しているデータは、①実行日時、②実行アカウント名を暗号化した文字列、③実行結果（成功 or APIエラー）の３つだけです。
重要なのは②で示したように、実行アカウント名が暗号化されているという点です。つまり、製作者の僕ですら、ログを見てもどなたのことなのか分からない仕様にしてあります。
お願い
さて、今回の記事では、ログを取りはじめて１週間が経過したので、その分析結果を踏まえて、少しだけお願いしたいことがあります。
- APIエラーの場合は少々お待ちください
- 短時間内の連続実行はお控えください
- 日曜22時を避けてみてください
このあと、一つずつ、データを元にご説明いたします。
詳細（分析結果と考察）
「APIエラーの場合は少々お待ちください」について
何度も書いておりますが、この場合は、最大15分で回復します。待ち時間にはpublicのコラムを1、2個読むのがおすすめです。コインランドリーでの洗濯中に週刊少年ジャンプを読み切るような感覚でお待ちください。
「短時間内の連続実行はお控えください」について
APIエラー発生の原因として改善できそうなものに、一人の使用者の連続実行が原因でAPIエラーにつながるパターンがあります。
典型的なケースとして、少しだけログをご覧いただくとご理解いただけるかと思います。
まずひとつめのケースは、どなたかが13回ほど連続で実行していたら、途中からAPI制限オーバーになってしまった事例です。
（このように誰が実行したらわからない形で管理しています）
続いて、最初の方が連続実行した際には問題なかったのだけれど、次の方からAPI制限オーバーにひっかかってしまったパターンです。
ただし、これらのケースについてどなたかを責めるつもりは全くありません。むしろ、これまでAPIの仕様についてしっかりとご説明差し上げていなかった僕のせいです。ご不便おかけして申し訳ないです。
今後は、一度表示されたチェック結果画面を閉じずに置いておいて、各アカウントに対する確認やらなんやらの作業をしていただくよう、お願いいたします。
「日曜22時を避けてみてください」について
これについては、「日曜22時を避けてみてください」とはしていますが、混み合いやすいおおよその時間帯だけでもわからないかなーと分析してみたところ、とりあえず今週は「日曜22時」だったという話です。
なので、来週もそうであるということはできないので、もしもこれで改善されたら嬉しいなぁ…というくらいのお願いです。
一応、根拠となるデータも示しておきます。
まず1週間分のデータを時間ごとに重ねたグラフを見てみると、22時代が実行回数もエラー出現回数も最も多いという時間帯でした。
これだけだとあまりにざっくりなので、日別のグラフも見てみると、こんな感じでした。
実行回数が最も多いもは9月3日（金）でしたが、APIエラーはそれほど多くありませんでした。
それに対してAPIエラー数が最も多いのは9月5日（日）でした。実行総数がそれほど多くないのにもかかわらず最多なのはなぜだろうという事で、当該日の時間別グラフを見てみると、なぜか22時台にだけ集中して実行されていたのが分かります。
ということで、これ以上の原因・理由についてはよくわからないのですが、今週は日曜日の22時前後はAPIエラーが多発した（短い時間内に混み合った）という事実をもとに、来週はちょっと避けてみましょうかねぇというだけのご提案です（あくまで予測であって、絶対ではありませんので、参考までに）。
なお、まだログを取り始めた段階なので、もう少しデータが溜まるまで、きちんとした傾向は得られづらいのかもしれません。というか、僕はデータ分析のプロではないので、もっと上手に分析できる方がいらっしゃったら、助けてください！
おわりに
というか、ログを取ってみた結果、１週間に1,031回も実行されていることがわかって、ツール制作者として、とてつもない満足感と自己肯定感をいただいています。本当にありがとうございます！
ではまた！