ธุรกิจแบบไหนที่ยังไม่จำเป็นต้องใช้ Vercel Sandbox รัน Code จาก AI Agent

ผมเคยนั่งฟังทีมหนึ่งเถียงกันในห้องประชุมว่าจะปล่อยให้ AI Agent รัน Code ที่มันเขียนเองบนเครื่อง Production หรือเปล่า ฝ่ายหนึ่งบอกว่า 'ก็แค่ปิด Sandbox ไว้ Agent รันในเครื่อง Dev ของเราเองก็พอ' อีกฝ่ายค้านว่า 'ถ้า Agent เขียน Code ที่ลบไฟล์ผิดหรือยิง Request ออกไปที่ไม่ควรยิงล่ะ' ทั้งคู่พูดถูกคนละครึ่ง เพราะคำถามจริง ๆ ไม่ใช่ 'ควรใช้ Sandbox ไหม' แต่คือ 'ทีมคุณอยู่ในจุดที่ความเสี่ยงจากการให้ AI รัน Code เองสูงพอจะต้องจ่ายเพื่อแยกสภาพแวดล้อมหรือยัง'

Vercel Sandbox เป็นบริการที่เปิดให้สร้างสภาพแวดล้อมแบบ ephemeral microVM ขึ้นมาชั่วคราว รัน Code ที่ไม่รู้ที่มาแน่ชัด แล้วปิดทิ้งเมื่อเสร็จงาน จุดขายหลักคือ Agent หรือกระบวนการอัตโนมัติที่เขียน Code เองสามารถรันได้จริงโดยไม่มีสิทธิ์แตะไฟล์ระบบ เครือข่ายภายใน หรือ Secret ของ Production ตรง ๆ ฟังดูจำเป็นสำหรับทุกทีมที่ทำงานกับ AI Agent แต่ในทางปฏิบัติ ต้นทุนที่แท้จริงไม่ได้อยู่แค่ค่าบริการต่อชั่วโมง Sandbox แต่อยู่ที่เวลาที่ต้องใช้วางระบบ CI/CD ให้เรียก Sandbox ถูกจังหวะ และดูแล Log ที่เกิดขึ้นจากการรันแต่ละครั้ง

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

ปัญหาจริงที่ Vercel Sandbox แก้ ไม่ใช่แค่ 'รัน Code ปลอดภัยขึ้น'

เวลาคนอธิบาย Vercel Sandbox มักพูดสั้น ๆ ว่า 'ใช้รัน Code ที่ไม่ไว้ใจอย่างปลอดภัย' ซึ่งถูกแต่ไม่ครบ เพราะปัญหาที่มันแก้จริง ๆ มีสองชั้น ชั้นแรกคือความปลอดภัยของระบบ ถ้า AI Agent เขียน Code ที่มีคำสั่งลบไฟล์ผิดพลาด หรือพยายามอ่านไฟล์ Environment Variable ที่ไม่ควรอ่าน การรันใน Sandbox ที่แยกออกจากเครื่องจริงทำให้ความเสียหายจำกัดอยู่แค่ในกล่องนั้น ปิดกล่องทิ้งก็จบ

ชั้นที่สองคือปัญหาเรื่องความเร็วในการ Iterate เวลา Agent ต้องลองรัน Code หลายรอบเพื่อแก้บั๊กหรือทดสอบ Output การมี Sandbox ที่สร้างขึ้นและทำลายทิ้งได้เร็วภายในไม่กี่วินาที ทำให้ Agent ทดลองได้ถี่ขึ้นโดยไม่ต้องรอ Provision เครื่องจริงทุกครั้ง ซึ่งเป็นคอขวดที่คนมักมองข้าม เพราะคิดว่าเรื่องความปลอดภัยสำคัญกว่าเรื่องความเร็ว ทั้งที่ในงานจริงทั้งสองเรื่องเกี่ยวโยงกัน

