Jevの速さと安さは本当か、Opus 5と比べた

今日も出し惜しみなしで、開発現場で得たものを全部書く。

今回は、AIの料金表を前に、業務にどのAIを組み込むかを決める立場にいる人に向けて書いた。渡すのは、自社の題材で速度と料金を測った一次データと、ベンダーの公称値や他社の比較記事を見抜くための判断の型だ。

ぼくは現役のCTO兼CEOで、自分で運用しているアプリの判定処理を、2つのAIで実際に測った。先に結果を置いておく。⁠Jevの公称値は、実際に測ってもおおむね妥当だった⁠。ただし同じデータでも、測り方ひとつで差は20倍にも200倍にも見える。だから怪しむべきは、ベンダーの公称値よりも、条件の書いていない伝聞の数字のほうだと思う。

記事の要点は、文末の要点ダイジェストにQ&Aでまとめてある。

JevとOpus 5に同じ炎上リスク判定を任せた仕掛け

題材は自分で運用しているアプリにした。SendSignal（SNSに投稿する前に炎上リスクを判定するアプリ）が、判定の中身に Jev を使っている。TypeSafe AIというベンダーのモデルで、文章を書かずに〝型のついた判断〟だけを返す。「危ない確率を数字で返す」「4段階から1つ選ぶ」のように、決まった形の答えしか出さないので、出力の文章量が構造的にゼロになる。Jevが何者かは別の記事で詳しく書いたので、ここでは速さと料金の話に絞る。

公称値はこうなっている。単位のトークンは、AIが読み書きする文章の量を数える単位だと思ってもらえればいい。

出典はTypeSafeのモデル一覧とClaudeの料金ページ。入力の単価で約119倍、出力は片方が無料。自動車のカタログ燃費と同じで、この数字自体は嘘ではない。実際に走らせたときに何倍になるかは、走らせないと分からないというだけだ。

判定の流れは二段構えになっている。

一段目で「何が危ないか」を20項目まとめて聞き、二段目で「その火種は本文のどの文にあるか」を文の数だけ聞く。火種が1つも点かなければ一段で終わるので、安全な投稿は速く、危ない投稿は少し時間がかかる。

比較のため、Opus 5にも同じ二段構えで、同じ20項目を、同じ本文について判定させた。Opus 5側は自然な日本語で答えさせている。本文は2種類で、測定日はすべて2026年9月22日。Jev側は3回の中央値をとり、Opus 5側は同じ条件で2回ずつ回した。

測ったのはJev 1.13.0だ。2026年10月14日に出た1.14.0では画像も渡せるようになったが、まだプレビュー扱いの機能で、料金は1.13.0と変わらない。この記事の数字は1.13.0で測ったものとして読んでほしい。

L3のほうは、1文だけ読むと世間話にしか見えないのに、前の文と合わさると来店客の住所が割れる投稿だ。二段構えにした理由そのものになっている。

Jevの公称値をOpus 5との実測で確かめた結果

速度で約200倍、料金で約400〜600倍の差が、実際の仕事でそのまま出た⁠。公称値の「出力は無料」は、文章を長く書く相手に対してこの形で効く。

Jev側（アプリの判定処理を端から端まで・3回の中央値）。

Opus 5側（同じ二段構え・自然な日本語で回答・各2回）。

左の2本（Jev）はほとんど見えない。描き間違いに見えるが、これが実際の差だ。

倍率にするとこうなる。「通信の往復」は、相手のサーバーまで行って帰ってくるだけの固定時間で、これは次の節で説明する。

入力トークンはほぼ同じだ（5,091〜6,566 対 6,084〜6,565）。同じ仕事を同じ分量の材料で頼んでいる、という裏取りになっている。違うのは出力側だけで、Jevは文章を出さず、Opus 5は判定の説明を日本語で書く。⁠だから料金の差が速度の差より大きく開く⁠。出力が無料という条件が、出力を多く書く相手に対して二重に効いている。

