AI電話応対の内製と外注｜GPT-Live-1で自作する判断軸

ボイスボットのSaaSを契約するか、APIで自作するか——電話の一次対応を自動化したい会社が最後に迷うのがこの分岐です。2026年9月10日、OpenAIが音声モデルGPT-Live 1をAPIで一般提供（GA）し、公式ドキュメントにテレフォニー（電話網）接続が明記されました。この記事では、内製に必要な構成・SaaSとの分かれ目・実際にハマる落とし穴を、実装を請け負う立場から整理します。

結論から言えば、内製が現実的になるのは「同時通話数が読めている・24時間動かす・既存の社内システムと繋ぎたい」の3つが揃うときだけです。GPT-Live 1の音声セッションは1分あたり0.05ドル・秒単位課金（バックエンドのモデル呼び出しとツール利用は別課金）で、Free ティアは利用できず、上限は「同時セッション数」で決まります（Tier 1で25、Tier 5で500）。逆に言えば、月に数十件の着信をさばくだけなら、内製の設計・保守コストのほうが確実に高くつきます。

何が変わったのか｜電話に耐える水準になった

音声AIで電話を受ける発想自体は新しくありません。変わったのは「電話という回線の乱暴さ」に耐えられるようになった点です。GPT-Live 1はfull-duplex（送話と受話を同時に扱う）で動き、OpenAIの発表では割り込み処理の誤りがSpeakの評価で従来比およそ80%削減されたとされています。

これは実務上、かなり大きい違いです。電話では相手が案内の途中で「あ、それじゃなくて」と話しかぶせてきます。従来の音声ボットはこの被りに弱く、read-outを最後まで喋り切るか、逆に環境音で誤って停止するかのどちらかに倒れがちでした。割り込みの精度が上がると、この「人間が普通にやること」で会話が壊れなくなります。

もう一点が、テレフォニーの経路が公式に用意されたことです。従来は電話網とAIの間を自前で橋渡しする必要がありましたが、現在は公式ガイドにSIPで直接つなぐ経路と、自社サーバーで音声を中継する経路の2つが示され、Twilio・Telnyx・LiveKit・Daily/Pipecatといった事業者向けの手順も整理されています。SIP直結ではTLS（ポート5061）でシグナリングし、音声はSRTP必須、コーデックは8kHzのG.711 μ-law／A-lawに対応しています。

モデル単体で何ができるのか・どのプランで触れるのかは、GPT-Live音声AIのできることと対応プランを整理した記事にまとめています。本記事は「電話応対という業務をどう作るか」に絞ります。

内製に必要な3層構成

AI電話応対をAPIで自作する場合、システムは必ず次の3層になります。どのSaaSを見ても内部は同じ構造なので、まずこの3つを紙に書けるかどうかが内製の可否判断そのものになります。

① 電話網｜番号をどう引き込むか

最初に決めるのは「既存の代表番号を転送でAIに向けるか、新しく発番するか」です。実務ではほぼ例外なく転送を推奨します。名刺・チラシ・Googleビジネスプロフィールに載っている番号を変えると、うまくいかなかったときに戻す手段がなくなるためです。転送であれば、転送設定を解除するだけで元の受電体制に戻せます。

接続方式は、OpenAIのSIPエンドポイントへトランクを向ける直結型と、自社サーバーがWebSocketで音声を中継するブリッジ型の2つです。直結型は構成が単純で遅延も少ない代わりに、着信の受理・拒否や転送をすべて自前のWebhookハンドラで書くことになります。

② v1/live/sessions｜エンドポイントは1本しかない

GPT-Live 1が使えるのはv1/live/sessionsだけです。Chat Completions、Responses、Realtime、Batch、ファインチューニングはいずれも非対応で、入出力も音声とテキストのみ（画像・動画は扱えません）。structured outputsも使えないため、「JSONスキーマで応答を固める」という設計は②の層では成立せず、③に押し出すことになります。

着信の流れは、live.transport.incomingのWebhookを受け取り、認証付きのPOSTでセッション設定とともに受理または拒否を返し、その後サイドバンドのWebSocketで文字起こし・委譲・コマンドをやり取りする、という順です。

③ 推論の委譲先｜「考える」のは別のモデル

GPT-Live 1は会話の口と耳であって、頭ではありません。用件の判断や社内システムの照会は、Responses delegation（GPT-Live側が設定済みのResponsesモデルを呼ぶ）か、client delegation（自社アプリがバックエンド実行を制御する）で別のモデルに委ねます。まず managed な Responses delegation から始め、細かい制御が要るところだけclient delegationに寄せるのが公式の推奨です。

ここで見落とされがちなのが、割り込みが起きても、バックエンドで走っている処理は自動では止まらない点です。相手が喋りかぶせて話題が変わったのに、裏では前の用件の在庫照会が走り続ける、という状態が普通に起こります。キャンセル処理を自分で書く必要があります。

