บทที่ 56: Structured Outputs ให้ AI ตอบเป็น JSON

ใน บทที่ 2 Input Process Output เราเห็นว่ารูปแบบ Output เปลี่ยนคุณภาพงาน ใน บทที่ 21 API & MCP เราเชื่อม AI เข้ากับบริการอื่น และใน บทที่ 25 เขียนคำสั่งให้ AI ทำได้ตรงใจ เราระบุ Output Format ไว้ใน Prompt

แต่ถ้าโปรแกรมต้องเอาคำตอบไปใช้ต่อ คำว่า “ช่วยตอบเป็น JSON” ยังไม่ใช่ Contract ที่แข็งแรงพอ เพราะ Prompt อย่างเดียวอาจได้ JSON ที่พิมพ์ผิด ขาดช่อง หรือใช้ชนิดข้อมูลไม่ตรง เอกสาร Claude จึงมี Structured outputs สำหรับจำกัดคำตอบให้เป็นไปตาม Schema และอ่านต่อได้.[1]

คำตอบที่คนอ่านรู้เรื่อง อาจยังเป็นข้อมูลที่ระบบใช้ต่อไม่ได้

สไลด์ 1 — คำตอบสวย แต่ระบบอ่านต่อไม่ได้

สมมติร้านให้ AI อ่านแชตลูกค้าแล้วส่งผลเข้า CRM

คำตอบภาษาคน

ลูกค้าสนใจแพ็กเกจธุรกิจ ดูค่อนข้างรีบ ควรให้ทีมขายติดต่อกลับ

คนอ่านเข้าใจ แต่โปรแกรมยังต้องเดาว่า “สนใจอะไร”, “รีบระดับไหน” และ “ต้องส่งให้คนหรือไม่” ถ้ารูปประโยคหรือ JSON เปลี่ยนไป ตัว Parser ที่เขียนไว้ก็อาจพัง.[1]

คำตอบที่มีโครงสร้าง

{
  "intent": "buy",
  "urgency": "high",
  "needs_human": true,
  "reason": "ขอให้ทีมขายติดต่อกลับ"
}

Structured outputs ใช้ Constrained decoding เพื่อบังคับให้ Response ตรง Schema แทนการหวังว่าโมเดลจะทำตามคำขอเรื่องรูปแบบทุกครั้ง.[1]

งานอัตโนมัติไม่ได้ต้องการคำตอบสวยอย่างเดียว แต่ต้องอ่านต่อได้แน่นอน

สไลด์ 2 — ศัพท์ 5 คำที่ต้องรู้

• JSON — รูปแบบข้อความที่เก็บข้อมูลเป็นชื่อช่องและค่า โปรแกรมหลายภาษาอ่านได้
• JSON Schema — สัญญาที่บอกโครงสร้าง ชนิดข้อมูล ช่องที่ต้องมี และข้อจำกัดของ JSON; เว็บไซต์ JSON Schema อธิบายว่าเป็นมาตรฐานสำหรับกำหนด Structure และ Rules ของข้อมูล JSON.[3]
• Structured Output — คำตอบที่ถูกจำกัดให้ตรง Schema ที่กำหนด.[1]
• Validation — การตรวจว่าข้อมูลผ่านกติกาหรือไม่
• Business Rule — กฎของธุรกิจที่ Schema อย่างเดียวตอบไม่ได้ เช่น Order นี้มีอยู่จริงหรือสถานะนี้เปลี่ยนต่อได้หรือไม่

Schema ตรวจ “รูปทรงของข้อมูล” ส่วน Business Rule ตรวจ “ข้อมูลนี้ใช้ได้จริงกับระบบของเราหรือไม่” ต้องมีทั้งสองชั้น

รูปทรงถูก ไม่ได้แปลว่าเรื่องข้างในถูก

สไลด์ 3 — Prompt ไม่เท่ากับ Contract

การเขียนใน Prompt ว่า

ตอบเป็น JSON และอย่าลืมใส่ intent กับ urgency

ช่วยบอกความต้องการ แต่ยังอาศัยการทำตามคำสั่งของโมเดล เอกสาร Claude ระบุว่าเมื่อไม่มี Structured outputs ยังอาจพบ JSON syntax ผิด ช่อง Required หาย ชนิดข้อมูลไม่ตรง หรือ Schema violation ได้.[1]

Contract ที่ชัดกว่าคือส่ง JSON Schema ไปพร้อม Request แล้วให้ระบบจำกัด Output ตาม Schema นั้น เอกสารปัจจุบันใช้ output_config.format สำหรับ JSON outputs และใช้ strict: true เมื่อต้องการบังคับชื่อและ Input ของ Tool.[1]

สองอย่างนี้ใช้แยกกันได้

• อยากได้คำตอบ JSON กลับมา — ใช้ JSON outputs
• อยากให้ Claude เรียก Tool ด้วย Input ที่ตรง Schema — ใช้ Strict tool use

อย่าขอรูปแบบ จงกำหนดสัญญา

