関連

ストーリーは主観的

歴史的事実に基づいていても解釈が混じる

なにが事実で何が解釈か明瞭に分離したい

事実の集合は人間が読むには向かない

ただしAIが読む場合には事実と解釈の明瞭分離されたドキュメントとして有益

事実の間の関係性はたくさんありすぎて一次元の文章で表現困難

ストーリーを作る上ではそれが取捨選択されている

何を「重要」とみなして選択するか、何を捨てるかに人間の価値判断が混じっている

2026-04-26

設計を考えるKarpathyのLLM Wikiを作った connecting-dots-design

ConnectingDotsシステムの設計に関する西尾さんの既存思考(Cosense 2hopダンプ、計18ページ、約1280行)を把握しました。

要旨を一言で言うと: 「点(Dots:検証可能な事実)・線(Stories:キュレーション)・面(Views:表示)」の3層で、自己紹介とPluralityの歴史を同じ仕組みで扱う設計。

「自己紹介ポーカー」が Story の本質を最も簡潔に言語化していた

2026-07-08

ConnectingDotsシステムとKozanebaの融合

Dotsはこざねである

こざね法における「こざねをあつめてホッチキスで止めたもの」がDotを配列したものである

多くの場合、それの配列を直接読者に見せるのではなく、グルーや補足説明が必要

2026-07-29

graspによってあちこちの情報を一括して参照できるようになったことと、Opus5が来たことと、次の週末にデジタル民主主義サミット2026があるので登壇者情報を出さないといけないというアウトプットのニーズによって2026自己紹介ページを更新した

十分な情報が集まった場所(今回はLLM Wikiがgraspで結合されたもの)があれば、自己紹介用のWebページを作るという作業は「切り出し」の一種

「ConnectingDotsシステム」に関する考察は深まったが、現時点での結論は「これに特化したシステムを作る必要はない」

Opus5はこのシステムの設計議論を読んだ上で「LLM Wikiからgraspで情報(=dots)を集めて、そのdotsを並べたstoryのHTMLページを生成」まで一気にやった

Dotsの中には「私に帰属しないもの」がある

国連IGF京都の話が書かれていて何かなと思ったらAudreyがTalk to the Cityを紹介した出来事だった、それは私がやったわけではない

「私に関係ない」かどうかはまた別の話

因果関係はあるが、私が因ではない、という感じか

帰属が明確ならStoryに混ざってても良い

むしろ「自分起因のDotsしかStoryに含めない」とやると、後からStoryを読む人が理解しにくいものになってしまう

2026-07-30

自己紹介ページの更新の過程でDotsとそれをつなげたStoryを作るという行動に関して5件の実例ができた

やっている間に西尾から突っ込まれた経験から「全Dotが真でも繋ぎ目が偽ならStoryは偽」という言語化がされた

事実であるDotを集めて「事実の集合」を作るところまでは問題ない

それを繋いだStoryを作る段階で「事実でないもの」が含まれる可能性がある

AIが想像で間を埋めるのでハルシネーションの可能性がある

またこれはKJ法的に言えば「集めた付箋がなぜ集まっているのかをストーリーにすることで創発が行われる」という捉え方もできる

どちらにせよ、そこで生成されたものの人間によるレビューが必要

自己紹介ページに載せるほどでもないけどStory(=系譜)として出力されたもの

2026-07-30

2026-07-31

現時点で「トップからリンクしてるストーリーに含まれるドット」でないとしても、将来振り返ったときにつながる可能性があるドットに関して、AIのクロールや検索で発見可能な対象として整備されているべき

dots.json # ★AIクロールの一次面: 全Dotのマニフェスト（全フィールド+status+verifiability）

LLM は数百〜数千 Dot なら manifest を読んで推論・grep で足りる。主オーディエンス（未来の後ろ向き接続者＝AI）にはこれが本命。まずこれだけで要件を満たす。

