Google ห้ามโปรแกรมมาติกพร็อกซีเข้าถึง Google Ads API และระบุ MCP server ไว้ในคำนิยาม

Google สั่งห้ามการเข้าถึง Google Ads API ผ่านโปรแกรมมาติกพร็อกซี และคำนิยามที่ Google เผยแพร่ระบุ Model Context Protocol (MCP) server ไว้เป็นหนึ่งในบริการที่เข้าข่าย ข้อห้ามนี้อยู่ในนโยบายนักพัฒนา Google Ads ฉบับปรับปรุงที่เผยแพร่เมื่อวันที่ 31 สิงหาคม 2026 และหน้าศูนย์ช่วยเหลือ Google Ads ที่ใช้ชื่อว่า "Programmatic proxy: Definition" เป็นที่ที่ระบุขอบเขตของคำนี้เอาไว้

คำนิยามโปรแกรมมาติกพร็อกซีของ Google ครอบคลุมอะไรจริง ๆ

ศูนย์ช่วยเหลือ Google Ads นิยามคำนี้ว่าเป็น "อินเทอร์เฟซที่โฮสต์โดยบุคคลที่สาม, API ลำดับที่สอง, บริการห่อหุ้ม (wrapper service), Model Context Protocol (MCP) server, พร็อกซีเอนด์พอยต์ หรือบริการใดที่คล้ายกัน ซึ่งเพียงแค่ทำซ้ำ ห่อหุ้ม หรือเปิดเผยความสามารถเชิงโปรแกรมของ Google Ads ซ้ำอีกครั้งในฐานะชั้นตัวกลาง" ถ้อยคำนี้อยู่บนหน้าคำนิยามของศูนย์ช่วยเหลือ Google Ads และมีสองส่วนในถ้อยคำนี้ที่ตัดสินว่าเครื่องมือหนึ่งเข้าข่ายหรือไม่

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

การระบุ MCP server ไว้ในรายการนั้นคือส่วนที่ไม่เคยมีมาก่อน MCP เป็นมาตรฐานอินเทอร์เฟซที่ผู้ช่วย AI ใช้เชื่อมต่อกับระบบภายนอก ดังนั้นกฎที่พูดถึงบริการห่อหุ้มจึงพูดตรงไปยังวิธีที่เอเจนต์ AI ถูกต่อเข้ากับบัญชีโฆษณาในเวลานี้ นี่เป็นครั้งแรกที่ Google รวมโครงสร้าง MCP เข้าไว้ในกฎการเข้าถึงเชิงโปรแกรมอย่างชัดเจน

Google เผยแพร่นโยบายนักพัฒนาฉบับปรับปรุงเมื่อ 31 สิงหาคม 2026 และเปลี่ยนชื่อนโยบาย API เดิม

เอกสารที่บรรจุข้อห้ามนี้คือนโยบายนักพัฒนา Google Ads เผยแพร่เมื่อวันที่ 31 สิงหาคม 2026 โดยเป็นการเปลี่ยนชื่อจากสิ่งที่ก่อนหน้านี้เรียกว่า Google Ads API Policy Google ประกาศเรื่องนี้บน Google Ads Developer Blog ภายใต้ชื่อผู้เขียน Nadine Wang จากทีม Advertising and Measurement APIs ส่วนสื่อสายโฆษณา PPC Land เขียนรายงานลงรายละเอียดของแต่ละหมวดในนโยบายเมื่อวันที่ 5 กันยายน 2026

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

สิ่งที่ตัวบทนโยบายห้ามไว้

ตัวบทนโยบายระบุว่านักพัฒนา "ไม่สามารถอนุญาตให้เอเจนซี ผู้ลงโฆษณาปลายทาง หรือบุคคลที่สามอื่น เข้าถึงการเข้าถึง Google Ads ในลักษณะที่จะทำให้บุคคลที่สามเหล่านั้นหลีกเลี่ยงการยื่นขอสิทธิ์นักพัฒนา Google Ads และโปรเจกต์ Google Cloud Platform ของตนเองได้" มีข้อห้ามสี่ข้ออยู่ในและรอบ ๆ ประโยคนี้

