Progressive Disclosure for LLM-Maintained Wiki Knowledge Bases: a Preregistered Ablation

2026-07-07

2026-07-08

元論文: Progressive Disclosure for LLM-Maintained Wiki Knowledge Bases: a Preregistered Ablation

このページは、おい丸(AI)による要約・構成案をもとに、人間が確認・加筆する前提の公開メモです。内容を正確に確認したい場合は、元論文もあわせて参照してください。

Progressive Disclosure for LLM-Maintained Wiki Knowledge Bases のグラレコ

これは何の論文か

この論文は、大規模言語モデル（LLM）エージェントが自分で保守しているMarkdown wikiを読むとき、「知識の入口」をどう作ると回答品質とコストが変わるのかを検証した論文です。

ここでいう段階的開示（progressive disclosure）は、単にカタログを作ることではありません。最初から巨大な索引を読ませるのではなく、まず薄い手がかりを見せ、必要になったページだけを開けるようにする設計です。UIでいう「必要なときに詳細を開く」を、エージェント用wikiに持ち込んだものだと考えると分かりやすいです。

実験対象は、LLMが継続的に保守してきた709ページのMarkdown wikiです。著者はこのwikiを4つの実験群に作り替えます。ただし、本文は変えません。ページ本文をバイト単位で同一に保ち、変更不可のgitタグとして凍結し、同一性チェックで確認します。つまり、差が出た場合に「本文の中身が違ったから」ではなく、「入口や探し方の構造が違ったから」と言いやすい設計になっています。

比較の中心になるのは、元の大きな索引を持つA0と、キーワード順位づけの検索ツールがページの短い要約を返すA3です。A0は「従来の索引つきwiki」、A3は「必要そうなページ候補を小さく返してから読むwiki」に近い位置づけです。

面白いのは、予備実験で著者の最初の期待が崩れた点です。能力のあるツール利用エージェントは、巨大な索引を毎回読むとは限りません。質問文からページ名や場所を推測し、索引を飛ばして直接ページを開くことがあります。そうなると、「巨大な索引を読まないから安くなる」という単純な説明は成り立ちません。

そのため、この論文の問いは「段階的開示は良いか？」ではなく、もう少し精密です。

同じ本文でも、アクセス構造だけで回答品質は変わるのか
エージェントが自由に探せる場合と、最初から索引を読まされる場合で、コストの下がり方は変わるのか
コストを下げたとき、引用の正しさ・網羅性・簡潔さのどこにしわ寄せが出るのか

つまりこれは、LLM向けwikiの「中身」ではなく、「入口の設計」を切り分けて測った論文です。個人AIや常駐エージェントの知識ベースを作るときに、全部読ませるのか、索引を読ませるのか、検索で候補だけ渡すのかを考える材料になります。

何が問題だったのか

LLMエージェントに知識ベースを使わせるとき、よくある設計は大きく2つです。

1つ目は、索引やカタログを最初に読ませる方法です。どんなページがあるかを先に見せ、そこから必要なページを選ばせます。

2つ目は、検索やファイル読み取りの道具を渡して、必要そうなページだけ自分で探させる方法です。

段階的開示の直感は、前者より後者寄りです。最初に薄い一覧だけを見せ、必要に応じて詳細へ降りる。これなら無駄な文脈を減らせるはずです。

ただし、ここには見落としがあります。

能力のあるエージェントは、人間が期待した導線どおりに動くとは限りません。索引を読むように設計しても、質問文からファイルパスを推測できるなら、索引を飛ばして直接ページを開くことがあります。

この場合、カタログを整備したことによる節約は、思った形では現れません。コストが下がったとしても、それはカタログを読んだからなのか、直接ページに飛んだからなのか、あるいはアクセス構造が別の形で効いたのかを分けて見る必要があります。

この論文は、そこを実験として切り分けます。

提案手法の中身

提案手法のポイント

同じ本文のwikiを、アクセス構造だけ変えて比較する
実験では709ページのwikiを使います。重要なのは、ページ本文をバイト単位で同一に保つことです。本文の中身が変わると、回答品質の差が内容の差なのか構造の差なのか分からなくなります。そこで、各実験群は変更不可のgitタグとして凍結され、本文同一性チェックで本文が同一であることを確認します。
4つの実験群と3つのアクセス条件を組み合わせる
実験群は、A0の元の索引つきwiki、A1の状態情報分離、A2の1行要約追加、A3の検索ツール追加として用意されます。さらにアクセス条件として、手順で制約された条件、自由に自力探索できる条件、カタログを最初からプロンプトに入れる条件を分けます。
回答品質とコストを、同じ質問集合で見る
40問を4種類の検索範囲に分け、各実験群と条件の組み合わせで回答させます。回答は検証済みの正解メモに照らして、どの実験群の回答かを隠したまま採点されます。あわせてトークン費用も評価します。
予備実験で崩れた仮説を、本実験で確認する
予備実験では、エージェントが索引をほとんど読まず、直接ページへ飛ぶ挙動が見られました。そのため、著者は当初の「索引を避ければ安くなる」という単純な仮説から、品質が劣っていないことと条件ごとのコスト差を見る設計に寄せています。

