Jev Playground が実際に叩いているもの — キーを取得したら何が変わるか

同じモデル、3 つの入り口

Playground の裏にあるものはモックでもデモビルドでもありません：匿名の訪問者は 1 日 30 回、サインインした訪問者は 50 回の Playground 実行ができ、どれもクレジットで支払われない実際の上游推論を実行しています。Playground のクォータは IP から導出したスコープで区切られており（ハッシュ化されるため、生のアドレスがログに残ることはありません）、ブラウザで見える JSON はキー付きの呼び出しが返す形状そのものです。

本番での 3 つの違い

• エンドポイント：/api/playground（ブラウザセッション）対 /api/v1/systemone（Bearer キー）。
• 認証：Playground は訪問者ごとに実行回数を区切ります。API はすべてのリクエストをワークスペースのキーで認証します。
• クォータ：1 日あたりの実行上限対プランのレート制限（free 20 req/min、Starter 120/分、Pro 600/分、Team 2,000/分）プラスクレジットの消費。

それ以外はすべて共通です：同じリクエストスキーマ（1〜8 の名前付き質問、最大 100,000 文字の state）、確率と confidence を伴う同じ回答形状、同じエラーコード — 唯一、Playground は 401 も 402 も返しません。そこでは何もクレジットを消費しないためです。

上限が存在する理由

上限はまず支出の天井であり、その次に製品上の判断です：Playground の実行はクレジットで支払われない実際の推論なので、上限は無料トラフィックがかけられるコストを区切ります。日次のリセットはワークスペース単位ではなく訪問者単位なので、チームでプールして無料枠を広げることはできません — 登録時の 5 クレジットと API キーはそのためのものです。

1 日の上限のメッセージが表示されたら、進むべき道は API キーです：5 無料クレジットはまさに「ブラウザで検証した」から「数百件の実際の呼び出しを送っている」への橋渡しをカバーします。この 2 つの世界の間で変わるのは Authorization ヘッダーと URL だけです。

現実的な移行の順序

• Playground（無料）で criteria の文言を反復し、実ケース 10 件が自分なら下す判断を返すまで調整します。
• 登録してキーを作成し、まったく同じリクエストボディを Bearer ヘッダーの下で実行します — これでワークロードの実際の使用トークンと latency_ms が観測できます。
• ラッパーをフィーチャーフラグの背後に置き、トラフィックの 5% から開始します。リクエストごとに request_id とポリシーのアクションをログに残します。
• しきい値が推測ではなく観測された分布の上に立ったら、スケールアップします。

所有権について最後にもう一点：ワークスペースが課金とアクセスの境界です。キーはワークスペースに属し、クレジットもワークスペースに属します。Team では各メンバーが残高を共有するキーを作るため、キーのローテーションと失効はワークスペース単位で行ってください。

初日に想定すべきレート制限の数字

最初の API バーストはたいてい、free ティアの X-RateLimit にぶつかります：1 分 20 リクエスト、同時 1 呼び出しです。ヘッダーは待つべき時間を正確に教えてくれ（Retry-After と、epoch 秒での X-RateLimit-Reset）、単純なクライアント側のセマフォ — 実行中は 1 リクエスト、プランのレートでトークンを補充 — は 429 をエラーからスケジューリングに変えます。Starter のボリュームなら単純な逐次ループでも十分です。1 秒あたり数リクエストを超えるならセマフォが必要になり、Starter 以上のプランでは 1 分あたりの数字より同時実行数の許容量が重要になります。

レスポンス、全体像

{
  "request_id": "req_fe17d05411092c4f7f97947a",
  "model": "jev-1.14.0",
  "answers": {
    "refund_requested": { "type": "noul", "noul": 0.28 },
    "policy_supports":  { "type": "noul", "noul": 0.98 }
  },
  "usage": {
    "input_tokens": 401,
    "output_tokens": 39,
    "credits": 0
  },
  "latency_ms": 523
}

ここで credits: 0 になっている点に注目 — これが Playground の課金上の署名です。Bearer キーの下では同じリクエストは credits: 1（入力 401 トークンは切り上げで 1 クレジット）と credits_remaining の残高を表示します。それ以外はすべて同一です。だからこそ Playground は信頼できるリハーサル段階なのです。