VOC（Voice of Customer）は、商品・サービスや利用体験に対する顧客の意見、要望、疑問、不満などの「顧客の声」です。問い合わせ、アンケート、営業メモ、レビュー、公開SNS投稿など、声が残る場所は一つではありません。重要なのは大量に集めること自体ではなく、「どの声を、誰が、何の判断に使うか」を決め、改善後にも確認できる形で残すことです。
この記事はVOCとは何か、社内外のデータをどう区別し、継続的な改善の仕組みにするかを扱います。AIで口コミを分類した実測例や、特定のSNS・ECサイトの操作手順は別記事に任せます。Octoparseが担えるのは、許可された公開Webページから必要な項目を表形式で収集する部分です。社内の問い合わせを管理したり、顧客の本音を自動確定したりする「VOCシステム」全体と同一視しません。
VOCとは？「顧客の声」と「VOC分析」の違い
VOCは、顧客が実際に伝えた言葉や評価を指します。例えば、購入後のレビューに書かれた使いにくさ、サポート窓口への質問、解約時に伝えられた理由は、それぞれ別の接点から得られるVOCです。対してVOC分析は、集めた声を出所・時点・対象製品・内容で整理し、改善すべき課題を判断する仕事です。テキストマイニングやAIの分類はその一部を補助しますが、単語の頻度や自動判定だけで顧客の意図が確定するわけではありません。
さらに、レビューを書いた人が必ず購入者や自社顧客とは限りません。公開投稿は「市場の反応」を見る材料にもなりますが、自社の契約・購買データと無条件に結びつけることはできません。アンケート回答者も全顧客の代表とは限らないため、件数を示す場合には対象期間、出所、母数、収集条件を添えます。
VOCの価値は「収集→判断→改善→再確認」にある
声を集めるだけでは、担当者ごとのメモや月次レポートが増えるだけで終わりがちです。まず「設定でつまずく理由を減らす」「商品説明と実物のずれを見つける」など、判断したい課題を一つ定めます。その上で、声の原文と分類、発生時点、対象を一緒に見て、製品、案内、サポートのどこを変えるか決めます。変更後は同じ条件で再度声を確認します。改善と同時期に広告や商品の仕様が変わったなら、VOCの件数だけで効果を断定しないことも大切です。
部門ごとに見る角度も異なります。サポートは再問い合わせの理由、製品担当は使い方と期待のずれ、マーケティングは購入前の疑問を重視するかもしれません。共通の記録項目と担当者を決めつつ、判断のための原文へ戻れるようにしておくと、同じ声を別々の部署が数え直すことを避けやすくなります。「VOCに取り組めばLTVが必ず上がる」といった成果保証はできません。
VOC活用の目標を部門ごとにどう決めるか
全社共通の大きな「顧客満足度向上」だけでは、誰が何を変えるのかが曖昧です。サポートなら同じ質問が繰り返される画面や案内を特定し、ヘルプを改善してから再問い合わせを見ます。製品担当なら、要望の数だけでなく発生する操作場面、再現性、対応の影響を確認します。営業・マーケティングなら購入前の誤解がどの説明で起きるかを見直します。声が同じでも、担当者の判断と変更対象は異なるため、分類名だけを共有するのではなく「次に何を確かめるか」まで記録します。
ただし、声が届かなかった顧客の事情はVOCだけでは分かりません。問い合わせの減少は、問題の解決だけでなく、問い合わせ導線が見つけにくくなった結果かもしれません。売上や継続率などへの影響を見るなら、利用データや調査結果と照合し、変更の前後で対象となる顧客数や利用者構成が違わないか確認します。「好評が増えた」といった表現も、同じ場所・同じ期間の採集条件で比較できて初めて意味を持ちます。
内部VOCと外部VOC：収集先と偏りを分けて考える
| 出所 | 主な記録 | 得られること | 注意点 |
|---|---|---|---|
| 社内の問い合わせ・チャット | 質問文、対象機能、回答、解決状況 | 実際の操作上のつまずき | 困った人の声に偏りやすく、個人情報とアクセス権限の管理が必要 |
| アンケート・インタビュー | 評価、自由記述、同意を得た発言 | 質問を設計して理由を掘り下げられる | 回答者・質問文・実施時期によって結果が変わる |
| 公開レビュー・口コミ | 評価、本文、投稿日、対象URLなど | 自社の窓口に届かない公開反応も見られる | 投稿者が顧客とは限らず、投稿・掲載サイトの条件と取得許可を確認する |
| 営業・店舗の記録 | 購入前の疑問、比較理由、対応後の反応 | 導入前に生じる障壁を把握できる | 担当者の要約と顧客の発言を混ぜない |
電話や面談の録音、社内チャット、CRMの個人情報を、Webスクレイピングで扱えるかのように書くのは誤りです。それぞれ同意、権限、保存期間、社内規程を確認してください。公開レビューについても、見えることと自動取得・再利用が認められることは別です。まず対象サービスの提供する公式のエクスポートやAPI、利用条件を確かめ、収集方法を選びます。
出所ごとの件数をそのまま合算しない
同じ人が問い合わせを送り、その後アンケートに回答し、公開レビューも投稿する場合があります。三つの記録があるからといって三人の顧客が同じ問題を抱えたとは限りません。逆に公開レビューは匿名・仮名の場合もあり、同一人物かどうか推定すべきでない場面もあります。まずは出所別に件数と収集対象を示し、個人を特定できる社内記録と公開投稿を安易に名寄せしない設計にします。分析の単位が「投稿」「問い合わせ」「人」のどれかをレポートごとに明記してください。
サンプルの偏りにも注意します。大きな不満を持つ人はレビューを書きやすい一方、満足していても投稿しない人がいます。サポート窓口には問題を抱えた利用者が集まります。アンケートは質問方法や配布先によって回答が変わりえます。あるチャネルの増減だけで「顧客全体の感情が変わった」と判断せず、同じ期間の製品利用状況や他の声と併せて検討します。
VOCを扱う表に残したい項目
VOCを別々の場所から集めるなら、分析の前に記録の粒度を揃えます。ここに示すのは管理項目の設計であり、実際に採集した行や成果データではありません。原文、出所、対象、日時、担当を分けて保存し、加工後も元の記録をたどれるようにします。
- 出所と参照先：問い合わせID、アンケートID、許可された公開ページのURLなど。元の記録に戻れる識別子を決めます。
- 日時：発言・投稿日時と取得日時を別の列にします。後日編集や削除があれば、その扱いも定めます。
- 対象：商品、店舗、機能、接点、利用段階など。部署ごとに異なる呼び名を統一します。
- 内容：原文、要約、分類、判断した担当者を分けます。自動分類は人が再確認できる候補として扱います。
- 対応：課題の担当、実施した変更、確認日を記録します。未対応の声を削除して見かけの傾向を変えないようにします。
重複判定には、社内記録なら元ID、公開ページなら対象URLと投稿IDなど利用可能な安定キーを検討します。URLだけでは同じページの複数レビューを区別できません。投稿日が欠ける、本文が途中までしか見えない、異なる商品が同名で混ざるといった欠損も、黙って補完せず確認用の印を付けます。
分類の品質を維持するための運用
最初から細かなタグを大量に作ると、部署によって付け方が変わり、時系列比較が難しくなります。「料金」「使い方」「品質」など、判断先が明確な少数の分類から始め、どちらにも当てはまる場合や判断できない場合の扱いを決めます。一定数の原文を複数人で読み比べ、分類の境界を調整してから過去分も必要に応じて付け直します。AIを使う場合も、要約だけを保存せず、出所へ戻れる識別子と人による確認結果を残します。
共有時には個人名や連絡先をむやみに載せません。社内の閲覧権限に合わせて公開範囲を分け、対外発信には匿名化や引用の許諾を別途確認します。データの削除・訂正依頼があったとき、元データと分析用の複製の双方を追えるようにしておくことも運用の一部です。古い記事にあった「テキストマイニングで企業の課題を自動解決できる」という読み方は避け、ツールの出力を人が確かめてから施策につなげます。
OctoparseはVOCのどの工程に使える？
Octoparseは、利用が認められたWebページの項目を選び、表形式で抽出して出力するツールです。例えば公開レビューが対象なら、対応するテンプレートの入力欄と出力項目を確認し、少数の対象URLで本文、評価、投稿日、対象ページURLが揃うか試せます。https://www.octoparse.jp/template/google-maps-review-scraperやhttps://www.octoparse.jp/template/amazon-jp-review-details-scraperは現行の公開ページで確認できます。ただし、対象サイトの規約・権利と現在のテンプレート仕様が実際の用途に合うかは別に確認が必要です。
Octoparseの役割は外部WebデータをVOCの入力候補として整えるところまでです。サポートチケットの保存、録音の文字起こし、顧客IDとの結合、個人情報の権限管理、感情の確定、改善策の決定は自動的には行いません。CSVなどに出力した後、元データの利用条件に従い、社内の安全な場所で必要な列だけを照合・分析します。日本語のデータ取得・エクスポートのヘルプで、実行と出力の現行操作を確認できます。
レビューをAIで分類して比較したい場合は、実際の収集条件と結果を示したVOC分析の実践記事へ進んでください。SNS投稿の個別の収集手順はSNS口コミ収集のガイド、ECレビューを継続的に見る運用はECレビューの記事が主ページです。本記事ではこれらの操作・数値・分析事例を繰り返しません。
VOC運用を始める順序と確認点
- 判断したい問いを一つに絞る：何を改善するか、誰が判断するか、いつ見直すかを決めます。単に「口コミを全部集める」を目標にしません。
- 使える出所を列挙する：社内の問い合わせ・アンケートと、許可された公開レビューを分けます。顧客の同意、利用条件、保存期間、権限を確認します。
- 少量の記録を点検する：原文と対象、日時、出所が分かるか、同じ声が二重に入らないか、誤分類しそうな表現がないかを見ます。Web収集ならページの表示と出力行を突き合わせます。
- 分類して判断する：頻度だけでなく、対象顧客、重大性、再現可能性、対応可能性を検討します。AIの要約やネガポジ判定は原文に戻って確認します。
- 改善と再確認を記録する：担当、変更内容、確認日を残し、同じ条件で後の声を見ます。市場全体や顧客全体の割合だと誤解させる数字を出さないよう、対象と母数を併記します。
よくある質問
VOCシステムとOctoparseは同じですか？
いいえ。VOCシステムは、社内外の声の収集、権限を守った管理、分析、担当者への共有、改善後の追跡までを含む運用です。Octoparseは、そのうち条件に合う公開Webデータの収集・表形式での出力に利用できます。対象とプランによって使える機能を現在の公式資料で確かめてください。
口コミを多く集めればVOC分析は正確になりますか？
件数だけでは決まりません。投稿者の偏り、同一人物・同一内容の重複、投稿日と取得日の違い、欠損、収集条件を点検します。レビューだけでは問い合わせに現れる操作の問題や、声を上げない顧客の事情は分かりません。別の出所と照らし合わせ、結論の範囲を明示してください。
公開SNSの投稿をそのまま社内VOCに結合できますか？
公開されていることだけで自動取得や再利用が認められるとは限りません。利用規約、権利、プライバシーの条件を確認し、個人を推定してCRMへ結びつけない設計を検討します。公開投稿は必ずしも顧客の発言ではないため、社内の問い合わせと同じ母集団として合算しないでください。
まとめ
VOCとは、顧客の声を改善の判断材料にするための出発点です。社内の直接的な声と、外部に公開された反応は、得られる情報も偏りも権限も異なります。まず目的、出所、記録の列、担当、確認日を決めましょう。Octoparseを使う場合は、許可された公開Webデータを収集・出力する工程に役割を限定し、原文照合、分析、改善判断は別工程として検証することが大切です。
競合情報も営業リストも、ウェブデータをそのままExcel・CSV・Google Sheetsに出力
コード不要、誰でも今日から。クリック操作だけで必要な項目を自動抽出
Google Maps・食べログ・iタウンページ向けテンプレートで、リード獲得をすぐに開始
クラウドで毎日・毎週自動実行。大量取得でも安定して、競合動向を常に把握
MCP対応でAIエージェントと連携。収集データをAIに渡して分析・活用まで一気通貫
クレジットカード不要で無料スタート。世界600万人以上が選んだ信頼のツール
