GitHub Copilot Enterprise: คู่มือ Spaces และ Usage Metrics API

GitHub Copilot Enterprise คืออะไร

GitHub Copilot Enterprise อยู่บนสุดของ ลำดับชั้นแพ็กเกจ Copilot ของ GitHub.

เมื่อเทียบกับ GitHub Copilot Business หรือ Pro+ แพ็กเกจ Enterprise เน้นหนักที่การกำกับดูแล บริบทระดับองค์กร และความสามารถในการวัดผล ออกแบบมาสำหรับบริษัทที่มีสภาพแวดล้อมวิศวกรรมขนาดใหญ่ ไม่ใช่นักพัฒนาเดี่ยวหรือทีมเล็ก

สองความสามารถที่สำคัญที่สุดในการใช้งานจริง:

1. บริบทแบบกำหนดเองขององค์กรผ่าน Spaces
2. เทเลเมทรีทั่วทั้งองค์กรผ่าน Usage Metrics API

คุณสมบัติทั้งสองนี้เปลี่ยน Copilot จาก “ระบบเติมโค้ดอัตโนมัติอัจฉริยะ” ให้ใกล้เคียงแพลตฟอร์ม AI ด้านวิศวกรรมภายใน

บริษัทที่ได้คุณค่าสูงสุดจาก GitHub Copilot Enterprise จะปฏิบัติกับมันเสมือนเป็นองค์ประกอบสำคัญของโครงสร้างพื้นฐานภายใน กำหนดค่าบริบทองค์กรอย่างรอบคอบ วัดการนำไปใช้อย่างต่อเนื่อง และปรับนโยบายตามข้อมูลการใช้งานแทนการคาดเดา

หากต้องการมุมมองภาพรวมของระบบนิเวศ GitHub แนะนำให้อ่านคู่มือ Introduction to GitHub Products ของเรา

ความแตกต่างระหว่าง Enterprise กับ Business และ Pro+

GitHub Copilot Enterprise ต่อขยายจากการสมัครสมาชิกแบบ Business ด้วยคุณสมบัติเพิ่มเติม เช่น:

• เมตริกการใช้งานในระดับองค์กร
• การควบคุมด้านธรรมาภิบาลที่ขยายขึ้น
• การสืบนโยบายทั่วทั้งองค์กร
• โควตาการร้องขอระดับพรีเมียมที่มากกว่า (1,000 เทียบกับ 300 ในระดับ Business)
• การเข้าถึงและการจัดการโมเดลเพิ่มเติม

Enterprise ต้องใช้ GitHub Enterprise Cloud นอกเหนือจากการสมัครสมาชิก Copilot Enterprise เอง ซึ่งเพิ่มค่าใช้จ่ายต่อผู้ใช้ ดังนั้นควรตรวจสอบให้องค์กรจำเป็นต้องมีการกำกับดูแล เทเลเมทรี และการบริหารจัดการระดับองค์กรจริง ๆ

หมายเหตุ: ผู้สมัครสมาชิกแบบ Business เข้าถึง Usage Metrics API ได้ในระดับองค์กร (/orgs/{org}/…) ส่วนสมาชิก Enterprise เข้าถึงรายงานรวมระดับองค์กร (/enterprises/{enterprise}/…) เพิ่มเติม ครอบคลุมทุกองค์กรในมุมมองเดียว

GitHub Copilot Enterprise เหมาะกับใคร

GitHub Copilot Enterprise มุ่งเป้าไปที่องค์กรที่ใช้งาน GitHub อย่างเป็นระบบและเติบโตแล้ว

ลูกค้า Enterprise ทั่วไป ได้แก่:

• องค์กรวิศวกรรมขนาดใหญ่
• อุตสาหกรรมที่ถูกกำกับดูแล
• กลุ่มวิศวกรรมแพลตฟอร์มแบบหลายทีม
• บริษัทที่มีมาตรฐานการพัฒนาภายใน
• องค์กรที่ต้องการธรรมาภิบาลแบบรวมศูนย์

