LLM ルーティングとガードレールはどう作る？Jev と大規模言語モデルの協働事例

利益相反と証拠の開示：PandaNpc は Jev を使った Agent 意思決定レイヤーを開発中です。以下では TypeSafe の公式ドキュメント、公式 cookbook、および私たちのリポジトリにある実際の Jev 呼び出しと合成シナリオのキャリブレーションをそれぞれ引用します。私たちのキャリブレーションはスクリプト化された偽 LLM provider を使用しており、実ユーザートラフィックや完全な本番経路の性能を代表するものではありません。

LLM ルーティングは次のようにできます。まず Jev にリクエストがどの種類で、リスクがどれくらい高いかを判断させ、次にコードが通常の関数、専門 LLM、または人手レビューのどれに渡すかを決めます。 Jev は検索と生成の間で証拠を選別したり、LLM 出力後に結果を検査したりすることもできます。Jev が返すのは閉じた選択肢、スコア、確率です。自由形式の回答、コード生成、長い推論は依然として LLM が担います。TypeSafe によるコーディングエージェントの説明は、Jev が Claude Code や Codex の背後にあるチャットモデルを直接置き換えるものではないと明確に述べています。

この記事では、1件のカスタマーサポートリクエスト、1本の RAG 質問応答パイプライン、私たち自身の Agent キャリブレーション記録を用いて、2種類のモデルがどこで引き継ぐのか、そして低 confidence の結果に明確な行き先がなぜ必要なのかを説明します。

Jev が判断できること、LLM が引き続き担うこと

2026年9月23日時点で、TypeSafe のモデルページに掲載されている安定モデルは jev-1.13.0 です。API は1つの state と questions のセットを受け取り、POST /v1/systemone を通じて対応する構造化された answers を返します。jev-latest は当日 1.13.0 を指していましたが、エイリアスはバージョンとともに変わります。閾値をキャリブレーションしたシステムは、バージョンを固定し、レスポンス内の実際のモデル ID を記録するのが望ましいです。

Noul には独立した confidence フィールドはありません。Noul の確率をそのまま「モデルの信頼度」と書くことはできません。Score も正確な金額の計算に使うべきではありません。金額、日付比較、クォータ、権限チェックは決定論的プログラムに残すべきであり、公式は Jev 1.13 におけるこれらの境界を挙げています。

1回の呼び出しの最小形

以下のリクエスト形状は公式 API リファレンスと一致しています。例示した質問は本記事で構成した説明用の設定であり、本記事ではオンライン実測を行っていません：

以下のJSONでは英語の顧客メッセージを使用していますが、日本語では顧客は「注文で二重に請求されてしまったので、返金をお願いします。」と言います。

{
  "model": "jev-1.13.0",
  "state": {
    "message": "My order was charged twice. Please help me get a refund.",
    "account_note": "Customer asks about an order charge"
  },
  "questions": {
    "intent": {
      "type": "choice",
      "instructions": "What does state.message primarily request?",
      "criteria": {
        "refund": "Money returned for a charge",
        "information": "An explanation only",
        "other": "Neither option fits"
      }
    },
    "asks_refund": {
      "type": "noul",
      "instructions": "Does state.message explicitly ask for money back?"
    }
  }
}

実際のシステムでは、まずコードで請求記録が同じ注文に属するか、返金が許可されているかを確認する必要もあります。上記の例はユーザー意図を読み取るためだけのものです。ユーザーが返金を求めることは、返金資格が証明されたことを意味しませんし、まして返金を直接実行する権限を与えるものでもありません。

Jev で LLM ルーティングを行う：3つの引き継ぎ経路

TypeSafe 公式の意図ルーティング例では、カスタマーサポートのリクエストをまず Jev に渡して意図と複雑さを判断させ、その後コードで振り分けます：注文状況の確認はデータベース関数へ；製品に関する質問と返品・交換はそれぞれ異なる資料を読み込んだ専門 LLM へ；複雑な苦情や低 confidence の結果は人手キューへ。これが Jev と LLM の最も理解しやすい協働です。前者が構造化された判断を出し、後者は説明や対話の生成が必要なときだけ登場します。

実装時は、モデルにすべての動作を自由に決めさせるのではなく、以下の順序で設計できます：

