自社アプリの App Store と Google Play のレビューを毎朝集めて不具合・要望・質問に分け、不具合は既存のチケットと照らして開発の Jira に起票する

処理の起点を決める

Schedule Trigger で毎朝8時に動かします。 公式ページでは、ワークフローに時間帯の設定が無ければ n8n のインスタンスの時間帯に従い、自前で置いた場合の既定は America/New York とされています。ワークフローの設定で Asia/Tokyo を指定します。

1日1回で足りるのは、Google Play の API の取れる範囲に余裕があるからです。 公式ページでは、API で取れるのは利用者が直近1週間に作成または更新したレビューだけで、それより古いものは Play Console から CSV で落とす必要があるとされています。毎日取れば、n8n が数日止まっても取りこぼしません。 1週間を超えて止まったときは、Play Console の CSV で埋めます。

更新の直後の数日は、昼にもう1回動かします。 不具合の報告が集中する時期に、開発に届くのを半日早めるためです。Schedule Trigger には複数の時刻を設定できます。

入力データを集める

質を決めるのは、いちばん下の「仕分けの説明」です。 Text Classifier の公式ページは、区分ごとに名前と説明を書き、意味が明らかでないときは説明が精度を左右するとしています。「不具合」とだけ書くと、「この機能が無いのは不具合だ」という要望が不具合に入ります。

Android のレビューの版と端末は、付かないこともあります。 公式ページでは、端末などの情報は一部の結果にだけ現れるとされ、投稿者名もまれに欠けるとされています。欠けた項目は空のまま扱い、AIに補わせません。

データの取得方法を決める

iOS は、作成日時の新しい順に取って、前回取った日時より古いものが出たら止めます。 公式ページでは、customerReviews の sort に -createdDate を指定でき、1回に返す件数の上限（limit）は200、filter[rating] で星を絞れるとされています。返す項目は rating・title・body・reviewerNickname・createdDate・territory などで、版や端末の項目はありません。

App Store Connect のトークンは、呼ぶたびに作り直します。 公式ページでは、JWT は ES256 で署名し、aud は appstoreconnect-v1、有効期限が20分より先のトークンは（一部を除き）無効とされています。n8n では、JWT ノードの Sign で期限を短く切ったトークンを作り、HTTP Request の Authorization ヘッダーに入れます。秘密鍵は資格情報に入れ、ワークフローの中に書きません。

Android は、1ページ100件で取り、次のページの印をたどります。 公式ページでは、既定は1ページ10件で、maxResults で100件まで増やせ、次のページは nextPageToken を token に渡して取るとされています。読み取りの上限はアプリごとに1時間に200回なので、1日1回では届きません。

同じレビューIDが、最終更新の日時を変えて戻ってきたら「編集」です。 利用者が星や本文を書き直すと、Android では最終更新の日時が変わります。編集されたレビューは仕分けをやり直し、既にチケットに追記していれば、そのチケットに「レビューが編集された」と追記します。

AIへ渡す前に整形する

1. 形をそろえる … 両ストアのレビューを、ストア・レビューID・星・本文・日時・国または言語・版・端末の共通の形にします。iOS の版と端末は null にします
2. 重複の除外 … Data Table と照らし、取り込み済みで更新の無いものを外します
3. 伏せ字 … 電話番号・メールアドレス・会員番号らしい文字列を [MASKED] に置き換えます
4. 言語の確認 … 日本語以外のレビューは、仕分けの前に印を付けます。Android は API の翻訳の指定で日本語訳を取れます
5. 短すぎるもの … 「最高」「ダメ」のような数文字のものは、AIに渡さず「その他」にします

3番目は、Jira に個人の情報を流さないためです。 利用者は「サポートに連絡したのに返事が無い、[email protected]」のように連絡先を書くことがあります。チケットは社内の多くの人が読むので、ここで伏せます。 投稿者名もチケットには写しません。

4番目の翻訳は、Android だけの機能です。 公式ページでは、translationLanguage を付けると本文を訳して返し、原文は originalText に入るとされています。iOS の外国語のレビューは、原文のまま渡します。

AIに処理させる

まず Text Classifier に、4つの区分のどれかを選ばせます。 公式ページでは、区分ごとに名前と説明を持たせ、既定では1件に1つの区分を選び、どれにも当たらないときに「Other」の出力に分ける設定があるとされています。既定の動作は「捨てる」なので、必ず Other に出す設定に変えます。

説明の最後に、迷ったときの順を書きます。 不具合の報告を含むなら、要望や感想が混ざっていても不具合を選ぶ、と書きます。不具合を他の区分に落とすと、開発に届きません。

次に、不具合のレビューだけを Basic LLM Chain に渡し、中身を抜き出させます。

指示内容を固定する

Basic LLM Chain のシステムメッセージに、次のように書きます。

あなたは家計簿アプリのサポート担当として、ストアのレビューのうち
「不具合の報告」と仕分けられたものから、開発に渡す情報を抜き出します。

【入力】
- レビュー（ストア、星、本文、日時、版、端末、OSの版。無い項目は null）
- 社内の画面・機能の一覧（ID と名前）
- 開いているレビュー起点のチケットの一覧（キー、要約、症状、画面、版）