โปรดทราบว่าสิ่งนี้ไม่ได้ทำให้ประสิทธิภาพของ Copilot ดีขึ้นโดยตัวมันเอง ประเด็นนี้สำคัญเพราะหลายทีมมักซื้อเกินความจำเป็นในช่วงแรก โดยคิดว่า Enterprise เท่ากับ “Copilot ที่ดีกว่า” ทั้งที่ความจริง Enterprise เพิ่มเครื่องมือด้านธรรมาภิบาลและการวัดผลเป็นหลัก

Copilot Spaces: บริบทแบบกำหนดเองสำหรับองค์กรของคุณ

Copilot Spaces แก้หนึ่งในจุดอ่อนใหญ่ของผู้ช่วยเขียนโค้ด AI แบบทั่วไป

โดยพื้นฐาน Copilot เข้าใจความรู้โปรแกรมมิ่งสาธารณะได้ดีพอควร แต่ไม่ได้เข้าใจ API ภายใน การตัดสินใจด้านสถาปัตยกรรม มาตรฐานการเขียนโค้ด เวิร์กโฟลว์การดีพลอย หรือเอกสารแนะนำการเริ่มต้นใช้งานของคุณโดยอัตโนมัติ

Spaces มอบบริบทขององค์กรที่คัดสรรไว้ให้ Copilot อ้างอิงระหว่างการสนทนาและการช่วยเหลือการเขียนโค้ด

ในทางปฏิบัติ Spaces ช่วยให้ Copilot ตอบคำถามอย่างเช่น:

• “ภายใน เราจัดโครงสร้างตัวจัดการ API อย่างไร?”
• “ทีมแพลตฟอร์มของเราแนะนำไลบรารีสำหรับการยืนยันตัวตนตัวไหน?”
• “ไมโครเซอร์วิสนี้ควรใช้เวิร์กโฟลว์ดีพลอยแบบใด?”
• “ทีมแบ็กเอนด์ของเราใช้มาตรฐานการตั้งชื่อแบบไหน?”

สิ่งที่ Spaces รองรับ

Spaces รองรับเนื้อหาระดับองค์กรที่กว้างกว่าระบบ Knowledge Bases เดิม

ประเภทเนื้อหาที่รองรับ ได้แก่:

• ไฟล์โค้ด
• เอกสาร Markdown
• ไฟล์ JSON
• ไฟล์อัปโหลด
• รูปภาพ
• GitHub Issues
• Pull requests

แต่ละประเภทมีบทบาทต่างกัน

ไฟล์โค้ดช่วยให้ Copilot เข้าใจแพตเทิร์นการลงมือทำ เอกสาร Markdown ให้คำอธิบายสถาปัตยกรรมและแนวทางการเริ่มต้นใช้งาน Pull requests เปิดให้เห็นการรีวิวและการตัดสินใจทางวิศวกรรมในอดีต การผสานกันของทั้งหมดนี้ทำให้ Copilot ตระหนักถึงแนวปฏิบัติการพัฒนาขององค์กรคุณได้ดีขึ้น

ประเด็นเล็กแต่สำคัญคือ Spaces ไม่ได้เป็นเพียงฐานข้อมูลเวกเตอร์ที่ผูกกับ GitHub เท่านั้น แต่ยังมีการควบคุมการแชร์และเวิร์กโฟลว์ธรรมาภิบาลขององค์กรที่ออกแบบมาสำหรับสภาพแวดล้อมระดับองค์กร

การยุติการใช้งาน Knowledge Bases

GitHub ยุติฟีเจอร์ Copilot Knowledge Bases เดิมเมื่อวันที่ 1 พฤศจิกายน 2025

Spaces เข้ามาแทนด้วย:

• การรองรับเนื้อหาที่กว้างขึ้น
• การควบคุมการแชร์ที่ดีกว่า
• การดูแลระบบที่ปรับปรุงขึ้น
• การจัดการในระดับองค์กรที่ยืดหยุ่นกว่า

คุณอาจยังพบเอกสารและบล็อกเก่าที่อ้างถึง Knowledge Bases โปรดระวังเมื่อทำตามบทช่วยสอนเก่า ๆ เพราะหลายจุดปลายทางและเวิร์กโฟลว์เปลี่ยนไปในช่วงเปลี่ยนผ่านปี 2025 ถึง 2026

การสร้างและกำหนดค่า Copilot Spaces

ในมุมมองของผู้ดูแลระบบ Copilot Spaces สร้างได้ไม่ซับซ้อน ความท้าทายอยู่ที่การจัดการหลายสิบหรือหลายร้อย Space ข้ามทีม

โครงสร้างที่เลือกตั้งแต่แรกมักจะติดตัวไป ฉันเคยเห็นองค์กรสร้าง “เอกสารกระจัดกระจาย” ภายใน Spaces โดยไม่ตั้งกฎความเป็นเจ้าของตั้งแต่เริ่มต้น

ใครก็สามารถสร้าง Copilot Space ได้ ลองสร้างในรีโปส่วนตัวกันก่อน ขั้นตอนคล้ายกันในระดับ Enterprise เพียงแต่หน้าจอแตกต่างเล็กน้อย

การตั้งค่า Space

การสร้าง Space โดยทั่วไปมีเวิร์กโฟลว์ดังนี้:

1. ไปที่หน้า Copilot Spaces ในพื้นที่การดูแลระบบของ Enterprise
2. สร้าง Space ใหม่

3. เลือกรีโพซิทอรีและแหล่งเนื้อหา รวมถึง MCP และเครื่องมือที่เป็นประโยชน์อื่น ๆ

4. เพิ่มแหล่งที่มาด้วยการคลิกปุ่ม “+ Add sources” ทางด้านขวา

5. สามารถเลือกแชร์ Space หรือกำหนดการตั้งค่าการแชร์ในขั้นตอนนี้

6. ตรวจสอบว่า Copilot อ้างอิงเนื้อหาได้ระหว่างการสนทนา

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

หลังการตั้งค่า ผู้ดูแลระบบควรทดสอบ Space ด้วยพรอมป์ต์ที่ใช้งานจริง

ตัวอย่างเช่น:

How does our authentication middleware handle token refresh logic?

หรือ:

Show me an example of how our backend services structure database migrations.

หาก Copilot ตอบไม่ได้อย่างแม่นยำ ปัญหามักเป็นเพราะ:

• ขาดรีโพซิทอรีที่เกี่ยวข้อง
• คุณภาพเอกสารไม่ดี
• สิทธิ์ไม่ถูกต้อง
• เวลาในการทำดัชนีไม่เพียงพอ

การแชร์และการควบคุมการเข้าถึง

Spaces รองรับรูปแบบการมองเห็นหลักสองแบบ:

• Spaces ส่วนบุคคล
• Spaces ระดับองค์กร

สมาชิกขององค์กรสามารถให้ Space ส่วนบุคคลถูกจัดการด้วยการตั้งค่าในระดับองค์กรได้ ผู้ดูแลระบบ Enterprise ยังสามารถจัดการนโยบายการเปิดใช้งานฟีเจอร์และตัวอย่างใช้งานได้แบบรวมศูนย์

Spaces แบบส่วนตัวเหมาะกับทีมทดลองหรือโครงการภายในที่อ่อนไหว Spaces ระดับองค์กรเหมาะกับมาตรฐานวิศวกรรม เอกสารการเริ่มต้นใช้งาน หรือเฟรมเวิร์กที่ใช้ทั่วบริษัท

