🧠 Transform conversation logs into Obsidian long-term memory

Tonight 20:00 JST Tsukutta-chan live stream

🧠 Transform conversation logs into Obsidian long-term memory | Tsukutta

This is the "Claude Code Environment" series. In 記憶を4層に分けた話 I wrote "conversation logs = layer 1" and "Obsidian Vault = layer 4," but this time I'm writing the implementation of the automated distillation pipeline that runs every night from layer 1 to layer 4.

Raw conversation logs are too massive to read. Meanwhile, the human Wiki in Obsidian is structured long-term memory. I'm running this unattended: every night, appending only the most recent 28 hours while preserving domain structure. What I've learned from doing this—how to eliminate silent failures and mechanisms to prevent fabrication—is the substance of this article.

Overview: Collection → Distillation → Backup

Launched from launchd every morning, there are roughly 3 stages:

Collection: Refresh conversation logs (layer 1) (extract_conversations.py)
Distillation: Run claude -p headless, appending only the 28-hour delta to the relevant domain in the Vault
Backup: Every time, git commit + push to private repo (if things break, revert is possible)

Distillation is split into 2 separate runs by source (Claude conversations and Codex conversations). The reason, explained later, is that combining them into one exceeded the time window and timed out every night.

Pitfall 1: launchd Cannot Touch Protected Folders (TCC)

Everything got stuck on this first. The Vault is under ~/Documents, which is protected by macOS's TCC (privacy protection). Even if you run git from launchd, it fails because it can't write to the protected area.

What makes it worse is that this tends to become a "silent failure." So I detect it early with a preflight check and log loudly + send notifications.

text

# launchd配下では ~/Documents(保護領域) に触れない場合がある。
# ここで早期検知し、サイレント失敗(exit 0偽装)を防ぐ。
if ! ( cd "$VAULT" && git rev-parse --git-dir >/dev/null 2>&1 ); then
  echo "❌ FDA未付与: launchdから '$VAULT' にアクセス不可(TCC保護)" >> "$LOG"
  notify_fail "FDA未付与（設定→フルディスクアクセス→/bin/bash を許可）"
  exit 1
fi

The solution is "System Settings → Privacy and Security → Full Disk Access, permit /bin/bash". Place the script itself outside the protected area (~/.claude/scripts/). If you put it in ~/Documents, launchd can't exec it.

I also tried a symlink escape to ~/, but iCloud's conflict handling breaks symlinks, so that's not viable. When protected areas and iCloud sync overlap, constraints that defy intuition multiply. It's stable to be strict about placement: scripts outside protection, data inside protection.

Pitfall 2: Sleep and Double Execution → Make It Self-Healing

When you close the lid and sleep, nighttime jobs freeze. caffeinate -s only works on AC power, so on battery it just stops normally. So I made it self-healing: retry across multiple slots until success, then exit immediately.

plist fires at multiple slots: 4:55 / 8:15 / 10:15 / 12:15, etc.
If today's run already succeeded, subsequent slots check the done marker and exit 0 immediately (no wasted runs, no log pollution)
Double execution is eliminated with mkdir locking (stale locks auto-recovered by process liveness)

text

DONE_MARKER="$HOME/.claude/logs/.vault-ingest-done-${TODAY}"
[ -f "$DONE_MARKER" ] && exit 0   # 本日成功済みなら即終了

Splitting distillation into 2 runs (Claude/Codex) is for the same reason. On busy days, digesting 28 hours of logs + article rewrites exceeded the 40-minute window and timed out daily, which froze the hot cache. Each substep has its own independent marker, so if one times out, the next slot retries only what remains.

Preventing Fabrication: Keep Ground Truth Separate

This is the most important lesson. When you throw "write today's brief from the conversation log" at claude -p, it sometimes invents plausible constraints and durations for events not in the notes. It sees prose like "M/D〜M/D" and inflates it into "this period is entirely constrained."

There are two countermeasures.

