「話題の記事」の判定をLLMに任せると壊れる──APIで取得・ソートし、解釈だけを任せる設計パターン

LLM や AI エージェントにトレンド情報の収集や検索結果の要約を任せる運用は、開発現場で広く行われるようになりました。プロンプトに「人気の話題を集めて」「高スコアな議論をリストアップして」と指示し、返ってきた整然とした箇条書きをそのまま信用しているケースも少なくありません。

しかし、その返答に含まれる 「順位や優位性の主張」 を実際に検算したことはあるでしょうか。

実は、LLM は存在しない情報をでっち上げるハルシネーション（嘘）を起こさない場合でも、「実在する正確なタイトルや URL を提示しながら、順位・スコアの評価判定だけを静かに踏み外す」という非常に厄介な失敗を起こします。出力されたテキストがあまりにも滑らかで、提示された URL もすべて実在するため、人間側が検算する発想に至らず、誤った順序づけをそのまま信用してしまう罠が存在するのです。

本記事では、自社で実施した Hacker News REST API による実測検証データをもとに、LLM がなぜ「存在判定（検索・要約）」には強く「順位判定（定量ソート）」には弱いのか、その構造的メカニズムと実践的な解決アーキテクチャを解説します。

一次検証ケーススタディ — Hacker News API で暴く405倍の定量的落差

「LLM の順位判定は崩れやすい」という話を単なる抽象論で終わらせないために、自社で実施したWeb検索エージェントによる実測検証データを示します。

ある調査タスクにおいて、Web検索機能を備えた LLM エージェントに対し、Hacker News および lobste.rs の直近1週間における「高スコア議論（top discussions）」の収集と要約を依頼しました。その際、エージェントへ投入した実際のプロンプト原文は以下の通りです。

Web-search: Hacker News and lobste.rs top discussions from 2026-07-27 to 2026-08-03 about LLM coding agents, context engineering, or agent evaluation. Return 5-8 bullets, each with the exact discussion URL (news.ycombinator.com/item?id=... or lobste.rs/s/...) and date. Output ONLY findings + URLs + dates. No preamble.

この指示に対してエージェントから返却された 8 件の Hacker News トピックについて、Hacker News の公式 Firebase REST API¹ を用いて、各トピックの実際のスコア（ポイント数）およびコメント数を実測・検証しました。

検証に使用した Bash コマンドは以下の通りです。

for id in 49076391 49070029 49100518 49110389 49122901 49129260 49145408 49145661; do
  curl -s "https://hacker-news.firebaseio.com/v0/item/$id.json" \
  | python3 -c "import sys,json,datetime as d;i=json.load(sys.stdin) or {};print(f\"{i.get('id')} | {i.get('score')}pt | {i.get('descendants')}c | {d.datetime.fromtimestamp(i.get('time',0)).date()} | {i.get('title')}\")"
done

実測データが示した鮮烈なギャップ

今回の検証事例（8件）において、返却された 8 件すべてのトピック ID・タイトル・URL は実在しており、内容の要約も正確でした。しかし、確定データである API 経由で取得した実際のスコアを並べると、極めて衝撃的な事実が判明しました。

最高スコア: 405 pt（119 コメント）— Benchmarking Opus 5 on SlopCodeBench
最低スコア: 1 pt（0 コメント）— Show HN: Replaybook, an Infrastructure Agent Evaluation Framework
スコアの定量的落差: 最高値と最低値の差は 405倍
低スコア記事の割合: 「高スコア議論」として選出・返却された 8 件のうち 5 件（62.5%）が、実際には 1〜3 pt の低スコア記事（内訳: 405pt, 32pt, 30pt, 3pt, 2pt, 2pt, 1pt, 1pt）

返却されたリストは見た目にも美しく整理されており、提示された URL もすべて問題なく閲覧できます。そのため、API で実測しなければ「1pt（コメント0件）の投稿」が高スコア議論として混ざっていることに誰も気づけません。

この破綻が起きた根本原因は、指示文で「スコアが何ポイント以上」という明確な数値ソート条件を与えず top discussions という曖昧な表現を使ったことにあります。その結果、エージェント側が「話題になりそうなテーマか」という定性的な文脈類似度と、「実際のスコアが上位である」という定量評価を暗黙に同一視してしまったのです。

構造的メカニズム — LLMが「存在判定」に強く「順位判定」に弱い3つの理由

なぜ LLM は、情報の検索や内容の要約（存在判定）には非常に強いのに対し、スコア順ソートや順序づけ（順位判定）ではこれほど脆いのでしょうか。学術研究とモデル構造から 3 つの理由に整理できます。

1. 確率的トークン予測 vs 決定論的計算とメタデータ不保持

LLM は本質的に、過去の文脈から次に来る単語の出現確率 $P(w_t | w_{1…t-1})$ を予測する確率的モデルです。アルゴリズムに基づく確実な数値比較演算（score_A > score_B）やソート処理を内部で決定論的に保証することはできません。

さらに、Web 検索や情報抽出のステップにおいて、LLM は元のページに含まれる定量的メタデータ（スコア数値）を正しく抽出・評価・保持せず、テキストとしての話題性や意味的類似度のみを基準にアイテムを選択してしまう傾向があります。

2. 位置バイアス (Position Bias) と Lost in the Middle

LLM に複数のテキスト情報を与えて評価・抽出を行わせる際、入力コンテキスト内の配置順序が判定に強い影響を与えます。

