LINE OA Chatbot คือระบบที่ช่วยรับและตอบข้อความใน LINE Official Account ตามเงื่อนไขหรือความสามารถที่ออกแบบไว้ โดยการทำระบบเชื่อมหลังบ้านมักเกี่ยวข้องกับ LINE Messaging API และ Webhook เพื่อให้แอปของผู้พัฒนาได้รับเหตุการณ์ข้อความและตัดสินใจตอบกลับ

การมี LINE OA ไม่ได้หมายความว่า Bot เชื่อมฐานข้อมูลหรือใช้ AI อยู่แล้ว และการใช้ Messaging API ก็ไม่ได้ทำให้ระบบอ่านประวัติแชตทุกข้อความย้อนหลังได้ ผู้พัฒนาต้องกำหนดว่าเหตุการณ์ใดส่งมาถึง Backend เก็บข้อมูลเท่าใด และใครมีสิทธิ์ดูข้อมูลนั้น

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

LINE Official Account กับ Messaging API ต่างกันอย่างไร

LINE Official Account (LINE OA) เป็นช่องทางที่ธุรกิจใช้ติดต่อผู้ติดตามผ่าน LINE ส่วน Messaging API เป็นชุด API/เหตุการณ์ที่ช่วยให้ระบบภายนอกที่ตั้งค่าและได้รับสิทธิ์เหมาะสมรับ Webhook และส่งข้อความตอบผ่านช่องทางที่รองรับ

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

ถ้าต้องการเทียบการทำบนเว็บกับช่องทางแชต ลองอ่าน คู่มือ Chatbot บนเว็บไซต์ และ ประเภท Chatbot

Webhook รับข้อความอย่างไร

ตามเอกสาร LINE Developers — Receive messages เมื่อเกิดเหตุการณ์ที่เกี่ยวข้อง แพลตฟอร์มสามารถส่ง HTTP POST ที่มี Webhook Event Objects มายัง URL ที่นักพัฒนาลงทะเบียนไว้

ตัวอย่างเส้นทางทำงานเชิงแนวคิด:

ผู้ใช้ส่งข้อความใน LINE
        |
        v
LINE Platform --> POST /webhook (raw request + x-line-signature)
        |
        v
ตรวจ Signature ด้วย Channel Secret ก่อน Parse ข้อมูล
        |
        v
ตรวจ Event ID ซ้ำ + ประเภท Event + สิทธิ์การดำเนินการ
        |
        +--> FAQ / Business Logic / Authorized API
        +--> Human handoff เมื่อเกินขอบเขต
        |
        v
ส่งข้อความตอบด้วย Messaging API ตามเงื่อนไขที่รองรับ

เส้นทางนี้เป็นตัวอย่างอธิบายระบบ ไม่ใช่โค้ดที่พร้อม Deploy โดยตรง เพราะต้องจัดการ HTTP Response, Security, Timeout, Retry และสถานะการส่งข้อความตามเอกสาร API ที่ใช้งานจริงด้วย

ทำไมต้องตรวจ Webhook Signature

การเปิด URL รับ Webhook หมายความว่าใครก็ตามบนอินเทอร์เน็ตอาจลองส่ง HTTP Request มายัง URL นั้นได้ จึงต้องตรวจว่าข้อความที่ได้รับมาจาก LINE และไม่ถูกแก้ไขระหว่างทาง

LINE ระบุให้ตรวจ Header x-line-signature โดยคำนวณ HMAC-SHA256 จาก Raw Request Body ที่ได้รับจริง และ Channel Secret ของ Channel นั้น ก่อน Parse JSON หรือเปลี่ยนข้อความ เพราะการแก้ไขช่องว่างหรือ Escape Character อาจทำให้ลายเซ็นไม่ตรง

  • Channel Secret เป็นความลับ ต้องเก็บไว้ฝั่ง Server ไม่อยู่ใน Client หรือ Repository
  • หาก Signature หายหรือไม่ตรง ให้ปฏิเสธคำขอและไม่ประมวลผล Event
  • ไม่พึ่งการ Allowlist IP แทน Signature Verification เพราะ LINE ไม่เปิดเผย IP ส่ง Webhook สำหรับใช้วิธีนั้น
  • ตรวจผลเปรียบเทียบลายเซ็นอย่างเหมาะสมโดยใช้ Crypto Utility ที่ถูกต้อง ไม่เขียนวิธีเทียบที่รั่วข้อมูลผ่าน Timing โดยไม่จำเป็น

รายละเอียดต้นทางอยู่ใน LINE Developers — Verify webhook signature

Webhook ซ้ำและลำดับที่ไม่ตรงกัน

ระบบจริงอาจได้รับเหตุการณ์เดิมมากกว่าหนึ่งครั้ง และเมื่อเปิดการส่งใหม่ (Redelivery) ลำดับที่รับอาจไม่ตรงกับเวลาที่เกิดเหตุการณ์ LINE ระบุว่าควรใช้ webhookEventId ตรวจรายการซ้ำ และอาศัย Timestamp เมื่อจำเป็นต้องพิจารณาลำดับ

ตัวอย่างสมมติ: ผู้ใช้ส่งคำว่า “ขอรายละเอียด” ครั้งเดียว แต่ Backend ได้ Event เดิมซ้ำสองครั้ง หากเขียนโค้ดให้ทุก Event สร้าง Lead ใหม่ทันที อาจเกิดลูกค้าซ้ำใน CRM ดังนั้นควรออกแบบ Idempotency Key และเก็บสถานะว่า Event นั้นดำเนินการแล้วหรือยัง ก่อนทำ Side Effect

