概要
Obsidianをウェブに公開する方法は様々ありますが、最も簡単な方法はObsidian publishを月8という金額は安くありません。私はObsidian Sync(4を追加で支払いたくありませんでした。
この記事では、私が使用した方法を共有します。Obsidian Syncは使用しても使用しなくても構いませんが、公開用のコンピューター（ホームサーバーであればなお良い）が一つ必要です。サイト自体はGitHub Pagesを使用して公開するので、ホームサーバーが24時間稼働している必要はありませんが、記事を書くたびにホームサーバーを起動する手間がかかるでしょう。個人PCでもスクリプトを実行するだけでよいので問題ありません。
このブログは、Obsidian + Sync、Quartz、そして常に電源が入っているPC（遊んでいるPC）を組み合わせて、構築とデプロイが自動化されています。 どこからでもObsidianで記事を作成し同期すると、別のPCで自動的にビルドとデプロイのプロセスが進行する構造です。 これにより、ユーザーは記事の執筆にのみ集中できます。
記事の作成と同期: ObsidianとObsidian Sync
すべての記事はObsidianで作成され、自動的にMarkdown形式で保存されます。 PC、モバイルなど、Obsidianクライアントがサポートするあらゆるデバイスで記事を作成または編集できます。
Obsidianの公式有料サービスであるObsidian Syncを使用すると、すべてのデバイスのノートがリアルタイムで同期されます。この時、記事をGitHub Pagesにアップロードする用途のホームサーバーにもノートが同期されます。 これがこのシステムの核となる部分で、ローカルファイルではなくObsidianサーバーを単一の情報源（Single Source of Truth）として使用します。もしObsidianをPCでしか使用しない場合、PCのObsidian VaultがSSOTになります。
Obsidian Syncを使用しなくても構築自体は可能です。Gitなどで自己同期をするか、個人PCでしか使用しない場合でも、公開するフォルダを選んでGitHubにアップロードする部分だけを自動化すればよいためです。
自動ビルド環境: 遊んでいるPC
自宅で常に電源が入っているPC（ホームサーバーまたはデスクトップ）がこの役割を担います。ホームサーバーがない場合は、個人PCでも構築可能です。 このPCにもObsidianアプリがインストールされており、同じObsidianアカウントでログインしてノートを同期します。
ホームサーバーにはLinuxをインストールしており、ここでinotify-toolsを使用してObsidian Vaultディレクトリのファイル変更をリアルタイムで検知します。
ファイル変更が検知されると、自動的にビルドとデプロイのプロセスを開始します。
自動デプロイが不要であればこの部分はスキップしても構いませんが、その場合はPCで以下のデプロイを手動で実行する必要があります。
ビルドとデプロイの自動化: Quartzとシェルスクリプト
まずデプロイのためには、Obsidian Vaultではなく、別途新しいプロジェクトフォルダを作成する必要があります。Obsidian Vaultには触れず、すべてのデプロイ作業はプロジェクトフォルダで進行します。
Quartzは静的ウェブサイトビルダーの一つで、Obsidianを公開することに最適化されたプログラムです。グラフも描画でき、ローカルでビルドも可能です。
Obsidian Vault内の公開するフォルダのファイル変更を検知した際に、以下の動作を実行します。
- コンテンツ同期: Obsidian Vaultの最新内容をプロジェクトの
contentディレクトリにコピー（rsync）。 - サイトビルド: Quartz CLI（
npx quartz build）を使用してMarkdownファイルを静的ウェブサイトファイルに変換し、publicディレクトリにビルド。 - Gitプッシュ: 変更があった場合、Gitを使用して自動的にコミットし、リモートリポジトリ（GitHub）にプッシュ。
Obsidianの記事を直接触らず、公開用フォルダにコピーした後、このフォルダ内のコンテンツを加工して公開するため、既存の記事は安全です。また、Obsidian Vault全体を公開するのではなく、公開用フォルダを選択できます。該当フォルダのみを公開用フォルダとして公開するからです。
ここで「フォルダ内コンテンツ加工」とは、コピー後にコンテンツに自動で肉付けしたり、翻訳コピーを新たに追加生成したりすることを指します。このサイトの場合、コピー後に自動で3カ国語にGeminiが翻訳コピーを生成します。コピー後に生成されるため、既存のObsidian Vaultには不要な翻訳版は表示されず、実際にファイルを「生成」してから公開するため、その言語でも外部から検索できるようになります。
最終的な公開: GitHub Pagesとカスタムドメインの接続
メインブランチに新しいコミットがプッシュされると、事前に設定されたGitHub Actionsワークフローがトリガーされます。
このワークフローはpublicディレクトリの静的ファイルをGitHub Pagesにデプロイします。
必要であればビルドをPC（サーバー）ではなくGitHub Pagesで行うこともできますが、この場合ビルドにも時間がかかり、ローカルでウェブサイトをテストするのが面倒になります。そのため、私はPC（サーバー）で事前にビルドを行い、完成したページだけをアップロードすることを選択しました。
GitHub Pagesの設定
実際のデプロイはGitHub → GitHub Pagesを通じて公開されます。したがって、Pagesの設定も行う必要があります。
GitHubリポジトリ設定の「Pages」セクションでGitHub Pagesを設定できます。
「Source」を「Deploy from a branch」に設定し、「Branch」をgh-pages（またはmainブランチのdocsフォルダ）を選択した後、/(root)フォルダを選択します。
保存するとGitHub Pagesが有効になります。
もしご自身で購入したCustom domainがある場合は、一緒に設定してください。
結論
このシステムを通じて、ユーザーは記事の執筆にのみ集中できるようになります。Obsidianに記事を書いて保存するだけで、複雑なビルドとデプロイのプロセスが自動的に処理されます。
Obsidian Syncを中央ハブとして使用し、遊んでいるPCを自動化エージェントとして活用するのが、この構造の核心アイデアです。遊んでいるPCがない場合は、ご自身のPCでデプロイスクリプトを一度実行するだけで、自動的に「Obsidian Vault → Copy to Content directory → Process contents → Upload(push) → Publish」が行われます。
追加
この全てのプロセスを直接コーディングしたわけではなく、Codex、Claude Code、Geminiの助けを借りて開発しました。
個人的にはGeminiはまだローカルでのコーディング作業をプロジェクト単位でさせるには適していないと感じているため、翻訳用途のみで使用しています（3.0モデルに期待しています）。CodexやCCに、現在の自身の環境（ホームサーバーの有無など）と上記の情報を整理してサイト構築を依頼すれば、うまくやってくれるでしょう。したがって、本文にはスクリプトコードなどは含んでいません。アイデアを共有しますので、ご自身の環境に合わせてうまくチューニングしてください。