メインコンテンツへスキップ
ご注意： X API v2 にて、Post 検索およびPost 件数の新バージョンをリリースしました。X API v2 の新機能をご確認ください。 これらのエンドポイントは、Post の編集メタデータを含むように更新されました。詳細は、“Edit Posts” の基本事項をご覧ください。 

​
概要

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

​
リクエストの種類

エンタープライズ検索 API は、2 種類のリクエストをサポートします：

​
検索リクエスト (data)

エンタープライズ検索 API への検索リクエストにより、指定された時間枠ごとにレスポンスあたり最大 500 件の結果を取得でき、追加のデータを取得するためのページネーションが可能です。maxResults パラメータを使用して、表示用途向けに小さいページサイズを指定したり（ユーザーが必要に応じてさらに結果をリクエストできるように）、大量のデータ取得向けに大きいページサイズ（最大 500）を指定したりできます。データは逆時系列順で配信され、配信時点で準拠しています。

​
カウント リクエスト (投稿カウント)

カウント リクエストは、指定されたクエリに一致する活動の数（指定した時間枠内で発生したもの）を反映した過去の活動カウントを取得する機能を提供します。レスポンスは本質的にカウントのヒストグラムを提供し、日、時間、または分単位でバケット化されます（デフォルトのバケットは hour です）。 カウント結果は、投稿公開後かなり経過（7日以上）してから発生するコンプライアンス イベント（例: 投稿の削除）を常に反映するわけではない点に注意してください。したがって、同じクエリに対するデータ リクエストのカウントと一致しない場合があります。 請求に関する注意: データおよびカウント エンドポイントに対する各リクエスト – including pagination requests – は、請求対象のリクエストとしてカウントされます。したがって、単一のクエリに複数の結果ページがある場合、X ページの結果をページ送りすると、請求上 X リクエストに相当します。

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