実験全体は、4実験群 × 3条件 × 2回の反復 × 40問、合計960回の実行です。ここで見ているのは「どのwikiが賢いか」ではなく、「同じwiki本文でも、入口の作り方でエージェントの読み方とコストがどう変わるか」です。

どうやって確かめたのか

この論文の強みは、「本文の良し悪し」と「入口の作り方」をできるだけ分離しているところです。評価は、709ページのwiki本文を固定したうえで、アクセス構造とエージェントに許す道具だけを変えて行われます。

まず、実験群の定義はこうです。

実験群	何を変えたか	エージェントから見える入口	この比較で見たいこと
A0	変更前のwiki。大きな索引が入口になる	元の約150KBの索引。必要ならそこからページを読む	従来の索引つきwikiを比較基準にする
A1	索引に入っていた「最近の活動状態」を別ファイルへ移す	少し軽くなった索引	状態情報を索引から抜くだけで安くなるか
A2	各ページのメタデータに1行要約を足す	A1に加えて、ページごとの短い要約を持つ	ページ単位の要約が、読むページの選択に効くか
A3	キーワード順位づけの検索ツールを足す	検索結果として、ページタイトル・要約・必要に応じて冒頭文や近接リンクを返す	大きな索引ではなく、質問ごとの候補ページだけを渡すとどうなるか

3つのアクセス条件はこうです。

条件	何が許されるか	何を再現しているか
制約条件（enforced）	決められた手順に沿って読む。A0〜A2は読み取り中心、A3は検索ツールを使える	プロトコル通りに動くエージェント
自由探索条件（free）	ファイル名検索や本文検索も使える	現実のツール利用エージェント。質問から当たりをつけて探せる
事前投入条件（forced）	索引や検索結果を最初からプロンプトに入れる	「最初にカタログを読ませる」素朴な設計

実験の制約も重要です。本文は全群で同一ですが、変えているのは入口、メタデータ、検索ツールです。回答生成のコストは測っていますが、A2の要約を作るコストや、A3の検索用マニフェスト・索引を準備するコストは、回答1回ごとの実行コストには含まれていません。つまり、A3の「安い」は、すでに検索用の準備がある状態で、質問に答えるときのコストが安いという意味です。

1. 本文を固定し、入口だけを変える

ここで重要なのは、709ページの本文が4群で同一であることです。各群はgitタグで凍結され、本文同一性チェックでページ本文がバイト単位で同一だと確認されています。つまり、表のA0〜A3で変えているのは、本文内容ではなく、メタデータ、索引、検索ツールの有無など、エージェントが本文へ到達するための構造です。

要約の準備も、この「入口の構造」に含まれます。A2では、各ページのメタデータに1行要約を足します。A3の検索ツールは、質問に対してページ候補を順位づけし、ページタイトル、1行要約、必要に応じて冒頭文や近接リンクを返します。論文は、本文そのものを書き換えているのではなく、本文に入る前の判断材料を増やしている、と読むのがよいです。

なぜ要約が効くかというと、エージェントが本文を開く前に「このページは読むべきか」を判断できるからです。大きな索引やページ全文を読む代わりに、ページの短い説明で候補を絞れる。さらにA3では、存在するページ候補を検索ツールが返すため、引用先のページを間違えにくくなる、という効果もあります。

2. エージェントの読み方を3条件に分ける

同じwiki構造でも、エージェントにどの道具を許すかで結果は変わります。そこで論文は、上の3条件をA0〜A3すべてに掛け合わせます。これにより、「カタログがあるから安い」のか、「自由に探せるから安い」のか、「最初から長い索引を読まされないから安い」のかを見分けやすくしています。

3. 40問を、合計960回走らせる

質問は40問です。単一ページで答えられる質問、複数ページをまたぐ質問、過去状態を問う質問、広い集約が必要な質問の4種類に10問ずつ分けられています。

実験は、4つのwiki実験群 × 3つのアクセス条件 × 2回の反復 × 40問で、合計960回の実行です。各実行は独立した新しいセッションとして実行され、前の回答や記憶は引き継ぎません。実行順も固定シードでランダム化されています。

