Antigravity で毎回環境づくりに迷っていたので、最初に入れる標準 repo を作った話

AI エージェントに開発を手伝ってもらうようになってから、
コードを書くこと自体よりも、「最初にどういう環境で始めるか」のほうが大事だと感じるようになりました。

自分の場合、Antigravity で開発を回していると、毎回だいたい同じところでつまずいていました。

• 最初に何を読ませるべきかが毎回ぶれる
• グローバルな知識と、案件固有の文脈が混ざる
• upstream 由来の資産をどこまで取り込むか曖昧になる
• 今の環境が本当に正しいか確認する方法が弱い
• 気づくと source repo と実案件の workspace の境界が曖昧になる

最初は「その都度ちゃんと気をつければいいか」と思っていたのですが、
AI 相手の開発は、人間が気をつけるだけではだんだん破綻してきます。

そこで、Antigravity で新しい開発を始めるときに、最初に必ず入れるための標準 repo として
Antigravity_Default_Settings を作りました。

https://github.com/yosuku0/Antigravity_Default_Settings

この記事では、

• なぜ作ったのか
• どういう思想で作ったのか
• 実際に使ってみてどうだったか

を、体験ベースでまとめます。

いちばん困っていたのは「環境が曖昧なまま進むこと」だった

AI エージェント開発をやっていて怖いのは、明らかなエラーよりも、
それっぽく進んでしまうことです。

たとえば、

• README はそれっぽい
• スクリプトも一応ある
• 実行するとなんとなく動く
• でも source of truth がどこか曖昧
• しかも別案件の文脈が混ざっている

みたいな状態です。

こうなると、あとから見返したときに

• どこまでがベース環境なのか
• どこからが案件固有の変更なのか
• upstream 由来のものを何で上書きしたのか
• 今の runtime が正しいのか

が、すぐに分からなくなります。

人間だけの開発なら、多少の曖昧さは記憶で補えることもあります。
でも AI を絡めると、その曖昧さがそのままドリフトの温床になります。

なので今回は、まず 「AI が迷いにくい最初の作業空間」 を作ることを優先しました。

---

何を作ったのか

Antigravity_Default_Settings は、
Antigravity で開発を始めるときに最初に取り込む前提の bootstrap / basecamp repo です。

自分の中では、これは「実案件そのもの」ではなく、
開発を始めるためのベースキャンプです。

役割としてはこんなイメージです。

• 環境の初期化をする
• upstream 由来の資産を取り込む
• runtime の active レイヤに昇格する
• 最後に検証して「今の環境が正しいか」を見る

つまり、「何かを作る repo」というより、
何かを安全に作り始めるための repo です。

---

設計でいちばん大事にしたこと

今回かなり意識したのは、generator と consumer を分けることでした。

generator

Antigravity_Default_Settings 側。
ここはベースキャンプで、基本的には read-only の信頼基盤として扱います。

consumer

実際に開発する側の workspace。
新しいプロジェクトは、ここで始めます。

この分離をちゃんとやるようになってから、かなり安定しました。

以前は、source repo の中でそのまま色々試したくなってしまい、
結果として

• ベースの repo を触っているのか
• 実案件のコードを触っているのか

が混ざりやすかったです。

でも一度、

• basecamp は basecamp
• 実装は consumer 側
• 異常系の再現も consumer 側のダミー環境

とルールを決めると、急に見通しが良くなりました。

---

実際の導入フロー

基本的には、まずこの repo を clone して、初期化・promote・validate までやります。

git clone https://github.com/yosuku0/Antigravity_Default_Settings.git C:\Dev\AntigravityLab
cd C:\Dev\AntigravityLab

.\scripts\initial-setup.ps1
.\scripts\promote-runtime-assets.ps1
.\scripts\validate-runtime.ps1

この流れを固定することで、
「とりあえず始める」がかなり減りました。

個人的には、validate-runtime.ps1 があるのが大きかったです。
AI エージェント開発って、雰囲気で進めると本当に危ないので、
最後にちゃんと検証できる出口があるだけで安心感が全然違います。

