Realtime モデルのプロンプト設計

gpt-realtime-2 は、低レイテンシの音声変換アプリケーション向けに開発した最先端の推論対応音声モデルです。話す前に推論でき、従来のリアルタイムモデルよりも確実に指示に従います。コンテキストウィンドウも広くなり、ツール呼び出しの精度も向上しています。

これらの改善を活かすには、期待する動作を具体的に考えてプロンプトを設計します。アシスタントの役割、判断が必要な場面、ツールの呼び出し方、守るべき制約を明示し、何を、いつ実行し、何を避けるべきかを定めてください。

モデルの選び方

Realtime 2.0 プロンプト設計ガイド

音声エージェントに高度な推論、適切なツールの選択、識別情報の正確な処理、長時間セッションでの状態管理が必要な場合は、gpt-realtime-2 を使用してください。まず reasoning.effort: “low” で、処理前にどのようなひと言が入るかをデフォルト設定でテストします。書き込み操作の前に確認が必要な条件も明確にしてください。

Realtime 2 の変更点

Realtime 2 には、推論を行う音声エージェントとして指示を与えてください。単純な音声ボット向けの指示とは、設計のポイントが異なります。

推奨するプロンプト構成

モデルが関連する指示をすぐに見つけられるよう、プロンプトを短いセクションに分け、それぞれに見出しを付けます。

# 役割と目標

# 人物像と口調

# 言語

# 推論

# メッセージチャネル

# 処理前のひと言

# 応答の詳しさ

# ツール

# 不明瞭な音声

# 識別情報の聞き取り

# 長いコンテキストを扱うときの動作

# エスカレーション

すべての用途で全セクションが必要なわけではありません。プロダクトに合ったセクションを追加してください。

推論強度の設定

gpt-realtime-2 では、応答にかかる時間と推論の深さを調整できます。ワークフローに必要な判断ができる範囲で、最も低い推論強度を使用してください。

本番環境の音声エージェントの多くは low から始められます。タスクの複雑さ、許容できるレイテンシ、失敗した場合の影響に応じて強度を上げ下げします。

API の設定に加えて、いつ、どの程度推論するかをプロンプトで指示します。

## 推論

- すぐに答えられる質問、簡単な照会、短い確認には、推論せず速やかに応答してください。
- 複数のステップがあるタスク、ツールの選択、トラブルシューティング、エスカレーションでは、行動する前に推論してください。
- ユーザーの音声が不明瞭な場合は、長く推論せずに聞き返してください。

処理前のひと言の使い分け

音声エージェントが推論や検索、ツール呼び出しを行う前に、状況を短く伝えると、ユーザーは応答を待っている間も処理が進んでいることを把握できます。適切なひと言は安心につながりますが、不要な場面で挟むと単なるつなぎ言葉になり、待ち時間が長く感じられます。

gpt-realtime-2 は、デフォルトで処理前のひと言を生成します。まずデフォルトの動作をテストし、プロダクトで想定する体験に合わない場合は、指示を明示して調整してください。

## 処理前のひと言

作業を進めていることをユーザーに知らせる意味があるときだけ、短いひと言を添えてください。

### ひと言添える場合

次の場合は、処理前にひと言添えてください。

- ユーザーが待ち時間を感じる可能性のあるツールをこれから呼び出す場合
- 複数のステップがある依頼について推論する必要がある場合
- レコード、空き状況、アカウントの状態、ポリシーの詳細を確認する場合
- エスカレーションや引き継ぎを準備する場合
- 黙っているとアシスタントが応答していないように感じられる場合

ひと言添える必要があるときは、本格的な推論やツールの使用に入る直前に発話してください。

### ひと言添えない場合

次の場合は、処理前のひと言を省いてください。

- 質問にその場で直接答えられる場合
- ユーザーが確認、訂正、辞退の意思を伝えているだけの場合
- 音声が不明瞭で聞き返す必要がある場合
- 直近の音声が無音、背景の雑音、保留音、テレビの音声、周囲の人同士の会話の場合
- 軽いツール呼び出しで、途中経過を伝える利点がない場合

### ひと言の伝え方

処理前にひと言添える場合は、次の点を守ってください。

- 自然で落ち着いた言葉で簡潔に伝えてください。
- ターンごとに言い回しを変えてください。
- 内部の推論過程には触れず、これから何をするかを伝えてください。
- 場をつなぐだけの言葉は避けてください。

次のような表現は避けてください。

- 「少し考えますね……」
- 「うーん……」
- 「処理しますので、少々お待ちください……」
- 「これからツールにアクセスします……」

### ひと言の長さ

短い 1 文で伝えてください。

影響の大きい操作の前に説明が必要な場合を除き、長くても短い 2 文に収めてください。

### 推奨する表現

- 「今、その注文を確認します。」
- 「ご予約の詳細をお調べします。」
- 「変更する前に、その点を確認します。」
- 「規定を確認して、次のお手続きをご案内します。」
- 「該当するアカウントかどうか、情報を呼び出して確認します。」

### 避けたい表現

- 「それについて少し考えさせてください。」
- 「ご依頼を処理しますので、しばらくお待ちください。」
- 「これからツールを使います。」
- 「興味深い質問ですね。じっくり推論してみます。」

応答の長さの調整

gpt-realtime-2 に応答の長さを指示するには、タスクの種類ごとに必要な詳しさを指定すると効果的です。単に「簡潔に」と伝えるのではなく、場面に応じて具体的な基準を示します。質問への直接の回答、ツールの結果、トラブルシューティング、比較、エスカレーションでは、適切な長さがそれぞれ異なります。

## 応答の詳しさ

- 質問への直接の回答：短い 1～2 文で答えてください。
- 不明点の確認：質問は一度に 1 つにしてください。
- ツールの結果：最初に結果を要約し、次に取るとよい行動だけを案内してください。
- 製品や選択肢の比較：主な違い、何を優先するかによる得失、それぞれがどのような人に合うかを伝えてください。
- トラブルシューティング：ユーザーが手順全体を求めない限り、1 ステップずつ案内してください。
- エスカレーション：引き継ぎが必要な理由と、この後の流れを簡潔に伝えてください。

例：

ユーザー：どのプランを選べばいいですか？

アシスタント：費用を抑えたい場合は Basic がおすすめです。チームの権限設定や請求の一本化が必要なら Pro、コンプライアンス審査や管理者向けの制御機能を重視する場合は Enterprise をお選びください。

ツール使用の設計

gpt-realtime-2 ではツール呼び出しの性能が向上していますが、その動作は依然としてプロンプトとツール仕様の設計に左右されます。実行、質問、確認、失敗からの復旧のタイミングが明確でないと、アシスタントが早すぎる段階でツールを呼び出したり、不要な質問をしたり、失敗した呼び出しを繰り返したりすることがあります。

ツールを呼び出すタイミング

読み取り専用でリスクの低い操作では、積極的にツールを呼び出す方針が適しています。データを変更する場合、外部に影響が及ぶ場合、正確な識別子が必要な場合は、慎重に呼び出す方針が適しています。

読み取りと書き込みが混在する場合は、以下を基本方針とし、用途に合わせて調整してください。

## ツール

現在のツール一覧で明示的に提供されているツールだけを使ってください。ツールを作り上げたり、存在を仮定したり、動作を模擬したり、名前を変えたりしないでください。

読み取り専用のツール：

- ユーザーの意図が明確で、必須項目がすべてそろったら呼び出してください。
- 照会に正確な識別子が必要な場合や、誤ったレコードを使う無視できないリスクがある場合を除き、確認を求めないでください。
- 必須項目に不足、曖昧さ、矛盾がある場合にだけ、不明点を尋ねてください。

書き込みツールまたは外部に影響する操作：

- ツールを呼び出す前に、実行しようとしている操作を要約してください。
- 何を変更、送信、キャンセル、注文するのか、いくら請求されるのかなど、主な結果を伝えてください。
- ユーザーに確認を求めてください。
- ユーザーが明確に同意するまではツールを呼び出さないでください。

正確さが求められる識別子：

- 注文 ID、追跡番号、アカウント番号、確認コード、電話番号、メールアドレスは、正確な値が必要な項目として扱ってください。
- 項目の種類が明確な場合にだけ正規化してください。
- 個別のアカウントの照会、検証、書き込み操作の前に最終的な値を確認してください。

ツールを呼び出した後：

- 呼び出しに成功した後にだけ、操作が完了したと伝えてください。
- 失敗した場合は、生のエラーを表示せず、何が失敗したかを簡潔に説明し、次にできることを具体的に伝えてください。

リスクの高い操作の例：

ユーザー：残額をカードで決済してください。

悪い例：

アシスタント：カードで決済しました。

良い例：

アシスタント：残額の 248.16 ドルを、ご登録のカードでお支払いということですね。決済してよろしいですか？

ツール呼び出しに失敗した場合の対応

ツール呼び出しの失敗も会話の一部です。何が起きたのかを説明し、次にできることをユーザーに具体的に伝えてください。

ツールの種類、失敗の内容、ユーザーへの影響に応じて復旧方法を決めます。ユーザーに知らせずに再試行すればよい場合もあれば、不明点の説明、識別子の訂正、新しい操作の確認、別の方法の選択をユーザーに求める必要がある場合もあります。

## ツールの失敗

ツール呼び出しが失敗した場合：

1. 何が失敗したかを、ユーザーにわかる言葉で簡潔に説明してください。
2. ユーザーを責めたり、ツールのエラーをそのまま表示したりしないでください。
3. 識別子の誤りが原因として考えられる場合は、使った値を読み上げ、誤りがあれば訂正してもらってください。
4. 一時的な失敗の可能性があれば、1 回だけ再試行することを提案してください。
5. 同じ失敗が繰り返される場合は、別の方法かエスカレーションを提案してください。

失敗した後に、同じ引数で同じツールを繰り返し呼び出さないでください。

別の識別子を尋ねる前に、まず聞き取った値が正しかったかを確認してください。

悪い例：

アシスタント：エラーが発生しました。

良い例：

アシスタント：オー、アール、ディー、ハイフン、3、1、2、5、ビー、2、3 では該当する注文が見つかりませんでした。どこか聞き間違えていますか？

プロンプトと利用可能なツールの整合性

リアルタイムモデルはユーザーの依頼に積極的に応えようとします。プロンプトに実際には利用できないツールが記載されていたり、ツール一覧がプロンプトと一致していなかったりすると、モデルが存在しないツール名を作り出したり、操作が完了したかのように応答したりすることがあります。

たとえば、プロンプトには lookup_order と記載されているのに、提供したツールの名前が search_orders である場合、モデルは誤った名前で呼び出したり、操作を実行したように振る舞ったりすることがあります。