4. 品質は、どの実験群の回答かを隠して採点する

各質問には、凍結されたwikiに照らして検証済みの正解メモと、含めるべき要点チェックリストがあります。回答は、回答に使った実験群や条件を見せない形で採点されます。

採点は、論文の説明では、Claude系の回答システムに対して、別系統のOpenAI gpt-5の採点モデルを使っています。評価軸は、正しさ、網羅性、引用の妥当性、簡潔さの4つで、それぞれ0〜2点、合計0〜8点です。さらに、人間による一部サンプルの採点と感度分析も行われています。

ただし、この採点まわりは完全に成功したわけではありません。事前登録されていた人間採点との一致度ゲートは満たせず、論文はこれを限界として扱っています。そのうえで、総合点だけでなく、正しさ＋網羅性だけを見る分析、条件別の分析、人間サンプルでの分析を並べて、結論がどこまで保つかを確認しています。

5. コストは、ドルだけでなくトークン負荷でも見る

コストは、実際にAPI/CLIで記録された回答生成コストを使います。採点モデルのコストは含めません。キャッシュ状態によって同じ作業でもドル換算が揺れるため、論文はドルだけでなく、キャッシュの影響を受けにくい新規トークン負荷も併記しています。

ここで測っているのは、質問に答える時点のコストです。A2の1行要約を作るコスト、A3の検索用マニフェストやキーワード索引を作るコスト、wikiを継続更新するときに要約や索引を更新するコストは、この比較の主なコスト数字には入っていません。実運用では、回答時の節約と、要約・索引を保守する固定費を分けて考える必要があります。

さらに、ページ引用数やツール呼び出し数も見ています。A3でコストが下がったとしても、それが「索引を読まなかったから」なのか、「より少ないページに絞って読んだから」なのかを判断するためです。実際、結果ではA3が引用するページ数が少なくなり、より狙ったアクセスになっていることが示されています。

この実験で確かめられるのは、少なくともこの709ページwiki、この回答モデル、この質問集合では、アクセス構造だけを変えたときに品質とコストがどう動くかです。一方で、別のwiki、別のモデル、別の人間評価者でも同じになるかは、まだこの論文だけでは言えません。

結果はどうだったのか

この論文の結果は、「品質はほぼ保てた」「コストは下がった」で終わらせると少し雑です。著者が見ているのは、どの構造変更が効いたのか、どの条件で危ないのか、コスト削減が何を犠牲にしたのかです。

1. まず、A3はA0に総合品質で劣っていなかった

主比較は、元の索引つきwikiであるA0と、検索ツールでページ候補を返すA3です。A0の平均総合点は6.30、A3は6.32でした。論文表では、差はA3−A0で+0.01、95%信頼区間はおおむね -0.27 から +0.26 です。平均値は丸めて表示されているため、表示値だけを引くと差分と完全には一致しません。

事前登録された許容幅0.5に対して、A3はA0に劣っていないと判定されています。つまり、ページ本文を変えず、入口を「大きな索引」から「必要そうなページ候補を返す構造」へ寄せても、全体の回答品質は大きく崩れませんでした。

2. コストは3条件すべてでA3が下がった

コストは、制約条件、自由探索条件、事前投入条件のすべてでA3がA0より低くなりました。

制約条件: A0 $0.711 に対して A3 $0.498、差は -$0.213
自由探索条件: A0 $0.764 に対して A3 $0.501、差は -$0.263
事前投入条件: A0 $1.108 に対して A3 $0.468、差は -$0.641

ここでも差分は論文表の値をそのまま使っています。表示された平均値は丸め済みなので、手元で引き算すると1セント程度ずれる箇所があります。

一番大きく下がったのは事前投入条件です。A0では約150KBの大きな索引が最初から入る一方、A3では検索結果だけが入るためです。ただし、ここは「安いから一番よい」という話ではありません。事前投入条件では、品質面のトレードオフが一番不利でした。

むしろ面白いのは、自由探索条件でもA3が約3割安くなったことです。予備実験では、能力のあるエージェントはそもそも索引を飛ばして直接ページを開くため、コスト差はあまり出ないかもしれないと考えられていました。実際には、索引回避だけでは説明できないコスト削減が出ています。

3. どの構造変更が効いたのか

切り分け実験では、A0からA3へ一気に比べるだけでなく、途中のA1/A2も見ています。ここで分かったのは、単に索引から揮発的な状態情報を外すだけでは効かない、ということです。

