Skip to main content

APIでTwitterのアクションを確認する:フォロー、リツイート、コメント、引用

X(旧Twitter)の報酬付きキャンペーンでは、アカウントのフォロー、投稿のリツイート、コメント、コミュニティ参加などを参加者に求めます。公平に報酬を配るには、各参加者が申告どおりに行動したか確認する必要があります。手作業では少人数までしか対応できず、自己申告のチェックボックスだけではボットや不正を招きます。 Sorsa APIの確認用エンドポイントでは、「このユーザーは対象アカウントをフォローしたか」「この投稿をリツイートしたか」「コメントしたか」「コミュニティに参加したか」を調べられます。各確認はAPI呼び出しで明確な真偽値または状態を返し、検証可能で記録を確認できるデータに基づくクエスト、プレゼント企画、紹介プログラム、エンゲージメントキャンペーンを構築できます。 このガイドでは、各確認エンドポイントのコードと、全体を組み合わせたパイプラインを説明します。新規アカウントにはカード不要の無料リクエスト100件があり、全エンドポイントで使えるため、プラン選択前に一連の流れを試作できます。
注: 追加のワークフローと全体の実装例は、ブログのTwitterのアクション確認API:キャンペーン完全ガイドを参照してください。

利用できる確認

確認できるアクション、対応エンドポイント、確認できない項目を整理します。 確認できないもの: 「いいね」です。Xは2024年に「いいね」を非公開にしたため、公式を含むどのAPIでも、特定ユーザーが特定ツイートに「いいね」したかを確認できません。上記5つのアクションを使ってキャンペーンを設計してください。

確認1:アカウントをフォローしたか

「@YourBrandをフォローしてプレゼント企画に参加」といった最も一般的なタスクです。 エンドポイント: POST /v3/check-follow 「user_2がuser_1をフォローしているか」を確認します。user_1をブランド(フォロー対象)、user_2を参加者にしてください。

最小限の例

レスポンス:

パラメーター

それぞれの側について識別子を1つだけ指定します。

Python

user_protectedtrueなら参加者は非公開アカウントで、フォロー関係を確認できません。

確認2:ツイートをリツイートしたか

「この投稿をリツイートして参加」というタスクです。1リクエストで最大100件のリツイートを調べ、それ以上ある場合はページネーションを使います。 エンドポイント: POST /v3/check-retweet

パラメーター

Python

各呼び出しは最新の100リツイートを調べます。多くのキャンペーンでは、参加者が開始直後にリツイートして直近の範囲に入るため、1回で十分です。人気の投稿で早期のリツイートを探す場合は、next_cursorで先のページを調べてください。

確認3:ツイートを引用したか

「感想を添えてこの投稿を引用」というタスクです。/check-quotedは引用と通常のリツイートを区別し、状態を文字列で返します。 エンドポイント: POST /v3/check-quoted

Python

レスポンス

statusは3種類です。"quoted"は引用済み、"retweet"は本文を加えずリツイート済み、"not_found"はどちらも未検出です。引用がある場合は日時と本文も含まれ、最低文字数、必須ハッシュタグ、不適切な表現の除外などの品質確認に使えます。

確認4:ツイートにコメントしたか

「この投稿にコメント」というタスクです。確認用エンドポイントの中で、POSTではなくGETを使うのはこれだけです。 エンドポイント: GET /v3/check-comment

パラメーター(クエリ文字列)

Python

commentedtrueなら、コメント自体の完全なtweetオブジェクト(本文、エンゲージメント指標、日時)が含まれます。返信の有無だけでなく、最低文字数、必須ハッシュタグ、絵文字だけの返信の除外などの条件を確認できます。

確認5:コミュニティのメンバーか

参加条件にする前に、現在のコミュニティデータの利用可否をサポートへ確認してください。リストとコミュニティの提供状況についての注記も参照してください。 「Xコミュニティに参加して応募」という、コミュニティ参加を前提とするキャンペーンに使えます。 エンドポイント: POST /v3/check-community-member

Python

コミュニティIDは、URL(x.com/i/communities/<id>)に含まれる数値の文字列です。

キャンペーン確認パイプラインの構築

実際のキャンペーンでは参加者が複数のタスクを行います。次の例は1参加者について5つの確認を実行し、構造化した結果を返して、コメントと引用の品質条件も適用します。
5つの確認の最初のページだけなら5リクエストです。リツイートの追加ページと再試行で増えるため、5回は固定費ではなく基本の目安です。ページ数の上限による例外は「確認未完了」であり、タスク未達成の証拠ではありません。

参加者をまとめて確認する

数千人の参加者にはバッチ処理を使います。次の例はレート制限を守り、参加者ごとにCSVへ書き込みます。障害で進捗を失わず、再開できます。
ループは参加者間で待機し、429を最大3回再試行しますが、1参加者の確認中にもリツイートの追加ページで呼び出しが増える場合があります。本番のワーカープールでは共通のレートリミッターを使ってください。実際の処理速度はページの深さと応答時間に依存します。未完了や失敗した参加者は、不合格と記録せず再試行できる状態に保ちます。

アカウントの所有確認

参加前に、申告されたXアカウントを本人が所有しているか確認する場合は、次の方法がよく使われます。
  1. 一意のコード(例:VERIFY-a8f3b2)を生成して参加者に表示します。
  2. そのコードを含むツイートを投稿してもらいます。
  3. /user-tweetsで最近の投稿を取得し、コードの有無を確認します。
各確認コードをログイン中の参加者と対象Xアカウントに関連付け、短い有効期限を設け、1回だけ使えるようにしてください。一致した投稿の投稿者と作成日時を照合します。例では投稿者と本文を確認しますが、コードの保存、期限、使い捨て処理はアプリケーション側で実装する必要があります。確認後、参加者はツイートを削除できます。

不正対策の検討事項

以下は、変更可能な参加条件や確認基準として使ってください。アカウントの経過日数や各種件数だけで、正当なアカウントかどうかは証明できません。
  • 最低アカウント年齢。 /infoでプロフィールを取得し、created_atを確認します。多くのボットファームが新規アカウントを使うため、過去30日以内に作成されたアカウントを除外するという基準があります。
  • 最低活動量。 tweets_countfollowers_countを確認します。件数が少ないことは追加確認の理由にはなりますが、ボットの証拠ではありません。
  • コメントの品質。 /check-commentが返す全文で、最低文字数、必須キーワード・ハッシュタグを確認し、1文字や絵文字だけの返信を除外します。
  • 引用の品質。 /check-quotedの引用本文に、コメントと同じ品質条件を適用します。
  • 完了速度。 速すぎる完了は調査のきっかけですが、自動化の証拠ではありません。時刻を記録し、不自然に速い場合はフラグを付けます。
5つの確認の前に実行してください。is_legitimate_accountFalseなら、最終的に除外する参加者について5回の確認を省けます。

影響力に応じて参加者を評価する

参加者のリーチは同じではありません。フォロワー50,000人からのリツイートは、50人のアカウントよりキャンペーンへの価値が高いと考えられます。/infoでプロフィールを取得し、フォロワー数で報酬に重みを付けられます。
暗号資産を扱うキャンペーンでは、フォロワー数の倍率をSorsa Scoreに置き換えられます。これは暗号資産分野のKOL、プロジェクト、VCからの認知を測定します。

「いいね」について

X(Twitter)は2024年に「いいね」を非公開にしました。現在、特定のツイートに誰が「いいね」したかは、Sorsa、公式X API、他の外部ツールを含む公開APIから取得できません。以前「このツイートにいいね」という条件を使っていた場合は、確認可能なリツイートかコメントに置き換えてください。

次のステップ