トラブルシューティング · API エラーとレート制限 · 2026-09-27 検証

Jev API のエラーとレート制限:完全トラブルシューティングガイド

公式ドキュメントに記載された Jev API の全ステータスコードと SDK エラークラスを一つずつ検証し、実務で使える対処法を提示します。429 レート制限、401 認証、422 ペイロード、529 過負荷、タイムアウトの再試行に加え、「なぜストリーミングがないのか」、公式ステータスページがない中での稼働確認方法まで。

結論から

429 はレート制限の超過です。まず Retry-After ヘッダー(SDK では retry_after_ms / retryAfterMs として参照可能)の示す時間を待ち、それから指数バックオフ+ジッターで再試行します。公式 SDK はデフォルトでまさにこれを行います(リトライ 2 回、0.5 秒から 5 秒まで倍々、Retry-After を尊重)。400/401/403/422 は決して再試行しないこと——これはサーバーの機嫌ではなく、あなた側のバグです。529 は TypeSafe 自身の過負荷:バックオフするかセカンダリエンドポイントへフェイルオーバー。ストリーミングはありません。Jev は 1 リクエストに 1 つの完全な型付き判断を返します。公開ステータスページもないため、最小リクエストでプローブし、ステータスコードを読んで判断します。

本ページのステータスコードと公式の方針は、2026-09-27 に docs.typesafe.ai に対して確認しました。HTTP API リファレンス、Python SDK の Exceptions と Retries リファレンス、JavaScript SDK のエラークラス、System One のコンセプトページです。公式が公表していない部分——具体的な制限値、ステータスページ、ストリーミング——についてはその旨を明記し、一般の HTTP エンジニアリング実践として明確にラベル付けした上で補います。

エラークイックリファレンス表

API と SDK のドキュメントが扱う全ステータスを 1 行ずつ。何が原因で、どう直すべきか、再試行に意味があるのか。HTTP リファレンスが明示するのは 401・422・429・529 の 4 つで、残りは SDK リファレンスが型付きエラークラスとしてカバーします。

