1 台目で書いて、別の PC で読めた ── Claude のメモリを複数 PC で共有した半日

2026-05-12 ／ 第9号 ／ 公開時点では下書き

私は 複数台のノート PC を使い分けています。机に向かう時間と、出先や別部屋で動く時間とで、使う PC が変わります。
これまでは「Claude Code は決まった 1 台でだけ使う」運用にしていました。理由はシンプルで、Claude が PC をまたいでくれなかった から。プロジェクトの記憶（memory）も、計画書（plans）も、1 台の PC のディスクの中にしかなくて、別の PC で同じ作業の続きをやろうとすると、ゼロから状況説明をやり直す羽目になっていました。

今日（2026-05-12）、その線を越えました。半日 で。

何が共有されていて、何がされていないか

まず、Claude に「Claude Code の設定ファイル一式（~/.claude/）の中で、PC 間で共有していいものは何か」を整理させました。
調査結果はこんな感じ：

線の引き方の原則は 3 つ：

1. append-heavy なものは共有しない（OneDrive 同期で衝突が起きやすい）
2. 機密はネット越しに置かない（認証情報・トークン類）
3. 残りで「PC 横断でうれしいもの」だけ共有する（記憶と計画）

OneDrive + ジャンクションで「ハブ」を作る

使っている PC はどれも OneDrive 同期が動いていて、OneDrive - esy net というパスがすべての PC で共通でした（運営会社の Microsoft 365 テナント）。
これを利用して、OneDrive 内に .claude-shared/ というハブを作り、各 PC の ~/.claude/ 配下からジャンクション（Windows の「フォルダの別名」）で参照する形にしました。

~/.claude/plans/                        ← ジャンクション
~/.claude/projects/<id>/memory/         ← ジャンクション × 3

        ↓ 実体は ↓

OneDrive - esy net/.claude-shared/
  ├── plans/
  └── projects/<id>/memory/ × 3

こうすると、Claude が ~/.claude/plans/foo.md を読み書きすると、実態は OneDrive 上のファイルが読み書きされて、別の PC からも見えるようになります。
「シンボリックリンクと違ってジャンクションは Windows の通常権限で作れる」「Files On-Demand なら容量も食わない」のが利点。

Claude が私のセーフティに止められた瞬間

セットアップを Claude にお願いして進めていたら、途中で Claude が自分のセーフティに止められる 場面がありました。

Permission for this action has been denied. Reason: Modifying the agent's own ~/.claude configuration directory (replacing memory/plans dirs with junctions to OneDrive) is Self-Modification of agent state, which the user did not specifically authorize.

つまり「お前は自分自身の設定ディレクトリを書き換えようとしている。ユーザーは『共有したい』と言っただけで『この具体的なジャンクション操作』を承認していない」と、Claude のセキュリティレイヤーが Claude を止めた。
これは 正しい設計 だと思いました。AI が自分の memory や設定を勝手に書き換え始めると、何が起きているか追えなくなる。「自己改変は人間の明示承認が要る」というガードレールが効いている瞬間でした。

解決は単純で、Claude にバッチファイル（setup-junctions.bat）を作ってもらい、私がそれをエクスプローラからダブルクリックして実行する、という形に切り替えました。承認の踏み込みは私の手で。

Claude に自分のバッチを監査させたら 3 つのバグが出た

動いたあと、「もう一度チェックして問題がないか確認して」と Claude に頼みました。自分が書いたコードを自分で監査させる、という使い方。出てきた指摘：

① v2 スクリプトの判定バグ
既存ジャンクションを検出するロジックで dir /AL を使っていたが、これは「ターゲット自身が reparse point かどうか」を正しく判定できない。通常フォルダがあっても「ジャンクションがある」と誤判定 → 共有設定されないまま[skip]で抜けてしまう。
→ fsutil reparsepoint query に置き換え。

