GitHub เปิด Copilot usage metrics ระดับ repository เป็น GA — วัดได้แล้วว่าเอเจนต์เปิด PR กี่ตัว และรีวิวไปกี่ครั้งในแต่ละ repo

วันที่ 17 กรกฎาคม 2026 GitHub ประกาศว่า Copilot usage metrics ระดับ repository ขึ้นสถานะ generally available แล้ว พร้อม REST endpoint ใหม่สองตัวที่ดึงรายงานรายวันแยกเป็นราย repository ได้

เรื่องนี้ฟังดูเหมือนงาน admin แต่มันคือคำตอบของคำถามที่หัวหน้าทีมวิศวกรรมทั่วโลกถามกันมาตลอดปีที่ผ่านมา — เอเจนต์ที่เราจ่ายเงินซื้ออยู่ มันทำงานอะไรให้บ้าง และที่ไหน

endpoint ใหม่ และสิ่งที่มันบอก

ประกาศระบุ endpoint สองตัวตรง ๆ:

GET /enterprises/{enterprise}/copilot/metrics/reports/repos-1-day?day=YYYY-MM-DD
GET /orgs/{org}/copilot/metrics/reports/repos-1-day?day=YYYY-MM-DD

ชื่อ repos-1-day บอกรูปแบบข้อมูลชัดในตัวเอง: ราย repository ต่อหนึ่งวัน เลือกวันที่ด้วยพารามิเตอร์ day ตามรูปแบบ ISO ตัวรายงานจะไล่ให้เห็นว่าในวันนั้น แต่ละ repo เกิดอะไรขึ้นบ้าง โดยสองตัวเลขที่ประกาศพูดถึงชัดเจนคือ

• pull request ที่ Copilot coding agent สร้างและ merge — คือฝั่งที่เอเจนต์เขียนโค้ดเอง
• pull request ที่ผ่าน Copilot code review พร้อมจำนวน suggestion แยกตามประเภทของ comment — คือฝั่งที่เอเจนต์ตรวจงานคน

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

ตามระบบ metrics ของ Copilot ที่มีอยู่ ปลายทางของ endpoint กลุ่มนี้คือ signed URL สำหรับดาวน์โหลดรายงาน ที่ generate รายวันและมีอายุจำกัด ไม่ใช่ JSON ก้อนเดียวที่ตอบกลับมาตรง ๆ — คนที่จะต่อ pipeline ควรออกแบบเผื่อขั้นตอนดาวน์โหลดนี้ไว้ด้วย

ใครเรียกได้ และเงื่อนไขที่ต้องเปิดก่อน

สิทธิ์เข้าถึงถูกล็อกไว้ค่อนข้างแคบ ประกาศระบุว่าผู้ที่เรียกได้คือ enterprise owner และ billing manager, organization owner และผู้ที่ถือ custom role ระดับ organization หรือ enterprise ที่ให้สิทธิ์ View Copilot Metrics

และมีเงื่อนไขสำคัญอีกข้อ: ต้องเปิด Copilot usage metrics policy ก่อน ถึงจะมีข้อมูลให้ดึง — ถ้าองค์กรของคุณไม่เคยเปิดไว้ การเรียก endpoint วันนี้จะไม่ทำให้ข้อมูลย้อนหลังโผล่มาเอง ทีมที่วางแผนจะใช้ตัวเลขชุดนี้ประกอบการตัดสินใจต่อสัญญาหรือขยาย seat ควรไปเปิด policy ตั้งแต่วันนี้ เพื่อให้มีข้อมูลสะสมพอตอนที่ต้องใช้จริง

มุมมอง AI Curator

ปี 2026 คือปีที่ทุกองค์กรซื้อ AI coding agent ไปแล้ว และกำลังเข้าสู่ช่วงที่ต้องตอบให้ได้ว่ามันคุ้มไหม การที่ GitHub ดัน metrics ระดับ repository ขึ้น GA ในจังหวะนี้ไม่ใช่เรื่องบังเอิญ — มันคือเครื่องมือสำหรับ การต่อสัญญารอบสอง ซึ่งยากกว่ารอบแรกเสมอ เพราะรอบแรกขายด้วยความตื่นเต้น รอบสองต้องขายด้วยตัวเลข

แต่ตรงนี้แหละที่ต้องระวัง เพราะตัวเลขที่วัดได้ง่ายที่สุดมักไม่ใช่ตัวเลขที่สำคัญที่สุด จำนวน PR ที่เอเจนต์เปิดและ merge ไม่ใช่มูลค่า — PR ที่ merge เข้าไปแล้วต้องตามแก้อีกสามรอบมีค่าติดลบด้วยซ้ำ เช่นเดียวกับจำนวน suggestion จาก code review ที่นับได้ แต่ไม่ได้บอกว่ามีกี่อันที่คนจริง ๆ ยอมรับ ประวัติศาสตร์ของวงการซอฟต์แวร์เต็มไปด้วยองค์กรที่เอา metric ที่วัดง่ายไปตั้งเป็นเป้า แล้วได้พฤติกรรมที่ตรงตามเป้าแต่ผิดเจตนา — lines of code เคยเป็นบทเรียนนั้นมาแล้ว PR merged by agent มีศักยภาพจะเป็นบทเรียนเดียวกันในเวอร์ชันปี 2026

สำหรับองค์กรไทยที่กำลังอยู่ในช่วงทดลอง Copilot ทั้งบริษัท ข้อเสนอที่ตรงประเด็นที่สุดคือ: เปิด policy เก็บข้อมูลไว้เลย แต่ อย่าเพิ่งเอาตัวเลขนี้ไปผูกกับการประเมินทีมหรือรายบุคคล ใช้มันตอบคำถามระดับ portfolio ก่อน เช่น repo ไหนที่เอเจนต์ช่วยได้จริง repo ไหนที่มันแทบไม่ถูกใช้เลยทั้งที่จ่ายค่า seat เท่ากัน — คำถามแบบนี้ตอบได้ด้วยข้อมูลราย repo และให้ผลลัพธ์ที่ actionable โดยไม่สร้างแรงจูงใจให้ใครไปปั่นตัวเลข

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

แหล่งข่าว

• Repository-level GitHub Copilot usage metrics generally available — GitHub Changelog
• REST API endpoints for Copilot metrics — GitHub Docs
• GitHub Changelog