医療向けElevenAgents：受電による予約スケジュールエージェントの構築

電話は今も医療への入り口ですが、混み合っています。Mayo Clinicの調査とEpicのケーススタディのデータによると、予約受付のおよそ30％は通常の営業時間外に行われています。留守番電話につながった電話は、気付かれないまま実現しない予約です。その受け皿となる受付スタッフも人手不足で、離職が相次いでいます。音声エージェントはすでにデモ段階を超え、クリニックがこのギャップを埋める手段となっています。なかでも予約受付は、件数が多く、反復的で予測しやすく、臨床的な判断を必要としない受付業務の大きな部分を占めるため、最も一般的な導入ポイントです。

医療における予約受付では、より高い水準が求められます。誤った時間枠の案内や受診理由の聞き違いは、単なる不快な体験ではなく、安全性とコンプライアンスに関わるインシデントです。受付の予約エージェントには、感じのよい音声だけでは不十分です。信頼できる本人確認、厳格なガードレール、人への明確なエスカレーション経路、保護対象医療情報を扱うためのコンプライアンス体制、そして実際の予約システムで予約の作成・変更・キャンセルを完了する能力が必要です。

このガイドでは、ElevenLabs Agentsを使ってこれを構築します。サンプルEHRに接続した電話対応可能なエージェントが、予約の作成、変更、キャンセルをエンドツーエンドで行い、必要な場合はエスカレーションします。規制のある医療環境向けに構築されたインフラストラクチャ上で、ルールを守るためのワークフロー、ガードレール、テスト、分析を紹介します。

ここでは、これから構築するエージェントが実際の通話を最初から最後まで処理するデモをご紹介します。

前提条件

始めるには、以下が必要です。

• ElevenAgentsプラットフォームとElevenLabsの音声にアクセスできるElevenLabsアカウント。
• Twilioアカウントと電話番号。
• Twilio Verifyへのアクセス。
• サンドボックスまたはデベロッパー向けEHR環境。このガイドでは、HAPI FHIRを使用します。これはHL7 FHIR形式のオープンソースのリファレンス実装で、合成患者レコードとの照合に使用します。
• 院内のカレンダーアプリケーション。このガイドでは、ElevenLabsのネイティブインテグレーションでCal.comを使用します。 

任意

サンドボックスデータにアクセスできない場合や、デモ目的で手順を試す場合は、HAPI FHIR R4サンドボックスサーバーを使用し、本人確認段階で利用できるモック患者レコードを登録します。そのためには、ターミナルから次のAPIコマンドをモックデータとともに実行してください。

curl -X POST "https://hapi.fhir.org/baseR4/Patient" \
  -H "Content-Type: application/fhir+json" \
  -H "Accept: application/fhir+json" \
  -d '{
    "resourceType": "Patient",
    "identifier": [
      { "system": "http://hospital.example.org/mrn", "value": "<YOUR-FAKE-MRN-NUMBER>" }
    ],
    "name": [ { "use": "official", "family": "<YOUR-FAKE-FAMILY-NAME>", "given": [ "<YOUR-FAKE-GIVEN-NAME>" ] } ],
    "gender": "<male or female>",
    "birthDate": "<YOUR-FAKE-DOB> (in YYYY-MM-DD format)"
  }'

一致が確認されるのは、クエリが正確に1件のレコードを返した場合のみです。結果が0件なら一致なし、複数件なら安全に進めるには検索パラメーターの特定性が不足しています。 

アーキテクチャ

このガイドでは、ElevenAgentとネイティブに統合され、Twilio番号を通じて稼働する予約エージェントを構築します。着信が接続されると、エージェントは利用可能なツールを使って患者の本人確認情報と予約詳細を取得します。新規予約、既存予約の変更、キャンセルのいずれを希望する場合でも対応し、必要に応じて人へ通話を転送できます。

このアーキテクチャとツールにより、正常な通話フローは次のステップで進みます。

