Peak Demandは、Webサイト制作や基本的な業務自動化を支援する組織として始まりました。AIの能力が進化するにつれ、創業者のAlex Masters Lecky氏はより大きな可能性に気づきます。AIを使って顧客とコミュニケーションしたいと考える組織は増えている一方で、そのエージェントが企業の既存システムと確実に連携できるようにすることには大きな課題があったのです。
現在、Peak Demandは医療機関、製造業、公共交通機関など、複雑なワークフローを持つ組織向けに、Retell上で本番運用の音声AIシステムを設計・統合・運用しています。
Retellはこれらのデプロイの中核として、業界最高水準の会話型音声AIインフラを提供しています。これによりPeak Demandは、本番レベルのエージェント構築に必要なリアルタイムの音声パフォーマンス、信頼性、関数呼び出し、開発環境を手に入れています。
Peak Demandは、その周囲にある統合・オーケストレーション層を構築しています。この層がRetellと業務システムを接続し、決定論的なルールを組み込み、本人確認とバリデーションを処理し、ワークフローのロジックを管理します。さらに、クライアントの実際の業務に合わせて各デプロイを継続的に最適化しています。
Retellとカスタム開発のTELUS Collaborative Health Record連携を用いたCreekside Health向けデプロイについて、Peak Demandが報告した結果です。
Lecky氏によると、カナダ市場はAIの導入に慎重です。特に、プライバシー、セキュリティ、業務の信頼性が重視される医療や公共部門ではその傾向が強いといいます。
見込み客は当初、音声AIを少し高度な自動電話メニュー程度に考えていることがあります。Peak Demandの課題は、エージェントがそれよりはるかに多くのこと、つまり発信者を理解し、組織のルールを適用し、既存システムと連携し、有用な業務を確実に完了できることを示すことでした。
「カナダ人がAIに非常に懐疑的であることは、言うまでもないことです。」
この懐疑心が、Peak Demandの導入方針を形づくってきました。クライアントにAIに合わせて業務を再設計してもらうのではなく、組織がすでに使っているワークフローを軸にシステムを構築するのです。
Peak Demandの顧客であるCreekside Healthにとって、音声AIソリューションの必要性は差し迫ったものでした。このクリニックでは、患者との会話に対応しながら電子カルテシステムを適切に扱える受付スタッフがなかなか見つからず、医師自ら電話に出なければならないこともありました。しかし、電話に応答することは課題の一部にすぎませんでした。
実用的なエージェントには、患者を適切に識別し、その目的を理解し、クリニック固有の予約ルールに従い、空き状況を取得し、TELUS Collaborative Health Record内で予約処理を完了することが求められます。しかもそれを、不安を抱えていたり、体調が悪かったり、テクノロジーに不慣れだったりする患者と、自然な会話を保ちながら行う必要があったのです。
Peak Demandは、RetellとTELUS CHRの間にカスタム連携と決定論的なオーケストレーション層を構築しました。Retellは会話型音声AIインフラとして、患者とのリアルタイムの会話、音声、推論、関数呼び出しを処理します。その周囲にあるPeak Demandのミドルウェアが、それらの関数呼び出しが臨床システムとどのようにやり取りするかを制御します。本人確認、予約ルール、バリデーション、空き状況の照会、予約処理、クリニック固有のワークフローロジックなど、即興が許されない領域はこのミドルウェアが担います。
Lecky氏によれば、この役割分担は意図的な選択です。
「Retellはエージェントに患者を理解し自然にコミュニケーションする能力を与え、Peak Demandの決定論的ソフトウェアが会話の裏側で行われる業務アクションを制御しています。」
とはいえ、そこに至るまでには相当な試行錯誤が必要でした。会話型AIを実際の臨床環境に接続した際に生じるエッジケースに一つずつ対処していく中で、Creekside向けエージェントはおよそ200番目のバージョンに達したとLecky氏は振り返ります。
ローンチ後も、Peak Demandは新たな発信者の行動やエッジケースが現れるたびに、本番エージェントのモニタリングと最適化を続けています。Retellのワークスペース、通話記録、関数呼び出しログにより、Peak Demandは想定外のやり取りを迅速に診断し、各デプロイを継続的に改善するために必要な可視性を得ています。
Lecky氏によると、本番環境で発生する問題の多くは、大規模な再開発サイクルを必要とせず、数分から数時間で診断・修正できるといいます。
「本当に機能するものにたどり着くまでに、私たちはこうしたエージェントを何百ものバージョンにわたって改良しています。」
Peak Demandは、Creeksideにおいて予約ワークフローの完結率74.9%、予約フローの成功率94.9%を達成し、測定期間中に196件の予約を獲得したと報告しています。これらの結果は、1,100件を超える接続済み通話を対象とした連携後の広範な分析に基づくものです。
Peak Demandにとって、こうした成果は、当初音声AIに慎重だった組織との対話の性質を変えました。そもそもテクノロジーが機能するかどうかを議論するのではなく、次にどのワークフローを任せるべきかに焦点が移りつつあります。
Creeksideでのデプロイにより、医療スタッフや医師が日常的な電話対応に時間を割く必要も減りました。Peak Demandは同じ考え方を他の現場にも応用しています。ある在宅医療事業者では、時間外対応のRetellエージェントが夜間の電話に応答し、必要な情報を収集したうえで、フォローアップのために適切な担当チームへ案件を振り分けています。また、あるグローバル製造業のクライアントでは、Retellベースの受付が大量の不要な電話をふるい分けつつ、正当な営業、部品、テクニカルサポート、顧客からの問い合わせを識別して転送しています。
「単調な業務の一部を引き受けることで、優秀な人材の業務を強化し、より生産的な仕事に取り組めるようにしています。」
Peak Demandは当初、公共交通の時刻表エージェントをSynthflow上で構築しようとしていました。そこでの課題は、扱う情報の量だけでなく、その情報の構造にありました。
実用的なシステムには、路線、停留所、運行方向、発車時刻、ダイヤの変動、さらにそれらの相互関係を網羅した、数千行に及ぶ時刻表情報を横断して機能することが求められます。利用者は正確な路線番号を知らないまま次のバスを尋ねたり、停留所ではなく目的地を説明したり、会話の途中で方向を変えたり、通話の前半で取得した情報に依存する追加の質問をしたりするかもしれません。データセットと検索要件が拡大するにつれ、Peak Demandは、プロジェクトに必要な挙動を維持しながら交通情報の量と構造に確実に対応することがSynthflowでは難しいと判断しました。
プロジェクトをRetellに移行したことで、実現できることが大きく変わりました。Retellのナレッジベース機能により、Peak Demandは膨大な交通情報を整理し、会話中にその情報をどのように検索・解釈・活用すべきかをエージェントに正確に指示できるようになりました。これによりRetellエージェントは、想定されるすべての時刻表照会に対してPeak Demandが専用の外部APIリクエストを構築しなくても、適切な時刻表情報を取得し、発信者に自然に伝えられるようになったのです。
信頼性もその判断を後押ししました。前年に発生した世界規模の大規模なテクノロジー障害（Cloudflareを含む多数のプラットフォームやインフラプロバイダーに影響）の際にも、Peak DemandのRetellエージェントは通話への対応を続けていました。ますます複雑化するデプロイにおけるRetellのパフォーマンスと相まって、この経験がLecky氏に、Peak Demandの音声AI業務をこのプラットフォームに集約する確信を与えました。
Peak Demandの医療・交通分野でのデプロイがRetellの目に留まり、最終的にパートナープログラムへの招待につながりました。Peak Demandにとってこの関係がうまく機能しているのは、両社が本番運用の音声AIという課題の補完的な部分をそれぞれ解決しているからです。Retellは重要な会話型音声AIインフラと開発環境を提供します。これによりPeak Demandは、クライアントの業務の理解、Retellと既存システムの接続、ビジネスルールの組み込み、エッジケースのテスト、そして本番稼働後のシステムに対する責任を担うことに集中できます。
「事業者に音声AIの運用をすべて自力で担ってもらうのは、多くの場合現実的ではありません。」
Lecky氏は5〜10名のチームメンバーとともに働いており、現在では同社の自動化とワークフロー開発の70〜80%がRetell上で行われていると見積もっています。パートナープログラム参加以前、チームは関心の大半をクライアント業務に注いでいたため、より広い技術コミュニティに参加する時間はあまりありませんでした。プログラムを通じて、Lecky氏は他のRetellビルダーとのつながりを深め、導入ノウハウを共有し、複雑なデプロイに関する質問に答えるようになりました。一方Retellも、もともと個々の組織向けに開発された取り組みを、はるかに幅広い層に届ける手助けをしています。
Lecky氏は、パートナープログラムを通じたエンタープライズ企業の紹介も、Peak Demandのモデルの自然な延長だと考えています。多くの組織が必要としているのはAIプラットフォームだけではなく、そのプラットフォームを実際に機能する業務システムへと仕上げ、ローンチ後も改善し続けられる熟練した導入パートナーなのです。
Peak Demandは現在、公共交通向けエージェント群の本格展開に向けた準備を進めています。時刻表の検索に加えて、このプロジェクトには複雑な公共サービスのリクエストを会話形式で処理するよう設計されたエージェントも含まれています。
このシステムは、複数のリクエスト経路にわたる広範な回帰テストを完了しています。カスタムのMCPベース連携層がRetellエージェントと交通当局のシステムを接続し、エージェントが必要な情報を収集・検証したうえで、利用者に代わってリクエストを送信できるようにしています。
このアーキテクチャにより、カナダの公共交通は従来型IVRを大きく超えるものになります。クライアント側で完了すべき技術作業がまだ一部残っており、Lecky氏によれば、ほかに2〜3の交通事業者が同様のデプロイを進める前にこのプロジェクトのローンチを待っているといいます。Peak Demandは、さらに別の自治体組織や医療機関とも協議を進めています。
Lecky氏は、音声AIがいずれ電話そのものを超えて広がると見ています。Peak Demandは、音声による指示で業務ソフトウェア全体にわたるアクションを起動し、従来のインターフェースを操作するのではなく会話で複雑なシステムを動かせる用途を模索しています。これにより、ソフトウェアに苦手意識がある人や、入力やクリックよりも話すことを好む人にとって、高度なテクノロジーがはるかに身近なものになる可能性があります。
「特にテクノロジーに詳しくない人でも、Retellのようなシステムを通じて、テクノロジーにただ話しかけるだけで済むようになります。」
柔軟で常に進化し続けるRetellのプラットフォームにより、音声AIは単に電話に応答するだけの存在を超え、より重要なもの、つまり組織の日々の業務全般に確実に参加できる会話型システムへと進化しつつあります。
すでにクライアントとRetellを活用していて、参加をご希望ですか？Retellのパートナープログラムの仕組みはこちら。