ข้อผิดพลาดที่พบบ่อยคือการรวมศูนย์เกินไป Space ขนาดใหญ่ที่ครอบคลุมทั้งบริษัทอาจมีสัญญาณรบกวนมากและทำให้ Copilot ใช้งานได้ไม่เต็มประสิทธิภาพ

การจัดระเบียบ Spaces ตามทีมหรือโดเมน

ไม่มีโครงสร้างองค์กรที่ถูกต้องแบบสากล

แพตเทิร์นที่พบบ่อย ได้แก่ หนึ่ง Space ต่อทีม หนึ่ง Space ต่อพื้นที่ผลิตภัณฑ์ หรือ Space มาตรฐานที่ใช้ร่วมกัน แต่ละแบบมีขอบเขตต่างกันและใช้การตั้งค่า Space ในลักษณะต่างกัน

หนึ่ง Space ต่อทีม

เหมาะเมื่อกลุ่มวิศวกรรมทำงานค่อนข้างอิสระต่อกัน

ตัวอย่าง:

• วิศวกรรมแพลตฟอร์ม
• วิศวกรรมข้อมูล
• พัฒนามือถือ

หนึ่ง Space ต่อพื้นที่ผลิตภัณฑ์

เหมาะสำหรับองค์กรที่จัดโครงสร้างตามผลิตภัณฑ์มากกว่าตามแผนก

ตัวอย่าง:

• การชำระเงิน
• การวิเคราะห์
• โครงสร้างพื้นฐาน
• แพลตฟอร์มลูกค้า

Space มาตรฐานที่ใช้ร่วมกัน

หลายองค์กรดูแล Space แยกต่างหากสำหรับ:

• แนวทางความปลอดภัย
• มาตรฐานการเขียนโค้ด
• เวิร์กโฟลว์การดีพลอย
• มาตรฐานสถาปัตยกรรม

ในทางปฏิบัติ แนวทางแบบไฮบริดมักได้ผลดีที่สุด แต่ละทีมอาจมี Space ของตนเอง และมี Space มาตรฐานขนาดใหญ่แชร์ร่วมกันระหว่างทีม

Copilot Usage Metrics API

Spaces แก้ปัญหาบริบท ส่วน Usage Metrics API แก้ปัญหาการวัดผล โดยแทนที่ระบบเทเลเมทรีรุ่นเก่าหลายรายการที่ GitHub เลิกใช้ระหว่างการรวม API ในปี 2026

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

แดชบอร์ดเปิดให้ใช้งานทั่วไปในกุมภาพันธ์ 2026 และเข้าถึงได้ผ่านบัญชีองค์กรของคุณ → AI Controls → Copilot → Metrics → Copilot usage metrics ในแท็บ Insights

ตัวอย่างแดชบอร์ด Copilot Usage Metrics จาก github.blog

API วัดอะไรบ้าง

Usage Metrics API เปิดเผยหมวดหมู่เทเลเมทรีการปฏิบัติงานหลายรายการ

เมตริกทั่วไปได้แก่:

• ผู้ใช้งานประจำ
• จำนวนบรรทัดโค้ดที่ถูกเสนอเทียบกับบรรทัดที่ยอมรับ
• รูปแบบการใช้งาน IDE
• การใช้งานโมเดล
• การโต้ตอบกับเอเจนต์
• สัดส่วนภาษาโปรแกรม

สิ่งนี้ให้องค์กรเห็นภาพที่ละเอียดกว่าการนับที่นั่งเพียงอย่างเดียว

ทีมที่มีที่นั่ง 100 ที่ แต่มีผู้ใช้งานจริงเพียง 15 คน มีโปรไฟล์การนำไปใช้ที่ต่างจากทีมที่ใช้งานประจำทุกวันและมีอัตรายอมรับสูงอย่างมาก

การเปลี่ยนผ่าน API ในปี 2026

GitHub เลิกใช้ API เทเลเมทรีรุ่นเก่าหลายตัว (User-level Feature Engagement Metrics API, Direct Data Access API, Copilot Metrics API) ระหว่างช่วงปี 2025 ถึง 2026 และยุติสมบูรณ์ในเมษายน 2026

