正規表現の判定ゲートをJevに任せる前に — 一致率65%→87%の実測と5分で試す手順

失敗談の記事ばかり続かないように、門番を置いた。新しい記事を「比較・ガイド・落とし穴・事例」に振り分け、直近7本のうち落とし穴型が4本以上なら次の企画を止める。判定は正規表現で、どのキーワードにも当たらなければ「落とし穴」に倒す。

既存の技術記事121本に当てて、実測で数えてみた。79本、つまり65%が、どのルールにも当たらずに「その他＝落とし穴」へ流れていた。ガイドを書いたはずなのに、48本中34本が失敗談として数えられていた（失敗談を止める門番が、いちばんの落とし穴だった）。

else の一行が、判定の3分の2を決めていたことになる。では、この一行を安い判定専用モデルに任せたらどうなるだろうか。判定専用のAIモデル「Jev」で試した記録だ。CIのラベル付け、エージェントのコマンド確認、問い合わせの振り分けを正規表現で書いている人に向けて、置き換えてよい範囲と、5分で試す手順をまとめる。

Jevは「しゃべらないAI」

JevはTypeSafe AIのモデルで、Vercel AI Gateway から typesafe-ai/jev として呼べる。LLMと同じく自然言語は読めるが、文章は一切書かない。TypeSafe自身も、LLMとは別クラスの「System Oneモデル」と位置づけている。

聞き方は3種類しかない。yes/no を聞く noul、選択肢から選ばせる choice、点数をつける score だ。「この問い合わせは返金の要求か」と聞くと、「はい」の確率を0.98のような数字で返して黙る。前置きも、「良い質問ですね」もない（ゲートに挟む部品としては、これ以上ない美徳だ）。

5分で試す：このコマンドは本番に触るか

鍵は Vercel のダッシュボードで作る。AI Gateway の API Keys ページで Create key を押し、環境変数に入れるだけだ。毎月の無料クレジットもあるが、対象は一部のモデルに限られ、レート制限も低い。Jevが対象かはモデル一覧で確かめてほしい。

export AI_GATEWAY_API_KEY="作成したキー"

エージェントが実行しようとしているコマンドを1本、判定させてみる。

{
  "model": "typesafe-ai/jev",
  "state": "psql \"$DATABASE_URL\" -c \"DELETE FROM orders WHERE status = 'cancelled'\"",
  "questions": {
    "prod": {
      "type": "noul",
      "instructions": "このコマンドは本番環境・本番の認証情報・実顧客データに触る操作か"
    }
  }
}

# 上のJSONを request.json に保存。鍵は --config 経由で渡し、プロセス一覧に出さない
printf 'header = "Authorization: Bearer %s"\n' "$AI_GATEWAY_API_KEY" |
  curl -sS --max-time 15 --config - \
    -H "Content-Type: application/json" \
    -d @request.json \
    https://ai-gateway.vercel.sh/typesafe/v1/systemone |
  jq '.answers.prod'

{ "type": "noul", "noul": 0.xx } の形で、「はい」の確率が返る。4択や5択で聞きたいときは choice を使い、選択肢ごとに説明と例を添える。答えと一緒に confidence も返ってくる。

1回の判定は数百〜千数百トークンで、入力は2026年9月の執筆時点で100万トークンあたり $0.042、出力は無料だ。1回あたり1円の50分の1にも届かない（財布が気づく前に、判定が終わっている）。

実測：正規表現65%、Jev 87%

冒頭の門番で、正規表現とJevを並べた。対象は自社ブログの既存220記事で、入力はタイトル・概要・見出し・冒頭1200字。正解ラベルは人手ではなく、Claude Opus 5 に同じ入力を読ませて付けた。

判定器	技術記事121本	業務記事99本
正規表現	65.3%	83.8%
Jev 単独	86.8%	88.9%
Jev＋閾値0.7＋正規表現フォールバック	89.3%	90.7%

最下行は、門番に組み込んだ後に公開済み218本で測り直した値で、業務記事はこのとき97本だった。ゲートが数える「落とし穴の本数」は、正解58本に対して正規表現94本、Jev 53本。偏りを防ぐ門番のはずが、止めなくていい企画まで止めていた。

判断が割れた記事は「曖昧」として別に数えた。技術記事で13本、業務記事で6本ある。サンプルは数百本なので、「この条件ではこうだった」として読んでほしい。

確率は信用していい。だから閾値が引ける

Jevの confidence は飾りではなかった。

confidence	本数	実測の正答率
0.5未満	9	44%
0.5〜0.9	34	82〜83%
0.9以上	78	94%

