unirt.dev

AWS を退職しました

Wed, 30 Sep 2026 00:00:00 GMT

AWS を退職しました。

学生のころに AWS を使ってみて、その良さにハマりました。2021年に新卒で入社してからの5年半は、その好きなものを伝え、広めていく立場で働けた時間でした。

ソリューションアーキテクトとして主に金融系のお客様を担当させていただき、イベントでの登壇や技術コミュニティ、直近では特に AI-DLC の活動を通じて、多くの方とご一緒できました。

ここ数年で生成 AI が台頭し、SA に求められることもどんどん変わっていきました。それでも、お客様を起点に考えるという大事なところは変わりません。その上で自分に何ができるか、どんな価値を出せるかを考えながら働けたのは、自分にとって大きな経験でした。

素晴らしいお客様と同僚に恵まれ、刺激的な毎日を送れて幸せでした。ありがとうございました！

10月からは、小さなスタートアップで新しいことを始めます。
またどこかでお会いしたら、よろしくお願いします！

Jev で問い合わせを振り分け、自信のないものだけ人に回せるか

Tue, 22 Sep 2026 00:00:00 GMT

分類を自動化しようとすると、たいてい全部任せるか全部やめるかの二択になる。9割当たるなら9割は任せたい。でも外れる1割がどれか分からないので、結局すべて目視する。

確率が返るモデルなら、ここを分けられるはずだった。確信しているものは通し、迷っているものだけ人に回す。このやり方は、外れやすいところに人手を集中できるので、全件見るより安い。

同じ文面に4つ聞く

架空のネット銀行に届いた問い合わせを10件作って、それぞれに4つの質問を投げた。使ったのは Jev で、質問の型が3つある。

department（choice）：口座管理、振込、投資商品、アプリ不具合、本人確認、その他から一つ選ばせる
needs_same_day（noul）：当日中に担当者が対応する必要があるか。確率で返る
is_offensive（noul）：担当者への暴言が含まれるか
frustration（score）：穏やか、苛立ちあり、強い怒りの3段階のどこか

判断が割れるものを混ぜてある。「身に覚えのない出金が3件あります。確認をお願いします」は、文面が穏やかなのに当日対応が要る。「いい加減にしてください。3回問い合わせても誰も答えません。責任者を出してください」は、強い苦情ではあるが暴言ではない。

結果は型で綺麗に分かれた。

質問	型	一致
department	choice	10/10
needs_same_day	noul	10/10
is_offensive	noul	10/10
frustration	score	8/10

文面が穏やかで緊急、という組み合わせも、強い苦情と暴言の区別も、外さなかった。落ちたのは3段階のスコアだけだった。

線を引く場所がない

では自信のないものを人に回そう、と confidence を見にいったところで詰まった。

confidence は「その答えがどれくらい確からしいか」を表す数値で、選択肢の確率が片方に寄っているほど高くなる。ところが、返ってくる質問と返ってこない質問がある。

"needs_same_day": { "type": "noul", "noul": 0.82 },
"department":     { "type": "choice", "choice": "security",
                    "probabilities": { "security": 0.98, "account": 0.02 },
                    "confidence": 0.96 },
"frustration":    { "type": "score", "score": 0.65,
                    "probabilities": { "0": 0.36, "1": 0.63, "2": 0.01 },
                    "confidence": 0.43 }

confidence が返るのは choice と score だけだった。noul は確率そのものしか返さない。

考えてみれば当然で、二値の確率は 0.82 と言った時点で確信の度合いも同時に言っている。0.5 からの距離がそのまま確信になる。選択肢が3つ以上あると、同じ「一番高いのは0.4」でも残りが 0.35 と 0.25 に割れているのか 0.3 と 0.3 なのかで意味が違うので、別の数字が要る。

つまり noul に線を引くなら、confidence ではなく 0.5 からの距離を使うことになる。0.3 から 0.7 のあいだを人に回す、ということになる。

引いてみたが、何も買えなかった

