Intune 構成プロファイルの競合を特定する方法｜Conflictが見えないときのレポート手順

Intune のホーム ダッシュボードに「構成ポリシー（構成プロファイル）が 2 つ競合している」と出ているのに、クリックしても「割り当ての失敗」が空で原因が追えない――この状況は意外とよくあります。本記事では、競合しているポリシー同士を“手早く”特定する具体的な見方と、レポートで確実に洗い出す方法、再発を減らす設計のコツまでまとめます。

Intune の「構成プロファイルの競合」とは（まず押さえるべき前提）

Intune の「Conflict（競合）」は、同じデバイス／同じユーザーに対して、同じ設定項目（実体としては同じ CSP / 同じポリシーキーに相当することが多い）へ、複数のポリシーが異なる値を配信しようとしたときに発生します。

典型例としては、次のようなケースです。

• 構成プロファイル A：パスワード最小長 8
• 構成プロファイル B：パスワード最小長 12
• 同一デバイス（または同一ユーザー）に両方が割り当てられている

この場合、OS 側がどちらかを自動採用してくれるとは限らず、Intune 側では「競合」として扱われます。運用上の結論はシンプルで、同じ設定項目を複数ポリシーで別値にしないことが解決と予防の近道です。

よくある表示	実際に起きていること	切り分けの最短ルート
ホームに「2 つ競合」	競合が現時点で残っている、または古い状態が残っている	デバイス画面の「競合」→設定項目を開く
エラーをクリックすると「割り当ての失敗」だが空	ダッシュボードの集計と詳細画面の表示条件が噛み合っていない／削除済みポリシーの残骸／集計遅延	レポートで Conflict を一覧化して裏取り
デバイス側で競合が見えない	同期前、表示のタイミング差、または競合が解消済みでダッシュボードだけ残っている	同期＋レポートで最新状態を確認

最短で「どのポリシー同士が競合しているか」を特定する（デバイス側から追う）

まず最初に試すべきは、対象デバイスの画面から競合を“設定項目レベル”まで掘る方法です。ダッシュボードは集計表示のため、ここが一番情報が濃いことが多いです。

手順：対象デバイス → 競合プロファイル → 競合している設定項目

1. Intune 管理センターにサインインします。
2. 左メニューの［デバイス］を開き、問題の対象デバイスを選択します（Windows 10/11 端末なら Windows デバイス一覧から辿るのが早いです）。
3. デバイスのメニューから［デバイスの構成］または［構成プロファイル］を開きます。
   ※管理センターの UI 更新により名称や配置が微妙に異なることがあります。見当たらない場合は、デバイス詳細画面上部の検索（検索ボックス）で「構成」「プロファイル」などのキーワード検索を使うと見つけやすいです。
4. 一覧の中で状態が「Conflict（競合）」になっているプロファイル（ポリシー）をクリックします。
5. 詳細画面で、競合マークが付いている設定項目をクリックします。

ここまで辿れると、同じ設定項目に対してどの 2 つのプロファイルが、どんな値を設定しているかが表示されます（両方とも Intune 由来の配布である場合）。つまり、原因が「プロファイル名 × 設定値」の形で見えるため、修正対象が一気に絞れます。

この画面で確認すべきポイント

• 競合している設定項目名（どの設定がぶつかっているか）
• 競合しているポリシー（プロファイル）名（誰がぶつけているか）
• それぞれの設定値（何が違うのか）
• 割り当て先（同じデバイスが両方のスコープに入っていないか）

見える情報	意味	次にやること
Conflict になっているプロファイル名	競合の当事者（片方、または双方）	両方のプロファイルを別タブで開き、同じ設定項目を探す
競合マークの付いた設定項目	ぶつかっている“設定の正体”	設定項目ごとに、どちらを正とするか決める
設定値の差分（A は有効、B は無効 など）	Conflict の原因そのもの	値を統一、片方から項目削除、割り当て分離のいずれかで解消

競合が見えない／「割り当ての失敗」が空のときは、レポートで一覧化して特定する

質問の状況のように、

• ダッシュボードのエラーをクリックしても「割り当ての失敗」に何も出ない
• デバイス画面でも Conflict が出てこない（または当該項目まで辿れない）

という場合は、レポート機能で全ポリシーの状態を俯瞰し、Conflict を“表”で洗い出す方法が有効です。ダッシュボードは集計・キャッシュの影響で古い情報を表示することがあり、レポートの方が状況を掴みやすいケースがあります。

手順：レポート「ポリシー構成の状態（Policy configuration status）」で Conflict を抽出

1. Intune 管理センターの左メニューで［レポート］を開きます。
2. ［デバイス構成］（または同等のカテゴリ）を選択します。
3. レポート一覧から「Device Configuration – Policy configuration status」（日本語環境では「デバイス構成 – ポリシー構成の状態」など）を選びます。
4. ［生成］［実行］などの操作でレポートを作成します。
5. 出力結果から状態が「Conflict」になっているポリシー／デバイスを探します。

