メインコンテンツへスキップ
ご注意: X API v2 で search Posts と Post counts の新バージョンをリリースしました。X API v2 の新機能をご確認ください。 これらの endpoint は、Post の編集 metadata を含むように更新されています。詳細は「“Edit Posts” の基礎」ページをご覧ください。 

​
概要

Enterprise Enterprise API は、当社のマネージドアクセスレベルでのみご利用いただけます。これらの API を使用するには、まず当社の Enterprise セールスチームとのアカウント設定が必要です。詳細はこちらをご覧ください。 X API における検索向けの Post 提供一覧はこちらでご確認いただけます。 Enterprise 検索 API は 2 種類あります:
  1. 30-Day Search API は、直近 30 日間のデータを提供します。
  2. Full-Archive Search API は、2006 年 3 月の最初の Post まで遡る X の全データコーパスへ完全かつ即時にアクセスできます。
これらの RESTful API は、リクエストあたり最大 2,048 文字の単一の query をサポートします。query は PowerTrack のルール構文で記述します。詳細はRules and filteringをご参照ください。ユーザーは分単位の粒度で任意の時間範囲を指定できます。ただし、レスポンスは指定した maxResults または 31 日のうち小さい方に制限され、次の結果セットにページネーションするための next トークンが含まれます。時間パラメータを指定しない場合、API は直近 30 日間の一致する data を返します。 Enterprise 検索 API は、分単位の粒度で Post アーカイブへの低レイテンシかつ高忠実度の query ベースアクセスを提供します。Post の data は逆時系列で返され、query に一致する最新の Post から始まります。Post は公開後おおよそ 30 秒で検索 API から利用可能になります。 これらの検索 endpoint は編集に関する Post の metadata を提供します。2022 年 9 月 29 日以降に作成されたすべての Post のオブジェクトには、Post が一度も編集されていない場合でも、編集 metadata が含まれます。Post が編集されるたびに新しい Post ID が生成されます。Post の編集履歴は、元の ID から始まる Post ID の配列として記録されます。 これらの endpoint は、常に最新の編集内容と編集履歴（存在する場合）を返します。30 分の編集ウィンドウ経過後に収集された Post は最終版を表します。Edit Post metadata の詳細は、Edit Posts fundamentals をご覧ください。 リクエストには、API レスポンスごとに返す Post の最大数を指定する maxResults パラメータが含まれます。query に関連付けられた Post がこの上限を超える場合、レスポンスに next トークンが含まれます。これらの next トークンを後続のリクエストで使用し、query に関連する Post の全件をページングします。 これらの Enterprise 検索 API には、query に関連するデータボリュームをリクエストできる counts endpoint が用意されています。 

​
リクエストの種類

Enterprise 検索 API は、2 種類のリクエストをサポートしています。

​
検索リクエスト（data）

Enterprise 検索 API への検索リクエストでは、指定した期間について、1 回のレスポンスで最大 500 件の結果を取得でき、ページネーションにより追加の data を取得できます。maxResults パラメータを使用すると、表示用途に合わせて小さいページサイズ（必要に応じてユーザーがさらに結果を要求できるようにする）や、大規模なデータ取得に適した大きいページサイズ（最大 500）を指定できます。data は配信時点でコンプライアンスに準拠しており、時系列の逆順で提供されます。

​
カウントリクエスト（Post 数）

カウントリクエストでは、指定した期間内に、与えられた query に一致して発生したアクティビティ数（過去のアクティビティ数）を取得できます。レスポンスは、日・時・分単位で集計（バケット化）されたカウントのヒストグラムを返します（既定のバケットは「時」）。カウント結果は、Post の公開からかなり後（7日以上）に発生するコンプライアンスイベント（例：Posts の delete）を常に反映するわけではありません。そのため、同じ query に対する data リクエストの結果とカウントの指標が一致しない場合があります。 課金に関する注意: data および counts endpoint に対して行われる各リクエスト（ページネーションのリクエストを含む）は、課金対象のリクエストとして計上されます。したがって、単一の query の結果が複数ページにわたる場合、X ページを順に取得すると、課金上は X 件のリクエストに相当します。

​
利用可能なオペレーター

Enterprise 検索 API は最大 2,048 文字のルールをサポートします。Enterprise 検索 API で利用できるオペレーターは以下のとおりです。詳細はこちらをご覧ください。 
Post コンテンツでのマッチング:対象アカウントでのマッチング:Post の属性:地理空間オペレーター:
* キーワード
* “引用フレーズ”
* “keyword1 keyword2”~N
* #
* @
* $
* url:
* lang:		* from:
* to:
* retweets_of:		* is:retweet

* has:mentions
* has:hashtags
* has:media
* has:videos
* has:images
* has:links
* has:symbols
* is:verified

* -is:nullcast（否定専用オペレーター）		* bounding_box:[west_long south_lat east_long north_lat]
* point_radius:[lon lat radius]
* has:geo
* place:
* place_country:
* has:profile_geo
* profile_country:
* profile_region:
* profile_locality:
注意: オペレーターを埋め込んだりネストしないでください。「#cats」は検索 API では cats として解釈されます。‘lang:’ オペレーターおよびすべての ‘is:’ と ‘has:’ オペレーターは単独では使用できず、別の節と組み合わせる必要があります（例: @XDevelopers has:links）。     検索 API はトークナイゼーション／マッチング機能の制約により、利用できるオペレーターが限定されます。Enterprise のリアルタイムおよびバッチ履歴 API では追加のオペレーターが提供されます。詳細はこちらをご覧ください。 さらに詳しくは、オペレーター入門ガイドをご覧ください。

​
データの可用性／重要な日付

Full-Archive search API を使用する際は、X プラットフォームが 2006 年以降も進化を続けていることに留意してください。新機能の追加に伴い、基盤となる JSON オブジェクトには新たな metadata が追加されてきました。そのため、検索オペレーターが照合対象とする Post の属性がいつ追加されたのかを把握することが重要です。以下は、重要な metadata グループの「導入日」となる、基本的な日付の一部です。Post の属性が最初に導入された時期の詳細については、このガイドを参照してください。  
  • 最初の Post: 2006/3/21
  • 最初のネイティブリツイート: 2009/11/6
  • 最初のジオタグ付き Post: 2009/11/19
  • フィルタリングのために URL が初めてインデックス化: 2011/8/27
  • 拡張 URL 展開 metadata（ウェブサイトのタイトルと説明）: 2014/12/1
  • プロファイル Geo エンリッチメント metadata とフィルタリング: 2015/2/17

​
データの更新と可変性

Enterprise 検索 API では、Post 内の一部のデータは可変で、初回のアーカイブ後に更新・変更される可能性があります。 この可変データは次の 2 つのカテゴリに分類されます:
  • ユーザーオブジェクトの metadata:
    • ユーザーの @handle（数値の id は変わりません）
    • Bio（自己紹介）
    • カウント: statuses、followers、friends、favorites、lists
    • プロフィールの位置情報
    • タイムゾーンや言語などのその他の詳細
  • Post の統計値 — すなわち、ユーザーの操作によってプラットフォーム上で変更されうるもの（以下の例）:
    • Favorites 数
    • リツイート数
多くの場合、検索 API は Post の生成時点ではなく、query-time におけるプラットフォーム上の状態としてデータを返します。ただし、特定のオペレーター（例: from、to、@、is:verified）を使用するクエリでは、この限りではない場合があります。データはインデックス内で定期的に更新され、直近の期間ほど更新頻度が高くなります。結果として、返されるデータが X.com に表示される最新のデータと完全に一致しない場合がありますが、最後にインデックス化された時点のデータとは一致します。 なお、この不整合は、オペレーターが可変データに対して適用されるクエリにのみ当てはまります。たとえば、ユーザー名でのフィルタリングが該当し、このようなクエリに対する最善の回避策は、@handle ではなくユーザーの数値 id を使用することです。

​
シングルスレッド vs. マルチスレッドのリクエスト

各顧客には、検索 endpoint に対するレートリミットが定義されています。Full-Archive 検索のデフォルトの 1 分あたりのレートリミットは 120 リクエストで、平均すると 1 秒あたり 2 query（QPS）に相当します。この平均 QPS は、理論上は毎秒 2 回 API にリクエストできることを意味します。本プロダクトのページネーション機能を踏まえると、1 年の query に紐づく Posts が 100 万件あり、年間を通じて均等に分布している場合、すべての data を取得するには（「maxResults」を 500 と仮定して）2,000 件超のリクエストが必要になります。各レスポンスに 2 秒かかると仮定すると、単一スレッドで直列（逐次）にすべての data を取得するには 4,000 秒（つまり 1 時間強）（直前のレスポンスの「next」トークンを用いて 1 秒あたり 1 リクエスト）となります。悪くありません。 次に、12 本の並列スレッドを使って data を取得する状況を考えます。100 万件の Posts が 1 年間に均等分布していると仮定すると、リクエストを 12 本の並列スレッド（マルチスレッド）に分割し、単一の「ジョブ」に対する 1 秒あたりのレートリミットをより活用できます。つまり、関心のある各月ごとに 1 本のスレッドを走らせることで、data は 12 倍の速度（約 6 分）で取得できます。 このマルチスレッドの例は counts endpoint にも同様に当てはまります。たとえば、2 年間の期間に対する Post の件数を取得したい場合、シングルスレッドのリクエストで 31 日単位でページングしながら遡ることができます。各レスポンスに 2 秒かかると仮定すると、24 回の API リクエストで件数の全セットを取得するのに約 48 秒を要します。ただし、同時に複数の 1 か月分リクエストを行うことも可能です。1 秒あたり 12 件のリクエストを行う場合、件数の全セットは約 2 秒で取得できます。

​
リトライ ロジック

Enterprise 検索 API で 503 エラーが発生した場合、多くは一時的なエラーのため、短時間待ってからリクエストを再試行すると解決することがあります。 リクエストが連続して 4 回失敗し、各失敗の間に少なくとも 10 分待機している場合は、次の手順でトラブルシュートしてください。
  • 対象期間を短くしてリクエストを再試行します。改善しない場合は、最短で 6 時間の時間枠になるまで段階的に短縮して繰り返します。
  • 多数の語句を OR で結合している場合は、別々のルールに分割し、それぞれ個別に再試行します。
  • ルールで多数の除外条件を使用している場合は、否定条件の数を減らして再試行します。

​
クイックスタート ガイド

​
Enterprise Search Posts: 30-Day API の始め方

Enterprise Search Posts: 30-Day API は、過去30日以内に投稿された Posts を提供します。Posts は、リクエストで指定した query に基づいて照合され、返されます。query とは、返される Post に含める内容を定義するルールです。本チュートリアルでは、英語の X アカウント @XDevelopers から発信された Posts を検索します。 レスポンスのペイロードに含まれる Posts は、Post の完全なペイロードを提供する data 形式、または一致した Posts の数値集計データを提供する counts 形式のいずれかです。data と counts の各 endpoint へのリクエストには cURL を使用します。 次のものが必要です:

​
data endpoint へのアクセス

この data endpoint は、マッチした Posts の完全な Post ペイロードを返します。from: と lang: 演算子を使って、@XDevelopers 由来の英語の Posts を検索します。他の演算子については こちらをご参照ください。
  • cURL
  • cURL example
