Claude Code の設定一式を Windows と Mac の2台で共有する移行作業

セッションを開いたら、起動時のフックが失敗したという行が出た。

参照先は /Users/ から始まるシェルスクリプトで、Mac のパスだった。 Windows にそのファイルは無い。 非ブロッキングの失敗なので実害はないが、毎朝これを見るのは落ち着かない。

何かの計画を作った覚えがあったので、計画書と引き継ぎメモを探させた。 今朝のエラーは新しい問題ではなかった。 前日に書かせた計画書の中に、判断待ちの項目としてそのまま載っていた。

実装より先に決めるべきだったこと

積み残しを、記憶ではなく実測ベースでリストにさせた。

本丸は、~/.claude を丸ごと git で持っている dotclaude リポジトリの2台運用対応だった。 ここが止まると他が進まない。 そして計画は、判断4件が決まるまで実装に入らない形で組まれていた。

判断はターミナルの選択肢ではなく、計画書に埋め込んだ決裁フォームで答えた。 4件とも推奨案を選び、コメントは付けなかった。

一般的なやり方を先に調べる

回答を返したあとで、ひとつ引っかかった。 Mac と Windows で同じ設定を共有している人は、世の中にもそれなりにいるはずだ。 自分の計画だけで走り出す前に、一般的なやり方を調べさせた。

返ってきた結論は、自分の計画が世の中の標準的なやり方とほぼ同型だ、というものだった。 主流は1つのファイルを条件分岐させる形ではなく、マシンごとに別ファイルを持って配布時に選ぶ形だった。 今回の計画も OS ごとにディレクトリを分ける形なので、そこは一致していた。 ただし Claude Code 固有の事情があり、既製の dotfiles 管理ツールがそのままはハマらない部分が残る。

方針は変わらなかった。 それでも、調べさせてよかったと思っている。 自分の設計が世の中から外れていないと分かった時点で、以降の判断で迷わなくなった。

走り出す直前に、1点だけズレが見つかった。 Mac のパスを一掃できたかどうかは、grep の件数で判定する受け入れ基準にしていた。 そこに、残すべき1行まで巻き込まれていた。 その1行は、以前 ~/.claude を丸ごと失った事故の再発防止策の一部だった。 消す対象と残す対象を分け、フックのほうは両 OS で動くように書き直す方針に変えた。

移行前の復元点

移行そのものに手を付ける前に、まず現状をコミットさせた。

その前に自動同期のタスクを止めさせた。 06:46 に、移行計画と判断への回答、関連する記録をまとめて1つの復元点にした。

コミットの直前、別のプロセスが同じリポジトリへ大量のファイルを書いているのが見えた。 朝のパイプラインが並行して動いていた。 そちらは巻き込まず、自分の変更だけを切り分けてコミットさせた。

学習ゲートが止めてきたが、コードは1行も変えていない。 着手前のスナップショットなので、スキップして通すよう指示した。

画面設定で決めた項目と保留にした項目

別のセッションでは、前日から持ち越していた画面設定の詰めをやった。

進捗を記憶で更新させると、済んだものも未了のまま残る。 実機で測り直させたら、6項目のうち2項目は既に解決していた。

夜間の時間指定は保留にした。 この Windows 機を夜に触ることがほとんどないので、決めても使わない。 縦置きにしているもう1枚も、今は何もしない。

残ったのは輝度だけだった。 75 が適正かどうかは、設定値を眺めても決まらない。 体感で申告するしかないので、70 に下げさせ、読み戻して 70 が返ることまで確認させた。

保留にした3件は、ドキュメントに「再検出しても蒸し返さない」と書かせた。 書いておかないと、翌朝の未了リストにまた並ぶ。 07:20 と 07:21 のコミットで、作業記録と引き継ぎメモの両方をクローズ済みに更新した。

コミット対象の切り出し

コミットを頼むときに、他のファイルを巻き込まないよう明示的に伝えた。

実際、対象の2ファイルは別のセッションが先にコミットしていて、手元は変更が乗った状態だった。 差分が自分の編集分だけであることを確認させてから、2つに分けてコミットさせた。

セッションを何本も同時に走らせている日は、コミットの範囲を放っておくと広がる。 「対象だけ」と一言添える手間のほうが、あとから剥がすより軽い。

移行後に残した3件

08:22 に移行完了の記録をコミットし、翌日へ持ち越す未了事項を3件残した。

終わったかどうかを確認したあと、明日やる分を未了事項として書き残すよう伝えた。 会話の中で確認しただけで終えると、翌朝には何も残らない。

振り返り

• 判断が決まるまで実装に入らない形で計画を組ませておくと、走り出してからの手戻りが出ない。今回は4件とも推奨案のまま通った
• 一般的なやり方を調べても方針は変わらなかった。それでも、変わらないと確認するための調査には意味があった
• 保留は「保留」と書いて残させる。書かないと翌朝の未了リストに戻ってくる
• 進捗は実測で更新させる。6項目のうち2項目は、測るまで未了のままだった
• 並行セッションが多い日は、コミットの対象を毎回こちらから切る