ถ้าจะใส่ AI ลงในเว็บที่สร้างเอง ให้หน้าเว็บส่งคำขอมาที่ server ของเราก่อน แล้วให้ server เป็นตัวเรียก Claude API หรือ Gemini API ด้วย API key ที่เก็บไว้ใน environment variable ห้ามใส่ key ไว้ในโค้ดฝั่งหน้าเว็บเด็ดขาด เพราะใครเปิด DevTools ก็เห็น key แล้วเอาไปใช้ได้ทันที แล้วค่าใช้จ่ายก็จะมาตกที่บัญชีของเรา

หลายคนที่ทำเว็บด้วย Claude Code, Codex หรือ Cursor มักติดตรงนี้ เพราะเวลาสั่ง AI ว่า "ทำปุ่มให้ผู้ใช้ถาม AI ได้" บางทีมันก็เขียนโค้ดเรียก API ตรงจากหน้าเว็บมาให้เลย ใช้ได้ตอนทดสอบในเครื่องตัวเองก็จริง แต่พอ deploy ขึ้นไปจริงเมื่อไร key ก็เปิดให้ทุกคนเห็นทันที บทความนี้จะอธิบายว่าทำไมถึงเป็นแบบนั้น มีวิธีไหนให้เลือกบ้าง และควรเช็กอะไรก่อนเปิดให้คนใช้

ทำไม API key ห้ามอยู่ฝั่งหน้าเว็บ

โค้ดทุกบรรทัดที่รันในเบราว์เซอร์ ผู้ใช้ดาวน์โหลดไปไว้ในเครื่องเขาแล้วทั้งหมด จะ minify หรือซ่อนในไฟล์ไหนก็ไม่ช่วย เปิดแท็บ Network ใน DevTools แล้วกดปุ่มถาม AI สักครั้ง ก็เห็นทั้ง request และ header ที่มี key อยู่

key หลุดแล้วมีผลแบบนี้

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

อีกเรื่องที่เจอบ่อยคือเผลอ commit ไฟล์ .env ขึ้น GitHub แบบ public มีบอทคอยสแกนหา key ใน repository สาธารณะอยู่ตลอดเวลา เพราะฉะนั้นอย่าคิดว่า repo เล็ก ๆ ไม่มีใครเข้ามาดู

3 วิธีต่อ AI เข้ากับเว็บ

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

วิธีที่ 1 เรียก API ตรงจากหน้าเว็บ

วิธีนี้ง่ายที่สุดและพังง่ายที่สุดด้วย ใช้ได้แค่ตอนลองไอเดียในเครื่องตัวเอง พอจะ deploy ต้องย้ายไปใช้วิธีที่ 2 หรือ 3 ทันที ถ้าเห็นโค้ดที่ AI เขียนให้มีตัวแปรชื่อ API_KEY อยู่ในไฟล์ฝั่ง client ให้ถือเป็นสัญญาณเตือนไว้ก่อน

วิธีที่ 2 เรียกผ่าน server ของเราเอง

วิธีนี้ใช้กันมากที่สุด เส้นทางของข้อมูลจะเป็นแบบนี้

``
เบราว์เซอร์ผู้ใช้ → /api/ask (server ของเรา) → Claude API หรือ Gemini API
``

หน้าเว็บส่งแค่ข้อความของผู้ใช้มาที่ /api/ask ส่วน server เป็นคนแนบ key แล้วส่งต่อไปให้ผู้ให้บริการ AI ผู้ใช้ไม่มีทางเห็น key เลย ถ้าใช้ Next.js ก็ทำเป็น API route ได้ ถ้า deploy บน Vercel, Netlify หรือ Cloudflare ก็มี serverless function ให้ใช้ทั้งนั้น และทุกเจ้ามีหน้าตั้งค่า environment variable ให้ใส่ key โดยไม่ต้องเขียนลงในโค้ด

