父の Mac を開発環境にする準備と、npm から pnpm への移行

地域サービス業のサイトのリポジトリに父のアカウントを入れて、父の Mac から git clone できる状態にしたかった。 GitHub のアカウント作成だけは本人にやってもらい、それ以外は自分の側で片付けるつもりだった。 招待はあっさり通った。 ところが、父のアカウントでログインしてもリポジトリが見えないという連絡が来た。

父のアカウントをコラボレーターに入れる

最初は Chrome DevTools でブラウザを操作してもらう前提で頼んだ。 調べさせたら、gh CLI が repo スコープ付きで認証済みだった。 招待はコマンド1本で済み、ブラウザを開く必要がなかった。

送る前に、渡されたアカウントが実在するかを確認させた。 前夜の遅い時間に作られていて、リポジトリは0件、フォロワーも0。 「今作ったばかり」という本人の話と一致していたので、admin 権限で招待を送った。 状態を見ると承認済みで、保留中の招待リストは空だった。

クローンさせる前に、ローカルに push していないコミットが6件残っているのが分かった。 このままでは父の Mac に古い状態が落ちてくる。 push させてから先へ進んだ。

父のアカウントでリポジトリが見えない

父のアカウントでログインしたのにリポジトリが見えない、と連絡が来た。 コラボレーターは見えない仕様だったろうか、と自分でも一瞬迷った。 API で見せてもらうと権限は付いている。 保留中の招待は空、permission は admin のまま。

権限ではなく画面の話だった。 父のアカウントでログイン中の Chrome を確認させたら、開いていたのはプロフィールページだった。 プロフィールには自分が所有するリポジトリしか並ばない。 リポジトリの URL を直接開かせると 404 ではなく中身が出て、ダッシュボードからも辿れた。

権限を付けたのに見えないと言われたら、まず権限を疑ってしまう。 今回は権限が正しくて、見ている画面が違っていた。

依存パッケージがゼロのリポジトリを pnpm へ移す

同じリポジトリの npm を pnpm に替えてもらった。 中を見せてもらうと、依存パッケージが1つも入っていない。 外部を使うのは npx wrangler deploy の1箇所だけで、移行の実体はほぼ表記の置き換えだった。

先に引っかかったのは改行だった。 作業ツリーの全ファイルが CRLF になっていた。 .gitattributes は入っているのに、再チェックアウトしていないので作業ツリーには効いていない。 Write は LF で書き戻してしまうので、Edit だけで直させた。 あわせて「.gitattributes が origin にない」という報告も上がってきた。 これは確認コマンドの誤りで、git ls-tree で見れば origin のルート直下にある。

実害のある修正が1つあった。 下書き同期スクリプトの除外リストが package-lock.json 決め打ちで、pnpm の lock ファイルが本番の dist/ に混入する。 ここは実際にビルドまで走らせて、混入しないところまで確かめさせた。

コミットのところで学習ゲートが止まったので、スキップするよう指示した。 --no-verify ではなく LEARN_SKIP=1 に理由を残す経路で通させた。

origin に入っていた見知らぬコミット

push の前に、origin に手元が持っていないコミットが1件あることが分かった。 force push はさせず、先に中身を調べさせた。 父自身のコミットだった。 その日の朝に、電話番号のリンクへ aria-label を足すアクセシビリティ修正を入れて push している。 クローンから push まで権限が実際に機能していることを、こちらが手順書を書き上げるより先に父自身が示してくれた。

リベースして履歴を一直線にしてから push させた。 その直後に下書きチェックが EXIT=1 で落ちた。 原因は sitemap.xml の lastmod で、父の編集に追随していないだけだった。 lastmod の取得元がファイルの更新時刻なら、手元で再生成すると誤った日付が入る。 そこを先に調べさせたら git 由来だったので、再生成しても差分は日付1行だけで済んだ。

pnpm のバージョンを上げるか

スクリプトを替えたなら、リポジトリのドキュメント側もそれに合っているのか気になった。 洗わせたら、別セッションが既に追随させていた。 記述と package.json の実体まで突き合わせさせて、食い違いはなかった。

そのうえで、pnpm も 11.21.0 に上げたほうがいいのではないかと聞いた。 父の Mac には Homebrew の node が入るので、Node のバージョン条件は両機とも満たす。 あとは実測するしかないので、グローバルの pnpm は動かさず、新しいバージョンを一時的に取ってきて試させた。

ここで corepack が想定と違う動きをした。 pnpm 11 を取得したうえで、「このプロジェクトは 10.33.2 指定だ」と言って実行を拒否する。 つまり packageManager の1行が、どのマシンで叩いても実効バージョンを決めている。 父の Mac で何が動くかは、この1行の話だった。

