วิธีเชื่อม Google Sheets กับแอปของคุณ
การเชื่อม Google Sheets กับแอปของคุณ ให้เปิดใช้ Google Sheets API ใน Google Cloud project สร้าง service account แชร์สเปรดชีตให้อีเมลของ service account แล้วเก็บคีย์ไว้เป็น ความลับฝั่งเซิร์ฟเวอร์ จากนั้นเซิร์ฟเวอร์ของคุณจะอ่านแถวด้วย spreadsheets.values.get และเพิ่มแถวด้วย spreadsheets.values.append หากผู้ใช้ต้องเชื่อมชีตของ ตัวเอง ให้ใช้ OAuth แทน และหากชีตเป็นสาธารณะทั้งหมด API key แบบธรรมดาก็เพียงพอสำหรับการอ่าน
คู่มือนี้ครอบคลุมว่าวิธีไหนเหมาะกับงาน การเรียกที่คุณต้องใช้ โควตาและข้อควรระวัง และพรอมต์สำหรับ AI app builder รายละเอียดของ Google อ้างอิงจากเอกสารนักพัฒนาของ Google ณ เดือนกันยายน 2026
ทำไมต้องเชื่อมชีต
เหตุผลที่พบบ่อย:
- รักษาขั้นตอนการทำงานของทีม เจ้าหน้าที่ยังคงแก้ไขรายการราคาหรือตารางงานใน Sheets แอปแสดงผลให้
- เก็บข้อมูลในที่ที่คนมองอยู่แล้ว การสมัครใหม่ คำสั่งซื้อ หรือคำตอบแบบฟอร์มจะกลายเป็นแถว
- การรายงาน ส่งออกข้อมูลของแอปไปยังชีตสำหรับคนที่ทำงานกับสเปรดชีตเป็นประจำ
- ขั้นกลางก่อนย้ายระบบ เริ่มจากชีต แล้วค่อยย้ายไปฐานข้อมูลที่เหมาะสม ดู วิธีเปลี่ยนสเปรดชีตเป็นแอป
เลือกวิธีที่แอปของคุณลงชื่อเข้าใช้ Google
คู่มือ credentials ของ Google อธิบายสามประเภท:
| Credential | เข้าถึงอะไรได้ | เหมาะกับ |
|---|---|---|
| API key | เฉพาะข้อมูลที่เผยแพร่สาธารณะ เช่น ไฟล์ที่แชร์แบบ “Anyone with the link” | อ่านชีตสาธารณะ |
| Service account | ข้อมูลที่แอปของคุณเป็นเจ้าของ หรือไฟล์เฉพาะที่แชร์ให้อีเมลของ service account | แอปของคุณอ่านและเขียน ชีตของคุณ |
| OAuth client ID | ไฟล์ของผู้ใช้เอง หลังจากผู้ใช้ยินยอม | ให้ผู้ใช้แต่ละคนเชื่อมชีตของ ตัวเอง |
สำหรับแอปส่วนใหญ่ service account เป็นตัวเลือกที่ถูกต้อง มี credentials ชุดเดียวที่คุณเป็นเจ้าของ และเข้าถึงได้เฉพาะชีตที่คุณแชร์ให้อย่างชัดเจน
ทีละขั้นตอนด้วย service account
- สร้างหรือเลือก Google Cloud project แล้วเปิดใช้ Google Sheets API
- สร้าง service account และสร้างคีย์ให้มัน คีย์เป็นไฟล์ JSON ปฏิบัติกับมันเหมือนรหัสผ่าน
- แชร์สเปรดชีต ให้อีเมลของ service account เป็น Viewer สำหรับอ่านอย่างเดียว หรือ Editor สำหรับเขียน คู่มือของ Google ระบุว่าทำได้ผ่านหน้าการแชร์ปกติ
- เก็บคีย์เป็นความลับ บนเซิร์ฟเวอร์ เช่น
GOOGLE_SERVICE_ACCOUNT_JSONและเก็บ spreadsheet ID (สตริงยาวในลิงก์ของชีต) ไว้เป็นSHEET_ID - เรียก API จากเซิร์ฟเวอร์ ด้วยไลบรารี client ของ Google สำหรับภาษาที่คุณใช้
- แคชการอ่าน หากผู้เข้าชมจำนวนมากเห็นข้อมูลเดียวกัน จะได้ไม่ชนโควตา
การเรียกที่คุณจะใช้
จากคู่มือของ Google เกี่ยวกับการอ่านและเขียนค่า:
| เมธอด | ทำอะไร |
|---|---|
spreadsheets.values.get | อ่านช่วงเดียว เช่น Leads!A1:E |
spreadsheets.values.batchGet | อ่านหลายช่วงในคำขอเดียว |
spreadsheets.values.update | เขียนลงช่วงที่ระบุ |
spreadsheets.values.append | เพิ่มแถวต่อท้ายข้อมูลที่มีอยู่ในตาราง |
ช่วงใช้สัญกรณ์ A1 Google ระบุว่าช่วงที่ไม่มีชื่อชีต เช่น A1:B2 จะใช้กับชีตแรก ดังนั้นให้ระบุชื่อแท็บอย่างชัดเจน เพื่อหลีกเลี่ยงปัญหาเมื่อมีคนเรียงแท็บใหม่
RAW กับ USER_ENTERED
การเขียนต้องระบุ valueInputOption:
- RAW เก็บสิ่งที่คุณส่งตรงตัวเป็นข้อความ
=1+2จะถูกเก็บเป็นข้อความ=1+2 - USER_ENTERED ปฏิบัติกับข้อมูลเหมือนที่พิมพ์ลงใน Sheets วันที่จะกลายเป็นวันที่ และ
=1+2จะกลายเป็นสูตร
หากคุณเขียนข้อความที่ผู้ใช้พิมพ์เข้ามาในแอป ให้ใช้ RAW เพราะถ้าใช้ USER_ENTERED ใครบางคนอาจส่งสูตรที่จะทำงานเมื่อเพื่อนร่วมงานเปิดชีต
โควตาและข้อผิดพลาด
ณ เดือนกันยายน 2026 หน้าขีดจำกัดของ Sheets API ของ Google ระบุไว้ดังนี้:
| ขีดจำกัด | คำขออ่าน | คำขอเขียน |
|---|---|---|
| ต่อนาทีต่อโปรเจกต์ | 300 | 300 |
| ต่อนาทีต่อผู้ใช้ต่อโปรเจกต์ | 60 | 60 |
ไม่มีขีดจำกัดรายวันตราบใดที่คุณอยู่ในโควตาต่อนาที หากเกินจะได้รับ 429: Too many requests และ Google แนะนำ truncated exponential backoff คือรอนานขึ้นหลังความพยายามที่ล้มเหลวแต่ละครั้ง โดยมีการหน่วงแบบสุ่ม จนถึงค่าสูงสุด คำขอเดียวที่ใช้เวลามากกว่า 180 วินาทีจะหมดเวลา
ในทางปฏิบัติ: อย่าเรียก API ทุกครั้งที่มีการเข้าหน้า ให้แคชข้อมูลชีตอย่างน้อยหนึ่งนาที รวมการอ่านด้วย batchGet และรวมการเขียนเท่าที่ทำได้
ตัวเลือกและการแลกเปลี่ยน
| แนวทาง | ข้อดี | ข้อเสีย |
|---|---|---|
| ชีตเป็นแหล่งข้อมูลสด | เจ้าหน้าที่แก้ไขในเครื่องมือที่คุ้นเคย ไม่ต้องสร้างหน้าผู้ดูแล | มีโควตา ไม่มีสิทธิ์รายแถว และพังง่ายถ้าเปลี่ยนชื่อคอลัมน์ |
| ซิงก์ชีตเข้าฐานข้อมูล | อ่านได้เร็วและเชื่อถือได้ แอปยังทำงานต่อได้หาก Sheets ล่ม | ต้องมีงานซิงก์และกฎว่าฝั่งไหนชนะ |
| ฐานข้อมูลก่อน ส่งออกไปชีต | แอปเป็นเจ้าของข้อมูล ชีตเป็นรายงาน | การแก้ไขในชีตไม่ไหลกลับ |
| เครื่องมืออัตโนมัติคั่นกลาง | ไม่ต้องเขียนโค้ดสำหรับขั้นตอนง่าย ๆ | เป็นอีกค่าบริการหนึ่ง และดีบักยากกว่า |
สำหรับสิ่งที่มีผู้ใช้จำนวนมากหรือข้อมูลละเอียดอ่อน ฐานข้อมูลเป็นแหล่งความจริงที่ดีกว่า ดู ฐานข้อมูลคืออะไร
พรอมต์สำหรับ AI builder ของคุณ
การอ่านชีต:
แสดงแท็บ “Menu” ของ Google Sheet ของเราในหน้าเมนู ใช้ Google Sheets API จากเซิร์ฟเวอร์ด้วย service account ที่มี JSON key อยู่ในความลับ GOOGLE_SERVICE_ACCOUNT_JSON และ spreadsheet ID อยู่ใน SHEET_ID อ่านช่วง Menu!A2:D (ชื่อ คำอธิบาย ราคา หมวดหมู่) แคชผลลัพธ์ไว้ 5 นาที หาก API ล้มเหลว ให้แสดงเวอร์ชันแคชล่าสุด ห้ามส่งคีย์ไปยังเบราว์เซอร์เด็ดขาด
การเขียนแถว:
เมื่อมีคนส่งฟอร์มติดต่อ ให้บันทึกลงฐานข้อมูลของเรา และเพิ่มแถวลงแท็บ “Leads” ด้วย (วันที่ ชื่อ อีเมล ข้อความ) โดยใช้ spreadsheets.values.append กับ valueInputOption RAW หาก Google ส่ง 429 ให้ลองใหม่ด้วย exponential backoff หากยังล้มเหลว ให้เก็บ lead ไว้ในฐานข้อมูลและลองใหม่ภายหลัง
ความผิดพลาดที่พบบ่อย
- ลืมแชร์ชีต ให้อีเมลของ service account แล้ว API จะตอบข้อผิดพลาดสิทธิ์ทั้งที่คีย์ถูกต้อง
- คีย์อยู่ในฝั่งหน้าเว็บหรือในรีโพซิทอรี JSON key ให้สิทธิ์เข้าถึงทุกชีตที่แชร์ให้มัน ดู วิธีเก็บ API key ให้ปลอดภัย
- ใช้ USER_ENTERED กับข้อมูลที่ผู้ใช้ป้อน ซึ่งเปิดช่องให้ฉีดสูตร
- เรียก API ทุกคำขอ และชนโควตาต่อนาทีในช่วงที่มีทราฟฟิกพุ่งครั้งแรก
- พึ่งตำแหน่งคอลัมน์ เมื่อมีคนแทรกคอลัมน์ แอปจะอ่านข้อมูลผิด ให้อ่านแถวหัวตารางและจับคู่ตามชื่อ หรือล็อกหัวตารางไว้
- แชร์ชีตกว้างกว่าที่จำเป็น การเลือก “Anyone with the link” ทำให้เป็นสาธารณะ
- ใช้ชีตเป็นฐานข้อมูลหลายผู้ใช้ การเขียนพร้อมกันและสิทธิ์ที่ขาดหายทำให้ข้อมูลสูญหายหรือรั่วไหลได้
เช็กลิสต์
- เปิดใช้ Sheets API และสร้าง service account แล้ว
- แชร์ชีตให้อีเมลของ service account ด้วยสิทธิ์ต่ำที่สุดที่จำเป็น
- เก็บคีย์และ sheet ID เป็นความลับฝั่งเซิร์ฟเวอร์
- การเรียกทั้งหมดทำจากเซิร์ฟเวอร์
- ใช้ชื่อแท็บในช่วงต่าง ๆ
- ใช้ RAW กับข้อความที่ผู้ใช้ป้อน
- แคชการอ่าน และจัดการ 429 ด้วย backoff
- แอปทำงานอย่างนุ่มนวลเมื่อ Sheets ใช้ไม่ได้
- ตัดสินใจแล้วว่าฝั่งไหนเป็นแหล่งความจริง
Google Sheets ใน Mythex
Mythex มีสองวิธีในการทำงานกับ Sheets Connectors เชื่อมบัญชี Google ของคุณกับ Mythex เพื่อให้เอเจนต์ใช้ได้ขณะที่คุณสร้างงาน เช่น อ่านชีตเพื่อสร้างแดชบอร์ดจากมัน เอกสารระบุว่า credential อยู่กับบริการเชื่อมต่อของ Mythex และไม่เข้าไปอยู่ในโค้ดของคุณ (ดู Connectors และอนุมัติทุกสิทธิ์ที่ Google ขอ) สำหรับ แอปที่เผยแพร่แล้ว ให้อ่านหรือเขียนชีตได้ด้วยตัวเอง วิธีที่เชื่อถือได้คือแนวทางในคู่มือนี้: คีย์ service account ที่เก็บเป็นความลับของโปรเจกต์ และการเรียก Sheets API จากเซิร์ฟเวอร์ของคุณ ตามที่อธิบายใน Integrate any API หากคุณกำลังเติบโตเกินชีต ขอให้เอเจนต์ย้ายข้อมูลไปยังฐานข้อมูลของโปรเจกต์ แล้วสร้าง แดชบอร์ด บนนั้น
คำถาม
แอปของฉันจะอ่าน Google Sheet ที่เป็นส่วนตัวได้อย่างไร?
วิธีที่นิยมคือใช้ service account ของ Google Cloud: เปิดใช้ Sheets API สร้าง service account และคีย์ แล้วแชร์สเปรดชีตให้อีเมลของ service account เป็น Viewer หรือ Editor เซิร์ฟเวอร์ของคุณใช้คีย์ที่เก็บเป็นความลับเพื่อเรียก Sheets API
ใช้ Google API key เข้าถึงสเปรดชีตได้ไหม?
ได้เฉพาะข้อมูลสาธารณะ คู่มือ credentials ของ Google ระบุว่า API key ใช้สำหรับการเข้าถึงแบบไม่ระบุตัวตนไปยังข้อมูลที่เผยแพร่สาธารณะ เช่น ไฟล์ที่แชร์ให้ทุกคนที่มีลิงก์ ชีตส่วนตัวต้องใช้ service account หรือ OAuth
Google Sheets API มีขีดจำกัดอย่างไรบ้าง?
ณ เดือนกันยายน 2026 Google ระบุว่า 300 คำขออ่านและ 300 คำขอเขียนต่อนาทีต่อโปรเจกต์ และ 60 ของแต่ละประเภทต่อนาทีต่อผู้ใช้ต่อโปรเจกต์ ไม่มีขีดจำกัดรายวัน หากเกินจะได้รับข้อผิดพลาด 429 และ Google แนะนำให้ใช้ truncated exponential backoff
ควรใช้ Google Sheets เป็นฐานข้อมูลของแอปหรือไม่?
ใช้ได้กับแอปขนาดเล็กที่มีผู้ใช้น้อย และมีคนแก้ไขข้อมูลในชีตโดยตรง แต่สำหรับผู้ใช้จำนวนมาก การเขียนบ่อย ความสัมพันธ์ระหว่างระเบียน หรือสิทธิ์รายผู้ใช้ ฐานข้อมูลจริงจะเชื่อถือได้มากกว่า และคุณยังส่งออกไปยังชีตได้อยู่