NISHIO Hirokazu[Translate]
日記2026-05-07
日記ページが自動生成ではなくたまに手動で作るようになると前のページがよくわからないなと思っていたが、検索窓に「日記」と入れれば更新日時順で出てくるので大部分のケースで問題ない
5/2から 週記2026-05-02~2026-05-07 でつらつら書いていた
週記1週間経ってるから切り替えるのもいいな
今日はゴールデンウィークを1日延長している
ゴールデンウィークどたばたしていて全然休んだ気がしないからな
昼食を食べよう 12:30
夕方に用事があるがまだソワソワする時間ではない

どうなっていくのがいいか
とりあえず読んでコメントを返す
KarpathyのLLM Wikiを作ってある
若干迷走している感じがある
自己紹介の更新がしたいのか、事実をDotsとして、その上にナラティブの層を被せたUIの実験をしたいのか
むしろDotsとしてJSONの1 objectをイメージしていたが、LLM Wikiの1ページが適切なのではという気もする
VTについても考えるWikiを作った方が良い気がする
何気なく書いた「考えるWiki」という言葉で「考える花火」を連想した
これは関連しそうな気がするな
いくつか絵を描いているが追加していってない
摩擦が高くなってしまっているのは問題、何が原因か?
Xが投稿を自動翻訳するようになったことだし、Xにどんどん投稿した方が良い
盲点カードのLLM Wikiを作ることでより良くなるかもしれない?
原稿は出版社側のボールになっている
僕のタスクとしてはdd2030側のWebサイトを更新
英語版との接続
LLM Wikiを作ってみたが、何となく作ったのではイマイチ
ConnectingDotsシステムの実験として、もうちょっとプロンプトを改善してから再挑戦するのがいいかもね
いい感じだったらPlurality本のWikiも作って接続しようかと思っていた
プライベートでスマホから見てコメント書きやすいUIをつけるプロジェクトが生えた
その目的に特化したWikiをはやした
プロジェクトの実装自体はまだ進んでない、明日以降業務の一環という位置付けでやる
広聴AI、Kozaneba、などに対するLLM Wikiを作ってみるといいかもしれないと思っているがまだ着手していない
広聴AIはGoogle Docsの議事録があるのが特徴
KozanebaもCosenseのあちこちに設計の議論がある
埋もれている
社内のあれ
適宜情報アップデート
広聴AIに掛けたいね
データFIXしてからでいいかなと思う
SenseMakerにかけてみるのもいい
LLMに関する色々なものはKarpathyのLLM Wiki勉強会をとりあえずのアウトプットのゴールにしていく
LENCHIとも関連するところ

謎解きをリリースした: NISHIONAZO

電車移動中
overviewがそもそも初見の読者に優しくないよね
初見の読者にやさしくあるべきかどうかはさておき
やさしくないけど知的生産性の高い手法によってまず語られるべき成果を生み出してから、それを噛み砕いて説明する方がいいな

「まだ言語化できない近さ」は概念候補
「下流に永続記憶を置く」もだね

>本書で読者に提示する入口は B のみ にするのか、サービス提供論を本論で扱うのか。
サービス提供の話は明らかにスコープ外
非常に賞味期限の短い環境依存の知識

Q6, Q7
現時点のScrapbox(Cosense)やKozanebaはLLMがここまで成長する以前に作られたサービスであるため、基本的には新しいものが作られるべきだと思う

Q8の「どの程度まで生のログを残すか」は、媒体が電子ならサイズの上限はないから全部残すべきだ
紙の書籍にすることがあるなら、そのタイミングでどこまで掲載するかを決めれば良い
それは今の段階で決めるべきことではない

Q9はingestしたらいいのかな?

Q10
KozanebaからエクスポートされたJSONを、少量の適切なガイドがあればClaude Codeは理解できるはずである
距離の近接はLLMで計算するよりスクリプトで計算した方がいいかもね
視線の動きをエミュレートするスクリプトは作れそう
つまり、まず一番大きなこざねから順に見る
隣接するレベルで近いものをたどる
リンクを辿る
などなど

Q21
>LENCHI 本書のどこで「集団スケールへの拡張」を扱うか。前書きで触れる/第二部の終章で展望として書く/本論には入れず別書に委ねる、の選択肢がある。
これはシンプルな問題ではない
まず個人の能力を高めるのが先だと基本的には思っている
一方で「他人とのインタラクション」によって大きな成果が生まれるケースはある
他人との口頭やチャットでの時間あたりの密度の高いやり取り
他人が書いたものを読むのも広い意味では他人とのインタラクションである
難しい問題であるが考える価値はあるように思う
ブロードリスニングと絡めるなら、色々な思惑によって色々に表現されている「ブロードリスニング」ではなく、もっと狭い範囲の概念にフォーカスすべきだと思う
自分以外の大勢が書いたものに対する理解能力の強化という切り口
他者理解能力とも表現できるが「個体としての他者」を捨象して「分布としての他者」を見ているところで従来の意味の「他者理解」とは異なるかもね
これは基本的にはAI要約の進化だと思う
収束ムーブとも言える
これは後でingestする
初期のブロードリスニングは力不足でベクトル空間を陽に使っていた
LLMの力が強くなるに従い、大量コンテキストの中での関連の発見になってくる
このLLM Wikiもその一端であるし、LLM以前に人間が労力を割いて行っていたのがKJ法だろう

Q23
>5 週間アクションプラン(2026-05-04〜05-31)の進捗を LENCHI 側で追うべきか — 追う場合、週次の ingest として記録する。追わない場合、5 週後にまとめて取り込む。
追うべきでないし、そのプランも最良の方針ではないと思う
進んでみることによって知識が得られる、その価値はある

>本書で ConnectingDots を「実例」として扱うか — LENCHI(個人)/ ブロードリスニング本(集団)/ ConnectingDots(事実・解釈分離)の 3 つの並走プロジェクトの関係を、本書のどこで論じるか。
ConnectingDotsが、語るに足るものであるかはまだ未定だ
生まれたばかりの若芽に過ぎない
成長するかもしれないししないかもしれない

Q22
ブロードリスニング本のWikiとの比較は面白いかもね
そもそも論としてCosenseとの比較が面白そう
だいぶ違う
Cosense的なWikiの作り方の方が知的生産には有用だと思う
Cosense的とは何かを言語化してやる必要がある

この「未解決問題」チェックリストは「解決」「未解決」で整理すべきではないな
今回一通りフィードバックを書くので、それで未解決なものは「時をおいて見返すリスト」に入るべき
Spaced Repetitionだね
エンジニアの知的生産術に書いたけど、rawに入ってるかな?
こういうやり方はSuperMemoの作者もIncremenal Readingなどの言葉で表現している
これも再度取得してrawに入れるべきかもな
執筆時は脳のメモリーに置いてたけど書籍にはrawでは入ってない
「常緑のノート」系の議論もだな

Q20
Scrapboxエクスポートは技術的なのでそのままがいいだろう
更新して上書きする可能性はある
a.txtのリネーム自体は良い

一通りコメントし終わった





そうそう、盲点カードのLLM Wikiも作りたいのだった

"Engineer's way of creating knowledge" the English version of my book is now available on [Engineer's way of creating knowledge]

(C)NISHIO Hirokazu / Converted from [Scrapbox] at [Edit]