運用で素早く見つけるコツは、次のどちらかです。

• 対象デバイス名で絞り込む（デバイス起点で原因を潰したい場合）
• Conflict の行だけを抽出する（環境全体の競合を棚卸ししたい場合）

もしレポート結果をエクスポートできるなら、CSV に落として「Conflict」でフィルターし、該当ポリシー名を拾うのが非常に早いです。

レポートで見つけたら、次は“設定項目レベル”に落とす

レポートは「どのポリシーが Conflict か」を教えてくれますが、「どの設定項目が競合しているか」は別画面になることが多いです。そこで、レポートで当たりを付けたら次の流れで深掘りします。

• Conflict になっているポリシーを開く
• 割り当て（含む／除外）を確認し、同じデバイスが両方を受けていないかを見る
• デバイス起点の画面に戻って、競合マークの付いた設定項目を開く

「ダッシュボードは Conflict と言っているが、レポートでは Conflict が出ない」という場合は、競合がすでに解消済みで、ダッシュボード表示だけが古い可能性が上がります。このときは、次章の同期・更新の切り分けが役立ちます。

「競合」と出るのに中身が見えないときの切り分け（同期・更新・削除済み）

ダッシュボードや一部の一覧は、タイミングによって次のような“見え方のズレ”が起きることがあります。

• 削除した古いポリシーの情報が集計として残っている
• デバイスがしばらくチェックインしておらず、状態が更新されていない
• ポリシー変更直後で、レポートとダッシュボードの反映タイミングがずれている

最初に確認したい 2 点

• 対象デバイスの最終チェックイン時刻（最近チェックインしていないなら、まずそこが原因になりやすい）
• 競合が出ているとされるポリシーが、今も存在しているか（削除済み・置き換え済みだと詳細が辿れないことがあります）

同期の実施：クライアントと Intune から両方試す

「まだ競合が残っているのか、表示が古いだけなのか」を分けるには、同期を挟むのが有効です。

• Windows クライアント側：設定 → アカウント →（職場または学校にアクセス）→ 接続情報 → 同期
  ※表記は Windows のバージョンで異なります。
• Intune 管理センター側：対象デバイスを開き、デバイス操作の同期（Sync）を実行

その後、再度「デバイスの構成／構成プロファイル」やレポートを確認し、Conflict が消えているか／残っているかを見ます。消えていれば「古い表示だった」、残っていれば「実際に競合が継続している」と判断しやすくなります。

競合を解消する実務手順（“どちらを残すか”を決める）

競合の解消は、テクニックよりも意思決定が重要です。原因が分かったら、次のいずれかで必ず解消できます。

解消方法	具体的な操作	向いているケース	注意点
値を統一する	両方のプロファイルで同じ値に揃える	どちらのポリシーも必要で、設定だけ揃えればよい	「例外対応」の意図がある場合は、例外側の設計を見直す
片方のプロファイルから該当項目を削除する	競合している設定項目だけを外す／未構成にする	同じ設定を複数プロファイルに入れてしまった重複の整理	削除後に代替が残っているか（“抜け”）を確認する
割り当て（含む／除外）を見直す	片方に除外グループを入れる／対象グループを分割する	部署別・端末種別などで設定を分けたい	グループが重複すると再発するので、ルールを明文化する

判断のコツ：ベースライン vs 例外を“役割”で分ける

競合を起こしやすい環境ほど、ポリシーが「なんとなく増えている」状態になりがちです。おすすめは、役割を次の 2 種類に分ける考え方です。

• ベースライン（標準）：全社標準の基本設定を集約。基本は 1 本（または少数）に寄せる。
• 例外（上書き）：例外が必要な項目だけを最小限で持つ。対象を狭く、項目を少なく。

競合が起きたら、「その設定はベースラインの責務か？例外の責務か？」でどちらを正にするか決めると、判断がブレにくくなります。

競合が起きやすい“ありがちな組み合わせ”と対策

Intune はポリシーの入口が複数あります。入口が違っても、同じ設定項目に触れることがあり、結果として Conflict が起きます。代表的なパターンを表にまとめます。

組み合わせ	例	なぜ起きる	対策
構成プロファイル同士	パスワード要件、アカウント ロックアウトなど	似た目的のプロファイルを複製して配布し、値が分岐	重複項目を統合、命名規則を整備
セキュリティ ベースライン vs カスタム設定	Defender、Firewall、ASR など	ベースラインも同じ領域を設定するため、別ポリシーで触ると衝突	ベースラインで触る領域は原則ベースラインに集約
設定カタログ vs 別の入口（テンプレート系）	同じ CSP を別画面から設定	入口が違っても同じ設定キーに書き込む	「設定の正本」を決め、同一項目は片方に寄せる
テスト用ポリシー vs 本番用ポリシー	テストで一時的に強めた値が残る	テスト端末が本番グループにも入ってしまう	テスト端末は明確に分離し、除外を徹底

