Context Window คืออะไร? เข้าใจ Token และหน้าต่างบริบทของ Claude แต่ละแผน 2569

Token คืออะไร — หน่วยที่โมเดลใช้นับข้อความ

ความเข้าใจเรื่อง Context Window ต้องเริ่มจากคำว่า Token เนื่องจากตัวเลขที่ประกาศทั้งหมด — 200K, 500K และ 1M — อ้างอิงหน่วย token ทั้งสิ้น ไม่ใช่จำนวนคำ ไม่ใช่จำนวนตัวอักษร และไม่ใช่จำนวนข้อความที่ส่งได้ต่อรอบ

Token คือหน่วยย่อยที่โมเดลใช้แทนข้อความ ซึ่งอาจเป็นคำเต็ม ส่วนของคำ ตัวอักษรเดี่ยว หรือไบต์ในกรณีของ Unicode เอกสารของ Anthropic ระบุหลักประมาณการไว้ว่า 1 token เทียบเท่าตัวอักษรภาษาอังกฤษประมาณ 3.5 ตัว พร้อมกำกับว่าตัวเลขจริงแปรผันตามภาษาที่ใช้ หลักนี้จึงเหมาะกับการประมาณการเบื้องต้น แต่ไม่เพียงพอสำหรับการจัดทำงบประมาณหรือข้อผูกพันตามสัญญา

ตัวเลขที่นำไปอ้างอิงได้ชัดเจนกว่า คือปริมาณ token ต่อเนื้อหาแต่ละประเภทที่ระบุไว้ในเอกสารของ Anthropic:

เนื้อหาที่นำเข้าสู่บริบท	ปริมาณ token โดยประมาณ	การเทียบเคียง
หน้าเว็บทั่วไป (~10 kB)	~2,500 tokens	บรรจุได้หลายร้อยหน้าในหน้าต่างขนาด 1M
หน้าคู่มือหรือเอกสารเทคนิคขนาดยาว (~100 kB)	~25,000 tokens	ประมาณ 8 ฉบับเต็มหน้าต่างขนาด 200K
ไฟล์ PDF งานวิจัย (~500 kB)	~125,000 tokens	ไฟล์เดียวใช้พื้นที่เกินครึ่งของหน้าต่าง 200K
หน้าต่างบริบทขนาด 200K tokens	—	ประมาณ 500 หน้าขึ้นไป ตามที่เอกสารศูนย์ช่วยเหลือระบุ
ค่าโสหุ้ย system prompt เมื่อเปิดใช้เครื่องมือ (ยังไม่รวมตัวคำนิยามเครื่องมือ)	~286–804 tokens	ถูกใช้ไปก่อนเริ่มบทสนทนา

# วัดจำนวน token ของข้อความจริง ก่อนส่งเข้าโมเดล
curl https://api.anthropic.com/v1/messages/count_tokens \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d '{
    "model": "claude-opus-5",
    "messages": [
      {"role": "user", "content": "ข้อความภาษาไทยที่ต้องการวัด..."}
    ]
  }'
# ผลลัพธ์: {"input_tokens": 42}

Context Window คืออะไร — พื้นที่ทำงานของโมเดล ไม่ใช่ความจำถาวร

เอกสารของ Anthropic นิยาม Context Window ว่าคือ ข้อความทั้งหมดที่โมเดลอ้างอิงได้ในขณะสร้างคำตอบ รวมถึงคำตอบที่กำลังถูกสร้างด้วย โดยเรียกสิ่งนี้ว่า "working memory" ของโมเดล ซึ่งแยกออกจากคลังข้อมูลขนาดใหญ่ที่ใช้ในการฝึกโมเดลอย่างชัดเจน

กล่าวอีกนัยหนึ่ง ความรู้ที่ได้จากการฝึกคือสิ่งที่โมเดลมีติดตัวอยู่แล้ว ส่วน Context Window คือพื้นที่ทำงานที่มีขอบเขตจำกัดสำหรับข้อมูลของงานตรงหน้า เมื่อพื้นที่เต็ม ข้อมูลส่วนแรกจะต้องถูกจัดการก่อนจึงจะรับข้อมูลใหม่ได้ และข้อมูลที่ไม่ได้อยู่ในพื้นที่นี้ โมเดลจะไม่สามารถอ้างอิงได้