① Make the calendar's actual snapshot the canon. Instead of prose, pull scheduled events with timestamps from Google Calendar API, drop them in a separate file, and instruct: "treat this as the sole canonical schedule."

② If retrieval fails, preserve last-known-good. Even if the API fails, don't wipe the canon empty. Keep the last successful value with a stale marker.

text

if [ -n "$CAL_SRC" ]; then
  cp "$CAL_TMP" "$CAL_SNAPSHOT"; cp "$CAL_SNAPSHOT" "$CAL_LASTGOOD"
elif [ -s "$CAL_LASTGOOD" ]; then
  # 取得失敗: 前回goodを温存し ⚠️stale 印で再構築（last-known-good）
  { echo "⚠️ 本日取得失敗。以下は前回成功時点の値(stale)。"; tail -n +4 "$CAL_LASTGOOD"; } > "$CAL_SNAPSHOT"
fi

And constrain it hard on the prompt side too. "Don't invent information not in the notes." "Explicitly separate confirmed facts from speculation in date/time claims." If you're having AI write long-term memory, you can only kill the room for fabrication through structure.

Freshness Judgment: Don't Mistake Old Artifacts for "Today's Output"

When archiving briefs with dates, only files newer than this run's start time count as today's output.

text

START_STAMP=$(mktemp ...)          # ラン開始時刻スタンプ
# ...生成...
if [ -s "$BRIEF_SRC" ] && [ "$BRIEF_SRC" -nt "$START_STAMP" ]; then
  cp "$BRIEF_SRC" "$ARCH_FILE"; touch "$DONE_MARKER"   # 新しい時だけ完了扱い
else
  notify_fail "ブリーフ未完 — 次スロットで自動再試行"   # 古いまま＝失敗、再試行へ
fi

Without this, even if generation times out, you'd copy "yesterday's old brief" and record it as "success." By judging freshness via mtime, you prevent failure from masquerading as success.

Pitfalls I Hit

launchd can't write to protected areas, silent failure → TCC preflight for early detection + FDA grant
Symlink escape to unprotected area → iCloud's conflict handling breaks it. Not viable.
Sleep freeze + double execution → Multi-slot retry + mkdir lock + done marker
28h in one run exceeds time window, daily timeout → 2 runs by source + independent substep markers
Inventing constraint durations for events → Canonicalize calendar reality + last-known-good + forbid speculation in prompt
Mistaking old artifacts for today's output → Only count completion if mtime is newer than run start

Summary

Every night, auto-distill only the most recent 28h delta from conversation logs (layer 1) → Obsidian (layer 4)
Protected areas are blocked by TCC. Detect early and log loudly—don't tolerate silent failure
Sleep and double execution are handled by multi-slot retry + locking + done marker for self-healing
If you have AI write memory, keep ground truth separate and forbid speculation through structure
mtime freshness judgment prevents failure from masquerading as success

Next time, I'll write about the parent orchestrator of this unattended job ―― Claude Codeの自律ループを24時間回し、コストで暴走を止める.

Lily (@bokuwalily) ― Individual developer. Building automation infrastructure with Claude Code while mass-producing iOS apps and web services
◼︎ Apps I've made are summarized at **ポートフォリオ**📱
◼︎ New releases and development behind-the-scenes on X **@bokuwalily**🐦
◼︎ OSS: **github.com/bokuwalily**🐙
Your ❤️ and shares are my motivation!

「Claude Code環境」シリーズです。記憶を4層に分けた話で「会話ログ＝層1」「Obsidian Vault＝層4」と書きましたが、今回はその層1から層4へ毎晩自動で蒸留する配管の実装を書きます。

会話ログは生のままだと巨大で読めません。一方Obsidianの人間Wikiは構造化された長期記憶です。この2つを「毎晩、直近28時間分だけ、ドメイン構造を守って追記する」のを無人で回しています。やってみて分かったサイレント失敗の潰し方と捏造させない仕掛けが、この記事の中身です。

全体像：採取 → 蒸留 → バックアップ

launchdから毎朝起動して、おおまかに3工程です。

