問い合わせメールを部署に振り分けたい。緊急度を 3 段階で付けたい。解約をほのめかしているかを知りたい。

こういう「決まった選択肢から選ぶ」仕事のために、LLM に JSON を書かせ、パースし、崩れたら再試行する。この手間を消す 判断モデル が、2026 年 9 月に相次いで登場しました。9 月 15 日に TypeSafe AI が Jev を、9 月 29 日に Liquid AI が d1 を発表しています。ただ、どちらも API での提供で重みは非公開、日本語の業務文での精度も公表されていません。

この記事では、拙作の日本語専用の判断モデル sokudan（即断）を、インストールから業務への組み込みまで順に使っていきます。

動機 Jev の発表の数日後、重みが公開されている多言語の判断モデル laya-multilingual を、日本語の業務文 300 件で測りました。部署の振り分けは当たる一方、解約の示唆を問うはい / いいえは AUROC 0.523 で、偶然とほぼ区別がつきませんでした。ないなら作るしかない、と 2 日間のスプリントで作ったのが sokudan の最初の版です。

問題意識 手元の LLM 呼び出しのうち、実は「選択肢から選ぶだけ」のものがどれだけあるか。それを考えるきっかけにしてほしいと思っています。

実地の文脈 開発と計測は、コンシューマ向けハイエンド構成の一例である RTX 5090 1 枚と Core Ultra 9 285K で行いました。外部では、会計アプリの勘定科目の候補提示に PoC として組み込まれています。

記事を通して、判断モデルを ハンコしか持っていない受付係 にたとえます。

この記事を読むと、明日こう決められます。手元の日本語の判定処理のうち、どれを LLM から sokudan に移すか。そして、閾値と人の確認をどこに置くか。

この記事について

対象読者: Python から LLM の API を呼んで、分類やラベル付けをさせたことがある人

得られること

手元の判定処理を LLM と sokudan のどちらに任せるか、判断フローで決められる
pip 1 行で入れて、3 種類の質問を投げられる
公開ベンチの精度を自分の手で計算し直せる
受け皿の選択肢の閾値、人に見せる候補の数、確率の見せ方を設計できる

扱わないこと: 学習手順と内部構造の詳細、Jev・d1 との精度比較（理由は 3 章）、英語の文章での利用

1. 判断モデルとは何か — ハンコしか持っていない受付係

冒頭で、LLM に JSON を書かせる手間を消すモデルが出てきたと書きました。自分の仕事に入れてよいかを判断するには、まず LLM と何が違うのかを押さえる必要があります。

このセクションで分かること: 判断モデルと LLM の違い、質問の 3 つの型、主なモデル

TypeSafe AI は Jev を最初の System One モデル と呼んでいます。呼び名の由来は、カーネマンが『ファスト&スロー』で描いた速く直感的な「システム 1」の思考です。一方、モデル名の Jev は経済学者ジェヴォンズから取ったと、発表記事にあります。

We named Jev after William Stanley Jevons.
（和訳: Jev という名前は、ウィリアム・スタンレー・ジェヴォンズにちなんで付けました）

たとえで言えば、LLM はメモを自由に書く受付係で、頼んでいない答えや崩れた書式が返ることがあります。判断モデルは選択肢のハンコしか持たない受付係で、選択肢にない答えは原理的に返りません。そのうえ、どのハンコにどれくらい手が伸びたかを確率で返します。

	LLM に分類させる	判断モデル
答え	テキストを 1 トークンずつ生成	選択肢ごとの確率を 1 回で返す
出力トークン	答えの長さ分	0
選択肢にない答え	返ることがある（パースと再試行が要る）	原理的に返らない
確率	モデルに言わせた自己申告	出力層から読んだ値

質問の型は 3 つです。

noul: はい / いいえ。P(はい) を返します
choice: 選択肢から 1 つ。全選択肢の確率を返します
score: 順序のある段階。段階の期待値と、段階ごとの確率を返します

モデル	提供	重み	日本語
Jev	TypeSafe AI	非公開（API）	—
d1	Liquid AI	非公開（API）	—
Laya	Convai Innovations	公開	多言語版あり
AnyJev	Nokia Applied Research	既存の LLM に被せる層	土台の LLM 次第
sokudan	GeneLab	公開	日本語専用

重みを公開した実装はほかにも多く、それらを同じ 13 万件超の問題で採点する Hugging Face の Jev Decision Index に、sokudan も載っています。

