300件の生データが入ったスプレッドシートを開けば、問題はすぐに見えてきます。コピーして、貼り付けて、読む。目をこらして、推測して、また繰り返す——それでも、追っている新製品発表を人々が喜んでいたのか、それとも不満だったのか、最後まで分からないことも少なくありません。
この“うまくいかない状態”を解決するのが感情分析です。とはいえ、ここでひとつ問題があります。多くの解説記事は2022年あたりで止まったまま。今では使えない無料APIを前提にしていたり、皮肉や絵文字に弱いモデルをすすめていたり、結果の意味を大きく左右する前処理を飛ばしていたりします。私はSaaSや自動化の領域で長く仕事をしてきました(Thunderbit の開発も含めて)。その中で、感情分析の世界がかなり変わってきたのを見てきました。今の現実に合った、正直で最新のやり方は、Pythonの手法とノーコードの両方を押さえつつ、2026年の状況に即したデータ収集方法とモデル選定まできちんと理解することです。
Twitter 感情分析とは?
Twitter 感情分析とは、X上の投稿をテキスト、絵文字、文脈にもとづいて、ポジティブ・ネガティブ・ニュートラルに自動分類するプロセスです。要するに、機械にツイートを読ませて「この人は嬉しいのか、不満なのか、それともその中間なのか?」を答えさせるようなものです。
ただし、感情分析は一般的なソーシャルリスニングとは違います。ソーシャルリスニングは、人々が何について話しているか——話題、トレンド、量——を追うものです。一方の感情分析は、その上に乗る“評価”の層であり、話している内容に対して人々がどう感じているかを示します。この考え方自体は、何十年も前からある計算言語学や意見マイニングの研究にルーツがありますが、ビジネス用途として広く使われるようになったのはここ数年のことです。
代表的な分類レベルは次のとおりです。
- 二値分類: ポジティブかネガティブか(最もシンプルだが、ニュアンスは失われる)
- 三値分類: ポジティブ、ニュートラル、ネガティブ(最も一般的な基本形)
- 多段階分類: とてもポジティブ → とてもネガティブ(研究や細かなブランド追跡に有効)
さらに、感情検出(怒り、悲しみ、喜びなど)、立場検出(賛成か反対か)、側面別感情分析(たとえば 価格 と 品質 に対する評価の違い)、皮肉・アイロニー検出といった関連タスクもあります。TweetEval のベンチマーク では、これらは別タスクとして扱われていますが、それには理由があります。ひとつの感情スコアでは、すべてのビジネス上の疑問に答えられないからです。たとえば新製品発表を追うなら、「カメラは好きだけどバッテリーは最悪」といった側面別感情分析が必要でしょう。危機対応を監視するなら、単なる極性ではなく、感情の種類と投稿量が重要です。
なぜ Twitter 感情分析がビジネスに重要なのか
Xはリアルタイムの会話を中心に設計されているので、製品発表、ライブイベント、速報ニュースへの反応が一気に広がります。ビジネスにとって、そのスピードこそが価値です。感情分析は、構造化されていない大量のテキストを、チームが確認して動ける構造化データに変えてくれます。
代表的なユースケースは次のように整理できます。
| ユースケース | 担当チーム | ビジネス成果 |
|---|---|---|
| ブランド評判の監視 | PR、マーケティング | ネガティブな急増を拡散前に検知 |
| 新製品発表への反応確認 | 製品、マーケティング | うまくいっている点、課題をリアルタイムで把握 |
| 競合比較 | 戦略、マーケティング | 同じ期間でブランド認識を比較 |
| 危機検知 | PR、オペレーション | ネガティブ投稿が急増したら人による確認を発動 |
| キャンペーン効果測定 | マーケティング | クリエイティブ、チャネル、時系列ごとの感情変化を測定 |
| 市場・株式のセンチメント | 金融、リサーチ | 決算、イベント、政策をめぐる世間の空気を追跡 |
| 政治・政策リサーチ | 研究、行政 | 世論を大規模に把握 |
具体例を挙げると、Xの2026年スーパーボウル総括では、ひとつのイベントだけで4百万の投稿者から1600万件の投稿、50億インプレッション、6億500万回の動画視聴があったと報告されています。その会話の半分はリアルタイムで発生していました。これほどの規模になると、手作業で読むのは不可能で、自動感情スコアリングが必須になります。
重要なのは量だけではありません。X独自の BrandRanx の手法 では、投稿量、エンゲージメント、感情を組み合わせています。つまり、感情は単独で見るより、ほかの指標と組み合わせたときに最も力を発揮するということです。
結論として、もしあなたのチームが製品、ブランド、キャンペーン、危機対応などで世間の評価をもとに判断しているなら、Xデータを使った感情分析は、最速のフィードバックループのひとつです。
2026年の X API の現実: ツイートデータをどう取るか
ここで多くのチュートリアルは破綻します。もしTweepyベースの解説をそのまま試して、コードを貼り付けたら課金壁やよく分からないエラーにぶつかった——そんな経験があるなら、あなただけではありません。昔のFree / Basic / Pro の区分はもうありません。現在のX APIはプリペイドクレジット付きの従量課金で、エンドポイントごとの料金と、リアルタイムの利用追跡が必要です。
現在のデータ収集方法を率直に比べると、次のようになります。
| 方法 | コスト(2026) | 取得量 | スキルレベル | 補足 |
|---|---|---|---|---|
| X API v2(従量課金) | $0.005/Post read | 月200万件のPost読み取りまで(セルフサーブ) | 中級(Python) | 公式、再現可能、コンプライアンスに適合 |
| Full-Archive Search | 戻りPost 1件あたり $0.005、全期間アーカイブ集計リクエスト 1回あたり $0.010 | 2006年3月まで遡れる | 中級〜上級 | 従量課金プランとEnterpriseで利用可 |
| Filtered Stream | 配信時にPost読み取り課金 | リアルタイム、継続取得 | 中級〜上級 | ライブ収集に最適 |
| 事前作成データセット(Kaggle、Sentiment140) | $0 | 静的、過去データのみ | 初級 | 学習には最適、リアルタイム分析には不向き |
| snscrape、Twint、Twikit など | $0 | 不安定 / しばしば動かない | 上級 | snscrape は 2023年以降、X検索で動作していない。Twint はアーカイブ済み。Twikit は非公式手法を使用 |
| 自分のXアーカイブ | $0 | 自分の投稿のみ | 初級 | 個人分析に有用 |
知っておくべきポイントは以下です。
- 昔の Free / Basic / Pro はもう存在しません。 それを今の仕様として書いている記事は、信用しないでください。
- snscrape は X では使えません。 メンテナーも2024年に、Twitter検索スクレイピングはもう動かないと認めています。Twint はアーカイブ済みです。Twikit は非公式のスクレイピングとCookieを使います。動くことと許可があることは別です。
- X の利用規約では、事前の書面同意なしのブラウザスクレイピングを禁止しています。 つまり、Selenium、Playwright、ブラウザ拡張機能は、X APIの代替としてはコンプライアンス上NGです。
X API v2 で実際に何ができるのか
標準的なPost読み取りは1件あたり $0.005です。ユーザー読み取りは1件 $0.010。つまり、Postを1万件読むと、ほかのリソース費用を除いて約50ドルになります。セルフサーブの上限は月200万件のPost読み取りです。料金は変わることがあるので、必ずDeveloper Console を確認してください。
感情分析では id と text だけでは足りません。最低限あると便利なスキーマは、created_at、lang、author_id、conversation_id、referenced_tweets、entities、context_annotations、public_metrics です。生のレスポンスと、クエリ、エンドポイント、UTCの期間、ページネーショントークンの不変レコードも保存してください。これがないと、コーパスの再現性が担保できません。
もうひとつの注意点として、Xの2026年5月4日の検索インデックス移行によって、実際に取得できるコーパスが変わりました。キーワードREST検索ではリポストが返らなくなった一方、Filtered Stream は変わっていません。移行前後の結果を比べる場合、母集団が違う可能性があります。
事前作成データセット: 学習には良いが、実運用には不向き
Sentiment140(160万件のツイート、遠隔教師ありラベル)や各種Kaggleデータセットは、無料で学習やベンチマークに最適です。ただし Sentiment140 は2009年に収集されたものです。TweetEval の感情サブセットも2013〜2016年の SemEval データを使っています。これらでは、2026年の言葉づかい、スラング、イベントに対してモデルがちゃんと動くことは証明できません。
Thunderbit と X データについての補足
Thunderbit を作っている立場として、ここははっきりさせておきたいのですが、Thunderbit は多くの対応サイトで使える AIウェブスクレイピング/自動化ツールです。ただし、X の現行規約では、同意なしのブラウザスクレイピングは禁止されています。ですので、Thunderbit を X API の料金やアクセス制限を回避する手段として紹介するつもりはありません。それは誤解を招くからです。Xデータについては、公式API、認可済みの提供元、または自分のアーカイブを使ってください。Thunderbit が感情分析ワークフローで役立つのは、その後の工程——すでに許可を得て取得したデータの整形、ラベル付け、エクスポート——です。これについては後ほど説明します。
適切な感情モデルの選び方: VADER、TextBlob、RoBERTa

