แผน GitHub Copilot: คู่มือฉบับสมบูรณ์เกี่ยวกับฟีเจอร์และการดูแลจัดการในแต่ละระดับ

แผน GitHub Copilot ฉบับย่อ

GitHub มีแผนแยกชัดเจนหลายระดับสำหรับระบบนิเวศของตน ที่น่าสังเกตคือแพลตฟอร์มจะดำเนินการเปลี่ยนไปใช้การคิดค่าบริการตามการใช้งานให้เสร็จสมบูรณ์ โดยแทนที่กรอบงานเดิม "Premium Request Unit" (PRU) ด้วย GitHub AI Credits ในเดือนมิถุนายน 2026

ภายใต้ระบบใหม่ การเติมโค้ดหลัก (code completion) และคำแนะนำ “Next Edit” ยังคงไม่จำกัดและไม่ใช้เครดิต 

แต่ปฏิบัติการขั้นสูงอย่างการแชตข้ามหลายไฟล์ เวิร์กโฟลว์แบบเอเจนต์ เซสชันเขียนโค้ดที่รันยาว และรีวิวโค้ดเชิงลึก จะใช้ AI Credits ตามการใช้โทเคน (อินพุต เอาต์พุต และโทเคนแคช) สัมพันธ์กับอัตรา API ที่เผยแพร่ของโมเดลนั้นๆ 

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

แผนรายบุคคล: Free, Student, Pro และ Pro+

ระดับรายบุคคลแตกต่างกันที่เกณฑ์การเข้าถึงโมเดล ขีดจำกัดการใช้งาน และความสามารถเชิงทดลอง ตัวอย่างเช่น Free เหมาะกับการสำรวจพื้นฐาน ขณะที่ Pro+ ให้เข้าถึง GitHub Spark ซึ่งเป็นสภาพแวดล้อมสำหรับสร้างแอปพลิเคชันที่มี AI ช่วย

ปัจจุบัน การลงทะเบียนใหม่สำหรับบัญชีรายบุคคลแบบเสียเงินของ GitHub อย่าง Pro, Pro+ และ Student ถูกพักไว้ บัญชีที่มีอยู่สามารถอัปเกรดจาก Pro เป็น Pro+ ได้ แต่บัญชีใหม่จะสมัครไม่ได้จนกว่า GitHub จะเปลี่ยนผ่านสู่ระบบคิดค่าใช้จ่ายแบบ AI Credits ตามการใช้งานเสร็จสิ้น

Business และ Enterprise

ในระดับ Business และ Enterprise แผน GitHub Copilot เปลี่ยนจากส่วนขยายของ IDE ไปเป็นทรัพย์สินโครงสร้างพื้นฐานองค์กรที่ตรวจสอบได้เต็มรูปแบบ

GitHub Copilot Business นำเสนอฟีเจอร์การจัดการสำคัญ ได้แก่

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

GitHub Copilot Enterprise เพิ่มการควบคุมและความสามารถมากขึ้นอีก ได้แก่

• Copilot Spaces: ฮับความรู้ที่ให้ผู้พัฒนาตั้งคำถามกับ Copilot จากเอกสารภายใน วิกิ และมาตรฐานโค้ดของระบบ
• การผสาน GitHub.com Chat ที่ดียิ่งขึ้น
• การสืบทอดนโยบายแบบลำดับชั้นข้ามองค์กรย่อย

GitHub Copilot Enterprise ต้องมีการสมัครสมาชิก GitHub Enterprise Cloud ที่ใช้งานอยู่ เนื่องจาก GitHub Enterprise Cloud มีค่าใช้จ่าย $21 ต่อผู้ใช้ต่อเดือน และไลเซนส์ Copilot Enterprise ราคา $39 ต่อผู้ใช้ต่อเดือน ต้นทุนขั้นต่ำจริงจึงอยู่ที่ $60 ต่อผู้ใช้ต่อเดือนสำหรับ Enterprise ข้อกำหนดนี้ไม่ใช้กับชั้น GitHub Copilot Business ซึ่งองค์กรที่ใช้แผน GitHub Free หรือ GitHub Team สามารถซื้อได้โดยตรง

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

หากกำลังพิจารณาแผน Enterprise คู่มือ GitHub Copilot Enterprise ของเราจะแสดงวิธีใช้ฟีเจอร์ต่างๆ เช่น Copilot Spaces และ Usage Metrics API ใหม่

อะไรที่แยกแผนรายบุคคลออกจากแผนสำหรับธุรกิจ

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

การจัดการข้อมูลและค่าตั้งเริ่มต้นของการฝึกโมเดล