データを社外に出せない業務なら、重み公開のモデルが候補です。表の中で日本語に絞ったのが sokudan です。

2. sokudan を入れて、最初のハンコを押してもらう

前節で、判断モデルは選択肢ごとの確率を 1 回で返し、表の中で重み公開かつ日本語専用なのは sokudan だけだと見ました。重みが手元にあれば、データを外に出さずに試せます。

このセクションで分かること: インストール方法、3 種類の質問の書き方、返ってくる値の読み方

sokudan は 314.6M パラメータで、日本語の ModernBERT（sbintuitions/modernbert-ja-310m、MIT）に判定用のヘッドを足して学習しました。ModernBERT は、読むことに特化した Transformer です。文章と質問を 1 本の入力で読み（joint encoding）、1 質問につき 1 回モデルを通します。公開中の重み v0.2 は、同じ設定で学習した 8 本の重みを平均した model soup で、ライセンスは Apache-2.0 です。

インストール

pip install sokudan

Python 3.11〜3.13 に対応しています。macOS 14 以降のApple SiliconではMLXが入り、torch は入りません。Windows、Linux、Intel Mac では PyTorch が入り、CUDA、MPS、CPU の順に自動で選ばれます。GPU を使うときは、先に CUDA 版の torch を入れてください。

pip install torch --index-url https://download.pytorch.org/whl/cu128
pip install sokudan

3 種類の質問を投げる

import sokudan

agent = sokudan.load("GeneLab/sokudan-ja-310m")

state = "先月の請求で同じ金額が二回引き落とされています。至急ご確認ください。"
questions = {
    "department": {
        "type": "choice",
        "instructions": "この問い合わせはどの部署が担当すべきか",
        "criteria": {
            "請求": "支払い・返金",
            "技術": "不具合・障害",
            "営業": "料金・新規契約",
            "その他": "上記以外",
        },
    },
    "urgency": {
        "type": "score",
        "instructions": "この依頼の緊急度は",
        "criteria": ["急がない", "早めに", "業務が止まっている"],
    },
    "churn": {
        "type": "noul",
        "instructions": "解約を示唆しているか",
    },
}

result = agent.predict(state, questions)
print(result["answers"]["department"]["choice"])

請求

result["answers"] の中身です（抜粋）。

{
  "department": {
    "type": "choice",
    "choice": "請求",
    "probabilities": {"請求": 0.9984, "技術": 0.0004, "営業": 0.0007, "その他": 0.0005},
    "confidence": 0.9984
  },
  "urgency": {
    "type": "score",
    "score": 1.09,
    "probabilities": {"0": 0.2075, "1": 0.4951, "2": 0.2974}
  },
  "churn": {"type": "bool", "noul": 0.0903}
}

choice: 選んだ選択肢と全選択肢の確率です。confidence は一番高い確率です
score: 段階ごとの確率と、その期待値です
noul: P(はい) です。既定で較正がかかっています（5 章）

score の値は期待値です。記号を使う順に導入します。

$K$（段階の数、整数）: 用意したハンコの数。この例では 3 です
$k$（段階の番号、整数、0 始まり）: 左から何番目のハンコかを表します
$p_k$（段階 $k$ の確率、スカラー）: $k$ 番目のハンコに手が伸びた割合です

\mathrm{score} = \sum_{k=0}^{K-1} k \, p_k

この式が言っているのは、手の伸び具合をハンコの番号で重み付けして平均する、ということです。例の値では $0 \times 0.2075 + 1 \times 0.4951 + 2 \times 0.2974 \approx 1.09$ で、真ん中の「早めに」寄りと読めます。

本番では動かす場所を固定すると安心です。明示すると、失敗しても別の候補へ切り替えずにエラーになります。

agent = sokudan.load("GeneLab/sokudan-ja-310m", backend="torch", device="cuda")

3. どれくらい当たるか — 300 件で腕前を確かめる

前節で、1 件の問い合わせに 3 つの判断が返ることを確かめました。ただ、1 件当たっただけでは業務に入れられません。受付係を窓口に座らせる前に、300 件の書類で腕前を確かめます。

このセクションで分かること: 公開ベンチ bench_ja での精度と、それを手元で計算し直すコード

