คำตอบสั้น: เมนูไม่หายไป แต่เลิกเป็นทางเดียวที่ใช้งานได้

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

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

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

บทความนี้มีสองส่วนให้ทดลองกดจริง ส่วนแรกให้เปรียบเทียบสองเส้นทางด้วยตัวเอง ส่วนที่สองให้ผู้อ่านรับบทเป็น AI Agent ที่ต้องตัดสินใจกับคำขอคืนเงินหนึ่งรายการ

ทำไม Backoffice ถึงกลายเป็นเมนูซ้อนเมนู

ระบบหลังบ้านส่วนใหญ่ไม่ได้ถูกออกแบบให้ซับซ้อนตั้งแต่วันแรก มันค่อย ๆ ซับซ้อนขึ้นตามเหตุผลที่ฟังขึ้นทุกข้อ

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

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

สองเส้นทาง ดูพร้อมกัน

ทั้งสองฝั่งตอบคำถามเดียวกัน สิ่งที่ต่างกันคือใครเป็นคนเดินเส้นทางนั้น

คำถามเดียวกัน สองเส้นทาง

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

Backoffice แบบเดิม

เส้นทาง Report → Sales → Monthly → กรุงเทพฯ → Export → Excel

ขั้นที่ 6 จาก 6

    ตอนนี้อยู่ที่ เมนูหลัก

    DashboardReportSettingMaster Data

    ปลายทางคือไฟล์

    sales-bangkok-2026-08.xlsx

    ไฟล์ตัวอย่างนี้มี 4,120 แถว และยังไม่ได้ตอบคำถามที่ตั้งไว้ ผู้ใช้ต้องเปิด Excel ทำ Pivot เทียบเดือนก่อน แล้วไล่หาสินค้าที่โตผิดปกติเอง

    AI Interface

    ประโยคเดียว แล้วเบื้องหลังเดินให้

    คำสั่ง

    สรุปยอดขายกรุงเทพฯ เดือนนี้ เทียบเดือนก่อน และหาสินค้าที่โตผิดปกติ

    ปลายทางคือคำตอบ

    ยอดขายกรุงเทพฯ เดือนนี้ 12.4 ล้านบาท เพิ่มขึ้น 8% จากเดือนก่อน สินค้าที่โตผิดจากรูปแบบปกติคือ SKU-2213 ซึ่งเพิ่มขึ้น 212% จากฐานที่ยังต่ำ

    ตัวเลขทั้งหมดเป็นตัวอย่างสมมติเพื่อประกอบการอธิบาย ไม่ใช่ข้อมูลของลูกค้ารายใด

    กำลังทำงาน

    ขั้นตอนเบื้องหลัง

    1. 1อ่านคำสั่งแปลงประโยคเป็นงาน: ช่วงเวลา พื้นที่ และการเปรียบเทียบที่ต้องทำ
    2. 2ตรวจสิทธิ์ผู้ใช้ผู้ใช้คนนี้ดูยอดขายได้เฉพาะเขตกรุงเทพฯ จึงขอ Token ตามขอบเขตนั้น
    3. 3เรียก Sales Tool ผ่าน MCPMCP คือมาตรฐานกลางที่ให้ AI เรียกความสามารถของระบบได้ ที่เรียกคือ salesSummary ซึ่งกำหนดพารามิเตอร์ไว้ล่วงหน้า ไม่ใช่ SQL อิสระ
    4. 4ระบบขายตรวจสิทธิ์ซ้ำระบบต้นทางตรวจ Token และกฎธุรกิจอีกครั้ง แล้วคืนเฉพาะแถวที่ผู้ใช้มีสิทธิ์เห็น
    5. 5วิเคราะห์เทียบกับเดือนก่อน หาสินค้าที่เติบโตผิดจากรูปแบบปกติ
    6. 6แสดงผลสรุปเป็นคำตอบ พร้อมบอกว่าใช้ข้อมูลช่วงใดและกรองด้วยเงื่อนไขใด

    6 คลิก1 ประโยค

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

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

    เบื้องหลังประโยคเดียวมีอะไรบ้าง

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

    ขั้นตอนที่สำคัญที่สุดคือขั้นตอนที่สาม โมเดลไม่ได้เขียน SQL เอง แต่เรียกความสามารถที่องค์กรกำหนดขอบเขตไว้ล่วงหน้า เช่น

    // ความสามารถที่เปิดให้ Agent เรียก - แคบโดยตั้งใจ
