動詞が豊かな PKM
Karwi.icon
出発点: 名詞 vs 動詞(Palantir の枠組み)
Palantir の言い方では、知識システムの構成要素は二種類に分かれます。
名詞 = データ要素・対象(Concept, Person, Source, Claim…)
動詞 = それらに対する操作(action types)
そして「名詞だけでは足りない」。名詞(カードやタグ)をいくら並べても、推論によって文のように結合する動詞がなければ、知識は静的なカード箱に留まり、思考の作業場にならない、という主張です。
典型的な PKM は「名詞偏重」
多くの PKM(Zettelkasten, Obsidian, Notion 的なメモ術)が蓄積する単位は名詞=静的なノートです。読んだ本、会議メモ、概念カード、タグ。「何を持っているか」は豊かでも、「それに対して何をするか」の語彙は貧しい。
動詞が無いわけではありません。「抽象化する」「リンクを張る」「リファクタリングする」「古い主張を捨てる」——これらは PKM 論でも語られます。しかし human-only PKM では、動詞は願望に留まりがちです。実行コストが高いので「やるべきだが、やらない」。結果、システムの設計語彙はほぼ名詞だけになる。
本 wiki が「動詞豊か」である証拠
本 wiki は逆に、操作(動詞)が異様に発達しています:
基本 Ingest / File back / Query / Lint
拡張 表札 / 株分け / 移植 / ページ分割 / 概念抽出 / 統合
これらは「ノートを書く」のではなく「単位を組み替える動詞群」です。CLAUDE.md の半分は名詞スキーマ(frontmatter, ページ種別)ですが、もう半分はこの動詞カタログの定義に費やされている。これは PKM として珍しい比重です。Palantir が「名詞だけでは足りない、動詞が要る」と外側から処方したものを、本 wiki は別系統で bottom-up に既に満たしていた——この兄弟的収束が「動詞が豊かな PKM」という handle の中身です。
なぜ本 wiki だけ動詞豊かでいられるのか(メカニズム)
鍵は 人間と LLM のコスト逆転 です。
human-only PKM で動詞が願望に留まるのは、操作の実行コストが人間にとって高いから。だが LLM は操作を実際に実行できるし、その単価が安い。すると:
動詞の実行コストが下がる → 動詞を明示的にカタログ化する価値が生まれる → action catalog が設計の中心になる
nishio.iconそれもあるけど、操作実行の主体が人間だけでなくなったのが大きいな
人間が操作をやるなら明確に操作の手順が言語化されてなくてもよい
AIが操作をやるから、操作の言語化が必要
LLM Wiki では「ページ分割」「株分け」が起動可能な操作になる。だからこそ、それらを精密に articulate する見返りがある。Palantir が「AI agent には許された操作だけを道具として渡す/AI 活用の設計単位はプロンプトでなく思考操作のカタログ」と言うのと同じ構図です。
含意 ― これは本 wiki 固有か、LLM Wiki パターン一般の性質か
ここが重要な含意です。上のメカニズム(LLM が操作を実行できるからこそ action カタログが意味を持つ)が正しいなら、「動詞が豊かな PKM」は本 wiki に偶然備わった癖ではなく、LLM Wiki パターン一般が向かう性質だと予測できます。
nishio.icon
この整理において「動詞」を "「名詞」(ページその他の対象物)に対する操作" であるかのように暗黙に仮定している
が、西尾が当初イメージしていた "動詞が豊かな PKM" は「ページタイトル(≒抽出された概念)が名詞系に偏らない」だった
百科事典的Wikipediaのタイトルが名詞に強く偏ってるのと対照的
一方で「操作としての動詞」という切り口は「名詞 v.s. 動詞」という粗い認知を一段詳細化した感じがある
プログラミングの、特に関数の記述において、関数は引数で渡される対象物に対する操作であり、操作を中心とした知識ネットワーク記述と言える
逆にクラスを定義したり、Entity-Relationを記述したりするやり方は名詞的
OOP v.s. FP がここに繋がるとは思ってなかった、気づき