前回（第3回）では、リンク・バックリンク・グラフビューを触って、ノート同士が「繋がっていく」感覚を掴みました。

もともとの計画では、次はプロパティとタグを触ってみて、プラグインについては「構想だけ考える」つもりでした。実際には触ってみたら、プロパティの奥が思ったより深くて、気づいたらプラグインまで一つ有効化していました。正直に、その過程を報告します。

最初はシンプルなフォルダ管理で考えていた

実は最初、5段階フロー（Grok収集→Perplexity再リサーチ→ChatGPT下書き→Claude記事化→投稿管理）に合わせて、01〜05の番号付きフォルダで工程を分ける設計を考えていました。

📁 最初の設計案（フォルダ版）

01_ネタ帳 → 02_リサーチ → 03_下書き → 04_記事 → 05_投稿管理

各工程でノートをコピーし直しながら進む方式

シンプルではあるものの、「1つのネタに対して4つのノートができる」「進捗を追うのにフォルダを移動する」という手間が気になっていました。ここでプロパティの出番です。

プロパティを設計してみた

プロパティを使うと、ノートを移動させずに「状態」だけを更新できます。フォルダは「コンテンツの型」、プロパティは「進行状況」という役割分担にしました。

実際に設計したプロパティは以下の9つです。

プロパティ名	型	用途
title	テキスト	記事タイトル
status	テキスト	ネタ/リサーチ中/下書き中/記事化済み/予約済み/公開済み
source	テキスト	Grok/Perplexity/ChatGPT/Claude/既存記事
stage	数値	1〜5の工程番号（ソート用）
created	日付	ノート作成日
published	日付	実際の公開日
scheduled_date	日付	予約投稿日（公開前のみ使用）
series	テキスト	ブログのシリーズ名
tags	タグ	分類用

途中で気づいたのが、「公開日」だけでは足りないということでした。過去記事を取り込んでいる最中、日付が未来のものが混ざっていて、それは予約投稿で公開前の記事だったんです。そこで急遽scheduled_dateを追加しました。公開されたらpublishedに日付を入れ、scheduled_dateは空に戻す、というルールにしています。

⚠️ 気づき

「公開済み」と「予約済み」を同じpublished日付だけで管理しようとすると、未来の日付が紛れ込んだときに区別がつかなくなる。日付が今日より先か過去かで、勝手に「公開済み」と決めつけないほうがいい。

タグは横断的な分類として使う

プロパティのstatusが「この記事固有の進行状況」だとすると、tagsは「テーマの横断的な分類」という役割分担にしました。

実際に使っているタグは obsidian、grok、perplexity のようなツール別タグと、ブログ記事、ネタ帳のような用途別タグです。ステータスをタグとしても併記しておくと（公開済み、予約済みなど）、タグパネルを開くだけでもざっくり状況が見えるので便利でした。

「構想だけ」のはずが、プラグインまで有効化していた

もともとの計画では、プラグインは次回（第5回）で実際に導入する予定でした。ところが、記事を毎回ゼロから書くのが手間になってきて、気づいたらコアプラグインのTemplatesを有効化していました。

設定→コアプラグイン→Templatesを有効化し、テンプレートフォルダにTemplatesフォルダを指定するだけで完了です。{{title}} {{date}} というプレースホルダーを使えば、新規ノートを作るたびにYAMLプロパティ入りの雛形が自動で挿入されます。

😲 正直つまずいた点

「無題のファイル」の状態でテンプレートを挿入したら、{{title}} が「無題のファイル」のまま反映されてしまいました。原因は、ファイル名をリネームした直後にすぐテンプレートを挿入していたこと。リネームが内部的に反映される前に{{title}}が古い名前を拾ってしまうようです。

対策：①ファイル名を先につける→②一度ノートを閉じて開き直す→③テンプレートを挿入、の順番にしたら解決しました。

小さなハマりどころでしたが、逆に言えば「プラグインを構想するだけ」のつもりが、1つ触っただけでもうこれだけ実用的な効果が出るのか、と驚きました。Obsidianの公式ガイドを見ると、コアプラグインだけで28個、コミュニティプラグインも合わせるとかなりの数があります。今回はTemplatesだけでしたが、次にどれを触るかは第5回で改めて考えます。

今の正直な感想

プロパティもタグもプラグインも、「聞き慣れない言葉」だった第1回の頃と比べると、実際に手を動かしてみると思ったよりシンプルでした。ただし、設計は一度作って終わりではなく、実際に運用しながら「あ、これが足りない」と気づいて直す（scheduled_dateの追加がまさにそれでした）、その繰り返しなのだと実感しています。

📘 次回予告

次回（第5回）は「ブログ管理、まずシンプルに作ってみた」。実際にVaultを作り、既存記事を8本取り込んでみたところ、想定していなかった文字化けトラブルにも遭遇しました。その顛末を正直にお届けします。

💜 Hiroroのひとこと

「プラグインは構想だけ」と決めていたはずが、気づいたら1つ有効化して実際に使っていました。触ってみないと分からないことが多いので、これくらい前のめりに進めるくらいでちょうどいいのかもしれません。