cURL は、URL 構文を用いてファイルを取得または送信するためのコマンドラインツールです。以下の項目を編集したうえで、次の cURL リクエストをコマンドラインにコピーしてください。
  • Username <USERNAME> 例: email@domain.com
  • Account name <ACCOUNT-NAME> 例: john-doe
  • Label <LABEL> 例: prod
  • fromDate と toDate 例: "fromDate":"201811010000", "toDate":"201811122359"
リクエストを送信すると、パスワードの入力を求められます。
curl -X POST -u<USERNAME> "https://gnip-api.x.com/search/30day/accounts/<ACCOUNT-NAME>/<LABEL>.json" -d '{"query":"from:TwitterDev lang:en","maxResults":"500","fromDate":"<yyyymmddhhmm>","toDate":"<yyyymmddhhmm>"}'

​
Data endpoint のレスポンスペイロード

API リクエストの結果として返されるペイロードは、以下のとおり JSON 形式になります。 
{
	"results": [
		{
			"created_at": "Fri Nov 02 17:18:31 +0000 2018",
			"id": 1058408022936977409,
			"id_str": "1058408022936977409",
			"text": "RT @harmophone: \"Tagboard、Twitter、TEGNAのコラボレーションが実現する革新的なクラウドソーシングにより、地域に関連する会話が浮上し…",
			"source": "<a href=\"http:\/\/twitter.com\" rel=\"nofollow\">Twitter Web Client<\/a>",
			"truncated": false,
			"in_reply_to_status_id": null,
			"in_reply_to_status_id_str": null,
			"in_reply_to_user_id": null,
			"in_reply_to_user_id_str": null,
			"in_reply_to_screen_name": null,
			"user": {
				"id": 2244994945,
				"id_str": "2244994945",
				"name": "Twitter Dev",
				"screen_name": "TwitterDev",
				"location": "インターネット",
				"url": "https:\/\/developer.x.com\/",
				"description": "Twitter Platformのニュース、アップデート、イベントの公式情報源。技術的なサポートが必要ですか？https:\/\/devcommunity.com\/ をご覧ください ⌨️ #TapIntoTwitter",
				"translator_type": "null",
				"protected": false,
				"verified": true,
				"followers_count": 503828,
				"friends_count": 1477,
				"listed_count": 1437,
				"favourites_count": 2199,
				"statuses_count": 3380,
				"created_at": "Sat Dec 14 04:35:55 +0000 2013",
				"utc_offset": null,
				"time_zone": null,
				"geo_enabled": true,
				"lang": "en",
				"contributors_enabled": false,
				"is_translator": false,
				"profile_background_color": "null",
				"profile_background_image_url": "null",
				"profile_background_image_url_https": "null",
				"profile_background_tile": null,
				"profile_link_color": "null",
				"profile_sidebar_border_color": "null",
				"profile_sidebar_fill_color": "null",
				"profile_text_color": "null",
				"profile_use_background_image": null,
				"profile_image_url": "null",
				"profile_image_url_https": "https:\/\/pbs.twimg.com\/profile_images\/880136122604507136\/xHrnqf1T_normal.jpg",
				"profile_banner_url": "https:\/\/pbs.twimg.com\/profile_banners\/2244994945\/1498675817",
				"default_profile": false,
				"default_profile_image": false,
				"following": null,
				"follow_request_sent": null,
				"notifications": null
			},
			"geo": null,
			"coordinates": null,
			"place": null,
			"contributors": null,
			"retweeted_status": {
				"created_at": "Tue Oct 30 21:30:25 +0000 2018",
				"id": 1057384253116289025,
				"id_str": "1057384253116289025",
				"text": "\"Tagboard、Twitter、TEGNAのコラボレーションが実現する革新的なクラウドソーシングにより、地域に関連する… https:\/\/t.co\/w46U5TRTzQ",
				"source": "<a href=\"http:\/\/twitter.com\" rel=\"nofollow\">Twitter Web Client<\/a>",
				"truncated": true,
				"in_reply_to_status_id": null,
				"in_reply_to_status_id_str": null,
				"in_reply_to_user_id": null,
				"in_reply_to_user_id_str": null,
				"in_reply_to_screen_name": null,
				"user": {
					"id": 175187944,
					"id_str": "175187944",
					"name": "Tyler Singletary",
					"screen_name": "harmophone",
					"location": "カリフォルニア州サンフランシスコ",
					"url": "http:\/\/medium.com\/@harmophone",
					"description": "@Tagboard のSVP Product。@Klout と @LithiumTech でデータ、ビジネス、プロダクトを担当；@BBI 理事会メンバー；@Insightpool アドバイザー。世界最悪のホワイトボード使い。",
					"translator_type": "null",
					"protected": false,
					"verified": false,
					"followers_count": 1982,
					"friends_count": 1877,
					"listed_count": 245,
					"favourites_count": 23743,
					"statuses_count": 12708,
					"created_at": "Thu Aug 05 22:59:29 +0000 2010",
					"utc_offset": null,
					"time_zone": null,
					"geo_enabled": false,
					"lang": "en",
					"contributors_enabled": false,
					"is_translator": false,
					"profile_background_color": "null",
					"profile_background_image_url": "null",
					"profile_background_image_url_https": "null",
					"profile_background_tile": null,
					"profile_link_color": "null",
					"profile_sidebar_border_color": "null",
					"profile_sidebar_fill_color": "null",
					"profile_text_color": "null",
					"profile_use_background_image": null,
					"profile_image_url": "null",
					"profile_image_url_https": "https:\/\/pbs.twimg.com\/profile_images\/719985428632240128\/WYFHcK-m_normal.jpg",
					"profile_banner_url": "https:\/\/pbs.twimg.com\/profile_banners\/175187944\/1398653841",
					"default_profile": false,
					"default_profile_image": false,
					"following": null,
					"follow_request_sent": null,
					"notifications": null
				},
				"geo": null,
				"coordinates": null,
				"place": null,
				"contributors": null,
				"is_quote_status": false,
				"extended_tweet": {
					"full_text": "\"Tagboard、Twitter、TEGNAのコラボレーションが実現する革新的なクラウドソーシングにより、地域に関連する会話がリアルタイムで浮上し、有権者が討論中に質問できるようになっています\" -- @adamostrow、@TEGNA\n詳細はこちら: https:\/\/t.co\/ivAFtanfje",
					"display_text_range": [
						0,
						259
					],
					"entities": {
						"hashtags": [],
						"urls": [
							{
								"url": "https:\/\/t.co\/ivAFtanfje",
								"expanded_url": "https:\/\/blog.tagboard.com\/twitter-and-tagboard-collaborate-to-bring-best-election-content-to-news-outlets-with-tagboard-e85fc864bcf4",
								"display_url": "blog.tagboard.com\/twitter-and-ta…",
								"unwound": {
									"url": "https:\/\/blog.tagboard.com\/twitter-and-tagboard-collaborate-to-bring-best-election-content-to-news-outlets-with-tagboard-e85fc864bcf4",
									"status": 200,
									"title": "TwitterとTagboardが連携し、Tagboardを通じてニュースメディアに最高の選挙コンテンツを提供…",
									"description": "Tyler Singletary、Tagboard プロダクト責任者"
								},
								"indices": [
									236,
									259
								]
							}
						],
						"user_mentions": [
							{
								"screen_name": "adamostrow",
								"name": "Adam Ostrow",
								"id": 5695942,
								"id_str": "5695942",
								"indices": [
									204,
									215
								]
							},
							{
								"screen_name": "TEGNA",
								"name": "TEGNA",
								"id": 34123003,
								"id_str": "34123003",
								"indices": [
									217,
									223
								]
							}
						],
						"symbols": []
					}
				},
				"quote_count": 0,
				"reply_count": 1,
				"retweet_count": 6,
				"favorite_count": 19,
				"entities": {
					"hashtags": [],
					"urls": [
						{
							"url": "https:\/\/t.co\/w46U5TRTzQ",
							"expanded_url": "https:\/\/twitter.com\/i\/web\/status\/1057384253116289025",
							"display_url": "twitter.com\/i\/web\/status\/1…",
							"indices": [
								117,
								140
							]
						}
					],
					"user_mentions": [],
					"symbols": []
				},
				"favorited": false,
				"retweeted": false,
				"possibly_sensitive": false,
				"filter_level": "low",
				"lang": "en"
			},
			"is_quote_status": false,
			"quote_count": 0,
			"reply_count": 0,
			"retweet_count": 0,
			"favorite_count": 0,
			"entities": {
				"hashtags": [],
				"urls": [],
				"user_mentions": [
					{
						"screen_name": "harmophone",
						"name": "Tyler Singletary",
						"id": 175187944,
						"id_str": "175187944",
						"indices": [
							3,
							14
						]
					}
				],
				"symbols": []
			},
			"favorited": false,
			"retweeted": false,
			"filter_level": "low",
			"lang": "en",
			"matching_rules": [
				{
					"tag": null
				}
			]
		}
	],
	"requestParameters": {
		"maxResults": 100,
		"fromDate": "201811010000",
		"toDate": "201811060000"
	}
}

​
counts endpoint へのアクセス

counts endpoint を使って、@XDevelopers アカウントから英語で投稿された Posts の数を、day ごとに集計して取得します。
  • cURL
  • cURL example
cURL は、URL 構文を用いてファイルを取得・送信するためのコマンドラインツールです。以下の項目を必要に応じて置き換えたうえで、次の cURL リクエストをコマンドラインにコピーしてください。
  • Username <USERNAME> 例: email@domain.com
  • Account name <ACCOUNT-NAME> 例: john-doe
  • Label <LABEL> 例: prod
  • fromDate と toDate 例: "fromDate":"201811010000", "toDate":"201811122359"
リクエストを送信すると、パスワードの入力を求められます。
curl -X POST -u<USERNAME> "https://gnip-api.x.com/search/30day/accounts/<ACCOUNT-NAME>/<LABEL>/counts.json" -d '{"query":"from:TwitterDev lang:en","fromDate":"<yyyymmddhhmm>","toDate":"<yyyymmddhhmm>","bucket":"day"}'

​
Counts endpoint のレスポンスペイロード

API リクエストの応答で返されるペイロードは、以下のとおり JSON 形式で示されます。 
{
	"results": [
		{
			"timePeriod": "201811010000",
			"count": 0
		},
		{
			"timePeriod": "201811020000",
			"count": 1
		},
		{
			"timePeriod": "201811030000",
			"count": 0
		},
		{
			"timePeriod": "201811040000",
			"count": 0
		},
		{
			"timePeriod": "201811050000",
			"count": 0
		}
	],
	"totalCount": 1,
	"requestParameters": {
		"bucket": "day",
		"fromDate": "201811010000",
		"toDate": "201811060000"
	}
}
素晴らしいです！これで Enterprise Search Posts: 30-Day API へのアクセスに成功しました。
参照記事

​
Enterprise Search Posts: Full-Archive API の開始方法

