日本語の業務判断に特化させた選択モデルを作った【Erabo-2B】

はじめに

Erabo-2B という、2Bの日本語判断モデルを公開しました。多言語の判断モデル Mapika/decider-2b を、日本語のビジネス用途に寄せてファインチューニングしたものです。

判断モデルなので、文章は書きません。

本文と判断基準を読んで、用意した選択肢から1つを選ぶことだけをするJev的なモデルです。

Eraboの考え方

Erabo-2Bは、単体で何でも決める万能モデルとしては作っていません。業務の流れの手前に置いて、「この判断はここで決めてよいか、人や上位のLLMに委ねるべきか」を振り分ける前処理の担当です。

工夫したのは、何を学ばせ、どの重みを選ぶかの基準です。ベンチマークの正解率だけを追うことはせず、わからないものを「わからない（要確認）」と返せることを最も重視しました。

振り分け役の失敗には2つの方向があります。何でも「要確認」にするモデルは安全ですが、仕分けの役に立ちません。何でも決めてしまうモデルは便利ですが、決めてはいけない案件まで通してしまいます。元のモデルは前者寄りで、確認の要らない規則判断160問のうち101問を「要確認」にしていました。Erabo-2Bはこれを29問まで減らしつつ、「要確認」が正解の80問のうち70問では保留を残しています。

重みの選び方も、この考え方に合わせました。42回の実験サイクルで候補を作り、「保留すべき問題で『要確認』を選べる数が減らないこと」を学習前に条件として決めて比べています。正解率が上がっても、この条件を満たさなかった候補は不採用としました。

Erabo-2Bモデルの強み

• 対応言語は日本語と英語に絞り、日本語のビジネス用途に寄せて追加学習済み
• 確認しすぎず、決められないときだけ「要確認」を選ぶ
• 2Bと小さく、メモリ8GBのMacで1件1〜2秒で動かせる

ライセンスは Apache-2.0 です。

Erabo-2Bでできること

渡すのは次の4つです。

• context：判断する本文
• question：何を判断するか
• rubric：判断の基準
• options：2〜10個の選択肢

返ってくるのは、選んだ選択肢のIDと、各選択肢の確率です。

仕組みは、答えを書く位置で、各選択肢に割り当てた記号のlogitsを読んで確率にしています。文章を生成してパースするわけではないので、LLMのように余計な前置きが付いたり、形式が崩れたりすることがありません。

動かしてみる

ダウンロードは1つで、NVIDIA GPU・Apple SiliconのMac・CPUのどれでも動きます。

pip install torch transformers==5.17.0 accelerate==1.15.0 huggingface_hub==1.31.0
hf download tanakaisworking/Erabo-2B --local-dir Erabo-2B
cd Erabo-2B
python erabo_predict.py --input requests.jsonl --output predictions.json

入力は1行1問のJSONLです。丁寧に書かれた断りのメールを8択で判定させてみます。

{
 "context": "件名：打ち合わせ日程の件\n\n先日ご提案いただいた打ち合わせですが、社内の調整がつかず、今回は見送らせていただきたく存じます。またの機会にぜひよろしくお願いいたします。",
 "question": "このメールの主な目的はどれですか。", 
 "rubric": "本文全体から送り手が最も求めていることを選びます。", 
 "options": [
    {"id": "request", "text": "依頼"}, 
    {"id": "refusal", "text": "断り"}, 
    {"id": "thanks", "text": "感謝"}, 
    {"id": "apology", "text": "謝罪"}, 
    {"id": "invite", "text": "勧誘"}, 
    {"id": "cheer", "text": "激励"}, 
    {"id": "notice", "text": "通知"}, 
    {"id": "inquiry", "text": "問い合わせ"}
  ]
}

結果はこうなりました。

選択肢	確率
断り（refusal）	0.956
依頼（request）	0.011
感謝（thanks）	0.011
謝罪（apology）	0.010
勧誘（invite）	0.004
通知（notice）	0.004
激励（cheer）	0.002
問い合わせ（inquiry）	0.002

