Jevで「大丈夫です」を分類する。会話の有無と二択・三択を48評価で比較した

みなさんこんにちは！かぎパケです！

「袋をお付けしますか？」への「大丈夫です」は、受け入れたのか、断ったのか。
Jev に「受諾」「辞退」「判断できない」の三択で聞くと、今回の会話全体では「辞退」、返事だけでは「受諾」が返りました。

この違いを入口に、架空会話12例を4条件で比較しました。
この記事では、入力と選択肢をどう分けて変えたか、実際の質問、全例の結果を示します。
日本語能力の順位付けではなく、小さな条件比較です。

Jevに選んでもらう三つの答え

Jev は、TypeSafe の型付き判断を返すモデルです。
今回は Choice（用意した選択肢から一つを選ぶ質問）を使いました。
返却値には選択結果、選択肢別の確率、確率分布の形から得る confidence があります。
出典：Choice。

分類対象は、最後の返事が「相手から提案された行為や条件」を受け入れているかどうかです。
選択肢は次のように定めました。

キー	意味
accept	元の提案を受け入れる
decline	元の提案を断る。別条件なら可能という返事も含む
unclear	与えられた情報では受諾と辞退を十分に絞れない

例えば「15時は無理ですが、16時なら大丈夫です」は、15時という提案への辞退として扱います。
何を受け入れたかを決めずに、肯定的な言葉があるかだけを問う実験にはしません。

会話と選択肢を別々に変える

各例で、前の発言を含めるかどうかと、unclear を含めるかどうかを組み合わせました。

条件ID	stateに渡すもの	選択肢
context_three	前の発言と返事	accept / decline / unclear
reply_three	返事のみ	accept / decline / unclear
context_two	前の発言と返事	accept / decline
reply_two	返事のみ	accept / decline

図1は比較の組み方です。矢印は、一つの条件だけを変えて比較する組を表します。
対角の二条件を直接比べて、文脈だけが原因だとは判断しません。

実行は2026年9月20日、モデルは jev-1.13.0 に固定しました。
12例をそれぞれ表の順に1回ずつ、計48リクエストです。
同じ条件の反復実験や、選択肢の並び順を入れ替える試験はしていません。

実際に送った質問と袋の例

次は48件のうち、袋の会話あり三択で送信した JSON です。
state は読む対象、instructions は質問、criteria は選択肢の説明です。
ケース名や想定答えはモデルへ渡していません。

{
  "model": "jev-1.13.0",
  "state": {
    "previous": "店員：袋をお付けしますか？",
    "reply": "客：大丈夫です。"
  },
  "questions": {
    "interpretation": {
      "type": "choice",
      "instructions": "提示された会話の最後の返事について、相手から提案された行為や条件を受け入れているか、断っているかを分類してください。提示されていない状況、口調、表情、本人の本心を補わず、与えられた選択肢から選んでください。",
      "criteria": {
        "accept": "最後の返事は、相手が提案した行為や条件を受け入れる意味である。",
        "decline": "最後の返事は、相手が提案した行為や条件を断る意味である。別の条件なら可能という返事も、元の条件への辞退に含める。",
        "unclear": "提示された情報だけでは、受諾と辞退のどちらかに十分に絞れない。"
      }
    }
  }
}

返事のみ条件は state.previous を省略し、二択条件は criteria.unclear を省略します。
それ以外の質問文と、accept、decline の説明と順序は固定しました。

再現する場合は、利用可能な TypeSafe アカウントと予算を確認したうえで、公式のAPI手順から POST https://api.typesafe.ai/v1/systemone にこの形式を渡します。
認証キーを本文や公開ログへ含めないでください。
今回の呼び出し側は Windows 11、PowerShell、Node.js v24.16.0で、1件ずつ送信し、失敗時は再試行せず停止する構成にしました。
このJSON自体を実行すればよいわけではなく、認証と送信、保存の処理は別途必要です。

全12例の会話

元の発言は場面ごとに次の一文です。各返事は別々の入力であり、三つ続けて送ってはいません。

• 袋：店員：袋をお付けしますか？
• 打ち合わせ：同僚：打ち合わせは15時開始で大丈夫ですか？
• 手伝い：同僚：荷物を運ぶのを手伝いましょうか？
• おかわり：店員：コーヒーのおかわりはいかがですか？

