feedback-analysis

feedback-analysis

まず using-appfollow を読んでください。このスキルは読み取り専用です。書き込みペアを呼び出すことはありません。

入力

• scope： アプリ（ext_id+store）、コレクション全体、または1つのコレクションからユーザーが選択したアプリのサブセット（例：「 からこの3つのアプリだけ」）。1つのレポートで複数のコレクションを対象にすることは、まだサポートされていません（今後対応予定）。
• window： デフォルトは直近30日間。比較対象は、その直前の同じ期間です。
• country / lang（任意）。
• depth： quick | standard | deep = 1回の取得あたりの get_reviews ページ上限が2／5／10です。コレクション全体の取得では上限が1回適用され、アプリ単位とサブセットの取得ではアプリごとに適用されます。デフォルトは deep です。 quick／standard は、ユーザーから明示的にリクエストされた場合にのみ使用します。
• テストのフィードバック（任意、Google Play のみ）：クローズドまたはオープンのテストトラックでテスターが残した内容です。レビューとは別のセットで、デフォルトでは無効です。ユーザーから明示的にリクエストされた場合にのみ取得します（Gather のステップ D）。

2つのティア、実行時にプローブ

公開されているツール一覧を読み、プランを選択してください（ツールキットと MCP のリリース系列は独立しています）。

• ティア A（常時）： whoami、list_collections、list_apps、get_reviews、get_ratings_history。
• ティア B（プローブで利用不可と判明した場合は縮退）： reviews_semantic、get_reviews_summary、get_reviews_ai_summary。
• 縮退可能、アプリレベル（プローブで有無を判定するティアではありません）： get_gp_console_ratings — 縮退ルールについては Gather のステップ B を参照してください。

Gather

0. セッション（using-appfollow）。 A. スコープの解決。 ext_id のみが指定されている場合でも、コレクションの検索は必須です。get_reviews、 get_reviews_summary、get_gp_console_ratings にはコレクションの apps_id（list_collections の collectionId）を指定し、get_reviews_ai_summary にはコレクションの collection_name（collectionCode）と store を指定します。list_apps（apps_id）から、各アプリの extId（ext_id 引数）を取得できます。また、 store は正式名称で返されるため、store 引数を指定する前に短縮コードへ変換してください（using-appfollow → references/tool-map.md）。コレクション全体を対象とする場合は、そのコレクションに属するアプリ（list_apps の isCompetitor: false）のみを対象にします。以下のアプリ単位の呼び出しは、すべてそのアプリに対して実行して ください。一部を対象とする場合は、list_collections でコレクションを解決し、list_apps でそのアプリを一覧表示してから、 選択したアプリのみのデータを収集します。scope.type: "collection_subset" を出力し、collection_name を設定して、 apps にはコレクション全体ではなく選択したアプリを設定してください。 B. まず低コストの集計を実行します。 アプリごとに、両方の期間をカバーする get_ratings_history を1回呼び出します （ext_id と短縮形の store、period=daily、type=total、country は1つ。ユーザー指定の国があればそれを、 なければ all）。全期間のデータが1回の呼び出しで返されるため、ページ分割は不要です。クライアント側で分割して ください。現在の期間について、Cのステップのスコープで get_reviews_summary（Tier B）を1回呼び出します （apps_id。Cのステップでアプリ単位の取得を行う場合は ext_id も指定）。total.value、previous、diff には 現在の期間と、その直前の同じ長さの期間のデータが含まれます。また、total.value はCのステップで取得する レビューの件数を見積もるために使用します。レビューの各ページには合計件数が含まれません。 get_gp_console_ratings（apps_id と各Google Playアプリの ext_id、レポート期間の from と to、 fields: ["ratings"]）は取得できない場合があります。Google Play Consoleがアプリに接続されていない場合や、 サーバー側で機能を利用できない場合があります。エラー（FEATURE_DISABLED、VALIDATION_ERROR、 UNKNOWN_TOOL、その他のエラー）が発生した場合、またはレスポンスが空の場合は、GP Consoleの評価シグナルを省略し、 レポートに欠落を記載して続行してください。App Storeの評価履歴の取得には影響しません。この呼び出しを理由に 分析全体を失敗させないでください。 C. ナラティブ。 アプリごとに、レポート期間の from と to、アプリの ext_id、コレクションの collection_name（collectionCode）、短縮形の store を指定して get_reviews_ai_summary を呼び出します （エラーが発生した場合はスキップしてください。AIサマリー機能が利用できない場合は、FEATURE_DISABLED または ACCESS_DENIED が返されます）。 reviews_semantic — クライアント側の分類を第一の代替手段とします。続いて、get_reviews で生のレビューを ページ単位で取得します。コレクション全体の場合は1回の取得（apps_id、ext_id なし。対象はそのコレクションに 属するアプリのみで、コレクションの競合アプリは除外されます）、アプリまたは一部のアプリを対象とする場合は アプリごとに1回取得します（apps_id と ext_id）。各 nextCursor を cursor として渡してページを取得し （引数は同じ）、深度上限に達するまで続けます。nextCursor が null または存在しない場合は、それより前に 終了します。Bのステップで得た合計件数に対する取得率を記録してください（references/method.md）。 D. テストフィードバック（オプトイン、Google Play）。 これは別のレビューセットです。Google Playアプリで get_reviews を呼び出すと、通常は公開レビューのみが返されますが、testing_feedback: true を指定すると、 テストフィードバックのみが返されます（typeList: ["beta"]）。1回の呼び出しで両方を取得することはできず、 公開レビューのセクションに統合してはなりません。テスター、ベータ版、テストトラックのフィードバックを明示的に ユーザーが求めた場合にのみ実行してください。レポート期間について、Google Playアプリごとに get_reviews を 別途呼び出し、各呼び出しにコレクションの apps_id、そのアプリの ext_id、testing_feedback: true を指定します。 ページ分割と深度上限はCのステップと同じです。他のストアではこのフラグは無視され、常に公開レビューが返されるため、 対象外としてください。ワークスペース全体に対して true を指定してはならず、typeList に beta を含むレビュー のみを対象にしてください。get_reviews の引数に testing_feedback が含まれていない場合は、このステップを スキップしてその旨を記載してください。このフラグに対応していないサーバーでは、公開レビューが返されます。 結果が空でもエラーではありません。期間内にテストフィードバックがない場合、またはAppFollowにGoogle Play Consoleが 接続されていない場合がありますが、ツールはそのどちらかを示しません。結果は空として報告し、再試行しないでください。 ユーザーがテスターからのフィードバックのみを求めた場合は、ステップ0、A、Dを実行し、BとCはスキップして、 テスト用セクションのみを出力してください。公開レビューとは分けて分析してください（references/method.md）。