ซึ่งรวมถึง:

• Metrics API แบบเดิม
• Feature Engagement APIs
• Direct Data Access APIs

จุดปลายทาง Usage Metrics รุ่นใหม่ที่เปิดให้ใช้ตั้งแต่กุมภาพันธ์ 2026 รวมระบบรายงานเหล่านั้นเป็นโมเดลที่เป็นหนึ่งเดียวมากขึ้น รวมถึงการกำหนดเวอร์ชันของ API ในกรณีที่มีการเปลี่ยนแปลงที่ทำให้เข้ากันไม่ได้ย้อนหลัง

เรื่องนี้สำคัญ เพราะยังมีบล็อกและตัวอย่างบน GitHub เก่าจำนวนมากที่อ้างถึงจุดปลายทางที่เลิกใช้แล้ว ทุกครั้งที่ทำงานกับ Usage Metrics API ควรตรวจเอกสารเทียบกับข้อมูลอ้างอิง API ล่าสุดของ GitHub ก่อนสร้างระบบอัตโนมัติ

การดึงข้อมูลจาก Usage Metrics API

เมื่อเข้าใจวัตถุประสงค์ของ usage metrics API แล้ว มาดูวิธีใช้งานจริงกัน

การยืนยันตัวตนและสิทธิ์

จุดปลายทาง GitHub Copilot Usage Metrics โดยทั่วไปต้องตั้งค่าสิทธิ์บางอย่างให้กับ Personal Access Token (PAT) ซึ่งทำได้ผ่านทั้ง PAT แบบคลาสสิกหรือแบบกำหนดสิทธิ์ละเอียด

• สำหรับ PAT แบบคลาสสิก ต้องให้ผู้ดูแลระบบองค์กรกำหนดสิทธิ์ต่อไปนี้: manage_billing:copilot และ read:org 

• สำหรับโทเค็นแบบกำหนดสิทธิ์ละเอียด ต้องใช้โทเค็นการเข้าถึงของผู้ใช้แอป GitHub หรือโทเค็นการติดตั้ง พร้อมชุดสิทธิ์ Enterprise Copilot metrics enterprise permissions (read)

โดยทั่วไป ควรใช้โทเค็นแบบกำหนดสิทธิ์ละเอียดเพื่อลดการเปิดเผยสิทธิ์ที่ไม่จำเป็น

จุดปลายทางระดับองค์กร

รายงานระดับองค์กรที่พบบ่อยสองรายการคือ:

• organization-1-day

• organization-28-day

รายงานหนึ่งวันระดับองค์กร

รายงานหนึ่งวันเหมาะกับการมอนิเตอร์เชิงปฏิบัติการและวิเคราะห์แนวโน้มระยะสั้น ข้อมูลย้อนหลังมีตั้งแต่ 10 ตุลาคม 2025 และเข้าถึงได้ย้อนไปไม่เกินหนึ่งปีจากวันที่ปัจจุบัน

คำสั่ง curl ด้านล่างจะเรียก API รายงานแบบหนึ่งวัน และส่งคืน JSON ที่มีลิงก์ดาวน์โหลดสำหรับรายงานการใช้งาน ต้องใส่ YOUR_TOKEN ใน bearer auth และเลือก DAY เป็นวันที่ต้องการในรูปแบบ YYYY-MM-DD

curl -L \
 -H "Accept: application/vnd.github+json" \
 -H "Authorization: Bearer <YOUR_TOKEN>" \
-H “X-GitHub-Api-Version: 2026-03-10” \
"https://api.github.com/enterprises/ENTERPRISE/copilot/metrics/reports/enterprise-1-day?day=DAY"

