この記事の結論
ObsidianのVaultは、GitHubの非公開リポジトリに置き、Claude Codeのフックで自動同期できます。2台のMacで使うと競合や取り込みの失敗が起きたため、変更が重ならなければ自動で通す仕組みと、作業中のファイルに触れない同期に作り直しました。
目次10項目
- ObsidianのVaultをGitHubで同期する仕組み：フックで送受信を自動にした
- Obsidian VaultをGitHubに置く手順と、.gitignoreで外すもの
- Obsidian GitプラグインとClaude Codeのフック、どちらで同期するか
- 2台のMacで同じVaultを同期したら、400回中19回が取り込みに失敗した
- 無人の定期タスクが同期ガードで止まった件と、2026年10月5日の自動修復
- 2026年10月23日、rebaseをやめて作業中のファイルに触れない同期に作り直した
- 作り直した後の同期73回：72回が成功し、残る1回も次の回で解消
- 2台以上でObsidianのVaultを同期するときに決めておくこと
- まとめ
- よくある質問
【無料・メールだけ】Claude Code 2daysセミナー（第二の脳構築講座）の次回開催の案内を受け取る →
ObsidianをGitHubで同期するとき、僕に必要だったのは便利なプラグインではなく、「2台のMacが同時に書いても壊れない手順」でした。僕の会社では、Claude CodeのフックがVaultをGitHubへ送り、相手の変更と重ならなければ自動で合わせ、重なるときだけ止めます。
この形になるまでに2回作り直しました。片方のMacの記録では、作り直す前の同期400回のうち19回が取り込みに失敗し、2026年10月23日に作り直した後は73回中72回が成功しています。
この記事では、Vaultを置く手順と外すべきファイル、Obsidian Gitプラグインとの違い、2台運用で実際に起きた失敗と直し方を順に書きます。「1台ならうまくいくのに、2台目を足したら同期が怪しい」と感じている方に向けた記録です。
ObsidianのVaultをGitHubで同期する仕組み：フックで送受信を自動にした
僕の会社のObsidianのVaultは、GitHubの非公開リポジトリに置き、Claude Codeのフックで自動同期しています。人が「保存しよう」と思わなくても、AIとの作業が区切れるたびに変更が送られます。
導入したのは2026年7月19日です。セッションの開始時（SessionStart）と、Claudeが応答を終えたとき（Stop）に同期スクリプトを動かしています。
導入のいきさつと最初の2か月半の記録は、Obsidianの使い方（同期とバックアップの節）に書きました。
最初はmacOSの定期実行（launchd）で回すつもりでした。ところが書類フォルダの保護（TCC）で動かせなかったので、Claude Codeのフックに切り替えています。止まった症状と、launchdを使い続けるときの逃げ道はMacのlaunchdで定期実行する方法とTCCの落とし穴に書きました。
フックの書き方そのものはClaude Code hooksの使い方にまとめています。この記事の主役は、そのあとに2台目のMacを足してから起きたことです。
Obsidian VaultをGitHubに置く手順と、.gitignoreで外すもの
手順は、VaultのフォルダでGitを始め、GitHubに非公開のリポジトリを作って送るだけです。むしろ大事なのは、送る前に「入れないもの」を決めておくことでした。
最初にやる3つ
- VaultのフォルダでGitの管理を始め、最初の記録（コミット）を作る
- GitHubで非公開（Private）のリポジトリを作り、Vaultからそこへ送る
- 送る前に
.gitignoreを書き、入れないファイルを外す
Obsidian公式のヘルプは、Gitを使うなら2つのファイルを .gitignore に入れるよう勧めています。.obsidian/workspace.json と .obsidian/workspaces.json です。
どちらも画面の配置を記録するファイルで、ノートを開くたびに書き換わります。入れたままだと、意味のない変更が毎回記録されます。
認証情報は「2か所」で外す
僕の会社では、認証情報を書いたファイルを .gitignore と、Vault内の「除外一覧」のノートの2か所で外しています。新しく外したいファイルが増えたら、必ず両方を直す決まりです。
2か所に分けたのは、.gitignore だけだと、なぜ外したのかが残らないからです。除外一覧には理由を書いておき、AIが新しく認証情報を書くときに先に確かめられるようにしています。
外し忘れたときに知っておくこと
Gitの公式ドキュメントには、すでに記録されているファイルは .gitignore の影響を受けないと書かれています。外すには git rm --cached で記録から外す必要があります。
さらにGitHubの公式は、秘密の値を記録してしまったら、まずその値を無効にするか変えることを最初の手順にしています。ファイルを消す記録を足しても過去の記録は消えないため、公式の手順は履歴の書き換えまで含んでいます。
Obsidian GitプラグインとClaude Codeのフック、どちらで同期するか
Obsidianの画面で完結させたいならプラグイン、AIにVaultを書き換えさせるならClaude Codeのフックが向いていると僕は考えています。僕の会社はプラグインを入れず、フックだけで回しています。
比べる前に前提を1つ書きます。Obsidian公式のヘルプでは、デスクトップのGitは「自動では同期されず、手で送受信する」方法として紹介されています。自動にするには、どちらかの仕組みを足す必要があります。
| 比べる点 | Obsidian Gitプラグイン | Claude Codeのフック（僕の会社） |
|---|---|---|
| 動くきっかけ | 決めた間隔ごと・Obsidianの起動時 | セッションの開始時・Claudeの応答が終わったとき |
| 画面での確認 | 変更一覧・履歴・差分をObsidianの中で見られる | ログのファイルと通知で見る |
| スマホ | READMEで「実験的」「とても不安定」と案内 | 対象外（スマホのアプリでは動かさない） |
| 向く使い方 | 人がObsidianで書くのが中心 | AIがVaultを読み書きするのが中心 |
| 作る手間 | プラグインを入れて設定する | スクリプトを自分で書いて保守する |
プラグインの作者は、モバイルでの利用を勧めていません。リポジトリが大きいと取り込みの途中で落ちることがあり、モバイルではSSH認証も使えないとREADMEに書かれています。
僕がフックを選んだのは、Vaultを書き換える主役がAIだからです。AIの作業が区切れたときに送れば、決まった間隔を待たずに済みます。
スマホからは、GitHub上のVaultをAIに読ませる形で使っています（Claude Codeをスマホで動かす方法）。
2台のMacで同じVaultを同期したら、400回中19回が取り込みに失敗した
2台目のMacを足してから、同期は「たまに止まるもの」になりました。片方のMacのログを数えると、2026年10月9日から23日夜までの同期400回のうち、19回が取り込みに失敗していました。
設計の時点で想定していた競合
2台目のMacを入れた直後の2026年8月22日に、2台運用の設計メモを書いています。そこには、2台で同期のフックが同時に走ると同じファイルの同時編集で競合する、というリスクを書き、競合を月0件に抑えることを目標にしていました。
翌8月23日には、同期スクリプトに安全装置を足しました。記録にどちらのMacかの名前を入れ、前回の結果を残して失敗を知らせる仕組みです。Macの移し替えの話はClaude Codeを新しいMacに移行する方法に書いています。
失敗の中身は「ぶつかった」ではなかった
当時の同期は、変更を記録したあと git pull --rebase で取り込み、失敗したら取り消して次回に回す作りでした。ログの19回はどれも「rebase_conflict」ですが、中身は違いました。
| 失敗の表示（要約） | 回数 |
|---|---|
| 未記録の変更があるので取り込めない（unstaged changes） | 10 |
| 別のgitの操作が使用中（index.lock） | 5 |
| Cannot rebase onto multiple branches | 3 |
| 参照の書き換えが鉢合わせた（cannot lock ref） | 1 |
ファイルの中身がぶつかったことを示す「CONFLICT」の行は、同じ期間に0回でした。止まった原因は、同じMacの中で同期とほかの作業が重なったことだと僕は読んでいます。
Vaultには、対話のセッションのほかに無人の定期タスクも書き込みます。記録した直後に新しい変更が入れば、取り込みは「未記録の変更がある」と言って止まります。2台の競合を心配していたのに、実際は1台の中の鉢合わせが多かったわけです。
止まったまま気づかなかったもう1台
もう1台のMacは、2026年10月11日からGitHubへ送れていませんでした。10月23日に確かめた時点で、送れていない記録が105件、取り込めていない記録が559件たまっていました。
自動同期はそのMacの中で記録を作り続けていたので、Vault自体は無事でした。ただ、2台が12日間ずれたまま動いていたことになります。
無人の定期タスクが同期ガードで止まった件と、2026年10月5日の自動修復
同期とは別に、書き込みの直前に同期の状態を確かめる「同期ガード」も置いています。これが無人の定期タスクを止めてしまったので、2026年10月5日に「変更が重ならなければ自分で同期して通す」自動修復を足しました。
同期ガードは何を止めるのか
ここでいう同期ガードとは、AIがVaultのファイルを書き換える直前（PreToolUse）に動き、危ない状態なら書き込みを止めるフックです。危ない状態とは、相手のMacが先に進んでいるのに、こちらにも未送信の変更がある状態を指します。
Claude Codeの公式ドキュメントでは、PreToolUseのフックが終了コード2を返すと、その操作は止まり、フックの出力がClaudeに届きます。僕のガードはこれを使い、止めた理由と直し方をAIに渡しています。
無人のタスクには「回避しない」と決めていた
2026年10月3日に、記事を書く定期タスクの手順に「同期ガードで止まったとき」の節を足しました。止まったら回避せず、その記事を保留にして、結果のメールで知らせて終える決まりです。
ガードを外す逃げ道もありますが、無人のタスクには使わせていません。人がいないところで同期の安全装置を外すと、壊れたときに誰も気づけないからです。
ところが、これで止まる回が続きました。社内の記録には、総括のメールが届かない回や記事の保存に失敗する回が続いたため、と自動修復を足した理由が残っています。
「重ならなければ通す」の中身
10月5日に足した自動修復は、こちらの変更と相手の未取込の変更が同じファイルに触れていないかを先に確かめます。重ならなければ、退避の記録を作り、pull --rebase で取り込み、送ってから書き込みを通します。
同じファイルに両方の変更がある、gitが使用中、どれかの手順が失敗した、のどれかなら従来どおり止めます。判断がつかないときも止める側に倒しました。
比べ方の1文字の違いで、未送信の記録があると必ず止まっていた
10月15日の夜に、比べ方の誤りを1つ直しています。相手の変更だけを数えるつもりの比較が、自分の未送信の変更まで数えていました（gitの差分の取り方で、点2つと点3つの違いです）。
未送信の記録が手元にあるときは、自分の変更が必ず「重なり」に見えて止まる誤りです。それでも、送り終えて未送信が無い場面では、自動修復は通っていました。
gitの記録では、自動修復の退避コミットは10月5日に1回、15日に119回、16日に167回あり、10月23日までの合計は309回でした。15日の119回は夜8時台の30分に集中していて、直す前の版が出したものです。
2026年10月23日、rebaseをやめて作業中のファイルに触れない同期に作り直した
2026年10月23日に、同期の取り込みから rebase を外しました。相手の変更を、作業ツリー（いま手元で開いているファイル）の外で試しに合わせ、ぶつからないときだけ反映する作りです。
きっかけは、取り込み中の巻き戻り
旧方式では、rebaseの最中の数十秒から数分間、手元のファイルが相手側の古い版や、衝突の印が入った状態に入れ替わります。10月23日に、その間に別のセッションが古い内容を読んだり、書いた変更が取り消しで巻き戻ったりする事故が起きました。
複数のセッションが同じVaultを読み書きしている以上、取り込みのたびに手元のファイルが一瞬でも入れ替わる作りは使えない。これが作り直した理由です。
新しい同期の流れ
- 手元の変更を記録する（手元のファイルは書き換えない）
- GitHubから取得だけ行う。鉢合わせで失敗したら2秒待って1回だけやり直す
- 相手だけが進んでいるなら
git merge --ff-onlyで進める - 両方が進んでいるなら
git merge-tree --write-treeで、手元の外で試しに合わせる - ぶつからなければ合わせた記録を作って進め、ぶつかるなら何もせずログに残す
- GitHubへ送る。相手が先に送っていたら次の回に回す
Gitの公式ドキュメントによると、merge-tree --write-tree は作業ツリーにも索引にも読み書きせずに、合わせた結果を作ります。ぶつかれば終了コード1を返します。
--ff-only は、早送り（相手の記録の先へそのまま進めること）で済まないときは、合わせずに終わります。
git merge 自体にも、未記録の変更が更新対象のファイルと重なると何もせずに止まる決まりがあります。だから、AIが書いている最中のファイルを上書きすることはありません。
同期ガードも作り直した
同期ガードの自動修復も、自前の pull --rebase をやめ、同じ同期スクリプトを1回走らせて直ったかを見る形にしました。このフックには15秒の制限時間を付けているので、待つのは合わせて14秒までです。
危ないかどうかの判定も変えました。「相手が先に進んでいて自分にも変更がある」を一律に危険とせず、試しに合わせて実際にぶつかるときだけ危険にしています。
作り直した後の同期73回：72回が成功し、残る1回も次の回で解消
同じMacのログで、作り直した版が動き始めた10月23日19時40分から24日12時51分までの同期は73回でした。72回が成功し、失敗は1回だけで、その次の回で解消しています。
| 結果 | 旧方式（10/9〜10/23） | 新方式（10/23〜10/24） |
|---|---|---|
| 同期の回数 | 400回 | 73回 |
| 成功（ok） | 381回 | 72回 |
| 取り込みの失敗 | 19回 | 0回 |
| 送信の失敗 | 0回 | 1回 |
| 両方の変更を自動で合わせた | 記録なし | 19回 |
| 相手の変更を早送りで取り込んだ | 記録なし | 4回 |
| ぶつかって保留にした | 記録なし | 0回 |
両方の変更を自動で合わせた19回は、どれもこちらの未送信が1件、相手の未取込が1〜4件の状態でした。旧方式なら取り込みの途中で手元のファイルが入れ替わっていた場面です。
取得の鉢合わせ（cannot lock ref）は4回出て、4回とも2秒後のやり直しで通りました。送信の失敗1回は、GitHub側で相手のMacとほぼ同時に送ったことによるものと見ています。2分半後の次の回で合わせて送れています。
ただし、新方式の期間はまだ1日足らずです。ぶつかって保留になる場面は、この期間には一度も出ていません。保留が出たときに人がどう直すかは、ガードが出す手順のとおりに進める予定です。
2台以上でObsidianのVaultを同期するときに決めておくこと
1台で動いていた同期は、2台目を足すと別物になります。僕が最初から決めておけばよかったと思うのは、次の5つです。
- 取り込みで手元のファイルを入れ替えない：AIや複数のセッションが書くVaultでは、rebaseの途中の状態を誰かが読む前提で考える
- 失敗の表示を読み分ける：「競合」とまとめず、中身の衝突か、処理の鉢合わせかを分けて数える
- 送れていない日数を見る：自動同期が手元で記録し続けていると、止まっていても気づきにくい
- 無人のタスクに安全装置を外させない：止まったら保留にして知らせる。その代わり、重ならない変更は自動で通す
- 認証情報は2か所で外す：
.gitignoreと理由を書いた除外一覧の両方を、同時に直す
ほかの同期サービスとの併用はしていません。Obsidian公式のヘルプも、同じVaultを複数のサービスで同時に同期しないよう注意しています。
無人で動かすタスク側の作り方はclaude -pのヘッドレス実行と定期実行に書いています。
まとめ
- ObsidianのVaultは、GitHubの非公開リポジトリとClaude Codeのフックで、作業の区切りごとに自動同期できます
.obsidian/workspace.jsonなどは.gitignoreへ。記録済みのファイルには効かないので、外し忘れたらgit rm --cachedと、秘密の値そのものの変更が要ります- 2台運用の旧方式では400回中19回が取り込みに失敗し、中身の衝突は0回でした。多かったのは処理どうしの鉢合わせです
- 2026年10月5日に「重ならなければ通す」自動修復、10月23日に作業ツリーに触れない同期へ作り直し、その後の73回は72回が成功しました
- 僕なら2台目を足す前に、取り込みで手元のファイルを入れ替えない作りから始めます
よくある質問
ObsidianのVaultをGitHubで同期するのに料金はかかりますか？
Gitで同期するなら、Obsidian Syncのような有料の同期サービスは要りません。GitHub側の料金はプランによるので、契約前に公式の料金ページで確かめてください。自動で同期するには、プラグインかスクリプトなど何らかの仕組みを自分で用意する必要があります。
Obsidian GitプラグインはiPhoneやAndroidでも使えますか？
動きますが、作者のREADMEはモバイル対応を「実験的」としていて、使うことを勧めていません。リポジトリが大きいと取り込みで落ちることがあり、SSH認証も使えません。スマホでも読み書きしたいなら、別の方法を考えるほうが安全です。
2台のパソコンで同じVaultをGitHub同期すると何が起きますか？
両方で同じファイルを変えると、片方の取り込みが止まります。僕の会社では中身の衝突より、同期の処理どうしが鉢合わせる失敗のほうが多く出ました。重ならない変更は自動で合わせ、重なるときだけ止める作りにすると安定しました。
.gitignoreに書いたのに、パスワードのファイルがGitHubに上がっています。
すでにGitが記録しているファイルには、.gitignoreは効きません。git rm --cached で記録から外したうえで、パスワード自体を変えてください。GitHubの公式も、まず秘密の値を無効にすることを最初の手順にしています。
