Enterpretで顧客の声を拾う4工程｜起票まで任せる範囲

「顧客の声のレポートは月に1回出しているが、届いたときには問題がもう広がっている」「AIが勝手に不具合の起票をしたら、開発の担当が誤報だらけの一覧に埋もれるのではないか」——顧客の声を受け持つマーケやカスタマーサクセスの担当と、その上長から聞こえてくる声です。どちらも、声の量が増えた会社ほど切実になります。顧客の声の分析は、集めた声を月に1回まとめて報告する仕事だと思われがちです。しかし、米国の Enterpret のように、常に声を見張るエージェントが、不具合の起票や担当への連絡まで行える段階に来ています。問いは「どう分析するか」から「どこまで自動で動かすか」に変わりました。この記事では、Enterpret を例に、顧客の声を拾ってから起票するまでを4つの工程に分け、AIに任せる範囲と人が決めることを整理します。

Enterpret は、散らばった顧客の声を1か所に集めて分類する基盤

Enterpret は、問い合わせの記録、アプリのレビュー、営業の通話、コミュニティの書き込みなど、会社のあちこちに散らばった顧客の声を1か所に集め、内容ごとに分類する製品です。2025年10月27日の発表によれば、50を超える窓口から声を取り込みます。例として、インターコム、Gong、Reddit、X が挙がっています。

同じ発表では、仕組みが4つの部品で説明されています。声を顧客・取引先・商談・製品と結び付ける顧客ナレッジグラフ、顧客の言葉の変化に合わせて分類を自動で育てるアダプティブ・タクソノミー、自然な言葉の質問に答えるエージェントのウィズダム、そして兆しを見つけて動く Action Agents です。Action Agents の例としては、不具合の兆しを見つけることと、重要な顧客の問題を解約の前に引き上げることが挙げられています。

つまり Enterpret は、声を分析する道具であると同時に、分析の結果をもとに誰かを呼ぶ、何かを起票するところまでを射程に入れた製品です。テキストマイニングで声を数える手順や、声を製品開発に返す流れの一般論は別の記事で扱っています。ここでは、エージェントに起票と連絡まで任せるときの条件に絞ります。

質問に答える側の機能も押さえておきます。2025年10月の発表では、ウィズダムが Slack や Jira、ChatGPT の中で、自然な言葉の質問に答えると説明されています。たとえば「欧州で新規登録が伸び悩んでいるのはなぜか」といった問いです。便利な反面、答えの数字がそのまま会議の資料に貼られやすい点には注意が要ります。答えに付く引用や件数を開いて、元の声に当たってから使うという習慣を、使う人全員の決まりにしておきます。

創業と顧客、国内でまだ知られていない理由

Enterpret は2020年に、兄弟2人が創業した会社です。2025年10月の発表は、米国の複数のベンチャー投資会社が出資していると紹介しています。利用企業としては Perplexity、Notion、Canva などの名前が挙がっています。いずれも、利用者が多く、声の量が人の手では読み切れない規模のソフトウェアの会社です。

国内でほとんど知られていない理由は、いくつか考えられます。1つは、想定している会社の姿です。声の窓口が数十に分かれ、毎日大量の声が届く、海外の大きなソフトウェアの会社が中心の顧客です。もう1つは言語です。この記事の調査では、公式の資料で日本語の声の分類や日本語の画面への対応を確かめることはできませんでした。日本語で紹介した記事も、2026年10月時点でごくわずかです。

そのため、2026年10月時点で現実的に検討するのは、海外の利用者を多く抱えるアプリやソフトウェアの会社でしょう。ただ、声を常に見張って起票まで進める流れは、ほかの道具や自社の仕組みでも組めます。この記事の4つの工程は、製品を問わず、起票を自動にする前に決めることの順番として読んでください。

2025年10月の「エージェント型」と、2026年6月の Agent OS

製品の変化は、2つの節目で追えます。最初は2025年10月で、Enterpret は自社の製品を「エージェント型」の顧客フィードバックの基盤として打ち出しました。分析の先に、兆しを見つけて動くエージェントを置いた形です。

次が2026年6月の更新です。公式の更新履歴によれば、Agent OS をベータとして提供しました。多段の調べものをこなすエージェント、決まった時刻や合図で動く Agent Automations、Jira や Slack、Salesforce などの道具とつなぐ接続が含まれます。7月の更新履歴は、Agent Automations が6月にベータとして始まったことを改めて記しています。同じ6月には、ChatGPT のアプリの一覧で Enterpret が使えるようになり、ChatGPT や Codex の中から顧客についての質問ができるようになりました。更新履歴にこのアプリのベータの表記はありませんが、Agent OS 全体がベータの期間に出た機能です。

