検索カードが、カレンダーの帯と収集元の投稿カードにつながっています。

選択の出発点は、何を収集する必要があるかです。確認用に少数の投稿を集める場合と、条件に一致するすべての投稿を集める場合では、必要な設定が異なります。同じキーワードと日付を使う場合でも、収集の成功を示すために必要な証拠は異なります。

この比較記事はChronometricaが公開しています。2026年10月20日に確認した公開の製品資料に基づいています。この記事のための収集実行は行っていません。推奨の根拠は、ドキュメントに記載された入力と出力です。速度、費用、網羅性、正確性、信頼性での優位性を主張するものではありません。

Actorとは、ホスト環境で動作する収集プログラムです。この比較で重要なのは、指定した日付範囲のキーワードサンプルを採用するために必要なフィルターと記録を、どちらのActorが提供するかです。

採用するサンプルの要件で選ぶ

公開されている購入希望者の依頼には、特定の期間のXデータをキーワードで収集したいという要望があります。これは、日付範囲を指定して収集する需要を裏付けます。ただし、過去の全投稿を網羅するアーカイブや、条件に一致するすべての投稿の正確な件数が必要だとは示していません。ここで取り上げる製品の組み合わせは、編集上の判断で選んだものです。この依頼は、検証済みの製品ベンチマークではありません。公開されている購入希望者の依頼

Actorを選ぶ前に、サンプルの採用条件を短く書きます。たとえば、「各キーワードについて、日付が分かる投稿を最大10件収集したい。各サンプルを確認できるだけの検索情報も必要」とします。これが実用的な判断基準になります。入力で要望を表現できるか、出力に確認用の証拠が残るかを確認できます。

採用するサンプルの要件で選ぶ
判断項目Chronometrica X Search ScraperApidojo Tweet Scraper V2
キーワードと日付による検索開始日と終了日を含む暦日の専用入力キーワード検索と開始・終了の設定
確認できた適性明示的なクエリ記録と行の位置を伴う、件数を限定したサンプルより幅広い明示的なフィルターが必要な検索
関連する設定クエリ数は1~20、クエリごとの保存行数は1~1,000高度な構文、投稿者・メディア・場所・エンゲージメント・言語のフィルター、クエリウィザードによるフィルター
選択基準サンプル件数の上限とクエリ記録が調査の要件を満たす場合に選ぶこれらのフィルターでサンプルを定義する場合に選ぶ

この表は、確認した公開ドキュメントをまとめたものです。記載のない機能を、存在しないものとして扱ってはいません。キーワードと日付による絞り込みは、両製品に共通する機能です。Chronometricaのドキュメント · Apidojoのドキュメント

Apidojoのドキュメントにある大規模収集の方針では、単一ツイートの取得を対象外としています。この制限は、複数の結果を取得する今回の検索の選択には影響しません。Apidojoのドキュメント

Chronometricaの主な制限は、保存行数の上限です。条件に一致するすべての投稿が必要で、いずれかのクエリで保存行数が1,000を超える場合、Chronometricaはその要件を満たしません。上限未満の依頼でも、網羅性を示す証拠は必要です。入力可能な件数であることは、収集元が条件に一致するすべての投稿を返す証明にはなりません。Chronometricaのドキュメント

Chronometricaが件数を限定したキーワードサンプルに適する理由

Chronometricaは、保存した行の検索情報を保持します。`inputQuery`には、指定したクエリを記録します。`executedQuery`には、生成された正確なクエリを記録します。`searchMode`には、選択したモードを記録します。`resultPosition`には、そのクエリ内で観測した行の位置を記録します。これらのフィールドにより、保存した投稿を、その投稿を取得した検索に結び付けられます。Chronometricaのドキュメント

キーワードを比較するときは、この結び付きが重要です。2つのクエリで同じ日付範囲と行数上限を使っても、採用できる行数は異なる場合があります。実行結果はクエリごとに分けて保持します。そうしないと、まとめたエクスポートでは、どのクエリが上限に達し、どのクエリの行数が少なかったかが分からなくなることがあります。

Chronometricaは、クエリごとの`OUTPUT`集計についても記載しています。これは、各クエリについて報告される実行結果です。保存した行と併せて確認します。行を保存したファイルからは、収集した内容が分かります。クエリの実行結果は、その収集が依頼を満たしたかを判断する助けになります。Chronometricaのドキュメント

`resultPosition`は、この文脈の中だけで使います。これは、1つのクエリでの観測値です。固定の順位や品質スコアではなく、その投稿が話題を代表する証拠でもありません。サンプルの順序を確認するために保持します。投稿の重要度を測るためには使わないでください。Chronometricaのドキュメント

この仕組みは、投稿を読んだり、ラベルを付けたり、比較したりするために、件数を限定して収集したい研究者に適しています。記録があれば、何を観測したかを説明しやすくなります。ただし、その観測が予定する分析を裏付けるかどうかは、研究者自身が判断する必要があります。