エンタープライズ検索 API は、最大 2,048 文字のルールをサポートします。エンタープライズ検索 API は、以下のオペレーターをサポートします。詳細な説明については、HERE を参照してください。
投稿内容の照合:関心アカウントの照合:投稿属性:地理空間オペレーター:
* keyword
* “quoted phrase”
* “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:
注意: オペレーターの埋め込み/ネストは避けてください。検索 API では (“#cats”) が cats に解決されます。 ‘lang:’ オペレーターおよびすべての ‘is:’ と ‘has:’ オペレーターは、単体オペレーターとして使用できず、他の句と組み合わせる必要があります (例: @XDevelopers has:links)。   検索 API は、トークナイゼーション/照合機能のため、制限されたオペレーター セットを使用します。エンタープライズのリアルタイムおよびバッチ履歴 API は、追加のオペレーターを提供します。詳細については、HERE を参照してください。 詳細については、オペレーターの使用開始 ガイドを参照してください。

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

Full-Archive 検索 API を使用する際は、X プラットフォームが 2006 年以降進化し続けていることを念頭に置いてください。新機能が追加されるたびに、基盤となる JSON オブジェクトに新しいメタデータが追加されてきました。そのため、検索オペレーターが照合する投稿属性がいつ追加されたかを理解することが重要です。以下は、重要なメタデータのグループのより基本的な「誕生」日付です。投稿属性が最初に導入された時期について詳しくは、このガイド を参照してください。  
  • 最初の投稿: 3/21/2006
  • 最初のネイティブ リツイート: 11/6/2009
  • 最初のジオタグ付き投稿: 11/19/2009
  • URL がフィルタリングのために最初にインデックス化: 8/27/2011
  • 拡張された URL 展開メタデータ (ウェブサイトのタイトルと説明): 12/1/2014
  • プロフィール Geo 強化メタデータとフィルタリング: 2/17/2015

​
データの更新と可変性

エンタープライズ検索 API を使用すると、投稿内のデータの一部は可変、つまり初期アーカイブ後に更新または変更可能です。 この可変データは、2つのカテゴリに分類されます：
  • ユーザーオブジェクトのメタデータ：
    • ユーザーの @ハンドル（数値 ID は決して変更されません）
    • 自己紹介
    • カウント: 投稿数、フォロワー数、フォロー数、いいね数、リスト数
    • プロフィールの場所
    • タイムゾーンや言語などのその他の詳細
  • 投稿の統計情報 - つまり、ユーザーアクションによってプラットフォーム上で変更可能なもの（以下の例）：
    • いいね数
    • リツイート数
これらのほとんどの場合、検索 API は投稿生成時ではなく、クエリ時 にプラットフォーム上で存在するデータを返します。ただし、選択演算子（例: from, to, @, is:verified）を使用したクエリの場合、これが当てはまらない場合があります。データは定期的にインデックスに更新され、最近の時間枠では更新頻度が増加します。その結果、一部のケースでは、返されるデータが X.com に表示される現在のデータと完全に一致しないことがありますが、最後にインデックス化された時点のデータと一致します。 注意、この不整合の問題は、演算子が可変データに適用されるクエリにのみ該当します。一例としてユーザー名によるフィルタリングがあり、最適な回避策は、これらのクエリで @ハンドルではなくユーザー数値 ID を使用することです。

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

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

​
再試行ロジック

エンタープライズ検索 API で 503 エラーが発生した場合、これは通常一時的なエラーであり、短時間後にリクエストを再試行すれば解決する可能性が高いです。 リクエストが 4 回連続で失敗し、各失敗の間に少なくとも 10 分待機した場合、次の手順でトラブルシューティングを行ってください：
  • 対象の時間範囲を短くしてからリクエストを再試行してください。うまくいかない場合は、6 時間の時間窓まで繰り返してください。
  • 多数の用語を OR で結合している場合、それらを個別のルールに分割し、それぞれを個別に再試行してください。
  • ルールで多数の除外を使用している場合、ルール内の否定項の数を減らして再試行してください。

​
クイックスタート

​
エンタープライズ Search Posts: 30-Day API の入門

エンタープライズ Search Posts: 30-Day API は、過去 30 日間に投稿された投稿を提供します。投稿は、リクエストで指定したクエリに基づいてマッチングされ、返されます。クエリとは、返される投稿の内容を指定するためのルールです。このチュートリアルでは、@XDevelopers の X アカウントが英語で投稿した投稿を検索します。 レスポンスのペイロードで返される投稿は、完全な投稿ペイロードを提供する data 形式、またはマッチした投稿の数値カウントデータを返す counts 形式のいずれかです。data および counts エンドポイントへのリクエストには cURL を使用します。 以下のものが必要です：

​
data エンドポイントへのアクセス

data エンドポイントでは、一致した Post の完全なペイロードが提供されます。from: と lang: オペレーターを使用して、@XDevelopers から英語で投稿された Post を検索します。他のオペレーターについてはこちらをご覧ください。
  • 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>"}'

​
データエンドポイントの応答ペイロード

API リクエストに対する応答として返されるペイロードは、以下の例のように JSON 形式になります。 
{
	"results": [
		{
			"created_at": "Fri Nov 02 17:18:31 +0000 2018",
			"id": 1058408022936977409,
			"id_str": "1058408022936977409",
			"text": "RT @harmophone: \"The innovative crowdsourcing that the Tagboard, Twitter and TEGNA collaboration enables is surfacing locally relevant conv…",
			"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プラットフォームのニュース、更新、イベントに関する公式情報源です。技術的なヘルプが必要ですか？ 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": "\"The innovative crowdsourcing that the Tagboard, Twitter and TEGNA collaboration enables is surfacing locally relev… 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": "タイラー・シングルタリー",
					"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": "タイラー・シングルタリー著、Tagboardプロダクト責任者"
								},
								"indices": [
									236,
									259
								]
							}
						],
						"user_mentions": [
							{
								"screen_name": "adamostrow",
								"name": "アダム・オストロウ",
								"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 エンドポイントへのアクセス

counts エンドポイントを使って、@XDevelopers アカウントからの英語の投稿の数を、day ごとにグループ化して取得します。
  • cURL
  • cURL の例
cURL は、URL 構文を使用してファイルを取得または送信するためのコマンドラインツールです。以下の cURL リクエストを、以下の項目を変更した上でコマンドラインにコピーしてください：
  • ユーザー名 <USERNAME> 例: email@domain.com
  • アカウント名 <ACCOUNT-NAME> 例: john-doe
  • ラベル <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"}'

​
カウントエンドポイントのレスポンス ペイロード

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"
	}
}
よくできました！これでエンタープライズ Search Posts: 30-Day API に正常にアクセスできました。
参照記事

​
エンタープライズ版 Search Posts: Full-Archive API を使い始める

エンタープライズ版 Search Posts: Full-Archive API は、2006年の最初の投稿以降の Post を提供します。リクエストで指定したクエリに基づいて、Post が照合されて返されます。クエリとは、返される Post に含めたい条件を定義するためのルールです。本チュートリアルでは、X アカウント @XDevelopers から英語で投稿された Post を検索します。 返されるペイロード内の Post は、Post の完全なペイロードを返す data 形式、またはマッチした Post の数を数値で返す counts 形式のいずれかになります。ここでは、data エンドポイントと counts エンドポイントへのリクエストに cURL を使用します。 次のものが必要です:
  • エンタープライズアカウント
  • ユーザー名、パスワード、アカウント名
  • console.gnip.com に表示される、検索エンドポイントに関連付けられたラベル

​
データエンドポイントへのアクセス

データエンドポイントは、一致したPostの完全なPostペイロードを返します。from: と lang: オペレーターを使って、@XDevelopers から英語で投稿されたPostを検索します。他のオペレーターについては こちらを参照してください。
  • 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>"}'
データエンドポイントの応答ペイロード
API リクエストから返されるペイロードは、以下の例に示すように JSON 形式になります。 
{
	"results": [
		{
			"created_at": "Fri Nov 02 17:18:31 +0000 2018",
			"id": 1058408022936977409,
			"id_str": "1058408022936977409",
			"text": "RT @harmophone: \"The innovative crowdsourcing that the Tagboard, Twitter and TEGNA collaboration enables is surfacing locally relevant conv…",
			"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プラットフォームのニュース、更新、イベントに関する公式情報源です。技術的なヘルプが必要ですか？ 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": "\"The innovative crowdsourcing that the Tagboard, Twitter and TEGNA collaboration enables is surfacing locally relev… 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": "タイラー・シングルタリー",
					"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": "タイラー・シングルタリー、Tagboardプロダクト責任者"
								},
								"indices": [
									236,
									259
								]
							}
						],
						"user_mentions": [
							{
								"screen_name": "adamostrow",
								"name": "アダム・オストロウ",
								"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 エンドポイントへのアクセス

counts エンドポイントを使用して、@XDevelopers アカウントから英語で投稿された Post の件数を、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"}'

​
カウントエンドポイントのレスポンスペイロード

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"
	}
}
おめでとうございます！ これで、エンタープライズ Search Posts: Full-Archive API に正常にアクセスできました。
参照記事

​
ガイド

​
検索クエリの構築

​
エンタープライズのオペレーター

以下は、X のエンタープライズ検索 API でサポートされているオペレーターの一覧です。
  • エンタープライズ 30日間検索 API
  • エンタープライズ 全アーカイブ検索 API
製品ごとの利用可能なオペレーターを比較した一覧はこちらをご覧ください。
オペレータ概要
キーワードPost の本文または URL 内に含まれるトークン化済みキーワードに一致します。これはトークン化に基づくマッチであり、指定したキーワード文字列は Post 本文のトークン化済みテキストと照合されます。トークン化は、句読点、記号、セパレーターの Unicode 基本多言語面の文字に基づきます。たとえば、テキストが “I like coca-cola” の Post は、次のトークンに分割されます: I, like, coca, cola。これらのトークンが、ルールで使用するキーワード文字列と比較されます。句読点（例: coca-cola）、記号、またはセパレーター文字を含む文字列と一致させるには、以下で説明する引用符で囲んだ厳密一致を使用する必要があります。

**注記：**Search API では、アクセント付き文字や特殊文字は標準的なラテン文字に正規化されます。これにより、外国語では意味が変わったり、予期しない結果が返される場合があります。
たとえば、“músic”は「music」と一致し、その逆も同様です。
例えば、一般的な表現として”明けましておめでとうございます！“スペイン語では、次のように索引付けされます”明けましておめでとうございます”、語句（フレーズ）の意味が変わってしまいます。

**注釈:**このオペレーターは、Post 内の URL とアンワインドされた URL の両方にマッチします。
絵文字Post の本文中に含まれる絵文字に一致します。絵文字はトークン化に基づいてマッチングされるため、指定した絵文字は Post 本文のトークン化済みテキストと照合されます。トークン化は、句読点、記号／絵文字、区切り文字といった Unicode 基本多言語面の文字に基づきます。たとえば、テキストが “I like” は次のトークンに分割されます：I、like、。これらのトークンはその後、あなたのルールで使用した絵文字と照合されます。絵文字にバリアントがある場合は、ルールに追加する際に「引用符」を使用する必要がある点に注意してください。
“フレーズの完全一致”Post の本文または URL に含まれる、トークン化され順序が保持されたフレーズに一致します。これはトークン化ベースのマッチであり、キーワード文字列は Post 本文のトークン化されたテキストと照合されます。トークン化は、句読点・記号・区切り文字に該当する Unicode 基本多言語面の文字に基づいて行われます。

**注記：**句読点はトークン化されず、空白と同様に扱われます。
例えば、引用符付きの“#hashtag”は“hashtag”には一致しますが、#hashtagには一致しません（実際のハッシュタグに一致させるには、引用符を付けずにハッシュタグ # 演算子を使用してください）。
たとえば、引用符付きの“cashtag”は“cashtag”には一致しますが、cashtag”は“cashtag”には一致しますが、cashtagには一致しません（実際のキャッシュタグにマッチさせるには、引用符なしで cashtag:$ 演算子を使用してください）。
例えば：“ラブ・スノー”一致する”#love #snow”
例として、“#Love #Snow”一致する”love snow”

**注記:**このオペレーターは、Post 内の URL と展開後の URL の両方に一致します。
“keyword1 keyword2”~N一般に近接演算子と呼ばれ、キーワード同士が互いに N 個以内のトークン距離にある Post にマッチします。

キーワードが逆順の場合、互いの距離は N−2 トークン以内でなければなりません。引用符内に含めるキーワードの数は任意です。N は 6 を超えられません。

このオペレーターは enterprise 検索 API でのみ利用可能である点にご留意ください。エンタープライズ検索 API。
差出人：特定のユーザーの任意のPostに一致します。
値は、ユーザーのXの数値アカウントIDまたはユーザー名（@は含めない）である必要があります。参照こちらまたはこちら数値のXアカウントIDの確認方法については参照してください。
宛先：特定のユーザーへの返信であるすべてのPostに一致します。

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

このオペレーターは厳密一致であり、トークン化による一致ではありません。つまり、ルール「2016」は「2016」というハッシュタグを正確に持つPostに一致しますが、「2016election」というハッシュタグを持つPostには一致しません。

注意: ハッシュタグ演算子は X に依存します’のエンティティ抽出を使用してハッシュタグを照合し、本文自体からハッシュタグを抽出するのではありません。参照：こちらX Entities の JSON 属性の詳細についてはこちらをご参照ください。
@指定したユーザー名に言及している任意のPostに一致します。
to: 演算子は、@mention 演算子のサブセットに一致する結果を返します。
$指定した「キャッシュタグ」（トークンの先頭文字が「$」）を含む任意のPostに一致します。

cashtag 演算子は X の「symbols」エンティティ抽出に依存していることに注意してください’X の「symbols」エンティティ抽出を利用してキャッシュタグではなくカスタグ（cashtag）を照合し、本文からカスタグを直接抽出しようとしないでください。参照こちらX Entities の JSON 属性についての詳細は、こちらをご覧ください。

このオペレーターは enterprise 検索 API でのみ利用可能です。エンタープライズsearch APIs（検索 API）

リポスト_の：利用可能な別名: リツイート数_の_ユーザー:
指定したユーザーによるリツイートの 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（例を参照）でタグ付けされたPostに一致します。複合語の地名（“New York City”、“Palo Alto”）は引用符で囲んでください。

注意: Xの place ID の取得方法は、公開APIエンドポイント GET geo/search を参照してください。

注意: このオペレーターはRetweetには一致しません。Retweetの場所情報は元のPostに付与されているためです。また、Quote Tweetの元のPostに付与された場所にも一致しません。
place_country:タグ付けされたplaceに関連付けられた国コードが、指定のISOアルファ2文字コードに一致するPostに一致します。

有効なISOコードはこちらで確認できます: http://en.wikipedia.org/wiki/ISO_3166-1_alpha-2

注意: このオペレーターはRetweetには一致しません。Retweetの場所情報は元のPostに付与されているためです。また、Quote Tweetの元のPostに付与された場所にも一致しません。
point_radius:[lon lat radius]存在する場合、Postの正確な位置（x, y）およびXでは「Place」のジオポリゴンに対して一致します。Placeは定義された領域内に完全に含まれている必要があります。

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

注意: このオペレーターはRetweetには一致しません。Retweetの場所情報は元のPostに付与されているためです。また、Quote Tweetの元のPostに付与された場所にも一致しません。
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の範囲です。
* すべての座標は十進法（度）です。
* ルール引数は角括弧で囲み、空白で区切ります。
注意: このオペレーターはRetweetには一致しません。Retweetの場所情報は元のPostに付与されているためです。また、Quote Tweetの元のPostに付与された場所にも一致しません。
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 固有の地理情報データを持つ Post にマッチします。これは「geo」の緯度・経度座標、または X の「Place」として提供される「location」で、対応する表示名、地理ポリゴン、その他のフィールドを含む場合があります。「Place（場所）」、対応する表示名、ジオポリゴン、その他のfieldsを含みます。



**注記:**Search API を使用する場合、この演算子は、is: または has: を含まない他の演算子と組み合わせて使用する必要があります。‘含まないis:またはhas:。
has:profile_ジオ使用可能なエイリアス: has:derived_ユーザー_Geo

いずれかのPostに一致しますプロフィールジオ実際の値にかかわらず、あらゆるProfile Geoのメタデータ。


**注:**Search API を使用する場合、このオペレーターは、is: や has: を含まない他のオペレーターと併用する必要があります’含めないis:またはhas:.
has:linksこのオペレーターは、メッセージ本文にリンクを含むPostに一致します。


**注意：**Search API を使用する際、この演算子は、is: や has: を含まない他の演算子と組み合わせて使用する必要があります’含めないis:またはhas:.
is:retweetルールに一致する明示的なリツイートのみを配信します。否定指定により、該当するリツイートを配信対象から除外し、オリジナルのコンテンツのみを配信することも可能です。

このオペレーターは、X の機能による真正な Retweet のみを対象とします’のリツイート機能。Quoted Tweets と、X のリツイート機能を使用していない Modified Post は、このオペレーターでは一致しません’X のリツイート機能による投稿は、このオペレーターでは一致しません。



**注:**Search API を使用する際、このオペレーターは is: や has: を含まない他のオペレーターと併用する必要があります’t includeis:またはhas:.
is:replyPosts が他の Post への返信かどうかに基づいてフィルタリングするオペレーター。ルールに一致する明示的な返信のみを配信します。否定して、ルールに一致する返信を配信から除外することもできます。

このオペレーターは有料のプレミアム検索およびエンタープライズ検索で利用可能ですが、Sandbox の開発環境では利用できません。



**注釈：**Search API を使用する場合、この演算子は、…でない他の演算子と組み合わせて使用する必要があります。‘含まないis:またはhas:.
is:quoteQuote Tweet、または別のPostを参照するPostのみを配信します。これはPostのペイロード内の “is_quote_status”: true によって識別されます”である_引用符_ステータス”:true は Post のペイロード内で使用されます。否定形にして Quote Tweets を除外することもできます。

**注記:**Search API を使用する場合、このオペレーターは、〜でない他のオペレーターと併用する必要があります’含めないis:またはhas:。
is:verified著者がXにより「認証済み」であるPostのみを返します。否定を用いることで、著者が認証済みのPostを除外することもできます。


**注:**Search API を使用する場合、このオペレーターは、is: や has: を含まない他のオペレーターと併用する必要があります’含まないis:またはhas:。
has:mentions他のXユーザーへの言及を含むPostに一致します。


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


**注記:**Search API を使用する場合、この演算子は、～しない他の演算子と組み合わせて使用する必要があります。‘含めないis:またはhas:.
has:media利用可能な別名: has:media_リンク

X により分類されたメディア URL を含む Post に一致します。例: pic.x.com


**注記：**Search API を使用する場合、このオペレーターは、～しない他のオペレーターと組み合わせて使用する必要があります’含めないis:またはhas:.
has:imagesX によって分類されたメディアのURLを含むPostに一致します。例: pic.x.com


**注記:**Search API を使用する場合、このオペレーターは、is: や has: を含まない他のオペレーターと併用する必要があります’含まないis:またはhas:.
has:videos使用可能なエイリアス: has:video_リンク

X に直接アップロードされたネイティブ動画を含む Post に一致します。Vine や Periscope で作成された動画、または他の動画ホスティングサイトへのリンクを含む Post には一致しません。


**注意:**Search API を使用する場合、この演算子は、〜しない他の演算子と併用する必要があります’含めないis:またはhas:。
has:symbols先頭に「」が付くキャッシュタグ（例:」が付くキャッシュタグ（例: tag）を含むPostに一致します。 このオペレーターはエンタープライズ検索 API。


**注:**Search API を使用する場合、このオペレーターは、〜しない他のオペレーターと併用する必要があります。‘含まれていないis:またはhas:.

​
製品概要

エンタープライズ階層の Full-archive Search は2015年8月、プレミアム階層のバージョンは2018年2月に提供開始されました。これらの検索製品により、公開されている任意の Post に即時アクセスできます。Full-archive Search では、単一のクエリを送信し、従来の RESTful 方式でレスポンスを受け取ります。Full-archive Search は1レスポンスあたり最大500 Postのページネーションに対応し、レート制限はプレミアムで毎分最大60リクエスト（rpm）、エンタープライズで毎分120リクエストです。これらの仕様により、Full-archive Search は同時リクエストを用いることで、大規模かつ迅速に Post を取得できます。 ディスク上の Post のフラットファイル集合を基盤とする Historical PowerTrack と異なり、Full-archive Search の Post アーカイブはオンラインデータベースに近い構造です。一般的なデータベースと同様に、その内容に対してクエリを実行でき、また、高速なデータ取得のために_index_（索引）を利用しています。Full-archive Search のエンドポイントでは、クエリ言語は PowerTrack Operators で構成され、各 Operator はインデックス化された Post の JSON 属性に対応します。 また、Historical PowerTrack と同様に、クエリ実行時点での最新の Post 属性が適用される項目があります。たとえば、今日 Search API を使用して2010年に投稿された Post にアクセスする場合、ユーザーのプロフィールの説明、アカウントの「ホーム」所在地、表示名、そしてお気に入り数やリツイート数といった Post のメトリクスは、2010年当時の値ではなく、現在の値に更新されます。 

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

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

​
2006

  • 3月26日 - lang:。検索インデックス生成時に Post のメタデータをバックフィルする例。
  • 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 など特定の動画ホスティングサイトへのリンクを含むPostにマッチします）。

​
2011

  • 7月20日 - has:media と has:images の一致条件での検索が有効化。ネイティブ写真は2010年8月9日に正式発表。

​
2014

  • 12月3日 - （おおよそ）一部の Enhanced URL metadata（HTMLのタイトルと説明を含む）がペイロードに含まれ始めました。強化されたメタデータは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

​
2017

  • 2月22日 - 投票のメタデータが拡張されたネイティブ形式で利用可能になりました。これらのメタデータに対応するOperatorは存在しません。

​
2022

  • 9月27日 - この日以降に作成されたすべての Post オブジェクトでは、編集済み Post のメタデータが利用可能になりました。Post オブジェクトを返すすべてのエンタープライズ向けエンドポイントも、この日から当該メタデータを提供するよう更新されています。提供される編集メタデータには、edit_history および edit_controls オブジェクトが含まれます。これらのメタデータは、2022年9月27日より前に作成された Post については返されません。現在、これらのメタデータに対応するエンタープライズオペレーターは提供されていません。Edit Post メタデータの詳細は、Edit Posts fundamentals ページをご覧ください。

​
2022

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

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

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

​
X プロフィール

Search API は、取得時点 のユーザープロフィールデータを付与した過去の Post を返します。たとえば 2014 年の Post をリクエストした場合でも、ユーザーのプロフィールメタデータはクエリ時点の状態を反映します。

​
オリジナルのPostとRetweet

PowerTrack _is:retweet_ オペレーターを使うと、Retweet を含めるか除外するかを選択できます。このオペレーターを利用する場合、2009年8月以前の data に対しては、Retweet を一致させる（あるいは一致させない）ための2つの戦略が必要です。2009年8月以前は、Post メッセージ本文を正確なフレーズ一致でチェックし、「@RT 」パターンに一致するか確認する必要があります（なお、2009年5月から8月の期間の Retweet をフィルタリングする場合は、「Via @」パターンも含めてください）。2009年8月以降は、_is:retweet_ オペレーターが利用可能です。

​
Post の言語分類

Post の言語分類でフィルタリングする場合、X の旧来のプロダクト間では挙動が大きく異なります。Search アーカイブの構築時に、すべての Post に X の言語分類が遡及適用（バックフィル）されました。したがって、lang: オペレーターは Post アーカイブ全体で利用できます。

​
Post のジオリファレンス

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

​
よくある質問（FAQ）

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

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

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

コード 404 - 見つかりません
  1. 各エンドポイントに適切なパラメータを使用していることを確認してください（例: buckets フィールドは counts エンドポイントでのみ使用でき、data エンドポイントでは使用できません）
  2. :product、:account_name、:label の各フィールドが正しいか再確認してください。:label フィールドは GNIP Console（エンタープライズのお客様のみ）で確認できます。

​
API リファレンス

​
エンタープライズ検索API

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

​
メソッド

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

​
認証

エンタープライズ検索APIへのすべてのリクエストは、https://console.gnip.com のアカウントにログインする際に使用する有効なメールアドレスとパスワードの組み合わせから生成したHTTPの Basic 認証 を使用する必要があります。認証情報は各リクエストで 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日までのクエリに一致するすべての Tweet を取得したいとします。リクエストでは、fromDate と toDate パラメータでその 6 か月間全体を指定します。search API は、maxResults パラメータ（デフォルトは 100）に一致する数の Tweet を含む最初の「ページ」を返します。さらに Tweet が存在する（多くの場合存在します）場合、API は次の「ページ」の data を取得するために使用する ‘next’ トークンも返します。この処理は、API が ‘next’ トークンを返さなくなるまで繰り返されます。詳細は次のセクションをご覧ください。 data リクエストとカウントリクエストの両方を行う場合、単一のレスポンスで返せる量を超えるデータが存在する可能性があります。その場合、レスポンスには「next」トークンが含まれます。「next」トークンはルートレベルの JSON 属性として提供されます。「next」トークンが含まれている場合は、取得すべき追加データがあるため、引き続き API リクエストを行う必要があります。 注: 「next」トークンの挙動は、data リクエストとカウントリクエストでわずかに異なります。両方について以下で説明しており、API Reference セクションに例示的なレスポンスを掲載しています。
データのページネーション
data のリクエストは、単一のレスポンスで返せる量を超える data を生成する場合があります。各 data リクエストには、リクエストごとに返す Tweet の最大数を設定するパラメータが含まれます。この maxResults パラメータの既定値は 100 で、10〜500 の範囲で設定できます。リクエストで指定した ‘maxResults’ より多くの Tweet がクエリに一致した場合、レスポンスには（ルートレベルの JSON 属性として）‘next’ トークンが含まれます。この ‘next’ トークンは、後続のリクエストでそのクエリに一致する次の Tweet 群（つまり次の「ページ」）を取得するために使用されます。‘next’ トークンは、そのクエリの結果の最後の「ページ」に到達して ‘next’ トークンが返されなくなるまで付与され続けます。 次の「ページ」の data をリクエストするには、query、toDate、fromDate パラメータを使用している場合はそれらを含め、元のものとまったく同一のクエリを実行し、前のレスポンスで返された値を設定した ‘next’ リクエストパラメータも含める必要があります。これは GET リクエストでも POST リクエストでも利用できます。ただし、GET リクエストの場合は ‘next’ パラメータを URL エンコードする必要があります。 クエリで対象とする期間に含まれるすべての Tweet を取得し終えるまで、前回のクエリで返された ‘next’ 要素を渡し続けることができます。‘next’ 要素を含まないレスポンスを受け取った場合は、最後のページに到達しており、指定したクエリと時間範囲について追加の data は存在しないことを意味します。
カウントのページネーション
‘counts’ エンドポイントは、クエリに関連する Tweet のボリュームを日次、時間単位、または分単位で提供します。‘counts’ API エンドポイントは、最大 31 日分のカウントに対する、タイムスタンプ付きのカウント配列を返します。31 日を超えるカウントをリクエストした場合は、‘next’ トークンが提供されます。data の ‘next’ トークンと同様に、元のクエリと完全に同一のリクエストを行い、前回のレスポンスで受け取った値を設定した ‘next’ リクエストパラメータを必ず含めてください。 31 日を超えるカウントを要求する場合以外にも、‘next’ トークンが提供されるケースがあります。高ボリュームのクエリでは、カウント生成に時間を要し、レスポンスのタイムアウトが発生する可能性があります。この場合、31 日分未満のカウントしか返されませんが、カウント全体のペイロードを取得し続けるための ‘next’ トークンが提供されます。重要: タイムアウト時は完全な「バケット」のみが返されます。たとえば 2.5 日分に相当する場合、1 日の完全な「バケット」が 2 つ返されます。
追加の注意事項
  • 検索リクエストで fromDate または toDate を使用する場合、取得できる結果は指定した時間範囲内のものに限られます。時間範囲内の最後の結果グループに到達すると、‘next’ トークンは返されません。
  • ‘next’ 要素は、10～500 の任意の maxResults 値（デフォルトは 100）で使用できます。maxResults は各レスポンスで返される Tweet の数を決定しますが、最終的にすべての結果の取得が妨げられることはありません。
  • ‘next’ 要素は有効期限がありません。同じ ‘next’ クエリを使用した複数のリクエストは、リクエストのタイミングに関係なく同じ結果を受け取ります。
  • ‘next’ パラメータでページングする際、クエリ境界付近で重複が発生する場合があります。アプリはこれに耐性を持つようにしてください。

​
データ エンドポイント

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

このパラメータには、すべてのオペレーターを含む PowerTrack ルールの全体を指定してください。ルールの一部をクエリの他のパラメータに分割しないでください。

注: すべての PowerTrack オペレーターがサポートされているわけではありません。サポートされているオペレーターはこちらに掲載しています。		はい(snow OR cold OR blizzard) weather
tagルールとその一致データを、別々の論理グループに分類するためにタグを使用できます。ルールタグが指定された場合、そのタグは ‘matching_rules’ 属性に含まれます。

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

指定した場合: toDate パラメータなしで fromDate のみを使用すると、現在から過去に遡って fromDate までのクエリ結果が返されます。

未指定の場合: fromDate が指定されていない場合、API は現在から30日前、または（指定されていれば）toDate までのすべての結果を返します。

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

指定した場合: fromDate パラメータなしで toDate のみを使用すると、toDate より前の直近30日分のデータが返されます。

未指定の場合: toDate が指定されていない場合、API は現在から過去に遡って fromDate までのすべての結果を返します。

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

注: すべてのPowerTrack演算子がサポートされているわけではありません。サポート対象の演算子一覧はAvailable operatorsを参照してください。
レート制限パートナーには分単位および秒単位の両方でレート制限が適用されます。分あたりの上限は契約で指定されたとおりパートナーごとに異なります。ただし、これらの分間上限を単一のバーストで使い切ることは想定されていません。分あたりの上限に関わらず、data および/またはカウントに対するすべてのリクエストを合算して、秒あたり最大20リクエストに制限されます。
コンプライアンスFull-Archive Search API経由で配信されるすべてのデータは、配信時点でコンプライアンスに適合しています。
リアルタイム可用性データはXプラットフォーム上で生成後30秒以内にインデックスで利用可能です
データのリクエストおよびレスポンスの例
POST リクエストの例
  • POST リクエストのパラメータは、以下のとおり JSON 形式の本文で送信されます。
  • 照会対象の PowerTrack ルールのすべての要素（例：キーワード、bounding_box: のようなその他のオペレーター）は、‘query’ パラメータに含めてください。
  • ルールの要素をクエリ URL 内で別々のパラメータに分割しないでください。
初回の data リクエストを行うための 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’ パラメータに含めてください。
  • クエリ URL 内で、ルールの一部を別のパラメータとして分割しないでください。
初回のデータリクエストを行うための 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編集メタデータがTweetオブジェクトに含まれます。詳細は “Edit Tweets” の基礎ページをご覧ください。 以下はdataクエリに対するレスポンス例です。この例では、利用可能なTweetが ‘maxResults’ を超えているため、後続のリクエスト用に ‘next’ トークンが付与されています。クエリに関連するTweetが ‘maxResults’ 以下の場合、レスポンスには ‘next’ トークンは含まれません。 ‘next’ 要素の値はクエリごとに変化し、内容を解釈せずに文字列として扱う必要があります。レスポンスボディでは、‘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"
      }
  }
