สร้าง MCP Server สำหรับโรงงาน | เชื่อม MES และ ERP เข้ากับ AI Agent อย่างปลอดภัย

“อยากให้ AI Agent เข้าถึงข้อมูลการควบคุมการผลิตและข้อมูลคุณภาพ ได้ยินคำว่า MCP บ่อยๆ แต่ควรสร้างอะไร สร้างไปถึงระดับไหน และควรเขียนอะไรลงในข้อกำหนดการจัดซื้อจัดจ้าง” นี่คือคำถามแรกที่ผู้รับผิดชอบระบบสารสนเทศและผู้ผลักดัน DX ในโรงงานญี่ปุ่นในประเทศไทยกำลังเผชิญอยู่ในขณะนี้ ขอเริ่มจากข้อสรุปก่อน การสร้าง MCP Server ไม่ใช่การสร้าง “หน้าต่างสู่ฐานข้อมูล” แต่เป็นการสร้าง “หน้าต่างสู่งาน” สิ่งที่ชี้ขาดความสำเร็จไม่ใช่ความฉลาดของโมเดลหรือความเร็วในการเชื่อมต่อ แต่คือการออกแบบ 3 ชั้น ได้แก่ (1) ความละเอียดของเครื่องมือ (granularity) (2) การอนุญาตสิทธิ์ (ขีดจำกัดสูงสุดของสิทธิ์) และ (3) หลักฐานการตรวจสอบ (audit trail)

ตัวเลขด้านจำนวนเงิน เวลา และอัตราการลดลงทั้งหมดที่ปรากฏในบทความนี้ เป็นค่าประมาณการและค่าสมมติที่บทความนี้จัดทำขึ้นเองโดยอิงจากโรงงานจำลองที่จะกล่าวถึงภายหลัง ไม่ใช่ค่าเฉลี่ยของอุตสาหกรรมหรือค่าจากการสำรวจ โปรดอ่านในฐานะ “แบบฟอร์มการคำนวณ” ที่ให้นำค่าจริงที่วัดได้ในบริษัทของท่านมาแทนสมมติฐาน

MCP คืออะไร และอะไรเปลี่ยนไปในปี 2026

MCP (Model Context Protocol) คือข้อตกลงร่วมที่ AI Agent ใช้เรียกข้อมูลหรือฟังก์ชันของระบบภายนอก โดยกำหนดรูปแบบที่เป็นมาตรฐานเดียวกันระหว่างฝั่ง Agent (ไคลเอนต์) กับฝั่งที่ให้บริการข้อมูลหรือฟังก์ชัน (เซิร์ฟเวอร์) ว่า “มีเครื่องมืออะไรบ้าง” “เรียกเครื่องมืออย่างไร” และ “ส่งผลลัพธ์กลับอย่างไร” ฟังก์ชันที่เซิร์ฟเวอร์ให้บริการหลักๆ มี 3 ประเภท ได้แก่ เครื่องมือ (Tools) ทรัพยากร (Resources) และพรอมต์ (Prompts) ในบริบทของโรงงาน อาจเข้าใจได้ง่ายที่สุดว่าเป็นการตั้ง “เคาน์เตอร์รับเรื่องสำหรับ Agent” ไว้หน้าระบบ MES, ERP, ระบบบริหารคุณภาพ (QMS) และระบบจัดการเอกสาร

แตกต่างจาก API อย่างไร

หลายโรงงานคงมี API สำหรับ ERP หรือ MES อยู่แล้ว API คือช่องทางให้นักพัฒนาที่เป็นมนุษย์เรียกใช้จากโปรแกรม โดยผู้เขียนโปรแกรมเป็นผู้กำหนดว่าจะเรียกอะไรในลำดับใด ส่วนเครื่องมือของ MCP นั้น Agent (โมเดลภาษา) จะอ่าน “คำอธิบายเครื่องมือ” แล้วเลือกเรียกใช้ด้วยการตัดสินใจของตัวเอง กล่าวคือ ใน MCP Server คำอธิบายเครื่องมือเองคือข้อกำหนดที่โมเดลอ่าน และขอบเขตของสิ่งที่เรียกได้ก็คือขีดจำกัดสูงสุดของความเสียหายเมื่อเกิดเหตุ นี่คือความแตกต่างโดยแก่นแท้จาก API การครอบ MCP Server บางๆ ไว้บน API เพียงอย่างเดียวจึงไม่เพียงพอ จำเป็นต้องออกแบบใหม่ว่า “จะอนุญาตให้โมเดลทำอะไรได้บ้าง”

อะไรเปลี่ยนไปในข้อกำหนดฉบับ 2026-07-28

ณ เดือนตุลาคม 2026 ข้อกำหนด MCP ฉบับล่าสุดคือฉบับ “2026-07-28” การเปลี่ยนแปลงหลักจากฉบับก่อนหน้า (ฉบับ 2025-11-25) มีดังนี้

• ยกเลิกเซสชันระดับโปรโตคอล และยกเลิกเฮดเดอร์ Session ID ใน Streamable HTTP
• ยกเลิกการ handshake แบบ initialize ตอนเริ่มเชื่อมต่อ และเปลี่ยนเป็นแบบ stateless (ใส่เวอร์ชันโปรโตคอลและข้อมูลความสามารถของไคลเอนต์ไว้ในแต่ละคำขอ)
• เพิ่มกลไกสอบถามความสามารถของเซิร์ฟเวอร์ (server/discover)
• ย้าย Tasks จากฟังก์ชันหลักเชิงทดลองไปเป็นส่วนขยาย (extension) อย่างเป็นทางการ
• ประกาศให้ Roots, Sampling และ Logging เป็นฟังก์ชันที่เลิกแนะนำให้ใช้ (Deprecated)
• ประกาศให้ transport แบบ HTTP+SSE แบบเดิมเป็น Deprecated และย้ายไปใช้ Streamable HTTP
• ประกาศให้การลงทะเบียนไคลเอนต์แบบไดนามิกของ OAuth เป็น Deprecated และแนะนำ Client ID Metadata Documents แทน
• นำนโยบายวงจรชีวิตมาใช้ โดยเมื่อจะยกเลิกฟังก์ชันใด ต้องมีช่วงเวลา Deprecated อย่างน้อย 12 เดือน

ตามบล็อกทางการ การเปลี่ยนเป็นแบบ stateless ทำให้สามารถวางเซิร์ฟเวอร์ไว้บนอินสแตนซ์ใดก็ได้ภายใต้ load balancer แบบ round-robin ทั่วไป สำหรับฝ่ายระบบสารสนเทศของโรงงาน นี่คือการเปลี่ยนแปลงที่ช่วยให้ออกแบบระบบสำรอง (redundancy) และการติดตั้งแยกตามไซต์ได้ง่ายขึ้น ในทางกลับกัน สิ่งที่ต้องรู้ไว้คือ MCP Server บางตัวที่สร้างขึ้นในปี 2025 ถูกสร้างด้วยวิธีที่ครั้งนี้ถูกประกาศเป็น Deprecated แล้ว

การแพร่หลายและความเป็นกลาง

ขนาดของการแพร่หลายก็ต่างจากปี 2025 อย่างมาก บล็อกทางการเดียวกันระบุว่ายอดดาวน์โหลดรวมของ SDK หลัก (Tier 1) ต่อเดือนใกล้แตะประมาณ 500 ล้านครั้ง และ Tier 1 SDK ของ TypeScript, Python, Go และ C# รองรับฉบับใหม่ตั้งแต่วันที่ข้อกำหนดเผยแพร่

ในด้านธรรมาภิบาล เมื่อวันที่ 9 ธันวาคม 2025 Linux Foundation ได้ประกาศจัดตั้ง Agentic AI Foundation (AAIF) และ MCP ของ Anthropic ได้กลายเป็นหนึ่งในโครงการก่อตั้ง โดยมี AWS, Google, Microsoft, OpenAI และอื่นๆ อยู่ในรายชื่อสมาชิกระดับ Platinum อาจกล่าวได้ว่า MCP ได้เข้าสู่ระยะที่ถูกมองเป็นโครงสร้างพื้นฐานร่วมของอุตสาหกรรม ไม่ใช่มาตรฐานเฉพาะของผู้ขายรายใดรายหนึ่ง

อย่างไรก็ตาม การที่เทคโนโลยีแพร่หลาย กับการที่โรงงานของท่านจะใช้งานได้อย่างปลอดภัย เป็นคนละเรื่องกัน ตามการคาดการณ์ของ Gartner เมื่อเดือนมิถุนายน 2025 โครงการ AI แบบ Agent มากกว่า 40% คาดว่าจะถูกยกเลิกภายในสิ้นปี 2027 โดยมีเหตุผลคือต้นทุนที่พุ่งสูง คุณค่าทางธุรกิจที่ไม่ชัดเจน และการบริหารความเสี่ยงที่ไม่เพียงพอ การสร้าง MCP Server เป็นกระบวนการที่เกี่ยวข้องโดยตรงกับเหตุผลทั้ง 3 ข้อนี้

“หน้าต่างสู่ฐานข้อมูล” กับ “หน้าต่างสู่งาน”: 3 ปัญหาของการต่อ Connector อเนกประสงค์โดยตรง

วิธีที่ทำให้ MCP Server ใช้งานได้เร็วที่สุดคือการนำ Connector อเนกประสงค์สำหรับฐานข้อมูลหรือสำหรับ ERP มาต่อตรงๆ หากให้เครื่องมือที่รัน SQL ได้หรือเครื่องมือที่อ่านตารางใดก็ได้ Agent ก็จะค้นหาได้ทุกอย่าง ในขั้นทดลองต้นแบบ วิธีนี้ทำงานได้ดีอย่างน่าประหลาดใจ