「断り」が0.956です。丁寧な言い回しに引っ張られず、ちゃんと断りだと判定できています。

手元のメモリ8GBのM1 Macで、1件1〜2秒でした。

答えの位置のlogitsを読む作りなので、LM StudioやOllamaのチャット画面では使えません。代わりに、同梱の erabo_predict.py などで簡単に試せるようにしています。

モデルの学習にあたって気をつけたこと

選択肢の並び順で答えが変わらないようにした

LLMに選択肢を渡すと、中身は同じでも並び順を変えただけで答えが変わることがあります。マークシート形式の試験でわからなかったら3番を塗り潰す僕と同じです。

業務で判断を任せるには、これがかなり困ります。

そこで、学習中は問題ごとに選択肢の並び順を入れ替えました。

効果は、日本語の含意判定ベンチマーク JNLI（dev、1,199問）で確かめました。通常の順と逆順の2通りで解かせています。

	通常順	逆順	2順平均	並び順を変えても同じ答え
公開ベース（Mapika/decider-2b）	76.9%	52.5%	64.7%	67.1%
Erabo-2B	67.2%	63.3%	65.3%	95.3%

2順平均はほぼ同じです。違いは中身にあります。

公開ベースは、逆順にすると76.9%から52.5%まで落ちます。並び順を変えて同じ答えを返したのは、3問に2問ほどでした。

Erabo-2Bは、通常順と逆順の差が小さく、95.3%の問題で同じ答えを返しました。

通常順だけ見るとErabo-2Bのほうが低いのですが、これは並び順の偏りで稼いでいた分がなくなったためだと考えています。

日本語の常識5択 JCommonsenseQA（valid、1,090問）でも、2順平均が82.5%から84.0%に、並び順を変えても同じ答えの割合が90.1%から91.6%に上がりました。

保留すべきときは保留する

公開する重みを選ぶとき、いちばん重視したのはここでした。

実は、正解率だけならもっと高い候補がありました。でも、そちらは公開を見送っています。

比べた2つの重み

学習の途中で、いくつかの構成を同じ条件で比べました。条件は学習の前に決めておき、その中に「保留すべき問題で『要確認』を選べる数が減らないこと」を入れていました。

比べた候補の1つは、GLM-5.3-Flashで規則判断の文面を作ったデータ（1,230問、正解はプログラムで計算）を加えた重みです。

評価データ	公開した重み	GLMのデータを加えた候補
規則判断（別形式、81問）	65.8%	77.8%
規則判断 3択（240問）	75.3%	75.8%
英語 MultiNLI（503問）	86.5%	86.8%
メールの目的 8択（200通）	72.5%	71.8%

※ 並び順3通りの平均

正解率だけ見ると、候補のほうが良さそうです。
別形式の規則判断では12ポイントも上でした。

ところが、「情報が足りないので『要確認』が正解」の80問を見ると、結果が変わりました。

並び順	公開した重み	GLMのデータを加えた候補
通常順	70問	51問
逆順	67問	46問
ランダム順	69問	49問

※ 80問中、正しく「要確認」を選べた数

候補は、保留すべき問題の3分の1以上で、無理に結論を出していました。

調べると、候補は「未確認の項目があっても結論が出せる問題」には強くなっていました。その代わり、本当に決めてはいけない問題でも決めてしまうようになっていました。正解率が上がった分には、この変化も含まれていたわけです。うーん、難しいね。

業務で、保留すべき案件を「実行」と決めてしまうと、あとから戻すのが大変です。

特に、今回はローカルでの実行を主目的とする2Bの小型モデル。分からなければAPI経由で大型のLLMに依頼する方がいいでしょう。正解率が少し下がっても、保留できるほうを選びました。

そういった経緯で、公開したErabo-2BはGLM-5.3-Flashのデータでは学習していません。正確に言えば、学習しない方が小型モデルとして目的に合った挙動をしたので採用したというところになります。

実験は42サイクル回し、条件を満たさなかった候補は8つ見送りました。それでもこの方向では保留率が改善しなかったため、わからないことをわからないと言える素直な挙動を優先しています。

