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

電話は今でも医療への入り口ですが、混み合っています。Mayo Clinicの調査とEpicのケーススタディのデータは、予約の約30％が通常の診療時間外に行われていることを示しています。留守番電話につながった電話は、気づかれないまま実現しない予約です。一方、それを受け止めるべき受付スタッフは人手不足で、離職も早い状況にあります。 音声エージェントは、こうしたギャップを埋める手段として、すでにデモの段階を超えています。なかでも予約管理は最も一般的な導入ポイントです。大量かつ反復的で予測しやすく、臨床判断を必要としない受付業務の大きな割合を占めています。

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

このガイドでは、まさにそれをElevenAgentsで構築します。サンプル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件なら一致なし、複数件なら安全に進めるには検索パラメータの特定性が不十分です。 

アーキテクチャ

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

このアーキテクチャとツールにより、通話が成功するフローは次の手順で構成されます：

1. 通話開始：患者がエージェントに紐づくTwilio番号へ電話をかけると、エージェントが挨拶し、目的を把握します。
2. EHR検証：エージェントが患者情報をEHR内のレコードと照合します。
3. 本人確認：エージェントがSMSツールで患者の電話番号にワンタイムパスワード（OTP）を送信し、最終確認を行います。
4. 予約または変更：エージェントは取得した目的に基づきカレンダーを操作します。新規予約では予約情報を取得して空き状況を確認し、日程変更では既存予約を表示して新しい枠を探し、キャンセルでは既存予約を確認して削除します。
5. 転送：予約または変更に失敗した場合、患者が人との会話を希望した場合、またはエージェントが処理できない目的が検出された場合は、人の担当者に通話を転送します。
6. 確認と終了：予約、日程変更、またはキャンセルが成功した後、エージェントは通話内容を振り返り、温かく会話を終えます。

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

効果的なElevenAgentを構築する最初のステップは、システムプロンプトです。ElevenLabsのプロンプトガイドに従い、あらゆる本番エージェントで推奨される中核要素、つまりパーソナリティ、目的、トーン、ツール、ガードレールを、1つの長い指示ブロックではなく、明確にラベル付けした個別セクションとして構成します。

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

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

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

ガードレール

システムプロンプトのガードレールセクションでは、指示レベルのルールを扱い、モデルによって強く重視されます。しかし、プロンプトは依然として非決定的なレイヤーであり、長時間の通話では逸脱しがちです。ElevenAgentsは、独自のガードレールによる独立したランタイム強制機能でこれを補完します。これには、会話が長引いた際にシステムプロンプトを強化するFocus Guardrail、エージェントが応答する前にプロンプトインジェクションの試みを検出するManipulation Guardrails、各応答をリアルタイムで評価し、発信者が聞く前にブロックできるContentおよび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サービスを指定します。それぞれのURLパスにはVerify Service SID（Verifyサービス設定にあるVA... の値）が必要です。また、シークレットとして保存した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インテグレーションを追加し、［接続］をクリックします。

2. イベントタイプを固定します。各カレンダーツールには、イベントタイプIDが必要です。これは、Cal.comでどのイベントに予約するかを指定します。接続済みツールでは、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のままにしてください。

患者ジャーニーの構造化

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

Greetingはエントリーポイントです。通話に応答してクリニックを紹介し、引き継ぐ前に患者の目的を把握します。専用ツールは持たず、正しくルーティングするために必要なコンテキストだけを収集します。

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

Bookingには、前節のカレンダーツールを配置します。Greetingで取得した目的により経路が決まります。新規予約では空き状況を確認して予約し、日程変更では既存予約を検索して再予約した後にキャンセルし、キャンセルでは確認してキャンセルします。このノードはTransfer Noticeへのフェイルオープンも備えています。カレンダーに適した枠がない、発信者が既存予約と一致しない、または発信者がスタッフとの会話を希望する場合、通話を停止させずにエッジがそこへルーティングします。

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

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

Closeには予約が成功した場合にのみ到達します。予約の詳細を発信者に振り返り、温かく通話を終了します。

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

分析とテスト

医療音声エージェントにおける努力の大半は、理想的な経路にあるのではありません。通話が想定どおりに進まないときに、すべてが正しく処理されるようにすることです。ElevenAgentsは、プラットフォームにネイティブなテストと分析のために構築されています。そのため、ローンチ前のテストで使用する評価基準と同じものが、本番中のすべての通話を評価します。別途ツールを接続したり、結果を突き合わせたりする必要はありません。

成功基準

成功基準を定義し、ビジネスおよび運用目標に沿った具体的な評価基準を取得します。［分析］タブでは、各基準はLLMが文字起こしに対して実行する平易な言葉のプロンプトであり、根拠とともにsuccess、failure、またはunknownを返します。このエージェントでは、次のような基準を設定できます：

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

データ収集

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

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

医療では、エージェントは最初の実通話の前に信頼を得る必要があります。失敗モードは患者の前ではなくテスト中に明らかにするべきです。Conversation Simulation APIは、エンドツーエンドと対象セグメントの両方で、現実的な発信者シナリオをシミュレートします。また、本番で稼働しているものと同じ基準、すなわち上で定義したpatient_verifiedとappointment_bookedの正確なチェックを使って結果を自動評価します。テスト専用の別の評価基準ではありません。通話全体の完全シミュレーション、または会話の途中から開始して単一の判断ポイントを検証する部分シミュレーションを実行できます。後者は、フロー全体を再実行せずに1つのノードを反復改善する、より迅速な方法です。 

このエージェントでは、理想的な経路を超えたシナリオを作成します。氏名がどのEHRレコードにも一致しない発信者、OTPを2回入力し損ねる人、予約ではなく日程変更を希望する患者、本人確認の途中で明確に人との会話を求める発信者などです。これにより、本番で問題が発生することを期待するのではなく、エッジケース、ツール利用、フォールバックロジックをカバーする明確で焦点を絞ったシナリオを用意できます。

Twilio電話番号を接続する

エージェントを構築したら、ライブ番号への接続は数分で完了します：

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

実際の患者に対応する準備

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

本番稼働で、このパターンの真価が発揮されます。構築中に定義した評価基準が本番移行のしきい値となります。エージェントが一貫して基準を満たし、指標が安定すれば、勘に頼るのではなく自信を持ってローンチできます。ローンチ後は、学びの対象がシミュレーションテストから本番の文字起こしへと移ります。段階的なロールアウトから反復を止めるタイミングまで、こうした実践については以前のブログで紹介しています。

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

これで、エージェント型音声AIをクリニックの入り口に導入するためのテンプレートが完成しました。予約管理は最も件数が多く、始めやすい領域です。同じパターンは患者受付、処方薬の再処方、請求、診察後のフォローアップにも広げられます。いずれも、診療時間外に留守番電話へつながる必要がなくなる通話です。Forward Deployed Engineeringチームは、医療機関と緊密に連携し、このような導入を具体的なプロダクト機能へとつなげます。医療で求められるコンプライアンス体制を備えた患者向けワークフローをElevenAgentsに導入したい場合は、ぜひこのアプローチを試し、感想をお聞かせください。