その問い合わせ、毎朝だれが仕分けていますか。
届いたメールを開いて、注文の話か、故障の話か、支払いの話かを見分ける。見分けたら担当へ回す。
一件あたりは10秒で終わります。それが毎日40件あると、片づける前に午前が終わります。
この作業をAIで自動化しようとすると、たいてい「精度」の話になります。
何％当たるのか。外したらどうするのか。そこで止まる相談を何度か見ました。
私は先に別のことを決めるべきだと考えています。どの案件を人に戻すかです。
今回は、選択肢と確信度を返すモデル Jev（TypeSafe）を使い、それを確かめました。例文を作り、実際に投げて、全件を記録しています。
Jevは2026年9月半ばから急に記事が増えました。Qiitaの検索APIでタイトルに「Jev」を含む記事を数えたところ、
9月17日から22日までの6日間で128本（2026-09-22時点で私が集計）。ただしLGTMの中央値は0でした。
紹介記事は出そろっています。足りないのは、日本語の実務文で「どこで外れるか」を数えた記録のほうだと考えて、この記事を書きました。
先に結論：44件のうち、人が読むのは14件にできた
架空の事業（小型家電の販売と修理受付）を想定し、問い合わせの例文を54件用意しました。
正解はAIの出力を見る前に決めています。 うち10件は基準を検討するときに中身を見たので調整用として集計から外し、
残る44件を最終評価用としました。Jevに窓口を選ばせた結果が次のとおりです。
表の「確認基準」は、これを下回る確信度の問い合わせを人に戻す、という境界の値です（確信度は後で説明します）。
| 確認基準 | 人が読む | 自動で片づく | 自動のうち誤り |
|---|---|---|---|
| Jevを使わない（全件を人が読む） | 44件 | 0件 | 0件 |
| 0.50 | 6件 | 38件 | 10件 |
| 0.70 | 7件 | 37件 | 9件 |
| 0.90 | 14件 | 30件 | 2件 |
| 1.00 | 22件 | 22件 | 1件 |
ここで見てほしいのは、同じ判定でも線の引き方で結果が入れ替わることです。
44件を全部人が読んでいた仕事が、基準0.90なら14件になります。代わりに、自動で送った30件のうち2件は間違った窓口へ行きます。
基準を最大の1.00まで上げても、誤りは1件残りました。今回のデータでは、厳しくしても誤りはゼロになりませんでした。
どの行を選ぶかは、業務の性質で変わります。誤配送が致命的な窓口なら0.90でも足りないかもしれません。
大事なのは、この表を見ながら決められる状態を作ることです。
Jevは「選択肢と確信度」を返す
今回使ったのはTypeSafeの Jev です。文章を書くAIではありません。
決めておいた選択肢から1つ選び、選択肢ごとの確率と、答えがどれくらい1つに集中しているかを表す 確信度 を返します。
リクエストは、状態（問い合わせの本文）と質問（選択肢と指示）を一度に送る形です。
{
"state": "注文したあとに引っ越しが決まりました。配送先の住所を変更できますか。",
"model": "jev-latest",
"questions": {
"desk": {
"type": "choice",
"instructions": "この問い合わせを担当する窓口を1つ選んでください。",
"criteria": {
"order": "注文内容の確認と変更、配送と受け取り方法、在庫と入荷…",
"repair": "故障や動作不良の相談、修理の受付と進み具合…",
"billing": "支払い方法、請求書と領収書、二重請求や引き落としの確認…",
"out_of_scope": "営業や提案の連絡、採用の問い合わせ…"
}
}
}
}
返ってくるのは窓口のIDと数字だけです。文章から窓口名を読み取る処理も、書き方が崩れたときの後始末も要りません。
振り分けにこれを選んだ理由は、確信度という数字が返ることに尽きます。
文章で答えるAIだと、返ってくるのは「おそらく注文窓口だと思われます」という言葉です。読めば分かりますが、線は引けません。
数字が返るから「0.90を下回ったら人が見る」と決められます。
ただし、モデルを選んだだけでは業務に載りません。線をどこに引くかは、こちらが決めることです。 そこから先が今回の検証でした。
なお、確信度は正解の確率ではありません。選択肢ごとの確率がどれくらい1つに寄っているかを表す統計値です
（公式ドキュメントのConfidenceの項にも明記されています）。
確信度0.95は「95%正しい」ではありません。ここを取り違えると、数字を信じすぎます。
業務に載せるとき、「精度を上げる」より先に決めることがある
精度の話が行き止まりになりやすいのは、外れたときの受け皿が決まっていないからです。
受け皿が決まっていれば、話は「何％当たるか」から「人が何件見るか」に変わります。
これは見積もれる数字です。人員の話にもできます。
だから私は、要件定義でまず次の3つを決めました。
決めごと1：窓口と担当範囲
窓口は3つにしました。注文窓口、修理窓口、請求窓口です。
これに「対象外」を足して、4つの選択肢にしています。営業の電話や採用の問い合わせを、無理にどこかへ押し込まないためです。
担当範囲は文章で書きます。たとえば修理窓口は「故障や動作不良の相談、修理の受付と進み具合、交換部品、保証の適用、故障が理由の返品」。
最後の一文が効きます。「届いた電子レンジが最初から動きません。返品したいです」は、返品という言葉が出ていても修理窓口です。
この線引きを先に文章にしておかないと、人が判断しても揺れます。
決めごと2：迷う案件は人に戻す（3つの条件）
-
複数の用件が混ざった問い合わせは、人に戻す。
「注文したトースターの色を変えたいのと、先月分の領収書の再発行もお願いしたいです」を1つの窓口だけで完結させると、もう片方を取りこぼすおそれがあります。 -
判断材料が足りない問い合わせも、人に戻す。
「先日の件、どうなりましたか」に正解の窓口はありません。 -
「対象外」が選ばれたら、確信度に関係なく人に戻す。
これはAIの判断ではなく、こちら側の規則です。
ここで、AIに任せる部分と人が持つ部分がはっきりします。
選ぶのはJev。戻す条件を決めるのは人。 逆にはできません。
実測してわかったこと（54件）
2026年9月22日、54件すべてをJevへ実際に送って記録しました。API呼び出しの失敗は0件（再試行を含めて、エラーで落ちた件がゼロ）。
リクエストしたモデルは jev-latest、応答に記録されたモデルIDは jev-1.13.0 でした。
- 1件あたりの応答時間は中央値630ミリ秒（487〜872ミリ秒）。1件ずつ順番に、各例文1回だけ、通信時間込みで測っています。
- 費用は54件で試算$0.0013。入力31,310トークン、公式の料金表は入力100万トークンあたり$0.042で出力は無料。
- 54件すべてが、決めておいた4つの選択肢のまま返りました。書式の崩れはゼロです。
誤りの中身のほうが、数字より重要でした。
例文の種類ごとに、基準0.90での誤りを数えるとこうなります。
| 例文の種類 | 件数 | 誤り |
|---|---|---|
| 用件が1つ | 18件 | 0件 |
| 複数の用件 | 7件 | 2件 |
| 窓口の境界（返品や部品など） | 5件 | 1件 |
| 遠回しな表現 | 4件 | 1件 |
| 打ち消しの表現 | 3件 | 0件 |
| 情報が足りない | 4件 | 0件 |
| 対象外 | 3件 | 0件 |
用件が1つの問い合わせは、18件すべて想定どおりでした。 基準を0.70に下げても同じです。
「修理の相談ではありません。注文した商品がまだ届かないので」のような打ち消しの表現も、
「昨日の夜から、いつもと違う音が台所から聞こえます」のような症状だけの文も、正しく読み分けています。
外したのは、複数の用件が混ざった問い合わせに偏りました。基準0.70では7件中5件が誤りです。しかも高い確信度で、片方の窓口へ送ります。
先ほどのトースターと領収書の例では、注文窓口を0.88、請求窓口を0.12。確信度は0.84です。迷っている様子はありません。
これはモデルの欠陥というより、こちらの質問の作り方の問題だと考えています。
「窓口を1つ選べ」と聞いたのだから、素直に1つ答えます。用件が2つあることを知りたいなら、質問を分けるべきです。
もう1つ気づいたことがあります。確信度がちょうど1.00の件が、44件中23件ありました。
だから基準を1.00にしても、自動で送られる件が22件残ります（23件のうち1件は「対象外」を選んだので、規則どおり人に戻ります）。
「基準を最大にすれば全部人が見る」とはならない。ここは実装でも表示でもテストでも、基準以上なら自動と揃えておく必要があります。
触って確かめられるようにしました
この54件は、ブラウザで1件ずつ再生できるようにしてあります。
🔗 デモ：問い合わせ振り分けラボ
画面ではJevのAPIを呼んでいません。事前に記録した応答を再生しているだけです。
閲覧のたびに課金されるのを避けるためと、「いま推論している」と誤解させないためです。
自由入力欄も置いていません。代わりに、確認基準のスライダーを動かすと、保存済みの判定をブラウザの中で計算し直します。
誤った判定も隠さず全件並べています。自作の評価データで、正解を決めたのも私です。
書き手と採点者が同じという弱点があるので、この件数から「日本語の実務全般で使える」とは言えません。
よくある質問
Q. 確信度は正解の確率ですか？
A. 違います。選択肢ごとの確率が1つに集中している度合いを表す数字です。確信度が高くても誤ります。今回も高い確信度のまま外した件がありました。
Q. 基準を上げれば誤りはなくなりますか？
A. なくなりません。今回の実測では基準を1.00にしても誤りが1件残りました。上げると、人が読む件数のほうが増えます。
Q. 費用はどれくらいかかりますか？
A. 今回の54件は公式単価による試算で$0.0013でした（入力100万トークンあたり$0.042・出力は無料）。1日40件を1年間続けても、同じ平均文字数・同じ単価なら試算で$0.36ほどです。実際の料金は送る文章の長さで変わります。これはAPIの利用料だけの話で、下の質問も併せてご覧ください。
Q. API利用料のほかに何が必要ですか？
A. メールや問い合わせフォームからの取り込み、判定結果を担当へ渡す仕組み、人に戻した件を捌く運用、そして作るための開発費が要ります。今回測ったのは判定そのものだけです。人の確認にかかる時間は測っていません。
Q. 他のモデルと比べてどうですか？
A. 今回はJevだけを測りました。同じ問い合わせを他のモデルに解かせていないので、速さと費用の優劣は言えません。
おわりに
振り分けの自動化は、当てにいく仕事ではありません。戻す条件を決める仕事です。
決めておけば、Jevが外しても業務は壊れません。決めていないと、当たっているうちは平気で、外した日に止まります。
次は、人に戻した件をどう捌くか（優先度と再入力の設計）を書く予定です。
「自社の問い合わせで同じことを試したい」「まず何を決めればいいか整理したい」というご相談を承っています。
いまの受付方法、1日のおおよその件数、振り分け先の数をメッセージでお知らせいただければ、人に戻す条件の設計から一緒に決めます。
やり取りはすべてテキストで完結します。
業務の流れを整理して「何を作るか」を決めるところ（要件定義）から、運用後の保守まで対応します。
- ホームページ：https://mamagotolab.com
- ご依頼（クラウドワークス）：https://crowdworks.jp/public/employees/6942778
関連記事
ママゴトラボは、業務の自動化ツールを**「何を作るか」を決めるところ（要件定義）から設計してつくる**開発ラボです。
属人化した業務の見える化から、自動化ツールの開発・保守まで承っています。
👉 ママゴトラボ｜業務自動化の開発ラボ