asodevapp/skills

レビューマネジメント

レビューの分析、評判管理、返信ドラフト作成、クレーム・報告書のドラフト作成、プロダクトインサイトの抽出、アップロードされたレビューCSVの分析、レーティング改善戦略に使用します。

MCPワークフロー

1. app-store-connect-mcpを使用します。
2. 単一レビュー：get_review_dataで読み取ります。
3. レビューリスト：get_reviews_dataで読み取ります。
4. unansweredOnly、badRatingOnly、maxRatingを使用してレビューリストを絞り込みます。
5. プロジェクトのコンテキスト（トーン、サポートリンク、既知の問題、対応ポリシー）を使用します。
6. レビューの健全性、テーマ、対応機会、クレーム・報告の該当性を分析します。
7. validate_ai_companion_dataをターゲットreviewまたはreviewListで検証します。
8. 適用が依頼された場合、fill_reviewまたはfill_reviewsでドラフトを入力します。

入力フィールド

単一レビュー：

• responseBody
• complaintReason
• concernType

レビューリスト：

• reviews：配列またはreviewIdによるマップ。各要素にresponseBody、complaintReason、concernTypeを含みます。

CSVレビュー分析

ユーザーがすべてのレビューを含むCSVをアップロードまたは参照する場合にこのモードを使用します。CSV分析は、ユーザーがASO.devに返信やクレームを入力する必要がない限り、MCPは必要ありません。

分析前：

1. CSVの列を特定します。一般的な列：レビューID、評価、タイトル、本文/テキスト、ロケール/国、アプリバージョン、日付、開発者応答、応答日、デバイス/プラットフォーム。
2. 日付、評価、ロケール、バージョン、空の値を正規化します。
3. レビューIDまたは完全一致のタイトル/本文/日付によって重複行を削除します。
4. 評価、ロケール/国、アプリバージョン、期間、回答済み/未回答ステータス、レビュー長でセグメント化します。
5. CSVが大きい場合は、引用用にサンプルを抽出しますが、カウントとテーマはファイル全体で計算します。

分析内容：

• 評価とテキストによる感情：ポジティブ、ニュートラル、ネガティブ、混合。
• テーマ：バグ/クラッシュ、UXの摩擦、価格/ペイウォール、オンボーディング、パフォーマンス、アカウント/ログイン、ローカリゼーション、サポート、コンテンツ品質。
• 機能要望：不足している機能、「これがあれば...」という繰り返しのパターン、競合との比較。
• プロダクトリスク：アプリバージョン/日付によるリグレッション、深刻なバグ、返金/キャンセルの意図、信頼性/プライバシーの懸念。
• ASO言語：ユーザーが価値、成果、ユースケースを説明するために使うフレーズ。
• サポート機会：未回答の低評価レビュー、古い返信、影響の大きい返信。

CSV出力にはカウントと代表的な例を含めます。生のレビューデータの大規模なダンプは貼り付けないでください。

レビュー分析フレームワーク

テーマの分類：

テーマ	意味	アクション
バグ/クラッシュ	技術的な障害、フローの破綻、リグレッション	修正をエスカレーション、確認済みのステータスのみ返信する
機能要望	ユーザーが不足している機能を求めている	頻度とユーザーセグメントを追跡する
UXの不満	わかりにくい、遅い、イライラする、使いにくい	UX/プロダクトレビューを優先する
価格/ペイウォール	高すぎる、サブスクリプションが不明瞭、トライアルの混乱	繰り返される場合はmonetization-strategyを使用する
称賛	価値、喜び、お気に入りの機能	感謝し、コンバージョン言語を学ぶ
競合の言及	比較や乗り換えの理由	ポジショニングのギャップを探る

レビューの健全性シグナル：

• 平均評価と傾向（利用可能な場合）
• 最近の低評価のボリューム
• 未回答の否定的レビュー
• 応答率と応答の鮮度
• 繰り返されるバグ/UX/価格のテーマ
• クレーム/報告の候補

返信ルール

