保守のコードというのは、新規開発とはまったく別の難しさがあります。
2014年から個人でアプリ開発を始めて今年で12年目に入りました。壁紙アプリ・癒し系アプリ・引き寄せ系アプリを中心に、累計5,000万ダウンロードを超える規模になりました。AdMobの収益が月150万円を超えていた時期もありましたが、それと同時に「何百万人のユーザーが使っているものを壊してはならない」というプレッシャーも積み重なってきました。
去年の末頃から Antigravity をメインの開発環境として使い始め、半年ほど経ちました。新規機能の開発より、既存アプリの保守・改修・リファクタリングに投入したときの感触を正直に書き残しておきたいと思います。
レガシーコードの理解は万能ではなかった
まず正直に言うと、古いコードの理解において Antigravity はまだ万能ではありません。
2014年から書き始めたコードは、当時の自分のスタイルやライブラリの作法が色濃く残っています。コメントが少なく、命名規則が統一されていない部分も多い。そういったコードベースをエージェントに渡すと、「このメソッドの意図が読み取れなかった」という判断ミスが起きることがあります。
特に困ったのが、Deprecated API の移行作業です。古い iOS SDK の API を新しい書き方に直す際、Antigravity が提案するコードが「文法的には正しいが、このアプリの設計意図と噛み合っていない」という場面が数回ありました。
// 古いデリゲートパターン（Antigravity の提案そのままでは意図が変わる場合がある）
// tableView.delegate = self
// tableView.dataSource = self
// AGENTS.md に「このアプリはシングルセクション構成を維持する」と明記したあと
// 提案の精度が上がった解決策として有効だったのは、AGENTS.md にアプリの設計上の制約を事前に書き込んでおくことでした。「このアプリはシングルセクション構成を維持する」「バックグラウンドスレッドで UI 更新は行わない」といった制約を文章で与えると、提案の精度が変わりました。
想定外に役立ったのはクラッシュログの解析
一方で、想定以上に力を発揮したのが、クラッシュログや Firebase Crashlytics のデータを読む場面でした。
大規模アプリの保守では、Firebase コンソールに積み重なった数百件のスタックトレースを人力で精査するのが最もしんどい作業の一つです。これをエージェントに渡して「同じ原因でグルーピングして」「再現条件を推定して」と伝えると、驚くほどきれいに整理されました。
入力: Firebase Crashlytics からエクスポートした CSV（500件のクラッシュログ）
出力例:
グループ1（178件）: NSRangeException — CollectionView の更新タイミング問題
グループ2（89件）: SKPaymentQueue delegate 未解放によるゾンビオブジェクト
グループ3（44件）: iOS 18 以降の API 動作変更（画像キャッシュ関連）
このグルーピングと原因推定だけで、以前は1日かかっていた作業が2〜3時間に短縮されました。自分ひとりでは優先順位をつけにくかった保守タスクに、明確な順番が生まれました。
12年分の「暗黙知」を渡す難しさ
個人開発の保守作業で最もぶつかった壁は、「自分の過去の判断を伝える難しさ」でした。
なぜこのアーキテクチャにしたか。なぜこのライブラリを選んだか。なぜこの部分だけ例外的な処理を入れているか。12年分の意思決定は、コードの中に暗黙的に眠っています。
AI はコードを読めますが、判断の背景にあった制約や優先順位は読み取れません。「当時は Swift Concurrency がなかったので、こういう実装になっている」という文脈を AGENTS.md や会話の冒頭に毎回渡す手間は、今のところ省けません。
これは Antigravity の限界というより、個人開発の保守特有の課題だと感じています。チーム開発ではドキュメントが整備されていることが多いですが、個人開発は「自分が覚えているから書かなかった」判断が山ほどあります。
Antigravity を使い始めてから、自分のコードにコメントを丁寧に残す習慣が戻りました。意外な副作用でした。
保守作業で実際に役立った使い方
半年使ってみて、保守作業に実際に役立った使い方を3つ挙げます。
Planning Mode でのリスク可視化
大きな変更を加える前に Planning Mode でシミュレーションしておくと、「この変更が影響する可能性のあるファイル」を一覧で確認できます。累計5,000万DL規模のアプリで、リリース直前に気づけるリスクの件数が明らかに減りました。
Background Agent での夜間レビュー
自分が寝ている間に「今週マージしたコードの問題点を探して」というタスクを Background Agent に渡しておくのが習慣になりました。翌朝レポートを確認するだけで、見落としを拾えることがあります。
差分の自動説明
git diff の内容を渡して「この差分を非技術者向けに説明して」という使い方は、アプリのリリースノートを書くときに重宝しています。日英のリリースノートを両方作成する手間が大幅に減りました。
まだ「人間の目」が必要な部分
正直なところ、今の時点でアプリ全体の保守判断を Antigravity に丸ごと渡すのは難しいです。
特に課題に感じるのは、「リリースしてはいけないタイミング」の判断です。クリスマス前後・お正月・ゴールデンウィーク中はユーザーが集中するので、リリースを避けたいという運用上の判断は、コードだけを見ていても読み取れません。AGENTS.md に「この期間はリリース提案しない」と書けばある程度は対応できますが、突発的な「今はまずい」という判断は人間が行っています。
ただ、保守作業の60〜70%は機械的な作業です。ログ解析、依存パッケージの更新、テストの整備、ドキュメントの補完。そのあたりは Antigravity が安定して引き受けてくれています。
まず試してほしいこと
Antigravity を個人開発の保守に使い始めるなら、最初のステップとして「古いクラッシュログを渡してグルーピングさせる」ことをお勧めします。Firebase Crashlytics でエクスポートした CSV を一枚渡すだけで、今まで見えていなかったパターンが浮かび上がることがあります。
保守の優先順位に悩んでいる方の参考になれば幸いです。