ブログ • AWS / Bedrock

Amazon Bedrock の Claude 構造化出力は JSON の形を保証するのに、バッチログやコピーしたチャットではなぜローカル三段階チェックが要るか？

2026年10月19日、AWS は Bedrock の Claude で構造化出力を発表。推論時に JSON Schema で制約付きデコード、output_config で schema、strict ツール、additionalProperties:false。バッチとストリーミングも対象。

Structured Output の比較は2026 構造化出力ガイド。schema が合法でも権限は別問題、Agent schema 不足の記事。JSON Schema の共用はAI が JSON Schema を要する理由。本記事は Bedrock 後のローカル三段階だけを書く。

• Bedrock リクエストは output_config.format に JSON Schema を付け、additionalProperties:false を置く。
• API が保証するのは 1 回の Invoke 応答の形であり、ログ・バッチ出力・コンソールコピーではない。
• ローカル手順：(1) JSON Schema 検証、(2) markdown 囲み除去後に JSON 修復、(3) バッチ JSONL の行チェック。
• 同じ TICKET_SCHEMA で API サンプル・ログ行・バッチ行を検証し、enum 誤り・欠落・余分なキーをローカルで止める。

10月19日 Bedrock が Claude に何を足したか？

AWS は公式 What's New：Bedrock の Claude で構造化出力、制約付きデコード、strict ツール、バッチ・ストリーミング。

技術詳細はAWS Machine Learning ブログ。API 保証をログ管道の終点にしない。

output_config に JSON Schema をどう付けるか？

Bedrock は output_config.format.type を json_schema にし、schema にオブジェクト定義を置く。ルートに additionalProperties:false。下の例は 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 }
        }
      }
    }
  }
}

バッチは JSONL で 1 行 1 レコードになりがち。ストリーミングはクライアント結合後にチケットへ貼られる。それらは Bedrock デコーダで再検証されない。

API が形を保証するのに、なぜローカル検証か？

Invoke 応答は Bedrock 側で schema 形だが、保存物は変形する。ログ接頭、CloudWatch エスケープ、Playground の ```json 囲み、バッチの空行・切断行。

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

priority が urgent や owner が増えると SLA が誤動作する。SAMPLE_BAD は enum 逸脱—同じ TICKET_SCHEMA で止める。

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

ローカル検証用の TICKET_SCHEMA は？

JSON Schema でフィールドと enum を固定。priority は low/medium/high のみ。additionalProperties:false で未宣言キーを拒否。通過は形が合法なことだけを意味する。

{
  "$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
    }
  }
}

ローカル三段階は何を直すか？

Bedrock をオンラインデコーダ、JSONNote をオフライン検品台とする。順序：schema 適合→囲み修復→JSONL 行検査。

JSONNote で三段階をどう回すか？

1. 1
   第一段階：Schema 検証

   JSON Schema。1欄に TICKET_SCHEMA、2欄に SAMPLE_OK かログ JSON。enum・欠落・余分なキーを即表示。

2. 2
   第二段階：囲み修復

   JSON 修復。```json 付きチャットを貼り、囲み除去後に再検証。

3. 3
   第三段階：JSONL 行チェック

   JSONL ツール。Bedrock バッチを上げ、各行 parse を確認。壊行は TICKET_SCHEMA で enum か切断か特定。

よくある質問

Bedrock 構造化出力でローカル検証を省略できるか？

いいえ。API はその Invoke の応答だけ。ログ・バッチ・コピー・キャッシュは同じ schema で再検証が要る。

strict ツールと output_config schema の関係は？

どちらも JSON Schema で token を制約するが層が違う。ツール引数は tool schema、最終テキストは output_config。ローカルでは schema を分けて保存する。

JSONL の 1 行失敗でバッチ全体を再実行するか？

必ずしも全体再実行は不要。JSONL ツールで行番号、TICKET_SCHEMA で enum・切断・文法を見る。失敗行だけ再試行する。

ローカル schema にも additionalProperties:false を書くか？

はい。Bedrock リクエスト schema とローカル TICKET_SCHEMA を一致させる。ずれると API 通過と入库拒否が食い違う。

ストリーミングも JSONL チェックが要るか？

ストリーミングは 1 本に結合後 Schema と Repair。JSONL はバッチが複数行ファイルのときだけ。

まとめ

Bedrock 構造化出力は API 応答を JSON Schema に閉じ込める。バッチ・ストリーミング結合・ログ・貼り付けは形を壊す。

結論：オンラインは Bedrock output_config、オフラインは同じ TICKET_SCHEMA で検証、Repair で囲み除去、JSONL でバッチ行。

ブログへ戻る