Jevとは？APIの使い方・料金と業務判断の実装例

Jev は、TypeSafe AI が提供する、判断を返すAIです。自然言語の入力を読み、あらかじめ決めた選択肢・評価段階・真偽の確率を返します。自由な文章は生成せず、ソフトウェアの処理を分ける判断に使います。提供元は、この種類を System Oneモデル と呼んでいます。公式の紹介

問い合わせを担当部署に振り分ける。開示文書を投資調査の候補へ回す。自作ゲームで次の行動を選ぶ。こうした小さな判断をプログラムへ渡せるのがJevの特徴です。この記事では、LLM（Large Language Model）との違いと基本のAPI実装から、投資判断支援・自動金融取引への接続設計、業務自動化、ゲーム操作まで具体化します。

目的から読むなら、投資判断支援、自動金融取引への接続、請求書・承認フロー、ゲーム自動操作へ進めます。前半の第1〜4節に基本のAPI実装、第5〜7節に問い合わせ・RAG・運用を掲載。呼び出し制限とサンプル一式、料金、日本語対応と限界も確認してください。

Jevでは、評価する文章やデータを state、尋ねたいことを questions に入れます。現在の入力はテキストのみで、画像・音声・動画を直接渡すことはできません。入力の公式仕様。「営業・請求・技術のどこへ送るか」と聞くなら、選択肢も先に渡します。返ってくるのは選んだ項目や確率で、返信メールや判断理由の文章ではありません。TypeSafeはこの仕組みを、ソフトウェア内で使う判断のためのモデルとして位置付けています。System Oneの説明

窓口のように順序のない分類には Choice、段階のある評価には Score、一つの条件の真偽には Noul を使います。Scoreに「影響なし・一部停止・全体停止」の3段階を渡すと、番号は0・1・2です。返り値の1.4は段階番号の確率加重平均であり、「業務が40%止まっている」という測定値ではありません。

この仕組みを使うなら、最初に仕事を分解すると見通しがよくなります。以下は製品の性能順位ではなく、本記事で提案する役割分担です。問い合わせの振り分けを例にすると、宛先の候補を決める判断と、実際の送信、返信文の作成は別々の処理として設計できます。

生成LLMでも、構造化出力 を使って分類結果を返せます。たとえば生成LLMの公式ドキュメントにある分類例は、その使い方を示しています。JevはChoice・Score・Noulという判断形式と確率を返すAPIを備え、自由文を生成しない設計です。既存LLMで分類できている場合も、同じ入力で誤分類、未判定、応答時間、総費用を比べて選びます。本記事では優劣を実測していません。

まず分類だけに使えば、返信の書き方を変えずに効果を確かめられます。逆に、すでに固定の条件で正しく分類できているなら、その部分をモデルに置き換える理由は薄いでしょう。必要な箇所を見極める考え方は、道具箱 EP.24「道具を増やしすぎない」にもつながります。

ここでは、架空の問い合わせに対して「担当窓口」と「返金要求の有無」を尋ねます。API（Application Programming Interface） のリクエストは JSON（JavaScript Object Notation） で送り、結果をファイルに保存します。実APIを呼ぶには、利用可能なTypeSafeアカウントとAPIキーが必要です。 公式クイックスタートを確認し、キーを環境変数 TYPESAFE_API_KEY に設定してください。コードは Python の標準ライブラリだけで動く形です。アカウントを利用できない場合も、第12節の同梱サンプルで模擬応答の検査と状態管理を試せます。これはJev自体をローカルで実行するものではありません。

以下は日本語の例です。公式では英語が最も得意とされており、日本語の精度は自社の文章で確かめる必要があります。言語対応と第14節を確認したうえで、まずAPI呼び出し、次に応答を受けた分岐を作ります。

注目したいのは「その他・判断保留」に当たる review も候補に入れたことです。請求・技術・営業のどれにも収まらない文を、無理にその三つへ押し込めないためです。また、返金について尋ねるのは「要求があるか」だけで、返金の可否や実行を任せているわけではありません。利用者の意図の判定と、会社の対応方針を分けておきます。

