AIチャットとブログをObsidianに集約する――自分の環境に自分の知識基盤を作る
All eyes on 自分の知識基盤。
1. はじめに――そんなものに金を払う必要があるのか
先日、ClaudeのチャットをObsidianに保存する方法を紹介したnoteの有料記事を見かけた。
率直に言って、こんなものに金を払うのは情報弱者の証拠ではないかと思った。必要な道具は既にあるし、同じようなことを考えている人間はいくらでもいる。必要なのは、それらを組み合わせる設計であって、誰かの書いた手順書をありがたがって購入することではない。
もっとも、ぼくはその有料部分を読んでいない。だから、その記事の実装そのものを評価しているわけではない。問題は、そもそもこの程度の仕組みを構築するのに、特別なノウハウを買う必要があるのか、ということだ。
というわけで、自分で作ることにした。
しかもClaudeだけでは面白くない。ぼくが普段使っているChatGPT、Claude、Gemini、Google検索のAIモード、それに日本語記事を公開しているnoteと英語記事を公開しているWordPressまで、まとめて扱えるようにしたい。
各サービスに保存されている会話や記事を取り出し、Markdownに変換してObsidianに格納する。次回以降はIDを使って同一性を管理し、変更されたものだけ更新する。元のサービスで編集したものは、次の同期でObsidianにも反映させる。
要するに、自分の知的生産物を、サービスごとに分断された状態から、自分自身が管理する知識基盤へ集約するのである。
本稿では、その仕組みをどう設計し、何を使って構築したかを紹介する。プログラムの詳細なソースコードは掲載しない。OSもディレクトリ構成もデータ形式も読者によって異なるし、必要なコードはAIに書かせればよいからだ。
もしこの記事が役に立ったら、投げ銭でもしてくれ。
少なくとも、この話のために有料記事を買う必要はない。
2. なぜObsidianなのか――保存ではなく、再発見と再利用のために
ぼくは以前、「ChatGPTは優秀すぎるがゆえに知的生産ツールとして失敗している――対話の次が設計されていない」という記事を書いた。
そこで問題にしたのは、AIとの対話が保存できないことではない。保存されているにもかかわらず、過去の議論を再発見し、知的生産に再利用するための仕組みが貧弱なことだ。
長いチャットの中で、まともな議論が成立することはある。複数の問題が接続され、仮説が生まれ、反論を経て結論が修正される。その過程こそ価値がある。
ところが、後日それを再利用しようとすると、「あの話はどのチャットだったか」という探索から始めなければならない。サービス内検索はあっても、複数のAIを横断して検索することはできない。検索結果から必要な文脈を取り出すことも容易ではない。
ブログについても事情は似ている。
ぼくは日本語記事の公開先をnoteに集約し、英語版の選集をWordPressに置く構成へ整理した。ところが、公開先を整理したところで、全文検索の問題まで解決するわけではない。
実際、Googleの site:note.com/ressenti_man 検索を自分の記事の検索に使っていたが、Googleの検索結果はすべての記事を網羅するものではないし、インデックスされた記事の本文が常に最新版である保証もない。
それなら、全部手元に持てばいい。
ここで検討したのが、NotionとObsidianだった。
Notionにはデータベースとしての便利さがあり、共同編集やオンラインでの利用にも強い。しかし、今回ぼくが欲しかったのは、サービス上にもう一つ知識管理システムを構築することではなかった。
欲しかったのは、ローカルに実体を持つMarkdownファイルの集合と、それらを横断検索し、相互にリンクできる環境である。
Obsidianでは、Vault（保管庫）は基本的に普通のフォルダであり、その内部にMarkdownファイルが置かれる。ファイルはObsidian以外のテキストエディタでも扱える。さらに [[記事タイトル]] のような内部リンクによって、異なるノートを結びつけられる。
AIチャット、公開済み論考、未発表の研究メモ、読書ノートを、同じVaultの中で横断的に検索できる。必要ならAIにVault内のMarkdownを検索・分析させることも可能だ。
また、ローカルのファイルを全文検索するなら、Googleのインデックス登録状況に依存する必要がない。
Obsidianであることに絶対的な必然性があるわけではない。Markdownを管理できる別のソフトウェアでも同じ構造は作れる。しかし、ローカルファイル、検索、内部リンクという今回の要件に対して、Obsidianは既に必要な機能を備えている。
だから採用した。
なお、ぼくはWindows PC一台のローカル環境に構築した。複数端末で使いたいなら、別途同期の仕組みを設ければよい。
Obsidianには公式の有料同期サービス「Obsidian Sync」がある。一方、Google Driveなどを利用する方法も、Obsidian公式ヘルプのデバイス間同期ガイドに掲載されている。ただしGoogle Driveによる同期自体はObsidianの公式サポート対象ではなく、端末構成によっては補助ツールやプラグインが必要になる。
この点も既存の情報を参考にすればよい。注意すべきなのは同期競合やファイル破損であって、基本設計を一から考え直す必要はない。
そしてGoogle Driveを利用したとしても、今回の構成では、それはあくまで自分が管理する知識基盤の同期先である。公開サービスにある記事やチャットの原本とは、役割が違う。
3. 原本とレプリカを分ける――版管理の基本である
今回、ぼくは最初から一つの原則を決めていた。
Obsidianに取り込んだAIチャットやブログ記事は、読み取り専用として扱う。
これは技術的なアクセス制御ではなく、運用方針である。Obsidian側でもファイルは編集できるが、編集しないことにする。
ブログ記事を修正したいならnoteやWordPressで修正する。AIチャットから新しい考えを得たなら、元のチャットを書き換えるのではなく、別の研究メモや論考を書く。
なぜそうするのか。
ぼくはGitの世代というより、Visual SourceSafe（VSS）やConcurrent Versions System（CVS）の時代にプログラミングやシステム開発に関わっていた人間である。Subversion（SVN）になると、自分で使った記憶はあまりない。
とはいえ、ソースコードや文書のバージョンを管理するという考え方は、別に新しいものではない。
いつ、誰が、何を変更したのか。以前はどうだったのか。どの版が現在の有効な版なのか。それを管理するのは、ごく基本的な話である。
これは著述にもそのまま当てはまる。
発表した論考は、発表時点で他人の批評や引用の対象になる。その後、自分の考えが変わったり、間違いに気づいたりすることは当然ある。しかし、だからといって元の記事を黙って書き換えてよいとは思わない。
旧版を残したまま、訂正や改訂が分かる形で新版へ移行するのが望ましい。少なくとも変更の痕跡は必要だ。
これは抽象的な規範の話ではない。
実際、ぼくは過去に、他人の論考を批判した後、その相手が批判対象だった記事を書き換えてしまったという経験がある。
太郎丸二郎氏との「有限統合主義」をめぐるやり取りである。
ぼくの問題提起は単純だった。相手の文章を読んで批判した。その後、相手が元の記事を書き換えた。すると、後から現在の記事だけを読む第三者には、ぼくが存在しない文章を相手に批判していたように見えてしまう。
これは論争の勝敗以前に、記録管理としておかしい。
太郎丸氏は後の「哲学を名乗るなら、リングに立て」で、この問題について反省すべき点があると認めている。批評後の改稿によって、第三者には批評者が何を批判していたのか分かりにくくなったこと、当時は改稿履歴を意識していなかったこと、その後は運用を変えたことを明記している。
ぼくも「18ラウンド空振りして、当たったのはジャブ一発だった」で、その点を取り上げた。
「思想そのものは変わっていない」という弁解は、この問題に対する回答にならない。批評対象だった文章がどうなったのか、第三者が追跡できるかどうかが問題なのだ。
そしてこれは、哲学を名乗って議論しているかどうかに関係なく、公開されたテキストを扱う上での基本的な責任だと思う。
こうした記録を残す思想は、ITの用語ならImmutable Record（不変記録）、Append-only（追記専用）、Versioning（版管理）などに接続する。
ただし、今回実装したObsidian側のレプリカ自体がAppend-onlyになっているわけではない。
現行版のレプリカは、元サービスの内容が更新されたら上書きする。一方、元のエクスポートファイルは日付別に保存することで過去の状態を保全する。
つまり、現行版の検索用レプリカと、履歴を残すためのアーカイブは別物である。
厳密な版管理や過去版同士の差分表示まで必要になれば、さらにその仕組みを追加すればよい。今回の目的は、まず原本とレプリカを分離し、原本を勝手に編集しない運用を成立させることだった。
4. システム全体の構造――サービスの外へ知識を持ち出す
仕組み自体はそれほど複雑ではない。
データフロー図（DFD）として見ると、サービスプロバイダー側と自分の環境側の二つに分かれる。
サービスプロバイダー側には、ChatGPT、Claude、Gemini、Google AIモード、note、WordPressが存在する。それぞれが会話や記事を保持している。
自分の環境側では、エクスポートされたデータを受け取り、Markdownへ変換し、Obsidianへ取り込む。
取得形式はサービスごとに異なる。ZIP、XML、JSON、HTMLなどだ。そこで、それぞれの形式を解釈する変換処理を用意し、最終的にはMarkdownへ揃える。
このデータの流れを示したものが、掲載したシステム概要図の左側、DFDである。
一方、右側の概念モデルは、取得したデータをどのような単位で管理するかを示している。
サービスを表す SourceService があり、その下に記事や会話を表す SourceItem がある。添付ファイルがあれば Attachment として対応づけられる。
SourceItem を変換して生成するMarkdownファイルが ReplicaNote であり、それをObsidianの VaultFolder に格納する。
ここで最も重要なのは、SourceItemのIDとReplicaNoteのファイル名を分離することだ。
例えばnoteの記事を取り込んだ際、最初は記事IDをそのままファイル名にしていた。
しかし、それではObsidianのファイル一覧が意味不明な英数字で埋まってしまう。
そこで、
2026-10-07_記事タイトル.md
という形式へ変更した。
人間が見るファイル名は日付とタイトルでよい。しかし、プログラムが記事の同一性を識別するためには、noteの記事IDを使う。
WordPressなら投稿ID、AIチャットなら会話IDやスレッドIDを使えばよい。
記事タイトルが変更されても、同じIDであれば同一記事として扱える。記事本文が変更されれば、そのIDに対応するMarkdownを更新する。本文に変更がなければ何もしない。
これが差分同期の基本である。
なお、ここでいう概念モデルはデータベースの物理設計ではない。Obsidian内部にリレーショナルデータベースを構築したわけでもない。
データの同一性と関連を管理するために必要なエンティティを、クラス図に近い形式で整理したものだ。
その程度の設計であれば、読者が別のサービスを追加する場合にも流用できる。
5. 実際に構築したもの
最初に作ったのは、noteの記事をObsidianへ取り込む仕組みだった。
noteの公式エクスポートでZIPを取得する。内部のXMLから記事ID、タイトル、本文、公開日時、更新日時などを読み取り、Markdownに変換する。画像や添付ファイルは可能な範囲でローカルに保存し、記事側から参照できるようにする。
最初は記事IDをファイル名にしていたが、先ほど述べたように日付とタイトルを使う形式へ変更した。
次にWordPressである。
こちらは公式エクスポートからXMLを取得する。基本的な仕組みはnoteと変わらない。投稿IDで同一性を管理し、記事本文をMarkdownに変換してObsidianへ配置する。
ただし、WordPressの標準XMLには画像ファイル本体が含まれないことがある。そこで、今回の実装では画像は公開サイトのURLを参照する方式とした。
ブログ記事と並行して、AIチャットにも同じ考え方を適用した。
Claudeは公式エクスポートから会話データを取得する。GeminiとGoogle AIモードはGoogle Takeoutを利用する。ChatGPTについては、後述する理由でChrome拡張による取得へ切り替えた。
AIチャットのデータは、単純なブログ記事より構造が複雑である。
ユーザーとAIの発言が交互に記録されるだけではない。会話の分岐、再生成された回答、ツール呼び出し、添付ファイル、画像、場合によっては途中の処理情報まで存在する。
だから、JSONの中身を時刻順に並べればそれでよい、とは限らない。
会話単位の同一性を維持しながら、どの発言がどの会話に属し、どの添付ファイルがどの発言に対応しているかを保存する必要がある。
実際、Claudeのエクスポートでは、会話本文と添付ファイルの情報が必ずしも同じ形式で取得できるわけではなかった。そこで本文の変換とは別に、添付ファイルを回収・照合する処理も検討・実装した。
Google Takeoutも、GeminiとGoogle AIモードで出力形式が異なるため、それぞれの構造に合わせた解析が必要だった。
だが、これは本質的にはデータ取得層の問題である。
最終的にやりたいことは同じだ。
一つの会話を一つのMarkdownファイルとして保存し、会話IDを保持し、必要な添付ファイルを対応づける。そしてObsidianから全文検索できるようにする。
ローカル側では、AIチャットとブログ記事を別フォルダに格納した。
これによって、公開済みの記事と、まだ公開されていないAIとの思考過程を区別できる。同時に、同じVaultの中にあるため横断検索や相互リンクも可能になる。
保存されたチャットは、完成した論考とは違う。試行錯誤や誤りも含む思考の記録である。それを無理に整った文章へ書き換える必要はない。
むしろ、思考過程は思考過程として残し、そこから作った公開論考を別の成果物として管理する方が自然だと思う。
6. ChatGPTだけは公式エクスポートが使い物にならなかった
ここまで読めば、各サービスの公式エクスポートを使って、必要な変換処理を作ればよいだけだと思うだろう。
実際、大半はそうだった。
Claude、Gemini、Google AIモード、note、WordPressについては、公式機能でデータを取得できた。形式の違いや添付ファイルの扱いには面倒なところもあったが、取得そのものが長期間止まることはなかった。
ところが、ChatGPTだけは違った。
そもそもぼくは、前述の「ChatGPTは優秀すぎるがゆえに知的生産ツールとして失敗している」で、ChatGPTのUI設計を批判していた。
問題は、対話を通じて知識が生み出されるにもかかわらず、その知識を後で取り出し、別の知識と結びつけ、再利用するための導線が弱いことである。
DOMを含めたUI設計の問題でもある。必要なデータをユーザーが容易に選択、抽出、再構成できるようになっていない。
だから外部のObsidianで知識管理をしようと考えた。
ところが、公式エクスポートを申請すると、今度はそのデータが届かない。
2026年10月14日12時35分に申請したエクスポートが、10月22日になっても処理中のままだった。
OpenAIの公式ヘルプには、データの準備には最大7日かかる場合があり、7日を過ぎても届かなければサポートに問い合わせるよう案内されている。
ぼくはその通りに問い合わせた。
ところが、サポートから返ってきたのは、問題の所在を理解しているとは思えない回答だった。
こちらが問い合わせたのは、申請済みのエクスポートが届かず、処理状況も分からないという問題である。
それに対して担当者は、製品内のエクスポート機能を使ったのではないか、それでは会話の参照情報しか含まれないかもしれない、Privacy Portalから申請し直してはどうか、という趣旨の案内を返してきた。
そもそも、ぼくは不完全なエクスポートを受け取ったと訴えているのではない。
エクスポート自体が届いていないのである。
しかも公式ヘルプには、製品内のエクスポートで取得するZIPにもチャット履歴が含まれると明記されている。
ぼくが知りたいのは、申請が正常に受理されているのか、処理が進んでいるのか、停止しているのか、失敗したのか、なぜ7日を超えたのか、ということである。
それに対して実質的な回答がない。
さらに、既存の申請を調査せずに別経路からの再申請を案内するのは、既存リクエストが処理中なら完了を待てという公式ヘルプの説明とも噛み合っていない。
この状況では、公式エクスポートを定期的な知識管理の入力として使うことはできない。
1週間に一度同期したいと思っても、データを取得するだけで1週間以上かかる可能性がある。しかも所要時間を予測できず、問い合わせても状況が分からない。
これでは同期の設計以前の問題である。
ChatGPTの会話UIが知識の再利用に向いていない。その問題を回避するために外部へ持ち出そうとしたら、公式エクスポートも実用にならない。挙げ句、サポートまで問題を理解していない。
ぼくに言わせれば、ここはもうクソ認定である。
だから、公式エクスポートに固執するのをやめた。
7. 車輪の再発明をする必要はない――Chrome拡張を使えばいい
そこで代替手段を調べた。
当然、同じようなことを考える人間はいる。ChatGPTの会話をMarkdownで保存したい、全履歴を取得したい、添付ファイルも残したい、という需要がないはずがない。
実際、既にそのためのChrome拡張が公開されていた。
今回利用したのは、ChatGPT Markdown Export / AI Archiveという第三者製の拡張機能である。
ChatGPTのブラウザセッションから、取得可能な会話履歴をMarkdown、HTML、ZIPなどで保存する。画像や添付ファイル、会話データのJSON、変更のない会話をスキップする増分エクスポートなどにも対応している。
これならOpenAIの公式エクスポートが届くのを待つ必要がない。
ただし、Chrome拡張からの増分取得と、Obsidianへの差分同期は別の処理である。前者は取得する会話を絞り、後者は取得した会話をローカルの既存ファイルと照合する。
この二つを組み合わせればよい。
また、第三者製ツールだからといって無条件に信用してよいわけではない。会話内容を取得できる拡張機能には、それだけのアクセス権限が必要になる。ソースコード、権限、データの送信先、更新状況は確認すべきだ。
今回の拡張は開発元の説明ではブラウザ内でエクスポートを生成する方式だが、ChatGPTの非公開APIにも依存しているため、今後の仕様変更によって動作しなくなる可能性がある。
なお、この拡張には取得後の会話を削除するオプションもある。ぼくの目的は履歴の保存であって削除ではないので、当然これを使わない。
重要なのは、取得処理を全部自作する必要はないという点だ。
公式機能がきちんと動くサービスでは公式エクスポートを使う。そうでない場合は、既存のOSSやブラウザ拡張を探す。足りない機能だけ自分の環境に合わせて補う。
わざわざ車輪を再発明する必要はない。
8. コードではなく、何を作るかを設計する
ここまで読んで、「で、そのPythonコードはどこにあるのか」と思った人もいるだろう。
しかし、今回ぼくが示したいのは、コードの書き方ではない。
そもそも読者のOSも、Vaultの構成も、保存したいデータも違う。WindowsでPowerShellを使う人もいれば、macOSやLinuxでシェルスクリプトを使う人もいる。保存先も、ファイル名の付け方も、扱いたいサービスも異なる。
ここでぼくの環境に合わせたコードを大量に貼り付けても、それがそのまま他人の環境で動くとは限らない。
必要なのは、プログラムが満たすべき要件を定義することである。
例えば、ぼくがAIに伝えたのは、概ね次のような要求だ。
公式エクスポートのZIPやXMLを直接読み込み、記事・会話単位でMarkdownへ変換する。
サービス名と記事ID・会話IDの組で同一性を管理する。異なるサービス間でIDが重複しても混同しない。
ファイル名は日付とタイトルを使うが、元のIDはMarkdownのプロパティに保持する。
新規アイテムは追加し、既存アイテムは内容を比較して変更時だけ更新する。
同期元から消えたアイテムは、削除や取得失敗の可能性があるため、確認なしにローカルから消さない。
添付ファイル、画像、元URL、日時、公開状態を可能な範囲で保持する。
Obsidian側のファイルは読み取り専用レプリカとして扱い、元のエクスポートは別途保存する。
これを基本仕様として渡し、実際のエクスポートファイルを解析させ、サービスごとのデータ構造に合わせてプログラムを生成させた。
特別に高度なアルゴリズムが必要なわけではない。
ファイルを読み、データを変換し、識別子を照合し、差分を判定してファイルに書き込む。処理そのものは普通のプログラミングである。
実際、今回もPythonのスクリプトを作り、WindowsではPowerShellやCMDから起動できるようにした。
もちろん、AIが書いたコードが最初から正しく動くわけではない。
例えばPowerShellの日本語が文字化けして構文エラーになったこともあった。Obsidianのファイル名を記事IDにしてしまい、一覧の視認性が悪くなったこともあった。
その場合は、エラーや不都合をAIに伝えて修正させればよい。
ここで必要なのは、すべてのコードを自分で書けることではなく、何が正しい動作なのかを判断できることである。
プログラミングの基礎知識があれば、もちろん有利だ。データモデル、主キー、ファイル形式、バージョン管理、例外処理といった概念を理解していれば、AIへの指示も具体的になる。
しかし、それらを完全に理解していなければ何も作れない、という時代でもない。
仕組みを考え、必要な処理を分解し、AIに実装させる。そして結果を検証して直す。
今回のような個人用の知識管理システムなら、この方法で相当なところまで作れる。
むしろ、詳細コードを丸ごとコピーすることよりも、この作り方そのものを理解してもらった方が再利用性は高い。
9. 自分の環境で再現するには
読者が同じ仕組みを作るなら、最初から六つのサービスを全部扱おうとする必要はない。
まずObsidianをインストールし、Vaultを用意する。次に、自分が普段使っているAIサービスかブログサービスを一つ選び、公式エクスポートが利用できるか確認する。
取得したZIPやXMLをAIに渡し、その内部構造を調べさせる。どの単位が一つの会話や記事を表し、ID、日時、本文、添付ファイルがどこにあるのかを確認させる。
その結果に基づいて、Markdown変換プログラムを作らせる。
最初は全件を取り込めればよい。
次に、同じデータを再度読み込ませても重複を生成しないようにする。さらに、元のデータを変更した場合に、対応するレプリカだけが更新されるようにする。
その際、完全エクスポートと増分エクスポートを区別する必要がある。
完全エクスポートには原則として対象となる全件が含まれるが、増分エクスポートには新規・変更分しか含まれない場合がある。後者でファイルが見つからないからといって、元サービスで削除されたと判断してはいけない。
また、エクスポート自体が不完全な場合もある。取得できなかった添付ファイルや回答があれば、その事実を分かるように残すべきだ。
ここまで実装できたら、同じ構造を別のサービスへ展開すればよい。
サービスごとに必要な変換処理は異なるが、最終的な保存形式と差分管理の原則は共有できる。
なお、元のエクスポートデータには、個人情報や機密性の高い会話、添付ファイルが含まれる場合がある。実データを使ったプログラムの検証や、クラウドストレージへの同期では、その保存先とアクセス権限に注意したい。
特にクラウド同期はバックアップとは別物である。同期によって削除や破損まで伝播することがあるからだ。取得した元データを日付別に保管しておく意味はここにもある。
10. 今回作ったのは、知識そのものではなく知識基盤である
最後に、今回の仕組みを過大評価しないようにしておきたい。
AIチャットをすべてObsidianに格納したからといって、それが直ちに知識になるわけではない。
過去のチャットには、誤った情報も、検討途中の仮説も、撤回した主張も、思いつきの雑談も含まれている。
それらを全部保存するのは、すべてを正しいとみなすためではない。
後から参照し、検討し、必要に応じて新しい知的生産へ接続できるようにするためである。
Obsidianにデータが入った後、それをどのように検索し、関連づけ、再利用するかは、また別の問題だ。
そもそも、過去のAIとの対話を全文検索できることと、そこから意味のある知識を取り出せることも同じではない。
これは冒頭で触れたChatGPTの設計問題にもつながる。
ぼくが欲しかったのは、単なるチャットのバックアップではない。
過去に何を考え、何を調べ、どこまで議論し、どんな結論に至ったか。それをサービスを横断して検索でき、必要なら別の文章や議論へ接続できる、自分自身の知識基盤である。
今回は、そのための土台を構築したところまでを紹介した。
実際に使い込んで、何が便利で、何が足りず、どう改善する必要があるかは、別の記事で扱いたい。
少なくとも、特定のサービスのUIにすべてを委ねる必要はなくなった。
そして、この程度の仕組みを作るのに、詳細なコードを書く能力を必ずしも要求されないことも確認できた。
既存のツールを調べる。データの構造を理解する。保存と同期のルールを決める。必要なコードはAIに書かせる。
それでよい。
要するに、自分の知識を自分で管理するために必要なのは、特別な有料ノウハウでも、特定のプラットフォームへの忠誠でもない。
何をどう管理するかという設計と、それを実装する手段である。
Word up.
