電話に出るAIをMVPで作るなら — Twilio × OpenAI Realtimeの一次受付 設計案
この記事について
電話の一次受付をAIに任せるサービスを、MVP（最小限の試作）として作るならどう設計するか——その設計案をまとめる。
はじめに断っておく。これは構想段階の設計であって、稼働実績ではない。 「作った記録」ではなく「作るとしたらこう組む」という設計の記録だ。前提にした技術は、Twilio（電話回線）とOpenAI Realtime API（音声対話モデル）の2026年7月時点の公開仕様（確認日: 2026-07-11）。料金・仕様は変わりやすいので、実装前に各社の公式ページで必ず確認してほしい。数値は裏取りできる範囲でのみ書き、試算の値は「概算・仮定」と明記する。
対象読者は、電話問い合わせが多くて取りこぼしているスモールビジネスや、音声AIの一次受付を検討している個人開発者。
何を解決するのか — 「一次受付」だけを切り出す
いきなり「電話業務を全部AIに」と考えると、要件が膨らんで作れなくなる。MVPで狙うのは一次受付の一点だけだ。
- 営業時間・場所・定休日といった定型質問に答える
- 用件を聞いて要約テキストを担当者にメール/チャットで渡す（折り返し前提）
- AIで完結しない用件は「担当から折り返します」で丁寧に取り次ぎに落とす
逆に、この時点でやらないことをはっきり決めておく。予約の確定、決済、クレーム対応、本人確認が要る手続き——ここはAI単独でやらせない。責任の所在が曖昧なままAIに判断させると事故る領域だ。「取りこぼしをゼロにする」のではなく、「一次接触だけは必ず拾う」がMVPのゴールになる。
全体構成 — 電話とモデルを”中継”でつなぐ
構成はシンプルだ。電話網とAIモデルの間に、音声を橋渡しする中継サーバを一枚置く。
発信者 → [電話番号] Twilio → (音声ストリーム) → 中継サーバ → OpenAI Realtime API
↑__________________|
(AIの応答音声を折り返す)
通話後: 要約テキスト → メール/チャットで担当者へ
- Twilio: 着信用の電話番号を持ち、通話の音声をリアルタイムのストリームとして中継サーバに流す（Media Streams）。逆にAIが生成した音声を通話に戻す
- 中継サーバ: TwilioとRealtime APIの間で音声データを双方向に受け渡すだけの薄い層。ここに凝った処理は載せない
- OpenAI Realtime API: 音声を直接受け取り、音声で返す対話モデル。文字起こし→テキスト応答→音声合成を1つのAPIで完結させる
技術選定の理由 — なぜ Realtime API か
音声対話は、昔ながらのSTT（文字起こし）→ LLM → TTS（音声合成）の3段パイプラインでも組める。それでもRealtime APIを一次候補に置く理由は遅延だ。
| 論点 | STT→LLM→TTS の3段構成 | Realtime API（音声直結） |
|---|---|---|
| 応答の遅延 | 3サービスを直列で通るぶん積み上がる | 1つのAPIで完結し割り込み・相槌に強い |
| 構成の複雑さ | 3つの結合点＝障害点が3つ | 結合点が減る |
| 会話の自然さ | 発話終了を待って処理しがち | 話の途中でも反応を返せる |
| コスト構造 | サービスごとに課金が分かれる | 音声トークンとして一本化（ただし割高） |
電話は間（ま）が命だ。数秒黙られると相手は「切れた？」と不安になる。遅延の少なさを最優先するなら音声直結が向く。ただしRealtimeは音声トークン課金が割高になりやすいので、コストは3段構成より慎重に見積もる必要がある（次節）。
Twilioを選ぶのは、電話番号の取得から通話音声のストリーミングまでを一通り公式APIで賄えて、MVPの立ち上げが速いからだ。ここは「枯れていて情報が多い」ことを優先する。
コスト試算 — 「型」を示す（数値は仮定）
料金は変動が激しいので、ここでは実額ではなく試算の型を示す。以下の単価は「計算方法を説明するための仮の値」であって、市場価格の断定ではない。必ず公式の料金ページで最新値に置き換えて計算すること。
1通話あたりのコストは、おおむね次の足し算になる。
1通話コスト ≒ 電話番号の月額 ÷ 月間通話数
+ 着信分課金 × 通話分数
+ Realtime音声入力（発信者の声）トークン × 単価
+ Realtime音声出力（AIの声）トークン × 単価
+ 中継サーバ稼働費（WebSocket接続・ホスティング費など）
たとえば「1通話3分・月200通話」と仮定して型に当てはめると、固定費（電話番号）は通話数で薄まり、変動費（通話分＋音声トークン）が主役になることが見えてくる。ここで効いてくる設計判断は2つ。
また、TwilioとOpenAIの間をWebSocketで常時接続して仲介する中継サーバー（Cloud RunやVPSなど）のホスティング起動時間やネットワーク転送料も、稼働モデルや月間通話数に応じて追加される点に注意が必要だ。
- 通話を短く終わらせるほど、分課金も音声トークンも減る。だらだら雑談させない設計がそのままコスト削減になる
- 定型回答はモデルに毎回考えさせない。営業時間のような固定文言は、モデルの生成に頼らず用意した文を返せば、そのぶんトークンを使わない
つまりコスト最適化と「一次受付だけに絞る」というスコープ設計は、同じ方向を向いている。用件を広げないことが、そのまま安さになる。
これで解決できること / できないこと
解決できること:
- 営業時間外・混雑時の取りこぼしをなくす（誰かが必ず「出る」）
- 定型質問を24時間さばく
- 用件の要約が担当者に届くので、折り返しの初動が速くなる
解決できないこと（AI単独でやらせない領域）:
- 契約・決済・予約確定など、間違うと実害が出る確定操作
- 本人確認・個人情報の照合が必要な手続き
- 感情的なクレームの一次対応（下手に返すと火に油）
MVPの合格ラインは「全部を自動化できたか」ではなく、「取り次ぐべきものを、失礼なく人へ渡せたか」に置く。AIが立派に喋ることより、境界の外側をきちんと人へエスカレーションできることのほうが、一次受付では価値が高い。
どこから始めるか
最初の一歩は、電話番号1本と、営業時間だけを答える最小の応答を通しで動かすことだ。そこに用件要約のメール送信を足し、最後に「AIで完結しない用件を折り返しに落とす」分岐を入れる。この3ステップなら、スコープを一次受付に固定したまま段階的に積める。
設計してみて見えた勘所は一つ。電話AIの難所は「うまく喋らせること」ではなく「どこで人に渡すかを決めること」だ。 喋りの質はモデルが年々上げてくれる。だが「AIに任せていい範囲」の線引きは、モデルではなくサービス側が引くしかない。MVPで最初に決めるべきはその一本の線だ、という設計案だった。
更新履歴
- 2026-07-11: 初稿（構想段階の設計案）