1. まず経路を定義する：通常の関数、各専門 LLM、人手レビューが処理できるリクエストを明確に列挙し、Choice には other などのフォールバック選択肢を用意します。
2. 事実を state に入れる：ユーザーの発話、アカウント状態、注文記録をそれぞれフィールドにします。出所不明な Web ページのテキストをシステム指示として扱わないでください。
3. 一度に狭い質問を尋ねる：意図には Choice、リスクや緊急度には Score、確認が必要な単一の事実には Noul を使います。公式は、同じ state に対する複数の独立した質問を同一リクエストで並行評価できると推奨しています。
4. 最終ルーティングはコードが行う：まず権限とハードルールを確認し、次に Jev の確率と本業務でキャリブレーションした閾値を見ます。低 confidence または証拠不足のリクエストは人手または追加質問へ回します。
5. 結果を記録して再確認する：モデルバージョン、質問バージョン、確率、最終的な行き先、人手による訂正結果を保存して初めて、閾値が適切か判断できます。

出典：TypeSafe AI「Introducing System One Models & Jev」、2026-09-15。4つのワークフローは TypeSafe が自作したもので、指標はワークフローごとに等重みで集計されています。評価方法は TypeSafe workflow evals を参照。

この公式図は、TypeSafe がなぜ「複数の狭い判断をプログラムのワークフローに組み込む」ことを強調するのかを理解する助けになります。図の縦軸はベンダーの「accuracy」という名称を踏襲していますが、その参考回答は2つの大規模モデルが予測した確率の合意から得られたものであり、人手で検証された唯一の正解ではありません。コストと指標もこれら4つのワークフローとベンダーの評価方法に依存するため、「どんなシナリオでもどれだけ節約できるか」に換算することはできません。

検索拡張生成：Jev が LLM の回答前に証拠を選別する

TypeSafe の RAG passage cookbookは、より具体的なマルチモデル例を提供しています：OpenAI embedding がまず段落を取得し、Jev が各「質問＋段落」に対して4つの Noul を尋ねます——関連しているか、回答に使用できる証拠を含むか、質問の前提に反論するか、回答モデルに指示を与えようとしているか。コードは4つの確率を順に処理し、その段落を証拠領域、衝突証拠領域に置くか、破棄するかを決めます。最後に Claude Sonnet 5 が回答を書きます。

このステップはよくある問題を解決します。ベクトル類似度が高い段落が必ず使えるとは限りません。類似語を使っているだけかもしれないし、フォーラム投稿に「前文を無視せよ」というプロンプトインジェクションが紛れ込んでいるかもしれません。cookbook の例では、インジェクションチェックをルーティングルールの最前面に置き、同時に、閾はそのコーパス向けに選んだ出発点であり、すべての RAG アプリケーションのデフォルト値ではないと注意を促しています。そのデモ数値は 2026-08-27 の jev-1.12 によるもので現在の jev-1.13.0 の新しい評価結果として扱うことはできません。

生成後には、もう一層の照合を行うこともできます。TypeSafe の引用チェック cookbookは、まずプログラムで引用元の原文を探し、次に Jev でその段落が生成された主張を支持するか、反論するか、言及していないかを判定します。これは再確認に値する引用を拾い出せますが、モデルの判断自体は依然として間違う可能性があり、「チェックを通った」ことを事実の保証として書くことはできません。

私たちの Agent キャリブレーション：低 confidence のエスカレーションはどこで詰まるのか？

PandaNpc リポジトリでは、Jev クライアント、質問バンク、オーケストレーターが、Jev を Agent の意図認識、候補修正のスコアリング、完了条件の確認、コミット判断に使用しています。クライアントはタイムアウト、429、5xx に対して限定的なリトライを行い、リクエスト予算と期限切れ結果に制限を設けます。実行権限はオーケストレーターと制御されたツール層が握っており、Jev の1つの判断によって直接付与されるものではありません。

私たちは 2026-09-22 に jev-1.13.0 を使い、19 個の合成 turn をそれぞれ shadow と enforce で 1 回ずつ実行し、合計38回の実行で165件の実際の Jev 意思決定を記録しました。この内部キャリブレーション報告と保存された実機レスポンスは、スクリプト化された偽 LLM provider を使用しているため、これらのデータは制御されたシナリオにおける意思決定の挙動だけを示します。実ユーザーリクエスト下での全体的な成功率、削減率、エンドツーエンド遅延を証明するものではありません。