URL ใน download_links มีการลงนามและจำกัดเวลา หมายความว่าจะหมดอายุไม่นานหลังดึงมา เวิร์กโฟลว์ต้องดึง URL ดาวน์โหลดและดาวน์โหลดไฟล์ทันทีในการรันเดียวกัน ไม่สามารถเก็บ URL เหล่านี้ไว้ใช้ภายหลัง

การตอบกลับที่ได้อาจมีเพียง download_links และ report_day แต่สคีมาที่เป็นไปได้ทั้งหมดคือ:

{
  "type": "object",
  "title": "Copilot Metrics 1 Day Report",
  "description": "Links to download the Copilot usage metrics report for an enterprise/organization for a specific day.",
  "properties": {
    "download_links": {
      "type": "array",
      "items": {
        "type": "string",
        "format": "uri"
      },
      "description": "The URLs to download the Copilot usage metrics report for the enterprise/organization for the specified day."
    },
    "report_day": {
      "type": "string",
      "format": "date",
      "description": "The day of the report in YYYY-MM-DD format."
    }
  },
  "required": [
    "download_links",
    "report_day"
  ]
}

รายงาน 28 วันระดับองค์กร

รายงาน 28 วันช่วยระบุรูปแบบการนำไปใช้ในวงกว้างและการเปลี่ยนแปลงการใช้งานระยะยาว คำสั่งคล้ายกันมาก เพียงเปลี่ยนไปใช้ API แบบ 28 วัน

ตัวอย่างคำขอ:

curl -L \
 -H "Accept: application/vnd.github+json" \
 -H "Authorization: Bearer <YOUR_TOKEN>" \
-H “X-GitHub-Api-Version: 2026-03-10” \
https://api.github.com/enterprises/ENTERPRISE/copilot/metrics/reports/enterprise-28-day/latest

จะได้การตอบกลับคล้ายกัน ยกเว้นว่าจะมี response_start_day และ response_end_day

โครงสร้างรายงานระดับองค์กร

รายงาน JSON สำหรับทั้งแบบหนึ่งวันและ 28 วันของระดับองค์กร อาจมีหน้าตาแบบนี้:

[
  {
    "user_id": 1001,
    "user_login": "octocat",
    "day": "2026-05-14",
    "organization_id": "999",
    "team_id": 42,
    "slug": "frontend"
  },
  {
    "user_id": 1001,
    "user_login": "octocat",
    "day": "2026-05-14",
    "organization_id": "999",
    "team_id": 43,
    "slug": "backend"
  },
  {
    "user_id": 1002,
    "user_login": "hubot",
    "day": "2026-05-14",
    "organization_id": "999",
    "team_id": 42,
    "slug": "frontend"
  }
]

จะเห็นว่าให้ภาพรวมระดับสูงของผู้ใช้ภายในองค์กร ทีมของพวกเขา และแท็กทีม

จุดปลายทางระดับผู้ใช้

รายงานระดับผู้ใช้ให้ภาพที่ละเอียดขึ้นของการนำไปใช้ หมายความว่าสามารถเข้าใจได้ว่าบุคคลใช้งาน Copilot อย่างไรในระดับสูง

จุดปลายทางทั่วไปได้แก่:

• users-1-day

• users-28-day

• user-teams-1-day

รายงานเหล่านี้ช่วยผู้ดูแลระบบระบุ:

• ผู้ใช้ที่ใช้งานหนัก
• ทีมที่มีการนำไปใช้น้อย
• โอกาสในการฝึกอบรม
• แนวโน้มการใช้งานในระดับแผนก

คำขอเหล่านี้คล้ายกับรายงานหนึ่งวันและ 28 วันระดับองค์กร เพียงชี้ไปที่ API คนละตัว

รายงานหนึ่งวันระดับผู้ใช้

ตัวอย่างการเรียก API users-1-day:

curl -L \
  -H "Accept: application/vnd.github+json" \
  -H "Authorization: Bearer <YOUR-TOKEN>" \
  -H "X-GitHub-Api-Version: 2026-03-10" \
  "https://api.github.com/enterprises/ENTERPRISE/copilot/metrics/reports/users-1-day?day=DAY"

