Obsidianのステータス管理をQuickAddで自動化｜タグ運用をやめた理由

私は以前、ブログ記事ノートのプロパティstatus: を書き換える作業を、毎回手打ちでやっていました。status: draftをstatus: publicに変える、といった具合で、1回あたりの書き換えは数秒で終わります。ただ、記事が増えるほど地味に積み重なります。しかもたまに、publicをPublicと打ってしまう…表記揺れの原因です。同じような経験をした人も多いと思います。

公開のたびに、更新情報用のノートへタイトルとURLと概要をコピペする作業もありました。記事を書き終えて、ようやく公開というときに、この手作業が待っているわけです。

こういった経緯を経て、今はQuickAddのマクロでステータスを選ぶだけになりました。AutoMoverは、新規ノートを作った直後の仕分けだけを担当しています。ただし、全部が自動になったわけではありません。SNSの投稿文は、今もAIに頼んで作っています。

この記事では、タグとフォルダで管理していた運用を、なぜstatusプロパティ中心に切り替えたのかを書いていきます。マクロの中身と、AutoMoverで今も気をつけている誤爆パターンもあわせて紹介します。ブログ記事の管理を例にしていますが、タスク管理への応用も効くはずです。

今の運用は「入口はAutoMover、状態はQuickAddマクロ」

先に、今の運用の全体像を示しておきます。役割は3つに分かれていて、それぞれが別々の仕事を受け持っています。

担当	役割
AutoMover	新規ノートに付いたタグを見て、決まったフォルダへ仕分ける（入口だけ）
QuickAddのマクロ	statusの変更と、公開時の周辺処理をまとめて実行する
Base Board	statusを軸に、カンバンで一覧・並べ替えをする

流れにすると、次のようになります。

1. 新規ノートを作る（AutoMoverが、入口で決まったフォルダへ仕分け）
2. 執筆の区切りで、QuickAddのマクロからstatusを切り替える
3. 公開前にpublicへ切り替えると、更新情報ノートが自動で書き換わる
4. サイトで記事を公開する

QuickAddとTemplaterの役割の違いは、QuickAddとTemplaterって何が違うの？役割を分けて考えるとObsidianが一気に使いやすくなるにまとめています。プラグイン4つをまとめて連携させる全体像は、Obsidianのノート管理を自動化する方法｜4つのプラグイン連携ガイドで紹介しました。

この記事は、その続きにあたる実践編です。連携ガイドが「こうすれば動く」という話だとしたら、こちらは「遠回りして、こう落ち着いた」という実体験になります。

最初はタグ＋AutoMoverでフォルダを振り分けていた

今の形に落ち着くまでには、遠回りがありました。最初は、タグを軸にした運用から始めています。

きっかけは、手動でのファイル移動が面倒だったことです。ステータスが変わるたびに、ノートをドラッグしてフォルダを移す。この作業を減らしたくて、AutoMoverを入れました。

タグを付けるだけでフォルダに入る

AutoMoverは、ノートに付いたタグを見て、あらかじめ決めたフォルダへ自動で移動してくれるプラグインです。たとえば「このタグが付いたら、このフォルダへ」というルールを作っておけば、タグを付けた時点で仕分けが終わります。

私はステータスごとにフォルダを分けて、そのフォルダにタグを対応させていました。タグを付ければ、ノートが勝手に動く。実際これだけでも、かなり楽になりました。AutoMover自体の設定は、Obsidianのドラッグ＆ドロップにさようなら｜AutoMover(al0cam版)でタグを使った自動整理で詳しく書いています。

タグの付け替えも、マクロで一発にした

ただ、すぐに別の面倒が出てきます。ステータスを変えるたびに、古いタグを消して、新しいタグを付ける必要があるのです。

そこで、QuickAddのマクロを作りました。メニューからステータスを選ぶと、タグがまとめて付け替わります。タグが変わればAutoMoverが反応して、ノートが移動します。

選ぶだけでフォルダまで動くので、この時点で「ほぼ全自動」という気分でした。でも、運用を続けるうちに、この仕組みの弱点が見えてきます。