Enterprise Search Posts: Full-Archive API は、2006年の最初の投稿以降の Posts を提供します。Posts は、リクエストで指定した query に基づいてマッチし、返されます。query は、取得対象の Post に含める条件を定義するルールです。本チュートリアルでは、X アカウント @XDevelopers から英語で投稿された Posts を検索します。 返されるペイロード内の Posts は、Post の完全なペイロードを得られる data 形式、またはマッチした Posts の数を提供する counts 形式のいずれかです。ここでは、data と counts の endpoint にリクエストを送信するために cURL を使用します。 以下が必要です:

​
data endpoint へのアクセス

data endpoint は、マッチした Posts の完全な Post ペイロードを返します。from: と lang: オペレーターを使って、英語の @XDevelopers 発の Posts を検索します。 ほかのオペレーターについては こちらをご覧ください。
  • cURL
  • cURL example
cURL は、URL 構文を用いてファイルを取得または送信するコマンドラインツールです。次の項目を必要に応じて変更し、以下の cURL リクエストをコマンドラインにコピーしてください。
  • Username <USERNAME> 例: email@domain.com
  • Account name <ACCOUNT-NAME> 例: john-doe
  • Label <LABEL> 例: prod
  • fromDate と toDate 例: "fromDate":"201802010000", "toDate":"201802282359"
リクエスト送信後、パスワードの入力を求められます。
curl -X POST -u<USERNAME> "https://gnip-api.x.com/search/fullarchive/accounts/<ACCOUNT-NAME>/<LABEL>.json" -d '{"query":"from:TwitterDev lang:en","maxResults":"500","fromDate":"<yyyymmddhhmm>","toDate":"<yyyymmddhhmm>"}'
Data endpoint のレスポンス・ペイロード
API リクエストのレスポンスとして返されるペイロードは、以下のとおり JSON 形式で表示されます。 
{
	"results": [
		{
			"created_at": "Fri Nov 02 17:18:31 +0000 2018",
			"id": 1058408022936977409,
			"id_str": "1058408022936977409",
			"text": "RT @harmophone: \"Tagboard、Twitter、TEGNAのコラボレーションが実現する革新的なクラウドソーシングは、地域に関連する会話を浮上させ…",
			"source": "<a href=\"http:\/\/twitter.com\" rel=\"nofollow\">Twitter Web Client<\/a>",
			"truncated": false,
			"in_reply_to_status_id": null,
			"in_reply_to_status_id_str": null,
			"in_reply_to_user_id": null,
			"in_reply_to_user_id_str": null,
			"in_reply_to_screen_name": null,
			"user": {
				"id": 2244994945,
				"id_str": "2244994945",
				"name": "Twitter Dev",
				"screen_name": "TwitterDev",
				"location": "インターネット",
				"url": "https:\/\/developer.x.com\/",
				"description": "Twitter Platformのニュース、アップデート、イベントの公式情報源。技術的なサポートが必要ですか？https:\/\/devcommunity.com\/ をご覧ください ⌨️ #TapIntoTwitter",
				"translator_type": "null",
				"protected": false,
				"verified": true,
				"followers_count": 503828,
				"friends_count": 1477,
				"listed_count": 1437,
				"favourites_count": 2199,
				"statuses_count": 3380,
				"created_at": "Sat Dec 14 04:35:55 +0000 2013",
				"utc_offset": null,
				"time_zone": null,
				"geo_enabled": true,
				"lang": "en",
				"contributors_enabled": false,
				"is_translator": false,
				"profile_background_color": "null",
				"profile_background_image_url": "null",
				"profile_background_image_url_https": "null",
				"profile_background_tile": null,
				"profile_link_color": "null",
				"profile_sidebar_border_color": "null",
				"profile_sidebar_fill_color": "null",
				"profile_text_color": "null",
				"profile_use_background_image": null,
				"profile_image_url": "null",
				"profile_image_url_https": "https:\/\/pbs.twimg.com\/profile_images\/880136122604507136\/xHrnqf1T_normal.jpg",
				"profile_banner_url": "https:\/\/pbs.twimg.com\/profile_banners\/2244994945\/1498675817",
				"default_profile": false,
				"default_profile_image": false,
				"following": null,
				"follow_request_sent": null,
				"notifications": null
			},
			"geo": null,
			"coordinates": null,
			"place": null,
			"contributors": null,
			"retweeted_status": {
				"created_at": "Tue Oct 30 21:30:25 +0000 2018",
				"id": 1057384253116289025,
				"id_str": "1057384253116289025",
				"text": "\"Tagboard、Twitter、TEGNAのコラボレーションが実現する革新的なクラウドソーシングは、地域に関連する… https:\/\/t.co\/w46U5TRTzQ",
				"source": "<a href=\"http:\/\/twitter.com\" rel=\"nofollow\">Twitter Web Client<\/a>",
				"truncated": true,
				"in_reply_to_status_id": null,
				"in_reply_to_status_id_str": null,
				"in_reply_to_user_id": null,
				"in_reply_to_user_id_str": null,
				"in_reply_to_screen_name": null,
				"user": {
					"id": 175187944,
					"id_str": "175187944",
					"name": "Tyler Singletary",
					"screen_name": "harmophone",
					"location": "カリフォルニア州サンフランシスコ",
					"url": "http:\/\/medium.com\/@harmophone",
					"description": "@Tagboard のSVP Product。@Klout と @LithiumTech でデータ、ビジネス、プロダクトを担当；@BBI 理事会メンバー；@Insightpool アドバイザー。世界最悪のホワイトボード使い。",
					"translator_type": "null",
					"protected": false,
					"verified": false,
					"followers_count": 1982,
					"friends_count": 1877,
					"listed_count": 245,
					"favourites_count": 23743,
					"statuses_count": 12708,
					"created_at": "Thu Aug 05 22:59:29 +0000 2010",
					"utc_offset": null,
					"time_zone": null,
					"geo_enabled": false,
					"lang": "en",
					"contributors_enabled": false,
					"is_translator": false,
					"profile_background_color": "null",
					"profile_background_image_url": "null",
					"profile_background_image_url_https": "null",
					"profile_background_tile": null,
					"profile_link_color": "null",
					"profile_sidebar_border_color": "null",
					"profile_sidebar_fill_color": "null",
					"profile_text_color": "null",
					"profile_use_background_image": null,
					"profile_image_url": "null",
					"profile_image_url_https": "https:\/\/pbs.twimg.com\/profile_images\/719985428632240128\/WYFHcK-m_normal.jpg",
					"profile_banner_url": "https:\/\/pbs.twimg.com\/profile_banners\/175187944\/1398653841",
					"default_profile": false,
					"default_profile_image": false,
					"following": null,
					"follow_request_sent": null,
					"notifications": null
				},
				"geo": null,
				"coordinates": null,
				"place": null,
				"contributors": null,
				"is_quote_status": false,
				"extended_tweet": {
					"full_text": "\"Tagboard、Twitter、TEGNAのコラボレーションが実現する革新的なクラウドソーシングは、地域に関連する会話をリアルタイムで浮上させ、有権者が討論中に質問できるようにしています\" -- @adamostrow、@TEGNA\n詳細はこちら：https:\/\/t.co\/ivAFtanfje",
					"display_text_range": [
						0,
						259
					],
					"entities": {
						"hashtags": [],
						"urls": [
							{
								"url": "https:\/\/t.co\/ivAFtanfje",
								"expanded_url": "https:\/\/blog.tagboard.com\/twitter-and-tagboard-collaborate-to-bring-best-election-content-to-news-outlets-with-tagboard-e85fc864bcf4",
								"display_url": "blog.tagboard.com\/twitter-and-ta…",
								"unwound": {
									"url": "https:\/\/blog.tagboard.com\/twitter-and-tagboard-collaborate-to-bring-best-election-content-to-news-outlets-with-tagboard-e85fc864bcf4",
									"status": 200,
									"title": "TwitterとTagboardが連携し、Tagboardを通じてニュースメディアに最高の選挙コンテンツを提供…",
									"description": "Tyler Singletary、Tagboard プロダクト責任者"
								},
								"indices": [
									236,
									259
								]
							}
						],
						"user_mentions": [
							{
								"screen_name": "adamostrow",
								"name": "Adam Ostrow",
								"id": 5695942,
								"id_str": "5695942",
								"indices": [
									204,
									215
								]
							},
							{
								"screen_name": "TEGNA",
								"name": "TEGNA",
								"id": 34123003,
								"id_str": "34123003",
								"indices": [
									217,
									223
								]
							}
						],
						"symbols": []
					}
				},
				"quote_count": 0,
				"reply_count": 1,
				"retweet_count": 6,
				"favorite_count": 19,
				"entities": {
					"hashtags": [],
					"urls": [
						{
							"url": "https:\/\/t.co\/w46U5TRTzQ",
							"expanded_url": "https:\/\/twitter.com\/i\/web\/status\/1057384253116289025",
							"display_url": "twitter.com\/i\/web\/status\/1…",
							"indices": [
								117,
								140
							]
						}
					],
					"user_mentions": [],
					"symbols": []
				},
				"favorited": false,
				"retweeted": false,
				"possibly_sensitive": false,
				"filter_level": "low",
				"lang": "en"
			},
			"is_quote_status": false,
			"quote_count": 0,
			"reply_count": 0,
			"retweet_count": 0,
			"favorite_count": 0,
			"entities": {
				"hashtags": [],
				"urls": [],
				"user_mentions": [
					{
						"screen_name": "harmophone",
						"name": "Tyler Singletary",
						"id": 175187944,
						"id_str": "175187944",
						"indices": [
							3,
							14
						]
					}
				],
				"symbols": []
			},
			"favorited": false,
			"retweeted": false,
			"filter_level": "low",
			"lang": "en",
			"matching_rules": [
				{
					"tag": null
				}
			]
		}
	],
	"requestParameters": {
		"maxResults": 100,
		"fromDate": "201811010000",
		"toDate": "201811060000"
	}
}

​
counts endpoint へのアクセス

counts endpoint を使用して、英語の @XDevelopers アカウント発の Posts の件数を day 単位で取得します。
  • cURL
  • cURL example
cURL は、URL 構文を使用してファイルを取得または送信するコマンドラインツールです。以下の項目を変更したうえで、次の cURL リクエストをコマンドラインにコピーしてください。
  • Username <USERNAME> 例: email@domain.com
  • Account name <ACCOUNT-NAME> 例: john-doe
  • Label <LABEL> 例: prod
  • fromDate と toDate 例: "fromDate":"201802010000", "toDate":"201802282359"
リクエスト送信後、パスワードの入力を求められます。
curl -X POST -u<USERNAME> "https://gnip-api.x.com/search/fullarchive/accounts/<ACCOUNT-NAME>/<LABEL>/counts.json" -d '{"query":"from:TwitterDev lang:en","fromDate":"<yyyymmddhhmm>","toDate":"<yyyymmddhhmm>","bucket":"day"}'

​
Counts endpoint のレスポンスペイロード

API リクエストの応答として返されるペイロードは、以下のとおり JSON 形式です。 
{
	"results": [
		{
			"timePeriod": "201811010000",
			"count": 0
		},
		{
			"timePeriod": "201811020000",
			"count": 1
		},
		{
			"timePeriod": "201811030000",
			"count": 0
		},
		{
			"timePeriod": "201811040000",
			"count": 0
		},
		{
			"timePeriod": "201811050000",
			"count": 0
		}
	],
	"totalCount": 1,
	"requestParameters": {
		"bucket": "day",
		"fromDate": "201811010000",
		"toDate": "201811060000"
	}
}
よくできました。これで Enterprise の Search Posts: Full-Archive API へのアクセスに成功しました。
参考記事

