AI開発用Macを壊さず整える初期チェック

AI開発用のMacを整える時、最初に確認すべきなのは「何を追加するか」ではありません。失敗した時に戻れるか、いま何がどこから起動しているかです。

2026年7月11日、私が普段AI自動化に使っているMacを、設定変更なしの読み取りコマンドだけで点検しました。すると、開発ツールは動いている一方で、Time Machineの最新バックアップ確認は保存先のマウントに失敗しました。ここでHomebrewやPythonの更新を先に始めていたら、「動く環境を変えたのに、戻り先は未確認」という順番になっていました。

この記事では、実際に確認した7項目、出た数値、そこで作業を止めた理由を公開します。機種やバージョンが違っても、同じコマンドで自分のMacの現在地を確認できます。

結論：インストール前に「戻れる・空いている・混ざっていない」を見る

今回の点検結果は次の通りでした。端末名、ユーザー名、バックアップ先のボリューム名など、個人を特定できる情報は記録していません。

確認項目	実測結果	今回の判断
OS / CPU	macOS 26.4 / arm64	Apple Silicon向けの導入先を選ぶ
内蔵ストレージ	926GiB中、248GiB利用可能	容量不足は直ちに問題ではない
Command Line Tools	/Library/Developer/CommandLineTools	Gitなどの土台は認識済み
Python	3.10.12 / pyenv shim	OS標準Pythonと混同しない
Node.js	25.8.0 / Homebrew配下	更新前にプロジェクト互換性を確認する
FileVault	On	暗号化は有効。ただし復旧方法も別途確認する
Time Machine	バックアップ先のマウント失敗	新規導入や一括更新をいったん止める

一番重要だったのは、ツールの新しさではなくTime Machineの失敗です。PythonやNode.jsは起動できましたが、それは「安全に変更できる」証拠ではありません。バックアップ確認が通るまでは、brew upgradeのように複数パッケージへ影響する操作を後回しにしました。

私が最初に実行した読み取り専用チェック

まず、環境を書き換えないコマンドだけを実行しました。

sw_vers
uname -m
df -h /
xcode-select -p

command -v git && git --version
command -v python3 && python3 --version
command -v node && node --version
command -v npm && npm --version
command -v ffmpeg && ffmpeg --version | head -n 1

fdesetup status
tmutil latestbackup

この順番には理由があります。

1. OSとCPUを確認する
2. 空き容量を見る
3. 開発ツールが「あるか」ではなく「どこから起動しているか」を見る
4. 暗号化とバックアップを確認する
5. すべて確認してから、追加や更新を判断する

command -vを付けたのは、バージョン番号だけでは導入元が分からないからです。今回のMacではGitは/usr/bin、Pythonはpyenvのshim、Node.jsとffmpegは/opt/homebrew/binから起動していました。全部が同じ管理方法ではありません。

複数の管理方法が共存すること自体は異常ではありません。ただし、どのコマンドを誰が管理しているか分からないまま更新すると、ターミナルでは動くのに定期実行では別バージョンが起動する、といった差が生まれます。

実測で見つかった問題1：バックアップ先を確認できなかった

tmutil latestbackupを実行すると、最新バックアップのパスではなく、バックアップ先をマウントできないというエラーが返りました。

Failed to mount backup destination

ここで大事なのは、「Time Machineを設定した記憶がある」ことと「いま復元に使える」ことを分けることです。私はこの結果を見て、次の操作を止めました。

• Homebrew全体の一括更新
• Pythonの既定バージョン変更
• Node.jsのメジャーバージョン切り替え
• shell設定ファイルの整理を兼ねた削除
• launchdジョブの一括変更

Appleの案内でも、Time Machineはファイルを自動バックアップし、後から復元するための仕組みとして説明されています。設定画面に保存先が表示されるだけで安心せず、実際に最新バックアップを確認できるか、復元対象が見えるかまで点検したほうが安全です。

• Apple：Time MachineでMacのファイルをバックアップする

この記事では保存先への再接続手順までは断定しません。外付けディスク、NAS、ネットワーク、権限など、使っている保存先によって原因が変わるためです。まず「確認できなかった」という事実を残し、バックアップ先を再接続してから変更作業へ戻します。

実測で見つかった問題2：PATHが23区間あり、1区間重複していた

次にPATHを分解して数えました。

printf '%s' "$PATH" | tr ':' '\n' | nl
printf '%s' "$PATH" | tr ':' '\n' | sort | uniq -d

今回の結果は23区間、そのうち重複が1区間でした。重複が1つあるだけでMacが壊れるわけではありません。しかし、環境設定を追加するたびに同じ行を.zshrcへ足していると、どの設定が現在有効なのか追いにくくなります。

ここでも、すぐ削除はしません。先に次の情報を保存します。

echo "$PATH" | tr ':' '\n'
command -v python3
command -v node
command -v git

その後、.zprofile、.zshrc、ツール固有の初期化行を一つずつ確認します。PATHの重複除去を「掃除」として始めるのではなく、どのコマンドの起動元が変わるかを確認する作業として扱います。

実測で分かったこと3：空き容量だけを見ても安全とは言えない

内蔵ストレージは926GiBで、確認時点の利用可能容量は248GiBでした。AI開発では、モデル、Dockerイメージ、動画素材、生成画像、node_modules、Python仮想環境などが増えるため、空き容量の確認は必要です。

ただし、248GiB空いているから何でも入れてよい、とは判断しませんでした。容量が十分でも、次の問題は残ります。

• どのプロジェクトがどのPythonを使うか不明
• Node.jsのメジャーバージョンと既存ツールの互換性が未確認
• バックアップの復元可能性が未確認
• 定期実行が対話シェルと同じPATHを使うとは限らない

