クイックスタート
1
プリセットを作成する
ダッシュボード -> 設定 -> プリセット を開き、
release-summary のような分かりやすいスラッグでプリセットを作成します。呼び出し元の間で共有する既定値だけを追加してください。2
リクエストでプリセットを参照する
呼び出し元はユーザー入力に集中し、プロンプト、パラメーター、ルーティングの安定した既定値はプリセットから適用します。
3
ルーティング結果を確認する
Gateway -> 使用状況 でリクエストを開き、適用された既定値とリクエストを処理したプロバイダーを確認します。
プリセットに含められるもの
- すべてのリクエストの先頭に追加するシステムプロンプト。
- 許可するモデルまたはモデルファミリー。
- ルーティングの優先設定に使うプロバイダー許可リストまたは無視リスト。
- temperature、top_p、max_tokens などの既定パラメーター。
- 対応モデルに適用する任意の推論既定値。
@ で始まり、簡単に判別できます。
プリセットの呼び出しにはリクエストの model フィールドのみを使用します。Phaseo は専用の preset リクエストフィールドを提供しません。
- 非公開プリセットとワークスペースプリセットは
@{slug}を使い、API キーのワークスペース内で解決されます。 - 公開プリセットは
@{username}/{slug}を使い、どのワークスペースからも解決できます。例:@octavia/release-summary。
バージョンとマーケットプレイスのフォーク
変更を保存すると非公開ドラフトが更新されます。公開できる状態になったら 新しいバージョンを公開 を選択してください。Phaseo は変更できない番号付きリリースを作成し、過去のバージョンも確認用に保持します。 プリセットの所有者は、バージョンラベルの表示方法を選択できます。- 連番:
v1、v2、v3。 - セマンティックバージョニング:
1.2.0、2.0.0-beta.1、1.4.2+build.7などの SemVer ラベル。 - 日付:
YYYY.MM.DD。同じ日に複数のリリースを公開した場合は、2026.08.02.2のように数値の接尾辞が付きます。
プリセットのマージ方法
Gateway コンテキストでリクエストにプリセットが適用される場合、プロバイダーのルーティング前にプリセットが適用されます。- 既定パラメーターはリクエスト本文にないフィールドのみを補い、呼び出し元が指定した値を上書きしません。
- リクエストにすでにシステムメッセージがある場合、プリセットのプロンプトをその前に追加します。Anthropic 形式の
systemフィールドを使う場合は、そのフィールドの先頭に追加します。 - プロバイダーの許可リストと無視リストは選択前に適用されます。見た目だけのラベルではなく、フォールバック候補を絞り込みます。
- プリセットのモデル許可リストにないモデルを使うリクエストは、無言で別モデルへルーティングせず、早い段階で拒否されます。
現在の公開プリセット機能
ダッシュボードのプリセット機能は、リクエスト設定のうち、安定して明示できる次の項目に意図的に限定されています。- システムプロンプトの挿入
- モデル許可リスト
- プロバイダー許可リストまたは無視リストによるルーティング制限
- デコードと生成の既定値
- 推論の既定値
プリセットを管理する
ダッシュボード -> 設定 -> プリセット でプリセットを作成、管理します。プロンプト、ルーティング、キャッシュの動作が大きく異なるワークフローには、別のスラッグを使ってください。プリセットを使う場面
- 複数サービスでシステムプロンプトを統一する。
- コンプライアンス要件に合わせて、承認済みプロバイダーだけにルーティングする。
- 環境間で既定パラメーターを統一する。
- アプリケーションコードをほぼ変更せず、移行プロジェクトがプロンプト、ルーティング、パラメーターの既定値を保持できるようにする。