株式会社リブテック
お問い合わせ

Geminiリアルタイム音声×Asterisk×IP電話で作る「AI電話受付」アーキテクチャ

一覧へ戻る
社外CTO・IT/AI戦略顧問 #AI活用更新 2026-10-26
Geminiリアルタイム音声×Asterisk×IP電話で作る「AI電話受付」アーキテクチャ

前回は、中小企業の人手不足と電話番の課題を解決するために構築した「AI電話受付」の概要と、実際の音声サンプルをご紹介しました。

「電話番が採れない…」中小企業社長の悲鳴をGeminiの音声AIで解決した話
社外CTO・IT/AI戦略顧問

「電話番が採れない…」中小企業社長の悲鳴をGeminiの音声AIで解決した話

社長自身が受話器を取る現場のリアル 先日、ある住宅設備販売会社の社長と会食をしていた際、現場の切実な悩みを打ち明けられました。 「最近、若い社員が本当に採用できなくてね……」 社長は苦笑い混じりにそう語りました。かつての中小企業であれば、新入社員や若手スタッフの登竜門として任せていた「電話番」。しかし採用難が続く現在、電話を受けるためだけの人員を雇う余裕はありません。結果として、現場で実務を抱える…

第2回となる今回は、どのようなアーキテクチャでIP電話とリアルタイム音声AIを接続したのか、その技術的な裏側を解説します。このプロトタイプは、手元のPC環境とオープンソース技術を活用し、わずか1〜2日程度で構築したものです。

1. システム全体構成（アーキテクチャ）

IP電話の音声をAIに流し込み、AIの音声を電話回線へ返すためには、電話通信プロトコル（SIP/RTP）と、AIの双方向リアルタイム通信（WebSocket）を相互接続する必要があります。

全体フロー

[発信者 (スマホ/固定電話)]
       │
       ▼ (電話回線)
[050 IP電話サービス (SIP Server)]
       │
       ▼ (SIP/RTP)
[中継サーバー: Asterisk (Docker)]
       │
       ▼ (Audio Stream / RTP)
[SIP/RTP クライアントプログラム (Node.js / Python)]
       │
       ▲▼ (双方向 WebSocket: PCM音声送受信)
[Gemini Live API (音声リアルタイム対話モデル)]

なぜ Asterisk を中継に挟むのか？

050事業者のSIPサーバーへ独自のプログラムから直接REGISTER（登録）し、RTPパケットのやり取りやセッション制御（SDP交渉、コーデック変換など）をゼロから書くのは非常に難度が高く、数日で実装するのは困難です。

そこで、長年オープンソースとして実績のあるPBX（構内交換機）ソフトウェア Asterisk をローカル中継として挟みます。 Asteriskを使えば、DockerコンテナとしてWindowsでもMacでも数分で起動でき、電話事業者とのSIPトランク接続や音声のコーデック処理をすべて肩代わりしてくれます。自作プログラム側は、Asteriskから転送されてくる音声ストリームをハンドリングするだけで済むため、開発期間を1〜2日に短縮できます。

2. Gemini Live に渡しているシステムプロンプト

AIが「受付担当」として振る舞い、重要顧客の判定と要件ヒアリングを自然に行うためのプロンプトです。GeminiのLive API（双方向WebSocketセッション）のセットアップ時に systemInstruction として注入しています。

const SYSTEM_INSTRUCTION = `
あなたは企業の電話受付AIです。以下のフローに厳格に従って親切かつ丁寧に対応してください。

【会話フロー】
1. 電話が繋がったら最初の一言として「お電話ありがとうございます。私は受付AIです。お名前とご会社名を伺えますか？」と名乗ってください。
2. 相手が「会社名」と「お名前」を言ったら、提供された顧客データベースと照合する判定を行います。
- 相手が発言した会社名・お名前を理解してください。
3. もし顧客リストに該当する人物であれば：
- 「ありがとうございます。[会社名]の[お名前]様ですね。担当者にお繋ぎいたしますので、少々お待ちください。」と伝えて会話を終了処理に導いてください。
4. もし顧客リストに該当しない、または聞き取れなかった場合：
- 「担当者より折り返しご連絡いたしますので、要件をお聞かせいただけますでしょうか？」と伝えてください。
- 相手が要件を話し終えたら「承知いたしました。お電話ありがとうございました。」と言って電話を終えてください。

【顧客データベース】
${CUSTOMER_DATABASE.map((customer) => `- ${customer.company} / ${customer.name}`).join('\n')}

【注意点】
- 丁寧な日本語（敬語）で対応してください。
- 簡潔かつ自然な発話スピードで答えてください。
`;

顧客リスト（データベース）を動的にテキスト展開してプロンプトに埋め込むことで、データベース外部通信のオーバーヘッドを挟まず、極めて低遅延な判定を実現しています。

3. 実際の動作ログ（ケース別）

実際にプログラムが着信を検知し、Gemini Live APIとRTPパケットを往復させた際の実行ログです。

ケース1：顧客リストに該当（担当者へ取り次ぎ）

