代表電話の一次受けをAIの音声応対で行い、用件を記録して担当へ回す
代表電話にかかってきた電話をAIが一次で受け、相手と用件と緊急かどうかを聞き取って記録します。受付担当の作業は、全件を受けて取り次ぐことから、記録された用件を確認して担当へ回すことに変わります。
- 利用ツール
- Azure AI/ChatGPT/Claude/Gemini/Google Vertex AI/Python
- 対象業界
- 不動産/士業/建設/製造
- 対象部門
- カスタマーサポート/総務
- 対象業務
- 問い合わせ対応/記録・議事録作成
- 主な課題
- 人手が足りない/問い合わせが多い/属人化している
- AIで行う処理
- 対話
- 主な効果
- 対応スピード向上/工数削減/機会損失防止
- 導入難易度
- ★★★★☆
- 実装レベル
- 本格構成
- 費用感
- 個別開発(大)
- 人間の確認
- 必須
01導入前 / 導入後の業務フロー
- 代表番号に着信する
- 受付担当が出て、社名を名乗る
- 相手の名前と用件を聞く
- 入居者からの連絡なら、物件名と部屋番号を聞く
- 用件から担当部署・担当者を判断する
- 担当者の在席を確認し、在席なら転送する
- 不在なら伝言を聞き、メモを作る
- 担当者に伝言メモを渡す(チャットまたは紙)
- 担当者が折り返す
- 代表番号に着信する
- 自動AIが応答し、AIが対応していることと、通話を記録することを最初に伝える
- 自動相手の名前と用件を聞き取る
- 自動緊急の用件かを判定する
- 【緊急】 緊急と判定したら、その場で応対を打ち切り、人へ転送する
- 自動入居者からの連絡なら、物件名と部屋番号を聞く
- 自動用件の種別を判定する
- 自動担当者への取次希望なら、在席を確認して転送する
- 自動不在なら、用件を詳しく聞いて記録する
- 自動用件を構造化して記録し、担当者に通知する
- 人受付担当が記録を確認し、必要なら補足する
- 人担当者が折り返す
- 自動折り返しが行われていないものを、一定時間後に再通知する
各工程の詳しい説明を読む
- 代表番号に着信する
- 受付担当が出て、社名を名乗る
- 相手の名前と用件を聞く
- 入居者からの連絡なら、物件名と部屋番号を聞く
- 用件から担当部署・担当者を判断する
- 担当者の在席を確認し、在席なら転送する
- 不在なら伝言を聞き、メモを作る
- 担当者に伝言メモを渡す(チャットまたは紙)
- 担当者が折り返す
問題は5つあります。
(a)時間帯に集中する。 9〜10時と17〜18時に1日の4割が集中します。3名では受けきれず、待たせるか、取り逃がします。
(b)営業電話が1割ある。 月200件の売り込みに、受付担当が対応しています。「担当者に確認します」と言って断る手順が、1件あたり2分かかります。
(c)伝言メモの内容が足りない。 「◯◯様から電話。折り返し希望」とだけ書かれ、用件が書かれていないメモが多くあります。 担当者は折り返してから初めて用件を知り、その場で答えられず二度手間になります。
(d)折り返しが遅れる。 担当者が外出していると、折り返しが翌日になることがあります。設備トラブルの場合、入居者の不満が大きくなります。
(e)緊急の判断が受付担当に委ねられている。 「水が漏れている」と言われたときに、どの程度緊急かの判断が人によって違います。経験の浅い担当者が通常対応に回してしまうことがあります。
- 代表番号に着信する
- 【自動】 AIが応答し、AIが対応していることと、通話を記録することを最初に伝える
- 【自動】 相手の名前と用件を聞き取る
- 【自動】 緊急の用件かを判定する
- 【緊急】 緊急と判定したら、その場で応対を打ち切り、人へ転送する
- 【自動】 入居者からの連絡なら、物件名と部屋番号を聞く
- 【自動】 用件の種別を判定する
- 【自動】 担当者への取次希望なら、在席を確認して転送する
- 【自動】 不在なら、用件を詳しく聞いて記録する
- 【自動】 用件を構造化して記録し、担当者に通知する
- 【人】 受付担当が記録を確認し、必要なら補足する
- 【人】 担当者が折り返す
- 【自動】 折り返しが行われていないものを、一定時間後に再通知する
相手が「人と話したい」と言えば、いつでも転送します。 これはすべての段階で有効です。
自動化されるのは「受ける」「聞く」「探す」「記録する」「通知する」の5つです。残るのは「用件への回答」と「緊急の対応」です。
02今回想定するシステム構成
代表電話への着信 │ ▼ クラウドPBX(SIP / 電話基盤) │ ▼ Azure AI Speech の Voice Live API(WebSocket) │ ├─ 音声認識 + 応答の生成 + 音声合成 を一体で提供 │ ├─ ノイズ抑制 / エコーキャンセル │ └─ 割り込み検出 / 発話の終わりの検出 │ ├──▶ function calling │ ├─ 物件・部屋番号の照会(賃貸管理システム) │ ├─ 担当者の在席確認 │ └─ 人への転送 │ ▼【通話終了後】 Claude API ── 通話の書き起こしから用件を構造化 │ + 伝言メモの作成 ▼ 用件の記録(賃貸管理システム / 一覧)──【受付担当が確認】 │ ├──▶ 担当者へ通知(Teams / メール) └──▶ 折り返し未実施の再通知
| 役割 | 想定する製品 | 代替候補 |
|---|---|---|
| 処理 | Azure AI Speech(Voice Live API) | Google Vertex AI、各社の音声対話サービス |
| 生成AI | Claude API(通話後の構造化) | OpenAI API、Gemini API |
| 連携 | Python(PBXとの接続、基幹システムの照会) | 個別開発 |
| 電話基盤 | クラウドPBX | 各社のPBX |
| 基幹システム | 賃貸管理システム | 各社の業務システム |
電話の一次応対を請け負うサービス(電話代行、AI電話受付のSaaS)が多数あります。 まずそれを検討してください。自前で組む価値があるのは、自社の基幹システムを照会しながら応対したい場合です。 「物件名と部屋番号を聞いて、その場で契約状況を確認する」ような応対は、汎用の代行サービスでは実現しにくくなります。
Voice Live API を選んだのは、音声認識・生成AI・音声合成を1つのインターフェースで扱えるためです。 これらを別々に組み合わせると、実装が複雑になるうえ、利用者が感じる遅れが積み重なります。 Voice Live API は WebSocket で接続する設計で、サーバー間の連携がしやすくなっています。また、ノイズ抑制、エコーキャンセル、割り込みの検出、発話の終わりの検出といった会話の質に関わる機能が組み込まれています。
03どうやって実装するのか
処理の起点を決める
代表番号への着信が起点です。クラウドPBXから、AIの応対を担うシステムに音声を渡します。
すべての着信をAIに回さないでください。 次の振り分けを、AIに渡す前の段階で行います。
| 着信 | 扱い |
|---|---|
| 緊急専用ダイヤル(別番号) | AIを介さず人へ直通 |
| 発信者番号が協力業者の登録番号 | 業者窓口へ直接転送 |
| 発信者番号が過去に営業電話と判定された番号 | 自動応答で断る |
| 上記以外 | AIが一次受けする |
緊急専用の番号を別に用意し、入居者に周知することが前提です。 「水漏れ・ガス漏れ・鍵の紛失はこちらへ」という案内を、契約書と入居のしおりに載せます。AIの判定に頼らず、番号で分けるのがもっとも確実です。
入力データを集める
| データ | 中身 | 取得元 |
|---|---|---|
| 通話の音声 | 相手の発話 | クラウドPBX |
| 発信者番号 | 着信元の電話番号 | クラウドPBX |
| 物件マスタ | 物件名、住所、部屋番号、管理担当者 | 賃貸管理システム |
| 契約情報 | 入居者名、契約状況、連絡先 | 賃貸管理システム |
| 担当者の在席状況 | 在席/外出/会議中 | Microsoft 365(予定表・プレゼンス) |
| 用件の種別の定義 | 設備トラブル/契約手続き/退去/支払/苦情/その他 | 総務部(文書化が必要) |
| 緊急の定義 | 緊急として人へ回す用件の一覧 | 総務部(文書化が必要) |
| 営業電話の番号リスト | 過去に営業電話と判定された発信者番号 | 運用で蓄積 |
| 過去の対応履歴 | 同じ物件・同じ入居者からの過去の連絡 | 賃貸管理システム |
「緊急の定義」が、この構成でもっとも重要な入力です。
| 緊急として即座に人へ回すもの |
|---|
| 水漏れ、漏水 |
| ガスのにおい |
| 火災、煙、焦げたにおい |
| 停電、電気が使えない |
| 鍵の紛失、閉じ込め |
| エレベーターの停止(閉じ込めを含む) |
| 人の体調、けが |
| 騒音・迷惑行為で今まさに困っている |
| 相手が強い苦情を述べている |
この一覧は「取りこぼさない側」に倒して作ってください。 判断に迷うものは緊急に入れます。緊急でないものを人に回すコストより、緊急を取りこぼすリスクのほうがはるかに大きい業務です。
データの取得方法を決める
音声: クラウドPBXから音声ストリームを受け取り、Voice Live API にWebSocketで渡します。PBXとの接続方式は製品によって異なります。SIPトランクを直接扱うか、PBXが提供するAPIやWebhookを使うかで実装が変わります。この部分は利用環境に応じた個別確認が必要です。
基幹システムの照会: Voice Live API の function calling を使い、応対の途中で物件情報や担当者の在席を照会します。「〇〇マンションの301号室ですね。担当の田中におつなぎします」と言えるかどうかで、相手の印象が大きく変わります。
通話の書き起こし: 応対の記録として保存し、通話終了後の構造化に使います。
AIへ渡す前に整形する
- 発信者番号による振り分け … 上記の表のとおり、AIに渡す前に振り分けます
- 営業時間の判定 … 営業時間外は、緊急受付の案内に切り替えます
- 過去の連絡の参照 … 発信者番号から、直近の連絡履歴を用意します。「先日の件でしょうか」と言えると、聞き取りが早くなります
- 音声の品質の判定 … 極端に聞き取りにくい場合は、早い段階で人に回します
AIに処理させる
通話中(Voice Live API):
| 処理 | 内容 |
|---|---|
| 冒頭の案内 | AIが応対していること、通話を記録することを伝える |
| 相手の特定 | 名前、入居者/オーナー/業者/その他の別を聞く |
| 緊急の判定 | 緊急の定義に当たる用件かを判定する |
| 物件・部屋番号の聞き取り | 入居者の場合、物件名と部屋番号を聞き、マスタと照合する |
| 用件の聞き取り | 何が起きているか、いつからか、どうしてほしいかを聞く |
| 担当者の在席確認 | 取次希望の場合、在席を確認する |
| 転送 | 緊急、または相手の希望があれば人へ転送する |
通話後(Claude API):
| 処理 | 内容 |
|---|---|
| 用件の構造化 | 書き起こしから、相手・物件・用件・希望を項目に整理する |
| 伝言メモの作成 | 担当者が折り返す前に用件が分かる文を作る |
| 対応の緊急度の再評価 | 通話全体を読み直し、通話中の判定が妥当だったかを見る |
| 未確認事項の指摘 | 聞けなかった項目を挙げる |
通話中と通話後で役割を分けるのは、求められる速さが違うからです。 通話中は遅れが許されないため、専用の音声対話サービスに任せます。通話後の構造化は数秒かかってよいので、じっくり整理させます。
AIに用件の回答をさせないでください。 「その設備は〇〇が原因かもしれません」といった回答を一次受けでしてはいけません。誤った案内は、入居者の対応を誤らせます。 一次受けの役割は、聞き取りと振り分けに限ります。
指示内容を固定する
通話中の応対指示(Voice Live API に渡す指示):
あなたは、賃貸住宅の管理会社の電話受付です。
かかってきた電話に一次対応し、用件を聞き取ってください。
【最初に必ず言うこと】
「お電話ありがとうございます。〇〇管理です。
こちらはAIによる自動応対です。通話内容は記録させていただきます。
担当者と直接お話しになりたい場合は、いつでもお申し付けください。」
【厳守事項】
- 設備の不具合について、原因や対処法を説明しないでください。
「〇〇が原因かもしれません」「こうすれば直ります」と言わないでください。
聞き取りに徹してください。
- 費用の負担がどちらになるかを答えないでください。
「確認して担当からご連絡します」と伝えてください。
- 契約の内容について答えないでください。
照会できるのは、物件名と部屋番号の確認までです。
- 次のいずれかに当てはまると判断した時点で、
質問を続けず、ただちに担当者へ転送してください。
(水漏れ/ガスのにおい/火災・煙・焦げたにおい/停電/
鍵の紛失・閉じ込め/エレベーターの停止/体調・けが/
今まさに困っている迷惑行為/強い苦情)
判断に迷う場合も転送してください。
- 相手が「人と話したい」「担当者を出して」と言った場合は、
理由を聞かずにただちに転送してください。
- 同じことを3回聞いても聞き取れない場合は、
「担当者におつなぎします」と言って転送してください。
- 相手を待たせないでください。照会に時間がかかる場合は、
「少々お待ちください」と声をかけてから行ってください。
- 相手の年齢、話し方、感情について記録に残す発言をしないでください。
【聞き取る項目】
1. お名前
2. 入居者 / オーナー / 業者 / その他 の別
3. (入居者の場合)物件名と部屋番号
4. 用件
5. いつから起きているか(設備の不具合の場合)
6. 折り返しの希望(電話番号、都合の良い時間帯)
通話後の構造化:
あなたは、電話の応対記録を整理する担当者です。
通話の書き起こしから、担当者が折り返す前に用件が分かる記録を作ってください。
【厳守事項】
- 書き起こしに含まれないことを補わないでください。
聞けなかった項目は null にし、missing_items に入れてください。
- 設備の不具合について、原因を推測しないでください。
相手が言ったことをそのまま記録してください。
- 相手の感情や態度について記述しないでください。
「怒っていた」「不機嫌だった」と書かないでください。
ただし、苦情の内容そのものは正確に記録してください。
- 用件の種別は、下記の一覧からのみ選んでください。
該当しない場合は "other" とし、理由を書いてください。
- 通話中に緊急と判定されなかったが、
書き起こしを読むと緊急に当たると考えられる場合は、
escalation_review を true にして理由を書いてください。
- 伝言メモは、担当者が折り返す前に読んで、
何を準備すればよいかが分かる内容にしてください。
【用件の種別】
{inquiry_types}
【緊急の定義】
{emergency_definitions}
【通話の書き起こし】
{transcript}
【発信者番号から特定した情報】
{caller_info}
「原因や対処法を説明しないでください」の1行が、この構成の安全装置です。 音声対話のモデルは、聞かれれば答えようとします。「ブレーカーを上げてみてください」と案内して事故が起きれば、会社の責任になります。
「判断に迷う場合も転送してください」も外せません。 緊急の判定を厳密にしようとすると、取りこぼします。転送しすぎるくらいでちょうどよい設計にしてください。
出力形式を固定する
{
"call_id": "",
"received_at": "",
"caller_number": "",
"caller_name": "",
"caller_type": "resident | owner | contractor | other | unknown",
"property": {
"name": "",
"room_no": "",
"matched": false
},
"inquiry_type": "",
"content": "",
"occurred_since": "",
"callback": {
"requested": false,
"phone": "",
"preferred_time": ""
},
"handled_by": "ai_completed | transferred_emergency | transferred_by_request | transferred_unclear",
"emergency_detected": false,
"escalation_review": false,
"escalation_reason": "",
"assigned_to": "",
"message_for_staff": "",
"missing_items": [],
"call_duration_seconds": 0
}
handled_by の4区分が、運用の指標になります。
| 値 | 意味 | 見るべき点 |
|---|---|---|
ai_completed | AIが最後まで対応し、記録を残した | これが増えれば工数が減る |
transferred_emergency | 緊急と判定して転送した | 見落としがないかを全件確認する |
transferred_by_request | 相手の希望で転送した | 多いなら、AI応対が受け入れられていない |
transferred_unclear | 聞き取れずに転送した | 音声認識の品質の問題 |
escalation_review は、通話中の判定が甘かった可能性を示します。 ここが立ったものは、必ず人が通話を聞き直してください。 緊急の定義を見直す材料になります。
なお、Claude API には出力をJSONスキーマに沿わせる構造化出力の機能があります(2026-09-15時点ではベータ機能として提供)。件数が多く後段が機械処理なので、利用できると安全です。
システムへ連携する
| つなぐ先 | 内容 |
|---|---|
| クラウドPBX | 着信の受け取り、人への転送 |
| 賃貸管理システム(読み取り) | 物件・部屋番号・契約状況の照会 |
| Microsoft 365(読み取り) | 担当者の在席状況の確認 |
| 賃貸管理システム(書き込み) | 用件を対応履歴として登録する |
| Teams / メール | 担当者へ通知する |
| 一覧(スプレッドシート等) | 受付担当が全件を確認する画面 |
転送先の設計を慎重にしてください。 緊急の転送先が話し中だった場合に、どこへ回すかを決めておく必要があります。転送に失敗して切れるのが、この構成で最悪の事態です。 一次転送先・二次転送先・最終的な携帯電話、という多段の設定を用意してください。
人が確認する
AIが対応した全件を、受付担当が確認します。
見る優先順位は次のとおりです。
| 優先 | 対象 | 対応 |
|---|---|---|
| 1 | escalation_review: true | 通話を聞き直す。 緊急を取りこぼしていなかったか |
| 2 | transferred_emergency | 転送後の対応が完了したかを確認する |
| 3 | missing_items があるもの | 折り返して聞き直すか、担当者に申し送る |
| 4 | handled_by: transferred_unclear | 音声認識の問題か、相手の事情かを見る |
| 5 | property.matched: false | 物件が特定できていない。担当を決められない |
| 6 | その他 | 一覧で流し見て、担当への通知を確認する |
全件確認を省かないでください。 一次受けをAIに任せるということは、会社として最初に受けた印象をAIが作るということです。少なくとも導入から半年は、全件を人が確認する運用にしてください。
例外に対処する
| 起きること | 対応 |
|---|---|
| 緊急の用件 | 質問を続けず、ただちに転送する。 判断に迷う場合も転送する |
| 相手が人と話したいと言う | 理由を聞かずに転送する |
| 3回聞いても聞き取れない | 転送する。「もう一度お願いします」を繰り返さない |
| 相手が高齢で、機械音声に戸惑っている | 早い段階で転送する。戸惑いの兆候(沈黙、聞き返し)を転送の条件に入れる |
| 転送先が話し中・不在 | 二次転送先へ。それも不在なら、用件を聞いて記録する |
| 転送が失敗する | 必ず代替の転送先を用意する。 切れることを絶対に避ける |
| 営業電話 | 断る定型文で応対し、発信者番号を記録する。繰り返す番号は次回から自動応答に回す |
| 無言電話・いたずら | 一定時間発話がなければ終話する。番号を記録する |
| 物件が特定できない | 用件を記録し、受付担当に回す。推測で物件を決めない |
| 通話中にシステムが落ちた | 人へ自動転送する。 切れる設計にしない |
| 営業時間外の着信 | 緊急受付の案内に切り替える |
| 通話の記録に同意が得られない | 人へ転送する。 記録なしでAI応対を続けない |
| 苦情が強い | 緊急として転送する。AIで受け続けない |
記録を残す
- 通話の録音(同意を得たうえで)
- 書き起こし
- 構造化した用件の記録
handled_byの区分と、転送の記録- 受付担当が記録を修正した内容と、修正前後
- 担当者の折り返しの記録
escalation_reviewとして挙がった通話と、聞き直した結果
通話の録音と書き起こしには、個人情報が含まれます。 保管期限を決め、それを過ぎたら削除してください。「念のため全部残す」としないでください。
escalation_review の蓄積が、緊急の定義を育てます。 「この言い方は緊急として拾えていなかった」が見つかれば、定義に追加します。
04実装レベルの3段階
半自動化の段階に価値があります。 発信者番号による振り分けと営業電話の自動応答だけでも、月200件の営業電話が受付担当の手から離れます。音声応対に進む前に、この段階で1〜2か月運用してください。
05工数削減シミュレーション
導入後 2,400件 × 0.7分 ÷ 60 = 28 時間/月
自社条件で導入効果を整理したい方へ
このユースケースを自社に当てはめた場合の前提値と削減見込みを、業務ヒアリングをもとに整理します。
06向いている企業・向いていない企業
- 代表電話への着信が月1,000件以上あり、受付の専任者を置いている企業。用件の種別が定型化できること。緊急の用件と通常の用件が明確に区別できること。電話基盤がクラウドPBXなど、外部システムと接続できる構成であること。
- 着信が月200件未満の場合。相手の多くが高齢者で、機械音声での応対が negative に受け取られる可能性が高い場合。用件の大半が複雑な相談で、一次受けでの切り分けが難しい場合。緊急連絡の割合が高く、常時人が出るべき場合。
07最小構成で試す方法
この構成には「最小構成」がありません。 電話の一次受けは、電話基盤との接続なしには試せないためです。★4なのはこのためです。
ただし、導入の可否を判断するための準備は、AIなしでできます。
- 直近1か月の着信記録を、用件の種別ごとに数える
- 緊急に当たる用件が何件あったかを数える
- 取次だけで終わった電話が何件あったかを数える
- 営業電話が何件あったかを数える
- 伝言メモを50件読み、用件が書かれていないものが何件あるかを数える
この5つの数字で、導入の効果がおおよそ見えます。
| 数字 | 意味 |
|---|---|
| 取次だけの電話の割合 | AIで完結できる割合の上限 |
| 営業電話の割合 | 発信者番号での自動対応で減らせる分 |
| 緊急の割合 | 高いなら、この構成は向きません。 人が常時出るべきです |
| 用件の書かれていない伝言メモの割合 | 記録の質が上がる余地 |
次に、音声応対そのものを試します。
- 過去の通話録音から、典型的な10件を選ぶ
- 書き起こしを生成AIに渡し、用件の構造化と緊急判定を行わせる
- 受付担当の判断と比べる
7の段階で、緊急の判定を取りこぼしていないかを必ず確かめてください。 ここが通らなければ、音声化に進む意味がありません。
音声応対の試行は、社内の内線番号など、影響のない番号で行ってください。 実際の代表番号でいきなり試さないでください。
08実装時につまずきやすいポイント
| 問題 | 対策 |
|---|---|
| 緊急の用件を通常対応に回す | 緊急の定義を「取りこぼさない側」に倒す。迷ったら転送する。escalation_review で事後に必ず検証する。最重要 |
| AIが設備の不具合の原因を説明する | プロンプトで明確に禁止する。応対の書き起こしを機械的に検査する |
| 転送が失敗して通話が切れる | 一次・二次・携帯の多段の転送先を用意する。切れる設計にしない |
| 相手が人を希望しても聞き返す | 理由を聞かずに即転送させる |
| 高齢の相手が戸惑ったまま続く | 沈黙・聞き返しの回数を転送の条件に入れる |
| 応答が遅れて会話が成立しない | 音声認識・生成・合成を一体で扱うサービスを使う。個別に組み合わせない |
| 物件を推測で特定する | マスタに一致しなければ matched: false として人に回す |
| 営業電話に毎回対応する | 発信者番号を記録し、繰り返す番号を自動応答に回す |
| 通話の録音に同意を得ていない | 冒頭で必ず伝える。同意が得られなければ人へ転送する |
| 録音・書き起こしを無期限に保管する | 保管期限を決める |
| 全件確認をやめてしまう | 少なくとも導入から半年は全件確認する。緊急の見落としに気づけなくなる |
| 営業時間外の着信に通常応対する | 時間帯で分岐し、緊急受付の案内に切り替える |
09セキュリティ・AIガバナンス上の注意点
この構成で扱うデータ: 通話の音声、発信者番号、氏名、住所(物件名と部屋番号)、契約状況、相談・苦情の内容。個人情報であり、住居に関する情報を含みます。
- 通話の録音の同意 … 通話を記録することを、応対の冒頭で必ず伝えてください。「同意しない」と言われた場合は、人へ転送します。 記録なしでAI応対を続けないでください
- AIであることの明示 … 人間が応対していると誤解させないでください。冒頭で「AIによる自動応対」と伝えます。 これは倫理の問題であると同時に、後の苦情を防ぐ実務でもあります
- 音声データの取り扱い … 音声は個人を識別しうる情報です。外部の音声サービスに送ることの可否を、自社の個人情報の取扱規程とプライバシーポリシーで確認してください。 プライバシーポリシーに記載した利用目的の範囲に収まるかを、法務に確認します
- 住居に関する情報 … 「どの物件の何号室に誰が住んでいるか」は、特に慎重に扱うべき情報です。照会の結果を音声で復唱する際の扱い(第三者が聞いている可能性)にも配慮してください
- 相手の属性を記録しない … 年齢、話し方、感情、態度を記録に残さないでください。「高齢のため理解が遅い」といった記述は、差別的な取り扱いにつながります
- 学習利用 … 入力を学習に使わないことが契約で保証されるサービスを選びます。通話音声が学習に使われる構成は避けてください
- アクセス権限 … 通話の録音と書き起こしの閲覧を、受付担当と当該物件の管理担当者に限定します
- 保管期限 … 録音と書き起こしの保管期限を決め、それを過ぎたら削除します
- 自動実行してよい範囲 … 聞き取り・照会・転送・記録までです。用件への回答、費用負担の判断、契約内容の説明は、必ず人が行います
誤りが起きた場合のリスクは、緊急の用件の見落としです。 水漏れやガス漏れの連絡を通常対応に回せば、物損や人身の事故につながります。この一点のために、緊急の判定は取りこぼさない側に倒し、escalation_review を全件確認してください。
10まず何から始めるか
1週目:着信の内訳を数える
直近1か月の着信を、用件の種別ごとに数えます。特に「緊急に当たる用件の割合」と「取次だけで終わった電話の割合」を出してください。
- 緊急の割合が高い(1割を超える)なら、この構成は向きません。 人が常時出る体制を維持すべきです
- 取次だけの電話が多い(4割以上)なら、効果が見込めます
2週目:緊急の定義を文書にする
「何を緊急として扱うか」を、総務・管理部門・法務で決めます。迷ったら緊急に入れる方針で作ってください。 この文書が、この構成の中核です。
3週目:発信者番号による振り分けを入れる
AIを使わず、PBXの設定だけでできることを先に行います。
- 緊急専用ダイヤルを別番号で用意し、入居者に周知する
- 協力業者の番号を業者窓口へ直接転送する
- 営業電話の番号を自動応答に回す
これだけで月200〜400件が受付担当の手から離れます。 1〜2か月運用して効果を確認してください。
2か月目:過去の通話で構造化と緊急判定を検証する
通話録音から典型的な30件を選び、書き起こしを生成AIに渡して用件の構造化と緊急判定をさせます。受付担当の判断と比べ、緊急の取りこぼしがゼロであることを確認します。 ここが通らなければ、音声化に進みません。
3〜4か月目:内線番号で音声応対を試す
社内の内線番号で音声応対を構成し、社員に電話をかけてもらいます。応答の遅れ、聞き取りの精度、転送の確実性を確かめます。 実際の代表番号では試さないでください。
5か月目以降: 時間帯を限定して(まず昼休みと17時以降など、受付担当が手薄になる時間帯)、実運用を始めます。全件を人が確認する運用を、少なくとも半年は続けてください。
11関連ユースケース
12この仕組みを理解するための記事
13技術仕様の確認日・参考情報
| 確認した内容 | 情報源 | 確認日 |
|---|---|---|
| Azure AI Speech の Voice Live API が、音声認識・生成AI・音声合成を1つのインターフェースで提供し、低遅延の音声対話を実現する仕組みであること。WebSocket で接続しサーバー間連携ができること。ノイズ抑制、エコーキャンセル、割り込みの検出、発話の終わりの検出を備えること。function calling により外部の処理を呼び出せること。音声認識は140以上のロケール、音声合成は150以上のロケールで600以上の標準音声に対応すること。料金は利用する生成AIモデルに応じた区分で、入力音声・出力音声・テキストのトークンに対して発生すること | Microsoft Learn: Voice Live API overview | 2026-09-15 |
| リアルタイムの音声認識が、ストリーミング音声に対して途中結果を含む即時の書き起こしを返すこと。Speech SDK、Speech CLI、REST API から利用できること | Microsoft Learn: Speech to text overview | 2026-09-15 |
| Claude API に、出力をJSONスキーマに沿わせる構造化出力の機能があること(2026-09-15時点ではベータ機能) | Claude Platform Docs: Structured outputs | 2026-09-15 |
電話基盤(PBX)と音声対話サービスの接続方式は、利用しているPBXの製品によって大きく異なります。この部分は利用環境に応じた個別確認が必要です。 通話の録音と音声データを外部サービスに送ることの可否、およびプライバシーポリシーへの記載の要否は、法務部門に確認してください。緊急の用件の判定基準と対応体制は、賃貸借契約上の管理会社の義務に照らして定めてください。
実装ステータス:構成例。 公開仕様に基づいて設計した構成であり、当社で実際に構築・検証したものではありません。工数の数値はモデル条件による試算です。AIが一次受けを完結できる割合は相手の受け入れ方に依存するため、自社での実測が必要です。
自社の業務に使えるAI活用候補を整理します
このユースケース(UC-0097)についてのご相談はこちらから。