bench_ja は、日本語の業務文 300 件に、部署（4 択）、緊急度（3 段階）、解約の示唆（はい / いいえ）の 3 問を付けた評価セットです（CC BY 4.0）。質問は学習で一度も使っていない書き方です。

	choice 正解率	score RPS（低いほど良い）	bool 正解率	bool AUROC
sokudan v0.2	0.880	0.075	0.780	0.844
laya-multilingual	0.747	0.232	0.543	0.523
多数決	0.380	0.197	0.703	—
ランダム	0.253	0.201	0.513	—

AUROC は「はい」と「いいえ」の文を 1 つずつ取ったとき「はい」側に高い確率を付ける割合で、0.5 が当てずっぽうです。RPS は段階のずれを罰する指標で、遠い段階に外すほど重く数え、0 が完璧です。

表に Jev と d1 がないのは、測っていないからです。TypeSafe AI の利用規約が、同社のサービスや出力を類似製品の開発に使うことを禁じているため、開発中に Jev は一度も呼んでいません。

手元で計算し直す

表はリポジトリの評価スクリプトの値です。同じ定義で手元計算する最小コードを載せます。

curl -LO https://raw.githubusercontent.com/hiroki-abe-58/sokudan/main/data/bench_ja.jsonl

指標を計算する関数です。

import numpy as np

def rps(probs, gold):
    """段階の確率 probs と正解の段階 gold から RPS を出す（低いほど良い）"""
    k = len(probs)
    pred_cdf = np.cumsum(probs)
    gold_cdf = (np.arange(k) >= gold).astype(float)
    return float(((pred_cdf - gold_cdf) ** 2).sum() / (k - 1))

def auroc(scores, labels):
    """正例に負例より高い確率を付けている割合（同点は平均順位で扱う）"""
    s = np.asarray(scores, dtype=float)
    y = np.asarray(labels, dtype=bool)
    ranks = np.empty(len(s))
    ranks[s.argsort()] = np.arange(1, len(s) + 1)
    for v in np.unique(s):
        ranks[s == v] = ranks[s == v].mean()
    n_pos, n_neg = y.sum(), (~y).sum()
    return float((ranks[y].sum() - n_pos * (n_pos + 1) / 2) / (n_pos * n_neg))

300 件を判定して集計します。質問は bench_ja と同じものを、パッケージから読み込みます。

import json
import sokudan
from sokudan.eval.bench_ja import bench_questions

agent = sokudan.load("GeneLab/sokudan-ja-310m", temperatures=None)
questions = bench_questions()
with open("bench_ja.jsonl", encoding="utf-8") as f:
    items = [json.loads(line) for line in f]

hit, top2, p_top1, rps_list, p_true = [], [], [], [], []
for item in items:
    a = agent.predict(item["state"], questions)["answers"]
    probs = a["department"]["probabilities"]
    ranked = sorted(probs, key=probs.get, reverse=True)
    hit.append(ranked[0] == item["department"])
    top2.append(item["department"] in ranked[:2])
    p_top1.append(probs[ranked[0]])
    urg = a["urgency"]["probabilities"]
    rps_list.append(rps([urg[str(k)] for k in range(len(urg))], item["urgency"]))
    p_true.append(a["churn"]["noul"])

gold = [item["churn"] for item in items]
print(f"choice acc  {np.mean(hit):.3f}   top-2 {np.mean(top2):.3f}")
print(f"P(top1) 中央値 {np.median(p_top1):.3f}")
print(f"score RPS   {np.mean(rps_list):.3f}")
print(f"bool acc    {np.mean((np.array(p_true) >= 0.5) == gold):.3f}")
print(f"bool AUROC  {auroc(p_true, gold):.3f}")

確率は小数第 4 位で丸めて返るので、最後の桁はずれることがあります。temperatures=None は較正を外す指定ですが、較正は 0.5 での判定も順位も変えないので 4 指標は同じです。bench_ja は評価用なので、学習には使わないでください（ライセンスではなくお願いです）。

4. 質問の書き方で正解率が 34 ポイント動く — ハンコに注意書きを付ける

前節の 0.880 は、各選択肢に 1 行の説明を付けた質問での値です。書き方で数字が動くなら、モデルより先に質問を直すべきです。そこで説明を外して測り直しました。

このセクションで分かること: 説明の有無で精度がどれだけ変わるかと、精度を落とさない質問の書き方

