AntigravityのAIがpackage.jsonの依存バージョンを上書きしてビルドが壊れた時の対処と予防

「ボタンの色を変えてほしい」とだけ依頼したはずなのに、差分を見たら package.json の依存が二十数個まとめて書き換わっていた、という事故にぶつかったのは2026年の春のことでした。^4.2.1 のような pin が外れて全部 latest になっており、npm install を走らせた瞬間に React Native の peer dependency が衝突してビルドが落ちました。私自身、2014年から iOS と Android の個人開発を続けてきて、AdMob 連携で累計5,000万ダウンロードを越えるアプリ群を回していますが、依存の自動書き換えは中でも復旧コストが大きい部類の事故です。

Antigravity の AI が package.json を勝手に触ってしまう現象は、エージェントが「環境を最新の状態に整える」のを善意でやってくれた結果として起こります。エディタや CLI のバグというより、エージェント設計とプロンプトの曖昧さが原因です。ここからは、どんな時に発生し、どう原状回復し、何を仕込めば二度と起きないかを実装ベースで掘り下げていきます。

何が起きているのか — 典型的な3パターン

私が確認した範囲では、AI による依存改変はおおむね次の三系統に分かれます。一つめは「caret/tilde を外して固定版にしてしまう」もので、^18.2.0 を 18.2.0 に書き換えてしまうケースです。これ自体は壊れにくいのですが、後続のセキュリティパッチが入りません。二つめは逆に「固定版を latest に格上げしてしまう」もので、18.2.0 → latest あるいは ^19.0.0 のように major を跨いで上げてしまうため即座に壊れます。三つめが最も厄介で、「peerDependencies の警告を黙らせるために関係ない依存まで連鎖的に書き換える」パターンです。

実際に Antigravity の Manager surface 上でログを追うと、fix the typecheck error のような短い指示でも、Sub-agent が npm install を実行 → 警告が出る → 警告を消すために package.json を書き換える → 別の警告が出る、というループに入ることがあります。

なぜ AI は依存を書き換えてしまうのか

エージェントのシステムプロンプトや学習データ全体が「依存は新しいほうが安全」というバイアスを持っているのが根本要因です。とくに Node エコシステムは Dependabot のような外部ボットによる継続更新が日常になっているため、AI 側も「古い指定を見かけたら上げてあげるのが親切」と判断しやすい傾向があります。

加えて Antigravity のマルチエージェント構成では、ファイル編集権限を持つ Sub-agent が複数並列で動くため、誰かが先に package.json を触ると別の Sub-agent もそれを参照して連鎖的に書き換えに走ります。Plan モードを使わずに自動承認していると、変更の規模に気づく前に commit まで進んでしまうことが多いです。

原状回復の手順

第一手は AI に直させない ことです。Antigravity のチェックポイントを開いて、依存改変の直前まで巻き戻すのが一番安全です。コマンドパレットから "Checkpoints: Restore" を選び、改変直前のスナップショットに戻します。

チェックポイントが流れてしまっている場合は git で復元します。

# まず変更内容を確認
git diff -- package.json package-lock.json pnpm-lock.yaml yarn.lock
 
# package.json と lock だけ戻す（他の編集は残す）
git checkout HEAD -- package.json package-lock.json
# pnpm の場合
git checkout HEAD -- package.json pnpm-lock.yaml
 
# クリーン install で整合性を取り戻す
rm -rf node_modules
npm ci   # あるいは pnpm install --frozen-lockfile

npm ci と --frozen-lockfile は lock を一次資料として扱うコマンドで、package.json との不整合があればエラーで止まります。手で書き換えてしまった後でも、これで「壊れた状態を二度と踏まない」ことが保証できます。

予防策1: AGENTS.md にバージョン編集の禁則を書く

Antigravity は AGENTS.md をプロジェクト直下に置くと、全エージェントが起動時に読み込みます。依存の自動書き換えを禁じる明確な規約を書いておくと、Sub-agent もこれに従うようになります。実際に私が iOS/Android のクライアントワーク用リポジトリで使っている書式を共有しておきます。

# Dependency editing policy
 
- Do NOT modify `package.json` `dependencies`, `devDependencies`, or `peerDependencies`
  without an explicit user instruction that includes the package name and the
  intended version.
- Do NOT run `npm install <pkg>@latest`, `npm update`, `pnpm up`, or
  `yarn upgrade` unless the user has typed those exact words.
- If a typecheck/lint error appears to require a dependency bump, STOP and
  ask the user instead of editing `package.json` yourself.
- The lockfile (`package-lock.json` / `pnpm-lock.yaml` / `yarn.lock`) must
  only be regenerated by `npm ci` / `pnpm install --frozen-lockfile` /
  `yarn install --frozen-lockfile` against the unchanged `package.json`.

この4項目を入れておくだけで、依存の暴走はかなり止まります。私の手元では Plan モードと併用して、運用開始から数十回のリファクタを通して一度も package.json の予期せぬ書き換えが発生していません。

予防策2: コミットフックで package.json 変更を検知する

人間の見落としに備えて、pre-commit で依存差分を検知するフックを入れておくと安心です。husky + 自前スクリプトの構成です。

# .husky/pre-commit
#!/usr/bin/env sh
. "$(dirname -- "$0")/_/husky.sh"
 
CHANGED=$(git diff --cached --name-only | grep -E '^(package\.json|package-lock\.json|pnpm-lock\.yaml|yarn\.lock)$' || true)
 
if [ -n "$CHANGED" ]; then
  echo ""
  echo "⚠️  Dependency files changed:"
  echo "$CHANGED" | sed 's/^/   - /'
  echo ""
  echo "Was this intentional? (y/N)"
  exec < /dev/tty
  read ANSWER
  if [ "$ANSWER" != "y" ] && [ "$ANSWER" != "Y" ]; then
    echo "Aborting commit."
    exit 1
  fi
fi

最低でも commit 直前で人間の目が一度入るため、AI の暴走に気づきます。CI 側でも git diff origin/main -- package.json を確認して、PR description にバンプ意図が書かれていなければ落とすジョブを足すと、レビュー漏れも防げます。

予防策3: lock を一次資料に戻す運用

開発機では npm install、CI では npm ci という運用にしていると、ローカルの一時的な書き換えが lock に流れ込むことがあります。AI に編集を任せている期間は、ローカルでも npm ci を既定にしておくと安全です。

# package.json に script を追加
{
  "scripts": {
    "install:safe": "npm ci",
    "install:add": "echo 'Use: npm install <pkg>@<version> --save-exact'"
  }
}

--save-exact を付けておくと caret が付かない明示的なバージョンで保存されるため、後続の AI 編集による「version range 解釈の揺らぎ」も抑えられます。

さいごに

依存の自動書き換えは、AI の善意が裏目に出る典型的なパターンです。Antigravity のような自律エージェントを本気で使うほど、こうした「修正の越境」をどう抑えるかが運用の主戦場になっていきます。今日の作業終わりに、まず AGENTS.md に依存編集の禁則を一節追加するところから始めてみてください。次にビルドが壊れた瞬間、巻き戻すべきファイルが限定されているだけで復旧時間が一桁変わります。お読みいただきありがとうございました。