MCP เวอร์ชัน 2026-07-28: มาตรฐานเชื่อม AI เข้าระบบองค์กร เปลี่ยนเป็น Stateless แล้ว

MCP คืออะไร อธิบายแบบไม่ใช้ศัพท์

ก่อนจะพูดถึงสเปกใหม่ ต้องเข้าใจปัญหาที่ MCP เกิดมาเพื่อแก้ก่อน สมมติองค์กรหนึ่งมีระบบบัญชี ระบบคลังสินค้า ระบบ HR และระบบจัดซื้อ แล้วอยากให้ผู้ช่วย AI ตอบคำถามอย่าง "ยอดค้างชำระของลูกค้ารายนี้เท่าไร" ได้ ในโลกก่อนมี MCP ทีมพัฒนาต้องเขียนตัวเชื่อมแยกทีละคู่ — AI ตัวนี้กับระบบนี้ AI อีกตัวกับระบบเดิม เปลี่ยนผู้ให้บริการ AI ทีก็ต้องรื้อใหม่

MCP เข้ามาทำหน้าที่เหมือน "ปลั๊กมาตรฐาน" ระบบธุรกิจฝั่งหนึ่งเปิดสิ่งที่เรียกว่า MCP server ประกาศออกมาว่าตัวเองมีเครื่องมือ (tools) อะไรให้เรียกใช้บ้าง เช่น ค้นหาใบแจ้งหนี้ ดูยอดคงเหลือ ขณะที่ฝั่ง AI ทำตัวเป็น MCP client ที่รู้จักวิธีอ่านรายการเครื่องมือและเรียกใช้ตามมาตรฐานเดียวกัน ผลคือเขียนตัวเชื่อมครั้งเดียว ใช้ได้กับ AI หลายเจ้า ซึ่งเป็นเหตุผลที่โปรโตคอลนี้แพร่หลายเร็วมากในกลุ่มองค์กรที่ทำ ระบบ AI แบบ Agentic รายละเอียดพื้นฐานของโปรโตคอลและตัวอย่างการตั้งค่าอ่านเพิ่มได้ในบทความ การใช้ MCP กับ Claude

การเปลี่ยนแปลงที่ใหญ่ที่สุด: ตัด session ออกทั้งหมด

ในสเปกรุ่นก่อน การคุยกันระหว่าง client กับ server ต้องเริ่มด้วยขั้นตอน initialize handshake คือทักทายกันก่อนเพื่อตกลงว่าจะใช้โปรโตคอลรุ่นไหน แล้ว server จะออกรหัสประจำการเชื่อมต่อกลับมา ทุกคำสั่งหลังจากนั้นต้องแนบรหัสนั้นไปด้วยผ่านหัวข้อความ Mcp-Session-Id เพื่อให้ server รู้ว่า "นี่คือคนเดิมที่เพิ่งคุยกันไป"

วิธีนี้ทำงานได้ดีตอนที่ MCP server รันอยู่บนเครื่องเดียว แต่พอต้องรองรับผู้ใช้หลายร้อยคน ปัญหาก็โผล่ทันที เพราะ server ต้องจำสถานะของทุกการเชื่อมต่อไว้ ถ้ามีหลายเครื่องหลัง load balancer แล้วคำขอถัดไปถูกส่งไปเครื่องอื่นที่ไม่รู้จักรหัสนั้น การเชื่อมต่อก็พัง ทางแก้เดิมคือบังคับให้คำขอของผู้ใช้คนเดียวกันวิ่งไปเครื่องเดิมเสมอ (sticky session) หรือมีที่เก็บสถานะร่วมกัน ทั้งสองทางเพิ่มความซับซ้อน

สเปกฉบับ 2026-07-28 ตัดปมนี้ทิ้ง โดยเอา initialize handshake และ Mcp-Session-Id ออก ทุกคำขอกลายเป็นข้อความที่สมบูรณ์ในตัวเอง (self-contained) — พกข้อมูลที่จำเป็นไปครบในครั้งเดียว ผลคือ MCP server ก็เป็นแค่บริการ HTTP ธรรมดาตัวหนึ่ง ที่กระจายโหลดแบบ round-robin ได้ทันที เพิ่มหรือลดจำนวนเครื่องได้อิสระ และรีสตาร์ตเครื่องหนึ่งโดยไม่ทำให้ใครหลุด

ภาพคร่าว ๆ ของคำขอเรียกใช้เครื่องมือ (ตัวอย่างเชิงอธิบาย ไม่ใช่สเปกฉบับเต็ม):

