Syncthing 4台運用レビュー｜Claude Code × WSLのコピペをゼロにした設計と.git除外の罠

この記事はClaude Code を WSL で動かしていて、複数PCでファイルを行き来させたい人向け（WSL とターミナル操作の基本が分かる前提）。

Claude Code を WSL で使っている人なら一度はやってるはず。

「WSL側にあるプロジェクトをWindows側で開きたい」と思って、Claude Code に cp -r ./project /mnt/c/Users/... を頼むやつです。

あれ、塵のように積もる。

私はこの作業を Syncthing で丸ごと消しました。

WSL内のプロジェクトフォルダがそのままWindowsからも、Macからも、持ち歩いているMacBookからも見える状態にしています。

同期は自動。

指示はゼロ。

この記事は「4台運用している私」の視点で書きます。

クラウド代を浮かせた話ではなく、AIエージェント時代のコピペ作業を消した話です。

ここが他の日本語Syncthing記事との一番の違い。

Syncthingとは？ クラウドを使わずPC同士を直接つなぐ無料の同期OSS

Syncthing は、手元のPC同士でフォルダを直接同期するオープンソースのツール。

Dropbox や Google Drive のような「クラウドに預ける型」の同期と違って、どこかの会社のサーバーを一切経由しないのが最大の違いです。

料金は完全無料（MPLv2ライセンス）。

GitHubスターは82,000以上。

2026年4月時点は v2.0.16（2026年4月7日リリース時点）が動いています。

一般的なクラウド同期は、手元のファイルを一度そのサービスのサーバーに送って、そこから別のPCに届ける仕組みです。

Syncthing はそれをしません。

PCとPCが直接つながる。

だから月額料金はゼロ、ファイルの中身が外部のクラウドに残りません。

動作イメージ（これだけ）

• 2台以上のPCに Syncthing を入れる
• 「このフォルダを同期したい」と両方のPCで指定する
• 相手のPCの「デバイスID」を一度だけ教え合う
• あとは勝手にファイルが両方で同じ状態に揃う

設定は最初の5分だけ。

そのあとは放置。

Google Drive のアイコンがタスクバーで回るのと同じ感覚で、背後で静かに動き続けます。

Dropbox との決定的な違いは、ファイルの中身は他人のサーバーを一切通らないこと。

公式ドキュメントに明記されています。

discovery server の役割は device ID と listening port(s) を30分ごとに送信してIPアドレスをマッピングするだけ。

ファイルの中身は discovery server を通らない。

— Syncthing公式 docs.syncthing.net/users/security.html

つまり「PC同士のIPを教える電話帳」だけが外部を経由して、ファイル本体はPCとPCで直接やり取りされる。

ここが Dropbox や Google Drive とは構造的に違うポイントです。

なぜ今Claude Code使いに刺さるのか

Claude Code の公式ドキュメントは「プロジェクトはWSLホームディレクトリ（~/）に置くべき。

/mnt/c/... は避けよ」と明記しています（Claude Code公式）。

理由は速度で、/mnt/c/経由のファイルアクセスはネイティブWSLの30〜50倍遅いことが実測されています。

ここで問題が起きる。

プロジェクトがWSL内にあると、Windows側からそのまま触れない。

エクスプローラーで開くには \\wsl$\Ubuntu\... を叩くか、WSL内で explorer.exe . を実行する必要があります。

毎回手動。

そして、出来上がったものを別のPCに渡すのが地獄。

私はこれを Claude Code に「WSL側からWindows側にコピー作って」と頼んでいました。

頼むたびにトークンが溶ける。

1回あたりは小さくても、1日5〜10回やれば積み上がる。

月で見ると数十ドル単位で消える計算で、人間にとって一番どうでもいい「コピーを作る作業」にトークンを払っているという事実が、だんだん気持ち悪くなってきた。

ここを消したかった。

Syncthing を WSL 内に立てて、WSL のプロジェクトフォルダをそのまま同期対象にする。

すると Windows 側にも、Mac 側にも、MacBook 側にも、同じフォルダが自動で揃う。