• การส่งต่อสิทธิ์นักพัฒนาให้เอเจนซี ผู้ลงโฆษณา หรือบุคคลที่สามอื่น เพื่อให้ฝ่ายเหล่านั้นข้ามขั้นตอนการยื่นขอสิทธิ์นักพัฒนา Google Ads และโปรเจกต์ Google Cloud Platform ของตัวเอง
• การฝังข้อมูลรับรอง (credentials) ไว้ในมิดเดิลแวร์ที่อำพรางต้นทางของการทำงานแบบอัตโนมัติ
• การให้บริการ developer proxy แบบแชร์ร่วมกัน
• การให้ผู้ใช้ปลายทางเข้าถึงเชิงโปรแกรมแบบ headless เพื่อแก้ไขบัญชี "โดยไม่มีการยืนยันตัวตนกับ Google โดยตรงเป็นราย entity"

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

การยืนยันตัวตนเป็นราย entity เรียกร้องอะไรจากงานพัฒนา

ข้อห้ามของ Google เรื่องการเข้าถึงเชิงโปรแกรมแบบ headless ที่ไม่มี "การยืนยันตัวตนกับ Google โดยตรงเป็นราย entity" เป็นข้อที่เปลี่ยนงานวิศวกรรม ไม่ใช่แค่เปลี่ยนงานเอกสาร อ่านจากตัวบท การทำงานอัตโนมัติที่เขียนข้อมูลลงบัญชีต้องสามารถสาวกลับไปถึงการยืนยันตัวตนกับ Google ที่เป็นของ entity ซึ่งเป็นเจ้าของบัญชีนั้น ไม่ใช่ของ service identity ที่ยืนแทนหลาย entity ในเวลาเดียวกัน

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

Google เขียนข้อยกเว้นสองข้อไว้ในหมวดเดียวกัน

หมวดเดียวกันของนโยบายนักพัฒนา Google Ads ระบุข้อยกเว้นสองข้อ ข้อแรก การที่นักพัฒนาใช้ API แบบอัตโนมัติกับบัญชีของตัวเองไม่ได้รับผลกระทบ ข้อสอง เครื่องมือโอเพนซอร์สที่ผู้ใช้ปลายทางดาวน์โหลดไปแล้วเชื่อมต่อด้วยข้อมูลรับรองของตัวเองก็ไม่ได้รับผลกระทบเช่นกัน

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

Google ให้เหตุผลสองข้อ: ข้อมูลรั่วข้ามผู้เช่า และแบนด์วิดท์ที่ใช้ร่วมกัน

Google ระบุเหตุผลสองข้อสำหรับข้อห้ามนี้ ข้อแรกคือการเปิดช่องโหว่ด้านความปลอดภัย รวมถึงการรั่วไหลของข้อมูลข้ามผู้เช่า (cross-tenant data leaks) ซึ่งเป็นรูปแบบความล้มเหลวที่ข้อมูลของลูกค้ารายหนึ่งเข้าถึงได้จากเซสชันของลูกค้าอีกรายภายในชั้นที่ใช้ร่วมกัน ข้อสองคือความเสี่ยงด้านการปฏิบัติงาน ทราฟฟิกปริมาณสูงที่วิ่งผ่านพร็อกซีตัวเดียว "สามารถจำกัดปริมาณการรับส่งข้อมูล ทำให้เกิดความหน่วงกับผู้ใช้ทุกราย และทำให้ต้องบังคับใช้มาตรการกับผู้ใช้ทุกรายของพร็อกซีนั้น" ในช่วงที่มีการรับมือการโจมตีแบบปฏิเสธการให้บริการ

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

ระดับ Required Minimum Functionality ที่ถูกย้ำไว้ในเอกสารฉบับเดียวกัน

เอกสารฉบับเดียวกันย้ำระดับ Required Minimum Functionality (RMF) ที่กำหนดว่าเครื่องมือหนึ่งต้องทำอะไรได้ถึงจะถือสิทธิ์การเข้าถึงในแต่ละระดับ ตารางด้านล่างคือสามระดับตามที่ Google ระบุไว้

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