公開ベースと比べると

保留については、元の公開ベースとも比べました。規則判断240問（通常順）の結果です。

	公開ベース	Erabo-2B
「要確認」が正解の80問で、要確認を選べた数	80問	70問
確認が要らない160問で、要確認と答えた数	101問	29問

公開ベースは、迷うとほとんど「要確認」に倒していました。保留できているというより、確認しすぎです。

Erabo-2Bは、確認しすぎを3分の1以下に減らしつつ、保留すべき問題もおおむね保留できています。決めるべきものは決めて、決められないものだけ人に回す。このバランスが、今回いちばん狙ったところです。

なぜ2Bなのか

文章を書く汎用のLLMとして見ると、2Bは賢くありません。

ただ、選択肢から選ぶ判断に絞れば、一次仕分けを任せられるくらいにはなります。そのうえで、手元のPCで軽く動かせるのが2Bの良いところです。

実際、ベースのDeciderシリーズ（0.8B〜35B）では2B版がいちばん使われていて、直近1か月で約33万ダウンロード、2番目に使われている4B版の約11倍でした（2026年10月19日時点、Hugging Face）。

性能ベンチマークの測り方について

選択肢を3通りの並び順で解かせ、その平均を取っています。

評価データ	公開ベース	Erabo-2B
メールの目的 8択（学習していない新規200通）	52.0%	72.5%
規則判断 3択（学習とは別の場面と書き方、240問）	55.6%	75.3%
英語 MultiNLI（503問）	83.4%	86.5%
MASSIVE 意図分類（8種、293問）	87.5%	95.1%

メールの目的は、人が読んでも1つに決めにくいメールを含む8択です。そこで7割を超えたのは良い結果でした。規則判断も、確認しすぎが減ったぶん20ポイント近く伸びています。

英語も下がっていません。日本語に寄せても、英語の力は落ちていませんでした。

JGLUE（JNLI・JCommonsenseQA）は、学習や調整には使わず、モデルを固めたあとに計測しました。

配布モデルとの違い

上の数字は、T4上でベースを4bit NF4で読み込み、LoRA adapterを重ねた構成で測りました。配布しているのは、adapterをベースに統合したbf16のモデル（約3.8GB）です。

量子化しないぶん答えが少しは変わるので、念の為同じ問題で正解数を比べました。

評価データ	測定した構成	配布モデル（M1 Mac）
メール（400問）	221問	210問
規則判断（240問）	179問	183問
英語（503問）	436問	432問

増えるものも減るものもあり、大きくは変わりませんでした。

学習データ

配布モデルの学習に使ったのは1,397問です。

データ	問数	内容
Japanese-Mail-Bench（PFN）	500	メール250通の「目的」と「発話行為」
Japanese-Mail-Bench（PFN）	173	作業・返信・応諾・期限の判断を付け直したもの
MultiNLI 1.0	204	英語の含意判定（英語力の維持用）
MASSIVE 1.1 ja-JP	160	日本語の意図分類8択
規則判断データ（自作）	360	社内ルールで「実行・見送り・要確認」を選ぶ3択

規則判断データは、自分で設計してスクリプトで組み合わせて作りました。

• AND・OR・例外・停止指定・訂正・数値の範囲など10種類の論理
• 6つの場面 × 3つの書き方（説明文・受付記録・対話）
• 正解はプログラムが計算
• 「未確認があっても結論が出る問題」と「確認しないと決められない問題」の両方を入れた

正解ラベルを、別のモデルに書かせた箇所はありません。

Japanese-Mail-Benchの一部を学習に使っているので、このベンチマークではErabo-2Bを公平に評価できません。

おわりに

日本語のビジネス環境で現実的に使いやすいモデルになったと思います。

特に、確認しすぎずに必要なときだけ保留できるようになったのは良かったです。

手元で軽く動くので、メールの仕分けなどで試してもらえたらうれしいです。感想やフィードバックもお待ちしています。

ビジネス目線でもnoteにしました、こちらもよろしくお願いします。