Dropbox 同期のフォルダで Antigravity エージェントに Xcode を任せると、ビルドが時々壊れる理由

.gitignore では守れない（Git と同期は別物）

ここで多くの人がつまずくのが、「.gitignore に書いてあるから大丈夫」という思い込みです。.gitignore は Git のコミット対象を制御するだけで、Dropbox や iCloud の同期デーモンは .gitignore をまったく読みません。Git にとって無視されているディレクトリでも、同期デーモンは律儀にアップロードし続けます。

つまり対策は、Git とは別のレイヤー——同期デーモン自身に「このフォルダは同期しないで」と伝えること——で打つ必要があります。macOS の Dropbox には、ファイル単位で同期から除外する拡張属性が用意されています。

揮発するディレクトリを同期から外す — xattr で印をつける

Dropbox（macOS 版）は、拡張属性 com.dropbox.ignored が 1 になっているファイル・ディレクトリを同期対象から外します。プロジェクトのルートで次のスクリプトを一度走らせると、揮発ディレクトリをまとめて除外できます。

#!/bin/bash
# mark-volatile-ignored.sh — Xcode プロジェクトの揮発ディレクトリを Dropbox 同期から外す
set -euo pipefail
 
# プロジェクトルートで実行する想定
TARGETS=(
  "Pods"
  "build"
  "DerivedData"
  ".swiftpm"
)
 
# *.xcodeproj / *.xcworkspace 内のユーザー固有メタデータも対象に加える
while IFS= read -r -d '' p; do
  TARGETS+=("$p")
done < <(find . -type d \( -name "xcuserdata" -o -name "*.xcuserdatad" \) -print0)
 
for t in "${TARGETS[@]}"; do
  if [ -e "$t" ]; then
    xattr -w com.dropbox.ignored 1 "$t"
    echo "ignored: $t"
  fi
done

設定できたかどうかは、次のコマンドで確認します。1 が返ればそのディレクトリは同期から外れています。

xattr -p com.dropbox.ignored Pods
# => 1

iCloud Drive を使っている場合は仕組みが違い、フォルダ名の末尾に .nosync を付けるか、ビルド出力先を同期対象の外（たとえば ~/Library/Developer/Xcode/DerivedData）に逃がすのが確実です。私はビルド成果物を最初から同期フォルダの外に出す方針にしていますが、CocoaPods の Pods/ のようにプロジェクト直下に置かざるを得ないものは、上の xattr での除外で対処しています。

クリーンビルドで印が消える問題を Run Script で塞ぐ

ここに落とし穴がもう一つあります。xattr の印はディレクトリに付いているので、クリーンビルドでそのディレクトリごと作り直されると、印も一緒に消えます。一度設定して安心していると、次のクリーンビルドの後にまた衝突コピーが復活する、という現象に悩まされます。

対策は、ビルドのたびに印を付け直すことです。Xcode のターゲットに Run Script フェーズを追加し、ビルドの早い段階で除外属性を再適用します。

# Build Phases > Run Script（"Based on dependency analysis" は外す）
# 生成直後のディレクトリに毎回 ignored 属性を貼り直す
for d in "${PODS_ROOT:-$SRCROOT/Pods}" "$SRCROOT/.swiftpm" "$SRCROOT/build"; do
  [ -e "$d" ] && /usr/bin/xattr -w com.dropbox.ignored 1 "$d" 2>/dev/null || true
done

CocoaPods を使っているなら、Podfile の post_install フックに同じ処理を入れておくと、pod install の直後にも確実に印が付きます。

# Podfile
post_install do |installer|
  system("xattr -w com.dropbox.ignored 1 \"#{installer.sandbox.root}\"")
end

こうしておくと、依存を入れ直すたびに Pods/ が同期対象から外れた状態で再生成されるので、pod install 中にロックファイルが衝突コピー化する事故が起きにくくなります。

エージェントを走らせる前に「衝突コピー」を検査する

除外を徹底しても、過去に作られた衝突コピーがフォルダの片隅に残っていることがあります。エージェントがそれを掴むと、また同じ失敗を踏みます。そこで、Antigravity のエージェントにタスクを渡す前に、衝突コピーが一つも無いことを確認するプリフライトを挟みます。スケジュール実行のいちばん最初のステップに置くのが効果的です。

#!/bin/bash
# preflight-no-conflicts.sh — 衝突コピーが残っていたらエージェントを走らせない
set -euo pipefail
 
# Dropbox の衝突コピー / iCloud の重複表現を拾う
HITS=$(find . \
  \( -iname "*conflicted copy*" \
  -o -iname "*コンフリクトしたコピー*" \
  -o -iname "* 2.lock" \
  -o -iname "*.lock.sb-*" \) \
  -not -path "*/.git/*" 2>/dev/null)
 
if [ -n "$HITS" ]; then
  echo "🛑 衝突コピーを検出しました。エージェントを中止します:"
  echo "$HITS"
  exit 1
fi
 
echo "✅ クリーン — エージェント実行を許可"

ポイントは、exit 1 で止めることです。無人実行では「怪しかったら進む」ではなく「怪しかったら止める」を既定値にしておかないと、壊れた状態のままコミットや push まで突き進んでしまいます。私はこの種の自動処理では、判断に迷う状況を見つけたら処理を続行せず、必ず手前で落とすようにしています。失敗を早い段階で表面化させたほうが、後始末がずっと軽く済みます。

何を同期に残し、何を外すか

最後に、線引きの基準を整理しておきます。迷ったときは「別の Mac と共有して意味があるか」「消えても再生成できるか」の二つで判断します。

*.lock を「残す」に入れているのは少し悩ましいところです。依存のバージョン固定情報なので共有したい一方で、ビルド中にいちばん衝突しやすいファイルでもあります。私は Pods/ ごと同期から外し、Podfile.lock はリポジトリのルート（揮発ディレクトリの外）に置いて Git で共有する、という分け方に落ち着きました。同期デーモンとビルドの責任範囲を物理的に分けてしまうのが、いちばん壊れにくい構成だと感じています。

まず一つのアプリで試すなら

複数のアプリを一度に直そうとすると、どの変更が効いたのか分からなくなります。まずは一つのプロジェクトで、次の順に小さく試すことをお勧めします。

1. Pods/ と .swiftpm に xattr -w com.dropbox.ignored 1 を付け、xattr -p で 1 が返ることを確認します。
2. その状態で夜間のエージェント実行を数日観察し、失敗の頻度が下がるかを見ます。ここで効果が確認できてから次へ進みます。
3. 効果が出たら Run Script とプリフライトを足し、クリーンビルドや過去の衝突コピーにも崩されない土台にします。

一つのアプリで手応えが得られたら、同じ手順を他のアプリへ広げていくのが安全です。私自身、最初に綺麗な壁紙アプリ一本で確かめてから、残りのプロジェクトへ同じ設定を展開しました。

クラウド同期は個人開発の強い味方ですが、ビルドという秒単位で状態が変わる作業とは、触る場所を分けてあげる必要があります。同期に任せる領域とビルドに任せる領域の境界を一度きちんと引いておくと、エージェントに安心して夜を任せられるようになります。