Blog • AWS / Bedrock

Les sorties structurées Claude sur Amazon Bedrock garantissent la forme JSON—pourquoi les journaux batch et le chat copié exigent encore un contrôle local en trois étapes ?

Le 19 octobre 2026, AWS a annoncé les sorties structurées pour Claude sur Bedrock : décodage contraint avec JSON Schema, schema via output_config, outils stricts, additionalProperties:false. Batch et streaming inclus.

La comparaison complète des sorties structurées est dans le guide sorties structurées 2026. Un JSON conforme au schéma ne remplace pas les permissions—voir l'article schema insuffisant. Comment JSON Schema relie outils et réponses finales : pourquoi l'IA a besoin de JSON Schema. Cet article ne couvre que les trois étapes locales après Bedrock.

• Les requêtes Bedrock attachent le JSON Schema sous output_config.format avec additionalProperties:false.
• L'API garantit la forme d'une réponse Invoke—not les journaux, fichiers batch ou extraits copiés.
• Pipeline locale : (1) validate JSON Schema, (2) repair JSON après fences markdown, (3) contrôle ligne JSONL batch.
• Un TICKET_SCHEMA pour échantillons API, lignes de log et batch—bloquer localement enums, clés manquantes ou en trop.

Qu'a ajouté Bedrock pour Claude le 19 octobre ?

AWS indique dans l'annonce officielle What's New : sorties structurées Claude sur Bedrock avec décodage contraint, outils stricts, batch et streaming.

Les détails techniques sont dans le article de blog AWS Machine Learning. La garantie API n'est pas la fin du pipeline de journaux.

Comment attacher JSON Schema dans output_config ?

Bedrock met output_config.format.type à json_schema et la définition d'objet dans schema. additionalProperties:false à la racine. L'exemple utilise ticket_id, priority (enum), summary.

{
  "anthropic_version": "bedrock-2023-05-31",
  "max_tokens": 1024,
  "messages": [
    {
      "role": "user",
      "content": "Return one support ticket as JSON."
    }
  ],
  "output_config": {
    "format": {
      "type": "json_schema",
      "schema": {
        "type": "object",
        "additionalProperties": false,
        "required": ["ticket_id", "priority", "summary"],
        "properties": {
          "ticket_id": { "type": "string" },
          "priority": { "enum": ["low", "medium", "high"] },
          "summary": { "type": "string", "maxLength": 200 }
        }
      }
    }
  }
}

Le batch devient souvent du JSONL—une ligne par enregistrement. Le streaming collé côté client n'est pas revalidé par Bedrock.

Pourquoi valider en local si l'API garantit la forme ?

Le corps Invoke est conforme chez Bedrock, mais les artefacts sauvés se déforment : préfixes de log, échappements CloudWatch, fences ```json, lignes vides ou tronquées en batch.

{
  "ticket_id": "TCK-1042",
  "priority": "high",
  "summary": "Bedrock batch row passed constrained decoding"
}

Si priority devient urgent ou owner apparaît, les règles SLA dérapent. SAMPLE_BAD montre un enum hors plage—bloquez avec le même TICKET_SCHEMA.

{
  "ticket_id": "TCK-1042",
  "priority": "urgent",
  "summary": "enum value not in schema"
}

Quel TICKET_SCHEMA en local ?

Utilisez JSON Schema pour fixer champs et enums. priority seulement low/medium/high ; additionalProperties:false rejette les clés non déclarées. Passer ne prouve pas la source du log.

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "type": "object",
  "additionalProperties": false,
  "required": ["ticket_id", "priority", "summary"],
  "properties": {
    "ticket_id": {
      "type": "string",
      "description": "Support ticket ID, e.g. TCK-1042"
    },
    "priority": {
      "enum": ["low", "medium", "high"]
    },
    "summary": {
      "type": "string",
      "maxLength": 200
    }
  }
}

Que corrige chaque étape locale ?

Bedrock = décodeur en ligne, JSONNote = contrôle hors ligne. Ordre : JSON conforme schema, repair fences, lignes JSONL.

Comment exécuter les trois étapes dans JSONNote ?

1. 1
   Étape 1 : validate schema

   Ouvrez JSON Schema. TICKET_SCHEMA au premier champ, SAMPLE_OK ou JSON de log au second.

2. 2
   Étape 2 : repair fences

   Ouvrez JSON Repair. Collez le chat avec fences ```json, retirez-les, revalidez.

3. 3
   Étape 3 : lignes JSONL

   Ouvrez outil JSONL. Chargez le batch Bedrock, vérifiez chaque ligne ; TICKET_SCHEMA pour enum ou troncature.

Questions fréquentes

Puis-je sauter la validation locale avec Bedrock ?

Non. L'API ne garantit que le corps Invoke courant. Journaux, batch, copies et caches exigent la même validation schema dans l'app.

Quel lien entre outils stricts et schema output_config ?

Les deux utilisent JSON Schema au décodage, mais couches différentes : arguments d'outil vs output_config. Gardez les schemas séparés pour les contrôles locaux.

Faut-il relancer tout le batch si une ligne JSONL échoue ?

Pas forcément. Outil JSONL pour le numéro de ligne, TICKET_SCHEMA pour enum, troncature ou syntaxe. Relancez seulement les lignes en échec.

Le schema local doit-il aussi avoir additionalProperties:false ?

Oui. Alignez le schema de requête Bedrock et TICKET_SCHEMA local—sinon API et ingest divergent.

Le streaming exige-t-il aussi des contrôles JSONL ?

Streaming : assembler une réponse puis Schema + Repair. JSONL seulement pour fichiers batch multi-lignes.

Conclusion

Bedrock enferme les réponses API Claude dans JSON Schema ; batch, streaming collé, journaux et collage déforment encore.

La décision : en ligne output_config Bedrock ; hors ligne le même TICKET_SCHEMA, Repair des fences, JSONL pour le batch.

Retour au blog