X (Twitter) Data Skill

UnifAPI を通じた公開 X (Twitter) データへの決定論的な読み取りパス。これは Data Skill です: 単独でマーケティングジョブを実行することはありません — 具体的な x/... オペレーション、レスポンス形状、落とし穴を明示し、どんな X 中心の ワークフロー（KOL の料金算定、クリエイター審査、購買シグナル、競合とリスニングの 作業）も、毎回サーフェスを再発見するのではなく、1 つの既知のレシピから読めるように します。

読み取り専用 — 手ではなく目。公開された X データをリサーチし、引用された レコードを返します。投稿、返信、フォロー、DM は決してせず、UnifAPI が X の 認証情報を保持することも決してありません。

ライブの根拠には unifapi スキルを使う

共有の unifapi スキル（OAuth MCP）を通じて一度接続し、続いて以下の オペレーションを呼び出します。X 統合は RapidAPI SocialLab を裏側に持ちますが、 公開契約は X スタイルの /x/... パス を使います — レガシーの /twitter/... パスは 使わないでください。レポートがレコードコストを記載できるよう、 billing メタデータは保持してください。

レスポンス契約

単一エンティティのエンドポイントはオブジェクトを data で返します。

{
  "request_id": "unif_...",
  "data": {},
  "billing": { "records_charged": 1, "balance_remaining": 99 }
}

リストのエンドポイントは配列を data に加えて pagination を返します。

{
  "request_id": "unif_...",
  "data": [],
  "pagination": { "has_more": false, "next_cursor": null },
  "billing": { "records_charged": 1 }
}

pagination.has_more が true のとき、pagination.next_cursor を次の リクエストの pagination_token として渡します（next_token も受け付けられます）。 コストを報告するときは常に billing を保持してください。

中核オペレーション

ここに載っていないフィールドが必要ですか？ 呼び出す前に unifapi スキルの get_operation を使って正確なスキーマを読みます — ただしオペレーションはこの テーブルから選び、当てずっぽうで発見しないでください。

ワークフロー

決定論的なレシピ。ジョブに合うものを選びます。それぞれが何を呼び出すかを正確に 明示します。

1. ハンドルをプロフィールに解決する。 先頭の @ を取り除き、続いて x/users/by/username/{username} を呼び出します。data.id（以下のユーザーごとの 呼び出しすべてに必要）と data.public_metrics.followers_count を読みます。
2. 最近のエンゲージメントを読む。 ステップ 1 の id を使い、 x/users/{id}/tweets?max_results=10&exclude=replies を呼び出します。各ツイートの public_metrics（like_count、retweet_count、reply_count、 quote_count、impression_count）からエンゲージメントを計算します。has_more の ときは x/users/{id}/tweets?pagination_token={next_cursor} でページングします。
3. 誰が投稿を増幅したかを追跡する。 ステップ 2 のツイート id を使い、 x/tweets/{id}/retweeted_by、x/tweets/{id}/quote_tweets、または x/tweets/{id}/liking_users を呼び出して、誰がリポスト、引用、いいねをしたかを見ます — 購買シグナル、リスニング、競合の作業の裏にある増幅と意図のシグナルです。 ユーザーがエンゲージするものには x/users/{id}/liked_tweets を使います。 next_cursor でページングします。
4. オーディエンスの質を測る。 x/users/{id}/verified_followers を呼び出します。 これは認証済みフォロワーを、すぐ使える数値ではなくページ分割されたリストとして 返します。そのサイズをステップ 1 の data.public_metrics.followers_count と 比べて測ります — その認証済み比率が、下流の料金算定/審査スキルの確度と警告に 流れ込む、本物 vs 水増しのシグナルです。より完全なカウントには next_cursor で ページングします。
5. トピックから発見する（まだハンドルなし）。 最近の一致する投稿には x/tweets/search/recent?query=... を、ユーザー/トピックの候補には x/autocomplete?query=... を呼び出し、続いて浮かび上がったハンドルをステップ 1 で 解決します。
6. ネットワークをマッピングする。 オーディエンスの重なりやリーチの作業には x/users/{id}/followers または x/users/{id}/following を呼び出します。 next_cursor でページングします。
7. 地域のトレンドを読む。 ある場所（WOEID）でトレンドになっているものには x/trends/by/woeid/{woeid} を呼び出します。例えばリスニングやコンテンツの タイミングのために。
8. すべてを引用する。 すべての数値は、それが由来した投稿またはプロフィールに 結びつきます。billing.records_charged を報告します（請求メタデータがないときは 推定します）。

形状メモ

• XUser — 指標は public_metrics の下にネスト: followers_count、 following_count、tweet_count、listed_count。プロフィールのフラグは トップレベル: protected、verified、verified_type。レガシーのフラットな フィールドではなく public_metrics を読みます。
• XTweet — 指標は public_metrics の下にネスト: like_count、 retweet_count、reply_count、quote_count、bookmark_count、 impression_count。利用可能なときは author と media を含むことがあります。

落とし穴

• /x/... パスを使い、/twitter/...（レガシー）は決して使いません。古い /twitter/users/{screen_name} → x/users/by/username/{username}; 古い /twitter/search → x/tweets/search/recent（ユーザー/トピックの発見には x/autocomplete を使う）。
• 保護された、古すぎる、または薄すぎるタイムラインは確度を下げます — それを 可視化し、覆い隠さないでください。
• いかなる x/users/{id}/... 呼び出しの 前に、ハンドルを data.id に 解決します。
• 残高が少ないと、リストのページが静かに切り詰められることがあります: billing.truncated_due_to_balance を確認します — true のときページは部分的なので、 そこから計算したカウントや比率を信頼する前にチャージしてください。

出力

呼び出し元のワークフローが必要とするレコードを、それぞれその投稿/プロフィールに 引用して返し、加えて 1 行のコストメモ（records_charged）を添えます。このスキルを 直接使う場合は、ハンドルごとのコンパクトなプロフィール + エンゲージメントの要約が 既定です。

**@handle** — followers {N}, verified {yes/no}. Recent 10 posts: avg engagement {x}% ({likes}/{reposts}/{replies}). Evidence: {post URLs}. Records: ~{N}.

関連スキル

• kol-pricing、creator-shortlist、audience-fit-check（Influencer Marketing） — この読み取りパスの上で X クリエイターの料金算定と審査を行う。
• buying-signal-monitor（Social Selling）、competitor-profiling（Competitive Intelligence）、social-listening-brief（Social Listening） — X 中心の意図、競合、リスニングの作業。
• unifapi — 共有データスキル: MCP を接続し、get_operation で正確なスキーマを調べる。