※この記事は、2026年7月に自分のObsidian VaultをFableとCodexで監査した実運用メモです。自分の環境で行った一例であり、特定モデルの機能比較を目的とした記事ではありません。
ObsidianをAIが読む場所として使うようになってから、保存する情報はかなり増えました。
AIとの会話。
ブログの候補。
毎日の作業記録。
判断ルール。
調査結果。
一度保留にした企画。
別のAIへ渡したい引き継ぎ。
最初の頃は、情報を残せるだけでもかなり助かりました。
以前の話をもう一度説明しなくてもいい。
別のAIへ移っても、必要なメモを読んでもらえる。
過去ログから記事の種を拾える。
失敗した時は、次回のルールへ戻せる。
ただ、数か月運用すると、別の問題が出てきます。
情報がないのではありません。
情報は保存されているのに、今の入口から正しくたどり着けない。
さらに厄介なのは、古い入口ファイルやREADMEが残っていると、AIがそちらを「現在の案内板」だと思って読むことです。
そこで今回は、FableにObsidian全体を監査してもらいました。
ただし、最初から整理や修正までは頼んでいません。
まず地図を作る。
次に問題と根拠を出す。
最後に、直すならどう変えるかを差分案にする。
この順番です。
実際にやってみると、AIへ大量のノートを読ませる時ほど、いきなり編集権限まで渡さない方がよさそうだと感じました。
Obsidianは、保存量が増えるほど安心とは限らない
Obsidianへ情報を残していると、つい安心してしまいます。
原文はrawにある。
判断途中はworkbenchにある。
確定した方針はdecisionsにある。
AIが最初に読む入口ファイルもある。
ここまで分けていれば、かなり整理できているように見えます。
実際、自分も以前よりは探しやすくなりました。
ただ、AIから見ると、ファイルが存在することと、そこへ到達できることは別です。
たとえば、必要なメモがrawの奥に保存されていても、入口ファイルやREADMEからリンクされていなければ、普段の作業では読まれません。
反対に、もう使っていないフォルダのREADMEが「今後もここへ保存する」と書いたまま残っていると、AIは古い置き場所を現役だと思う可能性があります。
保存されていない。
保存されているが見つからない。
見つかるが内容が古い。
新しい情報と古い案内が矛盾している。
この四つは、似ているようで違います。
今回やりたかったのは、ノートをきれいに並べ直すことではありませんでした。
今の入口から読んだAIが、正しい情報へたどり着けるか。
そこを確認する監査です。
Fableには、まずVaultの地図だけを作ってもらった
今回、Fableを統括役にして、複数のWorkerへ見る範囲を分けました。
workbenchを見る役。
dailyを見る役。
rawを見る役。
知識や判断ルールを見る役。
投資など、別管理している領域を見る役。
一つのAIへ全部をまとめて読ませるのではなく、範囲ごとに見てもらい、最後にFable側で統合する形です。
出してもらったのは、次の七つでした。
- Vault全体のテーマ地図
- 繰り返している作業
- 保存済みだが到達しにくい情報
- 昔の記録を今読み直す候補
- プロジェクトをまたいで繰り返しているパターン
- スキル化できそうな作業
- 今後30日で価値が高そうな次の作業
ここで大事にしたのは、既存ノートを変更させないことです。
移動しない。
削除しない。
READMEを書き換えない。
判断ルールへ自動昇格しない。
まずは、AIがどう見えたかをレポートとして出してもらうだけにしました。
この段階なら、AIの解釈が間違っていても、既存の運用は壊れません。
監査で見つかったのは、散らかったファイルより古い案内板だった
監査結果で一番気になったのは、ファイル数の多さではありませんでした。
古い案内板です。
自分のVaultには、AIが最初に読む入口ファイルがあります。
ただ、それとは別に、以前使っていたAI向けの全体説明や、昔のブログ支援フォルダのREADMEも残っていました。
そこには、
以前よく使っていたAI。
当時の主なプロジェクト。
その頃の保存先。
今後の作業手順。
などが、現在形のまま書かれていました。
運用はすでに変わっています。
普段使うAIも変わりました。
ブログ支援の置き場所も変わりました。
止まっている企画もあります。
新しい入口ファイルもできています。
しかし、旧側には「この運用は終了した」「現在はこちらを読む」という案内がありませんでした。
人間なら、更新日や最近の作業を見て、
「これは昔の説明だな」
と判断できるかもしれません。
AIは、与えられたファイルにそれらしい指示が書いてあると、現在の前提として扱うことがあります。
新しい情報が足りないだけではありません。
古い情報が、今も有効に見える。
これは、AIにObsidianを読ませる時の別の怖さだと思いました。
保存したのに使われない情報も見つかった
もう一つ見つかったのが、保存されているのに入口からたどり着きにくい情報です。
rawには長い会話や音声メモが残っています。
作業レポートもあります。
ただ、一部は索引へ載っていませんでした。
自動収集した引き継ぎ候補も、20件以上が未精査のまま残っていました。
収集する仕組みは動いている。
でも、その後の、
読む。
採用する。
保留する。
別の場所へ移す。
不要と判断する。
という精査工程が止まっていました。
これは以前から薄々感じていたことです。
自動収集を作ると、情報は増えます。
Inbox整理を頼めばrawへ退避できます。
会話から重要そうな内容を候補として抜けます。
外部資料から確認カードも作れます。
ただ、候補を作るところだけ自動化しても、確認する人間の時間が増えるわけではありません。
監査では、複数の領域が同じ場所で止まっていると指摘されました。
収集は回る。
精査で止まる。
これはObsidianだけではなく、AI運用全体に共通するボトルネックなのかもしれません。
監査レポートも、そのまま正しいとは限らない
もちろん、Fableが出した監査結果を、そのまま確定事項にはしていません。
レポートには、実際のファイルから確認できることと、AIが時系列から推測したことが混ざっています。
たとえば、
このプロジェクトは自然消滅したのではないか。
ブログの日課が、別の企画へ使う時間を吸収しているのではないか。
別々の分野で、同じ判断の仕組みを作っているのではないか。
こうした話は、かなり面白いです。
自分では気づいていなかった接続もありました。
ただし、面白いことと、確定していることは別です。
だから監査レポートでは、
実ファイルから確認できること。
後から人間が確かめる必要があること。
AIの仮説。
この三つを分けてもらいました。
AIに大量のログを読ませると、筋の通った物語を作ってくれます。
その物語が、自分の実感にかなり近いこともあります。
でも、筋が通っているから正しいとは限りません。
監査AIにも、監査が必要です。
七つのレポートから、すぐ直す候補を二つだけ選んだ
監査では、多くの改善候補が出ました。
索引へ載っていないファイルを追加する。
未精査候補をまとめて確認する。
古いプロジェクトの状態を直す。
新しいスキルを作る。
週次レビューを再開する。
止まっている企画を正式に休眠させる。
どれも、それなりに意味があります。
ただ、全部を一気に始めると、今度は監査結果の処理だけで一日が終わります。
そこで、最初は低リスクな二つだけを選びました。
一つ目は、古い全体説明へ注意書きを追加し、現在の入口ファイルを先に読むよう案内すること。
二つ目は、すでに使わなくなったブログ支援フォルダのREADMEへ、運用終了と現在の移行先を示すこと。
どちらも、既存の原文を消す必要はありません。
昔の記録は残したまま、
「これは当時の説明です」
「現在はこちらを読んでください」
と一行の墓標を置けば済みます。
新しい仕組みを作るより、旧側へ移行先を書いておく。
これだけで、AIの誤誘導をかなり減らせそうです。
Codexには、修正ではなくdry-runを頼んだ
Fableの監査結果から二つを選んだ後、Codexへ渡しました。
ただし、
「この二つを修正して」
とは頼んでいません。
「反映するなら、どこへ何を追加するか。まだ編集せず、差分案だけ作って」
と頼みました。
Codexが作ったのは、実ファイルの変更ではなくdry-runです。
古い全体説明のどこへ注意書きを入れるか。
注意書きには何を書くか。
昔のブログ支援READMEへ、どんな墓標を置くか。
frontmatterの状態まで変える必要があるか。
ここまでを一つの提案ファイルにまとめました。
まだ元ファイルは変えていません。
この順番なら、人間側で差分を読み、
この表現は強すぎる。
これは今も一部使っている。
statusまでは変えなくていい。
本文の注意書きだけで十分。
と判断できます。
AIに全体監査を頼み、そのまま修正まで連続実行させることもできます。
ただ、自分のVaultには、ブログ、投資、仕事、家庭、過去の企画など、公開範囲も重要度も違う情報が混ざっています。
一度の誤解で大量に移動・上書きされるより、監査と変更を分けた方が安心です。
「地図→問題→差分案」に分けると、人間の確認場所が見える
今回の流れを簡単にすると、三段階です。
1. 地図
何がどこにあるか。
今どのテーマが動いているか。
入口はどこか。
昔の仕組みと新しい仕組みがどう重なっているか。
まず全体像を作ります。
この段階では、良い悪いを急いで決めません。
2. 問題
古い入口。
索引漏れ。
到達しにくい情報。
自動収集後に止まっている精査。
現在形のまま残った昔のプロジェクト。
問題を根拠ファイルと一緒に出します。
AIの仮説なら、仮説と書きます。
3. 差分案
何を削除するかではなく、最小限どこへ何を足せば誤誘導を止められるかを考えます。
いきなり反映せず、dry-runを作ります。
人間は、この差分案だけを読めばいい。
数百のファイルを一から読み直すより、確認場所をかなり絞れます。
この三段階に分けることで、
Fableは広く読む。
Codexは変更案へ落とす。
人間は反映するか決める。
という役割分担も分かりやすくなりました。
AIにObsidianを整理させる話とは少し違う
AIにObsidianを整理してもらうというと、ファイルを分類したり、フォルダを作ったりする話を想像しやすいと思います。
今回やったことは、少し違います。
ノートを移動していません。
フォルダ構成も変えていません。
古いメモも削除していません。
確認したのは、
今のAIがどの入口から読むか。
その入口から必要な情報へ届くか。
昔の案内が現在の運用と矛盾していないか。
収集した情報が精査まで進んでいるか。
という運用の状態です。
Obsidianを人間用のきれいな本棚として見るなら、フォルダの見た目が大事です。
AIが読む外部コンテキストとして見るなら、入口とリンクと更新状態の方が重要になります。
ファイルが多少散らかっていても、正しい入口から必要なものへ届けば使えます。
反対に、フォルダがきれいでも、古いREADMEが現在形で残っていれば、AIは迷います。
今回の監査で見たかったのは、こちらでした。
監査も、一度作れば終わりではなさそう
今回、Vault全体を監査してもらい、かなり多くの改善候補が出ました。
ただ、全部をすぐ直すつもりはありません。
重要度が低いものもあります。
AIの仮説にすぎないものもあります。
今のままで困っていないものもあります。
人間が決めないといけないものもあります。
まずは、古い入口による誤誘導を止める。
次に、未精査候補を少しずつ確認する。
索引漏れは、必要な範囲から直す。
大きな移動や統合は、その後です。
以前、深いアーカイブから過去ログを拾う時、全部を一気に見るのではなく、一日一件だけ確認する運用にしました。
今回の監査結果も、同じ考え方で扱う方がよさそうです。
AIは大量に問題を見つけられます。
でも、人間が確認できる量は急には増えません。
だから、監査結果まで一度に処理しようとしない。
ここも大事だと思います。
まとめ
ObsidianをAIの外部コンテキストとして使うと、時間がたつほど情報は増えます。
ただ、問題は保存量だけではありません。
古い入口が現役に見える。
保存した情報が索引から漏れる。
新しい運用へ移ったのに、旧側へ墓標がない。
自動収集は動いていても、精査で止まる。
こうしたズレが積み重なると、AIは情報を持っているのに、古い前提で動くことがあります。
今回、自分はFableにVault全体を監査してもらいました。
ただし、最初から修正はさせませんでした。
まず地図を作る。
次に問題と根拠を出す。
最後にCodexで差分案だけ作る。
人間が確認してから反映する。
この順番です。
AIにObsidianを監査させるなら、いきなりきれいにしてもらうより、
地図→問題→差分案
に分けた方がよさそうです。
情報を残す仕組みだけでなく、古くなった入口を見つける仕組みも必要になる。
共通メモリを作った後には、共通メモリの保守が待っていました。
コメント