# 保存した資料を次の仕事に生かす AIがノートを更新するLLM Wikiの始め方 - 媒体: 知能圏（CHINOUKEN） - 公開日: 2026-09-11 - カテゴリー: エージェント・ソフトウェア - タグ: LLM Wiki、セカンドブレイン、知識管理、Claude Cowork - 想定読了時間: 約15分 - 調査基準日: 2026年9月11日 - 出典: 8件（末尾の「参照リンク」に番号順で記載） - ページ: https://www.chinouken.com/articles/llm-wiki-second-brain - このMarkdown: https://www.chinouken.com/articles/llm-wiki-second-brain.md - 利用条件: 引用する場合は出典として「知能圏（chinouken.com）」と該当ページのURLを明記してください。本文の再配布は行わず、要約や引用の範囲で使ってください。 企画書や議事録をAIに読ませると、その場で要約や比較を作ってくれます。さらに、新しい議事録が届くたびに、以前の企画ノートまで更新してくれたらどうでしょう。新資料に合わせて既存のノートを手入れする方法が「LLM Wiki」です。勉強会の資料を使った試行では、人数の変更を反映した後も、追加の訂正を受けて「解決済み」の食い違いを再び未決事項へ戻せました。「第二の脳」という考え方の背景から、出典を残して自分の資料で始める手順まで説明します。 ![AIと育てる知識ノートという見出しと、資料の紙片を取り込み、内容が更新される開いたノートのイラスト。](https://www.chinouken.com/images/articles/llm-wiki-second-brain/hero.png) ## 資料を集めた後に残る読み合わせ 来月の勉強会を準備しているとします。最初の企画書には開催日と定員があり、運営担当のメモには会場の条件があり、その後の打ち合わせで募集人数が変わりました。「いま何人まで募集できるのか」を知るには、ファイルを見つけたうえで、どの記述が今も有効なのかを読み合わせる必要があります。 こうした整理は、AIを使っても人の側に残りがちです。資料を渡して一度は答えが得られても、次の会議までに情報が増えれば、前回の結論から何が変わったかを確かめる仕事がまた発生します。議事録ごとの要約がそろっていることと、現在の計画が一つのノートにまとまっていることには差があります。 ### 頭の外に置いた知識を手入れする 「第二の脳」「セカンドブレイン」は、覚えておきたい情報や考えを、自分の頭の外へ残して使う考え方です。メモアプリに読書の抜き書きを集める、案件ごとに議事録をまとめる、調べた記事へ後からたどれるようにする。資料同士にリンクを付け、後で読み直せるノートにすると、単なる保存先から考えるための道具へ近づきます。 ただし、情報を集めるほど、古いノートを直す手間も増えます。新しい料金を知ったら比較表を直し、方針が変わったら関連する企画も直す。人がそのつながりを覚えていないと、古い結論だけが残ってしまいます。 2026年8月21日、Xに投稿したrvaniaaa（@rvaniaaaa）は、この手入れをAIへ任せる発想を「第二の脳はコンパイラだ」と紹介しました。元になったのは、AI研究者Andrej Karpathyが2026年4月4日に公開した「LLM Wiki」です。大規模言語モデルを意味するLLMを使い、資料を読み合わせて、互いに参照できるノートの集まりを作り続ける方法を提案しています。 ここでのWikiは、インターネットへ公開する百科事典に限りません。自分のPCにある「勉強会の計画」「会場の条件」「確認が必要なこと」といったページがリンクでつながっていれば、小さなWikiとして使えます。 ## AIの答えを次回も使えるノートへ この方法を支えるのは、AIに文章を返してもらうだけでなく、ファイルを読み、必要な箇所を書き換える仕事まで頼めるようになったことです。目的に合わせて道具を使い、途中の結果を確かめながら作業するAIを、AIエージェントと呼びます。 たとえばAnthropicのClaude Codeは開発作業を支援するAIエージェントですが、扱えるものには普通の文章ファイルも含まれます。同社のCoworkは、資料整理や文書作成を頼むための機能です。PCのフォルダを直接扱う場合は、デスクトップアプリを使います。こうした道具を使うと、「議事録を要約して」に加え、「前の計画と照合し、変更があったページを直して」と依頼できます。 AIと情報の関わり方を、勉強会の例で比べると違いが見えてきます。同じ製品でも、相談、資料検索、ノートの更新を組み合わせて使えます。 | 使い方 | AIに頼むこと | 次回へ残すもの | | --- | --- | --- | | 会話で相談する | 渡した企画書から募集文の案を考える | 会話の回答。次回のAIに履歴や資料を読み直させる | | 資料から検索して答える | 定員が書かれた箇所を探して答える | 元資料と検索の仕組み。回答の保存は別途決める | | Wikiを更新する | 新しい決定を既存の計画へ反映し、食い違いも記録する | 現在の計画、根拠、未決事項をまとめたノート | 資料を探してから回答に使う方法は、検索拡張生成、略してRAGと呼ばれます。大量の資料から質問に関係する部分を取り出し、AIへ渡す方法です。たとえば「会場Aの定員は」という質問に対し、運営メモの該当箇所を見つけて回答の材料にします。 LLM Wikiで加えるのは、資料を受け取った段階で、既存の知識との関係を整理して保存する仕事です。「定員40人の計画に対し、会場は30席しかない」という食い違いを、計画と会場の両方のページへ残しておきます。次の質問では、その整理を足場にできます。 rvaniaaa氏のX投稿のタイトルにある「コンパイラ」は、この作業の比喩です。ソフトウェアでは、人が書いたプログラムを別の形式へ変換する道具を指します。ここでは、ばらばらな資料を、次の作業で使えるまとまったノートへ変換することに重ねています。AIによる要約や判断には誤りがあり、プログラムの変換のように一定の規則だけで正しさを保証できるわけではありません。 また、ファイルに整理を残すことと、AIモデル自体が学習することは別です。次の会話で役立つのは、前に作ったページをAIが読み直せるためです。ページを参照させなければ、ノートを保存しただけで知識が伝わることはありません。 ![原資料を保持し、AIが新資料と既存ノートを照合して更新する流れ。次の質問でノートを参照し、食い違いは人が原文で確認する。](https://www.chinouken.com/images/articles/llm-wiki-second-brain/figure-note-update-flow.png) *AIが資料を読み合わせ、決定事項、根拠、未決事項をノートへ残します。食い違いは人が原文に戻って確認します。* ## 企画書と運営メモを読み合わせてみる 新しい資料で計画が変わったとき、以前のノートまで直せるでしょうか。知能圏では、架空の社内勉強会の資料を使い、AIにWikiを作成・更新させました。使ったのは、OpenAIのAIエージェントCodexの作業環境とGPT-5.6 Solです。Claude製品の動作や、長期利用による効果を測った実験ではありません。 最初に渡した資料は、次の二つです。食い違いがあるときに、AIが一方を勝手に正解にしてしまわないかを見ました。 | 資料 | 書かれていること | | --- | --- | | 2026年9月1日の企画書 | 2026年10月15日開催、定員40人、会場A、予算8万円、オンライン配信なし | | 2026年9月2日の運営メモ | 会場Aは着席30人、録画は未承認、参加者から配信の希望あり | AIには、出典を付けて「勉強会の計画」「会場」「未決事項」を作り、決定と要望を分け、食い違いを解決せずに残すよう頼みました。 生成されたノートでは、「定員40人」と「着席30人」が未解決の食い違いとして記録されました。配信希望は要望欄に置かれ、決定欄の「オンライン配信なし」は保たれています。資料ごとの要約を並べるだけでなく、二つの資料を同時に読むと分かる問題が、次回に参照できる形で残りました。 続いて、2026年9月5日付の責任者の決定を加えました。「会場Aのまま募集定員を25人へ変更する。日付と予算は変更しない。配信なし、録画は未承認」という内容です。 更新後の「勉強会の計画」では、募集定員が25人となり、変更の根拠に新しい決定資料が付きました。「未決事項」でも、40人の計画と30席の会場の食い違いが解消済みになりました。質問への回答にも、現在の募集定員25人と、録画の実施・提供は案内できないことが反映されています。 | 確認した点 | 新しい決定を加えた後の記録 | | --- | --- | | 現在の募集定員 | 25人へ更新し、責任者の決定を出典として記載 | | 以前の人数 | 40人だったことと変更理由を履歴として保持 | | 配信の希望 | 要望のまま残し、実施決定へ変えない | | 録画 | 未承認を維持し、参加者へ実施・提供を約束しない | 新しい資料が古い決定を変更すると明示していたため、今回は現在の計画を更新できました。「新しいメモに別の数字があった」というだけなら、訂正なのか、別条件での見積もりなのかを確かめる必要があります。 ## 誤った資料を訂正すると過去の回答も古くなる さらに、2026年9月8日付で「会場Aの30席は誤記で、正しくは20席」という訂正を加えました。ただし、運営担当による訂正であり、責任者が決めた募集定員25人を変更する権限はない、と明記しています。 このとき、AIは会場のページを20人へ直しながら、計画の募集定員は25人のまま残しました。両者の5人分の差を未決事項へ戻し、「このまま25人の募集を進めてよいとは判断できない」と回答しています。募集人数を減らすか、会場を変えるかは人が決めることとして分けられました。 会場の数字に加えて、以前の「食い違いは解消済み」という整理も改められました。訂正資料は、過去に作った計画と会場のページ、未決事項の記録に影響しました。 前の段階で作った回答も点検させると、後発の訂正を含まないため、現在の募集可否を判断する材料としては不十分だと変更履歴へ記録されました。前の回答自体は、履歴として残しています。前の回答にある「責任者の決定は25人」という記述自体は変わっていません。それでも、20席しかないことが分かった後に、その回答だけを読むと判断を誤るおそれがあります。 訂正の影響を確かめるには、原資料に戻り、「その資料を使って何を作ったか」をたどる必要があります。Wikiだけを直しても、別に保存した募集文や報告書が古いままなら、次の仕事には誤った前提が残ります。資料の訂正時には、関連するページと成果物を挙げさせ、現在も使えるかを確認する運用を勧めます。 ### 今回確かめた範囲 今回扱えたのは、決定と訂正の関係が明記された短い文章です。大量のPDF、曖昧な会議の発言、複数人による同時編集を同じように扱えるかは確かめていません。また、過去の回答の点検は人が明示的に依頼しました。AIが自力ですべての影響先を見つけることを確認した結果ではありません。 | 実行条件 | 今回の内容 | | --- | --- | | 環境 | macOS上のCodex作業環境でGPT-5.6 Solがファイルを操作 | | 処理 | 初回作成、決定の追加、訂正の追加を順に依頼 | | 明示したルール | 出典を付ける、決定と要望を分ける、権限のない変更をしない | | AIが処理した資料 | 筆者が入力した架空の原資料と、AIが作ったノート。処理のためクラウドAIへ送信 | この試行ではファイル更新に失敗は見られませんでしたが、入力した資料自体の誤りは、訂正を渡すまでWikiにも引き継がれていました。 ## 自分の資料で始める手順 最初の題材は、継続して読み返す一つのテーマが向いています。進行中の企画、比較検討しているサービス、勉強中の分野などです。まだ読み返す目的がない資料まで集めると、整理されたページが増えても使いどころが定まりません。 ### 資料の保存場所と書き込み先を分ける 自分のPCに作業用のフォルダを一つ作り、その中で、原資料とAIが更新するページを分けます。たとえば、次の構成です。各フォルダ名は自由ですが、役割の区別は保ちます。 ```text my-wiki/ raw/ 元の資料 wiki/ AIが整理して更新するノート output/ 募集文や報告書などの成果物 RULES.md AIに読ませる運用ルール ``` 普通の文章として保存できるMarkdown形式なら、特別なデータベースを作らずに始められます。Markdownは、見出しや箇条書きを簡単な記号で書くテキスト形式です。原資料はそのまま残し、訂正が届いたら新しい資料として加えます。後からAIの整理を疑ったときに、元の記述へ戻れるようにするためです。 AIに渡す資料は、所属先で利用を認められた範囲にします。ファイルがPCに保存されていても、クラウドのAIに読ませれば処理のために内容が送られます。このWikiを社内外の人へ共有する場合は、元資料の閲覧範囲に合わせてWikiも分けてください。社外秘の資料から作った要約も、共有範囲を決める対象です。 ### フォルダを扱えるAIで最初の一回を動かす 画面から始めるなら、Coworkで作業フォルダを選び、最初に運用ルールを読むよう依頼する方法があります。Claude Codeを使っている人は、作業対象をこのフォルダにして同じ依頼を送れます。LLM Wikiは、ファイルを読み書きできるAIで実践する方法です。利用条件は、選ぶ道具ごとに確認します。 2026年9月11日時点の公式案内では、CoworkはProを含む有料プランで利用できます。PCの資料を扱う間は、Claudeのデスクトップアプリを開き、接続を維持する必要があります。クラウド内だけで進む仕事とは実行条件が違います。ここでのCoworkの操作案内は公式資料に基づきます。 運用ルールには、自己紹介だけでなく、どこを読み、何を変え、何を保留するかを書きます。次の例は、そのままファイルへ保存して使えます。 ```text このWikiは勉強会の計画と判断理由を引き継ぐために使います。 ・rawの原資料は変更しない。 ・作業前にwikiの目次と関係するページを読む。 ・決定事項、要望、推測、未確認事項を分ける。 ・重要な記述に出典ファイル名と見出しを付ける。 ・日付が新しいだけで、既存の決定を取り消したと判断しない。 ・食い違いは両方の根拠を残し、人へ確認する。 ・更新後は目次と変更履歴も直す。 ・依頼にない公開、送信、原資料の削除は行わない。 ``` Claude Codeでは、`CLAUDE.md`というファイルに継続的な指示を書く仕組みがあります。ただし、どのAIでもその名前のファイルを自動で読むとは限りません。まずは依頼文で「作業前にRULES.mdを読んで」と明示し、実際に参照されたかを確認する方法が分かりやすいでしょう。 運用ルールを保存したら、最初の資料を`raw`へ入れ、次の依頼でWikiの土台を作ります。目次には各ページの場所と一行の説明を、変更履歴には何を根拠に作ったかを残します。 ```text RULES.mdを読んでください。まだwikiにページがなければ作成してください。 rawの資料から、勉強会の計画、会場の条件、未決事項をまとめてください。 各ページに出典を付け、関連ページへのリンク、目次、変更履歴も作ってください。 資料の間で食い違う点は、解決せずに人へ確認してください。 ``` ### 新しい資料を入れて更新を依頼する 原資料を保存したら、次のように頼みます。最初から全資料を一括処理するより、一件の取り込みでどんなノートが残るかを見れば、運用ルールを調整しやすくなります。 ```text 作業前にRULES.mdを読んでください。 rawに追加した03-decision.mdを読み、wikiの関係するページと照合してください。 変更するページと変更理由を先に示してください。 確認後、決定事項を更新し、要望や未確認事項は区別して残してください。 重要な記述には、原資料のファイル名と見出しを付けてください。 最後に、変更したページ、変わった内容、人が確認すべき点を報告してください。 ``` AIが示した変更案を読み、意図に合っていれば更新を進めます。完了報告だけで済ませず、書き換わったページを開いてください。見る場所は、人数や金額などの判断に使う記述、出典、未決事項です。間違いがあったら戻せるように、更新前のコピーかファイルの変更履歴も残します。 次に質問するときは、「Wikiの目次から関係するページを読み、根拠付きで現在の募集人数を答えて」と頼みます。人数のように正確さが要る箇所は原資料も照合させます。回答から新しい比較表や検討メモができたら、人が確認した後でWikiへ追加できます。その際、AIの推測を元資料の事実と混ぜないようにします。 ## 放置せず育てるための更新と点検 新しい資料が届けば、取り込みと更新の処理が必要です。資料が届かなくても、未決事項が放置されていることはあります。そこで、質問に答えてもらう時間とは別に、Wiki全体を点検する時間を設けます。 ```text RULES.mdを読み、wikiを点検してください。 出典のない断定、ページ間の食い違い、未反映の決定、 根拠資料が訂正・撤回された記述を探してください。 疑わしい箇所と原資料を対にして示してください。 期限を過ぎた確認事項も挙げ、事実を確かめられない箇所は保留してください。 原資料やページを自動削除せず、修正案を返してください。 ``` 「二週間更新していないページ」を一律に古いと判断する必要はありません。会場の住所と、来週の募集人数では確認すべき頻度が違います。更新日は点検の手掛かりであり、その内容が正しいかどうかは根拠資料と対象期間で判断します。 ここまで手動で安定してから、定時実行を検討します。フォルダを作るだけでは毎日の取り込みは動きません。実行する時刻、対象フォルダ、終わった後に読む報告の保存先を設定し、予定どおり実行されたかを履歴で確かめます。 Coworkの定時実行も、クラウド上の資料だけを扱う場合と、PCのフォルダを扱う場合で条件が違います。後者はローカル実行となるため、対象のPCを起動し、デスクトップアプリを開いて接続しておく必要があります。自動で整理する範囲と、人が決定する範囲を分ければ、確認の負担を絞れます。 ## 繰り返し使う知識ほど整理の手間が返ってくる Wikiの更新では、質問する前に、資料を読み、関連ページを探し、文章を書き直す処理が走ります。質問時にも必要なページを読み、答えを組み立てます。「一度コンパイルすれば、その後の理解は無料になる」という説明では、この費用が抜け落ちます。 新しい資料を入れる頻度、触るページ数、使うAIによって維持の負担は変わります。一度しか読まない資料なら、必要な箇所を検索してもらう方が簡単でしょう。同じテーマを何度も検討し、判断の経緯まで引き継ぎたい場合には、整理を保存する意味が大きくなります。これは使いどころについての筆者の見立てであり、今回の小規模な実験で費用対効果を測ったわけではありません。 実装方法を選ぶときも、WikiとRAGを二者択一にする必要はありません。MicrosoftのGraphRAGは、資料中の関係や要約を事前に作り、質問時に使います。AnthropicのContextual Retrievalも、検索の前処理でAIが文脈を補います。RAGにも取り込み時に整理する設計があり、「RAGは毎回ゼロから、Wikiは一度だけ」という分け方では実際の選択肢を捉えきれません。 人が読んで確認するノートはWikiへ置き、根拠の細部や大量の資料は検索でたどる。その組み合わせなら、読みやすさと原資料へ戻る道を両立させられます。 rvaniaaa氏のX投稿には、50〜100件の資料で蓄積の価値が見え始め、3カ月たつと自分では気付かなかった情報同士のつながりをWikiが示す、といった説明もあります。しかし、資料数や経過月数だけで効果が決まる裏付けは確認できませんでした。始めるときの目安は、ノートの数よりも、「次の仕事で、前回の整理を使えたか」に置くのがよいと考えます。 たとえば次の打ち合わせで、決定事項と保留事項を説明し直さずに確認できるか。新しい資料を加えた後も、変更理由までたどれるか。一つのテーマでその二つを確かめれば、自分にとって育てる価値のある「第二の脳」かを判断しやすくなります。 ## 参照リンク 1. [Andrej Karpathy: LLM Wiki](https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f) 2. [AWS: RAGとは何ですか](https://aws.amazon.com/jp/what-is/retrieval-augmented-generation/) 3. [Anthropic: Claude Coworkを始める](https://support.claude.com/en/articles/13345190-get-started-with-claude-cowork) 4. [Anthropic: Claudeがあなたのプロジェクトを記憶する方法](https://code.claude.com/docs/ja/memory) 5. [Anthropic: Claude Coworkの繰り返しタスクを設定する](https://support.claude.com/en/articles/13854387-schedule-recurring-tasks-in-claude-cowork) 6. [Microsoft: GraphRAG](https://microsoft.github.io/graphrag/) 7. [Anthropic: Introducing Contextual Retrieval](https://www.anthropic.com/engineering/contextual-retrieval) 8. [rvaniaaa (@rvaniaaaa): The Second Brain Is Not a Storage System. It’s a Compiler.](https://x.com/rvaniaaaa/status/2090512486738845784) 2026年9月11日時点の公式資料を確認しています。仕様は更新される可能性があります。 --- © 知能圏 https://www.chinouken.com/articles/llm-wiki-second-brain