Claude Code への「コピーしといて」指示はゼロになりました。

WSL↔Windows 間でファイルを動かす方法を並べると

Claude Code + WSL 勢が通る道を表にしておきます。

方法	特徴	問題点
\\wsl$\Ubuntu\ パス	エクスプローラーから閲覧できる	毎回手動。他PCには渡せない
explorer.exe .	WSL内から1コマンドで開ける	毎回手動。コマンド入力必須
/mnt/c/... にコピー	スクリプト化しやすい	ネイティブ比30〜50倍遅い
VSCode Remote WSL	開発そのものは快適	他PCへの同期目的には不向き
Syncthing（WSL内に常駐）	自動・常時・他3台にも同期	.stignoreの設計が必要

上4つは「WSL↔Windows の往復」しか面倒を見てくれない。

4台持ちだと根本解決にならないんですね。

私の4台運用構成

いま動かしている構成はこうです。

端末	役割	Claude Code	Syncthing
Windows（デスクトップ）	メイン機。記事執筆・画像処理	WSL経由で使用	WSL内に常駐
WSL（Windows上のUbuntu）	Claude Code の母艦	ここで動く	本体インスタンス
Mac（iMac）	サブ作業機	ネイティブで使用	ネイティブで常駐
MacBook	外出・移動用	ネイティブで使用	ネイティブで常駐

同期対象は「Claude Code で育てているプロジェクトフォルダ群」一式。

記事下書きもコードも設定ファイルも全部ここに入れています。

4台がすべてP2Pでつながっている状態。

WSL と Windows の間は、Windows側に別のSyncthingを立てないのがコツです。

WSL内のSyncthingが、Windowsの共有フォルダ（/mnt/c/...配下）ではなくWSLネイティブのホームディレクトリ（~/）を見る設計にしてあります。

速度とClaude Code公式推奨の両方に効く。

これが一番効いた設計判断。

Windows からそのプロジェクトを触りたければ、Syncthing が Mac と MacBook にも配った同じフォルダを、Windows 側の別のSyncthingフォルダとして同期する形にしています。

WSL とWindows でSyncthing 本体を分けて、ポートも別（私は8385 を使用）にする構成は、Syncthing 公式フォーラムでも複数のスレッドが推奨パターンとして紹介しています（forum.syncthing.net）。

ちなみにWindows版SyncthingでWSL2フォルダ（\\wsl$\Ubuntu\...）を直接指定するのはやめた方がいいです。

公式フォーラムで "Incorrect function" エラーの報告があり、変更監視（inotify相当）も動きません（Syncthing Forum）。

私も最初これで詰まりかけました。

導入前後で何が変わったか

体感で変わった順に並べるとこう。

• Claude Code への「コピーして」指示がゼロに。保存した瞬間にWindows側・Mac側・MacBook側すべてに反映される。
• 「どのPCで作業してたっけ」を考えなくてよくなった。作業は最新版が置いてあるPCで始めればいい。
• 移動中のMacBook作業が現実的になった。帰宅してデスクトップを開いた時点で最新版。同期漏れでパニックになる時間が消えた。
• Google Drive を「アップロード→ダウンロード」する儀式が消えた。私は無料の15GBプランで済ませていたけれど、容量上限で弾かれる瞬間もなくなった。

金額の話をすると、私は乗り換え前から月額サブスクには入っていませんでした。

なのでクラウド代の節約はゼロ円。

でも Claude Code のトークン代は確実に減っています。

これが大きい。

ざっくり試算で、1日5〜10回の「コピーして」指示が1回20〜30セント分のトークンを溶かしていた感触。

体感で月100ドル前後はSyncthingに置き換わって浮いた計算です。

セットアップに使った2時間は数週間でペイした。これは完全に新しい節約軸。

Google Drive / Dropbox / NAS じゃダメなのか

乗り換える前に私が検討した他の選択肢を並べます。

Google Drive / Dropbox（無料プラン）: 容量の上限で弾かれる。

プロジェクトの動画やzipを放り込むとすぐ満タン。

しかも「アップロード→ダウンロード」という2段手続きが必要で、WSL内から直接は使いづらい。