ここで押さえておきたいのは、起票や連絡を自動で回す中心の機能は、2026年10月時点でベータとして出ているということです。ベータの期間は、組織ごとに費用の上限を置けることと、提供元が内部で見張っていることも更新履歴に書かれています。本番の業務の流れに組み込む前に、提供の段階と、正式な提供に移ったときに何が変わるかを提供元に確かめてください。

「月1回のレポート」から「常に見張る」へ変わると何が変わるか

Agent Automations には2種類の動き方があります。1つは決まった周期で動くもので、更新履歴には週ごとの顧客の声の振り返り、新機能の公開後の見張り、サポートの成績表、取引先の健康状態のまとめなどが例に挙がっています。もう1つは合図で動くもので、声の急増、好意と不満の傾きの変化、急ぎのエスカレーション、品質の問題、取引先の危うさの兆しといった合図がきっかけになります。

月1回のレポートなら、人が読んでから動くかどうかを決められます。しかし合図で動く仕組みでは、人が読む前にエージェントが動き出すことになります。夜中に声が急増すれば、朝を待たずに担当の Slack に連絡が届き、場合によっては起票まで進みます。

これは速さという利点であると同時に、誤報が人の手間に直結するということでもあります。合図が敏感すぎれば、担当者は毎晩の通知に追われ、開発の課題の一覧は確かめられていない起票で埋まります。常に見張る仕組みでは、動かす条件と同じだけ、止める条件の設計が要ります。ここから、その条件を決める4つの工程を見ていきます。

4工程の全体像

顧客の声を拾ってから起票するまでを、4つの工程に分けます。工程ごとに、エージェントに任せることと、人が決めることを並べます。

工程	AIに任せること	人が決めること
工程1 集める	窓口から声を取り込み、顧客や取引先と結び付ける	取り込む窓口の範囲、個人情報を伏せるか残すか、取り込んだ声を読める人
工程2 分類する	声を分類し、新しい話題を見つけ、分類の案を育てる	分類の物差しの最終形、不具合と要望の境目、重要な顧客の定義
工程3 動かす	合図を見つけ、起票の下書きを作り、担当に知らせる	動かす条件と止める条件、起票の先と担当、一斉に止める操作の持ち主
工程4 確かめる	起票と連絡の記録をまとめ、当たり外れの集計を手伝う	当たり外れの判定、条件の直し、直した内容の承認

表を見ると分かるように、工程1と工程2の大部分は、エージェントを動かす前に人が済ませておく仕事です。ここを飛ばして工程3の自動化から始めると、何を基準に動いているのか誰も説明できない仕組みになります。

工程1 集める窓口を決める

最初の工程は、どの窓口の声を取り込むかを決めることです。窓口が多いほど見落としは減りますが、窓口ごとに声の性質が違います。問い合わせの記録は困っている人の声、アプリのレビューは感情の強い声、営業の通話は買う前の人の声、と偏りがあります。どの窓口の声が起票の合図になりうるかを、窓口ごとに考えておきます。

起票まで任せることを考えるなら、窓口ごとに、起票の材料にしてよいかどうかを分けておくのが安全です。たとえば、問い合わせの記録の不具合の報告は起票の材料にしてよいが、SNSの書き込みは件数の傾向を見るだけにとどめる、といった分け方です。SNSの声は、同じ話題がまとめて書き込まれると件数が急に膨らみ、合図を誤って鳴らしやすくなります。

取り込みの範囲は、一度決めたら終わりではありません。7月の更新履歴では、自社の TikTok のアカウントのコメントを取り込めるようになったと書かれており、つなげる窓口は増え続けています。新しい窓口をつなぐときに、誰が承認するか、起票の材料にするかどうかを誰が決めるかを、先に決めておきます。

営業の通話の記録を取り込む場合は、扱いをもう一段慎重にします。商談の会話には、見積もりの条件や相手の社内の事情など、顧客の声というより取引の中身にあたる情報が含まれるからです。商談の会話そのものの解析と、そこから先の送信や更新の扱いは、同じ便の Attention の記事で扱っています。ここでは、商談の記録は件数の傾向を見る材料にとどめ、不具合の起票の材料にはしないという線を一つの目安として挙げておきます。製品への不満が商談で語られたときは、受け持ちの営業が要旨を書き直して窓口に載せるほうが、取引の情報が広がらずに済みます。