สไลด์ 4 — ออกแบบ Schema จากการตัดสินใจ

อย่าเริ่มด้วยคำถามว่า “อยากให้ JSON หน้าตาสวยแบบไหน” ให้เริ่มจากคำถามว่า ระบบต้องตัดสินใจอะไรต่อ

ตัวอย่างระบบคัดแชตลูกค้า เป้าหมายคือเลือกว่าจะตอบอัตโนมัติหรือส่งให้ทีมขาย จึงต้องมีข้อมูลเท่าที่การตัดสินใจใช้

ถ้ามีช่องที่ “เผื่อไว้ก่อน” แต่ไม่มีขั้นตอนไหนใช้ ให้ตัดออก เพราะทุกช่องเพิ่มความซับซ้อนให้ Prompt, Schema, Log และระบบปลายทาง

เริ่มจากการตัดสินใจ แล้วค่อยออกแบบข้อมูล

สไลด์ 5 — ล็อก Type · Required · Enum · No Extra

Schema ที่ดีไม่ใช่แค่ลิสต์ชื่อช่อง ต้องลดพื้นที่ที่ระบบต้องเดา

{
  "type": "object",
  "properties": {
    "intent": { "type": "string", "enum": ["buy", "question", "complaint", "unknown"] },
    "urgency": { "type": "string", "enum": ["low", "normal", "high"] },
    "needs_human": { "type": "boolean" },
    "reason": { "type": "string" }
  },
  "required": ["intent", "urgency", "needs_human", "reason"],
  "additionalProperties": false
}

• Type ล็อกชนิดข้อมูล เช่น String หรือ Boolean
• Required ระบุช่องที่ขาดไม่ได้
• Enum จำกัดคำตอบให้อยู่ในชุดที่ระบบรองรับ
• No Extra กันช่องใหม่ที่ระบบปลายทางไม่รู้จัก

ควรมีค่า unknown เมื่อหลักฐานไม่พอ ดีกว่าบังคับให้ AI เดาเข้าหมวดใดหมวดหนึ่ง

สำหรับ enum และ const เอกสาร Claude มีข้อควรระวังว่า Output อาจต่างจากค่าที่กำหนดเฉพาะตัวพิมพ์ใหญ่–เล็ก และจบด้วย Stop reason ปกติได้.[1] ถ้าใช้ค่าเครื่องแบบ buy, question, complaint, unknown ให้กำหนด Casing เดียว แล้วทำ Canonicalization ตาม Mapping ที่เราควบคุมก่อนตรวจ Allowlist ซ้ำ ห้ามรับค่าที่คล้ายกันโดยอัตโนมัติ

เอกสาร Claude รองรับ JSON Schema มาตรฐานแบบมีข้อจำกัด จึงต้องตรวจ Feature ที่ Provider และ Model ปัจจุบันรองรับก่อนใช้ Schema ซับซ้อน.[1]

ยิ่งกำกวม ระบบยิ่งต้องเดา

สไลด์ 6 — Claude มี 2 ทางให้โครงสร้างนิ่ง

JSON outputs — คุมคำตอบที่ส่งกลับ

Request ใส่ output_config.format โดยใช้ชนิด json_schema และแนบ Schema ที่ต้องการ คำตอบจะกลับมาใน Text content block เป็น JSON ตาม Schema.[1]

output_config.format
  type: json_schema
  schema: LEAD_SCHEMA

Strict tool use — คุม Input ตอนเรียกเครื่องมือ

Tool แต่ละตัวมี input_schema และเปิด strict: true เพื่อบังคับให้ชื่อ Tool กับ Input ผ่าน Schema ก่อนส่งให้ระบบของเรา.[1]

tools[]
  name: save_lead
  strict: true
  input_schema: LEAD_SCHEMA

อย่าใช้ Tool call แทน JSON output โดยไม่จำเป็น เลือกตามปลายทางว่าเราต้องการ ข้อมูลกลับมา หรือ การเรียกความสามารถ

คำตอบใช้ JSON Output · เรียกเครื่องมือใช้ Strict Tool

สไลด์ 7 — ตรวจ 2 ชั้นก่อนให้เกิด Action

Structured outputs ช่วยให้คำตอบตรง Schema ที่กำหนด.[1] แต่ไม่ได้ตรวจว่าข้อมูลตรงกับฐานข้อมูลหรือกฎธุรกิจของเรา

ชั้น 1: Schema Validation

ตรวจว่า JSON อ่านได้ ช่องครบ Type ถูก และค่าอยู่ในชุดที่กำหนด ระบบ Claude ช่วยรับประกันส่วนนี้ผ่าน Constrained decoding ในกรณีปกติ.[1]

ชั้น 2: Business Validation

ตรวจต่อกับของจริง เช่น

• Customer หรือ Order ID มีอยู่จริง
• ผู้ใช้มีสิทธิ์ทำ Action นี้
• สถานะปัจจุบันอนุญาตให้เปลี่ยนไปสถานะใหม่
• จำนวนเงินและสกุลเงินตรงกับ Record ต้นทาง
• งานเสี่ยงต้องผ่าน Owner approval