python jev_request.py を実行すると、成功した応答が jev-response.json に保存されます。応答は answers.department と answers.refund_requested から読めます。仕様はAPIリファレンスを参照してください。この例では通信失敗時に例外で停止します。運用に組み込む際は、通信失敗も「未判定」として人の確認に戻し、過去の応答ファイルを今回の結果として使わない設計にします。

応答の形を読むため、説明用のJSONを示します。数値はすべて手で置いた仮値で、Jevによる判定・confidenceの計算・使用量の実測を示すものではありません。

choice は窓口候補、probabilities は候補ごとの確率、confidence は分布から得る指標、noul は返金要求についての「はい」の確率です。この仮の応答なら、次節の条件では billing が表示されます。同じ構造で confidence が0.85未満、または noul が0.20を超える場合は human_review になります。

一つの呼び出しに入れた質問は、同じ state を見て独立に評価されます。「質問Aの結果を読んで質問Bに答える」という順序にはなりません。たとえば、選ばれた窓口に応じて社内資料を取得し、その資料を評価したい場合は、最初の応答を受けた後で次の呼び出しを組みます。質問の独立性と組み合わせ

ChoiceとScoreに含まれる confidence（Jev） は、確率分布がどれだけ一つの候補や段階に集中しているかを要約した値です。したがって、confidence = 0.9 を「この判断は90%の確率で正しい」と読み替えることはできません。選択肢ごとの probabilities とも別の値です。confidenceの公式説明

Noulには独立した confidence がありません。たとえば返金要求を尋ねたときの noul = 0.5 は、「半額の返金を希望している」という意味ではなく、問いに対する「はい」と「いいえ」の確率が同程度という意味です。数値を使う前に、何についての確率なのかを文章で言える状態にしておくと、分岐条件を取り違えにくくなります。Noulの読み方

TypeSafeが重視する 確率校正 は、多数の予測で確率と実際の発生割合を対応させる考え方です。それも、目の前の一件を保証するものではありません。公式AI primerが示すように、個別の回答と集団での性質を分けて読みます。本記事では、未判定や曖昧な結果を、人が確認する窓口へ戻す設計を採ります。

二つのファイルを保存し、最初の呼び出しが成功した直後に python jev_route.py jev-response.json を実行します。表示されるのは担当窓口の候補か human_review です。ここで使った0.85と0.20は、推奨基準でも実測から得た値でもありません。実際の問い合わせで、誤って振り分ける件数と、人が確認する件数の両方を見ながら決めるための仮値です。

ここからは、ふくふくが扱うデータ活用・業務自動化の領域を想定した設計提案です。導入済みの顧客事例や実測結果ではありません。公式の設計パターンを踏まえ、入力するもの、Jevへの問い、その後の処理、効果の測り方を具体化します。

最初に試すなら、前掲コードを使った問い合わせの仕分けを提案します。フォームの件名と本文をつなぎ、分類に必要な内容だけをJevへ渡します。「請求書の宛名を変更したい」は請求窓口の候補、「接続できないので返金してほしい」は人が確認する候補、といった扱いを業務担当者と先に決めます。これは期待する扱いの例で、Jevの実際の出力を示したものではありません。

RAG（Retrieval-Augmented Generation） の構成なら、検索で見つかった資料を生成LLMに渡す前にJevを挟みます。アクセス権限、有効期間、参照すべき文書の版は検索側のコードで先に絞ります。その後、質問と一つの資料断片を入力にして、「この断片は質問に答える材料としてどれだけ直接役立つか」を判定します。権限の絞り込みは、権限付きRAGの設計でも詳しく扱っています。

この設計で分かるのは、渡した断片が問いに役立つかどうかです。一つの断片で none が返っても、社内の資料全体に答えがないとはいえません。また、資料が質問に関連していても、生成した回答の全てが裏付けられるとは限りません。資料の選別と、最終回答の根拠確認を別々に評価します。

必須項目や日付の形式はコードで検査できても、説明文の意味まで条件式で拾うと複雑になります。たとえば登録カテゴリは「アカウント発行」なのに、説明文は「退職者のアクセスを止めたい」という依頼です。構造上の検査を通った後に、カテゴリ定義と説明文の整合をJevへ尋ねる工程を加えます。自由文から項目そのものを取り出す工程は、LLMによる項目抽出と検証と組み合わせて考えられます。

