「同じアプリのはずなのに、なぜ App Store では『写真が綺麗』が並び、Google Play では『広告が多い』が上位にくるのか」——この違和感を6週間追いかけて、ようやく自分の中で答えが出ました。
私は2014年から累計5,000万DLを超える壁紙アプリを個人で開発しています。レビュー対応は手動で続けてきましたが、ストアごとに何が問題視されているかの輪郭がぼんやりしたままでした。Gemini API の Structured Output が出てからは個別のレビュー分類はだいぶ楽になっていたのですが、「ストア横断の差分」を見るところまでは手が回っていませんでした。
この記事は、その差分を Gemini API で6週間出し続けてみた運用記録です。出来上がったパイプラインは1日あたり数百件の新規レビューを月60円ほどで処理できるところまで落ち着きました。そこに至るまでに、いくつか想定外の発見もありました。
なぜストア横断の差分が必要だと感じたか
きっかけは2026年4月の Beautiful HD Wallpapers v2.1.0 リリースのあとでした。App Store のレビューでは「ロック画面の写真の発色が好き」というポジティブな声が増えていたのに、Google Play では「全画面広告の頻度が増えた」というネガティブな声が静かに積み上がっていました。
iOS と Android で広告 SDK のバージョンも頻度設定もほぼ同じにしているつもりでも、実機端末のスペック差・ネットワーク条件・OS の挙動の違いで、ユーザーが体感する広告頻度は別物になります。AdMob の管理画面では impressions として一括で見えますが、ユーザーの主観は別軸の話です。
両ストアのレビューを個別に分類していたのでは、この温度差に気づくのが遅れます。同じ4月の同じ週のレビューを横並びで比較し、「片方では言及されていないが片方では頻出」というカテゴリを抽出する仕組みが必要でした。
両家の祖父がともに宮大工で、「同じ材木でも、置く向きが違えば反り方が違う」とよく聞かされたことを思い出します。アプリも同じで、同じコードベースでも置く土俵が違えばユーザーの感じ方は変わる、と捉え直しました。
6週間の運用構成 — 取得・分類・差分の3段パイプライン
運用は次の3段で組みました。1段目は App Store Connect API と Google Play Developer API からの取得。2段目は Gemini 2.5 Flash Lite による個別レビューの構造化分類。3段目は Gemini 2.5 Pro によるストア横断の差分要約です。
1段目の取得は、cron で1日2回、過去24時間分のレビューを取りに行く構成にしました。App Store Connect 側は customerReviews エンドポイントを localizations 付きで叩き、Google Play 側は reviews.list を translationLanguage=ja 付きで叩きます。
2段目の Flash Lite による分類は、レビュー1件ずつに次のスキーマを当てます。
from pydantic import BaseModel
from typing import Literal
class ReviewClassification(BaseModel):
sentiment: Literal["positive", "neutral", "negative"]
primary_category: Literal[
"wallpaper_quality",
"ad_experience",
"search_filter",
"download_save",
"battery_storage",
"subscription",
"crash_stability",
"ui_navigation",
"language_support",
"other",
]
severity: Literal["low", "medium", "high"]
user_intent: Literal["bug_report", "feature_request", "praise", "complaint", "question"]
one_line_summary: strseverity は「他のユーザーにも起きていそうか」「課金行動に影響しそうか」を踏まえた重み付けに使います。Flash Lite に判定を任せるとブレが心配でしたが、6週間運用したかぎり大カテゴリの判定はほぼ安定しました。
3段目の差分要約は、Pro モデルに「直近7日間の iOS 側カテゴリ別出現頻度」と「Android 側カテゴリ別出現頻度」を表で渡し、platform_only_topics（片方だけに出ているカテゴリ）と gap_signals（両方に出ているが温度差が大きいカテゴリ）を構造化して返してもらいます。
Gemini に差分を出させるプロンプトの組み立て方
Pro 側に渡すプロンプトでは、次の3点を明示しました。
1つ目は「同義カテゴリの再正規化を許す」こと。Flash Lite が ui_navigation と分類したものと search_filter と分類したものが、人間の目では同じ問題を指していることがあります。Pro 側で再正規化させる前提で、「カテゴリの粒度は柔軟に扱ってよい」と伝えました。
2つ目は「件数より割合で語る」こと。レビュー全体数が iOS と Android で違うため、絶対件数で比べると iOS の指摘が常に少なく見えます。「カテゴリ別出現割合の差分を主に見る」「両ストアで出現割合が3ポイント以上ズレているカテゴリに注目する」と数値の閾値を指示しました。
3つ目は「課金導線への影響を別軸で評価する」こと。サブスク継続率に直結しそうな指摘は、出現頻度が低くても優先順位を上げて欲しい、と明示しました。eCPM や LTV といったメトリクスは Gemini が裸の数字として理解できるので、運用上の重要度を言葉ではなく数字で伝えるとブレが小さくなります。
6週間で実際に見えた3つのプラットフォーム差
6週間運用して、ストア間で顕著な差が出たカテゴリが3つありました。
1つ目は広告体験の体感差です。Android 側では ad_experience カテゴリのネガティブが iOS 側より約7ポイント多く出ていました。掘り下げてみると、ネットワークが遅い端末で全画面広告のスキップボタンが表示されるまでの待ち時間が体感差を生んでいることが、Gemini の要約から読み取れました。これは AdMob のメディエーション設定で Rewarded Interstitial の優先度を下げる方向で調整しました。
2つ目は検索・フィルタ機能への要望差です。iOS 側では「カテゴリ追加」「お気に入り並び替え」が上位に来ていたのに、Android 側ではこれらがほぼ言及されていませんでした。プラットフォーム別のヘビーユーザー層の違いか、UI 配置の差で気づかれていないか、どちらかと推測しています。次の v2.2.0 では Android 側でカテゴリ機能の発見性を高める変更を入れる予定です。
3つ目は言語サポートへの言及です。Android 側で韓国語・中国語簡体字のローカライズ抜けの指摘が iOS の倍くらい出ていました。Google Play は地域配信のローカライズ要件が厳しいぶん、ユーザーがローカライズの粗に敏感だと感じます。
レビュー1件あたり0.05円で回る運用コストと、人手に残した部分
6週間の運用コストは月60円前後で安定しました。1日あたり新規レビュー300件として、Flash Lite による分類が約20円/月、週次の Pro による差分要約が約40円/月の内訳です。Implicit Caching が効くようにシステムプロンプトを固定したことで、Pro 側のコストは想定より1/3ほどに収まりました。
ただし、すべてを自動化するつもりはありません。3つだけ人手に残した部分があります。1つ目は、severity: high かつ user_intent: bug_report のレビューに対する初期返信。2つ目は、新機能リリース直後1週間のレビュー全件目通し。3つ目は、差分要約から優先改善項目を確定させる週次の30分。
1997年に16歳で初めてインターネットに繋いだ頃、海外フォーラムで質問して英語の返事をもらえたあの感覚を、いまも忘れたくないと思っています。レビュー一件にも書いた人の生活があって、自動分類で済ませてしまうのは何かを失う気がしました。
ここから先に取り組むこと
このパイプラインは6週間で形になりましたが、まだ拡張の余地があります。
直近で取り組みたいのは、レビュー差分から自動で TestFlight ベータ向けの改善案候補を生成し、エンジニアリング側の優先度キューに流すところまでの一気通貫です。それと、Google Play 側の appVersion パラメータを使ってバージョン別の温度変化を追えるようにすること。v2.1.0 から v2.2.0 にかけて広告体感がどう変わったかを定量的に追えるようになると、リリース判断の確度がもう一段上がります。
レビュー対応は地味な作業に見えて、12年やってきて改めて、アプリ事業のなかで最もユーザーの本音に近い活動だと感じています。Gemini はその本音を読み解く補助線として、いまのところとても相性がよいです。