ケースID	最後の返事
bag_bare	客：大丈夫です。
bag_accept	客：はい、大丈夫です。袋をお願いします。
bag_decline	客：大丈夫です。袋は要りません。
meeting_bare	自分：大丈夫です。
meeting_accept	自分：大丈夫です。15時開始でお願いします。
meeting_decline	自分：15時は無理ですが、16時なら大丈夫です。
help_bare	自分：大丈夫です。
help_accept	自分：はい、大丈夫です。そちらの箱を運ぶのを手伝ってください。
help_decline	自分：大丈夫です。一人で運べるので、手伝いは不要です。
drink_bare	客：大丈夫です。
drink_accept	客：はい、大丈夫です。もう一杯お願いします。
drink_decline	客：大丈夫です。もう飲まないので、おかわりは要りません。

末尾が bare の4例には、正解ラベルを付けていません。
明示的な8例には作成者が accept または decline を事前に設定しましたが、独立した人手評価を済ませた正解データではありません。
前の発言を消した条件では、元の提案が見えなくなるため、このラベルで採点しません。

袋と打ち合わせで変わった回答

図2は、実行前に入口として決めた2例の三択結果です。矢印は送信と応答の対応で、モデル内部の推論過程ではありません。

確率は最大だった選択肢の返却値です。
袋の会話では辞退0.98ですが、「本心を98%当てた」という測定ではありません。
高い値でも誤判定し得ることと、値が示すものを区別します。

全例の選択結果は次のとおりです。見やすさのため accept を受諾、decline を辞退、unclear を不明と表記します。

ケースID	会話あり三択	返事のみ三択	会話あり二択	返事のみ二択
bag_bare	辞退	受諾	辞退	受諾
bag_accept	受諾	受諾	受諾	受諾
bag_decline	辞退	辞退	辞退	辞退
meeting_bare	受諾	不明	受諾	受諾
meeting_accept	受諾	受諾	受諾	受諾
meeting_decline	辞退	辞退	辞退	辞退
help_bare	辞退	不明	辞退	受諾
help_accept	受諾	受諾	受諾	受諾
help_decline	辞退	辞退	辞退	辞退
drink_bare	辞退	受諾	辞退	受諾
drink_accept	受諾	受諾	受諾	受諾
drink_decline	辞退	辞退	辞退	辞退

明示的な8例は、会話あり三択と会話あり二択のそれぞれで事前ラベルと8/8一致しました。
三択で不明を選んだ明示例は0件でした。
短い返事4例の正解率や、日本語全体の精度を表す数字ではありません。

返事のみの短い4例では、二択はすべて受諾、三択は2件が不明でした。
ただし三択でも袋とおかわりは受諾です。
「不明という選択肢を足せば、情報不足を必ず検出する」とは言えません。

同一入力でも数値に差があった

前の発言を外した袋とおかわりは、どちらも 客：大丈夫です。 です。
送信する質問も同じでしたが、二択の受諾の値は0.91と0.80でした。
同じく、打ち合わせと手伝いはどちらも 自分：大丈夫です。 で、返事のみ三択の不明の値は0.57と0.55でした。

場面名やケースIDは送信していないので、この差を「元の場面を理解したから」と説明することはできません。
差の原因は未検証です。
また、「客」「自分」という話者表記の違いは残っているため、別場面の返事のみ条件を完全に同じ入力としてまとめることも避けます。

今回は順序を変えたり、各条件を何度も繰り返したりしていません。
選択肢の数を変えると確率を割り当てる対象自体も変わるため、二択と三択の数値差をそのまま精度向上とは読めません。
観察した変化をすべて文脈だけの効果とせず、個々の入力と応答の対応として残します。

実行費用と再現するときの記録

成功48件の応答を合計すると、入力26,408トークン、出力1,848トークンでした。
2026年9月20日に確認した公式単価は入力100万トークン当たり0.042米ドル、出力無料です。
入力使用量からの計算額は 26408 * 0.042 / 1000000 = 0.001109136 米ドルでした。
これは請求確定額ではなく、クレジット消費との照合も未実施です。

成功実行の前に、1件目がTLSエラーで停止した実行があります。
認証なしの診断では UNABLE_TO_GET_ISSUER_CERT_LOCALLY が出て、Windowsの信頼ストアを使う node --use-system-ca で接続できました。
証明書検証を無効にせず、再実行の承認を取り直しています。
初回失敗分の請求は未確認で、上の計算額には含めていません。

再現時は、入力全文、質問全文、モデル版、選択結果、確率分布、confidence、使用量、実行日時、失敗も含む件数を残します。
認証キーやCookieは保存対象にしません。
公式も英語以外での独自評価と、字義的な読み取りなどの制約を案内しています。

自分のアプリで返事を分類するなら、まず「何の提案への返事か」を入力に含めるか決め、足りない場合の扱いを用意します。
そのうえで、明確な例と曖昧な例を分けて、同じ入力を繰り返したときも結果が安定するかを別に確かめます。
今回の12例は、その比較を作るための出発点です。