2026/07/26Claude Code

導入・運用非エンジニア向け

ClaudeCode｜gitを2台のPCで共有する設計｜衝突とpush失敗を防ぐ

「2台目のPCを用意したら、急にファイルの同期がおかしくなった」「エラーは出ているのに、何が悪いのか分からない」——AIの自動化を24時間動かそうとした人の多くが、この壁にぶつかります。

結論から言うと、原因の大半は git の使い方ではなく役割分担の設計にあります。2台に対等な権限を持たせると必ず衝突します。片方を「使い捨ての作業員」に落とすと、衝突は構造的に起きなくなります。

株式会社Fyveでは、メインのノートPCと24時間稼働のMac miniで1つのリポジトリを共有し、AIの定期実行を毎日回しています。この記事では、私が3ヶ月間気づかないまま踏み抜いていた設計ミスと、その直し方を実測値つきで公開します。

そもそも何が問題なのか — 2台目を持った瞬間に起きること

まず前提を短く整理します。git は「変更履歴を保存して、複数の場所で共有するための仕組み」です。GitHub などの共有置き場を中心に、各PCが自分の手元にコピーを持ちます。

1台だけで使っているうちは何も起きません。問題は2台目からです。両方が同じファイルを別々に書き換えると、git はどちらが正しいか判断できず「コンフリクト（衝突）」として止まります。止まったまま放置すると、片方の変更が共有置き場に届かなくなります。

私の環境で実際に起きた数字がこれです。

2晩連続で自動コミットが失敗し、共有置き場への反映が止まった
気づいた時点で、メインPCにだけ存在する変更が29件
逆に、共有置き場にあってメインPCに届いていない変更が47件

この状態になると、片方で直した設定がもう片方に反映されません。私の場合、AIの動作ルールを書き換えたのに、24時間稼働側は古いルールのまま丸1日動き続けていました。「直したはずなのに直っていない」という、原因の見えにくい不具合になります。

私がやらかした設計ミス — 衝突を避けるルールが衝突を作っていた

当時、私は衝突を防ぐつもりで2つのルールを決めていました。今読み返すと、これが原因そのものです。

メインPCは日中、共有置き場に上げない（他の作業とぶつかるのを避けるため）
常駐機に今すぐ届けたい変更は、ファイルを直接コピーして向こう側で保存する

一見それらしく見えますが、この2つを組み合わせると同じ変更が2つの別々の履歴として登録されます。メインPCに1つ、常駐機に1つ。git から見れば「同じ場所を、2人が別々に書き換えた」——つまり衝突そのものです。

証拠がはっきり出ました。両方の履歴を突き合わせると、記録時刻が分単位で完全に一致するペアが4組ありました。

03:28 — 同じ機能追加が、両方に
04:26 — 同じ表記ルールの修正が、両方に
04:40 — 同じ定義変更が、両方に
05:00 — 同じ削除作業が、両方に

別々の人が偶然、同じ作業を同じ分に行うことはありません。1つの作業が、2台で二重に記録されていたのです。衝突を避けるために作った迂回路が、衝突を製造していました。

読者特典・無料ダウンロードClaude Codeを「素のまま」使うな無料でダウンロード →

正しい設計 — 常駐機を「使い捨ての作業員」にする

解決の考え方はシンプルです。2台を対等にしない。メインPCを唯一の作業場所とし、常駐機は「毎回まっさらな状態から始めて、決められた場所にだけ結果を置いて帰る作業員」にします。

1. 開始時に、共有置き場の最新状態へ強制的に戻す

常駐機の各ジョブは、処理を始める前に必ず共有置き場の最新版を取得し、手元の状態をそれで上書きします。前回の実行が中途半端に終わっていても、設定がずれていても、毎回そこでリセットされる。自己修復する構造です。

この設計にすると、副次的にとても重要な性質が手に入ります。メインPCから常駐機へ何かを届けるための特別な手順が要らなくなるということです。共有置き場にさえ上げておけば、次のジョブの開始時に自動的に届く。私が作っていた「ファイルを直接コピーする」手順は、最初から不要でした。

2. 書き込める場所を1フォルダに限定し、機械的に強制する

常駐機には「このフォルダの中だけに結果を置くこと」というルールを与えます。ただし、ルールを書いておくだけでは守られません。私は保存する対象をそのフォルダだけに限定し、それ以外の変更は保存せずに捨てる処理を、実行スクリプト側に入れました。

指定フォルダ以外への書き込みを検知したら、保存せずに破棄した上で通知します。次回の開始時リセットで消えるので、事故は自動的に巻き戻ります。「守ってください」ではなく「守れない構造にする」のが要点です。

ただしこれには穴があります。この強制は実行スクリプトを通した処理にしか効きません。常駐機に直接ログインして手作業をすれば素通りできてしまう。技術で守れる範囲と、運用で守るしかない範囲の線引きは、あらかじめ意識しておいたほうがいいです。私の場合、この穴から今回の事故が入りました。