収集前に日付範囲を明確にする

Chronometricaでは、省略可能な`startTime`と`endTime`に、開始日と終了日を含む暦日を入力できます。ドキュメントに記載された処理では、確認可能な日付フィルターを追加し、返された投稿の日付を再確認します。同じ専用日付入力を使う依頼に、`since:`や`until:`演算子を追加しないでください。Chronometricaのドキュメント

開始日と終了日を含むとは、指定した両方の暦日が依頼の範囲に入るという意味です。ただし、調査のタイムゾーンを定義する必要はなくなりません。暦日だけでは、現地時間での集計日にどの時間帯が含まれるかは分かりません。

検索を実行する前に、使用するタイムゾーンを記録します。必要に応じて、意図した開始時点と終了時点を協定世界時(UTC)に変換します。UTCは、タイムスタンプを比較するための共通の時刻基準です。調査対象の日付について、変換が正しいかを確認します。返された投稿を調べるときは、確認済みのタイムスタンプを使います。

依頼の2つの情報を一緒に保持します。元の、開始日と終了日を含む暦日指定と、行の採用判定に使う正確なタイムスタンプ範囲です。これにより、別の読者も入力内容と、投稿を調査対象に含めるかどうかの判断を理解できます。

最初の確認では、日付の指定方法を1つ選びます。専用の日付入力で要望を表現できる場合は、それを使います。代わりに高度なクエリ演算子を使う場合は、結果を採用する前に、生成されたクエリを確認します。クエリへの影響を確認せずに、両方の方法を併用しないでください。

日付を確認する方法の全体像は、キーワードと日付でXの投稿を検索する方法を参照してください。この比較で扱うのは製品の選択です。どのActorのフィルターと出力記録が、収集要件に合うかを判断します。

確認できる小規模な入力を用意する

Chronometricaのドキュメントには、クエリ数1~20、モード`latest`、`top`、`photos`、`videos`、クエリごとの最大保存行数を1~1,000に設定できることが記載されています。保存したすべての行を確認できるよう、小さい上限から始めます。Chronometricaのドキュメント

次の入力は、2026年1月を対象に、1つのキーワードで最大10行の保存を依頼します。専用の日付入力と`latest`モードを使います。

json
{
  "queries": [
    "artificial intelligence"
  ],
  "searchMode": "latest",
  "maxItemsPerQuery": 10,
  "startTime": "2026-01-01",
  "endTime": "2026-01-31"
}
確認できる小規模な入力を用意する

この入力は、キャッシュされた公開JSON Schemaを使ったローカルでの確認に合格しました。JSON Schemaは、使用できる入力フィールドと値を定義します。指定したフィールド名はすべて、そのスキーマに存在します。これにより、入力の形式を確認できました。ただし、実際の収集元が利用できることの証明や、10行が返ることの保証にはなりません。Chronometricaの公開入力スキーマ

公開されているX Twitter Search API Dataset Taskは、開始用のプリセットを提供します。Taskとは、Actor用に保存した入力プリセットです。確認したページは、ページへの応答が成功したことを示すHTTP 200を返しました。この確認では、現在保存されている入力は確認していません。

実行前にTaskの入力を開き、意図した設定を適用します。例のキーワードと日付を、調査で使う値に置き換えます。最初の確認では、上限を小さくします。上の例は入力例であり、収集結果ではありません。

5段階でサンプルの採用を確認する

次の手順で、選んだActorが利用可能なサンプルを生成するかを判断します。

  1. 収集要件を書きます。各クエリのキーワード、暦日、使用するタイムゾーン、許容するサンプル件数を列挙します。必要なのが投稿の例、件数を限定した比較用サンプル、条件に一致するすべての投稿のどれかを明記します。結果を見る前に行ってください。必要な投稿者、メディア、その他のフィルターを含め、行の採用条件を定義します。
  2. 設定を選び、上限を小さくします。ドキュメントに記載されたフィルターが要件を満たすActorを選びます。専用の日付入力か、高度なクエリ演算子のどちらかを選びます。Chronometricaの確認では、上の入力を小規模な開始例として使えます。日付設定を組み合わせる場合は、その組み合わせを採用する前に、生成されたクエリを確認します。
  3. 実際のクエリと投稿の日付を確認します。`executedQuery`を読み、`inputQuery`と比較します。生成されたクエリが、意図したキーワードと日付範囲を表しているかを確認します。採用するすべての行で、投稿の作成日時を示すタイムスタンプ`createdAt`を確認します。開始日と終了日の両方の境界を含め、確認済みのタイムスタンプ範囲と比較します。Chronometricaのドキュメント
  4. 各クエリの実行結果を読みます。保存行数を、依頼した上限と報告された実行結果に照らして確認します。上限に達したクエリには、上限到達と記録します。証拠が裏付ける場合は、部分的な結果と記録します。理由を説明できない件数の不足も、分かるように残します。不明な値は不明のまま保持します。欠損データをゼロに置き換えないでください。
  5. サンプルを採用し、クエリごとに分けてエクスポートします。`resultPosition`を保持し、観測時刻、つまりサンプルを収集した時刻を記録します。これは投稿の作成時刻とは異なります。元の日付指定と、上限に達したクエリや部分的な結果となったクエリについての注記を保持します。何を依頼し、何を観測し、どの制限が当てはまるかを説明できるようになってから、分析を始めます。

