構造化出力／スキーマ検証

Structured OutputやJSON Schemaは、LLM出力を機械処理しやすい構造へ制約し、parse/schema failureを減らすための境界です。schema適合を、内容の真偽、業務妥当性、認可、最新状態、副作用の安全性と同一視しません。

side effectへ到達する前に、少なくとも次を分離します。

• syntax/parse: JSONとして読めるか。
• provider schema conformance: providerのstructured-output modeが対応subsetに従っているか。
• independent schema validation: application側validatorで期待dialect/schemaに適合するか。
• semantic validation: ID、単位、時刻、金額、相互関係、business invariantが正しいか。
• execution gate: identity/authorization、最新version、precondition、idempotency、必要なhuman confirmationを満たすか。

前段PASSを後段PASSの代用にしません。

「JSON Schema対応」という表記だけでDraft 2020-12全機能が同一に使えるとは仮定しません。

OpenAI strict structured outputはJSON Schemaのsubsetを使用します。公式documentation自身が、標準meta-schemaにはstrict mode未対応featureがあることを示しています。

Gemini structured outputsもJSON Schemaのsubsetであり、大規模・深いschemaは拒否され得ます。provider/model/API surfaceごとにsupported keywordとcomplexity limitをfixtureで確認します。

schemaにはdialect/version、provider/model/API revision、schema hashを付け、consumer側validator versionも監査証跡へ残します。

JSON Schema Draft 2020-12ではformatのassertion behaviorはvocabulary/implementationに依存します。email/date-time等がschema validatorを通っても、メールボックス実在、業務時間、timezone policy、組織上の許可までは証明しません。

domain validationをschema validationから分離します。

constrained decodingでschema validityが高くても、値そのものが誤っている場合があります。

例: - 存在する型のcustomer_idだが別顧客 - enum内のactionだが意図と違う - integerの金額だが通貨・桁が違う - ISO date-timeだがtimezone/business cutoffが違う - required fieldを満たすため未知値を生成 - tool argumentsはvalidだが対象versionが古い

運用metricはschema-valid率だけでなくsemantic accuracy、executable accuracy、unsafe-accept rateを分離します。

refusal、safety stop、max-token truncation、timeout、tool/runtime errorをschema-valid success objectへ変換しません。

retry対象はfailure classで限定し、schemaを通すためにbusiness meaningを変更しません。retry後も同一idempotency/precondition boundaryを維持します。

tool argumentがschema-validでも、そのまま実行しません。

実行直前にprincipal、authorization、resource version、business invariant、duplicate/idempotency key、confirmation requirementを再検証します。LLMが生成した「authorized=true」「confirmed=true」のようなfieldを権限証明に使いません。

schema変更はversioned contractとして扱います。field名を維持したまま意味・単位・nullable semanticsを変えないようにし、producer/consumerの互換fixtureを持ちます。

provider側structured-output subsetやAPI surface変更時も同じschemaで再試験します。

各provider/model/versionで、malformed JSON、missing/extra field、wrong type/enum、unsupported keyword、deep nesting、refusal、truncation、schema-valid semantic error、stale ID、wrong unit/timezone/currency、unauthorized tool call、duplicate execution、schema-version mismatchを試験します。

parse validity、schema validity、semantic accuracy、executable accuracy、unsafe acceptance、refusal/errorを別metricとして記録します。

unsupported keyword/dialect、schema complexity rejection、refusal、truncation、timeout、schema-valid semantic error、stale ID/version、unit/timezone/currency error、fabricated required value、numeric precision mismatch、format semantics mismatch、regex portability、provider subset drift、unauthorized tool call、duplicate execution、precondition failure、schema evolution mismatch、validator bypass、validation-log leakageを想定します。

本項は2026-10-05時点のJSON Schema Draft 2020-12、OpenAI/Gemini公式structured-output documentation、および2026年の独立structured-output evaluationsに基づくdesk researchです。production schemaやlive provider callは未検査です。

Structured Output／JSON Schemaは構造適合を強化しますが、正しい答え、安全なtransaction、認可済み操作を保証しません。providerごとのschema subset/dialect/versionを固定し、application側でsemantic validation、authorization、precondition、idempotencyを別gateとして実施してください。

対象provider/model/API revision、organization schema、Anthropic current subset、streaming/refusal contract、validator implementation/version、schema registry、business invariants、authorization、idempotency、numeric precision、logging/retentionは未確認です。

schema-validをsemantic-validやexecution-safeへ昇格させず、five-gate modelとprovider subsetを監査可能な形で固定します。organization固有schemaが必要な場合はexact contractに対するfixtureを追加します。