JSON SchemaはAI Agentの標準Contractになるか？

If you have read earlier posts in this series —the evolution of JSON Schema⟧, Function Calling, and MCP,Structured Output in practice,JSON data flow across the Agent call chain— one pattern stands out:whether the model vendor or the protocol layer, when describing “what shape of data to exchange,” the answer is almost always JSON Schema⟧ (or a subset).

That raises a natural question:will JSON Schema⟧ become AI Agents’ “standard Contract”— the default handshake language across teams, IDEs, and cloud vendors, like ⟦OpenAPI for REST or Protobuf for gRPC?

Starting from what “Contract” actually means, this article maps 2026 adoption, remaining gaps, and engineering choices. Spoiler:JSON Schema⟧ is already the de facto standard for Agent I/O boundaries, but not the only contract layer— transport, auth, and orchestration still belong to MCP, ⟦OpenAPI, and Agent SDKs.

What “Contract” Means for Agents

In software engineering, a contract specifies theshape, semantics, and error handlingof exchanged data. AI Agents are harder than ordinary APIs because the “caller” includes anon-deterministic large modelthat may omit fields, invent parameters, or drift between natural language and structured output.

So the Agent stack has multiple contract layers; JSON Schema⟧ mainly coverspayload shape:

Saying “JSON Schema⟧ becomes the standard Contract” in practice means:wherever models and programs — or programs and tools — exchange structured JSON, JSON Schema⟧ is the default description. How to connect and who is authorized is the layer above.

Three Fronts JSON Schema⟧ Already Holds

1. Tool / Function Calling parameters

OpenAI, Google Gemini, and Anthropic Claude Tools APIs all use JSON Schema⟧ for parameters (or equivalent). The model reads description for semantics; the host validates arguments with the same Schema before execution — matching the chain we broke down in the data flow article.

{
  "name": "create_ticket",
  "description": "Create a record in the ticketing system",
  "parameters": {
    "type": "object",
    "properties": {
      "title": { "type": "string", "description": "Ticket title" },
      "priority": { "type": "string", "enum": ["low", "medium", "high"] }
    },
    "required": ["title"],
    "additionalProperties": false
  }
}

2. Structured Output (final model reply)

When the business needs JSON instead of natural language, vendor Structured Output / JSON Schema⟧ modes constrain tokens atdecode time. See theStructured Output guide; for Gemini, the構造化された JSON チュートリアル.

3. MCP Tool inputSchema

The MCP spec requires each Tool to expose inputSchema as JSON Schema⟧. When Cursor, Claude Desktop, and other Hosts map MCP tools to model Function Calling, Schema is often passed through or lightly subset — the basis for “write Schema once, reuse across IDE and cloud models.”

These three fronts coveralmost every structured JSON boundaryin the Agent lifecycle — core evidence for the “standard Contract” thesis.

Alternatives and Competitors

Key insight:no single format optimally serves both “model-readable” and “high-performance RPC.”JSON Schema⟧ wins the model ↔ program link; ⟦OpenAPI and Protobuf keep their domains and connect via conversion layers.

Why JSON Schema⟧ Is Winning

1. Aligned with LLM training distribution: JSON is abundant in pretraining; Schema type, enum, and description act as soft type hints.
2. Human- and machine-readable: PMs, backend, and prompt engineers can review the same Schema — better for collaboration than binary Protobuf.
3. Mature validation ecosystem: ajv, jsonschema (Python), cloud API built-ins — still recommendsecond-pass validationafter Structured Output for semantics.
4. Vendor convergence: 2023 had custom tool formats; 2024–2026 mainstream API docs standardize on JSON Schema⟧ subsets for parameters and responses.
5. MCP and ⟦OpenAPI “downward compatibility”: MCP chose JSON Schema⟧ instead of a new DSL; ⟦OpenAPI 3 Schema components reuse directly.

What Is Not Unified Yet

“De facto standard” ≠ “fully unified.” Production Agents still face:

• Schema dialects: OpenAI strict: true is strict on additionalProperties and full required coverage; Gemini and Anthropic differ on unions, $ref depth, etc. Test complex Schema against target APIs.
• Draft versions: draft-07, 2019-09, 2020-12 coexist; $defs vs definitions trips codegen tools.
• Syntax vs semantics: Schema guarantees “priority exists and is string,” not “priority=high meets SLA policy” — business rules need code or extensions like JSON Logic⟧.
• Non-JSON payloads: images, audio, file URIs — Schema wraps metadata, not blob storage contracts.
• Orchestration and state: multi-step Agents, human-in-the-loop, sub-Agent delegation — JSON Schema⟧ does not describe state machines; LangGraph, Temporal, etc. have their own DSLs.

Expecting “one Schema to rule the full Agent stack” is unrealistic; expecting “all structured JSON boundaries default to Schema” is already largely true.

2026 Ecosystem Signals

If you are assessing tech debt:investing in JSON Schema⟧ skills and tooling now is safer than stacking prompts on private JSON formats— even a future “Agent Schema 2027” profile will likely be a JSON Schema⟧ superset or subset, not a new language.

Will It Become the “Only” Standard?

Two-level answer:

Yes (high confidence)— as the default Contract for Agentstructured I/O: tool parameters, Structured Output, MCP inputSchema, ⟦OpenAPI request/response bodies. New tools and model APIs without JSON Schema⟧ descriptions feel incomplete.

No (equally important)— as thesole full-stack Agent contract: transport (stdio/SSE/HTTP), auth, tool discovery, multi-Agent orchestration, SLA and quotas stay with MCP, ⟦OpenAPI, and platform policy. JSON Schema⟧ is the “type layer,” not the “network” or “governance” layer.

┌──────────────────────────────────────────────────┐
│  Governance / auth / audit (OAuth, RBAC, logs)   │
├──────────────────────────────────────────────────┤
│  Orchestration / state (Agent frameworks, flows) │
├──────────────────────────────────────────────────┤
│  Connection / discovery (MCP, OpenAPI, gRPC GW)  │
├──────────────────────────────────────────────────┤
│  ★ JSON Schema: tool args · output · payloads ★  │
├──────────────────────────────────────────────────┤
│  Executors (HTTP, DB, files, browser automation) │
└──────────────────────────────────────────────────┘

Practical Recommendations

• Single Schema source: define domain models in Pydantic / Zod, generate JSON Schema⟧ for OpenAI, MCP, and docs — avoid three drifting definitions.
• Subset per target API: maintain “compatible Schema” for OpenAI strict, Gemini, etc., or CI-detect unsupported keywords.
• Treat description as Prompt: description drives misfires; review it like field naming.
• Structured Output + server re-validation: decoding cuts syntax errors; business rules use the same Schema + custom validators.
• Version and changelog: Schema change = breaking API change; pin Schema versions or stay backward compatible.
• Validate locally first: JSON Toolbox⟧ for schema syntax and sample payloads before integration.

FAQ

Summary and Next Steps

JSON Schema⟧ is becoming the standard Contract for AI Agent structured I/O— not a prediction, but a track laid jointly by OpenAI, Google, Anthropic, MCP, and mainstream Agent SDKs. It will not replace all of ⟦OpenAPI or Protobuf, but for the model ↔ program handshake, alternatives have little room left.

Next: pick one real business path (e.g. user intent → structured extraction → ticket API), drive Structured Output and tool parameters from one JSON Schema⟧, validate locally in JSON Toolbox⟧, then wire MCP. Suggested series order:evolution overview→Structured Output→data flow→ this article (Contract verdict).