個人で開発しているアプリの中に、Beautiful HD Wallpapers というiOS/Androidアプリがあります。2013年にリリースして以来、累計5,000万DLを超えた壁紙アプリです。
このアプリは長年の積み上げでコードベースが肥大化しており、正直なところ「保守したくない」と感じる箇所が増えていました。iOSのバージョンアップへの追従、メモリリークの修正、UIKitからSwiftUIへの段階的な移行。それらを一人でこなすのはかなりの負荷です。アプリ事業を2014年から12年続けてきて、これは一番消耗する局面のひとつです。
2026年2月から6週間、Antigravity（Cursorなどと同系統のエージェント型AIコーディングアシスタント）をこのアプリの保守に本格的に組み込んでみました。今回はその正直なレポートです。良かった点も悪かった点も、実際に体験したことだけを書きます。
試した作業と、最初に決めた線引き
まず最初に「これはAntigravityに任せられそう」と考えた作業リストを整理しておきます。Objective-Cで書かれたレガシーコードへのコメント補完と説明文生成、UICollectionView関連のパフォーマンス最適化の提案、Crashlyticsのクラッシュログを貼り付けて再現コードを特定すること、TestFlightのレビューコメントから改善要望を整理すること、XCTestのスケルトン生成などです。
一方で「これはAntigravityには無理だろう」と最初から割り切っていた作業もあります。App Storeの審査基準の最新解釈、ユーザー体験の本質的な設計判断、壁紙コンテンツのキュレーションとクオリティ判断、そしてアプリのマネタイズ戦略の意思決定などです。
この線引きを最初に決めておいたことが、6週間通じて大きく助かりました。過度な期待を持たずに、本来Antigravityが得意とする領域だけに集中して使えたからです。AIツールを使う前に「どこまで任せるか」を自分の中で明確にしておくことは、どんなツールでも共通して重要だと感じています。
期待通りだった部分：クラッシュ解析とコメント生成
クラッシュログの解析は思った以上に使えました。
Crashlyticsのスタックトレースをそのまま貼り付けて「このクラッシュの原因を教えてください」と聞くと、コードを照合しながら「UICollectionViewのセルの再利用処理でメインスレッドとバックグラウンドスレッドが競合しています。おそらくline XX あたりです」という回答が返ってきます。
以前は1件のクラッシュ原因を特定するのに1〜2時間かかっていたものが、20〜30分で仮説が出るようになりました。すべての仮説が正しいわけではありませんが、検討の起点として十分使えます。確認と修正の工程に時間を使えるようになったのは体感として大きな変化です。
Objective-Cコードへの説明生成も想定以上でした。
Beautiful HD Wallpapersには2013〜2016年頃に書いたObjective-Cコードがまだ残っています。正直、自分でも「なぜこう書いたのか」が思い出せない箇所があります。Antigravityに「このメソッドが何をしているか、コメントを日本語で書いてください」と頼むと、かなり的確な説明が返ってきます。同じアプリを一緒に長く保守してくれる仕様書担当者が増えたような感覚で、これは地味に助かっています。
テストコードのスケルトン生成も思いの外効果がありました。
「この関数に対してユニットテストを書いてほしい」と依頼すると、XCTestCaseを使った基本的な構造と主要なアサーションを一通り生成してくれます。中身を詰めるのは自分ですが、白紙から書き始めるより格段に速いです。テストを書くことへの心理的ハードルが下がったのも副次的な効果でした。テストカバレッジが徐々に上がっているのを確認できると、長期保守に対する不安感が少し和らぎます。
正直に言うと、期待を裏切られた部分
コンテキスト喪失が思ったより頻繁に起きます。
Beautiful HD Wallpapersのコードベースは数万行に及びます。Antigravityはウィンドウ内に収まる範囲しか文脈として保持できないため、「さっき説明した画像キャッシュの設計と整合しているか確認してください」という問い合わせに対し、まるで初めて聞いたかのような回答が返ってくることがあります。
長期的な一貫性を保つには、セッションごとに自分で「今日の前提」を再説明する必要があります。このオーバーヘッドは思ったより手間で、慣れるまでストレスを感じました。大きなプロジェクトほどこの問題が顕著に出ます。対策として「前提メモ.md」を作り毎回先頭に貼り付ける習慣をつけましたが、それ自体が管理コストになっています。コンテキスト管理の手間をどう減らすかは、今後も試行錯誤を続けるつもりです。
SwiftUIの「それっぽいコード」問題。
UIKit側のコードをSwiftUIに移行する提案をしてもらったとき、生成されたコードは文法的には正しいのですが、「このアプリの壁紙表示ロジック特有の挙動」を反映していないことが多かったです。具体的には、画像の遅延読み込みと表示アニメーションのタイミングが微妙にずれる実装が、何度提案されても直らなかったことがありました。「このケースではこういう問題が起きる」と繰り返し説明しても、次のセッションではリセットされます。最終的には「この部分は自分で書く」と決断しました。アプリ固有のドメイン知識は、やはり外から補えないと感じた瞬間でした。
長いファイルへの対応が苦手です。
1,000行を超えるファイルを渡すと、後半への言及が薄くなる傾向があります。分割して渡す工夫をしましたが、それ自体が追加の手間になります。ファイル分割の設計自体をAntigravityに相談するという逆転の発想で対処することもありましたが、これはこれで時間がかかりました。
個人開発者にとっての現実解
Antigravityは「コードを全部お任せ」するツールではなく、「自分の判断を補助してもらう」ツールだというのが正直な結論です。
2014年から12年間、個人でアプリを開発してきて感じるのは、個人開発者の強みはドメイン知識の深さと意思決定のスピードです。Antigravityはこのうち「実装の速度」を底上げするのには効果的です。一方で、ドメイン知識（Beautiful HD Wallpapersのユーザーがどういう体験を期待しているか、どの壁紙カテゴリが季節ごとにダウンロード数を伸ばすか）は自分の中にしかありません。
この線引きを最初から意識しておくと、過度な期待も過度な失望もなく使えると思います。今後は特定の作業（クラッシュ解析、コメント生成、テストコードのスケルトン生成）を定型的に任せ、設計判断とUXの細部は自分で行うという分担を続けます。まずは得意な領域から着実に活用範囲を広げていくのが、長く使い続けるための現実的なアプローチだと感じています。
同じ課題に取り組んでいる個人開発者の参考になれば幸いです。