フィールドガイド / 8 分
Schema をユーザー体験として設計する
安定した形にも refusal、validation、domain check が必要。
Structured Outputs は response を JSON Schema に従わせ、parsing failure の一部をなくします。しかし値の真実性、有用性、権限、安全な適用までは証明しません。
作業原則
形は真実ではない
Schema adherence は構造を検証するだけ。domain validation、sources、business rules が採用可否を決めます。
Refusal は第一級 state
safety refusal は application schema に従うとは限らず、独立した UI と control flow が必要です。
契約を version 管理
schema version を命名し migration する。prompt edit で production data を暗黙に再定義しません。
フィールド手順
- 01
consumer から始める
次の application step が本当に必要とする最小 object を設計します。
- 02
曖昧さを制約
enums、required keys、bounds、descriptions を使い、既知の有限 list を unbounded map にしません。
- 03
全 terminal state を扱う
valid output、refusal、incomplete、transport error、local validation failure を分離します。
- 04
domain validation を適用
parse 後に identifiers、dates、permissions、totals、references、cross-field invariants を確認します。
- 05
fixtures で評価
代表 input を保存し、prompt/model 変更前に schema validity と task quality を検証します。
PASS / FAIL
受入チェック
- Schema に version がある。
- Refusal に product-state design がある。
- parse 後に business invariants が走る。
- normal、edge、adversarial、refused fixtures がある。
WATCH / REJECT
失敗パターン
- parse success と correctness を同一視する。
- failure 回避のため全 field を optional にする。
- 最初の sample だけで schema を作る。