Claudeでアプリのレビューを分析する手順 — 星の帯とテーマで直す順を決める

ストアのレビューCSVを、改善の順番に変える流れ

自社アプリのレビューは、星の平均だけ見ていても直す場所が決まりません。星1の不満と星4の要望では、同じ「遅い」でも重みが違うからです。ストアから書き出したレビューをClaudeに渡し、星の帯とテーマの2軸で数えれば、何から直すかを件数で説明できます。

この手順の中心は3つです。バージョン列を使って「どの版から悪化したか」を見ること。星の帯ごとに別の問いを立てること。返信の下書きをストアの規則に合わせて作ること。商品レビューの一般的な分類と検算は商品レビューCSVの分析手順にあるので、ここではアプリストア特有の部分に絞ります。

レビューの書き出し方はストアで違う

Google Play: CSVで月ごとに書き出せる

Play Consoleのレポートからは、Reviewsレポートを月単位で選んでダウンロードできます。Google Cloud Storageの保存先はreviews/reviews_[パッケージ名]_YYYYMM.csvの形式で、日次で集められた分が月ごとのCSVにまとまります。データは取得から3〜7日ほどで反映されます。

CSVの列には、分析で使うものが揃っています。

ヘルプには、列の数に依存した自動処理を組まないよう注意があります。列が増えても動くように、列は位置でなく名前で選びます。また、Cloud Storageのレポートを別の分析基盤へ取り込むときはCSVをUTF-16からUTF-8へ変換する必要がある、という案内もあります。日本語のレビューが文字化けしたら、まずエンコーディングを疑ってください。

画面からも、Reviewsページで日付・言語・返信状況・星・アプリのバージョン・端末などの条件でレビューを絞り込めます。評価の推移グラフには「Download CSV」ボタンがあり、期間を「Lifetime」、集計単位を「Daily」にすると、これまでに付いた評価の全データが得られます。ただし、このグラフのCSVは評価の分布で、レビュー本文は含みません。本文が要るときは、前述のReviewsレポートを使います。

App Store: ヘルプにCSV書き出しの記載がない

App Store Connectの「Ratings and Reviews」では、プラットフォームと国・地域を選び、バージョン・評価・編集済みか返信済みかで絞り込めます。閲覧できるロールはAccount Holder、Admin、App Manager、Customer Support、Developer、Marketingです。

このヘルプページには、レビュー本文をCSVで書き出す手順は載っていません。代わりに、App Store Connect APIでカスタマーレビューを取得する方法への案内があります。CSVが要るときは、APIで取得したJSONを自分でCSVに整形するか、社内の別ツールで書き出すことになります。この記事ではどちらのストアでも、次の列を持つCSVを用意できた前提で進めます。

review_id,store,date,rating,version,language,title,body

2つのストアを混ぜて分析するときは、store列を足しておきます。ストアごとの違いを後から切り分けられるようにするためです。

列を絞って、星の帯を付ける

Claudeに渡す前に、分析に不要な列を落とします。投稿者名や、本文中のメールアドレスのような個人情報があれば、この段階でマスクします。ストアのレビューには、問い合わせ先やアカウントIDをうっかり書いてしまう人がいるためです。

import pandas as pd
 
# Google Playのレポートは文字コードが異なることがあるので順に試す
for enc in ("utf-16", "utf-8-sig", "cp932"):
    try:
        raw = pd.read_csv("reviews_201610.csv", encoding=enc)
        break
    except (UnicodeError, pd.errors.ParserError):
        continue
 
df = pd.DataFrame({
    "date": raw["Review Submit Date and Time"],
    "rating": raw["Star Rating"],
    "version": raw["App Version Name"],
    "language": raw["Reviewer Language"],
    "title": raw["Review Title"].fillna(""),
    "body": raw["Review Text"].fillna(""),
    "replied": raw["Developer Reply Text"].notna(),
})
df = df[df["language"] == "ja"].copy()
 