Liu et al. の研究『Lost in the Middle』² が示す通り、LLM は入力プロンプトの先頭と末尾にある情報に高い注意（Attention）を向ける一方で、中央付近に存在する情報を軽視・見落としやすいという U 字型のパフォーマンス特性を持ちます。検索候補や候補リストをコンテキスト上に展開して評価させると、提示順序や配置の位置バイアスによって選択結果が大きく左右されます。

3. 順序バイアスと推移律の不成立

LLM を用いたペア比較やランキング処理に関する研究（RankGPT³ や Position Bias in LLM Reranking⁴）では、LLM 単体に順位付けを行わせる際の限界が定量的に立証されています。

LLM にアイテム A と B を比較させるとき、入力文脈での提示順序（A→B か B→A か）を入れ替えるだけで判定が容易に反転する順序バイアスが存在します。このため、正常なソートアルゴリズムの前提となる 推移律（$A > B$ かつ $B > C$ ならば $A > C$）や反対称性が崩れやすく、LLM 単体での並べ替え判定は本質的に不安定になります。

実践的解決パターン — 決定論的処理はAPIに、解釈はLLMに

この問題に対する解決策はシンプルです。「決定論的な事実計算（取得・フィルタ・ソート）」と「確率的なテキスト処理（解釈・要約）」を明確に分離すること（Separation of Concerns）です。

取得経路による信頼性の決定的な差

同じ目的（例: Hacker News の話題記事を取得して要約する）であっても、実現アプローチによって信頼性は天と地ほど変わります。

LLM 直投げ Web 検索（アンチパターン）: LLM に対して「人気の話題を集めて要約して」と一括で指示する形態。LLM 内部で検索・評価・順位づけ・要約が混ざり合い、前述の実例のように順位の主張が破綻します。
API 直叩き＋ LLM 要約（推奨パターン）: Hacker News REST API をプログラムや専用スクリプトで呼び出し、決定論的にスコア上位 N 件を取得・ソートします。その確実なソート済みデータを LLM に入力として渡し、要約や解説の生成のみを任せます。

役割分担のコード / プロンプト構成例

開発現場や AI エージェントの設計では、以下のように処理レイヤーを分離します。

import json
import requests

# 1. 決定論的レイヤー: APIから確定データ（スコア上位）を取得・ソート
def fetch_hn_top_stories(limit=10):
    top_ids = requests.get("https://hacker-news.firebaseio.com/v0/topstories.json").json()[:limit]
    items = []
    for item_id in top_ids:
        item = requests.get(f"https://hacker-news.firebaseio.com/v0/item/{item_id}.json").json()
        items.append({"title": item.get("title"), "score": item.get("score"), "url": item.get("url")})
    # スコア順に確定ソート
    items.sort(key=lambda x: x["score"], reverse=True)
    return items

# 2. 解釈レイヤー: ソート済みデータをLLMに渡して要約のみを依頼
top_items = fetch_hn_top_stories(limit=5)
prompt = f"""
以下のリストは、Hacker News の最新高スコア記事（確定ソート済み）です。
各記事の主要なポイントを技術者向けに簡潔に要約してください。

{json.dumps(top_items, ensure_ascii=False, indent=2)}
"""

このアプローチは、Anthropic が公開している『Building Effective Agents』⁵ の設計原則とも完全に合致しています。自律的エージェントですべてを推論・判断させようとするのではなく、確定的なデータ取得や計算ステップはプログラムによる「ワークフロー」として固定し、自律性が必要な要約や文脈分析のフェーズでのみ LLM を呼び出す設計です。

また、Anthropic の Tool Use⁶ や OpenAI の Function Calling⁷ も、この決定論的レイヤーと生成レイヤーの分離を安全に実現するための標準的な仕組みです。

自社プロンプト・設計の自己診断チェックリスト

ご自身の開発している AI システムや日常のプロンプト運用において、定量的判定を LLM に無意識に委ねていないか、以下の項目でセルフチェックしてみてください。

[ ] プロンプトの中に「スコア順に」「最新順に」「高評価なもの」といった決定論的ソート・比較要求が含まれていないか？
[ ] 順序判定やフィルタリングを、API パラメータ（sort_by, order）やプログラムコード（sort()）で担保しているか？
[ ] LLM にはソート済みの確定データ（JSON等）を渡し、言語化・要約・分析のみを行わせているか？

「判定と要約は分ける。判定は決定的に取れる手段があるならそちらを使う」

このシンプルな切り分けをシステム設計に組み込むだけで、LLM エージェントが吐き出す「静かな順位の誤り」を防止できます。

おわりに

LLM はテキストの解釈、文脈の要約、概念間の関係性の抽出といった「定性的な分析」において圧倒的なパフォーマンスを発揮します。しかし、確実な比較や数理的な並べ替えといった「決定論的な事実計算」を LLM に単体で任せるのは、専用のソートアルゴリズムを持たないモデルに対して誤った期待を寄せていると言えます。

「事実判定は API やプログラムに任せ、LLM は解釈と表現に専念させる」。この役割分担を徹底することで、ユーザーに安心して提示できる堅牢な AI アプリケーションや調査システムを構築していきましょう。

AI エージェントの設計や自動化プロセスの品質担保でお悩みの方は、ぜひコンタクトフォームよりご相談ください。