export const salesSummary = {
  name: 'salesSummary',
  description: 'สรุปยอดขายรายเดือนตามพื้นที่ที่ผู้ใช้มีสิทธิ์เข้าถึง',
  input: {
    month: 'YYYY-MM',
    // ไม่ใช่รายการพื้นที่ทั้งหมด แต่เป็นพื้นที่ที่ Token ของผู้ใช้ครอบคลุม
    territory: 'string',
    compareWithPreviousMonth: 'boolean',
  },
} as const;

    ความสามารถแบบนี้คือสิ่งที่ MCP Server ประกาศให้ AI เรียกใช้ ซึ่งอธิบายไว้ในบทความ MCP Server คืออะไร เมื่อ AI ทำงานกับ Backoffice ได้

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

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

    {
  "territory": "BKK",
  "month": "2026-08",
  "total": 12400000,
  "previousMonth": 11480000,
  "rowsWithheld": 3180,
  "scopeApplied": "sales:read:territory=BKK"
}

    ฟิลด์ rowsWithheld คือสิ่งที่แยกระบบที่ออกแบบมาดีออกจากระบบที่เพียงแค่ทำงานได้ ระบบรู้ว่ามีข้อมูลที่ไม่ได้ส่งไป และรู้ว่าเพราะเหตุใด รายละเอียดของการวางชั้นเชื่อมต่อแบบนี้ รวมถึงเรื่อง OAuth และการอนุมัติก่อนทำรายการ อยู่ในบทความ เชื่อม AI กับ ERP, CRM และระบบภายในให้ปลอดภัย

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

    ตอนนี้ผู้ผลิตซอฟต์แวร์ไปถึงไหนแล้ว

    สิ่งที่อธิบายมาข้างต้นไม่ใช่การคาดการณ์ระยะยาว มันคือทิศทางที่ผู้ผลิตซอฟต์แวร์องค์กรรายใหญ่กำลังส่งของอยู่แล้ว

    Microsoft อธิบายแนวทางของ Agent ใน Microsoft 365 Copilot เมื่อเดือนเมษายน 2026 ว่าเป็นการนำแอปพลิเคชันธุรกิจเข้ามาอยู่ในบทสนทนา จนทำให้ “intent becomes execution without ever leaving Copilot chat” และย้ำในย่อหน้าเดียวกันว่าการควบคุมยังอยู่ที่ผู้ใช้ ผู้ใช้เลือกได้ว่าจะทำงานกับหน้าจอของแอปในแชทโดยตรง หรือสั่งให้ Agent ทำงานภายใต้การกำกับดูแล

    ที่น่าสนใจกว่าคือทิศทางของฝั่งโปรโตคอล MCP เพิ่มส่วนขยายชื่อ MCP Apps ซึ่งเปิดให้เซิร์ฟเวอร์ส่งหน้าจอที่กดได้จริง เช่น ฟอร์ม แดชบอร์ด หรือกราฟ กลับมาแสดงในบทสนทนา โดยรันอยู่ใน iframe ที่ถูกจำกัดสิทธิ์และสื่อสารกับ Host ผ่าน postMessage เท่านั้น

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

    ลองเป็น AI Agent ห้านาที

    ส่วนนี้กลับด้านกัน จากที่อ่านว่า Agent ควรทำงานอย่างไร คราวนี้ผู้อ่านเป็นคนตัดสินใจเอง

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

    คำขอคืนเงินหนึ่งรายการ กับสี่จุดตัดสินใจ

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

    เดินเรื่องไปแล้ว 0 จาก 4เปิดดูทางเลือกแล้ว 0 ทาง

    สถานการณ์ลูกค้าส่งข้อความเข้ามาว่า “ขอคืนเงิน Order #1024 ด้วยครับ” นี่คือทุกอย่างที่คุณรู้ตอนนี้

    สิ่งที่เรียกได้ตอนนี้

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

    สี่คำถามก่อนเปิดให้ AI ทำงานกับระบบจริง

    ก่อนเชื่อม Agent เข้ากับระบบใด ให้ตอบสี่ข้อนี้ให้ได้ก่อน และตอบด้วยชื่อระบบจริง ไม่ใช่ด้วยหลักการ

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

    เอกสาร Security Best Practices ของ MCP ระบุความผิดพลาดที่พบบ่อยไว้ข้อหนึ่งซึ่งตรงกับข้อ 3 มาก คือการถือว่า Scope ที่อยู่ใน Token เพียงพอแล้วโดยไม่มีการตรวจสิทธิ์ฝั่งเซิร์ฟเวอร์ Scope บอกได้แค่ว่าเรียกอะไรได้ ไม่ได้บอกว่ากรณีตรงหน้าทำได้

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

    แล้วเมนูยังจำเป็นตรงไหน

    การสั่งงานด้วยภาษาไม่ได้ชนะทุกกรณี มีอย่างน้อยสี่สถานการณ์ที่หน้าจอแบบเดิมยังทำได้ดีกว่าอย่างชัดเจน

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

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

    สรุป

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

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

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

    แหล่งอ้างอิงและอ่านต่อ