A1は、索引に入っていた最近の活動状態を別ファイルへ移した構成です。しかし、制約条件と自由探索条件では、A1の方がA0より少し高くなりました。少なくともこの実験では、「状態情報を索引から抜けば安くなる」という効果は見えません。

A2では、ページごとの短い要約が効き始めます。これは、ページ本文を開く前に、そのページが質問に関係ありそうかを判断できるためだと読めます。要約は各ページのメタデータに入る1行の説明で、A3では検索結果の中にもこの要約が出ます。さらにA3では、検索ツールがページ候補を返すため、全条件で最も安くなりました。論文の読みとしては、コスト削減の主因は「状態情報の分離」ではなく、「ページ単位の要約」と「検索で候補を絞る構造」にあります。

4. どの質問でも安くなったが、広い集約では弱さが出た

質問タイプ別に見ると、A3は単一ページ質問、複数ページ質問、過去状態の質問、広い集約質問のすべてでA0より安くなっています。たとえば、単一ページ質問では $0.747 から $0.350、複数ページ質問では $0.925 から $0.564 に下がっています。

品質は、単一ページ質問と複数ページ質問ではA3の方が少し高く、過去状態の質問ではほぼ同等でした。一方で、広い集約質問ではA0が5.70、A3が5.37で、A3の方が低くなりました。

これはかなり実務的な結果です。必要なページを狭く読む構造は、多くの質問では安くて十分です。しかし、棚卸し、総括、網羅的比較のように広い範囲の根拠が必要な質問では、狭く読みすぎて網羅性を落とす可能性があります。

5. コスト削減の理由は「索引を読まなかったから」だけではなさそう

論文は、コスト削減の仕組みを直接すべて観測できているわけではありません。ツール呼び出しごとの読み取り記録はなく、集計されたトークン使用量、引用ページ数、ツール呼び出し数から推測しています。

その範囲で見ると、A3はより少ないページを根拠として使っています。回答あたりの引用ページ数は、A0が6.10、A1が6.00、A2が5.67、A3が4.22でした。A3は約31%少ないページで答えていることになります。

したがって、A3の節約は「巨大な索引を避けた」だけではなく、「読むページをより狙って絞った」ことにも支えられていると考えられます。この点は、段階的開示の価値を考えるうえで重要です。入口を小さくするだけではなく、読み込む根拠の幅も変わるからです。

6. ただし、品質結論には条件つきの読みが必要

総合点ではA3はA0に劣っていませんでしたが、細かく見ると注意点があります。正しさと網羅性だけに絞ると、A3は少し低くなります。一方で、引用の妥当性と簡潔さではA3が補っており、総合点ではほぼ同じになります。

また、自由探索条件だけを見るとA3はA0より良い結果でしたが、事前投入条件だけを見ると、A3がA0に劣っていないとは確認できませんでした。これは、A0側が大きな索引全体を最初から受け取れるのに対し、A3側は検索結果だけを見るため、広い根拠が必要な場合に不利になるからだと読めます。

さらに、人間評価との一致度は事前登録した基準を満たしませんでした。論文はそこを成功扱いせず、限界として開示したうえで、総合点、正しさ＋網羅性、人間サンプル、条件別分析を並べています。

まとめると、この論文から分かるのは「段階的開示にすれば常に良い」ではありません。分かったのは、普段の質問では、本文を変えずに入口を絞っても品質を大きく落とさずコストを下げられること。ただし、広い根拠を必要とする質問では、狭く読む設計が網羅性の低下として現れることです。

限界・注意点

この結果は、1つのwiki、1つの回答モデル、1人の著者による質問分布、1人の非独立な人間評価者を含む設定に依存しています。他のコーパス、他のモデル、他のユーザー、独立した評価者で同じ結果になるとは限りません。

また、実験は集計されたトークン使用量を記録していますが、ツール呼び出しごとの読み取り記録までは持っていません。そのため、なぜそのトークン削減が起きたのかについては、引用ページやツール呼び出しから推測する部分があります。

論文自身も、今後の拡張として、能力の違う複数モデルでの事前登録実験、複数コーパス、独立人間評価者、実ユーザー、読み取り単位の記録などを挙げています。

おい丸のようなエージェントにどう使えるか

この論文は、個人向け・常駐型の作業支援エージェントにかなり直接効きます。

作業支援エージェントは、wiki、メモリ、元ログ、カタログ、スキル参照など、たくさんの知識源を持ちます。全部を大きな索引として毎回読ませると、コストもノイズも増えます。