จุดที่ทำให้ทีมเข้าใจผิดบ่อยคือคิดว่า Sandbox แทนที่ Docker หรือ Container แบบที่ใช้กันมานานได้ทั้งหมด ความจริงคือ Sandbox ของ Vercel ออกแบบมาสำหรับ Use Case เฉพาะคือรัน Workload สั้น ๆ ที่มาจาก AI Agent เป็นหลัก ไม่ใช่ตัวแทนของ Container Orchestration แบบเต็มรูปแบบสำหรับ Production Workload ทั่วไป

สัญญาณที่บอกว่าทีมคุณ 'ต้องมี' Sandbox แล้วจริง ๆ

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

• Agent รัน Code อัตโนมัติต่อเนื่อง เช่น Coding Agent ที่ทำงานเป็น Loop แก้บั๊ก-รัน-ทดสอบ-แก้ใหม่ โดยไม่มีคนกด Approve แต่ละรอบ
• ทีมเปิดให้ผู้ใช้ภายนอกส่ง Code หรือ Prompt ที่ทำให้เกิด Code มารันบนระบบของคุณ เช่น Feature ที่ให้ผู้ใช้เขียน Script ปรับแต่งของตัวเอง
• มีเหตุการณ์เคยเกิดขึ้นแล้วที่ Agent รัน Command ผิดพลาดบนเครื่อง Dev จนต้องเสียเวลากู้คืนข้อมูลหรือ Config
• ทีมกำลังจะเปิด Feature ที่ให้ AI แก้ Code แล้ว Deploy อัตโนมัติโดยข้ามขั้นตอน Code Review ของมนุษย์บางส่วน

ธุรกิจแบบไหนที่ยังไม่ต้องรีบลงทุนกับ Sandbox

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

ทีม Solo Developer หรือทีมเล็กที่ใช้เครื่องมืออย่าง Claude Code หรือ Cursor เพื่อช่วยเขียน Code แล้วอ่านทุก Diff ก่อน Commit เอง ความเสี่ยงจากการรัน Code ที่ไม่ไว้ใจแทบไม่เกิดขึ้น เพราะจุดที่ AI 'รัน' Code จริง ๆ คือเครื่อง Local ของนักพัฒนาที่มีสิทธิ์ควบคุมอยู่แล้ว การจ่ายเพิ่มเพื่อสร้าง Sandbox แยกในกรณีนี้จึงเป็นต้นทุนที่ไม่ได้แก้ปัญหาอะไรที่มีอยู่จริง

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

ตารางตัดสินใจ: เทียบทางเลือกตามระดับความเสี่ยงจริง

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

ตัวอย่างสมมติ: คำนวณจุดคุ้มทุนก่อนตัดสินใจ

ลองสมมติทีมพัฒนาแอปขนาดกลางทีมหนึ่ง มีนักพัฒนา 4 คน ใช้ Agent ช่วยรัน Test และแก้บั๊กอัตโนมัติเฉลี่ยวันละ 30 ครั้ง ถ้าค่าใช้จ่ายต่อการสร้างและปิด Sandbox หนึ่งครั้งอยู่ที่ประมาณไม่กี่บาทต่อนาทีที่ใช้งานจริง (ตัวเลขสมมติเพื่อประกอบการคิด ไม่ใช่ราคาจริงที่ผูกกับแผนใดแผนหนึ่ง) เมื่อคูณด้วยจำนวนครั้งต่อวันและจำนวนวันทำงานต่อเดือน ต้นทุนรวมอาจอยู่ในหลักพันบาทต่อเดือน

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

ถ้าตัดสินใจใช้แล้ว ควรวางขอบเขตยังไงไม่ให้เกินความจำเป็น

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

1. กำหนดว่า Agent มีสิทธิ์เข้าถึง Network ภายนอกได้แค่ Endpoint ที่จำเป็นจริงเท่านั้น ไม่ใช่เปิดกว้างให้เรียก URL อะไรก็ได้
2. แยก Environment Variable ที่ Sandbox มองเห็นให้เป็นชุดจำกัด ไม่ใช้ Secret ชุดเดียวกับ Production
3. ตั้งเวลา Timeout ของแต่ละ Sandbox Session ให้สั้นพอสำหรับงานจริง เพื่อลดค่าใช้จ่ายจาก Session ที่ค้างโดยไม่ตั้งใจ
4. เก็บ Log การรันทุกครั้งไว้ตรวจสอบย้อนหลังได้ อย่างน้อยในช่วงเดือนแรกที่เริ่มใช้งานจริง เพื่อดูว่า Agent พยายามทำอะไรที่ไม่คาดคิดบ้างไหม