needs_same_day でその帯に入ったのは2件だった。「昨日の15時に振込手続きをしましたが、相手先にまだ着金していないようです」が 0.41、「振込の画面でエラーコードが出て先に進めません」が 0.44。

どちらも正解だった。

noul は10件とも当たっていたのだから、当然そうなる。2件を人に回す運用は、2割を人件費に変えて、何も買っていない。

外れるものがない範囲に線を引いても意味がない。当たり前の話だが、裏返すと、精度が出ているうちは線引きの設計そのものが要らない。線が効くのは、外れるほうの質問のほうだ。

score は高いところで切らないと止まらない

落ちた frustration の2件を confidence と並べる。

ケース	Jevの答え	confidence	正解
身に覚えのない出金	苛立ちあり	0.33	穏やか
着金していない	穏やか	0.60	苛立ちあり

低い。confidence が 0.90 以上だった6件はすべて正解だった。ここまでは期待どおりだった。

ところが質問文を英語に書き換えて同じ10件を回すと、confidence 0.80 で外すケースが出た。2回の実行を合わせると、0.90 以上の12件は全部正解で、誤りは 0.33 と 0.60 と 0.80 に散っている。

0.7 で切ると 0.80 の誤りが素通りする。0.9 で切れば全部止められるが、そのとき10件のうち4件から5件が人の手に回る。半分近くを見るなら、最初から全部見るのとどれだけ違うのか。

正解のほうを疑う

もっとも、外した2件は正解ラベルのほうが怪しい。

正解ラベルというのは、ケースを作るときにこちらで付けた「本当はこうであるべき」という答えのことだ。一致率は、モデルの出力とこのラベルがどれだけ合ったかを測っている。ラベルが間違っていれば、正しい答えが不正解として数えられる。

「昨日の15時に振込手続きをしましたが、相手先にまだ着金していないようです」に苛立ちありを付けたのはこちらの判断で、文面そのものは丁寧だ。Jevは日本語版で 0.27、英語版で 0.13 と、二度とも穏やか側に置いた。どちらが正しいかは、この文だけでは決まらない。

3段階のラベルは人間どうしでも揃わない。揃わないものを正解にして測っているので、8割という数字はモデルの精度ではない。こちらが付けたラベルとどれだけ合ったか、というだけの数字だ。

確率のぶれ

線引きの話をする前に、確率そのものが実行ごとにどれだけ動くのかを見ておいた。同じ入力でも毎回まったく同じ値が返るとは限らないので、閾値の近くにいる判定は実行ごとに変わりうる。

40のケースと質問の組を5回ずつ回して、判定が反転したものは0件、確率の幅は最大 0.08 だった。

動き方に癖がある。0.00 や 2.00 や 0.06 のように端に振れているものは、5回とも小数第2位まで同じ値を返す。幅が出るのは 0.41 から 0.44、0.52 から 0.58 のような、真ん中にいるケースだけだった。

閾値の近くにいるものほどぶれる。運用としては嫌な性質だ。ただ、ぶれること自体が「ここは割れる」という情報でもある。

結局どう組むか

二値に落とせる質問は落としたほうがいい。noul は10件とも当たったうえ、確率そのものが確信の度合いを兼ねているので、読む数字が一つで済む。

3段階以上を使うなら、confidence 0.9 で切って半分近くを人に回す前提で見積もる。そして、そこまでして測っているものが本当に3段階要るのかを先に疑ったほうがいい。「苛立ちあり」と「強い怒り」を分ける必要があったのかは、今回のケースを作った側として自信がない。

線を引ける場所と、引く意味のある場所は別だった。

NGワードの正規表現を、意味で判断する Jev に置き換えられるか

Tue, 22 Sep 2026 00:00:00 GMT

投資商品の紹介文を公開する前のチェックを10件用意して、NGワードの正規表現と、意味で判断するモデルの両方に通した。正規表現が4件、モデルが9件だった。

ただし置き換えられたのは取りこぼしのほうだけで、知識が要る判定は外している。その1件も、事実を一行足したら解けた。

言い過ぎを機械で拾う

