2026年版 X API 料金ガイドと実務サマリー

公式確認と更新ポリシー

料金や利用規約は随時更新されます。ここでは公式参照先と更新方針をまとめます。
提示する数値は参考情報です。見積や契約には必ず公式ページの単価・条文を反映してください。更新は四半期レビューと重大変更発生時に行います。

参照元（公式リンクと参照日）

以下は主要な公式ページと参照日の例です。リンク先で最新の記載を必ず確認してください。

• X Developer — Pricing: https://developer.twitter.com/en/pricing （参照日: 2026-05-01）
• X Developer Documentation: https://developer.twitter.com/en/docs （参照日: 2026-05-01）
• X Developer Agreement: https://developer.twitter.com/en/developer-terms/agreement （参照日: 2026-05-01）
• X Developer Policy: https://developer.twitter.com/en/developer-terms/policy （参照日: 2026-05-01）
• X Enterprise / Sales: https://developer.twitter.com/en/enterprise （参照日: 2026-05-01）

どのプランを選ぶか（実務向けの早見）

利用目的と想定トラフィックを整理すれば、必要な機能とコスト帯が見えます。ここでは代表的な利用者像ごとに初期の推奨方針を示します。各項目は後段の比較表やチェックリストで補足します。

個人開発者（学習・検証）

個人検証や学習用途に焦点を当てた選定基準です。

• 無料またはDeveloperの最小プランでまず検証することを推奨します。
• 無料枠の「カード不要／無料」は地域や時期で変わるため、登録前に支払要件を確認してください。
• 使用量をトラッキングし、有料化の閾値を決めておくと切替がスムーズです。

スタートアップ（MVP → 成長）

スケールに合わせた段階的な選定を想定した基準です。

• 初期は従量課金で実際の使用量を把握します。
• 履歴や大量ストリーミングが必要になるなら早めに営業窓口へ見積りを依頼してください。
• 請求書払いを希望する場合は法人情報やKYCが必要になることがあります。

メディア／速報用途

低遅延・高スループットの運用が求められる場合の基準です。

• 中〜上位プラン、またはEnterpriseでSLAとサポートを重視することを推奨します。
• 冗長化・再接続・フェイルオーバー設計を必ず行ってください。

データ解析SaaS／再販前提

大量履歴の利用や二次配布を想定する事業向けです。

• エンタープライズ契約で権利関係とオフボーディング手順を明文化してください。
• ツイート原文の再配布やバルク販売には追加ライセンスが必要な場合が多い点に注意してください。

全プラン一覧と比較（料金モデル・主要機能）

プランの主要差分を横並びで確認できます。ここでは機能差を中心に示します。数値的な単価や上限は公式ページで確認してください。表中のコストは通貨USDでの簡易想定（参考値・ダミー）です。

比較表の構成

表はプラン名、料金モデル、無料枠、利用可能エンドポイント、履歴データアクセス、ストリーミング接続、レート制限、サポート、請求形態、想定コストレンジで構成しています。

機能比較（簡易）

以下は機能ベースの簡易比較です。想定コストは参考値（ダミー）であり、見積に使えません。通貨はUSDです。

通貨はUSDです。上表の「想定コストレンジ」は参考値（ダミー）であり、実見積には公式単価を使用してください。

エンドポイント別コストと見積方法

エンドポイントごとにコスト性質が異なります。ここでは主要なコストドライバーと月間見積の基本式、実務での留意点を示します。

コストドライバー（投稿・取得・検索・ストリーミング・履歴）

各エンドポイント別のコスト特徴を簡潔に示します。

• 投稿（POST）系はリクエスト数課金が発生する場合がありますが、頻度は比較的低いことが多いです。
• 取得（GET）系はリクエスト単位での課金対象になりやすいです。ページングとフィールド指定で抑制します。
• 検索系はフルアーカイブが高単価であることが多く、期間や粒度を限定します。
• ストリーミングは接続時間と同時接続数がコストに直結します。
• 履歴（バルク）取得は別料金や専用契約になることが多く、データ量単価で計上します。

月間コストの基本式

