【2026年版】n8n での Twitter API：HTTP リクエストで X データを取得

著者：Sorsa Editorial

更新：2026年7月6日。1,000ツイートおよびプロフィールあたりで示すリクエストベースの料金、100回分の無料リクエストの開始オファー、2026年4月20日の変更後の X の従量課金 API レート、現行の n8n の X ノードの操作セット、そして検証済みの HTTP リクエストのページネーションのレシピで刷新しました。

要点： Twitter/X データを n8n に取り込むには、HTTP リクエストノードを使って読み取り専用の Twitter データ API を呼びます。組み込みの X ノードは、有料の公式 X API を通じて投稿、いいね、リツイート、そして限定的な検索しかできません。API キーヘッダーで認証し、カーソルでページネーションし、結果を Google Sheets に保存します。

ほとんどの n8n ビルダーは同じ壁にぶつかります。ネイティブの X（Twitter）ノードは、読むためではなく公開するために作られました。ツイートの投稿、DM の送信、薄い検索の実行を、すべて公式 X API 経由で計測します。完全なタイムライン、フォロワーリスト、メンション、または量のある過去データが欲しくなった瞬間、HTTP リクエストノードに降りて、それをデータ API に向けます。読み取り専用の Twitter/X API である Sorsa API は、まさにその呼び出しのために作られています。ApiKey ヘッダーの中の1つのキー、フラットなリクエスト単位の課金（1回の呼び出しが1リクエスト、作者プロフィール込み）、すべてのプランで一律の毎秒20リクエスト、そして開発者アカウントの審査待ちの行列はありません。バッチ料金は1,000ツイートあたり$0.02、1,000プロフィールあたり$0.01からで、公式 API のリソース単位の読み取りレートの最大50分の1、そして100回分の無料リクエスト（1回限り・クレジットカード不要、40個のエンドポイントすべて）が、プランを選ぶ前のフルテスト実行をカバーします。

n8n は Twitter/X データを取得できる？それともノードは投稿だけ？
公式 API なしで Twitter/X データを n8n に取り込む
HTTP リクエストノードをステップごとに設定する
n8n と X データのよくあるワークフロー
2026年に n8n で X データを取得するといくらかかるか
よくある質問