ステータスSDK クラス(Python · JS)意味対処法再試行?
400 Bad RequestTypeSafeBadRequestError · BadRequestErrorSDK 例外ページの原文:「リクエストが無効です」。HTTP リファレンスはボディ検証を 422 に割り当てているため、400 は JSON 自体の破損や、検証が始まる前に壊れているリクエストであることがほとんどです。エラーボティを読み、JSON ペイロードをローカルで(zod / pydantic で)検証し、Content-Type ヘッダーが application/json になっているか確認します。再試行しない——リクエストを修正
401 UnauthorizedTypeSafeAuthenticationError · AuthenticationError公式の原文:「API キーがないか無効です。Authorization ヘッダーを確認してください。」キーが存在し、有効で、正しい環境のものかを確認します。呼び出しがサーバー側で行われていることも。ブラウザバンドルに漏れたキーの始末は、緊急ローテーションでしかありません。再試行しない——資格情報を修正
403 Permission DeniedTypeSafePermissionDeniedError · PermissionDeniedErrorSDK の説明は「アクセスが拒否されました」。キー自体は有効でもこのリソースを使う権限がない状態です。一般の REST セマンティクスではプラン・リージョン・エンタイトルメントの問題に当たります。HTTP リファレンスはこのステータスを詳説していないため、レスポンスボディを正としてください。プロバイダーのダッシュボードでキーのプランと権限を確認し、プランが実際に許可するモデル ID を確かめます。再試行しない——権限の問題
404 Not FoundTypeSafeNotFoundError · NotFoundErrorパスかメソッドの間違いです。評価エンドポイントは POST https://api.typesafe.ai/v1/systemone。/v1/systemOne のようなタイプミスや、うっかり GET にするとここに落ちます。URL を /jev-api のエンドポイント表と一文字ずつ照合します。ゲートウェイはパスが異なります。Vercel AI Gateway と OpenRouter にはそれぞれ固有のパスがあります。再試行しない——URL を修正
422 Unprocessable EntityTypeSafeUnprocessableEntityError · UnprocessableEntityError公式の原文:「リクエストボディが検証に失敗しました。必須フィールドの欠落や、不正な形式の question などが例として挙げられます。」ボディには問題のフィールドが示されます。リクエストには model・state・questions が必須で、各 question には type(choice / score / noul)・instructions・criteria が必要です。ボディが指摘したフィールドを直してから再実行します。再試行しない——スキーマを修正
429 Too Many RequestsTypeSafeRateLimitError · RateLimitError公式の原文:「レート制限を超えました。少し待ってから再試行してください。」Retry-After ヘッダーがあれば、SDK は要求された待ち時間を retry_after_ms / retryAfterMs として解析します。ヘッダーが示す時間だけ待ち(なければ指数バックオフ+ジッターで代替)、クライアント側の同時実行数を制限し、それでもだめならプロバイダーへの制限引き上げを検討します。再試行可——まずバックオフ
529 OverloadedTypeSafeInternalServerError family · not a standard statusTypeSafe 固有のステータスで、公式の原文は「TypeSafe が一時的に過負荷です。少し待ってから再試行してください。」明確にプロバイダー側の状況を示す、唯一のステータスコードです。まずバックオフし、続くようならセカンダリエンドポイントへフェイルオーバー。/jev-api ガイドの 1500ms サーキットブレーカーがまさにこのパターンです。再試行可——またはフェイルオーバー
5xx server errorsTypeSafeInternalServerError · InternalServerError公式の説明は「サーバーがリクエストを処理できませんでした」。基本は一時的障害として扱います。ただし、同じエンドポイントだけが繰り返し失敗し、別が正常なら話は別です。バックオフ付きで再試行。SDK のデフォルト再試行集合には 5xx 全体が入ります。片方のエンドポイントだけが失敗し続けるなら、粘るよりフェイルオーバーです。再試行可——SDK デフォルト
No HTTP responseTypeSafeAPIConnectionError · APIConnectionErrorレスポンスを受け取る前にリクエストが失敗した状態です。DNS、TLS、ファイアウォール、あるいは自側のアウトバウンド(egress)ルールが原因で、API 自体とは無関係です。本番を束ねるマシンからネットワーク経路を確認します。ノート PC からのプローブはサーバーについて何も証明しません。SDK は接続エラーをデフォルトで再試行します。再試行可——SDK デフォルト
Request timeoutTypeSafeAPITimeoutError · APITimeoutErrorリクエストが設定したタイムアウトを超えました。SDK のエラーには発火したタイムアウト設定が乗ります。判断は 1 回の順伝播で数十〜二百 ms 程度。タイムアウトは予算か経路の問題であって、モデルのせいではありません。タイムアウトを p99 まで引き上げるか、タイトなままフェイルオーバーします(/jev-api のパターンは 1500ms)。SDK はタイムアウトをデフォルトで再試行します。再試行可——SDK デフォルト
Invalid response bodyTypeSafeAPIResponseValidationError · —2xx が返ってきたのに、ボディに必須データがないか構造が不正です。Python クラスは field_path(例:answers.tone.confidence。ドキュメント記載の例)を公開しています。HTTP エラーではなく SDK 側の検証失敗です。field_path と送信したモデル ID をログに残します。モデル識別子を固定し、プロバイダーのモデル更新後には盲目的な再試行ではなく重点的に再確認します。調査優先——ループ禁止

SDK 列は Python クラスと JavaScript の対応クラスを並べています。すべての HTTP エラーには x-typesafe-request-id レスポンスヘッダーが付きます(SDK のエラーオブジェクトでは request_id / requestId)。サポートに連絡する際はこれを添えてください。HTTP リファレンスに明記された 4 つ以外のステータスは、SDK リファレンスと標準的な HTTP セマンティクスに基づいて解説しています。

失敗している呼び出しを、動くサンプルリクエストと照合する

レート制限:公式が約束するもの、エンジニアリングが補うもの

公式の言葉は短い。しかし使える戦略は短くない。

