開発機をWindowsからMacに移行して、実際に詰まった3つのポイント

2026-08-22 ／ AI、開発環境

普段の開発機をWindowsからMac(Mac mini)に切り替える作業を進めています。

「開発はMacで、これまで通り動いているスケジュール処理や継続データはWindows側に残す」という役割分担にしたのですが、実際に切り替えを進めてみると、想定していなかったところで何度か手が止まりました。今日はその中でも印象に残った3点を振り返ります。

① 「AIが代わりにやってくれる」には権限の壁がある

MacとWindowsの間でファイルをやり取りできるようにSSH接続を設定したのですが、ここで最初につまずきました。

Windows側でSSHサーバーを有効にする作業(サービスの起動、ファイアウォールの許可、認証鍵の登録)は、UAC(ユーザーアカウント制御)で管理者権限が分離されている状態だと、AIエージェントからは実行できないことがわかりました。「システム設定の変更に該当する操作は自分ではやらない」という安全側の設計のおかげでもあるのですが、結果として、

AIが読み取り専用で現状を確認する(サービスが無い、ルールが無い、鍵が無い、を確認)
実行すべきコマンドをAIが用意する
管理者権限のPowerShellは自分で開いて実行する
実行結果をAIに渡して、設定が正しく反映されたかを確認してもらう

という「AIが下ごしらえして、権限が要る部分だけ自分が引き取る」進め方に落ち着きました。「AIに任せれば全部終わる」と思っていた部分だったので、地味に時間を食いました。逆に言えば、この境界線さえ最初に把握しておけば、以降の同種の作業はスムーズになります。

② 「気づいたら散らかっていた」複数リポジトリの実態

いざ移行前の棚卸しをしてみると、開発中のリポジトリが数十個、しかもその中のGitワークツリー(作業用の複製)だけで70件以上登録されていることが判明しました。

さらに、

一部のリポジトリはコミットしたのにpushし忘れている
一部はリモートより進んでいて、しかも作業途中のファイルが残ったまま(dirty)
一部は逆にリモートより遅れている

という「思ったよりバラバラ」な状態が可視化されました。これ自体は致命的な問題ではないのですが、移行のタイミングで棚卸しをして初めて実態に気づけたというのが正直なところです。日々の開発の中では「今動いてるからいいや」で流してしまいがちな部分なので、移行のような節目がないと見えてこない類のズレでした。

③ 「動いているデータの二重書き込み」という一番怖いリスク

3つ目は、実害こそなかったものの一番ヒヤッとした点です。

継続的にデータを貯め続けているプロジェクト(価格推移トラッキングのようなもの)は、DB代わりのファイル(SQLiteなど)がWindows側のリポジトリの中に直接置かれていました。ここで最初に考えていたのは「Macでも同じように動かせば楽そう」という発想だったのですが、これは危険なパターンだと気づきました。

もしMac側でも同じスクリプトを実行してしまうと、同じデータファイルに2箇所から書き込みが発生し、データが壊れる可能性があります。これを避けるため、今回の移行では明確なルールを決めました。

「今動いているデータ処理」はWindows側の単独オーナーのまま残す
Mac側は「完了したデータのコピー(スナップショット)」だけを取りに行く読み取り専用の立場にする
Mac側で新しく何かを作る場合も、書き込み先は変えず、結果だけを送り返す設計にする

「開発環境を移す」と「データの書き込み場所を移す」は全く別の話だと、身をもって学んだ形です。

おまけ：この記事のネタ元自体も「二重化」していた

余談ですが、この記事を書くために作業ログを振り返っていたら、セッションの記録の仕組み自体が2種類同時に存在していて、まだ統合されていないことに気づきました。ひとつは自動でバックグラウンド収集される仕組み、もうひとつは自分で「保存して」と指示して溜めていく仕組みです。

これはまさに②で書いた「複数の仕組みが並行して増えていく」パターンそのもので、記事を書きながら自分自身の環境の散らかりに気づく、というちょっと面白い体験でした。近いうちにこちらも整理しようと思います。

まとめ

権限が絡む作業は「AIが下ごしらえ→人間が引き取る」の境界線を先に把握しておくとスムーズ
複数リポジトリを日常的に触っていると、棚卸しのタイミングでしか気づけない散らかりが必ずある
継続稼働中のデータは「開発環境の移行」と切り離して、書き込み元を絶対に増やさない

環境移行は単なる引っ越し作業ではなく、普段は見えていなかった自分の開発環境の実態を棚卸しする良い機会でもあるな、というのが今回の一番の学びでした。