金融商品を扱うサービスでは、紹介文やお知らせを公開する前に、言い過ぎていないかを確認する工程を置くことが多い。値上がりを断定していないか、元本が減らないように読めないか、といったところを見る。最終的には人が判断するが、件数が多いので、まず機械で一次チェックを挟む。

その一次チェックは、だいたい正規表現の配列から始まる。

const NG = [/絶対/, /必ず(儲|もう)か/, /元本保証/, /損はしません/, /リスクなし/];

自然な選び方だと思う。差し戻される表現はある程度決まっているし、正規表現なら速いうえ、なぜ引っかかったかが一目で分かる。新しい言い回しが出るたびにパターンを一つ足す。リストは伸び続けるが、伸ばせばいずれ追いつくものだと思っていた。

増やしても追いつかず、増やすと誤検知が出る

個人向けのネット銀行と証券をひとつのアプリで出している架空のサービスを想定して、投資信託の紹介文を10件作った。差し戻すべき文が5件、問題ない文が5件。ケースと実行スクリプトはリポジトリに置いてある。

上の正規表現に通すと、正しく判定できたのは4件だった。

見逃したのはこういう文だった。

過去5年で一度もマイナスになっていません。今後も同様の推移が期待できます。
預金と同じ感覚でお使いいただけます。
値下がりの心配はまずないと考えてよいでしょう。
年利8%を安定して出し続けているファンドです。

登録済みのどのパターンとも語彙が重なっていない。「元本保証」とも「絶対」とも書かずに、元本が減らないことを読ませている。

厄介なのは誤検知のほうだった。

本商品に元本保証はありません。
絶対収益型のファンドとして運用しています。

前者は、むしろ書いておくべき注意文である。後者の「絶対収益型」は、相場が下がる局面でも利益を狙う運用方針を指す商品分類の名前で、これも問題ない。それでも 元本保証 と 絶対 に当たる。正規表現は、直後の打ち消しを見ないし、語がどこで切れるかも見ない。

見逃しを潰そうとパターンを増やせば、この種の誤検知が増える。片方を締めると、もう片方が緩む。

意味で判断させる

同じ10件を Jev に投げた。判断の材料になる文章と、聞きたいことの定義を渡すと、確率が返ってくるモデルである。質問は真偽を聞く noul ひとつだけ。

{
  is_violation: {
    type: 'noul',
    instructions: 'この文章に、社内のコンプライアンスチェックで差し戻される表現が含まれるか',
    criteria: {
      true: '利益や値上がりを断定する、元本割れしないと誤認させる、リスクがないかのように読ませる表現がある',
      false: '事実の記述、リスクの説明、注意喚起にとどまっている',
    },
  },
}

criteria には、パターンではなく判断の方針を書く。何にマッチさせるかではなく、何をもって差し戻すかを説明する形になる。

正規表現が4件、Jevが9件。見逃されていた4件は 0.58 から 0.88 で拾い、「元本保証はありません」は 0.09 で問題なしと答えた。打ち消しを読んでいる。

外したのは1件だけで、それが「絶対収益型のファンドとして運用しています」だった。確率は 0.59。正規表現が誤検知したのと同じ文で、Jev も差し戻す側に倒している。

真ん中に来た確率は2つあって、もう一つは「預金と同じ感覚でお使いいただけます」の 0.58 だった。こちらは当たっている。残る8件は 0.05 から 0.97 まで、どれも端に寄っていた。

0.5 のあたりに来たことは、間違えている印ではない。人間でも割れる文だという印でしかなく、どちらに倒れたかは別の話だった。

文字列の距離では解けない名寄せ

固定ルールにはもう一つの形がある。

同じ組織が「株式会社〇〇」と「〇〇」のように違う書き方で登録されることがあって、これを同じものとして扱う作業を名寄せと呼ぶ。一番素直なやり方は、登録名をキーにして完全一致で引くことだ。速いし、当たれば確実である。ただし1文字でも違うと当たらない。