ถ้า Schema ผ่านแต่ Business Rule ไม่ผ่าน ให้หยุดและรายงาน ไม่ใช่แก้ค่าขึ้นมาเองเพื่อให้ผ่าน

โครงสร้างผ่าน แล้วต้องผ่านโลกจริงด้วย

สไลด์ 8 — ข้อมูลไม่ครบ ต้องหยุด

Structured outputs มีข้อยกเว้นสำคัญสามแบบคือ Refusal, max_tokens และ Enum casing.[1] นอกจากนี้ระบบยังต้องแยก API error หรือ Timeout ออกจาก Success ก่อนเกิด Action

stop_reason: "refusal"

Claude อาจปฏิเสธด้วยเหตุผลด้านความปลอดภัย แม้ HTTP status เป็น 200 และข้อความปฏิเสธอาจไม่ตรง Schema.[1] ให้แยกเส้นทางนี้ออกจาก Success และส่งต่อให้คนพิจารณา

stop_reason: "max_tokens"

max_tokens คือเพดานสูงสุดของจำนวน Token ที่สร้างก่อนหยุด.[2] ถ้าชนเพดาน Output อาจขาดและไม่ตรง Schema ให้ Retry ด้วยเพดานที่เหมาะสม โดยต้องไม่ทำ Action เดิมซ้ำ

Enum value casing

ค่า enum หรือ const อาจต่างเฉพาะตัวพิมพ์ใหญ่–เล็กโดยไม่มี Error หรือ Stop reason พิเศษ.[1] ให้แปลงด้วย Mapping ที่กำหนดไว้ แล้วตรวจ Allowlist อีกครั้ง ถ้าจับคู่ไม่ได้ต้องหยุด ไม่ใช่เดาค่าที่ใกล้ที่สุด

API error หรือ Timeout

เก็บ Request ID/Task ID แล้ว Retry แบบ Idempotent ถ้าไม่รู้ว่า Action เกิดไปแล้วหรือยัง ให้ตรวจสถานะก่อน ห้ามส่งซ้ำแบบเดา

ข้อมูลไม่ครบ = ห้ามข้ามไปทำจริง

สไลด์ 9 — Safe Flow จากข้อความไปสู่ Action

Flow ที่ปลอดภัยมีลำดับเดียว

INPUT
→ CLAUDE + SCHEMA
→ STOP_REASON OK?
→ SCHEMA VALID?
→ BUSINESS VALID?
→ OWNER APPROVAL
→ ACTION

ลูกศร PASS เดินไป Gate ถัดไป ส่วนทางออกเมื่อ Gate ใดไม่ผ่านคือ

FAIL → STOP + REPORT → RETRY / HUMAN

อย่าต่อ Output จากโมเดลเข้าฐานข้อมูล การคืนเงิน การส่งข้อความลูกค้า หรือ Production โดยตรง แม้ JSON จะ Parse ได้ เพราะ Parse สำเร็จพิสูจน์เพียงว่ารูปแบบอ่านได้ ไม่ได้พิสูจน์สิทธิ์ ความจริง หรือความเหมาะสมของ Action

ลองทำเลย

เลือกงานที่ต้องอ่านคำตอบ AI ไปทำต่อหนึ่งงาน เช่นคัด Lead หรือจัดหมวด Ticket แล้วทำตามนี้

1. เขียนการตัดสินใจปลายทางหนึ่งประโยค 2. สร้าง Schema เฉพาะช่องที่การตัดสินใจใช้ 3. ใส่ unknown และ needs_human เป็นทางออกเมื่อหลักฐานไม่พอ 4. ทดสอบอย่างน้อยกับ Input ปกติ, ช่องว่าง, ข้อความกำกวม และข้อความที่ควรส่งต่อคน 5. จำลอง refusal, max_tokens และ Timeout แล้วตรวจว่าไม่มี Action หลุดออกไป

โครงสร้างผ่าน · กฎธุรกิจผ่าน · ค่อยลงมือ

เช็คลิสต์ท้ายบท

• แยก Prompt request ออกจาก Schema contract ได้
• ออกแบบ Schema จากการตัดสินใจปลายทาง
• ใช้ Type, Required, Enum และ additionalProperties เท่าที่ Provider รองรับ
• มีค่า unknown หรือเส้นทางส่งต่อคนเมื่อหลักฐานไม่พอ
• เลือกถูกว่าจะใช้ JSON outputs หรือ Strict tool use
• ตรวจ stop_reason ก่อน Parse หรือทำ Action
• แยก Schema Validation ออกจาก Business Validation
• Retry แบบไม่ทำ Action ซ้ำ
• งานเสี่ยงมี Owner approval ก่อนทำจริง

Sources

[1] https://platform.claude.com/docs/en/build-with-claude/structured-outputs — Claude structured outputs [2] https://platform.claude.com/docs/en/api/messages — Claude Messages API [3] https://json-schema.org/overview/what-is-jsonschema — What is JSON Schema?