1. 通話開始：患者がエージェントに紐付けられたTwilio番号へ電話をかけると、エージェントが挨拶し、用件を把握します。
2. EHR検証：エージェントが患者情報をEHR内のレコードと照合します。
3. 本人確認：エージェントがSMSツールを使い、最終確認用のワンタイムパスワード（OTP）を患者の電話番号に送信します。
4. 予約または変更：エージェントが把握した用件に基づきカレンダーを操作します。新規予約では予約詳細を取得して空き状況を確認し、変更では既存の予約を表示して新しい時間枠を探し、キャンセルでは既存の予約を確認して削除します。
5. 転送：予約または変更に失敗した場合、患者が人との会話を希望した場合、またはエージェントが対応できない別の用件が検出された場合、通話は担当者に転送されます。
6. 確認と終了：予約、変更、キャンセルが完了すると、エージェントが通話内容を要約し、丁寧に通話を終了します。

システムプロンプトとエージェント設定

効果的なElevenAgentを構築する第一歩は、システムプロンプトです。ElevenLabsのプロンプトガイドに従い、本番環境のエージェントに推奨される基本要素、つまりパーソナリティ、目標、トーン、ツール、ガードレールを、一続きの指示文ではなく、それぞれ明確な見出しを付けたセクションに分けて構成します。

医療予約エージェントでは、この構成で電話の向こうにいる人を考慮する必要があります。高齢の方、痛みを抱えている方、聞こえにくい方、あるいは電話の理由に不安を感じている方かもしれません。パーソナリティとトーンのセクションでは、温かく急かさないペースを設定し、応答を短く会話的に保ちます。日付、時刻、数字は画面を読み上げるのではなく、人が自然に話す形で伝えます。目標のセクションでは、本人確認の後、発信者が新規予約、変更、キャンセルのどれを希望するかに応じて、空き状況を確認して時間枠を確定する、既存予約を検索して変更する、削除する予約を確認するという順序でフローを示します。ツールには、想定する音声形式の入力を正確に記載します。ガードレールには、この領域固有のルールを設定します。発信者がすでに共有した以上のPHIを表示しない、ツールの失敗時に空き状況や予約詳細を捏造しない、臨床的な質問には発信者自身の医療提供者に相談するよう案内する、緊急症状や医療上の緊急事態が説明された場合は直ちにエスカレーションする、といったルールです。予約に関する操作の前に本人確認を行うことは、一度だけでなく繰り返し記載する唯一のルールです。エージェントが絶対に見落としてはならない境界線だからです。

ここから、追加のエージェント設定を追加できます。たとえば、最初のメッセージ、異なる言語（言語検出システムツールが有効であることを確認してください）、任意のLLM、会話向けElevenLabsテキスト読み上げモデル、ElevenLabs音声などです。

システムプロンプトの例はこちらで確認できます。

ガードレール

システムプロンプトの「ガードレール」セクションは、指示レベルのルールを扱い、モデル内で強く重み付けされます。ただし、プロンプトは依然として非決定論的なレイヤーであり、長い通話の中で逸脱する可能性があります。ElevenAgentsは、独自のガードレールにより、実行時の独立した強制機能でこれを補完します。会話が長くなってもシステムプロンプトを強化するFocus Guardrail、エージェントの応答前にプロンプトインジェクションの試みを検出するManipulation Guardrails、すべての応答をリアルタイムで評価し、発信者に聞こえる前にブロックできるContent GuardrailsおよびCustom Guardrailsがあります。各ガードレールには実行モードを設定します。ほぼゼロレイテンシーのストリーミング、または応答を通過するまで保留するブロッキングです。また、トリガー時の終了戦略も設定します。通話を終了するか、次のターンに修正フィードバックを挿入して再試行します。

このエージェントでは、医療機関やクリニック固有のルールに合わせてカスタムガードレールを定義できます。病状の診断や治療の推奨、請求に関する質問、薬剤の用量に関する案内、資格を持つ臨床医からの助言の代わりとなる内容をブロックします。緊急症状に対しては、人への通話転送を促すフィードバックを伴う再試行を終了戦略に設定します。これにより、ガードレールは通話をただ終了するのではなく、スタッフへ引き継げます。

ツール

フローの各ステップでは、患者と会話しながら特定の操作を実行するために、Webhookツールとインテグレーションツールが必要です。

EHR本人確認ツール

