アーティスト・個人アプリ開発者の廣川政樹です。Gemini Lab を運営しています。
先週の終わり、ようやく Beautiful HD Wallpapers の Android 版を v2.1.0 として段階公開に乗せました。2013 年に独立してアプリ事業を始めて 12 年、累計 5,000 万 DL を超えるシリーズの一本ですが、毎回リリース直前は妙に静かな気持ちになります。今日は、その「最後の数時間」に Gemini 3.2 へコードレビューを頼んだ話を、感想ベースで書き留めておきます。
技術記事というよりは、Gemini のモデルが少しずつ静かに進化していることに、個人開発の現場で気づいた——そんな観察記録だと思って読んでいただけたら嬉しいです。
段階公開の前夜、開発機の前で 1 時間だけ自分にあげた時間
土曜の深夜、5% リリースを翌朝に控えていました。Android Studio のビルドはすでに通っていて、Crashlytics の dSYM 設定も済んでいて、Play Console の段階公開も下書きまで進んでいます。
それでも私は、最後に一度だけ Gemini 3.2 にコードを通してから出すと決めています。これは v1 系の頃からの自分ルールで、「人間が見落とすところを、機械が一度黙って読んでくれる時間」を意識的に確保するためです。
具体的には、変更があった 3〜4 ファイル分の diff を Gemini に貼り付けて、「リリース直前のクラッシュリスクと、API レベル別の挙動差異を中心に読んでほしい」とだけ伝えます。仕様の説明はしません。コードの行数も指定しません。あえてヒントを少なくして、「気になったところだけ静かに言ってくれ」というスタンスで頼みます。
Gemini が拾ってきたのは、最低 API レベルの一文だった
最初に返ってきたコメントは、私が予想していたものとはまったく違うものでした。
「coreLibraryDesugaringEnabled を true にしている記述が見つかりません。Glide 5.0.5 と AGP 9.x の組み合わせで、minSdkVersion 23 を切ったときに java.util.function.Supplier が NoClassDefFoundError になる事例があります」
これを読んだ瞬間、私は背筋が少し冷えました。実は前の v2.0.0 リリース後、28 日間のあいだに Android 6.0.1 ユーザーから RecyclerView と一緒に出る NoClassDefFoundError のクラッシュが目立つようになっていたのです。当時の私は「特殊な端末の問題かもしれない」と棚上げしていました。
Gemini が静かに指摘してきたのは、まさにその箇所でした。
build.gradle に coreLibraryDesugaringEnabled true の一行を入れて、coreLibraryDesugaring の依存を 1 つ追加するだけ。たった 2 行の変更で、Android 6.0.1 ユーザーから上がっていたクラッシュが、その後の段階公開でほぼ消えました。Crashlytics の Crash-free users が 99.7% を割っていた地域から、99.95% まで戻ってきたのは、リリースから 3 日経ったあとのことです。
「全件読む」ではなく「気になるところだけ言う」精度が上がった
私が今回いちばん面白いと思ったのは、Gemini 3.2 が 指摘の選び方が以前より静かになった ことです。
以前の世代のモデルは、コードを読ませると「ここはこうしたほうが」「ここも気になる」と、丁寧すぎるほど全体を回ろうとしてくれました。それは親切ではあるのですが、リリース直前の人間が一番欲しいのは「致命的なものだけ」だったりします。
3.2 で同じプロンプトを通したとき、返ってきた指摘は 3 点。
coreLibraryDesugaringEnabledの不足（致命）RecyclerView.AdapterのnotifyItemRangeRemovedのあとに、削除元のリストを参照している箇所がある（潜在的）- 戻るボタンの広告ゲートが入れ子になっていて、優先度が読みにくい（保守性）
致命的なものから順に提示されていて、保守性の話は最後に「気になるけれど、今日のリリースには関係しません」と添えてある。この温度感が、今回は本当に助かりました。
「防御的コピー」を一行入れた静かな夜のこと
二点目の指摘——notifyItemRangeRemoved の話——は、実は私が一週間ぐらい前に直したつもりでいた箇所でした。28 日間で 50 ユーザー以上の IndexOutOfBoundsException が出ていて、防御的コピーで根治させたつもりだったのです。
ところが Gemini に diff を渡したら、別のファイルの古いコールパスが残っていることを発見してくれました。コピーしてから操作するパターンが、片方には入っていて、もう片方は元のリストをそのまま触っていたのです。リリースしてからクラッシュレポートで気づいていたら、また 28 日間の遅延が発生するところでした。
直したのは深夜の 1 時を回った頃で、外は静かで、コーヒーはもう三杯目で、自分の手がだいぶ疲れていました。Gemini にもう一度 diff を見せて、「これで防御的コピーのパターンが両方とも揃いましたか」と聞いて、「揃いました」と返ってきたとき、私は静かに安心しました。
個人開発で「もう一人の目」を持つことの意味
ここまで読んでくださって、おそらく「それなら誰でも Gemini を使えば同じことができる」と思われた方もいらっしゃるかもしれません。
でも、私が個人開発を 12 年続けてきた中で感じているのは、もう少し違うことです。Gemini が拾ってくれるのは、私が「忘れたい」と思っていた箇所のことが多いです。今回の coreLibraryDesugaringEnabled の件も、心のどこかで「あとで調べよう」と置いていたものでした。人間は疲れてくると、置いておいた問題を見て見ぬふりをする生き物です。Gemini はそういうとき、感情なく静かに「ここがありますよ」と指してくれる、そういう存在なのだと思います。
宮大工だった私の両祖父は、「手を動かすことが一つの信心」のような感覚で仕事をしていました。私は祖父の仕事のスケールにはまるで及びませんが、毎晩アプリの差分を一行ずつ読んでくれる「もう一人の目」を持てるようになったことで、自分の手元に少し丁寧さが戻ってきた気がしています。Gemini のおかげというより、Gemini という相方がいるおかげで、自分が手を抜けなくなった、という言い方のほうが正確かもしれません。
一日でモデルを変えない、というルール
最後にひとつ、現場の小さなコツを共有させてください。
私は リリース日の前後 48 時間は、コードレビューに使うモデルを途中で変えない ようにしています。Gemini 3.2 を選んだら、その日はずっと 3.2。途中で 2.5 Pro に戻ったり、別の AI に切り替えたりしません。
理由は、モデルが違うと「気になる箇所の優先度」がわずかに違うからです。リリース日に焦りながら違う観点が混ざると、せっかく見えた問題が他の指摘の中に埋もれてしまうことがあります。とくに 3.2 は、私の感覚では「致命と保守を分ける感度」が以前より落ち着いている分、その日のあいだは一貫して任せたほうが、結果的に判断が早くなります。
似たような気づきは Gemini 2.5 Pro と3ヶ月向き合った正直レポート や Gemini 3.2 を3週間使い続けた個人開発者の正直な記録 でも書いてきました。短いスパンで切り替えるより、一日単位で寄り添うほうが、私には合っているようです。
おわりに——次のリリースまでに準備したいこと
今回の段階公開は、5% から始めて 25%、50% と引き上げていく予定です。Crash-free users が 99.7% を割らないこと、ANR が 0.20% を超えないこと、この 2 つだけを静かに見ながら、来週には 100% まで開け切るつもりです。
そのあとは、iOS 側で進めている 4 アプリの更新作業に戻ります。Firebase の CocoaPods から SPM への移行や、StoreKit 2 への切替が控えていて、これらも近いうちにブログに書ければと思っています。Gemini Lab には Gemini API の Function Calling 実装ガイド や Gemini CLI 個人開発ワークフロー など、今回の作業に関連する記事もあるので、興味のある方はあわせて覗いてみてください。
書籍を一冊だけ挙げるとしたら、Android のリリース運用については Android アプリ開発の教科書 第2版（金田浩明） を今でも本棚から引っ張り出して読み返しています。今回の coreLibraryDesugaringEnabled のような話は載っていませんが、リリースに対する基礎の姿勢を整える本として、私には繰り返し戻ってくる一冊です。
最後までお読みいただき、ありがとうございました。来週、100% リリースまでたどり着いたら、また続きを書きに来ます。