設計の手順
申告と確認済みの事実を分ける
架空の依頼：「左のイヤホンから音が出ない。10日前に購入し、交換したい」。ユーザーの申告、注文システムの購入日、検査状況を別々に記録します。購入日の申告だけで交換資格を確定しません。
三つの小さな質問に分ける
Choice で主な問題、Noul で明示的な交換希望、Score で診断情報の十分さを判断します。分類、希望、情報量を一つの質問に混ぜません。
同じ情報で答えられる質問だけまとめる
一つのリクエストに複数の質問を送れます。ただし、音声テストに合格したかはテスト結果が届くまで判断できません。並列化しても情報の依存関係は残ります。
回答を使う条件をコードにする
十分な confidence の故障分類だけを診断へ進めます。交換希望は担当者向けの印であり、交換許可ではありません。配送問題なら診断スコアを使いません。項目不足や API エラーは確認へ戻します。
処理全体を比較する
同じ依頼と質問版で、まとめた場合と個別の場合の p50/p95、費用、誤り、確認率を比べます。モデル版と処理ログを保存し、公式デモを自分の測定値にしません。
具体例 · 本サイトの架空データ
| 観察した事実 | 判断 | コードでの処理 |
|---|---|---|
| 故障の訴え・交換希望・未検査 | 希望と資格は異なる | 診断へ進め、希望を記録 |
| 配送遅延だが診断スコアも返る | この分岐では無関係 | 配送の処理だけ使う |
| 分類が不確実・注文情報なし | 質問数を増やしても事実は増えない | 注文を取得するか人へ回す |
コピーできる設計例
独自の例です。JSON はリクエストや入力の形、Python は架空スコアの計算のみを示します。API は実行しません。接続前に公式仕様と処理方針を確認してください。
{
"model": "jev-latest",
"state": {
"user_report": "Left earbud is silent; I want a replacement.",
"order_verified": true,
"diagnostic_status": "not_tested"
},
"questions": {
"issue": {
"type": "choice",
"instructions": "What is the main issue in the user report?",
"criteria": {
"device": "Device behavior or malfunction",
"shipping": "Delivery, tracking, or missing parcel",
"billing": "Payment or charges",
"other": "None of the above"
}
},
"replacement_requested": {
"type": "noul",
"instructions": "Does the user explicitly request a replacement?"
}
}
}よくある失敗
- 予測した分類を事実として次の質問に渡すこと。元の state を共有し、結果はコードで組み合わせます。
- 返った項目をすべて利用すること。まず分岐を選びます。
- 一回のリクエストを業務処理の許可と見なすこと。権限と失敗処理も必要です。
TRY / THINK / COMPARE
先に考えてから解説へ
「電池切れか故障か分からない」という依頼で、充電後に直ったかを同時に判定できますか？
解説を開く
できません。今ある情報で分類し、充電テストの結果を得てから state を更新します。予測は観測の代わりになりません。
提出前の確認
- 質問は一つの概念に絞り、事実の出所を記録する。
- 回答を使う条件と無視する条件を決める。
- 失敗・項目不足・不確実性への処理を用意する。
- 同じデータと版で比較する。
よくある質問
必ず速くなりますか？
保証はありません。往復を減らせますが、実際の条件で測定します。
質問同士は自動で検証し合いますか？
しません。矛盾処理と制約を明示します。
参考資料
公式パターンと Datawhale の実践テーマを参考に、説明・例・演習を独自に作成しています。API の実行結果や性能測定ではありません。