ตัวอย่างงานที่ทำแบบนี้คือ Smart & Safe City เป็นงานสาธิตการรับแจ้งเหตุภาษาไทยผ่าน LINE แล้วให้ Claude AI จำแนกประเภทเหตุ ความรุนแรง และหน่วยงานที่เกี่ยวข้อง จากนั้นเจ้าหน้าที่ดูข้อมูลต่อผ่าน dashboard และบันทึกประวัติลง Google Sheets งานลักษณะนี้ผู้ใช้ไม่ได้แตะ AI ตรง ๆ แค่ส่งข้อความเข้ามา แล้วฝั่งระบบเป็นคนจัดการต่อ

วิธีที่ 3 ให้ผู้ใช้ใส่ key ของตัวเอง

วิธีนี้เรียกกันว่า BYOK (Bring Your Own Key) เหมาะกับเครื่องมือที่คนใช้เป็นสายทำงานซึ่งมี key อยู่แล้ว ข้อดีคือเราไม่ต้องแบกค่า API เลย ตัวอย่างคือ LE PDF Scan ที่เปรียบเทียบเอกสาร 2 ฉบับจาก PDF รูปภาพ หรือไฟล์ตาราง โดยใช้ Gemini ตรวจความต่างเชิงเนื้อหาด้วย API key ของผู้ใช้เอง แล้วส่งออกผลเป็น PDF ที่มีคำอธิบาย

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

ขั้นตอนทำวิธีที่ 2 ให้ปลอดภัย

1. สร้าง key แยกสำหรับแต่ละโปรเจกต์

อย่าใช้ key เดียวกันทุกงาน ถ้าโปรเจกต์ไหนมีปัญหา จะได้ยกเลิกเฉพาะ key นั้นโดยไม่กระทบงานอื่น หน้า console ของทั้ง Anthropic และ Google มีให้สร้าง key หลายอันและตั้งชื่อแยกกันได้

2. เก็บ key ใน environment variable เท่านั้น

ตอนทำในเครื่องให้เก็บไว้ในไฟล์ .env และใส่ .env ลงใน .gitignore ก่อน commit ครั้งแรก ตอน deploy ให้ไปใส่ในหน้าตั้งค่าของ hosting ระวังเรื่องชื่อตัวแปรด้วย บาง framework จะส่งตัวแปรที่ขึ้นต้นด้วย prefix บางแบบไปให้ฝั่งหน้าเว็บอัตโนมัติ เช่น NEXT_PUBLIC_ ใน Next.js หรือ VITE_ ใน Vite ห้ามตั้งชื่อ key ด้วย prefix พวกนี้

3. ตั้งเพดานค่าใช้จ่าย

เข้าไปตั้ง spending limit หรือ budget alert ใน console ของผู้ให้บริการ ถ้ามีคนยิงคำขอรัว ๆ เข้ามา อย่างน้อยค่าใช้จ่ายจะหยุดที่ตัวเลขที่เรารับได้ ดีกว่ามารู้ตอนบิลออก

4. จำกัดจำนวนครั้งที่เรียกได้

ใส่ rate limit ที่ /api/ask เช่น จำกัดจำนวนครั้งต่อ IP ต่อนาที หรือให้ login ก่อนถึงจะใช้ได้ ถ้าเว็บเปิดให้ใช้ฟรีโดยไม่มีอะไรกั้นเลย endpoint นี้ก็ไม่ต่างจากการแจกบัตรเติมเงินให้คนแปลกหน้า

5. กำหนดว่า server รับอะไรจากผู้ใช้ได้บ้าง

อย่าให้หน้าเว็บส่ง prompt ทั้งก้อนหรือชื่อ model มาเองได้ ให้ server เป็นคนกำหนด system prompt, model และความยาวคำตอบสูงสุด ส่วนผู้ใช้ส่งได้แค่ข้อความของตัวเอง และควรจำกัดความยาวข้อความด้วย ไม่อย่างนั้นจะมีคนเอา endpoint ของเราไปใช้เป็น AI ฟรีสำหรับงานอื่น