ใครได้รับผลกระทบ และใครไม่ได้รับ

ตามตัวบทของนโยบาย ฝ่ายที่มีงานต้องทำคือฝ่ายที่ให้บริการชั้นโฮสต์ซึ่งธุรกิจอื่นยืนยันตัวตนผ่าน ได้แก่ ผู้ให้บริการที่ลูกค้าไม่เคยยื่นขอสิทธิ์นักพัฒนาของตัวเอง แพลตฟอร์มที่ถือข้อมูลรับรองชุดเดียวแทนผู้ลงโฆษณาหลายราย และใครก็ตามที่รัน MCP server ที่บริษัทหลายแห่งชี้ผู้ช่วย AI ของตนเข้ามาใช้ เอเจนซีที่ดูแลแคมเปญ Google Ads ให้ลูกค้าจำนวนมากผ่านชั้นข้อมูลรับรองที่แชร์กันชุดเดียวก็อยู่ในสถานะเดียวกัน ไม่ว่าจะมองตัวเองว่าเป็นนักพัฒนาหรือไม่

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

สิ่งที่ควรตรวจสอบในระบบของคุณเอง

1. ทุกการเชื่อมต่อที่แตะบัญชี Google Ads ของคุณมีโปรเจกต์ Google Cloud ของตัวเองหรือไม่ หรือกำลังยืมของผู้ให้บริการอยู่
2. MCP server ที่ผู้ช่วย AI ของคุณเชื่อมผ่านนั้นถูกโฮสต์ให้ธุรกิจหลายรายใช้ ซึ่งนโยบายห้ามไว้ หรือรันในเครื่องด้วยข้อมูลรับรองของคุณเอง ซึ่งข้อยกเว้นครอบคลุมอยู่
3. สคริปต์ตั้งราคาบิด งานแจ้งเตือน และแดชบอร์ด ยืนยันตัวตนเป็นราย entity หรือผ่าน service identity ที่แชร์กันชุดเดียว
4. มีอะไรในสายการทำงานที่เขียนข้อมูลลงบัญชีโดยไม่มีการยืนยันตัวตนกับ Google ที่เป็นของเจ้าของบัญชีหรือไม่
5. การดึงรายงานดึงข้อมูล Google Ads ผ่านตัวห่อหุ้มที่คุณไม่ได้ควบคุมหรือไม่ ถ้ามีชั้นโฮสต์คั่นอยู่ระหว่างบัญชีกับแดชบอร์ด ชั้นนั้นก็เป็นส่วนหนึ่งของระบบวิเคราะห์ข้อมูลและการวัดผลของคุณไม่ต่างจากเครื่องมือโฆษณา และสายท่อที่อ่านข้อมูลอย่างเดียวคือจุดที่การรั่วไหลข้ามผู้เช่าจะโผล่ขึ้นมา

สิ่งที่แหล่งข่าวไม่ได้ระบุ

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

ช่องว่างที่ใหญ่ที่สุดคือบานพับของคำนิยามเอง Google ไม่ได้บอกว่าคำว่า "เพียงแค่ทำซ้ำ" สิ้นสุดที่ไหน และเครื่องมือที่สร้างคุณค่าเพิ่มจริงเริ่มต้นที่ไหน บริการโฮสต์ที่ห่อหุ้ม Google Ads API แล้วเพิ่มลอจิก การจัดเก็บข้อมูล การตั้งเวลา หรืออินเทอร์เฟซของตัวเองทับลงไป ไม่ได้เข้าข่ายกฎที่มุ่งเป้าไปที่บริการซึ่งไม่ทำอะไรเลยนอกจากเปิดเผย API ซ้ำอย่างชัดเจน และก็ไม่ได้อยู่นอกกฎอย่างชัดเจนด้วย ใครที่รันตัวห่อหุ้มอยู่ในวันนี้กำลังอ่านคำนั้นโดยไม่มีเกณฑ์ทดสอบมาใช้ และแหล่งข่าวไม่ได้ให้เกณฑ์นั้นมา

เรื่องนี้มีความหมายอย่างไรกับนักการตลาดในไทย

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

