`JEV_API_KEY` 保有・日本から実測（公式の 70-500ms は「西海岸の自社ラップトップから」なので軸が違う点に注意）。
関連: LLM Wiki id=3746（X学習・公式主張まとめ）
## API 形状
- `POST https://api.typesafe.ai/v1/systemone`
- `Authorization: Bearer
- body: `{state, model:"jev-latest", questions:{<名前>:{type, instructions, criteria?}}}`
- 質問型: `noul`(0-1・criteria無し) / `choice`(criteria=option->説明のobject) / `score`(criteria=レベル説明の配列)
- 返却: `{model, answers, usage{input_tokens, output_tokens}}`。実測の解決版は `jev-1.13.0`
- Python SDK は `typesafe-sdk`。**読む環境変数は `TYPESAFE_API_KEY`**
## 計測結果
| 計測 | 結果 |
|---|---|
| 接続確立(1回・TCP+TLS) | 358ms（TCP単体27ms / TLSが315ms） |
| 持続接続・1問 | median 294ms（min 234 / max 386） |
| 持続接続・5問 | median 278ms（min 243 / max 336） |
| 毎回新規接続(urllib既定) | median 577〜592ms |
| usage(5問) | input 576 / output 107 → 入力コスト $0.0000242 |
## 検証できた公式主張
1. **70-500ms は日本からでも成立**（持続接続なら 234-386ms）。ただし接続を使い回さないと倍になる
2. **「質問を足しても応答時間はほぼ変わらない」は本当**。5問(278ms)が1問(294ms)よりむしろ速い（誤差内）。
並列サンプリングの主張は実測で裏が取れた。**5つの判断を1問分のレイテンシで買える**
3. **型を外さなかった**: choice は定義した4択の中、score はレンジ内
4. **出力トークンは課金されない**（usage に出るが単価0）
## 較正の実例（これが売り）
入力: 「本番デプロイ失敗・顧客に502・nginxは確認済み・深夜2時・オンコール20分無反応」
| 質問 | 結果 |
|---|---|
| urgent (noul) | 0.93 |
| self_diagnosed (noul) | 0.96 |
| route (choice) | backend / conf 0.38（backend 0.53・infra 0.47） |
| severity (score) | 3.35 / conf 0.69 |
| tone (score) | 2.05 / conf 0.81 |
route の confidence 0.38 は**失敗ではなく情報**。nginx確認済みの502は backend/infra が本当に割れる入力で、
「割れている」と正直に返してきた。ここで人間にエスカレーションする設計ができる。
## 統合時の罠（実測で踏んだ）
1. **接続を使い回さないとレイテンシが倍**（577ms→278ms）。`urllib.request` / `requests` の都度呼びは
毎回TLSを張り直す。**Session / keep-alive 必須**
2. **`score` は整数インデックスでなく float**（実測 3.32 / 3.35）。一方 `legend` のキーは `'0'`〜`'4'` の文字列。
**`legend[score]` で直接引くと壊れる**。丸めるか連続値として使う
3. SDK が読む変数名は `TYPESAFE_API_KEY`（手元の `JEV_API_KEY` とは別名）
## 設計への示唆
**複数の判断を1コールに詰めるほど得**。レイテンシがほぼ増えないので、
「1問だけ聞いて分岐→また1問」より「必要な判断を全部まとめて1回」が正解。
公式ドキュメントの「複合的な判断は原子的な質問に分解して自分のコードで合成せよ」という
設計指針は、このレイテンシ特性に裏打ちされている。