แต่โครงสร้างแบบ “หน้าต่างสู่ฐานข้อมูล” นี้ เมื่อนำไปใช้ในโรงงานจริงจะเผชิญ 3 ปัญหาต่อไปนี้พร้อมกัน

ปัญหาข้อที่ 3 ตรวจรับงานไม่ได้ มักถูกมองข้าม สิ่งที่ฝ่ายผู้ว่าจ้างยืนยันได้ในการทดสอบเพื่อตรวจรับ คือฟังก์ชันที่กำหนดไว้ทำงานตามที่กำหนดหรือไม่ และไม่มีสิ่งใดนอกเหนือจากที่กำหนดเกิดขึ้นหรือไม่ เครื่องมือที่รัน SQL ใดก็ได้นั้น “ทำได้ทุกอย่าง” จึงไม่สามารถพิสูจน์ด้วยการทดสอบได้ว่า “สิ่งที่ไม่ควรเกิดจะไม่เกิดขึ้น”

ในทางตรงข้าม แบบ “หน้าต่างสู่งาน” จะแยกเครื่องมือออกเป็นหน่วยของงาน เช่น “ดึงประวัติย้อนกลับของล็อต” “ดึงสถานะการตอบกำหนดส่งมอบของคำสั่งซื้อจากลูกค้า” “จัดทำร่างรายงานความไม่สอดคล้อง” แม้จำนวนเครื่องมือจะเพิ่มขึ้น แต่สามารถกำหนดได้ว่าเครื่องมือแต่ละตัวส่งอะไรกลับและอนุญาตให้ใครใช้ ทำให้ทั้ง 3 เรื่อง คือ สิทธิ์ หลักฐานการตรวจสอบ และการตรวจรับ สามารถออกแบบได้ทั้งหมด

ต่อไปนี้จะพิจารณา 3 ชั้นที่รองรับ “หน้าต่างสู่งาน” นี้ตามลำดับ คือ ชั้นที่ 1 การออกแบบเครื่องมือ ชั้นที่ 2 การอนุญาตสิทธิ์ และชั้นที่ 3 หลักฐานการตรวจสอบ ทั้ง 3 ชั้นไม่ได้แยกเป็นอิสระจากกัน แต่ซ้อนต่อกันเป็นลำดับ กล่าวคือ เพราะเครื่องมือถูกแบ่งตามหน่วยของงาน จึงกำหนดขอบเขตการอนุญาตสิทธิ์ได้ และเพราะการอนุญาตสิทธิ์ถูกกำหนดไว้แล้ว จึงกำหนดรายการที่ต้องบันทึกเป็นหลักฐานได้

ชั้นที่ 1 การออกแบบเครื่องมือ: เชื่อมต่อ MES และ ERP โดยแบ่งตามหน่วยของงาน

การตัดสินใจเชิงออกแบบข้อแรกของการสร้าง MCP Server คือ “จะแบ่งเครื่องมือตามหน่วยใด” หลักการในที่นี้คือ แบ่งตามหน่วยของงานที่ผู้รับผิดชอบทำอยู่ทุกวัน ไม่ใช่ตามหน่วยของ SQL หรือตาราง

ตัวอย่างเครื่องมือที่แบ่งตามหน่วยของงาน

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

สิ่งสำคัญคือการจำกัดสิ่งที่เครื่องมือส่งกลับให้เหลือเพียง “รายการที่จำเป็นต่องานนั้นเท่านั้น” เครื่องมือดึงประวัติย้อนกลับของล็อตไม่จำเป็นต้องส่งชื่อบุคคลของพนักงานหรือประเภทเงินเดือนกลับมา การจำกัดค่าที่ส่งกลับช่วยได้ทั้งในเรื่องการอนุญาตสิทธิ์ที่จะกล่าวถึงต่อไป และการปฏิบัติตามพระราชบัญญัติคุ้มครองข้อมูลส่วนบุคคลของไทย (PDPA)

แยกการอ่านและการเขียนออกจากกัน

หลักการข้อที่ 2 คือ แยกเครื่องมืออ่านและเครื่องมือเขียนไว้คนละเซิร์ฟเวอร์ หรืออย่างน้อยไว้คนละขอบเขตสิทธิ์ (scope) หากเครื่องมืออ่านและเขียนอยู่ในเซิร์ฟเวอร์เดียวกัน ผู้ใช้ที่ต้องการอนุญาตให้อ่านอย่างเดียวก็จะมองเห็นเครื่องมือเขียนด้วย ทำให้การออกแบบสิทธิ์ซับซ้อนขึ้น หากแยกเซิร์ฟเวอร์ไว้ ก็จะนำระบบมาใช้แบบเป็นขั้นตอนได้อย่างตรงไปตรงมา เช่น “เปิดเฉพาะเซิร์ฟเวอร์อ่านก่อน แล้วค่อยเพิ่มเซิร์ฟเวอร์เขียนภายหลัง”

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

คำอธิบายเครื่องมือคือ “ข้อกำหนดที่โมเดลอ่าน”

หลักการข้อที่ 3 คือการเขียนคำอธิบายเครื่องมือ (description) อย่างรอบคอบ ดังที่กล่าวไว้ข้างต้น Agent จะอ่านคำอธิบายแล้วตัดสินใจว่าจะเรียกเครื่องมือใด หากคำอธิบายคลุมเครือ โมเดลอาจเลือกเครื่องมือที่ชื่อคล้ายกันผิดตัว หรือเติมอาร์กิวเมนต์ที่จำเป็นด้วยการเดา

ในคำอธิบายควรเขียนอย่างน้อยดังต่อไปนี้

• เครื่องมือนี้ส่งอะไรกลับ (รวมถึงสิ่งที่ไม่ส่งกลับด้วย)
• ความหมายและรูปแบบของอาร์กิวเมนต์ (จำนวนหลักของเลขล็อต รูปแบบวันที่ ฯลฯ)
• ควรใช้กับคำถามแบบใด ในงานใด
• สถานการณ์ที่ห้ามใช้ (ตัวอย่าง: ห้ามใช้ในการตัดสินขั้นสุดท้ายว่าจัดส่งได้หรือไม่)

ศัพท์เฉพาะงานในโรงงานมักมีหลายชื่อเรียกสำหรับสิ่งเดียวกัน จึงต้องระวัง หากคำว่า “ล็อต” “หมายเลขการผลิต” และ “แบทช์” ถูกใช้ปะปนกันตามไซต์หรือฝ่าย ให้ทำพจนานุกรมเพื่อให้ศัพท์ในคำอธิบายและในค่าที่ส่งกลับตรงกัน เรื่องการจัดการภาษาในการดำเนินงานหลายไซต์ จะกล่าวถึงอีกครั้งในหัวข้อประเด็นเฉพาะของประเทศไทย

จำนวนเครื่องมือที่เหมาะสมคือเท่าใด

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

ชั้นที่ 2 การอนุญาตสิทธิ์: “ขีดจำกัดสูงสุดของสิทธิ์” ที่ต้องกำหนดเป็นอันดับแรกในความปลอดภัย MCP

เมื่อแบ่งเครื่องมือตามหน่วยของงานแล้ว ขั้นต่อไปคือการกำหนดว่า “ใครเรียกเครื่องมือใดได้ กับข้อมูลในขอบเขตใด” สิ่งที่ต้องกำหนดเป็นอันดับแรกในความปลอดภัยของ MCP ซึ่งมาก่อนวิธีการทางเทคนิค คือหลักการที่ว่า สิทธิ์ของ Agent ต้องไม่เกินสิทธิ์ของผู้ที่ร้องขอ

Agent ทำงานในฐานะ “ตัวแทนของผู้ร้องขอ”

เมื่อผู้รับผิดชอบฝ่ายประกันคุณภาพร้องขอว่า “ขอดูประวัติย้อนกลับของล็อตนี้” สิ่งที่ Agent ดูได้คือขอบเขตเดียวกับที่ผู้รับผิดชอบคนนั้นล็อกอินเข้า MES ด้วยตัวเองแล้วดูได้เท่านั้น หากให้บัญชีบริการ (service account) ที่มีสิทธิ์เทียบเท่าผู้ดูแลระบบแก่ Agent จน “ดูได้ทุกอย่าง” ผู้ร้องขอก็จะมองเห็นข้อมูลที่ตามปกติตนไม่มีสิทธิ์ดู โดยผ่านทาง Agent ซึ่งนี่คือการยกระดับสิทธิ์ (privilege escalation) โดยตรง

ในรายการความเสี่ยงสำหรับ MCP ที่ OWASP เผยแพร่ (OWASP MCP Top 10 ซึ่ง ณ เดือนตุลาคม 2026 ยังอยู่ในขั้นเบต้า) ก็มีหัวข้อการยกระดับสิทธิ์จากการขยายตัวของ scope (MCP02) และการยืนยันตัวตนและการอนุญาตสิทธิ์ที่ไม่เพียงพอ (MCP07)

การจัดการโทเคนตามที่ข้อกำหนดกำหนดไว้

ข้อกำหนดด้านการอนุญาตสิทธิ์ของ MCP ฉบับ 2026-07-28 ใช้ OAuth 2.1 เป็นพื้นฐานสำหรับกรณีใช้งานกับ transport แบบ HTTP ประเด็นสำคัญที่ฝ่ายผู้ว่าจ้างควรรู้มี 3 ข้อ ดังนี้

