【2026年版】Twitter 検索コマンド：完全チートシート & API

要点： X（旧Twitter）の検索コマンドは、作者、日付、エンゲージメント、メディア、言語、そして場所でツイートをフィルターするキーワードと記号です。広いキーワード検索を正確なクエリに変え、2026年には50を超えるものが web で動きます。公式 X API v2 はサブセットのみをサポートします。

著者：Sorsa Editorial

2026年7月更新：すべてのコマンドを X のライブの検索の挙動と公式 X API v2 に対して再確認し、Sorsa の料金を現行の1,000件あたりのバッチレートに刷新し、100回分の無料リクエストの開始枠を追加しました。以前の改訂で、よく混同されるコマンドのセクションを追加し、壊れたコマンドのリファレンスを拡張し、深いページネーションのガイダンスを追加しました。

ほとんどのチートシートは、実際の作業に最も重要な部分を静かに飛ばします。最も価値の高いコマンドは、公式 X API v2 がサポートしない web 検索コマンドです。min_faves:、min_retweets:、豊かな since:/until: の日付構文、within_time:、そして filter:blue_verified はすべて x.com の検索ボックスで動き、すべて /2/tweets/search/recent によって静かに落とされます。代替の Twitter/X API である Sorsa API は、完全な web コマンドセットをその ツイート検索エンドポイント をまっすぐ通すため、本ガイドのすべてのコマンドは、ウェブサイト上だけでなく本番のコードで動きます。リソース単位ではなくリクエスト単位で課金し、エンドポイント別の窓なしにすべてのプランで一律の毎秒20リクエストで動き、開発者アカウントの承認を必要とせず、それがコマンド駆動のパイプラインが公式 API を後にする傾向のある理由です。

本ガイドは2人の読者のために作られています。ただ動くコピー＆ペーストのクエリが欲しいマーケターと、それらのクエリを規模で実行する必要のある開発者です。以下のすべてのコマンドは、何をフィルターするかで動く例とともにグループ化され、クックブックがそれらを14の実行可能なクエリパターンに変えます。

しかるべき功績のために、このリファレンスは、実世界のテストに加えて、Igor Brigadir によるコミュニティが維持する twitter-advanced-search リファレンス、文書化されていない X 検索の挙動の事実上の業界の情報源に基づいています。

目次

1. X 検索コマンドの仕組み
2. web コマンド対公式 X API v2 コマンド
3. キーワード、フレーズ、ブール論理
4. ユーザーとアカウントのフィルター
5. エンゲージメントのゲーティング
6. メディアとコンテンツタイプのフィルター
7. 日付、時刻、Snowflake ID
8. 地理的なフィルター
9. 言語とソースのフィルター
10. カードと URL のコマンド
11. 人々が混同するコマンド
12. クックブック：14の本番対応レシピ
13. Sorsa API でコマンドを使う
14. 複雑なクエリの構築：演算の順序
15. 2026年に壊れているか信頼できないもの
16. よくある質問

