以前、Obsidianを中心にPARA・GTD・AIを組み合わせて「第二の脳」を運用している話を書きました。

そこでは、Obsidian Vaultを単なるノート置き場ではなく、WebクリップやYouTubeの要約、用語調査、AIによる整理などを集約する個人用のKnowledge Baseとして使っています。PARAで情報の置き場所を決め、GTDで情報を処理し、AIワークフローでその運用を補助する、というアプローチです。

AIと共に耕す知識の庭：PARA × GTD × Obsidianで作る第二の脳

また別の記事では、画像が増えてVaultが肥大化してきたことをきっかけに、Cloudflare R2へ画像を逃がし、MkDocsで静的サイトを生成してCloudflare Pagesから参照できるようにしました。これによって「Obsidianを開かなければVaultを見られない」という制約からも少しずつ離れています。

Obsidian Vaultを「個人ナレッジ基盤」に変える——Cloudflare R2 + mkdocs + Pages + Access構成ガイド

このあたりまで仕組みを作ると、「Obsidianをどう使うか」というより、このKnowledge Baseをどう運用するかという話になってきます。 以前の同期方式を説明した記事はこちらです。

Obsidian同期ガイド：PC・iPhone・iPad間でノートを自動連携させる方法

そして実際に1年くらい運用してみると、同期部分に無理が出てきました。 今回は、Windows、Linux、iPhoneのすべてでVaultを同期していた構成をやめ、「GitHub同期はLinux母艦だけ」という構成へ変更した話を書いてみます。

※なお、この記事では便宜上「GitHub同期」と表現していますが、現在のGitHubの主な役割は端末間のファイル同期ではなく、Gitによる履歴管理とリモート保管です。

これまで：どの端末にもVaultを持たせていた

以前の構成は、ざっくり言うと次のようなものでした。Windows、Linux、iPhoneのすべてにObsidian Vaultが存在し、それぞれからGitHubと同期する構成です。

WindowsではObsidianを普通のノートアプリとして使います。ChromeやEdgeからWeb Clipperで記事を取り込み、Obsidianでノートを書いたり編集したりします。 一方、Linux側のVaultはもう少し特殊です。Obsidianで編集するだけでなく、Claude CodeやCodexから直接Vaultを操作します。

さらにLinux上のDockerではn8nを動かしていて、

• WebコンテンツのClipping
• 用語調査
• YouTubeサマリ
• その他の情報収集ワークフロー

などを実行し、その結果をVaultへ保存しています。

以前の記事で書いたPARA + GTDの構成では、こうして収集した情報をまず 0_Inbox に入れ、あとからProject、Area、Resourceなどへ整理する運用にしています。AIによるワークフローも、この運用を継続するための重要な仕組みになっています。

つまりこの時点で、Vaultを変更する主体は自分だけではありません。

graph TD
    subgraph 人間
        H1[Windows / Obsidian]
        H2[Linux / Obsidian]
        H3[iPhone / Obsidian]
    end
    subgraph AI自動化
        A1[Claude Code]
        A2[Codex]
        A3["n8n (Docker)"]
    end
    H1 --> Vault[(Markdownファイル群)]
    H2 --> Vault
    H3 --> Vault
    A1 --> Vault
    A2 --> Vault
    A3 --> Vault

これらすべてが、同じMarkdownファイル群を触る可能性があります。そして変更履歴の管理と端末間同期の中心にはGitHubがありました。

2つの問題点

問題1：GitHubを「同期ツール」にするとコンフリクトがつらい

GitをVault管理に使うこと自体は、今でも良いと思っています。

以前の記事でも書きましたが、自分のVaultにはMarkdownだけでなく、スクリプトやAIワークフローの定義なども入っています。変更履歴を確認できる、過去の状態へ戻せる、diffを見られる、ブランチを切って大きな変更を試せる、といった性質は自分のVaultと非常に相性が良いです。

問題は、Gitを端末間のリアルタイムに近い同期まで兼ねるようにしたことでした。

WindowsでDaily Noteを編集する。その間にLinuxではClaude Codeが複数のノートを書き換える。さらにn8nが新しいノートを追加する。こうしたことが重なると、次のような形で競合します。

