For the complete documentation index, see llms.txt. Markdown versions of documentation pages are available by appending .md to the page URL.
メインナビゲーション

おすすめ

GPT-Live

Realtime API

音声を活用した開発

接続

音声処理

API Dashboard
ChatGPT を試す

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

Realtime 音声モデル向けのプロンプトを設計し、テストします。

開発に使用する Realtime モデルを選択してください。GPT-Live を使用する場合は、GPT-Live のプロンプト設計を参照してください。

gpt-realtime-2 は、低レイテンシの音声変換アプリケーション向けに提供する、推論機能を備えた最先端の音声モデルです。発話前に思考でき、従来のリアルタイムモデルよりも確実に指示に従い、より大きなコンテキストウィンドウを使用し、より高い精度でツールを呼び出せます。

これらの改善を活かすには、意図をより明確にしたプロンプトを設計します。アシスタントの責務、判断が必要な場面、ツール呼び出しの動作、ガードレールを明示し、何を、いつ行い、何を避けるべきかを定義してください。

シンプルに始めましょう。最初からプロンプトに指示を詰め込みすぎないでください。最小限のプロンプトで評価を実施し、テストで期待どおりに動作しなかった点についてのみ指示を追加します。

モデルの選び方

モデル 適した用途 プロンプトで重視する点
gpt-realtime-2

リアルタイムでの推論、ツールの使用、指示への追従に最高の性能が必要な場合。

推論強度、前置き、ツールの使用ポリシー、エンティティの正確な取得、長時間セッションの状態管理を調整します。

gpt-realtime-1.5推論を行わない、高速で信頼性の高い音声変換モデルが必要な場合。

基本的なリアルタイムのプロンプト構成に従い、レイテンシが重要となる動作をテストしてください。

Realtime 2.0 プロンプトガイド

音声エージェントに、より高度な推論、ツールの選択、 エンティティの正確な処理、長時間セッションの状態管理が必要な場合は、gpt-realtime-2 を使用します。 reasoning.effort: "low" から始め、前置きのデフォルトの動作をテストし、 書き込み操作の前に確認が必要となる条件を明確に定義してください。

Realtime 2 の変更点

Realtime 2 には、単純な音声ボットとしてではなく、推論を行う音声エージェントとしてプロンプトを作成してください。

変更点プロンプト設計への影響
推論複雑なタスクでは、発話やツール呼び出しの前にモデルが内部で推論できるようにします。前置きを使い、気まずい沈黙や不要なつなぎ言葉を避けてください。
プロンプトの正確さがより重要に「役に立つように」といった漠然とした指示を、実行条件、行動、例外を明確にしたルールに置き換えます。いつ行動し、何を行い、どのような場合には行わないかを指定してください。
指示の矛盾による悪影響が増大always、never、only、must を使ったルールが重複している場合、本当に必要なもの以外は削除します。ルールが競合する場合は、優先順位を定義してください。
ツールの動作をより細かく制御可能にアシスタントが即座に行動する場合、不足情報を尋ねる場合、高い精度が求められる詳細を確認する場合、失敗後に再試行する場合、エスカレーションする場合の条件を指定します。
前置きが主要な動作の一つにモデルは、時間のかかる推論や一連のツール操作の前に、短い状況説明を話すことがあります。前置きを入れるタイミング、長さ、省略する条件を指定してください。
コンテキストウィンドウの拡大gpt-realtime-2 では、リアルタイムのコンテキストウィンドウが 32k トークンから 128k トークンに拡大し、長時間のセッションや大きなシステムプロンプトにより適しています。

前置きは、非公開の思考の連鎖ではありません。「その注文を今から確認します」といった、音声による短い状況説明です。モデルに非公開の推論を開示するよう求めないでください。

推奨するプロンプト構造

見出しを付けた短いセクションに分けます。モデルが関連する指示をすぐに見つけられるようにしてください。

# Role and Objective

# Personality and Tone

# Language

# Reasoning

# Message Channels

# Preambles

# Verbosity

# Tools

# Unclear Audio

# Entity Capture

# Long Context Behavior

# Escalation

すべてのユースケースで、すべてのセクションが必要なわけではありません。プロダクトに関連するセクションを追加してください。

推論強度の設定