工程1 個人情報の扱いを決める

顧客の声には、氏名、メールの宛先、注文の番号、ときには体調や家族の事情まで含まれます。それを海外の提供元の仕組みに取り込み、さらに起票の形で開発の課題の一覧や Slack に流すことになります。声が起票や連絡の形で社内に広がるほど、個人情報が届く人の数も増えることを前提に考えます。

公式の安全のページによれば、2026年10月時点で、Enterpret は SOC2 のタイプ2の報告書を持ち、データは AWS の米国の拠点で保管され、通信と保存は暗号化されています。欧州の個人データの規則のうえでは、処理を受託する立場であるとしています。一方で、この記事の調査では、個人情報を自動で伏せる機能の有無、声が学習に使われるか、どれだけの期間保存されるかは、公式のページで確かめられませんでした。

そのため、取り込む前に、伏せる項目を自社の側で決めておくのが安全です。起票や通知に載せるのは声の要旨と件数までにし、氏名や連絡先は元の窓口の仕組みの中にとどめる、といった線です。7月の更新履歴には、自動の実行で作られた成果物が既定で受け取り手に共有されると書かれています。誰に何が届くかの既定の設定を、動かす前に確かめておくことも、この工程に含めます。

工程2 分類の物差しは人が決める

次の工程は、声を分ける物差しを決めることです。Enterpret のアダプティブ・タクソノミーは、顧客の言葉の変化に合わせて分類を自動で育て、手で印を付ける作業をなくすと説明されています。分類の案を出す速さは、人の手作業とは比べものになりません。

ただし、分類の物差しは、そのまま起票の物差しになります。エージェントが「不具合」に分けた声が起票の材料になり、「要望」に分けた声は起票されない、という具合です。物差しが変われば、誰が呼ばれるか、何が起票されるかが変わります。分類が自動で育つ仕組みでは、昨日まで要望だった声が、今日は不具合として起票される、といったことも起こりえます。

そのため、分類の案はエージェントに出させても、起票につながる分類の確定は人が持ちます。具体的には、不具合と要望の境目、急ぎとみなす言い回し、製品のどの部分の話かの分け方について、起票につながる分類だけは、変わるときに持ち主の承認を通すと決めておきます。起票につながらない分類は、エージェントが自由に育てて構いません。

工程2 優先度の物差しを決める

分類と並んで決めておくのが、優先度の物差しです。同じ不具合の声でも、1件だけの声と100件の声、無料の利用者の声と大口の取引先の声では、急ぐ度合いが違います。Enterpret の顧客ナレッジグラフは、声を取引先や商談、売上と結び付けると説明されているので、どの取引先の声かを踏まえた優先度の案を出させることはできます。

ここで人が決めるのは、何を重要な顧客とみなすかです。売上の大きさで決めるのか、契約の更新が近い取引先を重く見るのか、業界の評判に影響する顧客を重く見るのかは、会社の方針です。エージェントが「この取引先は解約の危うさが高い」と判定しても、その判定を営業や経営の判断にどう使うかは、人が決めます。

優先度の物差しは、件数・深刻さ・顧客の重みの3つの組み合わせで書くと分かりやすくなります。たとえば「深刻な不具合なら1件でも起票」「軽い不具合は重要な顧客から2件、またはそれ以外から20件で起票」といった形です。数字は会社ごとに違いますが、数字で書いておけば、後から当たり外れを見て直せます。

重要な顧客の声をめぐっては、もう1つ決めておくことがあります。その取引先を受け持つ営業やカスタマーサクセスの担当に、誰がどう知らせるかです。エージェントが取引先の危うさを開発の担当にだけ知らせ、受け持ちの担当が知らないまま顧客と話す、という食い違いは避けたいところです。重要な顧客の声は、起票と同時に受け持ちの担当にも届く流れにすると決めておくと、社内の動きがそろいます。顧客に連絡するかどうかは、その担当が判断します。

工程3 起票・連絡させる条件を決める

3つ目の工程で、いよいよエージェントを動かす条件を決めます。6月の更新履歴によれば、Agent OS のエージェントは、つないだ道具の中で動作を起こせます。接続先には Jira や GitHub、Slack、Salesforce などが並びます。急ぎのエスカレーションの合図を、ウェブフックや Slack、メールに送る機能もあります。