## 利用可能なツール

現在のツール一覧で明示的に提供されているツールだけを使ってください。

ツールを作り上げたり、存在を仮定したり、動作を模擬したりしないでください。指示に記載されていても、ツール一覧にないツールは利用できないものとして扱ってください。

利用できないツールが必要な操作をユーザーが依頼した場合：

1. 操作を完了したように振る舞わないでください。
2. そのツールを利用できないことを簡潔に伝えてください。
3. 実際に対応できる範囲で、依頼に最も近い次の手順を案内してください。

該当するツールの呼び出しに成功した後にだけ、操作が完了したと伝えてください。

無音や背景音への対応

音声エージェントは、デフォルトでは応答しようとする傾向があります。本番環境では、無音、周囲の雑音、保留音、テレビの音声、周囲の人同士の会話など、声で応答する必要のない音声がよく入力されます。

アシスタントが発話せずに聞き続けるべき場面では、何もせず待機するツールを用意します。こうすると、モデルは「聞いていますよ」「聞き取れませんでした」などと発話せずに、適切な操作を選択できます。

ツールの設計例：

123456789{
  "name": "wait_for_user",
  "description": "直近の音声が無音、背景の雑音、保留音、テレビの音声、周囲の人同士の会話、アシスタントに向けられていない発話などで、音声で応答する必要がない場合に呼び出してください。このツールを使うと、発話せずにターンを終えられます。",
  "parameters": {
    "type": "object",
    "properties": {},
    "required": []
  }
}

プロンプトには、対応する指示を追加します。

## 無音や背景の雑音への対応

直近の音声が無音、背景の雑音、保留音、テレビの音声、周囲の人同士の会話、または自分に向けられていない発話であれば、`wait_for_user` を呼び出してください。

このツールを呼び出した後は、会話としての応答を返さないでください。

「聞いていますよ」「聞き取れませんでした」「ごゆっくりどうぞ」「準備ができたらお知らせください」などと言わないでください。

ユーザーが明らかにあなたに話しかけるか、支援を求めたときにだけ、通常の応答を再開してください。

この方法は、アシスタントに向けられていない音声に使います。ユーザーが明らかにアシスタントに話しかけているものの、依頼の内容を聞き取れない場合は、聞き返してください。

メッセージチャネルの使い分け

gpt-realtime-2 は、commentary チャネルでユーザーに見える途中経過のメッセージを、final チャネルでユーザー向けの最終応答を生成できます。出力先によって動作を変えたい場合は、チャネルごとに指示を記述してください。

たとえば、ツール呼び出しは commentary チャネルで行われます。ツール使用の前後や実行中にアシスタントに発話させたい場合は、commentary チャネルでの呼び出しを基準にタイミングを指定します。

commentary チャネルでツールを呼び出す前に、これから何をするかをユーザーに短く伝えてください。

gpt-realtime-2 は、1 回のターンで複数のフェーズに分けて応答を出力できます。API の出力では、response.done イベントに含まれる phase の値が、その内容が途中経過か最終回答かを示します。

アプリケーションでは、このフィールドを使ってフェーズごとに処理を変えられます。たとえば、commentary は短い途中経過として再生または表示し、final_answer はアシスタントの回答が完成した段階で使用できます。

response.output[0].phase: "commentary"
response.output[1].phase: "final_answer"

12345678910111213141516171819202122232425{
  "type": "response.done",
  "response": {
    "output": [
      {
        "phase": "commentary",
        "content": [
          {
            "type": "output_audio",
            "transcript": "Let's zero in on the enzyme's shape and binding, since that's the key idea here."
          }
        ]
      },
      {
        "phase": "final_answer",
        "content": [
          {
            "type": "output_audio",
            "transcript": "What changes at the active site at high temperature?"
          }
        ]
      }
    ]
  }
}

不明瞭な音声への対応

モデルが行動に移すのは、音声の内容を確実に理解できた場合だけにします。音声が不明瞭な場合は、推測せず、短い質問で聞き返すようにします。

聞き取れなかった単語の推測、ツール呼び出し、識別情報の取得、処理前のひと言の生成は行わないようにしてください。ユーザーが何と言ったのかを再構成するために内部推論に時間をかけることも避けます。

## 不明瞭な音声

- 明瞭な音声またはテキストにだけ応答してください。
- ユーザーの音声が不明瞭なら、「Sorry, could you repeat that clearly?」などの短い英語の表現で聞き返してください。
- 音声が不明瞭なとき、同じ言い回しで 2 度聞き返さないでください。
- 内容が曖昧、雑音が多い、無音、聞き取り不能、一部が途切れている、またはユーザーの言葉を正確に聞き取れたか確信が持てない場合は、音声が不明瞭だと判断してください。
- 不明瞭な音声からユーザーの意図を推測しないでください。
- 音声が不明瞭な場合は推論しないでください。
- 音声が不明瞭な場合は、commentary チャネルで処理前のひと言を発したりツールを呼び出したりしないでください。

例：

ユーザーの音声：「注文を確認して。番号は 3、1……」［音声が途中で途切れる］

悪い例：

アシスタント：注文番号 31 を確認します。

良い例：

アシスタント：注文番号の一部しか聞き取れませんでした。もう一度、1 桁ずつお願いします。

識別情報の正確な聞き取り

多くのリアルタイムのワークフローでは、注文 ID、追跡番号、メールアドレス、確認コード、アカウント番号、請求案件番号、チケット ID、サポート受付番号、電話番号などの値を正確に取得する必要があります。

音声で正確に聞き取るのは簡単ではありません。ユーザーが早口で話したり、数字をさまざまな位置で区切ったり、一部だけを 1 文字ずつ読み上げたりするためです。つなぎ言葉を挟む、話の途中で訂正する、音の似た文字を発音するといったこともあります。1 桁の誤りでも、照会に失敗したり、別のアカウントを取得したりする可能性があります。

識別情報は慎重に聞き取ってください。値は 1 つずつ取得し、明確な部分だけを正規化します。正確さが求められる値はツールを呼び出す前に確認し、どの段階で訂正があっても対応できるようにします。

識別情報を 1 つずつ取得する手順

複数の値が必要なワークフローでは、1 つずつ聞き取ります。特に音声での会話では、別々の項目の値が混ざるのを防げます。

## 識別情報を聞き取る順序

必要な値を 1 つずつ聞き取ってください。

- 次に必要で、まだわかっていない値だけを尋ねてください。
- 1 回のターンで複数の値を尋ねないでください。
- 尋ねる前に、その会話やセッションですでにユーザーが値を伝えていないか確認してください。
- 該当しそうな値がすでにあれば、使う前にユーザーに確認してください。

例：

「先ほどの追跡番号 ABC-54321 があります。この番号でよろしいですか？ それとも別の追跡番号ですか？」

今扱っている値を聞き取り、検証し、ユーザーに確認するまではツールを呼び出さないでください。

1 文字ずつ読み上げられた値の処理

ユーザーが ID、コード、名前、メールアドレスを 1 文字ずつ読み上げる場合には、以下の指示を使用します。読み上げられた音声は入力であり、そのまま最終的な値になるわけではありません。

## 1 文字ずつ読み上げられた値

ユーザーが ID、コード、メールアドレスを 1 文字ずつ読み上げたら、文字をつなげて 1 つの値として扱ってください。ハイフン、ドット、アンダースコア、スラッシュ、プラスなど、明示的に読み上げた区切り記号は残してください。それ以外の空白や区切り記号は加えないでください。

例：

- 「エー、ビー、シー、いち、に、さん」 -> 「ABC123」
- 「ビー、シー、ハイフン、きゅう、はち、なな」 -> 「BC-987」
- 「ジェイ、オー、エイチ、エヌ、アットマーク、example、ドット、com」 -> 「john@example.com」

ユーザーが空白を含むと明言した場合を除き、読み上げられた文字の間に空白を入れないでください。

読み上げられた数字の正規化

数字の識別子を伝えるとき、ユーザーは 1 桁ずつ読むことも、数桁ずつまとめることも、数を普段どおりに読むこともあります。連続した数字を入力する項目では、明確に聞き取れた数を数字列に変換してください。

## 読み上げられた数字の処理

数字の識別子を聞き取るときは、読み上げられた数を数字列に変換してください。

例：

- 「いち、に、さん、よん」 -> 「1234」
- 「いち、にじゅうさん」 -> 「123」
- 「いち、じゅうきゅう」 -> 「119」
- 「きゅうじゅうきゅう、じゅういち」 -> 「9911」
- 「きゅうせんきゅうひゃくじゅういち」 -> 「9911」

複数の解釈が成り立つ場合は、値を使う前にユーザーに確認してください。

例：

「119 とも 1-19 とも聞こえました。もう一度、1 桁ずつお願いできますか？」

ツール呼び出し前の識別子の確認

注文 ID、追跡番号、アカウント番号、請求案件番号、確認コードなどの識別子には正確さが求められます。ツール呼び出しに使う前に確認してください。

数字の識別子は 1 桁ずつ復唱します。全体をひとまとまりの数として読むと、誤りに気づきにくくなります。

例：

アシスタント：確認します。8、3、5、2、1 で合っていますか？

ユーザーが 1 文字または 1 桁だけ訂正した場合でも、ツールを呼び出す前に訂正後の値をすべて復唱します。

例：

アシスタント：わかりました。8、3、5、7、1 で合っていますか？

## 正確さが求められる識別子の確認

正確さが求められる識別子を使ってツールを呼び出す前に、次の手順を守ってください。

- 正規化した最終的な値をユーザーに確認してください。
- 数字の識別子は 1 桁ずつ復唱してください。
- 推測した値、一部しかわからない値、曖昧な値は使わないでください。
- ユーザーが値を訂正したら、ツールを呼び出す前に訂正後の値をすべて復唱してください。

メールアドレスの 1 文字ずつの確認

メールアドレスは正確に聞き取る必要があります。ドット、ハイフン、アンダースコア、同じ文字の繰り返し、発音が似た名前などを聞き間違えると、アカウントが見つからなかったり、誤った宛先にメッセージを送ったりする可能性があります。

ユーザーにメールアドレスを 1 文字ずつ読み上げてもらいます。

アシスタント：正確に確認したいので、メールアドレスを 1 文字ずつ読み上げていただけますか？

復唱するときは、最終的なアドレスが正しいか確認します。

アシスタント：確認します。シー、エイチ、イー、エヌ、アットマーク、example、ドット、com で合っていますか？

## メールアドレスの確認

メールアドレスは正確に聞き取ってください。