見積テンプレートに入れる基本式を示します。項目を埋めて再計算してください。

月間コスト ＝ Σ(各エンドポイントのリクエスト数 × 単価)
　　　　　＋ ストリーミング接続時間 × ストリーミング単価
　　　　　＋ 履歴取得回数 × 履歴単価
　　　　　＋ 保存データ量（GB） × ストレージ単価
　　　　　＋ サポート／SLA料金（定額）

サンプル計算（参考値・ダミー）

以下は参考値（ダミー）を用いた例です。必ず公式単価で置き換えてください。通貨はUSDです。

参考単価（ダミー）:

• 読取（GET）: $0.0001 / リクエスト（参考値・ダミー）
• 検索（Query）: $0.001 / クエリ（参考値・ダミー）
• ストリーミング: $0.50 / 時間（参考値・ダミー）
• 履歴取得: $0.01 / リクエスト（参考値・ダミー）
• 保存: $0.10 / GB（参考値・ダミー）

想定利用（例）:

• 読取 100,000 件／月
• 検索 5,000 件／月
• ストリーミング 100 時間／月
• 履歴 1,000 件／月
• 保存 10 GB

計算（ダミー単価での内訳）:

• 読取: 100,000 × $0.0001 = $10
• 検索: 5,000 × $0.001 = $5
• ストリーミング: 100 × $0.50 = $50
• 履歴: 1,000 × $0.01 = $10
• 保存: 10 × $0.10 = $1

合計（参考値・ダミー） = $10 + $5 + $50 + $10 + $1 = $76／月

必ず、上記の「参考単価（ダミー）」を公式単価に置き換えて再計算してください。スプレッドシートでは、各行に unit_price を入れて monthly_cost を計算し、合計をSUMしてください。

CSVテンプレート例（列見本）:

Google スプレッドシートの合計例:

• 各行の monthly_cost を計算: =ARRAYFORMULA(B2:B * D2:D)
• 総合計: =SUM(E2:E)

契約チェックリスト：商用利用・再販・SLA・データ権利

契約交渉で具体的に確認すべき条項をチェック項目として整理します。条文そのものは提供できないため、確認ポイントと参照先を明確にしてください。

商用再販・二次配布のチェック項目

再販や二次配布は制限が厳しいため、以下を確認してください。

• 原データ（ツイート原文）の再配布可否と許諾範囲を確認すること。
• 派生データ（集計・分析結果）の提供範囲と表示義務（クレジット）を確認すること。
• サブライセンスや再販に関する追加料金の有無を明確にすること。
• API経由で得たデータのキャッシュ・保存期限や表示ルールを確認すること。

SLA・オフボーディング・データ削除のチェック項目

SLAやオフボーディングは運用に直結します。以下を契約で明文化してください。

• 稼働率保証（%）とクレジット算出方法を確認すること。
• インシデント時の応答時間とエスカレーションフローを定義すること。
• オフボーディング手順（データ提供／削除／移行）を明記すること。
• データ削除要求の処理期限や証跡（どのように削除完了を確認するか）を合意すること。

請求・支払・税処理

請求形態は財務に影響します。次を確認してください。

• 請求書払いの可否と支払条件（支払サイト）を確認すること。
• KYC/法人情報に関する要件と登録手順を把握すること。
• VAT／消費税などの税区分と請求書の記載内容を確認すること。
• 誤請求・過請求時の争訟・返金プロセスを合意すること。

導入・移行・コスト最適化・セキュリティ・代替比較・FAQ

導入から運用までの実務ノウハウと実装者向けの設定例、代替ソリューション比較、導入前チェックリスト、FAQをまとめます。即使える具体例を優先しています。

導入・移行時の手順

移行作業で押さえるべき主要手順を段階的に示します。

1. 現行で使用しているエンドポイント一覧を作成し、Xのエンドポイントへマッピングします。
2. 認証方式（API Key／OAuth）とトークン更新処理を準備します。
3. レート制限差分を洗い出し、スロットリング／バックオフロジックを実装します。
4. ストリーミング／ポーリングの設計を見直し、接続管理を実装します。
5. ステージング環境で負荷試験を行い、実使用のコストと挙動を検証します。

