X(Twitter)用プロキシを検討する理由は主に3つあります。複数アカウントの管理、API経由のデータ取得、そしてプラットフォームがブロックされている地域からのアクセスです。それぞれに固有のルールがあり、間違ったプロキシタイプを使うと、プロキシなしの場合よりも早くアカウントが凍結される可能性があります。
複数アカウントの運用
Xは公式にはユーザーあたり最大10アカウントを許可していますが、同一IPから複数にログインした瞬間、プラットフォームはそれらを紐付けます。1つがフラグ付けされると、関連するすべてのアカウントがリスクにさらされます。30以上のプロフィールを管理するSMMチームにとって、これは深刻な問題です。
各アカウントには固有のIPアドレスが必要です。しかしそれは半分に過ぎません。Xはブラウザフィンガープリント、Cookie、タイムゾーン設定、行動パターンも追跡しています。セッション分離のないプロキシは、玄関に鍵をかけて窓を開けっぱなしにしているようなものです。アンチディテクトブラウザ(GoLogin、Multilogin、Dolphin Anty)はアカウントごとに個別の環境を構築します。プロキシがIPを処理し、ブラウザがそれ以外すべてを処理します。
アカウント運用には、ISPプロキシがより安全な選択肢です。プラットフォームはログイン時にデータセンターのIP範囲を積極的に検出・フラグ付けします。ISPアドレスは実際のプロバイダーから提供され、通常の家庭用接続のように見えます。 プロキシの種類に関係なく、アカウントごとのアクティビティ制限は適用されます:1日あたりツイート2,400件、フォロー400件、いいね1,000件。これらを超えるとシャドウバンが発動し、投稿が検索やハッシュタグフィードに表示されなくなりますが、通知は一切届きません。気づかないうちに見えない存在になります。
APIアクセス
Xは2023年2月に無料APIアクセスを廃止しました。現在の料金体系:
- Free:月1,500投稿(読み取り)、1日50ツイート(書き込み)。テスト用としてもほぼ不十分です。
- Basic($200/月):10,000投稿/月
- Pro($5,000/月):月間100万投稿。
- Enterprise($42,000+/月):5,000万件以上。
レート制限はアプリごと、かつ15分間のウィンドウごとに適用されます。複数のアプリを運用している場合や、より高いスループットが必要な場合は、複数のAPIキーにコールを分散させ、それぞれを独自の 専用プロキシ — 実質的な処理能力を倍増させます。キーをローテーションするAPIプロキシを使えば、これを自動的に処理できます。APIコールはサーバー間通信のため、 データセンタープロキシ ここでは問題なく機能します。認証済みAPIリクエストに対してプラットフォームがIPタイプをフラグ付けすることはありません。
スクレイピング — 困難な道
APIを使わずにXをスクレイピングするのは終わりなき戦いです。プラットフォームは2〜4週間ごとに防御アップデートを配信し、既存のスクレイパーを無効化します。ゲストトークンはIPに紐づけられ、数時間で失効します。GraphQLエンドポイントのIDは定期的に変更されます。TLSフィンガープリンティングがヘッドレスブラウザを検出します。そしてデータセンターIPは未認証アクセスに対してほぼ即座にブロックされます。
自作スクレイパーの保守には毎月10〜15時間の継続的な作業が必要です。ほとんどのチームにとって、APIアクセスへの課金やマネージドスクレイピングサービスの利用の方が、エンジニアリングコストより安く済みます。
ブロックされた環境でのアクセス方法
一部の国や制限されたネットワーク(学校、オフィスなど)では、Xはファイアウォールレベルでブロックされています。プロキシを使えばトラフィックが別のアドレス経由でルーティングされるため、フィルターにはプラットフォームへの接続が見えません。Twitterへのブロック解除には、適切なホストとポートを設定したシンプルなHTTPプロキシでも十分です。ブロックはネットワーク側の問題であり、X側の問題ではありません。プロキシ設定を構成した任意のブラウザから、x.comのTwitterウェブインターフェースを利用できます。
Twitter アクセスに最適なプロキシはタスクによって異なります。アカウント管理にはISPプロキシ、API作業にはデータセンタープロキシ、制限されたネットワークでのTwitterブロック解除にはどちらのタイプでも対応可能です。