タグ運用をやめて、statusプロパティ管理に切り替えた理由

切り替えた理由は、大きく2つあります。ひとつは、仕組みが拡張しにくかったこと。もうひとつは、Base Boardを入れて、プロパティで管理する強みが見えたことです。

フォルダとタグが増え続ける問題

ステータスごとにフォルダを決めていると、あとから種類を増やしたくなったときに困ります。フォルダが増える。それに対応するタグも増えていく…これが繰り返される。

AutoMover側の設定も、同じペースで増えていきます。「このタグなら、このフォルダ」というルールを、ひとつずつ足していく必要があるからです。気づくと、設定画面のルールの一覧が長くなっていました。

しかも、ルールの数が増えるほど、後から出てくる問題もあります。ルールの並び順に気をつけないといけなくなるのです。この話は、のちほど詳しく書きます。

Base Boardを入れて見えた、プロパティ管理の強み

決め手になったのは、Base Boardの導入です。Base Boardは、フロントマターのプロパティ値ごとに、ノートをカンバンの列として並べてくれます。ドラッグすると、プロパティの値も書き換わります。

使ってみて分かったことは、statusをプロパティとして持つほうが、一覧にも並べ替えにも向いているということでした。フォルダの場所で状態を表していると、カンバンで見たいときに、結局プロパティが必要になります。それなら最初から、プロパティを正とすればいい。

そこで、statusプロパティで状態を管理する運用に切り替えました。記事のフォルダは01_blog/Data/の1つに集約しています。フォルダが増える心配は、これでなくなりました。Base Boardの使い方は、Obsidian Base Boardの使い方｜プロパティ駆動カンバンでブログ管理を可視化するで紹介しています。

Blog Statusマクロでやっていること

タグを付け替える処理は、マクロから外しました。代わりに、statusを書き換える処理と、その周辺の処理を足しています。機能は、必要になった都度、少しずつ増やしてきました。

今のマクロは、Inbox／Progress／Draft／Public／Archiveの5段階から選ぶと、次の処理を実行します。

機能	動き
ステータスの切り替え	選んだ値をstatusに書き込む
publishedの自動入力	publicにしたとき、空なら当日の日付を入れる
更新情報ノートの書き換え	publicにしたとき、タイトルとURLを書き出す
Notionへのバックアップ	publicにしたとき、バックアップ用のスクリプトを呼び出す
ログの記録	変更前後のステータスなどを、ログのファイルに残す

全部を細かく説明すると長くなるので、動機を語れる3つに絞って紹介します。

一番効いたのは「更新情報ノートの自動書き換え」

いちばん助かっているのは、publicに切り替えたときの、更新情報ノートの自動書き換えです。

以前の手順は、こうでした。記事を書き終えたら、元の記事からタイトルとURLと概要をコピーし、それを更新情報のノートに貼る。そのあとで、サイトに公開する。数分もかからない作業ですが、公開の直前に必ず発生します。

今は、publicに切り替えるだけです。マクロが、記事のタイトルとURLを読み取って、更新情報ノートに書き出してくれます。中身は、QuickAddのマクロにUser scriptsとしてJSファイルを登録する形です。

※赤枠の部分で、使うスクリプトを選択

const postTitle = frontmatter.title || activeFile.basename;
const slug = frontmatter.slug || "";
const postUrl = frontmatter.url || (slug ? `https://haineons.com/${slug}/` : "");

const blogUpdateContent = `blogを更新しました：\n${postTitle}\n${postUrl}\n`;

URLは、slugから組み立てています。そのため、サイトで公開する前にpublicへ切り替えても、URLがすでに確定した形で書き出されます。私は、完成した時点で先にpublicにして、そのあとで公開しています。

publishedの自動入力とログ

publishedの自動入力も、地味に便利です。publicにしたとき、publishedが空なら当日の日付を入れる、というだけの処理です。

await app.fileManager.processFrontMatter(activeFile, (fm) => {
    fm.status = selected;

    if (selected === "public" && (!fm.published || fm.published === "")) {
        fm.published = todayString;
    }
});

空のときだけ入れるので、あとから手で直した日付を上書きする心配はありません。公開日の入れ忘れも、これでなくなりました。