sitemap.xml # 全Dot URLを列挙 → クローラが漏れなく辿れる

llms.txt # 「Dotの一次データは /dots.json」をAIに明示（クロール誘導の作法）

なるほどね〜

この後、Webサイトの自己紹介でStoryを生成した時に使われたDotsを抽出してみる

当初「Dotsを作る、それを並べてStoryを作る」と考えていた

暗黙に「人間がそれを並べてStoryを作る」だった

AIが膨大なデータからDotsの抽出とStory作成までを一気にやったのが今回の自己紹介update

旧プロトタイプにある自己紹介 Dot と今回自己紹介作成にあたってStory生成した結果としてpick upされたDotsとの間にどのような差があるか検討したい

Set A（旧プロトタイプの profile Dot）＝約15件。「最近の活動＋基本経歴」をマイルストーン単位で上から選んだもの（born / 博士 / 入社 / 著書 / 学位 / 理事就任 / 近年のブロードリスニング活動）。

Set B（今回の5 facet Story の Dot）＝約40件（重複除く）。テーマの縦糸を辿った結果、中間・連結の Dot まで湧き出したもの。

つまり A は「プロフィール枠を先に決めて代表イベントを摘む」トップダウン、B は「縦糸を辿って必要な点を掘り出す」ボトムアップ。これが一番効いている差です。縦糸を通すには支える点が要るので、Story 生成そのものが Dot 発見装置になっている（「線を引く行為が点を発見させる」の実証）。

深い差：同じ出来事が Story の高度で別 Dot になる

24歳博士（2006）：A では「博士取得」という経歴マイルストーン Dot。B（highdim）では「球面SOM で高次元遺伝子発現を可視化する研究」＝ベクトル可視化の縦糸の起点として再枠付け。同じ時期でも Story の角度が違えば別 Dot。

word2vec本（2014）：A＝著書 Dot、B-intellectual-production＝著書、B-highdim＝「単語を高次元ベクトルで表現」。1出来事が3つの枠で現れる。

未踏理事（2015）：A＝就任 Dot、B-mentoring＝2015–2025 の期間 Dot（退任込み）。

24歳博士のように「A ではマイルストーン、B では研究の起点」と枠がかなり違う場合、本当に1 Dot＋2 caption で足りるか、それとも event 文言が枠に引きずられて事実部分を切り出しにくいか。

word2vec本（2014）→ 畳める

未踏理事（2015–2025）→ 畳める

24歳博士（2006）→ 畳めない

畳もうとすると event を「博士取得（credential）」にするか「球面SOM研究（research）」にするか選ばされる

さらに mentoring 用の「NAIST で後輩に教える立場に」も同期間の第3の事実。博士期は最低3つの sub-fact の container

未踏の理事も「理事をやっていた期間」と「未踏ジュニアの設立」と「未踏ジュニアのメンター(継続中)」は別factじゃない？

私が間違えた根因は、元の facet Story の <li> 項目「2016年– 未踏ジュニア コファウンダー・メンター」自体が2つの fact を束ねていたこと。

mentoring「ITスクール2004・2005／ICTスクール2006 チューター」＝3回のチューター

分けて語るエピソードがないからまとめといていいんじゃないかな

2026-08-01

Plurality Tokyo 2023が4/14説、4/12説、4/23説があるw

動画にも4/12と書かれているし、当時の僕のスケジューラを確認しても4/12だった

初期設計（2026-03〜04）と実装・deploy後の現実（2026-07-29〜08-01、83 Dot / 7 Story 公開済み）を突き合わせて考察します。

初期設計（3〜4月）の構造論——3層モデル、薄いスキーマ、Dotの再利用性——は驚くほどよく当たった。一方で、「誰が編むのか」と「何が危険なのか」という2つの前提が実装で裏返った。暗黙に「人間がDotを並べてStoryを編む」と想定していたが、実際はAIが抽出から編纂まで一気にやり、人間の仕事は「繋ぎ目の検証」に移動した。そして初期設計が心配していた「選択に混じる価値判断」よりも、設計時に名前すらなかった「繋ぎ目に紛れ込む偽の事実主張」のほうが実害として大きかった。