公式ドキュメントが実際に言っていること

  • 429 の公式文はこうです:「レート制限を超えました。少し待ってから再試行してください。」529 はこうです:「TypeSafe が一時的に過負荷です。少し待ってから再試行してください。」
  • API リファレンスは「即座に再試行せず、指数バックオフで再試行すること」を求め、公式クライアント SDK がデフォルトのリトライポリシーで自動処理すると明記しています。
  • 数値の制限は一切公表されていません。1 秒あたりのリクエスト数も、同時実行数も、日次クォータも。正確な RPS の数字を挙げる情報源はすべて推測です。実際に受け取った 429 と、サーバーが送る Retry-After ヘッダーから、自分の上限を逆算してください。
  • SDK はデフォルトで 429 を再試行対象とし、デフォルトで Retry-After を尊重します(respect_retry_after=True。Retry-After と retry-after-ms の両方を読みます)。
  • すべての HTTP エラーには x-typesafe-request-id ヘッダーが付きます。サポートに連絡する前に控えておきましょう。

一般の HTTP エンジニアリングが補うこと(公式の Jev 動作ではありません)

  • ジッター付きの指数バックオフ:delay = random(0, min(cap, base × 2^n))。形状は SDK デフォルト(0.5 秒から 5 秒へ倍々)と同じです。スケールするほどジッターが効きます。1000 クライアントが同じ秒に再試行すれば、また一斉に制限にぶつかります。
  • Retry-After が出たらそれに従う。サーバーが「あとどれだけ」に答えてくれているのです。それより速くポーリングすれば、リセットされるだけです。
  • リトライに予算を設ける。SDK のデフォルトは 1 呼び出し 30 秒の総予算内で 2 リトライ。素の HTTP クライアントにも同じ種類の停止条件が要ります。無限ループではありません。
  • 429 を 2 つの原因に分ける。バーストのペース配分は自分側の問題——バックオフとクライアント側の同時実行制限で直します。クォータやクレジットの枯渇は課金の問題——バックオフは効きません。ダッシュボードを監視し、上限に達する前にアラートを。
  • 正当なトラフィックなのに 429 が続くなら、負荷を逃がしてください。ユーザーをリトライの列の後ろに並ばせるのではなく、セカンダリエンドポイントか決定論的なフォールバック規則へ回します。
バックオフで足りないとき:信頼度ゲート付きフォールバックチェーン

リトライのプレイブック:Python と TypeScript

コピーして出発点にできる実装です。最初の 2 つは上の一般論をコードにした素の HTTP クライアント、3 つ目は公式 SDK に全部やらせる形です。

Python での素の HTTP リトライ(requests)

python · raw http

どんなときに使うか

requests や httpx で POST /v1/systemone を直接呼び、リトライロジックを自前のコードに見えておきたい方向け。408・429・5xx 系(529 を含む)を再試行し、Retry-After を尊重し、検証・認証エラーは決して再試行しません。

python · raw http
# jev_retry.py — raw-HTTP retry for POST /v1/systemone.
# Documented statuses: 401 · 422 · 429 · 529 (docs.typesafe.ai/api.md).
# The retry mechanics below are general engineering practice — the official
# docs publish no numeric limits, so none are assumed here.
import os
import random
import time

import requests

URL = "https://api.typesafe.ai/v1/systemone"
# Mirrors the official SDK's default retryable set ({408, 429, all 5xx});
# 529 is listed explicitly — it is TypeSafe's documented overload status.
RETRYABLE = {408, 429, 500, 502, 503, 504, 529}