どのモデルを選ぶかは、多くのチュートリアルが言う以上に重要です。しかも、ほかの記事に足りない最大のポイントは、ツイート向けにファインチューニングされたTransformerモデルをほとんど扱っていないこと。現在の実務では、そこに強いベースラインがあります。
以下で比べます。ここでは、万能のF1スコアは表に入れていません。データセット、分割方法、ラベル定義、時期、指標によってスコアは変わるからです。その代わり、相対的な性能を説明し、確認できるベンチマークも案内します。
| モデル / ライブラリ | 手法 | 皮肉に対応できるか | スラング / 絵文字に対応できるか | ツイートでの相対精度 | セットアップの複雑さ |
|---|---|---|---|---|---|
| VADER(NLTK) | ルールベースの辞書方式 | 弱い | 絵文字は一部対応 | 最低 | かなり低い |
| TextBlob | パターンベース | 弱い | いいえ | 低め | かなり低い |
| Naive Bayes / Logistic Regression(TF-IDF) | 伝統的な機械学習 | いいえ | いいえ | 中程度 | 中程度 |
| CardiffNLP RoBERTa | Transformer(ツイートで学習済み) | より強い(完全ではない) | はい | この中で最高 | 中程度(HuggingFace pipeline) |
VADER: 速くて簡単だが、限界はある
VADER は、ソーシャルテキスト向けに作られたルールベースの辞書手法です。高速で解釈しやすく、学習データも不要で、絵文字や顔文字にも一部対応します。否定、程度表現、句読点、大文字を考慮します。すぐ使えるベースラインが欲しいときや、計算量や説明可能性を重視するときに向いています。一方で弱いのは、皮肉、スラング、文脈依存の意味、単語単体以上の理解が必要なケースです。デフォルトの compound スコア閾値(≥0.05 = positive、≤-0.05 = negative)はあくまで初期値であって、ビジネスでの絶対基準ではありません。自分の検証データで調整してください。
TextBlob: さらに簡単だが、さらに限定的
TextBlob は、教育用のミニマルなベースラインです。デフォルトの PatternAnalyzer は、ツイート特有のテキストで学習されていません。NLPの最初の実験には使えますが、本番のツイート分析には向きません。
伝統的機械学習: Naive Bayes、Logistic Regression、SVM
単語・文字ベースの TF-IDF パイプラインに、logistic regression か LinearSVC を組み合わせる方法は、今でも価値のある教師ありベースラインです。安価で解釈しやすく、Transformer を使う価値が複雑さに見合うかを見極めるのにも役立ちます。重要なルールは、語彙や IDF の漏洩を防ぐため、ベクトライザは必ず train/validation 分割のあとに fit することです。
これらのモデルは、大規模なラベル付きデータセットではルールベースを上回りますが、それでも文脈、皮肉、スラングは取りこぼします。
CardiffNLP RoBERTa: 2026年のツイート感情分析の標準
cardiffnlp/twitter-roberta-base-sentiment-latest は、今も保守されているツイート向けの3クラスモデルで、2026年の強力な標準ベースラインとして妥当です。大量のツイートで事前学習され、感情分類用にファインチューニングされているため、絵文字、スラング、くだけた表現をルールベースや従来型MLよりかなりうまく扱えます。
最小限の HuggingFace コード例はこちらです。
from transformers import pipeline
classifier = pipeline(
"text-classification",
model="cardiffnlp/twitter-roberta-base-sentiment-latest",
top_k=None,
)
scores = classifier("@user Love waiting three hours for support 😒 http")
print(scores)
注意点もあります。
- 出力はモデルのスコアであって、調整済みのビジネス確率ではありません。今のデータでキャリブレーションするか、保留閾値を設けてください。
- 文脈を扱うモデルは、一般に多くのツイートタスクでルールベースより優れていますが、皮肉、複数対象、スレッド文脈の欠落、方言、コード化された言い回しは、依然として構造的な誤り要因です。「皮肉を理解する」と言い切るのではなく、「よりうまく扱えるが完璧ではない」と表現するほうが正確です。
- 代替としては、言語やタスクに応じて BERTweet、TimeLMs、多言語Twitter向けのXLM-Rモデルなどがあります。
では、Twitter感情分析は本当に精度が出るのでしょうか?答えはイエスです。ただし、モデル、前処理、ラベル定義、評価サンプルがタスクに合っている場合に限ります。2019年のチュートリアルから持ってきたVADERのスクリプトはベースラインであって、本番品質の証明ではありません。
本物のツイート前処理パイプライン(単なる text.lower() ではない)