条件は、動作の重さで段を分けて決めます。いちばん軽いのは、担当のチャンネルに知らせるだけの動作です。次が、起票の下書きを作り、担当者が確かめてから課題の一覧に載せる動作。いちばん重いのが、課題の一覧に直接起票し、担当者を割り当てる動作です。最初は知らせる動作と下書きまでにとどめ、直接の起票は当たりが安定した条件だけに広げるのが安全です。

ヘルプの案内では、エージェントは作業の途中で情報や承認を求めることがあるとされ、7月の更新履歴には、外部の道具の中身を変える動作の前に承認を求める接続の例も出てきます。どの動作で承認を求めさせるかを、接続ごとに確かめてください。なお、顧客への回答は、起票の自動化とは切り離して人が行うと決めておきます。エージェントの分析を材料に、回答の文面を決めるのはサポートの担当者です。

起票の先の持ち主も、動かす前に決めておきます。開発の課題の一覧、サポートの対応の一覧、営業の取引先の記録のどれに起票するかで、受け取る人が変わるからです。起票を受け取る側の責任者に、どんな条件で何件くらい届くかを見せて合意を取っておくことが欠かせません。受け手の合意がないまま起票が届き始めると、受け手はそれを他部門からの押し付けと受け取り、確かめずに閉じるようになります。

工程3 止める条件と、誤報の扱い

動かす条件を決めたら、同じ重さで止める条件を決めます。たとえば、同じ話題の起票が1時間に一定数を超えたら自動の起票を止めて人に回す、新製品の公開直後の数日は合図の閾値を引き上げる、といった条件です。公開の直後は、仕様どおりの動きへの戸惑いの声が不具合のように見えて急増しやすいからです。

一斉に止める操作の持ち主も決めておきます。誤報が続いたときに、自動の実行を止められるのは誰か。夜間や休日に止める判断を誰がするのか。止める操作の持ち主と連絡の経路を、動かす前に紙に残しておくことで、誤報が広がったときに慌てずに済みます。

誤報が出たときの扱いも型にします。誤った起票は削除せずに「誤報」の印を付けて閉じ、なぜ誤報になったかを1行書いておきます。ヘルプの案内も、生成された答えは不正確だったり不完全だったりすることがあるとし、数字や引用を使う前に、母数、絞り込みの条件、期間、元の声の言い回しを確かめるよう勧めています。誤報の記録は、工程4で物差しを直すときのいちばんの材料になります。

工程4 起票の結果を確かめる

最後の工程は、エージェントが起こした動作の結果を確かめることです。7月の更新履歴によれば、自動の実行は1回ずつの記録が残り、どの道具を呼び出し、何を出力したかを後から開いて確かめられます。この記録を使って、起票と連絡のうち、どれが当たりでどれが外れだったかを数えます。

数えるときは、少なくとも3つに分けます。起票した不具合が実際に直す対象になったもの、起票したが不具合ではなかったもの、そして起票されなかったが後から不具合と分かったものです。最後の「拾い漏れ」は、エージェントの記録だけを見ていても見つかりません。開発や営業の側で後から見つかった問題を、元の声と突き合わせる作業が要ります。

当たりと外れの数は、エージェントの成績表であると同時に、物差しの成績表でもあります。外れが多いなら、エージェントの読み違いなのか、物差しの書き方がずれているのかを分けて見ます。同じ種類の声が繰り返し外れているなら、多くの場合、直すべきは物差しの側です。

当たりの割合は、自動の範囲を広げるかどうかの判断にも使います。たとえば、下書きまでにとどめている条件のうち、担当者がほぼそのまま課題の一覧に載せている条件は、直接の起票に移す候補になります。逆に、担当者が下書きを捨てることの多い条件は、知らせるだけの動作に戻します。自動の範囲は、条件ごとの当たりの割合を見て一段ずつ動かすことで、仕組み全体を止めずに直していけます。

工程4 物差しを直す周期と持ち主

確かめた結果をもとに、物差しを直します。直す周期は、動き始めの1か月は週に1回、落ち着いたら月に1回が目安です。直すのは、分類の境目、優先度の数字、動かす条件と止める条件の4つです。直す権限を持つ人は、物差しを決めた人と同じにしておくと、誰の判断で変わったのかが追えます。

