Claude CodeをWindowsからMac miniに移行したら、トラブル対応もClaude Codeがやってくれた話

この記事の実施記録（2026-05-07）: Claude Code 運用環境をWindowsからMac miniに移行。.mcp.json のWindowsコマンド（cmd /c npx、.exe）3箇所はClaude Codeが自動修正・再インストール。PowerShell（.ps1）スクリプト4本もClaude Codeがその場でbash書き直し。settings.local.json はOS依存のためgit管理外に変更。blogsync はOSTYPE分岐で事前対応済みのため追加修正ゼロ。

---

Mac miniが届いた。

Windows 11で運用してきたClaude Code環境を、一日でmacOSに移し替える作業になった。

「設定ファイルをコピーしてあとは動くだろう」と思っていたが、実際には .mcp.json のWindowsコマンドがそのまま残っていたり、PowerShellスクリプトが動かなかったりと、いくつか詰まりポイントがあった。

ただ、面白かったのは——そのトラブル対応のほとんどを、Claude Code自身がやってくれたことだ。

---

移行の全体像：何を動かす必要があったか

まず、この環境で動いているもの一覧から整理する。

カテゴリ	内容
Claude Code CLI	本体。npm install -g @anthropic-ai/claude-code で入れ直し
MCPサーバー群	Google Drive / Analytics / Google Search Console など
blogsync	はてなブログへの記事投稿ツール
PowerShellスクリプト	Windowsで動いていた自動化スクリプト4本
設定ファイル	.mcp.json / settings.local.json
認証情報	APIキー・OAuthクレデンシャル

このうち「そのままコピーして動く」ものと「OS依存で修正が必要なもの」が混在していた。

---

MCP設定（.mcp.json）：Windows固有コマンドが残っていた

MCPサーバーの設定ファイル .mcp.json には、Windows環境で動かすために書いた記述がそのまま入っていた。

たとえば google-drive サーバーの設定はこうなっていた（Windows版）：

"google-drive": {
  "type": "stdio",
  "command": "cmd",
  "args": ["/c", "npx", "-y", "@piotr-agier/google-drive-mcp"]
}

cmd /c はWindowsのコマンドプロンプト経由でコマンドを実行するための記法だ。macOSには cmd コマンド自体が存在しないので、当然エラーになる。

同様に gsc-mcp（Google Search Console MCP）も "command": "cmd", "args": ["/c", "uvx", ...] という形式だった。

analytics-mcp には .exe 拡張子が残っていた。Windowsバイナリはそのまま動かない。

Claude Codeが自動で直してくれた

Mac側でClaude Codeを起動してMCPが使えないことを伝えると、Claude Codeはこちらのログを確認し、修正内容を提案・実行してくれた。

変更の中身は単純だ：

• "command": "cmd", "args": ["/c", "npx", ...] → "command": "npx"
• "command": "cmd", "args": ["/c", "uvx", ...] → "command": "uvx"
• .exe を削除してmacOS向けバイナリのパスに変更

さらにMCPサーバーの再インストールまで実行してくれた。私がやったのは「MCPが動かない」と伝えることだけだった。

手動でトラブルシュートする必要がなかったのは正直助かった。移行作業中にMCPの設定を一つひとつ見直すのは地味に時間がかかるので。

---

PowerShell（.ps1）スクリプト：4本まとめてbashに書き直し

Windowsで使っていたスクリプトのうち、PowerShell（.ps1）で書かれたものが4本あった。macOSには powershell.exe がないため、そのままでは実行できない。

• screenshot.ps1（スクリーンショット取得）
• start-todo-manager.ps1（Todoマネージャーの起動）
• obsidian-link.ps1（Obsidianとの連携）
• もう1本

どう対応しようか考えていたところ、Mac側のClaude Codeがその場でbashスクリプトに書き直してくれた。

たとえば screenshot.ps1 に対応するmacOSの実装はこうなる：

#!/bin/bash
screencapture -x /tmp/screenshot.png  # 無音

macOSには標準で screencapture コマンドがあるので、PowerShellで書いていた処理をネイティブコマンドで置き換えることができる。

こちらも「動かない」と伝えただけで、4本まとめて対応してくれた。元のスクリプトの意図を読み取ったうえで書き直してくれるので、結果的に「PowerShellスクリプトをbashに変換する」という作業を自分でやる必要がなかった。

---

settings.local.json：git管理外が正解だった

ここは自分で対応した箇所だ。Claude Codeが直してくれた話ではなく、移行を機に気づいた設計上の問題として残しておく。

気づきとして大きかったのが settings.local.json の扱いだ。

このファイルには環境変数（PROJECT_ROOT や TODO_DOTENV のパス）や権限設定が入っている。WindowsのときはWindowsの絶対パスで書いてあった：

{
  "env": {
    "TODO_DOTENV": "C:\\Users\\saito\\Documents\\000.パートナー\\.env",
    "PROJECT_ROOT": "C:\\Users\\saito\\Documents\\000.パートナー"
  }
}

これをmacOS環境にそのままコピーしても当然動かない。

さらにこのファイル、もともとgit管理されていた。つまりWindowsパスが書かれたファイルがリポジトリに入り続けていたことになる。

移行を機に settings.local.json を .gitignore に追加してgit管理から外し、各OS環境で個別管理する方針に変えた。

Mac版の内容は次のようになる：