1. 当たったもの — 構造論はほぼ設計通り

3層構造とスキーマの薄さ。 GPT-5の最小スケッチ（①Dotスキーマを薄く date/refs/entities/verifiability、②Storyは dot_id配列+caption、③Viewは1つだけ、④逆引き自動生成）は、pilot 0.1スキーマと build.py v0 にほぼそのまま実現された。新フィールド追加なしで83 Dotまで走り切り、ビルドツール選定（Q6）はPython stdlibで足りたまま。「Viewsは薄く」は完全に的中した。

Dotの再利用性。 初期設計の核「同じDots採掘場から複数Storyを編む」（自己紹介ポーカー：同じカードから複数の役）は、実装で最も強く実証された。plurality-facet Storyは新規Dotゼロ、既存7 Dotを別captionで再編集しただけで成立し、テーマ間共有Dotは13件。word2vec本（2014）が3つのStoryに別の顔で現れる。「自己紹介と歴史は共通の構造を持つ」も、自己紹介Dotと Plurality史Dotが単一フラットプールに同居して壊れなかったことで裏付けられた。

curator-first。 閲覧者の自由組み換えUIは作らない、という決定は維持された。ただし理由が変わった——「人間キュレーターの完成作品を優先するから」ではなく、「AIが dots.json を丸ごと取得してローカルで読むから、クライアント検索自体が不要」になった。決定は生き残り、根拠が入れ替わった例。

2. 裏返ったもの — 前提の転倒が3つ

(a) 編む主体：人間 → AI。 overview.md のStories行には「人間が編む」と明記されていた。実際に起きたのは、Opus5がgraspでLLM wiki群からDots抽出とStory生成を一気にやる、だった。Scrapboxページの2026-07-31の記述——「暗黙に『人間がそれを並べてStoryを作る』だった」——がこの転倒の自己認識。人間の役割は「編者」から「繋ぎ目のレビュアー」へ移動した。これは初期設計の未決問題「AIによる叩き台生成と人間レビューのワークフロー詳細」が、詳細どころか主客逆転して解決されたということでもある。

3月の段階ではdotsはKozanebaの付箋みたいになって人間が並び替えて(こざね法的に)storyを作るイメージだった、しかしgraspを作り、その後登場したfable, opus5と組み合わせることで「ゼロから並べようとするよりAIが叩き台を作ってレビューで良いのでは」となった。AIの作る叩き台の完成度が高い。

(b) Dotが先か、Storyが先か。 初期設計は「Dotsを作る→並べてStoryを作る」という順序を想定していた。実際にはSet A/Set B比較が示した通り、Storyを編む行為こそがDotの発見装置だった（「線を引く行為が点を発見させる」）。旧プロトタイプのトップダウン15 Dotに対し、テーマの縦糸を辿ったら中間・連結のDotが40件湧き出した。層の順序としては Dots→Stories だが、生成の順序としては Stories→Dots。この非対称は初期設計のどこにも書かれていなかった。

これはKJ法においても「付箋を集めた上でそれをストーリーとして話してみることで言語化が促される」という形で言及されている。関連: 連想接続

(c) 危険の所在：選択 → 繋ぎ目。 初期設計の中心の問いは「何を選び何を捨てるかに価値判断が混じる」で、リスクを選択に見ていた。実装で実際に踏んだ誤りは3件とも繋ぎ目だった：ReGroup命名の由来の捏造、IGF京都の過剰帰属、highdimの博士期の逆因果。ここから「全Dotが真でも繋ぎ目が偽ならStoryは偽」（story-joints-hide-claims）が言語化された。選択の主観性は設計で覚悟していた通り無害に済み、設計時に想定していなかった「解釈の顔をした事実主張の混入」が実害だった。fact-checkが移行プレイブックの必須工程になったのはこの帰結。