def evaluate(state: str, questions: dict, max_attempts: int = 4) -> dict:
    delay = 0.5  # first backoff; doubles per attempt, capped at 5 s (SDK shape)
    resp = None

    for _ in range(max_attempts):
        resp = requests.post(
            URL,
            headers={
                "Authorization": f"Bearer {os.environ['TYPESAFE_API_KEY']}",
                "Content-Type": "application/json",
            },
            json={"model": "jev-latest", "state": state, "questions": questions},
            timeout=5.0,
        )
        if resp.status_code < 400:
            return resp.json()

        if resp.status_code not in RETRYABLE:
            # 400/401/403/404/422: identical bytes in, identical error out.
            resp.raise_for_status()

        # Honor the server's requested wait when it sends one:
        # Retry-After (seconds). The official SDK also parses retry-after-ms.
        wait = resp.headers.get("Retry-After")
        sleep_s = (
            float(wait) if wait else min(delay, 5.0) * random.uniform(0.75, 1.0)
        )
        time.sleep(sleep_s)
        delay *= 2

    resp.raise_for_status()  # budget spent on a retryable status
    raise RuntimeError("retry budget spent")

再試行集合は公式 SDK のデフォルト({408, 429, 全 5xx})に合わせ、可読性のため 529 を明示しています。5 秒の上限はドキュメント済みの backoff_max に対応します。

TypeScript:タイムアウト+バックオフ+フェイルオーバー

typescript · fetch

どんなときに使うか

サーバー側 TypeScript の経路です。各試行に 1500ms の中止予算(/jev-api ガイドと同じサーキットブレーカー値)を与え、再試行可能なステータスはもう一度やり直し、予算が尽きたら throw して呼び出し側がセカンダリへフェイルオーバーできるようにします。

typescript · fetch
// lib/jev-retry.ts — per-attempt timeout, backoff with jitter, Retry-After
// handling, and a throw the caller can fail over on. The 1500 ms abort budget
// is the same circuit-breaker number used by the failover adapter on /jev-api.
const PRIMARY = 'https://api.typesafe.ai/v1/systemone';
// Mirrors the official SDK default ({408, 429, all 5xx}) + the documented 529.
const RETRYABLE = new Set([408, 429, 500, 502, 503, 504, 529]);

type Contract = { state: string; questions: Record<string, unknown> };

export async function evaluateWithRetry(
  contract: Contract,
  {
    attempts = 4,
    timeoutMs = 1500,
  }: { attempts?: number; timeoutMs?: number } = {},
): Promise<unknown> {
  let last: Response | undefined;

  for (let attempt = 0; attempt < attempts; attempt++) {
    if (attempt > 0 && last) {
      // Wait at least what the server asked for: retry-after-ms is the
      // millisecond form the official SDK understands; Retry-After is seconds.
      const msForm = Number(last.headers.get('retry-after-ms'));
      const sForm = Number(last.headers.get('retry-after')) * 1000;
      const asked = Number.isFinite(msForm) ? msForm : sForm;
      // ...then add full jitter on top: random(0, min(cap, base * 2^n)).
      const base = Math.min(500 * 2 ** (attempt - 1), 5000);
      await new Promise((r) =>
        setTimeout(r, Math.max(asked || 0, Math.random() * base)),
      );
    }

    const controller = new AbortController();
    const timer = setTimeout(() => controller.abort(), timeoutMs);
    try {
      const res = await fetch(PRIMARY, {
        method: 'POST',
        headers: {
          'Content-Type': 'application/json',
          Authorization: `Bearer ${process.env.TYPESAFE_API_KEY}`,
        },
        body: JSON.stringify({ model: 'jev-latest', ...contract }),
        signal: controller.signal,
      });
      // 2xx, or a fix-the-request 4xx: hand it back either way.
      if (!RETRYABLE.has(res.status)) return res.json();
      last = res; // 408/429/5xx/529: back off and go around again
    } catch (err) {
      if (attempt === attempts - 1) {
        throw new Error('Jev unreachable after retries');
      }
      // AbortError / network failure: fall through and retry.
    } finally {
      clearTimeout(timer);
    }
  }

  // Budget spent on retryable statuses — surface where it died so the caller
  // can fail over to a secondary endpoint (see the adapter on /jev-api).
  throw new Error(`Jev still failing: HTTP ${last?.status ?? 'no response'}`);
}

フルジッターの遅延は 5 秒で頭打ち。SDK のドキュメント済み backoff_max と一致します。レスポンスに retry-after-ms があればそれに従います。公式 SDK が解析するのもこのミリ秒形式です。