gpt-realtime-2 は、レイテンシーが増える代わりに、より深く推論できます。ワークフローに必要な判断能力をアシスタントが発揮できる範囲で、最も低い推論レベルを使用してください。

本番環境の音声エージェントの多くは、low から始めるとよいでしょう。タスクの複雑さ、許容できるレイテンシー、失敗時のコストに応じて、設定を上げ下げしてください。

推論強度適した用途例
minimalレイテンシーを最小限に抑えることが最優先で、タスクが単純な場合。スマートホームの操作、タイマー、簡単なカレンダーの確認。
low応答の速さと基本的な推論の両方が必要な場合。カスタマーサポート、注文の照会、ポリシーに関する簡単な質問。
medium複数のステップからなるタスクについて、アシスタントが推論する必要がある場合。テクニカルサポート、診断、複雑な振り分け。
highより深い推論によって成功率が大きく改善する場合。高い精度が求められるワークフロー、エスカレーションの判断、制約のあるタスク。
xhighレイテンシーやコストが増えても、最大限の推論を行う価値がある場合。複雑な計画立案、重大な問題のトリアージ、判断を誤った場合の影響が大きいツールのオーケストレーション。

API の設定に加えて、いつ、どの程度推論するかもモデルに指示してください。

## Reasoning

- For direct answers, simple lookups, and short confirmations, respond quickly and do not reason.
- For multi-step tasks, tool decisions, troubleshooting, or escalation, reason before acting.
- Do not perform extended reasoning when the user's audio is unclear; ask for clarification instead.

前置きの意図的な活用

前置きとは、音声エージェントが推論、調べもの、ツール呼び出しを行っている間も、応答が続いていると感じられるようにする、音声による短い状況説明です。うまく使えば、アシスタントが作業を進めているとユーザーに伝わり、安心感につながります。使い方が悪いと、単なるつなぎ言葉になり、待ち時間を長く感じさせます。

gpt-realtime-2 は、デフォルトで前置きを生成します。まずはデフォルトの動作をテストしてください。プロダクトで目指す体験に合わない場合は、明示的に調整します。

前置きの生成と再生のタイムライン

## Preambles

Use short preambles only when they help the user understand that work is happening.

### When to use a preamble

Use a preamble when:

- you are about to call a tool that may take noticeable time;
- you need to reason through a multi-step request;
- you are checking records, availability, account state, or policy details;
- you are preparing an escalation or handoff;
- silence would make the assistant feel unresponsive.

When a preamble is needed, output it immediately before substantive reasoning or tool use.

### When to not use a preamble

Do not use a preamble when:

- the answer is direct and can be given immediately;
- the user is only confirming, correcting, or declining something;
- the audio is unclear and you need clarification;
- the latest audio is silence, background noise, hold music, TV audio, or side conversation;
- the tool call is lightweight and the user would not benefit from an update.

### Preamble style

When using a preamble:

- keep it natural, calm, and concise;
- vary the wording across turns;
- describe the action, not the internal reasoning;
- avoid filler.

Avoid phrases like:

- "Let me think..."
- "Hmm..."
- "One moment while I process that..."
- "I am now going to access the tool..."

### Preamble length

Use one short sentence.

Do not exceed two short sentences unless the user needs an explanation before a high-impact action.

### Prefer

- "I'll check that order now."
- "I'll look up your appointment details."
- "I'll verify that before we make any changes."
- "I'll check the policy and then give you the next step."
- "I'll pull that up so we can make sure it's the right account."

### Avoid

- "Let me think about that for a second."
- "Please wait while I process your request."
- "I'm going to use my tools now."
- "Interesting question. I will reason through this carefully."

応答の長さの制御

gpt-realtime-2 は、タスクの種類ごとにどの程度詳しく説明するかをプロンプトで指定すると、長さに関する指示に最もよく従います。単に「簡潔に」と伝えるのではなく、その状況で何をもって簡潔とするかを定義してください。質問への直接的な回答、ツールの結果、トラブルシューティング、比較、エスカレーションでは、それぞれ適切な応答の長さが異なる場合があります。

## Verbosity

- Direct answers: Use 1-2 short sentences.
- Clarifying questions: Ask one question at a time.
- Tool results: Summarize the result first, then give only the next useful action.
- Product or option comparisons: Include key differences, tradeoffs, and who each option fits.
- Troubleshooting: Give one step at a time unless the user asks for the full procedure.
- Escalations: Briefly explain why escalation is needed and what will happen next.