dotsが事実である、storyは解釈である、というのは当初から意識していたが、この「解釈」を自分以外が作るのをみて、思ったよりも「僕の解釈と違う」となることがわかった。

3. 初期設計に存在しなかった発見

孤児Dotと発見面。 初期設計の発見経路は暗黙にStory経由だった。実装で「どのStoryにも属さないDotも将来接続しうるのだからAI発見可能であるべき」（orphan-dot-discovery）が加わり、発見インデックスはStoryでなく dots.json 本体に張られた。これは主オーディエンスの再定義を伴う：初期設計は人間の読者にどう見せるかを考えていたが、最終的な一次面は「未来の後ろ向き接続者＝AI」向けの dots.json+sitemap+llms.txt になった。

人間向けの記述よりもAI向けの記述の方が長命という考え方の変化があったから。

層の相対化。 初期の3層は絶対的な階層だったが、7月末に「Dot/Storyは固定層でなく相対的な役、粒度は出力の高度が決める」（flatness-is-view-resolution）へ改訂された。24歳博士のDotが「畳めない」（credentialと研究と後輩指導は別事実）ことの発見が、この抽象論に具体的な歯応えを与えている。初期設計の「スキーマは実データを見てから確定する」という保留は正しい判断だった——畳む/分割の判定基準は事前には導出できず、実データとの衝突からしか出なかった。

Inboxの消滅（簡約）。 初期設計で入口の一級コンポーネントだったInboxは、「candidates/*.jsonl と dots.json のファイル分離、区別はlocation、statusフィールド不要」に溶けた。設計時に構造として立てたものが、実装では規約で足りた。

4. メタ考察 — 「作る必要はない」のに、なぜ在るのか

最も面白いのは2026-07-29の結論「これに特化したシステムを作る必要はない」と、その3日後にシステムが公開されているという見かけの矛盾。これは矛盾ではなく、「システム」の指示対象がすり替わったと読むのが正確だと思います。

初期設計が想像していた「システム」＝Dot管理・Story編纂・表示を担う知識編集ソフトウェア。この意味のシステムは確かに不要だった。編纂の知能はOpus5+graspが汎用に供給するから。

実際に作られた「システム」＝薄いビルドスクリプト＋データ規律（スキーマ、fact-check工程、畳む/分割基準、帰属の注意）＋AI向け配信面。ソフトウェアとしては build.py 一枚で、価値の本体はデータとプレイブックの側にある。

つまり4ヶ月の設計考察は「作るべきソフトウェア」の設計としては空振りし、「守るべきデータ規律」の設計としては命中した。そしてこれは初期設計自身が持っていた「薄さと堅実さは同居する」という直観の、想定以上に極端な実現でもある——薄さはViews層どころかシステム全体に及び、堅実さはDotのJSONスキーマではなく「繋ぎ目を一次ソースで検証する」という人間の工程に宿った。

もう一つ。3月の設計開始から7月の実装まで放置されていたのは停滞ではなく、「適切な切り出し方は、ニーズが明らかになった後に決まる」の実演だった。デジタル民主主義サミット2026という締切（アウトプットのニーズ）が来るまで、正しい切り出し方は原理的に決められなかった。初期設計の未決問題リストの多く（スキーマ確定、Inbox実装位置、レビューワークフロー）が「実データ・実ニーズを見てから」と保留されていたのは、後知恵で見れば設計の弱さではなく、この構造の正しい認識だった。

補足：初期設計の決定のうちまだ検証されていないものが一つあります。「多言語=並行Story（テンプレ切り分けではない）」は、現状 en.html がindexのみ英語でDot/Story本文は日本語のままなので、実データでの試験を経ていません。英語データ翻訳（HANDOFF.mdの残タスク）に着手する時が、この決定が初めて現実と衝突する時になります。