GitHub Enterpriseのproof of presenceで何が変わる？2時間sudoとMFA確認チェックリスト【2026年9月版】
GitHubは2026年9月24日、GitHub Enterprise Cloud向けに、高インパクト操作の前へ追加確認を挟むproof of presenceをpreviewとして発表しました。対象は、GitHub.comおよびGHEC-DR上のEnterprise Managed Users（EMU）で、Microsoft Entra IDをSAMLまたはOIDCのSSO IdPとして使う企業です。重要操作の瞬間に、本人が操作していることをIdP側で再確認できます。
概要：高インパクト操作に追加の本人確認を挟む
今回の変更は、Enterprise Cloudの統制レイヤーに関わる更新です。GitHubは、盗まれたセッションCookieや長寿命トークンがサプライチェーン攻撃で悪用されていることを背景として説明しています。proof of presenceを有効にすると、トークン作成、webhook編集、組織セキュリティ設定変更、リカバリーコード表示などの重要操作時にIdPへリダイレクトし、再認証またはMFAを満たした場合だけ処理を続行します。
管理者がまず押さえるべき仕様表
項目 | 公式発表で確認できる内容
対象環境 | GitHub Enterprise CloudのEMU企業、github.comとGHEC-DR
IdP条件 | Microsoft Entra IDをSAMLまたはOIDCで利用
確認方法 | IdPでの再認証またはMFAチャレンジ
対象操作例 | トークン作成、webhook編集、組織セキュリティ設定変更、リカバリーコード表示
セッション継続 | 成功後は同じブラウザセッションで2時間、高インパクト操作を継続可能
今後の予定 | pull request merge前のproof of presence対応がcoming soon
この仕様で重要なのは、IdPの条件付きアクセスポリシーを使って操作直前の鮮度を確認できることです。端末準拠、再ログイン、MFAなど、Entra IDのルールをGitHubの重要操作に接続できます。
導入手順：30日で確認する3ステップ
1週目は対象企業かを確認します。EMUを使っているか、SSOがEntra IDでSAMLまたはOIDCか、管理対象がgithub.comかGHEC-DRかを整理します。対象外の企業では、preview前提の社内案内を出さない方が安全です。
2週目は高インパクト操作の棚卸しです。トークン作成、webhook変更、組織セキュリティ設定、リカバリーコード表示を、誰が、どの頻度で、どの業務時間帯に行うかを確認します。特にCI/CD担当、Organization Owner、セキュリティ管理者は、急なMFA要求で作業が止まらないよう手順を用意します。
3〜4週目はIdPポリシーと例外運用のテストです。再認証だけで足りる操作、MFAまで求める操作、端末準拠を条件にする操作を分けます。2時間のsudoセッションがあるため、頻繁な設定変更を行う保守時間帯では、確認が過剰になりすぎないかも検証します。
AI・GitHub運用の権限設計を見直すなら、 HelloCraftAIに相談する ことで、管理者向けチェックリスト作成やAI開発環境のガバナンス整備を進められます。
チェックリスト：有効化前に見る8項目
1. EMU企業であることを確認する
2. Entra IDのSAML/OIDC連携方式を確認する
3. Organization OwnerとEnterprise Ownerの人数を棚卸しする
4. トークン作成・webhook編集の通常フローを洗い出す
5. リカバリーコード表示の承認ルールを決める
6. MFA失敗時の代替担当者を決める
7. 2時間のsudo継続を前提に保守時間帯を設計する
8. PR mergeへの対応予定を見越して、重要リポジトリのマージ権限を見直す
この8項目は、セキュリティ強化だけでなく、開発速度を落とさないための確認でもあります。重要操作のたびに作業者が迷うと、緊急修正で遅延が起きます。preview段階では、少人数の管理者グループで操作ログと失敗パターンを集めるのが現実的です。
既存のGitHub統制とどう組み合わせるか
proof of presenceは、監査ログ、SSO、MFA、fine-grained token、branch protectionの代替ではありません。役割は、重要操作の直前に本人性と認証の鮮度を上げることです。たとえば、branch protectionでマージ条件を縛り、監査ログで変更履歴を残し、proof of presenceでトークンやwebhookなどの高リスク操作を直前確認する、という分担になります。
AI codingやCopilot導入が進む企業では、エージェントが作業を広げるほど権限境界の説明責任が重要になります。今回の発表はCopilot専用機能ではありませんが、AIエージェントがリポジトリ操作や設定変更に関わる組織ほど、セッション乗っ取りの影響を小さくする意味があります。
FAQ
Q. すべてのGitHub Enterpriseで使えますか？
A. 公式発表では、public previewの対象はEMU企業で、Microsoft Entra IDをSAMLまたはOIDCのSSO IdPとして使う環境に限られます。通常のOrganizationや別IdP利用企業は、公式ドキュメントの対象拡大を待つ必要があります。
Q. 毎回MFAが必要になりますか？
A. GitHubは再認証またはMFAを要件として設定できると説明しています。さらに、成功後は同じブラウザセッションで2時間、高インパクト操作を続けられます。運用上は、操作の重要度に応じてIdP側の条件を分けるのがよいです。
Q. pull request mergeにも影響しますか？
A. 2026年9月24日の発表では、PR merge前のproof of presence対応はcoming soonとされています。今すぐ全PRに適用されるわけではありませんが、重要リポジトリのマージ権限と緊急対応フローは先に確認しておく価値があります。
まとめ：2時間sudoを前提に、重要操作だけを強く守る
GitHub Enterpriseのproof of presenceは、ログイン済みセッションを信用しすぎないための追加レイヤーです。対象は限定的ですが、トークン作成、webhook編集、組織セキュリティ設定、リカバリーコード表示に直前確認を入れられる点は実務的です。まずは対象条件、8項目チェックリスト、2時間sudoの影響を小さく試し、PR merge対応が来る前に管理者フローを整えましょう。
GitHub EnterpriseやAI coding環境の権限設計を整理したい場合は、 HelloCraftAIへお問い合わせください 。現状棚卸し、管理者チェックリスト、社内研修資料までまとめて支援します。