POST /mcp
Content-Type: application/json
Authorization: Bearer <access_token>
# รุ่นเดิมต้องแนบ Mcp-Session-Id ที่ได้จาก initialize มาด้วย
# รุ่น 2026-07-28 ไม่มีบรรทัดนั้นแล้ว — คำขอสมบูรณ์ในตัวเอง

{
  "jsonrpc": "2.0",
  "id": 42,
  "method": "tools/call",
  "params": {
    "name": "search_invoices",
    "arguments": { "customer": "ACME", "status": "open" }
  }
}

Enterprise-Managed Authorization: ฝ่าย IT ได้คุมสิทธิ์จากศูนย์กลาง

อีกครึ่งหนึ่งของเรื่องนี้คือการยืนยันสิทธิ์ ปัญหาที่องค์กรบ่นมาตลอดคือ พนักงานคนหนึ่งเปิดเครื่องมือ AI บนเครื่องตัวเอง แล้วเชื่อม MCP server ของบริการภายนอกเข้าไปเองได้ โดยฝ่าย IT ไม่รู้เลยว่ามีการเชื่อมต่อนั้นอยู่ นี่คือรูปแบบเดียวกับ shadow IT ที่เคยเกิดกับบริการคลาวด์เมื่อสิบปีก่อน เพียงแต่รอบนี้ปลายทางที่เชื่อมคือระบบที่เก็บข้อมูลธุรกิจจริง

Enterprise-Managed Authorization (EMA) ซึ่งขึ้นสถานะ stable เมื่อ 6 กรกฎาคม 2569 เข้ามาอุดช่องนี้ แนวคิดคือย้ายการอนุมัติจาก "ผู้ใช้กดยอมรับเอง" ไปเป็น "องค์กรกำหนดไว้ล่วงหน้าที่ระบบยืนยันตัวตนกลาง" องค์กรจึงบอกได้ว่าพนักงานกลุ่มใดเชื่อม MCP server ใดได้บ้าง และเมื่อพนักงานลาออก การถอนสิทธิ์ที่ระบบกลางก็ตัดการเชื่อมต่อทั้งหมดพร้อมกัน โดยมีผู้พัฒนาระบบยืนยันตัวตนและผู้ให้บริการ AI รายใหญ่ทั้ง Anthropic, Microsoft และ Okta ร่วมนำไปใช้จริงตั้งแต่ต้น

สเปกฉบับนี้ยังรวมข้อเสนอด้านสิทธิ์ (SEP) ไว้ 6 ฉบับ ทั้งหมดปรับให้เข้ากับมาตรฐานที่โลกใช้อยู่แล้วคือ OAuth 2.0 และ OpenID Connect แทนที่จะประดิษฐ์กลไกเฉพาะของ MCP ขึ้นมาใหม่ จุดหนึ่งที่ชัดเจนคือการบังคับให้ตรวจสอบค่า iss ซึ่งเป็นตัวระบุว่าใครเป็นผู้ออกโทเคน ตามข้อกำหนด RFC 9207 เพื่อกันการโจมตีแบบสลับผู้ออกโทเคน — สรุปสั้น ๆ คือ MCP เลิกคิดเรื่องความปลอดภัยด้วยตัวเอง แล้วหันไปยืนบนมาตรฐานที่ผ่านการตรวจสอบมานาน ซึ่งเป็นทิศทางเดียวกับที่เราเคยเขียนไว้ในบทความเรื่อง ความปลอดภัยของระบบสารสนเทศองค์กร

รูปแบบการขอสิทธิ์โดยย่อ (ตัวอย่างเชิงอธิบาย):

1) client เรียก MCP server โดยยังไม่มีโทเคน
   -> server ตอบ 401 พร้อมชี้ว่าต้องไปขอสิทธิ์ที่ผู้ออกโทเคนรายใด

2) client พาไปที่ระบบยืนยันตัวตนขององค์กร (OAuth 2.0 / OIDC)
   -> องค์กรเป็นผู้ตัดสินว่าอนุญาตให้ผู้ใช้รายนี้เชื่อม server นี้หรือไม่

3) client ได้ access token กลับมา และต้องตรวจว่า iss ตรงกับ
   ผู้ออกโทเคนที่คาดไว้จริง (ตาม RFC 9207) ก่อนนำไปใช้

4) ทุกคำขอถัดไปแนบ Authorization: Bearer <access_token>
   โดยไม่ต้องมีรหัส session ใด ๆ อีก

ของใหม่อีกสามอย่าง และของเก่าที่กำลังจะเลิกใช้

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

องค์กรไทยควรเตรียมอะไร ก่อนปล่อยให้ AI แตะข้อมูลจริง