現場で迷わない：競合特定から解消までの“最短フロー”

競合のトラブルシュートは、遠回りしない順序が大切です。おすすめの流れは次の通りです。

1. 対象デバイスを開き、構成プロファイルの一覧でConflictを探す
2. Conflict のプロファイルを開き、競合している設定項目をクリックして「どのプロファイル同士か」「値がどう違うか」を確定
3. デバイス画面で見えない／ダッシュボードが空なら、レポート（ポリシー構成の状態）で Conflict を一覧化
4. 修正方針を決める：値の統一／項目削除／割り当て分離
5. 同期→再確認。ダッシュボードではなく、デバイス画面とレポートで収束を確認

競合を減らすためのポリシー設計・運用のコツ（再発防止）

競合は「設定の増殖」と「責務の曖昧さ」から起きます。以下は、現場で効く再発防止策です。

ポリシーの命名規則を固定し、役割が一目で分かるようにする

• 例：BASE_（標準）、EXC_（例外）、TEST_（テスト）など接頭辞を付ける
• 例：BASE_Win11_Security、EXC_Kiosk_USB、TEST_ASR_Rules

名前だけで「これは標準」「これは例外」「これは触っていい範囲」が分かると、重複設定の混入が減ります。

「同じカテゴリの設定はできるだけ 1 つに集約」する

パスワード、BitLocker、Defender、Firewall など、カテゴリが明確なものほど分割しすぎると競合が増えます。例外が必要な場合は、例外ポリシーを増やすのではなく、例外の項目だけを最小限にして対象を限定する方が安全です。

割り当て設計を“重複させない”前提で作る

• 本番グループとテストグループを明確に分ける（端末が両方に入らない運用）
• 例外は「含める」より「除外」を使う方が分かりやすい場合が多い
• 部署別・端末種別で分けるなら、どのポリシーがどの端末に当たるかを表にして共有する

運用ドキュメントを“1 枚の表”にする（棚卸しに強い）

ポリシーが増えるほど、口頭共有や記憶に頼る運用は破綻します。おすすめは、最低限次の列を持つ管理表です。

ポリシー名	役割	主な設定領域	対象（含む）	除外	変更履歴メモ
BASE_Win11_Security	標準	パスワード、Defender、Firewall	All Windows 11 Devices	例外端末グループ	2025-xx 強化
EXC_Kiosk_USB	例外	USB 制御	Kiosk Devices	—	端末更改対応

運用チェックリスト（Conflict を起こさない／起きてもすぐ潰す）

チェック項目	頻度	ポイント
新しいポリシー作成時、既存ポリシーと設定領域が重複していないか	作成・変更の都度	同一カテゴリ（パスワード、Defender 等）は特に注意
割り当て（含む／除外）で、同一端末が複数スコープに入っていないか	作成・変更の都度	テスト端末が本番にも入る“二重所属”が最大の原因
レポート（ポリシー構成の状態）で Conflict を定期棚卸し	月次・四半期	ダッシュボードよりレポートで実態を掴む
ダッシュボードで Conflict が出たら、デバイス画面で設定項目まで掘る	発生時	「どの 2 つが」「何の設定で」ぶつかっているかを確定

よくある質問

Conflict は「どちらかが自動で優先」されないのですか？

少なくとも運用の観点では、Intune 上で「このポリシーを優先する」といった形で競合を解決できるケースは多くありません。Conflict が出たら、基本は同じ設定項目を 1 つに寄せる（または値を揃える）のが最も確実です。

「割り当ての失敗」が空なのは、故障ですか？

故障というより、集計画面の表示タイミングや条件によって「エラーっぽいが詳細に出ない」ことがあります。削除済みの古い情報が残っていたり、反映が追い付いていないケースもあるため、レポートとデバイス画面を優先して確認すると切り分けしやすいです。

競合の特定ができたら、最短での直し方は？

特定できた時点で勝ちです。次のいずれかを選び、必ず Conflict を消せます。

• 設定値を統一する
• 片方のポリシーからその設定項目を削除（未構成）にする
• 割り当てを分離し、同一端末が両方を受けないようにする（除外の活用）

今後、同じ問題を増やさないために一番効くことは？

ベースライン（標準）と例外（上書き）を分け、例外は項目数を最小限にすることです。加えて、命名規則と割り当てルール（テスト端末の扱いなど）を決め、棚卸しできる管理表を持つと、競合は大幅に減ります。