新 iPhone の解像度対応作業で、Antigravity を使えば一瞬で終わる──そう思っていた時期が、私にもありました。
2026年5月、累計5,000万DLを超えるアプリ群のうち iOS 版4本（Beautiful HD Wallpapers・Ukiyo-e Wallpapers・Relaxing Healing・Law of Attraction Everyday）を新モデルに対応させる作業を始めたとき、現実はそう甘くありませんでした。DefineManager.h に三項演算子を追加した箇所は最終的に29箇所。Antigravity が自動で検出してくれた部分もあれば、完全に見落とした部分もあります。得たものと失ったものを、正直に整理してみます。
なぜ解像度対応はこんなに面倒なのか
iOSアプリを長く運営していると、iPhone の画面サイズが増えるたびに対応コストが積み上がります。2026年現在、主要モデルの論理解像度はざっと以下の通りです（ポイントベース）。
- iPhone 16 / 17: 390×844
- iPhone 16 / 17 Plus: 430×932
- iPhone Air（新）: 420×912
- iPhone 16 Pro: 393×852
- iPhone 17 Pro（新）: 402×874
- iPhone 16 Pro Max: 440×956
- iPhone 17 Pro Max: 440×956（同じ）
壁紙アプリ特有の問題は、ダウンロードする壁紙の解像度をデバイスごとに切り替える必要がある点です。iPhone Air に iPhone Plus 用の画像を渡すと、上下が切れたり縦横比が崩れたりします。これを制御しているのが DefineManager.h で、三項演算子の連鎖で機種判定を行っています。2013年に事業を始めた頃は10種類ほどの分岐でしたが、新モデルが増えるたびに条件が積み上がり、今回の更新では29箇所の追記が必要になりました。
Antigravity に最初に投げたプロンプト
最初のプロンプトはシンプルでした。
DefineManager.h の機種判定部分を確認して、
iPhone Air（420×912）と iPhone 17 Pro（402×874）への対応を追加してください。
既存のパターンに従って三項演算子で追記してください。
Antigravity はすぐにファイルを開き、既存のパターンを読み取っていくつかの箇所に追記してくれました。問題はここからです。
Antigravity が見落とした部分
生成されたコードをシミュレーターで確認すると、ある解像度バケットでは正しく切り替わるのに、別のバケットでは古い解像度のままになっていました。原因を追うと、DefineManager.h 内の参照箇所が複数あり、Antigravity は最初に検索した箇所だけを修正していたことが分かりました。
具体的には以下の状況でした。
- サムネイル用解像度定義: 修正済み ✓
- フルサイズダウンロード用解像度定義: 修正済み ✓
- Play Store 向けプレビュー解像度（iOS にも共通定義が残っていた）: 見落とし ✗
- キャッシュキー生成部分（解像度文字列を含む）: 見落とし ✗
- OGP 画像生成処理（一部兼用）: 見落とし ✗
「他にも同じパターンの箇所があるか全て探してほしい」と伝えると、追加で4箇所を発見してくれました。しかしキャッシュキーの修正は、私が自分で気づくまで指摘されませんでした。
Antigravity が本当に役立った工程
正直なところ、29箇所の修正で Antigravity が効果を発揮したのは以下の部分です。
既存パターンの読み取りと雛形生成
長い三項演算子の連鎖は人間が書くと凡ミスしやすいですが、Antigravity は既存のフォーマットをきちんと読み取り、同じスタイルで新しい条件を追記してくれました。タイポが一切なかったのは助かりました。コードスタイルの一貫性を保つ作業はAI IDEが最も得意な領域のひとつだと感じています。
全文検索によるパターン一致箇所の列挙
「このファイル内で同じ機種判定パターンが使われている箇所を全て列挙してほしい」と指示すると、正規表現ベースで候補をリストアップしてくれました。私が目視でスクロールするよりずっと確実でした。ただし「列挙してから修正」という2段階の指示をしないと、見落としが増えます。
シミュレーターで確認する手順の提案
「iPhone Air のシミュレーターがまだ Xcode 上で選択できない」と伝えると、カスタム解像度でシミュレーターを設定する方法を教えてくれました（Devices and Simulators の + から手動追加する手順）。公式ドキュメントだけではなかなか辿り着けない情報でした。
修正作業をスムーズにするプロンプトパターン
この経験から、iOS の機種依存コードを AI IDE で修正するときには、以下の2段階構成が効果的だと感じています。
[Step 1 — 列挙]
DefineManager.h 内で UIScreen.main.bounds.size を使って機種判定を
行っている箇所を全て列挙してください。直接参照だけでなく、同じ定数を
参照している間接的な箇所も含めてください。ファイル名と行番号で教えてください。
[Step 2 — 絞り込みと修正]
そのリストの中で、iPhone Air（420×912）と iPhone 17 Pro（402×874）の
対応が必要な箇所だけに絞り込み、既存の三項演算子のパターンで修正してください。
「一発で直して」という指示では、Antigravity は文脈から修正すべき箇所を推測して動くため、自明でない参照箇所を見落としがちです。列挙→絞り込みの2段階を踏むことで、見落としが大幅に減りました。
Play Store の密度分割で消えるリソース問題との組み合わせ
解像度対応と並行して、Android 版では別の問題が起きていました。Play Store の密度分割（APK splits by density）が有効になっていると、drawable-nodpi/ に配置したはずの壁紙サンプルが低密度デバイスで取得できない問題です。
Antigravity に相談すると、「drawable-nodpi/ ではなく drawable/ に配置するか、android:density の分割設定を見直す」という提案が返ってきました。最終的には drawable-nodpi/ のままにして、密度ごとのリソースバケット対応を見直す方針にしました。
iOS と Android で並行して異なる問題が起きているとき、コンテキストを混ぜると Antigravity も混乱します。チャットを分けることを強くおすすめします。
AI IDE を使っても「一発確認」が必要な理由
今回の作業を通じて改めて感じたのは、AI IDE は「変更範囲が広くて単純な作業」には強く、「文脈依存で見つけにくい参照箇所の発見」には弱い、という傾向です。
2013年から個人でアプリ開発を続けてきた私の経験では、機種依存コードはプロジェクトが育つにつれて散在していきます。最初は1ファイルにまとまっていた定義が、機能追加のたびに参照先が増え、気づいたら6箇所に同じロジックの断片が存在する──そういう状態になりやすいのです。Antigravity はファイルを開いて「最初に見えた箇所」を修正することには長けていますが、同じ意味を持つ複数の定義がプロジェクト全体に散っている場合は、明示的に「全ファイルを対象に探して」と指示しないと追い切れません。
今回 29 箇所のうち Antigravity が見落とした部分は、どれも「ファイルの違う場所にある同一目的のコード」でした。この種の問題は AI IDE に限らず、人間が作業しても見落としやすい箇所です。だからこそ、列挙→絞り込み→修正という手順を習慣にしておくことが大切だと感じています。
29箇所の修正を終えて
Beautiful HD Wallpapers の v2.1.0 として、iPhone Air・iPhone 17 Pro 対応を含む更新を段階公開した後、解像度絡みのクラッシュレポートはゼロでした。それは素直にうれしかったです。
一方で、Antigravity を使っても「全部おまかせ」にはできないという感覚は変わりませんでした。2014年から個人開発を続けてきて、累計5,000万DLを達成できたのは、こういう細部の確認作業を省略しなかったからだと思っています。宮大工だった私の祖父が「手を動かすことが一つの信心」と言っていましたが、AI IDE の時代になってもその感覚は私の中に残っています。
最終確認の責任は人間にある、という前提で Antigravity と付き合うのが、今の私のスタンスです。次に新しい iPhone モデルが発表されたとき、今回磨いたプロンプトが役に立つはずです。