「顧客の声は宝の山」。そう言われ続けて久しいですが、実態はどうでしょうか。

コールログ、チャット履歴、アンケートの自由記述、レビュー。声は毎日大量に届いているのに、人手でタグ付けして読めているのは全体のごく一部、という組織がほとんどです。

LLMを使えば、この分類と要約を全チャネル・全件で実行できます。実際、LLMのAPIとBIツールを組み合わせれば、動くVOC分析ツールは数日で作れます。作れるかどうかは、もう論点ではありません。

しかし、分析レポートが出ることと、その声が商品や業務を変え続けることは、別の問題です。私たちが見てきた内製プロジェクトの多くは、構築でつまずくのではなく、「分析結果が意思決定に使われ続ける」状態を維持する段階で止まります。

この記事では、内製の7ステップを実務の順番で解説したうえで、本当に難しいのはどこか、そして内製とSaaSをどう使い分けるべきかまで踏み込みます。

全体像：7ステップと「育てるループ」

先に全体像を示します。ステップ1〜2が設計、3〜5が構築、6〜7が検証と運用の入り口です。注目してほしいのは、ステップ7からステップ2へ戻る点線の矢印です。VOC分析ツールは一度作って完成するものではなく、レポートの受け手の反応と「その他」に溜まった未分類の声を分類軸に還流させるループを回し続けることで、初めて意思決定に使われる分析になります。

ステップ1：VOCの「届け先」を決める

最初にやるべきことは、ツール選定でも分類作業でもなく、この分析が誰の意思決定を変えるのかを決めることです。VOC分析の失敗パターンの第1位は、「とりあえず全部の声を分析してみる」です。全部を対象にした分析は、誰の業務にも刺さらない平均的なレポートを生み、静かに読まれなくなります。

届け先の候補は大きく3つあります。商品開発部門への改善要望（どの製品のどこを直すべきか）、CS部門自身の業務改善（FAQやオペレーションのどこを直すべきか）、経営層への顧客体験の定点観測です。それぞれ必要な分類の粒度もレポートの頻度も異なるため、最初は1つに絞ります。

そして、届け先が決まれば、KPIもここで決まります。推奨は分析カバレッジ（全チャネルの声のうち分析された割合）と、後述する「その他」率（既存の分類軸に収まらなかった声の割合）の2つです。

• 例（架空の家電メーカー・C社）：
  コールログ・チャット・アンケート・ECレビューの4チャネルに月間約2万件の声があったが、読めていたのはアンケートの一部だけだった。C社は届け先を「商品開発部門への月次改善要望レポート」の1つに絞り、経営向けダッシュボードは初期リリースの対象外と明記した。

ステップ2：出口から逆算して分類軸を設計する

届け先が決まったら、分類軸（タクソノミー）を設計します。ここで重要なのは、分類の正しさではなく、受け手が動ける粒度になっているかです。「使いにくいという不満：328件」というレポートで商品開発は動けません。「炊飯器X型の内蓋の取り外しに関する不満：47件」なら動けます。

設計の基本は、製品・サービス軸と声の種類（不満・要望・称賛・質問）の2軸に、届け先が動ける粒度のトピックをぶら下げる構造です。このとき、分類学的な網羅性を追求しすぎないことです。MECEで美しい100項目の体系より、受け手が動ける30項目の方が機能します。そしてもう1つ、「その他」を正式なカテゴリとして設計に含めることです。既存の軸に収まらない声こそが新しい問題の兆候であり、「その他」は分類の失敗ではなく、次の分類軸の候補リストです。

• 例：
  C社はベテランオペレーター2名と商品開発のPM2名でワークショップを行い、大分類4×中分類28の初版を作った。基準は「PMがこの項目名を見て、次のアクションを言えるか」。言えない項目は統合するか粒度を下げた。

ステップ3：チャネル横断でデータを集約・整備する

VOC分析の品質は、モデルの賢さよりも入力データの質で決まります。内製プロジェクトで最も時間がかかるのは、実はこのステップです。

やることは3つです。

第一に、チャネルごとにばらばらの形式を正規化することです。コールログは文字起こしの精度と話者分離、チャットは定型文の除去、レビューは重複投稿の処理と、チャネルごとに前処理の論点が異なります。全チャネル同時に始めず、整備の軽いチャネルから着手するのが定石です。

第二に、個人情報のマスキングです。氏名・住所・注文番号などを外部APIに送る前に処理するのか、契約上送ってよいのかを、法務・セキュリティ部門と先に握っておきます。