ทำแบบนี้แล้วพัง เพราะอะไร: ข้อผิดพลาดที่เจอบ่อยตอนเริ่มใช้

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

• เปิด Sandbox ให้ Agent เรียกใช้ทุกครั้งที่มีการแก้ Code แม้เป็นการแก้เล็กน้อย ทำให้ค่าใช้จ่ายพุ่งเร็วกว่าที่คาด เพราะทีมนับแค่ 'ต่อครั้งถูกกว่า Container เต็มรูป' แต่ลืมคูณด้วยความถี่จริง
• ไม่ได้ตั้ง Timeout ทำให้บาง Session ค้างนานเกินจำเป็นเพราะ Agent เข้าสู่ Loop ที่ไม่จบ ต้นทุนจึงบวมขึ้นโดยไม่มีใครสังเกตจนถึงตอนดูบิลสิ้นเดือน
• ผูก Sandbox เข้ากับ Pipeline หลักโดยไม่มี Fallback เมื่อ Sandbox ล่มหรือ Provision ช้ากว่าปกติ ทำให้ Pipeline ทั้งเส้นค้างตามไปด้วย ทั้งที่ Sandbox ควรเป็นส่วนเสริมไม่ใช่จุดล้มเดียวของระบบ
• คาดหวังว่า Sandbox แก้ปัญหาเรื่อง Code Quality ได้ด้วย ทั้งที่มันแก้แค่เรื่องการแยกสภาพแวดล้อม ส่วนคุณภาพของ Code ที่ Agent เขียนยังต้องมีขั้นตอน Review หรือ Test แยกต่างหากเหมือนเดิม

ทางเลือกกึ่งกลางสำหรับทีมที่ยังไม่พร้อมจ่ายเต็ม

ถ้าทีมยังไม่แน่ใจว่าคุ้มจะจ่ายเต็มรูปแบบ มีทางเลือกกึ่งกลางที่ช่วยลดความเสี่ยงได้ในระดับหนึ่งโดยไม่ต้องเปลี่ยน Workflow ทั้งหมด เช่น การรัน Agent ใน Container ที่จำกัดสิทธิ์ Network และ File System บนเครื่อง CI ที่มีอยู่แล้ว หรือการตั้งกฎว่า Agent มีสิทธิ์แก้ไฟล์ในโฟลเดอร์ที่กำหนดเท่านั้น

อีกแนวทางคือใช้ Sandbox แบบจ่ายตามใช้จริงเฉพาะ Use Case ที่เสี่ยงสูงสุดก่อน เช่น เฉพาะตอนที่ Agent ต้องรัน Code จากแหล่งภายนอก ส่วนงานประจำวันที่ Agent ทำภายใต้การควบคุมของทีมเองยังคงรันในสภาพแวดล้อมเดิมไปก่อน วิธีนี้ช่วยให้เห็นข้อมูลจริงว่าต้นทุนกับประโยชน์ที่ได้คุ้มกันไหม ก่อนจะขยายไปใช้เต็มรูปแบบทั้งองค์กร

สรุป

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

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

• Sandbox จำเป็นเมื่อ Agent รัน Code อัตโนมัติโดยไม่มีคนตรวจก่อน หรือรับ Code จากภายนอก
• ทีมที่ยังอ่าน Diff และรันเองทุกครั้งบนเครื่อง Local ยังไม่จำเป็นต้องรีบใช้
• คำนวณต้นทุนตามความถี่การเรียกใช้จริง ไม่ใช่แค่ราคาต่อครั้ง
• เริ่มจำกัดขอบเขตสิทธิ์ Network และ Timeout ก่อนขยายไปใช้เต็มรูปแบบ

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