話題の Serenity 投稿への公開リプライを分析する方法
マーケット関連の投稿が広がると、重要な情報は元投稿だけに残るわけではありません。リプライには、出典を求める質問、主張への反論、資料や発表の追加、関連企業や cashtag への話題の広がりが出てきます。
Serenity の公開投稿を調べるなら、会話が動いているうちにリプライを保存しておくと便利です。新しい実装では、TwexAPI 推奨の POST /twitter/tweets/{tweet_id}/replies/page を使います。カーソルページングなら大きなスレッドでのタイムアウトを避けやすく、next_cursor で続きのページを取得できます。
この手順の目的は、Serenity の見解が正しいかどうかを判断することではありません。リプライ欄を、繰り返し質問、確認すべき異論、証拠付きの補足、高く拡散した返信に整理することです。
まず tweet_id を決める
分析対象となる Serenity の公開投稿を 1 つ選びます。リプライ分析はアカウントのタイムライン全体から直接始めるのではなく、各スレッドのルート投稿から始めます。
投稿 URL がある場合は、URL 内の数字の tweet_id を使います。まだ対象投稿を決めていない場合は、先に Serenity のツイートとリプライを取得 し、返信数が多い投稿、調査主張が明確な投稿、重要な cashtag を含む投稿を選びます。
選ぶときは、次のようなシグナルを見ます。
| シグナル | 役立つ理由 |
|---|---|
reply_count が多い | 分析できる議論サンプルが十分にある |
| 元投稿の主張が明確 | 支持、異論、質問を分けやすい |
cashtags を含む | 議論が銘柄コードへ広がったかを後で見られる |
| 外部リンクや画像がある | 出典確認や追加証拠がリプライに出やすい |
API エンドポイント
新しい実装では、ページネーション対応のリプライ取得 API を使います。パスに tweet_id を入れ、body に並び替えと任意の next_cursor を渡します。
POST https://api.twexapi.io/twitter/tweets/{tweet_id}/replies/page
Authorization: Bearer <your_token>
Content-Type: application/json最初のリクエストでは next_cursor を省略します。最初のページには root_tweet が含まれる場合があり、各ページのリプライは data 配列に入ります。has_next_page が true の間は、返された next_cursor を次のリクエストへ渡します。
curl --request POST \
--url 'https://api.twexapi.io/twitter/tweets/<tweet_id>/replies/page' \
--header 'Authorization: Bearer <your_token>' \
--header 'Content-Type: application/json' \
--data '{"sort_by":"Recency"}'並び替えを選ぶ
エクスポート前に、どの切り口のリプライを見るかを決めます。並び替えが変わるとサンプルも変わるため、同じ比較の中で混ぜない方が安全です。
| 並び替え | 使う場面 |
|---|---|
Recency | 投稿が広がっている最中の新しい反応を追う |
Relevance | 手動ラベル付け前に、比較的バランスのよい返信を見る |
Likes | 他ユーザーが強く反応した高可視性の返信を見る |
各分析では、tweet_id、sort_by、取得時刻、ページ数を保存してください。これがないと、同じスレッドの 2 回のエクスポートが違って見える理由を後で説明できません。
Python の例
次の Python 例では、ルート投稿とリプライの生データを先に保存し、その後ローカルで分類、センチメント、テーマ整理を行います。生データを残しておくと、分類ルールを変えた場合でも分析を再現できます。
1import json
2import os
3from pathlib import Path
4
5import requests
6
7TOKEN = os.environ["TWEXAPI_BEARER_TOKEN"]
8TWEET_ID = "<serenity_tweet_id>"
9SORT_BY = "Relevance"
10URL = f"https://api.twexapi.io/twitter/tweets/{TWEET_ID}/replies/page"
11HEADERS = {"Authorization": f"Bearer {TOKEN}"}
12ROOT_FILE = Path(f"{TWEET_ID}-root.json")
13REPLIES_FILE = Path(f"{TWEET_ID}-replies.jsonl")
14
15cursor = None
16page_count = 0
17reply_count = 0
18
19while True:
20 body = {"sort_by": SORT_BY}
21 if cursor:
22 body["next_cursor"] = cursor
23
24 response = requests.post(URL, headers=HEADERS, json=body, timeout=30)
25 response.raise_for_status()
26 payload = response.json()
27
28 root_tweet = payload.get("root_tweet")
29 if root_tweet and not ROOT_FILE.exists():
30 ROOT_FILE.write_text(
31 json.dumps(root_tweet, ensure_ascii=False, indent=2),
32 encoding="utf-8",
33 )
34
35 replies = payload.get("data") or []
36 with REPLIES_FILE.open("a", encoding="utf-8") as output:
37 for reply in replies:
38 output.write(json.dumps(reply, ensure_ascii=False) + "\n")
39
40 page_count += 1
41 reply_count += len(replies)
42
43 cursor = payload.get("next_cursor")
44 if not payload.get("has_next_page") or not cursor:
45 break
46
47print(f"{page_count} ページ、{reply_count} 件のリプライを保存しました")データベースに保存する場合は、リプライ自身の tweet_id で重複排除し、ルート投稿の tweet_id を外部キーとして残します。これにより、別の並び替えで再エクスポートしても互いに上書きされません。
測定する内容
リプライ欄は、単なるポジティブ/ネガティブではなく、再確認できる問いに分けます。マーケット調査の投稿では、感情そのものよりも、異論や確認質問の方が価値を持つことがあります。
| 測定対象 | 見方 |
|---|---|
| 繰り返し質問 | 出典、日付、手法、定義を尋ねるリプライをまとめる |
| 異論と修正 | 元投稿に反論する返信、反対証拠、誤りの指摘を別に保存する |
| 高エンゲージメント返信 | favorite_count、reply_count、retweet_count を比較する |
| Cashtag の広がり | cashtags を見て、サプライヤー、競合、隣接銘柄へ広がったか確認する |
| 再現性 | ルート tweet_id、取得時刻、sort_by、ページ数を保存する |
リプライ量が多い場合は、まず Likes で高可視性の返信を見つけ、その後 Recency で新しい反応を追います。この 2 種類の結果は別々に保存し、「最新の議論」と「最も見られた議論」を混ぜないようにします。
関連リソース
- Replies by Tweet ID API リファレンス
- Serenity ツイートをページごとにエクスポート
- Serenity のツイートとリプライを取得
- Serenity 関連 Cashtag を追跡
免責事項
この手順は、公開リプライの保存と整理だけを扱います。リプライ分析は公開議論を要約できますが、金融上の主張を検証するものではなく、投資助言でもありません。