2025年12月〜2026年1月アドベントカレンダー|RightTouch
2025年12月のアドベントカレンダーと2026年1月の新春noteリレーを開始します。総勢40名近くのメンバーが平日毎日投稿していきます。
https://note.righttouch.co.jp/m/m8d364191fdc1
※この記事は2025年12月に『RightTouch公式note』に掲載した記事を転載しています。
初めまして。RightTouchでCE(Customer Engineer)をしている川下です。
RightTouchアドベントカレンダー5日目はカスタマーエンジニアについての記事を書いていきます。
RightTouchでは、2025年12月にアドベントカレンダーを、2026年1月に新春noteリレーを開催します。有志で集まった総勢40名近くのメンバーが、平日に毎日投稿していきます。
▼全記事はこちらから
突然ですが、近年数が急速に増えているAIプロダクトは「それっぽく」動きます。
けれど、現場で及第点—つまり業務に耐える本番品質—には届かない。この「乖離」を埋めるのがAgent Software Engineer(ASE)です。
ASEはセールスでも純開発でもなく、プロダクトのラストワンマイルを完成品にする役割を担います。
0→1で作った型を現場の文脈に落とし込み、評価・検証・連携まで面倒を見る。
そして定着した知見を横展開していくのが、RightTouchのCE設計です。
そこで今回は、ASEが担う役割や実際の動きを、具体的な話を交えて公開したいと思います。
尚、自分は現在Voicebotプロダクトに深く関わっているため、音声領域に話の比重がよる点はご容赦ください。
簡単な自己紹介
横浜国立大学卒業後、新卒でECカートシステムを提供する上場企業に入社し、PjMやPdM・開発部長に従事。2024年5月にRightTouchに入社。
最近の気づきは、中華料理は合わせ調味料の水分を飛ばしてから野菜を入れるととっても美味しくなること。
本題に入る前に、簡単にRightTouchにおけるCEについて触れます。
RightTouchのCEは、ASE(Agent Software Engineer, 0→1〜型化)/SE(Solutions Engineer, 獲得と提案)/CRE(Customer Reliability Engineer, 運用信頼性)に分かれます。
ASEが現場で「動く品質」に仕上げた型を、SEが獲得・提案に活かし、CREが可観測性と継続改善で守る。そんな分業と連携でプロダクトのデリバリーやサポートを進めています。
それぞれのポジションの中でも対応する内容に幅があったり、また相互にオーバーラップすることもあるのですが、それは今回の話では省略します。
PoCは動く。でも、運用現場の「及第点」、つまり業務に耐える品質には届いていない。
このわずかな差分は、モデルの賢さの問題というより主に文脈の不足から生まれます。
PoCと及第点のあいだに横たわるのは、たいてい文脈不足・切り分け不能・評価の粗さ・連携の浅さです。LLMは「広く賢い」ものの、業務の背景や顧客の感情、社内の運用制約までは知りません。
ここを「コンテキストで接続し直す」のがASEの本質です。
ASEは日々、メインプロダクトの技術サポートに加え、CRM/CTI/ナレッジ基盤などの各種システムとの最小工数のつなぎ方を設計し、プロダクト(今回の例ではボイスボット)の動作意図が業界ごとの常識に沿うかを見ながら検証を行い、定常的に品質維持・向上ができる状態を保っていきます。
得られた知見は導入テンプレや評価テンプレ、あるいはフィードバックとしてプロダクト側へ戻し、全社で再利用できる形にしていきます。
ここでよく誤解されるのが、「それってASEじゃなくてよくない?」です。
ASEは決して、「御用聞きの受託開発」でも「プロンプトだけをいじるチューニング屋」でもありません。PoCの支援も行いますが、目的は「動くデモ」ではなく本番稼働に耐える設計と、プロダクトへのフィードバックです。
またプリセールス専任でもありません。SEが案件獲得を牽引するのに対し、ASEは実装・評価・連携で及第点まで押し上げます。
さらには、SRE/CREの常駐代替でもありません。CREはSLO/SLAやドリフト監視、回帰の安全網を仕組み化しますが、ASEはプロダクトの初期フェーズから伴走し、PMFまでを力強くサポートします。
ASEが0→1のフェーズで型化して作った「勝ちパターン」をSEが獲得で活用し、CREが運用に組み込む。このバトン設計が、ASEの担う役割です。
ただ設定するだけでは埋められない個社毎の業務との乖離に対して、試行錯誤を行い最適なチューニングのプロセスを作り上げ、プロダクトの価値を実感しやすくすることでプロダクトの拡大を支援するのです。
PoCは動く。でも及第点に届かない—生成AIを実装する現場でいちばん頻繁に起きる「違和感」は、ここに尽きます。
モデルは賢いし、一般知識は十分にある。
なのに、業務の手触りや顧客の言い回しにぴたりとは合わず、テスト環境では期待通りでも本番で急にバグる。
ASEの仕事は、この「動く」と「現場で使える(及第点)」のあいだに横たわる差分を詰め切ることです。
AIのふるまいと既存システムの接続を同時に扱い、プロダクトを「仕掛かり品」ではなく「完成品として届け切る」ことを役割として設計しています。型になったやり方はSE・CREにリレーされ、事業全体の標準へと還元されていきます。
この差分は一足飛びには埋まりません。
フェーズに分けるとすれば、「初期設定(0→80点)→社内検証(80→90点)→一般公開(90点→100点)」の三段階で表現することができます。
最初の一段は「どう作るか」より「何を作るか」の解像度勝負。
次の一段は「人の言い方の幅」を受け止めてほつれを潰す検証の手間が中心。
最後の一段は「現場の実際の流れ」に合わせて日々微調整を続ける運用の粘りが効きます。
同じ1時間の改善活動でも前半ほど改善効果が大きく、後半ほど逓減するのが常で、この前提に立った設計と評価の回し方が重要です。
この点数は決してAIの「精度」だけの話ではありません。実際の運用では100点という定義は難しいため、「これならば実際に運用しても問題ないだろう」というボーダーラインを便宜上100点と表現しています。そのため、この「100点」のボーダーラインは人や企業によって変わってきます。
以降は、Voicebotのチューニングで実際にあった例をもとに各フェーズでの取り組みについて説明します。
このフェーズでは、最適な体験の設計を行います。
どの業務範囲をどこまで自動で扱い、どこから人に委ねるのか。
応対のトーンはどの水準に置き、企業側の運用制約(窓口の分割、監査要件、転送ルール)と、顧客の焦りや言い回しの揺らぎをどう両立させるのか。
ここでの設計が、その後の精度改善の上限を決めます。いきなりプロンプトの枝葉に入るのではなく、まず「体験の目的関数」を言語化する。
目的関数とは、たとえば一次解決率・離脱率・転送先の妥当性・待ち時間、そして特定業界ならではの禁則などです。
これらをプロダクト上で評価できる前提(テストケースの登録・再評価のしやすさ)が整っていることを最初に確認することが重要です。
次に向き合うのは、企業の「窓口設計」と顧客の「困りごと」の衝突です。
企業は業務効率のために窓口を細かく分けたくなる。けれど、ログインできずに困って電話してきた人に、サービス選択や数字選択を延々と迫れば、苛立ちと離脱だけが残る。
ここでは顧客の発話をいったん「困りごとの言語」へ翻訳し、企業の窓口言語に写像する橋渡しが要になります。
ここで効くのは、VoCや通話ログを読み込み、ベテランの一撃を分解することです。
「ログインできない」の一言から、「PWを忘れた」「メールが届かない」「二要素で詰まっている」「端末が社用端末で制限が掛かっている」といった原因語彙の地図を作る。
ベテランが暗黙にやっている「目的の把握→感情への共感→正しい窓口への着地」の手続きを段階化し、エージェントの初期コンテキストとして与えます。
これが「まずは動く」を最短で達成する近道です。
加えて、この時点ではエスカレーションの作法も一緒に作ります。
初期は多少早めに人へ渡すガードレールを敷き、自動化よりも安全側に倒す。
その代わり、渡した後に何が起きたかをプロダクト上で追える可観測性を担保しておく(どの原因語彙で、どの窓口に、どれくらい渡ったか)。
こうして「エージェントがやるべきこと・やらないこと」の輪郭が見えてくると、80点は自然に超えていきます。
以降のフェーズで、SEやCREが横展開できる「型」にしていく前提も、この段階で仕込んでおくと効果的です。
このフェーズは、想定発話を作るところから始まります。
初期設計で描いた体験の方向性が、本当にユーザーの言葉で使えるかを確かめることが目的です。
たとえば、住所変更ひとつとっても伝え方は十人十色です。
実際の通話では「引っ越しました」「登録のところ変えたい」「旧住所がまだ出る」などと言い回しが散らばります。さらに季節やキャンペーンが重なると、「新生活で手続きが間に合わない」「年末調整の関係で」などの文脈語が混ざり、机上で作った「想定ユーザー(=ペルソナ)」があっという間に古くなってしまいます。
この対策として、よりリアルな想定ユーザーを立てて発話を網羅していく必要があります。
そのために、VoCや過去ログを元にユーザー像を具体化し、「発話×到達すべき状態」を格子状に並べた評価メッシュをつくっていきます。
あとはメッシュのマス目を埋めるようにテストを回し、差分は必ず「どこを直したら、どのマスが改善したか」で記録します。
LLMの動きはしばしばブラックボックスに見えますが、メッシュで網羅性を可視化すれば、回帰比較も影響範囲の見立てもチームで共有できます。
RightTouchでは評価テンプレや回帰比較の仕組みをプロダクト側に持ち込み、検証のやり直しを数分単位で反復できるようにしています。
このフェーズでは、実際のユーザーの動きを見ながら、仮説→修正→再確認のサイクルを最速で回せるように整えます。
公開直後は途中離脱や聞き取りミスが必ず出ます。これを「勘」で直してしまうと、改善のサイクルが途端に回らなくなってしまいます。
まず離脱の山を見つけ、発話→文字起こし→意図振り分け→回答のどこで破綻したかを一次切り分けします。
文字起こしの失敗なら辞書と表記ゆれ、ルーティングの失敗なら意図の定義と例示、回答の失敗なら根拠文の不足を疑う。
切り分けの単位を固定化しておくと、改善→再検証の速度が一気に上がります。
精度が高くなればなるほど課題は細かく、対応した際の影響は大きくなっていくため、これを高速に安全に回せる仕組みが必要になります。
例えばRightTouchのボイスボットでは通話・チャットのログからテストケースをそのまま登録し、before/afterを並べる運用をプロダクトとして支援しており、変更前後で精度を見比べることで日々の更新を怖がらずに回せるようになっています。
ここから先は、ASEが用意した「直し方の型」を、プロダクトやオンボーディングプロセスに落とし込んだり、CREが継続の仕組みに編み込む、という社内のバトンパスで安定度を上げていきます。
VoCや通話ログを起点に仮説を立て、評価テンプレートに追加しながら回すこのループは、RightTouchのプロダクト群がデータでつながる前提だからこそスムーズに回ります。
PoCは動くのに、いざ現場に置くと「及第点」に届かない。その差分を詰めるには、モデル単体の賢さではなく「文脈」と「運用」が要ります。
RightTouchのプロダクト群は顧客中心に設計され、行動ログ・通話ログ・VoC・ナレッジなどの重要データが面でつながっています。
Webの自己解決(QANT Web)→通話の前捌き(QANT コネクト)→VoCの分析(QANT VoC)→ナレッジ活用(QANT ナレッジデスク)→音声自動応答(QANT スピーク)という一連の流れが、評価・改善の土台になっています。
応対ログからテストを登録し、プロンプトのbefore/afterを比較できる仕組みがあるので、「評価が回る現場」を前提にチューニングを設計できる。この一体構造こそ、及第点に到達する速度を上げつつリソースを適切化する要因です。
組織側も、ASE(0→1〜型化)→SE(獲得)→CRE(運用信頼性)という役割を適切に分け、ASEが型にしたものをSEとCREが「拡げ・守る」設計です。
評価基盤/テンプレ/導入パッケージまで含めて型化するのがASEの業務なのです。
結果として、ASEが一社ごとの事情に寄り添いつつも属人化しないやり方で及第点を越えにいけるのがRightTouchです。
個別の「神対応」で終わらせず、評価テンプレや導入テンプレが持ち運べる資産として社内に蓄積され、次案件の初速が上がる。
SEとCREがその資産を使ってスケールさせるので、価値の提供が速く、効果の維持が長い。この構造こそ、ASEというロールを選ぶ意味であり、RightTouchでやる強い理由です。
PoCは動く。でも、及第点(業務に耐える品質)に届かない。
世に多くあるこの現象を解決するのは、設計・評価・連携・運用を面で扱うエンジニアリングです。
ASEは「プロダクトのラストワンマイルを埋めて、現場にプロダクトの価値を届け切る人」。
SaaSの開発やテクニカルサクセスの現場で「あと少しが届かない」を何度も味わってきた方に、ぜひチームに加わってほしいです。RightTouchのCEは「完成品で届ける」ことを前提に進化中です。ぜひ気軽に話しましょう。
<採用強化中:RightTouch採用概要>
資金調達に伴い、カスタマーサポート領域全体の変革に向けた事業をさらに推進すべく全職種で積極採用中です。
この記事で紹介したASEについても、先日JDを公開しています。
当社のチャレンジにご興味を持っていただいた方は採用サイト応募導線からのご連絡をお待ちしております。
直近で初のCompany Deckもリリースしたので、カスタマーサポート市場やRightTouchの事業展開をより詳しく知りたい方はぜひご覧ください。