1 週間という単位で開発を捉え直したら、Antigravity の使い方が変わった
私はアプリ開発を本業にしながら、世界各地でアート活動も並行しています。ですので、毎週同じ時間にコードを書くという生活ではなく、移動の合間や撮影の合間にまとまった作業時間を確保する、というスタイルで動いています。
Antigravity を導入してしばらくは、毎日「今日はどこまで進められるか」だけを見て使っていました。しかし、それでは Agent モードの真価が発揮できないことに、3 ヶ月ほど運用してから気づきました。Antigravity は 1 日単位ではなく、1 週間単位で設計すると一気に効率が上がるのです。
ここでは私自身が今運用している週次リズムの設計と、その中で Antigravity をどう使い分けているかを共有します。同じように個人で複数のプロジェクトや活動を抱えている方の参考になれば嬉しいです。
週次リズムの基本構造 — 4 種類の時間帯を設ける
私の 1 週間は、次の 4 種類の時間帯に分けられます。
- 設計時間（月曜午前・木曜午前）
- 集中実装時間（火・水・木・金の午前または午後のまとまった 3〜4 時間）
- 検証・微調整時間（毎日の夕方 1〜2 時間）
- 非同期作業時間（移動中、深夜、アート活動の合間の細切れ時間）
Antigravity は、この 4 種類のうち主に 設計時間と非同期作業時間 で力を発揮するように使い分けています。集中実装時間は意外と Antigravity をフル稼働させない方が良い、というのが現時点での結論です。
なぜそうなったのか、各時間帯ごとに使い方を見ていきます。
設計時間 — Antigravity の Agent モードでアウトラインを書かせる
月曜の午前は、その週に取り組むタスクを 1 つの大きな塊として捉え、設計を整える時間にしています。ここで Antigravity の Agent モードに最初の素案を作ってもらいます。
たとえば「今週は決済画面のリファクタリングを 1 段階進めたい」というテーマであれば、こう依頼します。
今週、決済画面のリファクタリングを 1 段階進めたい。
- 現在の実装の責務を 3 行で要約
- リファクタリング後にあるべき責務分割を 3 つに分けて提示
- 各分割の作業順序と、それぞれの作業に必要な時間の目安
- 既存テストへの影響範囲
を、ファイルを参照しながら出力してください。Agent モードはコードベース全体を見て、上記のアウトラインを返してくれます。私はこれを そのまま実装計画にはせず、たたき台として読みます。多くの場合、「ここはちょっと違うな」「この順序は逆の方がいい」という気づきが出てきます。その気づきが、その週の最初の判断材料になります。
ここで重要なのは、設計判断を Antigravity に丸投げしないことです。アウトラインはあくまで思考のスタート地点であり、判断は自分で下します。Antigravity を「自分の代わりに考えてくれる存在」と捉えると、判断の責任が曖昧になります。「自分の思考を可視化してくれる存在」と捉えると、結果的に良い設計に辿り着けます。
集中実装時間 — Agent モードを意図的に控える
これは少し意外かもしれませんが、集中して実装する時間帯では、Agent モードをフル稼働させていません。
理由は 2 つあります。1 つは、Agent モードに任せている間、自分の思考が止まってしまうこと。もう 1 つは、Agent モードが返してきたコードをレビューする時間が、自分で書く時間とほぼ変わらない場合が多いことです。
集中実装時間に私が使うのは、Antigravity の インライン補完 と チャット相談です。コードを書きながら、迷った時だけチャットで「この関数はどっちの書き方が良いと思う？」と聞きます。Agent モードを呼び出すのは、自分が手を動かしている時間ではなく、考えている時間に当てる方が、結果的に良いコードが書けるという感覚です。
ただし、例外が 1 つあります。繰り返しの作業、たとえば「この関数のパターンに合わせて、似たような関数を 5 個作る」という場合は、Agent モードに任せます。創造性が求められない反復作業は、自分でやるよりも Antigravity の方が確実に速いです。
検証・微調整時間 — 軽量タスクをまとめて投げる
夕方の 1〜2 時間は、その日の実装の検証と、細かな微調整に使います。この時間帯の Antigravity の使い方は、軽量タスクをまとめて投げるスタイルです。
たとえば、その日に書いたコードに対して次のような依頼をまとめます。
- TypeScript の型エラーを全て検出して修正
- ESLint の警告を修正
- 不要な console.log や使われていない import を削除
- 関数のドキュメンテーションコメントを追加
- ユニットテストを未テストの関数に追加
これらを 1 つずつ依頼するのではなく、優先順位を付けて一括で依頼します。Agent モードは並列で進められる部分は並列に処理してくれるので、この時間帯の作業効率は手動より明らかに高くなります。
ただし、修正結果は必ず自分で diff を見て確認します。Antigravity が「これは未使用」と判断した import が、実は型推論のために必要だった、というケースもあります。差分を見る目を持つことは、AI を使う上での最低限の作法だと思っています。
非同期作業時間 — 移動中や深夜の隙間を活かす
この時間帯が、私にとって Antigravity の真骨頂です。
私はアート活動で移動が多いので、ノート PC を開ける時間は限られます。しかし、スマートフォンや iPad から軽いコメントだけ送れる時間は意外と多いです。Antigravity を 非同期に走らせるエージェントとして運用することで、この時間を有効に使います。
具体的には、深夜寝る前や移動の前に、こんな指示を Agent モードに残します。
- このブランチに対して、未対応の TODO コメントを全て洗い出してリストアップ
- このディレクトリ配下の依存関係を整理し、循環参照があれば検出
- このログファイルから、過去 24 時間で発生した特異な挙動を抜き出し
- このコードベースに対して、新規参加者用の README を草稿として書く
これらは即時のレスポンスを必要としないタスクなので、Antigravity に任せて、結果は次に PC を開いた時に確認します。自分が手を動かしていない時間に、Antigravity が考え続けてくれるという感覚は、個人開発者にとって大きなレバレッジです。
ペース配分の落とし穴 — 「全部 Antigravity に任せたい」誘惑
ここまで紹介してきて、「では全部 Antigravity に任せれば最大効率では？」と思う方もいるかもしれません。私も 2026 年初頭はその発想で運用していました。しかし、半年運用して気づいたのは、全部任せると、自分の判断軸が失われるという事実です。
判断軸が失われると、次のような問題が発生します。
- コードレビューで「なぜこう実装したのか」が説明できない
- バグが出た時、自分のコードのはずなのに動作を理解できない
- 設計の方向性を聞かれた時、Antigravity の出力をそのまま答えてしまう
これは、個人開発者として致命的です。長期メンテナンスは自分の責任ですし、アプリの運営方針は AI ではなく自分が決めるべきものです。
そこで、私は意図的に「Antigravity を使わない時間帯」を週に 2 回設けています。月曜の午前と木曜の午前、つまり設計時間の冒頭 1 時間は、ペンとノートだけで考える時間です。何の効率化もしない時間を週次リズムに入れることで、自分の判断軸を保っています。
アーティストとしての視点 — 創造性は効率化できない
最後に、アーティストとして個人開発に関わっている立場から、もう 1 点書き残しておきたいことがあります。
アプリ開発の中には、効率化できる作業と、効率化してはいけない作業があります。
効率化できるのは、コーディング、テスト、ビルド、デプロイ、ドキュメント整備などの 再現可能な作業です。これらは Antigravity に任せて、私はアートの活動に時間を使います。
効率化してはいけないのは、ユーザー体験の設計、世界観の構築、アプリの個性を決める要素です。これらは私がアーティストとして培ってきた感性で判断するもので、AI に任せると平均的なアウトプットに収束します。
Antigravity は強力ですが、強力だからこそ、使う側が「どこに使い、どこに使わないか」を意識する必要があります。週次リズムを設計するというのは、技術的な話に見えて、実は 自分のクリエイティブの主導権を保つための設計でもあるのだと、最近強く感じています。
明日からの 1 週間、皆さんも一度、自分の開発リズムを見直してみてはいかがでしょうか。Antigravity に任せる時間と、自分で考える時間の配分を意識するだけで、1 週間後の実装が驚くほど変わるはずです。