同期対象の整理——Claude Codeの「記憶」はどこに保存されるか
Claude Codeには会話をまたいで知見を蓄積するメモリ機能がありますが、実体はただのMarkdownファイル群です。同期を考える前に、対象が3か所に分かれていることを押さえてください。
~/.claude/projects/<プロジェクトのスラッグ>/memory/— プロジェクトごとの自動メモリ。1ファイル1知見で、索引のMEMORY.mdが付きます~/.claude/skills/— ユーザースキル(定型ワークフローの手順書)~/.claude/commands/— カスタムスラッシュコマンド
スラッグはプロジェクトのフルパスから生成されます。たとえば/Users/yourname/Projects/ProjectAで開いたセッションのメモリは-Users-yourname-Projects-ProjectAというフォルダに入ります。ユーザー名がパスに含まれるこの仕様が、後述する2台目のMacでの作業に効いてきます。
なお本記事で扱うのはこの「記憶ファイル」であり、RAMとしてのメモリ消費の話ではありません。動作が重い場合の切り分けはClaude Codeのメモリ使用量が肥大化する原因の切り分けと対処法を参照してください。以下は2026年8月時点、Claude Code 2.1系での確認内容です。
iCloud Driveに実体を移し、シンボリックリンクで参照させる
結論から言えば、方式は「実体をiCloud Driveへ移動し、元の場所にはシンボリックリンクを置く」だけです。Claude Code側の設定変更は不要で、リンクを辿って今までどおり読み書きしてくれます。macOSのiCloud Driveは~/Library/Mobile Documents/com~apple~CloudDocs/がローカルの実体なので、ここに集約用フォルダを作ります。
フォルダ構成はアカウント別・プロジェクト別に住み分ける
後からプロジェクトが増えることを見越して、最初に構成を決めておくと迷いません。
iCloud Drive/claude-memory/
└── main/ # Claude Codeのアカウント(設定ディレクトリ)ごとに1フォルダ
├── global/
│ ├── skills/ # ~/.claude/skills の実体
│ └── commands/ # ~/.claude/commands の実体
├── ProjectA/ # プロジェクトごとのメモリの実体
└── ProjectB/
1台目のMacでの移行コマンド
移行中はClaude Codeを終了しておきます。
IC="$HOME/Library/Mobile Documents/com~apple~CloudDocs/claude-memory/main"
mkdir -p "$IC/global/skills" "$IC/global/commands" "$IC/ProjectA"
# グローバルのスキルとコマンド
mv ~/.claude/skills/* "$IC/global/skills/"
rmdir ~/.claude/skills && ln -s "$IC/global/skills" ~/.claude/skills
mv ~/.claude/commands/* "$IC/global/commands/"
rmdir ~/.claude/commands && ln -s "$IC/global/commands" ~/.claude/commands
# プロジェクトのメモリ(スラッグは実際のパスに合わせる)
SLUG="-Users-$(whoami)-Projects-ProjectA"
mv ~/.claude/projects/$SLUG/memory/* "$IC/ProjectA/"
rmdir ~/.claude/projects/$SLUG/memory
ln -s "$IC/ProjectA" ~/.claude/projects/$SLUG/memory
移行後にClaude Codeを起動し、スキル一覧とメモリが今までどおり見えることを確認してください。
会社の別のMacでの作業——ユーザー名やパスが違っても使える理由
デスクのMacと持ち出し用のMacでユーザー名やプロジェクトの置き場所が違っても、この方式はそのまま使えます。iCloud側のパスは各Macの$HOME起点で解決され、シンボリックリンクはMacごとにローカルで張り直すものだからです。2台目では実体の移動は不要で、リンク作成だけを行います。
# iCloudの同期完了を確認してから
IC="$HOME/Library/Mobile Documents/com~apple~CloudDocs/claude-memory/main"
SLUG="-Users-$(whoami)-Projects-ProjectA" # このMacでの実際のスラッグに合わせる
mkdir -p ~/.claude/projects/$SLUG
ln -s "$IC/ProjectA" ~/.claude/projects/$SLUG/memory
ln -s "$IC/global/skills" ~/.claude/skills
ln -s "$IC/global/commands" ~/.claude/commands
ユーザー名が違えばスラッグも変わりますが、変わったスラッグのフォルダから同じiCloud実体へリンクするだけなので問題になりません。注意が必要なのはプロジェクトのフォルダ名自体が違うケース(片方はProjects/ProjectA、もう片方はwork/project-aなど)で、この場合もリンク先を手で合わせれば動きますが、スラッグの読み替えを間違えやすいので、可能ならフォルダ名は揃えておくのが無難です。
落とし穴——同時使用の競合と「ストレージを最適化」
実運用で踏みやすいのは次の4点です。
- 2台のMacで同時にClaude Codeを使わない。iCloud Driveはロック機構がないため、両方からメモリが書き込まれると「ファイル名 2」のような競合コピーが生まれ、索引のMEMORY.mdと実ファイルがずれます
- 「Macストレージを最適化」に注意。実体がクラウド退避されるとClaude Codeがファイルを読めるまでラグが出ます。Finderで
claude-memoryフォルダを右クリックし「今すぐダウンロード」でローカルに固定しておきます - 同一Apple IDが前提。iCloud Driveを共有できないアカウント構成(会社と個人でApple IDが別など)では成立しません。その場合は共有できるストレージで同じシンボリックリンク方式を検討することになります
- Windowsとの混在は不可。この方式はmacOSのパス構造前提です
受託開発での使いどころ——「調べ直し」をなくす
この同期が効くのは、案件ごとの調査知見を端末をまたいで持ち運べる点です。たとえばEC-CUBEの受託案件では、バージョンアップ影響調査で洗い出したapp/Customizeの上書き箇所や、検証環境の構成、過去に踏んだ不具合の原因と対処がプロジェクトメモリに蓄積されていきます。デスクのMacで調査した内容を、翌日打ち合わせ先に持ち出したMacのセッションがそのまま覚えている——同じことを二度調べ直さない状態を、特別なツールなしに作れます。
スキル側も同様で、定型ワークフロー(記事投稿手順、デプロイ手順など)を1か所で直せば全端末に反映されます。一方、チームメンバーと共有したい許可設定などはプロジェクト側の.claude/settings.jsonでGit管理するのが筋で、個人の記憶はiCloud・チームの設定はGitという住み分けにすると運用が濁りません。設定側の考え方はpermissionsのallow/deny/askで許可プロンプトを制御する手順を参照してください。