はじめに

LLM（大規模言語モデル）の活用は、単なる文章作成や要約のフェーズを超え、推論エンジンやエージェントとしての利用へと急速にシフトしています。とはいえ、「これまで人間や従来の機械学習が担っていた泥臭い領域」を全てLLMで代替できるわけではなく、あくまでタスクによって使い分けるしかないのが今の状況と考えています。

テキストや画像のような非構造化データ：LLM
CSVやExcelのような構造化データ：機械学習

大枠としてはこういう枠組みで考えても良さそうですが、それだけでもない気がします。そこで今回、テキストを扱うタスクにおいても機械学習が有利になるケースを考え検証してみました。

結論から言うと、今回検証で扱った「テキスト分類タスク」において、推論速度に500倍以上の差がつき機械学習（LightGBM）が圧勝という結果になりました。

本記事では、その実験データとなぜそうなったのかの技術的背景や使い分けの視点について触れていきます。

1. 検証の目的とタスク設定

目的

「明確な正解が存在するテキスト分類タスク」において、LLMは本当に最適なソリューションなのか？
推論時間と精度の観点から機械学習手法（LightGBM）と比較検証し、アーキテクチャ選定の判断軸を再考する。

タスク：Livedoorニュースコーパスの分類

データ: livedoor ニュースコーパス（約7,300記事）
クラス数: 9クラス（IT、スポーツ、芸能、家電、映画など）
入力: ニュース記事のタイトルと本文
環境: MacBook Air (M4) / Python 3.11

つまり、「与えた文章（テキスト）が、9つのカテゴリのどれに該当するか」という分類を行い、機械学習とLLMのどちらの精度が良いかを検証するものです。

2. 対戦カード

🥊 赤コーナー：LightGBM （機械学習）

アプローチ: 教師あり学習
特徴量: MeCabによる形態素解析 → TF-IDF (max_features=5000)
モデル設定:
- objective: multiclass
- num_boost_round: 100 (Early Stoppingあり)
- 戦略: 「単語の出現パターン」に基づく高速なルールベース推論

🥊 青コーナー：Local LLM（大規模言語モデル）

モデル: Llama-3.1-8B-Instruct (4bit量子化)
実行環境: Ollama(Apple Silicon最適化)
アプローチ: Zero-shot 推論 (学習なし)
生成パラメータ: temperature=0.0
- 意図: 分類タスクにおける再現性を担保し、ハルシネーションを抑制するため、決定論的な挙動に固定。
System Prompt:

"あなたは分類タスクを行うAIです。余計な説明は不要です。カテゴリ名だけを答えてください。"

3. 実験結果

実験コードを実行し、出力されたログを集計した結果が以下です。

▼LightGBM検証結果

▼Local LLM検証結果

評価指標	LightGBM	Llama 3.1 8B	勝者
正解率 (Accuracy)	94.17%	40.0% (参考値)	🏆 LightGBM
平均推論時間	約 0.001 秒/件	約 0.50 秒/件	🏆 LightGBM (約500倍高速)
学習時間	約 8.6秒 (全件)	なし	-

※ 補足: LightGBMのスコアは「学習・前処理を含む全工程の所要時間（8.6秒）」を「全データ数（約7,300件）」で割ったスループット値です。純粋な推論のみであればさらに高速（マイクロ秒オーダー）になります。

評価のまとめ

速度差 500倍:
LightGBMが瞬きする間に1,000件処理している横で、LLMはやっと2件目の分類を終えている状態。
精度の崩壊:
LightGBMが94%を叩き出したのに対し、LLMは40%程度。これはLLMが「文脈」は理解できても、smax（ガジェット系）やdokujo-tsushin（女性コラム）といった「データセット固有のラベル」を知らないため。

4. 何が起こった？

LightGBMの勝因は、TF-IDF × 決定木というアルゴリズムの特性がこのタスクにハマった点にあります。（というか最初からわかっていたことではありますが）

TF-IDFの本質：巨大なOne-Hotの重み付け

LightGBMに入力されたのは単語の意味ベクトルではなく、「その単語が含まれているか（TF）× その単語はレアか（IDF）」を表す巨大な表（疎行列）です。

「今日」のような単語: どの記事にもある → IDFがゼロに近づく → 無視される。
「iPhone」のような単語: 特定の記事にしかない → IDFが高い → 決定的な特徴量になる。

逆に言えば、LightGBMは『辞書にない単語』には無力で、ここがLLMとの明確な境界線になります。

決定木の挙動：距離ではなく「ルール」

LightGBMはベクトル空間上の意味の近さを計算しているわけではなく、「iPhone」という単語のスコアが0.5以上なら右のノードへ（ITカテゴリ確定）といった、if文のルールを高速に構築しています。

ニュース分類のようなタスクでは、「キーワードの有無」がカテゴリ決定の9割を占めるため、複雑な文脈理解よりも単純なルールベースの方が圧倒的に効率が良いのだと考えます。

5. 想定されるツッコミ

Q. 「プロンプトを工夫（Few-shotとか）すればLLMも精度が出るのでは？」

A. 出ると思います。ただし、入力トークン数が増えて推論時間はさらに遅くなると思われます。0.001秒で終わるタスクに、コストをかけて重いLLMを使う経済合理性は低いです。

Q. 「学習データを作るコスト（アノテーションとか）を無視していない？」

A. LLMを使う場合でも、ハルシネーション検知のためにテストデータ作成は必要。また、これほど明確な差が出るなら、アノテーションコストを払ってでも専用モデルを作る方が長期的な運用コストでメリットはあると思います。

Q. 「じゃあLLMは役に立たないのか？」

A. いや、適材適所かと。
もし、タスクが「ネガティブな表現の検出」や「未知の概念の推論」であれば、キーワードマッチのLightGBMは歯が立たないでしょうし、LLMが圧勝していたと思います。（例えば、iPhone35というものはまだ存在しないけど、LLMなら文脈からその意味を理解し分類可能）

6. 結論

今回の検証はある意味で出来レースでした。キーワードが支配的な分類タスクでLightGBMが勝つのは直感で分かることです。
ただ、今回の検証結果で「やっぱりなんでもかんでもLLMは無理だよね」という事実を数字で再確認することができました。

得られた示唆

「バターにはナイフを、木にはチェーンソーを」
- タスクが決定論的なら「枯れた技術」の方が速くて安くて確実。
LLMは「部品」として見る
- 全てをLLMにやらせるのではなく、「LLMで非構造化データを解釈し、LightGBMで高速に判定する」といったハイブリッド構成が良さそうです。

以上