​
ガイド

​
検索クエリの作成

​
Enterprise のオペレーター

以下は、X の Enterprise 検索 API でサポートされているオペレーターの一覧です：
  • Enterprise 30 日間検索 API
  • Enterprise 全アーカイブ検索 API
製品ごとの利用可能なオペレーターの比較は、こちらをご覧ください。
演算子説明
keywordPostの本文またはURL内のトークン化されたキーワードにマッチします。これはトークン化マッチであり、キーワード文字列がPostの本文のトークン化されたテキストと照合されます。トークン化は句読点、記号、区切り文字のUnicode基本平面文字に基づいて行われます。例えば、「I like coca-cola」というテキストのPostは、次のトークンに分割されます：I、like、coca、cola。これらのトークンが、ルールで使用されるキーワード文字列と比較されます。句読点（例：coca-cola）、記号、または区切り文字を含む文字列をマッチさせるには、以下で説明する引用符による完全一致を使用する必要があります。

注意： Search APIでは、アクセント記号や特殊文字は標準的なラテン文字に正規化されるため、外国語での意味が変わったり、予期しない結果が返される可能性があります：
例えば、「músic」は「music」にマッチし、その逆も同様です。
例えば、スペイン語の「Feliz Año Nuevo!」のような一般的なフレーズは「Feliz Ano Nuevo」としてインデックス化され、フレーズの意味が変わってしまいます。

注意： この演算子は、Post内のURLと展開されたURLの両方にマッチします。
emojiPostの本文内の絵文字にマッチします。絵文字はトークン化マッチであり、絵文字がPostの本文のトークン化されたテキストと照合されます。トークン化は句読点、記号/絵文字、区切り文字のUnicode基本平面文字に基づいて行われます。例えば、「I like 」というテキストのPostは、次のトークンに分割されます：I、like、。これらのトークンが、ルールで使用される絵文字と比較されます。絵文字にバリアントがある場合は、ルールに追加するために「引用符」を使用する必要があります。
“exact phrase match”Postの本文またはURL内のトークン化され順序付けられたフレーズにマッチします。これはトークン化マッチであり、キーワード文字列がPostの本文のトークン化されたテキストと照合されます。トークン化は句読点、記号、区切り文字のUnicode基本平面文字に基づいて行われます。

注意： 句読点はトークン化されず、代わりに空白として扱われます。
例えば、引用符付きの「#hashtag」は「hashtag」にマッチしますが、#hashtagにはマッチしません（実際のハッシュタグにマッチさせるには、引用符なしでハッシュタグ#演算子を使用してください）。
例えば、引用符付きの「cashtag」は「cashtag」にマッチしますが、cashtag」は「cashtag」にマッチしますが、cashtagにはマッチしません（実際のキャッシュタグにマッチさせるには、引用符なしでキャッシュタグ$演算子を使用してください）。
例えば、「Love Snow」は「#love #snow」にマッチします
例えば、「#Love #Snow」は「love snow」にマッチします

注意： この演算子は、Post内のURLと展開されたURLの両方にマッチします。
“keyword1 keyword2”~N一般的に近接演算子と呼ばれ、キーワード間の距離がNトークン以下のPostにマッチします。

キーワードが逆順の場合、N-2トークン以下の距離である必要があります。引用符内に任意の数のキーワードを含めることができます。Nは6を超えることはできません。

この演算子はenterprise検索APIでのみ利用可能です。
from:特定のユーザーからのPostにマッチします。
値は、ユーザーのX数値アカウントidまたはユーザー名（@文字を除く）である必要があります。X数値アカウントidを検索する方法については、こちらまたはこちらを参照してください。
to:特定のユーザーへの返信であるPostにマッチします。

値は、ユーザーの数値アカウントidまたはユーザー名（@文字を除く）である必要があります。X数値アカウントidを検索する方法については、こちらを参照してください。
url:Postの展開されたURLに対してトークン化された（キーワード/フレーズ）マッチを実行します（url_containsと同様）。句読点や特殊文字を含むトークンやフレーズは二重引用符で囲む必要があります。例：url:“/developer”。一般的には推奨されませんが、特定のプロトコルにマッチさせたい場合は、二重引用符で囲んでください：url:“https://developer.x.com&quot;。
注意： PowerTrackまたはHistorical PowerTrackを使用する場合、この演算子は引用Postの元のPostに含まれるURLにマッチします。例えば、ルールにurl:“developer.x.com”が含まれ、PostにそのURLが含まれている場合、そのPostの引用Tweetも結果に含まれます。これはSearch APIを使用する場合には当てはまりません。
#指定されたハッシュタグを含むPostにマッチします。

この演算子は完全一致を実行し、トークン化マッチではありません。つまり、ルール「2016」は正確なハッシュタグ「2016」を含むPostにマッチしますが、ハッシュタグ「2016election」を含むPostにはマッチしません

注意：ハッシュタグ演算子は、本文自体からハッシュタグを抽出するのではなく、Xのエンティティ抽出に依存してハッシュタグをマッチさせます。XエンティティのJSON属性の詳細については、こちらを参照してください。
@指定されたユーザー名をメンションするPostにマッチします。
to:演算子は@mention演算子のサブセットマッチを返します。
$指定された「キャッシュタグ」（トークンの先頭文字が「$」文字）を含むPostにマッチします。

キャッシュタグ演算子は、本文自体からキャッシュタグを抽出しようとするのではなく、Xの「symbols」エンティティ抽出に依存してキャッシュタグをマッチさせます。XエンティティのJSON属性の詳細については、こちらを参照してください。

この演算子はenterprise検索APIでのみ利用可能です。

retweets_of:利用可能なエイリアス：retweets_of_user:
指定されたユーザーのリツイートであるPostにマッチします。ユーザー名とX数値アカウントidの両方を受け入れます（Postステータスidではありません）。X数値アカウントidを検索する方法については、こちらを参照してください。
lang:Xによって特定の言語として分類されたPostにマッチします（Postが分類されている場合のみ）。各Postは現在1つの言語としてのみ分類されるため、複数の言語をANDで結合しても結果は得られないことに注意することが重要です。

注意： 言語分類ができない場合、提供される結果は「und」（未定義）です。

以下のリストは、現在サポートされている言語とそれに対応するBCP 47言語識別子を示しています：
アムハラ語: amドイツ語: deマラヤーラム語: mlスロバキア語: sk
アラビア語: arギリシャ語: elディベヒ語（モルディブ語）: dvスロベニア語: sl
アルメニア語: hyグジャラート語: guマラーティー語: mrソラニー・クルド語: ckb
バスク語: euハイチ・クレオール語: htネパール語: neスペイン語: es
ベンガル語: bnヘブライ語: iwノルウェー語: noスウェーデン語: sv
ボスニア語: bsヒンディー語: hiオディア語（オリヤー語）: orタガログ語: tl
ブルガリア語: bgヒンディー語（ラテン文字）: hi-Latnパンジャーブ語: paタミル語: ta
ビルマ語（ミャンマー語）: myハンガリー語: huパシュトー語: psテルグ語: te
クロアチア語: hrアイスランド語: isペルシア語: faタイ語: th
カタルーニャ語: caインドネシア語: inポーランド語: plチベット語: bo
チェコ語: csイタリア語: itポルトガル語: pt繁体字中国語: zh-TW
デンマーク語: da日本語: jaルーマニア語: roトルコ語: tr
オランダ語: nlカンナダ語: knロシア語: ruウクライナ語: uk
英語: enクメール語: kmセルビア語: srウルドゥー語: ur
エストニア語: et韓国語: ko簡体字中国語: zh-CNウイグル語: ug
フィンランド語: fiラオス語: loシンド語: sdベトナム語: vi
フランス語: frラトビア語: lvシンハラ語: siウェールズ語: cy
ジョージア語: kaリトアニア語: lt
place:指定した場所名 または X の place ID（例参照）のタグが付いた Posts に一致します。複数語の地名（“New York City”、“Palo Alto”）は引用符で囲んでください。

注: X の place ID の取得方法は、公開 API endpoint の GET geo/search を参照してください。

注: このオペレーターはリツイートには一致しません。リツイートの place は元の Post に付与されるためです。引用ツイートの元の Post に付与された place にも一致しません。
place_country:タグ付けされた place に関連付けられた国コードが、指定の ISO アルファ2文字コードに一致する Posts に一致します。

有効な ISO コードはこちらを参照してください: http://en.wikipedia.org/wiki/ISO_3166-1_alpha-2

注: このオペレーターはリツイートには一致しません。リツイートの place は元の Post に付与されるためです。引用ツイートの元の Post に付与された place にも一致しません。
point_radius:[lon lat radius]存在する場合は Post の厳密な位置（x,y）に対して一致し、また X では「Place」のジオポリゴンに対して、Place が定義された領域内に完全に含まれる場合に一致します。

* サポートされる半径の単位はマイル（mi）とキロメートル（km）です。
* 半径は 25mi 未満である必要があります。
* 経度は ±180 の範囲です。
* 緯度は ±90 の範囲です。
* すべての座標は 10 進数の度です。
* ルール引数は角括弧内に入れ、空白区切りにします。

注: このオペレーターはリツイートには一致しません。リツイートの place は元の Post に付与されるためです。引用ツイートの元の Post に付与された place にも一致しません。
bounding_box:[west_long south_lat east_long north_lat]利用可能なエイリアス: geo_bounding_box:

存在する場合は Post の厳密な位置（long, lat）に対して一致し、また X では「Place」のジオポリゴンに対して、Place が定義された領域内に完全に含まれる場合に一致します。

* west_long と south_lat はバウンディングボックスの南西端を表し、west_long はその点の経度、south_lat は緯度です。
* east_long と north_lat はバウンディングボックスの北東端を表し、east_long はその点の経度、north_lat は緯度です。
* バウンディングボックスの幅と高さは 25mi 未満である必要があります。
* 経度は ±180 の範囲です。
* 緯度は ±90 の範囲です。
* すべての座標は 10 進数の度です。
* ルール引数は角括弧内に入れ、空白区切りにします。
注: このオペレーターはリツイートには一致しません。リツイートの place は元の Post に付与されるためです。引用ツイートの元の Post に付与された place にも一致しません。
profile_country:Profile Geo エンリッチメントの「address」オブジェクトにある「countryCode」フィールドの厳密一致。
ISO-3166-1-alpha-2 仕様に基づく正規化された2文字の国コードを使用します。簡潔にするため、「address」オブジェクトの「country」フィールド用オペレーターの代替として提供されています。
profile_region:Profile Geo エンリッチメントの「address」オブジェクトにある「region」フィールドに一致します。

これは完全一致の厳密な文字列マッチです。バックスラッシュでエスケープする必要はありません。例えば、スラッシュを含むものに一致させる場合は「one/two」を使用し、「one/two」は使用しません。空白や句読点を含む部分文字列に一致させるには二重引用符を使用してください。
profile_locality:Profile Geo エンリッチメントの「address」オブジェクトにある「locality」フィールドに一致します。

