日文长文拆解：用 Jev + Kimi K3 做级联，agent 成本降九成

新井 元気@ITエンジニア @_moto___原推发布于 2026.10.03

在 X 上打开原推

「「判断」だけを安いモデルに任せて、エージェントのコストを9割減らす方法 ― Jev エンジニアリングと Kimi K3」の記事をまとめてみた。前提知識も説明してあるので読んでみてほしい。 ●背景/ 問題意識● InstructGPT（ChatGPT を生んだ RLHF 研究）の共著者 Diogo Almeida は、ハルシネーションも含めて、95% 正解できても、どの 5% を間違えるため、自動化はできない。ここが弱点だ。 一方、 Jev は RLCD（較正された判断のための強化学習） で訓練され、正直な確率（確信度）を出すことを目標にしている。個々の答えは間違うこともあるが確率で算出される。 JevはLLMのハルシネーションを解決する方向で出てきたものと言える。 --- ■はじめに：前提知識 - LLM（大規模言語モデル） は、 文章やコードを生成する AI である。GPT、Claude、Kimi などがこれにあたる。 - AI エージェント は、 LLM が何度も考えては道具（ツール）を使い、作業を自動で進める仕組みである。 - トークン は、 AI が文章を処理するときの単位である。料金は「100万トークンあたり何ドル」で決まり、入力（読ませた量）と出力（書かせた量）は別々に計算される。 - フロンティアモデル は、 最先端の高性能で高価な LLM を指す。 - 確信度（confidence） は、 AI が自分の答えをどれだけ確かだと考えているかを 0〜1 で表した値である。 - キャリブレーション（較正） は、 確信度と実際の正答率が一致している状態をいう。「90% の確信で答えたものが、実際に約90%当たる」なら較正されている。 - カスケード は、 安い処理から順に試し、自信がないものだけを次の高い処理へ回す構成である。 - しきい値（threshold） は、 「確信度がこれ以上なら自動で採用する」という境目の値である。 --- ■記事が伝えたいこと 記事冒頭の図には、左から右へ 4 つの箱が並んでいる。 CODE（厳密なルール・無料・即時） → JEV（あいまいな判断・100万トークン $0.042・約100ms） → KIMI K3（難しい判断・入力 $3／出力 $15・1M コンテキスト） → YOU（取り消せない操作・1日に数件） 図の副題は「every decision stops at the first layer that is sure （すべての判断は、確信が持てる最初の層で止まる）」である。 これが記事の主張そのものである。 エージェントの処理を見ると、何かを創り出している場面は意外と少ない。 「次にどのツールを使うか」「この情報は関係あるか」「テストは通ったか」「このコマンドは安全か」「作業は終わったか」といった選択肢から選ぶだけの小さな判断が大半を占める。 それにもかかわらず、そのたびに高価なフロンティアモデルで文章生成と同じ料金を払っている。 この判断部分を、文章を一切書かない専用モデル Jev に移せば、コストは桁違いに下がる。 --- 1. Jev とは何か TypeSafe AI が 2026年9月15日に公開したモデルである。 特徴は次のとおり。 - 文章は一切書かない。状態（state）と型付きの質問を受け取り、確率付きの答えだけを返す。 - 応答はおよそ 100 ミリ秒、料金は入力100万トークンあたり $0.042 で、出力は無料である。 - 自社評価では LLM より 193.6 倍速く、444.6 倍安かった。ただし同社自身が、この数値は期待値の上限だと述べている。 書けないモデルがなぜ役に立つのか。 InstructGPT（ChatGPT を生んだ RLHF 研究）の共著者 Diogo Almeida は、自身の手法を批判している。 人間の評価者を喜ばせるように訓練されたモデルは「正しく見える」ことを覚えてしまい、本人が示す自信は当てにならなくなる。 95% 正解できても、どの 5% を間違えるか分からなければ自動化はできない。 そこで Jev は RLCD（較正された判断のための強化学習） で訓練され、正直な確率を出すことを目標にしている。個々の答えは間違うこともある。 だからこそ確信度が重要で、「この答えは採用する」「これは他に回す」をプログラムが決められるようになる。 実例：Hassan 氏は詐欺と正規が半々のメール 100 通を Jev で分類した。100 通の処理は 1.42 秒で終わった。確信度 95% 未満の 31 通を Kimi K3 に精読させた結果、全体で 100 通中 96 通が正解、所要 16 秒、費用は約 $0.07 だった。そのうち Jev の分は 1 セントの 3 分の 1 にすぎない。 --- 2. 最初の作業：エージェントの各ステップを 4 つに仕分ける 実際のエージェントの実行記録を 1 つ取り出し、各ステップを次の 4 つに振り分ける。 - 文章・コード・計画を生成するもの → LLM（下書き、修正、要約、人間が読む理由説明） - 厳密なルールで決まるもの → コード（リトライ上限、予算、許可リスト、日付計算、数え上げ） - あらかじめ列挙できる選択肢から選ぶもの → Jev（振り分け、順位付け、残すか捨てるか、安全か否か、完了か否か） - 取り消せないもの → 人間（送信、支払い、公開、削除、権限変更） 3 つ目は、たいてい想像よりずっと大きい。 Jev エンジニアリングで動かすのはこの 3 つ目だけで、ほかはそのまま残す。 --- 3. Jev の 3 種類の質問と API - Choice（選択）： 用意した選択肢から 1 つを選ばせる。各選択肢の確率（合計 1）と確信度が返る。選択肢は最大 255 個まで。 - Score（評価）： 2〜10 段階の順序付き基準に当てはめる。結果は「1.3」のように段階の間の値にもなり、分布も返る。 - Noul（はい／いいえ）： 「はい」の確率を返す。0.5 は「判断できない」という意味であり、「中くらい」ではない。 ◆構築時に押さえておく事実： - エンドポイントは POST https://api.typesafe.ai/v1/systemone で、送るのは state、model、questions である。Python なら pip install typesafe-sdk のあと client.system_one(...) を呼ぶ。 - モデルは、しきい値を調整し終えたら jev-1.13.0 に固定する。jev-latest は中身が変わる。 - サイズ上限： state と全質問の合計で約 64K トークン。state と最長の質問 1 つで約 32K トークン（英語で約 15 万文字）に収める必要がある。 - 入力はテキストのみ（文字列、JSON オブジェクト・配列）で、画像は扱えない。 - レート制限： jev-1.13 では毎秒 1,200 リクエスト、25 万トークン。TypeSafe は容量の増加に合わせて変わるとしている。 - 速度と料金： 応答は 70〜500ms。 1,000 トークンの判断 1 万回で $0.42 になる。 --- 4. 関連する質問は 1 回の呼び出しにまとめる 1 回のリクエストに入れた質問は、同じ state に対して並列に評価される。 TypeSafe はこれを speculative fan-out と呼び、利用者が操作できる最大のコスト削減手段だとしている。53,777 文字の文書に 13 の質問をした試験では、13 回に分けるより 1 回にまとめたほうが 12.2 倍安く、10 倍速かった。state を 1 回送るだけで済むからである。 ◆コード例 1：問い合わせチケットの一括判定 from typesafe_sdk import Choice, Noul, Score, TypeSafeClient client = TypeSafeClient(model="jev-1.13.0") ticket_text = "先月から二重請求されています。返金してください。直らなければ解約します。" r = client.system_one( state={"ticket": ticket_text, "customer": {"plan": "pro", "refunds_90d": 0}}, questions={ "department": Choice( instructions="Which team should own the problem described in `ticket`?", criteria={ "billing": "Charges, invoices, plan changes", "bug": "Something in the product does not work as documented", "howto": "The customer asks how to do something that already works", "other": "None of the above fits", }), "frustration": Score( instructions="How frustrated is the customer, judged from `ticket` only?", criteria=[ "Neutral or positive, no complaint about the experience", "Annoyed but polite, describes wasted time", "Angry, mentions cancelling, a public review or a chargeback", ]), "refund_requested": Noul( instructions="Does `ticket` ask for money back, a refund or a chargeback?"), }, ) dept = r.answers["department"] print(dept.choice, dept.confidence, dept.probabilities) print(r.answers["frustration"].score) # 例: 1.3 のように段階の間の値にもなる print(r.answers["refund_requested"].noul) # 「はい」の確率 ◆試し方 1. Python 3 を用意し、 pip install typesafe-sdk を実行する。 2. https://typesafe.ai でアカウントを作り、API キーを取得する。 キーの渡し方（環境変数名など）は記事に書かれていないため、https://docs.typesafe.ai/api で確認すること。 3. 上のコードを http://ticket.py として保存し、python http://ticket.py で実行する。 4. ticket_text の文面を書き換えて、部署・不満度・返金要求の判定がどう変わるかを観察する。 元記事のコードでは ticket_text が未定義なので、上では例文を入れてある。 制約は 2 つある。 1 つ目に、同じ呼び出し内の質問は互いの答えを参照できない。 ある判断の結果を受けて次を決めたい場合は、必要な情報を取得してから改めて質問する。 2 つ目に、まとめて得をするのは state を共有している質問だけで、無関係な質問は別の呼び出しにする。 --- 5. 本当の技術は「質問の書き方」にある Jev の悪い答えの多くは、悪い質問に原因がある。 - 質問 ID はモデルに送られない。 is_fraud という名前を付けても意味は伝わらないので、意味は instructions と criteria に書く。 - 1 つの質問には 1 つの判断だけを入れる。 「緊急かつ有料顧客か」は 2 つの質問に分け、結果をコードで組み合わせる。 - 程度ではなく状況を書く。 「解約やチャージバックに言及している」は確認できるが、「とても怒っている」は気分であり判定しにくい。数字だけの段階も同様に避ける。 - 各段階は単独で意味が通るように書く。 段階は個別に判定されるため、「前の段階より悪い」という書き方は伝わらない。 - Noul は「高い値＝はい」になるように書く。 「true が危険を意味する」ような逆向きの質問は、バグのもとになる。 - Choice には必ず逃げ道を用意する。 モデルは何かを選ばなければならないので、other や none を入れて不確かさの行き場を作る。 - 対象のフィールドを指し示す。 `order.charges` のようにバッククォートでパスを書けば、state のどこを見る質問かが伝わる。 - state はコードで絞り込んでから渡す。 無関係な情報が増えると精度が落ちる。 「調査はほぼ終わった」と書くより出典 7 件と各主張を渡すほうがよく、ページ全体よりも関係する行だけを渡すほうがよい。 - 抽出を選択に変える。 Jev はスキーマにない値を出せない。請求書から取引先名を抜き出したいなら、既知の取引先一覧を渡して選ばせる。 --- 6. Jev の弱点と対処法 TypeSafe は jev-1.13 の苦手分野（jaggedness）を公開しており、どれにも周辺の仕組みで対処できる。 - 質問を文字どおりに読む。 あいまいな質問には文字どおりの答えが返る。 質問はコードと同じように、バージョン管理・テスト・レビューを行う。 - 計算機ではない。 件数が増えるほど数え間違いが増える。 数え上げ・合計・比較はコードで行い、結果を渡す。 - 日付を文字として扱う。 「3月3日以降」を順序として比較できないので、日付の判定はコードで行う。 - 関係ない state が多いと精度が落ちる。 state は質問に必要な分だけに絞る。 - state の内容を信じてしまう。 state に悪意ある文が混ざると答えが歪むことがある。決定的なチェックと権限管理はコード側に残す。 - テキストを受け取り、数値を返すだけである。 理由の説明もスクリーンショットの読み取りもできない。言葉や画像が必要な処理は LLM に任せる。 - 多段の推論に弱い。 推論の連鎖は劣化するので、複数回の呼び出しに分け、そのつど state を更新する。 最後の防衛線はどれも同じである。 型安全なので Jev がスキーマ外の値を返すことはないが、スキーマ内の間違った値は返しうる。 それを捕まえるのが、確信度のしきい値と 2 つ目のモデルである。 --- 7. カスケード：まず Jev、難しいものは Kimi K3 へ 冒頭の図のとおり、判断は次の 4 層を上から順に落ちていき、確信が持てた層で止まる。 1. コード： 厳密なルールを処理する。即時かつ無料である。 2. Jev： しきい値を超えた選択型の判断を約 100ms で処理する。 3. Kimi K3： しきい値未満の判断と、文章による理由が必要なものを数秒で処理する。料金は入力 $3／出力 $15（100万トークンあたり）。 4. 人間： 取り消せない操作と、両方のモデルが自信を持てなかったものを担う。 2 番手が Kimi K3 である理由： エスカレーションされた案件はスレッドや履歴をまるごと読む必要があることが多い。 K3 は 100 万トークンのコンテキストを長さに関係なく同じ単価で扱える。 Jev が読めないスクリーンショットやスキャンした PDF も読める。 重みが公開されているので、Moonshot の API、Together、自前のサーバーのどれでも同じコードが動く。 コード例 2：メール分類のカスケード import json, os from openai import OpenAI from typesafe_sdk import Choice, TypeSafeClient CRITERIA = { "customer": "A current customer asking about an order, a bill or their account", "lead": "Someone asking about prices, a demo or working together", "vendor": "Someone selling a product or service to us", "fraud": "Urgent payment request, changed bank details, spoofed sender or a login link", "other": "None of the above fits", } THRESHOLD = 0.95 # Hassan 氏の詐欺判定用の値。判断ごとに調整する jev = TypeSafeClient(model="jev-1.13.0") kimi = OpenAI(api_key=os.environ["KIMI_API_KEY"], base_url=os.environ.get("KIMI_BASE_URL", "https://api.moonshot.ai/v1")) def ask_kimi(email, jev_guess): reply = http://kimi.chat.completions.create( model="kimi-k3", response_format={"type": "json_object"}, messages=[{"role": "user", "content": f"Classify this email as one of {list(CRITERIA)}. " f"A fast classifier guessed '{jev_guess}' with low confidence. " 'Answer as JSON: {"category": "...", "reason": "...", "sure": true}\n\n' + email}], ) return json.loads(reply.choices[0].message.content) def route(email): r = jev.system_one( state={"email": email}, questions={"category": Choice( instructions="What does the sender of `email` want?", criteria=CRITERIA)}, ) a = r.answers["category"] if a.confidence >= THRESHOLD and a.choice != "other": return {"category": a.choice, "by": "jev", "confidence": a.confidence} k = ask_kimi(email, a.choice) if k.get("sure"): return {"category": k["category"], "by": "kimi-k3", "reason": k["reason"]} return {"category": "review", "by": "you", "jev": a.choice, "kimi": k["category"]} if __name__ == "__main__": print(route("至急！振込先口座が変更になりました。本日中に下記リンクからログインして確認してください。")) ◆処理の流れ 1. Jev が分類する。 確信度が 0.95 以上で、かつ other 以外なら、その答えを採用して終わる。 2. それ以外は Kimi K3 に回す。 このとき Jev の推測を参考情報として渡す。K3 が sure: true を返せば採用し、理由も記録する。 3. 両方とも自信がなければ review（人間による確認）とし、2 つの答えを並べて渡す。 並んだ 2 案を見比べるのが、人間にとって最も速いレビューになる。 4. other は単独では採用されず、必ず次の層に回る。 ◆試し方 1. pip install typesafe-sdk openai を実行する。 2. https://platform.kimi.ai で API キーを取得し、環境変数に設定する。 PowerShell なら $env:KIMI_API_KEY="取得したキー"。Together や自前ホストを使う場合は KIMI_BASE_URL も設定する。 3. TypeSafe 側のキーも設定し（方法は公式ドキュメントで確認）、python http://cascade.py で実行する。 4. 文面を普通の問い合わせに変えたり、THRESHOLD を 0.8 や 0.99 に変えたりすると、どの層が答えたか（by）が変わる様子を確認できる。 5. 完成版の実装は https://github.com/Nutlope/jev-fraud で公開されている。 --- 8. 既存のフレームワークへの組み込み 新しいフレームワークは要らない。 主要な 3 つに、すでに Jev が組み込まれている。 - LangChain（langchain-typesafe）：ミドルウェアが 2 つある。 ModelRouterMiddleware は、自分で書いた基準に沿って、リクエストを処理できる最も安いモデルを Jev に選ばせる。 AutoModeMiddleware は、ツールを実行する前に毎回危険度を判定する。 -- from langchain.agents import create_agent from langchain_typesafe.experimental.middleware import AutoModeMiddleware agent = create_agent(YOUR_MODEL, middleware=[AutoModeMiddleware(tools=["bash"])]) -- pip install langchain langchain-typesafe で導入し、YOUR_MODEL を普段使っているモデルに置き換えれば、bash コマンドを実行する前に安全判定が入る。 - Pydantic AI（pydantic-ai-slim[typesafe]）：Agent("typesafe:jev-latest", output_type=Triage) のように、出力の型がそのまま質問に変換される。bool は Noul に、Literal は Choice に、各メンバーに docstring を付けた IntEnum は Score になり、X | None を使うと「該当なし」の選択肢が加わる。FallbackModel を使えば、自信のない答えを LLM に回すカスケードが 2 行で書ける。 - Vercel AI SDK：@ai-sdk/typesafe-ai プロバイダーの experimental_evaluate から使える。AI Gateway 経由なら typesafe-ai/jev として同じ価格で使える。 --- 9. 実際の活用例 - Browser Use： 次の操作と対象要素を毎ステップ選ばせ、チューリッヒ発ロンドン行きの航空便を 7.1 秒、$0.0039 で見つけた。 - Hassan 氏の詐欺判定： 100 通中 96 通が正解、16 秒、約 $0.07。 - http://1kpapers.com： 論文 1,018 本を 24 トピックに分類し、費用は $0.08、応答時間の中央値は 256ms。 LLM で要約すると $3.99 かかる。 - Riley Brown 氏の受信箱整理：メール 500 通を 3.5 セントで仕分けた。 - デスクトップ操作（awlevin 氏）： 1 判断あたり $0.0002、0.13〜0.38 秒。Opus 5 では $0.032、5.2 秒かかる。 - セッション圧縮（tamara 氏）： まだ必要なツール呼び出しだけを選び、Claude のセッションを約 100 万トークンから 8.6 万トークンへ約 1 秒で削った。 - jev-trader（Jarrod Watts 氏）： 1 ブロックごとに 1 つの売買判断を行い、モデルの応答は約 81ms。 どの例も型は同じである。 毎ステップ、最新の状態から選択肢を作り直し、Jev が選び、残りをコードや小さなモデルが処理する。 --- 10. 大規模な場合： Kimi K3 のスウォームを Jev が操る 大きな仕事では、Kimi K3 の Agent Swarm（最大 300 のサブエージェント）が実際の作業を担う。 ターンの合間の判断、つまり「次はどの役割を動かすか」「どの結果を残すか」「目標は達成されたか」は Jev が受け持つ。 1 ターンに 3 回 Jev を呼んでも 1 セントに満たないので、毎ターン「終わったか」を確認し、自分で止まれる。 完了判定の確信度が中間帯に入ったときだけ、K3 が全体の状態を読んで判断する。 --- 11. しきい値と導入の進め方 - しきい値はモデル単位ではなく、操作ごとに設定する。 TypeSafe のドキュメントは、人間レビューの下限を 0.5、破壊的な操作の前を 0.9 としているが、これは例であって既定値ではない。 ニュースレターの振り分けなら、詐欺の警告よりずっと低いしきい値で自動化してよい。 - まず 1 週間のシャドー運用を行う。 既存の仕組みで判断を続けながら、Jev にも並行してラベルを付けさせる。 確信度の帯ごとに比較し、0.9 以上の答えがほぼ毎回一致していれば、その帯から自動化する。 - バージョンを固定し、すべてを記録する。 モデル ID、確率分布全体、しきい値、どの層が答えたか、その後どうなったかを残す。ログはそのまま評価用データになる。 バージョンを固定しておけば、来月もしきい値の意味が変わらない。 - 質問はコードとして扱う。 criteria を変えると本番の挙動が変わるので、バージョン管理し、ラベル付きデータでテストし、ずれたら元に戻す。 --- 12. コスト計算 条件は、月 1 万通のメール、Jev には 1 通あたり約 1,000 入力トークン、通常のモデル呼び出しは入力 1,500・出力 300 トークン、エスカレーション率 10% である。 - フロンティアモデル（入力 $10／出力 $50）で全件を読む場合： 入力 1,500 万トークンで $150、出力 300 万トークンで $150、月 $300。 - Kimi K3 で全件を読む場合： 入力 $45 と出力 $45 で、月 $90。 - Jev で全件を判定し、自信のない 10% だけを K3 に回す場合： Jev が $0.42、K3 が $9.00 で、月 $9.42。 フロンティアモデル単独と比べて約 97% の削減であり、タイトルの「9割減」はこの計算に基づく。 TypeSafe 自身の試算でも、サポートチケット 100 万件で $30,400 が約 $6,480 になるとしている。 --- 13. 仕事としての展開 著者は、これが収益源にもなると述べている。 - 中小企業向けの仕分けシステム構築： 初期費用と月額保守で請け負う。まず自分の受信箱でカスケードを動かし、1 か月分のログを用意する。 - 経理部門向けの詐欺・請求書チェック： メールボックス単位の料金にする。 なりすまし業者への支払いを 1 件止めれば、数年分の費用を回収できる。導入前に、相手の実際のメールでシャドー運用の結果を示す必要がある。 - エージェントのコスト監査： チームのエージェント処理を洗い出し、判断部分を Jev に移す仕事を定額で請け負う。 最も売りやすいのがこれである。 どのチームも判断にフロンティアモデルの料金を払っており、監査でまさに移すべき呼び出しを示せるからである。 --- ■まとめ エージェントの各ステップを「創る」「厳密なルール」「既知の選択肢から選ぶ」「取り消せない」の 4 つに分ける。 3 つ目を Jev に移し、関連する質問は 1 回にまとめる。基準は状況として書き、逃げ道の選択肢を必ず入れる。 確信度で振り分け、しきい値は操作ごとに決める。Jev が迷ったものは Kimi K3 に回し、取り消せない操作は人間の手に残す。 おすすめの最初の一歩は、「エージェントが 1 日に 50 回行っている判断を 1 つ選び、そこから始める」ことである。 #JEV #KIMIK3 #SWARM

这条是引用着另一条写的：x.com/polydao/status/2104783226833186920