一時的に書き換えて実測させたら、install は「Already up to date」で lockfile の変換すら要らなかった。 プロジェクトのスクリプト4本も通った。 デプロイに使う pnpm dlx は pnpm 11 でサプライチェーン保護が効くので、実行はせずバージョン取得だけで確かめさせた。 上げると決めて push させた。 グローバルは 10.33.2 のまま、プロジェクト内だけ 11.21.0 に自動で切り替わることも確認した。

以前の計画書をリポジトリの手順書に起こす

父の Mac をいじり始める前に、そのための計画書を以前作った覚えがあった。 探させたら memo/2026-08-10/ に残っていた。 6万字ほどあり、Codex のレビューを4回反映した状態で止まっていた。 判断が必要な5件は未回答のままだった。

これをリポジトリ側の新規ドキュメントとして起こさせた。 AI が読む AGENTS.md、父が最初に開く README.md、操作の手順書、一括インストーラ、チェックリスト、Mac のセットアップ手順を合わせて11ファイルになった。 推測で書かれると父の隣で詰まるので、CLI の実際の操作を確認してから書くよう指示した。

macOS の bash が3.2であることも効いた。 手元の bash 5.x では通るのに、向こうでは空配列が unbound variable で落ちる。 配列を使わない形に直させた。

途中で HEAD が進んでいた。 別セッションの pnpm 移行が入ったので、npm 時点の package.json を前提に書いた記述を現状へ合わせ直させた。

別セッションと父の Mac が同じファイルを触っていた

同じリポジトリを別セッションでも触っていたので、push が重複しないよう待ってもらう場面があった。 待っている間に向こうのコミットが入り、こちらは残っていた sitemap.xml の修正だけを乗せた。

あとで実際に push が弾かれた。 origin を見ると、別セッションが同じドキュメント群を別の CLI 向けに書き換えていた。 しかも Author が父のアカウントで、父の Mac の側で作業が進んでいた。 デスクトップに置くつもりだった .command 4つは廃止されている。

壊さないよう、先に内容を把握させてから進めた。 向こうの方針変更を尊重して、手元のローカルコミットは捨てさせ、直したい事実の誤りだけを最新版に当て直させた。 git reset は拒否されたのでマージで進み、競合はチェックリストの Phase 0 だけだった。 origin 側、つまり父の Mac の実態を土台にして、こちらの追記を足して統合した。

父の Mac に入れるものを確かめる

途中で止まっていた判断が2件片付いた。 どちらも父の Mac に何を入れるかに関わる話だったので、インストーラの中身にも反映させた。

インストールに使う cask 名が正しいかまで確認させた。 父の隣で失敗させたくない。

生成AIサービスの契約も見た。 個人向けの契約になっていたので、家族向けに切り替えた。

手順書に書いた断定が間違っていた

チェックリストを読み返していて、自分の書いた記述に引っかかった。 ある操作について「その場でしか取得できない」と断定していた。 確かめさせたら不正確で、あとからでも取り直せるものだった。 訂正してドキュメントを直させた。

積み残しの棚卸し

両方のセッションで積み残しを聞いた。 記憶ではなく実際の状態を見てから答えてくるので、そこは安心して聞ける。

一方では、自分の作業で作ってしまった不整合が1件出てきた。 報告の前に直して push させた。

もう一方では、README に書いたドメインが実際の本番と違っていた。 本番の表示を確認しようとしたら、curl は接続に失敗し、ブラウザでも名前が解決できなかった。 sitemap から実際のドメインを見たら、ハイフンの有無が違っていた。 README 側の書き間違いだった。 本番そのものは正常に動いていて、父の aria-label 修正はすでにデプロイ済みだった。

オートモードで承認を求められる回数が増えた件

別件で、オートモードの挙動が変わって承認ボタンを押す回数が増えていた。 設定が壊れたのかと思って見てもらったが、壊れてはいなかった。 Claude Code 2.1.232 の Windows 限定のリグレッションで、ディレクトリを移動してからコマンドを続ける形が毎回手動承認を要求するようになっていた。 2.1.233 で修正済みで、この機は当日の朝に更新されている。 ただし更新は起動済みのセッションには効かない。 朝の更新より前に開いたターミナルが、古いバージョンのまま動いていた。

学んだこと

• 権限を付けたのに見えないと言われたら、権限より先に「どの画面を見ているか」を確かめたほうが早い。GitHub のプロフィールページには自分が所有するリポジトリしか並ばない
• packageManager の1行が、どのマシンで叩いても実効バージョンを決める。corepack がその固定を厳格に強制するので、複数マシンで揃えたいならここを直せば済む
• 依存ゼロのリポジトリでも、移行の実害は lock ファイルの扱いに出た。除外リストがファイル名決め打ちだと本番の生成物に混入する
• 家族に渡す手順書は、推測で書くと隣で詰まる。cask 名もコマンドも実物で確認してから書く
• 同じリポジトリを複数のセッションで触るときは、push が弾かれてから慌てても遅い。相手が何をどの方針で書き換えたかを読むほうが、force push で押し切るより安い