0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

LLM Wikiで自分のトリセツを作ってみた

0
Posted at

LLMによる知識管理の方法として、最近注目を浴びている「LLM Wiki」。既存のRAGやGraph RAG、構造化データとは一線を画する斬新な構造が特徴です。今回はそんなLLM Wikiを使って、自分の価値観や好き嫌いをまとめた取り扱い説明書、いわゆる「トリセツ」を作ってみたお話をします。

LLM Wikiとは?

一言でいうと、LLM Wikiは「LLMが回答のベースにする知識を設計する仕組み」のひとつです。同じくLLMの知識基盤として利用されているRAGやGraph RAGと地続きの技術と言えます。

LLM Wikiを提唱したのは元OpenAIのAndrej Karpathy氏。氏自身のツイートでその概要を示すとともに、GitHub Gistにて詳細を発表しています。ここで、LLM Wiki自体はあくまで思想であって、具体化されたソフトウェアではないことに留意したいところです。

詳細は出典となる元ツイート、またQiitaやZennの別記事に譲るとして、かいつまんで説明すると、LLM Wikiは「3つのレイヤー」と「3つの操作」で構成されています。

3つのレイヤー

  • 生データ:人間が書いた記事や論文など、そのままの一次情報
  • wiki:AIが生データを咀嚼し、AI自身が読みやすいように加工したもの。記事や論文に頻出する概念や価値観などに対応するページの集まりです。ポイントは、AIが生データそのものに基づいて都度回答するのではなく、一度wikiとしてコンパイルしておき、それを回答のベースに使うという点。生データが追加されれば、wikiも随時更新されます
  • スキーマ:wikiそのものの構造や、wikiを使った回答生成・メンテナンスに関するメタ的なルールのまとめ

3つの操作

  • ingest:人間が新しいソースを追加する。追加されたソースをAIが読み、wikiに要約する
  • query:人間が質問する。AIはwikiに基づいて答える
  • lint:AIがページ間の矛盾や古い主張など、改訂した方がいい部分を指摘する

他の方による活用例

LLM Wikiはあくまで思想であり、具体的な実装方法は人によってさまざまです。実際にすでに活用されている方の記事をいくつかまとめてみました。

  • 社内wiki:プロジェクトに関する情報など
  • 論文の知識管理。複数の論文における主張の対比もやってくれる
  • MySQLでの構造化。こちらはより実践的な知識の整理
  • 多言語対応:同じwikiから日英両言語版の記事を生成。単純な翻訳ではなく、トピック順など文化的な文脈(cultural contextと言われるやつですね…)に合わせてくれる

なお、LLM Wikiはあくまで思想なので、これらの方々が実際にどのようにLLM Wikiを実装・運用しているかは様々です。

LLM Wikiで自分のトリセツを作ろう

私はふだんObsidianにデイリーノートをつけていて、雑談やアイデア、体調や感情の記録などをタグ付けしながら書き溜めています。(ちなみにこのメモは以前紹介したDiscord Botを使って書いたものでもあります)


こんな感じに

この蓄積を材料に、「自分がどんな人間か」をLLMに整理させる、トリセツをAIに作ってもらいました。

技術スタック

ノート管理にはObsidian、LLMの実行環境にはClaude Codeを使っています。

方針

フォルダ構成

構成は次の通り。

diary-wiki/
├── raw/articles/     # 生データ。デイリーノートのMemo欄などを配置
├── wiki/             # LLMが書き込むページ本体
│   ├── index.md      # 全ページのカタログ。まずここを読ませる
│   └── queries/      # 問い合わせ結果の置き場
├── outputs/reports/  # lint結果などのレポート
├── log.md            # 追記専用の操作ログ
└── CLAUDE.md          # このwiki固有のルールを定義

処理の流れとしては、

  1. Obsidianのデイリーノートを生データとしてraw/articles/に取り込む
  2. Claude CodeがCLAUDE.mdのルールに従ってwiki/配下にMarkdownページを生成・更新する
    という構成です。

ページ間のリンクもObsidianのWikilink記法([[ページ名]])をそのまま使っているので、生成されたページはObsidian上でグラフビューなどからも辿れます。

CLAUDE.mdにルールを記載

CLAUDE.mdには以下の項目が名文化されています。

  • ページ種別ごとのテンプレート(concept/person/source-summary/query-output)
  • ファイル命名規則(lowercase-kebab-case、Wikilinkの書式)
  • 相互リンクのルール(関連ページには必ずリンクを張る、矛盾があれば> [!WARNING]で明示する)
  • 操作ごとの手順

操作については、Karpathy氏の原案は「ingest・query・lint」の3つですが、自分の運用では取り込みとページ化を分け、ingest(生データの保存とログ記録のみ)とcompile(内容を読み込んでページを作成・更新する)を独立させ、実質4操作にしています。ソースを入れたタイミングと、それをどう解釈してページに落とし込んだかを別々にログへ残せるようにするためです。

バックアップ

フォルダはローカルにも保存しつつ、更新したファイルは実験用に切ったGitHubブランチへコミットして残す運用にしました。生成過程がすべてコミット履歴とlog.mdに残るので、後から「いつ・何を入れて・どう解釈されたか」を追跡できます。(本番の運用ではこんなことしなくていいと思いますが)