สำหรับทีมที่จัดการระบบกรรมสิทธิ์ ความเป็นส่วนตัวของข้อมูล มักเป็นปัจจัยชี้ขาดระหว่างแผนส่วนบุคคลกับการสมัครแบบ Business

ในเดือนเมษายน 2026 GitHub เปลี่ยนวิธีเก็บข้อมูลการโต้ตอบสำหรับแผน Copilot รายบุคคล โดยสำหรับผู้ใช้ Free, Pro และ Pro+ ข้อมูลการโต้ตอบอาจถูกนำไปใช้ฝึกโมเดลโดยค่าเริ่มต้น เว้นแต่ผู้ใช้จะเลือกยกเลิก (opt-out)

มาทำความเข้าใจความแตกต่างระหว่างโค้ดขณะพัก (code at rest) กับข้อมูลการโต้ตอบ เพื่อให้ทราบว่าอะไรถูกใช้ในการฝึก AI:

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

ข้อตกลงของ Business และ Enterprise มีการรับประกันตามสัญญาอย่างเคร่งครัดว่าจะไม่ใช้ข้อมูลการโต้ตอบเพื่อการฝึกโมเดลไม่ว่ากรณีใดๆ โดยไม่ต้องอาศัยการตั้งค่าด้วยตนเองของผู้ใช้

หากต้องการเจาะลึกว่าใช้ข้อมูลอย่างไรและจะแก้ปัญหาใน Copilot ได้อย่างไร แนะนำให้อ่านคู่มือ ความเป็นส่วนตัวและการแก้ปัญหาใน GitHub Copilot ของเรา

การชดเชยความรับผิด IP

GitHub Copilot Business และ Enterprise มีความคุ้มครองการชดเชยความรับผิดด้านทรัพย์สินทางปัญญาสำหรับโค้ดที่สร้างขึ้น ขณะที่แผนรายบุคคลไม่มี

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

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

การเรียกเก็บเงิน ที่นั่ง และการเปลี่ยนไปใช้ AI Credits

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

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

SKU และข้อพิจารณาด้านความเป็นส่วนตัว

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

การเปลี่ยนนโยบายการฝึกโมเดลในเดือนเมษายน 2026

การเปลี่ยนจากโมเดลยินยอมเข้าร่วม (opt-in) ไปเป็นยกเลิกการเข้าร่วม (opt-out) สำหรับแผนรายบุคคล ตอกย้ำเวกเตอร์หลักของการรั่วไหลด้านการปฏิบัติตามข้อกำหนด โดยเพย์โหลดข้อมูลการโต้ตอบที่ถูกจับอัตโนมัติระหว่างเซสชัน IDE แบบแอคทีฟรวมถึง:

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

ลองนึกภาพนักพัฒนาใช้บัญชี Copilot Pro ส่วนตัวขณะทำงานในคลังโค้ดของบริษัท หากการฝึกยังเปิดใช้งานอยู่ ข้อมูลการโต้ตอบที่ผูกกับเซสชันนั้นอาจเข้าสู่ระบบฝึกโมเดลของ GitHub สถานการณ์เช่นนี้เป็นเหตุผลที่องค์กรจำนวนมากหันมาใช้แผน Business

การเลือก SKU ที่เหมาะกับข้อกำหนดด้านความเป็นส่วนตัว

ขึ้นอยู่กับระดับงานที่ทำ อาจต้องใช้ SKU ต่างกัน 

• นักพัฒนาเดี่ยว/โปรเจกต์ส่วนตัว: Free หรือ Pro ให้ความยืดหยุ่นสูงสุด เพียงเลือกยกเลิก (opt-out) ในการตั้งค่าความเป็นส่วนตัวส่วนบุคคลเมื่อต้องทำงานกับโค้ดกรรมสิทธิ์
• ฟรีแลนซ์/สัญญาจ้าง: แผน Business เป็นแนวป้องกัน ข้อตกลงกับลูกค้ามักระบุชัดว่าไม่ให้ส่งข้อมูลไปยังผู้ให้บริการ LLM ภายนอก การมีที่นั่งในองค์กรโดยเฉพาะช่วยปกป้องสัญญาของคุณ
• ทีมองค์กรที่มีข้อกำหนดการปฏิบัติตาม: ชั้น Business คือมาตรฐานขั้นต่ำ เพื่อให้มั่นใจว่าท่อข้อมูลถูกแยกและเปิดใช้งานการกำกับดูแลโดยผู้ดูแลระบบ
• อุตสาหกรรมกำกับดูแล (การเงิน การแพทย์): ชั้น Enterprise มักเป็นข้อบังคับ ช่วยบูรณาการกับคอนฟิกความปลอดภัยเฉพาะ ข้อกำหนดที่อยู่ข้อมูลที่เข้มงวด และชั้นการปรับแต่งเฉพาะที่อยู่ภายใน

