{
  "format": "agent-article-v0",
  "article_id": "EA-521",
  "canonical_url": "/tools/ea-521-cross-provider-schema-loss-accounting-envelope",
  "page_type": "reference",
  "claim_ids": [],
  "evidence_ids": [
    "EA-521-CURRENT-APPROVAL",
    "EA-521-CURRENT-BODY-READBACK"
  ],
  "unknown_ids": [
    "EA-521-UNKNOWN-01"
  ],
  "operational_object_ids": [],
  "provider": [],
  "models": [],
  "plans": [],
  "surfaces": [],
  "regions": [],
  "current_status": "CURRENT",
  "observation_status": "SPEC_ONLY",
  "freshness": "CURRENT",
  "last_verified": "2026-10-18",
  "supersedes": [],
  "superseded_by": [],
  "provenance": [
    "ORPHAN-RESCUE-EA521-20261019-C1",
    "BODY-SHA256:8f0dc81ebfe26b99b4a370d3244d7065018689c50add3da143b402adc857f5e6"
  ],
  "article_sources": [
    {
      "id": "EA-521-CURRENT-APPROVAL",
      "evidence_class": "RESEARCH",
      "title": "現行本文の監査・revision対応",
      "supports": [
        "現行台帳のAUDIT_PASSと候補・revision・本文ハッシュの対応を確認しています。"
      ],
      "limit": "監査状態と来歴の記録です。外部根拠の最新性や本文の全主張を追加保証しません。",
      "origin_class": "AUDITED_CANONICAL_RESEARCH_PACKET",
      "source_or_experiment_ids": [
        "ORPHAN-RESCUE-EA521-20261019-C1"
      ],
      "supporting_locators": [
        "1KqhJtiSb2S84rWmeYVwKcT_76dBwZ_B0ZZuAWQqH0rQ/EA_REVISION_LEDGER#ea_id=EA-521&revision_id=EA-521-R1-20261013&candidate_id=ORPHAN-RESCUE-EA521-20261019-C1",
        "EA-521-R1-20261013"
      ],
      "provenance_status": "CURRENT_CANONICAL_APPROVAL_READBACK"
    },
    {
      "id": "EA-521-CURRENT-BODY-READBACK",
      "evidence_class": "IMPL",
      "title": "現行本文の収録照合",
      "supports": [
        "公開生成入力の本文SHA-256が、監査済み候補に結び付いたハッシュと一致しています。"
      ],
      "limit": "本文の同一性の検査です。外部システムの挙動や全主張の真偽を実証したものではありません。",
      "checked_at": "2026-10-19",
      "origin_class": "IMPLEMENTATION_READBACK",
      "source_or_experiment_ids": [
        "BODY-SHA256:8f0dc81ebfe26b99b4a370d3244d7065018689c50add3da143b402adc857f5e6"
      ],
      "supporting_locators": [
        "content/staging/EA-521.md",
        "8f0dc81ebfe26b99b4a370d3244d7065018689c50add3da143b402adc857f5e6",
        "EA-521-R1-20261013"
      ],
      "provenance_status": "CURRENT_APPROVED_BODY_HASH_MATCH"
    }
  ],
  "research_sections": [
    {
      "heading": "要点と前提",
      "text": "CANDIDATE_ID: ORPHAN-RESCUE-EA521-20261019-C1"
    },
    {
      "heading": "要旨",
      "text": "LLMやAgentのstructured output／tool callingを複数providerへ移植する際、同じJSON Schemaを渡したという事実だけでは、同じ制約が実効しているとは判断できない。各providerはJSON Schemaの異なる部分集合を受理し、SDKやAPI経路によってはschemaを変形・正規化したり、厳格検証からbest-effortへ移行したりする。したがってEnterprise AI運用では、アプリケーション側のcanonical schemaと、providerへ実際に渡されたlowered schemaの差分を明示的に管理し、失われた制約を監査可能にする必要がある。\n\n\n本項の中心は「共通schemaを作ること」ではなく、「変換で何が失われたかを証明可能にすること」である。canonical schemaのhash、provider/model/API/SDK・adapter version、実際のlowered schema、削除・書換え・近似されたconstraint、effective strictness、生成結果の終端状態、canonical schemaによる再検証結果を一つの運用記録として結び付ける。"
    },
    {
      "heading": "なぜschema portabilityが壊れるのか",
      "text": "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が厳格に強制された」ことは同義ではない。\n\n\nAnthropicの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そのものへの適合を意味しない場合がある。\n\n\nGeminiも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を同一視してはならない。"
    },
    {
      "heading": "運用上の失敗モード",
      "text": "最も危険なのは、load-bearing constraintがadapterで黙って消える場合である。たとえば業務上許可された値域、追加field禁止、相互排他的条件、文字列長、数値上限、依存field、条件分岐などがcanonical schemaでは安全条件でも、provider subsetへloweringする際に表現できないことがある。生成結果がprovider側schemaには適合していても、canonical business ruleには違反し得る。\n\n\n第二の失敗は、refusal、max-token truncation、streaming partial、tool-call interruption、schema validation errorを「空fieldを補った正常object」に変換することである。終端状態を失うと、失敗を成功に変換してしまう。特にdefault値の自動補完は、providerが生成しなかった値とproviderが明示した値を区別できなくする。\n\n\n第三はversion driftである。provider、model、API revision、SDK、adapterのいずれかが更新されると、同じcanonical schemaでもlowered schemaやstrictnessが変化し得る。過去のPASSを新versionへ自動継承すると、constraint lossの再発を検出できない。\n\n\n第四は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が成功したことは証明しない。"
    },
    {
      "heading": "実装・control implication",
      "text": "運用基準は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で必ず補う。\n\n\n生成後は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へ正規化しない。\n\n\nschema 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が変化していないかを再検査し、変化時は既存承認を無効化して再監査する。"
    },
    {
      "heading": "適用境界",
      "text": "この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耐性を保証するものではない。\n\n\nprovider documentationが示すsubsetはdocumented contractであり、すべてのmodel/API revisionで永続不変とは限らない。SDK helperの変換もversion依存である。したがってdocumentationの表を固定的な永久互換表として扱わず、versionをbindしたcapability evidenceとして扱う。"
    },
    {
      "heading": "Counterevidence / limitations",
      "text": "各providerはstrict／structured output機能を提供しており、適切なsubset内では自由形式JSONより強い構造保証を得られる。この事実は有用であるが、provider間で同じJSON Schema意味論が保証されることを示さない。SDKによるschema変換とclient-side validationはportabilityを改善できるが、変換で失われたconstraintをproviderが強制したことにはならない。\n\n\n本candidateはcurrent provider documentationを中心にした運用設計であり、version-pinned三provider横断negative fixtureをこのRUNで実行したものではない。streaming partial、refusal、truncation、SDK rewriteの細部はmodel/API/SDK versionにより変わり得る。"
    },
    {
      "heading": "OPEN_UNKNOWN",
      "text": "- OpenAI／Anthropic／Geminiの全current model・API revision・SDK組合せに対するkeyword-by-keyword executable matrix。\n- SDK内部rewriteがversion間でどのように変化するかの継続的なmachine-readable差分。\n- streaming partial／refusal／truncation／tool-result errorを含む三provider共通negative fixtureの実測結果。\n- providerのschema-support変更を事前通知だけで完全に検出できるか。\n- 複雑な業務constraintをcanonical validatorへ退避した場合のlatency／cost／failure distribution。"
    },
    {
      "heading": "SAFE_WORDING",
      "text": "「Structured Outputsを使えばJSON Schemaどおりになる」「三providerで同じschemaを使える」とは表現しない。安全な表現は、「各providerのdocumented subsetと実効strictnessをversion付きで確認し、canonical schemaからprovider schemaへの変換差分を記録し、生成後にcanonical constraintを再検証する。表現不能な重要constraintはfail closedまたはdeterministic validationで補う」である。"
    },
    {
      "heading": "Source / provenance locator",
      "text": "- 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。\n- Anthropic Claude Platform: Structured outputs / Strict tool use — current documentation accessed 2026-10-17. Supported/unsupported schema subset、SDK transformation、refusal/max_tokens caveat。\n- Google Gemini: Function Calling / Structured Outputs — registered current provenance for EA-521。JSON Schema subsetおよびprovider-specific request/validation boundary。\n- Model Context Protocol: Tools specification — registered provenance。Tool schemaはcapability descriptionであり、provider-specific generation validationやauthorizationそのものではない。\n- Continuation canonical: Google Doc 1XpjZC_R1eHlIckvUaEaJ_mcj6YW6j0ihZ0b91z5vewU, EA-521 research checkpoints 2026-10-13〜2026-10-17。"
    }
  ],
  "human_url": "/tools/ea-521-cross-provider-schema-loss-accounting-envelope",
  "markdown_url": "/agent/article.md?path=%2Ftools%2Fea-521-cross-provider-schema-loss-accounting-envelope",
  "json_url": "/agent/article.json?path=%2Ftools%2Fea-521-cross-provider-schema-loss-accounting-envelope"
}