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