ObsidianでAI運用を続けるための人間用マニュアルを作る方法 - すくらっぷ　あんど　びるどー（したい）

はじめに

Obsidian VaultをAIと一緒に運用していると、仕組みそのものが少しずつ育っていく。

日報を分ける。AI作業ログを分ける。Assetを台帳化する。Mapを中間レイヤーにする。エラー台帳を作る。Context Packを生成する。

便利になる一方で、別の問題も出てくる。

それは、人間が運用ルールを忘れるという問題である。

AI用の入口ファイルやSystem側のマニュアルは作っていた。しかし、それらはAIやスクリプトが読むための説明であり、人間が日常的に読むには少し硬い。

そこで今回は、Obsidian Vaultの上位に、人間が読むためのユーザーマニュアルを作った。

結論から言うと、AI運用の仕組みが複雑になってきたら、人間用の「最初に読む場所」を別に作ったほうがよい。

はじめに
マニュアル作成の完成図
前提環境
なぜ作ったか
全体構成
作ったもの
実行結果
詰まったところ
セキュリティで注意したこと
Before / After
まとめ

マニュアル作成の完成図

今回作ったのは、Obsidian Vault内で迷ったときに最初に開く入口である。

今までは運用ルールが複数の場所に散らばっていて、AI用の説明はあるが、人間が読むには内部仕様に寄っていた。日報、Map、Asset、エラー台帳の扱いを毎回思い出す必要がある。

今回作成したものによって、マニュアルだけを読めばよいことになった。

完成後の入口は、次のような構成にした。

00_ユーザーマニュアル/
├─ README.md
├─ 00_最初に読む.md
├─ 01_全体像.md
├─ 02_毎日やること.md
├─ 03_AIに頼むときのルール.md
├─ 04_Mapの使い方.md
├─ 05_Assetの扱い方.md
├─ 06_エラー記事とエラー台帳.md
├─ 07_ブログ記事化.md
├─ 08_セキュリティと禁止事項.md
├─ 09_困ったとき.md
└─ 10_コマンド一覧.md

「全部読む」のではなく、「今困っている項目だけ開く」形にする。

前提環境

この記事の前提は次の通りである。

項目	内容
OS	Windows
シェル	PowerShell
AIツール	Codex
ローカルLLM	今回は未使用
関連ツール	Obsidian、Markdown、blogsync
対象サービス	Obsidian Vault、はてなブログ
実行場所	Obsidian Vault、AIチャット欄、ターミナル

この記事では実PCのフルパスは載せない。Vault内の相対パスだけを使う。

なぜ作ったか

syurainu.com

内部のシステムはAIに管理をさせているが、その分使うためのルールやファイルの場所が複雑になってきたためである。
タスクを追加するためのルール、AIが普段使用する場所・人が使う場所なども明記しさせてどの様な使い方であるかをちゃんと文章にしておく必要がでてきた。

全体構成

基本的には人がどのように使用するかを解決するためにマニュアルを用意したのが本題である。AIが読む場所は既に作成しているため、今回はそれほどsystem側の問題ではない。

00_ユーザーマニュアル/
人間が普段読む入口
迷ったときに最初に開く場所

90_System/manuals/
System側の詳しい運用説明
AI、スクリプト、Context Pack、台帳管理の細かい仕様

90_System/output/AI_START_HERE.md
AIが作業開始時に読む入口
読んでよい場所、読んではいけない場所、優先するContext Packを案内する

作ったもの

Vault直下に、次のフォルダを作った。

00_ユーザーマニュアル/

Vaultの上位の見える場所に配置。

中身は、目的別に分けた。

ファイル	役割
`README.md`	入口。どのページを読めばよいかを案内する
`00_最初に読む.md`	最低限の運用方針
`01_全体像.md`	Vault全体の考え方
`02_毎日やること.md`	日報や毎日の確認
`03_AIに頼むときのルール.md`	AIに読ませてよい場所、頼み方
`04_Mapの使い方.md`	CanvasやMapの扱い
`05_Assetの扱い方.md`	画像、PDF、添付ファイルの管理
`06_エラー記事とエラー台帳.md`	内部記録と公開記事の分離
`07_ブログ記事化.md`	作業ログを記事にするときの考え方
`08_セキュリティと禁止事項.md`	置いてはいけない情報
`09_困ったとき.md`	迷ったときの確認先
`10_コマンド一覧.md`	よく使うコマンド

これで、「全部読まないと分からない」状態を避けられる。

実行結果

作ってみて一番よかったのは、運用の判断が「記憶」ではなく「場所」になったことだ。

たとえば、こういう判断がファイル名だけで分かる。

毎日やることが分からない
-> 02_毎日やること.md

AIに何を読ませてよいか迷う
-> 03_AIに頼むときのルール.md

Mapの扱いが分からない
-> 04_Mapの使い方.md

Asset名を変えたい
-> 05_Assetの扱い方.md

ブログ記事化したい
-> 07_ブログ記事化.md

危ない情報を置いてよいか迷う
-> 08_セキュリティと禁止事項.md

全部を頭で覚えるのではなく、迷ったら該当ファイルを開けばよい。

詰まったところ

作業中に難しかったのは、「AI用に正確な説明」と「人間が読みやすい説明」が同じではない点である。

詰まったこと	原因	対処
System側の説明を読めば分かるが、普段使いには硬い	AIやスクリプト向けの仕様説明になっている	人間用の入口を別に作った
1ファイルに全部書くと長くなる	日報、Map、Asset、エラー台帳など論点が多い	目的別ファイルに分けた
AIに読ませてよい場所が曖昧になる	人間用メモとAI用ログが混ざると危ない	禁止フォルダと読ませる入口を明記した
ブログ記事とエラー台帳が混ざりそうになる	内部用記録と公開用説明の目的が違う	エラー台帳は内部用、ブログ記事は公開用に分けた

特に重要なのは、AI用の説明を人間向けに薄めるのではなく、最初から人間用の入口として設計することである。

セキュリティで注意したこと

人間用マニュアルを作るときは、便利さだけでなく、置いてはいけない情報も明記しておく必要がある。

特に、次のような情報はVault内の共有対象やブログ記事には載せない。

パスワード
APIキー
OAuthトークン
Cookie
秘密鍵
住所や電話番号などの個人情報
未公開の契約情報

また、ブログ記事にするときは、次のような値をそのまま載せない。

<USER_HOME>
<VAULT_PATH>
<API_KEY>
<TOKEN>
<CLIENT_SECRET>

検証用ドメインや非公開環境のURLを使っている場合は、それらもそのまま載せない。

AIに読ませない場所、編集させない場所をシステム権限だけで完全に管理しようとすると、日常運用が複雑になりやすい。

そのため今回は、明確な禁止事項とフォルダ分離によって、安全を優先する構成にしている。

Before / After

今回の変更を短くまとめると、こうである。

Before:
運用ルールが増えるたびに、どこを見ればよいか迷う
AI用のSystem説明を人間も読もうとしていた
日報、Map、Asset、エラー台帳、ブログ記事化の判断が記憶頼りだった

After:
00_ユーザーマニュアル/ が最初に読む場所になった
System側の詳細マニュアルとは役割を分けられた
迷ったら目的別ファイルを開けばよくなった
AIに読ませてよい場所と読ませない場所を説明しやすくなった

AI運用で重要なのは、大きな自動化だけではない。

人間が翌日も迷わず使える状態にしておくことも、継続運用では重要である。