1. การตรวจสอบปลายทางของโทเคน: MCP Server ต้องตรวจสอบว่าโทเคนการเข้าถึง (access token) ที่ได้รับนั้นออกให้กับตนเองหรือไม่ (MUST)
2. ห้ามส่งต่อโทเคน: ข้อกำหนดห้ามรับโทเคนอื่น หรือส่งโทเคนนั้นต่อไปยังระบบปลายน้ำโดยตรง แนวปฏิบัติด้านความปลอดภัยทางการเรียกสิ่งนี้ว่า Token Passthrough และห้ามไว้อย่างชัดเจน การสร้างระบบที่นำโทเคนที่ได้รับจาก Agent ไปส่งต่อให้ API ของ ERP ตรงๆ จึงทำไม่ได้
3. ห้ามใส่โทเคนใน URL: ห้ามใส่โทเคนการเข้าถึงไว้ใน query string ของ URL ด้วย

ทั้งนี้ MCP Server แบบ STDIO ที่รันบนเครื่องท้องถิ่น (local) จะไม่ปฏิบัติตามข้อกำหนดการอนุญาตสิทธิ์นี้ แต่จะรับข้อมูลรับรอง (credentials) จากสภาพแวดล้อมแทน สำหรับเซิร์ฟเวอร์ที่ผู้ใช้หลายคนในโรงงานใช้ร่วมกัน หลักพื้นฐานคือสร้างด้วย transport แบบ HTTP และทำตามข้อกำหนดการอนุญาตสิทธิ์

Scope แบบครอบคลุมทั้งหมดคือความผิดพลาดที่พบบ่อย

แนวปฏิบัติด้านความปลอดภัยทางการแนะนำให้เริ่มจาก scope (ขอบเขตสิทธิ์) ที่น้อยที่สุด แล้วค่อยๆ ยกระดับตามความจำเป็น และระบุว่าการให้ scope แบบครอบคลุมทั้งหมดอย่าง full-access เป็นความผิดพลาดที่พบบ่อย

สำหรับโรงงาน การออกแบบ scope ในทางปฏิบัติอาจเป็นดังนี้

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

เซิร์ฟเวอร์ของผู้ขายก็ใช้แนวคิดเดียวกัน

แนวคิด “สิทธิ์ของ Agent อยู่ในขอบเขตของบทบาท (role) ที่กำหนดให้เท่านั้น” นี้ ถูกนำไปใช้ในผลิตภัณฑ์ของผู้ขาย ERP รายใหญ่ด้วย Dynamics 365 ERP MCP Server ของ Microsoft ออกแบบให้ส่งคืนเมนู เอนทิตี และ API เฉพาะในขอบเขตของ security role ที่กำหนดให้ Agent เท่านั้น และปฏิเสธการเรียกที่อยู่นอกสิทธิ์ อีกทั้งยังกำหนดให้ไคลเอนต์ที่เชื่อมต่อได้ต้องได้รับอนุญาตก่อน

การแยกข้อมูลตามไซต์

หากใช้ MCP Server ตัวเดียวกันร่วมกันหลายไซต์ เช่น ไทย เวียดนาม และสำนักงานใหญ่ในญี่ปุ่น การแยกข้อมูลตามไซต์ (หรือตามนิติบุคคล) ก็เป็นข้อกำหนดในการออกแบบการอนุญาตสิทธิ์ด้วย ดังที่กรณีของ Asana ซึ่งจะกล่าวถึงต่อไปแสดงให้เห็น การมองเห็นข้อมูลข้ามองค์กรอาจพังทลายได้จากข้อบกพร่องของซอฟต์แวร์เพียงอย่างเดียว แม้ไม่มีการโจมตี จึงควรระบุให้ชัดเจนทั้งในเอกสารออกแบบและในการทดสอบว่า “โทเคนของผู้ใช้โรงงานไทยจะไม่ได้รับข้อมูลล็อตของโรงงานเวียดนาม”

ชั้นที่ 3 หลักฐานการตรวจสอบ: บันทึกการเรียกเครื่องมือทุกครั้ง

ชั้นที่ 3 คือหลักฐานการตรวจสอบ หากย้อนดูภายหลังไม่ได้ว่า Agent ตอบโดยอาศัยหลักฐานใด และเขียนอะไรลงไปบ้าง ก็จะอธิบายไม่ได้เมื่อเกิดปัญหาคุณภาพหรือเมื่อมีการตรวจสอบ (audit) ใน OWASP MCP Top 10 การขาดการตรวจสอบและการเก็บข้อมูลการทำงาน (telemetry) ก็ถูกแยกเป็นหัวข้ออิสระคือ MCP08

รายการที่ควรบันทึก

อย่างน้อยที่สุด ควรบันทึกรายการต่อไปนี้สำหรับการเรียกเครื่องมือทุกครั้ง

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

กำหนดระยะเวลาการเก็บและผู้ตรวจดู

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

การจัดการล็อกเชื่อมโยงกับการออกแบบการเฝ้าระวังการทำงานของ Agent โดยรวม เรื่องการเฝ้าระวังปริมาณการใช้ API และอัตราข้อผิดพลาดของ Agent ได้สรุปไว้ใน “การดำเนินงาน API ของ AI Agent” และแนวคิดการจัดการด้วยทะเบียนว่า Agent ใดเชื่อมต่อกับเซิร์ฟเวอร์ใด ได้สรุปไว้ใน “ทะเบียนและการควบคุม AI Agent“

เรียนรู้ความปลอดภัย MCP จากเหตุการณ์และช่องโหว่ที่เกิดขึ้นจริง

การออกแบบ 3 ชั้นไม่ใช่เรื่องบนกระดาษ ซึ่งเห็นได้ชัดเมื่อดูเหตุการณ์ที่เกิดขึ้นจริงและช่องโหว่ที่ถูกเปิดเผยในปี 2025 ในที่นี้จะเลือกนำเสนอเฉพาะกรณีที่มีบทเรียนเชื่อมโยงโดยตรงกับการสร้าง MCP Server ของโรงงาน

Asana: แม้ไม่มีการโจมตี ข้อบกพร่องก็อาจทำให้มองเห็นข้อมูลขององค์กรอื่นได้

Asana ซึ่งเป็นบริการบริหารโครงการ เปิดตัว MCP Server เมื่อวันที่ 1 พฤษภาคม 2025 ต่อมาเมื่อวันที่ 4 มิถุนายน ได้พบข้อบกพร่องเชิงตรรกะและหยุดเซิร์ฟเวอร์ แล้วกลับมาให้บริการเมื่อวันที่ 17 มิถุนายน ข้อบกพร่องนี้ทำให้ผู้ใช้ MCP ขององค์กรอื่นอาจมองเห็นข้อมูล เช่น งาน (task) และโครงการได้ ตามรายงานข่าว โฆษกของ Asana ระบุว่ามีลูกค้าได้รับผลกระทบประมาณ 1,000 ราย รายงานข่าวไม่ได้กล่าวถึงร่องรอยการนำไปใช้ในทางมิชอบ และเป็นเหตุการณ์ที่เกิดจากข้อบกพร่องของซอฟต์แวร์ ไม่ใช่การโจมตี

บทเรียน: การแยกข้อมูลข้ามองค์กรหรือข้ามไซต์ ต้องใส่ไว้เป็นข้อกำหนดในการออกแบบ ไม่ใช่เพียงเพื่อรับมือการโจมตี แต่เพื่อรับมือข้อบกพร่องด้วย หากใช้ MCP Server ตัวเดียวร่วมกันหลายไซต์ ให้ยืนยันในการทดสอบเพื่อตรวจรับว่า “ข้อมูลของไซต์อื่นจะไม่ถูกส่งกลับ” และยืนยันต่อเนื่องด้วยการทดสอบถดถอย (regression test) ทุกครั้งที่มีการแก้ไขระบบ

“Toxic Agent Flow” ของ GitHub MCP: เอกสารจากภายนอกกลายเป็นทางเข้า

ในเดือนพฤษภาคม 2025 บริษัทด้านความปลอดภัย Invariant Labs ได้เปิดเผยวิธีการโจมตี Agent ที่ใช้ GitHub MCP Server โดยหากฝังคำสั่งที่มีเจตนาร้ายไว้ใน Issue ของ repository สาธารณะ Agent ที่อ่าน Issue นั้นจะทำตามคำสั่ง อ่านข้อมูลจาก repository ส่วนตัว แล้วทำให้ข้อมูลรั่วไหลผ่าน pull request ที่สร้างขึ้นโดยอัตโนมัติ ซึ่งก็คือสิ่งที่เรียกว่า indirect prompt injection ผู้เขียนระบุว่านี่ไม่ใช่ข้อบกพร่องในโค้ดของ GitHub MCP Server เอง แต่เป็นปัญหาเชิงโครงสร้างของระบบ Agent และจำเป็นต้องมีมาตรการที่ฝั่ง Agent

บทเรียน: หากเทียบกับโรงงาน กรณีนี้ตรงกับสถานการณ์ที่ให้ Agent อ่านเอกสารที่มาจากภายนอก เช่น อีเมลจากคู่ค้า ข้อกำหนดสินค้าจากลูกค้า หรือใบรายงานผลการตรวจสอบจากซัพพลายเออร์ หากให้ Agent ที่อ่านเอกสารภายนอกมีเครื่องมือเขียนด้วย ก็จะเกิดเส้นทางที่คำสั่งซึ่งฝังอยู่ในเอกสารทำให้เกิดการออกเอกสารหรือการส่งที่ไม่จำเป็น ในกรณีนี้ หลักการ “การเขียนทำได้ถึงขั้นร่าง ส่วนการยืนยันเป็นหน้าที่ของคน” และการแยกการอ่านกับการเขียนออกจากกันก็ได้ผลเช่นกัน