例：

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

アシスタント：費用を最も抑えたい場合は Basic を選んでください。チームの権限管理と請求の一本化が必要な場合は Pro を選んでください。コンプライアンスレビューや管理者向けの制御機能を重視する場合は、エンタープライズを選んでください。

ツールの動作設計

gpt-realtime-2 はツール呼び出しの能力が向上していますが、ツールの動作は引き続きプロンプトとツール仕様の設計に左右されます。実行、質問、確認、復旧を行うタイミングをプロンプトで定義していないと、アシスタントがツールを早まって呼び出したり、不要な質問をしたり、失敗した呼び出しを繰り返したりする可能性があります。

ツール呼び出しの積極性の設定

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

ツールの種類デフォルトの動作
読み取り専用でリスクの低い検索意図と必須フィールドが明確な場合に呼び出します。
正確な識別子を必要とする読み取り専用の操作検索前に識別子を確認します。
ユーザーの目に触れるメッセージの送信送信前に下書きを作成するか、内容を要約します。
アカウントの変更呼び出す前に確認します。
購入、キャンセル、支払い呼び出す前に金額、対象、実行による結果を確認します。
取り消せない操作や影響の大きい操作明示的に確認し、必要に応じてエスカレーションを提案します。

読み取りと書き込みの操作が混在する場合は、このバランスの取れたデフォルト設定を使い、ユースケースに合わせて調整してください。

## Tools

Use only the tools explicitly provided in the current tool list. Do not invent, assume, simulate, or rename tools.

For read-only tools:

- Call the tool when the user's intent is clear and all required fields are available.
- Do not ask for confirmation unless the lookup depends on a high-precision identifier or there is meaningful risk of using the wrong record.
- Ask a clarification question only if a required field is missing, ambiguous, or conflicting.

For write tools or external actions:

- Summarize the intended action before calling the tool.
- Include the key consequence, such as what will be changed, sent, canceled, ordered, or charged.
- Ask for confirmation.
- Do not call the tool until the user clearly confirms.

For exact identifiers:

- Treat order IDs, tracking numbers, account numbers, confirmation codes, phone numbers, and email addresses as high precision.
- Normalize only when the field type is clear.
- Confirm the final value before account-specific lookups, validation, or write actions.

After tool calls:

- Only say an action was completed after the tool call succeeds.
- If the tool fails, explain the failure briefly, avoid raw errors, and give the user a clear next step.

リスクの高い操作の例：

ユーザー：残りの支払額をカードに請求してください。

悪い例：

アシスタント：カードへの請求が完了しました。

良い例：

アシスタント：確認ですが、残りの支払額 $248.16 を登録済みのカードに請求するということですね。進めてもよろしいですか？

ツールの失敗からの復旧

ツールの失敗も会話の一部です。適切に復旧するには、何が起きたかを説明し、次に何をすればよいかをユーザーに明確に示す必要があります。

すべての失敗に同じ対応をしないでください。復旧時の動作は、ツールの種類、失敗の内容、ユーザーへの影響に応じて変える必要があります。ユーザーに知らせずに再試行すべき失敗もあります。一方で、ユーザーに説明を求めたり、識別子の修正、新たな操作の確認、別の方法の選択を依頼したりする必要がある失敗もあります。

## Tool Failures

If a tool call fails:

1. Briefly explain what failed in user-friendly language.
2. Do not blame the user or expose raw tool errors.
3. If the failure may be due to an exact identifier, read back the value used and ask the user to correct it.
4. If the failure may be temporary, offer to retry once.
5. If the same failure happens repeatedly, offer an alternate path or escalation.

Do not repeatedly call the same tool with the same arguments after failure.

Do not ask for a different identifier until you have first checked whether the captured value was correct.

悪い例：

アシスタント：問題が発生しました。

良い例：

アシスタント：O R D ダッシュ 3 1 2 5 B 2 3 に一致するものが見つかりませんでした。どこか聞き間違えていましたか？

利用可能なツールとプロンプトの同期