コスト最適化の実践テクニック

実装担当が使える具体的な施策です。

• レスポンスキャッシュを導入し、同一リクエストの頻度を下げます。TTLはユースケースで調整します（例: タイムラインの短期キャッシュ 60〜300 秒）。
• バッチ化・集約クエリでAPIコール回数を削減します。定期集計でコスト削減が可能です。
• 必要フィールドだけを要求（例: tweet.fields, user.fields）してレスポンスサイズを小さくします。
• 増分取得（since_id など）で重複取得を防ぎます。
• ストリーミングでポーリングを減らす設計にすると効率が良い場合が多いです。

実装担当向けの設定例と運用指針

実務で参照しやすいヘッダやスコープ名、ログ保持の目安を示します。

• OAuth スコープ（例）: tweet.read, tweet.write, users.read, offline.access（正式名称は公式ドキュメントを参照してください）。
• レート制限ヘッダ（一般例）: x-rate-limit-limit, x-rate-limit-remaining, x-rate-limit-reset。429時は Retry-After ヘッダを参照。
• ログ保持の目安: アクセスログ 90 日、監査ログや課金証跡は法令や内部規程に応じて 1 年程度を検討。
• シークレット管理: APIキーはシークレットマネージャで保管し、ハードコーディングを避けます。キーのローテーションは方針で定めます（例: 90 日ごとを目安）。

セキュリティ（実務レベル）

APIキー管理やアクセス制御の実装ポイントです。

• シークレットはシークレットマネージャで保管し、環境変数経由でロードします。
• 最小権限の原則でスコープを付与します。
• IP制限やVPCピアリングが可能なら発信元を制限します。
• レート異常や不正アクセスはアラート化して即時対応できる体制を整えます。

代替ソリューション比較（簡易）

機能軸での短い比較表です。コストはUSD/月の想定レンジ（参考値・ダミー）で示します。

想定コストは参考値（ダミー）です。提供範囲・SLA・契約条件を精査してください。

導入前チェックリスト（実務で必須の項目）

導入判断時に最低限確認すべき項目です。

• 公式の料金ページで単価・プラン構成を確認する。
• 見積テンプレートに自社のリクエスト想定を入れて試算する。
• 履歴データや再販が必要なら営業窓口へエンタープライズ見積りを依頼する。
• 利用規約（Developer Agreement/Policy）をリーガルに確認する。
• ステージングでレート制限の動作検証を行う。
• 課金・請求要件を財務と連携して確認する。

よくある質問（FAQ）

Q: 無料プランで商用検証できますか？
A: 小規模な機能検証は可能ですが、無料枠にはレート・機能制限があります。商用運用は有料プランを推奨します。

Q: 履歴データを大量取得して製品に組み込めますか？
A: フルアーカイブは別製品や有料オプションで提供されることが多いです。営業窓口に利用目的と量を伝え、ライセンス条件を確認してください。

Q: 請求書払いはどのプランで可能ですか？
A: 一般に請求書払いはBusiness/Enterprise契約で対応されますが、条件は交渉次第です。

まとめ

ここまでの要点を短く整理します。料金選定は利用エンドポイント、リクエスト量、履歴利用、ストリーミング接続、SLA要件の五つを軸に判断します。見積は必ず公式単価で再計算し、契約では再販・データ権利・オフボーディングとSLAクレジットの条項を確認してください。導入前にステージングでレート検証とコスト試算を行うことを推奨します。

• 公式確認は最優先。リンクと参照日を必ず確認する。
• 見積は「エンドポイント別リクエスト数×公式単価」で算出する。
• 無料枠の要件（カード不要等）は地域・時期で変動する。
• 契約交渉で確認すべきは再販権、オフボーディング、データ削除、SLAクレジット。
• 実装面ではキャッシュ、バッチ、必要フィールド限定、増分取得で大きくコスト削減できる。

参考となる公式ページは冒頭に一覧を示しました。実運用では必ず公式ドキュメントと契約条文で最終確認してください。