bench_ja の部署の質問が持つ説明を、空にしただけです。

 "criteria": {
-    "請求": "支払い・返金・請求書・料金の二重引き落としなど金銭処理に関するもの",
+    "請求": "",
     # 技術・営業・その他も同じように空にする
 }

3 章のコードで questions["department"]["criteria"] を上のとおり書き換えると、次の値を測り直せます。

	正解率	上位 2 件に正解が入る率	1 位の確率の中央値
説明つき	0.880	0.963	0.997
ラベルだけ	0.537	0.747	0.546

正直に書くと、筆者が測った中でいちばん大きく効いたのは、モデルの構造でも学習データでもなく、この 1 行の説明でした。少し悔しい結果です。

勘定科目 10 項目では、ラベルだけでも 0.852 から 0.843 とほぼ同じでした。「旅費交通費」は名前で中身が伝わりますが、「請求」のような短い部署名は説明で初めて範囲が決まります。何を請求とするか書いていないハンコでは、受付係は迷います。

精度を落とさない書き方は 3 つです。

state は文字列で渡す: dict を渡すと key: value の行に変換され、学習時の入力と違うので結果が変わります。手元の 1 事例では P(はい) が 0.318 から 0.145 まで動きました
choice の criteria は dict、score は list: choice は「選択肢: 説明」の dict、score は低い順に並べた段階の list です
選択肢には説明を書く: 受け皿の「その他」にも「上記以外」と書きます

5. 実務で踏む 3 つの罠 — 外れ方には癖がある

前節までで、質問を正しく書けば部署の振り分けは 9 割近く当たると分かりました。残る 1 割強の外れ方に癖があれば、運用側で受け止められます。

このセクションで分かること: 受け皿の選択肢の閾値、人に見せる候補の数、確率を画面に出す前に確かめること

5-1. 「その他」は 1 位になりにくい

bench_ja で「その他」が正解の 38 件のうち、1 位になったのは 11 件（再現率 0.289）で、取りこぼしの多くは「技術」に入りました。選んだときの的中率は 0.846 です。押せば正しいのに、手が伸びないハンコです。

それでも P(その他) の順位は取れています。筆者が勘定科目 10 項目と「その他」で作った 90 件の検査では、どの科目にも当たらない書類を P(その他) で見分ける AUROC が 0.94 でした。なので 1 位を採るのではなく、P(その他) に閾値をかけます。

THRESHOLD = 0.1  # 手元のラベル付きデータで決める

def route(answer, catch_all="その他", threshold=THRESHOLD):
    probs = answer["probabilities"]
    if probs[catch_all] >= threshold:
        return catch_all
    rest = {k: v for k, v in probs.items() if k != catch_all}
    return max(rest, key=rest.get)

label = route(result["answers"]["department"])

閾値はデータで大きく変わります。事後に同じデータで調べた参考値ですが、bench_ja では P(その他) が 0.05 以上を「その他」にすると再現率が 0.500 に上がり、ほかの書類を巻き込む率は 0.8% でした。同じ閾値でも、英語の bench_en では巻き込む率が 29% に達しています。

受け皿は、並びの先頭や最後に置かないほうが選ばれやすくなります。勘定科目の検査で、正解が「その他」の書類に付いた P(その他) は、先頭で 0.218、最後で 0.213、中ほどで 0.37〜0.42 でした。端に置いたハンコほど手が伸びません。

5-2. 人が確認するなら、上位 2 件を見せる

上位 2 件まで見れば、正解が入る率は 0.880 から 0.963 に、正解が「その他」の書類でも 0.289 から 0.763 に上がります。

def top_k(answer, k=2):
    probs = answer["probabilities"]
    return sorted(probs, key=probs.get, reverse=True)[:k]

print(top_k(result["answers"]["department"]))  # ['請求', '営業']

会計アプリの PoC も、この形です。仕訳の摘要から勘定科目の候補を 1〜3 件に絞り、人が確認しています。受付係がハンコを数本差し出し、最後に押すのは人、という分担です。

5-3. 画面の「99%」は 99% ではない

bench_ja では 300 件中 224 件で 1 位の確率が 0.99 以上でしたが、うち 14 件（6.25%）は外れでした。「確信度 99%」と表示する前に、帯ごとの正解率を確かめてください。

