累計5,000万DLアプリの保守をAntigravityにどこまで任せられたか — 12年個人開発者の現場検証

「12年積み上げてきたコードベースに、今のAIエージェントを当てて何が起きるのか」を、ここ数週間ずっと検証していました。

私はアーティスト・クリエイターの廣川政樹です。2014年から個人で壁紙アプリと癒し系アプリ群を作り続けていて、累計ダウンロードは5,000万を超えました。広告収益の月次は時期によりますが、AdMobのピーク帯では月150万円超に達したこともあります。問題は、最も古いコードが10年以上前に書かれていて、当時の自分が「これでいい」と思った設計と、今の自分が見て「これは良くない」と感じる設計が、同じプロジェクトに同居していることです。

Antigravityをこの保守作業に投入してみて、想像以上に任せられる仕事と、まだ自分が判断するしかない仕事が、はっきり分かれました。今回はその境界線を、実際に発生したやり取りベースでお伝えします。

なぜ今、古いアプリ群の保守にAIエージェントを試したのか

正直に言うと、最初は「AIに任せてもどうせ最新のコードしか理解できない」と決めつけていました。きっかけは、壁紙アプリの一つで広告SDKの非推奨APIが原因でクラッシュ率が0.3%上がったことです。手を入れたい場所はわかっていましたが、似た構造のアプリが14本あり、全部に同じ修正を入れる気力が削がれていました。

これはまさにエージェント向きの仕事ではないかと、考え直しました。判断は人間がして、機械的な展開だけ任せる。そう割り切ったところから、検証の方針が見えてきました。

宮大工だった両祖父の影響で、古いものに新しい手を入れるときは「元の設計の意図を尊重する」癖が私には染みついています。リファクタは破壊ではなく、対話に近いものだと思っています。Antigravityがその対話に入れる相手なのか、を見たかったのです。

検証環境と前提

検証対象は以下の通りです。

アプリ本数: 壁紙系8本・癒し系6本（合計14本）
言語構成: Swift（iOS）+ Kotlin（Android）。一部アプリにObjective-CとJavaの遺産あり
コード行数: 各アプリ平均で約2.5万行（うち4本は5万行超）
一番古いコード: 2014年ごろに書かれた壁紙ローダーロジック
Antigravityの利用バージョン: Manager Surface中心、agentsはGemini系をメインに

検証期間は約3週間で、保守タスクとして発生した修正をできる限りエージェントに渡し、最終判断と統合だけ自分が行う体制で運用しました。

任せられた仕事 — 機械的な広がりがある作業

1. 同一構造の修正を14本に展開する作業

最初に効果が出たのが、AdMob SDKのデリゲートメソッド更新です。1本のアプリで修正パターンを確定させた後、Antigravityに「この差分を、似た構造の他のリポジトリに当てはめて、各アプリの命名規則を尊重して反映してほしい」と伝えました。

ここで助かったのは、エージェントが「アプリAではAdManager、アプリBではAdvertisingServiceという命名なので、それぞれに合わせて変換した」と報告してきたことです。私が手作業でやれば必ず1〜2本で命名を取り違えていたはずで、ここは完全に任せて良い領域だと感じました。

// Before（古い実装・iOS壁紙アプリで2018年ごろに書かれたもの）
class AdManager: NSObject, GADBannerViewDelegate {
    func adViewDidReceiveAd(_ bannerView: GADBannerView) {
        // 旧API、警告が出ている
    }
}
 
// After（Antigravityが14本に展開した結果・命名は各アプリに合わせて変換済み）
class AdManager: NSObject, BannerViewDelegate {
    func bannerViewDidReceiveAd(_ bannerView: BannerView) {
        // 新API・期待出力: クラッシュ率の0.3%上昇が解消
    }
}

期待した出力どおりにクラッシュ率は元の水準に戻り、所要時間は手作業で見積もった半分以下でした。

2. テストコードの“穴”を補う作業

これは予想以上に効きました。古いアプリのテストカバレッジは平均30%前後で、特に壁紙ローダーまわりは「動いているから触れない」状態でした。Antigravityに既存実装の振る舞いを読ませて、既存挙動に合うテストを書かせる方針で進めると、明らかに人間より速く網羅的なテストが揃いました。

注意したのは、エージェントの書いたテストを必ず一度落としてから通すことです。最初から通るテストは、実装ではなくテスト側を実装に合わせて書いてしまっている可能性があるためです。

