月3,000円の格安電話代行を使っていましたが、かかってくる電話はほぼ営業電話。重要な連絡は月に1本あるかどうかで、「この使い方だともったいないな」と思っていました。
そこで、会社の固定電話をAIで受け付け、用件をChatworkへ通知する仕組みを作りました。基本的にすべてCodexのAstraに作ってもらい、自分ではコードを一行も書いていません。
実際に使ってみると、これが最高に使い勝手がいい！ 平日10時〜18時だった受付が24時間対応になり、届いた用件もChatworkでそのまま社内共有できます。
今回は、使った仕組みや費用とあわせて、電話番号の聞き間違いや通知の抜けなど、テストで見つかった問題と改善したことを紹介します。
コードを一行も書かずに、ここまで作れるとは。実際に使ってみても、かなり便利です！
月3,000円でも、重要な電話がほとんどなければもったいない
うちの着信は、営業電話も含めて月10件ほどです。月3,000円の電話代行は格安でも、実際に対応が必要な連絡はごくわずかでした。
月額だけ見れば安くても、実際の利用状況に合っているかは別です。とはいえ、たまに来る重要な電話を取り逃したくはありません。そこで、電話の一次受付をAIに任せることにしました。
平日10時〜18時から24時間受付へ。Chatworkで共有できるのも便利
使っていた電話代行の対応時間は平日の10時〜18時でした。今回の仕組みでは、AIによる受付を24時間動かせるようになりました。
もう一つ便利なのが、受付内容がChatworkに届くので、そのまま社内で共有できることです。電話で聞いた内容を担当者へ渡すところまでつながっているので、使い勝手がとてもよく感じています。
※24時間対応するのは、AIによる用件の受付です。
作ったのは「AIが受けて、用件をChatworkに渡す」仕組み
大まかな流れは、固定電話への着信をAIが受け付け、相手の用件を確認し、受付内容をChatworkへ通知する形です。受付記録はGoogleスプレッドシートにも残すようにしました。
通知には、相手の名前や用件、連絡先、折り返し希望の有無などを載せています。担当者が通知を読んで、その後の対応を判断するための情報です。
ひかり電話のホームゲートウェイとUbuntuを使った
手元にあったひかり電話のホームゲートウェイ（NTTからの貸与品）に、IP電話の子機を接続する機能がありました。今回はその機能を使えるようUbuntu側を設定し、電話受付の仕組みにつなげています。
新しい電話受付用の機器を買い足す必要はありませんでした。手元の環境を利用して始められた点も、今回の導入では助かりました。
機器の追加購入費は0円。約40回のテスト通話でAPI代は約1ドル
今回、新しく機器を買うためにかかった費用は0円です。もともと使っていたホームゲートウェイと、手元のUbuntu環境を利用しました。
AIの会話処理にはOpenAIのRealtime APIを使っているので、API利用料はかかります。私がテストで40回ほど電話をかけた時点では、利用料は約1ドルでした。
営業電話も含めて月10件ほどの着信なので、運用費は少なく済みそうです。実際の月額は、今後の請求で確認していきます。
※API代は今回のテストでの概算で、通話の長さや利用条件によって変わります。既存の電話回線料金やサーバーの電気代は含みません。
コードは一行も書かず、CodexのAstraに作ってもらった
コードの作成や修正はCodexのAstraに任せました。「電話を受けて、用件をChatworkに通知してほしい」と要望を伝え、出来上がったら自分で電話をかけて試す形で進めました。
試して気になった点も、コードを直す代わりに言葉で伝えました。「返事が遅い」「通知に用件が残っていない」と伝えて修正してもらい、もう一度電話で確認する。この繰り返しです。
初期の作成とテストは丸1日ほど。その間はほかの仕事を進められたので、ずっと付きっきりになる必要はありませんでした。
作成に使ったのがCodexのAstraで、完成したシステムで普段の電話に応対しているのはRealtime APIです。
少し大変だったのは、実際に電話して、応答の流れや通知内容を確かめるところです。動くものができても、使ってみると気になるところは出てきます。事務の方にも試してもらい、その後も調整を続けました。
技術メモ：使ったライブラリ・APIと、採用しなかった方式
ここだけ少し技術的な話です。2026年9月の構成記録をもとに、主なソフトウェア・ライブラリ・APIをまとめました。
| 役割 | 使ったソフト・ライブラリ・API | 今回の使い方 |
|---|---|---|
| 電話の受け口 | NTTのホームゲートウェイ RS-500MI＋Asterisk | IP電話の子機としてSIP接続し、着信や通話音声を扱う |
| 実行環境 | Ubuntu＋Python | 受付・音声処理・通知を動かす。今回の構成ではローカルの文字起こしはCPUで実行 |
| AIとの音声会話 | OpenAI Realtime API＋websockets | 標準モデルを通常受付に採用。Pythonのwebsocketsで音声APIへ接続 |
| ローカルの文字起こし | faster-whisper／CTranslate2 | 別番号の聞き取りと、通話後の録音の文字起こし。Whisperのsmallモデルを使用 |
| 社内通知 | Chatwork API | 通話終了後に用件や折り返し希望などを送信 |
| 受付記録の保存 | Google Sheets API＋google-auth／requests | サービスアカウントで認証し、スプレッドシートに記録 |
| 比較・予備の方式 | Codex CLI（ChatGPTアカウントでログイン） | 音声を文字にする→Codexで返答を作る→音声にする方式 |
通常受付の流れは、NTTの電話機器 → Ubuntu上のAsterisk → Realtime APIで音声会話 → Chatwork通知・スプレッドシート記録です。AsteriskとAI側の音声処理はAudioSocketでつなぎ、通知と受付記録への書き込みは、通話後に別の処理で行っています。
会話はRealtime APIと音声で直接やり取りします。ローカルのWhisperは、別番号の聞き取りと、通話後の録音の文字起こしに使っています。録音から起こしたテキストは、通知内容と照合して問題を調べるときにも役立ちました。
最初はChatGPTプラン内のCodexで対応しようとした
最初に試したのは、ChatGPTプランの利用枠でCodexを使い、電話への返答を作る方式でした。別途のRealtime API代をかけず、普段のプランを活用できれば、という考えです。
ただ、実際に電話してみると、返答までに5秒ほど待つ感覚がありました。こちらが話してから間が空くので、自然に会話しているというより、留守番電話に向かって話しているようになってしまいました。
会話のテンポが合わなかったので、普段の受付にはRealtime APIを使うことにしました。Codex方式も、いざというときの予備として残しています。
安いRealtime APIも試したが、日本語の細かな意図が気になった
Realtime APIは、安い軽量モデルと標準モデルの両方を試しました。軽量モデルでも日本語で会話はできましたが、私の感覚では、言葉は通じているのに、細かな意図が少しずつ伝わりきっていないような場面がありました。
相づちは返ってくるけれど、こちらが意図した理解とは少し違う。電話の受付を任せるには、この微妙なずれが気になりました。
そのため、通常受付には標準モデルを選びました。電話自体が少ないうちの使い方では、API代の安さだけで選ぶより、用件を伝えやすいと感じる方を使うことにしました。
電話番号の確認は、通知番号を使う場合と読み上げてもらう場合に分けた
最初はRealtime APIに電話番号を聞き取らせようとしましたが、何度試しても数字を微妙に間違えることがありました。そこで、着信時の通知番号を使う場合と、相手に別の番号を読み上げてもらう場合で、処理を分けました。
① 着信時に通知された番号を使う
基本はこちらです。SIPで届く発信者番号をサーバー側で取得し、「ご連絡先は、今おかけの番号でよろしいでしょうか？」と確認します。了承されたら、取得済みの番号を連絡先として保存します。
番号はプログラム側で表記を整えて保持し、読み上げにも固定音声を使います。すでに取得できている番号を、わざわざ音声から聞き取り直さずに済むようにしました。
② 別の番号を相手に読み上げてもらう
別の電話番号に折り返してほしい場合や、非通知の着信では、相手に連絡先を読み上げてもらいます。こちらはRealtime APIの会話中の認識に任せず、番号を話した音声を録音し、Ubuntu上のWhisperで文字起こしする方式にしました。
ローカルの文字起こしにはPythonのfaster-whisperを使い、推論処理はCTranslate2で動かしています。流れは「番号を録音 → ローカルで文字起こし → 認識した番号を確認」。普段の受け答えはRealtime APIに任せつつ、電話番号の取り込みは別の処理として扱っています。
この部分は、別番号を録音して確認するphone_capture.pyと、発信者番号の整形や連絡先確認を行うcallback_numbers.pyに分けて実装しました。
電話番号は、1桁違うだけでも困るんですよね。ここはテストで苦労しました。
最初と最後の挨拶は、保存済みの音声で待ち時間を減らした
電話がつながってからAPIの準備が終わるまで、無音で待たされるのも気になりました。そこで、最初の挨拶はあらかじめ生成・保存しておいた音声を流し、その間にRealtime APIの接続準備を進めるようにしました。
「お電話ありがとうございます。AI受付でございます」と挨拶をしている間に準備し、その後の会話をRealtime APIにつなぎます。挨拶の生成を毎回待つ必要がなくなりました。
終了時も同じ工夫をしています。「お電話いただきありがとうございました。失礼いたします」といった締めの挨拶は保存済みの音声を使い、再生し終わったら通話を終了します。最後の一言を生成する待ち時間や、挨拶後の無駄な間を減らすためです。
冒頭と締めの音声は、会話と同じ声を指定して用意しました。決まった挨拶は保存音声、用件のやり取りはRealtime API、という使い分けです。
電話から動作確認や設定変更ができるようにもしました。実際にかけた電話で、そのまま調整を試せます。
電話をかけてテストしてみると
出来上がったところで、私や事務の方が実際に電話をかけ、仕事の相談や折り返し依頼を伝えてみました。電話での受け答えと、通話後にChatworkへ届く通知を確認するテストです。電話番号の聞き間違いには、先ほどの番号の取り込み方を分ける工夫で対応しました。ここでは、通知内容や応答のタイミングで気づいた点を紹介します。
すると、事務の方から「電話では復唱していたのに、通知を見ると用件が省かれている」という指摘が。ログを確認しながら、次の点を直していきました。
問題① 「ExcelからWebへ移したい」の背景が抜けた
最初の確認では、次のような相談を電話で伝えました。
現在Excelで管理している顧客情報を、Web上で管理できるようにしたい。システム開発について相談したい。
ところが、通知の要約にはWebで顧客情報を管理するシステムの相談であることは残っていても、「現在はExcelで管理している」という背景が抜けていました。
「システム開発の相談」という大きなくくりでは合っています。しかし、折り返す担当者にとっては、既存のExcelを置き換えたいのか、新しく仕組みを作りたいのかで、最初に確認することが変わります。
試した方の指摘だけでなく、文字起こし・AIの発言ログ・保存された要約を照合したところ、この背景は保存済みの要約から抜けていました。最終確認の発言にも省略があり、どの段階で抜けたのかを分けて見る必要がありました。
問題② 内容は入っていても、英語と受付処理の説明で読みにくい
別の試用では、依頼中のホームページ改修は今週公開予定と認識しており、進捗を確認したい、という用件を伝えました。こちらは通知を調べると、進行中の改修や公開予定の時期は英語の文章に含まれていました。
つまり、すべてのケースで情報が消えていたわけではありません。必要な内容があっても、英語や電話番号確認などの説明が混ざっていて、用件をつかみにくいという問題もありました。
電話受付の記録として正しそうに見える文章と、担当者がすぐ使えるメモは、同じではありませんでした。
最初の改善：会話中の復唱と、通知用の記録を分ける
そこで、通知用の要約を次の方針で修正しました。
日本語で書く／現状・希望・依頼事項・時期を残す／相手が話していないことは推測で足さない。電話番号の確認などは、用件ではなく専用の欄で扱います。
電話口での復唱は簡潔なままにし、担当者へ渡す記録まで同じ短さに縮めないようにしました。
たとえば最初の相談なら、「現在Excelで管理している顧客情報をWeb上で管理できるようにしたい。システム開発について一度相談したい」という具体性を残す方針です。
修正後の処理に、相談を模した会話ログを入力して確認したところ、「Excel」や「今週公開予定という認識」が日本語の用件に残ることを確認しました。
それでも「今日の15時以降」が抜けた
ここで終わりにせず、別の保存済みの文字起こしでも試したところ、まだ問題がありました。
相手は「今日の15時以降に電話してほしい」と伝えているのに、生成された通知では時間指定が抜けていました。さらに、話されていない「進捗または対応状況」という目的が補われていました。
希望時間がないと、担当者が都合の悪い時間に折り返してしまうかもしれません。文章として自然でも、受付メモとしては困ります。
そこで、折り返し希望日時を要約とは別の項目で抽出し、通知の用件へプログラムで付記するように変更しました。あわせて、話されていない目的を推測で補わないようにしました。
同じ保存済みの文字起こしで再実行した結果、用件は次の形になりました。
折り返し希望日時：今日の15時以降。
先日依頼している件について、連絡がほしい。
※この再テストは、保存済みの文字起こしを使った確認です。
名前の聞き間違いは、要約とは別の課題として残した
試用では、会社名の聞き間違いもありました。リアルタイムの認識と通話後の文字起こしで、表記が食い違うケースも確認されています。
今回は用件の情報が落ちる問題を先に直し、社名・氏名の認識処理は現状のまま、しばらく様子を見ることにしました。
実際に電話して気づいた「応答が早すぎる」違和感
AIが電話に出るまでの時間を1秒に設定して試したところ、思った以上に早くつながり、話し始める前に挨拶が始まる感覚がありました。
待ち時間は短ければ短いほどよいと思いがちですが、自分でかけてみると、話し始める心構えとのずれも気になります。
「え、もうつながったの？」ってなりました。早ければいいわけでもないですね。
最終的には、応答までの待ち時間を3秒にしました。うちの環境では、電話がワンコール鳴ってからAI受付につながります。着信にもぎりぎり気づけて、かける側も待たされすぎない、ほどほどの長さです。
まとめ：コードは書かず、電話で試しながら使える受付にできた
月3,000円の電話代行から切り替えて、24時間受け付けてもらえて、用件はChatworkで社内共有できる。電話が少ないうちには、とても使い勝手のよい仕組みになりました。
作成はCodexのAstraに任せ、私は要望を伝えて電話で確認する役に。ほかの仕事と並行して進められたのも助かりました。
機器の追加購入費は0円。Realtime API代は約40回のテスト通話で約1ドルでした。実運用の月額は、これから確認していきます。
手間がかかったのはテストです。電話番号が少し違う、通知から大事な用件が抜けるなど、実際に電話しなければ気づかなかった点がありました。受け答えだけでなく、担当者に届く通知まで確認しておいてよかったです。
名前の聞き取りなど、引き続き様子を見ている部分はあります。それでも、自分でコードを書かずに、欲しかった電話受付を形にできました。
最初のテストは少し大変でしたが、今は「作ってよかった！」と思っています。