def accuracy_by_band(top1_probs, correct, edges=(0.0, 0.9, 0.99, 1.01)):
    p = np.asarray(top1_probs)
    ok = np.asarray(correct, dtype=bool)
    for lo, hi in zip(edges[:-1], edges[1:]):
        m = (p >= lo) & (p < hi)
        if m.any():
            print(f"{lo:.2f}〜{min(hi, 1.0):.2f}: {m.sum():3d} 件, 正解率 {ok[m].mean():.3f}")

accuracy_by_band(p_top1, hit)  # 3 章のループで集めた値

はい / いいえには既定で較正をかけています。P(はい) が低く出る癖があり、bench_ja では「はい」の割合 0.297 に対し平均 0.133、較正後も 0.198 です。較正は手の伸びを補正する眼鏡ですが、0.5 での判定は変えません。閾値は自分のデータの割合から決めてください。

ここまでのまとめ

判断モデルは選択肢ごとの確率を返し、選択肢にない答えは返さない
sokudan は bench_ja で部署の振り分け 0.880、はい / いいえの AUROC 0.844
精度をいちばん動かすのは選択肢の説明で、消すと 0.537 まで落ちる
「その他」は閾値で拾い、人には上位 2 件を見せ、確率は帯ごとの正解率を見てから出す

6. 速さと置き場所 — 質問の数だけ書類を読み直す

前節で運用の形が決まりました。残る問いは、どのマシンで 1 件に何ミリ秒かかるかです。

このセクションで分かること: 環境ごとの待ち時間とメモリ、時間が増える条件、HTTP サーバーとしての置き方

まず、2 章の例の usage を見ます。

print(result["usage"]["backbone_passes"], result["usage"]["output_tokens"])  # 3 0

質問 3 つでモデルを 3 回通し、出力トークンは 0 です。受付係は、質問ごとに書類を頭から読み直しています。

環境	入力	1 件あたりの時間
GPU: RTX 5090（fp32）	bench_ja 300 件、3 問	中央値 22.8 ms（p95 27.5 ms）
CPU: Core Ultra 9 285K（24 スレッド）	同上	中央値 371 ms（p95 583 ms）
Apple M1 Max（MLX、float16）	2 章の例文、3 問	中央値 17.8 ms
Apple M1 Max（MLX、float16）	949 トークンの長文、3 問	中央値約 276 ms

GPU と CPU はウォームアップ 20 件のあと 300 件を 1 件ずつ測った値で、GPU のメモリは約 1.3 GiB でした。M1 Max は負荷の高い状態での計測です。手元で試すコードです（items は 3 章のもの）。

import statistics
import time

agent = sokudan.load("GeneLab/sokudan-ja-310m")  # device="cpu" などで比べる
questions = bench_questions()
states = [item["state"] for item in items]

for state in states[:20]:  # ウォームアップ（計測しない）
    agent.predict(state, questions)

times_ms = []
for state in states:
    start = time.perf_counter()
    agent.predict(state, questions)
    times_ms.append((time.perf_counter() - start) * 1000)

times_ms.sort()
print(f"中央値 {statistics.median(times_ms):.1f} ms")
print(f"p95   {times_ms[int(len(times_ms) * 0.95)]:.1f} ms")

時間が増える条件は 3 つです。

質問を増やすと、ほぼ比例して増えます。質問ごとに読み直すからです
選択肢を増やしても、読み直しの回数は増えません。選択肢は同じ 1 本の入力に並ぶだけです
文章が長いと増えます。1,024 トークンを超えた分は切り詰められ、usage の state_truncated が True になります

HTTP の窓口を開ける

GPU なら 1 件 20 ms 台、メモリ約 1.3 GiB と軽いので、1 台に置いて HTTP で呼べば足ります。

pip install "sokudan[serve]"
sokudan serve --port 8000

curl -s localhost:8000/v1/systemone -H 'content-type: application/json' -d '{
  "state": "先月の請求で同じ金額が二回引き落とされています。至急ご確認ください。",
  "questions": {"churn": {"type": "noul", "instructions": "解約を示唆しているか"}}
}'

POST /v1/systemone の形は TypeSafe AI の公開 API リファレンスと同じで、d1 も同じ形です。判断モデル向けのクライアントは、接続先を http://127.0.0.1:8000 に変えるだけで向けられます。サーバーは公開ドキュメントとオープンな実装の README から作り、TypeSafe AI の SDK もサービスも使っていません。

7. 苦手なことと、任せる判断 — 押させてはいけない書類