n8n は Twitter/X データを取得できる？それともノードは投稿だけ？ {#can-n8n-pull-twitterx-data-or-does-the-node-only-post}

n8n の組み込みの X ノードは書き込み重視です。n8n 自身のドキュメントによると、このノードはダイレクトメッセージを作成し、ツイートについては削除、検索、いいね、リツイートをサポートします。フォロワーリスト、完全なタイムライン、メンション、引用ツイート、または過去検索の操作はなく、提供する1つの検索は有料の公式 X API で動きます。

それが人々を驚かせるギャップです。このノードは公開には本当に有用です。ツイートのスケジュール、自動返信、トリガーでのリツイートです。公開データの読み取りには、ほとんど何もせず、その少しできることも X によってスロットルされ計測されます。

なので n8n での読み取りの経路は HTTP リクエストノードです。それは、n8n が専用ノードを出荷していないあらゆる REST API のための万能コネクターで、Twitter データ API はまさにそれです。メソッド、エンドポイント URL、認証ヘッダー、そしてパラメータを設定すると、JSON がワークフローに戻ってきて、Filter、Code ノード、または Google Sheets の書き込みの準備が整います。

当社は読み取り専用の X API を毎日ビルドして運用しており、実務での役割分担はきれいです。目的が X に対して動作する（投稿、いいね、DM）ことならネイティブノードを、目的が X からデータを取り出す（ツイート、プロフィール、フォロワー、検索）ことなら HTTP リクエストノードを使います。両者は同じキャンバス上で共存します。

公式 API なしで Twitter/X データを n8n に取り込む {#getting-twitterx-data-into-n8n-without-the-official-api}

HTTP リクエストノードからサードパーティの Twitter データ API を呼ぶことで、公式 X API なしで n8n の中の X データを読めます。これらのサービスは公開の X データを自身のインフラで照会して JSON を返すため、X 開発者アカウント、OAuth、アプリ審査は不要です。「API キーなし」という言い回しは、ほとんどの場合 X API キーなしを意味します。データプロバイダーは依然として自身のキーを発行します。

その区別は重要です。なぜなら、本当にキーなしの選択肢こそが脆いものだからです。

コミュニティのスクレイパーノード。 n8n-nodes-twitter-scraper のようなパッケージは存在し、内部でスクレイピングを通じて動作します。落とし穴はその自身のドキュメントにあります。ノードは Rettiwt ライブラリを使い、その「キー」は公式 API ではなく X のウェブインターフェースから導出した認証です。平たく言えば、ログイン済みのセッショントークンに乗るもので、それは背後のアカウントをフラグ付けされ得るし、X がウェブの内部を変えるたびに壊れます。またコミュニティノードとしてインストールされ、それは n8n Cloud ではデフォルトでオフです。

Apify のアクター。 よくあるチュートリアルの経路は、Apify の Twitter アクターを HTTP リクエストノードまたは Apify ノードを通じて n8n に配線します。それは動作し、ローテーションするプロキシを同梱しますが、スクレイプしたレコード単位で課金し、ワークフローの上にアクター実行のオーケストレーション層（実行を開始、終了を待つ、データセットを取得）を加えます。

マネージドの読み取り専用 API。 最も保守の少ない経路は、HTTP リクエストノードから直接呼ぶ、ホスト型の Twitter データ API です。公開データをサーバー側で照会するため、自分の X ログインを一切さらさず、それこそがクッキーベースのスクレイパーでアカウントが停止される元凶です。Sorsa はそうした選択肢の1つです。1つの ApiKey ヘッダー、OAuth なし、承認の列なし、そして数分で終わるセットアップです。懸念が特に開発者アカウントの障壁なら、その経路は開発者アカウントなしで X データを使うガイドで詳しく扱っています。

公開の X データを読むのはルール違反でしょうか。マネージド API を通じて公開の、ログインしていないデータを取得するのは、スクレイプしたセッションクッキーで個人アカウントを自動化するのとは異なるリスクプロファイルです。マネージド API が取得を行い、n8n ワークフローは JSON を消費するだけです。トレードオフのより広い見方は、X データをスクレイピングする方法の内訳をご覧ください。

HTTP リクエストノードをステップごとに設定する {#configure-the-http-request-node-step-by-step}

Twitter データ API のために HTTP リクエストノードを設定するのは、4つの設定に帰着します。リクエストメソッド（GET または POST）、エンドポイント URL、API キーを運ぶ認証ヘッダー、そしてユーザー名または検索クエリのためのボディまたはクエリパラメータです。複数ページにまたがる結果には、ノードのカーソルページネーションをオンにして、レスポンスのカーソルを自動でたどらせます。

メソッド、URL、ApiKey ヘッダーを設定する

エンドポイントによって異なる HTTP メソッドを使い、それらを混同するのが最もよくある最初のミスです。プロフィールとフォロワーの照会は GET、ツイート検索とタイムラインは POST です。キーは（Bearer トークンとしてではなく、URL にも決して入れず）ApiKey という名前のヘッダーで渡します。n8n では、ハードコードするのではなく Header Auth 認証情報として保存します。認証情報は暗号化されたままノード間で再利用できるからです。ヘッダーの形式は認証リファレンスに記載されています。

GET の照会は、GET の HTTP リクエストノードに直接対応します。

bash

curl -H "ApiKey: YOUR_API_KEY" \
  "https://api.sorsa.io/v3/info?username=nasa"

POST の検索は、JSON ボディを持つ POST ノードに対応します。

bash

curl -X POST "https://api.sorsa.io/v3/search-tweets" \
  -H "ApiKey: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"query": "from:nasa moon", "order": "latest"}'

検索エンドポイントは query の中で Twitter の高度な検索の構文（from:、since:、until:、引用符のフレーズ、ハッシュタグ）をサポートします。limit パラメータはなく、ページサイズは固定で、カーソルで結果をたどります。完全なコマンドセットは、高度な検索コマンドのチートシートにあります。

n8n でカーソルページネーションを扱う

ページネーションのあるエンドポイントは next_cursor フィールドを返します。それが null または存在しないとき、もうページはありません。n8n の HTTP リクエストノードは、Code ノードなしでこれをたどれます。Options を開き、Pagination を有効にして、次を設定します。

ページネーションモード（Pagination Mode）: Update a Parameter in Each Request
タイプ（Type）: POST エンドポイント（検索、タイムライン）には Body、GET エンドポイント（フォロワー、フォロー中）には Query
名前（Name）: next_cursor
値（式）: {{ $response.body.next_cursor }}
完了条件（Pagination Complete When）: Other（Complete Expression）で {{ !$response.body.next_cursor }} を設定

ループの中に短い間隔か Wait ノードを追加して、長い実行がレート制限の下に留まるようにします。このパターンは n8n の HTTP リクエストのページネーションのクックブックに記述されています。手動版のほうが好きなら、next_cursor が存在するかをチェックしてループバックする IF ノードでも動きますが、このようなきれいな JSON カーソルには組み込みのページネーションのほうがすっきりします。データ側のカーソルの契約はページネーションの下に記載されています。

結果を保存する

JSON が流れ始めたら、Google Sheets ノードが各ツイートやプロフィールを行として追加し、Remove Duplicates ノードが、再実行するワークフローが同じレコードを二度記録するのを防ぎます。それのエンドツーエンド版は、リクエストから満たされたシートまで、X データを Google スプレッドシートにエクスポートするで案内しています。

n8n と X データのよくあるワークフロー {#common-n8n-and-x-data-workflows}

これらが実際に作られるパターンです。それぞれが1つの HTTP リクエストノードと、選んだ保存先です。

ユーザー名でユーザーのツイートを取得する

POST /user-tweets は、任意の公開アカウントのページネーションされたタイムライン（1ページあたり約20ツイート）を返します。ハンドルのリストを Loop Over Items ノードに通せば、複数アカウントのタイムライン収集器ができます。

キーワードやクエリでツイートを検索する

POST /search-tweets は、order を popular または latest に設定したクエリを実行します。これはトピック監視、ハッシュタグ追跡、データセット構築の主力です。

スケジュールでブランドのメンションを監視する

POST /mentions は、ハンドルに言及するツイートを返し、素の検索にないフィルターを加えます。min_likes、min_replies、min_retweets、since_date、until_date です。Schedule Trigger と組み合わせて数分ごとに実行します。これはソーシャルリスニングのセットアップの中核で、日付フィルターが低価値のノイズをデータベースから締め出します。

フォロワーとフォロー中のリストを抽出する

GET /followers、GET /follows、GET /verified-followers はそれぞれ、リクエストあたり最大200件のユーザープロフィールを返し、利用可能な呼び出しあたりの収量の高いものの1つで、それがオーディエンスとリードのワークフローを安く実行できる理由です。仕組みは、フォロワーとフォロー中のエンドポイントガイドで扱っています。

プロフィールのリストを一括で充実させる

GET /info-batch は最大100件のユーザー名または ID を受け付け、それらすべてのプロフィールを1回のリクエストで返すため、そうでなければ100回ループする CRM 充実のステップが1回の呼び出しになります。

懸賞やキャンペーンのアクションを検証する

POST /check-follow は、あるアカウントが別のアカウントをフォローしているかに答えます。check-retweet と check-comment は、リツイートと返信に同じことをします。自分のルールに対してエントリーを検証するワークフローの中で、それらを連結します。

場所別にトレンドを追跡する

GET /trends は WOEID（場所の識別子）を取り、その地域のトレンドトピックを返し、Slack やメールにパイプする日次のトレンドダイジェストに有用です。

2026年に n8n で X データを取得するといくらかかるか {#what-it-costs-to-pull-x-data-in-n8n-in-2026}

コストこそ、バックエンドの選択が実際にプロジェクトを決めるところです。公式 X API は取得したリソース単位で課金します。レスポンスの中のすべての投稿とすべてのプロフィールが別々の課金単位です。フラットなリクエスト単位の API は、何件の項目が返ってこようと呼び出し単位で課金します。n8n が向いている、読み取りの多い、常時稼働のワークロードでは、この2つのモデルは速く分岐します。

X は2026年2月に新規開発者のデフォルトとして従量課金に移り、2026年4月20日の更新がレートを再び作り替えました。投稿の読み取りは各$0.005、ユーザーの読み取りは各$0.010、フォロワーの読み取りは各$0.010、無料枠はなく、従量課金のアカウントは月間200万投稿の読み取りに制限されます。標準の投稿作成は$0.015に上がり、URL を含む投稿は$0.20に跳ね、そしてフォロー、いいね、引用投稿の書き込みは Enterprise 限定に移りました。古いガイドの多くは、廃止された「$100〜$200の Basic」のサブスクリプション層をいまだに引用します。それらは新規登録に閉じられています。現行の完全な内訳は、2026年版 Twitter API 料金ガイドにあります。

以下は同じデータを、n8n の2つの実用的なバックエンドを通して見たものです。公式 X API はネイティブノードがすでに使うもので、フラットな代替は HTTP リクエストノードが呼ぶものです。

項目	公式 X API（従量課金）	Sorsa API
課金モデル	取得したリソース単位	リクエスト単位（フラット）
1,000ツイートの読み取り	$5.00（作者プロフィールごとに$0.010追加）	Pro でバッチエンドポイント経由$0.02から（呼び出しあたり最大100ツイート）、ページネーション検索経由で約$0.10、どちらも作者込み
1,000プロフィールの読み取り	$10.00	Pro で約$0.01（フォロワーエンドポイント経由5リクエスト、各最大200）
レート制限	エンドポイント別の15分の窓（エンドポイントにより変動）	一律20リクエスト/秒、全プラン
認証	OAuth 2.0 + ベアラートークン	単一の API キーヘッダー
セットアップ	開発者アカウント + アプリ審査	約3分、承認なし
月次の入口	従量課金、無料枠なし、200万投稿読み取り上限	100回分の無料リクエストで開始、その後10,000リクエストで月額$49から
書き込みアクセス	投稿と DM（フォロー、いいね、引用投稿は Enterprise 限定）	なし（読み取り専用）
ツイートレスポンス内の作者プロフィール	ユーザー読み取りとして別課金	無料で込み

一行の要点：読み取り専用の n8n ワークフローには、公式 API はすべてのツイートとすべてのプロフィールを別々に課金し、一方フラットなリクエスト単位の API は、作者データ込みで呼び出しあたり1単位を課金するため、フラットモデルは読み取りの多い自動化では安くも予測しやすくもあります。

ワークフローが投稿、DM の送信、またはフォロー・いいね・引用のアクションの実行を必要とするなら、それは公式 API の領分で、Sorsa は設計上読み取り専用です。承認の列なしで、フラットで予測しやすい価格で公開データを読むには、リクエストベースのモデルが基準にすべきものです。公開されている料金プランは1,000ツイートあたり$0.02から始まり、プランは呼び出し単位で課金される10,000リクエストで月額$49からです。

ほとんどの n8n のスクレイピングチュートリアルは、代わりにレコード単位で計測されるバックエンド、たとえば twitterapi.io（1,000ツイートあたり約$0.15、1,000プロフィールあたり$0.18）や Apify の Twitter アクター（1,000ツイートあたりおよそ$0.40、アクターにより変動）を配線します。どちらも返されるすべての項目に課金するため、同じアカウントを数分ごとに再取得する24時間365日の Schedule Trigger は、予測できない請求を積み上げ得ます。フラットなリクエスト単位のモデルは異なる挙動をします。1回の呼び出しは、1項目を返そうと200項目を返そうと1リクエストと数え、バッチエンドポイントは最大100ツイートまたは100プロフィールを1回のリクエストに畳み込み、実効レートは1,000ツイートあたり$0.02、1,000プロフィールあたり$0.01から、その両方のレコード単位のバックエンドを下回ります。ループをバッチや200プロフィールのフォロワーページに置き換えられるところでは、リクエスト数、そして請求が急に下がります。そのための戦術は、API 使用量の最適化のノートにあります。

実際のコストのパターン

公式 API から移行を手伝ったソーシャルリスニングのセットアップ全般で、同じ形が繰り返し現れます。一例：小さな分析エージェンシー、およそ8人が、一連のアカウントと検索語を数分ごとにポーリングする24時間365日のブランドメンション監視を n8n で動かしていました。公式 X API のリソース単位の料金では、その量（返信と引用を数えると月間100万投稿読み取りを優に超える）は4桁ドルの月次請求を指し示し、200万投稿読み取りの上限に近く座っていました。同じ HTTP リクエストノードをフラットなリクエスト単位のプランに向け直したことで、監視全体が固定の月次コストに収まり、メンションエンドポイントの min_likes と日付フィルターが、ノイズがデータベースに届く前にそれを刈り取りました。

よくある質問 {#faq}

n8n の X（Twitter）ノードは非推奨？

n8n の X（Twitter）ノードは非推奨ではなく、まだ動きますが、書き込み重視で、その古い OAuth 1.0a 認証は V2 ノードで廃止されました。DM を作成し、公式 X API を通じてツイートの削除、検索、いいね、リツイートをさせます。公開データを規模で読むには、n8n ビルダーは代わりにデータ API を持つ HTTP リクエストノードを使います。

n8n には組み込みの Twitter スクレイパーがある？

いいえ、n8n には組み込みの Twitter または X スクレイパーはありません。ネイティブの X ノードは有料の公式 API で公開と浅い検索を実行し、コミュニティのスクレイパーノードはよく壊れるログイン済みセッショントークンに依存します。標準のアプローチは、ツイート、プロフィール、フォロワーをきれいな JSON として返す読み取り専用の Twitter データ API を呼ぶ HTTP リクエストノードです。

同じ n8n のセットアップでツイートの読み取りと投稿ができる？

はい、ただしそれらは2つの異なる接続です。ネイティブの X ノードは公式 X API を通じて投稿、DM、いいね、リツイートを扱い、一方ツイート、フォロワー、メンションを量で読むのはデータ API に向けた HTTP リクエストノードを通じて動きます。多くのワークフローが両方を組み合わせます。片方で読み、もう片方で公開し、同じキャンバス上で行います。

n8n で X データを取得する無料の方法はある？

n8n で量のある X データを取得する信頼できる無料の方法はありません。公式 X API は2023年に無料枠を落とし、公開の Nitter インスタンスは不安定で、コミュニティのスクレイパーノードはアカウント停止のリスクがあるログイン済みセッションクッキーに乗ります。自身のキーを持つ低コストのマネージドデータ API が頼れる経路で、通常は数千レコードで数ドル、そしていくつか、その中の Sorsa は、支払う前にワークフローをテストするための100回分の無料リクエスト（クレジットカード不要、1回限り、40個のエンドポイントすべて）を含みます。

n8n で X データを取得する際にレート制限をどう避ける？

n8n でレート制限を避けるには、ページネーションループの中に Wait ノードでリクエストの間隔を空け、シンプルで寛容な制限のデータ API を選びます。Sorsa は、エンドポイント別の窓も15分のリセットもなく、すべてのプランで一律の毎秒20リクエストを適用するため、ワークフローは実行の途中でクォータを引っかけずにフォロワーや検索結果をページネーションできます。

n8n で古いツイートや過去のツイートを取得できる？

はい。データ API がアーカイブ検索を公開しているとき、HTTP リクエストノードは n8n で過去のツイートを取得できます。Sorsa の検索と user-tweets のエンドポイントは、2006年まで遡る完全な公開ツイートアーカイブに到達し、日付で区切った取得のためにメンションエンドポイントに since_date と until_date のフィルターがあるため、これから先のツイートを収集するだけでなく、データセットをバックフィルできます。

始め方 {#getting-started}

n8n での X データの読み取りは、2つのノードと1つのキーに帰着します。HTTP リクエストノードを追加し、ApiKey ヘッダーを設定し、必要なエンドポイントに向け、カーソルページネーションをオンにします。Sorsa の API キーは開発者アカウントの審査なしで約3分で設定でき、一律の毎秒20リクエストが大きなリストをページネーションで取得する余地を残し、100回分の無料リクエスト（1回限り・クレジットカード不要、40個のエンドポイントすべて）がプランを選ぶ前のフルテスト実行をカバーします。その後バッチ料金は1,000ツイートあたり$0.02、1,000プロフィールあたり$0.01から動作します。n8n の代わりに Make や Zapier を動かすなら、同じデータ API が同じ方法でそれらのツールに収まります。Make 版と Zapier 版をご覧ください。

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

本ガイドは、読み取り専用の X API を本番で運用する当チームの実地の作業と、稼働中のエンドポイントのドキュメントに基づいています。n8n の挙動は、n8n の公式の X ノードのドキュメントとその HTTP リクエストのページネーションのドキュメントに対して確認しました。X API のレートは、2026年4月20日の更新後に現行の X の開発者プラットフォームの料金を反映しています。この比較は、公式 X API と Sorsa を9つの項目にわたって比較検討します。2026年7月6日確認。