問い合わせと商談で出た要望を毎月まとめて、製品開発へ渡す一覧にする

処理の起点を決める

チケットがクローズされたときと、商談メモが登録されたときの2つを起点にします。

月末にまとめて処理しないでください。 これがBeforeの（d）の原因です。クローズの直後に処理すれば、対応履歴の文脈がそのまま残っています。担当者に確認したいことがあれば、その場で聞けます。

クローズを起点にする理由は、対応の途中では要望かどうか判断できないためです。「こういう機能はありませんか」という質問が、実は既存機能でできることだった、という場合があります。対応が終わってから見れば、それが要望なのか単なる質問なのかが分かります。

商談メモは、営業がCRMへ登録した時点で処理します。営業に「要望フラグ」を立てさせないでください。 立て忘れが起きます。全件を通して、要望が含まれるかを機械が判定します。

入力データを集める

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

対応履歴： 問い合わせ管理システムのAPIで取得します。社内メモと顧客向けメッセージを区別できるかを確認してください。 要望は顧客の発言の中にあります。担当者が社内メモに書いた「この機能あればいいのに」は、担当者の意見であって顧客の要望ではありません。区別できないと、この2つが混ざります。

顧客情報： 契約金額と契約更新日を取得します。「更新が3か月後に迫っている顧客からの要望」は、重みが違います。 ただし、金額の大きい顧客の要望だけを通す運用にすると、製品が特定の顧客向けに歪みます。材料として出すだけにとどめてください。

製品の機能一覧とリリース予定： 要望の判定に使います。「すでにある機能を知らないだけ」という問い合わせを、要望として拾わないためです。また、「すでに開発中」の要望は、一覧では別扱いにします。

この2つが古いままだと、この構成の精度が落ちます。 月1回の更新で構いませんが、更新する担当を決めてください。

AIへ渡す前に整形する

1. 社内メモの分離 … 顧客の発言と担当者の発言を分けます。要望の抽出は顧客の発言だけを対象にします
2. 署名・引用の除去 … メールの署名と、過去のやり取りの引用を落とします。引用を残すと、同じ要望を何度も数えます
3. 定型文の除去 … 「いつもお世話になっております」のような挨拶と、システムからの自動返信を除きます
4. 自社製品名の正規化 … 製品名の略称・旧名称を正式名称にそろえます。「旧・A製品」と「A」が別の要望としてまとまらないのを防ぎます
5. 長い履歴の絞り込み … 10往復を超える場合、要望が出やすい箇所（顧客の最初の発言と、最後の2往復）に絞ります

AIに処理させる

2つの工程に分けます。間にフィルタを置くことが、費用の面で重要です。

要望を見つける工程（1回目の呼び出し・全500件）：

要望を構造化してまとめる工程（2回目の呼び出し・約150件）：

「現状の回避策」を取ることが、この構成の質を分けます。 「一括編集がほしい」だけでは、開発は動けません。「毎月200件を1件ずつ画面で変更しており、1人日かかっている」まで分かれば、優先度の判断ができます。

要望の実現可否や、作るべきかどうかは判定させません。 「技術的に難しいと思われます」といった記述を書かせないでください。

指示内容を固定する

要望を見つける側の指示は次のようになります。

あなたはプロダクト企画を支援する担当者です。
下の対応履歴に、製品への要望が含まれているかを判定してください。

【厳守事項】
- 判定の対象は、顧客の発言だけです。[社内] の印が付いた担当者の発言は対象外です。
- 要望とは「現在の製品ではできないこと、またはやりにくいことを、
  こうしてほしいと顧客が述べているもの」です。
- 次のものは要望に含めないでください。
  ・下の「製品の機能一覧」にすでにある機能についての質問
  ・設定方法や操作方法の相談
  ・不具合の報告（動くはずのものが動かない）
  ・料金や契約条件についての希望
- 要望が含まれる場合、該当する顧客の発言を**原文のまま**抜き出してください。
  要約したり言い換えたりしないでください。
- 1つの履歴に複数の要望が含まれる場合、すべて抜き出してください。
- 判断に迷う場合は has_request を "unclear" にし、理由を書いてください。
  **無理に要望として拾わないでください。**

【対応履歴（社内メモには [社内] の印あり）】
{conversation}

【製品の機能一覧】
{feature_list}

要望を構造化する側の指示は次のようになります。

下の要望を、開発が読んで判断できる形に整理してください。

【厳守事項】
- 顧客の発言に書かれていることだけを使ってください。
  書かれていない業務の事情や件数を補わないでください。
- 「現状の回避策」は、顧客が実際に述べた場合だけ書いてください。
  述べていない場合は null にしてください。**推測で書かないでください。**
- 下の「既存の要望一覧」に同じ内容の要望があるかを判定してください。
  言い方が違っても、望んでいる状態が同じなら「同じ」としてください。
  例：「一括編集したい」と「複数選択してまとめて変更したい」は同じです。
  例：「一括編集したい」と「編集履歴を見たい」は違います。
- 同じかどうか迷う場合は match_status を "unclear" にしてください。
  **迷ったまま既存へまとめないでください。後から分けるのは手間がかかります。**
- 要望の実現可否、開発の難易度、優先度を書かないでください。
  判断はプロダクト企画が行います。
- 要望の表題は20字以内で、顧客の言葉に近い形にしてください。
  社内用語に置き換えないでください。

【抜き出された要望（原文）】
{extracted_request}

【顧客の情報（プラン・契約金額・更新日）】
{customer_context}

【既存の要望一覧（内容が近いもの・上位10件）】
{existing_requests}