患者情報をEHRのレコードと照合するには、FHIR GET /Patient APIアクションを使用します。family、given、identifier、birthdateをLLM入力パラメーターとして設定し、HAPI FHIRベースURLを指すWebhookツールとして追加します。本人確認ステージでの最初のツール呼び出しは、発信者の氏名と生年月日を1つのクエリでエンドポイントに送信します。

GET /baseR4/Patient?family={lastName}&given={firstName}&birthdate={YYYY-MM-DD}

一致が確認されるのは、クエリが正確に1件のレコードを返した場合のみです。この条件を満たした場合にのみ、エージェントは予約ステージへ進めます。

ツールのJSON例はこちらで確認できます。

Twilio SMS本人確認ツール

EHRとの一致が確認されると、本人確認ステージは第2要素へ進みます。患者にワンタイムコードをテキストメッセージで送信し、他の操作の前に確認します。設定は次の3ステップです。

1．SMS Webhookツールを作成します。次の2つのツールを設定します。send_SMS_verificationとcheck_SMS_verificationです。いずれもTwilio Verifyサービスを指定します。それぞれ、Verifyサービスの設定にあるVA... 値であるVerify Service SIDをURLパスに指定し、シークレットとして保存したAccount SIDとAuth Tokenから作成したBasic認証ヘッダーを設定します。

2．システム変数で受信者を設定します。ElevenAgentsはシステム変数を提供しています。これにより、すべての音声通話で発信者の電話番号がsystem__caller_idに自動入力されます。発信者に電話番号を読み上げてもらう代わりに、Toパラメーターとして{{system_caller_id}} を渡してください。実際のEHRと統合した本番環境では、発信者IDではなく、患者レコードに保存された電話番号へコードを送信します。

3．skip_turnを有効にします。このシステムツールをWebhookツールと併せて追加すると、発信者がメッセージを探している間、エージェントは沈黙して待機できます。間を埋めるように話しかけることはありません。

EHR検索とOTP確認の両方を通過した発信者のみが、予約ステージへ進めます。 

両ツールのJSON例はこちらとこちらで確認できます。

カレンダーインテグレーションツール

予約ステージでは、実際のカレンダーに対して空き状況の確認、予約、変更、キャンセルを行う必要があります。Cal.comインテグレーションの設定は次の3ステップです。

1．インテグレーションを接続します。エージェントの［ツール］タブからCal.comインテグレーションを追加し、［Connect］をクリックします。

2．イベントタイプを固定します。各カレンダーツールには、イベントタイプIDが必要です。これはCal.comに予約対象のイベントを指示します。接続したツールでは、このIDを固定パラメーターとして設定します。IDはCal.comダッシュボードで確認できます。

3．参加者のメールアドレスを設定します。予約ツールには参加者のメールアドレスも必要です。デモでは、確認メールが受信トレイに届くよう、自分のメールアドレスを固定パラメーターとして設定します。実際のEHRを使う本番環境では、ハードコードした値ではなく、患者レコードのメールアドレスを入力します。

ここから先の予約フローは、Greetingで把握した用件に応じて異なります。新規予約では、エージェントはまずcalcom_get_available_slotsを呼び出して空き時間を照会してから候補を提示し、その後、発信者の確認を受けてcalcom_create_bookingを呼び出します。空き状況の確認を先に行うことで、時間枠の二重予約を防げるため、この順序を必ず守ります。変更またはキャンセルでは、まずcalcom_find_bookings_by_attendeeで発信者の既存予約を検索し、対象の予約を発信者に確認します。その後、calcom_cancel_bookingで削除するか、変更の場合は古い予約をキャンセルする前に新しい時間枠を予約します。

人への転送

人へ転送するには、ElevenLabsのtransfer_to_number システムツールを使用できます。Greeting、Verification、Bookingのどこからでも利用できるよう、エージェントレベルでシステムツールとして追加します。転送ルールには、E.164形式の転送先電話番号と、転送を実行する条件を自然言語で追加します。LLMは、これらの条件とツールの説明に基づいて、いつ、どこへ転送するかを判断します。転送タイプは、デフォルトのConferenceのままにしてください。人のオペレーターに通話の理由を説明する、温かみのある引き継ぎメッセージに対応しているためです。

患者ジャーニーの構造化