名寄せを機械でやるとき、次に思いつくのが文字列の近さで測る方法になる。何文字書き換えれば同じ文字列になるかを数える編集距離が代表的で、近ければ同じ組織とみなす。

実在の金融機関名で10組を作って、同じ組織かどうかを聞いた。この「文字列が近ければ同じ」という前提が崩れるペアを、両方向に入れてある。

確率は実行ごとに 0.02 ほど動く。以下の話に効く差ではないが、手元で再現したときに小数第2位が合わないのはそのためだ。

名称A	名称B	正解	Jev
みずほ銀行	みずほ信託銀行	別	0.15
三井住友銀行	三井住友信託銀行	別	0.08
楽天銀行	楽天証券	別	0.06
野村證券	野村証券	同一	0.97
新生銀行	SBI新生銀行	同一	0.54
ジャパンネット銀行	PayPay銀行	同一	0.16

上の3組が、字面は近いのに別の会社という向き。「みずほ銀行」と「みずほ信託銀行」は2文字の追加でしかないが、別の法人である。編集距離で閾値を引けば、まず同一に倒れる。Jevは 0.15 と 0.08 で、はっきり別だと答えた。

下の3組は逆で、字面が離れているのに同じ会社だ。「證」と「証」の違いは解けた。改称も「SBI」が前に付くだけなら 0.54 でかろうじて解けた。

解けなかったのが「ジャパンネット銀行」と「PayPay銀行」で、0.16、つまり別の会社だと答えている。この2つは同じ銀行で、2021年に名前が変わった。重なっている文字は「銀行」だけなので、文字列を見るかぎり手掛かりがない。

知らないだけだった

改称の事実を、判断の材料になる文章のほうに一行足して、もう一度聞いた。

名称A: ジャパンネット銀行
名称B: PayPay銀行
参考: ジャパンネット銀行は2021年にPayPay銀行へ商号変更した。

0.96 になった。0.54 で危なかった「新生銀行 / SBI新生銀行」も、同じように事実を足すと 0.96 まで上がる。別の会社の組はいずれも確率が下がり、判定が緩くなったわけでもなかった。

推論ができなかったのではなく、知らなかっただけだった。

そして、知らないことを教える場所があった。正規表現に「この会社は改称した」と伝える書き方はない。パターンを足すか、前段に表記の対応表を持つか、どちらにしても判定の外側に別の仕組みを建てることになる。

置き換えられるのは、意味を読めば分かるほうだ。知識が要ることは置き換えられないが、判断の材料に混ぜておけば解ける。固定ルールとの差は、精度よりもまず、載せる先があるかどうかにあった。

文章を書かずに判断だけ返すモデル Jev を Workers AI で動かす

Tue, 22 Sep 2026 00:00:00 GMT

問い合わせのメールを読んで、急ぎかどうかを判定する。どの部署に回すかを決める。この手の仕事を LLM にやらせると、返ってくるのは {"urgent": true} のような短い JSON になる。