มีคำถามสามข้อที่ควรถามคนที่สร้างระบบของคุณ การเชื่อมต่อถือโปรเจกต์ Google Cloud ของตัวเองหรือไม่ หรืออาศัยของผู้ให้บริการอยู่ MCP server ที่อยู่หลังผู้ช่วย AI ของคุณถูกโฮสต์ให้ธุรกิจหลายรายใช้พร้อมกัน หรือรันอยู่บนเครื่องคุณด้วยข้อมูลรับรองของคุณ และสคริปต์บิดกับงานรายงานของคุณยืนยันตัวตนแยกเป็นรายบัญชีหรือไม่ คำถามทั้งสามข้อไม่ต้องรอนักพัฒนามาตอบ และคำตอบจะบอกได้ว่าเอกสารฉบับ 31 สิงหาคมสร้างงานให้คุณหรือไม่สร้างเลย

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

นโยบายนี้ห้ามผู้ช่วย AI ทำงานกับ Google Ads หรือไม่

ไม่ห้าม นโยบายห้ามชั้นโฮสต์ของบุคคลที่สามที่มีหน้าที่เพียงเปิดเผยความสามารถเชิงโปรแกรมของ Google Ads ซ้ำอีกครั้ง และระบุยกเว้นเครื่องมือโอเพนซอร์สที่ผู้ใช้ปลายทางดาวน์โหลดไปเชื่อมต่อด้วยข้อมูลรับรองของตัวเองไว้อย่างชัดเจน ผู้ช่วย AI ที่เข้าถึงบัญชีของคุณผ่านเครื่องมือที่รันในเครื่อง บนสิทธิ์นักพัฒนาและโปรเจกต์ Cloud ของคุณเอง อยู่ฝั่งที่ได้รับการยกเว้นตามที่ Google เขียนไว้

เรื่องนี้มีผลในไทยแล้วหรือยัง

แหล่งข่าวไม่ได้ระบุรายชื่อประเทศใดไว้ นโยบายนักพัฒนา Google Ads กำกับดูแลสิทธิ์การเข้าถึงของนักพัฒนา ไม่ใช่การเปิดตัวผลิตภัณฑ์ตามภูมิภาค และทั้งประกาศนโยบายวันที่ 31 สิงหาคม 2026 กับหน้าคำนิยามในศูนย์ช่วยเหลือก็ไม่ได้ระบุขอบเขตทางภูมิศาสตร์ จึงไม่มีการอธิบายการทยอยเปิดใช้เป็นรายประเทศไว้ในทางใดทางหนึ่ง

ถ้าเอเจนซีเป็นคนดูแล Google Ads ให้ ผมต้องทำอะไรไหม

ถามคำถามเดียว ทุกการเชื่อมต่อที่แตะบัญชีของคุณเชื่อมผ่านโปรเจกต์ Google Cloud ของตัวเองโดยเฉพาะหรือไม่ ถ้าคำตอบคือใช่ นโยบายนี้ไม่ได้เรียกร้องอะไรจากคุณ ถ้าคำตอบคือมีชั้นที่แชร์กันตั้งอยู่หน้าผู้ลงโฆษณาหลายราย นั่นคือสถาปัตยกรรมที่นโยบายวันที่ 31 สิงหาคม 2026 ห้ามไว้ และงานแก้เป็นของคนที่สร้างมัน

การเชื่อมต่อที่ไม่เป็นไปตามนโยบายจะเกิดอะไรขึ้น

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

MCP server ที่โฮสต์เองได้รับอนุญาตหรือไม่

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

สรุปสั้นของนโยบายฉบับ 31 สิงหาคม ข้อมูลรับรอง โปรเจกต์ Cloud และบัญชี ควรเป็นของฝ่ายเดียวกัน การไล่ดูว่าเครื่องมือไหนในระบบของคุณเข้าเกณฑ์นั้นอยู่แล้วใช้เวลาตรวจแค่เช้าเดียว และควรทำก่อนที่รายละเอียดการบังคับใช้จะออกมา ไม่ใช่หลังจากนั้น ถ้าอยากมีคนช่วยไล่ดูโครงสร้าง Google Ads ไปด้วยกัน เรายินดีดูให้