公式 SDK にリトライさせる(Python)

python · typesafe-sdk

どんなときに使うか

地味で正しい選択肢です。ドキュメント済みのデフォルトは、408/429/5xx と接続・タイムアウトエラーの再試行に、指数バックオフ・ジッター・Retry-After 処理まで済ませています。再実装ではなくチューニングを。

python · typesafe-sdk
# The official Python SDK retries for you. Defaults below are the documented
# ones (docs.typesafe.ai/sdk/python/api/retries.md), shown explicitly so you
# can tune rather than reinvent:
from typesafe_sdk import RetryPolicy, TypeSafeClient

client = TypeSafeClient(
    retry=RetryPolicy(
        max_retries=2,             # default: 2 retries (three attempts total)
        backoff_initial=0.5,       # first backoff, seconds — doubles each attempt
        backoff_max=5.0,           # ceiling for the exponential growth
        backoff_jitter=0.25,       # random fraction subtracted from each delay
        timeout=30.0,              # total budget per SDK call, in seconds
        # default is {408, 429, all 5xx}:
        http_statuses={408, 429, 500, 502, 503, 504},
        respect_retry_after=True,  # honors Retry-After / retry-after-ms headers
    ),
)

# Connection errors and timeouts are retried by default too. When the budget
# is spent on a 429, the SDK re-raises TypeSafeRateLimitError — its documented
# retry_after_ms attribute carries the server's requested wait in
# milliseconds (None when the header is absent):
#
#     import time
#     from typesafe_sdk import TypeSafeRateLimitError
#
#     try:
#         decision = run_evaluation(client, state, questions)
#     except TypeSafeRateLimitError as err:
#         time.sleep((err.retry_after_ms or 5_000) / 1000)
#         decision = run_evaluation(client, state, questions)

公式 Retries リファレンスのデフォルトを明示しています。max_retries 2、backoff_initial 0.5 秒、backoff_max 5 秒、ジッター 0.25、予算 30 秒。予算を使い切ると最後のエラーが再スローされます。TypeSafeRateLimitError を捕まえて retry_after_ms を読んでください。

再試行するかしないか:分類

SDK のデフォルト再試行集合は {408, 429, 全 5xx} に接続エラーとタイムアウトを加えたもの——それ以外は自分で直す対象です。素の HTTP でも同じ分類が使えます。

再試行する——待ってから

408 リクエストタイムアウト、429 レート制限、529 過負荷を含む 5xx 全般、接続失敗、自分のタイムアウト。これらは「今はだめ」であって「ずっとだめ」ではありません。試行の間は待つこと——バックオフ+ジッター——そして試行回数に上限を。

再試行しない——まず修正

400・401・403・404・422。同じバイト列を送れば同じエラーが返ります。壊れたボディ、欠落または無効なキー、権限の問題、間違ったパス、スキーマ違反。エラーボディを読み(422 は該当フィールドを明示します)、送り直す前に修正してください。

予算と課金

リトライは課金対象の呼び出しです。入力トークンは毎試行ごとに課金され、Jev に出力トークンの課金はありません——判断は生成テキストではないからです。試行回数に上限を設け、時間予算を明示し、429 の発生率には黙って耐えるのではなくアラートを。

API が初めてなら、入門ガイドから

なぜストリーミングがないのか

「Jev streaming」という疑問に、正直に答えます。

公式ドキュメントは評価エンドポイントにストリーミングやサーバー送信イベントのモードを記載していませんし、コンセプトページが、なぜ不要なのかを説明しています。Jev は「生成テキストではなく、型付きの判断と確率を返す」もので、「返信を書かず、コードを作らず、説明を生成しない」。トークンがひとつずつ流れ出ることはありません。トークンがないのですから。リクエストを 1 回送れば、完全な JSON レスポンスが 1 つ返ってきます。3 つの公式エンドポイントの典型的なレイテンシは数十〜二百 ms 程度(/jev-api の比較では 80〜190ms)。