flowchart TD
    subgraph 端末
        Win[Windows の変更]
        Lin[Linux の変更]
    end
    GH[GitHub]

    Win -->|push| GH
    Lin -->|push| GH
    GH -.->|競合 / コンフリクト発生| GH

AIを導入する以前なら、それほど大きな問題ではありませんでした。しかし現在はAIエージェントが数十ファイル単位で変更することがあります。 人間一人でノートを書いていた頃とは、Vaultへの書き込み量そのものが違います。

Gitは履歴管理としては非常に優秀です。しかし、複数マシン間で頻繁にファイルを同期するというのは本来の用途ではないと理解しました。 よって、履歴管理と同期を分けるアプローチをとろうというわけです。

問題2：iPhoneからGitHub同期できなくなった

もう一つ、構成を見直す直接的なきっかけになったのがiPhoneです。

これまではiPhoneにもVaultを置き、ToDoを追加する、Daily Noteを書く、Vaultを参照する、といった使い方をしていました。

ところが自分の環境では、Obsidianアプリ側がiCloudとObsidian Syncのみの対応となり、GitHubを使った従来の同期が使えなくなりました。

最初は、「ではiPhoneでも別の方法でVault全体を同期できないか？」と考えて運用していましたが、方針変更を強いられたわけです。

発想を変える：すべての端末にVaultを置かなくていい

そもそもiPhoneにVault全体が必要なのだろうか？ iPhoneから自分が実際に行っている操作を考えてみると、それほど多くありません。主に、

1. ToDoを追加する
2. Daily Noteへメモする
3. 過去のノートを読む

くらいです。

であれば、「書き込みはAPI、読み取りはWeb」で割り切ってよいのではないか。 この考えから、現在の構成に変わりました。

現在：GitHub同期はLinux母艦だけ

現在の構成がこちらです。

一番大きな変更点は、「GitHubとのVault同期をLinuxだけに限定した」ことです。

現在は、以下のような経路にしています。

flowchart TD
    Win[Windows] <-->|Syncthing| Linux[Linux 母艦]
    Linux <-->|Git| GH[GitHub]

WindowsとLinuxの間はSyncthing。LinuxとGitHubの間はGit。役割を完全に分けました。

Syncthingは「マシン間同期」

WindowsとLinuxの間では、単純に同じMarkdownファイルを使いたいだけです。そこで、マシン間の同期には Syncthing を使うようにしました。

Windows側から見れば、今まで通りObsidianを開けばVaultがあります。ChromeやEdgeからClipすることもできます。自分がWindows側でGitのpullやpushを意識する必要はありません。変更はSyncthingによってLinuxへ同期されます。

もちろんSyncthingでも、完全に競合がなくなるわけではありません。同じファイルをWindowsとLinuxから同時に変更すれば競合の可能性は残ります。

ただし、Gitのブランチ状態、未commit、pull、mergeといった状態管理を複数マシンで持たなくてよくなったことは、自分にとってかなり大きな違いでした。

GitHubは「履歴管理」に戻す

一方、GitHubとの同期はLinuxだけが担当します。これはGitをやめたわけではありません。Gitを履歴管理に集中させるための変更です。

LinuxをGitHubへのゲートウェイにすることで、各端末から直接pushするのではなく、操作主体をLinuxへ寄せることができます。AIエージェントによる変更も含めて、履歴を一元的に管理しやすくなりました。

Linuxを「母艦」と呼んでいますが、WindowsとLinux間のSyncthingは双方向です。そのため厳密な意味でLinuxだけがSingle Source of Truth（唯一の正本）というわけではありません。GitHubとの同期・AI処理・自動化を集約する運用上の母艦、という意味合いです。

Linuxは「Obsidianを動かすPC」からKnowledge Baseサーバーへ

以前の記事を書いた頃から、その兆候はありましたが、Linux上では、Obsidian、Git、Claude Code、Codex、n8n、Docker、MkDocs関連処理などが動いています。 現在の感覚としては、個人Knowledge Baseのバックエンドといったところです。

graph TD
    Win[Windows] <-->|Syncthing| LinuxVault[(Linux Vault)]
    LinuxVault <-->|Git| GH[GitHub]

    subgraph Linux環境
        CC[Claude Code] -->|ファイル操作| LinuxVault
        Codex[Codex] -->|ファイル操作| LinuxVault
        Obs[Obsidian] <--> LinuxVault
        N8N[n8n] -->|自動追記| LinuxVault
    end