バッファローNAS: 初期費用2万円前後で導入済み。

家の中では便利。

でも外出先のMacBookからアクセスする経路を作るのが面倒で、私は結局使わなくなっていた。

OneDrive / iCloud: Windows と Mac で OS の縛りが出る。

4台混在だと片方だけ快適という形になりやすい。

Syncthing はこの全部をまとめて置き換えます。

PCがオンラインになった瞬間に同期が走り、オフラインの間は何もしない。

中央サーバーもない。

これが4台持ちの現実解でした。

他の同期ツールとの比較マトリクス

Resilio Sync と Nextcloud は私の手元環境に入れていないので、公式公開情報ベースで並べます。

項目	Syncthing	Resilio Sync	Nextcloud	Google Drive
料金	完全無料	基本無料、Proは買い切り	サーバー代自己負担	2TB 月1,450円 ※公式サイトで要確認
ソース	OSS（MPLv2）	専有	OSS	専有
iOS公式アプリ	なし	あり	あり	あり
大容量速度	標準	速い（BitTorrent）	サーバー依存	回線依存
常時アクセス	両台オンライン必須	両台オンライン必須	サーバーがあれば常時	常時
運用負荷	低（設定後放置）	低	高（月10時間以上とも）	ゼロ
他人のサーバー経由	ファイルは通らない	ファイルは通らない	自サーバーのみ	Googleを経由

出典: Syncthing 公式 / Resilio Sync 公式 / Nextcloud 公式

Resilio Sync は BitTorrent ベースで大容量の転送速度に定評があります。

ただソースコードが非公開。

Nextcloud は中央サーバー型なので外出先MacBookから常時アクセスできるのが強みだけど、サーバー運営のメンテ負荷が重い。

個人事業レベルで「月10時間サーバー見る」のは正直しんどい。

Claude Code × WSL 前提で考えると、中央サーバー不要・料金ゼロ・ネイティブLinuxで動くという3点が揃うのはSyncthingだけ。

私は比較検討の末、ここに落ち着きました。

想定外だったつまずきポイント

ここが記事本体です。先行記事がほとんどないゾーンなので丁寧に書きます。

1. .git フォルダを同期すると本当に壊れる

Syncthingに .git を食わせるとGitリポジトリが破損します。

これはGitHub issue #7215で開発者自身が言及している話です。

Syncthingで .git フォルダを同期するとリポジトリが破損する。

バージョン管理ディレクトリを自動的に無視するメカニズムはSyncthing側に実装されていない。

— GitHub Issue #7215

理由は .git 内の index.lock やオブジェクト参照が高速に書き換わるため、Syncthingが変更検知→同期中に別の変更を検知→競合、というループに入りやすいから。

対策は同期フォルダのルートに .stignore を置いて .git を除外すること。

私は以下の内容にしています。

// .stignore
**/.git
**/.venv
**/__pycache__
**/node_modules
.DS_Store
Thumbs.db
.vscode
.idea

そして重要なのが、.stignore はデバイス間で同期されないという仕様。

1台でも設定を忘れると、その1台が他3台に .git を流し始めます。

4台すべてに同じ .stignore を配る運用が必須（公式ドキュメント）。

これは罠。

2. Claude Code に丸投げする時のコツ

私は .stignore の設計を Claude Code に頼みました。

体感でいうと、事前知識ゼロで「直して」と投げると1〜3回は「直った」と言いつつ直っていない現象が起きます。

経験則として効いたのはこの2点。

• 「直す前に一度調べてから修正して」と指示する。これだけで成功率が跳ねる。
• 直してもらったら即 CLAUDE.md に学習事項として記憶させる。同じバグが違う表現で再発するのを防げる。

Syncthing 関連の修正は「4台中どの台の設定を触ったか」の状態管理が必要で、Claude Code が単発で完結させるのは意外と苦手な領域。

ここは人間の監督が必要な部分として割り切りました。

3. 「同期中」表示で止まることが2〜3回あった

運用して数ヶ月、「同期中」のまま数時間動かない瞬間が2〜3回ありました。