เครื่องมือทางการและเครื่องมือยอดนิยมก็มีช่องโหว่ได้

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

mcp-server-git เป็นเซิร์ฟเวอร์ที่เผยแพร่ในฐานะตัวอ้างอิงทางการของ MCP ฝ่ายผู้ว่าจ้างจึงควรตั้งสมมติฐานว่า แม้แต่ของทางการหรือของที่ใช้กันแพร่หลายก็มีช่องโหว่ได้ และในการจัดจ้างต้องตกลงให้ชัดเจนเรื่อง “รายการเวอร์ชันของแพ็กเกจที่เกี่ยวข้องกับ MCP ที่ใช้” และ “จะอัปเดตภายในกี่วันเมื่อมีการเปิดเผยช่องโหว่”

postmark-mcp: การโจมตีห่วงโซ่อุปทานผ่านเซิร์ฟเวอร์นอกการควบคุม

มีรายงานว่าในเดือนกันยายน 2025 บริษัทด้านความปลอดภัย Koi Security ได้พบ MCP Server ที่เป็นอันตรายชื่อ “postmark-mcp” ซึ่งเผยแพร่อยู่บน npm โดยเป็นแพ็กเกจที่ลอกเลียนไลบรารีของ Postmark Labs ตัวจริง และในเวอร์ชัน v1.0.16 ที่เผยแพร่เมื่อวันที่ 17 กันยายน 2025 มีการเพิ่มโค้ด 1 บรรทัดที่ส่งสำเนาลับ (BCC) ของอีเมลขาออกทั้งหมดไปยังที่อยู่ภายนอก ยอดดาวน์โหลดสะสมอยู่ที่ 1,643 ครั้ง

บทเรียน: หากผู้ปฏิบัติงานหน้างานติดตั้ง MCP Server ที่ดูสะดวกตามดุลยพินิจส่วนตัว แพ็กเกจที่เป็นอันตรายเช่นนี้ก็จะเล็ดลอดเข้ามาในองค์กร OWASP MCP Top 10 ระบุ MCP Server ที่อยู่นอกการควบคุมไว้เป็น MCP09 (Shadow MCP Servers) และการดัดแปลงแพ็กเกจที่พึ่งพา (dependency) ไว้เป็น MCP04 มาตรการพื้นฐานคือการจัดทำ รายการที่อนุญาต (allowlist) ของ MCP Server และแพ็กเกจที่พึ่งพาซึ่งอนุญาตให้ใช้ และจัดโครงสร้างระบบให้เชื่อมต่อสิ่งอื่นนอกรายการไม่ได้

การรับมือเบื้องต้นเมื่อเกิดเหตุ ได้แก่ การตัดสินใจหยุดเซิร์ฟเวอร์ การระบุขอบเขตผลกระทบ และขั้นตอนการแจ้งผู้ใช้ ได้อธิบายไว้อย่างละเอียดใน “การรับมือเหตุการณ์ของ AI Agent” ก่อนนำ MCP Server ขึ้นใช้งานจริง อย่างน้อยที่สุดโปรดกำหนดไว้ว่า “ใครเป็นผู้ตัดสินใจหยุดเซิร์ฟเวอร์”

ขอบเขตกับ OT: การเขียนไปยัง PLC และระบบควบคุมไม่อยู่ในขอบเขตของ MCP

เมื่อพูดถึง MCP ในโรงงาน จะมีคำถามเสมอว่า “จะเชื่อมเครื่องจักรหรือ PLC เข้ากับ AI ด้วยหรือไม่” ข้อแนะนำของบทความนี้ชัดเจน คือ ให้การเขียนไปยัง PLC และระบบควบคุมอยู่นอกขอบเขตของ MCP

เหตุผลนั้นเรียบง่าย การเขียนไปยัง MES หรือ ERP แม้จะผิดพลาด คนก็ยังหยุดไว้ได้ในขั้นร่าง และแม้ยืนยันไปแล้วก็ยังย้อนกลับได้ด้วยการแก้ไขเอกสาร ในทางกลับกัน การเขียนไปยังระบบควบคุมส่งผลโดยตรงต่อการทำงานของเครื่องจักร ต่อผลิตภัณฑ์ และในบางกรณีต่อความปลอดภัยของคน และไม่สามารถ “แก้ไขภายหลัง” ได้ ดังที่เห็นในหัวข้อก่อนหน้า เมื่อพฤติกรรมของ Agent อาจเปลี่ยนไปได้จากคำสั่งที่ฝังอยู่ในเอกสารภายนอก การให้สิทธิ์ Agent ควบคุมเครื่องจักรจึงเป็นความเสี่ยงที่ไม่คุ้มค่าในขณะนี้

OPC UA MCP Server ยังอยู่ในขั้นพรีวิว

OPC Foundation ผู้กำหนดมาตรฐานการสื่อสารทางอุตสาหกรรม OPC UA ได้เผยแพร่เซิร์ฟเวอร์ที่เปิดการเรียกบริการของ OPC UA ให้เป็นเครื่องมือของ MCP ในรูปแบบแพ็กเกจ NuGet เวอร์ชันล่าสุดคือ 2.0.0-preview.6 ที่เผยแพร่เมื่อวันที่ 30 กันยายน 2026 และยังมีสถานะเป็นรุ่นก่อนเผยแพร่ (prerelease) นอกจากนี้ยังมีกลไกโปรไฟล์ที่ใช้สลับขอบเขตของเครื่องมือตามวัตถุประสงค์การใช้งาน

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

เรื่องการแยกเครือข่ายฝั่ง OT และการออกแบบขอบเขตเมื่อนำ AI Agent เข้าสู่เครือข่ายโรงงาน ได้สรุปไว้อย่างละเอียดใน “ความปลอดภัยของ AI Agent ในอุตสาหกรรม“

MCP Server สำเร็จรูปกับการสร้างเอง: ควรเลือกแบบใดในการเชื่อม AI Agent กับ ERP

เมื่อพิจารณาการสร้าง MCP Server ทางแยกสำคัญคือจะใช้ MCP Server สำเร็จรูปที่ผู้ขาย ERP หรือผู้ให้บริการคลาวด์จัดให้ หรือจะสร้างขึ้นเองตั้งแต่ต้นโดยบริษัทเอง (หรือผู้รับจ้าง) ในปี 2026 เริ่มมีเซิร์ฟเวอร์สำเร็จรูปสำหรับ ERP หลักๆ ออกมาแล้ว

ตัวอย่างเซิร์ฟเวอร์สำเร็จรูป

Dynamics 365 ERP MCP Server (Microsoft): ให้บริการฟังก์ชันของ ERP ใน Dynamics 365 เป็นเครื่องมือ 3 ประเภท ได้แก่ การจัดการข้อมูล (Data) การทำงานผ่านหน้าจอ (Form) และการเรียกแอคชัน (Action) ดังที่กล่าวไว้ข้างต้น เซิร์ฟเวอร์จะส่งคืนฟังก์ชันเฉพาะในขอบเขตของ security role ที่กำหนดให้ Agent และไคลเอนต์ที่เชื่อมต่อได้ต้องได้รับอนุญาตก่อน ฟอร์มอย่างการตั้งค่าความปลอดภัยหรือการจัดการผู้ใช้ไม่สามารถเข้าถึงได้จาก MCP หากใช้จากไคลเอนต์อื่นที่ไม่ใช่ Copilot Studio จะใช้ 0.1 Copilot Credit ต่อการเรียกเครื่องมือ 1 ครั้ง ภาษาที่รองรับมีเพียงภาษาอังกฤษแบบสหรัฐอเมริกา และเซิร์ฟเวอร์รุ่น “static” แบบเดิมถูกยกเลิกไปเมื่อวันที่ 1 ตุลาคม 2026

AWS for SAP MCP Server (Amazon Bedrock AgentCore): เปิดให้บริการทั่วไป (general availability) ในเดือนพฤษภาคม 2026 เชื่อมต่อกับ S/4HANA และ SAP ECC และให้ Agent สร้าง อ่าน อัปเดต และลบ SAP business object เช่น คำสั่งซื้อจากลูกค้า ใบสั่งซื้อ ข้อมูลหลักวัสดุ (material) และเอกสารทางบัญชี โดยมีการแยกเซสชัน การเชื่อมต่อแบบส่วนตัว (private connectivity) การยืนยันตัวตนสองชั้นด้วย AgentCore Identity และ telemetry ผ่าน CloudWatch

เปรียบเทียบวิธีเลือก

ประเด็นสำคัญคือ แม้จะเลือกเซิร์ฟเวอร์สำเร็จรูป การออกแบบสิทธิ์และการออกแบบหลักฐานการตรวจสอบก็ยังเป็นงานของฝ่ายผู้ว่าจ้าง Dynamics 365 ERP MCP ทำงานในขอบเขตของ security role ก็จริง แต่ผู้ตัดสินใจว่าจะกำหนด role ใดให้ Agent คือบริษัทผู้ใช้ หากกำหนด role ที่กว้าง Agent ก็จะทำงานได้กว้างเช่นกัน นอกจากนี้ เซิร์ฟเวอร์สำเร็จรูปมองเห็นเฉพาะภายใน ERP เครื่องมือตามหน่วยของงานที่ต้องข้าม MES, QMS และ ERP อย่าง “ประวัติย้อนกลับของล็อต” จึงมักต้องสร้างแยกต่างหาก