最も価値のある発見は平均速度ではなく、「一見安全に見える」閾値が渋滞を引き起こしたことです。enforce の19 turn のうち13 turn が、Q2「情報は修正を始めるのに十分か」の時点で、Noul の確率が当初定めた 0.15–0.85 の不確実区間に入ったためにエスカレーションされ、LLM Worker が後続ステップを実行する機会を得られませんでした。キャリブレーション記録では、情報が十分と注釈された34件の Q2 意思決定のうち、多くが中程度の確率でした。報告書は、複雑な Q2 をより原子的な判断に分割するか、エスカレーションルールを調整することを提案しています。これらは提案であり、すでにデプロイされた閾値ではありません。

私たちの質問バンクは入口を answer_only、inspect、modify、out_of_scope のいずれかに判定します。書き込み経路では、Worker が提示した候補修正をまず Score で順位付けし、最終的な内容と変更サマリーが受け入れとコミットの判断を経ます。これらは意思決定ポイントにすぎません。実際に対象を読み書きできるかどうかは、依然として制御された実行者が段階に応じて権限を付与するかで決まります。Jev にはツールの許可リストを自ら緩める権限はなく、コミット前の整合性チェックを迂回することもできません。

キャリブレーションデータはもう一つのトレードオフを明らかにしました。shadow モードでは、Jev は回答と完全な分布を出しますが、Worker 本来の実行経路は変えません。enforce モードでは、回答が継続、エスカレーション、破棄の判断に影響します。shadow の accuracy をそのまま enforce の完了率と見なすと、システムを誤解します。Q2 のエスカレーションがタスクを早い段階で止め、後続の候補スコアリング、受け入れ、コミットの質問がそもそも出る機会をなくすからです。したがって、この報告書は各質問の分布、エスカレーションの方向、最終状態を分けて読んでいます。

候補修正には具体的な対照があります。同じ turn で、対象を正確に修正する候補は 2.94 点、ファイル全体を上書きする候補は 0.38 点でした。高得点の候補が選ばれました。この例は、その合成シナリオにおいてスコアリング質問が2つの案を区別したことだけを示します。逆に、証拠が切り詰められた候補は 2.27 点でしたが、数値が「悪くない」ように見えるからといって、その低 confidence と切り詰めマークを無視してはいけません。私たちのコードは証拠不足を別個に識別し、モデルが保持されたプレフィックスだけに基づいて確定的な書き込み判断を下すのを避けます。

私たちはさらに、「どの候補を選ぶか」と「それを書き込ませるか」を2つの異なるステップに分けています。候補が Jev のスコアリングを通過した後、制御された実行者は ACT/modify 段階でのみ書き込みツールを開放します。発行されるワンタイムチケットは、ツール呼び出し ID、現在のリビジョン番号、対象オブジェクトのハッシュ、引数のダイジェストに紐づきます。候補テキストがモデルに「制限を無視せよ」と誘導したとしても、これらのチェックを越えるツール権限は得られません。これは私たちがコードレベル統合から得た経験です。確率判断はどの道を進む価値があるかを決め、副作用の権限は再確認可能なプログラム条件によって決まります。

失敗経路も同様に設計する必要があります。クライアントはタイムアウト、ネットワークエラー、429、5xx のときだけ限定的にリトライします。キャンセル後、または turn の締切を過ぎた回答は直接破棄されます。enforce モードで Jev が利用できない場合、降格の許可が得られていなければ続行できません。llm_only で進むことが許可された場合、実行者は読み取り専用に固定されます。ブランチですでに変更が発生した後に Jev を失った場合、オーケストレーターはラウンド全体を失敗としてマークし、後続の LLM に意思決定レイヤーを欠いたまま書き込みを補完させることはしません。これらの経路はユーザー体験にコストを課しますが、「モデルが一時的に利用できない」ことが密かに「書き込み権限はそのまま」に変わるのを防ぎます。

キャリブレーション報告はさらに「低 confidence のエスカレーション」と「実行拒否」を区別しています。たとえば、正しい discard でも confidence が統一された 0.85 の閾値に達していなければ、ユーザー入力が必要として記録されます。これは誤った通過を意味しません。報告はこれに基づき、コミットと破棄の閾値を分けることを提案していますが、現時点ではまだ提案です。ワークフローを書くときは、誤った通過、誤った拒否、保留審査の3つの結果を明確に区別しなければなりません。そうでなければ、同じデータセットから誤った閾値結論が導かれます。