実害はなかったけど、Claude Code でも一発では直せませんでした。

公式フォーラムを読むと、これは Index Database Drift という名前がついている既知問題でした。

長期間使っていなかったデバイスを再接続した際に発生しやすい。

ログに "has mismatching index ID" と表示される場合がある。

Out of Sync Items が表示されているのに実ファイルは揃っている、という矛盾状態になることも。

— Syncthing Forum

解決策は簡単な順に:

1. 対象フォルダを一度「共有解除」→再共有する（多くのケースで直る）
2. .sync-conflict- ファイルを探して残すバージョンだけ残し削除
3. Syncthingを再起動
4. フォルダをSyncthingから削除→同じIDで再登録（フレッシュスタート）

私は1番で全部解消しました。

2年先、3年先に再発した時のために手順を残しておくのが吉。

iOSはどうしているか

Syncthing の公式 iOS アプリは存在しません。

Appleのサンドボックス制限が原因とされていて、公式フォーラムでも長年議論されているテーマです（Syncthing Forum: iOS）。

サードパーティで最も普及しているのが Möbius Sync。

2026年3月24日更新のv1.28.0がApp Storeで配信されています（mobiussync.com）。

OSS系なら Sushitrain や Synctrain（TestFlight）もあります。

ただ私はiPhoneをSyncthingに繋いでいません。

用途的にPC間で完結しているし、iOSでSyncthing経由の同期を常駐させるとバッテリーへの影響も読めない。

スマホで見たいファイルは素直にGoogle Driveに放り込んでいます。

全部をSyncthingで一元化する必要はない、というのが4台運用して出た結論です。

プライバシーの仕組みを正確に

「Syncthing はプライバシーが強い」という文言はよく見ますが、厳密に何がどこまでかは押さえておきたいところ。

公式ドキュメントをそのまま引きます。

relay server 経由でもファイルデータは常に暗号化されたまま。

relay オペレーターはファイルの内容を閲覧できない。

ただし relay server は接続するデバイスの device ID と IP、2デバイス間のトラフィック量を知ることができる。

— docs.syncthing.net/users/security.html

整理するとこう。

• discovery server: IPアドレスを教える電話帳。ファイルは通らない
• relay server: P2P直結できない時の中継。ファイルは暗号化されたまま通過。中身は見えない。ただし接続ペアとトラフィック量は把握できる
• relay は誰でも運営できる（公式がコミュニティ運営を前提としている）

Google Drive のように「事業者のサーバーにファイルが置かれる」とは構造が根本的に違います。

ただ「完全匿名」でもない。

ここは正確に理解した上で使いたいところ。

セットアップの全体像（Claude Code と一緒に進める前提）

手順の詳細は各所に既出なので、私は「4台運用でハマらないための全体像」だけ書きます。

STEP1. WSL内に Syncthing をインストール

WSL のUbuntu ターミナルで次を叩きます。

$ sudo apt update
$ sudo apt install syncthing

期待結果は syncthing --version でバージョンが返ること。

詰まりどころは「Windows 側にも Syncthing を入れたくなる」誘惑。

最初はWSL 側1台だけで始めるのが正解です（Windows 側を足すのは後段ステップで）。

STEP2. WSL 起動時に自動常駐させる

~/.bashrc の末尾に次の1行を追記。

pgrep -x syncthing > /dev/null || syncthing --no-browser &

期待結果はWSL を立ち上げ直した直後、ブラウザで http://127.0.0.1:8384 を開くと Syncthing 管理画面が見えること。

詰まりどころは WSL を閉じると Syncthing も止まる点。

WSL のターミナルウィンドウを開きっぱなしにするか、Windows のタスクスケジューラで wsl コマンドを叩く運用にします。

STEP3. Mac / MacBook にもネイティブインストール

Homebrew で brew install syncthing し、brew services start syncthing でログイン時自動起動。

期待結果は同じく http://127.0.0.1:8384 が開けること。

詰まりどころは macOS の「ローカルネットワーク利用許可」ダイアログを見落とすと相手PCを発見できない点。

