はじめに
Obsidianを長く使っていると、人間が読むためのノート、AIに渡したい作業ログ、Pythonが処理するためのファイル、画像などのAssetが同じVaultの中に増えていく。
人間用の日報には主観や未整理のメモが入る。Assetには画像や資料が入る。.obsidian のプラグイン設定には認証情報が入ることもある。これらをAIに丸ごと読ませるのは、便利そうに見えて雑である。
今回はObsidian Vaultを「人間が読む場所」と「AI・Pythonが処理する場所」に分ける設計を調査し、実際に運用できるところまで整えた。
AIにはVault全体を読ませず、90_System/output に生成した入口ファイルとContext Packだけを読ませるように変更した。
- はじめに
- きっかけ
- 最終的な役割分担
- AI_START_HEREを作った
- 旧Daily Logは移動せずコピーした
- プラグインあり版の運用基盤も作った
- セキュリティ上の注意
- Before / After
- 次にやること
- まとめ
きっかけ
初期状態は以下。
人間用フォルダ = 日本語OK・見やすさ優先 システム用フォルダ = 英数字固定・自動処理優先
人間が使う場所は、日本語フォルダ名のほうが分かりやすい。たとえば 00_人間用/日報、20_Assets/画像 のようにしておくと、Obsidian上で見たときに迷いにくい。
一方で、PythonやAIエージェントが処理する場所は英数字で固定したほうが安定する。日本語パスが悪いというより、自動処理の対象範囲を狭く、機械的に扱える形にしたい。
だから方針はこうした。
人間が読む・書く場所は日本語で見やすくする。 AI・Pythonが処理する場所は英数字で固定する。 AIにはSystem/outputのContext Packだけ渡す。
最終的な役割分担
今回の設計では、Vault内をざっくり次のように分けた。
<VAULT_PATH>/ ├─ 00_人間用/ │ ├─ 日報/ │ ├─ 週報/ │ ├─ 月報/ │ ├─ メモ/ │ ├─ 資料/ │ └─ レビュー待ち/ │ ├─ 20_Assets/ │ ├─ 未整理/ │ ├─ 画像/ │ ├─ 資料/ │ ├─ 出力/ │ └─ アーカイブ/ │ ├─ 50_Workspace/ │ ├─ Draft/ │ ├─ Review/ │ ├─ Approved/ │ └─ Rejected/ │ └─ 90_System/ ├─ config/ ├─ indexes/ ├─ logs/ ├─ output/ ├─ scripts/ └─ templates/
ポイントは、00_人間用 と 20_Assets をAIが直接読む場所にしないことだ。
AIが読む入口は、原則として 90_System/output に限定する。
90_System/output/AI_START_HERE.md 90_System/output/context_pack.md 90_System/output/asset_context_pack.md
この3つを中心にすれば、AIに渡す情報をかなり制御しやすい。
図にすると、今回の分離はこうである。
Obsidian Vault
├─ 00_人間用
│ └─ 人間が読む・書く
│ ├─ 日報
│ ├─ 週報
│ └─ メモ
│
├─ 20_Assets
│ └─ 人間が管理する素材置き場
│ ├─ 画像
│ ├─ 資料
│ └─ 未整理
│
└─ 90_System
└─ AI・Pythonが処理する場所
├─ logs/ai_daily
├─ output/context_pack.md
└─ output/asset_context_pack.md
AI_START_HEREを作った
今回の大きな成果は、AIが最初に読む入口ファイル AI_START_HERE.md を用意したことである。
これは、AIにVault全体を読ませる代わりに、最初に読むべきルールと現在の運用状態をまとめたファイルである。
内容としては、次のようなルールを入れた。
Vault全体を丸読みしない。 .obsidian/ を読まない。 04_Archive/ を読まない。 00_人間用/ を直接読まない。 20_Assets/ のraw fileを直接読まない。 APIキー、OAuthトークン、認証情報の値を表示しない。 人間の日報とAIの作業ログを混ぜない。 AIに渡す情報は原則として 90_System/output/ の生成物に限定する。
これはかなり重要である。
AIに「このVaultを見て」と雑に言うと、必要以上に読む可能性がある。最初に読むファイルを決めておけば、「どこを読んでよいか」「どこを読んではいけないか」が明確になる。
AIに読ませる流れはこうした。
AI ↓ 90_System/output/AI_START_HERE.md ↓ 90_System/output/context_pack.md ↓ 90_System/output/asset_context_pack.md ↓ 必要な場合だけ、ユーザーが指定したファイルを読む
逆に、通常時はこの流れから外れる場所を読まない。
人間の日報とAI作業ログを分けた
それは、人間の日報とAIが書く作業ログを分けることだ。
最初は 02_Logs/Daily にAIセッションの記録も入っていた。これは動くには動く。だが、人間の日報とAI作業ログが混ざると、あとで読み返すときにつらい。
人間の日報には、生活ログ、気分、作業前の迷い、まだ整理されていないメモが入る。一方でAI作業ログは、何を実行したか、どこで詰まったか、次に何をすべきかを機械的に残したい。
なので、保存先を分けた。
人間の日報: 00_人間用/日報/ AIの作業ログ: 90_System/logs/ai_daily/ AIに渡す要約: 90_System/output/context_pack.md
これで、AIは人間の日報を直接読むのではなく、AI作業ログから生成したContext Packを読む形になる。
分離後のログの流れはこうである。
人間の日報 00_人間用/日報/ ↓ 人間が読む・必要なら後で要約する AI作業ログ 90_System/logs/ai_daily/ ↓ 90_System/output/context_pack.md ↓ AIが次回作業の前提として読む
旧Daily Logは移動せずコピーした
既存の 02_Logs/Daily には、過去のAI作業ログとDaily Notesテンプレートが混ざっていた。
ここでいきなり移動や削除をすると危ない。リンクが壊れたり、日報テンプレートやGoogle CalendarブロックまでAI作業ログ側に混ざったりする。
そこで、旧ファイルは残したまま、必要なAI作業ログだけを新しい場所へコピーした。
旧: 02_Logs/Daily/ 新: 90_System/logs/ai_daily/
実行時には、2026-06-07 の旧日報から Codex Session だけをコピーし、google-calendar コードブロックは除外した。
この判断はかなりよかった。過去ログを壊さず、AI作業ログ側だけきれいにできる。
Context Packの入力元も切り替えた
AIが作業開始時に読む context_pack.md は、人間の日報ではなく、AI作業ログを参照するようにした。
90_System/logs/ai_daily/ ↓ 90_System/output/context_pack.md ↓ AIが参照
これにより、人間の日報をAIに直接読ませずに済む。
また、週報生成も 90_System/logs/ai_daily をソースにするよう確認した。
実行時には、context と weekly を並列で動かすとログファイルへの同時書き込みでファイルロックが起きた。なので、今後は順番に実行するのがよい。
context生成 ↓ weekly生成
Assetも直接読ませない
画像や資料の扱いも整理した。
Vaultには既存の asset/ フォルダがあり、棚卸ししたところ以下の状態だった。
asset/: 55 PNG files, 99.54 MB 20_Assets/: 3 Markdown files, 2.2 KB referenced asset files: 2 unreferenced asset files by Markdown scan: 53
Markdownから参照されていた画像は2件だけだった。
つまり、旧 asset/ は大容量の画像置き場になっているが、AIが最初に読む必要はない。
そこで、AIには画像ファイルそのものを読ませず、Asset Recordから生成した asset_context_pack.md だけを渡す方針にした。
20_Assets/**/*.md ↓ type: asset_record status: active ai_use: yes ↓ 90_System/output/asset_context_pack.md
この形なら、「AIに使ってよいAsset」だけを選べる。
Assetまわりの流れはこうなる。
20_Assets/画像・資料 ↓ 人間が必要な素材だけAsset Record化 ↓ type: asset_record status: active ai_use: yes ↓ 90_System/output/asset_context_pack.md ↓ AIが素材情報だけ読む
プラグインあり版の運用基盤も作った
今回のセッションでは、Obsidianのプラグインを前提にした運用基盤も整えた。
作ったものは以下。
50_Workspace/Draft50_Workspace/Review50_Workspace/Approved50_Workspace/Rejected- Dataview確認ページ
- 標準Templates用テンプレート
build_asset_context_pack.pyasset_context_pack.md- プラグインのセキュリティ判断メモ
.gitignore
セキュリティ上の注意
この設計では、AIに読ませない場所を明確にすることがセキュリティ対策になる。
特に読ませない場所は以下。
.obsidian/ 04_Archive/ 00_人間用/ 20_Assets/ raw files 90_System/assets/raw/ Vault全体
.obsidian/plugins/*/data.json には、OAuthトークンやAPIキー系の設定が含まれることがある。
したがって、AIが通常読む対象から .obsidian を外すのは必須である。
また、Git管理を考える場合も注意が必要だ。今回 .gitignore を用意し、秘密情報、生成物、raw asset、人間用原本をGit管理対象から外す方針にした。
AI運用で怖いのは、AIが悪いというより、人間が「読ませてはいけないもの」を読ませてしまうことだ。だから、入口を絞るのが大事になる。
Before / After
導入前はこうだった。
人間の日報、AI作業ログ、Asset、System出力が混ざりやすい AIにどこまで読ませるかが曖昧 旧Daily LogにAIログとDaily Notesテンプレートが混在 Assetフォルダの参照状況が不明
導入後はこうなる。
人間の日報は 00_人間用/日報 AI作業ログは 90_System/logs/ai_daily AIの入口は AI_START_HERE.md AIに渡す情報は context_pack.md / asset_context_pack.md 旧Daily Logは legacy として残す AssetはRecord化したものだけAIに渡す
かなり見通しがよくなった。
特に「AIにVault全体を読ませない」と決めたのが大きい。これは安全性だけでなく、AIの作業精度にも効く。読む場所が少ないほど、余計な情報に引っ張られにくい。
なお元々はindex作成して軽い運用にしようとしていた。Googleスプレッドで管理する方法もあったが、外部にやると煩雑になるし、出来れば一元管理したかったのでこうなった。
次にやること
残っている作業は、だいたい次のあたりである。
- サンプルAsset Recordを実素材のAsset Recordへ置き換える。
- Gitを実際に
git initするか判断する。 - Templater / Obsidian Git plugin の導入条件を再評価する。
- Obsidian本体でDaily Note作成テストを行う。
個人的には、次はAsset Recordの実素材化がよさそうだ。
せっかく asset_context_pack.md の仕組みを作ったので、まずは実際に参照されていた画像2件をAsset Record化する。そこまでやると、AssetをAIに渡す流れが机上の設計ではなくなる。
まとめ
Obsidian VaultをAIと一緒に使うなら、人間用とシステム用は分けたほうがよい。
今回の最終方針はこれである。
人間が使う場所は日本語で見やすくする。 AI・Pythonが処理する場所は英数字で固定する。 AIには 90_System/output の生成物だけ渡す。
さらに、AIが最初に読む AI_START_HERE.md を作ると、運用の事故が減る。
Obsidianは自由度が高いぶん、何でも同じ場所に置けてしまう。だからこそ、AIに読ませる前提なら、最初に「読んでよい場所」と「読ませない場所」を分けて考えた方が事故が少なく、情報の検索や再現性もます。ました。
後はasset管理なんだが……多分これが一番面倒ではある。元々は勉強用の資料を入れ込む場所として作成していたので整理がされていない。canvasで使用していればいいというゆるい扱いでったので、これもルールを決めないといけない。
なんだか大変なことになってしまった。