前回のクエリで取得した ‘next’ 要素を、クエリで対象とする期間内のすべての Tweet を取得するまで渡し続けることができます。‘next’ 要素を含まないレスポンスを受け取った場合は、最後のページに到達しており、その期間内で利用可能な追加の data はありません。

​
Counts エンドポイント

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

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

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

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

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

fromDate と toDate のどちらのパラメータも使用しない場合、API はリクエスト時点から遡って直近 30 日間のカウント（データ量）を返します。		いいえ201207220000
toDateTweets が提供される最新の UTC タイムスタンプ。タイムスタンプは分単位の粒度で、上限は非包含です（例: 11:59 はその時間の 59 分目を含まない）。

指定あり: toDate のみを使用し、fromDate を指定しない場合、toDate の 30 日前までの最新のカウント（データ量）を返します。

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

fromDate と toDate のどちらのパラメータも使用しない場合、API はリクエスト時点から遡って直近 30 日間のカウント（データ量）を返します。		いいえ201208220000
bucketカウントデータを提供する時間単位。リクエストした期間内の日単位・時単位・分単位のカウントデータを返せます。既定では時単位のカウントが提供されます。オプション: ‘day’, ‘hour’, ‘minute’いいえminute
nextこちらで説明しているとおり、結果の次の「ページ」を取得するために使用するパラメータです。値は API のレスポンスからそのまま取得し、変更しないでください。いいえNTcxODIyMDMyODMwMjU1MTA0
追加の詳細
利用可能な期間30日: 直近31日間
フルアーカイブ: 2006年3月21日〜現在
クエリ形式PowerTrack ルール1件分に相当（最大2,048文字）。

