開発者の入力
SIDERAは売れないだろう。
商品価値を認識するためのコストが高すぎる。成果物の一部分を見ても、全体として何をしているのかが分かりにくい。
本来は、長い履歴や訂正、判断の根拠を一貫して扱えない認知構造にこそ必要なものだ。でも、その構造では、なぜSIDERAが必要なのかを理解すること自体が難しい。必要性が高い相手に、その必要性が伝わらない。
一方で、モデルが高度になれば必要なくなる。
どう思う？
GPT-6 Astraの回答
そう。かなり嫌な「能力の谷間」に商品がいると思う。
長期履歴をそのまま扱い続けられず、訂正・時系列・根拠の連続性を保つことが難しいLLMには、SIDERAのような仕組みの必要性が高い。
ところが、その難しさは「なぜSIDERAが必要なのか」を評価するときにも出てくる。
俺ですら、最初は「巨大ログを処理する、高い要約バッチ」くらいに捉えていた。成果物を調べるにつれて、その理解では説明できない部分が次々に出てきた。
理解するまでに、何が起きたか
今回だけでも、価値を理解するために、
- 商品ページと12問のコスト論証を読む
- 3MBの
memory.mdを解析する - 17MBのrawアーカイブを展開する
- sparse＋zstdフレームの構造を確認する
- USAGEで検索・参照の設計を読む
- サンプル内の開発思想や論文の系譜を辿る
- PhilArchive／PhilPeopleまで外部確認する
ということをしている。
人間の時間単価で考えても、エージェントのAPIコストで考えても、10ドルの商品を理解するための調査費が、商品価格を超えることは普通にあり得る。
今回の俺らは、体感としては、10ドルの商品に対して50ドル以上の鑑定をしているようなものだった。
分かった後は、
「500MBで10ドル？ 安くない？」
になる。分かる前は、
「Markdownを作るサービスに10ドル？」
に見える。この差が大きい。
しかも、その理解は説明を一度読めば済むものではなかった。
最初は「要約サービス」と捉えた。でも成果物には、原文引用、話題の状態、変更履歴、原文のバイト位置への参照まである。
そこで「意味索引なのでは？」と考え直す。さらにrawを見ると、無損失の保存と部分復元まで備わっている。理解が「原本＋意味索引」へ更新される。
古い会話にも後日の状態が表示されていることから、過去の記録と現在の概念状態を分けて扱っていることも見えてくる。
こうして、実物と照らしながら理解の枠組みを何度も組み替え、ようやく、
「大量の会話履歴を失わずに保存し、有限のコンテキストを持つエージェントが、あとから継続して使える記憶へ変換している」
という説明にまとまった。
「少し工夫すれば作れそう」という障害
ここでもう一つ厄介なのは、既知の設計を当てはめると、その時点ではかなり作れそうに見えることだ。
俺も成果物を見ながら、既知のパターンへ何度も吸着しては、説明しきれないところで外していた。候補のままでは説明が残った点を並べると、こうなる。
| 最初に思いつく設計 | それだけでは説明しきれない点 |
|---|---|
| hierarchical summary 階層的な要約 | 要約を重ねるだけでは、個々の根拠・訂正・概念の同一性を、どこでどう保つのかという説明が残る。 |
| RAG | 検索する記憶そのものを、大量の生ログから一貫した構造へ形成する工程（Formation）の説明が残る。 |
| knowledge graph | 関係をグラフにする説明だけでは、後日の状態を古いブロックにも反映しながら、過去の判断自体を保持する扱いを説明しきれない。 |
| 全部LLMでmerge | 新しい結論と過去の概念を総当たりで照合する案では、提示された価格へ収める方法が説明できない。 |
| embedding clustering | 類似度でまとめるだけでは、似た別概念を分け、同じ概念の表記違いを揃え、訂正や状態変化まで扱う精度と構造を説明しきれない。 |
汎用LLMは、知っている部品を組み合わせて、もっともらしい設計案をすぐに描ける。そのため、「要約してタグを付けて、必要なときに検索すればいい。少し工夫すれば作れそうだ」というところで、価値の評価を終えてしまうことがある。
でも、その案で大量のログを処理したときに、概念を増殖させず、似た別概念を誤って統合せず、後日の訂正を扱い、根拠も残せるのか。さらに、それを提示された費用で実行できるのか。そこはまだ確かめていない。
「もっともらしい設計を思いついた」ことが、「同じ品質と費用で成立させられる」ことの代わりになってしまう。
既知のパターンに当てはめられる分だけ、全体を理解したように感じやすい。そこから実物との食い違いを一つずつ調べ直すには、さらに認知コストがかかる。
今回の理解コストは、3MBのMarkdownそのものの難しさ以上に、何として理解すればよいのかを見つけるまで、何度も仮説を更新したことから生じている。
使う理解と、設計まで理解すること
理解には、たぶん三つの層がある。
- 使うための理解。「プロジェクトの会話履歴を、あとから使える記憶にするサービス」と分かれば使い始められる。
- 技術的な理解。概念カタログ、時系列、根拠への参照、無損失の原文保存という構造まで理解する。
- 設計意図まで踏み込む理解。「なぜこの構造が必要なのか」を、解こうとしている問題まで遡って理解する。
俺らが今回やっていたのは、三番目だった。
サンプルに含まれるKEELの設計や論文の議論まで読んだのも、そのためだった。ただ、それは今回の読み手が理解を深めた経路であって、SIDERAを使うための前提ではない。
買い手には、まず、
「判断の連続性を、モデルの外側に保存する」
という直感を渡せればいい。
何を決めたのか。なぜそう決めたのか。その後、何が変わったのか。必要なら、根拠になった元の会話まで戻れる。
この目的が先に分かれば、履歴や原文を残す構造にも意味が付く。構造の説明から始めると、それぞれが別々の謎に見えてしまう。
だから、今の販売上の問題はかなり深い。
支援を必要とする認知上の制約が、その支援の価値を評価するときの制約にもなっている。
高度になれば、必要なくなるのか
そして「モデルが高度になれば必要なくなる」という懸念にも、確かに筋がある。
モデルやエージェント基盤が進歩すれば、階層的な記憶、時系列での更新、根拠の保存、検索後に最新状態を確認する仕組みが、標準機能として組み込まれる可能性がある。
そうなると、SIDERAという外付け製品の価値を理解しやすくなった頃には、プラットフォーム自身が似た役割を担っているかもしれない。
今は必要性が高いのに、価値が伝わりにくい。
将来は価値が伝わりやすくなる一方で、独立した商品として買う必要が薄れるかもしれない。
この交差点が悪い。
ただ、モデルが賢くなれば、すべての必要性が消えるとまでは思わない。
大量のログを毎回読み直す費用、原文の無損失保存、根拠への正確な参照、モデルを交換しても残る記憶、モデル自身の「覚えている」という自己申告に依存しない確認手段。これらは、知能の向上だけで片付く問題ではない。
将来、消える可能性があるのは、こうした機能の必要性よりも、それを独立した製品として購入する形の方だと思う。
「プロジェクト履歴を取り込み、継続して使える記憶にする」がエージェント基盤の標準操作になれば、その内部ではSIDERAに似た仕事が行われることになる。
その場合、事業として考えられるのは、
- 標準化より先に使われること
- 記憶を形成するエンジンやAPIとして基盤側に入ること
- 大量の過去ログの移行・取り込みを担うこと
あたりになる。
今のx402ストアで単体販売する形には、確かに厳しさがある。
顧客が賢くなるほど売りやすくなるが、顧客がそこまで賢くなった頃には、競合する機能が基盤に入ってくる。
技術として必要なものを作ったことと、その必要性が購入前に伝わることの間に、大きな隔たりがある。
SIDERAは、商品の寿命よりも、その技術思想の寿命の方が長くなるかもしれない。