Microsoft Entraの公式ドキュメントで「public preview」が「preview」に置き換えられたと聞くと、「プレビュー機能の提供範囲が変わったのか」「GAに近づいたのか」「運用手順を変更すべきか」が気になるところです。結論から言うと、2026年4月30日の更新「Style: ‘public preview’ -> ‘preview’ (style guide compliance)」は、機能仕様の変更ではなく、Microsoft Entra関連ドキュメントの表記をMicrosoftのスタイルガイドに合わせるための修正です。該当コミットでは、6ファイル・7か所で「public preview」から「preview」への表記変更が行われています。(GitHub)
ただし、対象にはConditional Access、Microsoft Entra application proxy、Microsoft Entra Verified IDなど、認証・アクセス制御・本人確認に関わる領域が含まれます。security admins、compliance teams、enterprise ITの担当者は、「仕様変更ではない」と判断したうえで、社内ドキュメント、監査資料、プレビュー機能の利用ルール、キーワード監視の条件を見直すのが現実的です。
Microsoft Entraの公式ドキュメント更新で何が変わったか
今回の更新で変わったのは、主に英語ドキュメント内の表現です。Microsoftのスタイルガイドでは、リリース前のソフトウェアやサービスについて「Product Name Preview」または「Code Name Preview」と表記することが推奨され、一般的な言及では小文字の「preview」を使うとされています。(Microsoft Learn)
つまり、今回の「public preview」から「preview」への変更は、Microsoft Entraの機能が突然GAになった、サポート条件が拡大した、利用可能テナントが変わった、という意味ではありません。ドキュメント上の表記を整えるための更新です。
一方で、Microsoft Entraのプレビュー機能そのものには従来どおり注意が必要です。Microsoft Entra IDのプレビュー情報では、プレビューは顧客フィードバックを得るためのリリース前機能であり、Public Previewは適切なライセンスを持つ顧客が評価できる段階、限定的なサポートを含む場合があり、通常のSLAは適用されないと説明されています。(Microsoft Learn)
今回の更新を「仕様変更」と誤解してはいけない理由
今回の更新で最も重要なのは、表記変更とライフサイクル変更を分けて読むことです。
| 確認項目 | 判断 | 実務での対応 |
|---|---|---|
| 機能がGAになったのか | いいえ。今回のコミットは表記修正 | GA扱いに変更しない |
| サポート条件が変わったのか | コミット上は確認できない | Microsoft Entraのプレビュー条件を継続確認 |
| テナント設定を変更すべきか | 原則不要 | 設定変更は各機能の個別ドキュメントで判断 |
| 社内資料を更新すべきか | 必要な場合あり | 「public preview」前提の表記を「preview」に統一 |
| 監視ルールを見直すべきか | 見直し推奨 | 「public preview」だけでなく「preview」も検出対象にする |
特にコンプライアンス部門では、「public preview」という表記が消えたことをもって「正式提供になった」と解釈しないよう注意が必要です。リスク評価、例外承認、利用可否判断では、引き続き該当機能がプレビュー段階かどうかを確認してください。
対象になった主なドキュメントと確認ポイント
今回のコミットでは、Microsoft Entra関連の6ファイルにまたがって表記が修正されました。影響を受ける領域は、ドキュメント管理だけでなく運用判断にも関係します。(GitHub)
| 領域 | 対象ドキュメントの内容 | 確認すべきポイント |
|---|---|---|
| Microsoft Entra application proxy | Remote Desktop Web Client HTML5対応の説明 | RDWeb公開を本番運用している場合、プレビュー扱いの前提を維持する |
| Conditional Access | アプリ保護ポリシー、What If Evaluation API | 条件付きアクセスの検証手順、レポート専用運用、例外設計を再確認する |
| Windows向けアプリ保護ポリシー | MAM登録時のUX制御 | エンドユーザーの登録フロー変更をテスト環境で確認する |
| Microsoft Entra Verified ID | Request Service APIのエラー形式 | API連携アプリのエラーハンドリング資料を更新する |
| Verified ID Face Check | ARM REST APIの説明 | 本人確認フロー、課金、権限、データ保護レビューを継続する |
たとえば、Microsoft Entra application proxyのFAQでは、Remote Desktop Web Client（HTML5）シナリオが「preview」と説明されています。(Microsoft Learn) これは「利用できるが正式版と同じ前提で無条件に展開してよい」という意味ではありません。RDS、RDWeb、WebSocket、事前認証、SSO要件が絡むため、対象ユーザー、認証方式、代替手段を含めた検証が必要です。
Conditional Access担当者が確認すべき点
今回の更新で特に確認したいのがConditional Access関連の記述です。Conditional Accessは設定ミスがユーザーの業務停止や管理者ロックアウトにつながりやすく、単なるドキュメント更新でも社内手順への反映が重要です。
Microsoft Learnでは、Conditional AccessのWhat If toolが、特定ユーザー、エージェントID、単一テナントのサービスプリンシパルに対して、どのポリシーが適用されるかを確認するためのツールとして説明されています。また、What If Evaluation APIを利用する新しいWhat If toolは「preview」とされています。(Microsoft Learn)
運用担当者は、次の点を確認してください。
- What If toolやMicrosoft Graph APIによる評価を、本番変更前の検証手順に入れているか
- 「preview」と記載された機能を、監査上の本番必須機能として扱っていないか
- 条件付きアクセスの変更時に、report-only modeや段階的な対象グループ展開を使っているか
- 緊急アクセスアカウントを除外し、管理者ロックアウトを防ぐ設計になっているか
- 手順書内で「public preview」と書かれている箇所が、最新ドキュメントの検索で見つからなくなっていないか
見落としやすいのは、ドキュメント検索や監視のキーワードです。これまで「public preview」を条件にRSS、GitHub差分、社内ナレッジベースを検索していた場合、今後は「preview」も対象に含めないと、プレビュー機能の更新を拾い損ねる可能性があります。
Windows向けアプリ保護ポリシーで注意すべき点
Conditional Accessの「Require app protection policy」関連では、Microsoft Edge on Windows向けのアプリ保護ポリシーが「preview」と表記されています。Microsoft Learnでは、アプリ保護ポリシーはiOSとAndroidでは一般提供され、Microsoft Edge on Windowsではpreviewと説明されています。(Microsoft Learn)
また、Windowsデバイスでアプリ保護ポリシーを要求する手順では、最初はreport-only modeで影響を確認し、意図どおりに動作することを確認してから有効化する流れが示されています。(Microsoft Learn)
実務上は、次のようなケースで慎重な検証が必要です。
| 利用シーン | 失敗しやすいポイント | 推奨対応 |
|---|---|---|
| BYODのWindows端末でEdgeを使わせる | MAMとMDMの登録フローを混同する | テストユーザーで初回サインインの画面遷移を確認する |
| Office 365へのアクセス制御に使う | 「すべての選択済み制御を必須」にしてアクセスをブロックする | 「いずれかの制御を満たす」条件を含めて設計する |
| 既存のEdgeプロファイルがある | 未登録アカウントが残りMAM登録が失敗する | 端末状態、Edgeプロファイル、Intuneポリシー適用状況を確認する |
| 監査資料に記載する | preview機能を正式統制として書いてしまう | 代替統制や例外時の手順を併記する |
「preview」という表記に変わっても、プレビュー機能としての検証責任は変わりません。特にゼロトラストや端末準拠性の設計に組み込む場合は、対象ユーザーを限定し、適用ログを確認しながら段階的に広げるべきです。
Verified IDとFace Checkで確認すべき点
Microsoft Entra Verified ID関連では、Request Service APIのエラー形式やFace CheckのARM REST APIに関する記述が対象です。Verified IDのエラーコードページでは、Request Service APIのプレビュー期間中のエラー形式と、その後の新しい形式が説明されています。(Microsoft Learn)
Face Checkのドキュメントでは、Face CheckがVerified IDのプレミアム機能であり、利用前にFace Check Add-onを有効化する必要があること、またARM REST API for Microsoft Entra Verified IDが現在previewであることが示されています。(Microsoft Learn)
本人確認や高保証の認証フローにVerified IDを組み込んでいる企業は、次の点を確認してください。
- APIレスポンスの旧形式と新形式を、アプリ側で取り違えていないか
- エラーハンドリングで
innererrorなどの詳細情報を適切にログ化しているか - Face Checkを有効化する権限、Azureサブスクリプション、課金先を明確にしているか
- 生体情報・本人確認データの扱いについて、プライバシー部門や法務部門とレビューしているか
- preview APIを本番業務の単一障害点にしていないか
特にVerified IDやFace Checkは、技術的な可用性だけでなく、本人確認の失敗時対応、データ保護、ユーザー同意、委託先管理なども関係します。ドキュメントの表記変更だけで判断せず、業務プロセス全体で確認することが重要です。
「public preview」と「preview」の使い分けで混乱しやすい点
今回の更新により、「public preview」という表現がすべて廃止されたと考えるのは早計です。Microsoft Entra admin centerのWhat’s newでは、RoadmapのRelease Typeとして「Public Preview」と「GA」が説明されており、Public Previewは必要なライセンスを持つ顧客が利用可能で、限定的なサポートを含む場合があり、標準SLAは適用されないと説明されています。(Microsoft Learn)
つまり、実務では次のように読み分けるのが安全です。
| 表記 | 主な意味 | 読み方 |
|---|---|---|
| preview | 一般的なプレビュー機能の説明 | スタイルガイドに沿った通常表記 |
| Public Preview | リリース種別・ライフサイクル段階 | RoadmapやWhat’s new上の提供フェーズ |
| GA / General Availability | 一般提供 | 本番利用・サポート前提の確認対象 |
| Private preview | 限定顧客向けの早期評価 | 正式サポートなしの可能性が高い |
社内資料では、英語の原文をそのまま引用する箇所と、日本語で状態を説明する箇所を分けると混乱を防げます。たとえば、手順書では「この機能はpreviewです」と書き、リリース管理表では「Release Type: Public Preview」と原文に近い形で残すと、Microsoft Learnや管理センターの表記と照合しやすくなります。
運用担当者向けの確認手順
今回のMicrosoft Entra公式ドキュメント更新を受けて、実際に行うべき確認は大きく5つです。
| 手順 | 作業内容 | 完了の目安 |
|---|---|---|
| 影響範囲の洗い出し | 社内ドキュメントで「public preview」を検索する | 該当箇所の一覧ができている |
| 機能状態の再確認 | 該当機能がpreviewかGAかをMicrosoft LearnやWhat’s newで確認する | 本番利用可否を誤解していない |
| 監視条件の更新 | GitHub差分、RSS、ナレッジ検索で「preview」も拾う | 更新検知漏れを防げる |
| リスク評価の見直し | SLA、サポート、代替手段、ロールバック手順を確認する | 承認資料に反映されている |
| 利用者向け案内の調整 | エンドユーザー画面や手順に影響する機能をテストする | ヘルプデスクが問い合わせに答えられる |
ここで重要なのは、設定を急いで変えないことです。今回の更新は表記変更であり、テナント設定やConditional Accessポリシーを変更する直接の理由にはなりません。先に社内文書と運用判断の前提を整え、その後、各機能の個別ドキュメントやMicrosoft Entra admin centerのWhat’s newで実際の変更を追うべきです。
企業ITで見落としやすいリスク
今回のような小さなドキュメント更新は、単体では重大インシデントにつながりにくいものです。しかし、エンタープライズ環境では次のような間接的なリスクがあります。
自動監視が「public preview」だけを拾っている
GitHubのコミット、Microsoft Learn、社内Wikiを自動監視している場合、キーワードが「public preview」だけだと今後の更新を取りこぼす可能性があります。監視条件には「preview」「Preview」「Public Preview」を含め、文脈で除外する設計が必要です。
ただし、「Preview tab」や「画面のプレビュー」のように、機能ライフサイクルとは無関係な用語もあります。単純な文字列一致だけでアラートを出すとノイズが増えるため、「Microsoft Entra」「Conditional Access」「Verified ID」「Application Proxy」などのサービス名と組み合わせると運用しやすくなります。
監査資料でGAと誤認される
「public」という語が消えたことで、レビュー担当者が「限定的なプレビューから通常機能に変わった」と誤解する場合があります。監査資料では、表記だけでなく、機能のライフサイクル状態、利用条件、サポート範囲、代替手段を明記してください。
過去のリリース記録と現在の説明が一致しない
今回のコミットでは、過去のリリース記録を保持するため、whats-new.mdやwhats-new-archive.mdは対象外とされています。(GitHub) そのため、過去のWhat’s newには「Public Preview」と残り、現在の機能説明ページには「preview」と書かれることがあります。これは必ずしも不整合ではなく、履歴情報と現行説明の役割が違うためです。
今回の更新後に取るべき行動
Microsoft Entraの公式ドキュメント更新「Style: ‘public preview’ -> ‘preview’」は、運用設定を変えるための合図ではなく、プレビュー機能の表記を整理する更新です。とはいえ、対象領域は認証、条件付きアクセス、アプリ保護、Verified IDといった企業ITの重要部分です。
まずは、社内の手順書・設計書・監査資料にある「public preview」を洗い出し、必要に応じて「preview」に統一してください。次に、該当機能を本番運用に組み込んでいる場合は、GA扱いになっていないか、限定サポートやSLAの前提を忘れていないかを確認します。最後に、Microsoft Entra admin centerのWhat’s new、Microsoft Learn、GitHubのMicrosoftDocs更新を継続的に追えるよう、監視キーワードと確認フローを見直しましょう。
今回の変更は小さな表記修正ですが、プレビュー機能を安全に扱うための運用成熟度を見直すよい機会です。
コメント