Jev形式の小型AI「Jiwo」を日英20件で検証。問い合わせの振り分けを任せられる？

ただし、公式が説明する学習データは英語中心で、ほかの言語は未評価です。編集部では同じ架空の10場面を日英にして、0.8B版を手元のMacで計20回試しました。明確な部署の一致は日本語7/8件、英語8/8件。一方、複数部署にまたがる依頼は両方とも見逃しました。 本記事では、その違いを生の応答と教材から確認します。

確認日は2026年10月6日です。これは限られた入力の小試験であり、日本語の一般的な正答率や、Jevとの性能比較ではありません。公式モデルカードの言語と限界

Jiwoは文章を読み、指定した候補それぞれの確率を返すモデルです。文章の回答や判断理由を長く生成する用途とは異なります。入力と出力はJevのAPI（Application Programming Interface）形式に合わせていますが、独立したプロジェクトで、TypeSafeが推奨・保証しているものではありません。公式README

0.8B版の重みが追加されたのは日本時間10月5日17時27分、実行コードの初コミットは同日21時40分です。翌6日2時2分のHacker News投稿は、その後の紹介です。正式なGitHubリリースタグは確認時点ではなく、本稿ではコードとモデルのコミットを固定しています。重みの初回公開、コードの初コミット、HN投稿

選択問題は最大255候補、段階評価は2〜10段階です。入力を作る側が候補と意味を定義します。「どこへ回すか分からない」案件を残したいなら、確認用の選択肢や運用を自分で設計する必要があります。固定版の入力検査

公式にはH100での処理時間や外部ベンチマークの数値もありますが、作者による提出値で、評価サイトの管理者による検証は未了と明記されています。日本語の問い合わせや手元のMacに、その数字を当てはめることはできません。製品の役割はJev・Laya・Jeff・Micaの比較も参照してください。

教材は架空の社内窓口です。選択肢を accounting（経理）、it（情シス）、hr（人事）、general（総務）、human_review（人の確認）の5つにしました。英字IDと並び順は両言語で同じにしています。

経理なら経費精算や請求支払、情シスならVPN接続やアカウント認証というように、担当の境界を先に文章で決めました。複数部署の用件が混ざるときと、情報不足で担当を決められないときは human_review を期待します。「一番近い部署へ必ず送る」という課題にはしていません。

問い合わせだけでなく、振り分け規則、質問、選択肢の表示名も同じ意味で日英化しています。したがって、業務入力全体の言語を変えた対照であり、問い合わせ文だけの翻訳効果ではありません。モデル内部の共通の指示形式まですべて日本語に置き換えた試験でもありません。

問題と期待値は10月6日7時7分に固定し、期待値はモデルへ渡さない別ファイルに置きました。その後、各入力を1回ずつ実行しました。結果を見てから依頼文や判定の基準を調整していません。10場面を2言語にした20件なので、独立した20種類の仕事を試したわけではありません。

20件とも形式の正しい応答が返りました。ここでいう「一致」は、編集部が事前に決めた担当への一致です。明確な場面と、人の確認が必要な場面を分けると、次のようになりました。

日英で答えが違ったのは、業務用アカウントのパスワード再設定です。「パスワードを忘れ、ログインできません。本人確認をしたうえで再設定する方法を教えてください」という日本語には human_review、同内容の英語には it を返しました。教材の規則ではどちらも情シスなので、日本語側は不要な保留です。ただし、どの語が原因かまでは、この一試行から分かりません。

さらに大事なのが、日英とも間違えた例です。「出張の立替経費を精算したい。それとは別に会社のVPNへ接続できないので直してほしい」という入力には、両方とも accounting を返しました。経理の話は含まれていますが、情シスの用件もあるため、教材では人の確認に戻すべき案件です。

一方、「例の手続きが進まず困っています。どこに連絡すればよいですか」という情報不足の入力は、日英とも確認へ戻せました。つまり、確認用の選択肢を入れれば、どんな曖昧さでも検出できるわけではありません。