X 検索コマンドの仕組み {#how-x-search-operators-work}

X 検索コマンドは、結果セットをフィルターするためにクエリに付け加える小さなテキストのコマンドです。3つの場所で動きます。x.com の検索バー、TweetDeck、そして Sorsa のツイート検索エンドポイントのような、完全な web 検索の構文を通す任意のサードパーティ API です。構文はコロンの周りにスペースなしの operator:value で、コマンドは自由に組み合わせられます。

コマンドは2つの広いカテゴリに入ります。単体のコマンド は単独で使えます（たとえば from:elonmusk は有効な結果セットを返します）。連言必須のコマンド は少なくとも1つの単体のコマンドと並んで現れなければなりません。そうでなければ多くのコンテンツに一致しすぎるからです。この区別は web より公式 X API v2 で重要ですが、最初から理解しておく価値があります。

3つの普遍的なルール：

• AND は暗黙。 2つの用語を隣り合わせに置く（bitcoin etf）と両方を必要とします。
• OR は大文字でなければならない。 小文字の or はリテラルの語として扱われます。
• 除外は先頭のダッシュを使う。 crypto -scam は「scam」を含む結果を取り除きます。

これらを本番で使うつもりなら、Sorsa 検索ビルダー をブックマークします。それは、フィルターをビジュアルに切り替えさせ、完全なコマンドのカバレッジでコピーできるクエリ文字列を生成する、無料でログイン不要のツールです。コードに統合する前にクエリをプロトタイプする最も速い方法です。

web コマンド対公式 X API v2 コマンド {#web-operators-vs-official-x-api-v2-operators}

これがほとんどのチートシートが教えない単一の最も重要なことです。x.com で動く X 高度な検索の構文は、公式 X API v2 の検索エンドポイントがサポートするコマンドのリストのスーパーセットです。/2/tweets/search/recent の上に本番のパイプラインを構築し、それに min_faves:100 since:2026-01-01 filter:blue_verified を渡すと、それら3つのコマンドはどれも何もしません。それらはエラーではありません。静かに落とされます。

2024年以来いくつかの移行プロジェクトで、この正確なバグを見てきました。クエリは、ツイートを返すという意味では「動き」ますが、持っていると思ったフィルターはなくなっています。誰かが気づく頃には、ダッシュボードは何週間も間違っていたのです。

開発者が実際に気にするものについてのコマンドごとの比較はこうです。

実際の作業への最大の犠牲者は、エンゲージメントフィルター（min_faves、min_retweets、min_replies）と豊かな日付構文です。min_faves: なしには、API v2 側でバイラルまたは影響力のあるコンテンツを効率的に表面化できません。ツイートを取得してクライアント側でフィルターできますが、大量のクエリでは、すぐに捨てるツイートに枠を燃やすことになり、コスト差が速く複利で効きます。

そのコストのギャップは具体的です。公式 X API v2 はリソース単位で課金します。20投稿にその作者プロフィールを加えて返す単一の検索は、約$0.30かかります（各$0.005で20投稿読み取りに、各$0.010で20ユーザー読み取り）。Sorsa の Proプランでの同じ呼び出しは、各ツイートの作者プロフィールを追加料金なしで含んで、およそ$0.002の1リクエストです。公式 X API v2 はまた、クエリ文字列自体にハードな文字数制限を課します。セルフサーブの最近の検索で512文字、完全アーカイブで1,024、エンタープライズ層でのみ4,096です。一方 web 構文と Sorsa の通し抜けは、クエリあたりおよそ22〜23コマンドの実用的なコマンドの上限にのみ境界づけられます。投稿や DM の送信が必要なら、公式 API は依然としてそのためのツールです。完全なコマンドセットで公開データを読み検索するには、Sorsa のような Twitter/X API の代替 が、コマンド駆動の検索チームが切り替える理由です。

開示： Sorsa は当社の製品です。この比較を厳密に事実に留めました。欠けているコマンドのリストは、本記事が改訂された日に X 自身の公開のコマンドのドキュメントに対して検証可能です。トレードオフのより深い見方は、公式 X API からの移行ガイド をご覧ください。

キーワード、フレーズ、ブール論理 {#keyword-phrase-and-boolean-logic}

これらが構成要素です。すべての高度なクエリはここから始まります。

人々をつまずかせるいくつかの実用的な注記。 複数形はその単数に、逆も一致します。bulls は bull に一致します。X はときにありふれた語を静かにコンテンツの意図として再解釈するため、photo を検索すると、テキストに「photo」の語がなくても添付画像のあるツイートを返すことがあります。そのような語を二重引用符で包んでリテラルの一致を強制します。コマンドはツイートの本文に厳密には縛られてもいません。作者の表示名、スクリーン名、そしてツイートの中の展開された URL に対して一致でき、それが驚くべき結果の頻繁な原因です。

コマンド数の上限は実在します。単一のクエリでおよそ22〜23コマンドを越えると、X は文字列の末尾の部分を静かに無視し始めます。それより多くが必要なら、複数の API 呼び出しに分けて結果を下流でマージします。

ユーザーとアカウントのフィルター {#user-and-account-filters}

これらは、誰が投稿したか、誰に返信するか、または誰がメンションされるかでツイートをフィルターします。

ブランド監視のトリック。 @ または引用符のブランド名を -from: と組み合わせて、ブランド自身を除く全員がブランドについて言うことを見つけます。"Tesla" -from:tesla。その1つの手が、行動可能なシグナルと PR のノイズの違いで、ほとんどの ソーシャルリスニング のセットアップの背骨です。

メンション監視のより深い扱いは、メンションの追跡 のドキュメントをご覧ください。list: コマンドは、すべてのメンバーのツイートを1つのフィードに欲しいとき、X リスト API と自然に組み合わさります。

エンゲージメントのゲーティング {#engagement-gating}

最小（または最大）のエンゲージメントでフィルターします。これらはノイズを切り抜けバイラルなコンテンツを表面化するのに不可欠で、また公式 X API v2 に最も頻繁に欠けているコマンドです。

しきい値の設定方法。 低く（min_faves:10）始め、反復的に上げます。X の報告はおよそ1,000を超えると近似になるため、調整しすぎないでください。増幅ではなく自身のコンテンツでエンゲージメントを稼いだツイートだけが欲しいなら、-filter:retweets と組み合わせます。Sorsa 自身のパイプラインの作業では、min_faves:N に -filter:retweets に -filter:replies を加えた組み合わせが、オリジナルのバイラルコンテンツを表面化する単一の最も有用なフィルターです。他のすべては飾りです。

メディアとコンテンツタイプのフィルター {#media-and-content-type-filters}

X は、どの種類のコンテンツが結果に現れるかを異常に細かく制御します。落とし穴は、web コマンドセットが API v2 の相当物よりはるかに豊かなことです。

メディアフィルター

ツイートタイプのフィルター

特殊コンテンツのフィルター

日付、時刻、Snowflake ID {#date-time-and-snowflake-ids}

正確な時間ベースのフィルターは、イベント分析、キャンペーン追跡、過去のデータ抽出に不可欠です。ここが公式 X API v2 が最も鋭く分岐するところでもあります。start_time と end_time を別々のリクエストパラメータとして期待し、クエリ文字列の since: / until: を理解しません。web 構文と Sorsa は完全なセットをサポートします。

Snowflake ID のトリック

X 上のすべてのツイート ID は、その作成タイムスタンプをミリ秒精度でエンコードする Snowflake ID です。変換の式：

millisecond_epoch = (tweet_id >> 22) + 1288834974657

これは2つの理由で有用です。第一に、API 呼び出しをせずに任意のツイートの正確な投稿時刻を計算でき、それが時間で重複排除または順序付けするバックフィルのジョブに便利です。第二に、since_id: と max_id: が、結果の窓に日付レベルではなくツイートレベルの境界を与え、それは大量のキーワードを何時間もページネーションし、すでに見たツイートを再取得せずに正確に中断したところから再開したいとき非常に貴重です。

過去のツイートのセットを取得するより深い案内は、古いツイートを検索する ガイドをご覧ください。

地理的なフィルター {#geographical-filters}

ここを深く掘る前の現実のチェック：推定でツイートの1〜2%しか正確な位置情報のデータを運びません。X は2019年6月にメインの iOS と Android のアプリから正確な位置のタグ付けを削除し、ほとんどのユーザーはそもそもオプトインしませんでした。地理フィルターはまだ有用ですが、薄いカバレッジを見込みます。

構造化された API 側では、公式 X API v2 は異なる地理のセット、place_country:、point_radius:、bounding_box: を、web の near:/within:/geocode: のコマンドの代わりに使います。Sorsa は、x.com の検索ボックスで動くのと同じ web の地理コマンドを query フィールドを通じて受け付けます。API v2 の形は上の比較表に示しています。

有用なフォールバックの挙動。 ツイートが正確な座標を持たないなら、検索はユーザーのプロフィールの所在地の逆ジオコーディングにフォールバックするため、ツイートの実際の起源ではなく作者の述べた所在地に基づいて一致するツイートを受け取ることがあります。それはときに欲しいもので、ときに紛らわしいものです。オーディエンスがどこを拠点とするかを地図化するより高いカバレッジのアプローチは、国別のオーディエンス地理 をご覧ください。

言語とソースのフィルター {#language-and-source-filters}

言語

X は2文字の ISO 639-1 コードを使います。lang:en、lang:es、lang:fr、lang:de、lang:ja、lang:ru などです。知っておく価値のあるいくつかの非標準のコードもあります。

高シグナルの1つの用途：from:user lang:zxx filter:images は、画像でありそれ以外の何でもない、テキストのノイズがゼロのツイートを返します。ただし X の言語検出は完璧ではありません。短いツイート、コードスニペット、絵文字の多い投稿は日常的に誤分類されるため、重要なアプリケーションには、取得後に本文のテキストに自分の言語検出を実行します。

ソース（投稿クライアント）

よくある値：Twitter_for_iPhone、Twitter_for_Android、Twitter_Web_App、TweetDeck、twitter_ads。source: は結果を返すのにときに別のコマンドを並べて必要とすることに注意します。

カードと URL のコマンド {#card-and-url-operators}

これらは Twitter カードのメタデータに一致します。リンク、メディア、埋め込みコンテンツを含むツイートに付いた豊かなプレビューです。前もって知っておくべき2つのこと：card_name: は通常直近7〜8日間のツイートにのみ動き、url: はドメインにはよく動きますが長い URL のパスには信頼できません。

人々が混同するコマンド {#operators-people-mix-up}

ひと握りのコマンドが交換可能に見えて、そうではありません。これらが静かにデータセットを破損させるペアなので、それぞれについて正確であることに価値があります。

filter:verified 対 filter:blue_verified。 filter:verified は、レガシーの認証（ジャーナリスト、公人、2023年より前に認証された組織）を持ったアカウントに一致します。filter:blue_verified は、有料の X Premium に加入した誰にでも一致します。ほとんどのブランド監視と編集のクエリは、シグナルには filter:verified を欲しがり、支払っている任意のユーザーを含む filter:blue_verified ではありません。レガシーのアカウントをきれいに切り出すには、それらを組み合わせます：filter:verified -filter:blue_verified。

-filter:retweets 対 include:nativeretweets 対 -is:retweet。 -filter:retweets（web 構文）は、旧式の「RT」テキストリツイートとネイティブのリツイートの両方を除外します。include:nativeretweets は、デフォルトでそれらを除外する結果セットにネイティブのリツイートを戻します。-is:retweet は、リツイートを除外する公式 X API v2 の綴りで、歴史的に引用ツイートも掃き入れた filter:retweets より狭いです。web 側できれいなオリジナルコンテンツのセットには -filter:retweets を、1つのツイートがどこまで広がったかを追跡するには、きつい時間の窓で filter:nativeretweets を使います。

within_time:Xd 対 since:/until:。 within_time:7d は、クエリが実行される瞬間から測る時系列の窓なので、同じクエリが今日と明日で異なるツイートのセットを返します。since: と until: は固定の暦の境界です。再現可能な研究データセットには、within_time: よりつねに明示的な since:/until: の日付を好みます。

from:user 対 @user。 from:user はそのアカウントが書いたツイートのみを返します。@user は、他者からの返信と引用ツイートを含む、そのアカウントをメンションする任意のツイートを返します。タイムライン分析には from: を、メンション監視には @ を使います。ありふれた語のハンドルには、ノイズを切るために @ のクエリに lang:en か小さなエンゲージメントの下限を加えます。

filter:retweets 対 -is:retweet。 filter:retweets はリツイートに一致する web 構文で、-is:retweet はそれらを除外する API v2 の構文です。それらは完全な逆ではないため、web 側で増幅のあらゆる形を除外するには、-filter:retweets を -filter:quote と組み合わせます。

これらのコマンドは、インタラクションのタイプでツイートをフィルターします。ある与えられたツイートの背後の実際の返信、引用、リツイート者を取得することは別の仕事で、専用のエンドポイントで扱われ、Twitter エンゲージメント API ガイド で扱っています。

クックブック：14の本番対応レシピ {#cookbook-14-production-ready-recipes}

コマンドは単独で有用です。組み合わせで強力です。以下は、自分で構築したか、クライアントのパイプラインで見た14のクエリパターンです。それらをコピーし、変数を入れ替え、X の検索バーか Sorsa の検索エンドポイントにまっすぐ貼り付けます。

1. ブランドと評判の監視

ブランドについてのオリジナルのバイラルコンテンツを、ブランド自身の投稿とリツイートのノイズを除いて見つけます。

("Tesla" OR "Elon Musk") min_faves:500 filter:links lang:en -from:tesla -filter:nativeretweets

2. 競合のリード生成

自社のニッチで代替について積極的に尋ねているユーザーを見つけます。

("notion" OR "obsidian") "?" -filter:links -from:notionhq lang:en

3. 高意図の買い手の発見

製品カテゴリの購買シグナルのように読めるツイートを見つけます。

("looking for" OR "anyone use" OR "recommend") ("twitter api" OR "x api") -filter:retweets lang:en

4. インフルエンサーの発見

あるトピックの認証済みアカウントからの高エンゲージメントのオリジナル投稿。

"machine learning" filter:blue_verified min_faves:200 -filter:replies -filter:retweets lang:en

5. OSINT と速報

認証済みソースからの視覚的な証拠でリアルタイムのイベントを追跡します。

"breaking news" filter:images filter:blue_verified within_time:6h

6. X リストからのコンテンツキュレーション

特定のリストのメンバーが投稿したバイラルな動画を見つけます。

list:715919216927322112 (filter:videos OR card_name:animated_gif) min_retweets:50

7. 開発者のトラブルシューティング

GitHub にリンクするエラー関連の会話を見つけます。

url:github.com "error" lang:en filter:replies

8. エンゲージメントのゲーティング付きの暗号資産の感情

実質でフィルターした、あるトークンについての感情を帯びた会話を追跡します。

(bitcoin OR $BTC) (bullish OR bearish OR crash OR moon) min_faves:20 lang:en since:2026-01-01 -filter:retweets

9. 超ローカルの監視

きつい時間の窓の中で特定の場所の近くで言われていること。

"traffic" near:"London" within:5km since:2026-03-05_12:00:00_UTC

10. 特定のユーザーの引用ツイートを見つける

URL の形をパターン一致させ、ユーザー自身のハンドルを除外します。

twitter.com/elonmusk/status/ -from:elonmusk

11. オリジナルのみのスレッドリーダー

スレッドを始め（返信でもリツイートでもない）実際のエンゲージメントを稼いだツイートを見つけます。

"your topic" min_replies:10 -filter:replies -filter:retweets lang:en

12. 製品ローンチの窓を追跡

エンゲージメントの下限とともに特定の日付範囲のすべての会話を捕捉します。

"product name" since:2026-02-10 until:2026-02-17 lang:en min_faves:5

13. ゼロエンゲージメントのスパム検出

疑わしい低品質の投稿を特定します（モデレーションのパイプラインに有用）。

"buy now" -filter:has_engagement filter:links lang:en

14. 求人ボードの採掘

特定の技術的なニッチの採用シグナルのツイート。

("hiring" OR "we're looking for") ("react" OR "typescript") -filter:retweets lang:en min_faves:5

14すべてにまたがるパターン：トピックから始め、エンゲージメントを重ね、コンテンツタイプを重ね、それから除外を重ねます。除外が通常、ノイズの多い結果セットを使えるものから分けるものです。

Sorsa API でコマンドを使う {#using-operators-with-the-sorsa-api}

上に挙げたすべてのコマンドは、Sorsa の /v3/search-tweets エンドポイントの query フィールドで動きます。完全なクエリ文字列を POST リクエストのボディで渡し、next_cursor でページネーションし、429 を短いリトライで扱います。順序、ページネーション、結果の処理を巡るより広いワークフローは、API を通じてツイートを検索するガイド が端から端まで案内します。

curl での最小の呼び出し：

curl -X POST https://api.sorsa.io/v3/search-tweets \
  -H "ApiKey: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "query": "(AI OR \"machine learning\") min_faves:100 lang:en -filter:retweets",
    "order": "popular"
  }'

Python：ページネーションとリトライ付きの本番対応

これが本番で動かしているパターンです。完全な結果セットをページネーションし、レート制限でリトライし、ハードなエラーを表面化します。

import requests
import time
from typing import Iterator

API_KEY = "YOUR_SORSA_API_KEY"
BASE_URL = "https://api.sorsa.io/v3/search-tweets"


def search_tweets(query: str, order: str = "latest") -> Iterator[dict]:
    """
    Paginate through every tweet matching the query.
    Retries on 429 (rate limit) with a 1-second wait.
    """
    cursor = None
    while True:
        payload = {"query": query, "order": order}
        if cursor:
            payload["next_cursor"] = cursor

        response = requests.post(
            BASE_URL,
            headers={"ApiKey": API_KEY, "Content-Type": "application/json"},
            json=payload,
            timeout=30,
        )

        if response.status_code == 429:
            time.sleep(1.0)
            continue

        response.raise_for_status()
        data = response.json()

        for tweet in data.get("tweets", []):
            yield tweet

        cursor = data.get("next_cursor")
        if not cursor:
            break


# Usage: collect viral AI tweets from January 2026
for tweet in search_tweets(
    '(AI OR "machine learning") min_faves:1000 lang:en '
    'since:2026-01-01 until:2026-02-01'
):
    print(tweet["id"], tweet["likes_count"], tweet["full_text"][:80])

JavaScript / Node.js：非同期イテレーターのパターン

const API_KEY = "YOUR_SORSA_API_KEY";
const BASE_URL = "https://api.sorsa.io/v3/search-tweets";

async function* searchTweets(query, order = "latest") {
  let cursor = null;

  while (true) {
    const payload = { query, order };
    if (cursor) payload.next_cursor = cursor;

    const res = await fetch(BASE_URL, {
      method: "POST",
      headers: { ApiKey: API_KEY, "Content-Type": "application/json" },
      body: JSON.stringify(payload),
    });

    if (res.status === 429) {
      await new Promise((r) => setTimeout(r, 1000));
      continue;
    }
    if (!res.ok) throw new Error(`Sorsa API error: ${res.status}`);

    const data = await res.json();
    for (const tweet of data.tweets ?? []) yield tweet;

    cursor = data.next_cursor;
    if (!cursor) break;
  }
}

// Usage
for await (const tweet of searchTweets(
  '"product launch" min_faves:50 lang:en since:2026-02-10'
)) {
  console.log(tweet.id, tweet.likes_count);
}

深いページネーションは信頼できない：代わりに日付でチャンク分割する

大量の過去の取得で計画しておくべき1つのこと：X の検索のページネーションは、深い結果セットには不安定です。これは、すべてのアクセス経路が継承する上流のプラットフォームの挙動で、1つの API の癖ではありません。単一のカーソルチェーンの最初の十数ページを過ぎると、結果セットが尽きるずっと前に、重複が見え始めるかチェーンが早く止まります。

対処法は、1つの長いカーソルチェーンに頼るのをやめ、代わりにクエリを日付範囲のチャンクに分けることです。since: と until: で境界づけられたいくつかの小さなクエリを実行し、各チャンクをそれ自身の新鮮なカーソルでページネーションします。

from datetime import date, timedelta


def chunked_search(query_base: str, start: date, end: date, chunk_days: int = 7):
    """Split a long date range into weekly chunks, each with its own cursor chain."""
    current = start
    while current < end:
        chunk_end = min(current + timedelta(days=chunk_days), end)
        full_query = (
            f"{query_base} since:{current.isoformat()} until:{chunk_end.isoformat()}"
        )
        yield from search_tweets(full_query, order="latest")
        current = chunk_end


# Q1 2026, week by week, no deep-cursor instability
for tweet in chunked_search(
    'openai min_faves:200 lang:en', date(2026, 1, 1), date(2026, 4, 1)
):
    print(tweet["id"])

1週間でさえ広すぎる速く動くイベントには、完全なタイムスタンプの形（since:2026-03-01_12:00:00_UTC until:2026-03-01_13:00:00_UTC）を使って時間単位のチャンクに落とします。各チャンクは再現可能で再開可能で、それはローンチやニュースイベントのタイムラインを再構築するとき重要です。ツイートを検索するのではなく特定のツイートをスナップショットする必要のあるアーカイブのパイプラインには、tweet-info-bulk エンドポイント がリクエストあたり最大100件のツイート ID を取ります。

複雑なクエリの構築：演算の順序 {#building-complex-queries-order-of-operations}

5つか6つのコマンドを積み重ね始めると、それらが評価される順序が重要になり始めます。X のルールはほとんどの検索エンジンと同じです。AND は OR より強く結びつきます。

つまり cat OR black dog は (cat OR black) dog ではなく cat OR (black dog) として評価されます。2つ目の解釈が欲しいなら、括弧で囲みます：(cat OR black) dog。疑わしいときは括弧を使います。何もコストはかからず、曖昧さを取り除きます。

ほぼすべてのクエリで動く構築の順序：

1. コアのキーワードをグループ化 して括弧に：(bitcoin OR ethereum OR $BTC)
2. コンテンツの制約を加える： lang:en、filter:images、-filter:replies
3. エンゲージメントのしきい値を設定： min_faves:50、min_retweets:10
4. ノイズを除外： -from:spambot、-scam、-airdrop、-filter:retweets
5. 必要なら時間の境界を加える： since:2026-01-01 until:2026-03-01

この順序に一貫して従えば、どのクエリもひと目で読め、ミスをより速く見つけられます。

2026年に壊れているか信頼できないもの {#what-is-broken-or-unreliable-in-2026}

コマンドは X で静かに失敗します。クエリは依然としてツイートを返すため、壊れたフィルターは、データがすでに間違うまで動くもののように見えます。これらが、噛まれる前に知っておく価値のある故障モードです。

もはや名前が示唆するように振る舞わないコマンド：

よくある「私の検索が動かない」状況と実際に起きていること：

• 「最新」ではなく「話題」にいる。 デフォルトの「話題」タブはアルゴリズムの選択を見せてほとんどの一致を隠し、それが欠けた結果のように読めます。完全なカバレッジには、「最新」タブに切り替えるか、API で order: "latest" を渡します。
• 引用符の完全一致フレーズの検索が何も返さない。 引用符は完全なトークンの一致を強制しスペル修正を無効にするため、X が完全な一致を持たないフレーズは空で返ってきます。緩めるには、引用符を取り除くか、ワイルドカードの形 "word * word" を使います。
• from: が何も返さないかゴミを返す。 最もよくある原因はコロンの後のスペースです。from:username と書き、決して from: username とは書きません。スペースがコマンドを壊すからです。2番目によくある原因は、アカウントが投稿しなかった日付範囲です。
• geocode: または near: がほとんど何も返さない。 地理のカバレッジは2019年以降崩壊しました。位置の作業には、プロフィールの所在地のフォールバックに頼るか、ツイートレベルの座標ではなくオーディエンスがどこを拠点とするかを国別に分析します。
• クエリが x.com で動いたが公式 X API v2 で動かなかった。 ほぼつねに API が静かに落とす web 専用のコマンドです。上の web 対 API v2 の比較表 をご覧ください。

さらにいくつかの持続的な落とし穴：

• コマンドの上限： クエリはおよそ22〜23コマンドをサポートします。それを越えると、クエリの末尾の部分が静かに無視されます。
• 非公開と停止されたアカウントは、すべての検索結果から除外されます。 どのコマンドの組み合わせもそれらに到達しません。
• すべてのツイートがインデックスされているわけではありません。 プラットフォームまたは不正防止の理由でフラグ付けされた投稿は、技術的にはまだ稼働していても検索から除外されます。これは、エンゲージメントがブロックされたアカウントを追うときの既知のギャップです（関連する文脈は Twitter「このリクエストは自動化されているように見えます」のエラー の記事をご覧ください）。
• 自動修正が一部のケースで静かに起こります。 完全一致を強制するには +word か "word" を使います。
• URL の一致は脆いです。 ドメインとサブドメインは動き、長い URL のパスは動かず、ドメインのハイフンはアンダースコアに置き換える必要があります（url:t_mobile.com）。

実践

協力したおよそ12人のソーシャル分析チームは、公式 X API v2 の上にブランド監視のダッシュボードを構築していました。このチームのクエリは min_faves: と filter:blue_verified を使って、人間の返信に値する高シグナルのメンションだけを表面化しました。API v2 では、その両方が静かに落とされる web 専用のコマンドなので、何週間も「トップメンション」のパネルはすべての低エンゲージメントのメンションを取り込み、優先順位付けは事実上ランダムでした。誰もエラーを見ませんでした。エラーがなかったからです。同じクエリ文字列を完全な web コマンドセットを受け付ける検索 API に移すことが、どのフィルターのロジックも書き直さずにそれを修正し、そして課金がリソース単位ではなくリクエスト単位なので、同じ監視の量が投稿読み取り単位の公式の料金の小さな何分の1かかかりました。故障が見えなかったのは、まさに壊れたコマンドが、公式 API がそもそもサポートしなかったものだったからです。

よくある質問 {#faq}

X 高度な検索とは？

X 高度な検索は、作者、日付、エンゲージメント、メディアタイプ、言語、そして場所でツイートをフィルターするプラットフォームの組み込みの方法です。x.com/search-advanced でフォームとして利用できるか、同じコマンドをどこからでも検索バーに直接打ち込めます。構文を知れば、コマンドを打ち込むほうがフォームを埋めるより速いです。

Twitter を日付でどう検索する？

Twitter を日付で検索するには、since:YYYY-MM-DD と until:YYYY-MM-DD を1つのクエリで組み合わせます。たとえば "product launch" since:2026-02-10 until:2026-02-17 です。since: の日付は含み、until: の日付は含まないため、ツイートは until の日付にではなく、その前に投稿されていなければなりません。日未満の精度には、タイムスタンプの形 since:2026-02-10_14:00:00_UTC を使います。

なぜ私の検索コマンドが公式 X API で動かない？

min_faves:、min_retweets:、since:、until:、within_time:、filter:blue_verified、card_name: のようなコマンドは、公式 X API v2 がサポートしない web 検索コマンドです。エラーを返す代わりに静かに無視します。Sorsa の検索エンドポイントは完全な web コマンドセットを受け付け、それがエンゲージメントでフィルターまたは日付で区切ったパイプラインを動かすチームが公式 API から移る理由です。

X アカウントなしで古いツイートをどう見つける？

X は2026年に、基本の検索バーを含むほとんどの検索にログインを必要とします。2つの選択肢が自分のアカウントなしで動きます。すでに持っている特定のツイート URL のためのインターネットアーカイブの Wayback Machine か、公開の検索インデックスへの自身のアクセスを維持する Sorsa のようなサードパーティの Twitter/X API で、それは過去の結果を構造化された JSON として返します。

filter:retweets と -is:retweet の違いは？

filter:retweets はリツイートに一致する web 検索の構文で、-is:retweet はそれらを除外する公式 X API v2 の構文です。それらは正確な逆ではありません。filter:retweets は歴史的に旧式の「RT」リツイートと引用ツイートの両方を含み、一方 API v2 の is:retweet はより狭いです。web 側で増幅のあらゆる形を除外するには、-filter:retweets -filter:quote を一緒に使います。

1つのクエリで何個の検索コマンドを組み合わせられる？

X は単一のクエリでおよそ22〜23を超えるとコマンドを静かに無視し始めるため、長すぎるクエリの末尾の部分はエラーなしで落とされます。公式 X API v2 はまた、クエリ文字列自体を、セルフサーブの最近の検索で512文字、完全アーカイブで1,024、エンタープライズ層でのみ4,096に制限します。

完全な検索コマンドのセットをサポートする Twitter/X API はある？

はい。公式 X API v2 は検索コマンドのサブセットのみをサポートしますが、Sorsa のツイート検索エンドポイントは、min_faves:、since:/until:、そして filter:blue_verified を含む完全な web コマンドセットを通します。エンドポイント別の窓なしと開発者アカウントの承認なしにすべてのプランで一律の毎秒20リクエストで動き、各ツイートの作者プロフィールを追加コストなしで返します。

監修：Keksich（Sorsa創業者、マーケター兼X APIリサーチャー）

情報源とこれをどう確認したか {#sources-and-how-we-checked-this}

本ガイドは、代替の Twitter/X API をビルドして運用する Sorsa 自身の実地の作業（2022年以来50億を超えるリクエストを処理）、稼働中のツイート検索エンドポイントに対してテストしたもの、加えて Igor Brigadir によるコミュニティが維持する twitter-advanced-search リファレンス と公式 X API v2 のコマンドのドキュメントに基づいています。ここに挙げたすべてのコマンドは、2026年6月に X の現行の検索の挙動に対して再確認し、web 対 API v2 の違いは、この改訂の日に X 自身の公開されたコマンドのリストに対して確認しました。コマンドのリファレンスは、エンドポイントのリファレンスと並べて欲しいなら Sorsa のドキュメントにもあります。

始め方 {#getting-started}

このチートシートを働かせる最も速い方法：

1. 検索ビルダーを開き、クエリをビジュアルに組み立てます。ログインなし、構築にレート制限なし。
2. Sorsa Playground でそれを実行し、JSON と CSV のエクスポートでライブの結果を見ます。
3. スクリプト化の準備ができたら、クエリを上の Python または JavaScript の例に落とし込み、API キーで 検索エンドポイント を呼びます。すべてのアカウントは100回分の無料リクエストで始まります。1回限り、クレジットカード不要、40個のエンドポイントすべてで有効、最大10,000ツイートまたは20,000プロフィールに十分です。まだキーを作っていないなら、クイックスタート がキーの作成を案内します。

公式 X API v2 から来て、静かに何もしないコマンドに疲れましたか。移行ガイドが違いをエンドポイントごとに対応付け、バッチエンドポイントで Sorsa は1,000ツイートあたり$0.02、1,000プロフィールあたり$0.01から、審査待ちなしの一律の毎秒20リクエストのレート制限で動作します。完全な 料金 は公開です。