X（Twitter）内部APIとSNS自動化業者エコシステムの構造分析
はじめに
以下、やってはいけないので、興味本位に知るだけにしておいてね。
僕はやってないよ。公式使ってるんでね。
X API v2のBasicプラン（月額100ドル）からPro（月額5,000ドル）への急激な値上げ・仕様変更を経て、最終的にPay-Per-Use（従量課金）モデルへ転換しました。
合法的な公式API契約を維持しながら運営する立場から見ると、SNS界隈には「公式APIで真面目にやってる人」と「内部APIを使い倒す業者」の間に巨大なコスト・スピードギャップが存在することが見えてきます。
本記事では、Yahoo!ニュース等で話題になった「Xインプレ操作業者」の技術的・経済的構造を、リバースエンジニアリング・住宅プロキシ市場・検知メカニズム・法的論点の4つの軸から解説します。
本記事の目的: 業者の手口を批判的に分析し、健全な開発者が市場構造を理解した上で適切な戦略を取れるようにすることです。具体的な実装手順や攻撃コードは記載しません。
1. 「裏口API」の正体
巷で「裏口API」と呼ばれているものの正体は、公式Xアプリ自身が使っている内部API（Private API / Undocumented API） です。
公式API vs 内部API
| 項目 | 公式API（v2） | 内部API |
|---|---|---|
| 認証 | API Key + Bearer Token | アカウントの Cookie + ct0 |
| 月額固定費 | $200〜$5,000+ | なし |
| 規約上の扱い | 正規 | 規約違反 |
| ドキュメント | 公開 | 非公開（リバース解析） |
| Rate Limit | プラン依存 | Webクライアント相当 |
外部開発者向けに公開されている v2 API とは別系統で、X公式アプリ ⇔ Xサーバー間の通信用に使われています。X社はドキュメント化していませんが、技術的には「公式アプリと同じリクエストを送れば同じ動作をする」だけの話です。
リバースエンジニアリングの手法
業者がやっていることは概ねこのフローです。
- 公式アプリ（APK / IPA）を取得
- mitmproxy / Frida / Burp Suite で通信を傍受
- GraphQL エンドポイント（XはGraphQLを多用）の構造、必要なヘッダー、署名アルゴリズムを抽出
- リクエストをスクリプトで再現
一度解析できれば、HTTPリクエスト1発 = 1アクション。実機もエミュレータもUI描画も不要なので、速度・コスト・スケーラビリティが桁違いです。
公開ドキュメント
リバース成果は GitHub に複数公開されています。代表的なのは以下の2つ。
- fa0311/TwitterInternalAPIDocument: 日本人開発者がメンテしている、最も体系的なドキュメント。Stable / Develop / Logged in / Twitter Blue の4ブランチで構成。GraphQLクエリID、features フラグ、リクエスト/レスポンススキーマを JSON で網羅。
- trevorhobenshield/twitter-api-client: v1 / v2 / GraphQL をPythonで叩ける実装ライブラリ。コードを読むのが事実上のドキュメント代わり。
これらは研究・解析用途として中立的にまとまっていますが、フォーク先には露骨に「impression farm用」を謳うリポジトリも存在します。
2. 内部APIの認証構造
公式APIとの最大の違いは「APIキーが要らない」ことです。
必要なもの
Bearer Token（公式アプリに固定）
+ Cookie（auth_token = ログイン後に発行）
+ ct0（CSRFトークン）
つまり**「APIキー」ではなく「アカウントそのもの」が認証クレデンシャル**。Bearer Token はアプリにハードコードされた固定値で、DevTools で https://x.com/ の通信を見れば3秒で観察できます。
# ゲストトークン取得（POST必須）
curl -X POST 'https://api.x.com/1.1/guest/activate.json' \
-H 'Authorization: Bearer AAAAAAAAAAAAAAAAAAAAANRILgAAAAAA...' \
-H 'Content-Length: 0'
「Bearer Token を盗めば何でもできる」は誤解
Bearer Token は「このリクエストはX公式アプリから来てます」を示すアプリ識別子に過ぎません。実際にツイート・いいね・フォローするには Cookie + ct0 が必要で、それを取るにはアカウントにログインが要る。
つまり業者のボトルネックは Bearer Token ではなく、アカウントの大量調達です。エイジドアカウント（数年寝かせた古いアカウント）が闇マーケットで1個 500〜5,000円で売買されているのはこのため。
3. 住宅プロキシ市場の構造
X側の検知を回避するには、住宅用 IP アドレスが必要です。データセンタープロキシ（AWS、GCP）は ASN 情報で即バレします。
IP の調達ルート
| 種別 | 仕組み | 合法性 |
|---|---|---|
| SDK埋め込み型 | 無料VPN・ゲームに収益化SDKを組込み、ユーザー回線を借りる | 規約上は同意済み（実態はグレー） |
| P2P型 | Honeygain・Pawns.app のように本人同意で回線提供 | 合法 |
| ボットネット型 | マルウェア感染機器を勝手に踏み台化 | 完全に違法 |
主要業者と価格
| 業者 | 単価 | 特徴 |
|---|---|---|
| Bright Data | $8.4/GB〜 | 業界最大手、KYC厳格、SNS用途は契約段階で弾かれる |
| IPRoyal | $1.75〜$3.68/GB | コスパ最強、Pay-as-you-go対応 |
| SOAX | $3.6/GB | クリーンプール、企業向け |
| Smartproxy / Decodo | $3.68〜$7.5/GB | 中庸、ダッシュボード使いやすい |
日本IPの在庫状況（2025年時点）
| 業者 | 日本IP数 |
|---|---|
| Bright Data | 約688,000 |
| IPRoyal | 約487,000 |
| SOAX | 約210,000 |
| SimplyNode | 約162,000 |
| Smartproxy / Decodo | 約100,000 |
「日本IP」と一口に言っても、中身は
- Residential（NTT・KDDI・SoftBank等のISP回線）
- Mobile（docomo・au・SoftBankのキャリア回線、最も検知されにくい）
- ISP / Static Residential（住宅IPをデータセンターでホスト）
- Datacenter（避けるべき）
の4種類があり、X側は ASN 単位で判定するため、契約前に whois で素性確認が必須です。AS17676（SoftBank Mobile）、AS4713（NTT OCN）、AS2516（KDDI）などが「真の」住宅・モバイルIP。
自分の回線を貸し出すリスク
Honeygain・Pawns.app に登録すれば月数百円〜数千円もらえますが、事業者にとっては割に合いません。
理論上は「悪用されても予見可能性なしで過失なし」とされやすいですが、
- 児童ポルノ流通・テロ・薬物取引の中継点になると家宅捜索リスク
- 開発機・サーバー証跡を一時的にでも押収されると事業に直撃
- 月数百円の収益と期待損失が釣り合わない
合理的判断としてはやらない一択です。
4. 業者の経済合理性
業者目線で1アカウント運用する原価を分解すると、以下のようになります。
| 項目 | 単価 |
|---|---|
| エイジドアカウント | 500〜5,000円（一回限り） |
| 住宅プロキシ（中堅） | 月10〜100円/アカ |
| SMS認証（必要時） | 50〜200円 |
| 自動化スクリプト（償却） | 数円/月 |
→ アカウント1個あたり月100〜200円で運用可能。1,000アカ運用しても月10〜20万円。インプレ販売単価が「1万インプレ500〜2,000円」とかなので、規模次第で十分にペイする商売構造になっています。
公式APIとのコスト比較
公式API Pro プランは月額5,000ドル。同じトラフィック量を内部API + 住宅プロキシで処理すると、1/100 以下のコストで済むケースがあります。
X 社が中間プラン（月100〜500ドル帯）を厚くしない限り、この経済合理性のギャップが内部API利用の温床になり続けます。
5. X側の検知メカニズム
X側の検知ロジックは多層化しています。プロキシのIP変えるだけでは守れません。
検知レイヤー
- TLS指紋（JA3 / JA4）: Pythonの requests と公式アプリでは TLS握手の仕方が違う
- HTTP/2フィンガープリント: フレーム順序、SETTINGS値
- Canvas / WebGL指紋（ブラウザ自動化の場合）
- アカウント年齢 × 行動の不整合: 新規アカが即100フォロー等
- 行動パターン: 人間離れした時間帯・間隔
- アカウントクラスタ: 同じプロキシ・同じUA・同じ行動で動くアカ群
業者の対抗策
- curl_cffi 等で公式アプリの TLS指紋を偽装
- 住宅プロキシで IP を大量分散
- SMS認証用の SIM 大量調達
- エイジドアカウントの利用
駆逐できない構造的理由
X側がいくら検知強化しても、
- 1アカBANされても即補充できる供給ライン（エイジドマーケット）
- 個別アカウントは「普通の人」と区別困難
- 検知強化しすぎると正常ユーザーの誤BAN増 → 収益減
完全駆逐は原理的に不可能で、「コストを上げて割に合わなくする」のが現実的な対策の限界です。
6. 法的論点（司法書士視点）
私は司法書士資格を保有しているので、業者の各行為がどの法令の射程に入るかを整理します。
適用されうる法令
| 法令 | 適用シーン |
|---|---|
| 不正アクセス禁止法 | 他人アカウントの認証情報を不正取得・利用 |
| 電子計算機損壊等業務妨害罪（刑234条の2） | 偽情報注入で業務妨害が認められる場合 |
| 景品表示法（ステマ規制、2023年10月施行） | 広告主が業者に依頼してインプレを買う場合 |
| 金融商品取引法 158条（風説の流布） | 株価操作目的でのインプレ拡散 |
| 民事: X Corp との利用規約違反 | 損害賠償（米国では訴訟事例あり） |
「自前のアカウントを大量運用」だけならどうか
- 自分が作ったアカウントに自分が認証情報でログインする限り、不正アクセス禁止法の構成要件には当たらない（規約違反は民事の話）
- ただし買ってきたエイジドアカウントを使う場合、元の所有者が存在するため不正アクセスに該当しうる
- 偽情報の組織的拡散を伴うと、業務妨害罪の射程に入るリスク
業者は法的グレーゾーンで動いていますが、金融市場への影響を伴う行為は警察・SESC・取引所の監視対象になります。
7. 健全プレイヤーの戦略
ここまで分析した上で、合法プレイヤーが取るべき戦略を整理します。
やるべきでないこと
- 内部APIを使った自動化の自前実装（規約違反）
- エイジドアカウントの購入・運用
- Honeygain等での回線貸し出し（事業者には期待損失が大きすぎる）
- 闇プレイヤーと同じ土俵での価格・規模競争
やるべきこと
① 公式APIを前提にしたコスト構造設計
Pay-Per-Use化することでユーザーに API 単価を直接転嫁。固定費を持たないモデルへ。
② 闇業者が真似しにくい付加価値領域へシフト
- 生成AIによる投稿支援（API原価が乗るので業者は採算合わない）
- 法人向けコンプライアンス・分析機能
- 公式API認可済みの正規連携
③ 住宅プロキシは正当業務に限定して活用
- SEO 順位の地域別チェック
- 広告配信検証
- 海外SaaSの価格表示確認
- 競合の地域別表示確認
IPRoyal の Pay-as-you-go なら月10〜30ドルで十分回せます。
④ 異常検知側の発想を持つ
公式アプリの DevTools で GraphQL クエリ（CreateTweet、FavoriteTweet、UserByScreenName 等）の粒度を観察すると、業者がどのエンドポイントを大量発行しているか想像できるようになります。これは健全運営側のレピュテーション保護にも役立ちます。
おわりに
X の表示回数操作問題は、技術論だけでも、法律論だけでも、経済論だけでも語れません。
- 技術: 内部APIは公開アプリのリバース解析で誰でも実装可能
- 市場: 住宅プロキシとエイジドアカウントの闇マーケットが原価を下げている
- 検知: X側は完全駆逐できず、コスト戦争に持ち込むしかない
- 法律: 自前運用と他人アカウント運用で適用法令が大きく変わる
公式API側でビジネスを設計している身としては、X社が中間価格帯のAPI プランを整備することが業界全体の健全化に最も効くと感じています。月5,000ドルか月100ドルしかない現状では、合法プレイヤーが事業として成立する余地が狭すぎる。
自身の運用設計を見直す材料、あるいは異常検知側の発想を持つきっかけとして、本記事が役立てば幸いです。
参考リポジトリ・リソース
- fa0311/TwitterInternalAPIDocument
- trevorhobenshield/twitter-api-client
- IPRoyal、SOAX、Smartproxy / Decodo（各社公式サイト）
- 不正アクセス行為の禁止等に関する法律
- 金融商品取引法 158条
phpでも使えるの？
PHPの致命的な弱点：TLSフィンガープリント
ここがPHPで内部APIを叩くときの最大の壁。
X側は前述の通りJA3/JA4のTLS指紋で「公式アプリかどうか」を見てる。PHPの cURL（libcurl）と Python の requests は、両方ともデフォルトの TLS握手パターンが公式アプリと違う。だから即「Bot判定」される。
Pythonには curl_cffi という決定的なライブラリがある。これはBrowser Impersonation機能を持っていて、Chrome や Safari、iOS の TLS指紋を完全模倣できる。
python# Python: curl_cffi で iOS の TLS指紋を完全模倣
from curl_cffi import requests
resp = requests.get(url, impersonate="safari17_0")
PHPにはこの決定打にあたるライブラリが存在しない。これがPHPが内部API用途で主流にならない最大の理由。
その通り。「内部APIの認証 = 通常アカウントとしてのログイン」だから、Rate Limit も普通のアカウントと完全に同じ。これが業者の最大のボトルネックになってる。
Xの主要なRate Limit（ログイン済みユーザー）
X側は公式に詳細を公開してないけど、観察ベースで判明してる主な制限：
| アクション | 制限の目安 |
|---|---|
| ツイート投稿 | 約 300/日（新規アカは50/日）、上限到達後は数時間〜24時間ロック |
| いいね | 約 1,000/日 |
| フォロー | 約 400/日（急に大量フォローは即制限） |
| DM | 約 500/日 |
| リツイート | 約 300/日 |
| GraphQLクエリ全般 | 各エンドポイント 15分あたり 50〜500回 |
UserByScreenName |
15分で約 95回 |
TweetDetail |
15分で約 150回 |
UserTweets |
15分で約 500回 |
15分ウィンドウ制で、超えると 429 Too Many Requests を返してきて、残り時間は x-rate-limit-reset ヘッダーに書いてある。
「アカウント年齢」で制限が変わる
ここが重要。X側は新規アカウントに対して段階的に制限を緩める仕組みになってる。
| アカウント状態 | 1日あたり投稿上限の目安 |
|---|---|
| 新規（〜1週間） | 50件 |
| 1週間〜1ヶ月 | 100件 |
| 1ヶ月〜半年 | 200件 |
| 半年以上 + 認証済み | 300件 |
| Blue 課金 | 約 4,000件（ただしAPI経由は別カウント） |
エイジドアカウント（数年寝かせたアカウント）に業者が高値払うのは、ここの初期制限を回避できるから。新規アカ1個に5,000円払う理由はこれ。
「叩く頻度」で凍結される
回数だけじゃなくて時間あたりの集中度も見られる。例えば：
- 1秒間に10連投いいね → ほぼ確実に制限
- 1分あたり1いいねのペースで100回 → 通る可能性高い
人間の操作速度を超えると、Rate Limit の数字に達してなくてもヒューリスティック検知で短時間ロックされる。
だから業者は「水平スケール」する
1アカで1日300ツイートしか打てない → 1,000アカ運用すれば30万ツイート/日。
ここが業者の経済設計の核心：
1アカ運用コスト: 月100〜200円
1アカで打てるアクション: 1日数百回 × 30日 = 月数千〜1万回
1アクションあたりの原価: 約0.01〜0.05円
この単価で「1万インプレ500円」とかで売るから利益が出る。
Cookie認証だから「同時ログイン」も制限あり
実は内部API使うときの隠れた落とし穴で、X側は同一アカウントの同時セッション数もモニタリングしてる。
- 普通のユーザーはスマホ1台 + PC1台 = 2セッション程度
- 業者が同じアカに10台のサーバーから同時アクセスすると即異常検知
なので業者は「1アカ = 1サーバー（or 1プロセス）」で完全分離して運用してる。Cookie の使い回しもしない。
まとめ
- 内部APIのRate Limit = 普通のアカウントと同じ（1アカ単位）
- アクション種別 × アカウント年齢 × 集中度 で動的に決まる
- 業者は「水平スケール（アカ大量保有）」で総量を稼ぐ
- 公式APIは「アプリ単位 + ユーザー単位」のダブルカウントで、業者が嫌う構造になってる
- 結局**「アカウントの数」が業者の供給力を決める**ので、エイジドアカウントの闇マーケットが業界の生命線