Power PlatformのAdvanced connector policies（ACP）は、従来のデータポリシーよりも細かく、厳格にコネクタ利用を制御するための新しい仕組みです。結論から言うと、2026年6月2日更新の公式情報で最も重要なのは、従来の「Business / Non-Business / Blocked」に分類する考え方から、明示的に許可したコネクタとアクションだけを使える“許可リスト型”の管理へ移る点です。Microsoft Learnでは、ACPをPower Platformにおける次世代のコネクタ保護機能と位置付け、既定ではすべてのコネクタとアクションをブロックするモデルとして説明しています。(Microsoft Learn)
ただし、すべてをACPだけで置き換えられるわけではありません。現時点でACPの対象は主に認定コネクタであり、カスタムコネクタやHTTPコネクタはまだACPではサポートされていません。これらを使っている組織では、従来のデータポリシーと併用しながら段階的に移行する判断が必要です。(Microsoft Learn)
Advanced connector policiesとは何か
Advanced connector policiesは、Power Apps、Power Automate、Copilot Studioなどで使われるコネクタを、環境単位または環境グループ単位で制御するためのポリシーです。
従来のデータポリシーでは、コネクタをBusiness、Non-Business、Blockedの3種類に分類し、異なるグループ間でのデータ共有を制限する考え方が中心でした。Microsoftのドキュメントでも、従来のデータポリシーはコネクタを3つのデータグループに分類し、BusinessとNon-Businessなど異なるグループ間ではデータを共有できないと説明されています。(Microsoft Learn)
一方、Advanced connector policiesはよりシンプルです。
許可したものだけ使える。許可していないものは使えない。
この考え方に変わることで、次のような管理がしやすくなります。
| 観点 | 従来のデータポリシー | Advanced connector policies |
|---|---|---|
| 基本思想 | コネクタをBusiness / Non-Business / Blockedに分類 | 許可リストにないコネクタは既定でブロック |
| 新規コネクタ追加時 | 既定グループに分類される | 明示的に許可しない限りブロック |
| 制御粒度 | コネクタ単位が中心。一部でアクションやエンドポイント制御 | 認定コネクタに対してコネクタ単位・アクション単位で制御 |
| 適用範囲 | テナントや環境に対するデータポリシー | 個別環境または環境グループ |
| 移行時の注意 | 既存資産への影響確認が必要 | カスタムコネクタ、HTTPコネクタ、仮想コネクタの扱いに注意 |
特に大きいのは、新しくPower Platformに追加されたコネクタが自動的に許可されないことです。従来の運用では「知らないうちに新しい外部サービスのコネクタが使える状態になっていた」というリスクがありました。ACPでは既定でブロックされるため、セキュリティやコンプライアンスを重視する組織に向いています。
2026年6月2日更新情報で押さえるべき変更点
2026年6月2日更新のMicrosoft Learnでは、Advanced connector policiesについて、管理者が確認すべき複数のポイントが整理されています。特に重要なのは、以下の変更です。(Microsoft Learn)
| 変更点 | 内容 | 実務上の影響 |
|---|---|---|
| 既定拒否モデル | 明示的に許可しないコネクタとアクションはブロック | 新規コネクタの野放し利用を防ぎやすい |
| 環境・環境グループ対応 | 個別環境または環境グループに適用可能 | 本番、検証、部門別などで統制を分けやすい |
| アクション単位の可視化 | トリガー、内部アクション、非推奨アクションを確認可能 | 古いアクションやリスクの高い操作だけを抑制しやすい |
| 設計時の強制 | 作成者がアプリ、フロー、エージェントを作る段階で違反を検知 | 公開後に動かない、という手戻りを減らせる |
| ACP-only mode | 従来のデータポリシー評価をスキップし、ACPだけで評価可能 | 移行完了後のポリシー運用を単純化できる |
| Mixed mode | 従来のデータポリシーとACPを併用可能 | 移行期間中の現実的な運用ができる |
| MCPサーバー管理 | MCPサーバーをACP上で確認・ブロック可能 | Copilot Studioやエージェント利用時の統制に関係する |
| Remove rule | ACPルールをUIから削除可能 | API操作や全許可による解除に頼らず無効化できる |
従来のデータポリシーをすぐ廃止するのではなく、まずはMixed modeで併用し、対象コネクタや既存資産への影響を確認してからACP-only modeへ進むのが安全です。
対象になるコネクタと対象外のコネクタ
Advanced connector policiesを導入する前に、最初に確認すべきなのは「自社で使っているコネクタがACPの対象かどうか」です。
Microsoftの公式情報では、ACPは認定コネクタのカタログを基盤にしており、認定コネクタとMCPコネクタには対応する一方、カスタムコネクタとHTTPコネクタは現時点では未対応、仮想コネクタは今後もACPには追加されないと説明されています。(Microsoft Learn)
| コネクタ種別 | ACPでの扱い | 管理者の対応 |
|---|---|---|
| 認定コネクタ | 対応 | ACPで許可・ブロック、アクション単位の制御を検討 |
| MCPコネクタ | 対応 | MCPサーバー単位でブロック可能。個別ツール単位の細かな制御は現時点では不可 |
| カスタムコネクタ | 未対応 | 従来のデータポリシーで管理を継続 |
| HTTPコネクタ | 未対応 | 従来のデータポリシーやコネクタエンドポイントフィルタリングで管理 |
| 仮想コネクタ | 非対応 | Copilot Studio関連は専用ルールへの移行を待つ。Desktop Flow系は認定コネクタ化後にACP管理の対象になる可能性 |
この点を見落とすと、ACPを有効化したのにHTTPコネクタやカスタムコネクタの制御が抜ける、または逆に従来ポリシーとの整合性が崩れる可能性があります。
特に開発部門が外部API連携のためにカスタムコネクタを多用している場合、ACPだけを前提に移行計画を作るのは危険です。まずは既存のカスタムコネクタ、HTTP、Webhook、外部SaaS連携を棚卸しし、どの制御をACPに移し、どの制御を従来のデータポリシーに残すかを分けてください。
従来のデータポリシーから何が変わるのか
Advanced connector policiesの本質は、単なるUI変更ではありません。Power Platformのガバナンス設計そのものが変わります。
Business / Non-Business分類の考え方から離れる
従来のデータポリシーでは、「SharePointはBusiness」「GmailはNon-Business」のように分類し、同じアプリやフロー内で組み合わせられるかを制御していました。これはデータ流出防止の考え方として有効ですが、現場では分類ルールが複雑になりやすい問題もあります。
ACPでは、この分類モデルを前提にしません。使ってよいコネクタとアクションを明示的に許可し、それ以外はブロックします。Microsoftも、従来のBusiness / Non-BusinessカテゴリはACPには引き継がれず、ポリシー管理を簡素化するため厳格な許可リストにしたと説明しています。(Microsoft Learn)
実務では、次のような判断に変わります。
| 旧来の判断 | ACPでの判断 |
|---|---|
| このコネクタはBusinessかNon-Businessか | この環境でこのコネクタを使わせる必要があるか |
| このコネクタ同士を組み合わせてよいか | このアクションやトリガーまで許可してよいか |
| 既定グループを何にするか | 許可リストに何を入れるか |
| 新規コネクタをどの分類に入れるか | 新規コネクタは原則ブロックし、必要時に審査して許可 |
「使えるコネクタ」ではなく「使える操作」まで見る
ACPでは、コネクタ単位だけでなく、アクションやトリガー単位の可視性が強化されています。公式ドキュメントでは、従来のデータポリシーでは見えなかったトリガー、内部アクション、非推奨アクションを確認できるようになり、管理者が特定のトリガーや非推奨アクションをブロックする判断をしやすくなると説明されています。(Microsoft Learn)
たとえば、Office 365 Outlookコネクタを全面的に禁止するのは現実的でない場合があります。しかし、特定のメール送信アクション、外部共有につながる操作、非推奨アクションだけを制限したいケースはあります。
このような場合、ACPのアクション単位の管理は有効です。特に本番環境では、「コネクタを許可するかどうか」だけでなく、「そのコネクタのどの操作を許可するか」までレビューする運用に変えるべきです。
影響範囲：管理者、開発者、作成者が受ける影響
Advanced connector policiesの影響は、Power Platform管理者だけにとどまりません。アプリやフローを作る開発者、市民開発者、Copilot Studioでエージェントを作る担当者にも影響します。
Power Platform管理者への影響
管理者は、従来のデータポリシーに加えて、ACPという新しい制御レイヤーを設計する必要があります。
特にMixed modeでは、従来のデータポリシーとACPの両方が評価され、最も制限の強い設定が反映されます。公式ドキュメントでも、Mixed modeではクラシックデータポリシーとACPの最も制限的な設定を統合したポリシーが評価されると説明されています。(Microsoft Learn)
つまり、「従来ポリシーでは許可しているのに使えない」「ACPでは許可しているのに実行時に失敗する」といった問い合わせが発生する可能性があります。移行期間中は、どちらのポリシーでブロックされているかを切り分けられる運用が必要です。
開発者・作成者への影響
作成者にとっての大きな変化は、設計時にブロックされるケースが増えることです。
ACPは設計時の強制に対応し、作成者がアプリ、フロー、エージェントを作成している段階で、ブロックされたコネクタやアクションを使おうとするとエラーが表示されます。展開順はPower Automate、Copilot Studio、Power Appsの順とされ、各Maker Portalで設計時サポートが提供されるまでは、そのワークロードでは実行時のみの強制になります。(Microsoft Learn)
これは良い変更です。公開後や本番実行時に初めて失敗するより、作成段階で気づける方が手戻りは少なくなります。
ただし、作成者側から見ると「昨日まで使えたコネクタが突然使えない」と感じる可能性があります。管理者は、導入前に次の情報を共有しておくと混乱を減らせます。
- どの環境にACPを適用するのか
- 使えなくなる可能性があるコネクタやアクション
- 例外申請の方法
- 既存アプリやフローの確認期限
- ブロック時の問い合わせ先
Copilot StudioとMCP利用への影響
ACPでは、Model Context Protocol（MCP）サーバーの可視化と管理にも対応しています。管理者はACP上でMCPサーバーを確認し、サーバー全体をブロックできます。ただし、MCPサーバー内の個別ツールや個別エンドポイント単位での細かな制御は、現時点では利用できないと説明されています。(Microsoft Learn)
Copilot Studioでエージェントを展開している組織では、この点が重要です。MCPサーバーを許可することは、エージェントが外部機能やAPI的な能力にアクセスできる可能性を広げることを意味します。
そのため、Copilot Studioを使っている場合は、通常のコネクタ棚卸しに加えて、MCPサーバーの利用有無も確認してください。
管理者が最初に確認すべき設定
ACPを導入する前に、いきなり本番環境へ適用するのは避けるべきです。まずは現在の利用状況、環境構成、従来ポリシーとの関係を整理します。
| 確認項目 | 確認内容 | 判断基準 |
|---|---|---|
| コネクタ利用状況 | どのアプリ、フロー、エージェントが何のコネクタを使っているか | 使われていないコネクタは許可しない |
| アクション利用状況 | どのトリガーやアクションが使われているか | 非推奨アクション、不要な高権限操作は許可しない |
| カスタムコネクタ | 自社APIや外部API連携があるか | ACPではなく従来データポリシーで管理 |
| HTTPコネクタ | HTTP、Webhook、HTTP request系の利用有無 | 従来データポリシーやエンドポイント制御を継続 |
| 環境分類 | 本番、検証、個人開発、部門別環境の区別 | 本番ほど厳格な許可リストにする |
| 環境グループ | 管理対象環境をグループ化できるか | 同じ統制でよい環境だけをまとめる |
| 既存DLP | 現在のBusiness / Non-Business / Blocked設定 | ACP移行後も必要な制御を洗い出す |
| ACP-only mode | 従来ポリシーを無視してよい状態か | 移行完了前は原則有効化しない |
コネクタ棚卸しには、Power Platform inventoryの活用が有効です。Microsoft Learnでは、Power Platform inventoryでアプリ、フロー、エージェントを統合的に確認でき、コネクタや操作の利用状況を把握できると説明されています。特にConnector visibilityでは、各リソースが使っているコネクタや操作をインベントリグリッド上で確認できます。(Microsoft Learn)
ACPの設定手順
Advanced connector policiesは、環境グループ単位または単一環境単位で設定できます。
環境グループに適用する場合
複数環境へ同じルールを展開したい場合は、環境グループを使います。公式ドキュメントでは、Power Platform管理センターの「Manage」から「Environment groups」を開き、対象グループの「Rules」タブでAdvanced connector policiesを設定し、保存後に「Publish rules」を実行する手順が案内されています。(Microsoft Learn)
基本的な流れは次の通りです。
| 手順 | 操作 |
|---|---|
| 1 | Power Platform管理センターにサインイン |
| 2 | Manage > Environment groups を開く |
| 3 | 対象の環境グループを選択 |
| 4 | Rulesタブを開く |
| 5 | Advanced connector policiesを選択 |
| 6 | 許可するコネクタとアクションを設定 |
| 7 | Saveで保存 |
| 8 | Publish rulesで環境グループに反映 |
環境グループを使う場合の注意点は、環境グループにはManaged Environmentsのみを含められることです。また、各環境は1つのグループにしか所属できず、グループの入れ子もできません。(Microsoft Learn)
本番環境、開発環境、個人開発環境、AI検証環境を同じグループに入れると、必要以上に厳しい、または緩いポリシーになる可能性があります。環境グループは「組織図」ではなく「同じガバナンスで管理したい環境のまとまり」として設計してください。
単一環境に適用する場合
特定の環境だけで試したい場合や、高リスク環境だけ厳しく管理したい場合は、単一環境に直接ACPを設定します。
公式ドキュメントでは、Power Platform管理センターの「Security」から「Data and privacy」を開き、Advanced connector policiesを選択して設定する手順が示されています。(Microsoft Learn)
基本的な流れは次の通りです。
| 手順 | 操作 |
|---|---|
| 1 | Power Platform管理センターにサインイン |
| 2 | Security > Data and privacy を開く |
| 3 | Advanced connector policiesを選択 |
| 4 | 許可するコネクタとアクションを設定 |
| 5 | Saveで適用 |
単一環境への適用は、検証や段階導入に向いています。まずは影響範囲が小さい環境で試し、作成時と実行時の挙動、既存フローへの影響、問い合わせ内容を確認してから展開範囲を広げると安全です。
ACP-only modeとMixed modeの使い分け
ACP導入時に迷いやすいのが、ACP-only modeを使うべきか、Mixed modeで従来データポリシーと併用すべきかです。
移行中はMixed modeが現実的
Mixed modeでは、従来のデータポリシーとACPを並行して評価します。Microsoftは、Mixed modeを従来データポリシーからACPへ移行する際に有用な方法として説明しています。(Microsoft Learn)
次のような組織では、まずMixed modeを選ぶのが現実的です。
- カスタムコネクタを使っている
- HTTPコネクタやWebhookを使っている
- 既存のDLP設計が複雑で、すぐに廃止できない
- Power Automate、Power Apps、Copilot Studioの利用状況をまだ棚卸しできていない
- 一部の部門だけ先行導入したい
Mixed modeの注意点は、トラブルシューティングがやや複雑になることです。ブロック原因がACPなのか従来データポリシーなのかを切り分ける必要があります。問い合わせ対応のために、ポリシー名、対象環境、対象コネクタ、対象アクションを記録しておきましょう。
移行完了後にACP-only modeを検討する
ACP-only modeでは、対象環境で従来のデータポリシー評価をスキップし、ACPだけでコネクタガバナンスを行います。公式ドキュメントでは、ACP-only modeを有効にするとクラシックデータポリシーは削除されず残るものの、ACP-only modeが有効な間は強制されないと説明されています。(Microsoft Learn)
ACP-only modeは、次の条件を満たしてから検討してください。
- 認定コネクタの許可リスト設計が完了している
- カスタムコネクタとHTTPコネクタの管理方針が別途決まっている
- 既存アプリ、フロー、エージェントの影響確認が終わっている
- 作成者向けの周知と例外申請フローが整っている
- 本番環境での検証手順と戻し手順がある
移行が不完全な状態でACP-only modeを有効化すると、「従来のデータポリシーで守っていたはずの制御が効かない」または「ブロック原因の説明ができない」という状態になりかねません。
Managed Environmentsと非Managed Environmentsの違いに注意
ACPは単一環境モードではManaged Environmentsと非Managed Environmentsの両方で利用できます。ただし、非Managed Environmentsでは従来のデータポリシーでブロックできない一部のコネクタは引き続きブロックできません。一方、Managed Environmentsでは、従来ブロックできなかったコネクタを含め、任意の認定コネクタやアクションをブロックできます。(Microsoft Learn)
これは実務上かなり重要です。
同じACPという名前でも、環境の種類によって制御できる範囲が変わるためです。特にDataverse、SharePoint、Microsoft 365 Outlook、Teamsなど、業務上よく使われるMicrosoft系コネクタをどこまで制限できるかは、環境の管理状態に左右されます。
厳格なガバナンスを必要とする本番環境や規制対象環境では、Managed Environments化を含めて設計を見直してください。
移行時の実務ステップ
Advanced connector policiesへの移行は、ポリシー画面で設定を入れるだけでは不十分です。既存資産への影響確認、例外管理、作成者への周知まで含めて進める必要があります。
まずはコネクタ利用状況を棚卸しする
最初にやるべきことは、現在使われているコネクタを把握することです。
Power Platform inventoryでは、アプリ、フロー、エージェントが使っているコネクタや操作を確認でき、Power Platform for Admins V2 connector、Power Platform inventory API、Azure Resource Graphでも同じデータを扱えると説明されています。(Microsoft Learn)
棚卸しでは、最低限次の項目を整理します。
| 項目 | 例 |
|---|---|
| 環境名 | Production、Sales Dev、Defaultなど |
| リソース種別 | Canvas app、Model-driven app、Cloud flow、Agentなど |
| 所有者 | 部門、担当者、サービスアカウント |
| 使用コネクタ | SharePoint、Dataverse、Office 365 Outlook、Salesforceなど |
| 使用アクション | メール送信、レコード作成、ファイル取得など |
| 業務重要度 | 本番必須、部門利用、個人利用、廃止候補 |
| 外部連携有無 | 社外SaaS、HTTP、カスタムAPIなど |
| 代替可否 | 別コネクタで代替可能か、業務停止リスクがあるか |
ここを飛ばして許可リストを作ると、必要なフローが止まったり、逆に不要なコネクタを広く許可したりする原因になります。
許可リストの基準を決める
許可リストは、単に「現在使われているから許可」ではなく、業務上の必要性とリスクで判断します。
実務では、次の基準で分類すると整理しやすくなります。
| 判断 | 基準 |
|---|---|
| 許可する | 業務上必須、データ管理責任者が明確、利用部門と用途が説明できる |
| 条件付きで許可する | 特定部門、特定環境、特定アクションに限定すれば許容できる |
| 一時許可にする | 移行期間中のみ必要、廃止予定の資産で使っている |
| ブロックする | 個人利用色が強い、外部転送リスクが高い、利用実績がない、代替手段がある |
| 従来DLPで管理する | カスタムコネクタ、HTTPコネクタ、仮想コネクタ関連 |
たとえば、本番環境ではDataverse、SharePoint、Office 365 Outlookを許可しつつ、外部ストレージや個人向けメールサービスはブロックする、といった設計が考えられます。一方、開発環境では検証用に一部の外部SaaSコネクタを許可するが、本番環境への昇格時には再審査する、という運用も有効です。
パイロット環境で検証する
ACPは設計時と実行時の両方に影響します。パイロットでは、管理者目線だけでなく、作成者目線でも確認してください。
| 検証観点 | 確認内容 |
|---|---|
| 作成時 | ブロックされたコネクタを追加しようとしたときにエラーが出るか |
| 保存時 | アプリやフローの保存が意図通り制御されるか |
| 実行時 | 既存フローやアプリが失敗しないか |
| 通知 | 作成者がエラー内容を理解できるか |
| 例外申請 | 追加許可が必要な場合の判断ルートがあるか |
| 監査 | どのポリシー変更がいつ適用されたか追えるか |
環境グループに対してACPを公開すると、グループ内の各環境に対して環境ライフサイクル操作が実行され、環境履歴には「Update Managed Environment Settings」として表示されると説明されています。(Microsoft Learn)
本番適用後は、設定画面のStatusがAppliedになっているか、対象環境の履歴、作成者側の挙動、既存フローの実行結果を確認してください。
展開時に失敗しやすいポイント
Advanced connector policiesは便利ですが、導入時に失敗しやすいポイントがあります。
| 失敗しやすいポイント | 起きる問題 | 対策 |
|---|---|---|
| ACPだけで全コネクタを管理できると思い込む | カスタムコネクタやHTTPコネクタの制御が抜ける | 対象外コネクタは従来DLPで継続管理 |
| 既存DLPを確認せずACPを追加する | Mixed modeで想定外にブロックされる | 両方のポリシーを一覧化してから設定 |
| 本番環境へ一括適用する | 重要フローやアプリが停止する | パイロット環境から段階展開 |
| コネクタ単位だけで許可する | 不要なアクションまで使える | アクション、トリガー、非推奨アクションも確認 |
| ACP-only modeを早く有効化する | 従来DLPで守っていた制御が無効になる | 移行完了後に限定して有効化 |
| 環境グループ設計が粗い | 開発環境と本番環境に同じ制約がかかる | ライフサイクルやリスク別にグループ化 |
| 作成者への周知がない | 問い合わせや業務停止が増える | 変更日、影響範囲、例外申請方法を事前共有 |
特に注意したいのは、環境グループから環境を外した場合の挙動です。公式ドキュメントでは、環境を環境グループから削除しても、最後に適用されたACP構成は保持され、その後は個別環境で調整できると説明されています。(Microsoft Learn)
つまり、グループから外しただけでポリシーが完全に初期化されるわけではありません。検証や例外対応で環境を移動する場合は、移動後のACP設定を必ず確認してください。
管理者・開発者別の確認チェックリスト
管理者向けチェックリスト
- Power Platform inventoryでコネクタ利用状況を確認した
- 本番、検証、開発、個人環境を分類した
- 環境グループを使うか、単一環境に適用するか決めた
- Managed Environmentsと非Managed Environmentsの違いを確認した
- 従来のデータポリシーとACPの役割分担を決めた
- カスタムコネクタとHTTPコネクタの管理方針を残した
- MCPサーバーの利用有無を確認した
- 例外申請ルートを決めた
- ACP-only modeを有効化する条件を定義した
- 作成者向けに変更内容を周知した
開発者・作成者向けチェックリスト
- 自分のアプリやフローが使っているコネクタを確認した
- 外部SaaS、HTTP、カスタムコネクタの利用有無を確認した
- ブロック予定のコネクタを使う資産を管理者に申告した
- 非推奨アクションを使っていないか確認した
- 本番で必要なフローを検証環境で実行確認した
- エラーが出た場合の問い合わせ先を把握した
- 新しいコネクタを使う前に承認手順を確認した
どの運用パターンを選ぶべきか
ACPの導入方針は、組織の成熟度や利用状況によって変わります。
| 状況 | 推奨方針 |
|---|---|
| Power Platform利用が限定的 | 単一環境でACPを試し、許可リストの考え方に慣れる |
| 本番利用が多い | Power Platform inventoryで棚卸し後、Mixed modeで段階移行 |
| カスタムコネクタやHTTPが多い | ACPだけに移行せず、従来DLPを併用 |
| Copilot StudioやMCPを活用中 | MCPサーバー単位のブロック可否を重点確認 |
| 多数の環境を管理している | Managed Environmentsと環境グループで標準ルール化 |
| ガバナンスを厳格化したい | 認定コネクタ中心にACPを整備し、移行後にACP-only modeを検討 |
おすすめは、いきなり全社展開するのではなく、次の順番で進めることです。
- Power Platform inventoryで利用実態を把握する
- 従来DLPとACPの対象範囲を分ける
- 検証環境または限定部門でACPを適用する
- 作成時・実行時の挙動を確認する
- 本番環境に段階展開する
- カスタムコネクタやHTTPの扱いを整理したうえでACP-only modeを検討する
まとめ：ACPは「DLPの置き換え」ではなく、移行設計が必要な新しい統制レイヤー
Advanced connector policiesは、Power Platformのコネクタ管理をより厳格かつ実務的にする重要な機能です。特に、既定拒否の許可リスト型、アクション単位の制御、環境グループによる展開、設計時の強制、ACP-only modeは、従来のデータポリシーよりも強力なガバナンスを実現します。
一方で、カスタムコネクタ、HTTPコネクタ、仮想コネクタはACPだけでは管理しきれません。既存のアプリ、フロー、エージェントがどのコネクタを使っているかを確認せずに適用すると、業務影響が出る可能性があります。
まず取り組むべきことは明確です。
Power Platform inventoryで利用中のコネクタを棚卸しし、ACPで管理するもの、従来データポリシーに残すもの、段階的に廃止するものを分けてください。
そのうえで、検証環境からACPを適用し、Mixed modeで影響を確認しながら移行するのが安全です。ACP-only modeは、移行完了後に運用をシンプルにするための選択肢として考えるとよいでしょう。
コメント