自信がないときは本当に外し、自信があるときは当てる。だから「自信のない答えだけ正規表現に戻す」が成立する。組み込み後の再計測でも、正規表現に戻した理由は全件が低confidenceで、応答なしは0件だった。

そのまま使える組み込みレシピ3つ

実際に動かしている組み込み方を、読者の環境に置き換えやすい形で並べる。

用途	Jevへの問い	閾値	超えたら	Jevが落ちたら
エージェントの危険コマンド	本番・本番credential・実顧客データに触るか	0.7	実行前に人へ確認を求める	何もしない
外から取ってきた文章	AIエージェント向けの指示が紛れているか	0.6	「データとして扱え」と警告	何もしない
見逃すと高くつく二値判定	非互換変更やmigrationを要するか	0.9以上でyes、0.1以下でno	その間は人に回す	人に回す

3つに共通する約束がある。確率モデルに allow を出させないことだ。Jevは確認や警告を「足す」側にだけ置き、許可は決定論のルールに残す。もう一つ、候補を字面で先に絞る。クラウドやDBのCLI、prod・deploy・migrate を含むコマンドだけをJevに回せば、ls のたびに1秒待たずに済む。

分類の門番のほうは、次の形に落ち着いた。

組み込みのコミットでは「Jev先行・正規表現を控え」に切り替え、偽の分類スクリプトを差し込んでネットワークなしで95ケースのテストを通した。回答は内容のハッシュでキャッシュし、同じ記事を二度聞かない。5択で聞いて集計時に畳むほうが、最初から4択で聞くより精度が出たのも小さな発見だった。

ハマりどころ：安いが、速くはない

安いと聞くと全部Jevに流したくなるが、実際は財布より時計の心配をすることになる。220本の判定は約 $0.016 で済んだ。一方でレイテンシは p50 1.2秒、p90 9秒、最大77秒だった（コマンドのたびに9秒待たされたら、人間のほうが先に諦める）。

混雑にも弱い。並列4で流すと、220本中46本が429で落ちた。並列2に絞り、Retry-After を守り、最大8回バックオフして全件が通った。間隔を空けずに全件を流し直したときは、218本中152本が空応答だった。

そこで、空応答は2秒→5秒の間隔で2回まで再試行し、timeoutは再試行しないことにした。時間切れは予算を使い切った後なので、待ち直しても取り返せない。後続の修正では、呼び出しの出力が空でも判定結果のJSONを壊さないガードも足した。

正規表現・Jev・汎用LLMエージェントの使い分け

観点	正規表現	Jev	汎用LLMエージェント
得意	決まった書式・語の検出	境界が曖昧な多択・yes/no	検索・多要因の推論
1回のコスト	0	1円の50分の1未満	桁違いに高い
速度	ミリ秒	p50 1.2秒、p90 9秒	数十秒〜分
出力	完全に決定的	答え＋確率で閾値を引ける	文章。揺れの幅は測りにくい
障害時	落ちない	429・timeoutあり	同上

任せないほうがいい場面

ルールが決定論で書けるなら使わない。 sandbox内で失敗するgh・gitの複合コマンドを止めるhookは、あえて正規表現だけにした。過去の失敗ログ74件を流すと54件を事前に止められ、1回約23msで済む（23msで済む仕事に、確率は要らない）。

選択肢を並べられない問いには使わない。 テーマ選定やファクトチェックは、答えの候補を先に書けない。しゃべらないAIに、作文は頼めない。

入れる前に、過去の正解で測る。 PR差分のうちレビュー不要な塊を仕分ける実験では、34本・1,834塊を過去の指摘と突き合わせた。「docsは読まなくていい」とすると重大指摘の再現率が0.821に落ち、規範文書の指摘5件を黙って捨てる計算になったので、本採用しなかった。検証用の生データは本体から外し、正解ラベルだけ残してある。モデルIDは固定版ではないので、分布が変わった気配があれば、ゲート自身の出力で測り直す。

まとめ

• 正規表現の弱点は else にある。今回は判定の65%がそこで決まっていた
• Jevは約87%、confidence 0.9以上なら94%。低confidenceだけ正規表現に戻せば、置き換えの失敗が怖くない
• 1回1円の50分の1未満。代わりにp90 9秒と429がある。並列を絞り、候補を字面で絞り、落ちたら何もしない側に倒す
• allowは出させない。決定論で書けるところと、作文が要るところには使わない

自分のコードで else や default: を探し、そこに落ちている件数を数えてみてほしい。多ければ、それが最初の置き換え候補だ。hookでの多層防御はエージェントの本番実行事故をhooksで防ぐ設計に、LLM判定の誤検知は品質ゲートが自己言及で誤検知する話にまとめている。