はじめに
前回の記事では、S2S（Speech-to-Speech）APIを比較し、体験品質・知能性能・レイテンシといった観点から各モデルの違いを整理しました。 またRAG編では、Tool Callingを含めた実務的な観点での選び方を扱いました。
今回は少し方向を変えて、実際にどこまで「アプリケーションとして成立するのか」を試した内容を紹介します。
S2Sはここ1年で急速に進化していますが、「実際に業務として使えるのか」という点はまだ見えづらい部分もあります。
そこで今回は、できるだけシンプルな構成に限定し、どこまで成立するのかを検証しました。
- モデルは
gpt-realtime-1.5のみ - 構成は System Prompt + Tool Calling
- いわゆる「複雑なエージェント構成」は使っていません
この条件で、以下の3つの音声アプリを試作しました。
- App1: 電話応対
- App2: 通訳
- App3: AI面接官
結論から言うと、想像していたよりもかなり実用に近いところまで成立しました。
全体として見えたこと
今回の3アプリはいずれもシンプルな構成ですが、共通して次のような特徴がありました。
- 会話の進行はほぼ System Promptだけで制御可能
- 「確定的な出力」だけを Tool Callingで外に出すと安定する
- モデルの知能というより、責務分離の設計で体験が大きく変わる
特に印象的だったのは、 「どこまでを会話に任せ、どこからを構造化するか」の切り分けでした。
この点を踏まえつつ、それぞれのアプリを見ていきます。
App1: 電話応対
最初に作ったのは、いわゆる一次受電の電話応対です。
役割はシンプルで、
- 宛先
- 名前
- 折り返し先電話番号
を聞き出し、電話メモとして残す、というものです。
構成としては、
- 会話進行 → System Prompt
- メモ確定 →
save_call_memo（Tool）
という分離にしています。
実際の出力イメージ
やっていることはかなり単純
- 1ターン1質問
- 必須項目が揃ったらToolを呼ぶ
- 名前と電話番号は復唱
いわゆる新人研修レベルの電話応対ルールを、そのままプロンプトに書いています。
想像以上だった点
実際に動かしてみると、かなり自然に成立しました。
- 相手が話した内容を踏まえて質問順を調整する
- すでに出た情報を重複して聞かない
- 電話番号を正確に聞き取り、復唱する
特に印象的だったのは、電話番号の扱いの安定性です。 多少聞き取りが曖昧でも、無理に補完せずに聞き直す動きが自然に出ます。
また、1回の通話コストも数円程度で、 単純な一次受電の一部は置き換え可能な感触がありました。
設計上のポイント
このアプリで重要だったのは、次の分離です。
- 会話 → プロンプトに任せる
- 確定出力 → Toolで外に出す
これにより、
- 会話は柔軟に
- 出力は安定して構造化
という状態を作れます。
App2: 通訳
次に試したのが、音声通訳です。
最初は単純な逐次通訳を想定していましたが、最終的には3セッション構成にしています。
- Channel A: 日本語 → 対象言語
- Channel B: キャラクター
- Channel C: 対象言語 → 日本語
UIイメージ
2セッションではうまくいかなかった
当初は「通訳＋キャラ」の2セッションで試しましたが、
- 入力と出力の向きが混線する
- モデル同士が会話し始める
といった問題が発生しました。
結果として、
➡︎ 双方向通訳を1セッションに持たせない
という方針に変えています。
特に、同一セッション内で双方向の通訳を担わせると、入力と出力の向きの解釈が不安定になり、結果としてモデル同士が会話を継続してしまうような挙動が発生しやすい状態でした。
同時通訳的な体験
途中から逐次通訳ではなく、ストリーミング寄りの同時通訳にすると体験が大きく変わりました。
- こちらが話している途中に通訳が始まる
- それに対してキャラクターが反応する
- その応答がまた通訳されて戻ってくる
従来の「順番に待つ」通訳ではなく、 被りながら会話が進む感覚になります。
これはかなり新鮮でした。
設計上のポイント
このアプリのポイントはシンプルです。
- 通訳は「忠実変換」に徹する
- 会話はキャラクター側に寄せる
- 双方向を分離する
結果として、
➡︎ セッション分割がそのまま品質に効く
という構造になっていました。
App3: AI面接官
最後に作ったのが、AI面接官です。
これは、
- App1のTool（構造化出力）
- App2の複数セッション
を組み合わせた形になっています。
UIイメージ
構成
- 面接官（AI）
- 応募者（AI or 人間）
に加えて、
- 求人票
- 職務経歴書
をプロンプトに差し込んで面接を進めます。
最後に、
➡︎ submit_interview_feedback
を呼び出して評価を出します。
想像以上だった点
これもかなり驚きがありました。
- 面接の流れを自然に進行する
- 回答に応じて深掘りする
- 最後に構造化された評価を出す
特に面接官側は、かなり“ちゃんとした面接官”として振る舞います。
一方で、あまりにも正確に評価してくるため、 体感としてはやや厳しめに感じる場面もありました。
AI応募者の挙動
応募者もいくつかパターンを用意しましたが、
- 優秀な候補者
- やや弱い候補者
の差がかなり自然に出ます。
特に「書類は通るが決め手に欠ける」ような微妙なラインも再現されており、 このあたりは実務的にも興味深い結果でした。
設計上のポイント
このアプリでは、
- 会話（面接進行） → プロンプト
- 評価（最終出力） → Tool
という分離に加えて、
➡︎ コンテキスト（求人票・職務経歴書）をそのまま渡す
ことが効いています。
まとめ
今回の3つの試作から見えてきたのは、
S2Sはまだ万能ではないものの、 「型のある会話業務」はかなりの精度で成立するということでした。
特に重要なのは、
- モデルの性能そのもの
- よりも
- どの責務をどこに置くか
です。
整理すると、
- 会話 → プロンプト
- 確定出力 → Tool
- 複雑な役割 → セッション分割
この3点で、多くのユースケースは一定の形になります。
少なくとも今回の範囲では、「複雑なエージェント構成を組まなくても、ここまでは作れる」というラインは見えたように思います。
おわりに
今回の内容はあくまで試作レベルですが、 S2Sが「デモ」から「実装」に近づいてきている感触はありました。
一方で、
- 安定性
- 長時間運用
- エッジケース対応
といった点はまだ検証が必要です。
今後もこのあたりは継続的に試していきたいと思います。
