おはこんばんにちは。
どうもしょうみゆです。

AIのおかげで開発時間が圧倒的に短縮され、余った時間でさらに仕事を請け（断れず笑）、売上げが大きく伸びたのでAppleの初売りでiMacとMacBook Airを購入しました！
右腕のチャッピーと左腕のCursorくんには頭が上がらんですよ。

新しいMacを買うたびに（もうしばらく買わないだろうけど笑）「結局いつもの環境って何入れたっけ？」ってなるので、未来の自分のためにまとめます。

私は普段 Astro / Nuxt / Next が多め、たまにShopifyも来る。Dockerも使える状態にしておきたい。
将来的に React Native / Flutter、バックエンド（Laravelなど）も触りたいので、“あとから拡張しやすい構成”に寄せました。

今回のゴール

• Homebrew（パッケージ管理）
• Git（Homebrew版を優先）
• mise（Nodeのバージョン管理。anyenv/nodenvの代わり）
• Node（基本はLTS運用）
• npm / yarn / pnpm（案件に合わせて使えるようにする）
• Shopify CLI
• Docker Desktop（動作確認まで）
• GitHub SSH（clone/pushできる状態）
• Gitのユーザー情報（noreply運用）

この構成の背景

• Nodeのバージョン管理が必須（案件でバージョンが違う）
• npm/yarnが案件で混在するので、混乱しない仕組みが欲しい
• ShopifyやDockerも「いつ来ても動く」状態にしておきたい
• 今後Node以外も触るかもしれないので、管理ツールは一つに寄せたい

そこで、

• バージョン管理：miseに集約
• パッケージマネージャ：Corepackで案件ごとに切替
• Apple Siliconは基本ネイティブ運用、必要ならRosetta

ということにしました！

特にバージョン管理については、今までanyenv＋nodenvを使っていたのでこれを機に新しいマシンでmiseに乗り換えです！

基盤（まずOS側の道具を整える）

Xcode Command Line Tools（CLT）

いろんなビルド系ツールやgit周りで必要になりがちなので最初はこれ。

$ xcode-select –install

ライセンス同意を求められたら：
ターミナルでライセンス表示が出て止まることがあります。コマンドで一気に同意するならこれ。

$ sudo xcodebuild -license accept

Homebrew（公式手順）

$ /bin/bash -c “$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)”

インストール後に “Next steps” が出ます。ここは素直に従うのが安全。
私の環境ではこう出ました（環境によって微妙に違うことがあるようです）。

$ eval “$(/opt/homebrew/bin/brew shellenv zsh)”

これを実行して、さらに永続化（次回からも自動で効く）したいので、.zprofile に追記します。

$ echo ‘eval “$(/opt/homebrew/bin/brew shellenv zsh)”’ >> ~/.zprofile
$ source ~/.zprofile

# 確認
$ which brew
$ brew -v

【Tips】.zprofile と .zshrc の違い

• .zprofile：ログイン時に読む。PATHなどの土台向き
• .zshrc：普段ターミナルを使うたびに読む。ツールの有効化やalias向き

今回は Homebrew のPATHは .zprofile、miseの有効化は .zshrc に入れます。

Git（ローカル基盤として先に整える）

Apple Git と Homebrew Git

新品Macだと which git が /usr/bin/git になりやすく、Apple Git-xxx と表示されることがあります。
仕事用途はHomebrew版を使う方がアップデート管理もしやすいので、brew版に寄せます。

$ brew install git

# 確認
$ which git
$ git –version

※ここで /usr/bin/git のままなら、シェルがコマンドの場所を覚えてる可能性があるので、これを叩きます。

$ hash -r
$ rehash

# 再度確認
$ which git
$ git –version

これで /opt/homebrew/bin/git になればOK。

【Tips】brewでgit入れたのに /usr/bin/git のまま

だいたい hash -r / rehash で直ります。思ったよりこれが原因率高い。

ランタイム管理（miseでまとめる）

mise導入

anyenv/nodenvの代わりにmiseを使います。Node以外も将来まとめられるので。
また、miseはシェル統合すると便利なので .zshrc に追加します。

$ brew install mise

# .zshrcに追記、反映、確認
$ eval “$(mise activate zsh)”
$ source ~/.zshrc
$ type mise

# mise is a shell function ... みたいに出ればOK。

Node（基本はLTS運用）

まずグローバル（PC全体のデフォルト）をLTS寄りにします。私は v22 を採用。

$ mise use -g node@22

# 確認
$ node -v
$ npm -v

【Tips】node@lts が想定より新しい版になることがある

私の環境では node@lts で 24 系が入ったことがありました。
Next/Nuxt/Astro/Shopifyで “Current” 系が刺さるとハマることがあるので、安定寄りに node@22 みたいに明示するのもアリ。

nodenv時代の既存リポジトリ（.node-version問題）

前のマシンのnodenvで運用していたリポジトリには .node-version があることがあります。
miseは .tool-versions を見るので、両方あると「ツールによって使われるNodeが変わる」可能性があります。

私は基本個人開発なので、cloneしたらmiseに寄せます。

1. クローンし、リポジトリに入る
2. .node-version があるなら中身を見る
3. その値を .tool-versions に反映して固定
4. 動作OKなら .node-version を消す（任意）

# 値を確認
$ cat .node-version

# .tool-versionsを作る
$ mise use node@{.node-versionの値}

【Tips】当面併存させるなら