危ない投稿（L3）のほうが差が開くのも同じ理屈だ。二段目で「どの文が危ないか」を文の数だけ聞くので、生成AI側は説明を書く量が増える。Jev側は問いが増えても数字を返すだけで、出力が増えない。仕事が重くなるほど差が開く構造になっている。

20倍が200倍に化けた、AI検証の落とし穴

同じ実測データから、割り算のやり方を変えるだけで20倍・16倍・222倍が出た⁠。最初に出した「20倍」は捨てている。数字は嘘をつかないが、割り算は嘘をつく。

最初の20倍は、条件が揃っていない状態で総時間どうしを割った数字だった。いちばん効いていたのが、⁠両者に固定で乗る通信の往復を引いていなかったことで、これを測ると両者で10倍違った（新規接続・各3回）。

この固定の時間は、時間の短い側ほど重くのしかかる。Jevの1回が0.5秒前後で、そのうち0.43秒が往復なら、モデルが実際に考えている時間は1割ちょっとしかない。Opus 5は40秒動いて往復が0.04秒だから、無いに等しい。この非対称な2つを総時間どうしで割れば、差は小さいほうへ潰れる。20倍は、回線とモデルを足して平均した何かだった。ここが今回いちばんの沼だったと思う。

比較として成立するまでに直した前提は4つある。

②は単純な手落ちで、Jevは2往復しているのにOpus 5には1回で全部やらせていた。③がいちばん悩んだところで、Opus 5に「決まった形式だけで返せ・説明は書くな」と縛ると、出力が10分の1になって差は11〜16倍まで縮む。でも採らなかった。文章で答えるのが生成AIの標準的な使い方で、それを禁じた状態は生成AIから生成を奪った姿だからだ。相手の得意な形を取り上げたうえで勝ったと言うのに近い。自然に書かせたら200倍に戻り、こちらのほうが実際に使うときに起きることを表している。

単価と実効コストが別物になる構造は、Kimi K3の実効コストを測った回でも同じ形で出てきた。カタログの1行を実運用の1行に翻訳するときには、だいたい何かが挟まっている。

AI料金の差は、月1万件だといくらになるのか

月1万件の判定なら、Jevが2〜3ドル、Opus 5が925〜1,620ドルになる⁠。これは上の表にある1件あたりの実測料金を、そのまま掛け算した数字だ。ボリューム割引などの条件は考えていない。実測値からの単純計算として読んでほしい。

ここでもJevの棒はほぼ見えないが、これも実際の差だ。1ドル150円で換算すると、月1万件でJevが約320〜410円、Opus 5が約13.9万〜24.3万円になる。

ただ、ここで「Opus 5は高い」と読むのは早いと思う。Opus 5側の料金には、判定に添えた日本語の説明文が含まれている。説明が要る業務なら、それは払う価値のある料金だ。差が本当に効いてくるのは、件数の桁がもう1つ増えたときと、1件の処理の中で判定を何度も回す設計にしたときで、そこでは月の桁が変わる。

0.7秒と40秒の待ち時間が、業務設計に効く理由

0.7秒は画面の前で待てる時間で、40秒は待てない時間だからだ⁠。待てない処理は「送信したら、あとで結果を知らせる」形に作り直すことになり、料金より先に業務の流れそのものが変わる。

もうひとつ、時間が読めるかどうかの差がある。⁠生成AI側は、同じ条件でも毎回同じ時間にならない⁠。L0は1回目が41.40秒、2回目が43.57秒で、このとき出力が2,484から2,814に増えている。書く量が変わると時間が変わる。

ただ、それだけでもなかった。L3は出力が5,171と5,167でほぼ同じなのに、66.85秒と71.27秒で4.4秒違っている。書く量で説明しきれない揺れも残る、というのが正直なところだ。原因は分からないが、⁠業務に乗せる立場では原因より「毎回違う」という事実のほうが効く⁠。文章を書くAIには、この揺れが仕組みとして付いてくる。