รายงาน 28 วันระดับผู้ใช้

ตัวอย่างการเรียก API users-28-day:

curl -L \
  -H "Accept: application/vnd.github+json" \
  -H "Authorization: Bearer <YOUR-TOKEN>" \
  -H "X-GitHub-Api-Version: 2026-03-10" \
   https://api.github.com/enterprises/ENTERPRISE/copilot/metrics/reports/users-28-day/latest

รายงานหนึ่งวันระดับผู้ใช้-ทีม

ยังมีจุดปลายทาง user-teams-1-day ซึ่งแมปผู้ใช้แต่ละคนกับการเป็นสมาชิกทีมของตน โดยตัวมันเองไม่มีเมตริกการใช้งาน จุดประสงค์คือใช้เป็นคีย์สำหรับเชื่อมเมื่ออยากรวมข้อมูลรายผู้ใช้ตามทีม

โครงสร้างรายงานระดับผู้ใช้

ระดับรายละเอียดภายในรายงานเหล่านี้สูงกว่ามาก เพราะชี้ไปที่ข้อมูลการใช้งานของผู้ใช้รายบุคคล:

[{
  "code_acceptance_activity_count": 1,
  "code_generation_activity_count": 1,
  "day": "2025-10-01",
  "enterprise_id": "1",
  "loc_added_sum": 8,
  "loc_deleted_sum": 0,
  "loc_suggested_to_add_sum": 10,
  "loc_suggested_to_delete_sum": 0,
  "totals_by_cli": {
    "last_known_cli_version": {
      "cli_version": "1.0.8",
      "sampled_at": "2025-10-01T00:01:43.000Z"
    },
    "prompt_count": 2,
    "request_count": 2,
    "session_count": 2,
    "token_usage": {
      "avg_tokens_per_request": 4400.0,
      "output_tokens_sum": 5000,
      "prompt_tokens_sum": 3800
    }
  },
  "totals_by_feature": [{
    "code_acceptance_activity_count": 1,
    "code_generation_activity_count": 1,
    "feature": "code_completion",
    "loc_added_sum": 8,
    "loc_deleted_sum": 0,
    "loc_suggested_to_add_sum": 10,
    "loc_suggested_to_delete_sum": 0,
    "user_initiated_interaction_count": 0
  }],
  "totals_by_ide": [{
    "code_acceptance_activity_count": 1,
    "code_generation_activity_count": 1,
    "ide": "vscode",
    "last_known_ide_version": {
      "ide_version": "1.85.0",
      "sampled_at": "2025-10-01T00:00:02.000Z"
    },
    "last_known_plugin_version": {
      "plugin": "",
      "plugin_version": "",
      "sampled_at": "2025-10-01T00:00:02.000Z"
    },
    "loc_added_sum": 8,
    "loc_deleted_sum": 0,
    "loc_suggested_to_add_sum": 10,
    "loc_suggested_to_delete_sum": 0,
    "user_initiated_interaction_count": 0
  }],
  "totals_by_language_feature": [{
    "code_acceptance_activity_count": 1,
    "code_generation_activity_count": 1,
    "feature": "code_completion",
    "language": "unknown",
    "loc_added_sum": 8,
    "loc_deleted_sum": 0,
    "loc_suggested_to_add_sum": 10,
    "loc_suggested_to_delete_sum": 0
  }],
  "totals_by_language_model": [],
  "totals_by_model_feature": [],
  "used_agent": false,
  "used_chat": false,
  "used_cli": true,
  "user_id": 1,
  "user_login": "login1",
  "user_initiated_interaction_count": 0,
  "etl_id": "green",
  "day_partition": "2025-10-01",
  "entity_id_partition": 1
}]