保存行数が少ないクエリでも、X全体で条件に一致する投稿が少なかったとは限りません。その実行結果は、その収集についての証拠として扱います。必要なフィルターを設定で表現できない場合は、サンプルを増やす前に、製品の選択を見直します。

採用の確認は、明確な終了基準にもなります。必要な設定が機能し、保存した記録が予定する用途を裏付ける場合は、先に進めます。どちらかの確認に失敗した場合、収集量を増やすだけでは問題は解決しません。

2つのキーワードを使った架空の判断例

この例は架空です。Actorのテスト、実際のデータセット、購入希望者の発言の引用、費用の測定結果ではありません。

ある研究者が、「artificial intelligence」と「machine learning」という2つのキーワードについて、1月の投稿を集めようとしています。目的は、人が確認するための例を収集することです。研究者は、各クエリの保存行数の上限を10とし、収集前に使用するタイムゾーンを記録します。

他の制限を適用する前の、依頼するサンプルの最大件数は次のとおりです。

`2 queries × 10 rows per query = at most 20 saved rows`

この架空の結果では、最初のクエリは、日付条件を満たして採用された10行を返します。2つ目のクエリは、公開ソースの終端に達するまでに、日付条件を満たして採用された6行を返します。研究者が保持する行数は次のとおりです。

`10 + 6 = 16 observed rows`

研究者は、2つのクエリの実行結果も保持します。最初のクエリは上限に達しました。2つ目のクエリは上限未満で停止しました。行をまとめる場合も、この違いを失ってはいけません。

この要望には、Chronometricaが適しています。研究者は件数を限定したサンプルを受け入れ、元のクエリ、生成されたクエリ、行の位置、個別の実行結果を必要としています。これらの記録があれば、明示した依頼内容に照らして収集結果を確認できます。Chronometricaのドキュメント

研究者は、観測した16行の内容を説明できます。ただし、最初の話題がX全体でより多く出現したとは結論できません。上限と実行結果の違いからは、母集団での出現頻度は分かりません。母集団での出現頻度とは、投稿全体の中で各話題がどの程度出現したかということです。

要件が、1月の条件に一致するすべての投稿へと変わった場合、研究者はその新しい要件を別に評価する必要があります。小規模なサンプルの収集に成功しても、完全な収集を証明することにはなりません。全件取得の要件がChronometricaのクエリごとの上限を超える場合、このActorは要件を満たしません。

クエリ記録と投稿の観測記録を分けて保持する

クエリ管理用の表を1つ用意し、依頼内容と実行結果を記録します。これは自分の調査記録であり、Actorのエクスポート形式についての主張ではありません。各クエリについて、元のキーワード文字列、開始日と終了日を含む日付指定、使用するタイムゾーン、選択したモード、依頼した上限、保存行数、報告された実行結果を保持します。

投稿の観測記録は、`postId`と`executedQuery`をキーにして、別に保持します。キーとは、レコードを識別するために使う値の組み合わせです。各投稿と、その投稿を取得した生成済みクエリの結び付きを保持します。

ドキュメントに記載された検索情報のフィールド`inputQuery`、`executedQuery`、`searchMode`、`resultPosition`を保持します。日付の確認用に`createdAt`を保持します。調査記録には観測時刻も追加します。Chronometricaのドキュメント

1つの投稿が、複数のクエリのサンプルに現れることがあります。その場合は、それぞれのクエリとの結び付きを保持します。これにより、投稿が各サンプルに含まれた理由が分かります。後で重複のない投稿数を数える場合は、その計算を、保存したクエリごとの観測件数とは分けて説明します。

この構成は、エクスポートしたすべての行を、条件の説明なしに1つの合計として示すという、よくある誤りを防ぐ助けになります。まとめたファイルには、上限に達したサンプル、部分的なサンプル、重複する投稿が含まれる場合があります。クエリ記録があれば、結論を出す前に、それらの違いを説明できます。

後で、一緒に出現する語を分析する場合は、X投稿のキーワード共起を参照してください。まず、どの観測記録を使えるかを確定します。その後、明示したサンプルに分析手法を適用します。

出典と参考資料

著者 Chronometrica · 更新日

ページの先頭へ ↑