約7分で読める記事です。ポイントをギュッとまとめましたので、ぜひ最後までどうぞ！
目次
2026年10月6日ごろから、Xの検索「最新」タブが20〜40件ほどで読み込みを止めるようになりました。検証した人の報告では、投稿そのものは消えておらず、Xのサーバーが「ここで終わり」と画面に伝えているだけだと分かっています。私がいちばん引っかかったのは、不便さよりもこの点です。エラーが出ないので、止まっていることに気づかないまま数を数え続けてしまう。キャンペーンの投稿数を検索画面で数えている方にとっては、静かに数字が狂う変化です。
この記事では、何が起きているのかを整理したうえで、検索を作る側から見たこの制限の意味と、効果測定を画面に頼らない形へどう移していくかを考えてみます。
ハッシュタグやキーワードで検索し、「最新」タブを下へスクロールしていくと、あるところでぴたりと読み込みが止まります。アプリ情報サイトのSBAPPの検証によると、投稿の多い言葉では40件前後、投稿の少ない言葉では20件ほどで止まるそうです。ウェブ版とiOS版で起きており、Android版でも同じ報告が出ています。
SBAPPはウェブ版の通信の中身も確かめています。止まる地点で、サーバーから「TimelineTerminateTimeline」という、下方向の読み込みを終わらせる指示が返ってきていました。さらに、ブラウザ側でこの応答を書き換えると、40件より先の投稿も読み込めたそうです。つまり投稿は存在しています。止めているのはXのサーバー側で、画面が「これで全部です」と言っている状態です。
なぜこの制限が入ったのか、執筆時点（2026年10月7日）でXからの説明は見当たりません。負荷対策ではないかという見方もありますが、推測の域を出ないので、ここでは理由を決めつけないでおきます。
私は以前、3000万件規模のデータを扱う検索エンジンを作っていたことがあります。その立場から見ると、検索結果を途中で打ち切るという判断そのものは、珍しいものではありません。
検索の仕組みは、先頭の数十件をできるだけ速く返すように作られています。奥のページへ進むほど、1件を返すための手間は増えていきます。たとえば広く使われている検索ソフトのElasticsearch（エラスティックサーチ）は、初期設定で1万件より深い位置の結果を返さないようになっています。深い位置の結果を返すには、その手前の結果もすべて並べ直す必要があり、件数が増えるほど負担が大きくなるからです。
だからといって、Xがこの理由で制限を入れたと言いたいわけではありません。意図はXにしか分かりません。ただ、作る側の感覚として言えるのは、画面の検索は「全件を取り出すための道具」として作られていない、ということです。人が目で追える範囲の結果を、速く、気持ちよく返すための道具。そう考えておくほうが、今回のような変化に驚かずに済むと思っています。
キャンペーンのハッシュタグがどれくらい投稿されたかを、検索画面をスクロールして数えるやり方は、今も広く使われていると感じます。手軽で、費用がかからず、誰でもすぐにできるからです。小さなキャンペーンなら、それで十分に回ってきました。このやり方を選んできた担当者を責める話ではありません。
ただ、今回の制限で、その数え方は40件で頭打ちになります。実際には300件投稿されていても、画面には40件しか出てこない。そのまま報告書に「投稿数40件」と書いてしまうおそれがあります。
ここで大事なのは、問題の本体が今回の不具合ではないという点です。画面で数えるという方法は、もともと数え方の正しさをXの表示の都合に預けていました。表示の仕様が変われば、数字も黙って変わる。今回は、その前提が目に見える形で表に出ただけだと私は見ています。
いま有効とされているのが、検索コマンドの since:（この日から）と until:（この日まで）で期間を区切る方法です。たとえば「#キャンペーン名 since:2026-10-01 until:2026-10-02」と入れると、1日分だけが検索の対象になります。1回の検索に出てくる件数が20〜40件を下回れば、取りこぼしは減ります。
当面の応急処置としては、この方法をおすすめできます。ただし、1日の投稿が数百件を超えるようなキャンペーンでは、時間単位まで細かく刻んでも、手作業では追いきれなくなります。数え漏れも出やすくなります。数日で終わる小さな施策なら回りますが、何週間も続くキャンペーンで毎日これを続けるのは現実的ではないと感じています。
もう一つの選択肢として、SBAPPはYahoo!リアルタイム検索を挙げています。Xの投稿を外から検索できるサービスで、ハッシュタグの動きをざっと追うには便利です。ただし、こちらもXとは別の会社のサービスなので、件数をきっちり数える用途に向いているかは、使い方しだいです。
件数を正確に残したいときは、X API（プログラムから投稿データを受け取るためのXの公式窓口）や、それを使った集計ツールで取る方法があります。APIは画面とは別の経路なので、今回の表示の打ち切りとは関係なくデータを受け取れます。
一方で、APIには費用がかかります。Xは2026年に料金体系を従量課金に切り替えており、投稿を1件読み込むごとに料金が発生する仕組みです。また、APIの通常の検索で取れるのは直近の一定期間に限られるため、キャンペーンが終わってから慌てて取りにいくと、古い投稿に手が届かないこともあります。数えたい施策は、期間中に取っておく前提で準備しておくと安心です。
では、どこで画面からAPIやツールへ切り替えるのか。私は、その数字を報告書に書いて誰かに説明するかどうかが境目だと考えています。社内でざっくり傾向を見るだけなら、画面で十分です。でも、クライアントへの報告に載せる数字や、次の予算を決める材料になる数字なら、画面の都合で変わらない方法で取っておきたい。数字の重さに合わせて、数え方を選ぶということです。
Xの検索が不安定になったのは、今回が初めてではありません。2026年3月ごろには、「最新」タブに検索した言葉とは関係のない外国語の投稿が大量に混ざる、という別の不具合が報告されていました。今回は「件数が減る」という量の問題、3月は「関係のない投稿が混ざる」という質の問題です。中身は違っても、どちらも画面の検索に頼った運用を揺さぶった点は同じです。
プラットフォームの画面は、プラットフォームの都合で変わります。それを止めることは、私たちにはできません。
Xの検索「最新」タブが20〜40件で止まる現象は、投稿が消えたのではなく、サーバーが画面に「ここで終わり」と伝えていることで起きています。当面は since: と until: で期間を刻めば取りこぼしを減らせますが、投稿の多いキャンペーンでは手作業に限界があります。報告や予算判断に使う数字は、APIやツールなど画面以外の方法で、キャンペーン期間中に取っておくのが確実です。
仕様の変化に振り回されないために、私が大事にしたいのは「画面に見えている数」と「実際にある数」を分けて考えることです。画面はプラットフォームが見せたいものを見せる場所で、記録を残す場所ではありません。大事な数字ほど、画面の外に残しておきたいと思っています。