提案Aの最小構成は、既存のフォーム、処理待ちの問い合わせを保存する表、バックグラウンドで判定するプログラム、候補を表示する管理画面です。受信と判定を分けておくと、Jevの応答が遅くても問い合わせ自体は受け付けられます。APIキーはサーバー側に置き、利用者のブラウザには渡しません。

次のコードは、①の受付や管理画面までを作るものではなく、③〜⑤を一件ずつ試すためのものです。前掲の jev_request.py と jev_route.py を同じフォルダに置き、架空の本文を保存した ticket.txt で実行します。毎回その入力への新しい応答を使い、担当窓口の候補を記録します。実行するとTypeSafeへ本文を送信し、API料金が発生します。

jev-decisions.jsonl には、1行に1件のJSONが追記されます。mode = observe と applied = false は観測だけの結果であることを表します。status = evaluated は、この例で必要な応答項目の検査を通ったという意味で、判断の正しさを保証しません。不正な応答や通信失敗は pending_review とエラー種別を残します。有効な応答でも、確率や候補が分岐条件を満たさなければ human_review になります。

運用版では、この判断記録を 監査ログ（Audit Log） として扱える保存先へ移し、入力の参照番号、本文の版、モデル・質問・分岐ルールの版をひも付けます。本文を判断記録へ何度も複製せず、権限を限定した元の保管先から確認できるようにします。コード中の入力の指紋は同じ本文かどうかを照合するためのもので、元の本文を復元する機能ではありません。 入力の指紋は匿名化の代わりにはならないため、判断記録にもアクセス権と保存期間を設定します。

同じ処理が再実行されても担当変更が重複しない性質を 冪等性（Idempotency） と呼びます。問い合わせ処理の状態を保存する表と、担当変更先の仕組みの両方で考える必要があります。Jevの判定が返ったことだけで「業務処理が完了した」とせず、判定済み・反映待ち・反映済みを分けて記録します。

検証計画の例として、過去の日本語問い合わせを300件ほど用意し、100件を質問や閾値の調整、残り200件を最終確認に使います。件数は設計例で、精度を保証するための必要十分な数ではありません。同じ相談の続きが両方へ混ざらないように分け、窓口と返金要求の有無を人が確認します。曖昧な案件には保留という答えを認めます。 正解ラベルはJevの候補を見せずに付け、返金要求のような少数の分類も件数を確認します。最終確認用のデータで閾値を調整した場合は、別の未使用データで確かめ直します。

候補を表示した状態では、担当者の判断がAIの案に影響される可能性があります。候補を隠した精度比較と、候補を使った作業時間の評価を分けます。後者でも一部を候補なしで再確認し、人とAIの一致だけで正しかったと判断しないようにします。

集計する値は、少なくとも「自動反映の候補になった件のうち何件が誤分類か」「実際に返金要求がある件を何件見逃したか」「全件のうち何件が人へ戻るか」「仕分けに使う時間と総費用」です。割合には必ず分母の件数を付けます。少数の確認で誤りがゼロだったことから、将来も誤らないとは判断できません。窓口別・文章の種類別に結果を見て、対象を広げます。

金融分野で最初に切り出したいのは、調べる資料を選び、決めた事実が書かれているかを確かめる仕事です。「この株は上がるか」を一つの質問にまとめると、価格予測、売買の条件、発注までが混ざります。開示文書を分類して確認候補を作り、価格や出来高は別のプログラムで計算する構成なら、どの工程が役立ったかを測れます。以下は実装提案であり、売買成績の実測ではありません。

TypeSafeの公式function calling例も、自然言語の依頼から株価表示・相関・変動性などの分析関数と引数を選ぶ構成です。そこで掲載される関数には売買注文は含まれません。Jevが「何を分析したいか」を選び、通常のコードがデータ取得や計算を担う使い方は、読み取り専用の投資調査ツールから試す際の参考になります。

たとえば「会社が工場の操業停止を公表したか」を尋ねたNoulの値は、渡した文書についての問いへの回答です。0.9が返っても「明日の株価が90%の確率で下がる」という意味にはなりません。期待利益、ポジション量、売買方向へ変換する部分は別の戦略であり、その戦略自体を検証する必要があります。本文に事実が明記されていることと、市場がどう反応するかを分けて扱います。

