AIを使った知識マネジメント

ここ数年別のことを忙しくしてたけど僕の本来の興味はこっちに近いのでキャッチアップしていきたい

これがすごく注目を集めた(現時点で2000万インプレッションくらい)

@karpathy の Obsidian セットアップが、汚染リスクを軽減する手段として気に入っています。個人用のボールトをクリーンに保ち、エージェント用の乱雑なボールトを作成してください。

AI用の知識ベースと人間用の知識ベースを分けた方が良いと言う議論

CosenseのJSONを参考資料としてAIに与えてもいいわけだし

たぶん自動でいっぱい書かせるみたいな想定で話されたことなので状況が違いそう

沈没船からしか取れない鉄ってなんか面白い

Claude + Obsidian = A true AI employee

5つの要素

Obsidian (free)

Call transcription

The Obsidian MCP

Claude Cowork + MCP connectors

Custom instructions

「質問に答える前に、必ずオブシディアンのVaultで関連するメモを探してください。見つけたものを使って対応を考えてください。」

Gemma4の登場で、あらゆる情報の整理がマジでAPIなしで多くのエッジ端末でできるようになってきてるので、みんな自分の興味ある情報Wikiは作った方がいいと思う。

karpathyからのアップデートが来た！

Gistがある！

Obsidian Mindの解説(韓国語)

2026/4/6

nishio.icon

自分のやり方との比較

これはrefが単なるファイル置き場として管理されていて、Wikiにはなっていなかった

LLM Wikiは人間可読な形での知識ネットワークのメンテであると言える

専用のデータ構造を使うよりオーバーヘッドはあるが、LLMの方が賢いのでオーバーヘッドのコストを支払うのはLLMがやれば良いということ

Cosenseを検索するスクリプトが生成された

テーマに関連したものを検索して読んで考察させることができている

ローカルのObsidianにバンバンと「価値のありそうなもの」が生成されていくわけだが、これがたまった後どうするんだ感はある

過去の複数人のTwitter DM/Group Chatやその時に書かれたScrapboxの1hop exportなどをAgentにどんどん与えてingestさせている

すごく面白い

チラ見せすらできない内容なのが残念w

という話を書こうとしていてリンクサジェストでこんなものが見つかった

dd2030のチャットログをどうしようかという話もあるし、これを試してみるのは手かもな

今感じていること

https://gyazo.com/bcb55ffe225a655da516d52d253890c9

最初、普段使っている場と別に新しいものを作ることに抵抗があった

ところが実際に使ってみた感覚としては、これはテーマが「種」であり、それが枝を伸ばして成長していくようなもの

テーマがまずあって、関係ありそうな資料を投げ込んで、それを食べたAgentが成長していく

「Agentが成長していく」は、モデル自体が更新されるのではないが、Agentが整理した知識体系が育っていく

むしろCosenseでぐっちゃぐちゃになったものを2-hop links exportして整理させたらいい？

taktamur.icon

今ある既存のobsidianのvaultに突っ込んで見たら、wikiというよりリンク集っぽくなった

既存に似たようなページがあって、それに引っ張られた感じ

これはこれで便利なので残す

アイデアノートがシェアされて、具体的な方法論が無いので、それぞれの人の中に「俺の考えるさいつよのllm-wiki」が乱立するんだろうなぁと思う

これはこれで良い。

試行錯誤の先に、さらに良いアイデアが出てくる予感。

これはテーマが「種」であり、それが枝を伸ばして成長していくようなもの

これしっくりきた。

自分は今ある、ごちゃ混ぜのvaultにllm-wikiを打ち込んではみたものの、個別のテーマで(vaultを別に分けて)やってみるのも良さそう

バンバン作ってる、今日だけで5つくらい作った

4時間くらいの録音データを元に文字起こししてingestするのをさせた

いい感じ

知識構造が育ってきてから「もう一度文字起こしを読んで」とやると、新たな発見が行われたりする

human: 次にこの知識体系を前提にして改めて...の文字起こしを読み直してみてください。新しい発見やつながりがあるかも。

AI: 改めて読み直します。文字起こしの中で、wikiにまだ拾えていない部分に注目します。

知識体系を前提に読み直して、いくつかの新しい発見がありました。synthesisページを作成します。

再読で7つの新しい接続が見えました。特に面白いと思ったもの：

Cosenseの2-hop link exportと組み合わせたりすると、自分でも気づいていなかったつながりが発見されたりする

実はかつて自分で書いていた(から2-hop linkで引っかかった)

長文の勉強会資料の中の1行と言う形

それを今回の講演の文脈で想起することができていなかった

