- パラメーターの役割
- 期待される型
- 一般的な範囲または受け付ける値
- 品質、コスト、レイテンシ、ルーティングに影響するか
クイック参照
エンドポイントに関する注意
service_tierは、主なテキストリクエストのインターフェースでサポートされています:
選択したモデルとプロバイダーの組み合わせが対応している場合にのみ、ultrafast、fast（対応していればpriority）、flexを使います。Ultrafastは対応する最高速階層を選び、fastとpriorityは同じFastのルーティングと料金を使います。service_tierを省略するとstandardになります。
Batchはservice_tierの値ではありません。Batchリクエストには別のBatch APIを使用します。
Anthropic互換のMessagesリクエストでは、Anthropicのネイティブな上流値はautoとstandard_onlyです。Phaseoはこれらの値をプロバイダー間で正規化またはマッピングし、/v1/messagesでAnthropic互換の動作を維持する場合があります。
Phaseoを指すカスタムベースURLでAnthropic公式SDKを使用する場合は、/v1/messagesでAnthropicネイティブの値を優先してください。ultrafast, priorityやflexなどのプロバイダー間で正規化されたティア制御や、OpenAIの別名fastには、生のHTTPリクエスト、またはゲートウェイネイティブ／OpenAI形式のテキストAPIを使用してください。
パラメーターリファレンス
model
リクエストに使用するゲートウェイのモデルIDを選択します。
意図的に対応エイリアスを使う場合を除き、各モデルページのクイックスタートに記載された正規モデルIDを使用してください。正規IDは、例、自動化、長期的な統合で最も安全な選択です。
stream
最終レスポンス本文を待たずに、Server-Sent Eventsで出力を逐次返します。
チャットUI、トークン単位の表示、または早い段階で出力されると使いやすい長いレスポンスに対して有効にします。完全なJSONレスポンス、簡単な再試行、または構造化データの解析しやすさを優先する場合は無効にします。
注意:
ストリーミングの対応状況はエンドポイントによって異なります。
ストリーミングは通常、品質制御ではなく転送方法の選択です。
ツール呼び出しや構造化出力のフローでは、プロバイダーによってストリーミングの動作が異なる場合があります。
temperature
トークン選択のランダムさを制御します。
低い値では出力が保守的で再現しやすくなります。高い値では多様性が増し、ブレインストーミングや創作に役立つ一方、一貫性やスキーマへの準拠が低下することもあります。
適した用途:
- 情報抽出
- 分類
- JSONまたはスキーマ出力
- クリエイティブな生成
temperatureとtop_pは、まずどちらか一方だけ変更してください。
高いtemperatureと強い量子化を組み合わせると、不安定さが増すことがあります。
top_p
累積確率がtop_pに達する最小のトークン集合に候補を絞る、nucleus samplingを適用します。
値を下げると、モデルが選択する確率分布の範囲が狭まり、通常はより安全で焦点の合った出力になります。値を上げると、より多くのトークンを検討します。
注意:
temperatureを直接変えずに探索範囲を狭めたり広げたりするには、
top_pを調整します。
多くの用途では、中程度のtemperatureと1.0に近いtop_pが妥当な初期値です。
top_k
対応プロバイダーでは、各ステップの上位k個の候補トークンにサンプリングを制限します。
top_kを低くするとモデルの選択肢が絞られ、出力が予測しやすくなります。値を高くすると候補の範囲が広がります。
注意:
top_kはすべてのプロバイダーで利用できるわけではありません。
top_pより明示的に候補トークン数を制限する方法として使います。
max_tokens
max_tokensフィールド名を引き続き使用するエンドポイントとプロバイダーで、出力長を制限します。
コスト、レイテンシ、出力が途中で切れるリスクの制御に使います。値が小さすぎると、モデルが正しく動作していても出力が不完全に見えることがあります。
max_output_tokens
max_tokensではなくmax_output_tokensを使用するルートで出力長を制限します。
意味上は
max_tokensと同じ制御ですが、選択したエンドポイントまたはSDKインターフェースが期待するフィールド名を送信してください。
max_completion_tokens
max_completion_tokensを使用する新しいOpenAI形式のテキストAPIで、出力長を制限します。
これは出力トークン上限を指定する別のフィールドです。同じリクエスト内で出力長の別名を混在させず、エンドポイントが期待する名前を使用してください。
frequency_penalty
トークンがすでに出現した回数に応じて、繰り返しを抑制します。
モデルがループしたり、フレーズを繰り返したり、同じ表現を使いすぎたりする場合は値を上げます。
presence_penalty
一度でも出現したトークンの再利用を抑え、モデルが新しい話題や表現を試しやすくします。
frequency_penaltyと比べると、繰り返し回数ではなく、より広い意味で新規性を制御します。
repetition_penalty
従来のOpenAI形式のペナルティフィールドとは異なる、プロバイダー固有の反復抑制を適用します。
frequency_penaltyやpresence_penaltyと似た目的ですが、意味はプロバイダーによって大きく異なります。共通の制御ではなく、プロバイダー固有の動作として扱ってください。
seed
上流プロバイダーがseed生成に対応している場合、決定論的なサンプリングを要求します。
デバッグ、回帰テスト、上流プラットフォームが許す範囲での挙動再現に使用します。seed付き生成は再現性を高めますが、すべてのプロバイダーやインフラ変更をまたいだ完全な決定性は保証されません。
stop
生成を途中で終了する1つ以上のシーケンスを定義します。
フッター、ツール区切り、次の生成セクションの前で停止するなど、出力に明確な境界が必要な場合に便利です。
logprobs
利用可能な場合にトークン単位の確率メタデータを要求します。
主に分析、評価、ランキング、デバッグ、信頼度に関するワークフローで役立ちます。通常の製品レスポンスでは必要ありません。
top_logprobs
各出力位置の上位代替候補トークンと、その対数確率を要求します。
選択された出力トークンだけでなく、代替トークン候補も調べたい場合に使用します。
tools
ツールを使うモデルワークフローで呼び出せるツールや関数を宣言します。
エンドポイントのドキュメントに別の指定がない限り、OpenAI形式のツールスキーマを使用します。ツール宣言はモデルが呼び出せるものを示し、呼び出しを必須にはしません。
tool_choice
モデルがツールを自動で呼び出せるか、呼び出しを禁止するか、特定のツールを使う必要があるかを制御します。
コンテンツのみを返す場合は
none、モデルに判断させる場合はautoを使い、後続のオーケストレーションでツール呼び出しが必要なら、より厳しい値を指定します。
parallel_tool_calls
対応APIでツール呼び出しを並行して実行するかどうかを指定します。
後続システムが厳密な逐次実行、順序付きの副作用、または簡潔なエージェントトレースを必要とする場合は無効にします。
response_format
プレーンテキスト、JSON、スキーマ制約付きレスポンスなど、特定の出力形式を要求します。
受け付けられる形式はエンドポイントとプロバイダーアダプターによって異なります。自由形式のテキスト以外、特にJSONレスポンスや構造化抽出フローが必要な場合に使用します。
structured_outputs
選択したルートとプロバイダー構成で、信頼できる構造化レスポンスやスキーマ制約付きレスポンスに対応しているかを示します。
クイックスタート表では、選択したエンドポイントと有効なプロバイダーが構造化出力ワークフローを安定してサポートできるかを確認できます。サポート状況のメタデータとして解釈してください。
json_schema
対応するモデルとエンドポイントで構造化出力を強制するためのJSONスキーマを指定します。
必須フィールド、型付き抽出、厳格なレスポンス契約が必要な場合に使用します。準拠率を高めるため、スキーマは小さくタスク固有にしてください。
reasoning
推論に対応するAPI向けの、プロバイダー固有の推論設定を含みます。
ルートに応じて、有効化、推論レベル、トークン予算、詳細度、推論内容を返すかどうかを含みます。
reasoning_effort
エンドポイントとモデルが制御に対応している場合に、推論予算の引き下げや引き上げを要求します。
推論レベルを上げると難しい推論タスクの性能が向上する場合がありますが、レイテンシとトークン使用量が増えます。低めの設定は、速度とコストを重視するリクエストに適しています。
reasoning_tokens
対応時に推論専用のトークンフィールドを表します。
ルートによっては、一般的なリクエストパラメーターではなく、リクエスト設定、上限、またはレスポンスの使用量フィールドを表します。
include_reasoning
対応時にレスポンスへ推論内容または要約を含めるよう要求します。
慎重に使用してください。推論ペイロードは大きくなる場合があり、すべてのモデルで使えるとは限りません。追加の診断情報が不要な本番レスポンスには適さないことがあります。
service_tier
対応するテキストAPIでサポートされるルーティングまたは料金ティアを選択します。
選択したモデルとプロバイダーの組み合わせが対応している場合にのみ、
ultrafast、fast（対応していればpriority）、flexを使います。Ultrafastは対応する最高速階層を選び、fastとpriorityは同じFastのルーティングと料金を使います。標準階層を使う場合はフィールドを省略します。
Phaseoは、ゲートウェイで正規化されたティア値を内部でプロバイダー固有の制御に変換するため、対応するテキストインターフェースで同じservice_tier値を使用できます。
注意:
Batchは独立したAPIフローであり、サービスティアの値ではありません。
対応状況はエンドポイントとプロバイダーによって異なります。
prompt_cache_key
プロンプトキャッシュを考慮したルーティング用に、安定したキャッシュ親和性キーを指定します。
複数のリクエストで安定したプロンプトの接頭辞を共有し、可能なら同じ上流プロバイダーまたはリージョンを優先する場合に使用します。Phaseoはリクエストコンテキストからキャッシュ親和性を導出することもできますが、長時間の会話、エージェントセッション、反復ワークフローでは明示的なキーが適しています。
prompt_cache_options
対応するOpenAIルートにOpenAIのプロンプトキャッシュ設定を渡します。
GPT-6 Astraで明示的なプロンプトキャッシュを使う場合は、
{"mode":"explicit","ttl":"30m"}を指定します。Phaseoはリクエストの正規化中もこのオブジェクトを保持し、そのままOpenAIに送信します。
cache_control
対応するテキストリクエストのインターフェースで、プロバイダーに依存しないプロンプトキャッシュポリシーを適用します。
同じキャッシュヒントをゲートウェイ共通スキーマ経由で渡すには、Chat Completions、Responses、Anthropic Messagesリクエストのトップレベルで
cache_controlを使用します。明示的なキャッシュ境界が必要な場合は、対応するコンテンツブロックにも配置できます。
一般的なTTL値は5mと1hですが、プロバイダーとモデルの対応状況によります。ネイティブ統合ではprovider_options.anthropic.cache_controlやprovider_options.google.cache_controlなどのプロバイダー固有の別名も引き続き使用できます。
prompt_cache_retention
OpenAIルートの対応リクエストで、OpenAI互換のプロンプトキャッシュ保持ポリシーを設定します。
OpenAIのキャッシュ保持オプションをプロバイダー固有のオプションに入れずに渡す場合に使用します。プロバイダー固有の別名
provider_options.openai.prompt_cache_retentionも引き続き使用できます。両方が指定された場合はトップレベルのprompt_cache_retentionが優先されます。
provider
ルーティング制約とプロバイダーの優先設定を含みます。
リクエストを実行できる上流プロバイダー、優先順位、満たすべきコンプライアンス要件を指定する場合に使用します。
主なフィールド:
quantizationsはOpenRouter互換のプロバイダールーティング用語に従い、providerとroutingのどちらでも指定できます。照合では大文字と小文字を区別せず、空白、ハイフン、アンダースコアを無視します。float8/FP8やbfloat16/BF16のように意味が明確な名前は別名として扱われます。このフィルターを指定すると、量子化メタデータのないオファーは除外されます。一致する適格なオファーがない場合、Gatewayは別のバリアントへ黙ってルーティングせず、要求値と現在利用可能な量子化方式を含むエラーを返します。
provider_options
ゲートウェイ共通のリクエスト形式に正規化せず、そのまま渡すプロバイダー固有の設定を含みます。
例:
openai.context_managementopenai.prompt_cache_retentionanthropic.cache_controlgoogle.cache_controlgoogle.cached_content
cache_control、OpenAI互換の保持設定にはトップレベルのprompt_cache_retentionを使用してください。
Chat Completions、Responses、Anthropic Messagesでのプロバイダー別プロンプトキャッシュ例は、プロンプトキャッシュを参照してください。
meta
対応時にレスポンスの追加メタデータを要求します。
デバッグ、分析、後続処理での確認に使う、必須ではないレスポンスメタデータが必要な場合に使用します。
usage
対応時に使用量の集計情報を要求します。
ヘッダーやダッシュボードだけに頼らず、レスポンス本文にトークン数や使用量の情報を含めたい場合に便利です。
debug
リクエストとルーティングの診断情報を制御して有効にします。
対応するデバッグフィールド:
デバッグペイロードには機密性の高いリクエストコンテキストが含まれる場合があります。開発環境または厳格に管理された環境でのみ使用してください。
リクエスト例
詳しい解説
フィールドリファレンスではなく、具体的な調整方法を知りたい場合は、次のページを参照してください。- 推論パラメーター: temperature、top_p、top_k、トークン上限、停止シーケンス、調整手順に関する実践的な説明
- サンプリングとデコード ランダム性、ペナルティ、デコード設定がモデルの動作に与える影響について