壁紙アプリのリリース作業は、地味に時間がかかります。
個人開発で長く壁紙アプリを運営してきた今でも、この実感は変わりません。バージョン番号を上げてPlay Consoleに申請するだけなら数分で済みますが、その前後にある「クラッシュログを読む」「修正の優先度を判断する」「段階公開中の指標を監視する」という一連の作業は、コードを書くのとは別の種類の集中力を消費します。
2026年春、Beautiful HD WallpapersのAndroid版をv2.0.0からv2.1.0に上げるタイミングで、AntigravityのAgents機能をこのリリースフローに本格的に組み込んでみました。3ヶ月の試みで得た「ここは任せられる」「ここは自分で判断しないと危ない」という感覚を、実際のコードと指標とともに、できるだけ具体的に書いておきます。
クラッシュ診断：Agentが正確に当てた場合
v2.0.0リリース直後から、Firebase CrashlyticsにRecyclerViewのIndexOutOfBoundsExceptionが積み上がり始めました。28日間で50ユーザー以上に影響が出ていました。
この診断をAntigravityのAgentに最初に任せたのは、ある種の実験でした。スタックトレースとAdapterの実装コード、そしてnotifyDataSetChangedの呼び出し箇所をすべてAgentに渡し「何が起きているか教えてほしい」と伝えました。
返ってきた診断は正確でした。非同期でリストを更新していた箇所で、UIスレッドからの操作とバックグラウンドの更新が競合していることを、コールスタックの流れから特定してくれました。さらに「防御的コピーを使えばよい」という修正方針まで提示してくれました。
// Before: 共有参照をそのまま渡していた fun updateList (newItems: List < WallpaperItem >) { items = newItems // 呼び出し元のリストを直接保持 notifyDataSetChanged () }
// After: 防御的コピーで参照を切る fun updateList (newItems: List < WallpaperItem >) { items = ArrayList (newItems) // コピーを作って参照を分離 notifyDataSetChanged () } この1行の変更でv2.1.0では該当クラッシュがゼロになりました。スタックトレースを読み解いてパターンマッチする作業は、Agentが得意とする領域だと感じました。既知の落とし穴——RecyclerViewの更新競合のような——は、学習データのどこかに必ず類例があります。だからこそ、こちらが十分な材料を渡せば診断は速く、正確になります。
なぜここでAgentが当たったのか。後から振り返ると、渡した3点セット（スタックトレース・Adapter実装・更新呼び出し箇所）が、この不具合を再構成するのに必要な情報を過不足なく含んでいたからでした。問題が「一つのクラスの内部」で完結していたことも大きい。文脈が閉じているほど、Agentの推論は安定します。
クラッシュ診断：Agentが見落とした場合
一方で、最初の診断をAgentが外したケースもありました。
Android 6.0.1端末（API 23）でアプリが起動しない、という報告が数件来ていました。ログにはjava.lang.NoClassDefFoundError: Failed resolution of: Ljava/util/function/Supplierと出ていました。
Agentに相談すると「Glide 5.0.5との互換性問題の可能性がある」という方向に答えを出そうとしました。半分正しいのですが、根本原因はAGP 9.xとJava 8ストリームAPIのdesugaring設定が有効になっていないことでした。
// app/build.gradle — この設定が抜けていた compileOptions { sourceCompatibility = JavaVersion.VERSION_1_8 targetCompatibility = JavaVersion.VERSION_1_8 isCoreLibraryDesugaringEnabled = true // ← これ }
dependencies { coreLibraryDesugaring ( "com.android.tools.desugar_jdk_libs:2.1.4" ) } この設定を追加してからAPI 23端末のクラッシュも消えました。Agentが正確に診断できなかった理由を後から考えると、「build.gradleの全体構成」「使用しているAGPバージョン」「ターゲットとする最低APIレベル」という3つの文脈が同時に必要だったのに、私がスタックトレースだけを渡していたからでした。
先ほどのRecyclerViewのケースと違い、この不具合は「ビルド設定」「依存ライブラリ」「実行端末のAPIレベル」という複数のレイヤーにまたがっていました。原因が一箇所に閉じていない問題では、Agentは手元の材料の範囲でもっともらしい仮説を立てます。その仮説がGlideに向いたのは、渡された情報だけを見れば自然な推論だったのです。
Agentに渡す文脈をどう設計するかは、こちら側の責任です。
なぜ外したのか——文脈設計のチェックリスト
この2つの対比から、私はAgentに診断を頼むときの「文脈チェックリスト」を作りました。クラッシュ報告を受け取ったら、Agentに渡す前に次の観点が揃っているかを確認します。
このチェックリストを通すようになってから、一発目の診断が当たる確率が体感で大きく上がりました。ポイントは、Agentの賢さに期待するのではなく、こちらが問題を再構成できるだけの材料を先に揃えることです。診断精度は、Agentの能力より、渡す文脈の設計で決まる——この3ヶ月で最もはっきりした学びでした。
段階公開の監視：数値判定を対話に落とす
Play Storeの段階公開（5% → 25% → 50% → 100%）では、各フェーズでCrash-free usersが99.7%以上を維持できているかを確認します。
この作業にAgentを使うのは、相性がよかったです。Play Consoleからエクスポートした指標のCSVをAgentに渡して「問題があるか判断してほしい」と伝えると、閾値ベースで「このまま進めてよいか」を即座に答えてくれます。判断の基準は、あらかじめ次の表の形でAgentに渡しておきます。
基準を渡しておけば、毎回のチェックが対話形式で完結します。
私: v2.1.0の25%→50%拡大を判断したい。指標を確認してほしい。
Crash-free users: 99.83%
ANR rate: 0.14%
Force stop（過去7日）: 前バージョン比 -12%
Agent: 全指標が基準を満たしています。
Crash-free users 99.83% > 99.7% ✓
ANR rate 0.14% < 0.20% ✓
Force stop 減少傾向 ✓
50%への拡大を進めることを推奨します。
スプレッドシートで手動確認していた頃より、見落としが減りました。判断の根拠もセッション内に残るため、次のフェーズで振り返りやすくなります。
ただし、ここで一つ注意していることがあります。数値が基準を満たしていても、拡大を止める判断はAgentに委ねません。指標が緑でも、ストアレビューに「更新後に重くなった」という声が数件でも出ていれば、私は拡大を一段保留します。数値は過去の平均であり、レビューは今この瞬間の温度感だからです。Go/No-Goの最終スイッチは、数値の外側にある情報も含めて人間が握る——ここは3ヶ月を通して変えませんでした。
リリースノートの草稿作成
これは予想より使えました。
修正内容の箇条書きをAgentに渡すと、日英のリリースノート草稿を数秒で返してくれます。技術的すぎる表現を一般ユーザー向けの言葉に変換することも、ある程度対応できます。
私がやっていることは、草稿を読んで「このアプリらしくない言葉遣い」を直すことだけです。アプリのトーンやユーザー層の感覚はAgent側にはないため、最終調整は手作業になりますが、ゼロから書く労力と比べると大幅に軽減されました。白紙から書き始める摩擦がなくなるだけでも、リリース直前の消耗はかなり減ります。
委譲の境界線——工程ごとのマトリクス
3ヶ月の経験を、工程ごとの委譲度として整理するとこうなります。
個人開発を続けてきた感覚として、Agentが最も力を発揮するのは「過去の類似事例が多いパターンマッチング」です。RecyclerViewのクラッシュのような既知の落とし穴には強い。一方で、「このアプリの文脈では何が正解か」という判断は、まだ人間が持ち続けるべき部分だと感じています。
委譲度が「低」の行を人間の側に残しておくこと。これが、Agentに任せる範囲を広げても事故を起こさないための、私なりの安全弁になっています。
問いを組み立ててから渡す——習慣の変化
Antigravity Agentsを継続的に使うことで、変わった習慣が一つあります。問題をより構造的に整理してからAgentに渡すようになりました。
使い始めた頃は、「なんか起動しない」「クラッシュが出ている」という形で問いを投げていました。これだとAgentは可能性を広げすぎてしまい、答えの精度が下がります。
今は問いを投げる前に、自分でまず仮説を一つ立てるようにしています。「API 23でのみNoClassDefFoundErrorが出ています。desugaringが原因の可能性があります。build.gradleのcompileOptionsを添付するので確認してほしい」という形です。
仮説が正しければAgentはすぐに確認してくれます。仮説が外れていても、「その方向ではなく、こちらが原因です」と絞り込みを手伝ってくれます。どちらにしても、漠然と「原因を探してほしい」と伝えるより早く答えにたどり着けます。
この「問いを組み立ててから渡す」習慣は、実はAgentを使い始めてから逆算的に身についたものです。Agentが答えやすい形を意識するうちに、問題を整理する自分自身の精度も上がりました。道具を使いながら、道具によって鍛えられる。私自身、そういう関係が個人開発の日々に静かに組み込まれていると感じています。
Agentsの立ち位置と、次の一歩
個人開発の視点で、Antigravity Agentsの立ち位置を整理するとこうなります。
Agentは「判断の実行を速くする道具」です。クラッシュの原因を追うスピード、指標を読むスピード、リリースノートを書くスピード——これらは確実に上がりました。
ただ、「何を判断するか」は依然として自分が決めなければなりません。どのクラッシュを優先するか、段階公開をいつ止めるか、アーキテクチャをどう変えるか——これらはアプリのユーザー層や運営の方針を熟知している自分にしかできない判断です。
もし今日から一歩を試すなら、まずは委譲度「高」の工程——スタックトレースの解読と指標の閾値判定——から始めることをおすすめします。そこで文脈設計のチェックリストを回し、Agentが当たる感覚と外す感覚を自分の手で確かめる。その体感が、委譲の境界線をあなた自身のアプリに合わせて引き直す土台になります。
判断の速度を上げてくれる相棒として使い、判断そのものは手放さない。その役割分担が、個人開発において現実的なAgentsの使い方だと感じています。お読みいただきありがとうございました。