シリーズ第3回では、設計を担うアーキテクトと、実装を担うプログラマーにAIの役割を分けた話を紹介しました。今回は、その役割分担で実際にどう作ったのかを解説します。電話を受けるのは、AI受付「ハンナ」です。AI受付に任せる仕組みを、Twilio（電話をプログラムから扱えるクラウドサービス）を使って自分で組み上げました。シリーズの全体像は Proof of Concept（概念実証）ページ にまとめています。
きっかけは、会社の代表電話が必要になったことでした。企業情報を扱う調査会社に会社を登録するのに、窓口となる番号を出す必要があったのです。
困ったのは、自分の携帯番号をそのまま公開したくないということでした。一人でやっている会社です。番号を出せば、打ち合わせ中だろうと移動中だろうと、そのまま個人の携帯が鳴る。しかも一度ネット上に出た番号は、簡単には引っ込められません。
そして、公開した番号に来るコールの多くは営業電話です。実際に運用してみると、まあまあの数が来ます。毎回、全部受けるのはきつい。
そこで、いつものようにアーキテクト役のClaude Desktopに相談を持ちかけました。「業務用の電話番号を持ちたい。ただ、自分の携帯で受けるのは嫌なので、AIで受けられるようにしたい。どんな選択肢があるか調べてほしい」——最初に投げたのは、この一言です。
そこから返ってきた選択肢を見比べているうちに、自分が本当に確かめたいことがはっきりしてきました。電話にまつわる業務を、どこまでAIと連携させられるのか。
電話に出るところだけを自動化しても意味がありません。誰から何の用でかかってきて、それが自分に必要なものかどうか、そして折り返すならどうするか——そこまで繋がって初めて、電話が仕事の中に入ります。
やってみて分かったことを、先に書いておきます。電話だけが、ずっとデジタルの外に取り残されていました。
電話業務は、こういう工程でできている
考えてみると、電話業務は、こういう工程の積み重ねでできています。
鳴る → 出る → 聞く → 誰の何の用か判断する → メモを取る → 担当者に伝える → 担当者が読む → 折り返す → 記録に残す
ひとつひとつは数十秒の作業です。だから、これまで誰も分解しようとしませんでした。電話は「出るもの」であって、工程として捉えていなかったからです。
でも、分解してみると気づきます。この中で人にしかできないのは、折り返して話すところだけです。残りは、聞き取り、判断、記録、受け渡し——整理すると、デジタルで扱える仕事ばかりでした。
そして今なら、そのほとんどが技術的に届く範囲に入っています。
いまのAI電話受付は、どこまでできるのか
まず、技術の側の話をします。ここ1〜2年で、電話に使える音声AIは相当変わりました。
昔からある自動音声ガイド——「ご用件の方は“1”を押してください」というあれとは、まったく別物です。あれは、かける側に選択肢を押し付ける仕組みでした。押す番号が分からない人は、そこで詰まってしまいます。
最新の仕組み（2026年7月時点）では、普通に話しかけて、普通の日本語で返ってくるところまで実現できています。私が実際に組んでみて、動くと確認できたのは次のあたりです。
- 電話を取って、自然な敬語で応対する
- 相手が話した内容をその場で理解して、聞き返したり、用件を掘り下げたりする
- この電話が営業なのか、実際の問い合わせなのかを判断する
- 通話の全文を文字に起こして残す
- 用件を要約して、担当者に通知する
- 営業時間の中と外でメッセージを変え、時間外も用件だけは預かる
技術的には、電話の音声処理そのものはTwilioに任せ、こちら側はテキストのやりとりだけを受け持つ形にしました。応答の生成はAI、動かす場所はクラウドです。音声の難しい部分は外に任せられるようになったので、自分で組む範囲は、思っていたよりずっと小さくて済みました。
ここで一つ、意識して決めたことがあります。第一声で、こう名乗らせています。
お電話ありがとうございます。サワリーフの、エーアイ受付、ハンナが対応致します。
AIであることを、最初に伝えます。人のふりはさせません。今の音声品質だと、黙っていれば人だと思われてしまう場面があります。それは踏んではいけない線だと考えました。
もう一つ、挨拶の直後に「ピッ」という短い音を入れています。留守番電話の録音開始音と同じ役割です。AI相手だと、相手はどこから話し始めていいか迷います。この一音があるだけで、自然に話し出せる。仕様書には残らない部分ですが、こういうところが体験の質を決めると思います。
受けた電話が、整理されて届く
さて、ここからが本題です。
電話を取って要約するところまでは、いまや珍しい機能ではありません。私が確かめたかったのは、その先でした。
うちの場合、着信があると、普段使っているビジネスチャット（Microsoft Teams）の「レセプション」というチャネルに、こういう形で流れてきます。
- 相手の名前
- 用件の要約（例：「折り返し希望」）
- 通話の時刻と長さ
- 営業の可能性（高・低）
- 折り返し先の番号
電話をメモした紙ではありません。最初から、業務で使える形に整理されたデータとして届きます。
このカード型の伝達方法が効果ありだと感じました。私は、電話に出ていません。それでも、誰が何の用でかけてきて、それが対応すべきものかどうかが、数行見れば分かる。営業の可能性が高いと判断されたものは、そのまま流していい。判断に必要な材料だけが手元に揃っている状態です。
先ほど分解した工程に当てはめると、鳴る・出る・聞く・判断する・メモを取る・伝えるまでが、ここで終わっています。人の手はまだ一度も動いていません。
これまでの電話業務は、この工程を全部人がやっていました。鳴る、出る、聞く、メモを取る、担当者に伝える、担当者が内容を確認する。間に人の記憶と転記が何度も挟まっていて、そのたびに情報が落ちていた。
そのまま、次の行動に移れる
届いた通知には、ボタンが並んでいます。
- Call Back — その場から折り返しの発信ができる
- 会話内容を見る — 通話の全文を確認できる
- 見込み客に登録 — 顧客情報として残せる
要約を読んで、判断して、そのまま次の行動に移れるのです。番号を控えて、電話アプリを開いて、打ち直して、あとで別のシステムに転記する——という工程が、まるごと無くなりました。
私が「どこまで連携させられるか」と考えていたのは、まさにここでした。AIが電話に出ること自体は、入口にすぎません。受けた内容が業務の動線に乗って、次の一手まで繋がって初めて、電話が仕事の中に入ってくる。
ちなみに折り返しの発信も、同じ場所からできるようにしました。チャネルにダイヤラーのタブを置いて、そこから直接かけられます。発信元には会社の代表番号が表示されるので、こちらの携帯番号は相手に渡りません。発信理由を「見込みフォロー」「見積り」「折り返し」から選んでおけば、その記録も残ります。
受けるだけでなく、かけるほうも同じ場所に集まった。電話にまつわる仕事が、一か所で完結するようになりました。
一人の会社でも、自社用のアプリは作れる
もう一つ、書いておきたいことがあります。
このダイヤラーは、SawaLeaf名義の自社アプリとして登録されています。アプリの一覧に自社のロゴが並び、そこから開けます。
企業がグループウェアに自社専用のアプリを載せる、というのは、これまで一定以上の規模の会社の話でした。専任の情シスがいて、開発の体制があって、はじめて手が届く領域だったと思います。
いま、それが一人の会社でも実現可能です。私が作ったものは、規模で言えば小さなものです。それでも、社員が普段開いている画面の中に、自分たちの業務に合わせた入口を置くことはできる。
これは、私が支援先で見てきた「ツールは入れたのに使われない」という現象に対して、ひとつの答えになると思っています。使われない理由の多くは、そのツールを使うために、いつもの場所を離れないといけないからです。別のアプリを開き、別のIDでログインし、また戻ってくる。その往復が、日に何度も発生した時点で使われなくなる。
いつもの場所の中に、必要なものを置きに行けるようになった。これは小さな組織にとって、けっこう大きな変化だと思います。
なぜ、既製のサービスではなく自前で作ったのか
ここは短く説明します。
候補は、大きく三つの方向がありました。番号の取得からAI応答まで一式そろったサービス、人が出る電話代行、そして自前構築です。手軽さで言えば、既製のサービスが圧倒的でした。申し込めば、その日のうちに番号が使えました。
それでも自前を選んだ理由は、二つあります。
ひとつは、先ほど説明したようなビジネスチャットへの通知や、ワンボタンでの折り返し、自社アプリとしての設置などが、既製のサービスの枠の中では作れないこと。電話に出るところまでは、どこでもできます。その先を自分の業務に合わせて組むところが、できない。
そして、もうひとつが、「あとで自分で機能を追加したくなったとき、番号は移せるのか」——調べると、移せませんでした。ナンバーポータビリティに対応していなかったのです。
会社の代表電話は、一度公開したら簡単には変えられません。名刺にも署名にも載ります。つまり「まず手軽に始めて、必要になったら作り直す」という道は、最初から存在しなかった。そう分かった時点で、自前で作ることにしました。
このTwilioを使ったアプローチは、正直、お手軽ではないです。法人名義で電話番号を取るには会社の書類などの提出が必要で、揃えるのに少し手間がかかります。自前構築は「安くて自由」ではなくて、「ひと手間かかるけれど、業務に合わせて組める」という選択です。
決めるところは、人に残す
最後に、人とAIの線引きラインの話をします。
ハンナがやるのは、聞き取って、整理して、振り分けるところまでです。一切の商談はしませんし、約束もしません。
「では見積りをお出しします」とは言わせない。金額も、納期も、可否も、AIの口からは出しません。要約が私のところに届いて、そこから先は私が折り返します。
これは第3回で書いた分業と、まったく同じ形です。AIが受け取って整えるところまでを担い、決めるところは人が持つ。相手が電話であっても、構造は変わりませんでした。
結果として、増員をせずに、365日不在のない状態が作れました。打ち合わせ中に鳴っても、運転中に鳴っても、夜中に鳴っても、用件は残ります。そして翌朝、判断できる形で並んでいる。
はじめは「毎回、電話を受けるのはきついな」から始まった話でした。
出来上がってみて思うのは、変わったのは電話の受け方ではなく、業務の中に電話が入ってきたことでした。
メールは検索できますし、チャットも記録が残ります。ドキュメント類もクラウドで共有が可能です。その中で電話だけが、鳴って、出て、覚えて、伝える、という昔ながらのやり方で残っているのです。デジタルの外側に、電話だけが取り残されているのです。
いまの音声AIは、そこを繋げられるところまで来ています。そして、繋げるために必要だったのは、高度な技術というより、電話業務を工程に分解して、どこをAIやデジタルに預け、どこを自分側に残すかを決めることでした。
次回は、こうして動き始めた仕組みが、その後どうやって日々の活動の中に定着し始めたのか——運用まで落ち着いた姿を書きます。