ObsidianをAIの「外部の脳」にする — 正を1か所に決め、点検スクリプトとGit自動コミットで「AIに書かせても壊れない」ナレッジ基盤を作る

AIに社内の文脈を覚えさせたいなら、AIが迷わず読める「外部の脳」を1つ用意し、そこをAI自身にも書かせる——ただし「壊れても戻せる」「壊れたらすぐ分かる」仕組みを先に敷いておく。当社ではObsidianのVault(ノート置き場)をその外部の脳に位置づけ、情報の正を1か所に決めるルール、健全性を自動点検するスクリプト、30分ごとのGit自動コミットの3点で、Claude CodeやCodexに書かせても壊れないナレッジ基盤にしました。この記事ではその構成と、運用して踏んだ落とし穴を紹介します。

背景: 「AIが読める」だけでは足りなかった

当社の業務はClaude Codeを中心に回しており、プロジェクトの現状・決定事項・作業の経緯はObsidianのノートに蓄積しています。AIはセッションをまたぐと記憶を持ちませんから、「どこを読めば現状が分かるか」が決まっているほど、作業の立ち上がりが速く、判断もぶれません。

ところが、同じ情報がトップの索引(INDEX)と一覧とプロジェクトごとのメモに散らばり、更新漏れが起きていました。AIに読ませるだけでなく書かせるようになると、索引が1日で2倍に膨らんだり、リンク切れや必須項目の抜けが静かに増えたりもします。「読める」の次に必要だったのは、「書いても壊れない」ための構造とガードレールでした。

構成1: 情報の「正」は1か所に決める

最初にやったのは、どの情報をどこに書くかを決め、同じ情報を複数の場所に書かないルールにしたことです。

プロジェクトの現状・決定事項・TODO: 各プロジェクトのフォルダにあるmemo.mdが唯一の正。決定事項は日付・内容・背景の表にして末尾に足していく
作業の経緯: 同じフォルダのlog/作業ログ YYYY-MM-DD.md。ファイル名の形式を統一し、memoからはリンクを置くだけ
全プロジェクトの一覧: 手書きしない。memoのフロントマター(状態・分類・月・優先度・要約)から、ObsidianのBases機能で自動生成する
索引(INDEX): 進行中プロジェクトにつき1行の要約とリンクだけ。進捗の詳細は書かない

この整理で、索引は14.3KBから8.0KBまで縮みました。あわせて「索引は8KB以内・1行200文字以内」を上限として決め、超えたら後述の点検で警告が出るようにしています。上限を数値で決めたのは、一度6.6KBまで圧縮した索引が翌日には14KBに戻っていたからです。ルールは文章ではなく、機械が検出できる数値にしないと守られません。

構成2: 壊れたらすぐ分かる点検スクリプト

次に、Vault全体の健全性を点検するPythonスクリプトを置きました。標準ライブラリだけで動き、依存はありません。

python3 vault_check.py            # 既定のVaultを点検
python3 vault_check.py --quiet    # サマリーのみ。ERRORがあれば終了コード1

点検内容は、止めるべきものをERROR、気づけばよいものをWARNに分けています。

ERROR: 壊れた[[リンク]]、フロントマターの欠落(日付・タグ)、memoの必須項目(状態・分類・月・優先度・要約)の不足や不正な状態値、作業ログのファイル名違反、相対形式のリンク、索引に載っていない進行中プロジェクト
WARN: 被リンク0の孤立ノート、ほぼ空のノート(200バイト未満)、プロジェクト名とフォルダ名の不一致、優先度や日付項目の不正な値、索引の肥大(8KB超または1行200文字超)

運用は「週1回、または大きな整理の後に『Vaultを点検して』とAIに言う」だけです。AIがスクリプトを走らせ、出てきたERRORを直します。「意図的に空のノートを置いておきたい」といった例外は、警告の対象から外す判断をその都度決め、点検内容を変えたら運用ルールのノートも同時に直すことにしています。

構成3: 30分ごとのGit自動コミットで「戻せる」状態に