第三に、メタデータの付与です。どの製品についての声か、いつの声か、どのチャネルの声か。特に製品の紐付けは、表記ゆれ（「炊飯器」「スイハンキ」「X-100」）を製品マスタに正しく寄せられるかが分析の精度を左右します。ここの「正」を1つにしておかないと、同じ製品の声が別々の集計に割れます。

• 例：
  C社は前処理の軽いチャットとアンケートの2チャネルから着手し、コールログは第2期に回した。製品の表記ゆれが激しかったため、型番と通称を対応させる製品辞書300語を先に整備した。個人情報は分析前にマスキングする前処理を挟むことで法務の承認を得た。

ステップ4：分析パイプラインの最小構成を組む

ここから技術の話に入ります。ただし、最初から凝る必要はありません。VOC分析ツールの最小構成は次の4層です。

1. 収集・前処理層：
   各チャネルから声を集め、正規化・マスキング・メタデータ付与を行います。地味ですが分析品質への影響が最も大きい層です
   

2. LLM分類・要約層：
   1件ずつの声を分類軸に沿って分類し、要約と代表的な発言の抽出を行います。分類・要約・抽出を1回のプロンプトでまとめて実行する構成は、実装は楽ですが精度が落ちます。タスクごとに分けて呼び出すのが基本です
   

3. 集計層：
   分類結果をデータベースに格納し、製品別・カテゴリ別・期間別に集計できるようにします
   

4. 表示・レポート層：
   ダッシュボードと月次レポートです。既存のBIツールで十分です。凝った可視化より、受け手が動ける形（件数順のトップ10と代表的な生の声）を優先します

精度が足りない場合の改善手段として、埋め込みベクトルのクラスタリングで「その他」の中から新トピックを発見する方法や、判定の難しいカテゴリだけ複数回分類させて多数決を取る方法があります。ただしこれらは、まず最小構成で動かして一致率を測ってから足すべきものです。最初から全部盛りにすると、どこが効いているのか分からなくなります。

• 例：
  C社は「前処理→分類→要約→集計」をタスクごとに分けたパイプラインを2週間で動かした。ダッシュボードは使い慣れた既存BIツールに接続し、月次レポートは「動ける改善要望トップ10＋各項目の生の声3件」の1枚に絞った。

ステップ5：分類手順書を書く

分類プロンプトというと、カテゴリ名を列挙した短い命令文を想像するかもしれません。しかし実務で機能するのは、新任のVOCアナリストに渡す分類マニュアルに近い文書です。

私たちはこれを分類手順書と呼んでいます。カテゴリの定義から、判定の手順、境界例の扱いまでを1つの手順書として書き上げ、それをそのまま分類プロンプトにする、という考え方です。

手順書で定義すべきことは、大きく4つです。各カテゴリの定義と「含む例・含まない例」、判定の手順（「まず製品を特定し、次に声の種類を判定し、最後にトピックを選ぶ」のように順序を固定する）、出力の形式（分類・根拠となる発言の引用を必ずセットで出力させる）、そして境界例です。

「配送の遅延への不満は製品の不満か、ECの不満か」のような迷いやすいケースは、実例と正解の分類をセットで手順書に載せます。確信が持てない場合は無理に分類させず「その他・要確認」と出力させます。

禁止事項も明文化します。元の声にない内容を要約で補わない。少数の声を「多くの顧客が」と誇張しない。ネガティブな声を要約で和らげない。VOCは意思決定の材料になるからこそ、「声の改変」を防ぐガードレールが信頼を左右します。

• 例：
  C社の分類手順書は、28カテゴリの定義と含む・含まない例に加えて、オペレーター間で判断が割れた過去の実例15件を境界例として収録した。出来上がりは、新任アナリストの研修資料とほぼ同じ構成になった。

ステップ6：人間の分類と突き合わせ、一致率を測る

「なんとなく合っていそう」で運用を始めてはいけません。実際の声から100件程度を抜き出し、分類軸を作ったメンバーが人手で分類した結果とセットにしたキャリブレーションセットを作ります。これに対してAIの分類を突き合わせ、カテゴリごとの一致率を測ります。

このとき先に測っておくべき数字があります。人間同士の一致率です。同じ100件を2人が独立に分類すると、多くの組織で一致率は7〜8割にとどまります。人間同士が75%しか一致しない分類軸で、AIに95%を求めるのは筋違いです。

そして不一致の分析こそが、このステップの最大の成果物です。AIと人間の分類が割れた箇所を見ていくと、AIの間違いと同じくらい、カテゴリ定義の曖昧さや重複が見つかります。あわせて「その他」率も監視します。その他が3割を超えているなら、分類軸そのものが実際の声とずれています。