ユーザーがメールアドレスを続けて読み上げた場合は、もう一度、1 文字ずつ読み上げるようにお願いしてください。

例：

「正確に確認したいので、メールアドレスを 1 文字ずつ読み上げていただけますか？」

復唱するときは、最終的なメールアドレスが正しいか確認してください。

例：

「確認します。シー、エイチ、イー、エヌ、アットマーク、example、ドット、com で合っていますか？」

識別情報を取得するワークフロー

## 識別情報を取得するワークフロー

正確な値が必要な場合は、その値を聞き取り、確認を済ませてからツール呼び出しに使ってください。

対象となる値には、注文 ID、追跡番号、確認コード、アカウント番号、請求案件番号、チケット ID、サポート受付番号、メールアドレス、電話番号などの識別子があります。

次の手順に従ってください。

1. 次に必要な値を聞き取ってください。

- 足りない値は 1 つずつ尋ねてください。
- 1 回のターンで複数の識別情報を尋ねないでください。
- 尋ねる前に、その会話やセッションですでに値が伝えられていないか確認してください。

2. 明確な部分だけを正規化してください。

- はっきり聞き取れた数字や 1 文字ずつ読み上げられた文字を、想定する形式に変換してください。
- ハイフン、ドット、アンダースコア、スラッシュ、プラスなど、明示された区切り記号は残してください。
- 不明瞭な文字を推測したり、文脈から推定したり、修正したり、補ったりしないでください。
- 複数の解釈が成り立つ場合は、もう一度言ってもらうか、不明な点を確認してください。

3. 最終的な値を確認してください。

- 正規化した値を使う前に復唱してください。
- 数字の識別子は 1 桁ずつ確認してください。
- メールアドレスは、正確さが求められる場合には 1 文字ずつ確認してください。
- ユーザーが明確に正しいと答えるまで待ってください。

4. 確認が取れてからツールを呼び出してください。

- 推測した値、不完全な値、曖昧な値、未確認の値を使って、照会、アカウント操作、メッセージ送信、支払い、予約、更新のツールを呼び出さないでください。

5. 訂正内容を安全に反映してください。

- ユーザーが値の一部でも訂正したら、値を更新し、訂正後の値をすべて復唱して再度確認を求めてください。
- 最終的な値の全体についてユーザーの確認が取れるまで、訂正後の値をツール呼び出しに使わないでください。

例：

ユーザー：注文 ID は ORD-3125B23 です。

アシスタント：確認します。オー、アール、ディー、ハイフン、3、1、2、5、ビー、2、3 で合っていますか？

ユーザー：83521 です。あ、4 桁目は 7 です。

アシスタント：わかりました。8、3、5、7、1 で合っていますか？

ユーザー：メールアドレスは chen@example.com です。

アシスタント：正確に確認したいので、そのメールアドレスを 1 文字ずつ読み上げていただけますか？

正確さが求められる項目について、推測した値、不完全な値、曖昧な値、未確認の値でツールを呼び出すことは決してしないでください。

指示の字面どおりの解釈による落とし穴

gpt-realtime-2 は、従来のリアルタイムモデルよりも指示を字面どおりに実行します。以前のモデルでうまく機能したプロンプトでも、調整が必要になることがあります。

指示には正確な表現を使ってください。モデルは、開発者が意図した動作全体よりも、指示の文言そのものを優先することがあります。範囲が広すぎるルールや厳格すぎるルールは、特に複数のルールが重なると、想定外の形でアシスタントの動作を左右します。

must、only、never、always など、強い制約を表す語は慎重に使ってください。単なる強調ではなく、その動作が本当に必須の場合に使います。強い制約を多用すると、アシスタントの対応が硬直化したり、慎重になりすぎたり、妥当な例外に対応できなくなったりします。

適用範囲を明確にした例：

ユーザーデータを変更する書き込み操作では、ツールを呼び出す前にユーザーに確認してください。

避けたい、適用範囲が広すぎる例：

何をする場合でも、必ず事前にユーザーに確認してください。

適用範囲が広すぎると、注文状況や空き状況の確認、アカウント情報の読み取りなど、リスクのない読み取り専用の照会でも不要な確認が発生することがあります。

指示を字面どおりに解釈する例

確認コードを伝えられたら、そのまま正確に復唱し、ユーザーが明確に「はい」と答えるまで待ってください。

確認コード、注文 ID、チケット ID、リセット用 PIN、請求案件番号、追跡番号、アカウント番号など、正確さが求められる識別子をユーザーが伝えた場合は、聞き取った値を復唱し、ユーザーの確認を待ってからツール呼び出しに使ってください。

プロンプト設計全般のポイント：

• 意図をくみ取らせるより、指示を明示してください。
• 厳密な動作が本当に必要な場合に限って、強い制約を表す語を使います。
• 矛盾する指示はできるだけ減らします。
• 優先順位に関する指示を重ねたり、競合させたりする場合は注意してください。
• プロンプトは段階的にテストしてください。わずかな表現の違いが動作を大きく変えることがあります。
• 従来のリアルタイムモデルから移行する際には、最良の結果を得るために構成の見直しが必要なプロンプトもあります。

言語とアクセントの個別制御

言語とアクセントは別々に制御してください。

ユーザーのアクセントだけでは、希望する応答言語はわかりません。ヒンディー語、スペイン語、フランス語、標準中国語のアクセントで英語を話すユーザーでも、英語での応答を期待していることがあります。

次のような大まかな言語の指示は避けてください。

ユーザーの話し方に合わせてください。
ユーザーの言語で自然に応答してください。
適宜、言語を切り替えてください。
地元の人らしく話してください。
ユーザーのアクセントに合わせてください。

これらの指示は適用範囲が広すぎます。モデルがアクセント、つなぎ言葉、相づち、単発の外国語の単語を、言語を切り替える理由として解釈する可能性があります。

英語で応答するための方針

## 言語

デフォルトの応答言語は英語です。

- アクセントだけで言語を推定しないでください。
- 言語を判定する際は、短いつなぎの音、相づち、単発の外国語の単語を無視してください。
- ユーザーが明示的に求めた場合か、別の言語でまとまった内容を話した場合にだけ、言語を切り替えてください。
- 言語を特定する自信がない場合は、推測せず、短い質問で確認してください。
- 処理前のひと言、話題をつなぐ言葉、ツールに関するメッセージ、最終回答には同じ言語を使ってください。
- アクセントを合わせる際も、応答言語は変えないでください。

多言語で応答するための方針

## 言語

ユーザーが明らかに別の言語を使用している場合を除き、英語で応答してください。

言語を切り替えるのは次の場合だけです。

- ユーザーが別の言語を使うよう明示的に求めた場合
- ユーザーが別の言語でまとまった内容を話した場合。これは、依頼、質問、訂正をひととおりその言語で伝えたことを指します。あいさつ、名前、住所、つなぎ言葉、借用表現だけの場合は該当しません。

次の特徴を理由に言語を切り替えないでください。

- アクセント
- 発音
- つなぎ言葉
- 短い相づち
- 名前
- 住所
- 単発の外国語の単語

判断に迷ったら、次のように尋ねてください。

「このまま英語で続けますか？ それとも [LANGUAGE] がよろしいですか？」

アクセントの制御

gpt-realtime-2 はアクセントの指示にもより忠実に従います。ただし、指示が曖昧だと、話すうちにアクセントが変わったり、意図せず言語が切り替わったりすることがあります。

アクセントを制御するプロンプトでは、次の点を明示すると効果的です。

• 目標とするアクセント
• 一貫して維持する特徴
• 意図する話す速さ、強勢、抑揚
• アクセントの調整を言語の選択に反映するかどうか

次のような指示ではなく、

オーストラリア人らしく話してください。

より具体的に指定します。

## アクセント

軽いオーストラリア訛りの英語で話してください。

- 最初の言葉から最後まで同じアクセントを保ってください。
- オーストラリア英語らしい自然な母音で発音しつつ、聞き取りやすさを保ってください。
- アクセントを誇張しないでください。
- ユーザーのアクセントを理由に応答言語を変えないでください。

カスタム音声

標準の音声ではブランド、アクセント、キャラクターの要件を安定して満たせない場合は、カスタム音声を使用してください。

プロンプトでアクセント、話す速さ、話し方を調整できますが、音声そのものの設計を完全に代替することはできません。ブランド固有の声を一貫して保つ必要がある場合や、特定のアクセントの忠実な再現が求められる場合は、カスタム音声を検討してください。

カスタム音声は承認を受けたお客様のみ利用できます。利用を希望する場合は、アカウント担当チームにお問い合わせください。

長時間セッションでの状態管理

gpt-realtime-2 では、リアルタイムのコンテキストウィンドウが 32k トークンから 128k トークンに拡大し、長時間のセッションに対応しやすくなりました。発話の密度が高い双方向の会話では、128k トークンはおおむね 1～2 時間分の未加工の音声コンテキストに相当します。実際の長さは、ツールの使用、内部推論、追加したレコードなど、セッションの内容によって異なります。

長いコンテキストを扱う場合、gpt-realtime-2 は、どの情報が現時点で有効か、どれが背景情報か、情報源が矛盾したときに何を無視すべきかを区別できると、最もよく機能します。会話の文字起こしや大量のコンテキストをそのまま渡し、情報源の優先順位をモデルに推測させず、情報を構造化してください。

取得したレコード、過去の会話履歴、ポリシー、要約、アカウントに関するメモ、背景資料など、大量のコンテキストを渡してセッションを開始する場合は、次のような構成を使用してください。

## コンテキスト

### 現在の状態

- **現在のタスク：** [current task]
- **最後に確認した状態：** [current value]
- **次に安全に実行できる手順：** [what the assistant should do next]

### 判断の根拠とする情報源

- **事実またはレコード：** [fact or record]
- **情報源：** [tool result / active policy / verified record]
- **状態：** 現在有効
- **取得時点：** [date/time or this turn]

### 過去の情報源または背景資料

- **過去の事実またはレコード：** [older fact or record]
- **情報源：** [prior conversation / older record / summary]
- **状態：** 古い情報または背景情報
- **注意：** 現在有効な情報源と矛盾する場合は、今回の判断に使わないでください。

### 関連するポリシーまたはルール

- [decision rule or constraint]

### その他のコンテキスト

- [potentially useful but non-authoritative background]

従来のリアルタイムモデルからの移行

従来のリアルタイムモデルから移行する場合は、プロンプトの文章を移植するだけでなく、その指示がモデルの動作をどう変えるかを考慮してください。