ยกเว้นไฟล์บางรายการจาก Copilot

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

โปรดทราบว่า GitHub Copilot CLI เอเจนต์บนคลาวด์ของ Copilot และโหมด Agent ใน Copilot Chat บน IDE ยังไม่รองรับการยกเว้นเนื้อหา

การกำหนดค่ากฎยกเว้น

ทีมผู้ดูแลสามารถใช้ค่ายกเว้นได้ทั้งในระดับแผง Organization Settings ของทั้งองค์กร หรือเฉพาะคลังโค้ดรายโปรเจกต์ เข้าไปที่การตั้งค่าของคลังหรือองค์กรโดยกดปุ่ม Settings มุมขวาบน

เลือก “Code and automation” ใต้การตั้งค่า Copilot ในแถบด้านข้าง จากนั้นกรอกการยกเว้นในกล่อง “Paths to exclude in this repository” ตามตัวอย่างนี้:

# Ignore the /src/some-dir/kernel.rs file in this repository.
- "/src/some-dir/kernel.rs"

# Ignore files called secrets.json anywhere in this repository.
- "secrets.json"

# Ignore all files whose names begin with secret anywhere in this repository.
- "secret*"

# Ignore files whose names end with .cfg anywhere in this repository.
- "*.cfg"

# Ignore all files in or below the /scripts directory of this repository.
- "/scripts/**"

ระดับคลังโค้ดในองค์กรก็คล้ายกัน ยกเว้นว่าจะอยู่ภายใต้ “Repositories and Paths to exclude” โดยใช้รูปแบบดังนี้:

REPOSITORY-REFERENCE:
  - "/PATH/TO/DIRECTORY/OR/FILE"
  - "/PATH/TO/DIRECTORY/OR/FILE"
  - …

การคงค่า REPOSITORY-REFERENCE ไว้เป็นส่วนหนึ่งของการตั้งค่านั้นสำคัญ ค่าพื้นฐานการคอนฟิกที่พบบ่อยควรให้ความสำคัญกับข้อมูลลับแบบฮาร์ด โปรไฟล์ orchestration ของโปรดักชัน โมดูลอัลกอริทึมกรรมสิทธิ์ที่อ่อนไหว หรือโฟลเดอร์ปฏิบัติตามข้อกำหนดที่เข้มงวด

การบังคับใช้การยกเว้นข้ามฟีเจอร์ของ Copilot

เมื่อเกิดการแมตช์การยกเว้น การแยกข้อมูลจะเป็นแบบสมบูรณ์ในทุกซับซิสเต็มของ Copilot:

• การเติมอินไลน์: ถูกบล็อกไม่ให้สร้างบริบทภายในไฟล์ หรือดึงบริบทจากไฟล์นั้นไปเติมไฟล์ข้างเคียง
• Copilot chat/agents: ระบบจะแจ้งว่าไม่สามารถรีวิวไฟล์ได้เนื่องจากข้อจำกัดของนโยบายองค์กร

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

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

การจัดการนโยบายทั่วทั้งองค์กร

การบังคับใช้นโยบายขององค์กรสำหรับ GitHub Copilot ทำให้ความปลอดภัยของบริษัทถูกกำหนดโดยทีมผู้ดูแล แทนที่จะเป็นความชอบของนักพัฒนาแต่ละคน

การตั้งค่านโยบายที่มีให้ใช้

องค์กรสามารถควบคุมการตั้งค่าหลายอย่างสำหรับนักพัฒนา:

• สวิตช์ฟีเจอร์: เปิดหรือปิด Copilot Chat ทั่วทั้งสภาพแวดล้อมการพัฒนา อินเทอร์เฟซบรรทัดคำสั่ง (ผ่าน Copilot CLI) หรือระบบรีวิวโค้ดแบบเอเจนต์ขั้นสูง
• ตัวกรองโค้ดสาธารณะ: กลไกควบคุมด้านกฎหมายที่บล็อก Copilot ไม่ให้คืนคำแนะนำโค้ดที่คล้ายกับคลังโอเพนซอร์สสาธารณะบน GitHub มากเกินไป ลดความเสี่ยงด้านการปฏิบัติตามไลเซนส์โอเพนซอร์ส
• ข้อจำกัดการเลือกโมเดล: จำกัดว่าให้นักพัฒนาเลือกใช้โมเดลใดได้บ้าง (เช่น เวอร์ชันของ GPT หรือ Claude) เพื่อบริหาร latency การใช้เครดิต และประสิทธิภาพ หากต้องการดูรายละเอียดโมเดลที่มีในแพลตฟอร์มของ GitHub โปรดดูคู่มือเชิงปฏิบัติเรื่อง GitHub Models
• คำสั่งเฉพาะองค์กร:แทรกไฟล์นโยบายแบบมาร์กดาวน์มาตรฐานที่แนบแพทเทิร์นการเขียนโค้ดของบริษัท กรอบงานความปลอดภัย และพาราไดม์เชิงสถาปัตยกรรม เข้ากับทุกพรอมต์ที่นักพัฒนาของคุณส่ง

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

การสืบทอดนโยบายระดับเอ็นเตอร์ไพรส์

ในสภาพแวดล้อมองค์กรขนาดใหญ่ เอนจินนโยบายจะสืบทอดแบบลำดับชั้นที่เคร่งครัด: นโยบายระดับ Enterprise > นโยบายระดับองค์กร > การตั้งค่าผู้ใช้

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

ในระดับทีม อาจจำกัดฝ่ายบริการการเงินด้วยตัวกรองโค้ดสาธารณะที่เข้มงวด ขณะให้องค์กร R&D ภายในมีอิสระทดลองมากกว่า

บันทึกการตรวจสอบ (Audit Logs)

เมื่อผู้ตรวจสอบการปฏิบัติตามต้องการการยืนยันห่วงโซ่อุปทานซอฟต์แวร์ของคุณ หรือทีมความปลอดภัยติดตามการรั่วไหลของข้อมูล GitHub Copilot จะบันทึกการเปลี่ยนแปลงของแพลตฟอร์มไว้

เหตุการณ์ของ Copilot ในบันทึกการตรวจสอบ

ระบบจะบันทึกสมุดบัญชีของปฏิบัติการด้านการจัดการอย่างครอบคลุม ได้แก่

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

ความละเอียดของข้อมูลขึ้นอยู่กับการสมัครของคุณ ชั้น Business จะเน้นสตรีมเหตุการณ์ในขอบเขตองค์กร ขณะที่บัญชี Enterprise จะปลดล็อกเทเลเมทรีนิติวิทยาศาสตร์ข้ามองค์กรอย่างเป็นระบบ

การค้นหา การกรอง และการส่งออก

สตรีมบันทึกการตรวจสอบเข้าถึงได้โดยตรงผ่านแผง Organization Settings ผู้ดูแลสามารถคิวรีผ่านอินเทอร์เฟซด้วยตัวระบุการกระทำเฉพาะ:

# Filter logs to identify who adjusted Copilot access privileges
action:copilot.cfb_seat_assignment_created

# Identify changes made to systemic exclusions within a date window
action:copilot.content_exclusion_updated created:2026-05-01..2026-05-31

บัญชี Enterprise รองรับการสตรีมเหตุการณ์ตรวจสอบเหล่านี้ไปยังระบบ SIEM ภายนอก (เช่น Splunk หรือ Datadog) เพื่อการแจ้งเตือนอัตโนมัติและการเก็บรักษากลางที่ไม่เปลี่ยนแปลง

การจัดการที่นั่ง Copilot ด้วย REST API

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

นี่คือส่วนที่ฉันชอบของการดูแล Copilot เพราะเปลี่ยนการออกไลเซนส์ให้กลายเป็นสิ่งที่ทีมวิศวกรรมทำอัตโนมัติได้อย่างเรียบร้อย

เอนด์พอยต์ API สำคัญ

เวิร์กโฟลว์ API ที่พบบ่อย ได้แก่

• รายการมอบหมายที่นั่ง
• มอบหมายที่นั่ง
• ลบที่นั่ง
• ดึงเมตริกการใช้งาน
• อ่านการตั้งค่า Copilot ขององค์กร

การรับรองความถูกต้องมักต้องใช้:

• โทเคนเข้าถึงส่วนบุคคลแบบละเอียด
• สิทธิ์ของ GitHub App
• สิทธิ์ผู้ดูแลองค์กร

เพื่อเข้าถึงเส้นทางการจัดการเหล่านี้ สคริปต์อินทิเกรชันต้องยืนยันตัวตนด้วย Personal Access Token (PAT) ที่มีขอบเขต admin:org ขั้นสูง หรือทำงานผ่าน GitHub App ที่ได้รับอนุญาตพร้อมสิทธิ์การจัดการ Copilot ระดับองค์กรโดยชัดแจ้ง 

