⚠️ 本記事は Jev の実運用結果ではなく、n8n へ組み込む際の設計検証記事です。
OpenRouter / Cloudflare Workers AI / TypeSafe 直 API への接続試行を行いましたが、2026-09-19 時点では成功レスポンスを取得できていません（認証・資格情報未配置）。それでも 差し込み位置・質問設計・confidence ゲートは n8n 実装のたたき台として使えます。n8n 本番ワークフローへの常時接続は未実施です。

2026-09-19｜JevはLLMの代替ではない。「返信文を書くAI」ではなく、LLMを呼ぶべきか・人間に回すべきかを決める前段レイヤーとして効く。n8nのSwitch/IFをJev（Choice / Score / Noul ＋ confidence）に置き換えると、問い合わせ分類やSNS投稿承認の判断コストを下げつつ、確信度が低いときだけLLM再判定やTelegram承認にフォールバックできる。

結論

JevはLLMの置き換えではなく、LLMの前段・後段に置く判断レイヤーとして効く。n8nのSwitch/IFでキーワード分岐している箇所を、Choice・Score・Noul＋confidenceのゲートに差し替えると、「分類だけ安く速く」「確信度が低いときだけ人間 or LLM」という実務向きの形になる。

論点	設計の要点
差し込み位置	Webhook受信直後。生成（返信文・投稿文）は後段のLLMノードに任せる
1リクエストで聞くこと	`category`（Choice）・`urgency`（Score 1–5）・`needs_reply`（Noul）を同時に投げる（公式は並列評価）
分岐の軸	答え（`choice` / `score` / `noul`）＋確信度（Choice/Scoreの`confidence`）。Noulは確率そのものが信号
実装の正本	TypeSafe `POST /v1/systemone`（API reference）。n8n からは Cloudflare Workers AI `typesafe/jev` や OpenRouter Decisions も選択肢
コスト感（公開価格）	入力 $0.042 / 1M tokens、出力 $0（Vercel AI Gateway: Jev、OpenRouter: jev-1.13）
本記事の検証度	設計検証＋API実測試行（2026-09-19）。Jev の成功レスポンスは未取得。n8n 本番常時接続は未

既にQiitaには「Jevとは」「LLMとの違い」「速度比較」系が並んでいる（例：Jevってなんだ？、みんなの使い方調査）。本記事はn8nの業務フローにどこを差し替えるかと、確信度ゲート付きの分岐表に絞る。

なぜn8nのIFをJevにするのか

問い合わせ自動化やSNS自動投稿では、だいたい次の流れになる。

[フォーム / メール / Webhook]
  → 分類（営業？請求？スパム？）
  → 緊急度
  → 返信が要るか
  → （要るなら）FAQ検索 or LLMで下書き
  → 人間承認（Telegram ✅）
  → 送信

キーワードIFは安いが、言い回しの揺れと否定（「返金は要らない」等）に弱い。LLM分類は柔らかいが、毎回JSONを生成・パースするコストと、想定外フィールドの防御コードが乗る。

TypeSafeの説明では、Jevは文章生成ではなく型付きの判断を返す System One モデルで、複数質問を1回にまとめてもコンテキストが腐りにくい（Introduction）。Intent routing パターンも公式にある（Intent routing）。

つまり n8n では 「Switchの中身をHTTP Request + Codeにする」 のが自然。

SNS投稿前のAI判定（X/note・Telegram承認ゲート）

自分の運用で差が出やすいのは、問い合わせより SNS自動投稿の公開直前 だ。生成（LLM）は別ノードのまま、出す／止める／人間に回すだけをJevに任せる。

[LLM: 投稿文案生成]
        │
        ▼
[HTTP Request: Jev — post_verdict]
        │
        ▼
[Code: confidence ゲート]
        │
        ├─ ok + HIGH conf ─→ [X/note 投稿ノード]
        ├─ review / MEDIUM ─→ [Telegram: ✅承認待ち]
        └─ block / LOW ─→ [キュー停止・ログ]

post_verdict の Choice 例（state に生成済み文案を渡す）:

"post_verdict": {
  "type": "choice",
  "instructions": "この文案をそのまま公開してよいか",
  "criteria": {
    "ok": "問題なし・通常の告知",
    "review": "誤解・強い断定・競合言及があり人間確認が妥当",
    "block": "炎上・法務・差別・個人情報の懸念"
  }
}

post_verdict.choice === 'ok' かつ confidence >= 0.9 のときだけ投稿ノードへ。それ以外は Telegram 承認ゲート（下書き: cloudflare-workers-telegram-approval-gate.md）に合流させる。炎上リスクは「生成の質」より 公開ゲート の問題なので、n8n × 承認WFと相性が良い。

全体アーキテクチャ（問い合わせ triage）

[Webhook: 問い合わせ受信]
        │
        ▼
[Set: state 文字列を整形]
        │
        ▼
[HTTP Request: Jev systemone]
        │
        ▼
[Code: route_by_confidence]
        │
        ├─ HIGH  ─→ [Switch: category] ─→ 定型処理 / スプレッドシート / 低コスト自動
        │
        ├─ MEDIUM ─→ [LLM: 再判定 or 下書き生成] ─→ [Telegram: 承認待ち]
        │
        └─ LOW   ─→ [Telegram: 人間キュー]（ラベルだけ付けて終了でも可）

問い合わせ側も、上記SNSと同じ 「Jev → 確信度ゲート → LLM/人間」 の型に揃える。

Jevに投げる質問設計（コピペ用ペイロード）

state は問い合わせ本文（件名＋本文を連結で十分）。model はピン留めするなら jev-1.13 相当（OpenRouterは typesafe/jev-1.13、モデル一覧）。

{
  "state": "{{ $json.body.message }}",
  "model": "jev-latest",
  "questions": {
    "category": {
      "type": "choice",
      "instructions": "この問い合わせを担当チームに振り分ける",
      "criteria": {
        "sales": "見積・導入・機能の質問・デモ希望",
        "support": "使い方・障害・設定・バグ報告",
        "billing": "請求・支払い・プラン変更・返金",
        "spam": "営業メール・無関係・スパム",
        "other": "上記に当てはまらない"
      }
    },
    "urgency": {
      "type": "score",
      "instructions": "対応の緊急度（1=低、5=高）",
      "criteria": [
        "1: 情報提供のみ・急ぎではない",
        "2: 数日以内でよい",
        "3: 通常の業務影響",
        "4: 本日中の対応が望ましい",
        "5: サービス停止・金銭・法務に直結"
      ]
    },
    "needs_reply": {
      "type": "noul",
      "instructions": "担当者からの返信が必要か",
      "criteria": {
        "true": "質問・依頼・不満・確認が必要",
        "false": "通知のみ・お礼・返信不要が明示"
      }
    }
  }
}

Scoreの返り値はレベル番号の確率加重平均（例: 1.6）なので、n8n側では Math.round(score) か、レベルごとの probabilities を見る（Score primitive）。

n8nノード設定

1. HTTP Request（TypeSafe 直）

項目	値
Method	POST
URL	`https://api.typesafe.ai/v1/systemone`
Authentication	Header Auth：`Authorization: Bearer <TYPESAFE_API_KEY>`
Body	JSON（上記ペイロード。`state` は式で差し込み）

2. HTTP Request（OpenRouter Decisions API）

Jevはチャット補完ではなく Decisions API（state + questions）で叩く（OpenRouter: Submit Decisions）。

項目	値
Method	POST
URL	`https://openrouter.ai/api/alpha/decisions`
Authentication	Header Auth：`Authorization: Bearer <OPENROUTER_API_KEY>`
Body	TypeSafe と同形の JSON（`model` / `state` / `questions`）
モデル例	`typesafe/jev-1.13` または `~typesafe/jev-latest`（OpenRouter）

n8n では TypeSafe 直 (/v1/systemone) と OpenRouter のどちらを使うかを Credentials で分ける。ペイロード形状は同じで、本稿の正本は TypeSafe ドキュメント、実運用で Waitlist を避けるなら OpenRouter 経由が現実的。

3. Cloudflare Workers AI（未検証）

執筆時点では Cloudflare 経由のリクエストは未送信。 以下は公式ドキュメントに沿った n8n 直叩きの設定例のみ。

