AIに「それは pay-as-you-go だ」と言われて、手探りで組んだ知識管理の仕組みが21年前の論文と同じだと知った
ここ3週間、自分のSNS投稿など過去のデジタルデータをAIに整理させる個人的な仕組みを動かしている。16年ぶんの雑多なテキストを一箇所に積んで、事前には整理せず、必要になったときにAIエージェントが掘りに行く。掘った成果だけを薄く蒸留して残す。その蒸留物が溜まると、次に掘るのが速く正確になる。それだけの仕組み。
きっかけは論文でなく、AIとの会話。大量のテキストから、あとで効くかもしれない主張(claim)を全部あらかじめ抜き出させておくのは無駄では、と思っていた。自分の仕組みでやっている「必要になってから掘る」を引き合いに、AIと詰めていた。するとAIが、本当のコストはテキストの量ではなく、意味づけをどこまで広く張るか（掘る面積）のほうだと指摘して、その上で「その賭け方には名前があって、pay-as-you-go、2005年の論文で確立している」と言った。自分が手の感触で組んでいたものに名前があって、その名前が21年前のもの。データベースの研究者ではないし、この分野を追ってきたわけでもない。名前を教わってから元をたどって、気になったことを記録しておく。
pay-as-you-go という考え方
教わった大本は2005年に Franklin・Halevy・Maier が出した構想（“From Databases to Dataspaces: A New Abstraction for Information Management”, SIGMOD Record 2005）。異質なデータ源を、事前に一つのスキーマへ統合しないまま共存させる。統合は必要になった分だけ後から足していく。この後払いを pay-as-you-go と呼ぶ。元々あった言い回しを、データ統合に転用したのが彼ら。名前を手がかりに読むと、後にこれを実装した論文がいくつも出てきて、どれも出典としてこれを指していた。2007年には Google も同じ発想のシステムを作って PAYGO と名付けている（CIDR 2007）。ただし、その PAYGO という名前もその後は残らなかった。
この原理を、自分は二部構成として読んだ。2005年と2006年の二本の論文にまたがって、二つのことが書いてある。一つ目は先送り。統合の労働集約的な部分は、本当に必要になるまで先送りする。全部を最初に片付けようとしない。これは翌年の続きの論文（Principles of Dataspace Systems、PODS 2006）に書いてある。二つ目は “incremental payoff for incremental investment”。こちらは先の2005年の論文のほう。払った分がそのまま資産として積み上がって、次からの手間が減る。先送りするだけでなく、一度払った統合を記録して二度払いを避ける。この二つ目が、ただの「あとでやる」と決定的に違うところ。ただし、原文にあるのは “incremental payoff for incremental investment” の一句だけで、「記録して二度払いを避ける」「帳簿」と読んだのは自分の言い換え。投資が積み上がって次に効く、と言う以上、払った統合は捨てずに残って再利用される、が含まれている、と取った。この二つを「二部構成」と束ねているのも自分の読みで、彼らがそう並べて書いたわけではない。
自分の仕組みで言えば、一つ目が「事前に整理しない・掘るときだけ掘る」に当たり、二つ目が「掘った成果を蒸留して残す・次から速くなる」に当たる。設計するときにこの論文は知らなかった。知らないまま同じ二部構成に行き着いていた。
pay-as-you-go は名前を変えて生き残った
この二部構成の片方だけが、その後ずっと出世した。
「事前に統合しない・必要になってから解釈する」という先送りのほうは、その後も別の名前で何度も現れる。データベースの外では schema-on-read。読むときにはじめて構造を当てはめて、書くときは生のまま置く。そして data lake。ただし data lake は dataspaces の子孫ではない。この語を2010年に作った James Dixonは、dataspaces にも pay-as-you-go にも触れていない。産業の側が、独立に同じ先送りの構造へ行き着いただけ。血筋ではなく、二部構成の片方（先送り）だけをたまたま共有している。残りの半分（帳簿）は受け継いでいない。面白いことに、dataspaces を出した Halevy 本人は、後に Google で巨大なデータレイクの管理（GOODS, 2016）に移っていて、やっているのは生の湖(lake)にカタログを足すこと。欠けた半分を、後から別の名前の場所に持ち込んでいる。名前は別々に生まれて、人だけが地続き。いま自分がテキストを積んでいる置き場も、自分で「lake」と呼んでいる。勝った側の語彙で自分のディレクトリに名前を付けていたことに、後から気づいた。
そして今のLLM時代。MicrosoftのLazyGraphRAG という手法がある。事前にグラフを作り込む重い索引を避けて、LLMを使う高価な処理をクエリが来た瞬間まで先送りする。索引のコストは作り込む方式の0.1%、クエリ一回あたりのコストは全体探索の700分の1という数字が出ている。やっているのは、あの先送りそのもの。ただし提案した側はそれを “lazy”（後回し）としか呼んでいない。dataspaces にも pay-as-you-go にも一言も触れていない。
この先送りの半分は、2005年の名前を一度も名乗らないまま、schema-on-read・data lake・lazy と別の名前で何度も現れて残った。一方 “dataspaces” という元の名前のほうは、いま検索すると別のもの（欧州のデータ主権の枠組みで、綴りは “data spaces” と二語）にほぼ覆われていて、元の意味ではもう出てこない。名前は死んで、中身だけが別名で続いている。
incremental payoff のほうは拾われていない
二つ目、“incremental payoff”。払った統合を記録して二度払いを防ぐ帳簿。こちらは、外に拾われていない。
正確には、構想の内側では実装まで行っている。統合のヒントを一本ずつ溜めるほど、それが効くクエリの品質が上がることを実験で示した論文（VLDB 2007）があり、翌年には人間への確認を溜めて、同じ問いを二度と人間に聞かない設計（SIGMOD 2008）が出た。確認作業の2割で理想状態の95%に届く、という数字も付いている。この線は「ユーザーフィードバックを一級市民に」と掲げた論文（CIDR 2011）を経て英マンチェスター大の系譜で2021年ごろまで続いた。それでも、外には出ていない。これらを引いた産業の製品は見当たらない。名寄せの裁定を記録して残す機構そのものなら、産業にも昔からある。MDM(master data management)の照合履歴がそれ。ただしあれは全部を先に統合してから使う、前払いの世界の道具。「必要な分だけ払う」と「払った分を帳簿に残す」を一つに束ねた形は、研究の中で動いたきりになっている。
さっきの data lake が、しばしば data swamp（沼）と呼ばれて使い物にならなくなるのも、これと同じ。先送りだけして帳簿を持たないと、貯めたものがどこにあるか分からなくなって、二度と引き出せない。先送りの半分は勝ったが、帳簿の半分を欠いた形が、いちばん人が使う場所でそのまま沼になっている。
いまのRAGの素の形も、この帳簿の否定形になっている。クエリが来るたびに、毎回まっさらから全額を払い直す。前回どのクエリで何を解決したかを覚えていない。同じ表記揺れに毎回振り回される。人名の表記の揺れ、同じものを指す別の言葉。こういう名寄せは実は2013年ごろのデータ統合の研究でも未解決のまま話題になっていて、それがRAGの内側でそっくり再演している。系譜の自覚がないまま。
LazyGraphRAG も、後払いという片方は綺麗にやっているのに、クエリのときに払った解釈をどこにも保存しない。使い捨て。しかも今後の方向として挙げているのが「先回りで抽出しておく」＝前払いへの回帰で、「後回しに抽出する、ただし捨てない」という第三の選択肢が視界に入っていない。
2026年に出た CacheRAG は、もう少し近いところまで来ている。動機の文で「既存のやり方はステートレスに動作し、各クエリを独立に扱い、過去のパターンから学ばない」と、毎回払い直しへの批判そのものを掲げている。ただ、その蓄積は自動のキャッシュ。人間が良し悪しを裁く手続きも、後から中身を検証できる作りも無い。帳簿の一番大事なところ、つまり「何を資産として認めるかを裁いて、記録を後から追える形で残す」が抜けている。
「ステートレスは駄目だ」という認識には、研究の側がもう到達している。帳簿の周りは埋まりはじめている。ただ、帳簿そのものの席はまだ空いている。
自分の仕組みが埋めているのは帳簿の側
3週間動かしている仕組みで、実際に賢くなっているのは帳簿の部分だと思う。
掘るたびに、掘った成果を蒸留物として残す。人名や用語の揺れをどう解決したか、どの情報源をどう評価したか。それを版管理された台帳に書いて、相互にリンクを張る。次に近いことを掘るとき、この蒸留物が効いて、二度目は払わずに済む。しかも何を残すかは自分が裁く。自動で溜まる履歴ではなく、採否を人間が決めて、決めた記録が後から読める形になっている。
蓄積が効くのは、二度目に払わずに済む速さだけではない。溜まった帳簿を掘り返すと、自分の記憶では引き出せないものが出てくる。前に一度、この索引に自分の昔の書き物をまとめて掘らせて、自分でも言葉にできていなかった生涯の負けパターンを一つ掘り当てたことがある（別稿に書いた）。蓄積があるから発掘が効いて、発掘するたびにまた蓄積が増える。この往復が回りはじめるところまでが、帳簿の見返り。
先送り（掘るときだけ掘る）と、蓄積（払った分を帳簿に残す）と、その蓄積に何を載せるかの裁定。この三つを一度に持っている仕組みを、探した範囲では見つけられなかった。後払いはLazyGraphRAGにあり、自動の蓄積はいわゆるメモリ機能にあるけれど、あれは裁定が無く人間から見えない。裁定まで込みの帳簿は、どこにも無い。
もっとも、これはうまくいっている一例が手元に一つあるという話でしかない。評価実験をしたわけではないし、他人が同じ形で回して同じ果実を得られるかは分からない。N=1の話。ただ、その一つが、20年ほど前の論文が二部構成で言っていたことの、片割れをそのまま動かしている。
2005年の構想が言い当てていた二つ
並べてみると、こういう形になる。2005年のあの構想（と、それを受けた一連の論文）は、二つを言い当てていた。一つは後払い。これは別の名前で何度も現れて残った。もう一つは帳簿。これは実装までされたのに、拾われなかった。自分の仕組みがいま埋めているのは、その拾われていないほう。
完璧に統合してから使う、ではなく、必要な分だけ払って果実を得る。この原理は、情報の量がいくら増えても全部を先に片付けようとする開発の病から抜ける道でもある。過去に二度、「全部整理」から始めて力尽きた。だから今度は整理しないと決めた。同じ結論が、20年ほど前の構想に書いてあった。当時これは主役になれなかったほう。その負けたほうが、半分は正しかった。
帳簿の席がなぜ空いたままなのか、埋まりつつある周りがいつ席そのものに届くのかは、まだ分からない。答え合わせはこれから。その前に、自分の埋めた半分がどこまで動くかを、もう少し見てみる。