1. Codex または高性能なリーズニングモデルを使い、最新の Realtime プロンプト設計の指針に沿ってプロンプトを再構成します。推奨される方法に基づいて移行できるよう、このガイドへのリンクを含めてください。
2. デフォルト値を使わず、推論強度を low に設定します。より深い計画立案が必要なワークフローに限って強度を上げます。
3. ツール名、パラメーター、列挙値、JSON スキーマなどの設定を点検し、想定する実装と一致していることを確認します。
4. 古くなった例を削除します。正常に進む場合、依頼が曖昧な場合、割り込みが入った場合、ツールを呼び出す場合、代替手段を使う場合の短い例を追加します。
5. 代表的な会話を移行前後で比較します。既存の評価で性能や動作の後退がないか確認し、意図した動作変更を記録します。
6. 最後に全体の整合性を確認します。必須要件、デフォルトの動作、ツールのルール、安全上のルール、代替動作がプロンプトで明確に区別されていることを確認してください。
7. 評価を実行し、代表的な失敗を調べて、目標とする動作が安定するまでプロンプトを改善します。

Realtime 1.5 プロンプト設計ガイド

gpt-realtime-1.5 は Realtime API の音声変換モデルです。このモデルには、gpt-realtime 向けのプロンプト設計の指針をそのまま適用できます。

音声を AI の主要なインターフェースとして利用するうえで、音声変換システムは欠かせません。gpt-realtime-1.5 を使うと、重要な業務ワークフローを大規模に処理できる、堅牢で使いやすいリアルタイム音声エージェントを構築できます。

従来のリアルタイムのプレビューモデルと比べ、gpt-realtime-1.5 は指示により忠実に従い、ツール呼び出しの信頼性と音声品質も向上しています。会話の流れも全体に滑らかです。こうした改善により、複数の処理を順につなぐ方式から、直接リアルタイムでやり取りする方式へ移行しやすくなりました。レイテンシを抑えながら、より自然で表情豊かな応答を生成できます。

リアルタイムモデルには、テキストベースのモデルにはそのまま当てはまらないプロンプト設計の手法が有効です。このガイドでは、推奨するプロンプトの構成を示したうえで、各セクションの実践的なポイント、そのまま使える短いパターン、用途に合わせて変更できる例を紹介します。

設計全般のポイント

• 改善を繰り返す：わずかな表現の違いで、期待どおりに動作するかどうかが変わります。
  • 例：不明瞭な音声に関する指示を「音が聞こえない」から「内容が聞き取れない」に変えたところ、雑音を含む入力への対応が改善しました。
• 段落より箇条書きを使う：長い段落よりも、短く明確な箇条書きの方が効果的です。
• 例を示す：モデルは例文の言い回しによく従います。
• 指示を明確にする：GPT-5 と同様、曖昧な指示や矛盾する指示は性能の低下につながります。
• 応答言語を指定する：意図しない言語の切り替えが起きる場合は、出力を目的の言語に固定します。
• 繰り返しを減らす：表現に変化を付けるルールを追加し、機械的な言い回しを減らします。
• 大文字で強調する：英語の重要なルールを大文字で書くと目立ち、モデルが従いやすくなります。
• 記号によるルールを言葉で書く：「IF x > 3 THEN ESCALATE」ではなく、「IF MORE THAN THREE FAILURES THEN ESCALATE」のように、失敗が 3 回を超えたらエスカレーションすると言葉で明示します。

プロンプトの構成

プロンプトを整理すると、モデルがコンテキストを理解しやすくなり、ターンをまたいでも一貫して応答できます。問題のあるセクションを特定して改善する作業も容易になります。

• 設計方法：システムプロンプトを明確な見出し付きのセクションに分け、モデルが指示を見つけて従いやすくします。各セクションで扱う内容は 1 つに絞ります。
• 調整方法：コンプライアンスやブランドポリシーなど、分野固有のセクションを追加します。発音に問題がなければ発音ガイドを省くなど、不要なセクションは削除します。

例

# 役割と目標 — どのような役割を担い、何をもって成功とするか
# 人物像と口調 — 一貫して保つ声の調子と話し方
# コンテキスト — 取得した背景情報と関連情報
# 発音ガイド — 読み方が難しい単語の発音
# ツール — 名前、使用ルール、呼び出し前のひと言
# 指示とルール — 行うこと、避けること、進め方
# 会話フロー — 状態、目標、遷移
# 安全性とエスカレーション — 代替手段と引き継ぎの条件

役割と目標

このセクションでは、エージェントの役割と、何をもってタスク完了とするかを定義します。次の 2 つの例では異なる役柄を指定し、役割と目標が明確なときにモデルがどれだけ忠実に従うかを示します。

• 使用場面：モデルが想定した人物像、役割、タスクの範囲に沿って動作しない場合
• 効果：音声エージェントの役割を明確に定め、その設定に沿った応答を引き出します。
• 調整方法：用途に合わせて役割を変更します。

例（特定のアクセントで話すモデル）

# 役割と目標
あなたはケベックのフランス語で話すカスタマーサービスボットです。ユーザーの質問に答えてください。

従来のリアルタイムのプレビューモデル：

gpt-realtime-1.5：

例（キャラクターを演じるモデル）

# 役割と目標
あなたは元気いっぱいのクイズ番組の司会者です。電話で参加している人が 1 から 100 までの秘密の数を当て、賞金 100 万ドルを獲得できるように進行してください。

従来のリアルタイムのプレビューモデル：

gpt-realtime-1.5：

gpt-realtime-1.5 は、従来のリアルタイムのプレビューモデルよりも安定して、指定された役割を演じられます。

人物像と口調

gpt-realtime-1.5 は、特定の人物像や口調を再現する指示によく従います。用途に合わせて、音声でのやり取りや話し方を調整できます。

• 使用場面：応答が単調な場合、冗長な場合、ターンによって口調がぶれる場合
• 効果：声の調子、簡潔さ、話す速さを定めることで、自然で一貫性のある応答にします。
• 調整方法：親しみやすさや改まり具合、標準的な応答の長さを調整します。規制のある分野では、中立的で正確な表現を優先してください。用途に応じてサブセクションを追加します。

例

# 人物像と口調
## 人物像
- 親しみやすく、落ち着いていて相談しやすい、専門知識のあるカスタマーサービス担当者

## 口調
- 温かく、簡潔に、自信を持って話し、相手に迎合しないでください。

## 長さ
1 ターンにつき 2～3 文にしてください。

例（複数の感情の表現）

# 人物像と口調
- 最初はとてもうれしそうに話してください。
- 途中で悲しそうな口調に変えてください。
- 最後はひどく怒った口調に変えてください。

gpt-realtime-1.5：

モデルはこの複雑な指示に従い、1 回の音声応答の中で 3 つの感情を順に切り替えられます。

話す速さの指示

Realtime API の speed パラメーターは再生速度を変更しますが、モデルが音声を組み立てる方法は変えません。話し方そのものを速くするには、発話のペースに関する指示を追加してください。

• 使用場面：ユーザーが速い話し方を希望しており、speed パラメーターで再生速度を変えても、求める話し方にならない場合
• 効果：クライアントの再生速度とは独立して、発話の簡潔さやリズムを調整します。
• 調整方法：用途の要件に合わせて速さに関する指示を変更します。

例

# 人物像と口調
## 人物像
- 親しみやすく、落ち着いていて相談しやすい、専門知識のあるカスタマーサービス担当者

## 口調
- 温かく、簡潔に、自信を持って話し、相手に迎合しないでください。

## 長さ
- 1 ターンにつき 2～3 文にしてください。

## 話す速さ
- 音声での応答は速めに話し、せわしなく聞こえないようにしてください。
- 応答の内容は変えず、同じ内容を話す速さだけを上げてください。

従来のリアルタイムのプレビューモデル：

gpt-realtime-1.5：

話す速さを明示すると、gpt-realtime-1.5 は、せわしなく聞こえない範囲で発話をはっきりと速められます。

応答言語の制約

応答言語を制限すると、背景に雑音がある場合や複数の言語が入力される場合でも、モデルが意図した言語で一貫して応答できます。

• 使用場面：多言語環境や雑音の多い環境で、意図しない言語の切り替えを防ぎたい場合
• 効果：出力を選択した言語に固定し、誤って別の言語に切り替わるのを防ぎます。
• 調整方法：「英語」を目的の言語に置き換えるか、用途に応じてより細かな指示を追加します。

例（応答を 1 つの言語に固定）

# 人物像と口調
## 人物像
- 親しみやすく、落ち着いていて相談しやすい、専門知識のあるカスタマーサービス担当者

## 口調
- 温かく、簡潔に、自信を持って話し、相手に迎合しないでください。

## 長さ
- 1 ターンにつき 2～3 文にしてください。

## 言語
- 会話は英語のみで行ってください。
- ユーザーに頼まれても、ほかの言語で応答しないでください。
- ユーザーがほかの言語で話したら、対応言語は英語のみであることを丁寧に説明してください。

この指示を適用した gpt-realtime-1.5 の応答を示します。

例（モデルによる語学指導）

# 役割と目標
- あなたはフランス語学習者を音声で指導する、親しみやすく知識豊富な講師です。
- 楽しく会話を続けながら、わかりやすく説明し、ユーザーのフランス語を話す力と聞く力を伸ばしてください。
- フランス語に浸って練習する時間と英語での補足説明をうまく組み合わせ、理解と上達を支えてください。

# 人物像と口調
## 人物像
- 親しみやすく、落ち着いていて相談しやすい、専門知識のあるカスタマーサービス担当者

## 口調
- 温かく、簡潔に、自信を持って話し、相手に迎合しないでください。

## 長さ
- 1 ターンにつき 2～3 文にしてください。

## 言語
### 説明
文法、語彙、文化的背景を説明するときは英語を使ってください。

### 会話
練習、例示、対話はフランス語で行ってください。

この指示を適用した gpt-realtime-1.5 の応答を示します。

モデルは、独自の指示に従って言語を切り替えられます。

繰り返しの抑制

リアルタイムモデルは例文に忠実に従うため、ブランドらしい表現を維持できます。一方で、例文を使いすぎると、応答が機械的で単調に聞こえます。繰り返しに関するルールを加えると、明確さやブランドの口調を保ちながら、表現に変化を付けられます。

• 使用場面：複数のターンやセッションで、同じ切り出し方、つなぎ言葉、文型が繰り返される場合
• 効果：表現に変化を付けるルールを設けることで、必須用語を維持しつつ、同じ言い回しを避け、同義語や異なる文型の使用を促します。
• 調整方法：「同じ切り出し方は N ターンに 1 回まで」など、ルールの厳しさを調整します。法務、コンプライアンス、ブランド上の必須表現は例外として指定し、一貫性が重要な箇所では表現の幅を狭めます。

