from ConnectingDotsシステム

何がDotsであるか

2026-07-30

何がDotsであるか

ある観点では、Scrapboxの1ページ、イラスト1枚がDotsとも言えるし、さらに言えばScrapboxの1行もDotsと言える

一方で今やってるようなレイヤーのアウトプットをする場合にはあまりに細かいDotsは不適切

何によって決まるのか

既存の設計（dots.md「粒度は微細でもよい」、inbox.md の3段階、audience.md、Q14 の container Dot 問題）を踏まえた上で、あなたの問いにまだ wiki が明快に答えていない核があります。答えはこうだと思います。

Scrapboxの1行・イラスト1枚・1ページは、どれもある層ではDotです。だから「何がDotか」を対象の側で固定しようとすると答えが出ない。決めているのは対象ではなく、いま何の出力を作っているか（Storyの高度）です。粒度はボトムアップ（ソースの細かさ）ではなく、トップダウン（出力の高度）で決まる。

「捕獲の粒度」と「Dotの粒度」は別物

ここが今の wiki の「微細でもよい」を精密化する点です。実は2つある：

捕獲の粒度（Inbox）：価値は事前に分からないので、取れる限り細かく拾う（Scrapbox行・イラスト）。これが「微細でもよい」の正しい適用範囲。

出力Dotの粒度（Story）：出力の高度に合わせて粗く束ねる。

あなたの違和感——「今のレイヤーには細かすぎるDotは不適切」——はこの2層の混同から来ています。Scrapboxの1行は正当な捕獲Dotだが、プロフィールの facet Story にとっては読者の解像度より下なので出力Dotにならない。矛盾ではなく、層が違う。

出力Dotの粒度を決める3つのテスト

候補ユニットが「この出力にとってのDot」かは、次を全て満たす最大のユニットか、で決まります：

読者の高度で意味を持つ（audience）。プロフィール読者は「2016 未踏ジュニア共同創設」から意味を得るが、Scrapbox 1行からは得ない。

文脈から持ち出しても自立する（再利用性・reverse-lookup）。別Storyに拾い上げても壊れないか。Scrapbox 1行は元ページ文脈に依存して自立しない＝下位層のDot。イラスト（vt-001）は自立する。

単一の検証可能な事実である（事実と解釈, 事実の島の周りに解釈が広がっている の「島」）。細かすぎると解釈の断片（雲のかけら）、粗すぎると複数事実＋解釈の束。→ 「1つの検証可能な事実」を保つ最大単位。

一言でいうと：出力Dotの適正粒度 = (a)対象読者に意味があり (b)持ち出して自立し (c)単一の検証可能事実 を同時に満たす最大のユニット。そして (a) は Story の高度に依存するので、粒度は出力が決める。

Dot と Story は「役」であって固定層ではない（再帰的）

だから同じ対象が、上の層から見れば Dot、下の層から見れば（細かいDotで編まれた）Story になります。Scrapboxページ＝行たちのStory かつ 経歴のDot。vt-001＝視覚要素のStory かつ Visual Thinking StoryのDot。これは Q14（container Dot vs サブイベント分割）への答えでもあって、両方の粒度を捕獲層に残し、Storyがその高度に合う粒度を選ぶ——どちらか一方に決める必要はない。粗いcontainer Dotは索引として、細かい子Dotは低い高度の出力用に共存する。

Q14とは

具体例は 2025-05-06 Tokyo Plurality Week（8日間で9イベント以上）。これを1つのDotとしてどう記録するか、という粒度の問い。選択肢が4つ挙がっています：

(a) 1つの container Dot として粗く記録（当時の現状）

(b) サブイベントを個別 Dot にする（集約Dotは廃止）

(c) container Dot + 子Dot の階層（parent_id フィールドを足す）

(d) Dot は粗いまま、Story側の sections で分割表現する

wiki 上の当時の所見は「(c) は機能的には自然だが『Dotはフラットな点の集合』という前提が崩れる。規模が大きくなるほど (b) の細分化が進むはずで、container Dot は索引として残す価値があるかもしれない。方針確定は規模拡張（50〜100Dot）時に判断」と保留になっています。