だから、「Jev streaming」で答えが形になっていく様を見たい人には——その答えは、最初のチャンクを描画する前にすでに完成しています。ストリーミングできるのは自分のワークフローです。1 回のリクエストが飛んでいる間に、ハンドラから「キューイング → 評価中 → 判断済み」イベントを出す。これは体感速度のための一般のエンジニアリングであって、API の機能ではありません。

サードパーティの「ストリーミング Jev」ラッパーは疑ってかかってください。モデルは判断の途中経過を出力できません。流れてくるものは、向こう側でバッファして切り貼りしたものです。遅延のコストを払って、見せかけを買っているだけです。

エンドポイント・プロトコル・フェイルオーバーアダプタの全体解説

ステータスとヘルスチェック:ステータスページなしで Jev の生存を確かめる

公開ステータスエンドポイントの記載はありません。実務上の代用法です。

まず正直なところから:公式ドキュメントに /health エンドポイントも公開ステータスページもありません。2026-09-27 にドキュメント索引全体を確認しました。実務上の代用は、最小のスモークリクエストを送り、そのステータスコードを正しく読むことです。

下のプローブは最小の有効ペイロード——小さな state と 1 つの Noul 質問——を送り、HTTP ステータスだけを表示します。本番コードと同じネットワーク経路から実行してください。ノート PC からのプローブで分かるのは、ノート PC の状況だけです。

本サイト独自のリレー /api/jev/evaluate を使う場合、その制限は当サイトのものであり TypeSafe のものではありません。Cloudflare Turnstile 検証、10 秒あたり 5 リクエストのバースト上限、32KB のボディ上限、日次クォータ。リレーからの 429 はサイトのクォータであって、上流のレート制限ではありません。

ダッシュボードには一般論が適用できます。429 の発生率、p95 レイテンシ、529 の頻度を事実上のヘルスメトリクスとして追跡し、単一イベントではなく傾向にアラートを。

スモークテスト(cURL)
# Minimal smoke test: tiny state, one Noul question, print only the status.
#   200 = healthy · 401 = key problem · 429 = pacing problem
#   529 = provider overloaded · no response = your network path
curl -s -o /dev/null -w '%{http_code}\n' -X POST https://api.typesafe.ai/v1/systemone \
  -H "Authorization: Bearer $TYPESAFE_API_KEY" \
  -H 'Content-Type: application/json' \
  -d '{
    "model": "jev-latest",
    "state": "health check probe",
    "questions": {
      "alive": {
        "type": "noul",
        "instructions": "Confirm the evaluation service responds",
        "criteria": {
          "ok": "The service returned any decision",
          "down": "No decision is available"
        }
      }
    }
  }'

スモークテストの読み方

200 OK

健全です。完全な型付きの判断が返ってきました。直すべきものはありません。

401 Unauthorized

サービスには到達し、キーが拒否された状態。原因はこちら側にあります。キーの欠落、ローテーション済み、環境違い。再試行せず資格情報を修正します。

429 Too Many Requests

サービスは正常で、制限を超えたのはこちら側。ペース配分かクォータです。バックオフしてから再プローブし、回復を確認します。

529 Overloaded

プロバイダー側の過負荷です。公式の表現は「一時的に過負荷」。待ち、続くようならセカンダリへフェイルオーバーします。

Timeout / no response

API を疑う前に、アウトバウンド経路・DNS・タイムアウトタイマーを確認します。

表示はステータスコードのみ。ヘルスチェックに判断内容は関係ありません。プローブは通常のレート内に収めてください。429 を起こすスモークテストは何かを教えてくれますが、知りたいことではありません。

別の確認方法:Playground で実際の判断を試す

Jev API のエラーとレート制限:よくある質問

Jev API が 429 を返し続けるのはなぜですか?