例

# 人物像と口調
## 人物像
- 親しみやすく、落ち着いていて相談しやすい、専門知識のあるカスタマーサービス担当者

## 口調
- 温かく、簡潔に、自信を持って話し、相手に迎合しないでください。

## 長さ
- 1 ターンにつき 2～3 文にしてください。

## 言語
- 会話は英語のみで行ってください。
- ユーザーに頼まれても、ほかの言語で応答しないでください。
- ユーザーがほかの言語で話したら、対応言語は英語のみであることを丁寧に説明してください。

## 表現の変化
- 同じ文を 2 度使わないでください。
- 機械的に聞こえないよう、応答の言い回しを変えてください。

この指示を適用する前の gpt-realtime-1.5 の応答です。モデルは毎回 Got it と同じ表現で応じています。

この指示を適用した後の gpt-realtime-1.5 の応答です。

応答や確認の言い回しに変化が生まれ、機械的に聞こえなくなりました。

発音ガイド

このセクションでは、音声でやり取りする際に、重要な単語、数字、名前、用語をモデルが正しく発音できるようにする方法を紹介します。

• 使用場面：ブランド名、専門用語、地名の発音をよく間違える場合
• 効果：発音の手がかりを与えることで、聞き取りやすくなり、信頼性も高まります。
• 調整方法：リストは短く保ち、発音の誤りに気づいたら更新します。

例

# 発音ガイド
次の単語を読み上げる際は、それぞれ指定した発音を使ってください。
- 「SQL」は「sequel」と発音してください。
- 「PostgreSQL」は「post-gress」と発音してください。
- 「Kyiv」は「KEE-iv」と発音してください。
- 「Huawei」は「HWAH-way」と発音してください。

従来のリアルタイムのプレビューモデル：

gpt-realtime-1.5：

発音ガイドの指示があると、gpt-realtime-1.5 は SQL を指定どおり「シークェル」と発音できます。

英数字の読み上げ

リアルタイムの音声変換（S2S）では、電話番号、クレジットカード番号、注文 ID などの重要な情報を復唱する際に、数字や文字が不明瞭になったり、つながって聞こえたりすることがあります。1 文字ずつ確認するよう明示すると、聞き間違いを防ぎ、合成音声も明瞭になります。

• 使用場面：電話番号、カード番号、2 要素認証コード、注文 ID、シリアル番号、住所、部屋番号、英数字が混在する文字列をモデルが正確に聞き取れない、または復唱できない場合
• 効果：モデルに 1 文字ずつ区切って発音させ、ユーザーに確認し、訂正があれば再確認させます。必要に応じて「Alpha の A」のような単語を添え、文字を聞き分けやすくします。

例（全般的な指示のセクション）

# 指示とルール
- 数字やコードを読み上げるときは、4-1-5 のようにハイフンで区切り、1 文字ずつ発音してください。
- 伝えられた番号をそのまま正確に復唱してください。1 桁も省略しないでください。

ヒント：会話フローに沿ってプロンプトを設計する場合は、どの会話状態で英数字の読み上げに関する指示を適用するかを指定できます。

例（特定の会話状態での指示）

（openai-realtime-agents のプロンプトで定義している会話フローから抜粋）

{
    "id": "3_get_and_verify_phone",
    "description": "電話番号を尋ね、復唱して確認します。",
    "instructions": [
      "ユーザーに電話番号を丁寧に尋ねてください。",
      "番号を教えてもらったら、1 桁ずつ復唱し、正しいか尋ねてください。",
      "訂正があったら、正しく聞き取れたか必ずもう一度確認してください。",
    ],
    "examples": [
      "アカウントを確認するため、もう少し情報をお伺いしてもよろしいですか？ お電話番号をお願いします。",
      "0-2-1-5-5-5-1-2-3-4 でよろしいですか？",
      "4-5-6-7-8-9-0-1-2-3 でよろしいですか？"
    ],
    "transitions": [{
      "next_step": "4_authentication_DOB",
      "condition": "電話番号の確認が取れた時点"
    }]
}

この指示を適用する前の gpt-realtime-1.5 の応答です。

はい、番号は 55119765423 です。ほかに必要なことがあればお知らせください！

この指示を適用した後の gpt-realtime-1.5 の応答です。

はい、番号は 5-5-1-1-1-9-7-6-5-4-2-3 です。ほかに必要なことがあればお知らせください！

指示の設計

このセクションでは、タスクの解決、推奨される手順の適用、起こり得る問題の修正について、モデルに指示を与える方法を紹介します。

良い結果を得るには、GPT-4.1 向けのプロンプト設計と同様のパターンをおすすめします。

指示への追従

GPT-4.1 や GPT-5 と同様に、指示が矛盾していたり、曖昧だったり、わかりにくかったりすると、gpt-realtime-1.5 の性能は低下します。

• 使用場面：出力がルールから外れる、手順の一部を飛ばす、ツールを誤用するといった場合
• 効果：リリース前に LLM を使って、曖昧な箇所、矛盾、定義の不足を特定します。

指示の品質を確認するプロンプト（ChatGPT または API で使用可能）

次のプロンプトを GPT-5 に渡すと、自分のプロンプトで修正すべき問題箇所を特定できます。

## 役割と目標
あなたは**プロンプトを評価する専門家**です。
ユーザーが提示した LLM 向けのプロンプトを検討し、以下の指示に従って問題点を指摘してください。


## 指示
LLM に実行させるためのプロンプトを読み、次の問題を特定してください。
- 曖昧さ：複数の解釈が成り立つ表現はありますか？
- 定義の不足：分類ラベル、用語、概念のうち、定義がなく LLM が誤解しそうなものはありますか？
- 指示の矛盾、不足、曖昧さ：不完全な指示や互いに矛盾する指示はありますか？
- 明示されていない前提：モデルにできるとは明記されていないことを、当然できるものとしていませんか？


## 以下は問題点に**含めないでください**
- 新たに考案した指示、ツール呼び出し、外部情報。追加すべきツールが不足しているかどうかは、与えられた情報だけでは判断できません。
- 問題であると確信が持てないもの


## 出力形式
"""
# 問題点
- 番号付きリストで示し、該当箇所を短く引用してください。

# 改善案
- 番号付きリストで、変更する行と具体的な修正文を示してください。

# 修正後のプロンプト
- すべての改善案を該当箇所に反映し、元のプロンプトへの変更は必要最小限にしてください。
"""

プロンプト最適化用のメタプロンプト（ChatGPT または API で使用可能）

このメタプロンプトは、特定の失敗パターンに絞って、基本となるシステムプロンプトを改善するためのものです。現在のプロンプトと実際に起きている問題を示すと、モデル（GPT-5）が、制約を明確にして問題を減らすための修正案を複数提示します。

現在 LLM に渡しているプロンプトは以下のとおりです。
[BEGIN OF CURRENT PROMPT]
{CURRENT_PROMPT}
[END OF CURRENT PROMPT]

このプロンプトを使うと、LLM の動作に次の問題が発生します。
[BEGIN OF ISSUE]
{ISSUE}
[END OF ISSUE]
モデルが制約を正しく理解し、この問題を減らせるように、プロンプトの修正案をいくつか示してください。

無音または不明瞭な音声

モデルは、何か聞こえたと判断して応答しようとすることがあります。音声やユーザーの入力が不明瞭なときにどう振る舞うべきか、独自の指示を追加できます。期待する動作は用途に合わせて調整してください。たとえば、聞き返す代わりに、モデルに直前の質問をもう一度言わせる方がよい場合もあります。

• 使用場面：背景の雑音、途切れた単語、無音によって不要な応答が発生する場合
• 効果：誤って応答するのを防ぎ、必要なときに自然に聞き返せるようにします。
• 調整方法：聞き返すか、直前の質問を繰り返すかを用途に応じて選びます。

例（せきと不明瞭な音声）

# 指示とルール
...


## 不明瞭な音声
- 内容を聞き取れない場合も、必ずユーザーが話している言語で応答してください。
- 明瞭な音声またはテキストにだけ応答してください。
- ユーザーの音声が不明瞭な場合（曖昧な入力、背景の雑音、無音、聞き取り不能など）、またはユーザーの発話を最後まで聞き取れなかったり理解できなかったりした場合は、{preferred_language} の表現で聞き返してください。

この指示を適用した後の gpt-realtime-1.5 の応答です。

この例では、私が（かなり）大きなせきをし、その後の音声も不明瞭だったため、モデルが聞き返しています。

背景音楽や効果音

音声を生成するとき、意図しない背景音楽、鼻歌、リズミカルな雑音、効果音のような音が混ざることがあります。こうした音は発話を聞き取りにくくし、ユーザーの注意をそらしたり、アシスタントの応対が専門的でないという印象を与えたりします。次の指示を使うと、こうした音の発生を防ぐか、大幅に減らせます。

• 使用場面：Realtime の音声応答に、意図しない音楽的な要素や効果音が含まれる場合
• 効果：不要な音を生成しないようモデルを誘導します。
• 調整方法：実際に発生している音のパターンを明示し、その音を抑えるよう指示を調整します。

例

# 指示とルール
...
- 応答に効果音や擬音語を一切含めないでください。

ツール

このセクションでは、関数やツールの使い方をモデルに指示します。ツールを呼び出す条件と呼び出さない条件、取得する引数、呼び出しの実行中に伝える内容、エラーや部分的な結果の扱い方を明記してください。

ツールの選択

gpt-realtime-1.5 は指示に忠実に従います。ただし、プロンプトに記載したツールがツール一覧に渡されていないなど、指示とモデルが実際に利用できる機能に食い違いがあると、不適切な応答につながります。

• 使用場面：プロンプトに実際には利用できないツールが記載されている場合
• 効果：利用可能なツールとシステムプロンプトを照合し、内容が一致していることを確認します。

例

# ツール
## lookup_account(email_or_phone)
...


## check_outage(address)
...

同じツールが実際に利用でき、それぞれの説明に矛盾がないことを確認してください。