注: すべての PowerTrack 演算子がサポートされているわけではありません。サポート対象の演算子一覧は Available operators を参照してください。
レート制限パートナーは分単位および秒単位の粒度でレート制限されます。1分あたりのレート制限は、契約に基づきパートナーごとに異なります。ただし、これらの1分あたりの上限は単一のバーストで使い切ることを想定していません。1分あたりの上限にかかわらず、すべてのパートナーは、data および/またはカウントに関するすべてのリクエストを合算して、1秒あたり最大20リクエストに制限されます。
カウントの精度本エンドポイントで提供されるカウントは、発生した Tweet の件数を反映しており、後に発生するコンプライアンスイベント（削除、位置情報のスクラブ）は反映しません。カウントに含まれる一部の Tweet は、ユーザーのコンプライアンス措置により data エンドポイントから取得できない場合があります。
カウント用リクエストとレスポンスの例
POST リクエストの例
  • POST リクエストのパラメータは、以下のとおり JSON 形式のボディで送信されます。
  • クエリ対象の PowerTrack ルールのすべての要素（例: キーワード、bounding_box: などの他のオペレーター）は、‘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 で、ルールの一部を別個のパラメータに分けないでください
初回の counts リクエストを行うための 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（データ量）クエリに対するレスポンス例です。このレスポンス例には「next」トークンが含まれており、counts リクエストの期間が31日を超えているか、送信したクエリに対して部分的なレスポンスが返されるほどの大きなボリュームがあったことを意味します。 「next」要素の値はクエリごとに変わり、不透明な文字列として扱う必要があります。レスポンス本文では「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"
        }
    }
前回のクエリで返された ‘next’ 要素を、クエリ期間内のすべてのカウントを受け取り終えるまで引き続き渡すことができます。‘next’ 要素を含まないレスポンスを受け取った場合は、最終ページに到達しており、その時間範囲で利用可能な追加のカウントはありません。

​
HTTP レスポンスコード

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