リアルタイムモデルは積極的にユーザーを支援しようとします。実際には利用できないツールがプロンプトに記載されていたり、ツール一覧とプロンプトが一致していなかったりすると、モデルがツール名を作り出したり、操作を完了したふりをしたりする可能性があります。

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

## Tool Availability

Use only the tools that are explicitly provided in the current tool list.

Do not invent, assume, or simulate tools. If a tool is mentioned in the instructions but is not present in the tool list, treat it as unavailable.

If the user requests an action that requires an unavailable tool:

1. Do not pretend to complete the action.
2. Briefly explain that the tool is not available.
3. Offer the closest supported next step.

Only say an action was completed after the relevant tool call succeeds.

付録のプロンプト監査用メタプロンプトを使って、本番環境のプロンプトに矛盾や不足しているツール、想定外の状況で破綻しやすい指示がないかをレビューしてください。

無音と背景音への対応

音声エージェントは、デフォルトでは応答しようとする傾向があります。本番環境では、無音、背景のノイズ、保留音、テレビの音声、周囲の会話など、音声で応答すべきでない音が入ることもよくあります。

アシスタントが発話せずに音声を聞き続けるべき場合は、何も処理せずに待機するツールを使ってください。このツールにより、モデルは「ここにいます」「聞き取れませんでした」などと発話する代わりに、発話を伴わない有効な操作を選べます。

ツールの設計：

{
  "name": "wait_for_user",
  "description": "Call this when the latest audio does not need a spoken response, such as silence, background noise, hold music, TV audio, side conversation, or speech not addressed to the assistant. This tool helps end the turn without a spoken reply.",
  "parameters": {
    "type": "object",
    "properties": {},
    "required": []
  }
}

プロンプトの指示と組み合わせます：

## Handling Silence and Background Noise

If the latest audio is silence, background noise, hold music, TV audio, side conversation, or speech not addressed to you, call `wait_for_user`.

Do not respond conversationally after calling this tool.

Do not say "I'm here," "I didn't catch that," "Take your time," or "Let me know when you're ready."

Resume normal responses only when the user clearly addresses you or asks for help.

これは、アシスタントに向けられていない音声に使うもので、不明瞭なユーザーリクエストに使うものではありません。ユーザーが明らかにアシスタントに話しかけているものの、内容が聞き取れない場合は、代わりに聞き返してください。

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

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

チャネルユーザーに表示されるか用途
commentaryはい前置きとツール呼び出し。
finalはいユーザー向けの最終メッセージ。

たとえば、ツール呼び出しは commentary チャネルで行われます。ツールの使用前、使用中、使用後にアシスタントに何かを発話させたい場合は、commentary チャネルでの動作として指定してください。

Before calling tools in the commentary channel, briefly tell the user what you are doing.

gpt-realtime-2 は、1 つのターンで複数の応答フェーズを出力できます。API 出力では、この違いは response.done イベントで表されます。このイベントには、内容が commentary か最終回答かを示す phase 値が含まれます。

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

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

不明瞭な音声への対応

モデルは、確実に理解できる音声に対してのみ操作を行うべきです。音声が不明瞭な場合は、推測するのではなく、短い確認の質問をするようにしてください。

モデルに、欠けている単語の推測、ツールの呼び出し、エンティティの取得、前置きの生成をさせないでください。また、ユーザーが何を言ったのかを再構成しようとして、内部の推論に時間を費やすこともさせないでください。

## Unclear Audio

- Only respond to clear audio or text.
- If the user's audio is not clear, ask for clarification using a short English phrase such as "Sorry, could you repeat that clearly?"
- Don't repeat the same unclear-audio clarification twice.
- Treat audio as unclear if it is ambiguous, noisy, silent, unintelligible, partially cut off, or if you are unsure of the exact words the user said.
- Do not guess what the user meant from unclear audio.
- Do not reason when the audio is unclear.
- Do not provide a preamble or call tools in the commentary channel when the audio is unclear.

例：

ユーザーの音声：「注文の、さん、いち……を確認して」［途中で途切れる］

悪い例：

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

良い例：

アシスタント：注文番号の一部しか聞き取れませんでした。1 桁ずつもう一度教えていただけますか？

エンティティの正確な取得

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