Jev側にはこの揺れが構造的に無い。文章を書かないので、書く量で時間が動く仕組みがそもそも無いからだ。問いの数と本文の長さを変えて測ると、こうなる（各3回の中央値）。

問いを1個から20個に増やしても、本文を長くしても、ほとんど増えない。しかもその約500 msのうち430 msは通信の往復だ。つまりJevの応答時間はほぼ全部が「行って帰ってくる時間」で、判断そのものはその隙間で終わっている。応答時間に締切や約束（何秒以内に返す、という取り決め）を付けたい業務では、この性質のほうが単価より効いてくる場面があると思う。

AIの使い分けで、安いほうへ一本化した先の壁

Jevは文章を1文字も書けないので、理由の説明や修正文の提案がある機能は作れなくなる⁠。これは性能の話ではなく仕様の話で、「安いから全部Jevで」は成立しない。

SendSignalでも、判定はJev、直し方の提案は生成AIで分けている。

使い分けの線はシンプルだと思う。

• 判定・仕分け・スコアリングは、型付きの判断を返すモデル
• 説明・文案・要約は、文章を書く生成AI
• 1つの機能の中でも、この2つは分けて設計する

「この投稿は危ない」を出すところまではJevで足りるが、「じゃあどう直すか」を日本語で書くのはJevには頼めない。ここを取り違えると、安いほうに寄せたつもりで機能が作れなくなって詰む。TypeSafe側もそこは正直で、出力を売っていないモデルだと最初に宣言している。できないことをできないと書いてあるモデルは、むしろ扱いやすい。

他人のAI検証を、自社の根拠に使うための4つの前提

数字そのものより先に、その数字がどんな条件で出たかが書いてあるかを見る⁠。今回ぼくが間違えた順番を裏返すと、そのまま4つのチェックになる。

4つのうち1つでも書いていない比較記事の数字は、自分の根拠には使わないほうがいい。倍率が10倍単位で動くのは、この4つのどれかが動いたときだ。順位表も同じで、Jevとその仲間に日本語で同じ問題を解かせた回では、英語の成績表とは順位が入れ替わった。問題の言語が変わるだけで、どれが上かも変わる。

社内で説明や稟議に使うときの作法も、ここから決まる。自分で測っていない数字を、自分の根拠として書かない。書くなら「ベンダーの公称値（出典のURLつき）」と「条件が明記された第三者の実測」を分けて並べ、どちらも自社の題材ではないと添える。バズった助言を自分の手で確かめる作法と同じで、根拠の出どころを分けて書けるかどうかが、Agenticな皆さんの説明の信用そのものになると思う。

AIの使い分けで、公称値のあとに見るべきもの

今回の実測で言えるのは2つだ。公称値は嘘ではなかった。そして、それが自分の題材でどの倍率になるかは、測るまで分からなかった。「20項目の型付き判断を毎投稿で回す」というぼくの仕事の形では約200倍になった。判定に説明文が要る仕事なら、この数字はもっと小さくなる。

測り方のほうが、測られる対象よりよく動く。だから公称値の次に見るべきなのは、他人の倍率ではなく、その倍率が出た条件だ。自社の題材で測れる場面なら、測るのがいちばん早い。自社で実測する時間を取れない場面でも、条件が書いてある数字だけを根拠にすれば、他人の割り算に振り回されずに済むと思う。カタログ燃費を疑う人は多いのに、AIの単価表はなぜか素通りされがちだ。そこを素通りしないだけで、AIの使い分けの判断はだいぶ勝ち筋に寄る。

モデルの名前も単価も、来年には変わっている。でも「条件を見る・段数を揃える・相手の得意な形を奪わない」という読み方は、対象が何であっても残る。⁠単価表は来年変わる。数字の読み方は10年もつ⁠。

本記事の実測データ・図は、出典（本記事URL）明記のうえ引用自由です。