CaseFlow × ChatGPT × Sentry × GitHub：問い合わせを「返信」ではなく改善パイプラインに変える

問い合わせ対応の失敗は、「返信した時点で終わる」ことから始まる

ユーザーから不具合報告や要望が届いたとき、返信してクローズすると、その場の対応は終わります。

しかしプロダクト側には何も残らないことがあります。

• 同じ質問が何度も来る
• 同じ不具合が別表現で報告される
• 重大障害なのに「問い合わせ1件」として埋もれる
• 修正したのにユーザーへ返答されない
• FAQを直せば消える問い合わせが毎週発生する

CaseFlowを単なる問い合わせ管理にすると、メールボックスが少し整うだけです。

価値が出るのは、問い合わせを製品改善の入口として扱ったときです。

ここでは役割を分けます。

• CaseFlow：ユーザー起点のケースを正本として保持する
• ChatGPT：自然文を構造化し、重複や論点を整理する
• Sentry：実際に起きた例外・エラー・性能劣化の証拠を補う
• GitHub：修正作業・レビュー・リリース履歴を残す

まず、問い合わせ文を「再現可能な情報」に変える

ユーザーは開発者向けのバグレポートを書いてくれるとは限りません。

たとえば、

昨日から保存できません。何回やってもダメです。前はできてました。

だけ届くことがあります。

この文章をそのまま開発者へ投げても、情報が足りません。

ChatGPTで最低限、次の形に分解します。

項目	内容
種別	不具合疑い
発生時期	昨日から
操作	保存
期待	保存成功
実際	保存できない
過去	以前は成功していた
不足情報	画面、端末、エラー表示、再現率

重要なのはAIに原因を断定させることではありません。

「何が分かっていて、何がまだ分からないか」を分離することです。

「問い合わせ」と「障害」は別物

問い合わせ件数が1件でも、裏で数百ユーザーが同じエラーを踏んでいる可能性があります。

逆に、強い言葉で書かれた問い合わせでも、その人固有の操作ミスかもしれません。

そこでCaseFlow上のケースとSentryの実行時データを突き合わせます。

たとえば、

• 同時刻に同じAPIで例外が急増している
• 特定リリース後からエラー率が上昇
• Androidだけ発生
• あるURLでのみ500が出る

といった証拠があれば、優先度判断の精度が上がります。

つまり、

ユーザーの声 = 主観的証拠

Sentry = 実行時証拠

として両方を見るわけです。

優先度は「声の大きさ」ではなく影響で決める

ケースごとに最低でも次を持つと扱いやすくなります。

• severity：どれほど深刻か
• scope：何人に影響しそうか
• reproducibility：再現できるか
• workaround：回避策があるか
• business impact：売上・契約・継続率への影響

例えば、

ケースA

1ユーザーのみ。見た目が少し崩れる。回避可能。

ケースB

問い合わせは1件だけだが、決済APIで500が増加。全ユーザーに波及可能。

この2つなら、問い合わせ件数ではAとBは同じ「1件」です。

しかし対応優先度はまったく違います。

GitHub Issueを作る前に、重複をまとめる

ユーザーは同じ問題を違う言葉で報告します。

たとえば、

• 保存できない
• 更新ボタンを押しても戻る
• 入力内容が消える
• 編集が反映されない

が、実は同じAPI障害かもしれません。

ChatGPTは、こうした意味上の近さを整理するのに向いています。

CaseFlowではケースを消さず、複数のケースを1つの原因候補へ関連付けます。

そのうえでGitHubには、原因単位でIssueを作ります。

これにより、

問い合わせ10件 → GitHub Issue 10件

ではなく、

問い合わせ10件 → 原因候補2件 → GitHub Issue 2件

にできます。

GitHubへ渡す情報は「ユーザー文」ではなく、検証可能な形にする

良いIssueは次のようになります。

症状

プロフィール保存APIが500を返し、編集内容が保存されない。

期待

保存後、再読み込みしても変更が保持される。

再現

1. プロフィール編集画面を開く
2. Bioを変更
3. 保存
4. 500エラー

証拠

• CaseFlow: 類似報告4件
• Sentry: PUT /api/profile の例外増加
• 発生開始: v1.8.2デプロイ後

完了条件

• 保存成功
• 再読み込みで保持
• 既存ユーザー更新を壊さない
• 対象Sentryイベントが再発しない

ここまで揃えば、AIコーディングエージェントへ渡すことも容易になります。

修正して終わりではない

開発側で修正してmainへmergeしても、CaseFlow側が開いたままならループは閉じていません。

理想の流れは、

問い合わせ → ケース化 → 証拠収集 → 原因特定 → Issue → 修正 → デプロイ → 再確認 → ユーザー返答 → ケース完了

です。

このときCaseFlowのケースには、可能なら

• 関連Sentry issue
• 関連GitHub issue / PR
• 対応バージョン
• ユーザーへの最終返答

を紐づけます。

これで「直したはずなのに誰も返事していない」が減ります。

本当に見るべきKPI

サポート業務では、単に返信速度だけを見ると危険です。

返信が速くても、同じ問い合わせが毎週来れば改善していません。

見るべき指標は、たとえば次です。

• 初回応答時間
• 解決時間
• 同一原因の再発件数
• 重複ケース率
• 問い合わせ → 製品改善への転換率
• 改善後に消えた問い合わせ件数
• 修正後の再オープン率

特に強いのは、**「この改善によって問い合わせが何件消えたか」**です。

サポートコスト削減とプロダクト品質を同じ指標で見られます。

AIに任せてよいこと、任せないこと

任せやすい

• 要約
• 情報抽出
• カテゴリ候補
• 類似ケース候補
• 不足情報の洗い出し
• 返信案
• GitHub Issueの下書き

人間または明示ルールが必要

• 補償判断
• 法的責任が絡む返答
• 重大障害の最終判定
• 顧客ごとの契約優先度
• セキュリティ事故の公開判断

AIは整理速度を上げられますが、責任の移譲先ではありません。

CaseFlowの本当の価値

CaseFlowが「問い合わせ箱」で終わるなら、Gmailやフォームとの差は小さいです。

しかし、

• ユーザーの声
• 実行時証拠
• 開発タスク
• 修正履歴
• 最終返答

を1つのケースから追えるなら、意味が変わります。

CaseFlowはサポートツールではなく、外部の現実をプロダクト改善へ変換する入口になります。

次の一手

直近20件の問い合わせを使って、まず次を試します。

1. ChatGPTで構造化
2. 意味上の重複をまとめる
3. Sentryで裏付け可能なものを探す
4. 原因候補ごとにGitHub Issueへ集約
5. 修正後にCaseFlowへ戻して閉じる

そこで「20件の問い合わせが、実際には何個の原因へ集約されたか」を測る。

この比率が高いほど、単に返信を速くするより、原因を潰す方が効くことが見えてきます。