ข่าวสเปกใหม่มักถูกอ่านเป็นเรื่องของทีมพัฒนา แต่การตัดสินใจที่สำคัญกว่าอยู่ที่ฝ่ายบริหารและฝ่าย IT คือคำถามว่า "เราพร้อมให้ AI อ่านข้อมูลอะไรได้บ้าง และเราพิสูจน์ย้อนหลังได้ไหมว่ามันอ่านอะไรไปแล้ว" คำถามนี้ตอบได้ก่อนที่จะเลือกเครื่องมือใด ๆ ด้วยซ้ำ

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

ถ้าจะให้ AI คุยกับ ERP ต้องมีอะไรบ้าง — และ Saeree ERP อยู่ตรงไหน

ต้องพูดตรง ๆ ก่อนว่า Saeree ERP ยังไม่มี MCP server ให้เชื่อมต่อในตอนนี้ และผู้ช่วย AI ของเราเองก็ยังอยู่ในระหว่างการพัฒนา บทความนี้จึงไม่ได้เขียนขึ้นเพื่อบอกว่าเราพร้อมเสียบปลั๊กเข้ากับมาตรฐานใหม่ทันที แต่เขียนเพื่ออธิบายว่าเงื่อนไขที่ทำให้เรื่องนี้เกิดขึ้นได้จริงคืออะไร

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

ในส่วนของ Saeree ERP สิ่งที่มีอยู่แล้ววันนี้และเกี่ยวข้องโดยตรงกับข้อสองคือ ผู้ดูแลระบบขององค์กรกำหนดสิทธิ์ผู้ใช้รายบทบาทและรายเมนูได้เอง ตั้งผู้ใช้เป็น inactive ได้เมื่อพนักงานลาออกหรือย้ายหน้าที่ กำหนดช่วงเวลาที่บัญชีใช้งานได้ (valid from–to) สำหรับผู้ใช้ชั่วคราวหรือผู้ตรวจสอบภายนอก และมีร่องรอยการบันทึกว่าใครแก้ไขรายการใดเมื่อใด ทั้งหมดนี้ตั้งค่าได้โดยองค์กรเอง ไม่ต้องแจ้งผู้พัฒนา นอกจากนี้ระบบยังรองรับ การยืนยันตัวตนสองชั้น (2FA) สำหรับลดความเสี่ยงจากบัญชีถูกสวมรอย ซึ่งเป็นความเสี่ยงที่ยิ่งสำคัญขึ้นเมื่อบัญชีนั้นอาจถูกเครื่องมืออัตโนมัติเรียกใช้แทนคน

อีกประเด็นที่มักตามมาคือเรื่องที่ตั้งของข้อมูล องค์กรที่ต้องอธิบายให้ผู้ตรวจสอบฟังว่าข้อมูลอยู่ที่ใด มักเลือกติดตั้งระบบหลักไว้ในศูนย์ข้อมูลของตนเอง แล้วค่อยพิจารณาว่าจะเปิดช่องให้บริการภายนอกเข้าถึงส่วนใดบ้าง ซึ่งเป็นการชั่งน้ำหนักชุดเดียวกับที่เราเขียนไว้ในบทความ On-Premise หรือ Cloud เลือกแบบไหนดี

สรุป

MCP เดินทางจากโครงการโอเพนซอร์สที่เปิดตัวปลายปี 2567 มาถึงจุดที่มีสเปกซึ่งออกแบบมาเพื่อการติดตั้งจริงในองค์กร การตัด session ออกทำให้ MCP server กลายเป็นบริการ HTTP ธรรมดาที่ทีม Ops ดูแลด้วยความรู้เดิมได้ ส่วน Enterprise-Managed Authorization ทำให้การเชื่อมต่อกลายเป็นสิ่งที่องค์กรอนุมัติและถอนคืนได้จากศูนย์กลาง แทนที่จะเป็นเรื่องที่พนักงานแต่ละคนกดยอมรับเอง

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

"มาตรฐานเชื่อมต่อบอกได้แค่ว่าต่อสายอย่างไร แต่ไม่ได้บอกว่าปลายสายควรเห็นอะไร — คำตอบนั้นยังอยู่ที่การกำหนดสิทธิ์ในระบบธุรกิจของคุณเอง"

- ทีมงาน Saeree ERP

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

• Model Context Protocol Blog — The 2026-07-28 MCP Specification Release Candidate (21 พฤษภาคม 2569)
• InfoQ — AI Model Context Protocol Adds Centralised Auth for Enterprise (6 กรกฎาคม 2569)
• Model Context Protocol — เอกสารสเปกอย่างเป็นทางการ
• RFC 9207 — OAuth 2.0 Authorization Server Issuer Identification

ตรวจสอบข้อมูลล่าสุดเมื่อ 20 กรกฎาคม 2569