分析

references/method.md に従います。KPI と増減、日次平均と 7 日間の移動傾向、明示的なしきい値を用いた異常検出ヒューリスティックを確認します。バグ／機能の抽出は、セマンティック分析を優先し、デフォルトのフォールバックとしてクライアント側で分類します。カバレッジによるゲーティングを適用し、テキスト由来の調査結果が 60% の基準を下回る場合は、「参考情報のみ」に格下げします。評価由来の調査結果には、カバレッジによるゲーティングを適用しません。各アプリの評価件数（最新の get_ratings_history 行の starsTotal）に基づいてロールアップの重みを付け、アプリをまたぐクラスターを affected_apps に統合します。

エラー時の対応（using-appfollow）

INSUFFICIENT_CREDITS の場合は停止し、カバレッジに関する注記を含む部分的なレポートを出力します。RATE_LIMITED の場合は、バックオフを 1 回行ってから続行します。重要でない呼び出しで NETWORK_ERROR／UPSTREAM_ERROR が発生した場合は、そのセクションをスキップして処理を続行します。Tier-B ツールがない場合は、文書化されたフォールバックを使用します。1 つのツールのエラーでレポート全体を失敗させないでください。

出力

./appfollow-reports/<report_id>/ に書き込みます。

1. findings.json — appfollow.toolkit.findings/v1、report_type:"feedback"。書き込む前に schemas/findings.schema.json に照らして検証します。各調査結果には、安定した id、type、title、description、severity、priority_hint、affected_apps、metrics、evidence（レビュー ID を用いた、200 文字以下の引用 3～5 件。パーマリンクの方式はありません）、suggested_labels、安定した dedup_key（再実行時に重複を作成せず更新できるようにするため）、status:"proposed" を含めます。
2. report.html — references/report-template.html に内容を入力します。SVG チャートはインラインで埋め込み、外部リクエストは行いません。
3. report.md — 同じ内容を Markdown 形式で記載します。

Claude Code では、HTML アーティファクトも公開します。Codex では、ファイルを書き込み、そのパスを伝えます。

調査結果の引き継ぎ

ユーザーには、接続済みのトラッカーエージェントを使って、自身のトラッカーに findings.json を登録できると伝えます。このツールキットからトラッカーにアクセスすることはありません。