この事例は、Jev と LLM の連携を「Jev が先に判断し、LLM が後で作業する」とだけ描いてはいけないことを教えてくれます。各判断について問うべきです。不確実区間はどれくらい広いのか？後続プロセッサが永遠にタスクを受け取れなくなるのか？入力証拠が切り詰められた場合、推測するのではなく明確にエスカレーションできるか？私たちの実装では、state ビルダーが evidence_truncated を記録し、呼び出し側が証拠不足の経路を不確実として扱えるようにします。カウントやソートなどの決定論的計算は先にコードで完了させ、Jev に推測させません。公式 Jev 1.13 の既知の制限も、カウントと算術をコードに残すことを推奨しています。

LLM ガードレールはどこに置くべきか？

TypeSafe の LLM guardrails cookbookは、Jev を LLM の入力側と出力側の両方に置きます。Noul のセットで異なるリスクを識別し、Score で深刻度を測り、コードがポリシーに従って通過、人手レビュー、ブロック、サポートへの転送を決めます。通常の入力でも不適切な生成結果が得られる可能性があるため、出力もチェックする必要があります。

この種のガードレールの境界も同様に明確です。Jev はあらかじめ書かれた質問に従って内容をチェックできますが、万能の安全証明ではありません。公式の制限ドキュメントは、悪意ある内容が判断に影響し得ると明確に述べ、criteria を明確に書き、境界をテストすることを求めています。私たちの合成サンプルでは、候補パラメータに対するインジェクションプローブを16回行い、順位反転は0回でした。サンプルが小さすぎるため、「プロンプトインジェクション耐性は解決済み」と結論づけることはできません。ツールが実際に何をできるかを決めるのは、依然としてコード内の許可リスト、段階ゲート、コミット前チェックです。

どんなときに適し、どんなときに使わないべきか？

Jev が適するのは、候補集合が既知である、質問をいくつかの短い判断に分割できる、ソフトウェアが自動処理か人手エスカレーションかを決めるために確率を必要とする場合です。たとえば、カスタマーサポートのルーティング、RAG 段落の選別、Agent 候補アクションのスコアリング、生成結果内の引用チェックです。返信を書く、コードの一部を修正する、複雑な推論過程を説明するといったタスクでは、LLM が引き受けます。正確な金額計算、日付比較、アクセス制御の確認などのタスクでは、プログラムが直接計算すべきです。モデルページはさらに、Jev がテキストのみを受け付け、英語が現在最も性能の良いトレーニング言語であると説明しています。中国語のシナリオでは自分のデータで評価する必要があり、英語 cookbook の閾値をそのまま流用することはできません。

実際の Agent が権限とツール呼び出しをどう扱うかを観察したい場合は、まず PandaNpc Agent をご覧ください。コーディング Agent の境界と使用シナリオについては、Claude Code と Codex の比較 も参照できます。

読者は非常に小さな検証セットから始められます。「明らかに自動処理できる」「明らかに拒否すべき」「意味が曖昧」「悪意ある指示を含む」の4種類のサンプルを用意します。まず人手アノテーションを確定し、次に Jev の各質問の確率とルーティング結果を記録します。成功基準は、すべてが自動通過することではなく、自動処理経路のエラー率と人手エスカレーション量の両方が許容範囲に収まることです。曖昧なサンプルが同じ質問で大量に詰まる場合は、まずその質問に複数の判断が混ざっていないか、state が長すぎないか、閾値がローカルデータでキャリブレーションされているかを確認してください。

FAQ

Jev は Claude Code、Codex、またはチャットモデルを置き換えられますか？ いいえ。TypeSafe は Jev をソフトウェア内の構造化意思決定モデルとして位置づけています。チャット、文章作成、コード生成には依然として LLM が必要です。

戻り値の型が固定なら、間違えないのですか？ いいえ。固定型はパースや範囲外出力の問題を減らしますが、分類、スコアリング、事実判断は依然として間違う可能性があります。低 confidence と高リスクの経路には人手レビューを残すべきです。

同じリクエストでいくつの質問を尋ねられますか？ 同じ state を共有する複数の独立した Choice、Score、Noul を1回のリクエストに含められます。質問はそれぞれ評価され、複雑な判断は依然として分割し、コードで組み合わせるべきです。

中国語は使えますか？ 公式は中日韓の文字を含む自然言語をサポートすると述べていますが、英語の accuracy が現在最も良いです。中国語のワークロードは個別に検証とキャリブレーションが必要です。