これは完全一致の厳密な文字列マッチです。バックスラッシュでエスケープする必要はありません。例えば、スラッシュを含むものに一致させる場合は「one/two」を使用し、「one/two」は使用しません。空白や句読点を含む部分文字列に一致させるには二重引用符を使用してください。
注意: Search API を使用する場合、is: および has: 演算子は単独では使用できず、必ず他の句と組み合わせて使用する必要があります。例: @XDeevelopers has:links
has:geoXから提供されたPost固有の地理的位置データを持つPostsにマッチします。これは「geo」緯度経度座標、またはX “Place”の形式での「location」（対応する表示名、地理的ポリゴン、その他のfieldsを含む）のいずれかです。



注意: Search APIを使用する場合、この演算子はis:またはhas:を含まない他の演算子と組み合わせて使用する必要があります。
has:profile_geo利用可能なエイリアス: has:derived_user_geo

実際の値に関係なく、Profile Geo metadataを持つPostsにマッチします。


注意: Search APIを使用する場合、この演算子はis:またはhas:を含まない他の演算子と組み合わせて使用する必要があります。
has:linksこの演算子は、メッセージ本文にリンクを含むPostsにマッチします。


注意: Search APIを使用する場合、この演算子はis:またはhas:を含まない他の演算子と組み合わせて使用する必要があります。
is:retweetルールにマッチする明示的なリツイートのみを配信します。ルールにマッチするリツイートを配信から除外し、オリジナルコンテンツのみを配信するために否定することも可能です。

この演算子は、Xのリツイート機能を使用する真のリツイートのみを検索します。Xのリツイート機能を使用しない引用TweetsやModified Postは、この演算子ではマッチしません。



注意: Search APIを使用する場合、この演算子はis:またはhas:を含まない他の演算子と組み合わせて使用する必要があります。
is:replyPostsがPostsへの返信であるかどうかに基づいてPostsをフィルタリングする演算子です。ルールにマッチする明示的な返信のみを配信します。ルールにマッチする返信を配信から除外するために否定することも可能です。

この演算子は有料のプレミアムおよびEnterprise検索で利用可能であり、Sandbox開発環境では利用できないことにご注意ください。



注意: Search APIを使用する場合、この演算子はis:またはhas:を含まない他の演算子と組み合わせて使用する必要があります。
is:quotePostペイロードの”is_quote_status”:trueで識別される、別のPostを参照するPostsである引用Tweetsのみを配信します。引用Tweetsを除外するために否定することも可能です。

注意: Search APIを使用する場合、この演算子はis:またはhas:を含まない他の演算子と組み合わせて使用する必要があります。
is:verified作成者がXによって「認証済み」であるPostsのみを配信します。作成者が認証済みであるPostsを除外するために否定することも可能です。


注意: Search APIを使用する場合、この演算子はis:またはhas:を含まない他の演算子と組み合わせて使用する必要があります。
has:mentions別のXユーザーをメンションするPostsにマッチします。


注意: Search APIを使用する場合、この演算子はis:またはhas:を含まない他の演算子と組み合わせて使用する必要があります。
has:hashtagsハッシュタグを含むPostsにマッチします。


注意: Search APIを使用する場合、この演算子はis:またはhas:を含まない他の演算子と組み合わせて使用する必要があります。
has:media利用可能なエイリアス: has:media_link

Xによって分類されたメディアURLを含むPostsにマッチします。例：pic.x.com。


注意: Search APIを使用する場合、この演算子はis:またはhas:を含まない他の演算子と組み合わせて使用する必要があります。
has:imagesXによって分類されたメディアURLを含むPostsにマッチします。例：pic.x.com。


注意: Search APIを使用する場合、この演算子はis:またはhas:を含まない他の演算子と組み合わせて使用する必要があります。
has:videos利用可能なエイリアス: has:video_link

Xに直接アップロードされたネイティブXビデオを含むPostsにマッチします。これはVine、Periscope、または他のビデオホスティングサイトへのリンクを含むPostsで作成されたビデオにはマッチしません。


注意: Search APIを使用する場合、この演算子はis:またはhas:を含まない他の演算子と組み合わせて使用する必要があります。
has:symbolsキャッシュタグシンボル（先頭に「」文字を含む。例：」文字を含む。例：tag）を含むPostsにマッチします。この演算子はEnterprise検索APIでのみ利用可能であることにご注意ください。


注意: Search APIを使用する場合、この演算子はis:またはhas:を含まない他の演算子と組み合わせて使用する必要があります。

​
製品概要

Enterprise ティアの Full-archive Search は 2015 年 8 月に、premium ティア版は 2018 年 2 月にリリースされました。これらの検索製品により、顧客は公開されている任意の Post に即時アクセスできます。Full-archive Search では、単一の query を送信し、クラシックな RESTful 方式でレスポンスを受け取ります。Full-archive Search は、1 レスポンスあたり最大 500 件の Posts のページネーションを実装し、premium では最大 60 リクエスト/分 (rpm)、enterprise では 120 rpm のレート制限をサポートします。これらの点から、Full-archive Search は高速かつ同時リクエストにより大規模な Post を迅速に取得できます。 ディスク上の Post フラットファイル群をアーカイブとする Historical PowerTrack とは異なり、Full-archive Search の Post アーカイブはオンラインデータベースに類似しています。すべてのデータベースと同様に、その内容に対してクエリを実行できます。また、高速なデータ取得を実現するために index を利用します。Full-archive Search の endpoint では、クエリ言語は PowerTrack Operators で構成され、各 Operator はインデックスされた Post の JSON 属性に対応します。 また、Historical PowerTrack と同様に、query 実行時点での Post 属性も存在します。たとえば、今日 Search API を使用して 2010 年に投稿された Post にアクセスする場合、ユーザーのプロフィールの説明、アカウントの「home」ロケーション、表示名、そして Favorites および リツイート 数の Post の metrics は、2010 年当時ではなく現在の値に更新されます。 

​
メタデータのタイムライン

以下は、Full-archive search endpoint の Operator がマッチングを開始した時期のタイムラインです。場合によっては、X 上で「コミュニケーション慣行」が一般化してからかなり経って、Operator のマッチングが始まったケースもあります。たとえば、@Replies は 2006 年にユーザー慣行として登場しましたが、「サポートする」JSON を伴う「第一級オブジェクト」または「イベント」として扱われるようになったのは 2007 年初頭です。したがって、2006 年に @Replies をマッチングするには、to: や in_reply_to_status_id: といった PowerTrack Operators に依存するのではなく、Post 本文を精査する必要があります。 ここに示す詳細は、Full-Archive Search（数百件の検索を通じて得られた成果）を用いて作成しました。このタイムラインは 100% 完全でも厳密でもありません。ユースケースにとって重要となる、別のフィルタリングやメタデータの「発生日」を確認された場合は、ぜひお知らせください。 なお、基盤となる Search インデックスは再構築される可能性があります。したがって、これらのタイムラインの詳細は変更される場合があります。

​
2006

  • 3月26日 - lang:。Search インデックス生成時に Post の metadata がバックフィルされる例。
  • 7月13日 - has:mentions のマッチングが開始。
  • 10月6日 - has:symbols。株式の銘柄記号について議論するための cashtags（またはsymbols）が一般化するのは2009年初頭以降。それまでは用法の多くがおそらくスラング（例:cashtags（または symbols）が一般化するのは2009年初頭以降。それまでは用法の多くがおそらくスラング（例: slang）だった。
  • 10月26日 - has:links のマッチングが開始。
  • 11月23日 - has:hashtags のマッチングが開始。

​
2007

  • 1月30日 - 初の本格的な @reply（in_reply_to_user_id）。reply_to_status_id: のマッチングが開始。
  • 8月23日 - トピックや会話を整理する一般的な慣習としてハッシュタグが登場。1週間後に初の本格的な利用例が現れる。

​
2009

  • 5月15日 - is:retweet。このオペレーターは、公式リツイートのベータ版リリースおよび「Via @」パターンの導入時点からマッチし始めます。ベータ期間中は、Post の動詞は「post」で、元の Post はペイロードに含まれません。
  • 8月13日 - 公式リツイートの最終版が、「RT @」パターン、動詞「share」の設定、そして元の Post を含む retweet_status 属性とともにリリースされました（その結果、JSON ペイロードのサイズはおおよそ2倍になります）。

​
2010

  • 3月6日 - has:geo、bounding_box:、point_radius: のジオ演算子によるマッチングを開始。
  • 8月28日 - has:videos（2015年2月まで、この演算子は youtube.com、vimeo.com、vivo.com など特定の動画ホスティングサイトへのリンクを含む Posts にマッチします）。

​
2011

  • 7月20日 - has:media と has:images の一致が開始。ネイティブ写真は2010年8月9日に正式発表。

​
2014

  • 12月3日 - （概ね）一部の Enhanced URL metadata が、HTML の title と description を含む形でペイロードに含まれ始めました。強化されたメタデータは 2016年5月に、より充実した形で本格的に導入されました。

​
2015

  • 2月10日 - has:videos はXのネイティブ動画に一致します。
  • 2月17日 - has:profile_geo、profile_country:、profile_region:、profile_locality: Profile Geo オペレーターのマッチングが開始されます。
  • 2月17日 - place_country: および place: のPostジオオペレーターのマッチングが開始されます。

​
2016

  • 5月1日 - Enhanced URL metadata が広く利用可能になり、2016年8月の Gnip 2.0 のローンチ の一部として正式に発表されました。Search API には、これらの metadata に対応する Operators はありません。

​
2017

  • 2月22日 - 投票のmetadataが拡張ネイティブ形式で利用可能になりました。これらのmetadataに対応する演算子（Operator）はありません。

​
2022

  • 9月27日 - この日以降に作成されたすべての Post オブジェクトでは、編集済み Post の metadata が利用可能になりました。Post オブジェクトを返すすべての Enterprise endpoint は、この日から当該 metadata を提供するよう更新されました。提供される編集 metadata には、edit_history と edit_controls のオブジェクトが含まれます。これらの metadata は、2022年9月27日以前に作成された Posts については返されません。現在、これらの metadata に対応する Enterprise Operators は提供されていません。Edit Post metadata の詳細は、Edit Posts fundamentals ページをご覧ください。

​
2022

  • 9月29日 - この日以降に作成されたすべての Post オブジェクトで、編集済み Post のメタデータが利用可能になりました。Post オブジェクトを提供するすべての Enterprise endpoint は、この日から当該メタデータを提供するよう更新されました。提供される編集メタデータには、edit_history と edit_controls の各オブジェクトが含まれます。これらのメタデータは、2022年9月27日以前に作成された Posts には返されません。現在、これらのメタデータに対応する Enterprise Operators は提供されていません。Edit Post メタデータの詳細は、Edit Posts fundamentals ページをご覧ください。

​
フィルタリングのヒント

ここまでのタイムライン情報を踏まえると、Search API のフィルター作成時には多くの細かな点を考慮する必要があることがわかります。特に重要なポイントは次の2点です。
  • 一部の metadata には「適用開始日」があるため、フィルターによっては偽陰性が発生する場合があります。これは、検索期間の全部または一部で存在していなかった metadata に依存する Operator を使った検索に当てはまります。たとえば、has:images Operator で Posts を検索する場合、2011年7月より前の期間には一致はありません。これは、その Operator が「ネイティブ」写真（X の UI を使って Post に添付された写真）にのみ一致するためです。写真共有の Posts をより網羅的に取得するには、2011年7月以前を対象とするフィルターに、一般的な写真ホスティングの URL に一致するルール句を含める必要があります。
  • 一部の metadata は、X に Post された時点より後に得られた情報でバックフィルされています。