ワークフローは、複数のノードタイプで構成される視覚的なグラフベースの会話フローです。通話の一つのフェーズに対して、オーケストレーターのベースエージェントにシステムプロンプト、ツール、ナレッジベースを重ねるサブエージェントノード、特定ツールの実行を保証し成功または失敗で分岐するディスパッチツールノード、引き継ぎ用のエージェント転送ノードと電話番号転送ノード、通話を終了するエンドノードがあります。ノードはエッジで接続され、順方向のエッジにはLLM条件を設定できます。これは、どの経路を選ぶかをモデルがリアルタイムで評価する自然言語ルールです。エージェントは、Greeting、Verification、Booking、Transfer Notice、Closeの5つのサブエージェントノードとして構築し、それぞれに専用ツールをスコープ設定します。さらに、Transfer Noticeから到達できるPhone Number Transferノードを1つ追加します。

あいさつはエントリーポイントです。通話に応答し、クリニックを紹介して、引き継ぐ前に患者の用件を把握します。専用ツールは不要で、適切にルーティングできる最低限の情報のみを収集します。

本人確認は、先ほど説明した二要素確認を担います。FHIRのGET /Patientツールで発信者がEHR内のレコードと一致することを確認し、続いてsend_SMS_verificationとcheck_SMS_verificationツールでワンタイムコードを送信・確認してから、発信者を先へ進めます。両方のゲートを通過した発信者だけが次へ進み、それ以外はTransfer Noticeへの順方向エッジに進みます。

予約には、前のセクションで紹介したカレンダーツールを配置します。Greetingで把握した用件が経路を決定します。新規予約では空き状況を確認して予約し、変更では既存の予約を検索して新たに予約してからキャンセルし、キャンセルでは確認して取り消します。このノードはTransfer Noticeへもフェイルオープンします。カレンダーに適した候補がない、発信者を既存予約に照合できない、または発信者がスタッフとの会話を希望する場合、通話を停止させるのではなく、このエッジでルーティングします。

転送のお知らせは、ワークフローの他の部分と実際の引き継ぎの間に配置します。エージェントから通話が離れる前に、「ただいま担当者におつなぎします」のように転送を伝えることだけを役割とする短いサブエージェントです。Greeting、Verification、Bookingから直接transfer_to_numberを実行するのではなく、すべての転送条件をまずこのノードに通すことで、サブエージェントごとに表現が異なっても、発信者が無言で転送されることなく必ずこの案内を聞けます。

電話番号への転送は、transfer_to_numberツールを基盤とし、Transfer Noticeが常に転送するノードです。そのルールでは、転送先番号と上流から引き継いだ同じ条件、つまり本人確認の失敗、明示的な依頼、完了できない予約を組み合わせ、発信者に転送を伝えた後で実際の引き継ぎを実行します。

終了には、予約が正常に完了した後にのみ到達します。予約の詳細を発信者に振り返り、温かい言葉で通話を終了します。

ワークフローのJSONテンプレート例は こちらで確認できます。

分析とテスト

医療音声エージェントで大半の労力を要するのは、理想的なフローではありません。通話が台本どおりに進まないときにも、すべてを正しく処理することです。ElevenAgentsには、プラットフォームネイティブのテストと分析が組み込まれています。つまり、ローンチ前のテストに使用する評価基準で、本番環境のすべての通話も評価できます。別途ツールを接続・照合する必要はありません。

成功基準

ビジネスと運用の目標に沿った具体的な評価基準を把握するには、成功基準を定義します。［分析］タブでは、各基準はLLMが文字起こしに対して実行する自然言語プロンプトです。根拠とともに、成功、失敗、または不明を返します。このエージェントでは、以下のような基準を設定できます。

• patient_verified：「予約に進む前に、エージェントがEHR検索とSMSワンタイムコードの両方で発信者の本人を確認した場合、成功とマークする。」
• appointment_booked：「患者の予約が作成された場合、成功とマークする。」
• appointment_changed：「患者が既存予約の変更またはキャンセルを依頼し、エージェントがカレンダーイベントの更新または削除によってその変更を完了し、結果を発信者に確認した場合、成功とマークする。」 
• call_escalated_when_requested：「発信者が人との会話を希望し、エージェントが通話を転送した場合、成功とマークする。発信者が希望したにもかかわらずエージェントが転送しなかった場合は、失敗とマークする。」

