16:I[51955,["/_next/static/chunks/433btrexvk76r.js?dpl=dpl_CKSwgUwoYzvbPW6KncFbjWH5LFzr","/_next/static/chunks/326scgxg_6_ox.js?dpl=dpl_CKSwgUwoYzvbPW6KncFbjWH5LFzr","/_next/static/chunks/27nb2pwl2arz8.js?dpl=dpl_CKSwgUwoYzvbPW6KncFbjWH5LFzr","/_next/static/chunks/35tslh9gpz5lx.js?dpl=dpl_CKSwgUwoYzvbPW6KncFbjWH5LFzr"],"default"] 17:T668,1)過去投稿エクスポート 2)AIがトーン・価値観・パターン分析 3)個人プロフィール生成 4)API経由で1日3投稿 5)毎晩7日分を自動補充。【追記 2026-05-06 — voice 抽出の上位互換手順 @rubenhassid（@873K views）https://x.com/rubenhassid/status/2050787472666399042】2 時間 100 質問インタビュー → XML 圧縮でファイル化する手順の完全公開。①Prompt 1「Taste Interviewer」で Claude が 7 カテゴリ 100 問（BELIEFS / WRITING MECHANICS / AESTHETIC CRIMES / VOICE & PERSONALITY / STRUCTURAL PREFERENCES / HARD NOS / RED FLAGS）を 1 問ずつ深掘り、vague な答えは push back、矛盾を指摘。Wispr Flow で口述すると 90 分（音声の方が早く正直）。②Prompt 2「Voice Compiler」で 20,000 word の archive を XML 構造（ / / / / / / / / / ）で 5,000 token 以下に圧縮、「この行が消えたら AI の出力が変わるか？」をテストに残す/捨てる判定。③Cowork folder に常駐 → どの新規セッションでも自分らしい初稿が出る → Obsidian で日々編集。【mkt-001 との違い】mkt-001 は X 投稿エクスポート → 自動配信の出力寄り、本追記は声を file 化する抽出寄りで対象は X 以外（newsletter / メール / チームに渡せる ghostwriting brief）。Claude / ChatGPT / Gemini / Grok のどれでも同じ file が動く portability を強調。18:T852,Claude CodeからObsidian Vaultを直接読み書きし、ナレッジの収集・整理・検索をAIで自動化。CLAUDE.mdにVaultパスを記載しセッション間でコンテキストを持続。スキルグラフレイヤーでスキル間依存関係をエージェントが辿れるようにする。 Vault構成・自動インデックス・検索パイプラインの実践手順が @rywiggs により体系化。 MCP接続は5カテゴリ（filesystem/memory/browser/git/database）で整理し、必要なものだけ有効化する。【追補 2026-04-25 @ClaudeCode_UT】setup-049「Claude Code + Obsidian AIセカンドブレイン」に対し、KarpathyのLLM Wiki（1質問44,000トークン、スケール困難）vs NotebookLM（エンベディング方式で即時・引用付き）vs Skills（日常の判断装置化）という3方式の比較実験と使い分け基準が補完情報として有用。（出典: https://x.com/ClaudeCode_UT/status/2046592455903219940）【追記 2026-04-25】cyrilXBT(@cyrilxbt): Claude CodeとObsidianの連携において、Vaultをセカンドブレインとして機能させるには「読み書き双方向」の設計が重要で、単なるメモ保存ではなく能動的な知識検索・更新フローを定義すべき。出典: https://x.com/cyrilxbt/status/2047246104421388461 【補強 2026-05-27 @cyrilXBT】耐障害性の設計原則（出典: https://x.com/cyrilxbt/status/2056924424838815824 ）。生産性システムが破綻する原因はどれも同じ＝「好調な日（時間も気力もある日）」を前提に設計されているから。Obsidianを「壊れない個人OS」にするには、調子の良い日でなく調子の悪い日（疲れて手入れを省く日）を基準に設計し、維持コストを限界まで下げる。整えるのに気力が要る仕組みは不調な日に放置され、放置が品質低下を招くという悪循環を、最初から「手入れ不要」に倒すことで断つ。setup-049のVault設計に、この「悪い日のために設計する」運

ブログ

ブログ