レート制限を超えたからです。公式の指示は「少し待ってから再試行」。数値の制限は公表されていないため、対処は機械的です。Retry-After ヘッダー(SDK では retry_after_ms / retryAfterMs)を読み、指数バックオフ+ジッターで再試行し、クライアント側の同時実行数を制限する。公式 SDK はデフォルトで 429 を再試行します(2 リトライ、Retry-After を尊重)。適切なバックオフを行っても 429 が続くなら、原因はペース配分ではなくクォータかクレジットの枯渇であることが多い。ダッシュボードを確認してください。バックオフは課金を直せません。

Jev API はどのエラーコードを返しますか?

HTTP リファレンスが明示するのは 4 つ:401 Unauthorized(キーがないか無効)、422 Unprocessable Entity(ボディの検証失敗)、429 Too Many Requests(レート制限)、529 Overloaded(TypeSafe の一時的な過負荷)、さらに一般の 5xx 系です。SDK 側は型付きクラスに対応します。BadRequestError(400)、AuthenticationError(401)、PermissionDeniedError(403)、NotFoundError(404)、UnprocessableEntityError(422)、RateLimitError(429)、InternalServerError(5xx)に、接続・タイムアウト・レスポンス検証のクラスが続きます。対処法付きの一覧は上の表を。

Jev API のタイムアウトはどう再試行すべきですか?

タイムアウトと接続エラーはデフォルトで再試行対象です。SDK は両方を再試行します。すべての呼び出しに明示的なタイムアウト予算を与えてください。SDK のデフォルトは 1 呼び出し 30 秒の総予算で、本サイト /jev-api のフェイルオーバーパターンは 1500ms のサーキットブレーカーでエンドポイントを切り替えます。試行間は指数バックオフ+ジッターで、試行回数にも上限を。Jev の判断は 1 回の順伝播で数十〜二百 ms 程度なので、タイムアウトはほぼ常に予算かネットワーク経路の問題であり、モデルのせいではありません。

Jev API はストリーミングに対応していますか?

いいえ。公式ドキュメントにストリーミングや SSE のモードは記載されておらず、アーキテクチャ的にも不要です。Jev は生成テキストではなく型付きの判断と確率を返すもので、返信を書かず、コードを作らず、説明を生成しません。1 リクエストに 1 つの完全な JSON レスポンス。体感速度が欲しいなら、ハンドラから自分のワークフロー状態(「キューイング → 評価中 → 判断済み」)をストリーミングしてください。それはアプリケーション側のエンジニアリングであって API の機能ではありません。サードパーティの「ストリーミング Jev」ラッパーは疑ってください。モデルは判断の一部だけを出力できません。

公式の Jev API ステータスページはありますか?

記載されているものはありません。2026-09-27 時点で、公式ドキュメントにヘルスエンドポイントも公開ステータスページもありません。実務上の代用は、本番のネットワーク経路から最小の有効リクエストを送り、ステータスを読むことです。200 は健全、401 はキー、429 はペースかクォータ、529 はプロバイダー側の過負荷、応答なしなら自分のネットワーク。サポートに連絡する際は、失敗した呼び出しの x-typesafe-request-id レスポンスヘッダーを添えてください。SDK はすべての HTTP エラーでこれを request_id / requestId として公開します。

Jev のレート制限の具体的な数値は?

公式には公表されていません。リファレンスには 1 秒あたりのリクエスト数、同時実行数、日次クォータの数値がなく、正確な数字を挙げる情報源はすべて推測です。自分の上限は実測で逆算してください。受け取った 429 レスポンスと Retry-After ヘッダーから読み取り、クライアントはトークンバケットでペース制御します。429 を起こして限界を探るよりずっと安上がりです。SDK のドキュメント済みリトライデフォルト(2 リトライ、0.5 秒から 5 秒へ倍々、ジッター 0.25)は再試行の形状を示すもので、制限値そのものではありません。

リトライしても入力トークンの課金は発生しますか?

発生します。リトライは課金対象の呼び出しで、試行ごとに入力トークンが課金されます。一方で Jev は判断を生成テキストとして作らないため、出力トークンの課金はありません。だからこそ試行回数に上限を設け、時間予算を明示し、429 の発生率には黙って耐えるのではなくアラートを張ることが重要です。