データ収集

これらをデータ収集フィールドと組み合わせることができます。たとえば、requested_action（予約、変更、キャンセル）、appointment_date、appointment_typeなどを追加できます。これらは各文字起こしから構造化された文字列、ブール値、数値として抽出され、通話後Webhookを通じて通話結果を追跡するシステムへ送信されます。 

シミュレーションとテスト

医療では、エージェントは最初の実際の通話の前に信頼を得なければなりません。障害モードは患者の前ではなく、テストで明らかにする必要があります。会話シミュレーションAPIは、エンドツーエンドと対象セグメントの両方で、現実的な発信者シナリオをシミュレーションします。また、本番環境で使用されるのと同じ基準、つまり上記で定義したpatient_verifiedおよびappointment_bookedのチェックを使って、結果を自動評価します。テスト専用の別の評価基準ではありません。通話全体に対する完全なシミュレーションを実行することも、会話の途中から開始して単一の判断ポイントを検証する部分シミュレーションを実行することもできます。後者は、フロー全体を再実行せずに一つのノードを素早く改善する方法です。 

このエージェントでは、理想的なフローを超えたシナリオをスクリプト化します。氏名がどのEHRレコードにも一致しない発信者、OTPの入力を2回間違える人、予約ではなく変更を希望する患者、本人確認の途中で明示的に人との会話を希望する発信者などです。こうした明確で焦点を絞ったシナリオにより、エッジケース、ツール使用、フォールバックロジックを本番環境で偶然見つけるのを待たずに検証できます。

Twilio電話番号を接続する

エージェントを構築したら、実際の電話番号への接続は数分で完了します。

1. ElevenLabsダッシュボードで、電話番号に移動し、番号をインポートをクリックします。
2. ラベル、電話番号、TwilioのアカウントSIDと認証トークン
3. を入力します。インポート後、ドロップダウンから番号をエージェントに割り当てます。
4. 番号に電話をかけてテストし、Conversations履歴ダッシュボードで最初の数件の通話が想定どおりに動作したことを確認します。

実際の患者への提供準備

構築したのは、電話に応答するだけではない患者予約エージェントです。レコードにアクセスする前にEHRと第2要素OTPで本人を確認し、Cal.comのAPIを通じてライブカレンダー上で予約、変更、キャンセルを直接実行します。また、必要なときには対応を引き、人へ通話を引き継ぎます。決定論的なワークフロー、実行時ガードレール、評価基準により、チームは医療導入に必要な監査証跡と再現可能なテストパターンを得られます。

本番運用の開始こそ、このパターンが真価を発揮する場面です。構築時に定義した評価基準が、本番開始の基準になります。エージェントが一貫して基準を満たし、指標が安定したとき、感覚的な判断ではなく確信をもってリリースできます。リリース後は、シミュレーションテストから本番環境の文字起こしへと学習の対象が移ります。段階的なロールアウトから、改善を止めるタイミングの判断まで、こうした実践については以前のブログで解説しています。

HIPAA準拠に向けた重要なステップの一つが、データ処理です。Zero Retention Modeを有効にすると、通話終了時に通話録音、文字起こし、PIIを含むメタデータが即座に削除され、電話ベースの導入における最大のコンプライアンスリスクを排除できます。通話後Webhookと組み合わせても、可視性が失われることはありません。通話が終了する際、すべての予約結果、本人確認結果、評価スコアがリアルタイムで自社システムに送信されます。

これで、エージェント型音声AIをクリニックの入り口に導入するためのテンプレートができました。予約受付は最も件数の多い導入ポイントであり、同じパターンは患者受付、処方箋の更新、請求、受診後のフォローアップにも拡張できます。いずれも、営業時間外に留守番電話へつながる必要がなくなる通話です。Forward Deployed Engineeringチームは、医療機関と密接に連携し、このような導入を具体的なプロダクト機能へと変換します。医療に求められるコンプライアンス体制を備えた患者向けワークフローをElevenLabs Agentsに導入したい場合は、ぜひこのアプローチを試し、ご感想をお聞かせください。