ในทางปฏิบัติ จุดลงตัวของโรงงานจำนวนมากคือการผสมผสาน โดยใช้เซิร์ฟเวอร์สำเร็จรูปกับงานสืบค้นและการออกเอกสารที่จบภายใน ERP เพียงระบบเดียว และสร้างเซิร์ฟเวอร์ของบริษัทเองตามหน่วยของงานสำหรับงานที่ข้าม MES, QMS และระบบจัดการเอกสาร วิธีเลือกผู้รับจ้างและประเด็นที่ควรระวังในสัญญาพัฒนา AI ได้สรุปไว้ใน “วิธีเลือกบริษัทพัฒนา AI“

ต้นทุนและ ROI ของการสร้าง MCP Server: ประมาณการด้วยโรงงานจำลอง

จากนี้ไปจะประมาณการต้นทุนและผลลัพธ์ของการสร้าง MCP Server โดยใช้โรงงานจำลอง ขอย้ำอีกครั้งว่า ตัวเลขต่อไปนี้ทั้งหมดเป็นค่าประมาณการและค่าสมมติที่บทความนี้จัดทำขึ้นเอง ไม่ใช่ค่าเฉลี่ยของอุตสาหกรรมหรือค่าจากการสำรวจ หากจะนำไปใช้ในการขออนุมัติภายใน โปรดแทนสมมติฐานด้วยค่าของบริษัทท่านแล้วคำนวณใหม่

สมมติฐานร่วม (โรงงานจำลอง P)

• โรงงานผลิตชิ้นส่วนอิเล็กทรอนิกส์ของบริษัทญี่ปุ่นในจังหวัดพระนครศรีอยุธยา ประเทศไทย พนักงาน 850 คน
• ผู้รับผิดชอบฝ่ายควบคุมการผลิต ฝ่ายประกันคุณภาพ และฝ่ายจัดซื้อ รวม 40 คน ใช้เวลาเฉลี่ยคนละ 45 นาทีต่อวันกับ “งานสืบค้นข้อมูล” คือการค้นหาและรวบรวมข้อมูลจาก MES, ERP, QMS และระบบจัดการเอกสาร (ค่าสมมติ)
• วันทำงาน 250 วันต่อปี
• อัตราค่าแรงต่อชั่วโมงคน 250 THB (ค่าที่บทความนี้กำหนดขึ้นชั่วคราว โดยรวมเงินเดือนของพนักงานสำนักงานและพนักงานเทคนิคกับประกันสังคมและค่าใช้จ่ายอื่นๆ)

เวลาที่ใช้กับงานสืบค้นข้อมูลต่อปีคือ 40 คน × 0.75 ชั่วโมง × 250 วัน = 7,500 ชั่วโมงต่อปี เมื่อคูณด้วยอัตราค่าแรงต่อชั่วโมงคน ค่าแรงของงานสืบค้นข้อมูลต่อปีจะเท่ากับ 7,500 × 250 = 1,875,000 THB ต่อปี

โครงสร้างที่ 1 “อ่านอย่างเดียว และเครื่องมือแบ่งตามหน่วยของงาน”

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

ด้านผลลัพธ์ สมมติว่าลดเวลาสืบค้นข้อมูลได้ 45% (ค่าสมมติ) 7,500 ชั่วโมง × 45% = 3,375 ชั่วโมง คูณด้วยอัตราค่าแรงต่อชั่วโมงคน 250 THB จะได้ 843,750 THB ต่อปี

ผลประโยชน์สุทธิต่อปีคือ 843,750 − 380,000 = 463,750 THB ต่อปี และระยะเวลาคืนทุนอย่างง่ายคือ 1,400,000 ÷ 463,750 = ประมาณ 3.0 ปี

โครงสร้างที่ 2 “อ่านและเขียน (ออกเอกสารและร่าง โดยคนเป็นผู้อนุมัติยืนยัน)”

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

ด้านผลลัพธ์ ให้นำการลดเวลาสืบค้นข้อมูลของโครงสร้างที่ 1 ซึ่งเท่ากับ 843,750 THB มาบวกกับการลดงานออกเอกสาร หากสมมติว่ามีการออกเอกสารปีละ 6,000 รายการ และลดเวลาได้รายการละ 15 นาที จะได้ 6,000 รายการ × 0.25 ชั่วโมง = 1,500 ชั่วโมง และ 1,500 × 250 = 375,000 THB ผลลัพธ์รวมคือ 843,750 + 375,000 = 1,218,750 THB ต่อปี

สิ่งที่ต้องระวังในจุดนี้คือ อย่านับการลดเวลาสืบค้นข้อมูลซ้ำสองครั้ง ผลลัพธ์ของโครงสร้างที่ 2 คือ “การลดเวลาสืบค้นข้อมูลของโครงสร้างที่ 1” บวกกับ “การลดงานออกเอกสาร” ไม่ได้หมายความว่าการลดเวลาสืบค้นข้อมูลเองจะเพิ่มขึ้น อาจมีความรู้สึกอยากเพิ่มอัตราการลดเวลาสืบค้นข้อมูลด้วยเหตุผลว่าเมื่อมีเครื่องมือเขียนแล้ว การสืบค้นก็น่าจะง่ายขึ้นด้วย แต่นั่นคือการนับซ้ำที่ไม่มีหลักฐานรองรับ

ผลประโยชน์สุทธิต่อปีคือ 1,218,750 − 580,000 = 638,750 THB ต่อปี และระยะเวลาคืนทุนอย่างง่ายคือ 2,300,000 ÷ 638,750 = ประมาณ 3.6 ปี

ค่าใช้งาน 120,000 THB เป็นค่าสมมติ ในความเป็นจริง ค่าใช้งานอาจผันแปรตามจำนวนครั้งที่เรียก ตัวอย่างเช่น Dynamics 365 ERP MCP ที่กล่าวไว้ข้างต้น เป็นระบบที่ใช้ 0.1 Copilot Credit ต่อการเรียก 1 ครั้งจากไคลเอนต์อื่นที่ไม่ใช่ Copilot Studio การประมาณว่าเครื่องมือจะถูกเรียกบ่อยเพียงใด ทำได้แม่นยำที่สุดจากล็อกในช่วงทดลองใช้

จุดสำคัญที่ 1: เมื่อดูผลรวม 5 ปี การเพิ่มเครื่องมือเขียนแทบไม่สร้างความแตกต่าง

หากดูเพียงผลประโยชน์สุทธิรายปี โครงสร้างที่ 2 (638,750 THB ต่อปี) มากกว่าโครงสร้างที่ 1 (463,750 THB ต่อปี) อยู่ปีละ 175,000 THB ดูเหมือนว่าการเพิ่มเครื่องมือเขียนจะคุ้มกว่า แต่เมื่อเปรียบเทียบผลรวม 5 ปีหลังหักเงินลงทุนเริ่มต้นแล้ว ภาพจะเปลี่ยนไป

โครงสร้างที่ 2 มีเงินลงทุนเริ่มต้นมากกว่า 900,000 THB แต่ผลประโยชน์สุทธิที่เพิ่มขึ้นปีละ 175,000 THB เรียกคืนได้เพียง 875,000 THB ใน 5 ปี ผลคือเมื่อดูผลรวม 5 ปี โครงสร้างที่ 1 มากกว่าอยู่ 25,000 THB

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

จุดสำคัญที่ 2: สิ่งที่ชี้ขาดการคืนทุนคือตัวแปรเพียงตัวเดียว

ยังมีอีกเรื่องสำคัญที่เห็นได้จากการประมาณการ ระยะเวลาคืนทุนของการลงทุนนี้แทบถูกกำหนดด้วยตัวแปรเพียงตัวเดียว คือ “อัตราการลดเวลาสืบค้นข้อมูล”

ลองคำนวณกรณีโครงสร้างที่ 1 ที่อัตราการลดเวลาสืบค้นข้อมูลเป็น 25% แทนที่จะเป็น 45%

• ผลลัพธ์: 7,500 ชั่วโมง × 25% × 250 THB = 468,750 THB ต่อปี
• ผลประโยชน์สุทธิ: 468,750 − 380,000 = 88,750 THB ต่อปี
• คืนทุนอย่างง่าย: 1,400,000 ÷ 88,750 = ประมาณ 15.8 ปี

เพียงอัตราการลดเวลาสืบค้นข้อมูลลดลงจาก 45% เป็น 25% ระยะเวลาคืนทุนก็ยืดจากประมาณ 3.0 ปี เป็นประมาณ 15.8 ปี เนื่องจากค่าดำเนินงานต่อปี 380,000 THB เกิดขึ้นโดยไม่ขึ้นกับอัตราการลด เมื่อผลลัพธ์ลดลงเพียงเล็กน้อย ผลประโยชน์สุทธิจึงถูกกัดกร่อนไปมาก

กล่าวคือ หากสั่งจ้างโดยไม่วัดจริงว่าปัจจุบันใช้เวลากับงานสืบค้นข้อมูลเท่าใด ก็จะไม่สามารถตัดสินใจลงทุนได้เลย หากสมมติฐาน 45 นาทีต่อคนต่อวันแท้จริงแล้วเป็น 20 นาที แม้อัตราการลดจะเท่าเดิม ผลลัพธ์ก็จะเหลือไม่ถึงครึ่ง นี่คือเหตุผลที่แผน 90 วันซึ่งจะกล่าวถึงต่อไป ใช้ 30 วันแรกสำหรับ “การวัดงานสืบค้นข้อมูลจริง”