割と無茶な使い方を試しているが、割と動く

ネットで検索して情報収集しろと言えばWebSearchエージェントを使う

音声ファイルとOpenAI API Keyを渡せば文字起こしもする

arXivから論文PDFをダウンロードしてrawに置いた上でそれをingestする

今はブロードリスニング本の全部の原稿を渡して主要概念の整理をさせようとしている

書籍1冊の原稿から62ページのWikiが生成された

音声文字起こしに関しても知識構造ができてから再読させたら新しい発見があったので書籍も何回か読んでもらおう

また別の言語化ができた

ChatGPTでDeep ResearchするとかProにサーベイさせるとかすると「クラウドの向こう側」でWebSearchしたりPDFをダウンロードして読んだりしてくれて、「こちら側」にはMarkdown1枚のレポートだけ渡してくる

一方でClaude Codeは適切に指示すればローカルのファイルシステムの上でDeep Research相当のことができる

"KarpathyのLLM Wiki"と組み合わせればリサーチの結果として出てくるものが構造を持ったWikiになる

もちろんWikiによって扱えるコンテキストの量が100倍になったとしても有限であることには変わりないので質の低いもので埋めるとよくない

そういう意味ではリサーチの最中に取得したマテリアルを全て取っておくことが適切とは限らない

ChatGPTが一旦リサーチして中間マテリアルを捨ててレポートを出してきたのを見た上で、それの参照先の論文を改めてClaude Codeが取得してingestする、という感じでいいかも。今はそうしてる。

これはテーマが「種」であり、それが枝を伸ばして成長していくようなもの

枝が伸びてからいい枝を取って自分のCosenseに植えたりしていた

探索系のプロジェクトでトランスクリプトを置いたリポジトリをつくって、claude codeで探検している

プロダクトオーナーと開発メンバーの乖離を考察させたり、使ってる用語のニュアンスの違いを論じさせたりできる

一次情報わからんときはWeb Searchで調べさせることができる

Claude CodeのAgent Teamsを理解しないことがあったので、一度調べさせてそれを参照させたりする

AIの出力をどう扱ってくかが悩ましい

raw/

AI_output/

note/ みたいに第三層をつくるか、AI_output/ 側に直接書き込む（区別しない）か、両方か

僕は今のところ自分が書いたものはまず社内のグループウェアやCosenseに書かれて、それからそれをコピーしてClaude Codeのターミナルに投げるか、rawに*.txtを作ってそこに書いて"ingestして"という

ターミナルに投げてやりとりして興味深い結果になったら(だいたいは「新しい概念が3つあります！」とかなる)fill backして、と伝えている

「俺自身が書いたテキスト」へのこだわりをどれだけ捨てれるかも勝負かもしれない

markdownよりもうちょいcosense寄りの文法欲しくて試してる

GemmaでLLM Wikiを(Claude Codeを使わずに)実現する方法を考察させてたんだけどClaude CodeがCLAUDE.mdを読んでやってることに相当するものをPythonで実装してOpenAI互換APIでGemmaを呼ぶという選択肢になりそう

その実装自体すでにインターネット上にありそうだ

OpenCodeでGemmaをOpenAI互換APIで呼ぶといいってGPT 5.4 Proが言ってた、今度試す

LLM Wikiの株分けをできないかな

元々LLM Wiki自体についてサーベイしていたWikiに、Xの書いたものを見て関連することの論文サーベイしたものを入れて、そこにXとの議論も追加したんだけども

こうなると「関連したもの」ではあるものの、当初の目的からはドリフトしてきていて

AIは当初の目的との関係が浅いものを無視してしまう

多分そうではなく「関係するもの」が溜まっているカオスのスープみたいなものがたゆたっていて

より詳細な「目的」ができたタイミングで関係ありそうなものを引き連れて株分けされるべきなのではないか

「すでにあるものに引っ張られすぎる感覚」だな、言語化できた

(LLMWiki)

ポケット一つ原則の例外ではなく、ライフサイクルの一部。種を蒔く→カオスのスープで育つ→目的が結晶化→株分け

AIが無視する問題の原因はスキーマ（CLAUDE.md）の目的文との乖離。株分け時に新スキーマを書くことで解決する

リランカーが株分けツールになる: 新目的を書いて全ページをリランクすれば「引き連れるべきページ」が自動で出る

コピーであって移動ではない: 同じ素材が別文脈で別の価値を持つ

ブロードリスニング本のLLM Wiki、Wikiの記述が原稿の内容に基づいているか再確認させたら、75ページ全部をサブエージェントで検証し始めて、人間の知的生産だとこうはならないな〜と思った