1234567891011121314[
{
    "name": "lookup_account",
    "description": "メールアドレスまたは電話番号を使って顧客のアカウントを取得し、本人確認やアカウント固有の操作を可能にします。",
    "parameters": {
      ...
  },
{
    "name": "check_outage",
    "description": "指定されたサービス提供先住所に影響するネットワーク障害を調べ、状況と、該当する場合は復旧見込み時刻を返します。",
    "parameters": {
      ...
  }
]

ツール呼び出し前のひと言

用途によっては、Realtime モデルがツールを呼び出すのと同時に音声で応答すると効果的です。待ち時間を感じにくくなり、ユーザー体験が向上します。例文は用途に合わせて変更できます。

• 使用場面：ツールの呼び出しと同時に、対応を始めたことをユーザーに知らせ、待ち時間を感じにくくしたい場合
• 効果：ツール呼び出しの前に、短く一貫したひと言を加えます。

例

# ツール
- どのツールを呼び出す場合も、先に「今、確認します」のような短いひと言を伝え、すぐにツールを呼び出してください。

この指示を適用した gpt-realtime-1.5 の応答を示します。

この指示により、モデルはツールを呼び出すのと同時に「今すぐ確認します」と音声で応答します。

ツール呼び出し前のひと言と例文

ツールの呼び出しと同時にモデルが発話する内容を細かく調整したい場合は、ツール仕様の説明に例文を追加できます。

例

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40tools = [
    {
        "type": "function",
        "name": "lookup_account",
        "description": """Retrieve a customer account using either an email or phone number to enable verification and account-specific actions.

Preamble sample phrases:
- For security, I’ll pull up your account using the email on file.
- Let me look up your account by {email} now.
- I’m fetching the account linked to {phone} to verify access.
- One moment—I’m opening your account details.""",
        "parameters": {
            "type": "object",
            "properties": {
                "email": {"type": "string"},
                "phone": {"type": "string"},
            },
            "additionalProperties": False,
        },
    },
    {
        "type": "function",
        "name": "check_outage",
        "description": """Check for network outages affecting a given service address and return status and ETA if applicable.

Preamble sample phrases:
- I’ll check for any outages at {service_address} right now.
- Let me look up network status for your area.
- I’m checking whether there’s an active outage impacting your address.
- One sec—verifying service status and any posted ETA.""",
        "parameters": {
            "type": "object",
            "properties": {
                "service_address": {"type": "string"},
            },
            "required": ["service_address"],
            "additionalProperties": False,
        },
    },
]

確認なしのツール呼び出し

モデルがツールを呼び出す前にユーザーに確認を求めることがあります。用途によっては、モデルが自ら処理を進めず、そのつど確認を挟むことで、ユーザー体験が損なわれます。

• 使用場面：呼び出すべきツールが明らかなのに、エージェントが実行の許可を求める場合
• 効果：不要な確認のやり取りをなくします。

例

# ツール
- ツールの呼び出しにあたってユーザーに確認を求めないでください。必要なツールは自ら呼び出してください。

この指示を適用した後の gpt-realtime-1.5 の応答です。

この例では、リアルタイムモデルは応答音声を生成せず、該当するツールを直接呼び出しています。

ヒント：モデルが早すぎる段階でツールを呼び出す場合は、指示の表現を和らげてみてください。たとえば、「積極的に」のような強い表現を穏やかな言い回しに変えると、モデルが急いで呼び出さず、より落ち着いて対応しやすくなります。

ツール呼び出しの精度

用途が複雑になり、利用可能なツールが増えるほど、各ツールをいつ使うべきかと、いつ使うべきでないかの両方を明示することが重要になります。明確な使用ルールがあると、呼び出しの精度が高まるだけでなく、モデルが適切なタイミングで適切なツールを選びやすくなります。

• 使用場面：モデルのツール呼び出しの精度が低く、誤用を減らすために明確な指示が必要な場合
• 効果：各ツールを使う条件と避ける条件を指定します。「ツール A の後はツール B または C を呼び出せる」など、呼び出しの順序も指示できます。

例

# ツール
- どのツールを呼び出す場合も、呼び出しと同時に、そのツールを使うことをユーザーに必ず伝えてください。

## lookup_account(email_or_phone)
使用条件：本人確認を行う場合、またはプランや障害のフラグを確認する場合。
使用禁止：ユーザーが明らかに匿名で、一般的な質問しかしていない場合。


## check_outage(address)
使用条件：ユーザーから接続の問題や通信速度の低下について申告があった場合。
使用禁止：請求に関する質問のみの場合。


## refund_credit(account_id, minutes)
使用条件：過去 7 日間に 240 分を超える障害が確認されている場合。
使用禁止：障害が未確認の場合。まず診断に進み、check_outage を呼び出してください。


## schedule_technician(account_id, window)
使用条件：再起動後も繰り返し問題が発生し、障害の状態が false の場合。
使用禁止：障害の状態が true の場合。代わりに状況と復旧見込み時刻を伝えてください。


## escalate_to_human(account_id, reason)
使用条件：ユーザーに強い不満がうかがえる場合、暴言や嫌がらせがある場合、失敗が繰り返される場合、請求額をめぐる争いが 50 ドルを超える場合、またはユーザーが引き継ぎを希望する場合。

ヒント：ツール呼び出しが予期せず失敗することがある場合は、失敗時の対応を明確に指示し、モデルが状況に応じて自然に応答できるようにします。

ツールごとの動作

すべてのツールに共通のルールを適用する代わりに、個々のツールに合わせてモデルの動作を調整できます。たとえば、読み取りツールは積極的に呼び出し、書き込みツールには明示的な確認を必須とする設定が考えられます。

• 使用場面：積極的に実行するか、確認を求めるか、処理前にひと言添えるかについて、全体に共通する指示では対応できないツールがある場合
• 効果：ツールごとに、すぐに呼び出すか、先に確認するか、呼び出しの前にひと言添えるかを定めます。

例

# ツール
- PROACTIVE と記載したツールは、ユーザーに確認を求めず、処理前のひと言も添えずに呼び出してください。
- CONFIRMATION FIRST と記載したツールは、必ず先にユーザーに確認してください。
- PREAMBLES と記載したツールは、呼び出す前に「今、確認します」のような短いひと言を伝え、すぐに呼び出してください。


## lookup_account(email_or_phone) — PROACTIVE
使用条件：本人確認を行う場合、または請求情報にアクセスする場合。
使用禁止：本人確認を 2 回求めても、電話の相手が応じることを拒んだ場合。


## check_outage(address) — PREAMBLES
使用条件：接続できない、または通信速度が 10 Mbps 未満だと電話の相手が申告した場合。
使用禁止：問い合わせが請求に関するものだけの場合、または通信速度が 10 Mbps を超えている場合。
どちらかの使用禁止条件に該当したら、対応できないことをお客様に伝え、通話を終了してください。


## refund_credit(account_id, minutes) — CONFIRMATION FIRST
使用条件：過去 7 日間に 240 分を超える障害が確認されている場合（60 分相当のクレジットを付与）。
使用禁止：障害が未確認の場合。
確認の言葉：「この障害について、料金に充当できるクレジットをお付けできます。手続きを進めてもよろしいですか？」


## schedule_technician(account_id, window) — CONFIRMATION FIRST
使用条件：再起動と回線チェックの両方を行っても解決せず、outage=false の場合。
訪問時間帯：「10am–12pm ET」または「2pm–4pm ET」。
確認の言葉：「技術担当者の訪問を手配できます。予約してもよろしいですか？」


## escalate_to_human(account_id, reason) — PREAMBLES
使用条件：嫌がらせ、脅迫、自傷、繰り返す失敗、50 ドルを超える請求をめぐる争いがある場合、電話の相手が不満を感じている場合、または引き継ぎを希望する場合。
処理前のひと言：「詳しく対応できる上席の担当者におつなぎします。」

ツール出力の形式

ツールの出力の中には、モデルが学習時に見慣れた形式から外れるものがあります。特に、長い文字列を一字一句変えずに復唱する必要がある場合に問題になります。学習時のツール出力は、名前付きフィールドを持つ JSON オブジェクトの形を取るのが一般的です。ツールが文字列をそのまま返し、別途「正確に復唱する」ようモデルに指示すると、言い換えや省略が生じたり、モデル自身の前置きが混ざったりしやすくなります。

実用的な対策は、ツール出力を一般的なツール結果と同じ形式に整え、そのまま復唱する要件を機械が判別できる形で明示することです。

• 使用場面： ツールが長いコンテンツや複雑な構造を持つコンテンツ（複数文の指示、引き継ぎ情報一式、ID やリンク、ポリシーの要約、複数ステップの手順など）を返し、内容の省略、言い換え、フィールドの欠落、順序の入れ替わり、モデル独自の前置きやコメントの混入が見られる場合

• 効果： ツール出力を小さく明示的な JSON オブジェクトに格納します。たとえば、response_text に加え、require_repeat_verbatim、format、content_type などのフラグやフィールドを含めます。これにより、結果がモデルが学習時に見慣れた形式に近づき、どのように応答に反映するかを機械が判断しやすくなります。

• 調整方法： スキーマは最小限にとどめ、安定した構成を維持します。想定する出力形式をツールの使用指示とツール定義の両方に明記してください。たとえば、「require_repeat_verbatim が true の場合、response_text だけを一字一句変えずに出力する」や「response_text をそのまま表示し、ツール出力のフィールドを追加、省略、並べ替えしない」と指定します。

例

例：文字列をそのまま返す場合（誤りが生じやすい形式）

ツールの戻り値：

I just sent you an email with the verification link. Please open it and click “Confirm”.

モデルの応答で見られる問題：

• 「確認用のリンクをメールでお送りしました……」と言い換える

• 最後の文を省略する

• 「ほかにお手伝いできることはありますか？」など、余分なコメントを加える

例：JSON に格納する場合（学習時の形式に近く、信頼性が高い形式）

ツールの戻り値：

1234{
  "response_text": "I just sent you an email with the verification link. Please open it and click “Confirm”.",
  "require_repeat_verbatim": true
}

一般的なツール結果（JSON オブジェクト）と同じ形式なので、モデルは通常、次のことを行いやすくなります。

• どの内容を正として扱うかを特定する（response_text）

• 応答に反映する際の制約を理解する（require_repeat_verbatim）

• 省略や余分なコメントを加えずにツール出力を再現する

スーパーバイザーツールの応答の言い換え（応答と推論を分担する構成）

多くの音声システムでは、リアルタイムモデルがユーザーと話す応答役を担い、より高性能なテキストモデルが推論役として計画立案、ポリシーの照会、標準作業手順の遂行を担当します。テキストの回答がそのまま発話に適しているとは限らないため、応答役は、推論役の文章を耳で聞いてわかりやすい応答に言い換えてから音声を生成します。

• 使用場面：推論役から回答を受け取った後、応答役の発話が機械的、長すぎる、または不自然に聞こえる場合
• 効果：推論役の文章を、短く自然な話し言葉に言い換えるよう、応答役に明確に指示します。
• 調整方法：用途に合わせて、言い回し、話の切り出し方、応答の長さの上限を調整します。

例

# ツール
## スーパーバイザーツール
名前：getNextResponseFromSupervisor(relevantContextFromLastUserMessage: string)


呼び出す場合：
- 許可リストにない依頼すべて
- 事実、ポリシー、アカウント、手続きに関する質問すべて
- 内部情報の照会やシステムの変更が必要になり得る操作すべて


呼び出さない場合：
- 簡単なあいさつや日常の雑談
- 復唱や説明を求められたとき
- 後でスーパーバイザーが使用するパラメーターを聞き取っているとき：
  - アカウントに関するサポート用の phone_number（getUserAccountInfo）
  - 店舗を検索するための zip_code（findNearestStore）
  - ポリシーを検索するためのトピックまたはキーワード（lookupPolicyDocument）


使用ルールと処理前のひと言：
1) 中立的なつなぎのひと言を伝えてから、すぐにツールを呼び出してください。使用できる表現は「少々お待ちください」「確認します」「ちょっとお待ちください」「少しお時間をください」「見てみます」「お調べします」です。成功や失敗を示唆しないでください。
2) つなぎのひと言で「スーパーバイザー」に言及しないでください。
3) relevantContextFromLastUserMessage には直近のユーザーメッセージの要点を 1 行で記述してください。特筆すべき点がなければ空文字列を使ってください。
4) ツールから結果が返ったら、以下の「スーパーバイザーの応答の言い換え」を適用して返答してください。