PowerTrack クエリを作成する際に、一般的に注目される属性タイプはいくつかあります。
  • X Profiles
  • オリジナルの Post か共有された Post か
  • Post の言語分類
  • ジオリファレンスされた Posts
  • 共有リンクのメディア
これらの一部はプロダクト固有の挙動があり、他は同一の挙動です。詳細は以下を参照してください。

​
X プロフィール

Search API は、取得時点 のユーザープロフィールのデータセットとともに、過去の Posts を提供します。たとえば 2014 年の Post をリクエストした場合でも、ユーザーのプロフィール metadata は query 時点の状態を反映します。

​
オリジナルのPostsとリツイート

PowerTrack の _is:retweet_ 演算子を使うと、リツイートを含めるか除外するかを指定できます。この演算子を利用する場合、2009年8月以前のデータについては、リツイートの判定（含める／含めない）に関して2つの戦略が必要です。2009年8月以前は、Post本文に対して厳密なフレーズ一致で “@RT ” パターンがあるかを確認する必要があります（実際には、2009年5月〜8月の期間のリツイートをフィルタリングする場合は “Via @” パターンも含める必要があります）。2009年8月以降は、_is:retweet_ 演算子が利用可能です。

​
Post の言語分類

Post の言語分類でフィルタリングする場合、X の旧来製品では事情が大きく異なります。Search アーカイブの構築時に、すべての Post に X の言語分類がバックフィルされました。したがって、lang: オペレーターは Post アーカイブ全体で利用できます。

​
Posts のジオリファレンス

Posts をジオリファレンスする主な方法は3つあります。
  • Post メッセージ内の地理的参照。 Post メッセージ内の地理的参照に基づいて一致（マッチ）させる方法は、地域知識に依存するため最も難しい手法になりがちですが、Post アーカイブ全体に対して利用可能な選択肢です。サンフランシスコ地域を対象に「golden gate」フィルターに基づいた、2006年のジオリファレンス済み一致例はこちらです。
  • ユーザーによってジオタグが付与された Posts。 検索 APIs では、いくつかの Geo Operators による Posts のマッチング機能が2010年3月に、その他が2015年2月に利用可能になりました。
    • 2010年3月6日: has:geo、bounding_box:、point_radius:
    • 2015年2月17日: place_country:、place:
  • ユーザーが設定したアカウントプロフィールの「home」ロケーション。 Profile Geo Operators は Historical PowerTrack と Search APIs の両方で利用可能です。Search APIs では、これらの Profile Geo metadata は2015年2月から利用可能です。Profile Geo metadata が利用可能になる前に投稿された Posts については、正規化されていないユーザー入力に対してマッチングできる bio_location: Operator を使用できます。
2012年3月に、Expanded URLs エンリッチメントが導入されました。それ以前は、Post のペイロードにはユーザーが入力した URL のみが含まれていました。そのため、ユーザーが短縮 URL を含めた場合、関心のある（展開済みの）URL と照合するのが難しいことがありました。Search APIs では、これらの metadata は2012年3月から利用可能です。 2016年7月に、Enhanced URLs エンリッチメントが導入されました。この拡張版では、Post のペイロード内にウェブサイトの HTML タイトルと説明が提供され、それらにマッチさせるための Operators も利用できます。これらの metadata は2014年12月から出現し始めています。 2016年9月、X は「ネイティブ添付」を導入し、文末の共有リンクが Post の140文字制限にカウントされなくなりました。これらの共有リンクには、両方の URL エンリッチメントが引き続き適用されます。 関連する Search Operators がマッチし始める時期は次のとおりです:
  • 2006年10月26日 - has:links
  • 2011年7月20日 - has:images および has:media
  • 2011年8月 - url: と Expanded URLs enrichment。2006年9月の早い時期から、(url:"spotify.com" OR url:gnip OR url:microsoft OR url:google OR url:youtube) は http://x.com/Adam/statuses/16602 にマッチします。これは、twitter_entities と gnip オブジェクトに urls[] metadata が存在しない場合でも同様です。「youtube.com」は、urls[] metadata がまったくなくても url:youtube にマッチするメッセージ内容の例です。
  • 2015年2月10日 - ネイティブ動画向け has:videos。2010/08/28 から 2015/02/10 の間、この Operator は youtube.com、vimeo.com、vivo.com などの特定の動画ホスティングサイトへのリンクを含む Posts にマッチします。
  • 2016年5月1日 - Enhanced URLs enrichment に基づく url_title: と url_description: が一般提供。最初の Enhanced URL metadata は2014年12月に出現し始めました。

​
よくあるご質問（FAQ）

​
Search Post API に関する一般的な質問

counts endpoint と data endpoint が返す結果には既知の差があります。counts endpoint は配信前のコンプライアンス適用前（削除された Posts や位置情報のスクラブなどを反映しない）であるのに対し、data endpoint は配信時点でコンプライアンスに準拠し、すべてのコンプライアンスイベントを反映するため、結果に食い違いが生じる場合があります。
これが起き得る理由はいくつか考えられます。たとえば、次のような場合です。
  1. 期待していたPostが保護アカウントの投稿である
  2. data endpointがすべてのコンプライアンスイベントを考慮するため（つまり、削除されたPostsやスクラブされた位置情報などはレスポンスに含まれません）
これは、Premium のルールとフィルタリングの不適切な使用が原因である可能性があります。ドキュメントはこちらを確認し、ルール作成に関する制限事項を十分に理解してください。
はい、以下が含まれます。
  • Tweepy - 標準の検索/Posts プロダクトの利用に適しています（Python）
  • X API - 標準の Search Post API の利用に適しています（Python）
  • Search Posts Python および Search Posts Ruby - Enterprise（および v2）向けの Search Post API に利用できる有用な 2 つのツールです
当社が直接サポートしているライブラリはすべて、当社の xdevplatform の GitHub ページに掲載しています: https://github.com/xdevplatform。他のサードパーティ製ライブラリ も有用な場合がありますが、一部は当社の Premium および Enterprise プロダクトでは動作しない可能性がある点にご留意ください。
はい。data endpoint では、指定した maxResults に達するか、30 日が経過した時点でページネーションが行われます。たとえば、ある 30 日間に 800 件の Posts がある場合、完全な結果を取得するには 2 回のリクエストが必要です。1 回のリクエストで返せる Posts の最大数は 500（maxResults）であるためです。また、1 か月目に 400 件の Posts、2 か月目に 100 件の Posts がある場合でも、完全な結果を取得するには 2 回のリクエストが必要です。これは、最初のリクエストの返却数が指定した maxResults 未満であっても、ページネーションは 30 日の期間後に実行されるためです。
Posts は新しい順（逆時系列）で返されます。たとえば、最初のページには query に一致する最新の Posts が表示され、ページネーションは結果の投稿日時が最初にリクエストした fromDate に到達するまで続きます。
請求の対象となるのは元のPostのみです。以降の編集は無視され、全体のアクティビティ件数には反映されません。Enterprise
当社のEnterpriseソリューションは、貴社のビジネスニーズに合わせてカスタマイズされ、予測可能な料金でご提供します。詳細はこちらからお申し込みください。
  • Enterprise の Search Post API のドキュメントはこちらをご参照ください
  • ルールおよびフィルタリングに関する有用な情報はこちらをご覧ください
  • data endpoint の利用方法に関する有用な情報はこちらをご覧ください
  • counts endpoint の利用方法に関する有用な情報はこちらをご覧ください
  • 利用可能な operators の一覧はこちらをご覧ください
この件については、Xのアカウントマネージャーまでご連絡ください。対応いたします。

​
エラーのトラブルシューティングガイド

コード 404 - Not Found
  1. 各 endpoint で適切なパラメータを使用しているか確認してください（例: buckets フィールドは counts endpoint でのみ使用でき、data endpoint では使用できません）
  2. :product、:account_name、:label の各 fields が正しいか再確認してください。:label フィールドは GNIP Console（Enterprise 顧客のみ）で確認できます。

​
API リファレンス

​
Enterprise search APIs

Enterprise 検索 API には 2 種類があります:
  • 30-Day Search API - 直近 30 日間に投稿された Tweet を提供します。
  • Full-Archive Search API - 2006 年 3 月に投稿された最初の Tweet から、2006 年まで遡る Tweet を提供します。
これらの検索 API は共通設計で、以下のドキュメントは両方に適用されます。なお、2022 年 9 月 29 日以降に作成された Tweet には、編集履歴を示す Tweet の編集 metadata が Tweet オブジェクトに含まれます。詳細は “Edit Tweets” の基礎ページを参照してください。 以下は、Enterprise 検索 API と統合する際に必要な重要事項です:
  • Tweet データおよび件数を取得する方法
  • 認証
  • ページネーション
  • API リクエストパラメータとリクエスト例
  • API レスポンスの JSON ペイロードとレスポンス例
  • HTTP レスポンスコード
Enterprise API は、低レイテンシで完全忠実な、query ベースの Tweet アーカイブへのアクセスを提供します。2 つの API の唯一の違いは検索可能な期間で、直近 30 日間か、2006 年まで遡るかのいずれかです。期間は分単位で指定できます。Tweet データは、query に一致する最新の Tweet から始まる新しい順で提供されます。Tweet は、公開後およそ 30 秒で検索 API から利用可能になります。

​
Methods

Enterprise 検索のベース URI は https://gnip-api.x.com/search/ です。
MethodDescription
POST /search/:product/accounts/:account_name/:label指定した PowerTrack ルールに一致する過去 30 日間の Tweet を取得します。
POST /search/:product/accounts/:account_name/:label/counts指定した PowerTrack ルールに一致する過去 30 日間の Tweet の件数を取得します。
Where:
  • :product は、リクエスト先の検索 endpoint を示し、30day または fullarchive のいずれかです。
  • :account_name は、console.gnip.com に表示される、アカウントに関連付けられた（大文字小文字を区別する）名前です。
  • :label は、console.gnip.com に表示される、検索 endpoint に関連付けられた（大文字小文字を区別する）ラベルです。
例えば、TwitterDev アカウントがラベル ‘prod’（production の略）付きの 30 日間検索プロダクトを利用している場合、検索 endpoint は次のとおりです。 Enterprise 検索の完全な API endpoint は https://console.gnip.com に表示されます。 以下に、curl というシンプルな HTTP ユーティリティを使用したリクエスト例をいくつか示します。これらの例では、:product、:account_name、:label を含む URL を使用しています。これらの例を利用する際は、URL を必ずご自身の情報に更新してください。

​
認証

Enterprise 検索 API へのすべてのリクエストは、https://console.gnip.com のアカウントにログインする際に使用する有効なメールアドレスとパスワードの組み合わせで構成される HTTP の Basic Authentication を使用する必要があります。認証情報は、各リクエストの Authorization ヘッダーとして送信する必要があります。

​
リクエスト/レスポンスの動作