หากต้องการเจาะลึกการอินทิเกรตแพลตฟอร์มแบบโปรแกรมมิง แนะนำให้เรียนรู้เส้นทางทักษะ GitHub Foundations ของเรา 

แพตเทิร์นอัตโนมัติที่พบบ่อย

ตัวอย่างแพตเทิร์นที่ใช้งานได้จริง ได้แก่

• การออนบอร์ดอัตลักษณ์แบบอัตโนมัติ: เชื่อมระบบข้อมูลบุคคลากร (เช่น Workday หรือ Okta) เข้ากับ GitHub ผ่านเว็บฮุค เมื่อวิศวกรเข้าร่วมทีมที่กำหนด สคริปต์จะยิงคำขอ POST เพื่อจัดสรรพื้นที่ทำงาน Copilot ให้อัตโนมัติ

• การเรียกคืนที่นั่งที่ไม่ใช้งาน: สคริปต์ Cron ตามกำหนดเวลาเรียกดูการใช้ที่นั่งผ่าน API หากผู้ใช้ไม่ได้ใช้งาน Copilot เกิน 30 วัน สคริปต์จะสั่ง DELETE เพื่อเรียกคืนไลเซนส์ รักษาเครดิตขององค์กร

• แดชบอร์ดการเงิน: ดึงเทเลเมทรีการจัดสรรและการใช้ในแต่ละวันไปยังแพลตฟอร์ม BI ภายใน (เช่น Tableau) เพื่อการคิดค่าใช้จ่ายไขว้ในระดับแผนกอย่างโปร่งใส

ตัวอย่าง: มอบหมายที่นั่ง Copilot ด้วย Python

สคริปต์ต่อไปนี้สาธิตวิธีมอบหมายที่นั่งองค์กรให้กับนักพัฒนาเฉพาะด้วย Python:

	import requests
	# Identity Configuration
TOKEN = "YOUR_ORGANIZATION_ADMIN_PAT"
ORG = "your-corporate-org"
USERNAME = "target-developer-user"

url = f"https://api.github.com/orgs/{ORG}/copilot/billing/selected_users"

headers = {
    "Authorization": f"Bearer {TOKEN}",
    "Accept": "application/vnd.github+json",
    "X-GitHub-Api-Version": "2022-11-28"
}

payload = {
    "selected_usernames": [USERNAME]
}

response = requests.post(url, json=payload, headers=headers)

if response.status_code == 201:
    print(f"Successfully allocated Copilot seat to {USERNAME}.")
else:
    print(f"Failed allocation. Status: {response.status_code}")
    print(response.json())

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

โครงสร้างแผนของ GitHub Copilot ดูเรียบง่ายจากหน้าราคา แต่เมื่อเริ่มบริหารทีม ความแตกต่างจะชัดเจนและสำคัญขึ้นมาก

ขอบเขตความเป็นส่วนตัว นโยบายการฝึก ความสามารถในการตรวจสอบ และเครื่องมือกำกับดูแล มักสำคัญกว่าการเข้าถึงโมเดลเพียวๆ นั่นคือเหตุผลที่การถกเถียง GitHub Copilot ระหว่าง Business กับ Enterprise มักกลายเป็นบทสนทนาด้านความปลอดภัยและปฏิบัติการ มากกว่าด้านวิศวกรรมล้วนๆ

หากฉันต้องให้คำแนะนำทีมวันนี้ ฉันจะเริ่มจากข้อกำหนดด้านการกำกับดูแลก่อน:

• ต้องการการรับประกันความเป็นส่วนตัวตามสัญญาหรือไม่?
• ต้องการบันทึกการตรวจสอบหรือไม่?
• ต้องการการจัดการนโยบายแบบศูนย์กลางหรือไม่?

หลังจากนั้นจึงค่อยปรับให้เหมาะกับปริมาณการใช้งานและการเข้าถึงฟีเจอร์

เพื่อยกระดับขีดความสามารถทางเทคนิคของทีมและเตรียมพร้อมสำหรับการรับรองอย่างเป็นทางการ สำรวจเส้นทางการเรียนรู้อันล้ำหน้าต่อไปนี้:

• คอร์สพัฒนาซอฟต์แวร์ด้วย GitHub Copilot
• เส้นทางทักษะ AI สำหรับวิศวกรรมซอฟต์แวร์
• คู่มือการรับรอง GitHub สำหรับผู้เชี่ยวชาญด้านข้อมูล