[Gemini Live API] WebSocket セッション確立 (model: models/gemini-3.8-live)
[RTP] 最初のパケットを受信: 127.0.0.1:53928 (172 バイト)
[RTP] 音声の返信先を設定: 127.0.0.1:53928
[Gemini Live API] セットアップ完了。最初の挨拶を開始します。
[Gemini Live API] 割り込みを検知。AI 音声の送信待ちをクリアしました。
[AI] お電話ありがとうございます。私は受付AIです。お名前とご会社名を伺えますか?
[RTP] AI 音声: 送信=223 フレーム (4460ms)
[発信者] この通話の録音を開始しました。
[AI] 承知いたしました。お電話ありがとうございます。私は受付AIです。お名前とご会社名を伺えますか？
[RTP] AI 音声: 送信=351 フレーム (7020ms)
[発信者] 東京銀行の迫花子と申します。社長はいらっしゃいますでしょうか?
[判定] 顧客リストに該当。担当者へ取り次ぎを開始します...
[通話終了] チャネルID: 1792743381.17

ケース2：顧客リストに該当しない（折り返し要件の受付）

[Gemini Live API] WebSocket セッション確立 (model: models/gemini-3.8-live)
[RTP] 最初のパケットを受信: 127.0.0.1:53886 (172 バイト)
[RTP] 音声の返信先を設定: 127.0.0.1:53886
[Gemini Live API] セットアップ完了。最初の挨拶を開始します。
[Gemini Live API] 割り込みを検知。AI 音声の送信待ちをクリアしました。
[AI] お電話ありがとうございます。私は受付AIです。お名前とご会社名を伺えますか？
[RTP] AI 音声: 送信=247 フレーム (4940ms)
[発信者] この通話の録音を開始しました。
[AI] かしこまりました。恐れ入りますが、お名前とご会社名を改めて伺えますでしょうか？
[RTP] AI 音声: 送信=288 フレーム (5760ms)
[発信者] あの、俺俺詐欺の詐欺と申しますが、あの、社長いますか?
[AI] 担当者より折り返しご連絡いたしますので、要件をお聞かせいただけますでしょうか？
[RTP] AI 音声: 送信=256 フレーム (5120ms)
[発信者] あの車検の返済について話し合いたいので、折り返しください。
[判定] 折り返し要件の受付が完了しました。保存します。
[要件保存完了] callback_2026-10-23T08-20-54.770Z_09087139148.txt に文字起こしを保存しました。
[AI] 承知いたしました。お電話ありがとうございました。
[RTP] AI 音声: 送信=158 フレーム (3160ms)
[通話終了] チャネルID: 1792743608.19

注目すべきは、発信者が話し始めた際の**「割り込み検知（Barge-in）」**が正常に機能している点です。AIが一方的に喋り続けることなく、人間の相槌や発言を検知して即座に発話を中断し、聞き役に回るため、極めて自然な電話対話が成立しています。

4. 他のリアルタイム音声サービスとの比較

今回はGoogleのGemini Live（双方向リアルタイムAPI）を採用しましたが、昨今は各社からリアルタイム音声基盤が登場しています。選定にあたっての所感をまとめました。

サービス特徴所感・電話受付での適合度
Google Gemini Live・音声入出力の一体型エンドツーエンド処理
・日本語の聞き取り精度とトーンの自然さが極めて優秀
・割り込み検知が高速		今回採用。日本語のビジネス敬語や会社名・人名の聞き取り精度が高く、電話受付に最適。
OpenAI Realtime API・GPT-4oベースの双方向音声WebSocket API
・ファンクションコーリング連携が強力
・多言語対応に強い		非常に強力な対抗馬。外部CRM検索などのツール呼び出し（Function calling）を多用する場合は有力な選択肢。
Twilio + 外部STT/TTS構成・電話回線とクラウドAPIが一体化
・Whisper（文字起こし）＋LLM＋ElevenLabs（音声合成）のパイプライン		ターンアラウンドタイム（遅延）が1〜2秒以上生じやすく、電話対話では「間」が気になりやすい。リアルタイム音声APIの方が体感が圧倒的に良い。

電話受付というユースケースでは、**「発話の割り込み（Barge-in）に耐えられるか」と「相槌やレスポンスの遅延が1秒未満に収まるか」**が成否を分けます。そのため、STT→LLM→TTSと直列に繋ぐ従来の構成よりも、Gemini LiveやOpenAI Realtime APIのようなエンドツーエンド（Speech-to-Speech）の音声APIを採用することが決定打となります。

5. まとめと本番化へのステップ

手元のPC、Docker、Asterisk、そしてGemini Live APIを組み合わせることで、「自社のルールに沿って賢く取り次ぐAI電話受付」は1〜2日のハッカソン感覚で実際に動くところまで持っていけます。

ここから商用環境へ持っていくためのステップとしては、以下が挙げられます。

  1. クラウド化：AWS ECSやGCP Cloud Run上にAsteriskと中継プログラムを移行し、24時間常時稼働させる。
  2. PBX連携：取り次ぎ判定が出た際、AsteriskのDialコマンドで社内内線や社長の携帯電話へブラインド転送する。
  3. 通知の自動化：保存された要件ログをSlackやLINE WORKS、メールへ即座にWebhook通知する。

大掛かりなコールセンターシステムを契約しなくても、最新の生成AI技術を使えば、現場の課題にジャストフィットした仕組みを素早く自前で作ることができます。電話対応に頭を抱えている方は、ぜひ一度プロトタイプ開発を試してみてはいかがでしょうか。