Contents
Togetterと年別まとめページの構造と読み方
TogetterはX(旧Twitter)のツイートをユーザーが編纂して公開するプラットフォームで、まとめごとに引用ツイートの集合や編集コメントが掲載されます。年別ページは月別/年間のランキング表示がされることがあり、用途に応じて使い分けると効率的です。
基本構造
まとめページで典型的に確認する表示要素を整理します。
- まとめタイトル:まとめの見出し。
- 抜粋/本文:引用ツイートと編集コメントの集合。
- 作成者ハンドル:まとめを公開したユーザー名。
- 掲載日:まとめの公開日。要注意:更新が分かりにくい場合はまとめ内のツイート日で期間を推定する。
- 引用ツイート:各引用に元ツイートへのリンクが付く場合が多い。
- 指標(要確認):ページ上にいいね等が表示されることがあるが、表示の有無はUIによる。
ランキングの種類と用途
月別・年間の違いを意識して活用してください。
- 月別ランキング:短期的な「瞬間風速」や速報の検知に向く。
- 年間ランキング:持続性や編集の選別が反映されやすく、中長期の話題性を測るのに向く。
注目度の読み方(実務ポイント)
順位だけで判断せず、数値と変化率の両面で評価します。
- 上位表示は話題化の指標だが編集者や母集団バイアスを考慮する。
- 絶対値(例:いいね)と成長率(週次増加)を組み合わせる。
- まとめ内の最古/最新ツイート日、元ツイートを確認して一次ソースで事実関係を検証する。
- インプレッションが提供されない場合はエンゲージメント(合計リアクション)を代替とする。
UIでの探し方(実務導線)
初心者が迷わず目的の年まとめやランキングページにたどり着けるよう、主な画面遷移と確認ポイントをテキスト手順で示します。UIやボタン名は変更される可能性があるため、見つからない場合はページ内検索やサイトメニューの確認を行ってください。
基本的な画面遷移(テキスト版)
最短ルートの例をテキストで示します。
- ブラウザでTogetterのトップページを開き、ヘッダーやフッターの「年別」「まとめ一覧」等を探す。
- 年別一覧があれば該当年(例: 2026)を選択するか、ブラウザで直接 https://togetter.com/2026 を開く(要確認: ページ構成は変わる可能性あり)。
- 月別/年間タブを切替え、リストから対象のまとめを開く。
- 個別まとめでタイトル、掲載日、引用ツイート群、元ツイートURLなどを確認する。
個別まとめで必ず確認すべき項目
個別ページを開いたら最低限これらを記録してください。
- まとめタイトル(summary_title)
- まとめURL(summary_url)
- 掲載日(summary_date)またはまとめ内の最古/最新ツイート日
- 各引用の元ツイートURL/ID(tweet_url / tweet_id)
- 表示される指標(いいね・リツイート等)と取得可否
- まとめ作成者のハンドル(author_handle)
検索と外部検索併用のテクニック
サイト内検索が不十分な場合は外部検索を使います。
- Google: site:togetter.com 2026 まとめ のようにキーワードを組み合わせる。
- ブラウザ内検索(Ctrl/Cmd+F)でページ内の年やイベント名を検索する。
- 一覧が見つからない場合は作者名やイベント名を組み合わせて検索を広げる。
データ取得:ダウンロード可否と代替ワークフロー
UIでのエクスポートが最優先です。エクスポートが無い場合は手動抽出→公式API→運営問い合わせの流れで進め、違法なスクレイピングは一切行わないでください(コンプライアンス節参照)。
アカウント登録フロー(要約)
登録はサイト指示に従って進めてください。以下は一般的な手順です。
- トップ右上の「新規登録」または「ログイン」を選ぶ。
- メールアドレス登録または外部アカウント(X)連携を選択する。
- メール認証やOAuthの指示に従い、プロフィールは任意で設定する。
- 継続的な収集やブックマークにはログインを推奨するが、利用制限や規約遵守の確認が必要です(詳細はコンプライアンス節)。
ダウンロード可否と代替手順
エクスポート機能の有無に応じた推奨手順を優先順で示します。
- UIのエクスポートボタンがあれば最優先で使用する(CSVがあればCSVを取得)。
- エクスポートが無い場合は手動抽出:まとめページから必要項目をコピーしてスプレッドシートに貼る。
- ページ保存:ブラウザの「印刷→PDF保存」や「ページ保存」でアーカイブを残す。
- 元ツイートURLリストを作成し、Xの公式APIでツイートメタ(例:public_metrics)を取得する(APIの利用規約とレート制限を確認)。
- 大量データが必要な場合はTogetter運営にデータ提供を相談する。
収集テンプレート(推奨カラム)
収集時に最低限保存しておくべきカラム名と説明の例です。列名はDBでは英語スネークケースを使い、UI表示では日本語名を併記してください(用語集参照)。
| 日本語名(列名) | 型 | 説明 |
|---|---|---|
| まとめID(summary_id) | STRING | Togetter上のまとめ固有ID |
| まとめタイトル(summary_title) | STRING | まとめのタイトル |
| まとめURL(summary_url) | STRING | まとめページのURL |
| 掲載日(summary_date) | DATE / TIMESTAMP | まとめの掲載日または更新日 |
| ツイートID(tweet_id) | STRING | 元ツイートのID |
| ツイートURL(tweet_url) | STRING | 元ツイートのURL |
| ツイート投稿日(tweet_date) | TIMESTAMP | 元ツイートの投稿日 |
| 投稿者ハンドル(author_handle) | STRING | ツイート投稿者のハンドル |
| likes(likes) | INT64 | いいね数 |
| retweets(retweets) | INT64 | リツイート数 |
| replies(replies) | INT64 | 返信数 |
| quotes(quotes) | INT64 | 引用リツイート数 |
| content(content) | STRING | ツイート本文 |
データスキーマとサンプル(再現性)
分析で再現可能にするための典型スキーマとサンプルCSV/SQLを示します。以下はBigQueryやCSVで扱いやすい型を想定しています。
サンプルスキーマ(BigQuery向け)
次のCREATE TABLEは例です。運用環境に合わせて型・列名を調整してください。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
CREATE TABLE `project.dataset.togetter_summaries` ( summary_id STRING, summary_title STRING, summary_url STRING, summary_date DATE, tweet_id STRING, tweet_url STRING, tweet_date TIMESTAMP, author_handle STRING, likes INT64, retweets INT64, replies INT64, quotes INT64, content STRING ); |
CSVサンプル行(ヘッダ行+1行)
| summary_id | summary_title | summary_url | summary_date | tweet_id | tweet_url | tweet_date | author_handle | likes | retweets | replies | quotes | content |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2026-0001 | イベントまとめA | https://togetter.com/xxxx | 2026-01-15 | 1480000000000000000 | https://x.com/…/status/148… | 2026-01-10 12:34:00 | user_a | 120 | 30 | 10 | 2 | 本文サンプル |
正規化・ゼロ除算の扱い(SQL/スプレッドシート)
最大値=最小値や分母ゼロを避ける実装例を示します。
- BigQuery(ウィンドウ関数で正規化):
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 |
WITH scores AS ( SELECT summary_id, SUM(likes + retweets + replies + quotes) AS engagement FROM `project.dataset.togetter_summaries` GROUP BY summary_id ), bounds AS ( SELECT *, MIN(engagement) OVER() AS min_e, MAX(engagement) OVER() AS max_e FROM scores ) SELECT summary_id, engagement, CASE WHEN max_e = min_e THEN 0 ELSE 100 * (engagement - min_e) / NULLIF(max_e - min_e, 0) END AS engagement_norm FROM bounds; |
- Googleスプレッドシート(例):
|
1 2 |
=IF(MAX(G:G)=MIN(G:G), 0, 100*(G2 - MIN(G:G)) / (MAX(G:G) - MIN(G:G))) |
このようにNULLIF/IFで分母ゼロを明示的に処理してください。
指標・ハッシュタグ抽出・分析テンプレ(スプレッドシート・SQL)
必須指標の定義、スプレッドシート式、正規表現によるキーワード抽出例を示します。インプレッションが取得できない場合はエンゲージメントを代替指標として扱います。
指標定義とスプレッドシート式
代表的な指標と簡易式の例です。
- Likes, Retweets, Quotes, Replies:元データの数値をそのまま使用。
- Engagement(エンゲージメント):
|
1 2 |
=SUM(C2:F2) // C=likes, D=retweets, E=replies, F=quotes |
- 週次成長率(分母が0の対処):
|
1 2 |
=IF(B2=0, IF(A2>0, 1, 0), (A2 - B2) / B2) |
ここでB2は先週、A2は今週の値です。分母0の扱いは指標の意味に応じて調整してください(例えば無限大を特定値で扱うなど)。
ハッシュタグ抽出(Unicode対応)
従来の正規表現 #[A-Za-z0-9_]+ は日本語や絵文字を含むハッシュタグに対応しません。Unicodeプロパティを用いるか、言語別に処理することを推奨します。以下は実装例です。
- BigQuery(REGEXP_EXTRACT_ALL を利用する例。環境によりUnicodeプロパティのサポートを要確認):
|
1 2 3 4 5 6 7 8 9 |
SELECT tag, COUNT(*) AS freq FROM ( SELECT id, tag FROM `project.dataset.togetter_summaries`, UNNEST(REGEXP_EXTRACT_ALL(content, r'#([\p{L}\p{N}_\p{M}\p{So}\p{Sk}]+)')) AS tag ) GROUP BY tag ORDER BY freq DESC; |
- Python(第三者ライブラリ regex を使う例):
|
1 2 3 4 5 6 |
import regex as re def extract_hashtags(text): # \p{L}: 文字、\p{N}: 数字、\p{M}: 結合文字、\p{So},\p{Sk}: 記号系(絵文字等を含む場合もある) return re.findall(r'#([\p{L}\p{N}_\p{M}\p{So}\p{Sk}]+)', text, flags=re.UNICODE) |
- JavaScript(環境がUnicodeプロパティエスケープをサポートする場合):
|
1 2 3 |
const re = /#([\p{L}\p{N}_\p{M}\p{So}\p{Sk}]+)/gu; const tags = [...text.matchAll(re)].map(m => '#' + m[1]); |
注記:環境依存(BigQuery/Sheets/ブラウザ等)のため、正規表現が動作するか事前に検証してください。GoogleスプレッドシートのREGEXEXTRACTはUnicodeプロパティを十分にサポートしないことがあるため、Apps Script や外部処理を推奨します。
SQL集計例(月別トップ)
月別の集計例です。スキーマに合わせてフィールド名を調整してください。
|
1 2 3 4 5 6 7 8 9 |
SELECT FORMAT_DATE('%Y-%m', DATE(summary_date)) AS ym, summary_title, SUM(likes + retweets + replies + quotes) AS total_engagement, COUNT(DISTINCT tweet_id) AS tweet_count FROM `project.dataset.togetter_summaries` GROUP BY ym, summary_title ORDER BY ym, total_engagement DESC; |
ツール連携例:Googleスプレッドシート・Python(pandas)・BigQuery・BIツール
運用規模に応じた段階的な連携例と実装のポイントを示します。まずは手動→簡易スクリプト→BIの順で導入するのが現場での定石です。
軽量運用(即時対応)
短期で立ち上げるフローの例です。
- 手動でまとめの情報をGoogle Sheetsに収集。
- QUERYやピボットで集計し、Apps Scriptで週次レポートを生成・Slack通知。
- ハッシュタグ抽出や簡易集計はSheets内の関数やApps Scriptで処理する。
中規模運用(スクリプト活用:Python)
中規模での自動化に向けた処理例です。簡易的にはCSV→pandasで処理し、定期出力を行います。
|
1 2 3 4 5 6 7 8 9 |
import pandas as pd df = pd.read_csv('togetter_raw.csv', parse_dates=['tweet_date','summary_date']) df['engagement'] = df[['likes','retweets','replies','quotes']].sum(axis=1) agg = df.groupby([df['summary_date'].dt.to_period('M'), 'summary_title']).agg({ 'engagement':'sum', 'tweet_id':'nunique' }).reset_index() |
出力はCSVで保存し、必要に応じてGoogle SheetsやBigQueryへロードします。BigQueryへは pandas-gbq や CSV→GCS→BigQuery の流れが一般的です。
本格運用(BigQuery + BI)
本格運用ではデータをBigQueryに集約し、Looker Studio/Tableau等でダッシュボード化します。KPIカード、時系列、Top-Nチャートを用意し、アラートはBigQueryのスケジュールジョブや外部の監視で実装します。
運用上の注意として、XのAPIやTogetterのUIの仕様変更が頻繁に起きるため、API呼び出しやスクレイピングに依存する自動化は冗長化(リトライ/代替フロー)を組み込んでください。
運用ワークフロー・KPI設計・活用事例・FAQ
週次監視から四半期の施策反映までの実務フローとKPI例、実際の活用ケースとよくある質問をまとめます。
週次→月次→四半期の基本フローと役割
運用の役割分担と頻度を明確にしてください。
- 週次(SNS運用担当): 上位トピック(例:上位10まとめ)を収集・集計し、増加率アラートを共有する。
- 月次(データ担当): 月次ダッシュを作成し、持続性あるトピックを抽出してコンテンツ提案をする。
- 四半期(事業/商品チーム): トレンドを施策に反映し、A/Bテストやロードマップへ反映する。
KPI設計(例)
定量的に追うべき指標の例です。
- トレンド起点のセッション数(UTMで分離してGA4で計測)。
- TrendページCTR、Trend来訪者のCVR。
- コンテンツ平均滞在時間、直帰率。
- Share of Voice(SOV):特定トピックのエンゲージメント ÷ 全トピックのエンゲージメント。
UTMの付与や比較期間の定義を運用ルールとして定めておくと再現性が高まります。
活用事例(短いケーススタディ)
実務での応用例を挙げます。
- コンテンツ企画:急上昇ワードを検出→短尺動画で速報配信→24時間の流入とCVを観測。
- SEO連携:トレンド語句に恒常ページを立て、長期的な集客を狙う。
- 広告:トピック関連キーワードで一時的に入札を強化しCTR・CVRを検証。
- PR危機察知:ネガティブワードの急上昇はPRへ即時エスカレーション。
よくある質問(FAQ)
Q: CSVが見つからない場合はどうする?
A: UIのエクスポートをまず探し、無ければ元ツイートURLリストを作成してXの公式APIでメタを取得するか、運営へ提供を問い合わせる。
Q: ランキングの更新頻度は?
A: ページ運営に依存します。更新情報が明記されていない場合はまとめ内のツイート日を基に推定してください。
Q: 引用時のクレジットはどう付ける?
A: 元ツイートへのリンクと投稿者ハンドルを明記し、画像や全文転載は権利確認を行う。
コンプライアンス・プライバシー・法務
データ取得・保存・公開に関わる法務・契約上の注意点と実務ルールを一か所にまとめます。違法・規約違反なスクレイピングの禁止や個人データの扱い方はここで統一して運用してください。
利用規約とスクレイピング
利用規約・APIポリシーを常に遵守してください。
- TogetterやXの利用規約に反する自動化や非公開データの取得は禁止です。
- 公開データでも大量取得による負荷や利用制限があるため、公式APIや運営窓口を優先してください。
- 法的判断が必要な場合は社内法務または外部の専門家に相談してください。
個人データの取扱い(保存期間・マスキング)
ユーザー名やツイートは個人データに該当する可能性があるため扱いに注意します。
- 保存原則:収集目的に必要最小限のデータを保存する。保存期間は事業目的に合わせて定め、不要になったら削除する。
- マスキング/匿名化の例:投稿者ハンドルはハッシュ化(HMAC-SHA256)して保存する、または一部文字を伏せる。マッピングテーブルは別の暗号化領域に保管する。
- ログ・アクセス管理:データへのアクセスは権限管理し、アクセスログを残す。
- 法的確認:個人情報保護法やプラットフォームの規約に基づく保存方針は必ず社内法務で最終確認する。
引用・転載と著作権
引用や転載はルールに従って行います。
- 元ツイートへのリンクと投稿者名を必ず明記する。
- 画像や全文転載は権利者の許諾が必要な場合がある。必要に応じて権利保有者へ確認する。
- 商用利用や二次利用は規約で制限される可能性があるため事前に確認する。
推奨読み物(参考リンク)
公式ドキュメントや参考記事を挙げます。外部リンクは随時変更されるため、利用時には各サイトで最新情報を確認してください。
- Togetter(公式サイト): https://togetter.com/
- Togetter 年別ページ(例): https://togetter.com/2026 (UI変更の可能性があるため要確認)
- X(旧Twitter)開発者向けドキュメント(API仕様): https://developer.twitter.com/ もしくはXの開発者ページ(名称変更のため要確認)
- BigQuery 正規表現/REGEXP_EXTRACT 全般ドキュメント(Google Cloud)
- Python regex(第三者モジュール): https://pypi.org/project/regex/
- 参考記事(第三者): https://app-tatsujin.com/togetter-2026-trend-ranking-guide/ — 非公式情報のため参照時は出典元を確認してください。
用語集・表記ルール
表記を統一しておくと運用・ドキュメントがぶれません。ここでは日本語表記とDB列名の対応例を示します。
| 日本語表記 | 列名(snake_case) | 説明 |
|---|---|---|
| まとめID | summary_id | Togetter上のまとめ固有ID |
| まとめタイトル | summary_title | まとめのタイトル |
| まとめURL | summary_url | まとめページのURL |
| 掲載日 | summary_date | まとめの掲載日 |
| ツイートID | tweet_id | 元ツイートのID |
| ツイートURL | tweet_url | 元ツイートのURL |
| ツイート投稿日 | tweet_date | 元ツイートの日時 |
| 投稿者ハンドル | author_handle | 投稿者のハンドル名 |
| いいね | likes | いいね数 |
| リツイート | retweets | リツイート数 |
| 返信 | replies | 返信数 |
| 引用RT | quotes | 引用リツイート数 |
| 本文 | content | ツイート本文 |
| エンゲージメント | engagement | likes+retweets+replies+quotes の合計 |
表記ルール例:UI向けは日本語表記、内部DBは英語スネークケース。ドキュメントやCSVヘッダでは「まとめタイトル(summary_title)」のように併記する運用が読みやすくおすすめです。
まとめ(実務アクションプラン)
最後に優先順位付きの短い実行プランを示します。まずは小さく始めて一つずつ自動化してください。
- 優先度1:無料アカウントを作成して、週次で上位10まとめを手動収集しCSV/Google Sheetsに保存する。
- 優先度2:元ツイートURLリストを作り、Xの公式APIでpublic_metrics等を取得できるか検証する(利用規約・レート制限を確認)。
- 優先度3:ハッシュタグ抽出ロジックをUnicode対応に更新し、多言語や絵文字を含むケースを検証する。
- 優先度4:保存ポリシーと匿名化ルールを定め、社内法務に確認した上で運用に組み込む。
- 優先度5:自動化スケールは段階的に移行する(Python→BigQuery→BI)し、API障害やUI変更に備えた代替ルートを用意する。
以上の手順を基にまずは1週間の試運用を行い、得られた知見を反映して運用ルールを整備してください。