fromDate と toDate パラメータを使用すると、API がサポートする任意の期間をリクエストできます。30-Day search API は直近31日分の Tweet を提供します（「30-Day」API と呼称されていますが、完全な月単位のリクエストを可能にするため31日分を利用できます）。Full-Archive search API は最初の Tweet（2006年3月21日）まで遡って提供します。ただし、1 回のレスポンスは、指定した ‘maxResults’ と 31 日のうち小さい方に制限されます。マッチする data や指定した期間が maxResults または 31 日を超える場合、残りの期間をページネートするために使用する ‘next’ トークンが返されます。 例えば、Full-Archive search を使用し、2017年1月1日から2017年6月30日までの間で、query にマッチするすべての Tweet を取得したいとします。fromDate と toDate パラメータで、その 6 か月間の全期間をリクエストに指定します。search API は最初の「ページ」の Tweet を、maxResults パラメータ（デフォルトは 100）に一致する件数で返します。さらに Tweet が存在する場合（多くの場合、存在します）、API は次の「ページ」の data をリクエストできるようにする ‘next’ トークンも返します。このプロセスは、API が ‘next’ トークンを返さなくなるまで繰り返されます。詳細は次のセクションをご覧ください。 data リクエストと count リクエストの両方を行う場合、単一のレスポンスで返しきれないデータ量になることがあります。その際は、レスポンスに「next」トークンが含まれます。「next」トークンはルートレベルの JSON 属性として提供されます。「next」トークンが含まれている場合は、取得すべきデータがまだあるため、引き続き API リクエストを実行してください。 注: 「next」トークンの挙動は data リクエストと counts リクエストでわずかに異なります。両者については以下で説明しており、API Reference セクションに例示的なレスポンスが掲載されています。
データのページネーション
データのリクエストでは、1 回のレスポンスで返せる量を超えるデータが生成される場合があります。各データリクエストには、1 リクエストあたりに返す Tweet の最大数を設定するパラメータが含まれています。この maxResults パラメータの既定値は 100 で、10〜500 の範囲で設定できます。リクエストで指定した ‘maxResults’ を超える数の Tweet が query に一致した場合、レスポンスには（ルートレベルの JSON 属性として）‘next’ トークンが含まれます。この ‘next’ トークンは、次のリクエストでその query に一致する Tweet の次の部分（つまり次の「ページ」）を取得するために使用されます。‘next’ トークンは、その query の結果の最後の「ページ」に到達し ‘next’ トークンが返されなくなるまで提供され続けます。 次の「ページ」のデータを要求するには、（使用している場合は）query、toDate、fromDate パラメータを含め、元のものとまったく同一の query を実行し、さらに前回のレスポンスで返された値を設定した ‘next’ リクエストパラメータも含める必要があります。これは GET または POST のいずれのリクエストでも利用できます。ただし、GET リクエストの場合は ‘next’ パラメータを URL エンコードする必要があります。 query で対象とする期間内のすべての Tweet を取得し終えるまで、前回のレスポンスで返された ‘next’ 要素を引き続き渡せます。‘next’ 要素を含まないレスポンスを受け取った場合は、最後のページに到達しており、指定した query と時間範囲に対して利用可能な追加データはありません。
カウントのページネーション
‘counts’ endpoint は、query に紐づく Tweet のボリュームを日次・時間別・分単位のいずれかで提供します。‘counts’ API endpoint は、最大31日分のカウントを含む、タイムスタンプ付きのカウント配列を返します。31日を超える期間のカウントを要求した場合は、‘next’ トークンが付与されます。data の ‘next’ トークンと同様に、元のものとまったく同一の query を再実行し、前回のレスポンスで返された値を設定した ‘next’ リクエストパラメータを必ず含めてください。 31日を超えるカウントを要求する場合以外にも、‘next’ トークンが返されるシナリオがあります。高ボリュームの query では、カウントの生成に時間がかかり、レスポンスのタイムアウトが発生する可能性があります。この場合は31日未満のカウントしか返されませんが、全期間分のカウントを取得し続けるために ‘next’ トークンが提供されます。重要: タイムアウト時には「バケット」は常に完全な単位でのみ返されます。たとえば 2.5 日分であれば、2 日分の完全な「バケット」になります。
追記事項
  • 検索リクエストで fromDate または toDate を使用する場合、指定した時間範囲内の結果のみが返されます。時間範囲内の最後の結果グループに到達すると、“next” トークンは返されません。
  • “next” 要素は、10〜500 の任意の maxResults 値で使用できます（デフォルト値は 100）。maxResults は各レスポンスで返される Tweet の数を決定しますが、最終的にすべての結果を取得することは可能です。
  • “next” 要素には有効期限がありません。同じ “next” query を使用した複数のリクエストは、リクエストの実行タイミングに関係なく同じ結果を受け取ります。
  • “next” パラメータで結果をページングする際、query の境界付近で重複が発生する場合があります。これらに対してアプリケーションは許容できるようにしておいてください。

​
Data endpoint

POST /search/:product/:label
endpoint パターン:
この endpoint は、指定した query と期間に対する data を返します。期間を指定しない場合、時間パラメータは直近30日間が既定値になります。注: 以下で説明するパラメータを URL にエンコードすれば、POST ではなく GET リクエストでも同等の処理が行えます。
データリクエストのパラメータ
パラメータ説明必須サンプル値
query1つの PowerTrack ルールに相当し、最大 2,048 文字まで（肯定・否定の節の数に制限はありません）。

このパラメータには演算子を含む PowerTrack ルールの全要素をすべて含めてください。ルールの一部を分割して query の別のパラメータに渡さないでください。

注: すべての PowerTrack 演算子がサポートされているわけではありません。サポートされる演算子はこちらに一覧があります。		はい(snow OR cold OR blizzard) weather
tagルールおよびその一致データを、論理的なグループに分けるために使用できるタグです。ルールタグが指定された場合、そのタグは ‘matching_rules’ 属性に含まれます。

クライアント側で望ましいマッピングを維持できるよう、ルールごとの UUID をタグに割り当てることを推奨します。		いいえ8HYG54ZGTU
fromDateTweets が提供される最も古い UTC タイムスタンプ（Full-Archive 検索では 2006/3/21 まで遡れます）。タイムスタンプは分単位で、包含的です（例: 12:00 は 00 分を含みます）。

指定あり: fromDate のみを指定し、toDate を指定しない場合、結果は now() から過去に遡って fromDate までの query の結果が返されます。

未指定: fromDate を指定しない場合、API は now() または toDate（指定されている場合）から過去 30 日分のすべての結果を返します。

fromDate と toDate のいずれも使用しない場合、API はリクエスト時点から過去に遡る形で、直近 30 日間のすべての結果を返します。		いいえ201207220000
toDateTweets が提供される最新の UTC タイムスタンプ。タイムスタンプは分単位で、非包含的です（例: 11:59 はその時間の 59 分を含みません）。

指定あり: toDate のみを指定し、fromDate を指定しない場合、toDate より前の直近 30 日分のデータが返されます。

未指定: toDate を指定しない場合、API は now() から過去に遡って fromDate までの query のすべての結果を返します。

fromDate と toDate のいずれも使用しない場合、API はリクエスト時点から過去に遡る形で、30 日インデックス全体のすべての結果を返します。		いいえ201208220000
maxResultsリクエストで返される検索結果の最大件数。10 からシステム上限（現在 500）までの数値。既定では、レスポンスは 100 件の結果を返します。いいえ500
nextこのパラメータは、こちらに記載のとおり、次の「ページ」の結果を取得するために使用します。パラメータの値は API のレスポンスからそのまま取得し、変更しないでください。いいえNTcxODIyMDMyODMwMjU1MTA0
追加詳細
利用可能な期間30-Day: 直近31日間
Full-Archive: 2006年3月21日〜現在
query の形式PowerTrack ルール1件分に相当し、最大2,048文字まで（肯定・否定の節の数に制限はありません）。

注: すべての PowerTrack 演算子がサポートされているわけではありません。サポート対象の演算子は Available operators を参照してください。
レートリミットパートナーには、分単位および秒単位の両方の粒度でレートリミットが適用されます。1分あたりのレートリミットは契約で指定されたとおりパートナーごとに異なります。ただし、これらの1分あたりのレートリミットを単一のバーストで使うことは想定していません。1分あたりのレートリミットにかかわらず、すべてのパートナーは、data および/または counts へのすべてのリクエストを合算して、1秒あたり最大20リクエストに制限されます。
コンプライアンスFull-Archive Search API で配信されるすべての data は、配信時点でコンプライアンスに準拠しています。
リアルタイム可用性データは、Twitter プラットフォーム上で生成後30秒以内にインデックスで利用可能になります
data フィールドのリクエストとレスポンス例
POST リクエストの例
  • POST リクエストのパラメータは、以下のように JSON 形式のボディで送信されます。
  • 取得対象の PowerTrack ルールのすべての要素（例: キーワード、bounding_box: のような他のオペレーター）は、‘query’ パラメータに含めてください。
  • ルールの要素を分割して、query URL の個別パラメータとして渡さないでください。
初回のデータリクエストを行うための POST（cURL 使用）コマンドの例を以下に示します。 
    curl -X POST -u<username> "https://gnip-api.x.com/search/:product/accounts/:account_name/:label.json" -d '{"query":"from:twitterDev","maxResults":500,"fromDate":"yyyymmddhhmm","toDate":"yyyymmddhhmm"}'
API の data レスポンスに「next」トークンが含まれている場合、以下は、提供されたトークンを「next」パラメータに設定した上で元のリクエストを踏襲した、続きのリクエスト例です。 
    curl -X POST -u<username> "https://gnip-api.x.com/search/:product/accounts/:account_name/:label.json" -d '{"query":"from:twitterDev","maxResults":500,"fromDate":"yyyymmddhhmm","toDate":"yyyymmddhhmm",
    "next":"NTcxODIyMDMyODMwMjU1MTA0"}'
GET リクエストの例
  • GET リクエストのパラメータは、標準的な URL エンコードで URL にエンコードされます。
  • 取得対象の PowerTrack ルールの要素（例: キーワード、bounding_box: のような他のオペレーター）はすべて、‘query’ パラメータに含めてください。
  • ルールの一部を分割して、query URL 内で個別のパラメータとして指定しないでください。
以下は、初回の data リクエストを行うための GET（cURL 使用）コマンドの例です。 
    curl -u<username> "http://gnip-api.x.com/search/:product/accounts/:account_name/:label.json?query=from%3Atwitterdev&maxResults=500&fromDate=yyyymmddhhmm&toDate=yyyymmddhhmm"
例のdataレスポンス
2022年9月29日以降に作成されたTweetには、編集履歴を示すTweetの編集metadataがTweetオブジェクトに含まれます。詳細は「Edit Tweets」の基礎ページを参照してください。 以下は、dataのqueryに対するレスポンス例です。この例では、利用可能なTweetが「maxResults」を超えているため、後続のリクエスト用に’next’トークンが提供されることを想定しています。queryに関連付けられたTweetが「maxResults」以下の場合、レスポンスに’next’トークンは含まれません。 ‘next’要素の値はqueryごとに変化し、不透明な文字列として扱う必要があります。レスポンス本文中の’next’要素は次のようになります。 
{
    "results":
      [
            {--Tweet 1--},
            {--Tweet 2--},
            ...
            {--Tweet 500--}
      ],
    "next":"NTcxODIyMDMyODMwMjU1MTA0",
    "requestParameters":
      {
        "maxResults":500,
        "fromDate":"201101010000",
        "toDate":"201201010000"
      }
  }