ここまでで、入れ方、当たり方、外れ方、速さ、置き方がそろいました。最後に、任せない仕事を決めます。

このセクションで分かること: sokudan に任せてはいけない入力と用途、そして判定処理ごとの任せ先の決め方

日本語専用です: 英語の bench_en では、はい / いいえの正解率が 0.690 で、多数決の 0.683 とほぼ同じでした
長い文章は精度が落ちます: 学習した文章は平均 134 トークンで、土台のモデルが一度に見渡す範囲（ローカルな Attention の窓）は 128 トークンです
4 段階以上の score では最初の段階が選ばれにくい: 4 段階の緊急度で、最初の段階が選ばれたのは 300 件中 5 件でした
学習データは合成データです: 1 つの LLM で作った 21 分野、4,833 文書です。bench_ja も合成データです

採用、与信、懲戒、医療、法律のように、人の判断を置き換える用途には使わないでください。

全部の一覧は README の Limits とモデルカードにあります。

これで、判定処理 1 つ 1 つをどちらの受付係に回すかを決められます。

最初の分岐は 1 章、中ほどはこの章、最後は 5 章の結論です。受け皿のある質問には 5-1 の閾値もかけます。

トラブルシューティング

症状	原因	対処
例と確率が大きく違う	state を dict で渡している	文字列で渡す
GPU があるのに遅い	CPU 版の torch が入っている	CUDA 版の torch を入れ直す
Mac で `backend="torch"` が ImportError	macOS 14 以降の Apple Silicon には torch が入らない	`pip install "sokudan[torch]"`
「その他」がほとんど選ばれない	受け皿は 1 位になりにくい	P(その他) に閾値をかけ、中ほどに置く
「はい」がほとんど出ない	P(はい) が低く出る癖	自分のデータの割合から閾値を決める
長い文章で外れが増える	学習した文章は平均 134 トークン	要点を切り出す、`state_truncated` を確かめる

用語集

用語	意味	受付係のたとえ
判断モデル	文章と型付きの質問から、選択肢ごとの確率を返すモデル	ハンコしか持っていない受付係
state	判定したい文章	窓口に出された書類
受け皿の選択肢	「その他」のように、どれにも当たらないときの選択肢	「該当なし」のハンコ
較正	確率の大きさを実際に当たる割合へ近づける補正。sokudan は温度スケーリング	手の伸び具合を補正する眼鏡
AUROC	正例と負例を 1 つずつ取ったとき、正例に高い確率を付けている割合	「はい」の書類へ手が伸びる割合
RPS	段階のずれ方を罰する指標。低いほど良い	遠いハンコに手が伸びるほど減点
joint encoding	文章と質問を 1 本の入力にまとめて読む方式	質問ごとに書類を読み直す
model soup	同じ設定で学習した複数の重みを平均したもの	何人かの受付係の癖をならした 1 人

学習ロードマップ

最初の一歩は、無料の CPU で動く Colab のノートブックです。

おわりに

sokudan は、TypeSafe AI とも Liquid AI とも関係のない、個人のオープンソースプロジェクトです。「System One」は TypeSafe AI による分類名で、この記事では判断モデルの種類を指す言葉として使いました。

ハンコしか持たない受付係は、何でも書ける受付係より不自由です。それでも仕分けの窓口なら、その不自由さがそのまま安心になる、と筆者は考えています。外れた例は GitHub の Issue で教えてください。

次の記事では、このモデルを作る過程で「3 シードの平均は嘘をつく」と知った話を書く予定です。

関連記事

文章を生成する側の仕組み: LLM
重みの配布先: Hugging Face
実務寄りの切り口で書いた Zenn 版
要点をまとめた: note版

参考文献

TypeSafe AI「Introducing System One Models & Jev」（邦訳: System One モデルと Jev の紹介、2026-09-15）。Jev の発表記事で、リンクは 1 章にあります。

GIGAZINE「ベンチマークでJev超えな意思決定モデル「d1」が登場」（2026-09-30）。Liquid AI の d1 発表の日本語解説です。

sokudan の docs/choice_guidance.md「Using choice questions well」（邦訳: choice の質問をうまく使う）。5 章の数字の出典です。

sokudan の docs/latency.md。6 章の GPU と CPU の計測条件です。Apple Silicon の値は同じフォルダの mlx.md にあります。