「証明書が 30 日後に失効しますが、対応の準備はできていますか？」
「…その証明書って、どれですか？」
その瞬間、IT 担当者の手が止まった。Microsoft 365 のサインインに使われている SAML 署名証明書。有効期限まで 1 か月を切っていた。
01｜概要
ある中小製造業では、オンプレミス Active Directory をユーザー管理の起点として、Google Workspace と Microsoft 365 の両クラウドを並行運用している。アカウント同期は、Google Cloud Directory Sync（GCDS）で AD → Google Workspace へ、Entra Connect で AD → Microsoft 365（Entra ID）へという二経路で行われている。
▶
▶
▼
GCDS 同期
Entra Connect 同期
SAML SSO（認証連携）
この構成の特徴は、認証の主（IdP）が Google Workspace であり、Microsoft 365 がサービスを受ける側（SP）として位置づけられている点だ。ユーザーは Google のログイン画面で一度認証し、その認証情報をもとに Microsoft 365 を利用する。
世間に多い「Microsoft Entra ID が IdP」の構成とは向きが逆で、日本語の技術情報が極めて少ない領域である。顧客のシステムで SAML 署名証明書の有効期限が約 30 日後に迫り、更新作業が必要になった。本稿はその対応プロセスを記録した技術事例報告である。
02｜直面した課題
① 証明書の失効期限が迫っていた
SAML 署名証明書が失効すると、Google Workspace と Microsoft 365 の間の SAML 連携が切れ、ユーザーは Microsoft 365 にサインインできなくなる。社内業務の一部が ExcelやPowerPointなど Microsoft Office アプリに依存していたため、SSO の停止は業務停止に直結する深刻なリスクだった。
② この構成を扱った日本語情報がほぼ存在しない
ネット上に存在する SAML 証明書更新の手順の大半は「Entra ID が IdP」の構成を前提としている。「Google が IdP」の構成に絞ると、参照できる日本語情報は極めて少なく、手順の設計自体を一から行う必要があった。
③ 無停止で切り替えなければならない
業務時間中の SSO 停止は許容できない。証明書の新旧を、認証が途切れない状態のまま入れ替える方法を選択する必要があった。
03｜なぜ PowerShell（Microsoft Graph）を選んだか
Entra ID の GUI での更新が不可能だとわかった時点で、選択肢は PowerShell（Microsoft Graph API）による直接操作に絞られた。
無停止での切り替えには、Update-MgDomainFederationConfiguration コマンドの -NextSigningCertificate パラメーターを使う「次期証明書方式」を採用した。
この方式では、新しい証明書を「次期証明書」として登録した時点で Microsoft 365 が新旧両方の証明書を受け入れる状態になる。その間に Google 側を新証明書に切り替え、動作確認後に正式昇格させる。この手順により、認証停止時間ゼロでの更新が可能となる。
下図は本事例（B方式：Google が IdP）と参考比較の A方式（Entra ID が IdP・世間に多い向き）の作業概念図だ。見出しをクリックすると内容を展開できる。
04｜実施プロセス
確立した手順は以下の 7 ステップである。順序の厳守が最重要であり、特にステップ 3（Microsoft 側次期証明書登録）とステップ 4（Google 側切替）の順番を絶対に逆にしてはならない。
| 実施内容 | 実施環境 |
|---|---|
| (1) Google 管理コンソールで新証明書を生成し、.pem ファイルを個別ダウンロード ※ メタデータ XML は 2 枚問題があるため使用しない | Google 管理コンソール |
| (2) PowerShell で Microsoft Graph に接続し、現在のフェデレーション設定を取得・保全 | PowerShell |
(3) .pem を変数に読み込み、-WhatIf で空打ち確認してから -NextSigningCertificate で新証明書を登録（新旧両方有効→無停止） | PowerShell |
| (4) Google 管理コンソールでアプリ割り当てを新証明書に切替 → 「SAML ログインをテスト」で動作確認 | Google 管理コンソール |
| (5) シークレットウィンドウで m365.cloud.microsoft にアクセスして実際の SSO 動作を確認（「portal.office.com」は同 URL にリダイレクトされる） | ブラウザ |
(6) 動作安定を確認後、-SigningCertificate で新証明書を正式昇格 | PowerShell |
| (7) 1 週間の経過観察後、Google・Microsoft 両側で旧証明書を削除。次回失効の 90 日前にアラートを設定 | 両コンソール |
PowerShell コマンド詳細（ステップ 2〜6）
以下に各ステップで実行する PowerShell コマンドの全文を示す。コマンド中の your-domain.jp・<username>・<証明書ファイル名> は実環境に合わせて置換すること。すべての PowerShell 操作は、SAML フェデレーション対象外ドメインの緊急用クラウド管理者アカウントで認証すること（典型的な例：{your-tenant}.onmicrosoft.com）。
【事前準備】Microsoft Graph モジュールのインストール（初回のみ）
# 実行ポリシーを設定（初回のみ）―「管理者として実行」で起動する
Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser -Force
# Microsoft Graph モジュールをインストール（数分かかる）
Install-Module Microsoft.Graph.Identity.DirectoryManagement -Scope CurrentUser
# インストール確認
Get-InstalledModule Microsoft.GraphStep 2：Microsoft Graph への接続
Connect-MgGraph -Scopes "Domain.ReadWrite.All", "Directory.AccessAsUser.All"
# ブラウザが開く → 緊急用管理者アカウント（例：{your-tenant}.onmicrosoft.com など SSO 非依存ドメイン）でサインイン
# フェデレーション対象のカスタムドメイン（your-domain.jp 等）は Google SSO が適用されるため使用不可Step 2（続き）：現在のフェデレーション設定を取得・保全
$domain = 'your-domain.jp' # ← 実際のドメイン名に置換
$fed = Get-MgDomainFederationConfiguration -DomainId $domain
$fid = $fed.Id # InternalDomainFederationId を変数に自動格納（手入力ミス防止）
$fed | Format-List # 現設定を全表示―ロールバック用にメモまたはファイルに保存することStep 3：新証明書（.pem）を変数に読み込む
$pemPath = 'C:Users<username>Downloads<証明書ファイル名>.pem'
Test-Path $pemPath # True を確認
$cert = (Get-Content $pemPath |
Where-Object { $_ -notmatch '-----BEGIN' -and $_ -notmatch '-----END' }) -join ''
$cert # 先頭が MIID... の1行になっていることを確認Step 3（続き）：-WhatIf で空打ち確認→本番登録
# 空打ち確認（変更は実行されない）
Update-MgDomainFederationConfiguration `
-DomainId $domain `
-InternalDomainFederationId $fid `
-NextSigningCertificate $cert `
-WhatIf
# 本番：次期証明書として登録（新旧両方有効→無停止）
Update-MgDomainFederationConfiguration `
-DomainId $domain `
-InternalDomainFederationId $fid `
-NextSigningCertificate $cert
Get-MgDomainFederationConfiguration -DomainId $domain | Format-List
# NextSigningCertificate に MIID... が入っていることを確認Step 6：新証明書を正式な SigningCertificate へ昇格（Step 4・5 の動作確認後）
Update-MgDomainFederationConfiguration `
-DomainId $domain `
-InternalDomainFederationId $fid `
-SigningCertificate $cert
Get-MgDomainFederationConfiguration -DomainId $domain | Format-List
# SigningCertificate に新証明書が、NextSigningCertificate が空になっていることを確認【ロールバック：必要な場合のみ】Microsoft 側を旧証明書に戻す
# Step 2 で保全した旧証明書の Base64 値を $oldcert に入れて実行
Update-MgDomainFederationConfiguration `
-DomainId $domain `
-InternalDomainFederationId $fid `
-SigningCertificate $oldcert05｜成果
- ダウンタイム 0 での更新完了：証明書の切り替えを SSO の停止なしで完了した。
- 失効を未然に回避：期限前に更新を完了し、全社的な Microsoft 365 への接続断を防いだ。
- 再現可能な手順書の確立：実機検証を通じて、この構成に特化した正確な手順書が完成した。担当者が変わっても次回の失効（約 5 年後）に対応できる状態になった。
- 緊急用アカウントの運用ルール化：今回の作業を通じて SSO 非依存の緊急用クラウド管理者アカウントの重要性が認識され、管理ルールとして明文化された。
06｜示唆と注意点
自動ロールオーバーは機能しない（Google Workspace が IdP の構成に限る）
Google Workspace を IdP とするこの構成では、MetadataExchangeUri が空であるため、証明書の自動更新（自動ロールオーバー）が動作しない。これは設定ミスではなく、Microsoft 公式手順どおりに構成した標準状態だ。手動更新が唯一の選択肢であることを、あらかじめ運用計画に組み込んでおく必要がある。
なお、Okta など WS-Federation に対応した IdP を用いる構成では MetadataExchangeUri が設定されるため、自動ロールオーバーが機能する場合がある。本注意事項はあくまで「Google Workspace が IdP」の構成に限った話である。
緊急用アカウントが生命線になる
作業中に SSO が一時的に切れると、SSO に依存した管理者アカウントでは管理操作自体ができなくなる。重要なのは、SAML フェデレーション対象外のドメインで緊急用クラウド管理者アカウントを用意しておくことだ。Entra ID のテナントには初期状態から {your-tenant}.onmicrosoft.com という初期ドメインが存在し、このドメインは SAML フェデレーションを設定できないため緊急用に最適だが、必須ではない。独自のカスタムドメインを複数持っている場合、フェデレーション対象外のドメインがあればそれでも構わない。ドメインが SAML 対象外であることが本質であり、その資格情報で作業することが前提条件だ。
切り替えの順序を絶対に守ること
実機検証中、誤って Google 側を先に新証明書に切り替えてしまい、署名検証エラー AADSTS5000811 が発生して SSO が停止した。正しい順序は 「① Microsoft（SP）に新証明書を次期証明書として登録 → ② Google（IdP）を新証明書に切替」 だ。
反映に最大 24 時間かかる場合がある
切り替え直後に認証ループが発生した場合は、accounts.google.com/Logout からサインアウトし、再ログインすることで解消できる。
手順書は実機検証を経て初めて本物になる
GUI で更新できると書いていた手順が実際には使えず、実機検証の中で正しい手順を発見した。手順書の精度は実機検証によってのみ担保される。
07｜今後の備え
- 90 日前アラートの設定：証明書有効期限の 90 日前にカレンダー通知を設定し、余裕を持って準備を開始できるようにした。
- 引き継ぎ資料の整備：今回確立した手順を事例ページとセットで引き継ぎ資料として整備し、次の担当者がゼロから調査しなくて済む状態にした。
- 緊急用アカウントの定期点検：SSO 非依存の緊急用クラウド管理者アカウントについて、半期に 1 度ログイン確認を行う運用とした。
08｜同じ課題を抱えている方へ
「Google が IdP で、Microsoft 365 が SP」という構成は、導入当時の判断や経緯によって成立していることが多い。日本語情報が少ないまま、気づいたら証明書の失効が迫っていた、という状況に直面している情シス担当者や、システムを引き継いだ SE の方は少なくないはずだ。
この事例が、同じ構成で証明書更新に直面している方の一助になれば幸いである。
HABAねっとでは、こうした「既存の手順書が使えない」「情報が少なくて自社構成に確信が持てない」という場面での技術的な整理・伴走支援も行っている。
参考・出典
- Microsoft Learn：Google ワークスペースと Microsoft Entra ID 間のフェデレーションを構成する
- Microsoft Learn：Update-MgDomainFederationConfiguration リファレンス
- Google Workspace ヘルプ：SAML 証明書を管理する
- 実践事例（Qiita）：Google Workspace を IdP とした Entra ID への SSO
🛠 デジタル工房 HABAねっと
北陸を拠点に、中小企業経営者・個人事業主がデジタル経営を実現するためのお手伝いを行っています。
「外注で完結」ではなく「自社で動かせる体制を作る」伴走型の支援を、北陸から提供しています。
サービス一覧 ▶ https://habanet.jp/services/
お問い合わせ ▶ https://habanet.jp/contact/