「またゼロから書く」 を減らす。 僕が過去記事を Obsidian の部品に分解した話

アーカイブをスニペット化する設計

「この説明、前にも書いたよな」

Obsidian で過去の note 記事を検索して、該当ファイルを開く。
長いスクロールの末に段落を見つけてコピー。
貼り付けてから、トーンが微妙に違うことに気づいて書き直す。

——気づけば 20 分。

本文はまだ一行も増えていません。

フリーランスとして発信を続けるほど、過去記事は資産になるはずです。
僕にとって、長いままのアーカイブは倉庫の段ボールでした。

中身はある。
でも、必要な部品だけ取り出すのが面倒。

この記事は、その段ボールを Obsidian 上の部品棚に分解し直した設計の記録です。

自動化の話に見えて、本質はもっと地味です。

「探す」「選ぶ」「貼る」の前にかかる時間を減らす。

ツールは Obsidian でも、メモアプリでも構いません。
大事なのは、長文を倉庫のまま抱え続けないという一点なのです。

資産のまま眠る記事が執筆を遅らせる

note の記事は、公開時点では完成品として美しい。

次の記事を書くとき、僕が欲しいのは完成品全体じゃありません。

説明の型
比喩の一段
手順の箇条書き
読者への注意書き一行

——こういう小さな部品です。

完成品を毎回開くと、視線が散る。
「あの見出しの言い回し、いいな」と寄り道する。
気持ちはわかる。
でも、今週の締切は容赦しない。

だから僕は方針を変えました。

公開用の原稿はそのまま残す。
再利用したい断片だけを、別ノートに抜き出す。

この二層に分けた瞬間から、「またゼロから書く」が減りました。

スニペット化の定義 （僕の使っている意味）

ここで言うスニペットは、プログラミングの厳密な意味より広めです。

「次の記事で、ほぼそのまま差し込める Markdown の断片」

条件は 3 つだけです。

1️⃣ 1 ノート 1 役割
　（説明なら説明、手順なら手順）

2️⃣ ファイル名で検索できる
　（迷子にならない）

3️⃣ 出典（元記事）が辿れる
　（いつ誰向けに書いた部品か分かる）

完璧な再利用を目指さない。

80% そのまま使えて、20% は毎回整える——それで十分です。

具体例でいうと

📌 スニペット:
「Inbox は脳から降ろす場所」という定義の 3 行

📌 テンプレート:
見出し構成、タグ欄、メンバーシップ境界のマーカー、画像プレースホルダ

この切り分けができると、「今日は定義を貼ってから書く」「今日は手順だけ先に置く」みたいに、最初の一手が選びやすくなります。

選びやすいと、手が動く。

手が動くと、公開に近づく。

地味ですが、フリーランスの発信はここが勝負なのです。

テンプレートとスニペットは、 別モノとして扱う

以前、僕はテンプレートさえあれば全部解決と思っていました。

Templater で記事の骨格を一発生成するのは、本当に生活を変えました。

テンプレートは型です。

スニペットは中身の部品です。

型だけあって中身が毎回空なら、結局ゼロから考えます。
逆に、部品だけ増えて型がないと、貼り付け順で迷子になります。

だから僕の Obsidian では、

📌 テンプレート:
新規記事の「枠」

📌 スニペット庫:
何度も使う「断片」

をフォルダも含めて分けています。

「また雛形コピペ」から卒業したあとも、次に来た壁が長文アーカイブのコピペだった——そんな感覚です。

検索は強い。 でも検索だけだと取り出しが重い

Obsidian の検索は好きです。

path:03.note記事 みたいに絞れば、過去記事も一気に拾える。

問題は、そのあとです。

ヒットしたファイルを開く。
長い。
読み直す。
結局、必要な 3 行のために 3,000 行を通る。

検索は発見には強い。
でも再利用の速度を上げたいとき、ボトルネックは発見じゃなく取り出しでした。

スニペット化は、検索の代わりではなく検索の後工程を短くするための仕組みなのです。

連載記事ほど部品棚の効果が出る

僕は連載やシリーズを意識して書くことが多いです。

同じテーマで、前提説明が毎回ちょっとずつ必要になる。
毎回ゼロから書くと、表現がブレる。

部品棚があると、

📍 前提説明は同じ部品から開始する
📍 今回だけの更新は ## 差し替えメモ に書く

という流れになります。

読者から見ると「この人の説明、いつも同じ軸だな」と安心しやすい。
書き手から見るとブレない。

小さな投資で、信頼の積み上げ方が変わるのです。

部品にするとき、 僕が最初に決めた 3 つのルール

【ルール 1】 抜き出す単位は段落より意味

段落単位で切ると、前後の文脈が消えて貧弱になりがちです。

僕は意味のかたまりで切ります。

📍 定義（この言葉はこういうこと）
📍 手順（3 ステップで終わる）
📍 比喩（読者のイメージが乗る一段）
📍 注意（誤解されやすい点の一行）

【ルール 2】 ファイル名に何の部品かを入れる

例:

snip- は僕の好みです。
検索欄に snip- と入れるだけで、部品棚に一発で戻れます。

【ルール 3】 先頭に 「いつ ・ どの記事から」 を残す

転載ではなく自分の再利用でも出典は残す。

未来の自分が「これ、誰向けの言葉だったっけ？」と迷わないためです。

【ルール 4（任意）】 ^block ではなく別ファイルにする日もある

Obsidian には、段落に ^id を付けて埋め込む方法もあります。

僕も使います。

ただ、note 記事の原稿は公開後に微修正が入ることもある。

そのたびにブロック ID がズレるのが怖いときは、最初から別ファイルの部品にしておく方が安全なことがあります。

正しいやり方は一つじゃない。
壊れにくさで選ぶのが個人開発のボールトです。

フォルダ設計 （最小構成）

僕のボールト（Vault）では、次のような最小構成から始めました。