iPhoneはVaultを持たない

現在の構成でもう一つ大きく変えたのがiPhoneです。iPhoneにはVaultをローカルに持たせないことにしました。これによって、「どうやってiPhoneへVaultを同期するか？」という問題そのものをなくしています。

書き込みはShortcut → n8n API

ではiPhoneからToDoやDaily Noteをどう更新するのか。Appleのショートカットからn8nへAPIコールしています。

sequenceDiagram
    autonumber
    actor User as iPhone (Shortcut)
    participant N8N as n8n (HTTP API)
    participant Vault as Linux上のVault

    User->>N8N: HTTP POST (ToDo / DailyNote内容)
    N8N->>Vault: ノートを更新・追記

iPhone側には「ToDoを追加する」「Daily Noteへ追記する」といったショートカットを用意します。ショートカットからAPIを呼び出し、n8nが受け取ってLinux上のVaultを更新します。

つまりiPhoneは、「Vaultそのものを扱うクライアント」ではなく、「Vaultに操作を依頼するクライアント」になりました

n8nがVaultのAPI層になってきた

もともとn8nは情報収集の自動化に使っていました。Clipping、用語調査、YouTubeサマリなど、以前の記事で紹介した「インプットを構造化ノートへ変換する」という考え方ともつながっています。

そこへ今回、「iPhoneからのVault操作」という役割が加わりました。結果としてn8nが、

flowchart LR
    subgraph 以前
        direction LR
        Ext1[外部情報] --> N8N1[n8n] --> V1[(Vault)]
    end

    subgraph 現在
        direction LR
        Ext2[外部情報] --> N8N2[n8n / API Gateway]
        iPhone[iPhone Shortcut] --> N8N2
        N8N2 --> V2[(Vault)]
    end

というように、VaultへのAPI Gatewayに近い位置へ移ってきています。これは自分でも当初は想定していなかった変化です。

読むだけならObsidianすら要らない

一方、「iPhoneから過去のノートを読みたい」という用途については、すでに別の仕組みを作っています。以前の記事で紹介した、MkDocs + Cloudflare Pages + R2 です。 ObsidianのMarkdownをMkDocsで静的サイトへ変換し、その成果物をGitHub経由でCloudflare Pagesへデプロイしています。画像についてはCloudflare R2へ配置し、Webサイト側から参照します。

flowchart TD
    LV[(Linux Vault)] -->|静的サイト生成| MkDocs[MkDocs]
    MkDocs -->|成果物コミット| GH[GitHub]
    GH -->|デプロイ| Pages[Cloudflare Pages]
    R2[(Cloudflare R2)] -.->|画像ロード| Pages
    Pages -->|Webブラウザ閲覧| iPhone[iPhone]

読むならWeb。書くならAPI。非常に単純です。認証についても、既存構成の通りCloudflare Accessを使って、自分だけが閲覧できるサイトとして運用しています。

画像は引き続きCloudflare R2へ

画像についても、以前構築した仕組みをそのまま利用しています。

Obsidianではスクリーンショットなどを普通のローカル画像として扱いつつ、Webから参照するときはR2へアップロードした画像を使います。以前の記事では、ローカル画像をスクリプトでR2へまとめてアップロードし、Markdown内のリンクを置換する方式にしました。これによって、Gitリポジトリそのものを画像で肥大化させずに済みます。

元々この仕組みを作った理由の一つは、画像が増えてVaultのサイズが大きくなり、全端末へ同期するコストが気になり始めたことでした。画像をR2へ分離し、MarkdownをWebとして参照できる構成にしたことで、Vault全体を端末へコピーしなくても情報へアクセスできるようになりました。

今回の同期構成変更とは別の話に見えますが、「端末へすべてのデータを持たせなくてもよい」という発想では共通しています。

以前と現在で、何が変わったのか

整理するとこのようになります。

使っているサービスの種類は、むしろ増えています。それでも以前より運用が分かりやすくなりました。理由は、それぞれの役割が明確になったからだと思います。

Sync / Version Control / Read / Writeを分ける