この3層を組み上げ、既存の予約台帳や基幹システムまで繋ぎ込む部分は、実装として決して軽くありません。私たちはこうした社内システムと繋がる独自AIの構築も行っています。記事の途中で恐縮ですが、自作の見積もりを取る前の比較対象として、よろしければ覗いてみてください。

内製とSaaSの分かれ目｜3つの軸で決まる

「AIに詳しい人がいるかどうか」で決めると、たいてい間違えます。判断軸は次の3つで、いずれも自社の業務側から答えが出るものです。

同時通話数はTierの天井で決まる

GPT-Live 1のレート制限は、1分あたりのリクエスト数ではなく同時セッション数で規定されています。Tier 1が25、Tier 2が50、Tier 3が200、Tier 4が300、Tier 5が500で、Freeティアは利用できません。これは「同時に何本の電話を受けられるか」がそのままアカウントのTierに縛られるということです。

中小企業の一次対応であれば、ピークでも同時5本を超えることは稀なので、Tier 1でも実用上は足ります。逆に、キャンペーン告知の直後に着信が集中するような業態では、天井に当たった通話がどう扱われるか（話中にするのか、人へ回すのか）をあらかじめ決めておく必要があります。

営業時間と、実際にかかる金額の考え方

音声セッションは1分0.05ドルの秒課金で、加えてバックエンドのモデル呼び出しとツール利用が別に乗ります。つまり「通話が長引くほど、判断を挟むほど増える」構造です。着信件数と平均通話時間を掛けるだけでは足りず、③の層で走る推論の回数も見積もる必要があります。

SaaSの月額と比べる具体的な金額感は、中小企業向けにAI電話応対の実現方法3タイプと月額の考え方を整理した記事で扱っています。内製の判断はここでは「固定費か従量課金か」の性格の違いとして押さえておけば十分です。

既存システム連携があるかどうかが最大の分かれ目

実務で内製に振れる決定打は、ほぼこれです。既製のボイスボットは「聞き取って、記録して、必要なら転送する」までは非常によくできています。一方で、自社の予約台帳の空き状況をその場で見て埋める、基幹システムの受注番号を照会して回答する、といった読み書きが必要になった瞬間に、既製サービスの範囲を超えます。

そこまでの要件が無いなら、SaaSで十分です。既製サービスの具体的な比較や、通話録音・個人情報の扱いといった導入前の注意点は、ボイスボットの仕組みと主要サービスの選び方をまとめた記事にあります。

内製で必ずぶつかる4つの落とし穴

1. 知識カットオフは2025年7月31日｜社内情報は必ず外から渡す

GPT-Live 1の学習データは2025年7月31日までです。当然ながら、自社の営業時間・料金表・在庫・担当者名は一切知りません。ここを勘違いして「プロンプトに会社概要を書いておけば答えてくれる」と設計すると、価格改定や休業日の変更のたびにプロンプトを直す運用になり、必ずどこかで古い情報を口にします。

正しくは、社内情報は③の推論層からツール経由で毎回取りに行く形にします。営業時間ひとつでも、Googleカレンダーやスプレッドシートを参照して答えるようにしておけば、更新は情報の側だけで済みます。

2. Freeティアでは動かない・Tierで同時通話数が決まる

検証段階でつまずきやすいのがここです。GPT-Live 1はFreeティア非対応なので、無料枠で試すことはできません。また前述のとおり上限が同時セッション数なので、「1日の着信件数」で容量設計をすると本番でずれます。数えるべきはピーク時間帯に重なる本数です。

3. 既存のResponsesベース実装からは載せ替えになる

すでにResponses APIでチャットボットや社内AIを組んでいる場合、その実装をそのまま音声化することはできません。GPT-Live 1はv1/live/sessions専用で、Responses・Chat Completions・Realtimeのいずれからも呼べないためです。既存資産は③の委譲先として残し、②の音声セッション層を新規に作る、という切り分けになります。移行そのものの注意点はGPT-6 Astra APIへの移行で消すパラメータを整理した記事も参考になります。

4. 有人へ戻す線を、数字で決めていない

技術より事故になりやすいのがこれです。内製だと「もう少しプロンプトを直せば取れる」と粘れてしまうため、有人転送の条件が曖昧なまま本番に出がちです。聞き返しが2回続いたら転送、特定の語（解約・クレーム・故障・至急）が出たら即転送、といった条件を実装の前に文章で固定してください。SaaSであれば設定画面に用意されている項目が、内製では自分で書かない限り存在しません。

最初の一歩｜内製を決める前にやること

内製かSaaSかを決めるのに、技術検証から入る必要はありません。順序としては、①直近1か月の着信を「用件」で数える → ②ピーク時間帯に重なる同時本数を出す → ③自社システムへの読み書きが要件に入るかを確認する、の3つで答えは出ます。①と②が小さく③が無ければSaaS、③がありピークが読めるなら内製、という切り分けです。

この棚卸しは、内製する場合の要件定義にも、SaaSの見積もりを同じ前提で比較する資料にもそのまま使えます。判断がついたあと、実際に3層を組み上げるところまでを外部に任せたい場合は、お気軽にご相談ください。

出典・参考