ChatGPT に PDF を渡して「要約して」と言うと、長文が返る。便利だが、毎日使うほど物足りなさが気になる。

LLM Wiki はこの物足りなさへの別の答えだ。「もっと良い要約」ではなく、そもそも要約ではない処理をする。

1. 圧縮していない

実測してみた。飼い猫の医療記録を3日分、ChatGPT Pro 出力も含めて 135KB 投入。整理後の LLM Wiki は 143KB。1.06倍、ほぼ同じ。

つまり情報量は減っていない。何をしているかというと、注意の足場を作っている。

家族が読める1枚（overview）＝ 全体の 12.6%

用語集（検査値9個＋病態4個）＝ 累積 43.7%

時系列、詳細 ＝ 100%

入口ページに注意を集中させるので、「最初に何を読めばいいかの判断コスト」が消える。同じ量でも、認知負荷は劇的に下がる。これが「圧縮しない要約」の正体。

2. 要約は構造的に物足りない

「もっと良い要約」を頑張っても限界がある。AI に要約させて1年以上感じてきた不満を整理すると、要約自体に構造的な問題がある：

1. 抽象化が経験と切断する — 人間の知識のアンカーは具体側にある。要約は抽象側に偏るので、自分の体験と繋がらない。

2. 書籍は既に抽象化産物 — それを要約すると二重抽象になり、具体からますます遠ざかる。

3. 専門用語を一般語に丸める — 「Cre」を「腎機能の値」と説明すると解像度が落ちる。

4. 「平均的読者」を想定する — あなたの知識境界とはずれる。「もう知ってる」か「全然わからない」のどちらかに落ちる。学習は一歩先でしか起きないのに。

5. ストーリーの配列が壊れる — 要約は「断片自体に価値がある」前提で動くが、経験記や物語の価値は断片の並びにある。

これらは要約という操作の本質にある問題なので、プロンプトを工夫しても根は残る。

3. LLM Wiki は構造で答える

LLM Wiki はこれらに対して構造で答える。

抽象化での切断 → concept ページから raw/ への着地パスを残す。元データに戻れる。

専門用語の喪失 → 用語ごとに concept ページを立て、原型のまま保持する。

ストーリーの破壊 → wiki と並行して raw/ を温存。ナラティブは raw 側で残る。

平均読者ずれ → 既存の wiki 群そのものが「あなたの知識マップ」になっている。新規 ingest はそこに接続される。「一歩先」を狙いやすい。

要約を「上手にする」のではなく、要約とは別の層をいくつか並べる。そのぶん容量は減らないが、層ごとに違う用途を担う。

4. 蓄積する

要約は1回ごとに使い捨て。LLM Wiki は続く。

100ページ目を ingest する時、AI は既存の99ページと結びつく箇所を探す。新概念は既存リンク網に編み込まれ、関連が再発見される。これが compounding。要約を100回別々に作っても起きない現象。

違いの要約（皮肉）

「AI要約の物足りなさ」を解決するために AI要約を改良しようとしても、構造的にぶつかる壁がある。LLM Wiki は別の方角から答えを出している。