感情モデルに、生のURL、@メンション、HTMLエンティティをそのまま入れると、そこそこ優秀なモデルでもひどい結果になります。多くのチュートリアルは(上位表示のものも含めて)、モデルに入れる前に小文字化するだけです。それでは精度を静かに壊してしまいます。特に従来型MLでは、前処理の質がモデル選択と同じくらい重要になることがあります。
何をどう処理するべきか
| 要素 | どう処理するか | 理由 |
|---|---|---|
| URLs | http のようなプレースホルダーに置換 | URL自体は感情にとってノイズ。周辺テキストを消しすぎると文脈が壊れる |
| @mentions | ハンドルを @user に置換 | 構造を残しつつ、投稿者固有情報の漏洩を防ぐ |
| Emoji/emoticons | 現代のトークナイザでは保持。疎なモデルでは絵文字をテキスト化して検証 | 絵文字は強い感情シグナル。消すのは有益情報を捨てること |
| Hashtags | トークンは残す。必要なら分割したコピーを追加(例: #ClimateChangeIsReal → Climate Change Is Real) | ハッシュタグに意見が含まれることが多い |
| Negation | not、no、never、縮約、対比語を保持 | 一般的なストップワードで消すと感情が反転しうる |
| Casing/punctuation | VADERや対応モデルでは保持 | VADERは大文字や句読点も特徴として使う |
| RT prefix | RT マーカーを削除 | これはメタデータであり、感情ではない |
| Reposts/duplicates | 分割前に完全一致・近似重複を検出 | train/test にまたがる重複はリークの原因 |
前後比較: 前処理はツイートをどう変えるのか
具体例を見てみましょう。
| Stage | Text |
|---|---|
| Raw tweet | RT @BrandX: Wow, #CustomerServiceFail 😡😡 https://t.co/abc123 I've been waiting 3 hrs ngl this is awful |
| After URL removal | RT @BrandX: Wow, #CustomerServiceFail 😡😡 http I've been waiting 3 hrs ngl this is awful |
| After mention normalization | RT @user: Wow, #CustomerServiceFail 😡😡 http I've been waiting 3 hrs ngl this is awful |
| After RT removal | @user: Wow, #CustomerServiceFail 😡😡 http I've been waiting 3 hrs ngl this is awful |
| After hashtag segmentation | @user: Wow, #CustomerServiceFail Customer Service Fail 😡😡 http I've been waiting 3 hrs ngl this is awful |
| After emoji-to-text (for sparse models) | @user: Wow, #CustomerServiceFail Customer Service Fail angry_face angry_face http I've been waiting 3 hrs ngl this is awful |
| Final (for CardiffNLP RoBERTa) | @user Wow, #CustomerServiceFail Customer Service Fail 😡😡 http I've been waiting 3 hrs ngl this is awful |
ここで大事なのは、CardiffNLP RoBERTa のようなTransformerでは、絵文字、句読点、大文字をそのまま残すべきだという点です。モデルはそうしたテキストで学習されているからです。一方、TF-IDF モデルでは、絵文字をテキスト化し、小文字化し、レンマ化することがあります。
コピペできる Python 前処理コード
Transformer に対応した、きれいでモジュール化された前処理関数はこちらです。
import html
import re
import unicodedata
URL_RE = re.compile(r"https?://\S+|www\.\S+", re.I)
MENTION_RE = re.compile(r"(?<!\w)@[A-Za-z0-9_]+")
def normalize_social_text(text: str) -> str:
"""ツイートをTransformerベースの感情モデル向けに正規化する。"""
text = html.unescape(text)
text = unicodedata.normalize("NFC", text)
text = URL_RE.sub("http", text)
text = MENTION_RE.sub("@user", text)
text = re.sub(r"\bRT\b", "", text)
return " ".join(text.split())
従来型MLのパイプラインでは、ここに小文字化、絵文字のテキスト化(emoji や demoji ライブラリ)、ハッシュタグ分割(wordninja や ekphrasis)、スラング正規化、ストップワード除去、レンマ化(spaCy や NLTK)を追加します。重要なのは、前処理をモデルに合わせることです。たとえば BERTweet には独自の正規化ルールがあります。すべてのモデルを1本のパイプラインに無理やり通さないでください。
手順で学ぶ: Pythonでの Twitter 感情分析
ここからは、上で説明した内容をまとめた完全なワークフローです。最初から最後までこのまま進められます。
始める前に:
- 難易度: 中級(Pythonの基本知識がある前提)
- 所要時間: 全工程で約30〜60分、Transformer を使う簡易ルートなら約10分
- 必要なもの: Python 3.8以上、無料の Google Colab またはローカル環境、
pandas、transformers、scikit-learn、matplotlib、seaborn、必要に応じてwordcloud
Step 1: ツイートデータを集める
このチュートリアルでは Sentiment140 データセットを使います(無料、160万件のツイート、Kaggle で入手可能)。過去データではありますが、学習とベンチマークに向いています。
ライブデータが欲しい場合は、X API v2 の従量課金を使ってください。標準的なPost読み取りは1件 $0.005です。1万件のPostなら約50ドルです。
データセットを読み込みます。
import pandas as pd
columns = ["target", "id", "date", "flag", "user", "text"]
df = pd.read_csv(
"training.1600000.processed.noemoticon.csv",
encoding="latin-1",
names=columns,
)
# ラベル: Sentiment140 では 0 = negative, 4 = positive
df["label"] = df["target"].map({0: "negative", 4: "positive"})
print(df[["text", "label"]].head())
生のツイート本文とラベル列を持つ DataFrame が見えるはずです。
Step 2: ツイートをクリーンアップして前処理する
先ほどの前処理関数を適用します。
df["clean_text"] = df["text"].apply(normalize_social_text)
print(df[["text", "clean_text"]].head())
いくつかの行を確認して、URL が置換され、メンションが正規化され、RT プレフィックスが削除されているか見てください。
Step 3: モデルを選んで感情を分類する
Path A: TF-IDF + Logistic Regression を使う従来型ML
これは「基礎を理解する」ためのルートです。データを分割し、ベクトライザは訓練データにだけ fit し、logistic regression 分類器を学習します。
from sklearn.model_selection import train_test_split
from sklearn.feature_extraction.text import TfidfVectorizer
from sklearn.linear_model import LogisticRegression
from sklearn.metrics import classification_report
X_train, X_test, y_train, y_test = train_test_split(
df["clean_text"], df["label"], test_size=0.2, random_state=42
)
vectorizer = TfidfVectorizer(max_features=50000, ngram_range=(1, 2))
X_train_tfidf = vectorizer.fit_transform(X_train)
X_test_tfidf = vectorizer.transform(X_test)
clf = LogisticRegression(max_iter=1000)
clf.fit(X_train_tfidf, y_train)
y_pred = clf.predict(X_test_tfidf)
print(classification_report(y_test, y_pred))
precision、recall、各クラスのF1を含む分類レポートが表示されるはずです。Sentiment140では、TF-IDF + logistic regression は通常そこそこ良い性能を出します。ただし、このデータセットは2009年のもので、遠隔教師あり(絵文字をラベルに使う)なので、この数値をそのまま本番の基準にしないでください。
Path B: HuggingFace 経由で CardiffNLP RoBERTa を使う
ツイート本文で最高クラスの精度を狙うなら、事前学習済みTransformerを使います。
from transformers import pipeline
classifier = pipeline(
"text-classification",
model="cardiffnlp/twitter-roberta-base-sentiment-latest",
top_k=None,
)
sample_tweets = [
"@user Love waiting three hours for support 😒 http",
"@user This new update is absolutely fantastic, best one yet!",
"@user The event was okay, nothing special.",
]
for tweet in sample_tweets:
result = classifier(tweet)
print(f"Tweet: {tweet}\nScores: {result}\n")
各ツイートに対して、negative、neutral、positive のラベルスコアが出ます。皮肉のあるツイート("Love waiting three hours...")は、ルールベースモデルよりネガティブ寄りになるはずです。もちろん、ここでも完璧ではありません。
Step 4: 結果を評価する
次に、従来型MLルートのために混同行列のヒートマップを出します。
import matplotlib.pyplot as plt
import seaborn as sns
from sklearn.metrics import confusion_matrix
cm = confusion_matrix(y_test, y_pred, labels=["negative", "positive"])
sns.heatmap(cm, annot=True, fmt="d", xticklabels=["negative", "positive"],
yticklabels=["negative", "positive"], cmap="Blues")
plt.xlabel("Predicted")
plt.ylabel("Actual")
plt.title("Confusion Matrix: Logistic Regression on Sentiment140")
plt.show()
Transformer ルートでは、最新の少量サンプル(50〜100件)を人手でラベル付けし、モデルを走らせて比較します。macro F1、各クラスの precision / recall、混同行列を出してください。本番案件なら、キャリブレーションと、曖昧なケース向けの保留閾値も確認します。
Step 5: エッジケースを試す
皮肉、絵文字、スラングを試すツイートをいくつか使ってみましょう。
edge_cases = [
"Oh great, another update that breaks everything 🙄",
"ngl this product slaps 🔥🔥🔥",
"The camera is amazing but the battery life is trash",
"Just got my order. It's... fine. I guess.",
]
for tweet in edge_cases:
clean = normalize_social_text(tweet)
result = classifier(clean)
print(f"Tweet: {tweet}\nScores: {result}\n")
どこで当たっていて、どこで苦戦するのかを見てください。複数対象を含むツイート("camera is amazing but battery is trash")はよくある難所です。側面別感情分析は別タスクです。
コードを書かずに Twitter 感情分析をする方法
Python を書きたくない人もいます。それは問題ありません。マーケター、ブランド管理者、オペレーション担当など、コードに触れずに感情インサイトが欲しい人向けの道もあります。
正直に言うと、ノーコードツールは柔軟性と引き換えに速度を得ています。簡易なブランド監視には最適ですが、研究レベルの分析や独自モデル学習には向きません。
ノーコードの選択肢を一覧で見る
| ツール | 向いている用途 | 感情分析は標準搭載? | 価格帯 |
|---|---|---|---|
| AWS Comprehend | 大規模テキスト分析 | はい | 従量課金 |
| Brandwatch / Sprinklr | 本格的なソーシャルリスニング | はい | エンタープライズ価格 |
| Google Sheets + NLP アドオン | すばやい軽量分析 | アドオン経由 | 無料〜低価格 |
| Thunderbit + スプレッドシート | 対応ページの構造化とラベル付け | 試験的ラベル用の AI Field Prompt | 無料プランあり |
ノーコードワークフロー: データを集め、スプレッドシートで分類する
これは、ツイートデータをすでに持っている人(公式X API、認可済み提供元、自分のアーカイブから取得した場合)向けの実用的な流れです。
- ツイートデータをスプレッドシートにエクスポートする。 X API を使ったなら JSON を CSV に変換するか、Thunderbit のようなツールを使って、許可のある対応ページからデータを整形・書き出します。
- Google Sheets で開く。 ツイート本文を列に貼り付けるか、インポートします。
- 感情分類を適用する。 Google Sheets の NLP アドオン(現行の選択肢はアドオンマーケットプレイスで確認)や AWS Comprehend のようなサービスを使います。セルの式から直接感情分類できるアドオンもあります。
- 確認して可視化する。 Google Sheets 標準のグラフ機能で、感情分布の棒グラフや、時系列の折れ線グラフを作ります。
Thunderbit の AI Field Prompt を使えば、対応ページでの抽出時にプロンプトベースの感情ラベルを追加することもできます。探索的なモニタリングには便利です。ただし、監査が必要な判断や重要な意思決定では、サンプルを検証し、文書化されたモデルを使ってください。
ノーコードとPython、どちらを使うべき?
| シナリオ | おすすめの方法 |
|---|---|
| ざっくりしたブランド確認、少量データ | ノーコード(スプレッドシート + アドオン) |
| チーム向けダッシュボード、週次レポート | ノーコードまたはローコード |
| 大規模分析、独自モデル | Python |
| 学術研究、再現性重視 | Python |
| 大規模なリアルタイム監視 | Python + API + 定期実行パイプライン |
Twitter 感情分析の結果を可視化する

多くのチュートリアルは分類レポートで終わります。でも、チームに共有したり意思決定に使ったりするなら、可視化が必要です。
感情分布の棒グラフ
最も基本的ですが、どんな場面でも役立つ出力です。
import matplotlib.pyplot as plt
import seaborn as sns
sentiment_counts = df["label"].value_counts()
sns.barplot(x=sentiment_counts.index, y=sentiment_counts.values, palette="coolwarm")
plt.xlabel("Sentiment")
plt.ylabel("Tweet Count")
plt.title("Sentiment Distribution")
plt.show()
感情クラス別のワードクラウド
ポジティブとネガティブのツイートを分けてワードクラウドを作ると、人々が実際に何を言っているかが見えてきます。
from wordcloud import WordCloud
for sentiment in ["positive", "negative"]:
text = " ".join(df[df["label"] == sentiment]["clean_text"])
wc = WordCloud(width=800, height=400, background_color="white").generate(text)
plt.figure(figsize=(10, 5))
plt.imshow(wc, interpolation="bilinear")
plt.axis("off")
plt.title(f"Word Cloud: {sentiment.capitalize()} Tweets")
plt.show()
時系列で見る感情変化: 他の記事があまり見せないチャート
これこそ、生データをストーリーに変える可視化です。タイムスタンプがあれば、イベント、発表、危機対応の最中に感情がどう変化したかを追えます。
df["date"] = pd.to_datetime(df["date"])
df["day"] = df["date"].dt.date
sentiment_map = {"positive": 1, "neutral": 0, "negative": -1}
df["score"] = df["label"].map(sentiment_map)
daily = df.groupby("day")["score"].mean()
plt.figure(figsize=(12, 5))
daily.plot()
plt.xlabel("Date")
plt.ylabel("Average Sentiment Score")
plt.title("Sentiment Over Time")
plt.axhline(0, color="gray", linestyle="--")
plt.show()
発表当日に急落したなら、それがネガティブ投稿を掘り下げるサインです。何が悪かったのかを確認しましょう。
混同行列ヒートマップ
評価ステップで既に示したものです。ポイントは、モデルがポジティブをネガティブと誤認する箇所(またはその逆)を見ること。そこが、人手で読む価値のある投稿です。
ノーコード派向け: Google Sheets や Notion での可視化
感情ラベル付きデータをスプレッドシートに出していれば、感情分布や推移は Google Sheets、Notion、または任意のBIツールでそのまま可視化できます。Pythonは不要です。
Twitter 感情分析でよくある失敗と回避法
実務の感情分析では、同じミスが何度も出てきます。
皮肉とアイロニー
最大の精度低下要因です。「Love waiting three hours for support 😒」は、ルールベースモデルにはポジティブに見えてしまいます。Transformer はよりうまく処理しますが、皮肉は構造的に難しいままです。特に投稿単体に文脈(スレッド、投稿者履歴、イベント)がない場合はなおさらです。重要な用途では、モデル出力に人間の確認を組み合わせてください。
絵文字とスラングの見落とし
前処理で絵文字を消してしまい、テキスト化もしないなら(疎なモデル向け)、あるいはTransformerで保持しないなら、データの最も強い感情シグナルを捨てていることになります。スラングも同様です。「ngl this slaps」はポジティブですが、フォーマル英語で学習したモデルは理解できないかもしれません。
古いAPIチュートリアルと壊れたスクレイパー
Tweepy と API v1.1 を使っているチュートリアルは古いです。snscrape を勧めているなら、2023年以降 X 検索では動いていません。チュートリアルは必ず日付とAPIバージョンを確認してください。
ひとつのデータセットへの過学習
Sentiment140 は学習に優れていますが、2009年のデータです。2024年の EMNLP による20件のソーシャルメディアデータセット監査では、重複を除去すると19件中14件でF1が下がり、19件中17件でモデル順位が変わったと報告されています。時間分割、イベント分割、できれば著者分割を使ってください。最近のツイートで汎化性能を確認しましょう。
感情スコアを正解ラベルとみなすこと
モデルスコアは校正済み確率ではありません。感情ラベルだけを根拠に自動応答や対外的判断をしてはいけません。個人や危機対応に関わる決定では、必ず人間の確認を入れてください。
プライバシー、プラットフォームポリシー、責任ある利用
この章は任意ではありません。
XのDeveloper Policy は、プライバシー、ユーザーコントロール、コンテンツ削除、X外での照合制限を重視しています。実務上のルールは次のとおりです。
- 必要最小限の項目だけ収集する。
- 生のハンドルを公開するのではなく、結果は集計する。
- コンプライアンスのため、Post ID と取得タイムスタンプを保持する。
- 削除、保護設定の変更、正式な要求があった場合は、保存内容を削除または更新する。
- 個人のセンシティブな属性を推測しない。
- 許可と同意なしに、感情スコアをCRMの個人情報と結びつけない。
- restricted-use rules で禁止されている場合、Xコンテンツを使って基盤モデルを学習・ファインチューニングしない。
- サンプルサイズ、検索語、期間、言語フィルタ、除外条件を文書化する。
- 感情スコアだけで公開応答を自動化しない。
感情分析は強力なツールですが、同時に大きな責任も伴います。それにふさわしく扱ってください。
まとめと重要ポイント
Twitter 感情分析は2026年でも有効です。ただし、今の現実に合わせてやり方を更新した場合に限ります。昔のやり方——無料API、小文字化だけの前処理、VADERやNaive Bayes、評価なし——はもう通用しません。本当に効くのは次のやり方です。
- 許可された経路でデータを取得する。 X API v2(従量課金)、認可済み提供元、または透明性のあるデータセットを使いましょう。壊れたスクレイパーやブラウザ回避策に頼らないでください。
- 見た目ではなく、モデルに合った前処理をする。 Transformer では絵文字、否定、大文字を残し、URL とメンションを正規化します。パイプラインを学習データに合わせてください。
- 安価なベースラインとツイート特化Transformerを比較する。 TF-IDF + logistic regression は、今でも良い健全性チェックです。Twitter感情分析の現在の強い標準は CardiffNLP RoBERTa です。
- 正直に評価する。 macro F1、クラス別指標、混同行列を出しましょう。最新の人手ラベル付きサンプルを使い、曖昧なケースには保留閾値を設けます。
- 飾りではなく、意思決定のために可視化する。 時系列の感情チャートやワードクラウドは、分類レポートでは見えないストーリーを伝えます。
- 人間をループに残す。 皮肉、複数対象、文脈依存の意味を完全に扱えるモデルはありません。重要な用途では、モデル出力に人による確認を組み合わせてください。
これから始めるなら、無料データセットを取って、Google Colab を開いて、HuggingFace の pipeline を動かしてみてください。10分以内に、ちゃんと動く感情スコアが得られます。ほかの業務でコードなしにWebデータを集めて整形したいなら、Thunderbit は、許可のある対応ページで役立ちます。
ポートフォリオや面接向けの作品を作るなら、Transformer比較、実際の前処理パイプライン、時系列の感情チャートを入れるだけで、Bootcampの定番作品とは一線を画せます。
さらに学ぶ
- Thunderbit を使った自動データスクレイピングをマスターする方法
- 2026年版: Twitter(x.com)スクレイパーおすすめ6選
- 2025年に Python で Twitter からツイートをスクレイピングする方法
- Twitter の AI スクレイピングでデータ洞察を強化する方法
- Twitter(X)統計 2026年版: ユーザー数、属性、広告
FAQ
Twitter 感情分析の精度は高いですか?
モデルと評価方法によります。VADER のようなルールベースツールは、ツイートデータでは精度が低めです。CardiffNLP RoBERTa のようなTransformerは大幅に良い結果を出しますが、正確なスコアはデータセット、分割方法、ラベル定義、指標によって変わります。前処理の質も重要です。ベンチマーク値をひとつ信じるのではなく、最新の人手ラベル付きサンプルで必ず評価してください。
Twitter 感情分析を無料でできますか?
はい。無料データセット(Kaggle の Sentiment140)、無料の Python 環境(Google Colab)、事前学習済みの HuggingFace モデルを使えばできます。ライブデータについては、X API はPost 1件読み取りあたり $0.005なので、小規模収集なら十分手頃です。Thunderbit には、対応ページのデータ整形向けに無料プランがあります。
Twitter 感情分析に最適な Python ライブラリは何ですか?
素早く試すなら、NLTK 経由の VADER。ツイートで最も高い精度を狙うなら、CardiffNLP の RoBERTa を使う HuggingFace の transformers ライブラリ。従来型MLのベースラインなら scikit-learn の TF-IDF です。最適な選択は、データ量、必要精度、計算予算によって変わります。
Twitter 感情分析で皮肉はどう扱えばいいですか?
Transformer モデルは、単語単体ではなく文脈を扱うため、ルールベースや従来型MLより皮肉に強いです。ただし、どのモデルも皮肉を完全には扱えません。研究では、人間の注釈者でさえ皮肉の意図に意見が分かれることが示されています。重要用途では、モデル出力に人手確認を組み合わせ、評価用に皮肉特化データセットの利用も検討してください。
コーディングなしで Twitter 感情分析はできますか?
はい。許可された経路(X API、認可済み提供元、自分のアーカイブ)でデータを取得し、Google Sheets に出力して、Sheets の NLP アドオンや AWS Comprehend のようなサービスでノーコードの感情分類を使えばできます。Thunderbit は、対応ページのデータ整形時にプロンプトベースの感情ラベルを追加することもできます。ノーコードのデータワークフローについては、Google Sheets 向け AI ツール のガイドも参考になります。


