1. はじめに：きっかけは「ClaudeにObsidianを読ませたい」だった
私は現在、大学で「起業部」や「DCC（デジタルクリエイターコミュニティー）」など、性質の異なる3つの学生団体の部長を兼任しています。所属する部員は合計で100人近く。日々の活動、イベントの企画、企業との連携など、常に数え切れないほどのプロジェクトが同時並行で走っています。
部員から飛んでくる質問への回答、意思決定、タスクの割り振りをこなすだけで、私の脳のキャパシティは完全に限界を迎えていました。「あのプロジェクトの進捗どうなってたっけ？」「あの時、AIと壁打ちして決めた技術選定の理由はなんだっけ？」——そんな風に、過去の自分の思考や決定事項を思い出すことすら困難になっていたのです。
最初から「AI部長」なんていう大それたものを作ろうとしていたわけではありません。きっかけはもっと個人的で地味なものでした。ちょうどClaudeがMCP経由で外部のデータソースに接続できるようになっていて、「自分の活動記録やメモをどこかにまとめておいて、それをClaudeにMCP経由で読ませれば、いつ話しかけても自分の文脈を踏まえた壁打ち相手になってくれるはずだ」というのが最初の発想でした。ツールとして選んだのは、ローカルでMarkdownファイルを管理できる Obsidian です。MCP経由でClaudeに参照させる前提なら、プレーンテキストのMarkdownで一箇所にまとまっているのが一番都合が良いと考えました。
Obsidianとは
念のため、前提として「Obsidian」について簡単に説明しておきます。
Obsidianは、Markdown形式のテキストファイルでメモを管理するノートアプリです。クラウドのサービスと違い、ノートの実体はすべて自分のPC上にローカルのファイルとして保存されるのが最大の特徴で、1つのフォルダ（Vaultと呼びます）がまるごと自分のナレッジベースになります。
ノート同士をリンクでつなげる：[[ノート名]]と書くだけで別のノートを参照でき、メモ同士が網の目のように繋がっていきます
グラフビュー：リンクの繋がりを可視化して、ノート全体の関係性を俯瞰できます
YAMLフロントマター：ノートの先頭にタグやステータスなどのメタデータを構造化して埋め込める
プラグインで拡張可能：コミュニティ製のプラグインで検索性やタグ管理を強化できる
ローカルファイルであること：AIエージェントやスクリプトからも、ただのMarkdownファイル群として自由に読み書きできる
実際の画面
この「実体はただのローカルMarkdownファイル」という性質こそが、後述するAIエージェントによる一括処理（タグの書き換えやファイルの分割・要約）を可能にした鍵でもあり、同時に今回の「大惨事」の原因にもなっています。
そこで、Claudeに読ませるための材料として、自分の思考プロセスや活動履歴をすべて一箇所に集約する 「第二の脳」 づくりを始めました。
集約の対象としたデータソースは、私の日々のインプット・アウトプットのすべてでした。
| データソース | 内容 |
|---|---|
| Gemini / Claude のチャット履歴 | 起業アイデアの壁打ち、技術調査、意思決定の過程 |
| 録音メモ（文字起こし） | 授業・MTG・独り言の録音を自動文字起こししたもの |
| NotebookLM のソース | 授業資料やPDFをまとめていたもの |
| 手書きのメモ・議事録 | 起業部やDCCの活動記録 |
「これらのデータをすべてObsidianのフォルダに突っ込めば、Claudeに読ませる最強のナレッジベースができるはずだ」——最初はその程度の、あくまで自分一人のための効率化ツールという位置づけでした。
2. データ収集フェーズ：Google Takeoutの無慈悲な罠
「第二の脳」構築の第一歩は、私の思考の大部分が眠っている「AIとのチャット履歴」のインポートでした。
特に、日々の意思決定の壁打ち相手として愛用していたGeminiのデータをエクスポートするため、Googleのマイアクティビティ（Google Takeout）機能を使用しました。手順自体は簡単で、Googleアカウントの設定から「Geminiでのアクティビティ」を選択してエクスポート申請を出すだけです。
しかし、数時間後に届いたエクスポートデータをダウンロードした私は、その無慈悲な構造に絶望することになります。
降ってきたのは、綺麗に整理されたJSONデータでも、日毎に小分けされたテキストファイルでもありませんでした。それは、 「これまでの全チャット履歴が1本の木構造のように結合された、数万行に及ぶ単一の巨大HTMLファイル」 だったのです。
この巨大HTMLは、テキストエディタで開くだけでフリーズし、ブラウザでスクロールするのすら重いという「ファイルという名の怪物」でした。当然、そのままObsidianのディレクトリに放り込んで検索やリンクを活用することなど不可能です。
ちょっと見にくいと思うけどずっとこんな感じ。右のスクロール長すぎでしょ笑
確か4万チャットぐらいあった
3. 最初の挑戦：AIエージェント agy との共同開発、そして「20万文字の壁」
この怪物を人間が手作業で解体するのは不可能です。そこで私は、私のコーディングをサポートしてくれるAIエージェント Antigravity（以降agy）に協力を仰ぎました。
「この巨大なHTMLファイルをパースし、会話のセッションごとに分割して、それぞれ適切なMarkdownファイルとして書き出すPythonスクリプトを書いてくれ」
agy は優秀でした。BeautifulSoupなどのライブラリを駆使し、HTMLの特定のクラス名（会話の区切り）をフックにして、セッションごとにMarkdownファイルを生成するスクリプトを一瞬で書き上げ、実行してくれました。
「これで会話ごとに綺麗に分かれたノートが手に入った！」と私は喜びました。
しかし、生成されたMarkdownファイルをObsidianにインポートした瞬間、再び目の前が真っ暗になります。
切り分けられたチャット履歴のファイルサイズを確認すると、 1ファイルあたり20万文字を超える巨大なMarkdownファイル が量産されていたのです。
原因は明白でした。私は「1つのチャットスレッド」を使い回し、何日も、あるいは何週間もかけて起業アイデアやプログラムの設計についてGeminiと壁打ちし続けていたのです。会話セッションごとに分けたところで、元のスレッドが長大すぎれば、生成されるファイルも巨大なモノリスのまま。
中身は例文であるが、右下を見てほしい
10万から20万文字のファイルが量産されてしまった
Obsidianの検索機能は「ファイル単位」でヒットするため、20万文字のファイルがヒットしても「その中のどこに欲しい情報があるのか」を特定できません。さらに、この巨大ファイルをAIに読ませてコンテキストにしようとすると、コンテキストウィンドウがパンクしてまともな回答が得られないという、ナレッジベースとして完全に本末転倒な状態になってしまいました。
4. 13GBの音声データと「📄 録音メモ」が引き起こしたグラフの汚染
さらに状況を悪化させたのが、もう一つの主要データソースである「録音メモ」でした。
大学の講義やミーティング、独り言を録音した音声データの総量は 13GB に達していました。これらを自動文字起こししてObsidianに取り込んでいたのですが、インポート時のファイル名処理とOS側の連番保存バグにより、ファイル名が、
📄 録音メモ 📄 録音メモ 10月2日_📄 録音メモ 10月2日_📄 録音メモ 10月2日.md
のように狂ったように重複・肥大化して生成されてしまったのです。
フォルダ内は意味不明な超長ファイル名で埋め尽くされ、Obsidianの機能である「グラフビュー」を開くと、数点のハブノートの周りに、中身の薄い巨大な「録音メモ」のモノリスが重力崩壊したブラックホールのように張り付いているだけという、見るに堪えない惨状になっていました。
この混沌としたフォルダ全体をそのままGeminiなどのAIに読み込ませて分析させようとしたところ、AIは完全にキャパシティを超え、 「大学の講義運営のノートなのに、なぜかメタバースや患者会の作り方について語り出す」 といった、凄まじいハルシネーションを吐き出す始末でした。
5. アトミックノート化への決断と、スペックの壁
ここにきて、私はようや気づきました。
ナレッジベースとは、ただデータを物理的に集める場所ではありません。
知識管理の理想である「アトミックノート」——すなわち、「1つのノートには、1つのアイデアやトピックだけを書き、サイズは数千文字以内に抑える」という設計思想に沿って、すべてのノートを再編成しなければ、AI連携はおろか、人間が検索するデータベースとしても機能しないという現実に直面したのです。
これを実現するためには、以下の処理を自動で行う強力なバッチ処理パイプラインが必要でした。
- 数十万文字の巨大ファイルを、意味の区切り（見出しやトピック）ごとに数千文字単位で物理的にスライスする。
- 分割された個々のノートに対し、LLMを走らせて「2〜3行の簡潔な箇条書き要約」を生成する。
- 要約と元のノートへのリンクを記述した「要約ファイル」を自動生成し、Obsidianのフロントマターとリレーションを100%綺麗に整備する。
ロジックは完璧です。しかし、ここで最後の物理的な壁が立ちはだかります。
文字起こしデータと膨大なチャットログ、合計13GBに及ぶテキストを処理するためにLLMの推論を回し続けるには、膨大な計算資源が必要になります。
私の手元にあるMacBook Pro 1台でこのバッチ処理を回せば、処理が完了するまでに数週間、あるいは数ヶ月かかることは火を見るより明らかでした。クラウドAPIを使うにしても、このトークン量では何万円吹っ飛ぶか分かりません。
「手元のMacBookではパワーが足りない。クラウドAPIは高すぎる。」
途方に暮れる私でしたが、ふと、ある場所に目を向けました。
「そうだ、部室に行けば、ハイスペックなゲーミングPCが何台も転がっているじゃないか」
この瞬間、部室のGPUパワーを結集した「ローカルAIクラスタ構築」という、狂気のプロジェクトが幕を開けたのです。
（ちなみに、この後改めてタグの状態も点検してみたところ、1,520ファイル・アクティブタグだけで545種類という、こちらも輪をかけて無秩序な状態でした。中編は、このタグの再設計とローカルAIクラスタ構築を並行で進めていく話です。）