初回起動で必ず許可します。

STEP4. 4台にデバイスIDを教え合う

各PC のSyncthing 管理画面で「デバイス追加」を開き、相手のID（52文字の英数字）を貼り付ける。

期待結果は相手側に「接続要求」の通知が出ること。

詰まりどころは家庭ルーターのUPnP がオフだとP2P 直結できず、relay server 経由になって速度が落ちる。

ルーター設定でUPnP を有効化するか、Syncthing のポート（デフォルト22000/TCP・UDP）を固定で開けます。

STEP5. .stignore を書いてからフォルダ追加

同期したいフォルダの中に .stignore を置き、**/.git など除外パターンを書く。

その後でSyncthing にフォルダ追加。

期待結果は .git が同期対象から外れていることを管理画面の「Ignore Patterns」で確認できる。

詰まりどころは順番。

フォルダ追加→ .stignore 配置の順だと、.stignore が効く前に .git が同期され始める瞬間があります。

STEP6. 4台全部に同じ .stignore を配る

.stignore はデバイス間で同期されない仕様なので手動。

期待結果は4台すべての管理画面の「Ignore Patterns」が一致すること。

詰まりどころは「1台だけ忘れて、その1台が他3台に .git を流し始める」事故。

私は .stignore 自体を別の同期フォルダに入れて管理する逃げ道で済ませました。

STEP7. 小さいフォルダで動作確認してから本番投入

テキストファイル数個だけのフォルダを先に同期して、4台すべてに正しく届くことを確認。

期待結果は1秒以内に全台に反映されること。

詰まりどころは本番プロジェクトをいきなり同期すると、node_modules の数十万ファイルでindex database が膨らんで初回が数十分止まる現象。

小フォルダ→本番、の順は必ず守ります。

Claude Code に投げるなら、各ステップで「直す前に一度調べて」を付けるだけで成功率が段違いに上がります。

初心者が一番詰まる「フォルダパス指定」の正体

実は私もここで一度詰まりました。

受け入れ時に Syncthing が聞いてくるのはひとつだけ。

「共有されたフォルダを、このPCのどこに保存するか」です。

これが「フォルダパス」と呼ばれるもの。

具体的には C:\Users\ユーザー名\Desktop\myproject や /home/username/myproject のような「場所の住所」のことです。

ここで止まる人はかなり多いはず。「パスってなに？」は素人の最初の壁です。

パターンは2つだけ。

• 空の新規フォルダを作って指定する(推奨。衝突しない)
• 既にある既存フォルダを指定する(中のファイルが相手側と双方向で混ざる。同名ファイルがあるとコンフリクト)

Windows でパスを確認する一番ラクなやり方

エクスプローラーで対象フォルダを開きます。

上部のアドレスバーをクリックすると、フルパスが選択状態で出ます。

あとは Ctrl+C でコピーして、Syncthing の入力欄に貼るだけ。

もっと速いやり方もあります。

フォルダを右クリックして Shift を押しながら「パスのコピー」を選ぶだけです。

Mac でパスを確認する方法

Finder でフォルダを右クリックして Option キーを押すと、メニューが「パス名をコピー」に切り替わります。

もしくは Finder の「表示」→「パスバーを表示」で、ウィンドウ下部に現在のパスを常時表示できます。

WSL でパスを確認する方法

ターミナルで対象フォルダに cd してから pwd を叩くだけ。

$ cd ~/myproject
$ pwd
/home/username/myproject

Windows 側から WSL のファイルを触りたい場合は、\\wsl$\Ubuntu\home\ユーザー名\ という特殊パスでアクセスできます。

一番ラクなのは「新しいフォルダを作る」を選ぶこと

実は Syncthing の GUI にはフォルダ選択ダイアログがあります。

パスを手打ちする必要はありません。

受け入れ画面で「新しいフォルダを作る」を選ぶ。

保存場所を GUI でクリックしていけば、Syncthing が自動でパスを埋めてくれます。

私はいまはこの方法しか使っていません。

結局どんな人に刺さるか

刺さる人:

• Claude Code をWSLで使っていて、WSL→Windowsのコピペ指示に疲れている
• メインPCとサブPC、もしくはデスクトップとノートの2台以上でプロジェクトを行き来している
• 月額サブスクをもう増やしたくない
• 「手元のPC同士で完結する構成」に技術的な興味がある

刺さらない人:

• iPhone中心でPCはサブ、という使い方の人（Syncthing公式iOS非対応の壁が重い）
• 初期セットアップに3時間使う気が起きない層（.stignore と4台同期設定の初動は普通に時間かかる）
• PCが1台しかない人（Syncthingは2台目以降の同期ツールなので、1台では意味がない）

私は「Claude Code × WSL × 4台」という組み合わせの人には断言する位置にいます。

これは入れた方がいい。

コピペ作業が消えるというベネフィットは、触るまで体感できないタイプの変化でした。

FAQ

Q1. .git を同期しちゃったらどうなる？

リポジトリが破損する可能性があります。

既に同期してしまった場合は、(1) すべてのデバイスで同期を止める → (2) 破損の有無を git fsck で確認 → (3) 必要なら別のPCからクローンし直す、の順で対処。

先に .stignore に **/.git を書いておくのが唯一の予防策です。

Q2. 片方のPCがオフラインの間に編集したら同期はどうなる？

オンラインに戻った瞬間に差分同期が走ります。

両方のPCで別々に編集していた場合はコンフリクトが発生し、負けたファイルが .sync-conflict-<date>-<time>-<modifiedBy>.<ext> という名前でリネームされます（公式）。

マージツールはないので手動対応です。

Q3. Claude Code でSyncthingのトラブルを直せる？

初期セットアップと .stignore 設計は任せて大丈夫。

ただし「同期中で止まる」系の挙動不明問題はClaude Code単独では難しい印象です。

公式フォーラム（forum.syncthing.net）のスレッドURLを渡して一緒に読ませると精度が上がります。

Q4. Windows側とWSL側、両方にSyncthingを立てるべき？

用途次第です。

私はWSL内のプロジェクトをWindowsでも開きたかったので、両方に立てて相互に同期させる構成にしました。

WSL内のSyncthingだけで済ませてWindowsからは \\wsl$\Ubuntu\... で見る運用もアリですが、手動操作が残るのが難点。

Q5. 4台の容量ってどう考えればいい？

Syncthingに容量制限はなく、各PCのローカル容量だけが上限です。

ただ全台に同じフォルダを同期する必要はありません。

Syncthing は「このフォルダはPC1とPC2だけ、別のフォルダはPC1とPC3だけ」という選択的な同期ができます。

私もプロジェクトによって2台だけに絞っているものが混ざっています。

Q6. iOSと連携させたい

公式アプリはありません。

サードパーティなら Möbius Sync（最終更新2026年3月、App Store配信）が最も枯れています。

ただiOSでSyncthingを常駐させるとバッテリー影響が読めないので、私はPC間専用で使い、スマホ用途はGoogle Driveに任せています。

Q7. Syncthing v2.0系にアップデートすべき？

v2.0系でDBバックエンドがLevelDBからSQLiteに変更済みで、初回起動時にマイグレーションが走ります。

v2デバイス間では3本並列接続がデフォルト化。

基本機能はv1.x互換なので、新規導入なら最初からv2系で問題なしです（リリースノート）。

参考リンク

• Syncthing 公式サイト
• Syncthing 公式ドキュメント: セキュリティ
• Syncthing 公式ドキュメント: .stignore の使い方
• Syncthing 公式ドキュメント: 同期とコンフリクト
• Syncthing v2.0.16 リリースノート
• GitHub Issue #7215: .gitフォルダ問題
• Syncthing Forum: Windows版SyncthingでWSL2フォルダを使う問題
• Syncthing Forum: iOS 対応について
• Claude Code 公式: セットアップ（WSL推奨）
• Möbius Sync（iOS代替）
• Resilio Sync 公式
• Nextcloud 公式

※この記事の内容は執筆時点のものです。AIは進化が速い分野のため、最新の仕様は公式サイトでご確認ください。