技術設計面接の解説と模範解答｜音声対話システム開発

技術設計面接（システムデザイン面接）のお題「音声対話システム開発」を題材に、事前に押さえておく知識、面接で引き出せる前提、論点、模範解答、よくあるつまずきを順に解説します。

ほかのお題の解説は技術設計面接の解説と模範解答まとめにあります。

この記事で使う設計の基礎は、日本語のシステムデザイン面接の教材 SystemDesign InterviewCat で詳しく学べます。この記事の各節に関係する章は次のとおりです。

設計面接では、お題を聞いた時点で「たぶんこの作りだろう」という仮説を持ち、前提を聞くたびにそれを確かめたり崩したりします。電話で話す AI のお題なら、まず「患者の声を受けてから AI の声を返すまでを、どうつなぐか」の選択肢を押さえておきます。声を受けて声を返すまでを、文字を経由して順につなぐか（OpenAI は chained、一般にはカスケード方式と呼ぶ）、音声をそのまま扱うモデルに任せるかの選び方を、ここでは音声対話の方式と呼びます。

患者が言い終えてから AI の声が出るまで

患者が「来週の水曜の午前に空いてますか」と言い終え、AI が「水曜の午前ですね。10 時と 11 時が空いています」と返す場面を、方式ごとに時間の棒で並べます。横軸は患者が言い終えてからの時間で、点線が前提の 1 秒です。

• 話し終わりの判定：相手が話し終わったか、まだ続くかを見分ける処理
• STT：声を文字に起こす音声認識
• LLM：文字の会話を読んで、返事の文や予約 API の呼び出しを決める言語モデル
• TTS：文字を声にする音声合成
• ストリーミング：前の処理が全部終わるのを待たず、できた分から次の処理へ渡すこと

それぞれの方式で何が起きるか

同じ「来週の水曜の午前に空いてますか」に対して、方式ごとに裏で起きることを並べます。

順につなぐ方式（無音を待ってから処理する）：無音が一定時間続くのを待ち、録った音声を STT に渡して文字にし、その文字を LLM に渡して返事を作り、「水曜の午前ですね。10 時と 11 時が空いています」が全部できてから TTS で声にします。部品ごとに製品を選べ、途中に文字が残るので、何を聞き取って何を答えたかを確かめられます。弱いところは、待ちが足し算になることです。図の 1 行目のように、無音の待ち、文字起こし、返事の全文、声の合成が順に並ぶので、1 秒には届きません。

順につなぐ方式（ストリーミングで重ねる）：部品は同じですが、待ちを重ねます。STT には話している最中から音声を流して文字起こしを進めておき、LLM が「水曜の午前ですね」の 1 文を作った時点で TTS に渡して話し始めます。「10 時と 11 時が空いています」は、1 文目を話しているあいだに作ります。無音を待つ方式と比べると、途中に文字が残る良さを保ったまま、話し始めまでの時間を大きく縮められます。それでも、話し終わりの判定の待ちと、文字起こし、返事、声それぞれの最初の出力までの時間は残ります。

音声をそのまま扱うモデル（speech-to-speech）：声を受けたモデルが、文字を経ずに声で答えます。順につなぐ方式と比べると、処理を受け渡す時間が無いぶん速く、声の調子も返事に反映できます。ただし、話し終わりの判定は同じように要ります。弱いところは、返事の前に中身を確かめにくいことです。OpenAI の Realtime API では、患者の発話の文字起こしはモデルとは別の仕組みで非同期に作られるので（OpenAI Realtime client events）、返事より先に検査には使えません。返事の文を決まった型に差し替えたり、部品を 1 つだけ別の製品に替えたりすることもできません。

方式名は製品やフレームワークによって呼び方が変わりますが、設計面接で比べたいのは名前ではなく、どこで待ちが生まれ、返事の前に何を確かめられるかです。

方式を比べる

方式の違いは、「水曜の午前ですね。10 時と 11 時が空いています」と返すまでの時間と、聞き取った内容を返事の前に確かめる場面の 2 つに、「決まった手順を守らせやすいか」を加えて比べると分かりやすくなります。