3. 依存関係のバージョン整理

これも任せて問題ありませんでした。Package.swiftやbuild.gradleの整理、互換性のあるマイナーアップグレードの提案、deprecated警告の解消などは、人間が見直すよりエージェントの提案の方が網羅的です。判断は私が下し、機械的な作業だけ任せるという原則を守ると、安心して任せられる領域でした。

任せられなかった仕事 — 文脈と意図を背負っている部分

1. 「なぜこの実装になっているか」を問う変更

壁紙アプリの中に、明らかに冗長に見えるけれど触ってはいけないコードがあります。これはApp Storeのレビューで一度だけリジェクトされた経緯があり、その対応として入れた回避策です。

Antigravityに「リファクタしてほしい」と依頼すると、当然のようにこの回避策をきれいに整理しようとしました。エージェントから見れば不自然なコードに見えますが、私から見れば過去の意思決定を背負った大切な実装です。

ここで学んだのは、コードに残っている「なぜ」を伝えるのは、結局のところ人間の仕事だということです。CLAUDE.mdに相当する文脈ファイルを各アプリに用意し、「このファイルのこの関数は触らない、理由はApp Store審査対応」と明記しておくことで、エージェントの暴走は防げました。

2. ユーザー体験の根幹に関わる判断

癒し系アプリの一つで、効果音のフェードイン時間を150msから200msに変えるかどうかを検討していました。技術的には1行の変更です。しかしこの50msは、私が2019年に吉祥寺駅上空で光の輪を見た夜の感覚を翻訳しようとして、何度も試した結果の数字でした。

Antigravityに「ユーザー体験の改善案を出してほしい」と依頼すれば、それなりに合理的な提案は返ってきます。でもそれは、私がアーティストとして残したかった呼吸感とは別の何かです。視覚や聴覚の細部を担う数値は、エージェントに任せず自分の手で決めるべきだと、改めて感じました。

3. リリース判断と謝罪文

クラッシュ修正をリリースする際の、ストア説明文の更新と、過去のバージョンでクラッシュに遭遇したユーザーへのレビュー返信は、エージェントに下書きを作らせると無難ですが個性のない文章になります。離れて暮らす子どもたちにも自分の言葉として残せる文章を書きたい場面では、下書きは作らせても、最終文は必ず自分で書き直すことを習慣にしました。

実際の運用で固めた3つの判断軸

数週間運用して、自分の中に判断基準ができました。

第一に「同じ作業を3回以上繰り返すならエージェントに任せる」。1回や2回なら手で書いた方が速いことが多いのですが、3回目になると展開コストが回収できます。

第二に「結果が数値で測れるならエージェントに任せる」。クラッシュ率・テストカバレッジ・ビルド時間など、人間より早く正確に測定し続けられる領域は、明らかに任せた方がいい仕事です。

第三に「ユーザーの感情に触れる場所には自分の手を置く」。文章・サウンド・色・タイミング・謝罪などです。ここを任せると、エージェントは平均点の答えを返します。平均点は、個人開発者にとって最大の敗北だと私は考えています。

エージェント向けに「なぜ」を書き残しておくということ

この検証で副産物として身についた習慣が、各リポジトリに非常に小さな文脈メモを置くことです。網羅的な設計書ではなく、「ここは触るな、理由はこれ」を3〜4文で書き残すだけの小さなメモです。

気づいたのは、エージェントが読む前に、書く行為そのものが意味を持っていたということです。何年も抱えてきたコードに、書かれた理由が初めて添えられたことで、次に開く人（多くの場合は未来の自分です）が遺跡を発掘する必要がなくなりました。エージェントの恩恵もありますが、コードベース自体の長寿命化に効きます。

まだエージェントを保守フローに入れる準備ができていない方にも、この一歩はおすすめできます。古いコードを言葉で説明し直す作業は、それ自体が報酬のあるリファクタです。そして一度メモが揃えば、後でエージェントを入れる移行コストはずっと小さくなります。

次のアクション

もし同じように長く運用しているプロジェクトをお持ちでしたら、まず1本のアプリで「3回以上繰り返す作業」を1つだけ選び、Antigravityにその展開を任せてみてください。それが今日の私の現実的な提案です。

私自身まだ検証の途中ですが、12年積み上げたコードベースに新しい道具を持ち込んで対話する経験は、想像していた以上に学びが多いものでした。同じ課題に向き合っている方の参考になれば嬉しく思います。