採取：会話ログ（層1）を最新化する（extract_conversations.py）
蒸留：claude -p ヘッドレスで、直近28時間の差分だけをVaultの該当ドメインに追記
バックアップ：毎回 git commit + private repo に push（荒れてもrevert可能）

蒸留はソース別に2本（Claude会話とCodex会話）に分けています。理由は後述しますが、1本にまとめると時間枠に収まらず毎晩timeoutしていたからです。

罠1：launchdからは保護フォルダに触れない（TCC）

最初に全部詰まったのがこれです。VaultはiCloud同期の ~/Documents 配下にあり、macOSのTCC（プライバシー保護）で守られています。launchdから git を走らせても、保護領域に書けずに失敗する。

しかも厄介なのは、これが「サイレント失敗」になりやすいこと。だからプリフライトで早期検知して大声でログ＋通知します。

text

# launchd配下では ~/Documents(保護領域) に触れない場合がある。
# ここで早期検知し、サイレント失敗(exit 0偽装)を防ぐ。
if ! ( cd "$VAULT" && git rev-parse --git-dir >/dev/null 2>&1 ); then
  echo "❌ FDA未付与: launchdから '$VAULT' にアクセス不可(TCC保護)" >> "$LOG"
  notify_fail "FDA未付与（設定→フルディスクアクセス→/bin/bash を許可）"
  exit 1
fi

解決は「システム設定 → プライバシーとセキュリティ → フルディスクアクセスで /bin/bash を許可」。スクリプト自身は保護外（~/.claude/scripts/）に置きます。~/Documents に置くとlaunchdからexecできません。

symlinkで ~/ に逃がす案も試しましたが、iCloudがsymlinkを競合処理して壊すため不可でした。保護領域とiCloud同期が重なると、直感に反する制約が増えます。スクリプトは保護外・データは保護内、と置き場所を割り切るのが安定します。

罠2：スリープと二重実行 → 自己回復型にする

蓋を閉じてスリープすると、夜間ジョブは凍結します。caffeinate -s はAC電源時しか効かないので、バッテリー駆動だと普通に止まる。そこで**「成功するまで複数スロットで再試行、成功したら即終了」**の自己回復型にしました。

plistは 4:55 / 8:15 / 10:15 / 12:15 など複数スロットで発火
本日分が成功済みなら、後続スロットは done マーカーを見て即 exit 0（空振りでログも汚さない）
二重実行は mkdir ロックで排除（プロセス死活でstaleを自動回収）

text

DONE_MARKER="$HOME/.claude/logs/.vault-ingest-done-${TODAY}"
[ -f "$DONE_MARKER" ] && exit 0   # 本日成功済みなら即終了

蒸留を2本（Claude/Codex）に割ったのも同じ理由です。活動の多い日は28時間分のログ消化＋記事リライトが40分枠に収まらず連日timeoutし、それが原因でホットキャッシュが凍結していました。サブステップごとに独立マーカーを持たせ、片方がtimeoutしても次スロットが残りだけ再試行します。

捏造させない：ground truth を別に持つ

これがいちばん大事な学びです。claude -p に「会話ログから今日のブリーフを書け」と投げると、ノートに無い予定の拘束時間や所要日数を、それらしく創作することがありました。「M/D〜M/D」という散文を見て「この期間ずっと拘束される」と膨らませてしまう。

対策は2つです。

① カレンダーの実体スナップショットを正典にする。 散文ではなく、Google Calendar APIから取った時刻付きの予定を ground truth として別ファイルに落とし、「これを唯一の正典スケジュールとして読め」と指示します。

② 取得失敗時はlast-known-goodを温存する。 APIが失敗しても、正典を空で潰さない。前回成功時の値を stale 印付きで残します。

text

if [ -n "$CAL_SRC" ]; then
  cp "$CAL_TMP" "$CAL_SNAPSHOT"; cp "$CAL_SNAPSHOT" "$CAL_LASTGOOD"