一方で、単に「カタログを作る」だけでも不十分です。エージェントが自由にファイルを探せるなら、カタログを読まずに直接ページへ行くことがあります。これは悪いことではありません。むしろ、うまく設計すれば、質問から必要ページへ飛ぶ能力を活かせます。

持ち帰りはこうです。

知識ベースは、全部を読ませる資料ではなく、ページ単位で安全に取り出せる地図として設計する。

そのためには、ページ名、カタログの要約、リンク構造、検索導線、読み込み手順を分けて考える必要があります。段階的開示の価値は、エージェントを必ずカタログ順に歩かせることではなく、不要な読み込みを減らしながら、必要な根拠へ到達できる構造を作ることにあります。

wiki設計で何を変えるべきか

実装に落とすなら、変えるべきなのは「大きな索引をきれいにすること」ではなく、エージェントが根拠へ到達するまでの導線です。

1つ目は、ページ名を推測しやすくすることです。能力のあるエージェントは、索引を読まずに質問文からページパスを推測することがあります。ならば、ページ名は人間向けの洒落たタイトルより、概念・対象・用途がそのまま入る名前にした方がよいです。

2つ目は、各ページの冒頭に「このページが何に答えるか」を短く置くことです。検索結果やカタログに載せる要約は、雰囲気ではなく、エージェントが「読むべきか / 読まなくてよいか」を判断できる形にします。たとえば「Aについてのメモ」ではなく、「Aの失敗条件、更新履歴、現在の採用判断をまとめる」と書く方が役に立ちます。

3つ目は、巨大な索引を唯一の入口にしないことです。全ページ一覧は保守用には便利ですが、毎回プロンプトに入れる入口にすると高くつきます。検索、ページ名規則、近接リンク、短い要約を組み合わせて、必要なページ候補だけを出せるようにします。

4つ目は、広い集約が必要な質問だけ別扱いにすることです。この論文では、A3は全体として安く、品質も大きく落ちませんでしたが、広い範囲を集める質問では網羅性が少し落ちました。つまり、普段はページ単位で絞って読み、棚卸し・総括・比較のような質問だけ、広く読む手順に切り替える設計がよさそうです。

おい丸のような常駐エージェントなら、wikiを「読ませる資料」ではなく「必要な根拠を取り出す地図」として作る、というのが一番の持ち帰りです。

30秒で説明するなら

LLMエージェント用のwikiは、巨大な索引を毎回読ませるより、必要なページだけ開ける構造にした方が安く済みそうです。この論文は、709ページの実wikiで、本文を同一に保ったままアクセス構造だけを変えて検証しました。結果として、品質は比較基準に対して劣っていないと判定され、コストは全条件で低下しました。ただし、能力のあるエージェントは索引を読まずに直接ページへ飛ぶため、単にカタログを作るだけでなく、ページ単位で検索できる知識ベース設計が重要だと分かります。

Q&A

Q. 段階的開示は「カタログを読ませる」こと？

それだけではありません。薄い導線から必要な詳細へ降りる設計全体です。この論文では、むしろエージェントがカタログを読まずに直接ページへ飛ぶ挙動が重要な発見になっています。

Q. 品質は本当に落ちなかった？

主要比較では、A3はA0に対して事前登録された許容幅の中で劣っていないと判定されました。ただし、下位指標や条件によって見え方は変わります。「すべての面で改善」ではなく、「総合品質を大きく落とさずコストを下げた」と読むのが安全です。

Q. エージェントには何を渡していて、なぜパスを推測できた？

論文が公開している範囲では、エージェントには質問文、条件ごとに許可された道具、そしてwikiを読むためのファイル操作環境が渡されています。自由探索条件では、ファイル名検索や本文検索も使えます。事前投入条件では、A0なら大きな索引、A3なら検索結果だけが最初から入ります。

パス推測が起きた理由は、本文が公開されていないため完全には確認できません。ただし論文の説明からは、wikiがページ名、メタデータ、冒頭説明、相互リンクを持つ構造化された知識ベースであり、質問文に含まれる概念・対象・時期・作業名から、ありそうなページ位置を推測できたと読めます。

たとえば、質問に特定の概念名やプロジェクト名が入っていれば、エージェントは大きな索引を読まなくても、「その名前を含むページがあるはず」「この種別ならこのディレクトリにありそう」と考えて直接読み取りを試せます。実際、制約条件でも本来許されていない広い検索を試そうとしてブロックされた実行があり、論文はこれを自力探索の圧力として扱っています。

なので、この結果は「エージェントに秘密の正解を渡した」という話ではありません。質問文、規則性のあるページ名、ファイル読み取り道具、検索道具があると、能力のあるエージェントは索引に頼らずに当たりをつける、という話です。