Microsoft Entra 管理者が今回まず押さえるべき結論は、「Release plans for Dynamics 365 and Power Platform」は Microsoft Entra 単体のリリースノートではないものの、Dynamics 365、Power Platform、Business Central、Copilot Studio などの認証・権限・エージェント利用に影響する変更を早めに確認すべき情報源だという点です。
特に 2026 release wave 1 では、Dynamics 365 の各アプリに AI エージェント、自動処理、音声認証、メール分類、Business Central の MCP 連携などが広がっています。これらは業務アプリ側の機能追加に見えても、実務では Microsoft Entra の条件付きアクセス、セキュリティグループ、アプリ登録、管理者権限、監査設計に波及します。公式リリース計画は 2026 年 4 月から 2026 年 9 月にかけて提供される機能を対象としており、予定や提供時期は変更される可能性があります。(Microsoft Learn)
Microsoft Entra 管理者が見るべき「Release plans for Dynamics 365 and Power Platform」の位置づけ
「Release plans for Dynamics 365 and Power Platform」は、Dynamics 365 と Power Platform の新機能を確認するための Microsoft Learn 上のリリース計画です。2026 release wave 1 では、Dynamics 365 Sales、Customer Service、Contact Center、Field Service、Finance、Supply Chain Management、Human Resources、Commerce、Business Central、Customer Insights など、幅広い業務アプリが対象になっています。(Microsoft Learn)
Microsoft Entra の管理者にとって重要なのは、ここに掲載される機能の多くが「業務部門だけで完結しない」点です。たとえば、AI エージェントがメールを処理する、Business Central API に MCP クライアントから接続する、Contact Center で音声認証を使う、といった変更は、次の領域に関係します。
| 確認領域 | Microsoft Entra 管理者への影響 |
|---|---|
| ユーザー認証 | MFA、条件付きアクセス、サインインリスク、デバイス条件の見直し |
| 管理者権限 | Power Platform 管理者、Dynamics 365 管理者、Dataverse System Administrator の棚卸し |
| アプリ連携 | アプリ登録、サービスプリンシパル、API 権限、同意管理の確認 |
| エージェント利用 | Copilot Studio、Business Central、Customer Service でのエージェント認証・公開範囲の制御 |
| 監査・証跡 | Microsoft Purview、Dataverse 監査、Power Platform 管理センターのログ確認 |
| グローバル展開 | 地域別・言語別の提供状況、国ごとのコンプライアンス要件の確認 |
「Dynamics 365 の更新だから Entra 管理者は関係ない」と判断すると、AI エージェントの接続先、共有メールボックス、外部ユーザー、管理者ロールの過剰付与を見落としやすくなります。
2026 release wave 1 の全体像：対象期間と確認すべき前提
2026 release wave 1 は、2026 年 4 月から 2026 年 9 月にかけて提供される Dynamics 365 と Power Platform の新機能を対象としています。Dynamics 365 側では、Sales、Customer Service、Contact Center、Field Service、Finance、Supply Chain Management、Business Central などに多数の新機能が含まれます。(Microsoft Learn)
リリース計画を見るときは、単に「いつ提供されるか」だけでなく、どの方式で有効化されるかを必ず確認してください。Microsoft は各機能について、次のような有効化区分を示しています。(Microsoft Learn)
| 有効化区分 | 意味 | 管理者が取るべき行動 |
|---|---|---|
| Users, automatically | ユーザー向け機能が自動で有効化される | UX 変更、問い合わせ増加、教育資料の更新を確認 |
| Admins, makers, or analysts, automatically | 管理者・作成者向け機能が自動で有効化される | 管理画面、作成者権限、監査ログを確認 |
| Users by admins, makers, or analysts | 管理者や作成者が有効化してからユーザーが利用する | 有効化条件、対象環境、承認フローを定義 |
特に Microsoft Entra 管理者は、「Users, automatically」の機能を軽視しないことが重要です。自動有効化される機能でも、ユーザーが新しい接続先やエージェント機能を使い始めることで、条件付きアクセス、DLP、共有メールボックス、Power Automate 接続、アプリ登録の運用に影響する場合があります。
2026年7月2日更新分で注目したい主な変更点
2026 年 7 月 2 日に更新された個別機能の中で、Microsoft Entra 管理者が特に意識したいのは、Customer Service、Contact Center、Business Central のエージェント系・認証系の変更です。ここでは、ID 管理・アクセス制御の観点で影響が出やすいものに絞って整理します。
| 機能 | 対象サービス | 提供時期・状態 | Entra 管理者の確認ポイント |
|---|---|---|---|
| 音声バイオメトリクスによる認証 | Dynamics 365 Contact Center | Public preview: 2026年8月、GA: 2026年9月予定 | MFA 方針、本人確認ポリシー、音声登録データの扱い、SMS OTP との併用設計 |
| Case Management Agent によるメール分類 | Dynamics 365 Customer Service | 2026年4月10日 GA | 対象メールボックス、送信者ドメイン、言語条件、下流の Power Automate・ルーティング権限 |
| AI による顧客メールの自律解決 | Dynamics 365 Customer Service | Public preview: 2026年6月、GA: 2026年9月予定 | 自律返信の承認範囲、ナレッジ・コネクタ・カスタムエージェントへのアクセス権 |
| Business Central の拡張 MCP server | Dynamics 365 Business Central | 2026年4月1日 GA | OAuth 2.1、Microsoft Entra ID のアプリ登録、サードパーティ MCP クライアントの接続可否 |
| Sales Order Agent の複数インスタンス化 | Dynamics 365 Business Central | 2026年7月 GA | 共有メールボックス、監視フォルダー、処理済みメール、チーム別権限の分離 |
これらはすべて「便利な自動化」として導入されやすい一方で、運用設計なしに有効化すると、誰がどのデータにアクセスし、どのエージェントがどの業務処理を実行したのかを後から追跡しにくくなります。
Contact Center の音声認証は MFA 代替ではなく「本人確認プロセス」として設計する
Dynamics 365 Contact Center では、音声バイオメトリクスを使って通話者を認証し、不正対策と本人確認を強化する機能が示されています。公式情報では、音声登録・音声検証、SMS OTP、知識ベースのチャレンジなどを含む多要素的な認証戦略として説明されています。機能は Customer Service Admin Center から組織全体に対して有効化・構成される予定です。(Microsoft Learn)
ここで注意したいのは、Microsoft Entra の MFA と、Contact Center の通話者認証を混同しないことです。Entra の MFA は従業員や管理者がクラウドリソースへサインインするときのアクセス制御です。一方、Contact Center の音声認証は、顧客や通話者の本人確認プロセスに関係します。
実務では、次のように役割を分けて考えると整理しやすくなります。
| 項目 | Microsoft Entra MFA | Contact Center の音声認証 |
|---|---|---|
| 主な対象 | 従業員、管理者、ゲスト、アプリ利用者 | 顧客、通話者、コンタクトセンター利用者 |
| 主な目的 | クラウドアプリへのサインイン保護 | 通話中の本人確認、不正対策、オペレーター負荷軽減 |
| 管理場所 | Microsoft Entra 管理センター | Customer Service Admin Center |
| 確認すべき点 | 条件付きアクセス、認証強度、リスクベース制御 | 音声登録、本人確認フロー、SMS OTP、監査、同意取得 |
導入時は、「高リスク取引では音声認証だけで完了させない」「失敗時は有人対応に切り替える」「録音・音声特徴量・本人確認結果をどの規程で扱うかを決める」といった業務ルールを先に作るべきです。グローバル企業では、国や地域ごとの生体情報・通話録音・個人情報保護ルールも確認が必要です。
Customer Service のメール分類は「AI の分類精度」より先に権限設計を確認する
Dynamics 365 Customer Service では、Case Management Agent が受信メールを分類する機能が示されています。管理者はカスタムのメールカテゴリを定義でき、AI がメールの件名と本文をもとに分類し、その結果をメール活動レコードの属性に書き込みます。分類結果は、Case Management Agent、Automatic Record Creation ルール、Power Automate、統合ルーティング、レポートなどの後続処理で利用されます。(Microsoft Learn)
この機能で失敗しやすいのは、AI の分類精度だけを検証して、権限と処理範囲の設計を後回しにすることです。分類結果が Power Automate やルーティングに渡る場合、誤分類は単なるラベルミスではなく、ケース作成、担当者割り当て、自動返信、エスカレーションに波及します。
管理者は、少なくとも次の観点を確認してください。
| 確認項目 | 実務での判断基準 |
|---|---|
| 対象メールボックス | 共有メールボックス、本番問い合わせ窓口、テスト用窓口を分ける |
| 分類対象条件 | 送信者ドメイン、言語、件名パターン、事業部単位で段階的に絞る |
| 下流処理 | Power Automate、統合ルーティング、レポートが分類値をどう使うか確認 |
| 手動修正 | 誤分類時に誰がカテゴリを修正できるか決める |
| 停止手順 | 問題発生時に新規分類を止める手順を用意する |
公式情報では、管理者が条件を構成し、対象となる受信メールが Case Management Agent フローの一部として分類されること、また管理者が機能を無効化できることが示されています。(Microsoft Learn) 本番導入前に、問い合わせ種別ごとのサンプルメールを使って「分類結果」だけでなく「分類後に何が実行されるか」まで確認しましょう。
AI による自律メール解決は「完全自動」と「下書き作成」を分けて運用する
Dynamics 365 Customer Service では、AI が顧客メールを分析し、必要な情報やアクションが揃っていれば自律的に解決する機能も示されています。公式情報では、企業ナレッジ、業務指示、コネクタ、カスタムエージェントを使って解決内容を構成し、メールで回答する流れが説明されています。自動解決できない場合は、顧客の意図や実行済みアクション、生成済み回答を含むケースを作成し、担当者が引き継げる設計です。(Microsoft Learn)
ここで重要なのは、すべての問い合わせを一気に完全自動化しないことです。管理者は事業部や問い合わせ種別ごとに、自動化レベルを分けるべきです。公式情報でも、管理者が業務ラインごとに自動化レベルを設定し、完全自律解決から担当者確認用の下書き作成まで選べることが示されています。(Microsoft Learn)
おすすめの導入順序は次の通りです。
| 段階 | 対象例 | 運用ルール |
|---|---|---|
| 下書きのみ | 契約、請求、クレーム、法務確認が絡む問い合わせ | AI は回答案作成まで。送信は担当者承認後 |
| 条件付き自動返信 | FAQ、営業時間、配送状況など低リスク問い合わせ | ナレッジ参照元と回答テンプレートを限定 |
| 完全自動解決 | 定型的で監査しやすい問い合わせ | 一定期間の精度確認後、対象範囲を限定して有効化 |
Microsoft Entra 管理者は、AI エージェントが参照するナレッジ、コネクタ、業務アプリ、メールボックスに対して、過剰な権限が付いていないかを確認してください。特に、テスト用に広い権限を付与したまま本番化するパターンは危険です。
Business Central の MCP server は Entra アプリ登録と条件付きアクセスの確認が必要
Business Central の拡張 MCP server では、AI エージェントが Business Central API やデータと安全に連携できるようにする機能が説明されています。公式情報では、Visual Studio Code、Copilot Studio、サードパーティの MCP クライアントとの互換性、OAuth 2.1、Microsoft Entra ID に登録されたサードパーティ MCP クライアントとの安全な統合が示されています。(Microsoft Learn)
これは Microsoft Entra 管理者にとって、特に重要な変更です。なぜなら、MCP クライアントが Business Central のデータへアクセスする場合、次のような確認が必要になるためです。
| 確認項目 | 確認内容 |
|---|---|
| アプリ登録 | 誰が Entra ID にアプリ登録できるか、管理者同意が必要か |
| API 権限 | Business Central API へのアクセス範囲が最小権限になっているか |
| OAuth フロー | ユーザー委任かアプリケーション権限か、運用に合っているか |
| 条件付きアクセス | 対象ユーザー、管理者、エージェント、アプリに適用されるポリシー |
| 監査 | MCP 構成変更、呼び出し成功・失敗、データ参照のログ確認 |
| サードパーティ | 外部 MCP クライアントの利用可否、承認プロセス、棚卸し |
公式情報では、MCP 構成のライフサイクルイベントや MCP 呼び出しの成功・失敗がテレメトリとして記録され、Microsoft Purview 連携による監査証跡にも触れられています。(Microsoft Learn) そのため、導入時は「接続できるか」だけでなく、「誰が、どのクライアントから、どの環境へ、どの権限で接続したか」を追跡できる状態にしておく必要があります。
Sales Order Agent の複数インスタンス化は共有メールボックス管理に注意する
Business Central の Sales Order Agent では、1 つの会社内で複数のエージェントインスタンスを構成できるようになる変更が示されています。各インスタンスは、独自のメールボックス、フォルダー設定、メール署名、処理ルールを持ち、チームや製品ライン、顧客セグメントごとに分けて運用できます。(Microsoft Learn)
この変更は業務上は便利ですが、Entra 管理者とメール管理者にとっては、共有メールボックスやグループ管理の複雑化につながります。たとえば、営業第 1 チーム、海外営業、代理店向け窓口で別々の Sales Order Agent を動かす場合、各エージェントがどのメールボックスを監視し、誰が設定を変更でき、処理済みメールがどう扱われるかを明確にする必要があります。
公式情報では、処理対象フォルダーの選択が必須化され、曖昧な状態でアクティブ化しないよう検証が強化されることも示されています。(Microsoft Learn) 本番導入では、次のような命名・管理ルールを設けると運用しやすくなります。
| 管理対象 | 推奨ルール例 |
|---|---|
| メールボックス | BC-SalesAgent-JP-Orders のように用途・地域・環境を含める |
| 監視フォルダー | Inbox 全体ではなく、業務ルールに合った専用フォルダーを使う |
| 管理者 | Business Central 管理者、メール管理者、Entra 管理者の責任範囲を分ける |
| テスト | 本番メールを送らずにセットアップ画面からテストタスクを作成する |
| 監査 | どのエージェントが見積・受注を作成したかを定期的に確認する |
特にグローバル組織では、国別の営業窓口や言語別メールボックスが増えやすいため、最初から標準ルールを決めておくことが重要です。
Microsoft Entra 側で確認すべき設定変更
今回のリリース計画を受けて、Microsoft Entra 管理者がすぐに確認すべき設定は大きく 5 つあります。
条件付きアクセスの対象アプリと対象ユーザーを見直す
Microsoft Entra 条件付きアクセスは、ユーザー、グループ、エージェント、場所、デバイス、アプリ、リスクなどのシグナルをもとにアクセス判断を行う仕組みです。(Microsoft Learn) Dynamics 365 や Power Platform でエージェント機能が増えると、従来の「人が画面から使う」前提だけでは不十分になります。
確認すべきポイントは次の通りです。
| 項目 | 確認内容 |
|---|---|
| 対象リソース | Dynamics 365、Power Platform、Business Central、Copilot Studio 関連アプリがポリシー対象か |
| 管理者 | Power Platform 管理者、Dynamics 365 管理者、グローバル管理者に強い認証を要求しているか |
| 例外 | サービスアカウントやアプリ登録を安易に除外していないか |
| レポート専用 | 新しいポリシーをすぐ有効化せず、影響を確認しているか |
| 緊急アクセス | break-glass アカウントが適切に除外・監視されているか |
エージェントやアプリ連携を止めたくないからといって、広範囲の除外を作るのは避けるべきです。例外は期限、理由、承認者、代替対策を記録して管理しましょう。
Entra セキュリティグループと Dataverse ロールを分けて確認する
Power Platform 環境では、Microsoft Entra のセキュリティグループを使って環境へのアクセスを制御できます。ただし、環境に入れることと、Dataverse データにアクセスできることは別です。公式情報でも、環境のセキュリティグループに所属していても、環境内のセキュリティロールがなければデータへアクセスできないことが示されています。(Microsoft Learn)
よくある失敗は、Entra グループに追加しただけで「権限設定は完了した」と考えてしまうことです。実際には、次の 2 段階で確認する必要があります。
| レイヤー | 役割 |
|---|---|
| Microsoft Entra セキュリティグループ | 環境に入れるユーザー・チームを制御する |
| Dataverse セキュリティロール | 環境内でどのデータ・機能にアクセスできるかを制御する |
AI エージェントや自動化機能の対象ユーザーを増やす場合は、Entra グループ、Dataverse チーム、セキュリティロール、Power Automate 接続、共有メールボックス権限をセットで棚卸ししてください。
管理者ロールは PIM とセルフ昇格を前提にする
Power Platform では、高権限の管理者ロール管理に Microsoft Entra Privileged Identity Management を活用する流れが強まっています。公式情報では、グローバル管理者、Power Platform 管理者、Dynamics 365 管理者が Dataverse データへ直接アクセスする作業を行うには、対象環境の System Administrator ロールへ昇格する必要があり、その昇格操作は Microsoft Purview に記録されると説明されています。(Microsoft Learn)
これは、今回のようなリリース対応でも重要です。新機能の検証や本番設定の変更時に、恒久的な System Administrator を増やすのではなく、必要な作業だけ一時的に昇格する設計にしましょう。
確認すべき項目は次の通りです。
| 項目 | 推奨対応 |
|---|---|
| 恒久管理者 | 不要な System Administrator を削除または見直す |
| 作業申請 | リリース検証、設定変更、本番反映の承認フローを用意する |
| PIM | Microsoft Entra PIM で Just-in-Time の管理者付与を使う |
| 監査 | 昇格操作、設定変更、エージェント有効化をログで確認する |
| グループ付与 | サポートされない、または期待通り動かないロール付与方式を避ける |
「リリース対応だから一時的に強い権限を付ける」は現場で起きやすい判断ですが、その一時権限が残ることが最も危険です。
エージェント認証と公開チャネルを環境単位で統制する
Power Platform では、エージェントの認証や公開チャネルを管理する仕組みも重要になっています。公式情報では、管理者が環境内のすべてのエージェント操作に対して認証方式を設定でき、Microsoft Entra ID による認証を強制する選択肢が示されています。また、エージェントの公開チャネルについても、Teams、Direct Line、Facebook、Dynamics 365 Customer Service、SharePoint、WhatsApp などのチャネルを制御できると説明されています。(Microsoft Learn)
今回の Dynamics 365 リリースでは、Customer Service、Contact Center、Business Central でエージェント系の機能が目立ちます。そのため、環境ごとに次の方針を決めておくと安全です。
| 環境 | 推奨方針 |
|---|---|
| 開発環境 | 検証目的のチャネルを限定し、外部公開を原則禁止 |
| テスト環境 | 本番に近い認証条件で検証し、匿名アクセスを避ける |
| 本番環境 | Microsoft Entra 認証を基本とし、公開チャネルは承認制にする |
| サンドボックス | 本番データコピー時は外部送信・自動返信を無効化して検証 |
エージェント機能は業務部門が簡単に試せる一方で、公開範囲を誤ると意図しない外部チャネルからアクセスされる可能性があります。作成者の自由度と管理者の統制を両立させるには、環境別のルールが欠かせません。
移行期限はあるのか：今回の読み方
今回のリリース計画だけを見る限り、Microsoft Entra 管理者が一律で対応しなければならない「移行期限」が明記されているわけではありません。ただし、実務上は次の時期を期限のように扱って準備する必要があります。
| 時期 | 管理者が行うこと |
|---|---|
| Public preview 前 | 対象環境、対象ユーザー、検証シナリオを決める |
| Public preview 中 | サンドボックスで認証・権限・監査・業務フローを検証する |
| GA 前 | 本番有効化の可否、例外、教育、サポート体制を決める |
| GA 後 | 利用状況、失敗ログ、過剰権限、問い合わせ傾向を確認する |
Dynamics 365 のリリースサイクルでは、wave 1 が 4 月から 9 月、wave 2 が 10 月から翌年 3 月を対象とし、早期アクセスでは本番適用前にサンドボックス環境で検証できます。Microsoft も、早期アクセス機能は本番前にサンドボックスや試用環境で確認することを推奨しています。(Microsoft Learn)
グローバル展開では、国や地域によって提供時期が異なる可能性があります。公式情報でも、日付は国や地域、アプリ、機能によって異なる場合があるため、対象機能ごとのリリース計画を確認する必要があるとされています。(Microsoft Learn)
管理者向けの確認手順
今回の更新を受けて、Microsoft Entra 管理者、Dynamics 365 管理者、Power Platform 管理者は、次の順序で確認すると抜け漏れを減らせます。
| 手順 | 作業内容 | 成果物 |
|---|---|---|
| 1 | Release Planner で対象アプリと対象機能を確認 | 対象機能一覧 |
| 2 | 有効化区分を確認 | 自動有効化・管理者有効化の分類 |
| 3 | 影響環境を洗い出す | 本番、サンドボックス、開発、地域別環境の一覧 |
| 4 | Entra グループと Dataverse ロールを棚卸し | 権限マトリクス |
| 5 | 条件付きアクセスと MFA を確認 | 影響評価、例外一覧 |
| 6 | アプリ登録とサービスプリンシパルを確認 | API 権限、同意状況、所有者一覧 |
| 7 | 監査ログを確認 | Purview、Power Platform、Dataverse の確認手順 |
| 8 | サンドボックスで検証 | 検証結果、既知の問題、回避策 |
| 9 | 本番有効化判断を行う | 承認記録、ロールバック手順 |
| 10 | 利用開始後にレビュー | 問い合わせ、失敗ログ、権限変更履歴 |
特に、AI エージェントがメール、顧客情報、注文、ナレッジ、ERP データにアクセスする機能では、業務部門だけで有効化判断をしないことが重要です。ID 管理、セキュリティ、監査、法務、業務オーナーを含めた確認フローを作りましょう。
失敗しやすいポイントと回避策
「リリース計画に載っている＝すぐ本番で使える」と考える
リリース計画には、まだ提供されていない機能や、予定が変更される可能性のある機能も含まれます。公式情報でも、提供時期や予定機能は変更される可能性があるとされています。(Microsoft Learn)
回避策は、リリース計画を「確定仕様書」ではなく「準備のための早期情報」として扱うことです。本番の変更計画には、必ず最終確認日と参照した公式ページを記録してください。
自動化機能を有効化してから権限を確認する
メール分類、自律メール解決、Sales Order Agent、MCP server は、業務効率化の効果が大きい反面、アクセス権の影響範囲も広くなります。先に有効化してしまうと、後から「どのデータを読めるのか」「誰の権限で動いているのか」を調べることになります。
回避策は、有効化前に次の 3 点を必ず確認することです。
| 確認項目 | 質問 |
|---|---|
| 実行主体 | 人、エージェント、アプリ、サービスプリンシパルのどれが処理するのか |
| 参照データ | メール、Dataverse、Business Central、ナレッジ、外部 API のどこを見るのか |
| 実行アクション | 分類、返信、ケース作成、受注作成、API 呼び出しのどこまで行うのか |
Entra グループだけでアクセス制御が完了したと考える
Power Platform や Dynamics 365 では、Entra グループに加えて、環境、Dataverse ロール、アプリ共有、チーム、メールボックス権限が絡みます。Entra グループに追加しただけでは、Dataverse データへのアクセス権が十分でない、または逆に広すぎることがあります。(Microsoft Learn)
回避策は、「Entra グループ」「環境アクセス」「Dataverse ロール」「業務アプリ内ロール」を 1 枚の表にまとめることです。人事異動、部門再編、グローバルロール変更がある組織では、四半期ごとの棚卸しも検討してください。
グローバル展開で地域差を見落とす
Dynamics 365 や Power Platform の機能は、地域、言語、アプリ、環境種別によって利用開始時期が変わることがあります。特に音声認証、AI エージェント、外部チャネル連携は、国ごとの規制やデータ処理要件の確認が必要です。
回避策は、グローバル標準ポリシーを作ったうえで、地域ごとの例外を管理することです。たとえば、欧州、米国、日本、APAC で、音声データ、顧客メール、自動返信、外部委託先アクセスの扱いが異なる場合は、同じ機能でも有効化タイミングを分けるべきです。
次に取るべきアクション
今回の「Release plans for Dynamics 365 and Power Platform」更新で、Microsoft Entra 管理者がすぐに行うべきことは、すべての新機能を詳細に読むことではありません。まずは、認証、権限、エージェント、メール、API、監査に関係する機能だけを抽出することです。
優先順位は次の通りです。
| 優先度 | 対応内容 |
|---|---|
| 高 | Customer Service、Contact Center、Business Central のエージェント・認証機能を確認 |
| 高 | 条件付きアクセス、MFA、アプリ登録、管理者ロールの影響を確認 |
| 中 | Sales Order Agent など共有メールボックスを使う機能の運用設計 |
| 中 | サンドボックスで自動化レベル、誤分類、ログ出力を検証 |
| 低 | 業務影響が限定的な ERP 機能は各アプリ管理者と連携して確認 |
2026 release wave 1 は、単なる業務アプリの機能追加ではなく、AI エージェントと自動化が業務データへ深く入っていく更新です。Microsoft Entra 管理者は、リリース計画を「認証・アクセス制御の変更予告」として読み、対象環境、対象ユーザー、管理者権限、アプリ登録、監査ログを先に整理しておきましょう。
コメント