# メールアドレスと電話番号らしき並びを伏せる
pat = r"[\w.+-]+@[\w-]+\.[\w.]+|\d{2,4}-\d{2,4}-\d{3,4}"
for c in ["title", "body"]:
    df[c] = df[c].str.replace(pat, "[伏せ字]", regex=True)
 
df["band"] = pd.cut(df["rating"], [0, 2, 3, 5], labels=["低(1-2)", "中(3)", "高(4-5)"])
df.insert(0, "review_id", [f"A{i:04d}" for i in range(1, len(df) + 1)])
df.to_csv("app_reviews_clean.csv", index=False, encoding="utf-8-sig")
print(df["band"].value_counts())

星の帯を3つにしたのは、帯ごとに立てる問いが違うからです。次の節で使います。ファイルはutf-8-sigで保存しておけば、Excelでもそのまま開けます。

レビューの件数が多いときは、月単位に分けます。Claudeのコード実行とファイル作成は、アップロードできるファイルが1つにつき30MBまでで、利用は通常のチャットよりもプランの上限を多く消費します。

帯ごとに別の問いで分類する

全件に同じ質問をすると、「使いやすい」と「使いにくい」が同じ"使い勝手"の山に積まれて、判断材料になりません。帯ごとに問いを変えるのがこの手順の肝です。

低評価の軸には「不具合以外」を入れてあります。ストアの星1には、アプリの出来と関係のない不満(配送やサポートへの不満、他社サービスの障害など)が混ざります。これを不具合の山に入れてしまうと、改善の優先順位が歪みます。

次のプロンプトは、app_reviews_clean.csvを添付して貼る例です。

添付のapp_reviews_clean.csvを分析します。
- band列ごとに、下の分類軸から選んでタグを付ける
  低(1-2): 原因 / 中(3): 星が上がる条件 / 高(4-5): 褒められた点
- 1レビューに複数のタグを付けてよい。各タグに本文からの引用を付ける
- 引用は本文(body)の一部を一字も変えずに抜き出す
- 出力は review_tags.csv に保存する
  列: review_id, band, category, quote
- 当てはまらないものは「その他」にする。捨てない
  (ここに帯ごとの分類軸を貼る)

引用を原文のとおりに抜き出させる理由は、あとで機械的に照合するためです。引用が原文にあるか、存在しないIDが混ざっていないか、件数が合うかの検算の書き方は、商品レビューCSVの分析手順にあるスクリプトがそのまま使えます。

バージョン別に見て、直す順番を決める

分類したタグをバージョン別に並べると、いつ悪化したかが見えます。件数ではなく、その版のレビュー全体に占める割合で比べます。リリース直後は新しい版のレビューが多く、件数が増えて見えるためです。

src = pd.read_csv("app_reviews_clean.csv", encoding="utf-8-sig")
tag = pd.read_csv("review_tags.csv", encoding="utf-8-sig")
 
m = tag.merge(src[["review_id", "version", "rating"]], on="review_id")
total = src.groupby("version")["review_id"].nunique()
 
low = m[(m["band"] == "低(1-2)")]
cnt = low.groupby(["category", "version"])["review_id"].nunique().unstack(fill_value=0)
rate = cnt.div(total, axis=1).round(3)
print(rate)

集計の読み方の例を、架空の数字で示します。実際の出力ではありません。

この表のように、割合が跳ねたカテゴリが「直す最初の候補」です。版による差がなく件数だけ多いカテゴリは、構造的な不満として、直す時期を別に考えます。

版を指定した検算も、Claudeに頼めます。たとえば「v4.2で増えた『ログイン・認証』の引用を5件、レビューID付きで見せてください」と頼めば、原文を読んで原因の仮説を立てられます。仮説は、クラッシュログや認証サーバーの記録で裏づけるまでは仮説のままにしておきます。

返信の下書きを、ストアの規則に合わせて作る

分類で見えた不満には、返信が付けられます。Claudeには、下書きの作成までを任せます。投稿は人が確認してから行います。

返信の規則は、ストアごとに確認する