表から分かるとおり、速さだけなら音声をそのまま扱うモデルが有利で、確かめやすさなら順につなぐ方式が有利です。順につなぐ方式でもストリーミングで重ねれば、速さの差はかなり縮まります。ただし、どの方式でも話し終わりの待ちは残ります。

どの方式でも要る 2 つの処理

話し終わりの判定：一番簡単な形は、VAD（音声に人の声が入っているかどうかだけを見分ける仕組み）で無音が一定時間続いたら話し終わりとみなすものです。無音の長さだけで決めると、待ちを短くすれば言いよどみの途中で割り込み、長くすれば返事が遅れます。そこで、文字起こしの途中経過と会話の流れから「この言い方なら続きがある」と見分けるモデルを VAD と併せて使う方法があります。「来週の、えっと」で止まったら待ち、「水曜の午前で」で止まったら早めに返す、という区別ができます。

割り込み：AI が話している途中で患者が話し始めることを割り込みと呼び、どの方式でも、割り込まれたらすぐ AI の声を止める処理が要ります。止め方の詳細は、模範解答の 5 で扱います。

最初の仮説

お題文だけを読んだ段階では、次の仮説を置きがちです。どれも筋は悪くありませんが、前提を聞くと一部が崩れます。答え合わせは「隠れていた前提を見直す」で行います。

面接官から示されるお題は次のとおりです。

本日はシステムの設計方法についてディスカッションしたいと思います。今、歯科クリニックチェーンの電話の予約受付を自動化するために、音声で対話するAIを作ることを考えています。電話で予約の新規・変更・キャンセルを受け、予約台帳のAPIで空きを確認して登録し、判断できない用件はスタッフに転送するようにしたいです

▼このお題は CaseMatch の AI 面接で、面接官に前提を質問しながら練習できます。

前提は質問すれば答えてもらえます。面接で引き出せる前提を、音声対話の方式の選び方に関わるものとそれ以外に分けて並べます。種類の列は、機能要件、非機能要件、制約、将来のどれにあたるかです。設計への影響の列は、次の節の問いを考えてから読んでください。

音声対話の方式の選び方に関わる前提

事前知識の比較表の 3 つの比べ方（声が返るまでの時間、返事の前に確かめられるか、手順を守らせやすいか）と、どの方式でも要る話し終わりの判定と割り込みの扱いを決める前提です。

それ以外の前提

取り違えの防ぎ方、予約台帳とのやり取り、転送、個人情報、規模のように、どの方式を選んでも別に設計が要る前提です。

お題文は「電話で予約を受けて、空きを確認して登録し、判断できなければ転送する」としか言っていません。前提の表は、質問して初めて出てきたものです。設計への影響を見る前に、あらためて前提を読み直し、お題文の裏に何が隠れていたかを考えます。先に次の問いを考えてから、前提の表の「設計への影響」の列と見比べてください。

1. 前提のうち、互いにぶつかっている 2 つの組を 3 組挙げてください。
2. 話し終わりの待ちを短くしたい理由と、長くしたい理由を、前提から 1 つずつ挙げてください。
3. 最初の仮説 1〜4 のうち、どれがどの前提で崩れますか。
4. お題文からは読み取れなかったのに、設計を一番大きく変えた前提はどれですか。

前提どうしのぶつかり

前提の多くは単独では難しくありません。難しいのは 2 つが互いに逆を向いているところで、このお題では次の 3 組です。これがそのまま、面接の後半で詳しく問われる 3 つの論点（深掘り）になります。

仮説の答え合わせ

このお題は、音声認識と LLM をつないで予約を取るだけのシステムに見えます。しかし実際に問われるのは、「1 秒以内に話し始める」速さと、「日時と患者を取り違えない」「止まっても電話がつながる」確かさを、聞き取りにくい電話の音声の上で両立させる設計です。

論点は 3 つあり、重さの順に 1 秒の内訳、取り違えを防ぐ確認、スタッフへつなぐ経路です。どれも前提のうち 2 つが互いにぶつかっており、どちらをどう守るかを自分で決めて説明できるかが問われます。予約台帳の側の作りには深入りしなくてかまいません。

