# Cross-provider Schema Loss Accounting Envelope CURRENT_STATUS: CURRENT OBSERVATION: SPEC_ONLY FRESHNESS: CURRENT PAGE_TYPE: reference CANONICAL_URL: /tools/ea-521-cross-provider-schema-loss-accounting-envelope CLAIM_IDS: none EVIDENCE_IDS: EA-521-CURRENT-APPROVAL, EA-521-CURRENT-BODY-READBACK UNKNOWN_IDS: EA-521-UNKNOWN-01 OPS_IDS: none ## Summary 「Structured Outputsを使えばJSON Schemaどおりになる」「三providerで同じschemaを使える」とは表現しない。安全な表現は、「各providerのdocumented subsetと実効strictnessをversion付きで確認し、canonical schemaからprovider schemaへの変換差分を記録し、生成後にcanonical constraintを再検証する。表現不能な重要constraintはfail closedまたはdeterministic validationで補う」である。 ## Current judgment 「Structured Outputsを使えばJSON Schemaどおりになる」「三providerで同じschemaを使える」とは表現しない。安全な表現は、「各providerのdocumented subsetと実効strictnessをversion付きで確認し、canonical schemaからprovider schemaへの変換差分を記録し、生成後にcanonical constraintを再検証する。表現不能な重要constraintはfail closedまたはdeterministic validationで補う」である。 ## Scope Cross-provider Schema Loss Accounting Envelope ## Confirmed ## UNKNOWN - EA-521-UNKNOWN-01: - OpenAI／Anthropic／Geminiの全current model・API revision・SDK組合せに対するkeyword-by-keyword executable matrix。 - SDK内部rewriteがversion間でどのように変化するかの継続的なmachine-readable差分。 - streaming partial／refusal／truncation／tool-result errorを含む三provider共通negative fixtureの実測結果。 - providerのschema-support変更を事前通知だけで完全に検出できるか。 - 複雑な業務constraintをcanonical validatorへ退避した場合のlatency／cost／failure distribution。 ## Evidence - EA-521-CURRENT-APPROVAL (RESEARCH): 現行本文の監査・revision対応 - EA-521-CURRENT-BODY-READBACK (IMPL): 現行本文の収録照合 ## Failure / limits 最も危険なのは、load-bearing constraintがadapterで黙って消える場合である。たとえば業務上許可された値域、追加field禁止、相互排他的条件、文字列長、数値上限、依存field、条件分岐などがcanonical schemaでは安全条件でも、provider subsetへloweringする際に表現できないことがある。生成結果がprovider側schemaには適合していても、canonical business ruleには違反し得る。 第二の失敗は、refusal、max-token truncation、streaming partial、tool-call interruption、schema validation errorを「空fieldを補った正常object」に変換することである。終端状態を失うと、失敗を成功に変換してしまう。特にdefault値の自動補完は、providerが生成しなかった値とproviderが明示した値を区別できなくする。 第三はversion driftである。provider、model、API revision、SDK、adapterのいずれかが更新されると、同じcanonical schemaでもlowered schemaやstrictnessが変化し得る。過去のPASSを新versionへ自動継承すると、constraint lossの再発を検出できない。 第四はtool schemaとresult schemaの混同である。tool argument validation、provider-native call/result correlation、application-side canonical validation、外部side effectのauthorizationは別のcontrol planeである。schema-validなtool argumentであっても、その操作が現在許可されていることや、外部effectが成功したことは証明しない。 ## Failure / limits 各providerはstrict／structured output機能を提供しており、適切なsubset内では自由形式JSONより強い構造保証を得られる。この事実は有用であるが、provider間で同じJSON Schema意味論が保証されることを示さない。SDKによるschema変換とclient-side validationはportabilityを改善できるが、変換で失われたconstraintをproviderが強制したことにはならない。 本candidateはcurrent provider documentationを中心にした運用設計であり、version-pinned三provider横断negative fixtureをこのRUNで実行したものではない。streaming partial、refusal、truncation、SDK rewriteの細部はmodel/API/SDK versionにより変わり得る。 ## 要点と前提 CANDIDATE_ID: ORPHAN-RESCUE-EA521-20261019-C1 ## 要旨 LLMやAgentのstructured output／tool callingを複数providerへ移植する際、同じJSON Schemaを渡したという事実だけでは、同じ制約が実効しているとは判断できない。各providerはJSON Schemaの異なる部分集合を受理し、SDKやAPI経路によってはschemaを変形・正規化したり、厳格検証からbest-effortへ移行したりする。したがってEnterprise AI運用では、アプリケーション側のcanonical schemaと、providerへ実際に渡されたlowered schemaの差分を明示的に管理し、失われた制約を監査可能にする必要がある。 本項の中心は「共通schemaを作ること」ではなく、「変換で何が失われたかを証明可能にすること」である。canonical schemaのhash、provider/model/API/SDK・adapter version、実際のlowered schema、削除・書換え・近似されたconstraint、effective strictness、生成結果の終端状態、canonical schemaによる再検証結果を一つの運用記録として結び付ける。 ## なぜschema portabilityが壊れるのか OpenAIのStructured Outputs／strict function callingはJSON Schema全体ではなく部分集合を扱う。current documentationではobjectにadditionalProperties=falseを要求し、propertiesをrequiredとして扱う制約があり、allOf、not、dependentRequired、dependentSchemas、if/then/elseなど利用できないkeywordがある。API経路によってはschemaをstrict向けに正規化できる場合がある一方、正規化不能時にstrict:falseのbest-effortへ落ちる経路もある。このため「requestが受理された」ことと「canonical constraintが厳格に強制された」ことは同義ではない。 AnthropicのStructured Outputs／strict tool useも制約されたJSON Schema subsetである。basic type、enum/const、anyOf、限定的allOf、local $ref、required、additionalProperties=false等を扱える一方、recursive schema、external $ref、数値minimum/maximum/multipleOf、一般的なminLength/maxLengthや広いarray constraintなどはそのまま扱えない。SDK helperはunsupported constraintを除去してdescriptionへ移す、additionalProperties=falseを強制する、formatをfilterする等の変換を行い、その後original schemaでclient-side validationする場合がある。したがってprovider側のstrict successは、アプリケーションのoriginal schemaそのものへの適合を意味しない場合がある。 Geminiもstructured outputでJSON Schemaのsubsetを扱い、schemaの大きさ・深さや利用可能keywordに制約がある。さらにfunction calling／structured responseのrequest wiring、tool result correlation、failure stateは他providerと同一ではない。三者の機能名が似ていても、constraint coverage、error semantics、refusal/incomplete state、streaming behaviorを同一視してはならない。 ## 運用上の失敗モード 最も危険なのは、load-bearing constraintがadapterで黙って消える場合である。たとえば業務上許可された値域、追加field禁止、相互排他的条件、文字列長、数値上限、依存field、条件分岐などがcanonical schemaでは安全条件でも、provider subsetへloweringする際に表現できないことがある。生成結果がprovider側schemaには適合していても、canonical business ruleには違反し得る。 第二の失敗は、refusal、max-token truncation、streaming partial、tool-call interruption、schema validation errorを「空fieldを補った正常object」に変換することである。終端状態を失うと、失敗を成功に変換してしまう。特にdefault値の自動補完は、providerが生成しなかった値とproviderが明示した値を区別できなくする。 第三はversion driftである。provider、model、API revision、SDK、adapterのいずれかが更新されると、同じcanonical schemaでもlowered schemaやstrictnessが変化し得る。過去のPASSを新versionへ自動継承すると、constraint lossの再発を検出できない。 第四はtool schemaとresult schemaの混同である。tool argument validation、provider-native call/result correlation、application-side canonical validation、外部side effectのauthorizationは別のcontrol planeである。schema-validなtool argumentであっても、その操作が現在許可されていることや、外部effectが成功したことは証明しない。 ## 実装・control implication 運用基準はcanonical-firstとする。canonical application schemaを唯一の業務意味の基準とし、provider adapterはそこからprovider-specific schemaを生成する。変換時には、canonical schema hash、provider/model/API/SDK/adapter version、lowered schema hash、effective strictness、各constraintのPRESERVED／REWRITTEN／DROPPED／UNSUPPORTEDを記録する。security・authorization・financial limit・data classification等のload-bearing constraintがDROPPEDまたはUNSUPPORTEDなら、生成経路をfail closedにするか、provider外のdeterministic validatorで必ず補う。 生成後はprovider側のschema successだけで完了させず、decoded complete objectをcanonical schemaと業務validatorで再検証する。provider validation successとcanonical validation successを別fieldとして保存する。refusal、incomplete/truncated、streaming partial、API rejection、provider-schema failure、canonical-schema failure、complete successを別状態として扱い、default-filled successへ正規化しない。 schema compiler／adapterにはnegative fixtureを持たせる。unsupported keyword、nested object、追加property、境界値、依存field、条件分岐、enum/const、nullable表現、長い／深いschemaを含むfixtureをprovider/model/API/SDK versionごとに実行し、lowering差分とcanonical revalidation結果を保存する。providerやSDK更新時にはschema capability fingerprintが変化していないかを再検査し、変化時は既存承認を無効化して再監査する。 ## 適用境界 このcontrolはOpenAI、Anthropic、Gemini等のstructured output／tool callingを横断するadapterに特に重要であるが、特定providerだけを利用する場合でもSDK更新やmodel migrationに伴うschema driftの検出に有効である。一方、ここで扱うのは構造・constraint portabilityであり、生成内容の真実性、semantic correctness、authorization、side-effect exactly-once、prompt injection耐性を保証するものではない。 provider documentationが示すsubsetはdocumented contractであり、すべてのmodel/API revisionで永続不変とは限らない。SDK helperの変換もversion依存である。したがってdocumentationの表を固定的な永久互換表として扱わず、versionをbindしたcapability evidenceとして扱う。 ## Counterevidence / limitations 各providerはstrict／structured output機能を提供しており、適切なsubset内では自由形式JSONより強い構造保証を得られる。この事実は有用であるが、provider間で同じJSON Schema意味論が保証されることを示さない。SDKによるschema変換とclient-side validationはportabilityを改善できるが、変換で失われたconstraintをproviderが強制したことにはならない。 本candidateはcurrent provider documentationを中心にした運用設計であり、version-pinned三provider横断negative fixtureをこのRUNで実行したものではない。streaming partial、refusal、truncation、SDK rewriteの細部はmodel/API/SDK versionにより変わり得る。 ## OPEN_UNKNOWN - OpenAI／Anthropic／Geminiの全current model・API revision・SDK組合せに対するkeyword-by-keyword executable matrix。 - SDK内部rewriteがversion間でどのように変化するかの継続的なmachine-readable差分。 - streaming partial／refusal／truncation／tool-result errorを含む三provider共通negative fixtureの実測結果。 - providerのschema-support変更を事前通知だけで完全に検出できるか。 - 複雑な業務constraintをcanonical validatorへ退避した場合のlatency／cost／failure distribution。 ## SAFE_WORDING 「Structured Outputsを使えばJSON Schemaどおりになる」「三providerで同じschemaを使える」とは表現しない。安全な表現は、「各providerのdocumented subsetと実効strictnessをversion付きで確認し、canonical schemaからprovider schemaへの変換差分を記録し、生成後にcanonical constraintを再検証する。表現不能な重要constraintはfail closedまたはdeterministic validationで補う」である。 ## Source / provenance locator - OpenAI: Structured model outputs / Function calling — current documentation accessed in EA-521 bounded refresh 2026-10-17. Documented JSON Schema subset、strict mode、normalization/fallback boundary。 - Anthropic Claude Platform: Structured outputs / Strict tool use — current documentation accessed 2026-10-17. Supported/unsupported schema subset、SDK transformation、refusal/max_tokens caveat。 - Google Gemini: Function Calling / Structured Outputs — registered current provenance for EA-521。JSON Schema subsetおよびprovider-specific request/validation boundary。 - Model Context Protocol: Tools specification — registered provenance。Tool schemaはcapability descriptionであり、provider-specific generation validationやauthorizationそのものではない。 - Continuation canonical: Google Doc 1XpjZC_R1eHlIckvUaEaJ_mcj6YW6j0ihZ0b91z5vewU, EA-521 research checkpoints 2026-10-13〜2026-10-17。 NEXT: /agent/start.json STOP: This is a knowledge projection, not an execution order.