ユースケース

App Store レビューを国別に分析してバグと機能要望を洗い出す

Q: アプリの ID はどうやって調べますか？

アプリの App Store URL の末尾にあります。上の例のように、id の接頭辞を付けずに渡してください。

Q: 複数の国のレビューを読めますか？

はい。country は 1 回のリクエストにつき 1 つのストアを受け取るため、国ごとに 1 回ずつ実行します。入力は多数の国コードに対応しており、既定値は us です。

Q: 1 回の実行で複数のアプリのレビューを取得できますか？

はい。appIds はリストなので、自社アプリと競合のアプリを 1 つのリクエストで渡せます。maxItems と max_results は合計数を考えて設定してください。

Q: 1 回の実行で何件のレビューを返せますか？

最大 500 件です。入力の maxItems に、必要な件数を設定してください。

任意のアプリ ID と国の App Store レビューを JSON で取得し、バグ・機能要望・不満に仕分けて、プロダクトのロードマップに役立てます。

API キーを取得ドキュメントを読む

プリペイド、サブスクなしREST でも MCP でもモデル・データ・エージェントを 1 つのキーで

サポートの問い合わせキューに現れるのは、声の大きな問題だけです。それ以外は App Store のレビューに眠っています。特定の iPhone 機種で起きるクラッシュ、ある国だけで要望が集中する機能、ユーザーが名指しで挙げる競合の機能などです。手作業で読めるのは数十件が限界でしょう。Lovely Router がそれを代わりに取得します。アプリ ID と国を送れば、レビュー 1 件につき 1 つの JSON オブジェクトが返り、課金はプリペイド残高からレビュー 1 件ごとです。

AI エージェントに任せる

このプロンプトを Claude Code、Cursor、Codex などのコーディングエージェントに貼り付けてください。ドキュメントの場所と API キーの使い方をエージェントに伝えます。

App Store レビューを国別に分析してバグと機能要望を洗い出す. Use the Lovely Router data tools: each returns JSON and is billed per result.

- Docs (read first): https://lovelyrouter.com/docs/tools/find.md and https://lovelyrouter.com/docs/tools/run.md
- Plan first: POST https://lovelyrouter.com/v1/tools/suggest with `{"task": "<my task in plain words>"}` (free). It returns the tools to run in order, each with an example `input`, the `input_required` fields, an estimated cost and a ready-made `run` request. Replace the example values with my task's; if a field is unclear, read the tool with GET https://lovelyrouter.com/v1/tools/<id>. To browse instead, POST https://lovelyrouter.com/v1/tools/discover searches the catalog.
- Show me the plan and its estimated cost (`total_est_cost_usd`) before running anything large.
- Run: POST https://lovelyrouter.com/v1/tools/<id>/run with `{"input": {...}, "max_results": N}`. A 200 has the finished run with `items`; a 202 means it is still running, so poll the `poll` path until `status` is `succeeded`, `failed`, `timed_out` or `stopped`.
- Only delivered results are billed. Keep max_results small on the first run, check the output, then scale up.
- If you support MCP, connect https://lovelyrouter.com/mcp instead (Streamable HTTP, same key; https://lovelyrouter.com/docs/tools/mcp.md) and use suggest_tools, get_tool and run_tool.
- Auth: read my API key from the LOVELY_API_KEY environment variable and send it as `Authorization: Bearer $LOVELY_API_KEY`. Never print or commit the key. If it is not set, ask me to create one at https://lovelyrouter.com/app/keys.
- Billing is prepaid: every call is charged to my balance, so test with a small request before running anything large.
- Every docs page is plain Markdown; the full index is https://lovelyrouter.com/llms.txt.

My task: <the inputs (links, keywords or accounts) and how many results you need>

仕組み

アプリと国を選ぶ
アプリの URL の末尾にある App Store ID を、id の接頭辞を除いて取り出します。自社アプリと競合 2、3 本を加え、どの国のストアが重要かを決めます。
上限を付けてツールを実行する
ID と国を POST /v1/tools/app-store-reviews/run に送ります。読みたいレビュー数を、入力の maxItems とリクエスト本文の max_results に設定してください。実行は最大費用を残高から仮押さえし、レビューを JSON で返します。
分類して順位を付ける
バグ、機能要望、価格への不満、称賛といった簡単な基準を付けて、レビューをモデルに渡します。リリースごと、国ごとに各分類を数え、上位の項目をバックログに送ります。

1 回のリクエストで App Store レビューを取得する

App Store レビューは、appIds に App Store ID のリスト、country に 2 文字のストアコードを受け取ります。maxItems でレビュー数の上限を決めます。

Shell

curl https://lovelyrouter.com/v1/tools/app-store-reviews/run \
  -H "Authorization: Bearer $LOVELY_API_KEY" \
  -H "content-type: application/json" \
  -d '{
    "input": {
      "appIds": ["284882215"],
      "country": "us",
      "maxItems": 20
    },
    "max_results": 20
  }'

60 秒を過ぎても実行中の場合は 202 が返ります。ポーリングの方法はツールを実行するをご覧ください。1 回の実行で最大 500 件のレビューを取得できます。

各レビューに含まれる内容

フィールドグループ	取得できる内容
レビュー	App Store に投稿されたままのレビュー
アプリ	レビューが属するアプリ ID
ストア	指定した国のストア

レビューはストアの言語のまま返ります。1 件ずつ読むのではなく、同じ処理の中でモデルに翻訳と分類をまとめて頼みましょう。

レシピ

リリースごとのバグ一覧を作る。

リリースのたびに最新のレビューを取得し、報告されたバグをモデルにすべて抽出させて、症状ごとにまとめます。リリース後数日のうちに多くのレビューに現れる症状が、リグレッションです。

国どうしを比較する。

同じアプリ ID で country を us、de、jp、br にして実行します。1 つのストアにだけ現れる機能要望は、世界共通のニーズではなくローカライズの不足です。

競合の星 1 つのレビューを読む。

ユーザーが流れていく先の 2 本のアプリでレビューを取得し、評価の低いものだけを残して、そのユーザーが何に不満を持っているかを一覧にします。次のリリースで埋められる隙がそこにあります。

サポートチームに共有する。

自社アプリの実行を週次でスケジュールし、新しい不満の要約を、サポートとエンジニアがすでに会話しているチャンネルに投稿します。

変更の前後で感情を測る。

リデザインや価格変更の前と後に実行結果を保存し、平均評価と、変更した部分に関する不満の割合を比べます。

普段の言葉で頼みたい場合は、MCP サーバーを接続して Claude Code や Cursor に次のように伝えます。「アプリ 284882215 の米国ストアのレビューを 200 件取得し、バグ、機能要望、称賛に分類して、それぞれ上位 5 件を見せてください。max_results は 200 に設定してください。」