入力は一つの対象文書と、一つの確認事項に絞ります。全文を何度も送る前に、見出しや文書種別で候補を減らし、該当箇所を取り出してください。以下は架空の銘柄と文書を使うリクエスト例です。supported は文章が対象事実を支持するという分類で、注文許可ではありません。質問IDの名前はモデルへ推論情報として渡されないため、聞きたいことを instructions に書きます。API仕様

実データを評価用に作る際は、公表時刻と自分のシステムが入手した時刻を別々に残します。後から訂正された本文や、その時点で未公表だった価格を混ぜると、過去の判断を過大評価する原因になります。学習済みモデルが過去の著名な出来事を知っている可能性もあるため、過去文書の好成績だけで採用せず、設定を固定した後の新しい文書で観測します。

自動取引へ進めるなら、既存の数値戦略 → Jevによる文書条件の確認 → コードのリスク検査 → 注文管理という流れを提案します。Jevに任せるのは途中の小さな判断です。注文数量、現金や保有数量、取引時間、価格の古さ、重複注文は、モデルの文章理解に依存させず検査します。最初は候補だけを記録し、次にペーパー取引で注文状態の扱いを確かめます。

ダウンロード版の paper_gate.py は、架空の現物・単一通貨・指値候補を検査する小さなプログラムです。Jev形式の模擬応答、対象状態の版、時刻、注文条件、口座の照合状況を与え、permit_paper_candidate または保留・拒否と理由を返します。証券口座へ接続したり、注文を送ったりはしません。 金額はDecimalで扱い、NaN、真偽値、負数などを金額や確率として通さない検査を含めています。

モデルの応答とは別に、呼び出し元のジョブ記録へ「どの文書・価格・口座状態を評価したか」を保存します。返ってきたあとに状態の版が変わっていたら、古い判断を適用しません。Jevが入力の版を自動的に証明するわけではなく、応答ファイルの読み込みだけで今回の入力との対応を確認できるわけでもありません。入力の参照と応答の対応は、呼び出し元が管理します。

このゲート自身は処理済みIDを登録しないため、呼び出し元が記録を更新せずに同じ候補を渡せば、二度とも通過し得ます。本番の同時実行制御や注文台帳は別途必要です。複数の処理が同時に上限検査を通るケースには、口座単位の予約・ロックなどで対応し、送信直前にも必要な状態を再確認します。検査で使う上限やconfidenceの閾値は説明用の設定であり、許容リスクや利益を保証する数値ではありません。

Alpacaの公式Paper Trading仕様では、模擬環境は注文による市場への影響、通信遅延に伴うスリッページ、板の待ち順などを再現しません。紙上の損益は本番の利益の証明にはなりません。IBKRは個人向けWeb APIの利用要件と、注文時の警告・確認応答を確認してください。株・FX・暗号資産の口座とAPI制限の比較は、金融口座API一覧にまとめています。

たとえば送信後の接続が切れても、注文が業者へ届いている可能性があります。台帳を UNKNOWN にし、新規の注文送信を止め、注文一覧・約定・残高を照合します。Alpacaの注文APIのFAQは、タイムアウト時にダッシュボードを確認し、サポートや取引担当の確認まで同じ注文を再送せず、取消済みとも扱わないよう案内しています。本稿の設計でも、照会が一度404だっただけで「注文は存在しない」と決めて再送しません。

冪等性の単位は、APIリクエストそのものだけではなく「この戦略が、この入力から作った一つの注文意図」です。再起動しても同じIDを使い、注文を一度予約した記録を失わないようにします。Jevの判定を再試行することと、注文送信を再試行することは別のルールにしてください。

前半の問い合わせ仕分けを一歩進めるなら、例外の意味を判定して、適切な確認作業へつなぐ使い方が考えられます。請求書の合計や税額は通常のコードで検算できても、「追加のデータ移行費用」という説明が当初の発注内容に含まれるかは、文章を読む必要があります。この意味の確認をJevに切り出し、金額や権限の検査と組み合わせます。

請求書なら「金額が合っているか」は計算し、「明細の説明が当初の依頼内容に沿うか」をモデルへ尋ねます。元のPDFはOCRや項目抽出の工程でテキスト化し、抽出した値を原資料と照合できるようにします。Jevは現行版では画像を直接読まないため、PDFやスクリーンショットを渡せば帳票の処理が完結する、と考えないことが大切です。入力形式