• 例：
  C社の初回の一致率は74%だった。不一致を分析すると、半分以上は中分類の定義の重複が原因だった。紛らわしい6カテゴリを統合・改訂して再評価したところ、一致率は86%まで改善した。モデルは一度も変えていない。

ステップ7：小さく運用を始め、受け手の反応で育てる

運用は小さく始めます。最初から全部門に配信するのではなく、届け先と決めた部門に月次レポートを届け、翌月に必ずレビューの場を持ちます。

確認することは1つだけです。どの項目が、実際に意思決定に使われたか。使われた項目は残し、読まれなかった項目は粒度を変えるか削る。「その他」に溜まった声から新しいカテゴリを起こす。この受け手の反応こそが、次に磨くべき分類軸のリストです。

月次でこのループを回した分だけ、レポートは「読まれる資料」から「会議の議題を決める資料」に変わっていきます。逆に言えば、このループが止まったVOC分析は、分類軸が実際の声とずれていき、静かに「誰も読まないレポート」になります。

• 例：
  C社の初回レポートでは、28項目のうち商品開発の会議で実際に使われたのは9項目だった。翌月から「動ける改善要望トップ10」形式に改め、使われなかった項目は集計を残しつつレポートから外した。「その他」率は運用3ヶ月で34%から12%まで下がり、その間に新カテゴリを4つ起こした。

内製の壁は「8歩目」にある

動くものは数日で作れても、分類軸の設計や一致率検証まで含めたここまでの7ステップには、エンジニア1〜2名とCS・商品開発の実務者で数週間から数ヶ月かかります。内製の本当の壁はその先にあります。それは、レポートが出続けることと、事業が変わり続けることの間の溝です。

具体的にはこうなります。月次レポートは配信されているが、受け手とのレビューが形骸化し、「読まれない定期便」になる。新製品の発売やキャンペーンのたびに分類軸の改訂が必要なのに、更新が「余裕がある時にやる仕事」に格下げされ、「その他」率がじわじわ上がっていく。LLMのモデルが更新されるたびに分類の傾向が変わり、「先月と今月の件数比較」という VOCの生命線である時系列の一貫性が壊れる。

どれも技術的には解決可能ですが、解決し続けるには専任に近い体制が必要です。作るのは1回のプロジェクトですが、育てるのは終わりのない業務です。内製を検討するなら、構築の工数ではなく、この運用体制を確保できるかを先に問うべきです。

内製かSaaSかを分ける4つの判断軸

内製とSaaS、どちらが正しいという話ではありません。判断軸は次の4つです。

1. エンジニアリソースの常設：
   構築時だけでなく、モデル更新時の再校正や分類軸改訂の実装に継続的にエンジニアを割り当てられるか。割り当てられないなら、その仕組みが製品側に組み込まれているSaaSに分があります
   

2. 商品・チャネルの変化頻度：
   製品ラインナップやキャンペーンの入れ替わりが激しいほど分類軸メンテナンスの負荷が上がり、更新運用の仕組みの差が効いてきます
   

3. 要件の特殊性：
   基幹システムや自社の商品マスタとの深い連携、業界固有の分析観点が中核要件にあるなら、内製の価値が出ます
   

4. コスト構造：
   内製は初期が重く運用も人件費が続く、SaaSは月額が続く。3年の総所有コストで比べると、直感と逆の結果になることがよくあります

実務では二者択一でもありません。アンケートの自由記述は内製で経験を積み、前処理の重いコールログの分析はSaaSに任せる、といった併用は現実的な解です。

私たちは「ダッシュボード」ではなく「届け続けるループ」が本体だと考える

私たちは、VOC分析ツールの本体はダッシュボードでもレポートでもなく、顧客の声を意思決定者に届け、その反応で分類軸を磨き続ける運用のループだと考えています。

だからこそ、内製という選択肢を否定しません。この記事の7ステップを実際にやり切った組織は、「自社にとって聞くべき声とは何か」を初めて厳密に言語化することになり、その言語化はどのツールを使っても資産になります。一方で、そのループを自社で回し続けることが難しいなら、ループそのものを製品として提供するSaaSに任せるのは、撤退ではなく合理的な設計判断です。

あなたの組織が確保すべきなのは、声を分類する技術でしょうか。それとも、声で事業を変え続ける体制でしょうか。内製を検討しているすべてのチームに、この問いを置きたいと思います。

分析から意思決定への接続までを含めたVOC活用の設計に関心のある方は、お気軽にお問い合わせください。