廣川政樹です。アプリ開発を中心に複数のサービスを個人で運営しています。Antigravity を使い始めて変わった一番大きなことは、「夜間に動いてくれる相棒ができた」という感覚です。寝ている間にきちんと働き、朝起きたら実装が進んでいたり、レビュー候補が用意されていたりします。これは個人開発の体感を変える出来事でした。
ただ、夜間運用は油断するとあっさり破綻します。曖昧なタスクを投げて寝た翌朝、見当違いの大きな変更が積み上がっていた、ということは私自身も何度か経験しました。Antigravity を「夜のもう1人」として迎え入れるには、人間と分担するつもりで境界線をきちんと引く必要があります。
ここでは私が個人開発でこのスタイルを成立させるために整えてきた運用モデルを共有します。Antigravity 公式のドキュメントには書かれていない、「夜間運用のリアル」の話です。
なぜ「夜のもう1人」という比喩が役立つのか
Antigravity をエージェント機能の集合として見ると、設定項目が多くて圧倒されます。私はあるときから視点を変えて、「人を雇うつもりで設計する」と決めました。具体的には、Antigravity に夜勤シフトを任せる新人エンジニアだとして、何を任せるか、どこまで任せるかを線引きするのです。
この比喩が便利なのは、判断のたびに「もしこれが本当の人間だったら」と置き換えられる点にあります。人間の夜勤に対していきなり本番デプロイ権限を渡す上司はいません。同じように、Antigravity にも段階的に責任を渡していくのが自然です。私は最初の数週間、Antigravity に書かせるのはブランチへのコミットのみで、main への push は朝の私が責任を持って実行する、というルールで運用していました。
「夜のもう1人」という言葉に置き換えるだけで、Antigravity の運用判断が驚くほど直感的になります。技術的な議論よりも、まずこの視点を持つことを強くお勧めします。
夜間に渡せるタスク・渡せないタスクの境界線
私が半年ほど運用してきて見えた、夜間に Antigravity に渡せるタスクの輪郭はだいたい次のような形です。
夜間に渡してよい:
- 仕様が言語で十分に書き切れているタスク
- 失敗しても元に戻すコストが低いタスク
- 観察可能な完了条件があるタスク（テストが通る・特定のファイルが生成される など）
夜間に渡すべきでないタスク:
- 仕様が「だいたいこんな感じ」止まりのタスク
- 影響範囲が広いリファクタリング
- 本番データに副作用が出るタスク
ここで重要なのは、「複雑だから渡せない」のではなく「曖昧だから渡せない」という点です。複雑でも、入口と出口が言葉で固定できているタスクなら、Antigravity は夜間でも安定して進めてくれます。逆に、難易度が低くても「やってみてうまくいったら、いい感じに整えておいて」のような指示は、ほぼ確実に翌朝の手戻りにつながります。
夜間タスクを設計する時、私は次の質問を必ず自分に問います。
このタスクが完了したかどうかを、私が朝起きて30秒で判定できる完了条件があるか?
この質問に「はい」と即答できないなら、そのタスクは夜間に渡してはいけません。
タスク指示書の最小構成
Antigravity に夜間タスクを渡す時、私は以下の最小構成で「指示書」を書いています。
## 目的
何のためにこのタスクをやるのか（1〜2行）
## 完了条件
- 朝起きて30秒で判定できる、観察可能な条件
- 例: 特定のテストが通る / 特定のファイルが生成されている
## 触ってよいスコープ
- 触ってよいディレクトリ・ファイル
- 触ってはいけない領域（本番コード・課金・認証など）
## 失敗した時の振る舞い
- 中途半端な状態で止めず、ブランチを作って退避してから停止する
- main / production には触らない
## 参照すべきコンテキスト
- 関連ドキュメント・既存実装の場所
たった5項目ですが、ここを丁寧に書くと夜間運用が一気に安定します。とくに「触ってよいスコープ」と「失敗した時の振る舞い」は明示しておくと、翌朝の私が驚かされる確率が大きく減ります。
私は最初、ここをサボって「やっておいて」と短く書いていました。それで見当違いな改修が積み上がっていた経験から、5項目テンプレに行き着きました。短くてもこの5項目を埋める方が、結局は速いです。
「中断点」をあらかじめ決めておく
夜間運用で意外と重要なのが、中断点をあらかじめ決めておくことです。Antigravity は完走しようとして頑張ってくれますが、長時間走らせると判断の精度が落ちる場面もあります。私は次のような中断点を仕込んでおくようにしています。
- ファイル変更が30個を超えたら、そこまでで一度コミットして停止
- 同じテストを3回以上失敗したら、そこで停止してログを残す
- スコープ外のディレクトリに触ろうとしたら、即停止
この中断点は Antigravity への指示文に明示するか、エージェント側のルール設定に組み込みます。「いい感じに頑張って」ではなく、「ここを越えたら止まれ」と明示する方が、結果として安定して進みます。
これは人間の新人にも近い話です。「困ったら相談して」と言うより、「この閾値を越えたら必ず相談して」と決めておく方が、夜勤シフトはうまく回ります。
朝のレビューを5分以内に終わらせる仕組み
夜間運用を継続するには、朝のレビューが軽くなければいけません。レビューに毎朝30分かかると、運用が続きません。私は次のようにして、5分以内に「何が終わって何がリスクか」を判定できる仕組みを作っています。
朝に最初に開くのは、Antigravity が出した作業ログとブランチの diff だけです。コードを直接読み始める前に、次の3つを見ます。
- 完了条件は満たされているか（指示書に書いた30秒判定の条件）
- 触ったファイルは「触ってよいスコープ」の中に収まっているか
- 中断点に引っかかった記録があるか
この3点が問題なければ、私は内容を細かく読まずに次のステップへ進めます。逆にどれかが外れていたら、その時点でブランチを破棄するか、自分で手動で修正する判断をします。
「コードを読んでから判断する」のではなく、「メタ情報で先に判断する」という順番が、朝のレビュー時間を明確に短くします。これは Antigravity を信用していないからではなく、信用するかどうかを毎朝ゼロから検証しないための仕組みです。
エージェントに任せないラインを言語化する
最後に、Antigravity を長く相棒として使い続けるために大切なのが、「エージェントに任せないライン」を言語化することです。私の場合は次のようなラインを引いています。
- プロダクトの方向性に関わる判断（料金・対象ユーザー・コンセプト）
- 課金・認証・個人情報を扱うコードのレビュー
- リリース判断と本番デプロイのトリガー
- ドメイン知識のドキュメント化（自分の頭で言語化することに価値がある）
これらは効率を優先すれば Antigravity に任せられそうな領域もありますが、私はあえて任せないと決めています。理由は、これらを自分で考え続けることが、個人開発者としての「目」を維持するために必要だと思うからです。Antigravity を相棒にしながら、相棒に飲まれない距離感を持つ。これが長期運用の鍵です。
逆に言えば、ここに含まれない領域については遠慮なく Antigravity に任せます。境界線がはっきりしていれば、任せる側にも任せられる側にも安心感が生まれます。これは人間の同僚との関係構築と何も変わりません。
半年運用してみて何が変わったか
このスタイルを半年続けて変わったのは、開発のリズムです。日中は設計と方向性の判断に集中し、夜間は Antigravity が手を動かす。朝は短いレビューで合意点を確認して、また日中の判断に戻る。このリズムが定着してから、個人開発でありながら「複数のサービスを並行して進められる」感覚が現実味を帯びてきました。
もうひとつ変わったのは、自分が「何を作りたいのか」をより頻繁に言語化するようになったことです。Antigravity に夜のタスクを渡すには指示書を書く必要があり、指示書を書くには目的をはっきりさせる必要があります。この作業を毎日続けると、自分の作品に対する解像度が上がっていきます。これは予期していなかった副産物でした。
Antigravity Lab では、このような「個人開発者の運用モデル」をより具体的なケーススタディと共に深掘りするプレミアム記事を継続して公開しています。広告のないクリーンな読書環境と、サイト運営費（Cloudflare・Stripe・各種ドメイン）への支援を兼ねていただける形になっています。今回の記事が役に立ったと感じていただけたら、記事末尾のメンバーシップ案内をのぞいてみてください。続きを書く力になります。