「同じかどうか迷う場合は unclear」の指示が効きます。 まとめすぎると、開発が読んだときに「これは別の話だ」となります。分かれているものを後から統合するのは簡単ですが、統合されたものを分けるのは元の発言を追い直す必要があり、手間がかかります。

もう1つ、粒度の問題があります。 「操作性を良くしてほしい」という要望と、「この画面の保存ボタンを上に置いてほしい」という要望が、同じ一覧に並びます。前者は件数が積み上がりますが、開発は着手できません。 後者は件数が少なくても、すぐ直せます。

粒度をそろえる指示を入れると、今度は逆の問題が起きます。大きい要望を小さく分割させると、顧客が実際に言ったことから離れます。 対処は、粒度を分類として持つことです。

【粒度の分類】
- specific ... 特定の画面・機能・操作についての要望。何を直すかが読める
- general ... 製品全体や使い勝手についての要望。方向の話であり、具体策は含まない

【厳守事項（追加）】
- granularity に specific か general を入れてください。
- general の要望を、勝手に specific へ言い換えないでください。
  「操作性を良くしてほしい」を「ボタンの配置を変えてほしい」と解釈しないでください。
- general の要望どうしをまとめる場合、望んでいる方向が同じかで判断してください。

general の要望は、件数を数える対象から外すという運用もありえます。 「操作性」に50件集まっても、何を作るかは決まりません。むしろ、その50件の原文を読むことに意味があります。 一覧では別枠に置き、四半期に1回、原文をまとめて読む時間を取るほうが使えます。

「社内用語に置き換えない」も必要です。 「一括編集」を社内の呼び方で「バルクオペレーション」と書くと、顧客の言葉が消えます。顧客がどう呼んでいるかは、それ自体が情報です。

出力形式を固定する

1回目の呼び出しの出力：

{
  "ticket_id": "",
  "has_request": "yes | no | unclear",
  "reason": "",
  "extracted_requests": [
    { "quote": "", "speaker": "customer", "position_in_thread": 0 }
  ]
}

2回目の呼び出しの出力：

{
  "ticket_id": "",
  "request_title": "",
  "what": "",
  "when_scene": "",
  "why": "",
  "current_workaround": "",
  "category": "機能追加 | 既存機能の改善 | 性能 | 連携 | その他",
  "match_status": "new | existing | unclear",
  "matched_request_id": "",
  "match_reason": "",
  "customer": {
    "name": "",
    "plan": "",
    "contract_value": 0,
    "renewal_date": ""
  },
  "source": "support | sales",
  "original_quote": ""
}

JSON Schema を指定して出力を固定します。Claude API では output_config.format にJSONスキーマを渡すことで、応答をスキーマに沿った形に制約できます。

original_quote を必ず残してください。 月次の会議で「この要望は具体的にどういう話ですか」と聞かれたとき、原文があれば答えられます。要約だけが残ると、元の文脈が永久に失われます。

match_reason も重要です。「どちらも複数の項目をまとめて変更したいという内容のため」と書かれていれば、まとめ方が妥当かを人が検証できます。

システムへ連携する

要望一覧をスプレッドシートに作ります。2つのシートに分けます。

要望マスタ（1要望1行）：

発言明細（1発言1行）：

要望マスタから展開して見る形にします。チケットID、顧客名、原文、出所（サポート／営業）が並びます。

件数と顧客数を分けて持つことが重要です。 同じ顧客が5回言った要望と、5社から1回ずつ出た要望は、意味が違います。前者は1社の困りごと、後者は共通の課題です。

開発の課題管理システムへの自動登録はしません。 着手が決まったものだけを、人が登録します。未検討の要望が課題管理システムに大量に流れ込むと、開発側が使えなくなります。

着手が決まった要望については、顧客の一覧を出します。 サポートが「以前いただいたご要望について、対応することになりました」と返せます。これがBeforeの（f）への対処です。

人が確認する

まとまり方の確認は、全件、プロダクト企画の担当が行います。

理由は、まとめ方の誤りが後から効いてくるためです。別の要望が1つにまとめられると、件数が実態より多く見え、誤った優先度が付きます。 逆に分かれすぎると、本当は同じ話なのに件数が少なく見えます。

確認の深さを分けます。

• match_status が unclear のもの … 全件、人が判断する
• 件数が急に増えた要望 … まとめ方が正しいかを確かめる
• has_request が unclear のもの … 要望かどうかを人が見る
• 新規に立った要望 … 表題と構造化の内容を読む
• 既存要望への加算 … 抜き取りで確認する。全件は見ない

確認を速くするための設計が効きます。

• unclear の行を最上部に集める
• 新規要望と既存への加算を分けて表示する
• まとめられた発言の原文を、並べて表示する（同じ話かが一目で分かる）
• 件数と顧客数を並べて表示する
• 初出日からの経過日数を表示する（古い要望が放置されていないか）

例外に対処する

記録を残す

この記録は、製品の意思決定の経緯になります。

• 抽出された要望の原文（顧客の発言そのまま）
• 構造化の結果と、まとめた根拠
• 人が分割・統合した場合、その前後と理由
• 要望ごとのステータスの変化と、その日付
• 見送った要望と、見送りの理由
• 着手が決まった要望と、顧客への返答の記録

「見送りの理由」を残すことが特に効きます。 半年後に同じ要望が上がってきたとき、前回なぜ見送ったかが分かれば、再検討すべきかの判断が速くなります。理由が残っていないと、毎回ゼロから議論します。

原文の保存は、顧客の発言を含みます。 保存期間と閲覧範囲を、問い合わせ履歴の管理方針に合わせて決めてください。