Cross-provider データ形式の定義 Loss Accounting Envelope

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による再検証結果を一つの運用記録として結び付ける。

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が成功したことは証明しない。

運用基準は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として扱う。

各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により変わり得る。

• 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。

「Structured Outputsを使えばJSON Schemaどおりになる」「三providerで同じschemaを使える」とは表現しない。安全な表現は、「各providerのdocumented subsetと実効strictnessをversion付きで確認し、canonical schemaからprovider schemaへの変換差分を記録し、生成後にcanonical constraintを再検証する。表現不能な重要constraintはfail closedまたはdeterministic validationで補う」である。

• 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。