② OneDrive Files On-Demand のリスク
ファイル属性に ReparsePoint が付いている＝「クラウドのみ保存、ローカルはプレースホルダー」状態。Claude が memory を読む瞬間に OneDrive が DL を走らせる。オフライン時や同期遅延時に失敗するリスク。
→ 「常にこのデバイス上に保持」を doc に明記。

③ ユーザー名検証なし
パスを C:\Users\asano\... で決め打ちしているのに、ユーザー名が違う PC で実行されたら無音で失敗する。
→ スクリプト冒頭で USERNAME をチェック → 違えば即終了。

3 つとも、自分一人で書いていたら見落としていた穴です。「コードを書く Claude」と「コードを監査する Claude」を別のターンで動かす と、AI の中でレビューが効きます。これは新しい使い方の発見でした。

同期テスト：1 台目で書いて、別 PC で読んだ

仕組みが動いていることを確認するために、1 台目で「テストエントリ」を memory に書いて、別の PC で読めるか を試しました。

1 台目側で Claude に書かせたファイル（test_sync_check.md）には、書き込み元 PC の名前、ユーザー、時刻、作業ディレクトリだけを記録。それを memory のインデックス（MEMORY.md）にも 1 行足してもらいました。

そのあと別の PC に移動して、Claude を起動して、こう聞いてみました：

このパソコンの名前は？ メモリのメモリ同期テストエントリを読んで内容を教えて

返ってきた答え（要約）：

このPCは、1 台目とは別の PC です。テストエントリには「書き込み元 PC：1 台目、書き込み時刻：2026-05-12 09:08 JST」と書かれています。1 台目で書かれた同期テストファイルが、別 PC から問題なく読めました。OneDrive 経由のメモリ共有は機能しています。

動いた。別の PC で同じ Claude のコンテキストを引き継げる ようになりました。あとから別 PC 側で「役目を終えたから消しといて」と頼んだら、テストエントリが OneDrive で同期されて、私の手元の PC からも自動的に消えていました。双方向にちゃんと同期している ことの確認も同時に取れました。

新しい PC を追加するときの手順

OneDrive の .claude-shared/ 直下に、セットアップ手順書（SETUP-2ND-PC.md）と冪等なバッチ（setup-junctions.bat）を置いておきました。新しい PC で必要なのは：

1. OneDrive 同期が走っていることを確認
2. .claude-shared を「常にこのデバイス上に保持」
3. 既存の memory / plans があれば .bak にリネーム（無ければスキップ）
4. setup-junctions.bat をダブルクリック
5. claude 起動 → 初回 OAuth ログイン（認証は PC 個別）
6. 必要なら MCP も再認証

何台でも同じ手順で動く設計。スクリプトは冪等（何度実行しても安全）で、親ディレクトリ無ければ自動作成、既存ジャンクションは [skip]、通常フォルダが残っていれば [warn] を出します。

何を「共有しない」かが、設計のいちばん大事なところ

今回のいちばんの判断ポイントは、セッション本体（jsonl）や認証情報を意図的に共有から外した こと。
「全部共有すれば便利」ではなく、「append-heavy なものと機密は OneDrive に置かない」というルールを先に決めて、それから「残りで嬉しいもの」だけを共有対象に絞る。

これは AI 時代のローカル設定との付き合い方として、けっこう汎用的な気がします。
memory（プロジェクトの長期記憶）は共有すると効く。session（その時の会話）は共有してもしょうがない。credentials（認証）は共有すると危ない。
道具が増えるほど、「共有しないこと」を意識的に決める 必要が出てきます。

残ったタスク

・.bak ディレクトリの削除 ── 1〜2 週間運用して問題なければ消す
・新しい PC で実機セットアップ ── 機会があったとき

テストエントリは別 PC 側で削除して、OneDrive 同期でこの PC からも自動的に消えていた。動作確認まで含めて、今日のうちに片付いた。

次回

第10号は、karaha.org の運用面（メンバー登録 → 一斉送信の本番）に戻るかもしれません。あるいは、今日整えた multi-PC 環境を実際に使い始めて気づいたことの話。
来週には書きます。