เมตริกเหล่านี้มีคุณค่าในฐานะสัญญาณการนำไปใช้ระดับทีม อัตราการยอมรับและจำนวนการใช้งานเป็นสัญญาณการปฏิบัติงาน ไม่ใช่มาตรวัดคุณภาพของนักพัฒนา

สำหรับเมตริกทั้งหมดที่อาจพบ โปรดดู เอกสารข้อมูลเมตริกการใช้งานของ GitHub เพื่อข้อมูลล่าสุด

รายงานระดับผู้ใช้รวมข้อมูลการโต้ตอบผ่าน CLI ด้วย หากทีมใช้งาน Copilot ผ่านคอมมานด์ไลน์ บทช่วยสอน GitHub Copilot CLI ของเราครอบคลุมการตั้งค่าและเวิร์กโฟลว์ที่พบบ่อย

การสร้างเวิร์กโฟลว์รายงานของ Copilot

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

ทีมที่ได้คุณค่าสูงสุดจาก Copilot Enterprise มักสร้างไปป์ไลน์รายงานแบบเบาที่ผสานเทเลเมทรีการใช้งานเข้ากับเมตริกวิศวกรรมภายใน

เมตริกสำคัญเพื่อพิสูจน์ ROI

ไม่ใช่ทุกเมตริกของ Copilot จะสำคัญเท่ากัน เมตริกที่มีประโยชน์มักรวมถึง:

• การเติบโตของผู้ใช้งานประจำ
• แนวโน้มอัตราการยอมรับ
• โค้ดที่ถูกเสนอเทียบกับโค้ดที่คงอยู่
• การปรับปรุงเวลาในรอบ PR
• ความถี่การมีส่วนร่วมกับ IDE

GitHub เผยแพร่บันทัดฐานไว้ เช่น:

• ทำงานเสร็จเร็วขึ้น 55%
• อัตราการคงอยู่ของโค้ด 88%

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

จากข้อมูลดิบสู่แดชบอร์ดทีม

เวิร์กโฟลว์รายงานแบบเบามักมีลักษณะดังนี้:

1. เรียก API ตามกำหนดเวลา
2. เก็บการตอบกลับในฐานข้อมูลหรือสเปรดชีต
3. แปลงข้อมูลเป็นตารางรายงาน
4. แสดงผลเมตริกในแพลตฟอร์ม BI ที่มีอยู่

สแตกที่ใช้สำคัญน้อยกว่าความสม่ำเสมอ

แม้เวิร์กโฟลว์ง่าย ๆ ที่ใช้สคริปต์ Python ตามกำหนดและส่งออกเป็น CSV ก็ให้การมองเห็นเชิงปฏิบัติการที่เป็นประโยชน์ได้

สถาปัตยกรรมตัวอย่าง:

GitHub API

  ↓

สคริปต์ Python แบบตั้งเวลา

  ↓

PostgreSQL / CSV / สเปรดชีต

  ↓

Power BI / Tableau / Looker

ข้อคิดส่งท้าย

สาระสำคัญของ GitHub Copilot Enterprise คือการสร้างโครงสร้างพื้นฐานให้พร้อมสำหรับโค้ดที่ขับเคลื่อนด้วย AI Spaces มอบบริบทระดับองค์กรที่ทำให้ Copilot มีประโยชน์ยิ่งขึ้นในสภาพแวดล้อมวิศวกรรมจริง ส่วน Usage Metrics API มอบเทเลเมทรีที่จำเป็นต่อการเข้าใจว่าการนำไปใช้ประสบความสำเร็จหรือไม่

องค์กรที่ได้ผลลัพธ์แข็งแกร่งจาก Copilot Enterprise มักมีรูปแบบร่วมกัน:

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

ทัศนคตินี้สำคัญกว่าการจัดสรรที่นั่งเพียงอย่างเดียวมาก

หากต้องการต่อยอดทักษะด้าน Copilot และ AI แนะนำคอร์ส Software Development with GitHub Copilot หรือเส้นทางทักษะ AI for Software Engineering