n8nを使うなら、次の表をワークフローの設計図にできます。Jevの認証情報はサーバー側のcredentialに保存し、HTTP Requestから呼び出します。HTTP Requestの仕様とWaitの仕様を参照してください。ここでは構成案を示しており、稼働中の業務環境で検証したワークフローではありません。

承認のメールを送った、Waitが再開した、Jevが「通常請求」と返した、というだけでは承認済みにしません。承認する人、承認対象の版、認めた操作がそろっているかを検査します。承認後に請求書が差し替われば再確認へ戻します。これにより、モデルの分類精度と、業務上の決裁手続きを分けて改善できます。

費用対効果は、処理前後の同じ種類の案件で、仕分け・確認・修正にかかった合計時間を比べます。「1万件を自動分類した」だけでは、不要な確認が増えていないかが分かりません。API費用に加え、抽出処理、再試行、確認待ちの運用、誤分類後の修正を含めて、1件を完了するまでの時間と費用を記録します。

Jevの発表記事には、Doomへ組み込む公式デモがあります。入力はゲームの状態を整理したテキストで、画像をそのまま見て操作する機能の実証ではありません。また、そのデモの速度を自分の環境の保証値にはできません。自作ゲームで試すなら、状態が変わる時点を管理しやすいターン制から始めると、判断と操作のつながりが分かります。

例として、「住民へ薬を届けたいが、門番から通行証を見せるよう求められている」場面を使います。ゲーム側は所持品を調べ、いま実行可能な show_pass・ask_guard・wait だけを候補にします。Jevは場面の説明と目的から一つを選び、ゲーム側のコードがそのIDに対応する決まった処理を実行します。移動距離や経路、衝突判定、所持品の有無をモデルに計算させる必要はありません。

このデモで show_pass を適用すると、門が開いてターンが一つ進みます。これは手作成の応答を使った処理の検証であり、Jevがこの場面を正しく解いたという結果ではありません。実APIへつなぐ場合は payload を送り、同じ context に返ってきた応答を渡します。通信中に状態が変わった場合は古い応答を拒否し、未判定や低いconfidenceは待機の一手として扱います。5秒の有効期限も、説明用の設定です。

ブラウザー上の自作ゲームなら、返った行動IDを固定のボタンへ対応させ、Playwrightのlocator等で操作する構成にもできます。Jevがマウスを動かすわけではありません。ゲーム側の状態APIを使うか、別の認識処理で画面を状態へ変換し、操作直前に再確認します。ここで扱うのは自作・許可されたテスト環境で、オンラインゲームの規約や不正対策を回避する手順ではありません。

検証用のゲーム環境を広げる際は、Gymnasiumの自作環境のように、観測・行動・終了を分けたインターフェースが参考になります。同じ初期状態で、固定ルール、ランダムな実行可能行動、Jevによる行動選択を比べ、目的達成率、手数、反復、保留、応答時間、1試行の総費用を記録します。場面の違いを読めるかを測り、単純な条件式で十分な箇所はコードに残します。

毎回すべてをJevへ送るより、判断が変わる出来事を起点に呼び出す構成を提案します。開示文書は新しい文書IDや訂正版が来たとき、請求書は対象の版が変わったとき、ゲームは次の行動を選ぶ状態になったときです。同じ入力、モデル、質問の版なら判定結果を再利用できますが、注文や承認に使うときは最新の市場・口座・業務状態を別途検査します。

数値の出典はJevのモデル・制限一覧とIBKR Web APIの制限です。Jevを毎フレーム呼ぶ必要はありません。複数の問いは一回にまとめられますが、質問同士は独立評価なので、前の答えを次の問いの材料にしたい場合は段階を分けます。総費用は要求数だけでなく、stateと質問の量、再試行、下流のAPI、確認作業まで含めて計測します。

通信処理の例 evaluate_payload.py は、リクエストの検査だけなら通信せず、既存の出力も変更しません。--send を付けると、安全な出力先を確認して旧出力を削除し、成功した今回の応答だけを保存します。呼び出し元は終了コードを確認し、失敗後のファイルを結果として処理しないでください。並行ジョブには別々の出力先を使います。実際に送る場合はAPI料金が発生するため、まず同梱の架空データを使ってください。