ข้อเข้าใจคลาดเคลื่อนที่พบบ่อยคือการคิดว่าพื้นที่นี้บรรจุเฉพาะข้อความที่ผู้ใช้พิมพ์ ในความเป็นจริงทุกองค์ประกอบของคำขอถูกนับรวมทั้งหมด:

องค์ประกอบที่ใช้พื้นที่ใน Context Window	นับรวมหรือไม่	เหตุผลที่มักถูกมองข้าม
คำสั่งระบบ (system prompt)	นับรวม	ผู้ใช้ไม่เห็น แต่ถูกใช้พื้นที่ไปแล้ว
ทุกข้อความในบทสนทนา ทั้งของผู้ใช้และของโมเดล	นับรวม	ข้อความรอบก่อนหน้าสะสมต่อเนื่อง ไม่ถูกลบทิ้ง
เอกสารแนบ รูปภาพ และไฟล์ PDF	นับรวม	ไฟล์ขนาดใหญ่ไฟล์เดียวใช้พื้นที่ระดับแสน token
คำนิยามเครื่องมือและผลลัพธ์ที่เครื่องมือส่งกลับ	นับรวม	ยิ่งเชื่อมต่อระบบมาก พื้นที่ตั้งต้นยิ่งเหลือน้อย
กระบวนการให้เหตุผลของโมเดล (extended thinking)	นับรวม	การให้เหตุผลเชิงลึกมีต้นทุนทั้งพื้นที่และค่าใช้จ่าย
คำตอบที่กำลังถูกสร้าง (output)	นับรวม	ต้องสำรองพื้นที่สำหรับคำตอบ ไม่ใช่ใช้จนเต็มด้วยข้อมูลขาเข้า
ส่วนที่จัดเก็บไว้ด้วย prompt caching	นับรวม	แคชทำให้ต้นทุนลดลง แต่ไม่ได้ทำให้ไม่ถูกนับ

ขนาด Context Window ของ Claude แต่ละแผน (ข้อมูล ณ 4 กันยายน 2569)

เป็นคำถามที่พบบ่อยจากองค์กรที่กำลังพิจารณาเลือกแผน และเป็นประเด็นที่มักเกิดความเข้าใจคลาดเคลื่อน เนื่องจากคำตอบที่ถูกต้องคือ ขนาด Context Window เป็นคุณสมบัติของรุ่นโมเดล ไม่ใช่ของแผนที่จัดซื้อ แผนเป็นตัวกำหนดสิทธิ์การเข้าถึงรุ่นและปริมาณการใช้งาน ส่วนตัวเลข 200K / 500K / 1M มาจากรุ่นที่เลือกใช้ในขณะนั้น

แผน	บริบทในหน้าแชท	บริบทใน Claude Code	หมายเหตุ
Free	200K tokens	—	ตารางเปรียบเทียบบนหน้าราคาระบุ 200k
Pro	ขึ้นกับรุ่น สูงสุด 1M	สูงสุด 1M	รุ่นตระกูล Opus ต้องเปิดใช้ usage credits
Max	ขึ้นกับรุ่น สูงสุด 1M	สูงสุด 1M	ต่างจาก Pro ที่โควตาการใช้งาน ไม่ใช่ที่บริบท
Team	ขึ้นกับรุ่น สูงสุด 1M	สูงสุด 1M	Standard และ Premium ต่างกันที่ปริมาณการใช้งาน
Enterprise	500k บนรุ่นตั้งต้น	สูงสุด 1M	หน้าราคาระบุ "500k on default model"

ตัวเลขในตารางข้างต้นล้วนมีที่มาจากคุณสมบัติระดับรุ่นโมเดล เอกสารศูนย์ช่วยเหลือระบุว่า เมื่อใช้งานผ่านหน้าแชทบนแผนที่มีค่าใช้จ่าย Fable 5.1, Opus 5 และ Sonnet 5 รองรับบริบท 1M tokens ขณะที่ Opus 4.8, Opus 4.7, Opus 4.6 และ Sonnet 4.6 รองรับ 500K tokens และรุ่นอื่นนอกเหนือจากนี้อยู่ที่ 200K tokens ส่วนการเรียกใช้ผ่าน API ตัวเลขเป็นเอกภาพมากกว่า เนื่องจากคิดตามความสามารถของรุ่นโดยตรง ดังนี้:

รุ่นโมเดล	Context Window (ผ่าน API)	Output สูงสุดต่อคำขอ
Claude Fable 5.1 / Fable 5	1M tokens	128K tokens
Claude Opus 5 / Opus 4.8 / Opus 4.7 / Opus 4.6	1M tokens	128K tokens
Claude Sonnet 5 / Sonnet 4.6	1M tokens	128K tokens
Claude Sonnet 4.5	200K tokens	—
Claude Haiku 4.5	200K tokens	—

ตารางนี้เป็นตัวเลขสำหรับการเรียกใช้ผ่าน API — สำหรับการใช้งานผ่านหน้าแชทให้อ้างอิงตารางระดับแผนด้านบน · เอกสารระบุค่า output สูงสุด 128K tokens เฉพาะรุ่นที่มีหน้าต่างบริบทขนาด 1M ส่วนรุ่นที่มีหน้าต่าง 200K เอกสารไม่ได้ระบุไว้

ข้อเข้าใจคลาดเคลื่อนที่พบบ่อย 3 ประการ

1. Context Window ไม่ใช่ Usage Limit

ทั้งสองเป็นข้อจำกัดคนละประเภท Context window กำหนดว่าบทสนทนาหนึ่งบรรจุข้อมูลได้เท่าใด ส่วน usage limit กำหนดปริมาณการใช้งานต่อรอบเวลา โดย Claude คำนวณเป็นรอบ 5 ชั่วโมงและมีเพดานรายสัปดาห์ประกอบ การปรับจาก Pro เป็น Max โดยหลักจึงเป็นการเพิ่มโควตาการใช้งาน ไม่ใช่การขยายพื้นที่บริบท องค์กรที่เข้าใจสองเรื่องนี้สลับกัน มักประเมินผลลัพธ์ของการอัปเกรดคลาดเคลื่อน รายละเอียดโควตาของแต่ละแผนอยู่ใน บทความเปรียบเทียบ Limit ทุก Plan ของ Claude

2. Token ไม่ใช่คำ และหน้าต่าง 1M ของแต่ละรุ่นบรรจุเนื้อหาได้ไม่เท่ากัน

เอกสารด้านราคาระบุว่า Claude รุ่น 4.7 เป็นต้นไปใช้ tokenizer ชุดใหม่ ซึ่งผลิต token มากกว่าเดิมประมาณ 30% สำหรับข้อความชุดเดียวกัน โดยเอกสารกำกับไว้ว่าอัตราที่เพิ่มขึ้นจริงขึ้นอยู่กับลักษณะเนื้อหาและรูปแบบงาน ผลที่ตามมาคือหน้าต่างบริบท 1M ของ Opus 4.7 ขึ้นไป บรรจุเนื้อหาได้น้อยกว่าหน้าต่าง 1M ของ Sonnet 4.6 แม้ตัวเลขที่ประกาศจะเท่ากัน ด้วยเหตุนี้ การเปลี่ยนรุ่นโมเดลจึงควรวัดปริมาณ token ใหม่ทุกครั้ง แทนการนำตัวเลขเดิมมาใช้ต่อ (ดูรายละเอียดการเปลี่ยนแปลงระดับรุ่นได้ใน บทความเปิดตัว Claude Opus 5)

3. หน้าต่างบริบทที่ใหญ่ขึ้นไม่ได้ให้คำตอบที่ดีขึ้นเสมอไป

เอกสารของ Anthropic ระบุไว้โดยตรงว่า "more context isn't automatically better" เมื่อจำนวน token เพิ่มขึ้น ความแม่นยำและความสามารถในการดึงข้อมูลกลับมาใช้จะลดลง ปรากฏการณ์นี้เรียกว่า context rot การคัดเลือกข้อมูลที่จะนำเข้าสู่บริบทจึงมีความสำคัญไม่น้อยไปกว่าขนาดของพื้นที่ ในทางปฏิบัติ การแนบเอกสารจำนวนมากโดยไม่คัดกรองมักให้ผลลัพธ์ด้อยกว่าการแนบเฉพาะเอกสารที่เกี่ยวข้องโดยตรง

