通話のイベントを利用者のサーバーへ、署名と再送つきで確実に届ける

この会社は、電話や Web の音声で受け答えをする AI の受付を作るための基盤を提供しています。利用者は、この基盤を組み込んで独自のサービスを作る事業者です。医院や店舗の予約を受け付けるサービス、企業に代わって電話に応対するサービスなど、基盤の上ではさまざまな用途の音声の受付が動いています。

基盤の上で交わされた通話の結果は、利用者のサービスにとって欠かせない情報です。通話が終わったことや、要約や録音の準備ができたことを、利用者のサーバーへ速やかに、確実に伝える必要があります。同社は、こうした通話のイベントの配信に Webhook Admin を採用しました。配信の仕組みをどのように整えたのか、その経緯を紹介します。

通話の結果を待っている利用者のサービス

音声 AI の基盤では、一つの通話の中で多くのことが起こります。電話がつながり、AI が用件を聞き取り、必要に応じて予約の空きを確かめたり担当者への引き継ぎを判断したりして、通話が終わります。通話の後には、内容の要約や文字起こし、録音のデータが用意されます。

利用者のサービスは、こうした出来事に合わせて自らの処理を進めます。予約を受け付けるサービスであれば、通話の要約を医院や店舗のスタッフに伝えます。電話を代行するサービスであれば、応対の結果を依頼主の企業に知らせます。AI が担当者への引き継ぎを求めた場合には、利用者の側ですぐに人が対応する準備を整えなければなりません。

利用者のサービスがこうした処理を行うには、基盤の側から出来事を知らせる仕組みが必要です。利用者が基盤に定期的に問い合わせて新しい通話を探す方法もありますが、それでは知らせが遅れ、問い合わせの回数も増えます。出来事が起きた時点で、基盤から利用者のサーバーへイベントを送る Webhook の方式が、この用途に適していました。

通話に関わる出来事のほかに、利用料の残高に関わる知らせも欠かせません。残高が少なくなったことを利用者が早く知ることができなければ、通話の受付が止まるおそれがあります。通話と残高のどちらのイベントも、利用者のサーバーへ確実に届けることが求められていました。

確実な配信に必要だった多くの仕組み

Webhook の方式でイベントを送ること自体は、技術的には難しくありません。しかし、利用者が安心して受け取れる配信を実現するには、送る処理のほかに多くの仕組みが必要になります。

まず、受け取ったイベントが本当に基盤から送られたものかを、利用者が確かめられなければなりません。第三者が偽のイベントを送りつけたり、内容を書き換えたりすることを防ぐには、イベントごとに署名を付け、利用者の側で検証できるようにする必要があります。

次に、配信が失敗した場合への備えです。利用者のサーバーが一時的に応答しない、更新作業の最中であるといった事情で、イベントが届かないことは避けられません。失敗したイベントを間隔を空けて再送し、同じイベントが重複して処理されないように配慮する仕組みが要ります。

さらに、配信の記録も欠かせません。利用者から通話の結果が届いていないという問い合わせを受けたとき、いつ、どの宛先に、どのイベントを送り、どのような応答が返ったかを確かめられなければ、原因を切り分けられません。利用者ごとに配信先を管理し、一時的に配信を止めたり再開したりする操作も必要でした。

これらを社内で独自に開発し、利用者が増えても安定して動かし続けることは、同社にとって負担の大きい課題でした。開発の力は本来、音声 AI の受け答えの質や通話の機能の改善に注ぎたいと考えていたためです。

独自開発ではなく専用の配信サービスを選ぶ

同社は、配信の仕組みを社内で独自に開発する案と、専用の配信サービスを利用する案を比べました。独自に開発すれば細部まで思いどおりに作れますが、署名、再送、重複の防止、配信の記録、配信先の管理と、整えるべき要素は多岐にわたります。開発が終わった後も、障害への対応や利用者の増加に合わせた見直しを続けなければなりません。

検討の結果、同社は Webhook 統合インテグレーションの Webhook Admin を採用しました。署名と再送、配信の記録を備えた配信の仕組みをそのまま利用でき、イベントの種類や利用者ごとの配信先も管理できる点を評価しました。署名は Standard Webhooks の方式に沿っており、利用者が広く知られた方法で検証できることも判断の材料になりました。

配信の仕組みを任せることで、同社の開発の担当者は、どの出来事をイベントとして送るか、イベントにどのような情報を含めるかといった、基盤ならではの設計に集中できます。配信そのものの確実さは Webhook Admin に委ねるという役割の分担が、同社の考えに合っていました。

採用の前には、テスト環境で配信先を作り、署名の付いたイベントを受け取る処理を試しました。利用者の側で必要になる作業が、署名の検証とイベントの種類ごとの処理の振り分けに収まることを確かめられたことで、利用者に過度な負担をかけずに導入できるという見通しが立ちました。

通話と残高のイベントを種類ごとに整理する

