シナリオ一覧測り方カタログ

業務シナリオのカタログ

このリポジトリで測る業務シナリオの一覧です。50件を8つの族に分けて定義しています。

ここに載っているのは「測れる形にできる仕事」だけです。実装済みのものはtasks/*.yaml にあり、それ以外はまだ定義だけの候補です。

全件が満たす前提

1. 正解を先に作り、seed を固定して文面を合成できる。実データは使いません。金額や日付といった値を先に決め、それを人が読む文面に組み立てます。この順序なので、本文と正解が食い違うことがありません。seed が同じなら誰の手元でも同じ入力になります。

2. 採点が決定論で決まる。応答からJSONを取り出し、スキーマを満たすかを見て、値が正解と一致するかを比べます。ラベルを返させる仕事なら文字列の一致だけを見ます。LLMに採点させることも、部分点も、類似度も使いません。

3. 正解が一意である。要約・翻訳・敬語への言い換えのように、正しい答えが複数ありうる仕事は入れません。採点のしかたを1文で書けない仕事は、このカタログに入れません。

列の読み方

• 入力長: 短（〜千字）／中（〜5千字）／長（万字〜）
• 出力形: ラベル（1〜2語）／JSON小（5項目まで）／JSON中（配列を含む）／入力同長（本文を書き換えて返す）
• 難所: そのシナリオでしか測れないもの
• 使う部品: 合成に必要な共通部品。generators/_lib/ に置く想定
• 実務区分: 導入判断／参考。下の「実務区分」を参照
• 状態: candidate（定義のみ）／implemented（タスク定義と生成器がある）／piloted・adopted・rejected・floor-documented（パイロット後。下の「パイロットによる採否」を参照）

実務区分

このカタログは「採点が決定論で書ける仕事」を選んでいます。この選び方は、採点しやすい仕事、つまり計算や検算の側にカタログを引っ張ります。計算・日付演算・構造化済みのデータどうしの突合は、実務ではExcelやコードでやる仕事です。その形でLLMを入れる会社はありません。「LLMは計算が苦手」は測れば出ますが、入れるかどうかの判断材料にはなりません。

同時に何本さばけるかを測る意味があるのは、実際にその形で使われる仕事だけです。そこで全件を2つに分けています。

• 導入判断: 実務でこの形のままLLMに渡す仕事。ポータルの逆引きに載せる
• 参考: LLMの限界を記録する値打ちはあるが、実務ではコードでやる仕事。 逆引きには載せず、測定にも進めない

分け方は次の3つで決めています。

1. 分担: LLMが担うのは読む・見つける・書き換えるまで。計算・日付演算・ 構造化済みのデータどうしの突合をLLMにさせていないか
2. 量: 束で届く仕事か。月に1度の点検作業に、同時32本の測定は要りません
3. 社外に出せないデータか: 給与・診療・個人情報を扱う仕事は、 ローカルで動かす動機がそのまま導入の動機になります

A. 構造化抽出（12件）

medical-receipt-json-ja と resume-summary-json-ja は、難所に計算（点数×10円、在籍期間の合算）を含みますが、仕事の中心は明細や職歴を読み取るところなので導入判断にしています。計算にあたる部分は、実務ではコードでやります。

B. 分類・ルーティング（7件）

C. 書き換え（6件）

出力が入力とほぼ同じ長さになる族です。指示された箇所だけを直し、それ以外を1字も変えないことを求めます。

この族で導入判断に残るのは pii-masking-ja だけです。伏せる対象が文中のどれかを決めるのに文の意味が要るためです。残りは置き換えの規則が決まっていて、company-name-normalize-ja・date-number-normalize-ja・address-normalize-ja は辞書と正規表現、contract-fill-in-ja はテンプレートの差し込み、transcription-fix-ja は正データ表との突合で書けます。

D. 照合・検算（6件）

invoice-po-match-ja は、並び順の違う明細を対応づけるのに表記ゆれ越しの同定が要るので導入判断です。残りは検算・時間の重なり・打刻との突合で、いずれもスクリプトの仕事です。

E. 変換（5件）

broken-csv-json-ja は、引用符の中のカンマも欠損もパーサの守備範囲なので参考です。

F. 長文・万字級（6件）

audit-log-filter-ja は、条件に合う行を選ぶのが grep と SQL の仕事なので参考です。

G. 集計・計算（4件）

集計・計算族は全件が参考です。expense-category-total-ja の定義に書いてあるとおり、測っているのは加算そのもので、実務ではSUMIFの仕事です。この業務でLLMが担うのは摘要から科目を決めるところで、それは expense-account-code-ja が測っています。

H. 判断系（4件）

contract-renewal-due-ja は、構造化済みの一覧に対する日付演算なので参考です。実務でLLMが担うのは契約書の本文から満了日・自動更新の有無・通知日数を抜くところで、contract-terms-json-ja がおおむね担っています（自動更新の有無と通知日数は、contract-terms の抽出項目に足す候補）。counterparty-watchlist-ja は表記ゆれ越しの同定なので導入判断に残しています。

変調軸（入力の荒れ）

入力の荒れはシナリオではなく、全シナリオに共通してかける変調です。同じシナリオを荒れレベル0〜3で測れば、「きれいな入力なら載るが、現場の書類では落ちる」という差が読めます。

変調は文面だけにかけ、正解は変えません。 値そのものを壊す変調（金額の桁を落とす、日付を消す等）は入れません。壊すと正解が一意でなくなり、前提3を満たさなくなるためです。荒れレベルはタスク定義の側で指定し、結果のJSONに記録します。

共通部品の集計

「使う部品」列を数えたものです。generators/_lib/ に置く順番の根拠になります。上位7つで、50件のうち大半のシナリオがまかなえます。

パイロットによる採否

候補をいきなり並列掃引にかけると、測る価値のないシナリオに時間を使います。先に小さく回して、モデルによって結果が変わるものだけを残します。

手順。 各候補を 同時1本・12件 で、手元にあるモデルすべてで測ります。モデルは2つあれば足りますが、多いほど判定が確かになります。seed はシナリオごとに1つ決め、全モデルで同じものを使います。

判定は正答率の95%区間（Wilson）で行います。 12件では正答率が1件あたり8ポイント刻みにしかならないので、点の値だけでは差も天井も読めません。

天井は12件では判定できません。 12件で全問正解でも区間の下端は76%までしか上がらず、基準の95%を満たしているとは言えないためです。下端を95%より上に持ち上げるには、全問正解でも70件ほど要ります。全モデル満点のシナリオは48件・同時1本の追試に回し、そこで下端が基準を超えたら天井として不採用にします。

空応答は誤答として数えません。 思考を先に吐くモデルは、出力の上限に達するまで思考が終わらず、本文を1文字も出さないことがあります。これはそのモデルの答えの質を測れていない状態なので、床の根拠には使いません。件数は正答率とは別に記録します。あるシナリオで、あるモデルの不正解がすべて空応答だった場合、そのモデルの結果はそのシナリオの判定から外します。使えるモデルが2つ未満になったら piloted に留めます。

例外。 集計・計算族（expense-category-total-ja / overtime-calc-ja /sales-ratio-ja / timesheet-billing-ja）は、床であっても「この種の業務はLLMに載らない」という事実として掲載を残します。ただし並列掃引には進めません。

状態の遷移。

candidate → piloted → adopted           （区間の重ならない差が出た。並列掃引へ）
                    → rejected          （床、または追試で天井と確認）
                    → floor-documented  （床だが事実として残す。集計・計算族のみ）

最初に実装する10件

選定の基準は次の3つです。

• (a) 8つの族すべてを最低1件含む
• (b) 使用頻度の高い共通部品でまかなえる
• (c) 実装済みの2件と、入力長×出力形の組み合わせが重ならない

この10件が必要とする部品は 日付・人名・社名・金額・品目・部署・数量の7つだけで、住所・メールアドレス・電話番号・役職・URLは要りません。実装済み2件は 短×JSON中 と 長×JSON中 なので、この10件はどちらの組み合わせも使いません。