elif [ -s "$CAL_LASTGOOD" ]; then
  # 取得失敗: 前回goodを温存し ⚠️stale 印で再構築（last-known-good）
  { echo "⚠️ 本日取得失敗。以下は前回成功時点の値(stale)。"; tail -n +4 "$CAL_LASTGOOD"; } > "$CAL_SNAPSHOT"
fi

そしてプロンプト側でも強く縛ります。「ノートに無い情報を推測で足すな」「日付・時間の主張は確定情報と推測を明示的に分けろ」。AIに長期記憶を書かせるなら、創作の余地を構造で潰すしかありません。

鮮度判定：古い成果物を「今日の成果」と誤認しない

ブリーフを日付つきでアーカイブするとき、「このランの開始時刻より新しいファイルだけ」を今日の成果と認めます。

text

START_STAMP=$(mktemp ...)          # ラン開始時刻スタンプ
# ...生成...
if [ -s "$BRIEF_SRC" ] && [ "$BRIEF_SRC" -nt "$START_STAMP" ]; then
  cp "$BRIEF_SRC" "$ARCH_FILE"; touch "$DONE_MARKER"   # 新しい時だけ完了扱い
else
  notify_fail "ブリーフ未完 — 次スロットで自動再試行"   # 古いまま＝失敗、再試行へ
fi

これが無いと、生成がtimeoutしても「前日の古いブリーフ」をコピーして「成功」と記録してしまう。鮮度をmtimeで判定することで、失敗を成功に偽装しないようにしています。

踏んだ落とし穴

launchdから保護領域に書けずサイレント失敗 → TCCプリフライトで早期検知・FDA付与
symlinkで保護外に逃がす案 → iCloudが競合処理で壊す。不可
スリープ凍結・二重実行 → 複数スロット再試行＋mkdirロック＋doneマーカー
28h分が1本だと枠超過で連日timeout → ソース別2本＋サブ独立マーカー
予定の拘束時間を創作 → カレンダー実体を正典化＋last-known-good＋推測禁止プロンプト
古い成果物を今日の成果と誤認 → ラン開始スタンプより新しい時だけ完了扱い

まとめ

会話ログ（層1）→ Obsidian（層4）を毎晩・直近28h差分だけ自動蒸留
保護領域はTCCで弾かれる。早期検知で大声、サイレント失敗を許さない
スリープ・二重実行は複数スロット再試行＋ロック＋doneマーカーで自己回復
AIに記憶を書かせるならground truthを別に持ち、推測を構造で禁じる
mtime鮮度判定で失敗を成功に偽装させない

次回は、この無人ジョブの親玉 ―― Claude Codeの自律ループを24時間回し、コストで暴走を止めるを書きます。

Lily（@bokuwalily）― 個人開発者。Claude Code で自動化基盤を組みながら、iOSアプリやWebサービスを量産しています
◼︎作ったアプリは **ポートフォリオ** にまとめています📱
◼︎新着・開発の裏側は X **@bokuwalily** で発信しています🐦
◼︎OSS: **github.com/bokuwalily**🐙
皆さんの ❤️ やシェアが励みになります！

🧠 Transform conversation logs into Obsidian long-term memory

🌙 見知らぬ誰かのために、夜中に直した

🔄 ドメインを、また更新した

💡 説明しなくてもわかってもらえた日

Overview: Collection → Distillation → Backup

Pitfall 1: launchd Cannot Touch Protected Folders (TCC)

Pitfall 2: Sleep and Double Execution → Make It Self-Healing

Preventing Fabrication: Keep Ground Truth Separate

Freshness Judgment: Don't Mistake Old Artifacts for "Today's Output"

Pitfalls I Hit

Summary

全体像：採取 → 蒸留 → バックアップ

罠1：launchdからは保護フォルダに触れない（TCC）

罠2：スリープと二重実行 → 自己回復型にする

捏造させない：ground truth を別に持つ

鮮度判定：古い成果物を「今日の成果」と誤認しない

踏んだ落とし穴

まとめ