AIには面倒だと思う感覚がないから簡単に力技をしてくる

https://gyazo.com/f5a2e7e0782402be107c6b77f841f92c

1パスでは結構間違ってる

間違っているという解釈が間違っている可能性もある

https://gyazo.com/6faa3caddc07e1105c2c942fd0fe3932

あるWikiでできたものを塊に加工して別のWikiに植える

Wiki Aで生み出されたもののうちの「〜〜をWiki Bで〜〜という目的で再利用したい」と言語化できてからこの処理が行われる

今回は実装上のものだったんだけと、Wikiで見えてきた概念を移植用に出力させてWiki Bの側でingestする運用もありだと思う

(LLMWiki)yosiderの未解決問題: 一度ある目的で切り出した後、別目的で両立可能な切り出しに作り直せるか、というのは 「移植」のOpen Questionとしても重要。

Scrapbox(=Cosense)での切り出しはcutなのでこの問題が起きる。LLM Wikiでの議論はCopyやdigestである

(LLMWiki)「コピー推奨」は単なる慎重さではなく、目的駆動の切り出しを目的別に独立させる原理であることが明確になりました。LLM Wikiの設計は、Scrapboxの運用知を引き継ぎつつcutの制約を取り除いている、という整理です。

いまなら「選択範囲をコピーして新しいページを作る」「目的に合わせた要約をLLMがやる」という形もありえる

LLM Wikiについて考えるLLM Wikiを育てた結果

2025-12に僕がやっていた「Claude Codeに日記を書かせる」パターンは「AIにコストを払わせる、振り返りで学習ボーナスを得る、CLAUDE.mdに運用ルールを書く、ファイル分離」の4つの点で根底の哲学は同じという話になった。

重要な違い

僕がやっていたのは「作業」を「日」の単位で切り取ってdiaryにすることであって、情報の整理のされ方が時系列だし、粒度が大きかった

「作業記録」としては機能していたが、知識体系が育てられるという感じではなく、日報が特に構造化されてないまま決まった箱に入っていくだけだった

(それ以前の「特に置き場所を決めずに適当なところに適当な名前のファイルを置いて後で収集つかなくなる」よりはだいぶマシ)

LLM Wikiはより小さい粒度の「概念」の単位のページをつくる、そしてそれが関連しているところにリンクを張る

単体としてはより小さく、リンク先の総体としてはより大きくなっている

そして状況によってどこまで参照するかをエージェントの決定に委ねている

https://gyazo.com/b06770a6e7bc9ce3c36dffc264a6cda8

1: エージェントが活動するが、コンテキスト幅に限界があるため古いものがcompactionされて失われていく

人間が記録を取らずに作業をした時に過去のことを忘れるのと似ている

2: 情報が消えないようにlogファイルに出力し、それを大きくなりすぎないように1日単位で切り取ってdiaryという形で整理するようにした

3: 情報から「概念」を抽出し、それらの間の関連性を発見するようにした

知識グラフ（ネットワーク）を複数持って、上手く行き来することが大事そうですね

「日記的なグラフ」と「LLM Wiki」どっちか一つじゃなくて、両方運用して上手く連携させる

書籍1冊分の原稿を入れてWikiを作る実験、公開

(LLMWiki)重要な4つの含意:

LLM Wikiは「主宅地」(main repository)ではなく「ワークショップ」（処理場）

note/ 第三層は外部主宅地があれば不要

「区別する／しない」問題の解決: 外部とは境界で区別している

ingest/filing back の役割が明確化: 境界での輸入・保存操作

nishio.icon

「Wikiをsource of truthにしない」というポリシー、いい切り口

source of truthは勝手に書き換えてはいけない、Wikiにsource of truthがあるとWikiを書き換えていいのかどうかわからず、追記追記になってしまう

より信頼できる情報源がLLM Wikiと明瞭分離されていることに意味があるのだな

Wikiを簡潔に保つ

(LLMWiki)

Wiki内容は気軽に書き換え/削除できる

Wikiが動的な合成層として機能する

(LLMWiki)

簡潔さの強さはページタイプによって異なる：

table:_

タイプ 簡潔さ 理由

concepts/ 強く簡潔（atomic） リンクハブとして機能するため

entities/ 簡潔 識別+最小限の文脈

sources/ 中程度 要旨を保持、原典は raw/ にある

analyses/ 長め可 推論プロセスに価値があるため

クラスからインスタンスを生成するみたいな

少し違う気もする。インスタンス生成はパラメータ変えるだけつくるものは同じ、LLM wikiでつくらせるのは中身からして微妙に違う感じで、たとえとして微妙かも