AIに書かせる前提として、壊れても戻せることが要ります。VaultをGitで履歴管理し、ログイン中は30分ごとに自動コミットするようにしました。履歴の実体(.git相当)はVaultの中ではなく、ホームフォルダ直下の別の場所に置いています。クラウド同期の退避や競合でリポジトリ自体が壊れるのを避けるためです。スクリプトは次のとおりで、これをmacOSのlaunchdから30分間隔で呼んでいます。

#!/bin/zsh
# Vault を 30 分ごとに自動コミット(履歴は Vault の外に置く)
V="$HOME/Obsidian"; G="$HOME/.obsidian-vault.git"
[ -d "$V" ] || exit 0
cd "$V" || exit 0
git --git-dir="$G" --work-tree="$V" add -A >/dev/null 2>&1
if ! git --git-dir="$G" --work-tree="$V" diff --cached --quiet; then
  git --git-dir="$G" --work-tree="$V" -c user.name="Your Name" -c user.email="you@example.com" \
    commit -q -m "auto: $(date '+%Y-%m-%d %H:%M')" >/dev/null 2>&1
fi

戻すときは、同じ--git-dirと--work-treeの指定でひとつ前のコミットから対象ファイルだけを取り出します。

git --git-dir="$HOME/.obsidian-vault.git" --work-tree="$HOME/Obsidian" log --oneline | head
git --git-dir="$HOME/.obsidian-vault.git" --work-tree="$HOME/Obsidian" checkout HEAD~1 -- "path/to/memo.md"

役割分担は「端末間の同期=Obsidian Sync、履歴=Git、第二の保険=Time Machine」の3層です。同期はバックアップではありません(消せば全端末から消えます)。履歴があって初めて、AIの書き込みを許容できます。

AIの書き込みは「場所を限定して、承認制から」

戻せる状態を作ったうえで、Codex(Claude Codeから呼んでいる別のAI)には書いてよい場所を4か所に限定しました。当日分の作業ログ、memoの決定事項表の末尾1行、受け渡し用のInboxフォルダ、実験記録のフォルダです。索引、memoのフロントマター、ダッシュボード、運用ルールには触らせません。しかも最初は常時許可ではなく、書くたびに人間が承認する運用から始めています。AI側の設定では「Vault全体を書き込み可」にしかできず、構造を守るものがルールの文面だけになるためです。AIが書いたノートはフロントマターのsourceで見分けられるようにし、1〜2週間の様子を見てから常時許可を再検討する、という段階を踏んでいます。

ハマりポイント

iCloudの「ストレージ最適化」でファイルが退避され、AIが読めなくなった: VaultをiCloud配下に置いていたところ、最適化でローカルから退避されたファイルを点検スクリプトもAIも読めず、作業が止まりました。根本対策としてVaultをiCloudの外へ移動し(223ファイル、内容差分0・退避0を照合してから切り替え)、端末間同期はObsidian Syncに一本化しました。旧パスは転送リンクを置いて参照を壊さないようにしています。
パス置換の洗い出しで、連結して書いたパスがgrepに引っかからなかった: 点検スクリプトの既定パスを"Documents" / "Obsidian"と分けて書いていたため、文字列検索で見つかりませんでした。移動のあとに旧パスを探すときは、連結形も探す必要があります。
プロセス名での終了確認が別プロセスに反応した: アプリが閉じているかをpgrep -x Obsidianで見ていたら、Obsidian用のMCPサーバー(npmのプロセス)にも反応しました。アプリ本体の終了確認は実行ファイルのパスで見るのが確実です。
Syncの同期範囲はVault内ではなくアプリ側に保存される: ファイルを読むだけのAIからは確認できず、画面での確認が人間の作業として残りました。

まとめ

AIに社内の文脈を持たせる作業は、「どのツールに覚えさせるか」より「書く場所を1つに決め、壊れたら検出でき、壊れても戻せる」という地味な設計で決まります。正を1か所に・点検スクリプト・自動コミットの3点が揃ってはじめて、AIの書き込みを限定的に許可する判断ができました。

社内の情報をAIが読み書きできる形に整えたい、といったAI導入の進め方のご相談は、お問い合わせフォームからどうぞ。課題の整理からご一緒します。

← TECH-BLOG一覧へ