Jevの応答時間 日本から141回直列で実測
2026-09-21 に日本から TypeSafe の Jev を、接続を使い回すコードを書かずに urlopen を1回ごとに呼ぶ作りで141回呼び出したところ、通信を含む応答時間は最小552ms・中央値647ms・最大812msで、500ms以下だった回は0回でした。公式ブログの End-to-end response time is 70ms-500ms for TypeSafe. の文には入力の長さ・接続の条件・計測区間・計測地点が添えられていないため、この記録と条件をそろえて並べることができず、どちらが速いか遅いかも比べられません。
この記事は、業務システムに Jev の判定を1件ずつ組み込むときの前提値として、公式の 70ms-500ms をそのまま置くか、自分の環境で測り直すかを決めるための記録です。測った条件、公式の記載、測れていない区間を並べます。
- 最終確認
- 2026-09-21
- 確認方法
- 日本国内の端末から Jev の API を Python で呼び出し、1回ごとの所要時間と入力トークン数を CSV に記録。公式側は TypeSafe AI のブログ1ページとドキュメント7ページを取得
- 回数
- 直列 141回（47件×3周）、8本並列 47回（条件が違うため別に集計）
- 扱わないもの
- 回答の正しさ、入力に使った文章の内容
- 更新周期
- 定期更新なし（再計測したときに追記）
この記事は何を、どういう条件で測ったか
測ったのは、Python の標準ライブラリで Jev の API（https://api.typesafe.ai/v1/systemone）を呼び、送信の直前から応答の読み込みが終わるまでの時間です。入力は、当サイトの運営元が運営する Instagram アカウントの投稿キャプション47件（日本語）で、同じ47件を3周、1回ずつ順に送りました。
| 項目 | 直列の計測（主題） | 並列の計測（参考） |
|---|---|---|
| 記録ファイル | jev_latency.csv（141行） | jev_result.csv（47行） |
| 実行した日時 | 2026-09-21。CSV に時刻の列は無く、分かるのはファイルの更新時刻 14:37:11（JST）です | 2026-09-21。同じくファイルの更新時刻 14:29:29（JST） |
| 実行した場所 | 日本国内（都市・回線の種類・有線か無線かは記録なし） | 同左 |
| クライアント | Python の urllib.request（標準ライブラリ）。Python の版は記録なし | 同左 |
| 接続 | 1回ごとに urllib.request.urlopen を呼ぶ。接続を保持して使い回すコードは書かれていない | 同左。ThreadPoolExecutor(max_workers=8) で8本同時 |
| 送信したモデル名 | jev-latest | jev-latest |
応答の model | 141行すべて jev-1.13.0 | 47行すべて jev-1.13.0 |
| 質問の数 | 1問（cta：キャプションの末尾が読者に求める行動を4択で選ぶ） | 2問（area と cta。cta の選択肢の説明文も直列とは文面が違う） |
| 入力の前処理 | なし（キャプションをそのまま送る） | 全投稿に共通する定型文の行を除いてから送る（strip_boilerplate） |
| 1件あたりの入力トークン | 最小479／中央値578／最大880（3周とも同じ値） | 最小759／中央値873／最大1,159 |
| 計測区間 | time.perf_counter() を urlopen の前で取り、json.load の後で取った差 | 同左（各スレッドが自分の1回分を測る） |
| タイムアウト | 60秒（timeout=60） | 同左 |
計測区間は、コードから読み取れる範囲で書いています。urlopen を呼ぶ前から応答の JSON を読み終えるまでなので、各回の値には、urlopen の中で行われる処理（接続を張る処理があればそれも）・送信・サーバー側の処理・応答の受信がまとめて入っています。各回に接続を張り直したかどうかそのものは記録しておらず、この中の内訳も、この計測では取っていません。
直列と並列は、質問の数、選択肢の文面、入力の前処理が違います。このため、この記事では2つを別々に集計し、応答時間・入力トークン・費用のいずれも「同じ47件の1回分」として並べていません。
TypeSafe は応答時間を公式にどう書いているか
応答時間の数字は、公式ブログ記事の比較表に End-to-end response time is 70ms-500ms for TypeSafe. と書かれています。この文にも同じ表の行にも、入力の長さ、接続の条件、End-to-end がどこからどこまでかの記載はありません。計測地点については、同じ記事の別の節に our published evals are generally run from our laptops on the West Coast と書かれています。
| 記載箇所 | 表記（原文のまま） | 同じ箇所に書かれている条件 |
|---|---|---|
ブログ記事 Introducing System One Models & Jev の比較表 Speed の行 | End-to-end response time is 70ms-500ms for TypeSafe. | 続く文に for System One shaped queries とある。入力の長さ・接続・計測区間の記載はなし |
同じ比較表の Use cases の行 | Real-time applications. 100ms speeds means you can use AI in your applications where UX is critical. | 条件の記載はなし |
同じ記事の Evidence / Technical Results | Speed per call: We truly are that fast, though our published evals are generally run from our laptops on the West Coast (this is where our service is currently based). | 計測地点（West Coast のラップトップ）とサービスの所在の記載。どの数字についての条件かは、この文には書かれていない |
ドキュメント Parallel questions クックブック | 13問を1回にまとめた呼び出しが 0.27s、13回に分けた呼び出しの合計が 2.71s | 入力は ~54,000-character article（GDPR の Wikipedia 記事）、5回の平均。SDK の client.system_one の呼び出しを perf_counter() で挟んだ値。計測地点の記載はなし |
ブログ記事の比較表では、Existing LLMs の列に End-to-end response time is 3 to 329 seconds for frontier models.、System One + Jev の列に上の文が並んでいます。
【引用】End-to-end response time is 70ms-500ms for TypeSafe. This can range from 40x-200x faster for the same levels of frontier intelligence for System One shaped queries.
【訳】TypeSafe では、端から端までの応答時間は70ミリ秒から500ミリ秒です。System One の形をしたクエリで、同じ水準のフロンティアの知能に対して40倍から200倍速い範囲になりえます。
【引用】Speed per call: We truly are that fast, though our published evals are generally run from our laptops on the West Coast (this is where our service is currently based).
【訳】呼び出しごとの速度：同社は本当にそれだけ速い。ただし、同社が公開している評価は、たいてい西海岸（West Coast）にある同社のラップトップから実行しています（同社のサービスが現在置かれているのがそこです）。
ドキュメントとブログの計8ページ（下の出典一覧の1〜8）で、ms・millisecond・latency・region・West Coast などの語を検索した範囲では、70ms-500ms について入力の長さ・接続の使い回しの有無・計測区間を書いた記載は見つけられませんでした。サービスを提供するリージョンやデータセンターの所在を書いた記載も、この8ページでは上の West Coast の文のほかに見つけられませんでした。milliseconds の語は SDK の例外のページにも出てきますが、The server's requested wait in milliseconds という再試行の待ち時間の説明です。
料金は docs.typesafe.ai/models の表に書かれています。Price (per Btok / per Mtok) の行が $42 / $0.042 で、その下に Charged per input token. Output tokens are free. とあります。同じページのエイリアスの表では、jev-latest の指す先が jev-1.13.0 です（2026-09-21 14:56 JST 取得）。
倍率（40x-200x など）が何に対する値か、LLM 側の 3 to 329 seconds のリンク先がどこかは、公式ページの記載を並べた別の記事で扱っています（TypeSafe Jevの倍率 公式28件で確認）。
日本から直列で141回呼んだ応答時間はどうだったか
141回の応答時間は、最小552ms・中央値647ms・90%値699ms・最大812msでした。500ms以下だった回は0回、600ms未満が21回、700ms未満が127回です。
| 集計 | 全141回 | 1周目（47回） | 2周目（47回） | 3周目（47回） |
|---|---|---|---|---|
| 最小 | 552ms | 552ms | 580ms | 571ms |
| 中央値 | 647ms | 647ms | 641ms | 661ms |
| 90%値 | 699ms | ― | ― | ― |
| 最大 | 812ms | 801ms | 799ms | 812ms |
90%値は、141回の値を小さい順に並べた127番目の値です。スクリプトが使っている計算（lat[min(len(lat) - 1, int(len(lat) * q))] に q=0.9 を渡す形。0から数えて126番目）に合わせており、値の間を補間していません。中央値は小さい順の71番目です。
50ms刻みの度数は次のとおりです。
| 応答時間 | 回数 |
|---|---|
| 500〜549ms | 0 |
| 550〜599ms | 21 |
| 600〜649ms | 53 |
| 650〜699ms | 53 |
| 700〜749ms | 10 |
| 750〜799ms | 2 |
| 800〜849ms | 2 |
| 合計 | 141 |
記録された141回は、いずれも応答の JSON から usage.input_tokens と model を読み取れています。スクリプトは例外を捕まえない作りで、途中で1回でも失敗すれば CSV は書き出されません。ただし、この CSV より前に実行して失敗した試行があったかどうかは記録に残っていないため、失敗の割合はこの記録からは出せません。
8本並列で呼んだとき、1件あたりの応答時間はどうだったか
並列の計測は、質問が2問で、入力から定型文を除いている点が直列と違います。その条件で8本同時に47回呼んだ1件ごとの応答時間は、最小560ms・中央値650ms・最大805msでした。
並列の記録は、Jev に投稿を2つの観点で分類させてその結果を確かめるために書かれたスクリプト（jev_test.py）の出力で、応答時間を測ることを主目的に組んだものではありません。質問が2問あること、定型文を除いてから送っていることは、いずれもこのスクリプトの設定で、直列の計測とは別の目的で決められています。
| 集計 | 47回 |
|---|---|
| 最小 | 560ms |
| 中央値 | 650ms |
| 最大 | 805ms |
| 500〜599ms | 10回 |
| 600〜699ms | 23回 |
| 700〜799ms | 13回 |
| 800〜899ms | 1回 |
47件すべてを処理し終えるまでの時間は、記録がありません。スクリプトはその値（wall）を画面に表示するだけで、ファイルには書き出していないためです。このため、並列にしたときに全体が何秒で終わったか、1秒あたり何件を処理できたかは、この記事では書きません。
応答時間のうち、接続の確立にはどれくらいかかったか
API キーを付けずに curl で10回送った計測では、TCP の接続が済むまでに0.126156〜0.141086秒、TLS の確立が済むまでに0.254739〜0.289522秒かかりました。直列の計測とは実行した時刻もクライアントも違うため、応答時間から差し引くことはしていません。
curl の計測は 2026-09-21 14:47:25〜14:47:38（JST）に行いました。直列の計測の CSV が書き出された 14:37:11 より後です。記録にある実行環境は Darwin 24.6.0（x86_64）と curl 8.7.1 で、直列の計測と同じ端末・同じ回線だったかは記録からは確定できません。
| 回 | 名前解決まで（namelookup） | TCP 接続まで（connect） | TLS 確立まで（appconnect） | 403 の応答開始まで（starttransfer） |
|---|---|---|---|---|
| 1 | 0.004622秒 | 0.126853秒 | 0.260142秒 | 0.395550秒 |
| 2 | 0.004463秒 | 0.137731秒 | 0.284665秒 | 0.432414秒 |
| 3 | 0.003366秒 | 0.138264秒 | 0.281547秒 | 0.429900秒 |
| 4 | 0.003097秒 | 0.140293秒 | 0.286953秒 | 0.481505秒 |
| 5 | 0.004092秒 | 0.126692秒 | 0.257863秒 | 0.384032秒 |
| 6 | 0.004127秒 | 0.135231秒 | 0.273937秒 | 0.413531秒 |
| 7 | 0.002992秒 | 0.126156秒 | 0.254739秒 | 0.389786秒 |
| 8 | 0.003245秒 | 0.130333秒 | 0.266644秒 | 0.399833秒 |
| 9 | 0.003206秒 | 0.141086秒 | 0.289522秒 | 0.433616秒 |
| 10 | 0.003339秒 | 0.126244秒 | 0.262451秒 | 0.393687秒 |
各列の値は、curl がその段階を終えた時点を、curl が処理を始めた時点から数えた秒数です。TLS 確立までの値は、名前解決と TCP 接続の時間を含みます。
右端の列は、モデルの応答が始まるまでの時間ではありません。API キーを付けていないため、10回とも HTTP 403 が返っています。同じ条件で1回保存した応答本文は {"detail":{"error_type":"authentication_error","message":"Must supply an API key! Check your request and try again."}} で、認証の拒否までの時間です。応答ヘッダの1行目は HTTP/2 403 でした。
API キーを付けた状態で、TLS の確立から応答の開始まで（モデルの処理を含む区間）を測った記録はありません。このため、Jev の応答時間のうち通信にかかった分とモデルの処理にかかった分を分けた数字は、この記事には載せていません。
入力トークンと費用はいくらだったか
直列の計測の入力トークンは1周28,570で、3周とも同じ値、3周の合計は85,710でした。公式の掲示価格（入力100万トークンあたり0.042ドル）で計算すると、3周の合計は約0.0036ドルです。
| 集計 | 入力トークン | 掲示価格 $0.042 / 100万トークンで計算した額 |
|---|---|---|
| 直列・1回あたり（最小／中央値／最大） | 479／578／880 | 約0.0000201／0.0000243／0.0000370ドル |
| 直列・1周（47回） | 28,570 | 約0.00120ドル |
| 直列・3周の合計（141回） | 85,710 | 約0.00360ドル |
| 並列・1回あたり（最小／中央値／最大） | 759／873／1,159 | 約0.0000319／0.0000367／0.0000487ドル |
| 並列・47回の合計 | 42,022 | 約0.00176ドル |
額は「入力トークン数 ÷ 1,000,000 × 0.042」で計算し、有効数字3桁に丸めて示しています。2つのスクリプトも同じ式で費用を出す作りになっています。
- この額は掲示価格から計算した値で、請求額ではありません。請求画面の記録は確認していません
- 出力トークン数は記録していません。API の応答には
usageの中にinput_tokensとoutput_tokensの2つの欄があるとdocs.typesafe.ai/api.mdに書かれていますが、スクリプトが保存したのはinput_tokensだけです。料金表では出力トークンはfreeと書かれています - 直列と並列の数字は横に並べて比べられません。並列は質問が2問で、定型文を除いた入力を送っています。同じ47件でも、1周あたりの入力トークンは直列28,570・並列42,022と一致しません
記録が無いのは、どの項目か
次の6項目は、記録が残っていないか、測っていないため、この記事では数字を出していません。いずれも「そうではなかった」という意味ではありません。
| 項目 | 状態 | 理由 |
|---|---|---|
| 並列で47件すべてを処理し終えるまでの時間 | 記録なし | スクリプトが画面に表示するだけで、ファイルに書き出していない |
| 認証した状態での、TLS 確立から応答開始までの時間 | 測っていない | curl は API キーを付けずに送ったため、認証の拒否までしか測れていない |
| 直列の計測の1回ごとの時刻 | 記録なし | CSV に時刻の列が無い。分かるのはファイルの更新時刻だけ |
| 計測した回線・都市・有線か無線か、Python の版 | 記録なし | スクリプトと CSV に含まれていない |
| 失敗した試行の有無 | 記録なし | 失敗するとCSV が書き出されない作りで、記録に残るのは成功した実行だけ |
70ms-500ms の入力の長さ・接続の条件・計測区間 | 公式の8ページで確認した範囲では記載なし | 上の「TypeSafe は応答時間を公式にどう書いているか」を参照 |
この記録から何が言えて、何が言えないか
言えるのは、2026-09-21 に日本国内の1地点から、毎回 urlopen を呼ぶ作りで、1問・入力479〜880トークンの条件で記録された141回が、552〜812msの範囲に収まったことです。言えないのは、公式の 70ms-500ms が正しいかどうか、そして応答時間のうちどれだけが通信でどれだけがモデルの処理かです。
この記事の数字と計測の設計から言えることは、次の6つです。
- 記録された直列141回の応答時間は552〜812msで、500ms以下の回は0回でした。これは記録された141回についての数の事実です
- 3周の中央値は647ms・641ms・661msでした。3つの値の幅は20msです
- この141回の値は、どれも
urlopenの呼び出しを含む区間で測っています。計測区間がurlopenを呼ぶ前から始まり、スクリプトには接続を使い回すコードが書かれていません - API キー無しの curl では、TLS の確立が済むまでに0.254739〜0.289522秒かかりました。直列の計測は1回ごとに
urlopenを呼ぶ作りですが、各回にこの段階にあたる処理が起きたかどうかは記録していません - 掲示価格で計算すると、直列3周（85,710トークン）の費用は約0.0036ドルです
- 送信した
jev-latestに対し、応答のmodelは141行すべてjev-1.13.0でした。docs.typesafe.ai/modelsのエイリアスの表の記載（jev-latest→jev-1.13.0）と同じです
この記事から言えないことは、次の8つです。
- 公式の
70ms-500msが正しいか誤りか。公式側の入力の長さ・接続の条件・計測区間が記載として見つからず、この記録と条件をそろえて比べられません。計測地点について公式が書いているのはWest Coastのラップトップで、この記録は日本からです。公式の記載そのものはTypeSafe Jevの倍率 公式28件で確認でも並べています - 応答時間のうち、通信の分とモデルの処理の分がそれぞれ何msか。認証した状態での内訳は記録が無く、curl の計測は別の時刻・別のクライアントです。curl の値を直列の値から差し引いた数字も、2つの値の比率も、この記録からは出せません
- 接続を使い回した場合、公式の SDK を使った場合、別の地点や別の時間帯から呼んだ場合、入力がもっと長い場合の値。いずれも測っていません
- 並列にしたときの全体の処理時間や、1秒あたりの処理件数。全件の所要時間の記録がありません
- 失敗の割合。記録された試行はすべて応答を返していますが、記録されなかった試行の有無が分かりません
- 実際の請求額。請求画面を確認していません
- 直列と並列のどちらが速いか、どちらが安いか。質問の数と入力の前処理が違います
- 回答の正しさ。この記事では扱っていません
この記事はどう更新するか
この記事は定期更新をしません。再計測にはスクリプトを手元で実行する必要があるため、周期を決めていません。再計測したときは新しい日付の記録を追加して「◯月◯日の記録」として追記し、2026-09-21 の記録は残します。
公式の 70ms-500ms・料金・モデルの版の記載が変わったかどうかは、TypeSafe Jevの倍率 公式28件で確認が1か月ごとに取り直して追っています。
記載に誤りがある場合、また確認してほしい項目がある場合はお問い合わせからご連絡ください。
この記事は何を出典にしているか
- TypeSafe AI Blog｜Introducing System One Models & Jev（2026-09-21 13:19 JST 取得、HTTP 200。記事の表示日付は Sep 15, 2026）
- TypeSafe AI Docs｜Models（2026-09-21 14:56 JST 取得、HTTP 200。料金・エイリアスの表）
- TypeSafe AI Docs｜API reference（2026-09-21 13:20 JST 取得、HTTP 200。エンドポイントと応答の
usage） - TypeSafe AI Docs｜llms.txt（ドキュメントの全ページ一覧）（2026-09-21 13:20 JST 取得、HTTP 200）
- TypeSafe AI Docs｜Parallel questions（2026-09-21 14:46 JST 取得、HTTP 200）
- TypeSafe AI Docs｜Speculative fan-out（2026-09-21 14:46 JST 取得、HTTP 200）
- TypeSafe AI Docs｜Python SDK Usage（2026-09-21 14:46 JST 取得、HTTP 200）
- TypeSafe AI Docs｜Python SDK Exceptions（2026-09-21 14:46 JST 取得、HTTP 200）
- 当サイトの計測記録 design/measure/raw/typesafe-jev-latency-japan-2026/2026-09-21/jev_latency.py（直列計測のスクリプト。sha256 283598fc4022255cc4183c076e731014fabf179f32f9aa7c4436696410737d41）
- 当サイトの計測記録 design/measure/raw/typesafe-jev-latency-japan-2026/2026-09-21/jev_latency.csv（直列141回の出力。sha256 163f1c876b0bcb677bd4ab4d52b23c992d527a0609dbbdd7fddf05ae090690fc）
- 当サイトの計測記録 design/measure/raw/typesafe-jev-latency-japan-2026/2026-09-21/jev_test.py（並列計測のスクリプト。sha256 6e0ccbeb08b17c9ff75809d937d4f9b0aca165d656057439aee9a6ed0d9ebcf9）
- 当サイトの計測記録 design/measure/raw/typesafe-jev-latency-japan-2026/2026-09-21/jev_result.csv（並列47回の出力。この記事では
latency_ms・input_tokens・modelの列だけを使用。sha256 b2bcca8e2649746dd810f41a29577886626027149060b91f3896467156f20584） - 当サイトの計測記録 design/measure/raw/typesafe-jev-latency-japan-2026/2026-09-21-curl/curl_timing.txt（API キー無しの curl 10回。sha256 80d7587fbf4ed789cb3d3f4e3252b475156eab1f99ea0d0395362c18c9d05404）
- 当サイトの計測記録 design/measure/raw/typesafe-jev-latency-japan-2026/2026-09-21-curl/headers.txt・body.txt・environment.txt（curl の応答ヘッダ・応答本文・実行環境）