เมื่อบทสนทนาถึงขีดจำกัด

ในแอปพลิเคชันของ Claude ระบบจะจัดการบริบทโดยอัตโนมัติเมื่อบทสนทนาเข้าใกล้ขีดจำกัด ด้วยการสรุปย่อข้อความช่วงต้นเพื่อให้สนทนาต่อได้ เอกสารระบุว่ากระบวนการนี้ไม่ถูกนับรวมในโควตาการใช้งาน และประวัติบทสนทนาฉบับเต็มยังคงเรียกดูย้อนหลังได้ตามปกติ

การทำงานฝั่ง API แตกต่างออกไป หากข้อมูลขาเข้าเกินขนาดหน้าต่างบริบทตั้งแต่ต้น ระบบจะตอบกลับเป็นข้อผิดพลาด "prompt is too long" ส่วนกรณีที่เริ่มสร้างคำตอบแล้วถึงขีดจำกัดระหว่างทาง โมเดลรุ่น 4.5 ขึ้นไปจะหยุดพร้อมสถานะ model_context_window_exceeded เพื่อให้แอปพลิเคชันจัดการต่อได้ สำหรับงานที่ทำงานต่อเนื่องเป็นเวลานาน แนะนำให้ใช้ compaction ฝั่งเซิร์ฟเวอร์ แทนการปล่อยให้คำขอถึงขีดจำกัด

สำหรับผู้ใช้งานในองค์กร แนวปฏิบัติที่ช่วยควบคุมบริบทได้อย่างมีประสิทธิผลมีดังนี้:

• เริ่มบทสนทนาใหม่เมื่อเปลี่ยนหัวข้อ — ประวัติที่ไม่เกี่ยวข้องใช้พื้นที่โดยไม่เพิ่มคุณภาพของคำตอบ
• จัดเก็บเอกสารอ้างอิงประจำไว้ใน Projects แทนการแนบไฟล์ซ้ำในทุกบทสนทนา (ดู Claude Projects และ Knowledge)
• แนบเฉพาะส่วนที่เกี่ยวข้อง — การคัดเฉพาะหน้าที่ต้องใช้จากเอกสารขนาดใหญ่ให้ผลดีกว่าการแนบทั้งฉบับ
• ให้ระบบเรียกข้อมูลตามคำถาม แทนการนำข้อมูลทั้งชุดใส่เข้าไป — ผ่าน MCP หรือกระบวนการ retrieval
• เลือกรุ่นโมเดลให้สอดคล้องกับลักษณะงาน — งานสรุปความขนาดสั้นไม่จำเป็นต้องใช้หน้าต่างบริบทขนาด 1M

ข้อพิจารณาสำหรับองค์กรที่ใช้ระบบ ERP

รูปแบบที่พบบ่อยในองค์กรคือความต้องการให้ระบบ AI ช่วยวิเคราะห์ข้อมูลจัดซื้อทั้งปี แล้วดำเนินการด้วยการส่งออกข้อมูลทั้งชุดเป็นไฟล์ Excel เพื่อแนบเข้าบทสนทนา แนวทางนี้มีต้นทุนสูงที่สุดและให้ความแม่นยำต่ำที่สุดในบรรดาทางเลือกทั้งหมด เนื่องจากข้อมูลดิบทั้งปีใช้ token จำนวนมาก และบริบทที่ยาวขึ้นส่งผลให้ความแม่นยำลดลง

แนวทางที่เหมาะสมกว่าคือการกำหนดให้ระบบ ERP เป็นแหล่งข้อมูลอ้างอิงเพียงแหล่งเดียว และให้ระบบ AI เรียกใช้เฉพาะข้อมูลที่จำเป็นต่อการตอบคำถามนั้น ผ่านการเชื่อมต่อที่มีการควบคุมสิทธิ์ ซึ่งเป็นวัตถุประสงค์ของการออกแบบ Model Context Protocol (MCP) โดยตรง

Saeree ERP ให้บริการ MCP integration สำหรับเชื่อมระบบ ERP เข้ากับ Claude โดยขอบเขตของบริการประกอบด้วย:

• การเรียกข้อมูลจริงจากระบบ ERP มาใช้ตอบคำถาม — ครอบคลุมงานจัดซื้อ คลังพัสดุ งานบุคคล และงานเอกสาร ผู้ใช้สอบถามด้วยภาษาธรรมชาติ ระบบจะอ่านข้อมูลจากฐานข้อมูลมาประกอบคำตอบ โดยไม่ต้องส่งออกไฟล์มาแนบในบทสนทนา
• การควบคุมสิทธิ์ตามบทบาทผู้ใช้เดิมของระบบ ERP — ผู้ใช้เข้าถึงข้อมูลผ่าน AI ได้ในขอบเขตเดียวกับที่เข้าถึงได้ในระบบ ไม่มีการเปิดข้อมูลเกินสิทธิ์
• การบันทึก audit trail ทุกครั้งที่มีการเรียกข้อมูล — ตรวจสอบย้อนหลังได้ว่าผู้ใช้รายใดสอบถามเรื่องใด และระบบเรียกข้อมูลชุดใดมาประกอบคำตอบ
• การทำงานร่วมกับระบบ ERP ที่ติดตั้งบนเซิร์ฟเวอร์ขององค์กร — ข้อมูลไม่จำเป็นต้องถูกคัดลอกออกไปจัดเก็บที่อื่นเพื่อให้ระบบ AI เข้าถึง

ผลลัพธ์ในทางปฏิบัติคือบริบทที่ส่งให้โมเดลประกอบด้วยเฉพาะข้อมูลที่เกี่ยวข้องกับคำถามนั้น ซึ่งมีต้นทุนต่ำกว่าและให้ความแม่นยำสูงกว่าการนำข้อมูลทั้งปีเข้าสู่บทสนทนา

การเลือกระหว่างบริบทขนาดใหญ่กับการเรียกข้อมูลเฉพาะจุด

ลักษณะงาน	ใช้บริบทขนาดใหญ่	ใช้ retrieval หรือ MCP
วิเคราะห์สัญญาฉบับเดียวความยาว 200 หน้า	เหมาะสม	ไม่จำเป็น
ตรวจทานซอร์สโค้ดทั้ง repository ในครั้งเดียว	เหมาะสม	ไม่จำเป็น
สอบถามยอดคงเหลือพัสดุรายการใดรายการหนึ่ง	ไม่เหมาะสม	เหมาะสม — เรียกเฉพาะรายการที่เกี่ยวข้อง
ค้นหาระเบียบปฏิบัติจากคู่มือ 40 ฉบับ	ไม่เหมาะสม	เหมาะสม — สืบค้นก่อน แล้วส่งเฉพาะส่วนที่ตรง
งานประจำวันที่อ้างอิงเอกสารชุดเดิม	ไม่คุ้มค่า	เหมาะสม — ลดทั้งต้นทุน token และเวลา

สำหรับทีมที่ยังไม่คุ้นเคยกับคำศัพท์ที่เกี่ยวข้อง เช่น token, prompt, RAG หรือ agent สามารถศึกษาเพิ่มเติมได้จาก AI Glossary สำหรับองค์กรไทย ซึ่งรวบรวมคำศัพท์ที่ใช้บ่อยไว้ในที่เดียว

"การออกแบบบริบทที่ดีไม่ได้วัดจากปริมาณข้อมูลที่ใส่เข้าไปได้ แต่วัดจากความแม่นยำในการคัดเลือกว่าข้อมูลใดจำเป็นต่อคำตอบนั้น"

- ทีม Saeree ERP

แหล่งอ้างอิง

• Anthropic — Context windows (คู่มือนักพัฒนา)
• Anthropic Support — How large is the context window on paid Claude plans?
• Claude Pricing — ตารางเปรียบเทียบแผน
• Anthropic — Pricing (long context pricing, หมายเหตุ tokenizer ใหม่)
• Anthropic — Glossary (นิยาม Tokens และ Context window)
• Anthropic — Token counting API

ข้อมูลทั้งหมดตรวจสอบเมื่อ 4 กันยายน 2569 — ขนาด context window และรายละเอียดแผนเปลี่ยนแปลงได้ตลอด ควรตรวจสอบกับแหล่งทางการก่อนตัดสินใจ