ข้อควรระวังที่มากกว่าเรื่อง key

ผลจาก AI ควรมีคนยืนยันก่อนเอาไปใช้จริง

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

แนวคิดเดียวกันนี้ยิ่งสำคัญถ้าให้ AI สั่งงานระบบอื่นได้ คู่มือ LINE Bot MCP Server กับ Codex ที่สอนใช้ Codex จัดการ LINE OA ด้วยภาษาธรรมดา ทั้งส่งข้อความ Broadcast, Flex Message และ Rich Menu ก็เตือนไว้เรื่อง permission และการขออนุมัติก่อนรันคำสั่งสำคัญ ส่ง Broadcast ผิดครั้งเดียวก็ไปถึงลูกค้าทุกคนแล้ว ดึงกลับไม่ได้

prompt injection

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

ข้อมูลส่วนตัวของผู้ใช้

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

prompt สั่ง AI ให้เขียนส่วนนี้ให้ถูกตั้งแต่แรก

ถ้าใช้ Claude Code, Codex หรือ Cursor เขียนโค้ด ให้บอกเงื่อนไขไปตั้งแต่ต้น จะได้ไม่ต้องตามแก้ทีหลัง เช่น

  1. หน้าเว็บส่งแค่ข้อความของผู้ใช้ไปที่ /api/ask
  2. API key อ่านจาก environment variable ฝั่ง server เท่านั้น ห้ามใช้ prefix ที่ส่งไป client
  3. system prompt และ model กำหนดใน server ผู้ใช้เปลี่ยนไม่ได้
  4. จำกัดข้อความไม่เกิน 1000 ตัวอักษร และจำกัดจำนวนครั้งต่อ IP
  5. ตรวจว่า .env อยู่ใน .gitignore แล้ว

เขียนเสร็จแล้วให้สั่ง AI ทวนอีกรอบว่า "ตรวจทั้งโปรเจกต์ว่ามี API key หรือ secret อยู่ในโค้ดฝั่ง client หรือในไฟล์ที่ถูก commit หรือไม่" ใช้เวลาไม่กี่นาที แต่ช่วยกันเรื่องที่แก้ทีหลังแล้วเสียเงินจริง

ถ้า key หลุดไปแล้วต้องทำอะไร

  1. เข้า console ของผู้ให้บริการแล้วยกเลิก key นั้นทันที อย่ารอแก้โค้ดเสร็จก่อน
  2. สร้าง key ใหม่ แล้วใส่ใน environment variable ของ hosting
  3. ลบ key ออกจากโค้ด และถ้าเคย commit ขึ้น Git ไปแล้ว ให้รู้ไว้ว่ามันยังอยู่ใน history ต้องถือว่า key เก่าใช้ไม่ได้อีกแล้ว
  4. ดูหน้า usage ว่ามีการใช้งานผิดปกติช่วงไหน แล้วติดต่อผู้ให้บริการถ้ามีค่าใช้จ่ายที่ไม่ได้ใช้เอง

สรุป

AI ช่วยเขียนโค้ดเรียก API ให้ได้ในไม่กี่วินาที แต่การวาง key ไว้ถูกที่ยังเป็นงานที่คนทำเว็บต้องคุมเอง หลักง่าย ๆ มีแค่ key อยู่ที่ server หรืออยู่ในเครื่องผู้ใช้ที่เป็นเจ้าของ key เท่านั้น ตั้งเพดานค่าใช้จ่าย จำกัดจำนวนครั้ง และให้คนยืนยันผลก่อนเอาไปใช้ทำเรื่องสำคัญ ถ้าอยากดูว่าคนไทยเอา AI ไปใส่ในงานแบบไหนกันบ้าง ลองเปิดดูผลงานทั้ง 2407 ชิ้นใน applnw.com ได้