もうひとつ、ログも残しています。ステータスを変えるたびに、変更前後の値と、各処理の結果を1つのファイルに追記する仕組みです。何かおかしいと感じたときに、あとから見返せる安心感があります。

あえて自動化しなかった部分と、まだ悩んでいること

ここまで読むと、「全部自動になった」と思われるかもしれません。実際は、手動のまま残している部分もあります。

SNSの投稿文は、その代表です。投稿用の文章はAIに頼んで作っていますが、自動で出てくるわけではありません。頼む作業が必要なので、自動化とは呼べないと考えています。投稿のタイミングも、以前より時間を置くようになりました。

公開のたびに、その場で判断したいことがあるからです。どのタイミングで出すか、どんな言葉で伝えるか。ここまで自動にしてしまうと、かえって窮屈になりそうでした。

もうひとつ、まだ悩んでいることがあります。今までのステータスにない、完全に新しい種類のノートを作るときです。5段階のstatusでは収まらないノートを、どう扱えばいいのか。いまのところ、答えは出ていません。

AutoMoverで今も気をつけている誤爆パターン

status中心の運用に変えてからも、AutoMoverは入口の仕分けに使っています。そして、ここで今でもたまに誤爆します。特に、新しいタグで移動させたくなって、ルールを足したときです。

原因は、AutoMoverの仕様にあります。タグのルールは一覧の上から順に判定され、最初に当たったルールだけが適用される仕組みです。これを意識しておかないと、意図しないフォルダへ移動してしまいます。

AutoMoverに触ってほしくないフォルダがある場合は、2枚目の画像のようにExclusion rulesへ追加しておくと安心です。

ネスト付きタグは、具体的なルールを上に置く

階層のあるタグ（memo/ideaのような形）を使うときが、いちばん間違えやすいところです。

次のように、2つのルールがあるとします。

順番	判定するタグ	移動先
1	memo	Memo
2	memo/(.+)	Memo/$1

この並びで#memo/ideaのタグが付いたノートを置くと、1番目のmemoに当たります。AutoMoverのルールは、タグの一部が合えば当たる仕組みだからです。結果として、期待していたMemo/ideaではなく、Memoに入ってしまいます。
この誤爆の厄介なところは、タグを付けたはずなのに意図したフォルダにノートが見当たらず、思わず「どこいった！？」と探す羽目になる点です。

対処はシンプルで、具体的なルールを上に置くことです。階層付きのルールを、階層なしのルールより前に並べておきます。新しいタグを足すときは、どこに差し込むかまで意識する必要があります。

複数のタグが付いたときは、ルールの並び順で決まる

もうひとつは、1つのノートに複数のタグが付いたときの判定です。

ここで決め手になるのは、タグを付けた順番ではありません。ルール一覧の並び順です。たとえば次の2つのルールがあるとします。

順番	判定するタグ	移動先
1	blog	Blog
2	reference	Blog/reference

#blogと#referenceの両方が付いたノートは、1番目のblogに当たって、Blogに引き戻されます。referenceのほうに入れたくても、そうはなりません。

私の環境でも、同じことが起きています。reference用のノートに、うっかりblogのタグも付けてしまうと、別のフォルダへ移ってしまうのです。複数のタグを使うときは、どちらを優先させたいのかを決めて、その順にルールを並べる必要があります。

AutoMoverのルールを足すときは、順番を確認する。この一手間を省くと、また誤爆します。

おわりに

最初から完成形を作る必要はなかった、というのが、ここまで運用してきた実感です。

タグでフォルダを分ける運用から始めて、マクロでタグの付け替えを楽にして、Base Boardを入れてstatus中心に切り替えました。遠回りに見えますが、どの段階にも理由がありました。その理由が積み重なって、今の形になっています。

まずは、statusを切り替える小さなマクロを1つ作ってみるのがおすすめです。使っているうちに、「ここも自動にしたい」という箇所が見えてきます。そうしたら、そのとき足せばいい。無理なく育てていく感覚で、試してみてください。その方が途中で挫折することなく運用していけるはずです。