この通信例は再試行を行いません。timeoutはHTTP操作の設定で、ジョブ全体の強制終了時刻ではないため、下流でも状態の版と期限を検査します。入力本文や認証情報をデバッグログへ出さず、応答と入力の対応は呼び出し元のジョブ台帳で管理します。金融ゲートへJSONを読み込む場合は json.loads(raw, parse_float=Decimal) を使うなど、金額と確率の型もサンプルの説明に合わせてください。

サンプル一式（ZIP）には、汎用API呼び出し、金融候補の検査、ゲーム1ターンの状態遷移、テスト、架空のリクエストをまとめました。ローカルで検証しているのは応答後の制御とエラー処理です。Jevの実APIでの精度・速度、金融の運用成績、n8nの実環境、証券会社への発注接続は今回測定していません。

金融の検証は、文書の分類精度、戦略の過去検証、将来のデータでの観測、注文接続の確認を分けます。バックテストの調整用と最終確認用の期間を分け、先読みバイアスや手数料・スプレッド・スリッページを確認します。候補を増やしてよい条件は、勝率一つでは決めず、総損益、最大損失幅、取引回数、保留件数、運用上の事故を合わせて決めます。モデルの導入効果を調べるには、同じ戦略からJevの条件だけを外した結果も比較します。

2026年9月23日確認時、公式のモデル一覧にある jev-1.13.0 の料金は入力100万トークン当たり0.042米ドルで、出力は無料です。単純計算では、質問などを含む課金入力が一件1,000トークンで100万件なら42米ドルになります。これはその条件だけの試算で、再試行、周辺システム、人による確認などの費用を含めていません。公式モデル・料金一覧

速度については、発表資料の比較値を自社の処理時間として扱わないことが大切です。提供元自身が、評価場所や入力の短さ、比較するモデルの設定によって結果が変わることを説明しています。導入を比べるなら、同じ問い合わせ群で分類の正しさ、応答時間、未判定率、一件当たりの費用を測ります。発表資料の評価条件

返り値の型が決まっていても、分類の中身を誤ることはあります。たとえば許された候補である billing を返しても、実際には技術窓口の案件かもしれません。型が合うという性質だけで、判断の正しさを検証済みにはできません。公式の既知の限界にも、不得意な作業が具体的に示されています。

• 正確な計算、数え上げ、日付の前後比較はコードで行う。
• 無関係な情報を大量に渡さず、判断に必要な入力を選ぶ。
• 入力に混ざる誘導文やプロンプトインジェクションへの耐性を、実際の条件で確かめる。
• 長い説明文の生成や、何段階もの推論が必要な作業は、適した処理へ分ける。

日本語の問い合わせで使うなら、日本語で評価する必要があります。公式資料では英語が最も得意で、他の言語は同等の精度ではないとしています。また、jev-latest の指す版は更新されます。検証したモデルの版、質問文、選択肢、分岐条件を一緒に残せば、変更前後の結果を比べやすくなります。対応言語とモデルの版

実際の問い合わせや社内文書を送る前に、送信してよい範囲と利用プランのデータ保存条件を確認します。公式は顧客のリクエスト・応答を学習に使わないと説明していますが、保存しないこととは別の条件です。データを保持しない仕組みは企業向けとして案内されています。初期検証は架空・匿名化した文章で行い、実データに進む際は不要な個人情報を除きます。公式のデータ取扱説明・契約とデータ保持の案内

最初の検証では、通常の問い合わせだけでなく、情報不足、複数の用件、否定表現、分類先を誘導する文も含めます。本番の担当窓口は変えずに候補だけを記録し、候補を見ずに人が決めた結果と比較する方法なら、誤り方を確認できます。正解率だけを見ず、「どの分類を取り違えるか」「確認待ちがどれだけ増えるか」まで見て、使う範囲を決めましょう。

Jevを組み込む入口は、「答えの候補を先に決められる小さな判断」です。文書の事実確認、承認経路の案内、次の行動選択を取り出し、計算・権限・状態管理・実操作はコードと既存システムへつなぎます。まず同梱のデモで失敗時の動きを確かめ、実際の日本語データでは、現在の方式と同じ条件で評価してください。