12 หัวข้อที่ควรเขียนใน RFP ระบบ MCP

เมื่อนำการออกแบบ 3 ชั้นและบทเรียนจากเหตุการณ์ที่กล่าวมาทั้งหมดมาแปลงเป็นข้อกำหนดการจัดจ้าง (RFP) จะได้ 12 หัวข้อต่อไปนี้ ไม่ว่าจะใช้เซิร์ฟเวอร์สำเร็จรูปหรือจ้างผู้รับจ้างสร้าง การขอให้ตอบทั้ง 12 หัวข้อนี้จะช่วยให้เปรียบเทียบข้อเสนอได้ง่ายขึ้น

โดยเฉพาะหัวข้อที่ 12 เป็นหัวข้อที่มักถูกมองข้ามเมื่อเปรียบเทียบใบเสนอราคา ข้อกำหนด MCP ยังเป็นมาตรฐานที่เคลื่อนไหวอยู่ ดังที่ฉบับ 2026-07-28 มีการเปลี่ยนแปลงใหญ่ เช่น การยกเลิกเซสชันและการประกาศให้ HTTP+SSE เป็น Deprecated เมื่อนโยบายกำหนดให้มีช่วง Deprecated อย่างน้อย 12 เดือนก่อนยกเลิกฟังก์ชัน จึงควรตัดสินใจตั้งแต่ตอนจัดจ้างว่า จะรวม “การแก้ไขระบบภายใน 12 เดือนหลังประกาศ Deprecated” ไว้ในสัญญาบำรุงรักษา หรือจะแยกเสนอราคาต่างหาก หากส่วนนี้คลุมเครือ จะเกิดค่าแก้ไขระบบที่ไม่คาดคิดตั้งแต่ปีที่ 2 เป็นต้นไป

ประเด็นด้านสัญญา เช่น ขอบเขตการบำรุงรักษาและการจัดการความชำรุดบกพร่อง โปรดอ่าน “สาระสำคัญของสัญญาพัฒนาระบบ” ประกอบด้วย

สิ่งที่ต้องยืนยันใน FAT/SAT: การทดสอบเพื่อตรวจรับ MCP Server

12 หัวข้อที่เขียนไว้ใน RFP จะมีความหมายก็ต่อเมื่อได้ยืนยันในการทดสอบก่อนส่งมอบจากโรงงานผู้ผลิต (FAT) และการทดสอบตรวจรับ ณ หน้างาน (SAT) หัวข้อทดสอบเฉพาะของ MCP Server มีดังนี้

การทดสอบ injection ไม่ได้จบเมื่อผ่านเพียงครั้งเดียว ผลอาจเปลี่ยนไปทุกครั้งที่มีการอัปเดตโมเดลหรือเพิ่มเครื่องมือ จึงควรเก็บชุดเอกสารทดสอบไว้เป็นทรัพย์สิน และรันเป็นการทดสอบถดถอยทุกครั้งที่มีการแก้ไขระบบ วิธีวางโครงสร้างการทดสอบเพื่อตรวจรับ AI Agent โดยรวม ได้อธิบายไว้อย่างละเอียดใน “การทดสอบเพื่อตรวจรับ AI Agent“

ประเด็นเฉพาะของประเทศไทย: PDPA ร่างกฎหมาย AI และการดำเนินงานหลายไซต์

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

1. การโอนข้อมูลส่วนบุคคลไปต่างประเทศตาม PDPA

หากโมเดลภาษาที่ Agent ใช้ทำงานอยู่บนคลาวด์ในต่างประเทศ ค่าที่เครื่องมือส่งกลับจะถูกส่งต่อไปยัง LLM API ในต่างประเทศโดยตรง หากค่าที่ส่งกลับมีข้อมูลส่วนบุคคล เช่น ชื่อพนักงาน รหัสพนักงาน หรือชื่อผู้ติดต่อของคู่ค้า ก็จะเกี่ยวข้องกับหลักเกณฑ์การโอนข้อมูลไปต่างประเทศตามพระราชบัญญัติคุ้มครองข้อมูลส่วนบุคคลของไทย (PDPA)

ในประเทศไทย คณะกรรมการคุ้มครองข้อมูลส่วนบุคคล (PDPC) ได้ออกประกาศเกี่ยวกับการโอนข้อมูลไปต่างประเทศ 2 ฉบับเมื่อวันที่ 25 ธันวาคม 2023 และมีผลบังคับใช้เมื่อวันที่ 24 มีนาคม 2024 มาตรา 28 เป็นกรอบที่ตั้งอยู่บนเงื่อนไขว่าประเทศหรือภูมิภาคปลายทางมีมาตรฐานการคุ้มครองที่เพียงพอ ส่วนมาตรา 29 เป็นกรอบที่อาศัยมาตรการคุ้มครองที่เหมาะสม เช่น นโยบายการคุ้มครองข้อมูลส่วนบุคคลภายในกลุ่มบริษัท (BCR) หรือข้อสัญญามาตรฐาน การใช้ LLM ของบริษัทท่านจัดอยู่ในกรอบใดได้ จำเป็นต้องยืนยันเป็นรายกรณีกับฝ่ายกฎหมายหรือผู้เชี่ยวชาญ

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

2. ร่างพระราชบัญญัติ AI ของไทย

ในประเทศไทย สำนักงานพัฒนาธุรกรรมทางอิเล็กทรอนิกส์ (ETDA) ได้เผยแพร่ร่างกฎหมาย AI ฉบับใหม่ในเดือนกรกฎาคม 2026 และจัดรับฟังความคิดเห็น ร่างนี้เป็นกรอบแบบอิงความเสี่ยงที่อ้างอิงกฎระเบียบ AI ของ EU โดยจัดประเภท AI ตามระดับความเสี่ยง และกำหนดโทษปรับทางปกครองสำหรับการฝ่าฝืนไว้ที่ 1 ล้านถึง 5 ล้านบาท อย่างไรก็ตาม ณ เดือนตุลาคม 2026 ร่างนี้ ยังอยู่ในขั้นร่างและยังไม่ผ่านเป็นกฎหมาย เนื้อหาและกำหนดเวลาในอนาคตอาจเปลี่ยนแปลงได้ สำหรับการใช้ Agent ในงานของโรงงาน โปรดยืนยันสถานการณ์ล่าสุดกับผู้เชี่ยวชาญหรือหน่วยงานที่กำกับดูแล

3. แนวทางธรรมาภิบาล AI ของ ETDA

ETDA ได้เผยแพร่แนวทางธรรมาภิบาล AI สำหรับผู้บริหารในปี 2023 และเมื่อวันที่ 30 ตุลาคม 2024 กระทรวงดิจิทัลเพื่อเศรษฐกิจและสังคม (DE) ร่วมกับ ETDA ได้ประกาศแนวทางธรรมาภิบาล Generative AI สำหรับองค์กร ทั้งสองฉบับเป็นแนวทางที่ไม่มีผลผูกพันทางกฎหมาย แม้จะไม่ใช่ข้อบังคับทางกฎหมาย แต่สามารถใช้เป็นแหล่งอ้างอิงในการจัดทำระเบียบภายในบริษัทหรือข้อกำหนดที่ใช้กับผู้รับจ้างได้

4. การดำเนินงานหลายไซต์และหลายภาษา

โครงสร้างที่ใช้ MCP Server ตัวเดียวกันร่วมกันระหว่างไทย เวียดนาม และสำนักงานใหญ่ในญี่ปุ่น เป็นรูปแบบที่พบได้บ่อยในผู้ผลิตญี่ปุ่น ซึ่งมีประเด็นในทางปฏิบัติ 2 ข้อ

ข้อแรกคือ การแยกข้อมูลตามไซต์ ที่กล่าวไว้ข้างต้น ดังที่กรณีของ Asana แสดงให้เห็น การมองเห็นข้อมูลข้ามองค์กรอาจพังทลายได้แม้จากข้อบกพร่องเพียงอย่างเดียว ยิ่งจำนวนไซต์เพิ่มขึ้น การทดสอบการแยกข้อมูลก็ยิ่งสำคัญ

ข้อที่สองคือ ภาษาของคำอธิบายเครื่องมือ เนื่องจากคำอธิบายเครื่องมือคือข้อกำหนดที่โมเดลอ่าน การเขียนด้วยภาษาเดียวที่สอดคล้องกันตลอด จะทำให้พฤติกรรมของโมเดลแปรผันตามไซต์น้อยกว่าการทำฉบับภาษาไทย ภาษาเวียดนาม และภาษาญี่ปุ่นแยกตามไซต์ แม้ผู้ใช้จะถามด้วยภาษาของไซต์ตน แต่ส่วนที่โมเดลอ่านคำอธิบายแล้วเลือกเครื่องมือนั้นเป็นส่วนร่วมกัน นอกจากนี้ หากทำพจนานุกรมให้ศัพท์เฉพาะงานที่ปรากฏในค่าที่ส่งกลับ (รหัสชิ้นส่วน ชื่อกระบวนการ ประเภทของเสีย ฯลฯ) ตรงกัน คำถามเดียวกันก็จะได้คำตอบเดียวกันในทุกไซต์ ทั้งนี้ เซิร์ฟเวอร์สำเร็จรูปบางตัว เช่น Dynamics 365 ERP MCP รองรับเพียงภาษาอังกฤษแบบสหรัฐอเมริกา จึงควรใส่เรื่องการจัดการภาษาไว้เป็นหัวข้อตรวจสอบในการคัดเลือกผลิตภัณฑ์ด้วย

