LLM × コンパウンドなプロダクトの立ち上げにおけるエンジニアリングの実践と学び

※この記事は2025年5月に『RightTouch公式note』に掲載した記事を転載しています。

はじめに

こんにちは、RightTouchでテックリードをやっている齋藤です。RightTouchは先日、プロダクト3周年記念を迎え、この度シリーズAの資金調達を行いました。

https://righttouch.co.jp/news/FpF1waA5

3周年記念と資金調達を記念して、RightTouchではリレー形式でのブログ投稿を行っています。

https://note.righttouch.co.jp/m/md84f0da0727f

本記事では、私が担当している、電話での音声自動応答のプロダクトである RightVoicebotのこれまでの開発を振り返り、「LLM ネイティブなプロダクトを、コンパウンドスタートアップの中でエンタープライズ向けに立ち上げる」という状況で、私や私たちのチームが意識したポイントを下記3つの観点でまとめました。

1. 顧客解像度向上の考え方
2. 品質の考え方
3. コンパウンド性の考え方

近い状況でプロダクト作りを行っているエンジニアやプロダクトマネージャにとって、何かしらの参考になれば幸いです。
(なお、Voicebot の開発においては AI の精度やアルゴリズムの検討も非常に重要ですが、本記事ではスコープ外としています)

エンジニアリングの力を借りて顧客課題の解像度を上げる

RightTouchの新規プロダクトの開発スタイルでは、RightTouchの小室の記事にあるように、明示的な PdM を設けず、事業開発メンバーとエンジニアメンバーが対等に議論し、スピード感を持って進めていくことが多いです。

特に、ボイスボットのような AI/LLM が主体となるプロダクトでは、全体コンセプト検討の早い段階から、biz/dev メンバーが協力して顧客課題を把握していく進め方が重要であると改めて感じています。
なぜなら、LLM は、モデルの変化も活用テクニックの変化も激しく、顧客や我々自身もまだ難しいだろうと思っていた課題があっさり解けるようになっていることが珍しくないためです。このような環境では、実際に動くプロト(=MVP)を潜在顧客に当ててみて、それをベースにディスカッションすることで、より深い顧客課題を引き出すことができます。
具体的には、下記のような1週間サイクルのプロセスでコンセプト探索を進めていきました。

1. 顧客課題やプロダクト仮説を元にボイスボットの理想の応対例を考え、エンジニアメンバーがdifyや各種コーディングアシスタントを活用し、半日程度で動くプロトを作る
2. その週に顧客にエンジニア/事業開発メンバー がデモ、ヒアリング
3. デモの結果を踏まえてチームで次の検証ポイント検討

実は、RightVoicebotはコンセプトの大きな再検討を一度行なっているのですが、初期検討時では上記ようなサイクルはそこまで意識しておらず、再検討時に上記取り組みを行なっていました。結果的に、これが顧客の強いニーズを引き出し、整理する上でかなり効果的だったと感じています。

プロト作りを含め、顧客解像度を上げるにあたって意識した点(反省点でもあります...)として、下記があります。

• 「技術的な差別化」と「顧客課題」を取り違えない
• プロダクト戦略上の顧客の立ち位置を理解した上で汎用的に考える

前者に関しては、ボイスボットやそれに類する自動応答の領域には、すでに数多くの代替品や競合製品が存在します。そのような状況で上記のような技術的な探索を行うと、エンジニア目線では、「どう他社と技術的な差別化を図るか」という点に目が行きがちです。
例えば、RightTouch は、すでにWeb の領域で PMF しているプロダクトが複数存在します。そのため、既存の技術アセットありきで考えると、Webの方向に視点が寄ってしまい、フラットに顧客を見る足枷になることもありました。
私たちのチームでは、カスタマーエンジニアやbizdevのメンバー主導でCPF/PSFなどのフィットジャーニーをチーム全体で意識合わせすることで、このバランスをとっていきました。

後者は、顧客接点が比較的少ないエンジニアがプロダクトの探索に関わる場合は特に、接点を持った顧客がどのような特性で、プロダクト戦略上どのような立ち位置にあるのかを理解する必要があるというものです。カスタマーサポートの形は業界や企業規模によって千差万別で、それぞれのペインポイントも異なるため、プロトを作ってみるにしても、誰のどんな課題に刺すか、それがどのような検証になるか、を意識する必要があります。
私は、プロト探索の取り組みを行うにあたって、これまでのRightVoicebotの商談ログをすべて見返し、顧客ごとの業界、ボイスボットで解きたい課題、検証したい仮説などをDBに起こし、整理することでこの理解を深めました。

限られた時間とリソースでエンタープライズ品質を担保する