音声では、こうした値を正確に取得するのが難しくなります。ユーザーは早口で話したり、数字をさまざまな単位で区切ったり、一部だけを 1 文字ずつ読み上げたり、つなぎ言葉を挟んだり、発話の途中で訂正したり、似た音の文字を発音したりします。1 桁間違えるだけで、検索に失敗したり、別のアカウントを取得したりするおそれがあります。

エンティティは慎重に取得します。値は 1 つずつ収集し、明確に聞き取れた部分だけを正規化します。高い精度が求められる値はツール呼び出し前に確認し、どのような訂正にも対応できるようにします。

エンティティを 1 つずつ収集

ワークフローで複数の値が必要な場合は、1 つずつ収集します。特に音声での会話では、これによってフィールド間で値が混同されるのを防げます。

## Entity Collection Order

Collect required values one at a time.

- Ask for only the next missing value.
- Do not ask for multiple values in the same turn.
- Before asking, check whether the value was already provided earlier in the conversation or the session.
- If a possible value already exists, confirm it with the user before using it.

Example:

"I see tracking number ABC-54321 from earlier. Should I use that one, or do you have a different tracking number?"

Do not call tools until the current value has been collected, validated, and confirmed.

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

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

## Spelled-Out Characters

When a user dictates an ID, code, or email character by character, treat the spoken sequence as one compact value. Preserve explicitly spoken separators like dash, dot, underscore, slash, or plus; otherwise do not add spaces or separators.

Examples:

- "A B C one two three" -> "ABC123"
- "B C dash nine eight seven" -> "BC-987"
- "J O H N at example dot com" -> "john@example.com"

Do not insert spaces between spelled-out characters unless the user explicitly says the value contains spaces.

読み上げられた数値の慎重な正規化

数字で構成される識別子を伝える際、ユーザーは 1 桁ずつ読んだり、複数桁をまとめて読んだり、通常の数の読み方を使ったりします。フィールドがひと続きの数値を想定している場合は、明確に聞き取れた数値の発話を数字に変換します。

## Spoken Number Handling

Convert spoken numbers into digits when collecting numeric identifiers.

Examples:

- "one two three four" -> "1234"
- "one twenty three" -> "123"
- "one nineteen" -> "119"
- "ninety nine eleven" -> "9911"
- "nine thousand nine hundred eleven" -> "9911"

If multiple interpretations are plausible, ask the user to clarify before using the value.

Example:

"I heard either 119 or 1-19. Could you repeat the number digit by digit?"

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

注文 ID、追跡番号、アカウント番号、請求番号、確認コードなどの識別子は、高い精度が求められるフィールドです。ツール呼び出しで使う前に確認します。

数字で構成される識別子は、1 桁ずつ復唱します。全体を 1 つの数として読み上げると、誤りを見落とすおそれがあります。

例：

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

ユーザーが 1 文字または 1 桁を訂正した場合は、ツールを呼び出す前に、訂正後の値を最初から最後まで復唱します。

例：

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

## Exact Identifier Confirmation

Before calling tools with high-precision identifiers:

- Confirm the final normalized value with the user.
- Read numeric identifiers back digit by digit.
- Do not use guessed, partial, or ambiguous values.
- If the user corrects the value, repeat the full corrected value before calling the tool.

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

メールアドレスは重要な値です。ドット、ハイフン、アンダースコア、連続する同じ文字、似た響きの名前などを取り違えると、アカウント検索に失敗したり、誤ったアドレスにメッセージを送信したりするおそれがあります。

メールアドレスを 1 文字ずつ読み上げるようユーザーに依頼します：

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

復唱する際は、最終的なアドレスが正確かどうかを確認します：

アシスタント：確認ですが、c-h-e-n、アットマーク、example、ドット、com で合っていますか？

## Email Confirmation

Email addresses must be captured exactly.

If the user says the email naturally without spelling it out, ask them to repeat it character by character.

Example:

"Could you spell the email address character by character so I can make sure I have it exactly right?"

When reading an email back, confirm the exact final email address.

Example:

"Just to confirm, that is c-h-e-n at example dot com, right?"

エンティティ収集のワークフロー

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

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

正確な表現を使います。モデルは、開発者が意図した全体的な振る舞いよりも、指示の文言そのものを優先する場合があります。適用範囲が広いルールや厳格なルールは、特に複数のルールが重なると、予想外の形でアシスタントの動作を支配することがあります。

