Claudeを使って、Wikipediaの大量ページを拾い、分割し、分類し、点数を付けて、最後に表へ落とし込む。これは派手なデモに見えて、実際はかなり実務的な発想です。

この記事では、X上で共有されたRuby製CLIツールのデモを手がかりに、AIを使って情報収集から整理までを一本の流れにする考え方を整理します。

この記事でわかること
– 大量のテキストをAIに渡す前に、なぜ分割が必要か
– Claudeを分類器や採点器として使うときの設計の勘所
– CLIツールにすると何が速くなるか
– 似た入力を毎回手で読まないための実装上の考え方

https://x.com/lsanger/status/2047045682045780258

まず何をしているのか

このデモの要点は、Wikipediaの93ページをまとめて扱うところにあります。単に要約させるのではなく、まずページを取得し、次に分割し、その後でClaudeに分類やスコアリングをさせています。最後はランキングやテーブルにまとめるので、結果を人間がそのまま見比べやすい形まで持っていけます。

ここで重要なのは、AIに全部やらせて終わりにしていない点です。取得、分割、分類、採点、整形を分けています。これによって、どの段階で精度が落ちたのかを切り分けやすくなります。AI活用で失敗しやすいのは、入力も処理も出力も一体化してしまうことです。原因が見えません。CLIにすると、各段階をログで追いやすくなります。

分割が先に来る理由

長文をそのままモデルに投げると、文脈の一部が埋もれます。特にWikipediaのように、見出し、本文、注釈、リンク先の文脈が混ざる素材では、1回で全部を理解させるより、意味のまとまりごとに切ったほうが安定します。

分割の目的は、単にトークン数を減らすことではありません。分類単位を揃えることです。たとえば、人名、年表、出来事、概念説明が混ざったままだと、モデルは何を軸に判断すればいいか迷います。まとまりを小さくし、役割を決めてから渡すと、出力のブレが減ります。

この発想はRAGにもそのまま使えます。検索した断片をそのまま詰め込むのではなく、見出しやテーマごとに切り分けてから評価させる。そうすると、後段のランキングや重み付けがやりやすくなります。

Claudeを分類器として使う意味

このデモでは、Claudeが文章を読むだけでなく、分類やスコア付けにも使われています。ここが実務上のポイントです。生成だけでなく、判定にも使うと、AIは「文章を作る道具」ではなく「作業を進める部品」になります。

分類器として使う場合、気を付けるべきなのは基準の固定です。毎回ちがう尺度で採点すると、ランキングの意味がなくなります。CLIツールでは、分類ラベルや点数の定義を先に決めておき、入力が変わっても同じ軸で返す設計が必要です。

Wikipediaのページは話題の幅が広いので、概念の近さだけでなく、説明の密度や再利用しやすさも評価対象にできます。ここでAIを使うと、単純なキーワード一致では拾えない関連性を見つけやすくなります。

表に落とすと何が変わるか

最後にテーブルへ整形する工程は、見た目の問題ではありません。比較可能性を上げる工程です。

人間は長い文章を連続で読むより、表で並んだ差分を見たほうが判断しやすいです。どのページが上位なのか、どのカテゴリに寄っているのか、どの項目が似ているのかを、1画面で確認できます。これはAIの精度が多少ぶれても、最終判断を人間が行いやすくするための工夫です。

ここでもCLIは強いです。結果をJSONやCSVに吐き出せば、あとから再集計できます。UI上の会話だけで終わるワークフローは、その場では便利でも、後で検証しにくいです。再現性が要る仕事ほど、ファイルに残す価値が大きくなります。

Rubyで組む利点

Rubyはテキスト処理が書きやすく、CLIの体裁にまとめやすい言語です。Wikipediaの取得、分割、整形のような処理は、スクリプトとしてつなぐとすばやく形になります。そこにClaudeを差し込むと、面倒な読解工程だけをモデルに任せられます。

重要なのは、AI部分をコードの中心に置きすぎないことです。取得や保存、失敗時のリトライ、出力形式の固定は、従来のプログラムとして堅く書いたほうがいいです。AIはあくまで判断が必要な部分だけに使います。役割を分けるほど、壊れにくくなります。

このデモから得られる実務のヒント

この事例は、単なるおもしろデモで終わりません。大量の資料を扱う仕事、調査メモを比較したい仕事、候補を絞りたい仕事にそのまま応用できます。

たとえば、社内ドキュメントの棚卸し、記事候補の選別、FAQの重複検出、競合サービスの一覧化などです。共通するのは、読む量が多く、判断軸をそろえたいことです。そこにAIを入れると、読む人の時間を削れます。

逆に向かないのは、基準が曖昧なまま「とにかく賢く要約してほしい」と投げるケースです。そういう使い方では、出力がふわっとして終わります。まず入力を分ける。次に採点軸を決める。最後に表へ出す。この順番が崩れると、再利用しにくい結果になります。

まとめ

このRuby CLIのデモが示しているのは、Claudeの強さそのものより、作業を工程に分ける設計の強さです。取得、分割、分類、採点、整形を切り分けると、AIは一気に実務へ近づきます。

大きな入力をそのまま読ませるより、意味の単位に分けて評価させる。会話で終わらせるより、CLIで結果を残す。こうした基本設計の差が、使えるAIツールと雰囲気だけのデモを分けます。