⚡ Claude Code Guide
← スマホからのリモート操作 Skill カタログ →

title: Windows⇔WSL 設定同期 icon: 🪟 slug: 25-windows-wsl card_desc: WSL CLI版とWindows Desktop版の2環境での設定配置と同期の考え方 — WSL symlink方式の罠を実測4パターンで検証し、確認コマンドターミナルに入力してコンピュータに与える一行の指示。lsやcdのように『プログラム名+補足指定』で構成される付きで解説

25 Windows⇔WSL 設定同期

最終更新: 2026-10-14 | 対象: WSL2 CLI版とWindows Desktopアプリ版の2環境運用

この章の目的

Claude Codeを WSL CLI版（Linuxホーム）と Windows Desktopアプリ版（C:\Users\<ユーザー>\）の2環境で使うとき、設定（CLAUDE.md・settings.json・skills・hookClaude Codeの特定のタイミング（ツール実行前後・セッション開始時等）で自動処理を差し込む仕組み。「保存前にチェック」「終了時に記録」等を機械的に強制できるs）がどのように配置され・どう同期されるかを1ページにまとめる。

結論: 2環境は「独立実体 + 部分的な自動同期」で運用するのが現実解。WSL symlinkでWindows側に見せかける方式は罠だらけ（本記事の経緯参照・実測で全パターンFAILを確認済み）。

現在の構成（実測ベース）

【WSL側】~/                             【Windows側】C:\Users\<ユーザー>\
├─ .claude/ ←実ディレクトリ             ├─ .claude/ ←完全に独立した実ファイル
│   ├─ scripts → 正典repoへsymlink      │   ├─ CLAUDE.md（Desktop版専用にカスタマイズ）
│   ├─ skills  → 正典repoへsymlink      │   ├─ settings.json（独立管理）
│   ├─ CLAUDE.md（CLI版・実ファイル）    │   └─ settings.local.json
│   └─ settings.json（実ファイル）       │
└─ projects/<正典repo>/                  └─ projects/
    （scripts/skillsの実体・git管理）
項目 WSL CLI版 Windows Desktop版 同期
CLAUDE.md CLI版専用（全量・長め） Desktop版専用（Windows固有の注意点に絞る） 非同期（意図的に別物が正解）
settings.json CLI版 Desktop版 hooks等を手動で二重管理（自動同期はシークレット事故リスクがあるため意図的に限定的）
scripts/ symlink → 正典repo 実ファイル 非同期
skills/ symlink → 正典repo 実ファイル 非同期

ポイント: 両環境のCLAUDE.mdを同じにしない。CLI版とDesktop版では使える機能・パス解決・シェルユーザーとOSの間に入って、コマンド入力を受け付けて実行する程序。ターミナルで打つコマンドを実際に処理する部分が違い、共通化しようとすると「どちらかでしか動かない指示」が混入する。Desktop版は「Windows固有の注意（パス変換・文字コード等）」に絞った薄いファイルにするのが効く。

WSL symlink方式が失敗する理由（実測）

Windows側からWSLの設定を使いたくて、C:\Users\<ユーザー>\projects\repo にWSL symlink（ln -s）を張ると次の挙動になる（全部実測済み）:

セル ツール 操作 結果
1 PowerShell Get-Content FAIL: PathNotFound — symlinkのtargetがLinux pathなのでWindowsから解決できない
2 PowerShell git status FAIL: カレント移動に失敗し、別ディレクトリフォルダのこと。ファイルを階層的に整理する入れ物。Linux系ではフォルダをディレクトリと呼ぶのが普通で実行される
3 cmd.exe type FAIL: 「UNC パスはサポート同じPCの中で複数のプログラムが通信を待ち受けるための「窓口番号」。8787番・3000番のように番号で区別するされません」+ フォールバックメインの手段が使えなくなった時に、自動的に予備の手段へ切り替える仕組み。「本命が失敗したら副えに任せる」二段構え先が別リポジトリになる
4 cmd.exe git status FAIL: UNCフォールバックで意図しない別リポジトリでgitコマンドが動く（危険）

特にセル4が深刻: 「あるrepoの状態を見たつもり」が別repoのgit操作になっており、誤コミット・誤pushの温床になる。

どうすればいいか

確認コマンド（自分の環境の点検用・読み取り専用）

# ① WSL側 .claude の symlink 構造を把握
ls -la ~/.claude/ | grep -E "^l"

# ② Windows側 .claude がsymlink無し（=独立実体）であること
ls -la /mnt/c/Users/<ユーザー>/.claude/ | grep -cE "^l"

# ③ Windows側projects配下に迷子symlinkが残っていないか
ls -la /mnt/c/Users/<ユーザー>/projects/

# ④ Windows側からWSL symlinkが解決できるか（失敗パターンの再現確認）
powershell.exe -NoProfile -Command "Get-Item 'C:\Users\<ユーザー>\projects\<repo>' | Select Name"

# ⑤ WSL symlinkの中身をWSL側から確認（target がLinux pathか）
readlink ~/.claude/scripts

📖 かみ砕くと

2つの家（WSLとWindows）から同じ金庫室（設定フォルダ）を使いたいとき、渡り廊下（symlink）を自作すると鍵が合わず開かないか、最悪別の部屋に繋がる。正解は「金庫室は1つに置き、必要な複製を検閲付きの宅配（同期スクリプト）で送る」こと。

環境早見表（ここを見れば自分の環境が1目でわかる）

ファイル配置 — 何がどこにあるか

