Skip to content
Yuki on Twitter

Obsidian に集約したら「書くこと」が捗るようになった

# Memo # Essay
目次

個人のナレッジベースとして使っている Obsidian でブログ記事 (markdown) も管理する運用にしたら、「書くこと」が捗るようになった気がするので、その方法とメリット・デメリットを紹介します。

🎧 音声概要 (※ NotebookLM で生成されており、誤りを含む場合があります)

分散する markdown

今、自分のプライベートで markdown を扱う場所が主に以下の3つあります。

  • ナレッジベース: Obsidian
  • このブログ: Astro
  • デジタルガーデン: Quartz [1]

それぞれが別のプロジェクト (ディレクトリ) として存在しています。雑に図にすると以下のような感じです。

Fig. 1 変更前の構成

それぞれが別のディレクトリで管理されており、文章を書くにはそれぞれを行き来する必要がありました。

ディレクトリを開くこと自体はそれほど手間ではないものの、書く際のインターフェイスが変わることによる微妙なスイッチングコストを感じていました。

例えば、Obsidian 上では当然ながら Obsidian のインターフェイスで文章を書きますが、ブログやデジタルガーデンでは基本的にコードエディタ上で書く必要があります。

もちろん、ブログなどの markdown ファイルを Obsidian の vault として開くことも物理的には可能ですが、普段使っている Obsidian の設定を引き継いだり同期させたりするのが手間でした。

自分は不精なのでこういう絶妙な"面倒くささ"が積み重なり、書くことが億劫になってしまうことが多々ありました。

Obsidian に集約する

そこで、「どうせすべて markdown で書いているなら、Obsidian 側に寄せてしまえばいいのでは？」と考えました。

自分は普段、個人的なメモや文章を残す場所として Obsidian を最も利用しています。 Plugin を有効化すれば Vim キーバインドも使えるし、拡張性がかなりあるのでストレスなく使えています。

Obsidian の中には例えば以下のようなものが含まれ、すべて markdown で記述しています [2] 。

  • デイリーノート (日々の記録)
  • 読書メモ
  • アイデアメモ
  • etc...

ディレクトリ構成で言えば、こんな感じです:

.
├── 00_Inbox
├── 01_Main_Notes
├── 02_Literature_Notes
├── 03_Topic_Notes
├── 04_Daily_Notes
├── 05_Project_Notes
└── 99_Templates

Obsidian にブログ記事等を集約するために、上記の中に専用のディレクトリを作ります。

具体的には上記の tree でいう 05_Project_Notes の中にブログとデジタルガーデン用のディレクトリを作成し、その作成したディレクトリと、ブログ (Astro) およびデジタルガーデン (Quartz) 側のコンテンツをシンボリックリンクで紐づけることで実現します。

例えば、ブログコンテンツ用に 05_Project_Notes/Blog/content というディレクトリを作成し、Astro 側の content ディレクトリとして紐づけるためには以下のコマンドを実行します。

# Astroプロジェクトのディレクトリ内で実行する例
# /path/to は適宜実際のObsidian Vaultへのパスに置き換える
ln -s /path/to/05_Project_Notes/Blog/content ./content

やっていることの雑なイメージは以下の通りです。

Fig. 2 シンボリックリンクで統合する

こうすることで、ブログ記事の実体である markdown ファイルをすべて Obsidian Vault 内に格納することができ、「公開する文章も、日々のメモも、すべて Obsidian 上で書く」という体験を実現できます。

メリットとデメリット

Obsidian に集約する運用にして感じているメリットとデメリットは下記の通りです。

メリット:

  • ブログを書くことへの心理的なハードルが下がる
    • 日々のメモの延長線上で書き始められる
    • ツール間の差異によるスイッチングコストが無い
  • 文書を一元管理できて楽
    • 情報があちこちに散らばらない
    • ナレッジベースをソースにして AI を活用するとき [3] も扱いやすい

デメリット:

  • CI/CD でのビルドに工夫が必要になる
    • プロジェクトのソースコード側にコンテンツの実体 (markdown) が含まれなくなるので、GitHub Actions など CI/CD プラットフォーム上でのビルドがそのままでは動かなくなる
  • ディレクトリを移動したり構成を変更すると動作しなくなる

一番大きいメリットは、やはり使い慣れた Obsidia 上で思考から執筆までをシームレスに行えることです。

Obsidian のテンプレートを使ってさっと書くための土台を整えられるし、Shell command を実行できるようにすれば Obsidian 上でビルド/デプロイコマンドの実行だってできます。 そして、Web viewer の機能を使えば preview を見ながら執筆だってできちゃいます。便利です。

Fig. 3 Web view で preview が見れる

一方デメリットは、CI/CD 上でビルドやデプロイを行うためには一工夫必要になることです。

自分の場合は、今まで GitHub Actions 上で実施していたプロセスを、ローカル上で実施する運用に変更しました。 大きなプロジェクトを扱っているわけではないので、特段今のところ問題は無いです。

Vercel を使う場合、以下のようにローカルからコマンドを実行することでビルドとデプロイを実施できます。

vercel build --prod && vercel deploy --prebuilt --prod

おわりに

以上、ブログコンテンツなど markdown で書くものを Obsidian 上で一元管理する方法について見てきました。

この運用にしてから、今までより記事を書くことの心理的な抵抗が減ったことを実感しています。 もしいま Obsidian を使っていて、markdown でブログやコンテンツを書いているよという方がいたら是非。おすすめです。

ここまでお読みいただきありがとうございました。

[1]
デジタルガーデンについては「デジタルガーデン」はじめました🪴で書きました↑
[2]
情報整理についてはこちらのポストを参照してください↑
[3]
例えば Obsidian の vault を Cursor で開く、みたいな話です↑