must、only、never、always など、制約を表す語の使用には注意します。単なる強調としてではなく、その動作が本当に必須の場合に使います。厳しい制約を多用すると、アシスタントが柔軟性を失い、過度に慎重になったり、妥当な例外に対応できなくなったりするおそれがあります。

適用範囲は明確に定めます：

For write actions that modify user data, ask for confirmation before calling the tool.

適用範囲を広くしすぎないようにします：

Always ask for confirmation before doing anything.

適用範囲が広い指示では、注文状況の確認、空き状況の取得、アカウント情報の読み取りなど、無害な読み取り専用の照会でも、不要な確認を求めるおそれがあります。

字義どおりに解釈される例

プロンプト作成全般の推奨事項：

  • 意図を暗に伝えるのではなく、明示的に指示します。
  • 動作を厳密に制限する必要がない限り、制約を表す語をむやみに使わないようにします。
  • 矛盾する指示を最小限に抑えます。
  • 優先順位に関する指示を重ねたり、競合させたりしないよう注意します。
  • プロンプトは段階的にテストします。わずかな文言の変更でも、動作に大きく影響する場合があります。
  • 従来のリアルタイムモデルから移行する際は、最良の結果を得るために、一部のプロンプトの構成を見直す必要があると考えておきます。

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

言語とアクセントは別々に制御する必要があります。

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

次のように、言語について適用範囲を広くしすぎた指示は避けます：

Mirror the user.
Respond naturally in the user's language.
Switch languages when appropriate.
Sound local.
Adapt to the user's accent.

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

英語での応答ポリシー

## Language

English is the default response language.

- Do not infer language from accent alone.
- Ignore short filler sounds, backchannels, and isolated foreign words for language detection.
- Only switch languages if the user explicitly asks or provides a substantive utterance in another language.
- If language confidence is low, ask a short clarification instead of guessing.
- Keep preambles, spoken bridges, tool-related messages, and final answers in the same language.
- Accent adaptation must not change the response language.

多言語での応答ポリシー

## Language

Default to English unless the user clearly uses another language.

Switch languages only when:

- the user explicitly asks to use another language;
- the user provides a substantive utterance in another language. A substantive utterance means the user gives a complete request, question, or correction in another language, not just a greeting, name, address, filler word, or borrowed phrase.

Do not switch languages based on:

- accent;
- pronunciation;
- filler words;
- short backchannels;
- names;
- addresses;
- isolated foreign words.

If uncertain, ask:

"Would you like me to continue in English or [LANGUAGE]?"

アクセントの制御

gpt-realtime-2 はアクセントに関する指示により忠実に従えますが、曖昧なプロンプトでは、アクセントが変化したり、意図せず言語が切り替わったりするおそれがあります。

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

  • 目標とするアクセント
  • 一定に保つべき特徴
  • 意図する話すペース、強勢、韻律
  • アクセントの調整を使用言語の選択に反映させるかどうか

避けたい例：

Sound Australian.

推奨する例：

## Accent

Speak English with a light Australian accent.

- Keep the accent stable from the first word to the last.
- Use natural Australian vowel shaping, but keep speech easy to understand.
- Do not exaggerate the accent.
- Do not change response language based on the user's accent.

カスタム音声

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

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

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

長時間セッションでの状態の維持

gpt-realtime-2 では、リアルタイムのコンテキストウィンドウが 32k トークンから 128k トークンに拡張され、長時間のセッションにより適しています。発話が密に続く双方向の会話では、128k トークンは、おおよそ 1～2 時間分の生の音声コンテキストに相当すると考えるとよいでしょう。この時間は、ツールの使用、内部推論、追加されたレコードなど、セッションの内容によって変わります。

長いコンテキストを扱うユースケースでは、gpt-realtime-2 が現在有効な情報、背景情報、情報源が矛盾した場合に無視すべき情報を区別できると、最も高い性能を発揮します。未整理の文字起こしや大量のコンテキストをそのまま渡して、情報源の優先順位をモデルに推測させないでください。情報を構造化してください。

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

以前のリアルタイムモデルからの移行

以前のリアルタイムモデルから移行する際は、プロンプトを単に移植するテキストとしてではなく、動作を設計するものとして扱ってください。

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

次のステップ

GPT-Live の場合：

Realtime の場合：