Microsoft Entraの公式ドキュメント更新「Clarify access review billing scenario guest access review example」でまず押さえるべき結論は、サービス仕様そのものの大きな変更ではなく、ゲストユーザーのアクセスレビュー課金例を誤解しにくくするための文言明確化だという点です。
特に確認すべきなのは、Microsoft Entra ID Governanceでゲストユーザーを対象にアクセスレビューを実行する場合、同じ月に課金対象となるゲストが「重複しているのか」「別のユーザー集合なのか」です。今回の更新では、Tailspinの例で2つ目のアクセスレビュー対象が「別の300人のゲストユーザー」であることが明確になり、200人＋300人＝500人という課金例の読み方が分かりやすくなりました。2026年4月30日のGitHubコミットでは、対象ファイルが docs/id-governance/microsoft-entra-id-governance-licensing-for-guest-users.md の1ファイルで、差分も1行の追加・1行の削除に限られています。(GitHub)
Microsoft Entraの公式ドキュメント更新で何が変わったか
今回の更新対象は、Microsoft Entra ID Governanceのゲストユーザー向けライセンスと課金を説明する公式ドキュメントです。コミット名は「Clarify access review billing scenario guest access review example」で、内容としてはアクセスレビュー課金シナリオの例を明確化する更新です。(GitHub)
変更されたのは、Billing examples内の「Scenario 3: Access Reviews for inactive users and user-to-group affiliation」にあるTailspinの例です。現行のMicrosoft Learnでは、5月の例として次の流れが示されています。
| 項目 | 内容 |
|---|---|
| 1つ目のレビュー | Tailspin Toysが200人のゲストユーザーに対して非アクティブゲストアクセスレビューを作成 |
| 2つ目のレビュー | Tailspinが、user-to-group affiliation機能を有効にしたセキュリティグループのアクセスレビューを、別の300人のゲストユーザーに対して作成 |
| 課金例 | 5月は200人＋300人で、合計500人分として課金される |
このポイントは、現行ドキュメントでも「different set of 300 guest users」として示されており、2つ目の300人が1つ目の200人と重複していない前提であることが分かります。(Microsoft Learn)
今回の更新を「仕様変更」と読まないほうがよい理由
今回の差分は、API、ライセンス体系、課金ロジック、管理ポータルの操作手順を変更するものではなく、既存の課金例の読み方を補強する更新と考えるのが妥当です。GitHubのコミット差分でも、対象は1ファイル・1行レベルの文言変更にとどまっています。(GitHub)
実務上は、次のように整理すると判断を誤りにくくなります。
| 確認項目 | 今回の読み方 | 実務での判断 |
|---|---|---|
| 新機能追加か | いいえ。文書上の例の明確化 | 新しい設定項目の有無ではなく、課金対象ユーザー数の見積もりを見直す |
| 価格改定か | この差分だけでは価格改定とは読めない | 最新価格はAzureの価格ページや契約条件で確認する |
| 課金対象の考え方が変わったか | 少なくともこの差分では、課金ロジックの変更は示されていない | 既存の「月内の課金対象アクション」と「対象ゲストの一意性」を確認する |
| 監査・コンプライアンスへの影響 | あり得る | アクセスレビューの対象範囲、実行月、対象ゲスト数の記録を残す |
つまり、security adminsやcompliance teamsが見るべきなのは「何か新しい機能が出たか」ではなく、自社の課金見積もりや監査説明で、ゲストユーザーの重複を正しく扱えているかです。
ゲストアクセスレビュー課金で押さえるべき基本
Microsoft Entra ID Governanceのゲストユーザー課金は、従業員向けライセンスとは異なり、Monthly Active User、つまり月間アクティブユーザーの考え方で扱われます。公式ドキュメントでは、ゲストは認証元にかかわらず userType が Guest のユーザーとして識別され、月内に1つ以上のガバナンスアクションがあるゲストユーザーが請求に含まれると説明されています。(Microsoft Learn)
ここで重要なのは、単にディレクトリ内にゲストアカウントが存在するだけではなく、その月にMicrosoft Entra ID Governance固有の課金対象アクションが発生したかを見る点です。公式ドキュメントでも、ゲストユーザーがその月にアクティブなガバナンス関連アクションを行っていない場合、たとえば前月に自動割り当てされたアクセスを保持しているだけの場合は、その月の課金対象にならないと説明されています。(Microsoft Learn)
一方で、Access Reviewsでは「machine learning assisted access reviews」や「inactive users」に関するアクセスレビューが課金対象アクションとして示されています。inactive guest reviewsがグループリソースのポリシーに含まれる場合も、ゲストユーザーがレビューに含まれると課金対象になります。(Microsoft Learn)
「200人＋300人＝500人」の例で誤解しやすい点
今回の文書更新で最も重要なのは、アクセスレビューの対象ユーザーが重複していないことを明確にした点です。
たとえば、次の2つのケースでは課金見積もりの考え方が変わります。
| ケース | 例 | 課金見積もりでの注意点 |
|---|---|---|
| 対象が重複していない | 非アクティブゲスト200人、別のセキュリティグループ内のゲスト300人 | 200人＋300人で500人として見積もりやすい |
| 対象が一部重複している | 非アクティブゲスト200人のうち100人が、2つ目のレビューにも含まれる | 単純加算すると過大見積もりになる可能性がある |
| 同じ月に複数アクションがある | 同じゲストがアクセスレビューとアクセスパッケージ自動割り当ての両方に該当 | 公式例では、同じ月に複数のガバナンスアクションがあっても、各ゲストは月内で1回分として扱われる考え方が示されている |
公式ドキュメントの別シナリオでも、同じゲストユーザーが同じ月にLifecycle Workflowと非アクティブユーザーレビューの両方に該当する場合、すでに課金対象となった100人は追加課金されず、月内の1人のゲストユーザーは1回として扱われる旨が説明されています。(Microsoft Learn)
そのため、実務での見積もりでは「レビュー数」や「グループ数」だけを数えるのでは不十分です。月ごとに、課金対象アクションに含まれるゲストユーザーの一意数を確認する必要があります。
Security adminsが確認すべき運用ポイント
Microsoft Entra ID Governanceのアクセスレビューを運用している管理者は、今回の更新をきっかけに、次の3点を確認しておくとよいでしょう。
アクセスレビューの対象スコープを確認する
まず、アクセスレビューがどのユーザー集合を対象にしているかを棚卸しします。
具体的には、次のような観点で確認します。
- ゲストユーザー全体を対象にしているのか
- 特定のセキュリティグループやMicrosoft 365グループを対象にしているのか
- 非アクティブユーザーのみを対象にしているのか
- user-to-group affiliation recommendation helperなどの高度な推奨機能を使っているのか
- 同じゲストユーザーが複数のレビューに含まれていないか
特に大企業では、部門別・アプリ別・プロジェクト別にアクセスレビューが分かれていることがあります。この場合、各チームが個別にレビューを作っていると、同じ外部パートナーや委託先ユーザーが複数のレビューに含まれる可能性があります。
月単位で対象ゲストの一意数を把握する
課金見積もりでは、レビュー定義の数ではなく、月単位の対象ゲスト数を見る必要があります。公式ドキュメントでは、月内に1つ以上のガバナンスアクションがあるゲストユーザーが請求に含まれると説明されています。(Microsoft Learn)
実務では、次のような集計軸を用意すると管理しやすくなります。
| 集計軸 | 確認する理由 |
|---|---|
| 月 | MAUベースのため、月をまたぐと再度対象になり得る |
| ゲストユーザーID | 同一ユーザーの重複カウントを避ける |
| レビュー名 | どのアクセスレビューが課金対象候補を発生させたかを追跡する |
| 対象リソース | アプリ、グループ、アクセスパッケージ単位で費用配賦しやすくする |
| 実行理由 | 非アクティブ確認、グループ所属確認、コンプライアンス対応などを説明できるようにする |
費用の説明責任がある環境では、「レビューを実施したから課金された」ではなく、「どの月に、どのゲストユーザーが、どのガバナンス機能に含まれたため課金対象になった」と説明できる状態を作ることが重要です。
監査ログで課金対象アクションを確認する
公式ドキュメントでは、Microsoft Entra ID Governance for guests add-onに課金されるアクションを監査ログで確認できるとし、課金対象アクションには TargetId、TargetUserType: Guest、GovernanceLicenseFeatureUsed: True といったプロパティが含まれると説明されています。(Microsoft Learn)
運用上は、少なくとも次のようなチェックを定期的に行うとよいでしょう。
| 確認項目 | 見るべきポイント |
|---|---|
TargetUserType | Guest のユーザーが対象になっているか |
GovernanceLicenseFeatureUsed | True のイベントが発生しているか |
TargetId | 同一月内で同じゲストを重複して数えていないか |
| イベント発生日 | 月次の請求見積もりと対応しているか |
| 操作元 | 管理者操作、ポリシー、ワークフローなど発生源を追跡できるか |
監査ログは、費用見積もりだけでなく、コンプライアンス監査で「なぜこのゲストに対してレビューが行われたのか」を説明する材料にもなります。
Compliance teamsが確認すべきポイント
コンプライアンスチームにとって、今回の更新は単なる文言修正ではありません。アクセスレビューの課金例が明確化されたことで、レビュー設計と監査証跡の整合性を確認しやすくなります。
特に確認したいのは、次の3点です。
| 確認項目 | 実務上のチェック内容 |
|---|---|
| レビュー対象の正当性 | ゲストユーザーをレビュー対象に含める業務上の理由があるか |
| レビュー頻度 | 月次、四半期、年次など、リスクに応じた頻度になっているか |
| 結果の証跡 | 承認、拒否、アクセス削除、例外承認の記録が残っているか |
アクセスレビューは、外部ユーザーの不要な権限を削除するために有効ですが、対象範囲が広すぎると費用や運用負荷が増えます。一方で、対象範囲が狭すぎると、リスクの高い外部ユーザーがレビュー対象から漏れる可能性があります。
そのため、コンプライアンス観点では「全ゲストを一括レビューするか」「高リスクなアプリやグループから優先するか」を決める基準を明文化しておくことが重要です。
Enterprise IT readers向け：移行準備で確認すべきこと
Microsoft Entra ID Governance for Guests Add-onを使うには、テナントをAzureサブスクリプションにリンクする必要があります。公式ドキュメントでは、適切な課金と機能アクセスのためにテナントをAzureサブスクリプションへリンクする手順が示されており、Microsoft Entra管理センターからID Governanceのダッシュボードへ進み、guest governance panelでサブスクリプションとリソースグループを選択する流れが説明されています。(Microsoft Learn)
また、サブスクリプションが表示されない場合は、権限不足、サブスクリプションがディレクトリに関連付いていない、サブスクリプション自体が存在しないといった原因が考えられるとされています。公式手順では、サブスクリプションまたはリソースグループに対して少なくともOwnerロールを持つアカウントでサインインする必要があると説明されています。(Microsoft Learn)
移行準備では、次の順番で確認すると失敗しにくくなります。
| 手順 | 確認内容 | 失敗しやすいポイント |
|---|---|---|
| 1 | 現在のゲストユーザー数を把握する | 招待済みだが使われていないゲストを含めてしまう |
| 2 | 課金対象になり得るガバナンス機能を棚卸しする | 基本的なP2機能とID Governance固有機能を混同する |
| 3 | アクセスレビューの対象範囲を確認する | 部門別レビューで同じゲストが重複する |
| 4 | Azureサブスクリプションとリソースグループを決める | 費用配賦先が決まらないまま有効化する |
| 5 | 監査ログの確認方法を決める | 請求後に原因を追跡できない |
| 6 | 本番前に小さいスコープで検証する | 全ゲストを一括で対象にして費用・運用負荷が増える |
特に、複数事業部や複数リージョンでMicrosoft Entraを使っている企業では、費用負担部門を先に決めておく必要があります。アクセスレビューはセキュリティ施策ですが、課金はAzureサブスクリプションに紐づくため、セキュリティ部門だけでなく、クラウド基盤チームやFinOps担当者との調整が欠かせません。
ゲスト課金を有効化しない場合の影響
公式ドキュメントでは、Microsoft Entra ID Governance for Guests Add-onの接続は2026年1月から適用されると説明されています。また、ゲスト課金メーターが有効でない場合、ゲストユーザーを対象にした新しいアクセスレビューで、Inactive user access reviewやUser-to-group affiliation recommendation helperを選択できないとされています。(Microsoft Learn)
Entitlement ManagementやLifecycle Workflowsでも、ゲストを対象に含むポリシーやワークフローの作成・更新に制限がかかる場面があります。たとえば、ゲストを含むアクセスパッケージポリシーでスポンサー承認、カスタム拡張、Verified IDなどの機能を使う場合や、userType=Guest を含む自動割り当てポリシーを作る場合は注意が必要です。(Microsoft Learn)
このため、まだゲストガバナンス課金を有効化していない企業は、次の判断を早めに行うべきです。
- ゲストアクセスレビューを継続する必要があるか
- 非アクティブゲストの棚卸しをどの頻度で行うか
- 高度な推奨機能を使う必要があるか
- Azureサブスクリプションへのリンクをどの部門が管理するか
- 課金対象イベントを誰が確認するか
機能を使えなくなってから対応するのではなく、既存のアクセスレビュー設定を先に棚卸ししておくほうが安全です。
Microsoft Entra P2利用企業が混同しやすい点
Microsoft Entra P2をすでに利用している企業では、「アクセスレビューはP2に含まれるのではないか」と考えがちです。しかし、公式FAQでは、Microsoft Entra P2に含まれる基本的なアクセスレビューやEntitlement Management機能はgovernance guest add-onに課金されない一方、Microsoft Entra SuiteまたはスタンドアロンのMicrosoft Entra ID Governanceに固有の機能だけがメーター課金対象になると説明されています。(Microsoft Learn)
つまり、判断軸は「アクセスレビューという名前の機能を使っているか」ではなく、そのレビューがMicrosoft Entra ID Governance固有の課金対象機能を使っているかです。
確認すべき具体例は次のとおりです。
| よくある誤解 | 正しい確認方法 |
|---|---|
| P2を契約しているのでゲストレビューはすべて追加課金されない | どのアクセスレビュー機能を使っているか確認する |
| ゲスト数が少なければ無料枠内に収まる | 公式FAQではgovernance guest billingに無料枠はないと説明されている |
| ディレクトリ内の全ゲストが自動的に課金対象になる | 月内に課金対象のガバナンスアクションがあるかを確認する |
| 同じゲストが複数レビューに入るとレビューごとに課金される | 月内の一意ユーザーとして扱われる例が示されている |
公式FAQでは、governance guest billingは最初の50,000 MAU内のゲストにも適用され、無料枠はないとされています。(Microsoft Learn)
マルチテナント組織ではuserTypeを確認する
Microsoft Entraのマルチテナント組織を利用している場合は、ゲストユーザーの扱いにも注意が必要です。公式ドキュメントでは、governance guest billingは userType が Guest のユーザーに適用され、Microsoft Entra ID Governanceライセンスを持つメンバーユーザーが他の組織テナントに Member として取り込まれた場合は課金メーターに加算されないと説明されています。(Microsoft Learn)
一方、対象ユーザーが Guest として取り込まれる場合はメーターに加算され得ます。ただし、参加組織テナントからのゲストであれば、マルチテナント組織を設定または参加することで課金を避けられる旨も説明されています。(Microsoft Learn)
大規模企業では、M&A、グループ会社、海外拠点、共同プロジェクトなどで外部ユーザー管理が複雑になります。単に「社外ユーザーだからゲスト」と扱うのではなく、対象ユーザーが Guest なのか Member なのか、マルチテナント組織の参加テナントなのかを確認することが、課金と統制の両面で重要です。
実務で使える確認チェックリスト
今回のMicrosoft Entra公式ドキュメント更新を受けて、管理者は次のチェックリストで自社環境を確認しておくとよいでしょう。
| チェック項目 | 確認する内容 | 優先度 |
|---|---|---|
| 公式差分の理解 | 今回は課金例の文言明確化であり、大規模な仕様変更ではないと理解しているか | 高 |
| アクセスレビュー棚卸し | ゲストを対象にしたレビュー定義を一覧化しているか | 高 |
| 対象ユーザー重複 | 同じ月に複数レビューへ含まれるゲストを把握できるか | 高 |
| 課金対象機能 | Inactive user access reviewやuser-to-group affiliation関連機能の利用有無を確認したか | 高 |
| 監査ログ | TargetUserType: Guest と GovernanceLicenseFeatureUsed: True を追えるか | 高 |
| Azureサブスクリプション | 課金先のサブスクリプションとリソースグループが決まっているか | 中 |
| 権限 | サブスクリプションまたはリソースグループのOwner権限を持つ担当者を確認したか | 中 |
| 費用配賦 | 事業部、アプリ、プロジェクト単位で費用説明できるか | 中 |
| コンプライアンス証跡 | レビュー結果とアクセス削除の記録を監査対応に使えるか | 中 |
| 不要ゲスト削除 | 利用終了した外部ユーザーを定期的にクリーンアップしているか | 中 |
次に取るべきアクション
今回の更新は小さな文言変更ですが、ゲストアクセスレビューの課金見積もりでは重要な示唆があります。特に、アクセスレビューの対象ゲストが重複しているかどうかを確認しないまま単純にレビュー単位で人数を足すと、費用見積もりや監査説明がずれる可能性があります。
まずは、Microsoft Entra ID Governanceでゲストを対象にしているアクセスレビューを一覧化してください。そのうえで、月ごとの対象ゲストユーザーの一意数、課金対象機能の利用有無、監査ログで確認できるイベントを照合します。
最後に、Azureサブスクリプションへのリンク、費用配賦、監査証跡の保管方法を決めておくと、security admins、compliance teams、enterprise ITの間で認識を合わせやすくなります。今回の公式ドキュメント更新は、機能追加のニュースとして読むよりも、ゲストガバナンス運用を費用・監査・アクセス制御の3点で見直すきっかけとして扱うのが実務的です。
コメント