Redditで話題になった「Claudeを使った大規模データ分析」の事例
本記事はCLSTRプロジェクト開発者様から許可を得て投稿しています。
海外掲示板Redditに投稿された、920万件規模のニュースデータを、データ処理パイプラインとClaudeを組み合わせて分析した事例が注目を集めています。
CLSTRというプロジェクトが約145日間で蓄積・処理した920万件規模のニュースデータについて、Claudeを使って分析したという内容です。
ニュース業界の話というよりも、920万件という大量のデータを、どう圧縮・構造化してからAIに渡すかという設計の話として参考になる内容です。
本記事では、その投稿内容とRedditに寄せられたコメントをもとに、AIを使った大規模データ分析の進め方や考え方を整理します。
該当の投稿 : https://www.reddit.com/r/ClaudeAI/comments/1wbv0yc/i_asked_claude_to_go_through_92_million_news/
全体の処理の流れ
CLSTRのデータ処理は、大きく分けて6つの段階で構成されています。
- ニュース収集: 4万以上のソースから、1日最大10万件規模の記事を収集
- 重複排除: 既存記事と極めて類似した記事を除外
- クラスタリング: 同じ出来事を報じている記事同士をまとめ、1つの「クラスタ」にする
- ストーリー化: 関連するクラスタを時系列でつなげ、「ストーリー(situation)」として展開を追えるようにする
- 集計: クラスタ数・ストーリー数・スコア分布などを数値としてまｔめる
- Claudeによる分析: 集計結果と代表的なサンプルデータを渡し、傾向の解釈や考察を行う
Claudeが登場するのは最後の1段階だけで、そこに至るまでの5段階はすべて専用のパイプラインが担当しています。
「記事」「クラスタ」「ストーリー」の違い
この事例を理解するうえで欠かせないのが、3つの単位の違いです。
| 単位 | 意味 | 件数 |
|---|---|---|
| 記事(article) | 収集した生のニュース記事そのもの | 9,220,844件 |
| クラスタ(cluster) | 同じ出来事を報じる記事をまとめた単位(2ソース以上のもの) | 787,464件 |
| ストーリー(situation) | 関連するクラスタを時系列でつなげた展開・timeline | 113,142件 |
CLSTRの定義では、クラスタは「1つの実際に起きた出来事」、ストーリーは「その出来事群が形成する展開」とされています。
例えば、ある地震を40の媒体が報じた場合、40本の記事は重複排除・クラスタリングを経て1つのクラスタに集約されます。
さらに、その地震に関連する救助活動や復興のニュースが後日発生した場合、それらは同じ「ストーリー」の中でつながっていきます。
920万件の記事が78万件超のクラスタに、さらに11万件超のストーリーに整理されていくイメージです。
78万件超のクラスタは「2つ以上の異なるソースから報じられた出来事」に限定されています。1ソースしかないクラスタは表示対象外として扱われているとのことです。
なぜ920万件をそのままLLMに渡さないのか
今回の事例のように、生データではなく集計結果を渡す設計が採られる背景には、一般的に次のような理由が挙げられます。
- コンテキスト量の制約: LLMには一度に入力できるトークン数に上限があり、920万件の記事全文をそのまま入力するのは現実的に不可能
- コスト: 入力データ量が増えるほど推論コストも増加するため、生データをそのまま渡す設計はコスト面で非効率になりやすい
- 処理時間: 大量データを逐次読み込ませる設計は、実行時間の面でも現実的ではない
そのため、今回の事例では、クラスタリングや集計といった大量データを扱う処理は専用パイプラインに任せ、Claudeには意味のある単位に圧縮されたデータを渡す、という役割分担がとられています。
Claudeに渡されたデータは何だったのか
Redditの投稿によると、Claudeに渡されたのは920万件の生記事ではなく、パイプラインが作成した集計データと、代表的な事例としてのサンプルデータでした。
具体的には、クラスタ数・ストーリー数・スコアの分布といった数値の集計結果に加えて、分析の裏付けとなる個別のクラスタ・ストーリーのサンプルが渡されたとみられます。
開発者によると、Observatoryページに掲載されているグラフについても、Claudeとのやり取りを重ねながら作成したとのことです。
「集計された数値」と「Claudeがそこから読み取った解釈」は別物という点は、このあとの数字を見る際にも意識しておきたいポイントです。
分析結果の一例
CLSTRが公開した分析では、いくつか興味深い数字が示されています。
あくまで今回のデータ分析でどのような出力が得られたかの一例として紹介します。各数字がどの母数・期間から算出されたものかもあわせて記載します。
1つの出来事あたり約11.7件の記事が公開されていた
CLSTRの集計では、1つのクラスタあたり約11.7件の記事が紐づく計算になります。
- 算出方法: 145日間(2026年4月10日〜9月1日)に読み込まれた記事数を、同期間の2ソース以上のクラスタ数(787,464件)で割った値
- 母数: 記事9,220,844件、クラスタ787,464件
ただ、CLSTR側はこの11.7という数字について「正確な比率というより、おおよその規模感(order of magnitude)として捉えてほしい」と明記しています。
単一ソースのクラスタが後から削除される仕組みもあり、クラスタ内の記事がすべて単純な転載・重複記事というわけでもないため、あくまで目安として見るのが適切です。
CLSTRは記事同士の類似度についてより厳密な数字も公開していて、2026年7月24日〜8月16日の24日間に読み込まれた275万件超の記事のうち、26万件超(9.6%)が、見出しと要約の双方で、直近2日以内の既存記事と98%以上の意味的類似度を示しました。
こちらは「厳格な条件での集計」「下限であって上限ではない」とCLSTR自身が説明している数字です。
「出来事」は3日以上ニュースにならない傾向に
-
クラスタ単位: 3日を超えて記事が追加され続けるケースは1.2%
母数は2ソース以上のクラスタ787,464件 -
ストーリー単位: 81.8%が3日後も進展を続けていた
母数は完了済みのストーリー49,232件
集計の粒度(出来事単位かストーリー単位か)によって、同じデータでも見え方が大きく変わるという点は、分析設計を考えるうえで参考になる部分です。「記事」というミクロな単位では短命に見える出来事も、「ストーリー」というマクロな単位でまとめ直すと、長期間動き続けていることが分かります。
「特筆すべき」と評価されたクラスタは0.07%
CLSTRでは、言語モデルが各クラスタの内容を読み、規模や影響範囲などをもとに1〜10のスコアを付けています。
- 算出方法: 言語モデルによる1〜10のスコアリングのうち、8以上を「exceptional」と分類
- 母数: スコア付け済みのクラスタ783,112件
そのうち、8以上の「特筆すべき」と評価されたクラスタは全体の0.07%でした。
この数値は、ニュースの重要度そのものを測定した客観的な統計ではなく、あくまで言語モデルによる主観的なスコアリングの分布です。
CLSTR自身も「これは測定ではなく、モデルによる判断である」としており、そのまま鵜呑みにせず分析事例の一つとして捉えておくべきです。
大規模データ分析におけるLLMの役割
ここまでの数字を整理すると、今回の事例における「従来型の処理」と「LLMの役割」の境界が見えてきます。
- 従来型の処理が担当した部分: 記事の収集、重複排除、クラスタリング、ストーリー化、件数などの集計 いずれも決まったルールに基づく、大量データの機械的な処理です
- LLM(Claude)が担当した部分: 集計されたデータを横断的に見て、傾向を解釈したり、仮説を立てたりする部分 加えて、各クラスタの重要度をスコアリングする部分にもLLMが使われています
つまり、「集計・検索」のような大量データを正確に処理する作業は従来型の仕組みに任せ、「複数の集計結果を横断して意味を読み取る」「傾向に仮説を立てる」といった解釈的な作業をLLMが担う、という分担です。
「LLMにすべてを処理させる」のではなく、LLMが得意な処理とそうでない処理を切り分けて設計することが、大規模データ分析にAIを活用する際のポイントといえそうです。
分析コストについて
Redditのコメントで真っ先に挙がったのは、これだけの分析にどれほどのコストがかかったのかという質問でした。
開発者は、Claudeのサブスクリプションプラン内で対応できたと回答しています。
ただし週の利用上限には達したとのことで、さすがに920万件規模のデータ分析は決して軽い処理ではなかったことがうかがえます。
ニュース以外への応用
今回の設計、つまり「生データ→前処理→意味のある単位への集約→LLMによる解釈」という流れは、ニュース記事に限った話ではありません。
同じ考え方は、サーバーのアクセスログ、ユーザーレビュー、問い合わせ内容、アプリの利用ログといった、日々大量に蓄積されるデータにも応用できます。
例えば、問い合わせ内容を種類ごとにグループ化して集計し、その集計結果をLLMに渡して傾向や仮説を考察させる、といった使い方が考えられます。
大量データをそのままLLMに読み込ませるのではなく、集約・構造化したうえでLLMに解釈させるという設計は、業種を問わず参考になりそうです。
まとめ
今回紹介したのは、CLSTRが約145日間かけて蓄積・処理した920万件規模のニュースデータを、データパイプラインとClaudeを組み合わせて分析した事例です。
ポイントを整理すると次の通りです。
- 920万件の記事は、78万件超の「2つ以上のソースから報じられた出来事(クラスタ)」と11万件超のストーリーに整理されていた
- Claudeは生データではなく、集計済みのデータと代表サンプルをもとに分析・考察を行う仕組み
- 収集・重複排除・クラスタリング・ストーリー化・集計は従来型のパイプラインが担当し、横断的な解釈や仮説の提示をLLMが担う
- 出来事(cluster)単位とストーリー(situation)単位では、同じデータでも見え方が大きく異なっている
- 各数値はCLSTR側が示す母数・期間・算出方法付きの結果であり、あくまで分析事例の一つとして参考にとどめるのが妥当
大規模データをAIで扱いたい場合、いきなり生データを読ませるのではなく、今回の事例のように前処理や集計を別のパイプラインで行ったうえで、AIに解釈・考察を任せるという役割分担の設計が、ニュース以外の領域でも参考になりそうです。
参考
・https://www.reddit.com/r/ClaudeAI/comments/1wbv0yc/i_asked_claude_to_go_through_92_million_news/
・https://clstr.news/observatory?utm_source=reddit&utm_medium=post&utm_campaign=claudeai
(Methodology欄に数値の前提条件が記載されています)