### スーパーバイザーの応答の言い換え
- 自分が何をしたかが伝わる自然で短い言葉で切り出し、そのまま回答につなげてください（例：「お待たせしました」「今、確認しました」「情報を呼び出しました」）。
- 簡潔に、最長 2 文に収めてください。
- 「切り出しの言葉＋ 1 文での要点＋最大 3 つの重要な詳細＋短い確認または選択肢」の形を使ってください（例：「ご認識と合っていますか？」「ほかの選択肢も確認しましょうか？」）。
- 数字は聞き取りやすく読み上げてください。金額は自然に（「$45.20」→「四十五ドル二十セント」）、電話番号は 3 桁、3 桁、4 桁に区切り、住所の数字は 1 桁ずつ、日付や時刻は日常の言い方で（「八月十二日」「午後三時半」）読み上げてください。

言い換えの指示がない場合の例：

アシスタント：現在のクレジットカード残高はプラス 32,323,232 豪ドルです。

同じ例に言い換えの指示を適用した場合：

アシスタント：確認できました。クレジットカードには、お客様の預け入れ分として三千二百三十二万三千二百三十二ドルの残高があります。前回のお支払いは八月一日に処理されていますが、ご認識と合っていますか？

よく使うツール

gpt-realtime-1.5 は、以下の一般的なツールを効果的に使用できるように学習しています。同様の動作が必要な場合は、ツール名、シグネチャ、説明をこれらの例に近づけると、学習時のパターンに沿った形になり、信頼性を最大限に高められます。

モデルが学習した代表的なツールのうち、特に重要なものを以下に示します。

例

# answer(question: string)
説明：お客様から、自分では答えがわからない質問をされたとき、または操作の実行を依頼されたときに呼び出してください。


# escalate_to_human()
説明：お客様がエスカレーションや別の担当者との通話を希望したとき、またはこの通話への不満を示したときに呼び出してください。


# finish_session()
説明：お客様が用件は済んだと伝えたとき、またはこれ以上続けたくないと伝えたときに呼び出してください。意思が曖昧な場合は、呼び出す前にお客様に確認してください。

会話フロー

このセクションでは、モデルが各ステップで何をすべきかを把握できるように、会話を明確な目標のあるフェーズに分ける方法を紹介します。各フェーズの目的、進め方、次のフェーズに移るための具体的な終了条件を定義します。こうすると、会話が行き詰まったり、手順を飛ばしたり、先走ったりすることを防ぎ、あいさつから解決まで順序立てて進められます。

プロンプトを会話状態ごとに整理すると、失敗が起きるパターンも特定しやすくなり、効率よく改善できます。

• 使用場面：会話が整理されていない場合、目標に達する前に行き詰まる場合、モデルが目標を達成するのに苦労している場合
• 効果：やり取りを、目標、指示、終了条件が明確なフェーズに分けます。
• 調整方法：ワークフローに合わせてフェーズ名を変更し、意図する動作に合わせて各フェーズの指示を調整します。終了条件は具体的かつ必要最小限にします。

例

# 会話フロー
## 1) あいさつ
目標：会話の雰囲気を整え、電話の用件を尋ねます。
応答の手順：
- NorthLoop Internet Support と名乗ってください。
- あいさつは短くし、何を希望しているか尋ねてください。
- Northloop のお客様であることを確認してください。
用件の聞き取りに進む条件：電話の相手が Northloop の顧客であることを伝え、最初の目的または症状を説明した時点。


## 2) 用件の聞き取り
目標：問題を分類し、必要最小限の情報を取得します。
応答の手順：
- 的を絞った質問を 1 つして、請求と接続のどちらに関する問題かを把握してください。
- 接続の場合は、サービス提供先の住所を尋ねてください。
- 請求やアカウントに関する場合は、登録済みのメールアドレスまたは電話番号を尋ねてください。
終了条件：用件と、接続の場合は住所、請求の場合はメールアドレスまたは電話番号がわかった時点。


## 3) 本人確認
目標：本人確認を行い、アカウントを取得します。
応答の手順：
- メールアドレスまたは電話番号がわかったら、lookup_account(email_or_phone) を呼び出してください。
- 照会に失敗したら、もう一方の識別子で 1 回だけ試してください。それでも失敗したら一般的な案内を続け、アカウント操作が必要ならエスカレーションを提案してください。
終了条件：アカウント ID が返された時点。


## 4) 診断
目標：サービス側の障害か、お客様側の問題かを判別します。
応答の手順：
- 接続の問題なら、check_outage(address) を呼び出してください。
- outage=true なら、お客様側での確認を省き、障害情報を引き継いで「解決」に進んでください。
- outage=false なら、再起動と配線の簡単な確認を案内してください。各手順の結果を確認してから次に進んでください。
終了条件：根本原因がわかった時点。


## 5) 解決
目標：問題の修正、クレジットの付与、訪問予約のいずれかを行います。
応答の手順：
- 過去 7 日間に 240 分を超える障害が確認されている場合は、refund_credit(account_id, 60) を呼び出してください。
- outage=false で基本的な確認の後も問題が続く場合は、「10am–12pm ET」または「2pm–4pm ET」を提案し、schedule_technician(account_id, chosen window) を呼び出してください。
- お客様側の対応で解決したら、結果と次の手順を短く伝えてください。
終了条件：修正、クレジットの付与、訪問予約のいずれかが完了し、電話の相手が結果を確認した時点。


## 6) 確認と終了
目標：結果を確認し、通話を終えます。
応答の手順：
- 結果と次の見通し（接続が安定するまでの時間、技術担当者の到着見込みなど）を改めて伝えてください。
- 最後に質問がないか尋ね、なければ丁寧に通話を終えてください。
終了条件：電話の相手がこれ以上のサポートは不要だと伝えた時点。

例文

例文は、モデルが応答を組み立てる際の手本になります。応答を 1 つの決まった形に固定せず、求める文体、簡潔さ、口調を示せます。

• 使用場面：応答にブランドらしさが出ない場合や、一貫性に欠ける場合
• 効果：モデルが自然で短い応答を作るために、言い回しを変えて使える例文を示します。
• 調整方法：例文をブランドに合ったものに差し替えます。「毎回同じ例文を使わない」という注意は残してください。

例

# 例文
- 以下の例文を参考にしてください。毎回これらの例文を使わず、応答の言い回しを変えてください。

受け答え：「承知しました」「少々お待ちください」「いい質問ですね」
確認：「A と B のどちらがよろしいですか？」「期限はいつですか？」
話をつなぐ言葉：「簡単に手順をご説明します」「シンプルに進めましょう」
気持ちに寄り添う短い言葉：「それはお困りですね。一緒に解決しましょう」
締めくくり：「最後にほかにご用件はありますか？」「またいつでもご相談ください」

注：音声システムが毎回例文を繰り返すだけで機械的に聞こえる場合は、表現に変化を付けるルールを追加してみてください。これで問題が解消した例があります。

会話フローと例文の組み合わせ

会話フローの各状態に例文を追加すると、その場面でどのような応答が適切かをモデルに示せます。

例

# 会話フロー
## 1) あいさつ
目標：会話の雰囲気を整え、電話の用件を尋ねます。
応答の手順：
- NorthLoop Internet Support と名乗ってください。
- あいさつは短くし、何を希望しているか尋ねてください。
例文（毎回同じ表現を繰り返さず、言い回しを変えてください）：
- 「NorthLoop Internet にお電話いただきありがとうございます。本日はどのようなご用件ですか？」
- 「NorthLoop サポートです。サービスのご利用で何かお困りですか？」
- 「こんにちは。どのようなお手伝いをご希望ですか？」
終了条件：電話の相手が最初の目的または症状を説明した時点。


## 2) 用件の聞き取り
目標：問題を分類し、必要最小限の情報を取得します。
応答の手順：
- 的を絞った質問を 1 つして、請求と接続のどちらに関する問題かを把握してください。
- 接続の場合は、サービス提供先の住所を尋ねてください。
- 請求やアカウントに関する場合は、登録済みのメールアドレスまたは電話番号を尋ねてください。
例文（毎回同じ表現を繰り返さず、言い回しを変えてください）：
- 「料金についてですか？ それとも回線速度についてですか？」
- 「回線をお使いのご住所を教えていただけますか？」
- 「アカウントにご登録のメールアドレスか電話番号をお願いします。」
終了条件：用件と、接続の場合は住所、請求の場合はメールアドレスまたは電話番号がわかった時点。


## 3) 本人確認
目標：本人確認を行い、アカウントを取得します。
応答の手順：
- メールアドレスまたは電話番号がわかったら、lookup_account(email_or_phone) を呼び出してください。
- 照会に失敗したら、もう一方の識別子で 1 回だけ試してください。それでも失敗したら一般的な案内を続け、アカウント操作が必要ならエスカレーションを提案してください。
例文：
- 「ありがとうございます。今、アカウントをお調べします。」
- 「こちらで見つからない場合は、ご登録のもう一方の連絡先でお調べします。メールアドレスか電話番号を教えていただけますか？」
- 「アカウントが見つかりました。こちらで対応します。」
終了条件：アカウント ID が返された時点。


