เชื่อม MCP กับ LINE OA ให้ AI Agent เรียกดูออเดอร์และสต็อกจริงระหว่างคุยกับลูกค้าได้ยังไง

AI Chatbot ที่ตอบคำถามได้จากเอกสารและข้อมูลนโยบายของบริษัทเพียงอย่างเดียว มีข้อจำกัดชัดเจนเมื่อลูกค้าถามคำถามที่ต้องการข้อมูล Real-time เช่น สถานะออเดอร์ของตัวเองตอนนี้ถึงไหนแล้ว หรือสินค้ารุ่นนี้ยังมีของเหลืออยู่ไหม เพราะข้อมูลแบบนี้เปลี่ยนแปลงตลอดเวลาและไม่สามารถเก็บไว้ล่วงหน้าในระบบค้นหาแบบ RAG ได้

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

บทความนี้จะพาไล่ดูว่า MCP ทำงานอย่างไร เมื่อนำมาต่อกับ LINE OA ช่วยให้ Chatbot ทำอะไรได้เพิ่มขึ้นบ้าง และมีข้อจำกัดหรือความเสี่ยงอะไรที่ทีมต้องพิจารณาก่อนเปิดให้ AI เข้าถึงระบบหลังบ้านจริง ต่อยอดจากแนวคิด RAG ที่เคยพูดถึงใน line-oa-rag และการรับ Event จาก LINE ตามหลักการใน line-webhook-vercel

ข้อจำกัดของ RAG ที่ทำให้ต้องมี MCP เข้ามาเสริม

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

ทางแก้แบบเดิมที่ทีมพัฒนาเคยใช้คือเขียนโค้ดเฉพาะเพื่อเชื่อม AI เข้ากับแต่ละระบบโดยตรง เช่น เขียนฟังก์ชันเรียก API ระบบออเดอร์ เขียนฟังก์ชันเรียก API ระบบสต็อกแยกกัน แล้วสอนให้ AI รู้ว่าเมื่อไหร่ควรเรียกฟังก์ชันไหน วิธีนี้ใช้งานได้แต่ขยายยาก เพราะทุกครั้งที่เพิ่มระบบใหม่ ต้องเขียนโค้ดเชื่อมต่อและปรับ Prompt ใหม่ทุกครั้ง

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

MCP ทำงานอย่างไรในภาพรวม

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

เมื่อลูกค้าถามคำถามที่ต้องการข้อมูล Real-time เช่น 'ออเดอร์ของฉันถึงไหนแล้ว' AI Agent จะพิจารณาจากรายการเครื่องมือที่มี แล้วเลือกเรียกเครื่องมือเช็คสถานะออเดอร์ พร้อมส่ง Parameter ที่จำเป็น เช่น หมายเลขออเดอร์หรือ User ID ไปยัง MCP Server จากนั้น Server จะไปดึงข้อมูลจริงจากระบบหลังบ้านมาตอบกลับ แล้ว AI นำผลลัพธ์นั้นมาสรุปเป็นคำตอบภาษาธรรมชาติให้ลูกค้า

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

ตัวอย่างสถานการณ์การใช้ MCP ร่วมกับ LINE OA

เมื่อลูกค้าทักเข้ามาทาง LINE OA แล้วถามคำถามที่ต้องการข้อมูล Real-time Webhook จะรับ Event เข้ามาตามหลักการปกติ แล้วส่งข้อความของลูกค้าไปให้ AI Agent ประมวลผล ถ้า AI Agent พิจารณาแล้วว่าคำถามนี้ต้องการข้อมูลจากระบบหลังบ้าน จะเรียกใช้เครื่องมือที่เกี่ยวข้องผ่าน MCP Server แทนที่จะพยายามตอบจากความรู้ทั่วไปหรือข้อมูลที่เก็บไว้ล่วงหน้า

ตัวอย่างเช่น ธุรกิจขายของออนไลน์ที่มีระบบจัดการออเดอร์อยู่แล้ว สามารถสร้าง MCP Server ที่เปิดเครื่องมือเช็คสถานะออเดอร์จากหมายเลขโทรศัพท์หรือ LINE User ID ที่ผูกไว้กับบัญชีลูกค้า เมื่อลูกค้าถามสถานะออเดอร์ AI จะเรียกเครื่องมือนี้ ได้ข้อมูลสถานะล่าสุดกลับมา แล้วตอบลูกค้าด้วยข้อมูลที่ถูกต้อง ณ เวลานั้นจริงๆ ไม่ใช่ข้อมูลเก่าที่เก็บไว้ล่วงหน้า

สถานการณ์อีกแบบที่ใช้ได้ผลดีคือระบบเช็คสต็อกสินค้า เมื่อลูกค้าถามว่าสินค้ารุ่นหนึ่งยังมีของไหม AI สามารถเรียกเครื่องมือเช็คสต็อกแบบ Real-time แทนที่จะตอบจากข้อมูลที่อาจล้าสมัยไปแล้ว ซึ่งช่วยลดปัญหาที่ลูกค้าสั่งซื้อสินค้าที่หมดสต็อกไปแล้วโดยไม่รู้ตัว