これが、さっき私が話した粒度論と直結します。Q14 が「(a)〜(d) のどれか一つに決めなきゃ」と悩んでいるのは、Dotを絶対的な固定層だと見ているからです。粒度が出力層で決まる／Dotとstoryが相対的な役だとすると、答えは「一つに決める必要はない」になる：

Tokyo Plurality Week 全体（container）＝ 経歴Storyの高度ではDot（「2025 Tokyo Plurality Week 開催」で十分意味を持つ）

9個のサブイベント＝ その週を主題にする低い高度のStoryではDot（container はそのStoryになる）

つまり (a)＝粗いcontainer Dot も (b)＝細かい子Dot も両方を捕獲層に残し、各Storyが自分の高度に合う方を選ぶ。(c) の親子リンクは「同じ対象の異なる高度」を繋ぐ索引として持てばよく、「フラットな点の集合」前提が崩れるという懸念は、Dotをフラットな一層と見ることをやめれば消えます。私が「私の粒度論は Q14 への答えでもある」と言ったのはこの意味でした。

設計としては

その設計は「現実にマッチしている」と思う

その設計は自由度が高すぎてなんでも入るから形を定めることに寄与しない

が、形を定めたかったのは認知能力の乏しいホモサピエンスにとっての「理解できる」という価値のためだったのではないか

この設計を忌避して"Dotはフラットな一層である"とするのは、不必要な制約の導入なのではないか

その通りだと思う。あなたは「形を定める」という制約の正体を2つに割っている——それが (1) 現実についての主張（存在論）なのか、(2) 認知の乏しいホモサピエンスに理解可能にするための道具（実用）なのか。「Dotはフラットな一層だ」は (2) が欲しくて導入されたのに、(1) の顔をして紛れ込んでいる。これは奇しくもさっき file back した「繋ぎ目に事実主張が紛れ込む」の設計版です。実用制約が存在論の主張に化けている。

だから「不必要な制約の導入では」という結論に賛成。ただ精密には、制約を捨てるのではなく置き場所を移す：

ストア（Dotのデータモデル）は再帰的・相対的・高自由度でよい ＝ 現実に忠実。

理解可能な「形」は、出力（Story/View）が render 時に一つの高度にコミットすることで与える。人間が要求する平坦さは、ストアの性質ではなく、その瞬間の View の解像度。

そうなるよな「必要に応じて人間向けの使い捨ての短い解説を作る」だ

これで「自由度が高すぎてなんでも入るから形を定めることに寄与しない」への答えが出ます：形を定めるのはそもそもデータモデルの仕事ではない。形を与えるのは curator が Story ごとに高度を選ぶ行為（curator-first、jikoshokai-poker の「役の作り方＝関連の見出し方」）。データモデルに形の決定を期待すること自体が、債務の押し付け先の間違い。ストアは現実への忠実さを負い、Story は読者への理解可能性を負う——別々の層の別々の債務です。「なんでも入る」は、消費点（Story）で必ず一段に潰れるので、人間側では起きない。

そしてこれは connecting-dot-design が既に採っているムーブと同型：

facts-and-interpretation：客観のストアと主観の線を分ける

relationships-as-edits：関係をデータ化せず、編集行為に委ねる

「理解のための平坦さ」も同じで、ストアに焼き込まず Story の高度コミットに委ねる。だから "Dotはフラット" は、関係をデータ化するのと同じ種類の早すぎる固定化です。

一点だけ、あなたの結論を弱めない範囲で留保：フラットなストアには「JSON が単純・逆引きが速い」という実装上の引力が実在します。でもそれは実装の便宜であって存在論ではない。だから正しい扱いは「既定はフラット、階層は parent_id を任意の索引として持てる」——つまり Q14 の (c) を「ストアの原則を壊すもの」ではなく「同じ対象の異なる高度を繋ぐオプショナルな索引」として採る。存在論を平坦と偽らず、便宜としての平坦は既定値として残す。

要するに「何によって決まるか」＝ソースの性質ではなく、出力するStoryの高度（＝audience+purpose）。Dotは絶対的な最小単位ではなく、出力層に対する相対的な役です。

これは connecting-dot-design の dots.md（「微細でもよい」を捕獲層に限定）と Q14 を前進させる内容なので、必要なら新概念ページ（「Dot粒度は出力層が決める／Dot と Story は相対的な役」）として file back できます。やりますか、それとも今は口頭の整理だけにしますか。