{
  "env": {
    "TODO_DOTENV": "/Users/saitoko/workspace/000-partner/.env",
    "PROJECT_ROOT": "/Users/saitoko/workspace/000-partner"
  }
}

考えてみれば当然で、OSが変わると絶対パスもユーザー名も変わる。settings.local.json は「local」という名前の通り、そもそもgitで共有するファイルではなかった。Windows環境を使い続けている間は気づかなかった問題だ。

なお、権限パターン（permissions セクション）にもWindowsパス形式（//c/Users/... や C:/Users/...）が混在していたので、そちらもあわせて修正した。

---

blogsync：事前対応済みで追加修正ゼロ

はてなブログへの記事投稿に使っている blogsync は、起動スクリプトにOSTYPE分岐が入っていた。

case "$OSTYPE" in
  msys*|cygwin*) BLOGSYNC="$HATENA_DIR/bin/blogsync.exe" ;;
  linux*)        BLOGSYNC="$HATENA_DIR/bin/blogsync-linux-amd64" ;;
  darwin*)       BLOGSYNC="$HATENA_DIR/bin/blogsync-darwin-arm64" ;;
  *)             echo "Unsupported OS: $OSTYPE" >&2; exit 1 ;;
esac

Mac miniはApple Silicon（ARM64）なので darwin-arm64 バイナリを使う形になっている。このバイナリをダウンロードして配置するだけで、スクリプト側は修正ゼロで動いた。

Windows環境から将来的にmacOSへ移行するかもしれないという想定で、スクリプト設計段階でOS分岐を入れておいた効果が出た形だ。

実際にはてなブログへの投稿まで確認できた。

---

移行後の気づき：「Claude Codeがいれば環境移行は怖くない」とは言い切れない

今回はほとんどのトラブルをClaude Codeが処理してくれた。

ただ正直に言うと、「Claude Codeがいれば何も考えなくていい」という話ではなかった。

いくつか補足すると：

事前準備は必要だった。 認証情報（OAuthクレデンシャル、APIキー）の移動は手動だ。AirDropかUSBで移す必要があり、Claudeはそこには手が届かない。

バイナリの確保も手動だった。 blogsync のdarwin-arm64バイナリはリリースページから自分でダウンロードした。Claude Codeが「ここからダウンロードしてください」と案内してくれたが、実行したのは自分だ。

.mcp.json の修正はClaude Codeが処理してくれたが、それは「何かおかしい」と伝えたから。 Claude Codeが自律的に環境をスキャンして先回りで直してくれたわけではない。詰まったポイントを伝えることで動いた。

それでも、.mcp.json の修正・MCPの再インストール・PowerShellスクリプト4本のbash書き直しをほぼ一度のやり取りで片付けてくれたのは大きかった。同じ作業を手動でやっていたら半日はかかっていたと思う。

---

まとめ：Windowsから移行するときの実務的なポイント

今回の移行で学んだことをまとめると：

1. .mcp.json はOS依存のコマンドが混入しやすい。 cmd /c / .exe はWindows固有。移行時に確認が必要
2. .ps1 スクリプトはmacOSで動かない。 Claude Codeに「動かない」と伝えればbashに書き直してくれる
3. settings.local.json はgit管理外にする。 絶対パスが書かれているため、OSをまたいで共有すると必ずズレる
4. blogsync 等のOSTYPE分岐は事前に入れておくと移行コストがゼロになる
5. 認証情報の移行は手動。 ここだけはClaude Codeが関与できない

Claude Code環境のWindows→Mac移行を検討している人の参考になれば。

Claude Code自体の使い方や運用設計をもう少し体系的に学びたい方には、Claude CodeによるAI駆動開発入門（平川知秀 著）がまとまっている。Kindle版で読める。

---

FAQ

Q: Claude Codeの設定はWindowsとMacで別にしないといけないの？

A: .mcp.json と settings.local.json はOS依存の内容が含まれるため別管理が現実的。特に settings.local.json はgit管理から外して各環境で個別に作成する方が安全。

Q: MCPが動かないとき、具体的に何と伝えればいい？

A: 「MCPが動かない」「エラーが出ている」で十分。Claude CodeがMCPのログを確認して原因を特定・修正してくれる。詳細なエラーメッセージを貼り付けると精度が上がる。

Q: PowerShellスクリプトがどれくらい複雑でも書き直してくれる？

A: 今回の4本は比較的シンプルなスクリプトだった（スクリーンショット取得・プロセス起動・外部ツール連携）。複雑なロジックが入っているスクリプトについては、書き直してもらった後に動作確認をしっかりしたほうがいい。

---

.mcp.json を直してもらい、スクリプト4本を書き直してもらうと、次の問いが出てくる——そもそも settings.local.json や CLAUDE.md はどう設計すれば、次のOS移行でも同じ苦労をしないで済むのか。

私はその問いを掘り下げる中で、権限設定・環境変数の構造・CLAUDE.mdによる行動制約の設計がひとつの体系になると気づいた。その全体像を整理したのが、Zenn BookのVol.4だ。

AIチームを「仕組みを渡すまで」育てる——CLAUDE.md設計・権限管理・ガバナンス（Vol.4）（序章無料）

---

関連記事

• Claude Code設定ファイルを整理したら「形」は19%しかなかった——4層×2軸で見えた、整理から始まる設計の問い
• Claude Code マルチエージェント構成の作り方——秘書・ライター・リサーチャーを6日で揃えた
• Claude Code 実用TIPS集——知っていれば5秒、知らなければ1時間