音声エージェントを使うと、ユーザーはアプリケーションに話しかけて質問したり、タスクを完了したりできます。設計でまず決めるのは、音声でのやり取りを推論やツールにどうつなぐかです。対話を続けながら別のバックエンドに処理を任せる方式、単一の音声モデルで処理する方式、パイプラインの各段階を個別に制御する方式があります。
アーキテクチャの選び方
| アーキテクチャ | 適した用途 | 選ぶ理由 |
|---|---|---|
| GPT-Live | 独立したバックエンドを使う全二重の対話 | 既存のテキストワークフローを活かし、バックエンドを独立して選べます。バックエンドでの処理中も対話を続けられます。 |
| Realtime API | 1 つのセッションでの音声処理、推論、ツールの使用 | 1 つのモデルが音声を解釈し、次の行動を決めて音声で応答します。 |
| チェーン型音声パイプライン | 音声処理とテキスト処理の各段階の制御 | 処理の途中でテキストを確認・変換でき、各コンポーネントを個別に交換できます。 |
全二重の音声エージェントの構築
GPT-Live は、相手の声を聞きながら同時に話すことができます。この機能を全二重と呼びます。ライブモデルが音声での対話を担当し、推論とツールの使用は別のバックエンドに委任します。バックエンドで処理を実行している間も、ユーザーは話し続けられます。
ビジネスロジックやツールを含む既存のテキストワークフローをそのまま使い、音声インターフェースとして GPT-Live を追加できます。バックエンドの処理を誰が実行し、そこに会話のコンテキストを誰が渡すかは、委任モードで決まります。
- クライアント委任: バックエンドのモデルとプロバイダーを選び、独自のエージェントやワークフローを接続します。アプリケーションが処理を実行し、結果を GPT-Live に返します。
- Responses 委任: バックエンドでの推論とツールの使用には、OpenAI がホストする Responses モデルを選びます。GPT-Live が会話のコンテキストを渡し、モデルの呼び出しを管理します。カスタム関数は引き続きアプリケーションが実行します。
どちらのモードでも、権限と業務記録はアプリケーションが管理します。話し方はライブモデルのプロンプトで、業務ルールはバックエンドのプロンプトで指定します。
まずは GPT-Live 入門を参照してください。バックエンドの設定については委任とツール、話し方の設定については音声モデルのプロンプト設計を参照してください。
音声変換型エージェントの構築
Realtime API では、RealtimeAgent と RealtimeSession を使って、ブラウザで動作するエージェントの実装を始められます。セッションは、発話のターン、ツール、割り込み、ハンドオフを管理します。スターターコード一式は、現在 Realtime API 入門に掲載されています。
チェーン型音声ワークフローの構築
音声認識、エージェントによる処理、音声生成の各段階の間でテキストを確認・変換したい場合は、チェーン型を使います。アプリケーションが次の 3 段階を管理します。
- 音声からテキストへの変換
- エージェントのワークフローの実行
- テキストから音声への変換
import asyncio
import numpy as np
from agents import Agent, function_tool
from agents.voice import AudioInput, SingleAgentVoiceWorkflow, VoicePipeline
@function_tool
def get_weather(city: str) -> str:
"""Get the weather for a given city."""
return f"The weather in {city} is sunny."
agent = Agent(
name="Assistant",
instructions="You are a helpful voice assistant.",
model="gpt-6-astra",
tools=[get_weather],
)
async def main() -> None:
pipeline = VoicePipeline(workflow=SingleAgentVoiceWorkflow(agent))
audio_input = AudioInput(buffer=np.zeros(24000 * 3, dtype=np.int16))
result = await pipeline.run(audio_input)
async for event in result.stream():
if event.type == "voice_stream_event_audio":
print("Received audio bytes", event.data.nbytes)
if __name__ == "__main__":
asyncio.run(main())各段階を確認したり、個別に置き換えたりする必要がある場合に、この方式が適しています。たとえば、文字起こしを保存し、テキストエージェントが応答する前にポリシーへの適合を確認してから、社内システムを呼び出します。その後、ワークフローで回答が承認されて初めて音声を生成するようにできます。
音声エージェントの評価
会話とタスクの実行結果の両方をテストします。たとえば予約アシスタントなら、予約確認の音声を聞き、正しい予約内容が保存されたことも確認します。
- 代表的なシナリオを選び、それぞれで期待する結果、ツール呼び出し、権限を明確にします。
- 各シナリオの結果を検証するために必要な音声、イベント、ツールの実行結果、アプリケーションの状態を保存します。評価の実行自体が失敗した場合と、評価は正常に実行されたもののエージェントがタスクに失敗した場合を区別します。
- シナリオを繰り返し実行し、タスクの達成状況、応答音声が聞こえるまでの時間、割り込み、意図しない無音を比較します。変更の前後で比較する際は、通話相手、モデル設定、ツール、通信方式をそろえます。
GPT-Live では、次の項目を個別に測定します。
- タスクとツールの実行結果: ユーザーの意図が保たれているかを確認し、委任した処理、ツールの引数、権限、アプリケーションの最終状態を検証します。音声で伝えた確認内容が、実際に完了した操作と一致することを確かめます。
- 会話のタイミング: 応答音声が聞こえるまでの時間、意図しない無音、発話の重なり、相手が割り込んだときに発話を譲るまでの時間を測定します。バックエンドでの処理中に相手が訂正を伝える場合も対象にします。
- 音声と言語: アクセント、背景雑音、会話中の言語切り替え、名前、数値など、さまざまな条件で入力音声を正しく認識できるかをテストします。応答音声の聞き取りやすさと応答言語の選択は、入力音声の認識とは別に評価します。
- セッションの信頼性: 接続の失敗、音声の欠落、タイムアウト、未完了のセッションは、タスクの評価スコアとは別に記録します。
合成音声、録音、模擬対話の 3 段階で、テストの複雑さを徐々に上げます。
- 合成音声: 条件を制御した 1 ターンのリクエストに合成音声を使います。比較を繰り返せるよう、生成した音声、アプリケーションのコンテキスト、期待する結果を固定します。
- 録音: 人が 1 ターンのリクエストを話した代表的な録音を再生し、声、マイク、発話中の間、音響条件がエージェントの動作にどう影響するかをテストします。
- 模擬対話: 独立したシミュレーターを通話相手にして、複数ターンにわたって対話を続けます。対話とバックエンドの処理が並行する状況で、不明点の確認、要件の変更、割り込み、問題が起きた後の復帰をテストします。
自動評価のスコアに加え、人が実際に音声を聞いて、発音、自然さ、会話のテンポが適切かどうかを評価します。
GPT-Live の評価ハーネスについては、Cookbook の音声エージェント評価ガイドを参照してください。
Realtime の評価ハーネスと具体的な評価例については、OpenAI Cookbook の Realtime 評価ガイドを参照してください。
レイテンシの測定
通話相手が必要な回答を音声で聞くまでの待ち時間を測定します。遅延の発生箇所を特定するため、バックエンドの処理時間は別に記録し、条件の近い通話で中央値と 95 パーセンタイル値を比較します。
フロントエンドのモデルを比較する際は、通話相手、録音、バックエンドのモデル、プロンプト、通信方式、音声データの送信間隔、評価器を固定します。
GPT-Live では、アプリケーションから観測できる各時点を記録します。具体的には、委任リクエストの受信、バックエンドへのリクエスト開始、最初の有用な結果の取得、ツールの実行開始と終了、結果の送信、音声の受信、クライアントでの再生です。クライアント委任では、アプリケーションがバックエンドへのリクエストを直接観測できます。Responses 委任では、ネストされたレスポンスイベントと、アプリケーションが実行するカスタムツールを観測できます。
これらの時刻を使って、接続の確立、モデルの処理、ツールの実行、バッファリング、再生のどこで遅延が生じているかを特定します。「確認しています」といった途中の応答と、通話相手が必要とする回答は、分けて測定します。
一度に変更する要因は 1 つに絞り、同じシナリオを繰り返します。応答の高速化が、タスクの成否、ツールの使い方の正しさ、割り込みにも影響していないかを確認します。バックエンドのレイテンシの削減を参照してください。
音声エージェントにも共通する基本構成要素
音声インターフェースでは通信方式と音声の入出力ループが変わりますが、ワークフロー設計の基本はテキストの場合と同じです。
- 音声エージェントに外部の機能が必要な場合は、ツールの使用を参照してください。
- 音声ワークフローでストリーミング、処理の継続、状態の永続化が必要な場合は、エージェントの実行を参照してください。
- 音声ワークフローの途中で処理を専門エージェントに振り分ける場合は、オーケストレーションとハンドオフを参照してください。
- 音声ワークフローで安全性のチェックや承認が必要な場合は、ガードレールと人によるレビューを参照してください。
- MCP を介して機能を利用する場合や、音声ワークフローが実際にどう動作したかを調べる場合は、統合とオブザーバビリティを参照してください。
まず音声アーキテクチャを選び、エージェントの残りのワークフローはテキストの場合と同じ手順で設計します。
次のステップ
用途に合ったリアルタイム処理または音声処理のガイドを選びます。
Realtime セッションのライフサイクルとイベントモデルの扱い方を学びます。
ブラウザやモバイル端末の音声を Realtime セッションに直接接続します。
推論、処理前の声かけ、ツールの使用、エンティティの抽出、話し方を調整します。