AI活用レビュー

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

この記事の結論（3行）

  • Windows・WSL・Mac・MacBookの4台で Claude Code を使う私が、SyncthingでWSL→Windowsのコピペ作業を丸ごと消した実体験レビュー。
  • 最大の効果は「クラウド月額が浮いた」ではなく「Claude Codeに出していたコピペ指示＝トークン代が消えた」という新しい節約軸。
  • .git除外と「同期中で止まる」問題だけは事前に知っておくと詰まらない。Claude Codeに任せる前提で運用手順を書きました。

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以上。
最新版は v2.0.16（2026年4月7日リリース）です。

一般的なクラウド同期は、
手元のファイルを一度そのサービスのサーバーに送って、
そこから別のPCに届ける仕組みです。
Syncthing はそれをしません。
PCとPCが直接つながる。
だから月額料金はゼロ、
ファイルの中身が外部のクラウドに残りません。

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

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

設定は最初の5分だけ。
そのあとは放置。
Google Drive のアイコンがタスクバーで回るのと同じ感覚で、
背後で静かに動き続けます。

download and run で完全動作。
保存容量・フォルダ数・場所に制限なし。
登録不要。
ロックイン戦略がない。
do one thing and do it well の哲学。

— tonsky.me https://tonsky.me/blog/syncthing/

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 CodeSyncthing
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別ポート（8385）でWindowsとWSLに独立したSyncthingを立て、
開発フォルダをLinux/Mac/Windows全台で揃えた。
データサイエンスの日常業務で問題なく動作。

— atimad.github.io atimad.github.io

ちなみにWindows版SyncthingでWSL2フォルダ（\\wsl$\Ubuntu\...）を直接指定するのはやめた方がいいです。
公式フォーラムで "Incorrect function" エラーの報告があり、
変更監視（inotify相当）も動きません（Syncthing Forum）。
私も最初これで詰まりかけました。

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

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

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

金額の話をすると、
私は乗り換え前から月額サブスクには入っていませんでした。
なのでクラウド代の節約はゼロ円。
でも Claude Code のトークン代は確実に減っています。
これが大きい。

数ヶ月単位で見ると「コピーして」指示が消えた分のトークン代は、
Syncthingのセットアップ工数を軽く超えてくるはずです。
ここは完全に新しい節約軸で、
既存のSyncthing記事が触れていないゾーン。

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 は私の手元環境に入れていないので、
公開情報ベースで並べます。

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

出典: fast.io / Qiita: Resilio vs Syncthing

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台運用でハマらないための全体像」だけ書きます。

  1. WSL内に apt install syncthing でインストール。Windows側にはインストールしない（これ重要）
  2. ~/.bashrc に pgrep -x syncthing > /dev/null || syncthing --no-browser & を書いてWSL起動時に常駐
  3. Mac / MacBook にも Syncthing をネイティブインストール
  4. Windows側に別のSyncthingを立てる場合は、WSLと別ポート（8385推奨）で起動して、WSL内のインスタンスとはデバイスを分ける
  5. 同期したいフォルダを決めて .stignore を先に書いてから追加する（順番大事）
  6. 4台全部に同じ .stignore を配る（デバイス間で同期されない仕様なので手動）
  7. 最初は小さいフォルダで動作確認してから本番プロジェクトを移す

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非対応の壁が重い）
  • 月10時間もセットアップに使いたくない層（.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.16（2026年4月7日）はDBバックエンドがLevelDBからSQLiteに変わり、
初回起動時にマイグレーションが走ります。
v2デバイス間では3本並列接続がデフォルト化。
基本機能はv1.x互換なので、
新規導入なら最初からv2系で問題なしです（リリースノート）。

参考リンク

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

-AI活用レビュー
-, ,

← 戻る