空き容量は合格条件の一つであって、変更許可そのものではありません。

PythonとNode.jsは「入っているか」より起動元を見る

今回、python3 --versionは3.10.12でした。起動元はpyenvのshimです。一方、Node.js 25.8.0とnpm 11.11.0は/opt/homebrew/binにありました。

この状態で、検索して見つけたコマンドをそのまま実行するのは危険です。たとえばPythonパッケージをグローバルへ追加すると、想定外のプロジェクトへ影響することがあります。私はプロジェクトごとに仮想環境を作り、実行前にPythonの場所を確認します。

python3 -m venv .venv
source .venv/bin/activate
python -c 'import sys; print(sys.executable)'

Python公式ドキュメントでも、venvはプロジェクトごとに分離された環境を作る仕組みとして案内されています。

• Python公式：venv — Creation of virtual environments

Homebrewも、既存の導入先を確認してから公式のInstallationページへ戻ります。Apple Silicon環境では/opt/homebrewが標準の導入先として使われますが、過去の移行や複数ユーザー運用では別経路が残っている場合があります。

• Homebrew公式：Installation

FileVaultがOnでも、復旧確認は別に必要

fdesetup statusの結果はFileVault is On.でした。端末紛失時の保護という点では重要な確認です。

ただし、FileVaultが有効であることと、バックアップから復元できることは別問題です。また、復旧キーの扱いを記事やログへ書くべきではありません。確認結果は「On / Off」だけ残し、キーやアカウント情報は保存しません。

• Apple：FileVaultでMacのデータを保護する

AI開発用MacではAPIキーやOAuthトークンを扱うことがあります。暗号化が有効でも、秘密情報をリポジトリ、記事、スクリーンショット、AIへの入力へ混ぜない運用は別に必要です。

初日に30分だけ使うなら、この順番にする

今回の実測を踏まえ、初日の作業を30分に限定するなら次の順番にします。

0〜5分：現在地を保存する

sw_vers
uname -m
df -h /
command -v git python3 node npm

コマンド結果は公開せず、自分用の作業ログへ保存します。ユーザー名、ホスト名、ボリューム名、秘密情報は除きます。

5〜10分：戻れるか確認する

fdesetup status
tmutil latestbackup

ここでエラーが出たら、新規導入へ進みません。今回の私のMacはここで止める対象になりました。

10〜20分：起動元を確認する

command -v git
command -v python3
command -v node
echo "$PATH" | tr ':' '\n'

同じ目的のツールを複数方式で管理していないか、説明できる状態にします。

20〜30分：用途に必要なものを一つだけ決める

記事生成ならPython、WebアプリならNode.jsというように、最初の用途へ必要な土台だけを選びます。Homebrew、pyenv、uv、Docker、複数エディタを同時に増やしません。

変更前後を1枚で残すチェック表

項目	変更前	変更後	戻し方
OS / CPU	バージョンとarm64/x86_64	原則変更なし	OS更新は別日にする
空き容量	数値を記録	増減を確認	大容量cacheの場所を確認
Python	versionとpath	同じprojectで再確認	仮想環境を削除して作り直す
Node.js	versionとpath	テストを1本実行	元バージョンへ戻す
PATH	区間数と重複	起動元が変わっていない	shell設定の差分を戻す
バックアップ	最新日時を確認	復元対象が見える	変更前snapshotへ戻る

「インストール成功」だけで終わらず、変更後も同じプロジェクトが開くか、テストが通るかまで確認します。

よくある質問

Homebrewは最初に必ず必要ですか？

目的によります。必要なツールの公式手順がHomebrewを使うなら候補になりますが、すでに別の管理方法があるMacへ重ねる前に、command -vで現在の起動元を確認します。

Pythonが動けば、そのままpip installしてよいですか？

先に仮想環境を作るほうが安全です。少なくともcommand -v python3とpython -c 'import sys; print(sys.executable)'を確認し、どのPythonへ入るか分からない状態でグローバル追加しません。

Time Machineが失敗しても、軽い設定変更なら進めてよいですか？

影響範囲を説明できない一括更新や削除は止めます。読み取り確認や、破棄できる新しい仮想環境内の実験に範囲を限定します。まずバックアップ先を再接続し、最新バックアップまたは復元対象を確認します。

launchdの自動化はいつ始めますか？

同じコマンドを手動で再現でき、入力、出力、ログ、停止条件が決まってからです。対話シェルとlaunchdではPATHが同じとは限らないため、実行ファイルは絶対パスで指定し、標準出力と標準エラーの保存先を決めます。

まとめ

今回の実機チェックでは、macOS 26.4、arm64、利用可能248GiB、FileVault Onを確認できました。一方、Time Machineは保存先をマウントできず、PATHにも1区間の重複がありました。

この結果から、私は新しいツールの追加より先に次の2点を残しました。

1. バックアップ先を再接続し、復元可能な状態を確認する
2. Python、Node.js、Gitの起動元を記録してからPATHを整理する

AI開発用Macを壊さず整えるコツは、ツールをたくさん知ることではありません。変更前の状態を説明でき、失敗した時に戻れる順番で一つずつ変えることです。

さらに30日単位でHomebrew、zsh、tmux、Claude Code、launchdの順番を整理したい場合は、Kindle本『副業会社員の Mac 開発環境 30 日』にまとめています。すでに環境が動いていて、今回の7項目だけ確認したい人は、この記事のチェックで十分です。

※リンクには広告属性を付けています。価格、レビュー数、ランキングなどの変動情報は本文では扱いません。

副業会社員の Mac 開発環境 30 日 をKindleで見る