導入にあたって、同社はまず配信するイベントの種類を整理しました。通話の開始と終了、要約の準備完了、文字起こしの準備完了、録音の準備完了、担当者への引き継ぎの依頼、残高の低下といった出来事を、それぞれイベントの種類として Webhook Admin に登録しています。

イベントの種類を細かく分けたのは、利用者が必要なイベントだけを受け取れるようにするためです。通話の終了と要約だけを受け取りたい利用者もいれば、引き継ぎの依頼をすぐに受け取って人の対応につなげたい利用者もいます。種類ごとに受け取りを選べることで、利用者は自らのサービスに合った形でイベントを扱えます。

イベントの内容についても、種類ごとに含める情報を決めました。通話を識別する番号や、通話の開始と終了の時刻、要約や録音の準備ができたことなど、利用者が自らのサービスの記録と突き合わせるのに必要な情報をそろえています。イベントの形をあらかじめ定めておくことで、利用者は受け取りの処理を作りやすくなります。

利用者ごとには、Webhook Admin の顧客と配信先を設定しました。基盤の利用者一社ごとに顧客を作成し、その利用者のサーバーの宛先を配信先として登録しています。利用者ごとに配信先が分かれているため、ある利用者の宛先の変更や一時停止が、ほかの利用者への配信に影響することはありません。

テスト送信と並行運用で確かめた切り替え

配信の切り替えは段階を追って進めました。最初はテスト環境で、イベントの種類ごとに Webhook Admin のテスト送信を使い、署名の検証や受け取りの処理が想定どおりに動くかを確かめました。

続いて、基盤を利用する社内のサービスを最初の受け取り手として、通話の終了や要約のイベントを配信しました。予約を受け付けるサービスや電話を代行するサービスが、実際の通話の結果をこの配信で受け取り、スタッフや依頼主への知らせに使える状態であることを確認しています。

外部の利用者には、イベントの種類と内容、署名の検証の方法を説明する資料を用意しました。利用者は、自らのサーバーで署名を検証し、イベントの種類に応じて処理を振り分けます。利用者のサーバーの更新作業の間は配信先を一時停止し、作業が終わってから再開する運用も案内しています。

切り替えの期間には、基盤の側で通話の結果を問い合わせる従来の方法も残し、配信と並行して使えるようにしました。利用者は、配信で受け取ったイベントと問い合わせで得た結果を見比べ、取りこぼしがないことを確かめたうえで、配信を中心とした運用に移っています。

署名と再送が支える日々の配信

導入後、通話と残高のイベントは、署名を付けて利用者のサーバーへ配信されています。利用者は署名を検証することで、受け取ったイベントが基盤から送られたものであることを確かめられます。検証に通らないイベントは処理せずに破棄すればよいため、利用者は偽の通知によって誤った処理を行う心配をせずに、通話の結果を自らのサービスに取り込めます。

利用者のサーバーが一時的に応答しなかった場合も、イベントは間隔を空けて再送されます。同じイベントが二度届いても重複して処理されないよう配慮されているため、利用者の側で通話の結果が二重に登録される心配も小さくなりました。

配信の記録は Webhook Admin で確認できます。利用者から通話の結果が届いていないという問い合わせを受けた場合も、記録をもとに送った時刻や応答の内容を確かめ、利用者のサーバーの側の問題か、配信の設定の問題かを速やかに切り分けられるようになりました。

予約を受け付けるサービスや電話を代行するサービスなど、基盤を利用するサービスは、通話の終了や要約をこの配信で受け取り、医院や店舗のスタッフ、依頼主の企業への知らせにつなげています。配信の仕組みを独自に持つ必要がなくなったことで、同社は開発の力を音声 AI の機能の改善に集中できています。

運用の担当者にとっても変化がありました。配信の失敗が続く配信先は記録から把握でき、必要に応じて利用者に連絡して宛先の設定を見直してもらうといった対応を、早い段階で取れるようになりました。配信の状況を一か所で確かめられることで、利用者からの問い合わせへの対応も標準化されつつあります。

利用者の広がりに合わせた次の取り組み

同社は今後、基盤の機能の追加に合わせて、配信するイベントの種類も広げていく方針です。新しい出来事をイベントとして送る場合も、種類を登録して配信先の設定を確かめれば、これまでと同じ仕組みで利用者に届けられます。利用者の側も、新しい種類の受け取りを選ぶだけで、既存の配信先のまま新しいイベントを扱い始められます。

利用者の数が増えても、利用者ごとの配信先と配信の記録を同じ方法で管理できる体制が整っています。同社は、イベントの内容や署名の検証の方法の案内を充実させ、利用者が基盤の通話の結果を自らのサービスにより速く取り込めるよう支えていく考えです。

あわせて、残高の低下を知らせるイベントの活用も広げていく予定です。利用者が残高の知らせを受け取って早めに手続きを進められるようにすることで、通話の受付が途切れる事態を防ぎ、基盤の上で動くサービスの安定につなげていきます。