予期しないルートを確認した際、有用な手がかりとなったのはモデル名ではなく配信ティアでした。リクエストを処理するルートは、論理的なモデルが同じであっても、価格の適格性を変更する可能性があります。この不一致があるため、私たちは配信ティアを品質のバッジではなく、ルーティングの決定として扱っています。これは、価格の適格性とルーティングを明示する必要がある場合に重要となります。デフォルトのポリシーがすでにリスクとコストの目標と一致している場合、その重要性は低くなります。
重要なポイント
- リクエストは
officialルートまたはverifiedルートを通じて処理されます。選択内容はリクエストごとにresolvedDeliveryTier（verifiedまたはofficial。この機能以前の記録の場合は null）として記録されます。 autoはデフォルトのポリシーであり、第3のルートタイプではありません。これは到達可能なパスを保持し、ディスパッチ前にリクエストにかかる最大コストを見積もります。- ワークスペースおよび API キーのポリシー継承が標準的な設定です。2026年9月11日の本番環境の読み取りでは、5,536のワークスペースが明示的な Auto ポリシーを持ち、217がシステムデフォルトを継承し、4,134の API キーすべてがワークスペースから継承していました。同週の後の読み取りでは、継承数は219となりました。明示的なカウントが横ばいだったのは、継承されたワークスペースがまだポリシーを設定していない新規作成アカウントだったためです。これらの数値は、内部リリースリハーサルノートに記録された TokenLab 2.0 ローンチ時の読み取り（2026年9月11日観測）によるものです。公開ベンチマークではなく、内部の本番環境の読み取りとして扱ってください。
- Official の価格適格性には、正確な Official ルートの一致が必要です。Official ルートが一致しない場合、Verified 配信が利用可能です。
- ヘッダー
X-TokenLab-Delivery-Policyを使用して、リクエストごとに配信の選択を上書きできます。ワークスペースのデフォルト設定で一般的なケースはカバーされます。
3つの配信ティアオプションの実際の内容
チャネルは配信ティアを VERIFIED および OFFICIAL として宣言します。アクティブな公開配信ティアを持つチャネルのみが、組織のモデルバインディングにバインドできます。ワークスペースは論理モデルを特定のチャネルにバインドできます。そのバインディングは、チャネルがアクティブで、削除されておらず、アクティブな公開配信ティアを宣言している場合を除き、拒否されます。そのチャネル上のモデルのルートも有効化されている必要があります。
Official とはルートが公式のプロバイダーパスによって提供されることを意味し、Verified とは TokenLab が検証したパスを意味します。Auto はルーターが到達可能なルートの中から選択できるようにするポリシーです。ディスパッチ後にリクエストを検査すると、resolvedDeliveryTier によって verified または official のどちらが処理したかがわかります。このフィールドは、記録がこの機能以前のものである場合は null になります。
配信ティアを選択すると何が変わるか
ティアを選択すると、価格の適格性、リクエストごとの記録、およびディスパッチ前に表示される見積もりが変更されます。価格は、組織レベルの配信価格調整ルールを通じて配信ティアごとに調整でき、その調整は適用前に正規化および検証されます。ローンチ後、明示的な Verified または Official の選択が引き続き適用されますが、ポリシー以前のリクエストはデフォルトで Auto になります。
Auto は単一の価格ではなく、リクエストの最大金額を見積もります。複数のルートが到達可能な場合がありますが、Auto は到達可能なすべてのルートを保持し、見積もりを低く見せるために高価なルートを除外することはありません。パイプラインでは、ディスパッチ前に見積もりをチェックし、完了後に resolvedDeliveryTier を確認します。
| オプション | 最適化対象 | 選択のタイミング | 事後に検証できること |
|---|---|---|---|
| Auto | 到達可能なルートと最大コストの見積もり | デフォルトのポリシーで到達可能なルートから選択したい場合 | resolvedDeliveryTier がリクエストを処理したルートを表示 |
| TokenLab Verified | Official が利用不可または不要な場合の TokenLab 検証済みパスへのアクセス | 検証済みルートが必要な場合、または Official ルートが一致しない場合 | resolvedDeliveryTier が verified を表示 |
| Official | 公式価格適格性のための正確な Official ルートの一致 | 公式価格の適格性が必要な場合 | resolvedDeliveryTier が official を表示 |
チームが通常行う配信ティアポリシーの設定
このセクションの読み取り数値は、内部リリースリハーサルノートに記録された TokenLab 2.0 ローンチ時の読み取り（2026年9月11日観測）によるものです。公開ベンチマークではなく、内部の本番環境の読み取りとして扱ってください。
デフォルトの設定は継承であり、リクエストごとの設定ではありません。2026年9月11日の本番環境の読み取りでは、5,536のワークスペースが明示的な Auto ポリシーを持ち、217がシステムデフォルトを継承していました。4,134の API キーすべてがワークスペースから継承していたため、古いクライアントは新しいヘッダーを必要としませんでした。このパターンは、ワークスペースポリシーが一般的なケースをカバーし、リクエストごとの上書きが例外として残るため合理的です。
同週の後の読み取りでは、明示的な設定が5,536、継承が219となりました。明示的なカウントは横ばいでしたが、継承数は217から219に増加しました。これらの継承されたワークスペースは、まだポリシーを設定していない新規作成アカウントであったため、アカウント作成に伴いカウントが変動します。ポリシーの設定は移行作業ではなく、ローンチ時にワークスペースやキーのポリシーの一括バックフィルは実行されておらず、継承されたキーはクライアント側の変更を必要としませんでした。
ワークスペースが論理モデルを特定のチャネルにバインドする場合、バインディングルールが引き続き適用されます。チャネルがアクティブで、削除されておらず、アクティブな公開配信ティアを宣言していない限り、バインディングは拒否されます。そのチャネル上のモデルの有効なルートも存在する必要があります。チャネルは、Registry 宣言が ACTIVE であり、削除タイムスタンプのない自身のレコードが ACTIVE である場合にのみ組織モデルバインディングにバインドできるため、一時停止中または廃止されたチャネルを固定することはできません。
論理モデルを特定のチャネルに固定することは、個々のリクエストに触れることなく、そのモデルに対して常に Official を使用することをワークスペースが表明する方法です。配信ポリシー以前のリクエストはデフォルトで Auto になります。クライアントの変更は不要であり、ローンチ時にワークスペースやキーのポリシーの一括バックフィルは実行されませんでした。モデルレベルのコンテキストについては、モデルデータセンターガイドと併せて参照してください。
リクエストを処理した配信ティアの確認方法
リクエストが完了したら、リクエスト記録内の resolvedDeliveryTier を読み取ります。値は verified または official であり、null 値は記録がこのフィールド以前のものであることを意味します。リクエストには requestedDeliveryPolicy も含まれており、これは呼び出し元が何を要求したかを記録します。ワークスペースのデフォルトが適用された場合は null になる可能性があります。
1つのリクエストに対してティアを上書きするには、X-TokenLab-Delivery-Policy ヘッダーを追加します。受け入れられる値は auto、verified、official です。以下はヘッダー単体の例です：
# Claude Sonnet 5 リクエストにこのヘッダーを追加
X-TokenLab-Delivery-Policy: verified
例えば、この cURL 呼び出しは Claude Sonnet 5 をターゲットにし、official を要求します：
curl https://api.tokenlab.sh/v1/chat/completions -H "Authorization: Bearer $TOKENLAB_API_KEY" -H "Content-Type: application/json" -H "X-TokenLab-Delivery-Policy: official" -d '{"model":"Claude Sonnet 5","messages":[{"role":"user","content":"Hello"}]}'
呼び出し後、そのリクエストの記録には以下が含まれます：
{
"requestedDeliveryPolicy": "official",
"resolvedDeliveryTier": "official"
}
リクエスト記録には使用状況フィールドも含まれており、Request Console ガイドでその記録の場所と現在の使用状況フィールド名を確認できます。
要求されたティアに有効なルートがない場合、ゲートウェイは delivery_tier_unavailable を返答し、別のティアに自動的にフォールバックすることはありません。リクエストコンソールでその記録の場所を確認でき、Request Console ガイドで検索方法を説明しています。価格やルートが予期しないものである場合、コンソールとリクエストの証拠からどのティアがトラフィックを処理したかを確認できるため、そこから調査を開始します。
Auto が予期しない配信ティアを選択した場合
Auto が予期しないティアを選択した場合は、リクエストの resolvedDeliveryTier を読み取り、組織がバインドしているチャネルと比較してください。その後、モデルを目的のチャネルにバインドするか、そのリクエストのティアを上書きしてください。これにより、デフォルトのポリシーをシンプルに保ちつつ、予期しないルートを修正する具体的な方法を提供できます。
制限事項
ここでの数値は2026年9月11日時点の読み取りであり、変動します。配信ティアの可用性は、モデルと組織に対してどのルートがアクティブであるかに依存します。チャネルが非アクティブ、削除済み、アクティブな公開配信ティアの欠如、またはモデルの有効なルートがない場合、ワークスペースのバインディングは拒否される可能性があります。配信ティアごとの価格調整は、組織独自のルールに依存します。ソースデータが提供されていないため、普遍的な比較はできません。配信の決定はルート選択後に解決されるため、得られるティアはその時点で組織に対してどのルートが有効であるかに依存します。
FAQ
Auto は実際に何を選択しますか？
Auto はデフォルトのポリシーであり、第3のルートタイプではありません。これは到達可能なパスを保持し、ディスパッチ前にリクエストにかかる最大コストを見積もります。ポリシー以前のリクエストはデフォルトで Auto になります。ディスパッチ後、resolvedDeliveryTier はリクエストが verified または official ルートを通じて処理されたかどうかを記録します。
Verified ルートが Official ルートより高価になるのはなぜですか？
価格は、組織レベルの配信価格調整ルールを通じて配信ティアごとに調整できます。調整は適用前に正規化および検証されます。そのため、差額は構成に依存します。ディスパッチ前に表示される価格を確認してください。
すべてのリクエストで配信ティアを設定する必要がありますか？
いいえ。ワークスペースおよび API キーのポリシー継承が標準的な設定です。2026年9月11日の本番環境の読み取りでは、5,536のワークスペースが明示的な Auto ポリシーを持ち、217がシステムデフォルトを継承し、4,134の API キーすべてがワークスペースから継承していました。継承数は、新規アカウント作成に伴い同週後半に219となりました。これらの数値は、内部リリースリハーサルノートに記録された TokenLab 2.0 ローンチ時の読み取り（2026年9月11日観測）によるものです。公開ベンチマークではなく、内部の本番環境の読み取りとして扱ってください。リクエストごとに配信の選択を上書きできますが、ワークスペースのデフォルト設定で一般的なケースはカバーされます。
どのティアが完了したリクエストを処理したかを知るにはどうすればよいですか？
リクエスト記録内の resolvedDeliveryTier を読み取ってください。値は verified または official であり、記録がこのフィールド以前の場合は null です。requestedDeliveryPolicy は呼び出し元が何を要求したかを示し、ワークスペースのデフォルトが適用された場合は null になります。リクエストコンソールと Request Console ガイドでその記録の場所を確認できます。
有効なルートがないティアを要求した場合はどうなりますか？
ゲートウェイは delivery_tier_unavailable を返答します。別のティアに自動的にフォールバックすることはありません。リクエスト記録を読み取り、一致するルートを有効にするか、要求されたポリシーを変更してください。
API キーを作成し、得られたティアと期待していたティアを比較してください。Request Console ガイドでその記録の場所を確認できます。
出典
- TokenLab changelog: delivery tiers2026-09-19 時点で確認
- TokenLab API documentation2026-09-19 時点で確認