3. メイン側は、特別なことをしない

メインPCは普通に作業して、普通に共有置き場へ上げます。上げる前に最新を取り込む、それだけです。日中は上げないといった独自ルールを作ると、今回のように迂回路が生まれて事故ります。

複数の作業を並行させている場合は、設定を2つ入れておくと安全です。取り込み方式を統一するものと、作業途中の変更を自動で一時退避してくれるものです。これで「作業中だから最新を取り込めない」という状況がほぼ消え、日中に上げない理由そのものがなくなります。

常駐機の1サイクル。開始時リセットからジョブ実行、保存範囲の判定と分岐までの流れ

本当の原因は、失敗に気づけないことだった

ここまでが設計の話ですが、私にとって一番の反省は別のところにありました。

今回の失敗は、実は初めてではありませんでした。3ヶ月分の記録を遡って調べたところ、同じ失敗が起きていた日はこれだけありました。

5月4日〜5月21日 — 18日連続で失敗
7月上旬に断続的に3日
直近の2日
合計23日分

18日連続で壊れていたのに、私は気づいていませんでした。理由は単純で、失敗の知らせがPC画面の通知だけだったからです。席を外していれば消えます。あとは記録ファイルに残るだけで、そのファイルを誰も読みません。

届かない通知は、存在しないのと同じです。これは自動化を組む人全員に当てはまります。動いているときは何もしなくていいのが自動化の価値ですが、裏返すと止まったことに気づく仕組みを別に作らないと、止まったまま何ヶ月も過ぎます。

通知を「正常」と「異常」で分ける

私は通知の送り先をチャットツールに変えた上で、2つの部屋に分けました。理由は、うちの常駐機が1日平均12.3本の完了報告を出しているからです。正常な報告が毎日12本流れる場所に警告を混ぜても、確実に埋もれます。

そこで、正常運転の報告は従来の部屋へ、異常だけを新しい部屋へ送るようにしました。普段は1本も通知が来ない部屋を作るのがポイントです。こうすると「鳴った＝異常」が成立し、通知そのものが情報を持ちます。スマホの通知を警告側だけオンにすれば、常時見張る必要がなくなります。

「何日連続で失敗しているか」を添える

もう一段だけ工夫を入れました。最後に成功した時刻を記録しておき、警告を出すときにそこからの経過時間を一緒に送るようにしたのです。

一時的な通信エラーで1回失敗するのと、今回のように詰まって何日も動いていないのとでは、対応の緊急度がまったく違います。24時間・48時間で表現を変えるだけで、この2つを見分けられます。失敗の有無ではなく、失敗の継続時間を見るという発想です。

おまけ — 記録が壊れると、原因究明の手段ごと失われる

調査中にもう1つバグを見つけたので共有します。地味ですが、影響はかなり厄介でした。

常駐機は実行結果を1行ずつ記録ファイルに書いています。長すぎる行を切り詰める処理が入っていたのですが、この切り詰めが文字単位ではなくバイト単位で動いていました。

日本語は1文字が複数バイトでできています。バイト単位で切ると、文字の途中で切れて壊れた文字が残ります。すると記録ファイル全体が「文字として読めないファイル」と判定され、検索コマンドがそのファイルを画像や動画と同じ扱いにして、何も返さなくなります。

私はこれに気づかず、集計コマンドが空を返すのをしばらく不思議に思っていました。エラーすら出ないので、原因にたどり着くまで時間がかかります。記録が壊れると、後から原因を追いかける手段そのものが失われる。自動化のログを日本語で書いている人は、切り詰め処理が文字単位かどうかを一度確認しておくと安全です。

もし今まさに詰まっているなら

すでに分岐してしまっている場合の直し方も書いておきます。手順は3段階です。

まずどれだけ離れているかを確認します。手元にだけある変更と、共有置き場にだけある変更が、それぞれ何件あるかを出します。数字を見ないまま操作すると、消してはいけないものを消します。

次に取り込み方を選びます。git には履歴を並べ直す方式と、合流させる方式の2つがあります。普段は前者で構いませんが、手元の変更が多いときは後者が安全です。前者は変更を1件ずつ順番に適用し直すので、同じ箇所の衝突を何度も解かされます。私の場合は29件のうち7件が同じファイルを触っていたため、後者を選んで1回で解決しました。

最後にどちらを残すか判断します。今回の衝突4件はすべて「同じ作業の二重登録」だったので、内容を見比べて新しい方を採用しました。迷ったら日付ではなく中身の整合性で決めるのが確実です。私のケースでは、片方が参照しているファイル名が実在しないことに気づいて、それが決め手になりました。

なお、自動コミットがそもそも起動しなくなる別系統の原因についても記事にしています。同じ「気づかないうちに止まっている」系のトラブルです。