Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
管理者向けGitHub Enterpriseの運用Tips紹介: 人にもAIにも優しいプラット...
Search
yuriemori
March 02, 2026
Technology
420
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
管理者向けGitHub Enterpriseの運用Tips紹介: 人にもAIにも優しいプラットフォームづくり
.NETラボ 勉強会 2026年2月でお話しした内容です
yuriemori
March 02, 2026
More Decks by yuriemori
See All by yuriemori
GitHub CopilotのFinOps- AI CreditのObservabilityと価値を生むためのエージェント設計
yuriemori
0
25
DevOps, SRE & Platform Engineering- A Journey Toward the Ideal Development Environment
yuriemori
0
100
GitHub Copilot のこれまでとこれから: From Copilot to Collaborative Agents
yuriemori
1
450
プロンプトエンジニアリングを超えて:自由と統制のあいだでつくる Platform × Context Engineering
yuriemori
0
410
GitHub Advanced Security × Defender for Cloudで開発とSecOpsのサイロを超える: コードとクラウドをつなぐ、開発プラットフォームのセキュリティ
yuriemori
1
230
Agentic AI 時代の DevOps セキュリティ 2.0- GitHub Advanced Security × Defender for Cloud による Platform Protection
yuriemori
1
200
プロンプトエンジニアリングを超えて:自由と統制のあいだでつくる Platform × Context Engineering
yuriemori
1
1k
生成AI時代のセキュアコーディングとDevSecOps
yuriemori
0
420
JuniorからSeniorまで: DevOpsエンジニアの成長ロードマップ
yuriemori
2
860
Other Decks in Technology
See All in Technology
AWS環境のセキュリティ不安を解消した企業事例 ~よくある課題と対策を一挙公開~
asanoharuki
0
240
AI工学特論: MLOps・継続的評価
asei
11
3k
事業成長とAI活用を止めないデータ基盤アーキテクチャの設計思想
hiracky16
0
770
ダッシュボード"開発"について 〜使われるダッシュボードのつくりかた〜
kimichan
0
240
信頼できるテスティングAIをどう育てるか?
odan611
0
160
DevOps Agentで運用判断をチーム資産にする~Agent InstructionsとAgent Skillを継続的に育てる~
fujioka6789
0
170
1台から試せる!Edge IoTを使った位置情報の活用設計【SORACOM Discovery 2026】
soracom
PRO
0
110
A Bag-of-Documents Model for Query Specificity
dtunkelang
0
160
AI時代におけるテストの基礎の再定義 / Rethinking the Fundamentals of Testing in the AI Era
mineo_matsuya
15
6.2k
QAと開発の両側から進める AI活用 -QAプロセスAI支援ツールキットと Inner Loop / Outer Loopの取り組み-
legalontechnologies
PRO
2
360
現場で使える AWS DevOps Agent 活用ノウハウ - Release Management 機能の検証結果を添えて / AWS DevOps Agent Release Management and Know-How
kinunori
4
760
AI Agent を本番環境へ―― Microsoft Foundry × Azure Serverless で作る Enterprise-Ready な基盤
shibayan
PRO
1
820
Featured
See All Featured
Leveraging Curiosity to Care for An Aging Population
cassininazir
1
440
How to train your dragon (web standard)
notwaldorf
97
6.7k
BBQ
matthewcrist
89
10k
The untapped power of vector embeddings
frankvandijk
2
1.8k
Accessibility Awareness
sabderemane
1
160
Navigating Weather and Climate Data
rabernat
0
420
Leo the Paperboy
mayatellez
8
1.9k
Jamie Indigo - Trashchat’s Guide to Black Boxes: Technical SEO Tactics for LLMs
techseoconnect
PRO
0
540
Introduction to Domain-Driven Design and Collaborative software design
baasie
1
920
SEOcharity - Dark patterns in SEO and UX: How to avoid them and build a more ethical web
sarafernandez
0
230
The Power of CSS Pseudo Elements
geoffreycrofte
82
6.5k
Designing for Performance
lara
611
70k
Transcript
管理者向けGitHub Enterpriseの運用Tips紹介: 人に もAIにも優しいプラットフォームづくり yuriemori .NET lab 1 / 20
お品書き GitHub Well Architected Frameworkに学ぶガバナンスのプラクティス GitHub EnterpriseのあるあるQ&A GitHub EnterpriseでのAgent/AIの管理 .NET
lab 2 / 20
Yurie Mori(森 友梨映) Job: Software Solution Engineer@Microsoft Japan Skills/Interests: GitHub/Azure DevOps/Defender
for Cloud/Azure PaaS DevOps/DevSecOps/IaC/Platform Engineering .NET lab 3 / 20
Please follow me X(旧Twitter)とLinkedInで発信しています。ぜひフォローしてください! .NET lab 4 / 20
GitHub Well Architectedに学ぶガバナンスのプラク ティス .NET lab 5 / 20
アンチパターン(抜粋) 不必要なOrganizationの分割 → 管理の煩雑化、ガバナンスの不整合、ナレッジのサイロ化に繋がる ブランチ戦略を定義しない 承認なしで変更がマージされる .NET lab 6 /
20
ベストプラクティス(抜粋) ガバナンスの違いごとにOrganizationを分ける rulesetを活用してブランチ,リポジトリに対してルールを適用する ガバナンスに関する方針やポリシーはバージョン管理できる形でドキュメント化 する レイヤごとに適切な権限を設定する .NET lab 7 /
20
GitHub EnterpriseのあるあるQ&A .NET lab 8 / 20
Organizationは単一?複数?どちらにすべき?(1/2) Organizationを分けた方がいいかどうかは組織内でリポジトリ/ユーザーに対して 適用したいガバナンスを特定のグループで分ける必要があるかどうかに依存す る。 Organizationでのレイヤーでは配下のリポジトリ、ユーザーに対する権限を制御 することができるので、ユーザーのグループやリポジトリ群に対して同じガバナ ンスを適用するのであれば、Organizationを分けてるメリットはあまりない。 (ま ったく同じ設定のOrganizationが複数存在することになるため) .NET
lab 9 / 20
Organizationは単一?複数?どちらにすべき?(2/2) Organizationを分けるメリットは、例えば部署ごとにOrganizationを分けること で、部署ごとに異なるガバナンスを適用できることや、部署ごとに管理者を設定 できることなどがある。 なので、適用させたいガバナンスの違いごとにOrganizationを分けるのが望まし い。 部署ごとなど、単純にユーザーを論理的にグルーピングするのであれば、 Organizationを分けるのではなくTeamを活用するのが望ましい。 昔はOrganizationは複数作らないほうがいいというプラクティスも紹介されてい たけども、現在ではその記述はなくなっている。
参考:組織のベストプラクティス .NET lab 10 / 20
Organizationで特定のユーザーグループごとに権限 を制御したい Teamを活用することで特定のユーザーを論理的にグルーピングして、特定のリポ ジトリに対する権限を定義したり、Team単位でCopilotのライセンス付与や権限 の制御ができる。 入れ子にすることもできる(が、階層が深くなると管理が大変になるので注意) 。 Team A userA-1
userA-2 user... Repository A-1 write Repository A-2 write Repository A-3 write Team B userB-1 userB-2 user... Repository B-1 write Repository B-2 write Repository B-3 write .NET lab 11 / 20
GitHub Enterprise - IdP連携を解除するとどうなる? Setpユーザー以外はユーザーは休眠ユーザーとして残る(PeopleのSuspendedで確認できる) 。 休眠中のユーザーはGitHub Enterpriseにログインできない。 IdP連携を再度有効化すれば、休眠ユーザーは復活する。 .NET
lab 12 / 20
EMUの環境を使っている。連携しているIdPの変更は できる? 最初はEntra IDで連携していたけど、途中でOktaなどの他のIdPに変更することはできるのか? Yes。 → 参考:新しい ID プロバイダーまたはテナントへの Enterprise
の移行 移行の際に既存のIdPの連携を切るときは、IdPの連携を停止するとSetupユーザー以外のすべてのユーザーが休眠ユーザーとな りアクセスできなくなるので、連携IdPを切る前にSetupユーザーが作業ができるように(=IdPに依存する認証なしでGitHub Enterpriseにアクセスできるように)しておく。 再びIdPと連携する際、usernameは移行元・移行先で一致するようにする必要がある。 最も安全なのはusernameに全く同じ値を設定していることだけど、正規化されてもこの値が移行先/移行元で完全に変わる場合 (
[email protected]
→
[email protected]
,
[email protected]
→
[email protected]
のように)は新しい Enterpriseアカウントのプロビジョニングが必要となる。 .NET lab 13 / 20
複数のEnterpriseを運用する際の注意点 .NET lab 14 / 20
Enterpriseはいくつまで作れる? 4つまで。同じGitHubアカウントでEnterprise ownerになっている環境が4つある 状態でEnterpriseを作成しようとすると、上限に達しているというメッセージが出 てくる この「4つ」はNon-EMUの環境もEMUの環境も両方含めた数。 .NET lab 15 /
20
EMUとNon-EMU, データレジデンシー版の併存はで きる? 現在提供されているのは、個人GitHubアカウントで利用を開始するGitHub Enteprise Cloudと、Entra IDなどのIdPでユーザーアカウントをプロビジョニング するEnterprise Managed Users(EMU)版、さらにEMUの場合、日本国内にデ
ータをホスティングするデータレジデンシー版の3つのオプションがある。 これらの環境の併存はできる。だが、IdPの連携において、同一Entraのテナント 内で、OIDC認証によるSSOの設定は1つのGitHub Enteprise環境でのみ可能。 .NET lab 16 / 20
GitHub Enterprise CloudとIdP連携 GitHub Enterprise Cloud - Microsoft Entra IDの連携:
Non-EMU(個人アカウント許容): SAML認証のみ対応 EMU(企業用アカウントで運用) :OIDC, SAML認証に対応 Enable OIDCのボタンを押してEntraに認証することでEntra IDにOIDC連携用のエ ンタープライズアプリケーションが登録される。 .NET lab 17 / 20
OIDC連携ができるのは1つのEnterprise環境のみ OIDC連携設定時に登録されるエンタープライズアプリケーションは、同一Entra テナント内の1つのみ。 そのため、すでにOIDC連携が完了しているGitHub Enterpriseがある状態で、2つ 目のEMUの環境を作ってOIDCの連携をしようとすると、すでにエンタープライズ アプリケーションがあるのでエラーになってしまう。 .NET lab 18
/ 20
SAML認証は複数の設定が可能 SAML認証の場合は、SAML連携用のエンタープライズアプリケーションを複数同 一テナント内に作ることができるため、併存させることは可能。 OIDC連携をしているGitHub Enterprise + SAML連携をしているGitHub Enterprise→ SAML連携をしているGitHub Enterprise
+ SAML連携をしているGitHub Enterprise→ OIDC連携をしているGitHub Enterprise + OIDC連携をしているGitHub Enterprise→ .NET lab 19 / 20
SAML認証で併存させる場合の注意点 SAML連携用のエンタープライズアプリケーションはそれぞれ別なので、どの GitHub Enterpriseはどのエンタープライズアプリケーションと連携しているのか を管理する必要がある。 .NET lab 20 / 20