• 落ち着いて、具体的に、簡潔に。
• タイムリーな返信を優先し、運用可能な場合は、影響の大きい否定的レビューには24～48時間以内を目指します。
• レビュアーと議論しないでください。
• 内部データを開示しないでください。
• 確認されていない修正を約束しないでください。
• 公開の場で個人情報を求めないでください。
• 怒りのレビューには、問題を認めてサポートに誘導します。
• ユーザーに評価の変更を依頼しないでください。
• 多数のレビューに同一の返信をコピーペーストしないでください。

返信フレームワーク

否定的レビューにはHEARを使用します：

1. Hear（聞く）：具体的な問題を認めます。
2. Empathize（共感する）：フラストレーションを理解していることを示します。
3. Act（行動する）：何がわかっていて、修正済みか、調査中かを説明します。
4. Resolve（解決する）：適切な連絡先でダイレクトサポートに誘導します。

テンプレートはあくまで出発点です：

• バグ：問題を認め、確認済みの修正バージョンがあれば記載し、アップデート/サポートに誘導します。
• 機能要望：感謝の意を伝え、チームと共有したことを伝え、ロードマップを約束しないようにします。
• 曖昧な否定的レビュー：簡潔に謝罪し、サポートを通じて詳細を求めます。
• 肯定的レビュー：感謝し、ユーザーが挙げた利点を繰り返します。

クレーム/報告ルール

• レビューが虐待的、スパム、詐欺的、無関係、またはその他ポリシー違反である場合にのみ報告します。
• 単に評価が低いという理由だけで正当な否定的フィードバックを報告しないでください。
• クレーム理由は事実に基づき簡潔に保ちます。

レーティングプロンプト戦略

アドバイスのみに使用します。このMCPスキルはレビュードラフトを作成するものであり、アプリコードを変更するものではありません。

• ポジティブな価値体験の後にのみトリガーします。
• 初回セッション、オンボーディング、エラー、クラッシュ、支払い失敗、サポートでのフラストレーションの場面では避けます。
• 良いタイミング：タスク完了、目標達成、連続記録、時間/コスト節約、復元/エクスポート/共有の成功。
• プラットフォームの制限を尊重し、レビューに対するインセンティブを提供しないでください。
• 悪いレビューの原因がプロダクトの問題である場合は、プロンプトのボリュームを増やす前に問題を修正します。

プロダクトインサイトの抽出

レビューから以下を抽出します：

• 最も愛されている機能と、メタデータ/スクリーンショットのための正確なユーザー言語。
• 最も頻繁に発生するバグやUXの失敗。
• マネタイズに対する反対意見とサブスクリプションの混乱。
• 機能需要の頻度。
• 言及された競合と乗り換えのきっかけ。

機能要望のスコアリング：

シグナル	意味
頻度	その要望がいくつのレビューで言及されているか
評価への影響	その要望が低評価や解約リスクのあるレビューに現れるかどうか
セグメント	どのロケール、バージョン、ユーザータイプ、国で現れるか
戦略的適合性	アプリのポジショニングやロードマップと一致するかどうか
労力/リスク	プロダクト、バックエンド、デザイン、価格設定、ポリシーの作業が必要かどうか

出力

# レビューの健全性と対応作業

アプリ：
モード：
評価/傾向：
フィルター：
CSVソース：

## 健全性サマリー
- 読み込まれたレビューの総数：
- 低評価レビュー：
- 未回答レビュー：
- 主なリスク：

## 感情
| セグメント | ポジティブ | ニュートラル | ネガティブ | 混合 | 備考 |
|---|---:|---:|---:|---:|---|

## テーマ
| テーマ | 件数 | 評価への影響 | 根拠 | アクション |
|---|---:|---|---|---|

## 不足機能/要望
| 要望 | 件数 | ユーザーセグメント | 根拠 | プロダクト推奨 |
|---|---:|---|---|---|

## ドラフト
| レビューID | 評価 | テーマ | アクション | ドラフト |
|---|---:|---|---|---|

## プロダクトインサイト
| インサイト | 根拠 | 推奨オーナー/アクション |
|---|---|---|

## レーティング改善計画
1.
2.
3.

## 検証
- CSV列マッピング完了：
- 全データに基づくカウント：
- トーンが適切：
- 個人情報なし：
- クレームが正当：
- MCP検証：
- 入力準備完了：