---

新規開発はどう始めるか

新しい開発は、この repo の中にそのまま書き足すのではなく、
consumer workspace 側で別プロジェクトとして始めます。

たとえばテンプレートを使って始めるなら、こんな感じです。

Copy-Item "projects\_template" "projects\my-new-project" -Recurse
notepad projects\my-new-project\.agent\project-context.md

ただ、実際の運用としては、
今後は Antigravity_Default_Settings を導入してから、別の consumer workspace で開発する
という流れに寄せていくつもりです。

今回この方針が固まったのは大きかったです。

---

実際に consumer 側で試してみた

ベースキャンプとして本当に使えるかを確かめるために、
consumer 側で hello-antigravity-dashboard という小さい題材を作って検証しました。

やったことはシンプルで、
source repo 側の validate-runtime.ps1 -Json を consumer 側から読み、
run-once の CLI ダッシュボードとして表示する、というものです。

でも、この題材がちょうどよかったです。

なぜなら、

• source repo を read-only のまま使えるか
• consumer 側だけで実装できるか
• 異常系を source repo を壊さずに検証できるか

を全部確認できたからです。

結果として、正常系だけでなく異常系も含めた 9 シナリオを検証して、
source repo 側は before / after で drift なし、というところまで確認できました。

ここまでできたことで、ようやく
**「この repo は本当に開発の起点として使える」**と判断できました。

---

作ってよかったポイント

今回やってみて、よかったのは次のあたりです。

1. AI に読ませる前提を揃えやすくなった

毎回ゼロから説明しなくてよくなりました。
最初に読むべき構成や文脈がある程度決まっているだけで、かなり安定します。

2. source repo を壊しにくくなった

これはかなり大きいです。
一度 source repo に手を入れ始めると、あとで境界がぐちゃぐちゃになりやすいので、
read-only basecamp という考え方は効きました。

3. 「検証できる」が強い

AI と一緒に開発していると、
「たぶん大丈夫」ではなく、確認できる仕組みがあることが大事です。
validate-runtime.ps1 があるだけでもかなり違いました。

4. 失敗の再現場所が決まった

異常系は consumer 側の test-scenarios で再現する、と決めたことで、
source repo を守りながら検証できるようになりました。

もちろん、まだ完璧ではない

この repo は Milestone 1 としては完成扱いにしましたが、
改善余地がなくなったわけではありません。

たとえば backlog としては、次のようなものがあります。

• initial-setup.ps1 の上書き保護強化
• .gitignore の BOM 除去
• PowerShell のエラー処理統一
• promote 処理の rollback-safe 強化
• ドキュメントの source of truth 一本化
• git 外部コマンドの終了コード検証

なので位置づけとしては、

今すぐ使えるベースキャンプにはなった。
でも、今後さらに hardening していく余地はある。

という感じです。

自分としては、この「完成したけど改善余地はある」という状態を
ちゃんと backlog として分離できたのも良かったと思っています。

今後の運用方針

少なくとも自分の今後の Antigravity 開発では、
まず最初にこの repo を導入して、それから各案件を始める方針でいきます。

つまり、流れとしてはこうです。

1. Antigravity_Default_Settings を導入する
2. 初期化する
3. promote する
4. validate する
5. その上で consumer 側の新しい開発を始める

この順番を固定するだけでも、かなり事故は減るはずです。

まとめ

AI エージェント開発をしていて感じるのは、
コード生成そのものより、「どんな環境で始めるか」のほうが効くことが多い、ということです。

Antigravity_Default_Settings は、そのための repo として作りました。

• 毎回の初期状態を揃える
• source repo と consumer を分離する
• runtime を promote する
• validate してから進む
• 異常系は consumer 側で再現する

この流れを先に作っておくと、
AI と一緒に進める開発がかなり安定します。

同じように、

• AI 開発の初期文脈がぶれやすい
• 環境の再現性に悩んでいる
• source と project の境界が曖昧になりやすい

という人には、こういう「最初に入れる repo」を先に作るのはかなりおすすめです。

リポジトリはこちらです。