การรับ HTTP สำเร็จกับการส่งข้อความตอบสำเร็จเป็นคนละเหตุการณ์ ควรมี Logging ที่ตรวจย้อนหลังได้โดยไม่เปิดเผยเนื้อหาส่วนตัวเกินความจำเป็น

ข้อสังเกตจากเอกสาร: การเปิด Redelivery และเงื่อนไขจำนวนครั้ง/เวลาที่จะส่งใหม่มีข้อกำหนดของแพลตฟอร์ม และไม่ได้รับประกันว่าทุก Event จะถูกส่งซ้ำจนสำเร็จ ต้องออกแบบระบบให้รองรับความไม่แน่นอน

คำตอบมาจากที่ไหน และเมื่อใดควรใช้ AI

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

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

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

ส่งต่อเจ้าหน้าที่โดยไม่ทำให้ข้อมูลหาย

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

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

สำหรับการเชื่อมกระบวนการรับลีดกับ CRM ที่ยังทำมือเป็นหลัก อ่าน รวมลีดจากเว็บไซต์ LINE OA และ Facebook ซึ่งอธิบายเจ้าของงาน การติดตาม และการจัดข้อมูลลูกค้าโดยไม่สมมติว่าทุกระบบเชื่อมกันแล้ว

ตัวอย่างออกแบบ LINE OA สำหรับธุรกิจบริการ

สถานการณ์จำลอง: บัญชี LINE OA ของบริษัทบริการได้รับข้อความ “อยากประเมินงาน ต้องส่งอะไรบ้าง” ระบบจัดหมวด Intent คำถาม ขอข้อมูลขั้นต่ำจากคู่มือบริษัท และเสนอทางเลือกส่งรูปหรือรายละเอียดเพิ่มเติมตามกระบวนการที่กำหนด

ถ้าลูกค้าถามราคาที่ต้องประเมินเฉพาะหน้างาน Bot บอกว่าต้องให้ทีมประเมิน ไม่สร้างราคาเทียม หากลูกค้ายินยอมให้ติดต่อ ทีมอาจสร้าง Lead ในระบบแยก โดยมีผู้รับผิดชอบและวันติดตาม

ก่อนเปิดใช้จริงควรทดสอบ Event ที่ไม่มีข้อความ, Unfollow/Unsend, Event ซ้ำ, Signature ผิด, Channel Secret ผิด, API ตอบ Error และเจ้าหน้าที่ไม่พร้อมรับเคส เพื่อให้เห็นว่ากรณีปกติและกรณีผิดพลาดถูกจัดการอย่างไร

สิ่งที่ต้องตรวจในเอกสารผู้ให้บริการก่อนใช้งาน

  • ประเภท Channel และเงื่อนไขสมัครใช้ Messaging API ปัจจุบัน
  • สิทธิ์ของผู้ดูแลในการตั้งค่า Webhook และ Channel Secret
  • ข้อจำกัดการตอบ Reply/Push Message และอายุของ Token ที่ใช้ใน Flow นั้น
  • โควตาหรือค่าใช้จ่ายของบัญชีที่เลือก ณ วันที่ Deploy จริง
  • นโยบายเก็บและลบข้อความ โดยเฉพาะกรณีผู้ใช้ Unsend
  • ช่องทางแจ้งผู้ใช้และส่งต่อเจ้าหน้าที่ที่ทีมมีระบบรองรับจริง

ระบบไม่ควรคาดหวังว่า LINE API จะช่วยดึงข้อความย้อนหลังทุกชนิดได้ เอกสารทางการระบุข้อจำกัดการดึงเนื้อหาบางประเภท เช่น ข้อความ text ไม่สามารถเรียกกลับผ่าน API หลังจากรับ Event แล้ว

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

ใช้ LINE OA ตอบแชตอัตโนมัติโดยไม่ใช้ AI ได้ไหม

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

ถ้า Webhook ถูกส่งซ้ำจะเกิดอะไรขึ้น

หากระบบไม่ตรวจ Event ID อาจตอบหรือสร้างข้อมูลซ้ำได้ ผู้พัฒนาควรออกแบบ Idempotency และบันทึกผลการดำเนินการตามความจำเป็น

LINE OA Chatbot อ่านประวัติแชตเก่าทั้งหมดได้หรือไม่

ไม่ควรตั้งสมมติฐานเช่นนั้น ความสามารถการรับข้อความขึ้นอยู่กับ Event ที่แพลตฟอร์มส่งและ API ที่กำหนดไว้ ต้องดูเอกสารประเภทข้อความและสิทธิ์ในปัจจุบัน

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

ตรวจเอกสารต้นทาง: 2 พฤศจิกายน 2026; แผนภาพและขั้นตอนในบทความเป็นตัวอย่างออกแบบ ไม่ใช่ระบบ LINE OA Production ที่ยืนยันว่ามีผู้ใช้จริง

✳
อ่านต่อเรื่องเทคโนโลยีและ AI

เลือกหัวข้อที่เกี่ยวข้องเพื่อทำความเข้าใจแนวคิดและข้อจำกัดก่อนนำไปใช้จริง

ดูบทความหมวดเทคโนโลยี ↗