【抜き出すこと】
1. symptom: 何が起きたかを1文で。利用者の言葉をできるだけ残してください。
2. feature_id: 画面・機能の一覧から1つ。分からなければ "unknown"。
3. action: 何をしたときに起きたか。書かれていなければ null。
4. match: 開いているチケットのうち、同じ不具合と言えるもののキー。無ければ null。
5. match_confidence: "same" / "similar" / "none"

【厳守事項】
- 版、端末、OSの版は、入力の値をそのまま使ってください。
  null のときに推測で埋めないでください。本文に書かれていても、
  入力が null なら reported_in_text に本文の言葉を写すだけにしてください。
- 同じ画面の不具合というだけで same にしないでください。
  症状と操作がそろって同じと言えるときだけ same にしてください。
- 重大度、優先順位、原因は書かないでください。
- [MASKED] の中身を推測しないでください。
- 不具合の報告でないと判断したら、is_bug を false にして他の項目を空にしてください。

「本文に書かれていても、入力が null なら写すだけ」が要の一文です。 iOS のレビューに「最新版にしたら落ちる」とあっても、利用者の言う「最新版」がどの版かは分かりません。 推測で版を入れると、開発はその版で再現を試して時間を使います。本文の言葉は reported_in_text に残し、版の欄とは分けます。

「同じ画面というだけで same にしない」も効きます。 書かないと、レシートの撮影についてのレビューを全部ひとつのチケットにまとめます。別の不具合が1つのチケットに混ざると、片方を直したときに閉じられてしまいます。

出力形式を固定する

Structured Output Parser で、次の形に決めます。 公式ページでは、JSON の例から生成するとすべての項目が必須として扱われ、JSON Schema で定義することもできるとされています。

{
  "review_id": "",
  "store": "app_store | google_play",
  "is_bug": true,
  "symptom": "",
  "feature_id": "",
  "action": null,
  "app_version": null,
  "device": null,
  "os_version": null,
  "reported_in_text": "",
  "match": null,
  "match_confidence": "same | similar | none"
}

1つ目の理由は、match_confidence で案の形を変えられることです。

2つ目は、版と端末を API の値で上書きできることです。 ワークフローは、AIの出力の app_version・device・os_version を前処理でそろえた値で必ず上書きします。AIが指示に反して埋めても、チケットに入るのは API の値だけです。

3つ目は、チケットの書き方がそろうことです。 新規のチケットは、要約・症状・操作・画面・版・端末・ストア・星・レビューの日時の欄を毎回同じ順で埋めます。開発が再現の条件を聞き返す回数が減ります。

システムへ連携する

Jira へは、Jira Software ノードで書き込みます。 公式ページでは、Issue に作成・取得・更新などの操作、Issue Comment にコメントの追加などの操作があります。新規のチケットは「レビュー起点」のラベルを付けて、開発の受付の状態で作ります。 優先順位の欄は空のままにし、開発が決めます。

担当への確認には、Slack の Send and Wait for Response を承認の形で使います。 公式ページでは、Slack の中で承認・却下でき、承認できる人を指定でき、誰が応じたかが出力に残るとされています。n8n が Slack から公開の HTTPS で届くこと、Interactivity の受け口の登録、資格情報の Signing Secret が要るとされています。

Google Play のサービスアカウントには、レビューの権限を付けます。 公式ページでは、サービスアカウントで使う場合はそのアカウントに「レビューへの返信」の権限を有効にするとされています。返信は投稿しない構成でも、この設定を済ませておきます。

人が確認する

サポートの担当が、Slack に届いた不具合の案を確かめます。

1. similar を先に見る … 候補のチケットを開き、症状と操作が同じかを見て、追記か新規かを選びます
2. none の新規の案を見る … 要約と画面が合っているかを見ます。版が空の iOS のレビューは、空のまま登録します
3. same の追記の案を流し見る … 追記の先が合っていれば登録します
4. Other と質問の一覧を見る … Other の行き先を決め、質問には管理画面から返信します

1番を先にするのは、ここが重複のチケットの出どころだからです。 似ているが言い切れないものを新規で登録すると、開発に重複が届きます。迷ったら追記にし、開発がチケットを分けます。 分けるより、まとめたものを探すほうが手間です。

目標は、900件をならして1件1分です。 不具合の案は1件2〜3分、その他は集計に入るだけで人は見ません。

例外に対処する

最後の行は、組む前に決めておいてください。 不具合の入った版を出した翌朝は、同じ症状の案が数十件届きます。1件ずつ承認を求めると、担当は中身を見ずに押し始めます。 症状が同じものを1つの案にまとめ、件数を添えて送ります。

記録を残す

• 取り込んだレビューID、ストア、最終更新の日時、伏せ字にしたか
• 仕分けの結果（区分、Other に出たか）
• 不具合の抜き出しの結果と、照合した既存チケット、match_confidence
• 担当の選択（登録する／しない、追記か新規か）と、応じた人と時刻
• 作ったチケットのキーと、追記したコメント
• 区分ごと・画面ごとの日々の件数

最後の行で、新しい版を出した翌日から画面ごとの不具合の件数を毎朝見られます。