模範解答の深掘り（5〜7）では、論点ごとに「弱い答え」「よい答え」「より良い答え」を並べ、何が足りないかを示しています。

面接での問答の順には合わせず、このお題への答えを 1 つの設計としてまとめた解答例です。設計の筋は、STT、LLM、TTS をストリーミングで重ねて 1 秒に収め、予約台帳には復唱で確かめた内容だけを送り、AI が止まっても電話の側で内線へつなぐ、というものです。前提に無いことは仮定として置き、その旨を書いています。

1. 作る範囲

前提を確かめたうえで、最初に作る範囲を次のように切ります。

• 作る：電話 API との音声のやり取り、話し終わりの判定と割り込みの扱い、予約の新規、変更、取消の会話、復唱とプッシュ入力による確認、予約台帳 API の呼び出しと流量制御、スタッフへの転送と用件の表示、夜間と休日の折り返しの受け付け、通話と用件の記録
• 作らない：症状の相談や治療内容への回答、予約台帳そのもの、Web 予約、通話の録音（既存の仕組みを使う）

LLM には会話の聞き取りと言い換えだけを任せ、予約台帳に何を送るか、いつ転送するかは、会話の状態を持つ自前のコードで決めます。

2. 見積もり

見積もりで出すのは、構成を決める 3 つの数字だけです。どれも前提の値から計算できます。

3. データモデル

予約台帳の正となるデータは SaaS の側にあり、自前で持つのは「1 本の通話で何を聞き取り、何を確かめ、台帳に何を送ったか」の記録だけです。中心になる表は次の 4 つです。

予約操作の表は、すべての項目が確認済みになった用件からしか作れないようにします。用件の要約には「症状の相談あり」のような種類だけを書き、症状の中身は残しません。

4. 全体構成

患者との会話は、通話ごとに 1 つの音声エージェントが最初から最後まで受け持ちます。予約台帳との通信と記録は、その裏で流量制御を通して行います。

色を付けた音声エージェントがこの設計の要で、会話の状態と「何が確認済みか」をここで持ちます。

1. クラウド PBX と電話 API：各院の代表番号への着信を外部の電話 API へ転送し、電話 API が音声を WebSocket で音声エージェントへ流します。電話の音声は 8kHz なので、STT にはその前提で精度を測ったものを選びます。
2. 音声エージェント（自前）：1 通話に 1 つ立ち上がり、話し終わりの判定、STT と LLM と TTS の受け渡し、割り込みの扱い、会話の状態（用件と確認状態）を受け持ちます。通話のあいだ接続を持ち続けるので、空きのあるエージェントへ新しい通話を振り分け、通話の数に合わせて台数を増やします。
3. STT、LLM、TTS：外部のサービスを使い、どれもストリーミングで呼びます。LLM には症状に答えないこと、予約に必要な項目を聞き取ることだけを指示し、復唱の文は LLM に作らせずテンプレートで組み立てます。
4. 予約ツールと流量制御：音声エージェントから呼ばれ、確認済みの用件だけを予約台帳 API に送ります。全院の呼び出しを 1 つの流量制御に通し、確定の直前の照会と登録を、先回りの照会より優先します。
5. 停止時の応答：電話 API に、音声エージェントが応答しないときに使う予備の指示を登録しておき、その中身は「院の内線へ転送する」だけにします。AI のサーバーが丸ごと止まっても、この指示は電話 API の側で動きます。
6. スタッフ画面と記録：転送の前に用件の要約を画面に出してから内線を鳴らします。夜間と休日の折り返しの依頼も同じ画面に並べ、翌朝スタッフが順にかけ直します。

通話の録音は既存の仕組みに任せ、音声エージェントは音声を保存しません。STT の文字起こしも、記録に残すのは用件の項目だけにして、会話の全文は残しません。