ただ、その一行を作るためにモデルがやっていることは、文章を書くときと変わらない。LLM は文字や単語のかたまり（トークン）を、先頭から一つずつ予測して並べていく。{ の次は "、その次は u、というふうに。一つ前まで出した内容を見て次を決めるので、この方式を自己回帰と呼ぶ。

欲しいのが真偽値ひとつでも、道のりは同じである。出力が長いほど時間がかかり、多くのサービスでは出力トークンにも課金される。JSON schema で形式を縛っても、一つずつ並べていること自体は変わらない。

Jev には、この並べる部分がない。

何を受け取って何を返すのか

TypeSafe が2026年9月に公開したモデルで、同社はこれを System One model と呼んでいる。名前は Kahneman の言うシステム1、速くて直感的なほうの思考から取っている。考え込まずに即答する側の役割、という位置づけになる。

渡すものは2つある。判断の材料になる文章（state）と、それについて何を聞きたいかの定義（questions）だ。返ってくるのは、質問ごとの数値だけ。文章は一文字も出てこない。

質問は3種類ある。

noul：そうである確率を 0 から 1 で返す。真偽を聞くときに使う
choice：用意した選択肢から一つ選び、どれがどれくらいの確率かも返す
score：「弱い、普通、強い」のような段階のどこに当たるかを、連続値で返す

noul は聞き慣れないが、TypeSafe が付けた名前で、真偽を確率で答える質問を指す。true か false ではなく 0.82 が返るので、boolean とは別物として名前を分けているのだと思う。

choice と score には confidence という数値も付く。これは「その答えがどれくらい確からしいか」を表す。選択肢の確率が 0.98 対 0.02 のように片方に寄っていれば高く、0.36 対 0.63 のように割れていれば低くなる。

Cloudflare には typesafe/jev というモデル ID で、他社製モデルとして組み込まれている。

Workers AI から呼ぶ

Cloudflare Workers でモデルを使うときは、設定ファイルに binding を1行書いておくと、コードから env.AI として触れるようになる（コード一式）。

{
  "name": "jev-eval-ja",
  "main": "src/index.ts",
  "compatibility_date": "2026-09-19",
  "ai": { "binding": "AI" }
}

呼び出しは、モデル ID と入力を渡すだけで終わる。

const response = await env.AI.run('typesafe/jev', { state, questions });

questions は、質問ごとに型と指示と判定基準を並べる。instructions が聞きたいこと、criteria がどう判断してほしいかの説明になる。

{
  is_urgent: {
    type: 'noul',
    instructions: 'Does this convey urgency?',
    criteria: { true: 'Explicitly time-sensitive', false: 'No urgency expressed' },
  },
  department: {
    type: 'choice',
    instructions: 'Which team should handle this?',
    criteria: {
      billing: 'Payments, invoicing, refunds',
      technical: 'Bugs, outages, integrations',
      sales: 'Pricing, upgrades, new accounts',
    },
  },
  frustration: {
    type: 'score',
    instructions: 'How frustrated is the customer?',
    criteria: ['Calm', 'Frustrated', 'Very angry'],
  },
}

state に Help! My payouts have been failing for 3 days. を入れて呼ぶと、こう返る。

{
  "is_urgent":   { "type": "noul", "noul": 0.95 },
  "department":  { "type": "choice", "choice": "billing",
                   "probabilities": { "billing": 0.98, "technical": 0.02 },
                   "confidence": 0.96 },
  "frustration": { "type": "score", "score": 0.65,
                   "probabilities": { "0": 0.36, "1": 0.63, "2": 0.01 },
                   "confidence": 0.43 }
}

score の 0.65 は、criteria に並べた3段階を 0、1、2 と見たときの位置を表す。0.65 なので「Calm」と「Frustrated」の間、やや後者寄りということになる。

confidence が付いているのは choice と score だけで、noul には付かない。二値なら 0.95 と答えた時点で確からしさも同時に言っているので、別の数値が要らないのだと思う。

ここまでは素直だった。

動かすまでに踏んだもの

一つめ。wrangler dev をそのまま起動しても動かない。

Workers AI のモデルは Cloudflare 側でしか実行できないので、ローカルで完結する開発モードでは呼べない。--remote を付けると、手元のコードを Cloudflare 上で動かす形になって通る。

npx wrangler dev --remote

二つめのほうが厄介で、最初の呼び出しがこれで落ちた。

AiGatewayError 2021: Insufficient AI Gateway credits

Workers AI には Cloudflare 自身が用意したモデルと、他社が提供するモデルの2種類がある。typesafe/jev は後者なので、Workers AI の無料枠には乗らない。AI Gateway に事前チャージしたクレジットから引かれる仕組みになっている。

ダッシュボードの AI Gateway で支払い方法を登録して Top-up したら通るようになった。購入額に5%の手数料が乗るが、モデルの利用料そのものへの上乗せはない。

値段と速さ

課金対象は入力トークンだけで、100万トークンあたり $0.042。出力は $0 と表示される。文章を書かないモデルなので、出力側で課金する根拠がない、ということだろう。

ただし応答の usage には output_tokens も入っていて、質問3つのときで63だった。テキストが一文字も出てこないのに何を数えた値なのかは分からない。料金表で出力側に値が付いていない、ということだけが確かである。

手元から Worker 経由で30回呼ぶと、応答の中央値は 261ms だった。最小は 210ms 前後で安定しているが、最大は実行ごとに 1.1 秒から 5.1 秒まで振れる。wrangler dev --remote 越しの測定なので、手元の開発セッションを一度通る分が乗っている。

一度に渡せる文章の長さは、Cloudflare の表記で 32,000 トークンまで。

日本語で使えるかどうか

TypeSafe の公式ドキュメントは、言語について「英語が主たる学習言語であり、精度もそこが一番よい」と書いている。日本語や中国語を含む他の言語も扱えるが同じようにはいかないので、自分のデータで試してから使い、確信度を見て振り分けること、という注意が付く。

ここまでの話は全部、動いたというだけの話でしかない。

なお、Jev の公開後、同じように文章を生成せず判断だけを返すモデルが、重みを公開する形でいくつか出ている。学習済みの重みが誰でも落とせるので、クラウドのAPIを経由せず手元のマシンで動かせる。Laya は Apache-2.0 で、Mac でも動く。

選択肢はあるわけだが、どれを選ぶにしても先に確かめることは同じである。実務で使うつもりなら、知りたいのは日本語でどれだけ当たるかのほうだ。

Mac で動く Laya は Jev の代わりになるか

Tue, 22 Sep 2026 00:00:00 GMT

判断をクラウドのAPIに投げると、通信の往復が乗るし、入力が外に出る。同じことが手元で済むなら済ませたい。

Jev の公開後、文章を生成せず判断だけを返すモデルが、重みを公開する形でいくつか出ている。学習済みの重みが誰でも落とせて、ライセンスの範囲で自由に使える形を、オープンウェイトと呼ぶ。クラウドのAPIを経由しないので、通信も課金もない。

その一つが Laya である。

生成しないモデルの作り

Laya は双方向エンコーダに判断ヘッドを載せた構成を取る。

用語を開くと、こうなる。文章を扱うモデルには、前から順に読んで次を予測するものと、文章全体を一度に見て各単語の意味を捉えるものがある。後者が双方向エンコーダで、BERT 系のモデルがこれにあたる。続きを書く用途には向かないが、すでにある文章を分類したり、意味を測ったりするのは得意である。

判断ヘッドというのは、そのエンコーダの出力を受けて答えを出す小さな層のことだ。「この文章は違反か」のような問いに、確率を一つ返す。

この構成だと、文章を一度通すだけで答えが出る。入力を頭から最後まで一回計算することをフォワードパスと呼ぶが、1回のフォワードパスで終わるので速い。LLM がトークンを一つずつ並べるのとは、そもそもやっていることが違う。

Apache-2.0 で重みが公開されていて、Apple Silicon 向けに移植された laya-mlx がある。MLX は Apple が出している機械学習フレームワークで、Mac のGPUとメモリの作りに合わせてある。

学習済みの重みは、用途別に何種類か公開されている。この単位をチェックポイントと呼ぶ。Laya には3つあって、括弧内はパラメータ数、つまりモデルの大きさである。

英語版：ModernBERT-large（421M）
多言語版：mmBERT-base（322M）
型付き判断に特化したもの：ModernBERT-large（421M）

多言語版だけ小さい。日本語を扱うならこれを選ぶことになる。

これまでの記事で使った30件を、そのまま多言語版に投げた。

50%という数字の読み方

金融機関名の同一性判定が 50% だった。

同じ会社かどうかを二択で答える質問で 50% なのだから、当てずっぽうと同じということになる。最初はそう読んだ。

実際には違った。laya は10件すべてに「同じ会社」と答えていた。

名称A	名称B	正解	laya
三菱UFJ銀行	株式会社三菱UFJ銀行	同一	1.00
みずほ銀行	みずほ信託銀行	別	0.99
三井住友銀行	三井住友信託銀行	別	1.00
楽天銀行	楽天証券	別	1.00
ゆうちょ銀行	りそな銀行	別	1.00

ゆうちょ銀行とりそな銀行を 1.00 で同じ会社と答える。正解が同一5件と別5件なので、全部に「同一」と答えると、ちょうど 50% になる。

数字は間違っていないが、意味が違う。「半分当たる」のではなく「見分けていない」。一致率だけを表に並べていたら、たぶん気づかないまま「二択なら五分五分か」と書いていた。

以降は、10件すべてに同じ答えを返した組み合わせに印を付けて数える。そこの一致率は、モデルの性能ではなくケースの偏りを写しているだけなので、読まない。

質問文を日本語から英語にする

同じことが frustration（3段階のスコア）でも起きていた。10件すべてが「苛立ちあり」だった。

ここで、崩れているのが日本語の本文なのか日本語の質問文なのかが分からなくなった。Jev と同じく、Laya にも判断の材料になる文章と、聞きたいことの定義を渡す。前者は日本語のまま、後者だけ英語に書き換えて回し直す。

質問	質問文 ja	質問文 en
コンプラ表現検出	40%	80%
department	40%	70%
needs_same_day	70%	80%
金融機関名の同一性	張り付き	張り付き
frustration	張り付き	張り付き

コンプラ表現検出が倍になった。判断の材料は日本語の文面のままである。

日本語が読めていなかったのではなく、日本語で聞かれると崩れていた。本文と質問文で、効き方が別になっている。

チェックポイントを型付き判断特化のものに替えると、日本語の質問文でもコンプラ表現検出は 80% に上がった。ただし needs_same_day が全件「当日対応が必要」に張り付く。英語版のチェックポイントは、日本語の本文に対しては軒並み崩れた。

どのチェックポイントでも、どちらの言語でも動かなかったものが2つある。金融機関名の同一性は6通り中5通りで全件「同一」、frustration は6通りすべてで全件「苛立ちあり」だった。

Jevは質問文の言語で動かない

比較のため、Jevにも英語の質問文で同じ30件を投げた。

	Jev ja	Jev en	laya 多言語 ja	laya 多言語 en
コンプラ表現検出	90%	90%	40%	80%
金融機関名の同一性	90%	90%	張り付き	張り付き
department	100%	100%	40%	70%
needs_same_day	100%	100%	70%	80%
is_offensive	100%	100%	80%	張り付き
frustration	80%	90%	張り付き	張り付き

Jevはほとんど動かない。frustration の1件差も、確信度 0.33 の境界ケースが反転しただけだ。

laya のほうは質問文の言語で倍近く動く。322M のモデルと、クラウドで動く規模のモデルとの差は、精度より先に、聞き方で崩れるかどうかに出た。

速さは本当

推論は30回の平均で 60.4ms だった。通信がないので、これがそのまま応答になる。最大は 607ms で、これは最初の1回だった。

Jevを同じ30件で測ると中央値 261ms、たまに1秒を超える。ネットワークの往復ぶんだけ明確に速い。

課金もない。モデルの読み込みは1秒弱で、型付き判断特化のチェックポイントを初めて落としたときで19秒だった。

どこまでなら任せられるか

needs_same_day の 80% と department の 70%（どちらも多言語版、英語の質問文）は、一次の振り分けの下書きとしてなら使える水準に見える。人が最後に見る前提で、問い合わせの並び替えと担当の初期値を作るくらいの使い方だ。無料で、通信もなく、60ms で返る。

金融機関名の同一性と3段階のスコアは、この構成では無理だった。見分けていないので、どこで切るかを決める以前の問題になる。

質問文を英語で書く、というのは運用として現実的ではある。判断の材料は日本語のままでいいので、書き換えるのは質問の定義だけで済む。ただ、それで上がるのがどのタスクなのかは、回してみるまで分からなかった。

ケースは各10件しかない。1件の当たり外れで10ポイント動くので、ここに出した数字は傾向までしか言えない。それでも、全件に同じ答えを返しているかどうかだけは、10件でもはっきり見える。