แผน 90 วันสำหรับการนำ MCP มาใช้: เริ่มจากการวัดจริง

สรุปเนื้อหาทั้งหมดที่กล่าวมาเป็นแผน 90 วันแรก ประเด็นสำคัญคือไม่เริ่มสร้างระบบทันที แต่ ใช้ 30 วันแรกสำหรับการวัดงานสืบค้นข้อมูลจริง ดังที่เห็นในหัวข้อต้นทุน ระยะเวลาคืนทุนแทบถูกกำหนดด้วยตัวแปรเดียวคืออัตราการลดเวลาสืบค้นข้อมูล หากไม่รู้จุดเริ่มต้นว่า “ปัจจุบันใช้เวลาไปเท่าใด” ก็จะไม่สามารถตัดสินใจลงทุนได้

วันที่ 0-30: วัดงานสืบค้นข้อมูลจริงและรวบรวมรายการเครื่องมือที่เป็นไปได้

• ขอให้ผู้รับผิดชอบฝ่ายควบคุมการผลิต ฝ่ายประกันคุณภาพ และฝ่ายจัดซื้อ บันทึกเวลาและเนื้อหาของงานสืบค้นข้อมูลเป็นเวลา 1-2 สัปดาห์ (ค้นหาอะไร ในระบบใด ใช้เวลากี่นาที)
• จากบันทึก คัดเลือกงานสืบค้นที่ใช้เวลามากที่สุดในลำดับต้นๆ มาเป็นเครื่องมือตามหน่วยของงานที่เป็นไปได้
• สำหรับเครื่องมือที่เป็นไปได้แต่ละตัว จัดระเบียบระบบต้นทาง รายการที่ควรส่งกลับ รายการที่ห้ามส่งกลับ (เช่น ข้อมูลส่วนบุคคล) และฝ่ายที่อนุญาตให้ใช้
• แยกส่วนที่ MCP Server สำเร็จรูปรองรับได้ ออกจากส่วนที่ต้องสร้างเอง

สิ่งส่งมอบของขั้นนี้คือค่าที่วัดได้จริงของงานสืบค้นข้อมูล และรายการเครื่องมือที่เป็นไปได้ (พร้อมระบุประเภทอ่าน/เขียน) ซึ่งจะกลายเป็นค่าสมมติฐานของการประมาณการโดยตรง และเป็นร่างของรายการเครื่องมือใน RFP ด้วย

วันที่ 31-60: ทดลองใช้เครื่องมืออ่านอย่างเดียว 2-3 รายการ

• นำงานสืบค้น 2-3 รายการที่อยู่ในอันดับต้นๆ จากการวัดจริง มาสร้างต้นแบบเป็นเครื่องมืออ่านอย่างเดียว
• ใส่กลไกการอนุญาตสิทธิ์ (ไม่เกินสิทธิ์ของผู้ร้องขอ) และล็อกการตรวจสอบตามแนวคิดเดียวกับระบบจริงตั้งแต่ขั้นทดลอง
• ทดลองใช้กับผู้ใช้กลุ่มจำกัด และวัดว่าเวลาสืบค้นข้อมูลลดลงเท่าใด ด้วยวิธีเดียวกับการวัดจริงใน 30 วันแรก
• ใช้ล็อกค้นหาการเลือกเครื่องมือผิด คำอธิบายที่ไม่เพียงพอ และค่าที่ส่งกลับที่มากหรือน้อยเกินไป แล้วปรับปรุง

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

วันที่ 61-90: FAT/SAT และการตัดสินว่าจำเป็นต้องมีการเขียนหรือไม่

• ดำเนินการ FAT/SAT ตามหัวข้อทดสอบในหัวข้อก่อนหน้า และยืนยันการปฏิเสธการเรียกนอกสิทธิ์ การแยกข้อมูลตามไซต์ และความครบถ้วนของล็อก
• จัดทำชุดเอกสารทดสอบ injection และเก็บไว้เป็นทรัพย์สินสำหรับการทดสอบถดถอย
• ลองดำเนินงานจริงว่าใครจะดูล็อกการตรวจสอบ และดูบ่อยเพียงใด
• หลังจากยืนยันว่าการดำเนินงานของการอ่านเป็นไปได้ด้วยดีแล้ว จึงตัดสินว่าจะเพิ่มเครื่องมือเขียน (ร่างและออกเอกสาร) หรือไม่

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

คำถามที่พบบ่อย (FAQ)

MCP Server คืออะไร และแตกต่างจาก API อย่างไร

MCP Server คือเคาน์เตอร์รับเรื่องที่สร้างขึ้นตามมาตรฐานร่วม (MCP) ซึ่ง AI Agent ใช้เรียกข้อมูลหรือฟังก์ชันของระบบภายนอก API ตั้งอยู่บนสมมติฐานว่านักพัฒนาเรียกใช้จากโปรแกรม โดยโปรแกรมเป็นผู้กำหนดลำดับและขอบเขตของการเรียก ส่วนเครื่องมือของ MCP นั้น Agent จะอ่านคำอธิบายแล้วเลือกเรียกด้วยการตัดสินใจของตัวเอง คำอธิบายเครื่องมือจึงเป็นข้อกำหนดที่โมเดลอ่าน และขอบเขตที่เรียกได้ก็คือขีดจำกัดสูงสุดของความเสียหายเมื่อเกิดเหตุ สิ่งสำคัญคือการออกแบบเครื่องมือใหม่ตามหน่วยของงาน ไม่ใช่การนำ API ที่มีอยู่มาห่อไว้ตรงๆ

การสร้าง MCP Server มีค่าใช้จ่ายเท่าใด

ค่าใช้จ่ายแตกต่างกันมากตามจำนวนงานเป้าหมาย การมีเพียงการอ่านหรือรวมการเขียนด้วย และการใช้เซิร์ฟเวอร์สำเร็จรูปได้หรือไม่ ในการประมาณการด้วยโรงงานจำลองของบทความนี้ (งานสืบค้นข้อมูล 7,500 ชั่วโมงต่อปี) กำหนดไว้ว่าโครงสร้างแบบอ่านอย่างเดียวมีเงินลงทุนเริ่มต้น 1,400,000 THB และค่าดำเนินงานต่อปี 380,000 THB ส่วนโครงสร้างที่เพิ่มการเขียนมีเงินลงทุนเริ่มต้น 2,300,000 THB และค่าดำเนินงานต่อปี 580,000 THB ตัวเลขเหล่านี้เป็นค่าประมาณการที่บทความนี้จัดทำขึ้นเอง ไม่ใช่ราคาตลาด เนื่องจากระยะเวลาคืนทุนเปลี่ยนแปลงมากตามอัตราการลดเวลาสืบค้นข้อมูล จึงขอแนะนำให้เริ่มจากการวัดงานสืบค้นข้อมูลจริงก่อน

ควรเลือก MCP Server สำเร็จรูป (ที่ผู้ขาย ERP จัดให้) หรือสร้างเองตั้งแต่ต้น

สำหรับงานสืบค้นและการออกเอกสารที่จบภายใน ERP เซิร์ฟเวอร์สำเร็จรูปอย่าง Dynamics 365 ERP MCP หรือ AWS for SAP MCP Server จะเริ่มใช้งานได้เร็ว ในทางกลับกัน เครื่องมือตามหน่วยของงานที่ข้าม MES, QMS และ ERP อย่าง “ประวัติย้อนกลับของล็อต” มักต้องสร้างเอง (หรือจ้างสร้าง) ไม่ว่าจะเลือกแบบใด การกำหนดว่าจะให้สิทธิ์ใดแก่ Agent และจะเก็บหลักฐานการตรวจสอบอย่างไร ใครเป็นผู้ดู ยังคงเป็นงานที่ฝ่ายผู้ว่าจ้างต้องตัดสินใจ

สิ่งที่ต้องกำหนดเป็นอันดับแรกในความปลอดภัย MCP คืออะไร

คือหลักการ “สิทธิ์ของ Agent ต้องไม่เกินสิทธิ์ของผู้ที่ร้องขอ” จากนั้นจึงกำหนดเรื่องต่อไปนี้ ได้แก่ กำหนด scope ตามหน่วยของงานและไม่มี scope แบบครอบคลุมทั้งหมด ให้เซิร์ฟเวอร์ตรวจสอบปลายทางของโทเคนและไม่ส่งต่อโทเคน บันทึกการเรียกเครื่องมือทุกครั้งไว้ในล็อกการตรวจสอบ และจัดทำ allowlist ของ MCP Server และแพ็กเกจที่พึ่งพาซึ่งอนุญาตให้ใช้ หากมีความเป็นไปได้ที่จะส่งข้อมูลส่วนบุคคลไปยัง LLM ในต่างประเทศ โปรดยืนยันเรื่องการโอนข้อมูลไปต่างประเทศตาม PDPA เป็นรายกรณีกับฝ่ายกฎหมายหรือผู้เชี่ยวชาญ

เชื่อม PLC หรือเครื่องจักรเข้ากับ AI ผ่าน MCP ได้หรือไม่