実例：OpenAI は音声エージェントの作り方として、音声をそのまま扱うモデルと、STT、LLM、TTS を順につなぐ方式の 2 つを挙げ、後者の利点に処理ごとの中身が見えること、決まりの検査や会話の記録を残しやすいことを、弱みに遅延が増えることを挙げています（OpenAI Voice agents）。電話 API の例として Twilio の Media Streams は、通話の音声を 8kHz の μ-law で WebSocket に流し、こちらから返した音声を再生します（Twilio Media Streams）。

代わりの案：STT、LLM、TTS の代わりに、音声をそのまま扱うモデルを使う構成もあります。話し始めまでの時間は縮まりますが、復唱の文をテンプレートで固定すること、症状の相談を返事の前に止めることがしにくくなります。採るなら、モデルが予約ツールを呼ぶときの引数を文字の用件として受け取ってスタッフ画面にも出し、確認と登録の手順は自前のコードに残します。1 通話 50 円に収まるかは、どちらの方式も通話の平均の長さと各サービスの単価で計算して比べます。

5. 深掘り：1 秒の内訳

1 秒は、処理を順に待つと超え、重ねても余裕の無い長さです。話し終わりの判定、STT、LLM、TTS のそれぞれで「何を待っているか」を分け、待ちを重ねるか短くします。最初の仮説の 1 と 2 は、ここで崩れます。

処理ごとの目安は次のとおりです。数字は Twilio が公開している目安で、製品と条件で変わるので、作るときは自分で計測し直します。

3 つの処理の目安を足すと約 825ms、電話網を含めると 1 秒を超えます。目安どおりでも 1 秒には余裕が無いので、話し終わりの待ちを意味から見分けて短くし、決まった文は作り置きの声で返します。

• 話し終わりは意味から見分ける：VAD に加えて、文字起こしの途中経過から「まだ続くか」を見分けるモデルを使います。「来週の、えっと」なら待ちを長く、「水曜の 10 時でお願いします」なら短くします（OpenAI の Realtime API でも、無音で区切る server_vad とは別に、話し終わった確からしさを中身から見積もる semantic_vad を選べます。OpenAI Voice activity detection）。高齢の患者の言いよどみで割り込まないことと、言い切った発話にすぐ返すことを、無音の長さ 1 つで両立させなくて済みます。
• 予約 API を待つあいだは先に話す：空き照会は 1〜2 秒かかるので、呼び出すと同時に「空きを確認しますね」と固定の文を流します。この文は作り置きの声なので、LLM も TTS も待ちません。照会が終わったら結果を話します。
• 割り込まれたら、電話の側の音声まで捨てる：患者が話し始めたら、TTS と LLM の生成を止め、電話 API の側で再生を待っている音声も消します。会話の記録は患者に実際に聞こえたところまでで切ります。「はい」「ええ」のような相づちでは止まらないよう、相づちと割り込みを見分ける仕組みも使います。
• 話す速さをゆっくりにする：高齢の患者が多いので、TTS の話す速さを落とし、1 文を短くします。1 文が短いほど最初の文が早くでき、割り込まれたときに聞き逃す量も減ります。

この構成で 1 秒を超えやすいのは、LLM が予約ツールを呼ぶかどうかを決めてから話す場面です。ツールを呼ぶと決めた時点で固定の文を先に流し、ツールの結果を待つ時間を会話の間に隠します。

実例：Twilio は、STT、LLM、TTS を順につなぐ音声エージェントの遅延を処理ごとに分け、STT 約 350ms、LLM の最初の出力まで約 375ms、TTS の最初の音まで約 100ms を目標に挙げ、LLM がストリーミングで返さないなら採用しない、としています（Twilio, 2025）。LiveKit は、無音の長さだけで話し終わりを決めると短ければ割り込み、長ければ遅れると指摘し、過去の会話から話し終わりを見分けるモデルで意図しない割り込みを 85% 減らしたと報告しています（LiveKit, 2024）。電話の側では、Twilio の Media Streams に clear を送ると、再生を待っている音声がすべて消えます（Twilio Media Streams）。

6. 深掘り：取り違えを防ぐ確認

