仕組み

このページでは、モデルルーター の背景にある概念を説明します。一度読んでおくと、他のすべてのページがより理解しやすくなります。

プリペイド残高

施設は USD 建てのプリペイド残高を保持します。残高が変動する方向は 2 つだけです。

• チャージすると（手動、自動チャージ、またはアカウントに入金された調整によって）増加 します。チャージはすぐに反映されます。
• 使用量が発生すると 減少 します。使用量は推論サービスからリアルタイムで報告され、15 分ごとにプリペイド残高と照合されるため、ごく最近のアクティビティが Monthly usage に表示されるまでに数分かかる場合があります。取引履歴には、チャージと残高の調整のみが表示されます。

残高は金銭的な壁です。残高がゼロになると、チャージするまで推論リクエストは insufficient credits エラーでブロックされます。モデルの一覧は残高がゼロでも取得できるため、アカウントに入金する前に、連携先でカタログを確認できます。

モデルカタログ

カタログには多数のプロバイダーのモデルが含まれ、それぞれ 100 万トークンあたりの料金が設定されています（入力と出力は別料金で、Models の設定に表示されます）。施設では、すべてのモデルがデフォルトで有効になっています。次のことができます。

• Settings → Models で アカウント全体でモデルを無効にする（少なくとも 1 つのモデルは有効のままにする必要があります）。
• API キーごと、または接続されたサービスごとにモデルを制限する：施設で有効になっているモデルの中から、さらに絞り込んだリストを設定します。

特別なカタログ項目である auto（Auto Router）には、独自の料金はありません。リクエストごとに、プロンプトの複雑さに基づいて最適なモデルが自動的に選択され、選択されたモデルの料金で課金されます。詳しくは、Models を参照してください。

モデルを利用する 2 つの方法

1. 連携サービス

施設とペアリングされたAIエージェントデバイスは、モデルルーターに自動的に接続します（デバイスに API キーを入力することは一切ありません）。また、Workflows も接続できます。接続された各サービスは、Settings → Service Access & API Keys の Connected Services に独自の支出額とともに表示され、それぞれに独自の支出の上限、モデルの制限、ガードレールの上書きを設定できます。詳しくは、Connected Services を参照してください。

2. 独自の API キー

API キー（phk_ で始まります）を発行すると、BYOK（Bring Your Own Key）に対応したサードパーティのソフトウェアやシステムを、Performance Hub が公開しているモデルに接続できます。エンドポイントは OpenAI 互換です。OpenAI SDK やツールの接続先をベース URL に設定し、キーで認証します。詳しくは、API キー と アプリケーションの接続 を参照してください。

どちらの方法も同じ残高を使用し、アカウント全体の同じ支出の上限に従い、同じ Activity の分析と Logs に表示され、個別に制限できます。

残高と支出の上限の違い

この 2 つは異なる仕組みで、両方が適用されます。

アカウントの支出の上限には 3 つの期間があります。日次（毎日午前 0 時に施設の現地時間でリセット）、月次（毎月 1 日に施設の現地時間でリセット）、累計のハードキャップ（前回の手動リセット以降の支出をカウントし、自動的にはリセットされない）です。任意の組み合わせを同時に有効にでき、上限はすべての API キーと接続されたサービスの合計に適用されます。プリペイド残高もあわせて適用されます。

キーごと・サービスごとの上限も同じように機能しますが（日次、月次、累計）、そのキーまたはサービスの支出だけをカウントします。上限に達すると、そのキーまたはサービスだけがブロックされ、施設の他の部分は引き続き動作します。

リクエストの処理方法

リクエストがエンドポイントに届くと、次の順序でチェックが行われます。

1. 認証：有効な API キー、または接続されたサービスの ID が必要です。API キーの場合、モデルルーターが有効になっていない施設はここで HTTP 403（"Model Router is not enabled for this facility"）で拒否されます。モデルの一覧の取得（GET /v1/models）には認証の直後に応答するため、残高がゼロでも引き続き動作します。
2. プリペイドクレジットのチェック：利用可能残高が $0 を超えている必要があります（接続されたサービスの場合は、モデルルーターが有効になっている必要もあります）。条件を満たさない場合、リクエストは insufficient credits エラー（HTTP 402）で拒否されます。
3. アカウントの支出の上限：日次、月次、または累計の上限を超えた場合、リクエストは budget exceeded エラー（HTTP 402）で拒否されます。このエラーには、期間がリセットされる日時が施設のタイムゾーンで記載されます。
4. キーごと/サービスごとの支出の上限：同じチェックを、呼び出し元のキーまたはサービスを対象に行います。
5. プロンプトのチェック：プロンプトに対して、プロンプトインジェクション対策とカスタムコンテンツフィルターが実行されます。block フィルターまたはインジェクションの検出に一致すると、リクエストは拒否されます（HTTP 403、content policy violation）。redact フィルターは一致した部分を [REDACTED] に書き換え、リクエストを続行させます。
6. モデルのルーティング：auto は Auto Router によって具体的なモデルに決定されます（画像を含むリクエストは、許可されている画像認識対応のモデルに送られます）。フォールバックモデルはキーで使用できるものに絞り込まれ、リクエストで独自に指定されていない場合は推論の設定が適用され、リクエストされた出力の上限はモデルが対応する範囲に制限されます。
7. 推論：PII のマスキングとシークレットの秘匿化（有効な場合）は、プロンプトがモデルに届く前に推論サービスによって適用されます。その後、リクエストはモデルプロバイダーに送られ、レスポンスがストリーミングで返されます。

レート制限（キーまたはサービスに設定されている場合、1 分あたりのリクエスト数と 1 分あたりのトークン数）は、処理全体を通じて適用されます。超過すると HTTP 429 が返されます。

記録される内容

すべてのリクエストは、メタデータとともに記録されます。時刻、モデル（リクエストされたモデルとルーターが決定したモデルの両方）、プロバイダー、トークン（プロンプト、補完、キャッシュ、推論）、コスト、レイテンシ、最初のトークンまでの時間、速度、ステータス、呼び出し元のキーまたはサービスです。プロンプトとレスポンスの内容が保存されることはありません。

モジュールに表示される使用量と支出額は、上限の適用に使われる値と同じです。そのため、「limit reached」と表示されるものが、そのままブロックされる対象になります。

用語集