GitHub Administration – Certificationsの更新でまず押さえるべき結論は、GH-100の学習軸が「GitHub Enterpriseを安全に管理・展開・監査できるか」に明確に寄っている点です。単にGitHubの基本操作を知っているだけでは足りず、SAML SSO、SCIM、権限設計、GitHub Actions、ランナー、GitHub Advanced Security、監査ログ、ライセンス最適化までを実務レベルで理解する必要があります。
2026年5月上旬に確認できる公式情報では、Microsoft Learnの認定ページは「Last Updated 05/04/2026」、GH-100スタディガイドは「Last updated on 2026-05-05」と示されています。試験ページ本体とスタディガイドの両方を確認し、特に2026年7月以降のスキル測定項目に沿って、学習計画と社内のGitHub Enterprise設定を見直すのが現実的な対応です。(Microsoft Learn)
GitHub Administration – Certificationsとは
GitHub Administration – Certificationsは、GitHub Enterprise環境の管理者向け認定です。対象者は、GitHub Enterprise Administrationに関する中級レベルの経験を持つシステム管理者、ソフトウェア開発者、アプリケーション管理者、ITプロフェッショナルとされています。(Microsoft Learn)
試験で問われるのは、リポジトリの作成やPull Requestの操作だけではありません。公式の概要では、ユーザーIDとアクセス管理、GitHub Actions、エンタープライズレベルのガバナンス、GitHub Advanced Securityなどの安全なソフトウェア開発を支える機能、GitHub Enterprise CloudとGitHub Enterprise Serverの運用が対象に含まれます。(Microsoft Learn)
つまり、この認定は「GitHubを使える人」ではなく、「組織でGitHubを安全に運用できる人」を評価する試験です。DevOpsエンジニア、情シス、プラットフォームエンジニア、開発組織のテックリードにとって、試験対策そのものがGitHub Enterprise運用の棚卸しになります。
何が変わるのか：2026年7月以降のスキル測定は5領域が中心
GH-100スタディガイドでは、2026年7月時点のスキル測定項目として5つの領域が示されています。また、変更ログでは、2026年7月に試験内容が大きく変更され、新しい目標の追加、削除、機能グループ間の移動、表現の見直しが行われると説明されています。(Microsoft Learn)
| 領域 | 配点目安 | 管理者・開発組織への影響 |
|---|---|---|
| GitHub identities and accessの管理 | 15〜20% | SAML SSO、2FA、SCIM、Team同期、組織・リポジトリ権限の理解が必須になる |
| GitHub Enterprise環境の管理 | 10〜15% | GitHub Enterprise Cloud、Enterprise Managed Users、Data Residency、GitHub Enterprise Server、ライセンス管理を整理する必要がある |
| セキュア開発とコンプライアンスの実装 | 25〜30% | Secret scanning、CodeQL、Dependabot、監査ログ、GitHub Apps、OAuth Apps、PAT管理が重要になる |
| GitHub Actionsの管理 | 20〜25% | Actionsポリシー、再利用ワークフロー、ランナーグループ、セルフホストランナー、シークレット管理が問われる |
| GitHub利用状況の監視と最適化 | 10〜15% | 監査ログ、API利用、ライセンス消費、メーター課金、未活用機能の把握が必要になる |
特に注目すべきは、「セキュア開発とコンプライアンス」と「GitHub Actions」の比重です。合計すると最大55%程度を占めるため、管理者はID管理だけでなく、CI/CD、シークレット、ランナー、監査、セキュリティ機能まで横断して理解しなければなりません。
対象者は管理者だけではない
GitHub Administrationという名称から、情シスやEnterprise Ownerだけの試験に見えるかもしれません。しかし、公式ページのロールにはAdministrator、DevOps Engineer、Technology Managerが含まれています。(Microsoft Learn)
実務では、次のような人が影響を受けます。
| 立場 | 影響を受ける理由 | 確認すべきこと |
|---|---|---|
| GitHub Enterprise管理者 | ポリシー、SSO、SCIM、監査ログ、ライセンス管理を直接扱う | Enterprise settings、Organization settings、監査ログ、課金・利用状況 |
| DevOpsエンジニア | Actions、ランナー、再利用ワークフロー、OIDC、シークレット設計に関わる | Actionsポリシー、runner groups、workflow permissions、環境ごとのsecrets |
| セキュリティ担当者 | secret scanning、code scanning、Dependabot、監査、アプリ承認に関わる | GitHub Code Security、GitHub Secret Protection、GitHub Apps、OAuth Apps |
| 開発リーダー | ブランチ運用、レビュー、CODEOWNERS、ルールセットの設計に関わる | rulesets、branch/tag保護、レビュー要件、例外申請フロー |
| 技術マネージャー | 利用状況、コスト、導入範囲、標準化を判断する | ライセンス利用、Actions消費、未活用機能、チーム別利用状況 |
試験対策としても、社内展開としても、「誰がどの設定を管理するか」を明確にすることが重要です。Enterprise Ownerだけに知識が集中すると、監査対応や障害対応時にボトルネックになります。
管理者がまず確認すべき設定
IDとアクセス管理：SAML SSO、SCIM、Team同期を分けて考える
最初に確認すべきなのは、ID管理の設計です。SAML SSO、SCIM、Team同期は似て見えますが、役割が異なります。
SAML SSOは、GitHub上の組織リソースへのアクセスをIdP経由で保護する仕組みです。ただし、Enterprise Managed Usersを使わない場合、SAML SSOはGitHub.comへの通常サインインを置き換えるものではなく、ユーザーは個人アカウントでサインインし、そのアカウントがIdP上の外部IDとリンクされます。(GitHub Docs)
SCIMは、組織メンバーの追加・管理・削除を自動化するための仕組みです。公式ドキュメントでは、SCIMを使わない場合、IdP側でアクセスを外してもGitHub組織から自動的に削除されず、認可済みトークンによるアクセスが残る可能性があると説明されています。(GitHub Docs)
Team同期は、IdPグループとGitHub Teamを対応させ、メンバー変更をGitHub側に反映する機能です。ただし、Team同期はユーザープロビジョニングサービスではなく、通常は非メンバーを自動招待するものではありません。GitHub Team自体も、IdPグループ作成だけで自動作成されるわけではありません。(GitHub Docs)
実務での判断基準は次のとおりです。
| 確認項目 | 判断基準 | 失敗しやすいポイント |
|---|---|---|
| SAML SSOの適用範囲 | Enterprise全体か、Organization単位か | 既存のOrganization単位設定を把握せずEnterprise全体に強制する |
| SCIMの利用有無 | 退職・異動時に自動で権限を外す必要があるか | IdPから外しただけでGitHubアクセスも消えたと思い込む |
| Team同期 | IdPグループとGitHub Teamの対応を標準化できるか | Team同期をユーザー作成・招待の仕組みと誤解する |
| Enterprise Managed Users | 個人アカウント運用を許容するか、企業管理アカウントに寄せるか | EMUと個人アカウント運用でSCIMやSSOの設計が変わる点を見落とす |
移行時は、まず「退職者をGitHubから完全に外す手順」をテストしてください。IdP、SCIM、Team、Organization membership、outside collaborator、PAT、SSH key、GitHub Appの権限まで確認しないと、アクセスが残ることがあります。
権限とルールセット：最小権限と例外フローを同時に設計する
GH-100では、OrganizationとRepositoryのロール、Enterprise Team、ポリシー、rulesets、監査アクセスが対象に含まれます。(Microsoft Learn)
実務では、まず次の3点を確認します。
- Organizationのデフォルト権限が必要以上に広くないか
- リポジトリ管理者が自由にセキュリティ設定を無効化できないか
- ルールセットの例外申請が属人的になっていないか
GitHubのルールセットは、ブランチやタグを保護し、リポジトリ操作の統制を強めるために使えます。Enterpriseレベルで作成したrulesetは、対象リポジトリに対する操作を制御でき、Evaluateモードで影響を確認してからActiveに切り替えることもできます。(GitHub Docs)
特に大規模組織では、いきなりActiveにせず、Evaluateモードで失敗する操作を観察するのが安全です。開発チームの通常業務を止めずに、どのルールが過剰で、どのルールが必要かを判断できます。
セキュア開発：GitHub Advanced Securityを「有効化」で終わらせない
新しいスキル測定では、セキュア開発とコンプライアンスが最大25〜30%と最も大きな領域です。対象には、脆弱性アラート、secret scanning、CodeQL、Dependabot、security advisories、セキュリティ対応計画、PAT、GitHub Apps、OAuth Appsの管理が含まれます。(Microsoft Learn)
GitHub Advanced Security関連では、GitHub Secret Protectionがsecret scanningやpush protectionを、GitHub Code Securityがcode scanning、Dependabot関連機能、dependency reviewなどを含む製品として説明されています。公開リポジトリでは一部機能が既定で有効な場合がありますが、privateまたはinternalリポジトリで使うには該当製品の購入が必要になる場合があります。(GitHub Docs)
管理者は、次の順で確認すると実務に落とし込みやすくなります。
| 優先度 | 確認する設定 | 実務上の目的 |
|---|---|---|
| 高 | secret scanningとpush protection | 認証情報がリポジトリに入る前に止める |
| 高 | CodeQLまたはcode scanning | 脆弱性をPull Requestやセキュリティアラートで検出する |
| 高 | Dependabot alertsとdependency review | 脆弱な依存関係を早期に検出する |
| 中 | GitHub AppsとOAuth Appsの承認ポリシー | 過剰な権限を持つ外部連携を抑制する |
| 中 | PATの利用ルール | 個人トークンへの依存を減らし、GitHub AppやOIDCへ移行する |
| 中 | セキュリティ対応計画 | secret漏えい時に、無効化・ローテーション・履歴対応の順番を迷わないようにする |
重要なのは、「機能を有効にしたか」ではなく、「検出後に誰が何をするか」です。secret scanningのアラートが出ても、担当者、SLA、ローテーション手順、例外承認がなければ、運用としては不十分です。
GitHub Actions：ポリシー、ランナー、シークレットをセットで見る
GitHub Actionsは、2026年7月以降のスキル測定で20〜25%を占める重要領域です。公式スタディガイドでは、再利用可能なactionsとworkflows、Organizationポリシー、GitHub-hosted runnerとself-hosted runner、IP allow list、Azure private networking、runner performance、暗号化シークレット、サードパーティVaultまでが含まれています。(Microsoft Learn)
EnterpriseのActionsポリシーでは、どのOrganizationでGitHub Actionsを使えるか、public actionsやreusable workflowsを許可するか、actionsを完全なcommit SHAに固定するかなどを制御できます。GitHub Actionsを無効化すると、CodeQL code scanningのdefault setupやGitHub Code Quality workflowsの実行にも影響するため、単純に「危険だから無効化」と判断しないことが重要です。(GitHub Docs)
セルフホストランナーは特に注意が必要です。GitHub Docsでは、public repositoryのforkから危険なコードがself-hosted runner上で実行される可能性があるため、self-hosted runnerはprivate repositoryでのみ使うことが推奨されています。(GitHub Docs)
| 確認項目 | 推奨される考え方 |
|---|---|
| third-party actions | 許可リスト化し、可能ならcommit SHA固定を標準にする |
| reusable workflows | 社内標準のbuild、test、deployワークフローを用意する |
| runner groups | 環境別、機密度別、チーム別にアクセス境界を作る |
| public repositoryとself-hosted runner | 原則として組み合わせない |
| secrets | repository、organization、environmentのスコープを使い分ける |
| OIDC | クラウド認証で長期シークレットを減らす |
| runner更新 | 自動更新を無効にする場合は、更新運用を必ず設計する |
セルフホストランナーの自動更新を無効化した場合、runner versionを定期的に更新する必要があります。公式ドキュメントでは、新しいrunner versionが利用可能になってから30日以内に更新しないとジョブがキューに入らなくなる可能性があると説明されています。(GitHub Docs)
監査ログと利用状況：試験対策ではなく運用の生命線
新しい領域には、GitHub利用状況の監視と最適化が含まれます。内容は、audit logs、API usage、管理者とGitHub Supportの責任分界、利用パターン、未活用機能、metered products、ライセンスやリソース最適化です。(Microsoft Learn)
GitHub Enterpriseの監査ログは、Enterpriseに影響するアクティビティのイベントを表示できます。GitHub Docsでは、監査ログは過去180日以内のイベントを、Git eventsは7日間保持すると説明されています。長期保管やSIEM連携が必要な組織は、エクスポートやストリーミングを前提に設計する必要があります。(GitHub Docs)
監査ログで見るべき代表例は次のとおりです。
| 観点 | 例 |
|---|---|
| 権限変更 | Organization ownerの追加、repository adminの変更、team membership変更 |
| 認証・アクセス | SAML認証、PAT利用、SSH key、OAuth App、GitHub App |
| セキュリティ | secret scanning関連、ruleset bypass、branch protection変更 |
| Actions | workflow変更、runner追加、secrets変更、環境保護設定 |
| コスト | Actions minutes、storage、ライセンス消費、未使用seat |
監査ログは「問題が起きた後に見るもの」ではなく、設定変更の検知、内部統制、トラブルシューティング、コスト最適化の基盤です。試験対策でも、ログをどう検索・保存・説明するかまで理解しておくと、シナリオ問題に対応しやすくなります。
開発者が受ける影響
開発者にとっての影響は、主にワークフローと権限の制約として現れます。
たとえば、third-party actionsの利用制限が厳しくなると、これまで使っていたMarketplace actionが突然使えなくなる可能性があります。rulesetsがActiveになると、直接push、レビューなしmerge、保護ブランチへのforce pushなどがブロックされることがあります。secret scanning push protectionが有効になると、トークンやAPIキーを含むcommitがpush時点で止まります。
これは開発者にとって不便に見えるかもしれません。しかし、管理者が次のような準備をしておけば、セキュリティと開発速度を両立できます。
| 開発者への影響 | 管理者が準備すべきもの |
|---|---|
| actionが使えない | 承認済みactions一覧、代替workflow、申請フロー |
| pushが止まる | secret検出時の手順、トークンローテーション方法 |
| merge条件が厳しくなる | rulesetの理由、例外申請、CODEOWNERS整備 |
| self-hosted runnerが使えない | 利用可能なrunner group、ラベル、対象リポジトリ |
| 権限が不足する | 最小権限の申請ルート、期限付き権限付与の運用 |
変更を展開する際は、単に「セキュリティ強化のため」と説明するだけでは不十分です。開発者が次に何をすればよいか、どの申請ルートを使えばよいか、どの例外が認められるかまで明文化してください。
移行・展開時の注意点
既存設定を先に棚卸しする
GitHub Enterpriseの管理設定は、Enterprise、Organization、Repositoryの各階層に分かれます。Actions、security、rulesets、branch protection、secrets、runner、App承認などを一度に変更すると、影響範囲の切り分けが難しくなります。
展開前には、少なくとも次の情報を一覧化します。
| 棚卸し対象 | 確認する内容 |
|---|---|
| Organization一覧 | 所有者、用途、外部コラボレーター、デフォルト権限 |
| Repository一覧 | visibility、管理者、branch protection、rulesets、CODEOWNERS |
| IdP連携 | SAML SSO、SCIM、Team同期、EMUの有無 |
| Actions | 利用Organization、runner、workflow、secrets、third-party actions |
| セキュリティ機能 | code scanning、secret scanning、Dependabot、security overview |
| 連携アプリ | GitHub Apps、OAuth Apps、PAT、machine account |
| 監査・保管 | audit log export、streaming、SIEM連携、保持期間 |
小さくEvaluateしてからActiveにする
ルールセットやActions制限は、いきなり全社適用すると業務停止の原因になります。まずは代表的なOrganizationや重要度の低いリポジトリでEvaluateし、失敗する操作や例外の数を確認します。
おすすめの順序は次のとおりです。
| 手順 | 実施内容 |
| -: | —————————————– |
| 1 | 現在の設定と利用状況を棚卸しする |
| 2 | 重要リポジトリと例外が多いチームを特定する |
| 3 | rulesetsやActionsポリシーをEvaluateまたは限定範囲で適用する |
| 4 | 失敗した操作、bypass、問い合わせ内容を収集する |
| 5 | 社内標準、例外申請、承認者を整備する |
| 6 | 対象Organizationを段階的に広げる |
| 7 | 監査ログと利用レポートで定期的に見直す |
GitHub Enterprise CloudとServerを同じ前提で扱わない
GH-100では、GitHub Enterprise Cloud、GitHub Enterprise Cloud with Enterprise Managed Users、Data Residency、GitHub Enterprise Serverなどの展開シナリオが含まれます。(Microsoft Learn)
CloudとServerでは、使える機能、更新タイミング、ネットワーク設計、セキュリティ機能、監査ログ、運用責任が異なる場合があります。社内資料や問題集が古い場合は、「この機能はGHEC前提か、GHES前提か」「どのバージョンで使えるか」を必ず確認してください。
受験準備で失敗しやすいポイント
古い出題範囲のまま学習する
2026年7月に試験内容が大きく変更されると公式スタディガイドで示されているため、古いブログ記事や問題集だけに依存するのは危険です。(Microsoft Learn)
学習時は、最初に公式の認定ページとGH-100スタディガイドを確認し、次にGitHub Docsで各機能の実務設定を読む流れにしてください。暗記よりも、「この組織ではどの設定を選ぶべきか」を判断できる状態が重要です。
Practice Assessmentを本試験の問題集だと思い込む
公式ページにはPractice Assessmentへの導線がありますが、Practice Assessmentは出題形式、表現、難易度感を把握し、弱点を確認するためのものです。本試験そのものの問題を再現するものではありません。(Microsoft Learn)
使い方としては、最初に1回解いて弱点領域を把握し、学習後にもう一度解いて理解の抜けを確認するのが効果的です。
試験中にMicrosoft Learnを参照できると思い込む
Microsoft認定試験の一部では試験中にMicrosoft Learnへアクセスできますが、公式の試験体験ページではGitHub examsは対象外と説明されています。(Microsoft Learn)
そのため、GH-100では「試験中に調べればよい」という前提で準備しない方が安全です。特に、SAML SSOとSCIMの違い、Actionsポリシー、self-hosted runnerのリスク、監査ログの保持・エクスポート、GitHub AppsとOAuth Appsの違いは、自分の言葉で説明できるようにしておきましょう。
受験アカウントを組織アカウントにしてしまう
公式の試験ページでは、試験登録には個人のMicrosoftアカウントを使うことが強く推奨されています。職場や学校の組織アカウントで登録すると、組織を離れた際に試験記録を失い、復旧できなくなる可能性があるためです。(Microsoft Learn)
企業で受験を推奨する場合も、受験者には個人MSAで登録するよう明確に案内してください。
英語試験への準備を後回しにする
公式ページでは、試験提供言語としてEnglishが示されています。日本語UIでGitHubを使っている人も、試験対策では英語の用語に慣れておく必要があります。(Microsoft Learn)
特に、以下の用語は英語のまま理解しておくと迷いにくくなります。
| 英語用語 | 日本語での理解 |
|---|---|
| Enterprise Managed Users | 企業管理ユーザー |
| SAML single sign-on | SAMLによるシングルサインオン |
| SCIM provisioning | ユーザー情報・メンバーシップの自動プロビジョニング |
| team synchronization | IdPグループとGitHub Teamの同期 |
| rulesets | リポジトリ操作を制御するルールセット |
| runner groups | ランナーへのアクセス範囲を分けるグループ |
| secret scanning | 認証情報などの秘密情報検出 |
| push protection | push時点での秘密情報ブロック |
| audit log | 監査ログ |
| metered products | 使用量に応じて課金・集計される製品 |
今すぐ取るべきアクション
GitHub Administration – Certificationsの更新に対応するために、最初にやるべきことは3つです。
まず、GH-100の公式認定ページとスタディガイドを確認し、2026年7月以降の5領域を学習計画の軸にします。次に、自社のGitHub Enterprise設定を、ID管理、権限、セキュリティ、Actions、監査ログ、ライセンスの観点で棚卸しします。最後に、rulesetsやActionsポリシーなど開発体験に影響する設定は、Evaluateや限定展開で影響を確認してから全体に広げます。
GH-100は、単なる資格試験ではありません。試験範囲をそのままチェックリストとして使えば、GitHub Enterpriseの管理成熟度を上げるための実践的な見直しにもなります。受験者は5領域を理解し、管理者は設定と運用を棚卸しし、開発チームには変更理由と対応手順を共有するところから始めてください。
コメント