直した内容は、関わる部門に知らせます。起票の条件が変われば、開発の担当に届く起票の量と種類が変わるからです。知らせずに変えると、開発の側は「急に起票が増えた」「急に来なくなった」と受け取り、仕組みへの信頼が下がります。条件を緩めて自動の範囲を広げるときは、特に丁寧に知らせます。

四半期に1回は、マーケ、カスタマーサクセス、開発の担当が集まり、仕組み全体を見直す場を持つとよいでしょう。どの窓口の声が役に立ったか、どの条件の起票が直すべき問題につながったかを共有します。その場で、エージェントに任せる範囲を広げるか、狭めるかを決めます。

費用の増え方と、外に出るもの

費用は、この記事では金額を扱いません。一般に、取り込む窓口と声の量、使う人の数、エージェントの実行の回数が増えるほど費用も増える仕組みが多いでしょう。6月の更新履歴が、ベータの期間に組織ごとの費用の上限を置けると書いているのは、エージェントの実行が費用に直結することの表れです。合図で動く仕組みは、声が急増した日に実行の回数も跳ね上がるので、上限と、上限に達したときに止まるのか知らせるのかを決めておきます。

外に出るものも整理しておきます。取り込んだ声は提供元の仕組みに保管され、つないだ道具には起票や通知の形で声の要旨が流れます。ChatGPT のアプリから質問できるようにすると、その答えは対話型のAIの画面にも表示されます。どの道具に、どの範囲の声が流れるかを、接続ごとに一覧にしておくと、後から確かめやすくなります。

やめ方も先に決めておきます。分類の物差しや優先度の数字、動かす条件と止める条件は、提供元の画面の中だけに置かず、自社の文書にも残しておくのが備えになります。乗り換えや解約のときに、物差しを一から作り直さずに済みます。

起票を自動にする前の確認

ここまでの4つの工程を、起票を自動にする前に確かめる点としてまとめます。1つでも答えられない点があれば、自動の起票は下書きまでにとどめ、先に人の側の準備を済ませてください。

• 起票の材料にしてよい窓口と、傾向を見るだけの窓口を分けたか
• 起票や通知に載せる情報から、氏名や連絡先などの個人情報を外す線を決めたか
• 不具合と要望の境目、重要な顧客の定義を、人が文書で決めたか
• 起票につながる分類が変わるとき、持ち主の承認を通す流れにしたか
• 動かす条件と同じ重さで、止める条件と一斉に止める操作の持ち主を決めたか
• 顧客への回答を、起票の自動化から切り離して人が行うと決めたか
• 当たり・外れ・拾い漏れを数える周期と、物差しを直す権限の持ち主を決めたか
• 使う機能がベータであることを踏まえ、正式な提供に移ったときの変化を提供元に確かめたか

• 分類の物差しを決めないまま、合図で動く自動の起票から始める
• SNSの書き込みの急増を、そのまま不具合の起票の合図にする
• 起票や通知に、顧客の氏名や連絡先をそのまま載せる
• エージェントの「解約の危うさ」の判定を、確かめずに営業や経営の判断に使う
• 誤報の起票を削除し、なぜ外れたかの記録を残さない

まとめ

Enterpret は、50を超える窓口の顧客の声を集めて分類し、エージェントが兆しの検知や連絡まで行う基盤です。2025年10月に「エージェント型」を打ち出し、2026年6月には Agent OS をベータで提供して、決まった周期や合図で動く仕組みを加えました。2026年10月時点で、起票や連絡を回す中心の機能はベータの段階にあり、日本語への対応は公式で確かめられませんでした。常に見張るエージェントに起票まで任せるなら、集める窓口と個人情報、分類と優先度の物差し、動かす条件と止める条件、結果の確かめ方の4つの工程を、人が先に決めておく必要があります。分類・兆しの検知・起票の下書きはAIに任せ、物差し・優先度の確定・顧客への回答は人が持つ。この線を部門で決めてから、自動の範囲を一段ずつ広げてください。

• 製品の機能と提供状況は、Enterpret の2026年6月と7月の更新履歴、公式の安全のページ、ヘルプの案内、2025年10月27日の発表を2026年10月21日に確かめた範囲に基づきます。ベータの機能は中身や提供の形が変わることがあるため、導入の前に最新の原文で確かめてください
• 顧客の声に含まれる個人情報の扱いは、自社の個人情報の決まりと委託先の管理の決まりに合わせて決めてください

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。