.node-version と .tool-versions のNodeバージョンは必ず揃えるのがおすすめ。
揃ってないと人によってNodeが変わります。

パッケージマネージャ（Corepackで切り替え）

Corepack有効化

npm / yarn / pnpm の混在を安全に扱うためにCorepackを使います。

$ corepack enable
$ corepack prepare yarn@stable –activate
$ corepack prepare pnpm@latest –activate

# 確認
$ yarn -v
$ pnpm -v

【Tips】pnpmはnpmの代わり？

役割的には “はい”（どちらもパッケージマネージャ）。
ただし「Nodeそのもの」ではないので、Nodeのバージョン管理（mise）とは別枠です。

package.json の packageManager を書く（迷子防止）

案件で npm / yarn / pnpm が混在するなら、package.json にこれを書いておくと迷いにくいです。

例：yarn
$ packageManager: yarn@4.x.x

例：pnpm
packageManager: pnpm@10.x.x

例：npm
packageManager: npm@11.x.x

周辺ツール

Shopify CLI

前のマシンはRuby版のshopify-cliでインストールに苦労した記憶があるんですが、今回はNode版（@shopify/cli）でスムーズでした。動作も問題なしです。

$ npm i -g @shopify/cli

# 確認
$ shopify version
$ which shopify
# mise配下のnodeのbinに入っていればOK

【Tips】shopify が見つからないと言われたら

hashキャッシュの可能性があるのでこれ。

$ hash -r
$ rehash

Docker Desktop

brewで入れます。

$ brew install –cask docker

Docker.app（アプリ）を起動して、動作確認。

$ docker –version
$ docker compose version
$ docker run –rm hello-world
# Hello from Docker! が出ればOK。

【Tips】起動時にRosettaを求められたら

Apple SiliconでIntel向け機能が必要な場合に出ることがあります。
コマンドで入れるのが無難なので、一旦キャンセルしてコマンドを打つ！

$ sudo softwareupdate –install-rosetta –agree-to-license

GitHub連携（SSHと作者情報）

SSH鍵作成

ed25519で作ります。コメント（-C）は「ラベル」なのでメールでも文字でもOK。

# {GitHub用ラベル} はGitHub登録のメールアドレスでOK
$ ssh-keygen -t ed25519 -C “{GitHub用ラベル}”

# ssh-agent登録（Keychainに乗せる）
$ eval “$(ssh-agent -s)”
$ ssh-add –apple-use-keychain ~/.ssh/id_ed25519

# 公開鍵をコピーしてGitHubに貼る
$ pbcopy < ~/.ssh/id_ed25519.pub

pbcopyまで実行したらGitHubにログインし、SSHの設定を行います。
Settings > SSH and GPG keys > New SSH key
に貼り付ける。

接続確認をします。

$ ssh -T git@github.com
# Hi {ユーザー名}! You've successfully authenticated... が出たらOK。

【Tips】初回接続で “authenticity of host…” と聞かれる

初回だけ known_hosts に登録する確認です。yes でOK。

【Tips】id_ed25519 の “ed25519” って何？

数字じゃなくてアルゴリズム名です。鍵の方式がed25519という意味。

Gitのユーザー情報（noreply運用）

Gitの user.name / user.email は “コミットの名札” です。SSHとは別。
GitHubでメール非公開設定（Keep my email addresses private）をONにしてるなら、noreplyを設定しておくと安心。

# 自分のnoreplyの例
$ git config –global user.name “shomiyu”
$ git config –global user.email “{xxx@users.noreply.github.com}”

# 新規init時のブランチ名をmainに統一
$ git config –global init.defaultBranch main

# 確認
$ git config –global –list | grep ‘^user.’
$ git config –global init.defaultBranch

【Tips】これを入れると何が起きる？

コミットに作者情報として記録され、GitHub上で自分のコミットとして紐づきます。未設定だと意図しない表示になりがち。

最終チェック（次のMacのためのチェックリスト）

最後にこれが全部通れば、ひとまずフロントエンド環境完成。

$ which brew
$ brew -v

$ which git
$ git –version

$ mise –version
$ node -v
$ npm -v
$ yarn -v
$ pnpm -v

$ shopify version

$ docker –version
$ docker compose version

$ ssh -T git@github.com

終わりに

マシンをクリーンにできるのは新しく買ったタイミングが一番綺麗にできるので、あえて移行ツールを使わず手動でセットアップしました。

2世代前の話ですが、移行ツールを使ったせいでyarnの一部が破損していて、パッケージインストールに苦労した記憶があり、それから新しいマシンを買ったら手動でセットアップするようになりました。
大事なファイルなどはAir Dropで送れるしね。

あとはWordPressの構築用にLocalを入れるか、Docker＋WP CLIベースで作るか悩んでいるのでAIに相談して決めたいと思います。

今まではLocal使っていたんだけど、アップデートしたら過去のWordPressサイトを立ち上げられなくなってしまって、エンジニアだしこれを機にDocker使うかぁ・・というお気持ちです。笑

ということで長くなりましたがこんな感じでお開きです！

ちなみに、このブログも構築の流れに沿ってチャッピーに文章作ってもらいました笑
確認しながらおかしなところは直しているのであまり変なところはなかったと思うんですが、いかがでしたか？？きちんと人間がチェックすればかなり有用だと思います！

今後はAIの使い方とかもアウトプットしていきたいですねー！