Syncthing シリーズ目次
- Syncthing の使い方：デバイスのペアリングからファイル同期までの実用メモ
- Docker で Syncthing をデプロイする：Compose、ポート、ボリュームマッピング
- Syncthing を複数デバイスでどう構成するか：メッシュ、スター構成、Introducer
- Android で Syncthing を使う：Syncthing-Fork 設定と写真バックアップ
- Syncthing の多デバイス・多フォルダ管理：トポロジー、命名、バージョン管理
- Syncthing で iPhone 写真を PC や NAS に同期する方法
Syncthing は、複数デバイス間でファイルをピアツーピア同期するのに向いています。従来型のクラウドドライブではなく、すべてのデータをいったん中央サーバーへアップロードしてからダウンロードする仕組みでもありません。許可されたデバイス同士が直接ファイルを交換します。
Markdown ノート、写真バックアップ、設定ファイル、家庭内 NAS のディレクトリを同期したい場合、まず考えるべきなのは「同期できるか」だけではありません。デバイス、フォルダ、デバイス ID、同期方向、検出方法、競合処理を理解しておく必要があります。
Syncthing が解決すること
Syncthing の中心的な用途は、2 台以上のデバイスで特定のディレクトリを同じ状態に保つことです。
典型例は次の通りです。
- Windows デスクトップとノート PC の間で作業資料を同期する。
- スマートフォンと NAS の間で写真や文書を同期する。
- 複数の Linux サーバー間で設定例、スクリプト、小規模な資料ディレクトリを同期する。
- Obsidian、Joplin の外部添付、Markdown ノートディレクトリを複数デバイスで同期する。
Syncthing は、自分でデバイスとデータを管理したい場面に向いています。複数人の権限管理、Web プレビュー、共有リンク、共同編集が必要なら、従来のクラウドドライブや文書コラボレーションサービスのほうが合います。
初回起動で何が起きるか
公式の入門ドキュメントでは、2 台のマシンを並べて設定する流れが紹介されています。Syncthing では、1 台のマシンを 1 つの device と考えます。いま設定しているマシンが local device、同期相手が remote device です。
初回起動時、Syncthing は設定ファイル、暗号鍵、デバイス ID を生成します。既定ではローカルで Web GUI を開きます。
|
|
Web GUI は日常的な設定入口です。既定で Default Folder が作成されることもあり、多くの場合はユーザーディレクトリ配下の Sync フォルダに対応します。まずテストに使ってもよいですし、後で削除して自分のフォルダを追加してもかまいません。
デバイス ID がペアリングの基本
Syncthing は device ID でデバイスをペアリングします。
各デバイスは初回起動時に自分の鍵を生成します。デバイス ID は、そのデバイス証明書の読みやすいフィンガープリントのようなものです。2 台のデバイスは、互いの device ID を追加して初めて接続し、同期できます。
一般的な手順は次の通りです。
- 両方のデバイスで Syncthing を起動する。
- それぞれで Web GUI を開く。
- A に B の device ID を追加する。
- B に A の device ID を追加する。
- 共有するフォルダを選ぶ。
- 保存して接続を待つ。
device ID はパスワードのように秘匿する必要はありませんが、同期トポロジーを不必要に公開するべきではありません。本当に保護すべきなのは、デバイスの秘密鍵、Web GUI の管理権限、同期対象のディレクトリです。
フォルダは自動で全体同期されない
Syncthing が同期するのは、明示的に追加した folder だけです。デバイス全体を既定で同期することはありません。
各フォルダには、パス、ID、共有先デバイス、同期タイプがあります。用途ごとに分けるのが扱いやすいです。
notes/：Markdown ノート。photos-inbox/：スマートフォン写真の取り込み。docs/：複数デバイスで使う文書。scripts/：小さなスクリプトや設定例。
最初から巨大なシステムディレクトリ、ダウンロードディレクトリ、雑多なディレクトリを同期しないほうがよいです。ディレクトリが複雑になるほど、競合、無視ルール、権限差、スキャンコストが長期的な負担になります。
よく使う 3 つのフォルダタイプ
公式ドキュメントではフォルダタイプが明確に整理されています。実用上はまず次の 3 つを理解すれば十分です。
Send & Receive
既定のモードです。このフォルダはローカルの変更を送信し、他のデバイスの変更も受信します。
向いている用途：
- 複数の PC でノートを編集する。
- 複数デバイスで文書を管理する。
- 一般的な双方向同期ディレクトリ。
2 台のデバイスが同じファイルを同時に変更した場合、Syncthing は片方を黙って上書きせず、競合ファイルを作成します。
Send Only
このモードでは、ローカルフォルダが基準コピーのように扱われます。他のデバイスへ変更を送信しますが、他のデバイスから来た変更は適用しません。
向いている用途：
- 主デバイスからバックアップ先へ配布する。
- あるマシンのディレクトリ状態を基準にしたい。
- リモート側の変更でローカルが影響を受けてほしくない。
リモート側で変更が発生すると、ローカル側は out of sync と表示される場合があります。このとき Web GUI に Override Changes が表示され、ローカル状態をクラスタ全体へ押し出せます。慎重に使うべき操作です。
Receive Only
Send Only の逆です。クラスタ内の変更は受信しますが、ローカル変更は他のデバイスへ送信しません。
向いている用途：
- バックアップ先。
- 読み取り専用ミラー。
- ローカルの誤操作で主同期ディレクトリを汚したくないデバイス。
ローカル変更があると、Web GUI に Revert Local Changes が表示され、クラスタの状態へ戻せます。
ファイアウォールとポートを先に確認する
Syncthing は discovery、NAT、relay などでデバイスを見つけられますが、ネットワークを理解しているほど接続は安定します。
公式のファイアウォール文書にある重要なポートは次の通りです。
|
|
それぞれの役割は次の通りです。
22000/TCPは TCP 同期トラフィック。22000/UDPは QUIC 同期トラフィック。21027/UDPはローカル検出。
同じ LAN 内にいるのにデバイスが見つからない場合は、まずローカルファイアウォール、ルーターの隔離設定、Wi-Fi と有線 LAN が別セグメントになっていないかを確認します。
インターネット越しや NAT 越しでは、ポート転送できるなら直接接続のほうが relay より速いことが多いです。ポート転送できない場合でも relay で接続できることはありますが、速度は落ちます。
Linux で ufw を使い、対応するプロファイルが入っている場合は次のように設定できます。
|
|
Web GUI は既定で 127.0.0.1:8384 のみをリッスンします。0.0.0.0:8384 に変更すると管理画面が外部から到達可能になるため、パスワード、HTTPS、リバースプロキシ、SSH トンネルを考慮する必要があります。家庭用途では SSH トンネルのほうが安全です。
.stignore は同期ルートに置く
同期したくないファイルがある場合は、同期フォルダのルートに .stignore を作成します。
注意点：
.stignoreは同期フォルダのルートに置く。- ルールは同期ルートからの相対パスで解釈される。
.stignore自体は他のデバイスへ同期されない。- ファイルは UTF-8 で保存する。
簡単な例：
|
|
(?d) は、無視されたファイルがディレクトリ削除を妨げる場合に Syncthing が削除してよいことを示します。.DS_Store のような自動生成ファイルに向いています。
! は否定ルールで、特定ファイルを再び同期対象に含めます。ただし複雑な否定ルールは、本来無視されるディレクトリを Syncthing に走査させることがあります。まずは単純なルールから始めるのが無難です。
ファイルバージョンはローカル Undo ではない
Syncthing はファイルバージョン管理に対応していますが、意味を誤解しやすい機能です。
公式ドキュメントでは、バージョン管理は「リモート変更を受信してローカルの古いファイルが置き換えられるとき、その古いファイルを保存する」ものだと説明されています。B がファイルを変更して A に同期した場合、A は置き換えられる前のファイルを保存できます。しかし A がローカルでファイルを編集した場合、その編集前の状態を Syncthing が保存するわけではありません。
代表的な方式：
- Trash Can File Versioning：削除・置換されたファイルを
.stversionsに移動する。 - Simple File Versioning：固定数の履歴を保持する。
- Staggered File Versioning：最近は細かく、古いものは粗く保持する。
- External File Versioning：外部スクリプトへ処理を渡す。
重要な文書を同期するなら、少なくともバックアップ先で simple または trash can のバージョン管理を有効にするのがおすすめです。完全なバックアップではありませんが、誤削除や誤上書きの被害を減らせます。
同期競合はどう起きるか
Syncthing は競合を検出します。2 台のデバイスが同じファイルを同時に別内容へ変更すると、次のような競合ファイルが作られることがあります。
|
|
黙って上書きされるより安全ですが、競合ファイルは定期的に整理する必要があります。
競合が起きやすい場面：
- 複数デバイスで同じ Markdown ノートを同時に開く。
- アプリが同じ状態ファイルを自動更新する。
.obsidian/workspace.jsonのようなデバイス固有状態ファイルを同期する。- Windows、macOS、Android 間でファイル名の大文字小文字差が出る。
ノートを同期する場合は、本文、添付、テンプレートをまず同期対象にします。ワークスペース状態、キャッシュ、プラグインの一時ファイルは慎重に扱い、必要なら .stignore に入れます。
セキュリティ境界
Syncthing のセキュリティ目標の一つは、許可されていないデバイスが同期クラスタに参加できず、通信中のファイル内容が第三者に読まれないことです。
公式のセキュリティ文書によると、デバイス間通信は TLS で保護され、接続時にはデバイス証明書のフィンガープリントが許可リストにあるか確認されます。つまり、双方が互いの device ID を設定して初めて同期関係が成立します。
ただし、Syncthing を使っている事実まで完全に隠れるわけではありません。
- グローバル discovery を有効にすると、デバイス ID とリッスンアドレスが discovery server に通知される。
- ローカル discovery は LAN 内にブロードキャストまたはマルチキャストする。
- relay server は device ID を知るが、同期内容は復号できない。
- Web GUI を外部公開すると、そのマシンで Syncthing が動いていることが分かる。
実用的な安全策：
- 認証と暗号化をきちんと設定しない限り、Web GUI をインターネットへ公開しない。
- 信頼できるデバイスだけを追加する。
- 重要なディレクトリはディスク暗号化や別バックアップと組み合わせる。
- 必要なければ global discovery、relay、自動アップグレードを無効化できるが、接続の便利さは下がる。
信頼しない暗号化デバイス
Syncthing には Untrusted / Encrypted Devices もあります。信頼できないデバイスに暗号化済みデータだけを保存させる機能です。
典型例は、クラウドサーバーや外部マシンを同期・バックアップに参加させたいが、平文ファイルは見せたくない場合です。信頼済みデバイスはフォルダパスワードで暗号化して送信し、同じパスワードを持つ別の信頼済みデバイスがそこから同期して復号できます。
ただし公式ドキュメントでも、この機能は beta / testing として扱われています。明確な目的がある場合に慎重に使う機能で、最初の主同期方式にはしないほうがよいです。
覚えておきたい点：
- ファイルデータ、ファイル名、時刻、ハッシュ、ディレクトリ構造は保護される。
- フォルダ ID、ラベル、おおよそのファイルサイズは完全には隠れない。
- パスワードと folder ID は確実に保存する。
- 信頼しないデバイス側のフォルダタイプは
Receive Encryptedにする。
家庭内 NAS、自分の PC、スマートフォン間の同期なら、通常は信頼済みデバイスとして使い、OS ログイン、ディスク暗号化、バックアップを整えるほうが維持しやすいです。
実用的な設定方針
Syncthing でノートや文書を長期同期するなら、次のように考えると扱いやすくなります。
- データ種別ごとにフォルダを分け、大きな混在ディレクトリにしない。
- 主力 PC は
Send & Receiveにする。 - NAS やバックアップ機は
Receive Onlyとバージョン管理を検討する。 - スマートフォンでは必要なディレクトリだけを同期する。
.stignoreでキャッシュ、一時ファイル、ワークスペース状態を除外する。- LAN 内では
22000/TCP、22000/UDP、21027/UDPを使えるようにする。 - Web GUI はなるべくローカルに限定し、遠隔管理は SSH トンネルや VPN を優先する。
- 重要データは同期だけに頼らず、独立したバックアップを用意する。
Synology DSM に Syncthing を導入する
事前準備
まず SSH で Synology にログインし、Syncthing を実行するユーザー ID を確認します。
|
|
出力に含まれる uid と gid を控えておきます。一般的には uid が 1026 前後、gid が 100 になることが多いです。後でそれぞれ PUID と PGID に設定します。
次に File Station で docker 共有フォルダを開き、次のディレクトリを作成します。
|
|
このディレクトリには Syncthing の設定ファイル、データベース、実行状態が保存されます。後でコンテナを作り直す場合でも、このディレクトリが残っていれば設定を引き継げます。
Syncthing イメージをダウンロードする
Synology の Container Manager を開き、左側の「レジストリ」に入り、次を検索します。
|
|
公式イメージ syncthing/syncthing を選び、タグは latest を使用します。ダウンロードが完了したら「イメージ」に移動し、syncthing/syncthing を選択して「実行」をクリックします。
コンテナを作成する
コンテナ名はそのまま次のように設定できます。
|
|
NAS の再起動後に Syncthing が自動で復帰するよう、「自動再起動を有効にする」も有効にしておくとよいです。
環境変数を設定する
詳細設定の環境変数エリアで、次を追加または変更します。
|
|
PUID と PGID は、前の手順で id username により確認した実際の値に置き換えてください。Syncthing が共有フォルダを読み書きするとき、このユーザーとして Synology のファイルシステムにアクセスします。
ポートを固定する
アクセスやトラブルシューティングをしやすくするため、ポートマッピングは手動で固定しておくのがおすすめです。
| コンテナポート | ローカルポート | プロトコル | 用途 |
|---|---|---|---|
8384 |
8384 |
TCP | Web 管理画面 |
22000 |
22000 |
TCP | 同期データ転送 |
22000 |
22000 |
UDP | QUIC データ転送 |
21027 |
21027 |
UDP | LAN 内探索 |
Synology のファイアウォールを有効にしている場合は、これらのポートも許可してください。LAN 内だけで使う場合でも、少なくとも 8384 に自分の PC からアクセスできる必要があります。
ボリュームマッピングを設定する
ボリュームマッピングは 2 種類あります。Syncthing 自身の設定ディレクトリと、同期したい Synology の共有フォルダです。
設定ディレクトリは次のようにマッピングします。
| Synology ホストパス | コンテナ内マウントパス |
|---|---|
/docker/syncthing |
/var/syncthing |
続いて、同期したいデータディレクトリを追加します。たとえば Synology 上の /volume1/NasData を同期したい場合は、次のようにマッピングします。
| Synology ホストパス | コンテナ内マウントパス |
|---|---|
/volume1/NasData |
/NasData |
ここは特に重要です。後で Syncthing の Web UI でフォルダを追加するときに入力するのは、次のようなコンテナ内パスです。
|
|
Synology のホストパス /volume1/NasData は入力しません。Syncthing はコンテナ内で動作しているため、コンテナにマウントされたパスだけを認識できます。
複数の共有フォルダを同期したい場合は、追加でマッピングします。
|
|
起動してアクセスする
環境変数、ポート、ボリュームマッピングを確認したら、「完了」をクリックしてコンテナを起動します。
その後、ブラウザで次のアドレスを開きます。
|
|
Syncthing の管理画面に入ったら、最初に Web 管理画面のユーザー名とパスワードを設定します。場所は次のとおりです。
|
|
パスワード未設定の Syncthing 管理画面を LAN 内に長時間公開したままにしないでください。
同期フォルダを追加する
「Add Folder」をクリックし、「Folder Path」に前の手順で設定したコンテナ内パスを入力します。
|
|
権限設定が正しければ、Syncthing はこの共有フォルダを読み書きできます。その後、リモートデバイスを追加し、共有するフォルダを選択すれば同期を開始できます。
iPhone の写真をパソコンや NAS に同期する
まず iOS の制限を理解する
Android では、Syncthing-Fork がバックグラウンドサービス、実行条件、バッテリー最適化の除外などを使って長時間動作できます。しかし iOS は、サードパーティの同期ツールが無制限にバックグラウンド常駐することを許可しません。
つまり、次の点に注意が必要です。
- NAS のように 24 時間同期し続けることは期待できません。
- App がバックグラウンドに入ると、同期できる時間は短い場合があります。
- 大量の写真は、手動で App を開いて同期を完了させるのが確実です。
- iCloud のストレージ最適化により、元画像の読み取りに影響が出ることがあります。
そのため iPhone 側では、完全に無意識のリアルタイムバックグラウンド同期ではなく、「定期的に App を開いて写真を同期する」運用が向いています。
手順 1：クライアントをインストールして権限を付与する
App Store から Mobius Sync をインストールしたら、初回起動時にいくつかの権限を確認します。
通知権限
通知は許可しておくことをおすすめします。同期状態、接続状態、エラー情報を確認しやすくなります。
ローカルネットワーク権限
この権限は非常に重要です。
iOS は、App がローカルネットワークへアクセスしてよいかを個別に確認します。許可しない場合、iPhone が LAN 内の PC、NAS、Syncthing ノードを検出できないことがあります。
誤って拒否した場合は、iOS の設定から再度有効にできます。
写真ライブラリへのアクセス権限
写真を同期するには、写真ライブラリへのアクセスを許可する必要があります。
推奨される選択は次のとおりです。
|
|
限定的な写真アクセスだけを許可すると、Mobius Sync は選択済みの写真しか見られず、後から追加した写真が同期されない可能性があります。
手順 2：iPhone と PC/NAS をペアリングする
Syncthing のペアリングは、デバイス ID を相互に登録する仕組みです。
iPhone 側では：
Mobius Syncを開きます。Settingsに入ります。Device IDを開きます。- QR コード画面を表示したままにします。
PC または NAS 側では：
- Syncthing Web UI を開きます。
Add Remote Deviceをクリックします。- iPhone 上の QR コードをスキャンするか、デバイス ID を手動入力します。
My-iPhoneのような名前を付けます。- 保存します。
iPhone に戻り、接続要求の通知を待って Accept をタップします。
ここまでで iPhone と PC/NAS は相互に信頼された状態になりますが、写真ライブラリはまだ共有されていません。
手順 3：iPhone で写真同期用フォルダを作成する
iOS では、Android のように /DCIM/Camera を直接選択する形にはなりません。Mobius Sync はシステム写真ライブラリ向けの専用サポートを持っているため、設定時に写真ライブラリ用のフォルダタイプを選びます。
Mobius Sync で：
Foldersに切り替えます。- 右上の
+をタップします。 - 新しいフォルダを作成します。
重要な項目：
Folder Type：Camera Rollを選びます。Folder Label：iPhone_Photosなど、識別しやすい名前を入力します。Folder ID：自動生成のままでもよいですし、安定した英数字 ID を使っても構いません。Folder Path：デフォルトのままにして、クライアントが iOS の写真ライブラリに関連付けられるようにします。
次に Sharing セクションで、先ほどペアリングした PC または NAS を選択します。
手順 4：iPhone 側を Send Only にする
写真同期は通常、「スマートフォンから NAS へ送る」用途であり、双方向編集ではありません。
そのため iPhone 側のフォルダタイプは次のように設定します。
|
|
これにより iPhone は写真を送信するだけになり、PC や NAS からの逆方向の変更を受け取りません。
この設定は誤操作のリスクを下げます。たとえば PC 側でバックアップフォルダを整理しているとき、その変更が iPhone の写真ライブラリに影響することを避けられます。
ただし、Syncthing は同期ツールであり、完全なバックアップシステムではありません。長期的に写真を安全に保つには、NAS 側のスナップショット、ファイルバージョン管理、独立したバックアップも必要です。
手順 5：PC または NAS 側で写真を受け取る
iPhone 側で保存すると、PC または NAS の Syncthing Web UI に次のような通知が表示されます。
|
|
追加をクリックします。
保存先パスを設定します。
Windows なら、たとえば次のようにします。
|
|
Linux または NAS なら、たとえば次のようにします。
|
|
Syncthing が Docker 内で動作している場合は、コンテナ内のパスを入力します。たとえばホスト側のマウントが次の場合：
|
|
Web UI では次のように入力します。
|
|
受信側は Receive Only がおすすめ
PC または NAS 側でも、このフォルダタイプは次に設定するのがおすすめです。
|
|
これにより受信側は iPhone から送られてくる写真だけを受け取り、ローカル変更を iPhone に同期しません。
これは 2 段目の保険です。
- iPhone 側：
Send Only - NAS 側：
Receive Only
両側を一方向バックアップの考え方で設定することで、写真アーカイブの用途に合いやすくなります。
iOS のバックグラウンド同期の現実的な制限
iOS はバックグラウンド実行に非常に厳しい制限があります。設定が正しくても、Mobius Sync が常にバックグラウンドで黙って動き続けるとは考えないほうがよいです。
よくある動作は次のとおりです。
- App を開いている間は通常どおり同期されます。
- バックグラウンドに切り替えた後、短時間は同期が続く場合があります。
- しばらくすると、システムが一時停止または制限します。
- 位置情報の変化、システムのスケジューリング、短いバックグラウンド実行枠で再度起動することがあります。
最も確実な運用はシンプルです。
- 大量の写真を撮った後、
Mobius Syncを手動で開きます。 - 画面を点灯したままにするか、すぐにロックしないようにします。
- 新しい写真の同期が終わるまで待ちます。
- その後 App を閉じるか、画面をロックします。
数日に一度写真バックアップを行う運用なら、この方法は比較的安定しています。
iCloud のストレージ最適化による影響を避ける
iPhone で次の設定が有効になっている場合：
|
|
システムはローカルにサムネイルだけを残し、元画像を iCloud に置くことがあります。サードパーティの同期クライアントが写真を読み取るとき、完全な元画像を取得できず、同期失敗、スキップ、またはシステムのダウンロード待ちが発生する可能性があります。
同期バックアップに向いている設定は次です。
|
|
通常の場所は次のとおりです。
|
|
端末容量が足りず、どうしても最適化ストレージを使う必要がある場合は、同期前にシステムの写真 App で対象の写真を開き、iPhone に iCloud から元画像をダウンロードさせてから Mobius Sync を起動するとよいです。
大量写真の初回同期のすすめ
iPhone の写真ライブラリを初めて同期するときは、数千枚から数万枚の写真があるかもしれません。急いで一度に終わらせようとしないほうが安全です。
次のように進めるとよいです。
- まず少量の写真でテスト同期します。
- NAS のパスが正しいことを確認します。
- フォルダタイプが Send Only / Receive Only であることを確認します。
- 受信側が iPhone に逆方向の影響を与えないことを確認します。
- その後、完全な同期を開始します。
初回同期時は、次をおすすめします。
- iPhone を電源に接続します。
- Wi-Fi を安定させます。
Mobius Syncを前面で実行します。- NAS または PC をオンラインにしておきます。
写真の数が多い場合、同期に時間がかかることがあります。これは正常です。
推奨構成
安定した iPhone 写真同期の構成は次のようになります。
- iPhone に
Mobius Syncをインストールします。 - 通知、ローカルネットワーク、写真ライブラリへのフルアクセスを許可します。
- iPhone と NAS でデバイス ID を相互登録します。
- iPhone 側で
Camera Rollフォルダを作成します。 - フォルダラベルを
iPhone_Photosにします。 - iPhone 側のフォルダタイプを
Send Onlyにします。 - NAS 側の受信パスを
/volume1/photos/iphoneにします。 - NAS 側のフォルダタイプを
Receive Onlyにします。 - NAS 側でファイルバージョン管理またはスナップショットを有効にします。
- 数日に一度
Mobius Syncを手動で開いて同期を完了させます。
完全自動のバックグラウンド写真バックアップに強く依存する場合、iOS は Android より少し面倒です。iOS の制限により、サードパーティ同期ツールが完全に無意識の常時バックグラウンド動作を実現するのは難しいためです。
複数フォルダーの管理とバージョン管理
Folder ID はフォルダーラベルより重要
Syncthing で同期フォルダーを本当に識別するのは Folder ID であり、画面に表示されるラベルではありません。
ラベルは表示名にすぎず、デバイスごとに違っていても構いません。Folder ID こそが、複数デバイス上のフォルダーが同じ同期グループに属するかを判断する鍵です。
そのため、最初のデバイスでフォルダーを作るときは、分かりやすい ID を手動で指定することをおすすめします。
例：
|
|
自動生成されたランダムな ID や、test、sync、new-folder のように長期運用に向かない名前は避けましょう。
命名ルールはシンプルで十分です。
- 双方向同期：
notes-main、work-docs - スマートフォンのバックアップ：
backup-pixel-photos、backup-iphone-photos - 資料配布：
media-ebooks、media-music - コードディレクトリ：
code-projects
後で別のデバイスが共有を受け取るとき、Folder ID を見れば用途をすぐ判断できます。
中心ノードのパスを整理する
NAS や中心となるパソコンでは、Syncthing 用の共通ルートディレクトリを作るのがおすすめです。
例：
|
|
同期ディレクトリをシステム内のあちこちに散らさないでください。短期的には便利でも、長期的には必ず管理が難しくなります。
おすすめの原則：
- Syncthing が管理するすべてのディレクトリを共通ルートの下に置く。
- スマートフォンのバックアップ、仕事用ドキュメント、メディアを分ける。
- フォルダー名は一時的なデバイス状態ではなく用途を表す。
- システムディレクトリやダウンロードキャッシュを長期同期フォルダーにしない。
Syncthing を Docker で動かしている場合は、ホスト側パスとコンテナ内パスの対応にも注意します。
ホスト側のディレクトリ：
|
|
コンテナ内では次のようにマウントされることがあります。
|
|
Web UI に入力するのはコンテナ内パスであり、ホスト側パスではありません。
バックアップと双方向同期を分ける
複数フォルダー管理で最も重要なのは、すべてのディレクトリに Send & Receive を使わないことです。
フォルダーごとにデータの向きは異なります。
スマートフォン写真バックアップ
スマートフォン側：
|
|
NAS 側：
|
|
スマートフォンは写真を送信し、NAS は受信して保存します。スマートフォンの容量整理や NAS 側の整理が、互いに影響しにくくなります。
複数端末のドキュメントとメモ
パソコン側：
|
|
NAS 側：
|
|
スマートフォンを双方向同期に参加させるかは、実際にスマートフォンでそれらのファイルを編集するかによります。閲覧だけなら Receive Only も検討できます。
資料配布
NAS 側：
|
|
他のデバイス：
|
|
電子書籍、インストーラー、参考資料など、中心から配布するフォルダーに適しています。
バックアップディレクトリ
メインデバイス：
|
|
バックアップ機：
|
|
さらにバックアップ側でバージョン管理やスナップショットを組み合わせます。
NAS でファイルバージョン管理を有効にする
複数デバイス同期で最も怖いのは、誤削除と誤上書きです。
例：
- あるパソコンで仕事用ドキュメントを誤って削除した。
- スマートフォンのクリーンアップツールがアルバムディレクトリを削除した。
- 2 台のデバイスが同じメモを同時に編集した。
- 同期ルールを間違えて空ディレクトリを同期してしまった。
そのため、中心ノードではファイルバージョン管理を有効にしておくのが安全です。
NAS の Syncthing Web UI で：
- 対象フォルダーの設定を開く。
- ファイルバージョン管理へ進む。
- 適切なバージョン戦略を選ぶ。
よく使われるのは Staggered File Versioning です。時間間隔に応じて履歴バージョンを保持し、古いものほど間引いて残します。
より単純な戦略も使えます。
- Trash Can File Versioning：ごみ箱のように扱う。
- Simple File Versioning：固定数のバージョンを保持する。
- Staggered File Versioning：時間段階に応じて保持する。
迷う場合、家庭用 NAS なら Trash Can または Staggered から始めるとよいでしょう。
バージョン管理は完全なバックアップではありませんが、複数デバイス同期における重要な復旧手段です。
複数フォルダーの命名例
固定した命名方式を用意できます。
スマートフォン写真：
|
|
iPhone 写真：
|
|
メインのノート保管庫：
|
|
仕事用ドキュメント：
|
|
電子書籍：
|
|
ID、ラベル、パスに規則があれば、デバイスが増えても管理しやすくなります。
推奨する全体構成
すでに Docker 版 Syncthing を NAS で動かしているなら、次のように設計できます。
- NAS を中心ノードにする。
- NAS を Introducer に設定する。
- すべてのデバイスは NAS とだけペアリングする。
- すべての同期ディレクトリを
/volume1/Syncthing/の下に置く。 - スマートフォン写真はスマートフォン
Send Only、NASReceive Onlyにする。 - 仕事用ドキュメントとメモは
Send & Receiveにする。 - 資料配布フォルダーは NAS
Send Only、他デバイスReceive Onlyにする。 - NAS 上の重要フォルダーでバージョン管理を有効にする。
- コードとキャッシュディレクトリには Ignore Patterns を設定する。
- NAS 自体にもスナップショットまたは別場所へのバックアップを用意する。
この構成を作っておけば、新しいデバイスやフォルダーを追加するときも、既存のルールに沿って入れるだけで済みます。同期関係を毎回考え直す必要はありません。
複数デバイスのトポロジーとペアリング
まず「対等」と「疑似サーバー」を理解する
Syncthing の各デバイスには固有の device ID があります。二つのデバイスがお互いの ID を追加し、同じフォルダーを共有すれば同期できます。
つまり Syncthing には「サーバー側がすべてのデータを保持しなければならない」という前提はありません。あなたが「サーバー」と呼んでいるものは、多くの場合、運用上中心に置いた常時稼働デバイスです。
たとえば：
- NAS は常時稼働し、容量も大きいので中心ノードに向いています。
- スマートフォンやノート PC はオフラインになりやすく、エッジデバイスとして扱うのが自然です。
- デスクトップ PC は高性能でも、24 時間稼働とは限らないため、通常の同期ノードとして考えます。
この「中心ノード」はプロトコル上のサーバーではありません。トポロジー設計の中で、管理と中継を担わせるデバイスです。
モード 1：純粋な Peer Mesh ネットワーク
純粋なピアモードでは、すべてのデバイスがほかのすべてのデバイスとペアリングします。
たとえば四つのデバイスがあるとします。
- NAS
- デスクトップ
- ノート PC
- スマートフォン
この場合、各デバイスは残り三つのデバイスと接続します。これにより、オンラインの任意の二台が直接同期できます。
利点：
- 転送経路がより直接的です。
- 一台がオフラインでも、ほかのオンラインデバイス同士は同期できます。
- 特定の中心ノードに依存しません。
欠点：
- デバイスが増えるほど、ペアリング関係が複雑になります。
- 新しいデバイスを追加するとき、複数の既存デバイスで確認と設定が必要になります。
- フォルダー共有の関係が分散しやすくなります。
デバイス数が少ない場合、純粋なピアモードは快適です。たとえば PC 一台とスマートフォン一台、または二台の PC でメモを同期するだけなら、複雑に考える必要はありません。
しかしデバイスが五、六台以上になると、完全接続の関係を手作業で維持するのはだんだん面倒になります。
モード 2：NAS を中心にしたスター型トポロジー
スター型は家庭や個人の生産性用途に向いています。
長時間稼働し、容量が十分で、ネットワークが安定しているデバイスを中心ノードにします。たとえば：
- NAS
- Synology
- ソフトルーター
- ミニ PC
- 自宅 Linux サーバー
そしてほかのデバイスは、その中心ノードとだけペアリングします。
|
|
スマートフォンはノート PC と直接ペアリングする必要がなく、ノート PC もデスクトップと直接ペアリングする必要はありません。すべて NAS を経由して間接的に同期します。
利点：
- 管理が簡単です。
- 新しいデバイスは NAS とだけペアリングすれば済みます。
- NAS がバージョン保持やバックアップの受け皿になります。
- 24 時間同期に向いています。
欠点：
- NAS がオフラインになると、ほかのデバイス同士は同期を続けられない場合があります。
- すべての通信が NAS を通る場合、NAS のネットワーク性能とディスク性能が体験に影響します。
- 中心ノードの権限管理を慎重に行う必要があります。
すでに NAS や常時稼働の小型サーバーがあるなら、まずスター型トポロジーをおすすめします。Syncthing の P2P の強みを残しつつ、日常管理はかなり中央集約型の同期に近づきます。
複数デバイス設定の基本順序
どのトポロジーを使う場合でも、Syncthing の設定順序は同じです。
- 先にデバイスをペアリングする。
- 次にフォルダーを共有する。
- 最後に受信側でローカルパスを確認する。
最初からあちこちにフォルダーを作らないでください。先にデバイス関係を整理しておくと、後の設定が乱れにくくなります。
ステップ 1：デバイスを接続する
デバイス A とデバイス B を接続するとします。
デバイス A はスマートフォン、デバイス B は NAS や PC だと考えてください。
デバイス A で：
- Syncthing Web UI を開きます。
- 右上の
操作をクリックします。 ID を表示を選びます。- device ID をコピーするか、QR コードを表示します。
デバイス B で：
- Syncthing Web UI を開きます。
リモートデバイスを追加をクリックします。- デバイス A の ID を入力します。
My-Phoneのような識別しやすい名前を付けます。- 保存します。
その後デバイス A に戻ります。通常は、デバイス B が接続しようとしているという通知が表示されるので、承認します。
ここまでで二台のデバイスは対等な関係を確立しました。ただし、まだどのフォルダーも同期していません。
ステップ 2：フォルダーを作成して共有する
デバイス A で フォルダーを追加 をクリックします。
よく使う項目：
- フォルダーラベル：自分が見るための名前。例：
Notes。 - フォルダー ID：デバイス間で識別するための ID。
notesのような安定した英語名がおすすめです。 - フォルダーパス：このデバイス上の実際のパス。
次に 共有 タブへ切り替え、先ほどペアリングしたデバイス B にチェックを入れます。
保存すると、デバイス A からデバイス B にフォルダー共有の招待が送られます。
ステップ 3：共有を受け入れる
デバイス B の Web UI を開いて数秒待つと、通常は次のような通知が表示されます。
|
|
追加をクリックし、デバイス B 上のローカル保存先を指定します。
例：
|
|
Docker デプロイの場合は、コンテナー内パスになります。
|
|
保存すると同期が始まります。
ここで重要なのは、各デバイスのパスは同じでなくてもよいということです。Syncthing はフォルダー ID で同期関係を識別し、すべてのデバイスに同じローカルパスを要求しません。
スター型トポロジーの設定方法
NAS 中心の構成を使うなら、次のようにします。
- まず NAS に Syncthing をデプロイする。
- すべてのスマートフォン、PC、サーバーを NAS とだけペアリングする。
- NAS 上で主要な同期フォルダーを作成または受け入れる。
- 新しいデバイスは NAS の device ID だけを追加する。
- 同期したいフォルダーを、NAS と対象デバイスの間で共有する。
例：
|
|
この構造はとても分かりやすいです。NAS を同期関係のコントロールパネルとして扱えます。
Introducer とは何か
Syncthing には Introducer という便利な機能があります。日本語では「紹介者」や「Introducer」と表示されることがあります。
これは複数デバイス環境に向いています。
NAS を Introducer に設定したとします。その後、新しいデバイスが NAS とペアリングすると、NAS は自分が知っているほかのデバイスを新しいデバイスに紹介できます。既存の共有関係の反映にも役立ちます。
これにより、同じクリックや同じペアリング作業を繰り返す必要が減ります。
向いているケース：
- 家に複数の PC とスマートフォンがある。
- NAS が長時間稼働する中心ノードになっている。
- 新しいデバイスをよく追加する。
- デバイス関係の手動メンテナンスを減らしたい。
ただし Introducer は、自動的に確立される関係の範囲を広げます。完全に信頼できないデバイスを Introducer にしないでください。トポロジーを理解しないまま気軽に有効化するのも避けましょう。
より安全な考え方は次の通りです。
- NAS またはメインサーバーだけを Introducer にする。
- 普通のスマートフォンやノート PC は Introducer にしない。
- 新しいデバイスを追加した後、自動追加されたデバイスとフォルダーを確認する。
フォルダーごとに違うトポロジーを使える
Syncthing のトポロジーは、サイト全体で一つに統一する必要はありません。フォルダー単位で設計できます。
例：
notes：デスクトップ、ノート PC、スマートフォン、NAS がすべて Send & Receive。photos：スマートフォンが送信し、NAS が受信してバージョンを保持する。downloads：デスクトップと NAS が同期し、スマートフォンは参加しない。backup：メイン PC は Send Only、NAS は Receive Only。
すべてのディレクトリを一つのルールに押し込まないでください。複数デバイス同期で本当に重要なのは、デバイス数ではなくデータの流れです。
衝突と誤削除を先に考える
複数デバイス同期でよく起きる問題は、設定失敗ではありません。同期が成功した後の誤削除や競合です。
問題が起きやすい場面：
- 二台のデバイスが同じファイルを同時に編集する。
- スマートフォンアプリがディレクトリを自動クリーンアップする。
- 一台のデバイスでパスを間違え、空のディレクトリを作って同期してしまう。
- キャッシュ、一時ファイル、作業状態ファイルをまとめて同期してしまう。
- NAS 側でバージョン保持を有効にしていない。
おすすめ：
- 重要なディレクトリでは NAS 側でファイルバージョン管理を有効にする。
.stignoreでキャッシュや一時ファイルを除外する。- 新しいフォルダーの初回同期前に、少量のテストファイルで検証する。
- 削除ポリシーが明確でない場合、すべてのデバイスを Send & Receive にしない。
おすすめ構成
NAS または常時稼働サーバーがあるなら、スター型トポロジーをそのまま使うのがおすすめです。
- NAS を中心ノードにする。
- NAS とすべてのデバイスをペアリングする。
- 通常のデバイスは NAS とだけペアリングする。
- NAS を Introducer にできる。
- フォルダーごとに Send & Receive、Send Only、Receive Only を選ぶ。
- 重要なフォルダーでは NAS 側でファイルバージョン管理を有効にする。
- 新しいデバイスを追加した後、まずテストフォルダーを共有してパスと権限を確認する。
二、三台だけで、どれも頻繁にオンラインになるなら、純粋なピアモードでも問題ありません。より直接的で、速度も良くなることがあります。
向いている場面、向いていない場面
Syncthing が向いている場面：
- データを主に自分のデバイス上に置きたい。
- デバイスのペアリング、同期ディレクトリ、競合処理を理解できる。
- NAS、家庭内サーバー、複数の個人デバイスがある。
- Markdown、写真の取り込み、スクリプト、軽量文書を同期したい。
あまり向いていない場面：
- 複数人でオンライン共同編集したい。
- Web プレビューや共有リンクが必要。
- 細かなチーム権限管理が必要。
- ネットワーク、ファイアウォール、競合問題を一切扱いたくない。
Syncthing は完全なクラウドドライブ製品ではなく、信頼できるデバイス間同期レイヤーとして理解するのがよいです。うまく使えば NAS、PC、スマートフォンを自分で制御できるデータネットワークにできます。雑に使うと、競合、誤削除、無視ルール、ネットワーク設定が維持負担になります。