Google Playの返信は、利用者にメールでも届きます。メールには、アプリ名、レビューの日付、利用者の評価とレビュー、あなたの返信、連絡先メールへのリンクが入ります。返信の本文は、レビュー本文から切り離されて読まれる場面があると考えて書きます。

Google Playの返信ポリシーは、明確で関連があること、攻撃的でないこと、宣伝や勧誘をしないこと、不適切な表現を含めないことを求めています。違反した場合、アプリや開発者アカウントの停止につながる可能性があるとも書かれています。したがって、返信の下書きには「アプリの使い方の誘導や再インストールを勧めるだけの定型文」「自社の他アプリの宣伝」を入れないようにしておきます。

Play Consoleには、レビューをもとにした返信案を選ぶ機能もあります。ただし、対象は直近の英語のレビューで、Play Consoleを英語で表示している開発者に限られます。日本語のレビューには使えないため、日本語の返信案はClaudeで作る意味があります。

返信案を作るプロンプト

返信は、分類したタグごとに方針を決め、その方針をClaudeに渡します。

review_tags.csvの「ログイン・認証」(低評価)のレビューに、返信案を作ります。
方針:
- 冒頭で不便をかけたことに触れる(謝罪は1回だけ)
- 原因が確認できていない間は、原因を断定しない
- 直した版の番号は、私が指定したものだけを書く: v4.3
- 個人を特定する情報・連絡先を本文に書かない
- 宣伝・勧誘・再インストールの定型案内は書かない
- 日本語で160字以内。レビューの内容に触れた1文を必ず入れる
出力: review_id, reply

字数の上限は、各ストアの規定を確認したうえで、自社で決めた値を入れてください。ここでは例として160字にしています。

直した版の番号を人が指定している点が重要です。指定がないと、まだ出していない修正を「修正しました」と書く文面になりかねません。返信は公開されるので、事実と合っているかは人が一件ずつ確認します。

返信の下書きに近いテーマとして、店舗向けの口コミ返信があります。口調の決め方や、返信してよい範囲の線引きはGoogleビジネスプロフィールの口コミ返信で扱っています。アプリのレビューでは、版の番号と原因の確定状況が返信の中身を左右する点が違います。

引き継ぎ用の1枚にまとめる

分析が終わったら、会議で使える1枚にします。Claudeは、ExcelやWord、PowerPoint、PDFのファイルを作れます。たとえばExcelで、次の3つのシートを作らせます。

作らせたファイルは、手元の集計と数字が合うかを見てから配ります。Claudeの集計表と手元のスクリプトの出力が一致しない場合は、スクリプトの出力を正とします。

つまずきやすい点

• 星の分布だけで原因を決めない: 星1が増えた原因が、アプリの不具合ではなく、ストア掲載の説明と実際の機能の食い違いにあることもあります。「説明との相違」を軸に入れておくと、この場合に気づけます
• 外部の文章を処理していることを忘れない: レビュー本文は外部の人が書いた文章です。ヘルプには、外部ファイルに目立たない形で指示を紛れ込ませ、Claudeを誘導する手口があり得るとあります。作業中のClaudeの動きを見て、想定外の動きがあれば止めてください
• ネットワーク接続は必要なときだけ開ける: Team・Enterpriseプランでは、ネットワークアクセスは既定で無効です。CSVの分析にはネットワークが要らないので、無効のまま使えます
• 返信を自動で投稿しない: Google PlayのReply to Reviews APIを使えば返信を連携できますが、公開される文章をClaudeの下書きのまま流すのは避け、人の確認を挟みます

よくある質問

星の帯は3つでよいですか

件数が数千を超えるなら、1・2・3・4・5の5つに分けても構いません。数百件までなら3帯のほうが、1つの帯あたりの件数が確保でき、タグの割合が安定します。

返信済みのレビューは分析から外しますか

分析からは外さず、replied列で区別しておきます。返信後に利用者が評価を変えることもあります。Play Consoleの評価の変化の画面で、返信の有無による評価の変化を見られるので、返信が効いたかどうかはそちらで確認できます。