ควบคุมสิทธิ์การเข้าถึงให้รัดกุมก่อนเปิดให้ AI เรียกระบบจริง

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

แนวทางที่ปลอดภัยกว่าคือ MCP Server ควรตรวจสอบสิทธิ์จาก Context ของ Session การสนทนา เช่น LINE User ID ที่ยืนยันตัวตนแล้ว แทนที่จะเชื่อ Parameter ที่ AI ส่งมาโดยตรงทั้งหมด เพราะ AI อาจถูกป้อนคำสั่งแปลกปลอมจากข้อความของผู้ใช้ที่พยายามหลอกให้ AI ทำสิ่งที่ไม่ควรทำ ซึ่งเป็นความเสี่ยงที่เรียกว่า Prompt Injection

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

จัดการ Error เมื่อระบบหลังบ้านไม่ตอบสนองหรือมีปัญหา

ระบบหลังบ้านที่ AI เรียกผ่าน MCP อาจล้มเหลวได้ด้วยเหตุผลหลายอย่าง เช่น ระบบกำลังบำรุงรักษา เชื่อมต่อไม่ได้ชั่วคราว หรือข้อมูลที่ค้นหาไม่พบ ทีมต้องออกแบบให้ AI จัดการสถานการณ์เหล่านี้ได้อย่างเหมาะสม ไม่ใช่ปล่อยให้ AI สร้างคำตอบขึ้นมาเองเมื่อเรียกเครื่องมือไม่สำเร็จ ซึ่งจะกลับไปเป็นปัญหา Hallucination แบบเดียวกับที่ RAG พยายามแก้

แนวทางที่ควรทำคือกำหนดใน Prompt ให้ชัดเจนว่าถ้าเครื่องมือคืนค่า Error หรือไม่มีข้อมูล ให้ AI แจ้งลูกค้าตามตรงว่าไม่สามารถดึงข้อมูลได้ในขณะนี้ พร้อมแนะนำให้ลองใหม่ภายหลังหรือติดต่อแอดมิน แทนที่จะเดาคำตอบหรือสร้างข้อมูลปลอมขึ้นมา เพราะความเสียหายจากการตอบผิดเรื่องสถานะออเดอร์จริงมักร้ายแรงกว่าการตอบว่าดึงข้อมูลไม่ได้

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

ธุรกิจแบบไหนควรเริ่มลงทุนทำ MCP Server ของตัวเอง

การสร้าง MCP Server ต้องใช้เวลาพัฒนาและดูแลระบบเพิ่มเติม จึงเหมาะกับธุรกิจที่มีคำถามจากลูกค้าจำนวนมากที่ต้องการข้อมูล Real-time จริงๆ เช่น ธุรกิจที่มีออเดอร์จำนวนมากต่อวันและลูกค้ามักถามสถานะบ่อย หรือธุรกิจที่มีสต็อกสินค้าเปลี่ยนแปลงเร็วจนข้อมูลที่ RAG เก็บไว้ล่วงหน้าไม่ทันสถานการณ์จริง

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

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

เทียบ RAG กับ MCP ให้เห็นว่าใช้เมื่อไหร่

ทั้งสองเทคนิคไม่ได้แข่งกัน แต่ใช้ร่วมกันเพื่อครอบคลุมทั้งข้อมูลคงที่และข้อมูล Real-time ตารางนี้สรุปให้เห็นความต่าง:

สรุป

MCP เปิดทางให้ AI Agent ที่คุยกับลูกค้าผ่าน LINE OA เข้าถึงข้อมูล Real-time จากระบบหลังบ้านได้ในรูปแบบมาตรฐานเดียวกัน แก้ข้อจำกัดของ RAG ที่ตอบได้แค่จากข้อมูลที่เก็บไว้ล่วงหน้า แต่การเปิดให้ AI เรียกระบบจริงมาพร้อมความรับผิดชอบเรื่องความปลอดภัยที่ต้องออกแบบให้รัดกุมตั้งแต่ต้น

ธุรกิจที่จะได้ประโยชน์สูงสุดจาก MCP คือธุรกิจที่มีคำถามเกี่ยวกับข้อมูล Real-time บ่อยจริงๆ ไม่ใช่ทุกธุรกิจที่จำเป็นต้องมี ควรประเมินจากความต้องการจริงของลูกค้าก่อนตัดสินใจลงทุนพัฒนาระบบที่มีความซับซ้อนเพิ่มขึ้นนี้

• MCP เหมาะกับข้อมูล Real-time ที่ RAG เก็บไว้ล่วงหน้าไม่ทัน เช่น สถานะออเดอร์และสต็อก
• ต้องผูกสิทธิ์การเข้าถึงกับตัวตนผู้ใช้จริงเสมอ ไม่เชื่อ Parameter ที่ AI ส่งมาโดยตรง
• เริ่มจากเครื่องมือที่มีคุณค่าสูงสุดก่อน ไม่ต้องพยายามครอบคลุมทุกระบบตั้งแต่วันแรก

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