ボイスボット開発を非機能要件という観点で見ると、大企業のカスタマーサポートにおける電話窓口は、極めてミッションクリティカルな存在であり、わずかなダウンタイムでも大きな問題につながる可能性があります。

一方で、私たちは限られた人数でプロダクトを立ち上げなければならず、コンセプトも日々ブラッシュアップがかかる中で、最速で顧客に価値を提供しなければなりません。

このような状況で、リリース時の開発においては下記のようなポイントを重視しました。

1. 自動化を意識した「守り」に投資する
2. 機能を増やす < 汎用的に作る

1 に関しては、プロダクトリリースするにあたり、外部チームによる網羅的なセキュリティレビューの実施、各種 LLM や AI サービスが落ちた時のフォールバックの実装、QA、監視の整備などはもちろん行いましたが、その中で特に取り組んで恩恵の大きかったものとして、日常的な監視や QA に関しては最初から自動化を進めていったことが挙げられます。
具体的には、実際に架電しての QA や監視の多くの部分を、独自構築した自動架電システムで賄っています。
初期構築のコストはかかりましたが、QA品質の均質化を含め、結果的にはかなり早い段階でペイするものになりました。

2 に関しては、闇雲なプロダクトへの機能の増加は、当然保守性・信頼性を低下させてしまいます。そのため、初期フェーズでは、機能を増やすよりも、汎用的に機能を設計し、顧客の要求に応じて柔軟に画面からカスタマイズする方式で、機能数自体は最小限にする形としました。
幸い、LLM を活用した機能は、プロンプトだけでその振る舞いを制御できるケースも多く、こうしたアプローチと相性が良いと感じています。もちろん管理者側のUX 的なトレードオフはある程度存在します。しかし、プロダクト戦略に鑑みて、初期のターゲット顧客が少ない段階では、サクセス含め顧客環境でのカスタマイズを行うことで、機能を減らし、迅速に価値提供することが優先と判断しました。

プロダクト自体の PMF vs 全社基盤への還元

開発のもう一つの観点として、コンパウンドスタートアップでのプロダクト開発において、「どこまでプロダクトで作ったものの全社基盤化を意識するか？」は、悩ましいポイントです。(ここでいう基盤とは、例えば共通インフラ、共通データベースなど、プロダクト横断で利用するアセットを指します)

基本は プロダクトの PMF が最優先ですが、意思を持って共通基盤の整備にコミットすることも中長期的には非常に重要だと考えています。

特にカスタマーサポートにおいては、実際のコールセンターのオペレータが社内マニュアルや顧客情報を縦横無尽に参照しながら電話応対を行うことからもわかるように、企業・顧客それぞれのデータの活用が、顧客応対にとって大きな意味を持ちます。
したがって、それらのデータをいかに自社で取得し、整備できるかは大きな肝になります。(もちろん、AI エージェントの広まりにより、エージェントがあらゆる データ を直接触れるようになる時代は来ると思いますが、エンタープライズにおける顧客対応向けのエージェントが現実的にこの領域に至るのはまだ時間がかかると考えています)

一方で、基盤開発は、特にまだ具体のニーズが固まりきっていないフェーズでは、さまざまなステークホルダーとコミュニケーションが必要になり、開発のスコープも肥大化しがち・遅れがちになるものでもあります。
私も、一度ニーズが固まり切らない段階で基盤的な機能の開発を検討したことがありますが、結局議論が空中戦になりうまくいかなかったという経験があります。

現在のRightTouch では、「基盤は、その上に乗るプロダクトに価値を提供するプロダクトである」という考えのもと、その基盤の一番の「顧客」となるプロダクトチームがオーナーシップを持って基盤整備を行う方針をとっています。

RightVoicebot開発チームも、初期はとにかく自分のプロダクトを動かすことにフォーカスしていましたが、リリースを経て、基盤化した方が良い部分が明確になってきてからは、その部分の全社基盤化を進めています。この方式により、過度にプロダクトチームに基盤開発の負担が乗ることなく、基盤が解くべき課題の解像度を適切に持って開発を進めることができています。

さいごに

ここまでお読みいただき、ありがとうございました。
私たちもまだまだプロダクトを磨いている状態ですが、本記事が少しでもお役に立てば幸いです。

株式会社RightTouchでは一緒に働く仲間を募集しています

Business
ビジネスデザイン
カスタマーサクセス
エンタープライズセールス
BDR
マーケティング

Product
プロダクトエンジニア
リードエンジニア
カスタマーエンジニア
UI/UXデザイナー

Accelerator
法務（正社員）
財務経理（Accounting ＆ Finance）