บทความนี้แนะนำให้การเขียนไปยัง PLC และระบบควบคุมอยู่นอกขอบเขตของ MCP เพราะการเขียนไปยังระบบควบคุมเมื่อผิดพลาดแล้วไม่สามารถย้อนกลับภายหลังได้ และส่งผลโดยตรงต่อเครื่องจักรและความปลอดภัยของคน OPC UA MCP Server ของ OPC Foundation แม้ในเวอร์ชันล่าสุด 2.0.0-preview.6 ที่เผยแพร่เมื่อวันที่ 30 กันยายน 2026 ก็ยังอยู่ในขั้นพรีวิว จึงสมควรไม่นำไปใช้กับงานควบคุมในระบบจริง และจำกัดไว้เพียงการอ่านข้อมูลในสภาพแวดล้อมทดสอบ

ใช้เวลานานเท่าใดจึงจะนำมาใช้ได้

บทความนี้เสนอให้วางแผน 90 วันแรกเป็น 3 ขั้น ได้แก่ วันที่ 0-30 วัดงานสืบค้นข้อมูลจริงและรวบรวมรายการเครื่องมือที่เป็นไปได้ วันที่ 31-60 ทดลองใช้เครื่องมืออ่านอย่างเดียว 2-3 รายการ และวันที่ 61-90 ทำ FAT/SAT และตัดสินว่าจำเป็นต้องมีการเขียนหรือไม่ ระยะเวลาจนถึงการขยายใช้งานเต็มรูปแบบในระบบจริง ขึ้นอยู่กับจำนวนงานเป้าหมาย จำนวนไซต์ และการมีเซิร์ฟเวอร์สำเร็จรูปหรือไม่ ทั้งนี้ ณ เดือนตุลาคม 2026 ร่างพระราชบัญญัติ AI ของไทยยังอยู่ในขั้นร่างที่ยังไม่ผ่านเป็นกฎหมาย สำหรับประเด็นด้านกฎระเบียบ โปรดยืนยันเป็นรายกรณีกับผู้เชี่ยวชาญหรือหน่วยงานที่กำกับดูแล

สรุป: การสร้าง MCP Server คือการสร้าง “หน้าต่างสู่งาน”

• สร้าง MCP Server เป็น “หน้าต่างสู่งาน” ไม่ใช่ “หน้าต่างสู่ฐานข้อมูล” หากใช้ Connector อเนกประสงค์ต่อฐานข้อมูลหรือ ERP ทั้งระบบ จะเผชิญ 3 ปัญหาพร้อมกัน คือ สิทธิ์มากเกินไป ไม่มีหลักฐานการตรวจสอบ และตรวจรับงานไม่ได้
• ความสำเร็จขึ้นอยู่กับ 3 ชั้น ได้แก่ (1) การออกแบบเครื่องมือตามหน่วยของงาน (2) การอนุญาตสิทธิ์ที่ไม่เกินสิทธิ์ของผู้ร้องขอ และ (3) หลักฐานการตรวจสอบของการเรียกทุกครั้ง
• แยกการอ่านและการเขียนออกจากกัน และให้การเขียน “ทำได้ถึงขั้นร่างและออกเอกสาร ส่วนการยืนยันเป็นหน้าที่ของคน” การเขียนไปยัง PLC และระบบควบคุมอยู่นอกขอบเขตของ MCP
• การเปิดเผยข้อมูลข้ามองค์กรของ Asana, Toxic Agent Flow, ช่องโหว่ของเครื่องมือทางการ และ postmark-mcp แสดงให้เห็นว่าการแยกข้อมูลตามไซต์ การจัดการเอกสารภายนอก การจัดการเวอร์ชัน และ allowlist ล้วนเป็นข้อกำหนดในการออกแบบ
• ในการประมาณการของโรงงานจำลอง โครงสร้างที่ 1 แบบอ่านอย่างเดียวมีผลประโยชน์สุทธิ 463,750 THB ต่อปี และคืนทุนในประมาณ 3.0 ปี ส่วนโครงสร้างที่ 2 ที่เพิ่มการเขียนมีผลประโยชน์สุทธิ 638,750 THB ต่อปี และคืนทุนในประมาณ 3.6 ปี เมื่อดูผลรวม 5 ปี โครงสร้างที่ 1 ได้ 918,750 THB และโครงสร้างที่ 2 ได้ 893,750 THB ส่วนต่างอยู่ที่เพียง 25,000 THB
• หากอัตราการลดเวลาลดลงจาก 45% เป็น 25% ระยะเวลาคืนทุนของโครงสร้างที่ 1 จะยืดเป็นประมาณ 15.8 ปี การตัดสินใจลงทุนจึงทำไม่ได้หากไม่วัดงานสืบค้นข้อมูลจริง
• ใน RFP ให้เขียน 12 หัวข้อ ซึ่งรวมถึงฉบับข้อกำหนด วิธีการอนุญาตสิทธิ์ รายการ scope และเครื่องมือ ล็อกการตรวจสอบ การแยกข้อมูลตามไซต์ การรับมือช่องโหว่ และการตามทันการแก้ไขข้อกำหนด

MCP เปลี่ยนโฉมไปมากในฉบับ 2026-07-28 และยังเป็นมาตรฐานที่เคลื่อนไหวอยู่ ด้วยเหตุนี้ สิ่งที่เป็นการเตรียมพร้อมที่มั่นคงที่สุดสำหรับฝ่ายผู้ว่าจ้าง คือการกำหนดส่วนที่ไม่เปลี่ยนแปลงแม้ข้อกำหนดจะเปลี่ยน ได้แก่ จะทำงานใดให้เป็นเครื่องมือ จะอนุญาตให้ใครทำอะไร และจะบันทึกอะไร ให้ชัดเจนก่อนรายละเอียดของข้อกำหนด

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

ข้อมูลอ้างอิง

• ข้อกำหนด MCP (ฉบับล่าสุด): https://modelcontextprotocol.io/specification/latest
• ประวัติการเปลี่ยนแปลงข้อกำหนด MCP ฉบับ 2026-07-28: https://modelcontextprotocol.io/specification/2026-07-28/changelog
• บล็อกทางการของ MCP “The 2026-07-28 Specification”: https://blog.modelcontextprotocol.io/posts/2026-07-28/
• ข้อกำหนด MCP ฉบับ 2026-07-28 ด้านการอนุญาตสิทธิ์: https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization
• MCP Security Best Practices (ฉบับ 2025-11-25): https://modelcontextprotocol.io/specification/2025-11-25/basic/security_best_practices
• ประกาศจัดตั้ง “Agentic AI Foundation” ของ Linux Foundation: https://www.linuxfoundation.org/press/linux-foundation-announces-the-formation-of-the-agentic-ai-foundation
• OWASP MCP Top 10: https://owasp.org/www-project-mcp-top-10/
• NVD CVE-2025-6514: https://nvd.nist.gov/vuln/detail/CVE-2025-6514
• GitHub Advisory GHSA-6xpm-ggf7-wc3p: https://github.com/advisories/GHSA-6xpm-ggf7-wc3p
• NVD CVE-2025-49596: https://nvd.nist.gov/vuln/detail/CVE-2025-49596
• GitHub Advisory GHSA-7f8r-222p-6f5g: https://github.com/advisories/GHSA-7f8r-222p-6f5g
• NVD CVE-2025-68143: https://nvd.nist.gov/vuln/detail/CVE-2025-68143
• NVD CVE-2025-68144: https://nvd.nist.gov/vuln/detail/CVE-2025-68144
• NVD CVE-2025-68145: https://nvd.nist.gov/vuln/detail/CVE-2025-68145
• Invariant Labs (Toxic Agent Flow ของ GitHub MCP): https://invariantlabs.ai/blog/mcp-github-vulnerability
• BleepingComputer (การเปิดเผยข้อมูลข้ามองค์กรของ Asana MCP): https://www.bleepingcomputer.com/news/security/asana-warns-mcp-ai-feature-exposed-customer-data-to-other-orgs/
• The Hacker News (postmark-mcp): https://thehackernews.com/2025/09/first-malicious-mcp-server-found.html
• Microsoft Learn “Dynamics 365 ERP MCP”: https://learn.microsoft.com/en-us/dynamics365/fin-ops-core/dev-itpro/copilot/copilot-mcp
• AWS การเปิดให้บริการทั่วไปของ “AWS for SAP MCP Server”: https://aws.amazon.com/about-aws/whats-new/2026/05/aws-sap-mcp-amazon-bedrock/
• NuGet “OPCFoundation.NetStandard.Opc.Ua.Mcp”: https://www.nuget.org/packages/OPCFoundation.NetStandard.Opc.Ua.Mcp
• Tilleke & Gibbins (การโอนข้อมูลส่วนบุคคลไปต่างประเทศตาม PDPA ของไทย): https://www.tilleke.com/insights/thailand-unveils-regulations-for-cross-border-personal-data-transfer/
• Tilleke & Gibbins (ร่างพระราชบัญญัติ AI ของไทย): https://www.tilleke.com/insights/thailand-releases-new-draft-artificial-intelligence-act
• Rajah & Tann Asia (ร่างพระราชบัญญัติ AI ของไทย): https://www.rajahtannasia.com/viewpoints/thailands-proposed-ai-law-moving-towards-a-risk-based-regulatory-framework/
• OECD.AI (AI Governance Guideline for Executives): https://oecd.ai/en/dashboards/policy-initiatives/ai-governance-guideline-for-executives-8517
• Digital Policy Alert (Generative AI Governance Guideline for Organisations): https://digitalpolicyalert.org/change/11675-de-and-etda-generative-ai-governance-guideline-for-organisations
• Gartner (ประกาศเมื่อวันที่ 25 มิถุนายน 2025): https://www.gartner.com/en/newsroom/press-releases/2025-06-25-gartner-predicts-over-40-percent-of-agentic-ai-projects-will-be-canceled-by-end-of-2027