## 4) 診断
目標：サービス側の障害か、お客様側の問題かを判別します。
応答の手順：
- 接続の問題なら、check_outage(address) を呼び出してください。
- outage=true なら、お客様側での確認を省き、障害情報を引き継いで「解決」に進んでください。
- outage=false なら、再起動と配線の簡単な確認を案内してください。各手順の結果を確認してから次に進んでください。
例文（毎回同じ表現を繰り返さず、言い回しを変えてください）：
- 「お住まいの地域で障害が起きていないか、すぐに確認します。」
- 「障害の報告はありません。まずはモデムを再起動してみましょう。」
- 「モデムのランプをご覧ください。インターネットのランプは点灯していますか？ それとも点滅していますか？」
終了条件：根本原因がわかった時点。


## 5) 解決
目標：問題の修正、クレジットの付与、訪問予約のいずれかを行います。
応答の手順：
- 過去 7 日間に 240 分を超える障害が確認されている場合は、refund_credit(account_id, 60) を呼び出してください。
- outage=false で基本的な確認の後も問題が続く場合は、「10am–12pm ET」または「2pm–4pm ET」を提案し、schedule_technician(account_id, chosen window) を呼び出してください。
- お客様側の対応で解決したら、結果と次の手順を短く伝えてください。
例文（毎回同じ表現を繰り返さず、言い回しを変えてください）：
- 「長時間の障害が確認できました。今、60 分相当のクレジットを料金に充当します。」
- 「障害はありませんので、技術担当者の訪問を手配しましょう。東部時間の午前 10 時から正午、または午後 2 時から 4 時でご予約いただけます。」
- 「クレジットを適用しました。次回のご請求に反映されます。」
終了条件：修正、クレジットの付与、訪問予約のいずれかが完了し、電話の相手が結果を確認した時点。


## 6) 確認と終了
目標：結果を確認し、通話を終えます。
応答の手順：
- 結果と次の見通し（接続が安定するまでの時間、技術担当者の到着見込みなど）を改めて伝えてください。
- 最後に質問がないか尋ね、なければ丁寧に通話を終えてください。
例文（毎回同じ表現を繰り返さず、言い回しを変えてください）：
- 「お手続きは完了しました。[credit applied / appointment booked / service restored]」
- 「数分以内に回線速度が安定する見込みです。」
- 「技術担当者の訪問時間帯は、東部時間の午前 10 時から正午です。」
終了条件：電話の相手がこれ以上のサポートは不要だと伝えた時点。

高度な会話フロー

用途が複雑になるにつれて、モデルの性能を保ちながら拡張できる構成が必要になります。保守のしやすさと簡潔さのバランスを取ってください。厳密に定義した状態が多すぎると、モデルの負担が増し、性能が低下して、会話も機械的になります。

モデルが一度に扱う複雑さを減らすようにフローを設計すると効果的です。状態を構造化しつつ柔軟に扱うことで、モデルがその場のタスクに集中して応答しやすくなり、ユーザー体験が向上します。

複雑なシナリオを扱う代表的なパターンは次の 2 つです。

1. ステートマシンによる会話フロー
2. session.updates を使った動的な会話フロー

ステートマシンによる会話フロー

会話の状態と遷移を JSON 構造で定義します。こうすると、どの場面をカバーできているかを検討し、例外的なケースを特定し、変更履歴を追いやすくなります。コードとして保存するため、フローの変化に合わせてバージョン管理、差分の確認、拡張ができます。ステートマシンでは、会話がどのような条件で、いつ次の状態に移るかを細かく制御できます。

例

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354# 会話の状態
[
  {
    "id": "1_greeting",
    "description": "会話の最初に親しみやすく温かい言葉であいさつし、サービス名を名乗って、ご用件を尋ねます。",
    "instructions": [
        "会社名「Snowy Peak Boards」を使い、温かくあいさつしてください。",
        "個別のアカウントに関するサポートには本人確認のための情報が必要なことを、あらかじめ伝えてください。"
    ],
    "examples": [
      "こんにちは、Snowy Peak Boards です。お問い合わせありがとうございます。本日はどのようなご用件ですか？"
    ],
    "transitions": [{
      "next_step": "2_get_first_name",
      "condition": "あいさつが終わった時点。"
    }, {
      "next_step": "3_get_and_verify_phone",
      "condition": "ユーザーが下の名前を伝えた場合。"
    }]
  },
  {
    "id": "2_get_first_name",
    "description": "ユーザーの名前（下の名前のみ）を尋ねます。",
    "instructions": [
      "「下のお名前をお伺いしてもよろしいですか？」と丁寧に尋ねてください。",
      "名前の確認や、つづりの復唱はせず、そのまま受け取ってください。"
    ],
    "examples": [
      "下のお名前をお伺いしてもよろしいですか？"
    ],
    "transitions": [{
      "next_step": "3_get_and_verify_phone",
      "condition": "名前を聞き取った時点、またはすでに名前が伝えられている場合。"
    }]
  },
  {
    "id": "3_get_and_verify_phone",
    "description": "電話番号を尋ね、復唱して確認します。",
    "instructions": [
      "ユーザーに電話番号を丁寧に尋ねてください。",
      "番号を教えてもらったら、1 桁ずつ復唱し、正しいか尋ねてください。",
      "訂正があったら、正しく聞き取れたか必ずもう一度確認してください。",
    ],
    "examples": [
      "アカウントを確認するため、もう少し情報をお伺いしてもよろしいですか？ お電話番号をお願いします。",
      "0-2-1-5-5-5-1-2-3-4 でよろしいですか？",
      "4-5-6-7-8-9-0-1-2-3 でよろしいですか？"
    ],
    "transitions": [{
      "next_step": "4_authentication_DOB",
      "condition": "電話番号の確認が取れた時点"
    }]
  },
...

動的な会話フロー

このパターンでは、現在の状態に応じてシステムプロンプトとツール一覧を更新し、会話をリアルタイムで調整します。すべてのルールとツールを一度にモデルに渡すのではなく、現在の会話フェーズに関係するものだけを提供します。

ある状態の終了条件を満たしたら、session.update を使って次の状態に移り、プロンプトとツールを次のフェーズで必要なものに置き換えます。

これによりモデルの処理負担が減り、不要なコンテキストに気を取られずに複雑なタスクを進めやすくなります。

例

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94from typing import Literal

State = Literal["verify", "resolve"]

# Allowed transitions
TRANSITIONS: dict[State, list[State]] = {
    "verify": ["resolve"],
    "resolve": [],  # terminal
}


def build_state_change_tool(current: State) -> dict:
    allowed = TRANSITIONS[current]
    readable = ", ".join(allowed) if allowed else "no further states (terminal)"
    return {
        "type": "function",
        "name": "set_conversation_state",
        "description": (
            f"Switch the conversation phase. Current: '{current}'. "
            f"You may switch only to: {readable}. "
            "Call this AFTER exit criteria are satisfied."
        ),
        "parameters": {
            "type": "object",
            "properties": {"next_state": {"type": "string", "enum": allowed}},
            "required": ["next_state"],
        },
    }


# Minimal business tools per state
TOOLS_BY_STATE: dict[State, list[dict]] = {
    "verify": [
        {
            "type": "function",
            "name": "lookup_account",
            "description": "Fetch account by email or phone.",
            "parameters": {
                "type": "object",
                "properties": {"email_or_phone": {"type": "string"}},
                "required": ["email_or_phone"],
            },
        }
    ],
    "resolve": [
        {
            "type": "function",
            "name": "schedule_technician",
            "description": "Book a technician visit.",
            "parameters": {
                "type": "object",
                "properties": {
                    "account_id": {"type": "string"},
                    "window": {"type": "string", "enum": ["10-12 ET", "14-16 ET"]},
                },
                "required": ["account_id", "window"],
            },
        }
    ],
}

# Short, phase-specific instructions
INSTRUCTIONS_BY_STATE: dict[State, str] = {
    "verify": (
        "# Role & Objective\n"
        "Verify identity to access the account.\n\n"
        "# Conversation (Verify)\n"
        "- Ask for the email or phone on the account.\n"
        "- Read back digits one-by-one (e.g., '4-1-5… Is that correct?').\n"
        "Exit when: Account ID is returned.\n"
        'When exit is satisfied: call set_conversation_state(next_state="resolve").'
    ),
    "resolve": (
        "# Role & Objective\n"
        "Apply a fix by booking a technician.\n\n"
        "# Conversation (Resolve)\n"
        "- Offer two windows: '10–12 ET' or '2–4 ET'.\n"
        "- Book the chosen window.\n"
        "Exit when: Appointment is confirmed.\n"
        "When exit is satisfied: end the call politely."
    ),
}


def build_session_update(state: State) -> dict:
    """Return the JSON payload for a Realtime `session.update` event."""
    return {
        "type": "session.update",
        "session": {
            "type": "realtime",
            "instructions": INSTRUCTIONS_BY_STATE[state],
            "tools": TOOLS_BY_STATE[state] + [build_state_change_tool(state)],
        },
    }

安全性とエスカレーション

Realtime 音声エージェントでは、人間の担当者に確実に引き継ぐ手段が重要になることがよくあります。このセクションでは、どのような場合にエスカレーションするかを、用途に合わせて調整してください。

• 使用場面：人間の担当者や代替システムに引き継ぐタイミングを、モデルが適切に判断できない場合
• 効果：迅速で確実なエスカレーションの条件と、その際にユーザーに伝える内容を定義します。
• 調整方法：用途に合わせたしきい値と、モデルが伝えるべき言葉を指定します。

例

# 安全性とエスカレーション
以下の場合は、追加のトラブルシューティングをせずにエスカレーションしてください。
- 安全上のリスクがある場合（自傷、脅迫、嫌がらせ）
- ユーザーが人間の担当者を明示的に希望した場合
- 強い不満が表れている場合（「本当に腹が立つ」などの発言、繰り返される苦情、暴言など）
- 同じタスクでツール呼び出しに **2** 回失敗した場合、**または**一致なし／入力なしが **3** 回連続した場合
- 対応範囲外または制限対象の場合（速報ニュース、金融・法律・医療に関する助言など）

escalate_to_human ツールを呼び出すのと同時に伝える言葉（必須）：
- 「お待ちいただきありがとうございます。ただいま専門の担当者におつなぎします。」
- 続けて `escalate_to_human` を呼び出してください。

エスカレーションが必要な発言の例：
- 「リセットしても直らないのはこれで 3 回目です。もう担当者に代わってください。」
- 「本当に腹が立ちます！」

最初の例は、この指示を適用した gpt-4o-realtime-preview-2025-06-03 の会話での応答です。

次の例は、この指示を適用した gpt-realtime-1.5 の会話での応答です。

gpt-realtime-1.5 は指示に従い、より確実に人間の担当者に引き継ぐことができます。