今回の変更を自分なりに整理すると、次の4つを分離したことになります。

• Sync → Syncthing
• Version Control → Git / GitHub
• Read → MkDocs / Cloudflare Pages
• Write from Mobile → Shortcut / n8n API

以前はこれらの多くを、「Vaultを各端末へ同期する」という一つの問題として考えていました。

しかし実際には、それぞれ別の要件です。ノートを同期したい。変更履歴を残したい。スマートフォンから読みたい。スマートフォンからToDoを書きたい。これらを同じ仕組みで解決する必然性はありません。むしろ分離した方が、構成は理解しやすくなりました。

PARA × GTD × AIの「運用基盤」も変わった

以前の記事では、

構造（PARA）× フロー（GTD）× 自動化（AI）

という考え方でObsidianを運用している、と整理しました。この考え自体は今も変わっていません。

ただ、その下を支えるインフラはかなり変わりました。現在なら、もう一段下に運用基盤のレイヤーがあると考えています。

flowchart TD
    subgraph 構造
        L1[PARA]
    end
    subgraph フロー
        L2[GTD]
    end
    subgraph 処理
        L3["AI / n8n"]
    end
    subgraph データ
        L4[Obsidian Vault]
    end
    subgraph 運用基盤
        L5["Syncthing / GitHub / API / MkDocs / Cloudflare"]
    end

    L1 --> L2
    L2 --> L3
    L3 --> L4
    L4 --> L5

PARAやGTDをどれだけ綺麗に設計しても、同期で毎回トラブルになれば使い続ける気は失せます。AIによる自動化を増やしても、ファイル競合の対応ばかりしていたら本末転倒です。

以前の記事で「良い仕組みは、運用されて初めて価値を持つ」と書きました。今回の変更は、まさにその「運用」を支える部分の見直しだったと思っています。

Obsidian中心からVault中心へ

もう一つ、自分の中で変わったことがあります。以前は、「Obsidianをどう便利に使うか」を考えていました。現在は、「VaultというKnowledge Baseをどう使うか」を考えることが増えています。

Obsidianは、そのVaultを編集する優れたUIの一つです。しかしVaultにアクセスする方法は、それだけでなくてもよい。

graph TD
    Obs[Obsidian / 人間] <--> Vault[(Vault)]
    CC[Claude Code] --> Vault
    Codex[Codex] --> Vault

    iOS[iPhone Shortcut] --> N8N[n8n]
    N8N --> Vault

    Vault --> MkDocs[MkDocs]
    MkDocs --> GH[GitHub]
    GH -->|デプロイ| Pages[Cloudflare Pages]
    Pages -->|閲覧| Browser[Webブラウザ]

人間はObsidianから触る。AIはファイルとして触る。iPhoneはAPIから触る。閲覧はWebから行う。 この形になってくると、Obsidian Vaultは単なるノートフォルダというより、自分のKnowledge Baseのデータストアという表現の方がしっくりきます。

まとめ

今回の変更で一番大きかったのは、Syncthingを導入したことでも、n8nにAPIを作ったことでもありません。

「すべての端末にVaultを同期する」という前提を捨てたことでした。

以前は

flowchart LR
    Win[Windows] --> GH[GitHub]
    Lin[Linux] --> GH
    iPhone[iPhone] --> GH

という発想でした。現在は、

flowchart TD
    Win[Windows] <-->|Syncthing| LinuxVault[(Linux Vault)]
    LinuxVault --> MkDocs[MkDocs] --> GH[GitHub] -->|デプロイ| Pages[Cloudflare Pages / 閲覧]

    iPhone[iPhone] -->|書く: Shortcut| N8N[n8n] --> LinuxVault
    iPhone -.->|読む: ブラウザ| Pages

です。

GitHubは履歴管理。Syncthingはマシン間同期。n8nは自動化とAPI。MkDocsとCloudflare Pagesは閲覧。R2は画像。それぞれに役割を分けました。

そして、そのVaultを人間、AI、自動化、PC、スマートフォンからどう安全に使うかを設計する。「Obsidianを同期する」から「個人Knowledge Baseへのアクセスを設計する」へ。 今回の構成変更は、そんな考え方の変化を反映したものだと思います。