予約台帳に送るのは、患者と日時と操作の種類がすべて確認済みになった用件だけです。確認のしかたは項目ごとに変え、聞き取りにくい項目ほど声に頼りません。

1. 患者を特定します。診察券番号は声ではなく電話のボタンで押してもらい、桁数と終わりのキー（#）を決めて受けます。診察券が手元に無ければ、生年月日をボタンで受け、発信者番号と合わせて患者を絞ります。最後に氏名を AI から読み上げ、「はい」をもらいます。
2. 日時を復唱します。「11 月 5 日、水曜日の午前 10 時」のように日付と曜日を両方言い、「来週の水曜」のような言い方は AI の側で日付に直してから読み上げます。復唱の文はテンプレートで作り、LLM に言い換えさせません。
3. 確定の直前に、その枠の空きを照会し直します。埋まっていたら、近い空きを 2 つほど提案して 2 に戻ります。
4. 登録して、結果を「ご予約を承りました。11 月 5 日、水曜日の午前 10 時です」のように日時を添えて伝えます。

• 聞き取れないときの扱い：同じ項目を 2 回聞き直しても確かめられなければ、3 回目は聞かずにスタッフへ転送します。前提が「迷ったら転送してよい」なので、聞き直しを重ねて通話を長くするより、転送したほうが取り違えも患者の負担も減ります。
• 登録を自動で再試行しない：予約台帳 API には予約を読み出す機能が無いので、登録が時間切れになると、予約が入ったかどうかを確かめられません。もう一度送ると二重に入るおそれがあるので、結果不明の登録は再試行せず、患者には「確認してスタッフから折り返します」と伝え、スタッフ画面に回します。照会は何度送っても台帳を変えないので、再試行してかまいません。
• 変更と取消：対象の予約を、患者と、患者が言う元の日時で指します。元の日時も復唱し、取り消す予約を取り違えないようにします。変更は「新しい枠の登録」と「元の枠の取消」の 2 つの操作になるので、新しい枠の照会し直しを先に済ませます。変更の API が 1 回で済むかは前提に無いので、面接では確かめたい点として面接官に聞きます。

Web 予約と枠を取り合う問題は、予約台帳 API に枠を仮押さえする機能が無いので、こちらでは完全には防げません。確定の直前に照会し直すことで取り合いが起きる時間を 1〜2 秒に縮め、それでも登録が「埋まっていた」で返ったら別の枠を提案します。

実例：Twilio の Gather は、電話のボタン入力（DTMF）を受け取る指示で、受け取る桁数と、入力の終わりを示すキー（デフォルトは #）を決められます（Twilio Gather）。番号のように聞き違えると困る項目を、声の聞き取りから外す方法になります。

7. 深掘り：スタッフへつなぐ経路

転送の経路は、AI が正常に動いているときと止まったときで別々に持ちます。止まったときの経路は AI に頼らず、電話 API の側だけで完結させます。

• 転送のきっかけ：「痛い」「腫れている」のような急患の言葉、症状や治療内容の質問、同じ項目を 2 回聞き取れないとき、患者が人と話したいと言ったとき、予約台帳 API が失敗したときです。急患は予約を取らずにすぐ転送します。
• AI が止まったとき：電話 API に、音声エージェントが応答しないときの予備の指示を登録し、その中身を「その院の内線へ転送する」だけにします。音声エージェントの空きが足りないときも、同じように内線へ回します。電話 API 自体が止まったときは、クラウド PBX の側で外部への転送が失敗したら内線を鳴らす設定にします。この設定ができるかは PBX の製品によるので、面接では確かめたい点として面接官に聞きます。
• 内線が出ないとき：受付スタッフは 1 院 2 名で、ピークの 9〜10 時は来院した患者の対応とも重なります。内線を呼ぶ時間に上限を決め、出なければ AI に戻して折り返しの依頼として受けます。
• 夜間と休日：AI だけで終わる予約の新規、変更、取消はそのまま受けます。転送が要る用件は折り返しの依頼として用件と連絡先を聞き、翌朝のスタッフ画面に並べます。急患には、院が決めた夜間の案内（休日夜間に急患を診る医療機関など）を流します。この案内の中身は院ごとに決めてもらう前提です。