役割 WSL CLI版 Windows Desktop版
大本の指示書（CLAUDE.md） ~/.claude/CLAUDE.md（フル版・@includeでルールファイルを毎回読込） ~/.claude/CLAUDE.md（Windows固有の注意に絞った別物・共通化しないのが正解）
プロジェクト指示書 各repoの CLAUDE.md 同左（\\wsl.localhost\...経由で読める）
動作設定（settings.json） ~/.claude/settings.json（hooks多数） ~/.claude/settings.json（hooksはWSL版より少ない・移行済み分のみ）
APIApplication Programming Interface（エーピーアイ）の略。あるプログラムの機能を、別のプログラムから呼び出せるようにした「窓口」キー ~/.secrets.env（SessionStart hookがsettings.jsonへ注入・値を会話やコマンド引数コマンドや関数に渡す補足の指定。ls -la の -la の部分のように、動作を細かく指示する値に書かない） .env読込不可 → Windows環境変数プログラムの外側（OS側）で設定する値の入れ物。プログラムを書き換えずに設定を切り替えられる。APIキー等の秘密の値はソースコードに直書きせずここに入れるのが安全な定石（[System.Environment]::SetEnvironmentVariable）かsettings.json直書き・設定後はアプリ再起動
プロジェクト永続メモリ ~/.claude/projects/<プロジェクト>/memory/（MEMORY.md索引が毎セッションClaude Codeの1回の対話単位。起動から終了までの会話と作業状態のこと。長く使うと内容が混ざるため、トピックの区切りで新セッションに引き継ぐ運用をする自動読込） C:\Users\<ユーザー>\.claude\projects\...（WSL側とは別管理・同期されない）

読み込み順序（Claude Code標準）: ①ユーザー設定（~/.claude/）→ ②プロジェクト設定（repoの.claude/）→ ③ローカル設定（settings.local.json）。後の方が優先。

バックエンドLLM — 何で動いているか確認する方法

原則: 実行エンジンは動的。プロキシ通信の中継役。「クライアント→プロキシ→本来の宛先」の順に通信を一度経由させる仕組みで、仲介者が経路の切替・集計・制限等を担当する（localhostローカルホスト。「自分のPCの中」を指す特別なアドレス。localhost:8787 のような書式は「自分のPCの8787番ポート」の意味:8787）が使用率・時間帯で自動切替するため、起動時のバッジ・画面表示・transcriptのモデル名は当てにならない（自己申告のキャッシュ一度得た結果を取っておいて、次回は同じ計算をせず使い回す仕組み。速くなるが、元のデータが変わった時の更新忘れに注意）。

方法 信頼度 内容
プロキシstatus（1行確認） 高 bash ~/bin/proxy-mode.sh status → 実効provider・使用率を表示。迷ったらこれ
プロキシ転送ログ 最高 journalctlのCaptured actual model行（実エンジンの直接証跡・llm-checkスキルClaude Codeで「特定の作業手順」をパッケージ化したもの。SKILL.mdに手順を書いておくと、対応する場面でAIがその手順を読み込んで従う。経験を再利用する仕組みの手順）
起動時バッジ/画面表示 ❌不可 起動時固定で動的切替を追跡しない（例: 15-19時のピーク帯は別エンジンに自動フォールバックするがバッジは変わらない）

切替: 「MiniMaxにして」「GLMにして」「自動に戻して」等の発話でプロキシの手動モード切替（TTL式・期限切れで自動復帰）。Desktop版（ネイティブSonnet動作）ではモデル切替不可・外部LLMはMCPModel Context Protocol（エムシーピー）の略。AIに外部ツール（検索・GitHub・データベース等）を繋ぐための共通接続規格。USBのような「差せば繋がる」仕組みでAIの能力を拡張するツール経由で呼ぶ。

コマンド系の制限 — guard・分類器と安全な回避

コマンド実行には3層の防御が働く。引っかかったら別ツールに差し替えて迂回するのではなく、正規経路を使うのが原則:

層 検知するもの 引っかかる例 安全な対処
破壊的コマンドdeny（hook） 恒真に危険な操作 rm -rf /・git push --force origin main・sudo rm -rf /・DROP DATABASE・terraform destroy 実行しない。削除は個別ファイル指定+ユーザー確認の正規経路
設定ファイルプログラムの動作を決める設定値を書いたファイル。コード本体を書き換えずに、設定だけ変えられるようにする書込guard（hook） 設定ファイル読取→外部送信の連鎖 cat settings.json の内容を含むcurl送信 設定の値をコマンドに含めない（キー名のみ扱う）
権限分類器（CC本体・auto mode） 外部送信系コマンド curlでのデータ送信（設定ファイルを含まなくても発火する場合がある） WebFetchツールやgh CLI等の専用経路を使う。分類器の迂回（別ツールへの差し替え）はしない——迂回は検知を外れるだけで事故種別は消えない

シークレットの鉄則: ①コマンド引数に直接書かない（source ~/.secrets.envして$変数参照）②「今後許可」を押すとコマンド全文がallowリストに永続化される（埋め込み文章の意味を数字の列（ベクトル）に変換すること。意味が近い文章は近い数字になるため、「意味での検索」ができるようになる。RAGの部品値も）③ denyされたら、なぜ止まったかを確認してから正規経路へ。

得意・不得意・障害（実測ベース）

WSL CLI版:

Windows Desktop版:

使い分けの指針: 自動化・スクリプト・定期実行はWSL CLI版（本丸）。Windowsアプリ操作・GUIが絡む作業だけDesktop版。両者で設定を共通化しようとせず、「独立実体+必要なものだけ同期」（本記事前半の構成）が実測上の正解。

🔗 関連章