後続のリクエストに対するレスポンスは次のようになります（新しい Tweet と異なる「next」値に注目してください）: 
{
      "results":
      [
            {--Tweet 501--},
            {--Tweet 502--},
            ...
            {--Tweet 1000--}
      ],
      "next":"R2hCDbpBFR6eLXGwiRF1cQ",
      "requestParameters":
      {
        "maxResults":500,
        "fromDate":"201101010000",
        "toDate":"201201010000"
      }
  }
前のqueryから返された「next」要素を渡し続けることで、queryで指定した期間内のすべてのTweetを取得するまでページネーションを進められます。レスポンスに「next」要素が含まれていない場合は、最後のページに到達しており、その期間内で利用可能な追加のdataはありません。

​
Counts endpoint

/search/:stream/counts
endpoint パターン:
/search/fullarchive/accounts/:account_name/:label/counts.json この endpoint は、指定された query に対する件数（データボリューム）を返します。期間を指定しない場合、時間パラメータは直近30日がデフォルトになります。データボリュームは、日単位、時間単位（デフォルト）、または分単位のいずれかで、タイムスタンプ付き配列として返されます。 注: 以下のパラメータを URL にエンコードすることで、POST の代わりに GET リクエストを使用して同等の機能を実行できます。
カウントリクエストのパラメータ
Parameters説明必須サンプル値
query最大 2,048 文字の 1 件の PowerTrack ルールに相当します（肯定・否定の節の数に制限はありません）。

このパラメータには、すべてのオペレーターを含む PowerTrack ルールの全要素を含める必要があり、ルールの一部を query の他のパラメータに分割しないでください。

注: すべての PowerTrack オペレーターがサポートされているわけではありません。サポート対象のオペレーター一覧は Available operators を参照してください。		Yes(snow OR cold OR blizzard) weather
fromDateTweets が提供される最古の UTC タイムスタンプ（2006/03/21 まで）。タイムスタンプは分単位の粒度で、包含です（例: 12:00 は 00 分を含みます）。

指定あり: fromDate のみを指定し、toDate パラメータを指定しない場合、API は現在から fromDate まで遡る期間について、query のカウント（データ量）を返します。fromDate が現在から 31 日より前の場合、ページング用の next トークンが返されます。

未指定: fromDate を指定しない場合、API は現在（ ）または toDate（指定されている場合）の 30 日前までのカウント（データ量）を返します。

fromDate と toDate のいずれも指定しない場合、API はリクエスト時点から過去に遡って直近 30 日間のカウント（データ量）を返します。		No201207220000
toDateTweets が提供される直近の（最新の）UTC タイムスタンプ。タイムスタンプは分単位の粒度で、非包含です（例: 11:59 はその時間の 59 分目を含みません）。

指定あり: toDate のみを指定し、fromDate パラメータを指定しない場合、toDate の 30 日前までの直近のカウント（データ量）を返します。

未指定: toDate を指定しない場合、API は query のカウント（データ量）を fromDate まで遡って返します。fromDate が現在から 31 日より前の場合、ページング用の next トークンが返されます。

fromDate と toDate のいずれも指定しない場合、API はリクエスト時点から過去に遡って直近 30 日間のカウント（データ量）を返します。		No201208220000
bucketカウントデータを提供する時間単位。指定期間内の日・時・分ごとのカウントデータを返せます。既定では時間単位のカウントが提供されます。オプション: ‘day’, ‘hour’, ‘minute’Nominute
nextHERE に記載のとおり、次の「ページ」の結果を取得するためのパラメータです。このパラメータに指定する値は API のレスポンスからそのまま取得し、変更しないでください。NoNTcxODIyMDMyODMwMjU1MTA0
追加の詳細
利用可能な期間30-Day: 直近31日間
Full-Archive: 2006年3月21日〜現在
Query FormatPowerTrack ルール1件分に相当し、最大2,048文字まで。

注: すべての PowerTrack 演算子がサポートされているわけではありません。サポート対象の演算子は Available operators を参照してください。
Rate Limitパートナーには分単位および秒単位の両方の粒度でレートリミットが適用されます。分あたりのレートリミットは、契約で規定されたとおりパートナーごとに異なります。ただし、これらの分あたりのレートリミットは単発のバーストで使うことを想定していません。分あたりのレートリミットに関わらず、すべてのパートナーは data および/または counts に対する全リクエストを合算して、1秒あたり最大20リクエストに制限されます。
Count Precisionこの endpoint を通じて提供されるカウントは、発生した Tweet の数を反映しており、後続のコンプライアンスイベント（削除、scrub_geo）を反映しません。カウントに含まれる一部の Tweet は、ユーザーのコンプライアンス対応により data endpoint からは取得できない場合があります。
例: counts リクエストとレスポンス
POST リクエストの例
  • 以下のとおり、POST リクエストのパラメータは JSON 形式のボディで送信します。
  • 取得対象の PowerTrack ルールの内容（例: キーワードや bounding_box: のような他のオペレーター）は、すべて ‘query’ パラメータに含めてください。
  • ルールの一部を分割して、query URL 上の別個のパラメータとして指定しないでください。
初回のカウントリクエストを行うための POST（cURL 使用）コマンド例は以下のとおりです。 
    curl -X POST -u<username> "https://gnip-api.x.com/search/:product/accounts/:account_name/:label/counts.json" -d '{"query":"TwitterDev","fromDate":"yyyymmddhhmm","toDate":"yyyymmddhhmm","bucket":"day"}'
API の counts レスポンスに「next」トークンが含まれている場合、以下は元のリクエストに対し、提供されたトークンを「next」パラメータに設定した後続リクエストの例です。 
    curl -X POST -u<username> "https://gnip-api.x.com/search/:product/accounts/:account_name/:label/counts.json" -d '{"query":"TwitterDev","fromDate":"yyyymmddhhmm","toDate":"yyyymmddhhmm","bucket":"day",
    "next":"YUcxO87yMDMyODMwMjU1MTA0"}'
GET リクエストの例
  • GET リクエストのパラメータは、標準的な URL エンコードで URL に埋め込まれます
  • 取得対象の PowerTrack ルールの要素（例: キーワードや bounding_box: などのオペレーター）は、すべて ‘query’ パラメータに含めてください
  • ルールの構成要素をクエリ URL 内で別個のパラメータに分割しないでください
以下は、初回の件数取得リクエストを行うための GET（cURL 使用）コマンド例です: 
    curl -u<username> "http://gnip-api.x.com/search/fullarchive/accounts/:account_name/:label/counts.json?query=TwitterDev&bucket=day&fromDate=yyyymmddhhmm&toDate=yyyymmddhhmm"

​
例: counts レスポンス

以下は、counts（データ量）query へのレスポンス例です。このレスポンス例には「next」トークンが含まれており、counts リクエストの対象期間が31日を超えているか、送信された query に関連付けられたボリュームが大きいために部分的なレスポンスが返されたことを意味します。 「next」要素の値は query ごとに変化し、不透明な文字列として扱う必要があります。レスポンス本文では「next」要素は次のように示されます: 
    {
      "results": [
        { "timePeriod": "201101010000", "count": 32 },
        { "timePeriod": "201101020000", "count": 45 },
        { "timePeriod": "201101030000", "count": 57 },
        { "timePeriod": "201101040000", "count": 123 },
        { "timePeriod": "201101050000", "count": 134 },
        { "timePeriod": "201101060000", "count": 120 },
        { "timePeriod": "201101070000", "count": 43 },
        { "timePeriod": "201101080000", "count": 65 },
        { "timePeriod": "201101090000", "count": 85 },
        { "timePeriod": "201101100000", "count": 32 },
        { "timePeriod": "201101110000", "count": 23 },
        { "timePeriod": "201101120000", "count": 85 },
        { "timePeriod": "201101130000", "count": 32 },
        { "timePeriod": "201101140000", "count": 95 },
        { "timePeriod": "201101150000", "count": 109 },
        { "timePeriod": "201101160000", "count": 34 },
        { "timePeriod": "201101170000", "count": 74 },
        { "timePeriod": "201101180000", "count": 24 },
        { "timePeriod": "201101190000", "count": 90 },
        { "timePeriod": "201101200000", "count": 85 },
        { "timePeriod": "201101210000", "count": 93 },
        { "timePeriod": "201101220000", "count": 48 },
        { "timePeriod": "201101230000", "count": 37 },
        { "timePeriod": "201101240000", "count": 54 },
        { "timePeriod": "201101250000", "count": 52 },
        { "timePeriod": "201101260000", "count": 84 },
        { "timePeriod": "201101270000", "count": 120 },
        { "timePeriod": "201101280000", "count": 34 },
        { "timePeriod": "201101290000", "count": 83 },
        { "timePeriod": "201101300000", "count": 23 },
        { "timePeriod": "201101310000", "count": 12 }
       ],
      "totalCount":2027,
      "next":"NTcxODIyMDMyODMwMjU1MTA0",
      "requestParameters":
        {
          "bucket":"day",
          "fromDate":"201101010000",
          "toDate":"201201010000"
        }
    }
後続のリクエストに対するレスポンスは次のようになります（新しい counts のタイムラインと異なる「next」値に注目してください）: 
    {
      "results": [
        { "timePeriod": "201102010000", "count": 45 },
        { "timePeriod": "201102020000", "count": 76 },
         ....
        { "timePeriod": "201103030000", "count": 13 }
     ],
     "totalCount":3288,
     "next":"WE79fnakFanyMDMyODMwMjU1MTA0",
     "requestParameters":
        {
          "bucket":"day",
          "fromDate":"201101010000",
          "toDate":"201201010000"
        }
    }
前回のqueryで返された’next’要素を、queryの対象期間におけるすべての件数を取得できるまで引き続き渡せます。‘next’要素を含まないレスポンスを受け取った場合は、最終ページに到達しており、指定した期間内で利用可能な追加の件数はありません。

​
HTTP response codes

StatusTextDescription
200OKリクエストは正常に処理されました。JSON レスポンスは次のとおりです。
400Bad Request一般的には、リクエストに無効な JSON が含まれている場合、または JSON ペイロードが送信されなかった場合に返されます。
401Unauthorized無効な認証情報により HTTP 認証に失敗しました。request で正しく使用できているか確認するため、認証情報で console.gnip.com にログインしてください。
404Not Foundリクエスト先の URL にリソースが存在しません。URL が誤っている可能性が高いです。
422Unprocessable Entityquery に無効なパラメータが含まれているため返されます（例: 無効な PowerTrack ルール）。
429Unknown CodeApp が接続リクエストの上限を超過しました。対応する JSON メッセージは次のようになります。
500Internal Server Errorサーバー側でエラーが発生しました。指数バックオフ方式で再試行してください。
502Proxy Errorサーバー側でエラーが発生しました。指数バックオフ方式で再試行してください。
503Service Unavailableサーバー側でエラーが発生しました。指数バックオフ方式で再試行してください。
⌘I