転送の前には、スタッフ画面に用件の要約（種類、患者、希望の日時、転送の理由）を出してから内線を鳴らします。スタッフは電話を取った時点で用件が分かり、患者は同じことを 2 回話さずに済みます。症状の相談で転送するときは、画面に出すのは「症状の相談」という種類までにし、症状の中身は患者から直接聞いてもらいます。症状を外部のサービスに保存しないためです。

実例：Twilio では、電話番号ごとに主の応答先とは別に予備の URL を登録でき、主の応答先から指示を取れないときや実行できないときは、すぐに予備の URL を呼び、そこで返した指示で通話を続けます（Twilio Availability and Reliability）。転送の Dial では、相手が出るまでの待ち時間（デフォルト 30 秒）と、終わったあとに結果を送る先を指定でき、結果には出なかった（no-answer）や話し中（busy）が入るので、そこから折り返しの受け付けに戻せます（Twilio Dial）。Google Duplex も、自分だけで終えられない予約を見分けたら人のオペレーターに合図して引き継ぎます（Google, 2018）。

8. 障害への備えと監視

どこが止まっても、患者の電話はスタッフか折り返しの受け付けにつながります。例外は予約の登録の結果が分からないときで、AI の側では片付けずにスタッフへ回します。

監視するのは、話し終わりから発話開始までの時間（中央値と遅いほうの 5%）、転送の割合と理由、割り込みで止まった回数、予約台帳 API の失敗と結果不明の数です。転送の割合は、見積もりで出した「予約の電話の 3 割まで」と並べて見ます。

9. 条件の変更への対応

面接の後半では、運用で起きた不具合や将来の要望という形で条件が足されます。答え方は、今の設計でなぜ起きたか、何をきっかけに何をどう処理して直すか、変えずに済むところはどこか、の順です。

例 1：同じ患者の予約が、同じ日時に 2 件入っていた

• 原因：予約台帳 API の登録が時間切れになり、予約ツールが自動で登録を送り直した。1 回目の登録は台帳に届いていたが、こちらには結果が返っていなかった。
• 直し方：登録の時間切れをきっかけに、再試行せず予約操作を「結果不明」で記録し、スタッフ画面に回します。スタッフが台帳で確かめて、患者に折り返します。予約台帳の SaaS に、同じ要求を 2 回送っても 1 件しか登録しない仕組み（冪等キー）や予約の読み出しがあるかを確かめ、あれば結果不明を自動で片付けます。
• 変えずに済むところ：音声の流れ、確認の手順、転送の経路です。

例 2：1 年後に全国 200 院へ広げたら、空きの確認で待たされる患者が増えた

• 原因：同時通話が院の数に比例しておよそ 500（100 × 200 ÷ 40）に増えたのに、予約台帳 API の上限は毎秒 10 回のままで、上限を全院で共有していると 1 通話あたり 50 秒に 1 回しか呼べなくなった。
• 直し方：まず予約台帳の事業者に、上限がチェーン全体か院ごとかを確かめ、全体なら引き上げか院ごとの上限にできるかを相談します。こちらでは、同じ院と日付の空き照会の結果を数秒だけ全通話で共有し、先回りの照会をそこから返します。確定の直前の照会だけは共有せず、毎回台帳に問い合わせます。
• 変えずに済むところ：音声エージェントは 1 通話に 1 つなので、台数を増やすだけで済みます。確認と転送の手順も変わりません。

まとめ：選んだものと捨てたもの

▼解説を読んだら、同じお題を AI 面接官を相手に通しで解いてみましょう。

海外の技術ブログと技術文書です。どれも開いて内容を確かめています。LiveKit と Twilio の記事は自社製品の紹介を兼ねています。

▼ほかのお題の解説

サカモトエンジニア監修

外資系企業のソフトウェアエンジニア。エンジニアのキャリアや面接について X や note で発信し、テック企業を目指すエンジニア向けの面接対策プラットフォーム InterviewCat を運営しています。