10組中9組で日英の選択は一致しましたが、その9組には複数部署の見逃しが含まれます。言語間で答えが揃うことと、業務の規則に合うことは別です。 日本語を英訳してから使えば解決する、と結論づける材料にもなりません。

複数部署の英語入力に対する confidence は約0.8036でした。比較的高い値でも、今回の期待分類には合っていません。

Jiwoの choice が返す confidence は、最大の選択確率を、候補数に応じて換算した値です。候補が2つ以上のときは次の式を使い、0〜1に収めます。score は別の計算なので、この式を流用しません。応答を作る公式コード

この数値は、その案件が正しい確率を実証したものではありません。「0.8以上なら自動処理」という境界を、今回の少数例だけから決めることもできません。別に用意した業務例で、誤分類をどれだけ減らせるか、人に戻す件数が増えすぎないかを確認する必要があります。

また、同じフィールド名でも他製品と定義が一致するとは限りません。最大確率を使うベンチマーク集計と、APIの confidence を混ぜない点は、DoubtBenchの再採点で分かった注意点でも扱っています。

編集部はApple M2 Ultra・メモリ192GiB・macOS 27.0で、CPU（Central Processing Unit）のみを使いました。Python 3.12.10、CPU側の計算形式はfloat32、並列処理は8スレッドです。コードを 8ed87c2…、0.8Bモデルを a3a37e4… に固定し、公式の既定の確率調整値をそのまま使っています。

モデルの初期読み込みは約1.195秒、最初の判定は約485.236ミリ秒、残り19件の判定時間の中央値は約373.643ミリ秒でした。初期読み込みはPython起動・ライブラリ読込を含む全所要時間ではなく、判定時間はローカルの DecisionModel.decide を呼んだ前後です。予熱はしていません。HTTPサーバー経由の時間や、Jevの速度は測っていません。

Pythonは現コードで3.12系に限定されています。小さなモデルでも、重みの保存容量と実行時メモリは同じではありません。今回の大容量Macで動いたことから、最低メモリ量やすべてのPCでの動作を保証することはできません。依存条件、コードのライセンス、モデルのライセンス

教材ZIPをダウンロードすると、モデルを取得せずに、入力検査と編集部結果の再集計から始められます。展開したフォルダで次を実行してください。通信もモデルの推論も行いません。

自分の端末で推論する場合は、同梱の RUNNING.md に従い、新しい仮想環境と固定版モデルを用意します。この準備段階はネットに接続します。取得後、次のように明示的に実行したときだけモデルを読み込みます。保存先は新しい名前にし、既存の結果を上書きしない仕様です。

教材は推論時のオフライン設定を有効にし、指定したローカル重みを照合します。編集部ではさらにOS側で通信を拒否した状態で20件の成功を確認しました。上記の一般向けコマンド自体には、そのOS側の拒否設定は含まれません。教材には架空入力、期待値、生応答、環境、ハッシュ値を入れ、モデル本体は同梱していません。

今回の結果から始めるなら、Jiwoが選んだ担当へ即座に案件を送るのではなく、受付担当者に候補として見せる使い方が適しています。担当候補、各選択肢の確率、人が直した担当、修正理由を残せば、使える場面と追加確認が必要な場面を分けられます。

特に、複数の用件が書かれた入力は独立した検収項目にします。単純な部署名の選択だけでなく、二つの用件を扱うときの業務規則が守られるかを見ます。翻訳後の一致だけで合格にせず、元の用件を理解できる人が、期待分類と照合することが必要です。

用途別に正解例から分類器を作る方法を選ぶなら、Jeffyで自作の問い合わせ分類器を検収した記事も参考になります。今回の教材をそのまま性能ランキングへ使うのではなく、自社の担当分担に合わせた別の検収データを用意してください。