結果

まず2026年7〜8月分のデイリーノートのメモ欄を素材としてingestし、最初のcompileでは人物ページを中心に14ページが生成されました(後述しますが、ここは狙い通りではありませんでした)。

そこから「体調のパターンをまとめてほしい」「快・不快の瞬間を抽出してほしい」といったタグベースの抽出リクエストを8ラウンドに分けて依頼し、最終的に次のようなテーマページ群ができあがりました。

  • やりたいことの記録:「これやりたいな」というメモや開発アイデアを抽出。すぐ叶えられそうな願望/長期的なプランが必要な願望に分けて整理
  • キャリア探索:進路決定に関して、具体的な行動と内省・気づきをまとめる。それに基づき、今後自分が目指すべき方向性を提案
  • 快と痛みの記録:自分がどんな時に気分が良くなる/悪くなるかを分析。また、できるだけ気分が良い状態でいるために、日常生活でどんなことを心がけるべきかをまとめる
  • 体調の記録:体調の良くなる/悪くなるパターンを抽出、傾向を分析
  • 美味しい料理の記録:美味しかったご飯の感想を抽出。自炊や外食などテーマ別に分割。
  • ゲーム・音楽・アニメの記録:日付ベースで感想を抽出したのち、タイトルごとに再構成
  • 夢日記思い出:徒然なるままに時系列でまとめる
  • ミスの記録:ミスを分類、減らすための方針を提案
  • 気になったリンク集:後で読もうと思ってメモしていたWebサイトの一覧。テーマ別にまとまっている

各ページには、元になったデイリーノートへの日付リンク(例:[[2026-08-12]])を必ず添えるようにしています。

やってみた感想

最初はいらないものを出してきた

最初のcompileでは、メモで1〜2回しか言及していない人物のノートばかりが優先的に作られました。素材の期間が短かったせいもありますが、無難な選択肢として人物・組織のノートを作りがちなのかもしれません。

一方で、そのとき唯一まとまっていた「キャリアの迷いを描写する」ノートは、自分の迷いをうまく言語化できていて驚きました。LLM-Wikiに限らず言えることだと思いますが、技術に何ができるか分かっていないと、出力を「改善しようがあるエラー」なのか「その技術を選ぶ限りどうしようもない仕様」なのか判断がつきません。ここで一つでも成功例を見られたのは、その後の方針を決めるうえで大きかったです。


※公開用にデータは加工しています

大部分は人間が考えている

LLM Wikiにノートを作成してもらうにあたり、以下をプロンプトで明示しました。

  • ノートの記録フォーマット:[[日付のリンク]] 日記の要約という書き方
  • テーマ設定:気分の上下/やりたいこと…など、wikiに抽出する概念
  • 各テーマの章/セクションの構成:パターン分析、それを踏まえて心がけるべきことや今後の方針など

つまり抽出・要約以外の設計はかなりの部分を人間が担っています。パターンの抽出自体はLLMに任せましたが、抽出の切り口や分析の仕方について、人間側が欲しいアウトプットを把握しておく必要があります。例えば「やりたいこと」のノートで自分の興味関心をまとめた際、内容そのものよりも感情の強さに基づいて項目の分類が行われていました。本当は感情の強さではなく内容に基づいて分類してほしかったので、分析をやり直させるはめに。


感情の強さがキモではないような…

一方で、パターンそのものは自分だけでは整理しきれないものでした。元のメモが膨大になっていたので、個々のメモから傾向を見出すのは大変です。それをぎゅっと凝縮したノートができたのは、LLM Wikiならではの価値だと感じました。


いつどんな時にコンディションを崩したかとか、覚えてないものです

後日arscontexta(LLM WikiをClaudeで動かすためのソフトウェア)で同じ実験をしたときは、フォーマット自体もLLMに考えてもらえましたし、テーマが固まった後は「テーマ内のパターン」だけでなく「テーマをまたぐ自分の考え方のくせ」まで分析してもらえました。LLM Wikiはカスタマイズ性が高い分、設計を自分で全部考え切らなければならず、「よく分からないけどまずやってみよう」という初心者にはハードルが高いと感じます。

見落としがまあまあ多い

タグベースでの検索で必ずしもすべての結果がヒットされ、テーマページに反映されたわけではありませんでした。例えば、体調に関するログとして「お風呂に入ったら少しよくなった」と記録した場合でも、その知見が拾われなかったり。

そのうえ、デイリーノートを分析してほしいと頼むと、本当にデイリーノートしか見てくれません。同じタグが付いたプロジェクトノートやタスク管理ノートとの関連性までは、別途指示しない限り見てもらえませんでした。

なんでも教えないといけない

例えば、健康診断の数値をメモしていたときは「大量の数値が入っている。体調が急変したのだろうか」と書かれてしまいました。健康診断だから数値をまとめてメモしているだけで実際は大したことない、という文脈まで全部説明しないと気づいてもらえません。

たいしたことないのに

まとめ

今回は自分のトリセツを作ってみました。膨大なメモをテーマごとに凝縮してくれる点は便利な一方、設計のほとんどを自分で決め切る必要があり、まだ一筋縄ではいかないという印象です。構造や実際に生成されるノートの中身など面白いポイントが色々あるので、今後も追っていきたいと思います。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?