Syncthing の使い方:デバイスのペアリングからファイル同期までの実用メモ

Syncthing 公式ドキュメントをもとに、デバイス ID、フォルダ共有、同期モード、ファイアウォールのポート、無視ルール、ファイルバージョン、安全境界、NAS・Windows・Android 間で同期するときの注意点を整理します。

Syncthing シリーズ目次

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 を開きます。

1
http://127.0.0.1:8384/

Web GUI は日常的な設定入口です。既定で Default Folder が作成されることもあり、多くの場合はユーザーディレクトリ配下の Sync フォルダに対応します。まずテストに使ってもよいですし、後で削除して自分のフォルダを追加してもかまいません。

デバイス ID がペアリングの基本

Syncthing は device ID でデバイスをペアリングします。

各デバイスは初回起動時に自分の鍵を生成します。デバイス ID は、そのデバイス証明書の読みやすいフィンガープリントのようなものです。2 台のデバイスは、互いの device ID を追加して初めて接続し、同期できます。

一般的な手順は次の通りです。

  1. 両方のデバイスで Syncthing を起動する。
  2. それぞれで Web GUI を開く。
  3. A に B の device ID を追加する。
  4. B に A の device ID を追加する。
  5. 共有するフォルダを選ぶ。
  6. 保存して接続を待つ。

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 などでデバイスを見つけられますが、ネットワークを理解しているほど接続は安定します。

公式のファイアウォール文書にある重要なポートは次の通りです。

1
2
3
22000/TCP
22000/UDP
21027/UDP

それぞれの役割は次の通りです。

  • 22000/TCP は TCP 同期トラフィック。
  • 22000/UDP は QUIC 同期トラフィック。
  • 21027/UDP はローカル検出。

同じ LAN 内にいるのにデバイスが見つからない場合は、まずローカルファイアウォール、ルーターの隔離設定、Wi-Fi と有線 LAN が別セグメントになっていないかを確認します。

インターネット越しや NAT 越しでは、ポート転送できるなら直接接続のほうが relay より速いことが多いです。ポート転送できない場合でも relay で接続できることはありますが、速度は落ちます。

Linux で ufw を使い、対応するプロファイルが入っている場合は次のように設定できます。

1
2
sudo ufw allow syncthing
sudo ufw status verbose

Web GUI は既定で 127.0.0.1:8384 のみをリッスンします。0.0.0.0:8384 に変更すると管理画面が外部から到達可能になるため、パスワード、HTTPS、リバースプロキシ、SSH トンネルを考慮する必要があります。家庭用途では SSH トンネルのほうが安全です。

.stignore は同期ルートに置く

同期したくないファイルがある場合は、同期フォルダのルートに .stignore を作成します。

注意点:

  • .stignore は同期フォルダのルートに置く。
  • ルールは同期ルートからの相対パスで解釈される。
  • .stignore 自体は他のデバイスへ同期されない。
  • ファイルは UTF-8 で保存する。

簡単な例:

1
2
3
4
5
(?d).DS_Store
node_modules
*.tmp
cache/**
!/cache/keep.txt

(?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 台のデバイスが同じファイルを同時に別内容へ変更すると、次のような競合ファイルが作られることがあります。

1
filename.sync-conflict-date-time-modifiedBy.ext

黙って上書きされるより安全ですが、競合ファイルは定期的に整理する必要があります。

競合が起きやすい場面:

  • 複数デバイスで同じ 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 でノートや文書を長期同期するなら、次のように考えると扱いやすくなります。

  1. データ種別ごとにフォルダを分け、大きな混在ディレクトリにしない。
  2. 主力 PC は Send & Receive にする。
  3. NAS やバックアップ機は Receive Only とバージョン管理を検討する。
  4. スマートフォンでは必要なディレクトリだけを同期する。
  5. .stignore でキャッシュ、一時ファイル、ワークスペース状態を除外する。
  6. LAN 内では 22000/TCP22000/UDP21027/UDP を使えるようにする。
  7. Web GUI はなるべくローカルに限定し、遠隔管理は SSH トンネルや VPN を優先する。
  8. 重要データは同期だけに頼らず、独立したバックアップを用意する。

向いている場面、向いていない場面

Syncthing が向いている場面:

  • データを主に自分のデバイス上に置きたい。
  • デバイスのペアリング、同期ディレクトリ、競合処理を理解できる。
  • NAS、家庭内サーバー、複数の個人デバイスがある。
  • Markdown、写真の取り込み、スクリプト、軽量文書を同期したい。

あまり向いていない場面:

  • 複数人でオンライン共同編集したい。
  • Web プレビューや共有リンクが必要。
  • 細かなチーム権限管理が必要。
  • ネットワーク、ファイアウォール、競合問題を一切扱いたくない。

Syncthing は完全なクラウドドライブ製品ではなく、信頼できるデバイス間同期レイヤーとして理解するのがよいです。うまく使えば NAS、PC、スマートフォンを自分で制御できるデータネットワークにできます。雑に使うと、競合、誤削除、無視ルール、ネットワーク設定が維持負担になります。

参考資料

记录并分享
Hugo で構築されています。
テーマ StackJimmy によって設計されています。