AIを使った知識マネジメント

Vault単位の課金となると、テーマごとに小さなWikiを作りまくるスタイルとは相性が悪いな

何が良いかの言語化に挑戦する

何もしなければ与えられる情報は「未知のキーワードと細かい数値が並んだ血液検査の結果」と「医師の口頭での解説」だけ

医師の口頭での解説はアドリブなのでこちらにとって未知の言葉を使ってしまうことがある

それを避けようと配慮した結果、本来専門用語でスペシフィックに指す概念が、ふわっとぼやけた表現になってしまうことがある

病院や検査が異なると同じ概念を指す単語が異なることがある

医師が使う言葉も紙に書いてあるのと異なることがある

同じ言葉であっても一般人は「Amy=アミラーゼ」という対応づけはできていない

医師が喋ったことを素人が聞いて思い出してメモしているものに比べて、数倍詳細な出力が出る

テキスト形式で出るので特に専門用語に関して素人の聞き取りによるノイズが入らない

正解は後者だが現時点だと前者が青リンクで後者が赤リンクだ

医師の解釈と異なること、医師が重要ではないと思って解説しなかったことも出る

これは解釈なので変わる可能性がある、時系列での検査データを見たり、過去のデータを見たりすることでだんだん詳細に理解できるようになる

この時点で発症から数日経っている

ただ、ChatGPT Proの出力は一次元的で長文

毎日血液検査の結果が出てくる状態でそれを「把握」するのは難しかった

overviewと、時間軸の整理timeline、重要な概念の解説などが生成されていく

「ある時点ではこう考えていた、新しい情報でこう更新された」という話が蓄積していく

なかなか面白さをうまく伝えられないなぁと思ってたんだけど

ChatGPT Proの少し先にいる感

不特定多数の猫を想定した獣医学の教科書的知識が、特定の一匹の猫の具体的な検査データを土台として再構築再配置されていく

2026/5/1

具体的な対象トピックに関するコメントはあっち、メタな仕組みに関するコメントはこっちに書こうと思う

複数人の議論がある状態からLLMに整理させる

Export for AIをいくつかのページに対して実行してそれをingestしてるだけ

人間とLLMの書くWikiを明確に分離するという方針ともマッチしてていいな

人間はCosenseで議論をし、AIはそれを眺めてObsidianで整理する

人間の会話にAIが「殴り込んで」くるのとは違う

議論をする時に口頭でやらずにホワイトボードを使う

「Xさんの意見」を「Xさん」から切り離して「ホワイトボードに書かれた情報」という客体にする作業

このホワイトボードに相当するものを作っていると考えられそう

A: 人対人だと沈黙が気まずい

B: 「言い訳オブジェクト」があると「私はこのオブジェクトを見てるんですよ」という「言い訳」が成立するので気まずくない

直接「人対人」の構図にならないようにする効果

AIが概念解説のページを作ってくれるのは有用

特に議論に出てくる概念については解釈が分かれていると不毛な議論になるから解説が生えてくるのは大事だなと感じた

議論に参加した個人ごとのスタンス解説ページができているのも面白い

自分のスタンスのまとめられ方が不満で「自分はこんなことは言ってない！」と言い出す人が出てくるかも

これが発生したら、その発言をAIに渡して生成し直せばいい

→ 修正は容易（再生成）だが、初見の心理的反応はケアが必要。

確かに、書いとくか

僕もやるけど、人間が人間の解説ページつくるのは心象良くない。なるほどAIなら行けそうだなと思った

AIが作るなら同じかなという気持ち

これは議論の場で盛り上がりが自然発生するにまかせて、後から整理したらいいという思想

ただ、現状のCosenseの切り出しメカニズムがカット&ペーストであることが原因で「どう切るか」は一通りしか作ることができず「どういう切り方をするのが最適か」に悩んで高コストになる問題があった

LLM Wiki化はコピー&ペーストなのでオリジナルが破壊されない

なのでいつでもリスクを感じることなく実行して良い

LLMが生成したWikiは「複数の人間が苦労して書いたもの」ではなく「それを参照してAIがちょちょいと作ったもの」なので、生成結果を見て不満なら捨てても良い

低コスト

複数の人間が書いたものを整理するのは精神的コストがめちゃ高い

整理は大体「捨てる」ことが重要なのだが、人は自分が書いたものを捨てられることを不快に思うからな

nishio.icon

nishio.icon

再起動してみた

sta.icon

nishio.icon

MacBookに置かれたMarkdownのWikiを出先でiPhoneで読んで、範囲選択してコメントできるシステムができた

講義資料を作りかけ