REST から叩く場合:

項目	値
Method	POST
URL	`https://api.cloudflare.com/client/v4/accounts/<ACCOUNT_ID>/ai/run`
Authentication	Header Auth：`Authorization: Bearer <CLOUDFLARE_API_TOKEN>`
Body	JSON：`{ "model": "typesafe/jev", "input": { "state": "...", "questions": { ... } } }`

Workers 内なら env.AI.run('typesafe/jev', { state, questions }) と同形。プロキシ Worker を挟む構成も可。

4. Code ノード：確信度ゲート（机上ロジック）

Jevレスポンスを items[0].json にある想定。閾値は最初は保守的に。公式も「操作の危険度で変える」としている（Confidence）。

const ans = $input.first().json.answers;
const cat = ans.category;
const urg = ans.urgency;
const reply = ans.needs_reply;

// 閾値（要チューニング・未実測）
const HIGH = 0.85;
const LOW = 0.55;

function band(confidence) {
  if (confidence >= HIGH) return 'high';
  if (confidence >= LOW) return 'medium';
  return 'low';
}

const categoryBand = band(cat.confidence);
// urgency も Choice 同様 confidence あり
const urgencyBand = band(urg.confidence);
// Noul: 0.5 から離れているほどはっきり
const replyStrength = Math.abs(reply.noul - 0.5) * 2; // 0..1 の粗い指標

let route = 'human';
if (categoryBand === 'high' && urgencyBand !== 'low') {
  route = 'auto';
} else if (categoryBand === 'low' || urgencyBand === 'low') {
  route = 'human';
} else {
  route = 'llm_review';
}

return [{
  json: {
    route,
    category: cat.choice,
    category_confidence: cat.confidence,
    category_probabilities: cat.probabilities,
    urgency_score: urg.score,
    urgency_confidence: urg.confidence,
    needs_reply: reply.noul >= 0.5,
    needs_reply_noul: reply.noul,
    reply_strength: replyStrength,
    raw: $input.first().json,
  },
}];

その後 Switch で route === auto | llm_review | human を分岐する。

擬似データでの分岐イメージ（APIレスポンス未取得）

OpenRouter への接続試行は 2026-09-19 に HTTP 401（詳細は次節）。以下は公式ドキュメントのレスポンス形状に沿った架空の3ケースで、n8n 分岐表のイメージだけ示す。

※以下の confidence 値は説明用の架空値です。

#	問い合わせ（要約）	category / conf	urgency / conf	needs_reply (noul)	想定 route
A	「請求書の宛名が違う。今月中に直したい」	billing / 0.91	3.2 / 0.88	0.93	auto → 請求ラベル＋テンプレ通知
B	「解約したのに引き落としがある。返金は不要、確認だけ」	billing / 0.72	4.1 / 0.65	0.81	llm_review（否定・引用の取りこぼし注意）
C	「資料請求の件で、御社のAI製品を代理販売しませんか」	spam / 0.48	1.0 / 0.52	0.12	human（confidence低）

Bのような文は、第三者の日本語検証でも「否定や間接表現でズレる」例が報告されている（Zenn: 48回試した）。自動返金・自動投稿には HIGH 閾値＋人間ゲートが前提。

LLM分類 vs Jev判断レイヤー（概念＋公開情報）

観点	LLM（分類プロンプト）	Jev（System One）
出力	自由テキスト → JSON化	型付き `choice` / `score` / `noul`（スキーマ外は出ない）
確信度	自前で logprobs 等を設計	Choice/Score に `confidence`（Confidence）
レイテンシ	用途依存（生成トークン分）	第三者実測: 日本語16文×3問で中央値 286ms（同上Zenn）※本記事未再現
コスト（公開価格）	モデルにより入力+出力課金	入力 $0.042/1M、出力 $0（上記 Gateway / OpenRouter）
JSONパース	必須・リトライ設計が要る	不要（HTTP JSONをそのまま分岐）
想定外ラベル	プロンプト逸脱で起きうる	Choiceは定義済み `criteria` 内（`other` を足すのが実務的）
曖昧入力	それっぽいJSONを返すことがある	`confidence` 低下＋Noulが0.5付近 → human へ
説明文生成	向いている	向かない（生成は後段LLM）

発表ブログでは LLM 比較の注記（ルーティングバイアス・スキーマ一致は保証等）もある（Introducing Jev）。自社案件で使うときは自分の文面セットで閾値を再校正する。

API接続試行ログ（2026-09-19）

項目	内容
データセット	問い合わせ分類 10件＋ SNS `post_verdict` 10件（自作短文・計20リクエスト）
再現スクリプト	`~/qiita-backup/ops/jev-bench-2026-09-19.py`（`--provider cloudflare` / `openrouter` / `typesafe`）
優先経路（方針）	Cloudflare Workers AI `typesafe/jev` → 取得できなければ設計検証として公開

試行履歴（捏造なし）

日時（UTC）	経路	結果
2026-09-18T23:57Z	OpenRouter Decisions	20/20 401（キー未設定/無効）
2026-09-19T12:22Z	OpenRouter / TypeSafe 直	401（OpenAI 系キーは Jev 経路と非互換）
2026-09-19T13:56Z	Cloudflare Workers AI	未実行 — 端末に `CLOUDFLARE_ACCOUNT_ID` / `CLOUDFLARE_API_TOKEN`（`CF_*` 可）が未配置

OpenRouter は都合により優先せず、再現手順の正は Cloudflare（公式）。TypeSafe 直 API の Waitlist はキャンペーン優先で待たない — 必要なら typesafe.ai から後日申請。

cd ~/qiita-backup
export CLOUDFLARE_ACCOUNT_ID=...
export CLOUDFLARE_API_TOKEN=...
python3 ops/jev-bench-2026-09-19.py --provider cloudflare \
  --out ops/jev-bench-2026-09-19-result.json

指標	問い合わせ10件	SNS判定10件	備考
成功率	未取得	未取得	CF 資格情報未配置
レイテンシ中央値	未取得	未取得	第三者引用 286ms（Zenn）※未再現
正解率	未取得	未取得	`accuracy_vs_gold`
`confidence` 中央値	未取得	未取得	Choice のみ
コスト	未取得	未取得	CF `usage` / ダッシュボード

実装チェックリスト

category に other と spam を入れ、想定外を「無理やり最寄り」にしない
自動実行する枝（返金・投稿・メール送信）ごとに 別の confidence 閾値を持つ
MEDIUM は LLM に「Jevの候補と確率」を渡し、再判定だけさせる（全文生成はまだしない）
LOW は人間キュー。Slack/Telegram に probabilities を添えて判断を速くする
APIキーは n8n Credentials のみ。記事・Gitに載せない
公開前 bash ops/confidentiality-scan.sh public/<basename>.md（qiita-backup 標準ゲート）

失敗パターン

パターン1: Jevを返信生成まで任せる

→ 向いていない。生成はLLM。Jevは triage とゲート。

パターン2: confidence 閾値を1つだけ

→ 請求ラベル付けと自動返金で同じ 0.8 など、事故りやすい。公式の voice banking 例のように操作別に変える。

パターン3: キーワードIFを全削除

→ スパムの明らかなパターンはルールの方が安い。ルール → Jev → LLM の段階が現実的。

パターン4: jev-latest のまま本番

→ モデル更新で分布が変わる。本番はバージョン固定（jev-1.13 等）を検討（Jev 1.13 jaggedness）。

参考リンク

TypeSafe Docs: Introduction
API reference（systemone）
Confidence-gated routing
Qiitaキャンペーン: 判断特化AI「Jev」で遊ぼう！（公開後に Qiita UI で「参加する」＋公開設定でキャンペーン選択）
Vercel AI Gateway: typesafe-ai/jev
OpenRouter: ~typesafe/jev-latest
Cloudflare Workers AI: typesafe/jev

この記事を書いた人✏️@YushiYamamoto
ITPRODX.com代表 / AIアーキテクト
Next.js / TypeScript / n8nを活用した自律型アーキテクチャ設計を専門としています。
日々の自動化の検証結果や、ビジネス側の視点（ROI等）に関するより深い考察は、以下の公式サイトおよびnoteで発信しています。