PCを校内で移動しただけなのに、SCCM（ConfigMgr）で端末が別コレクションに入り、別部署向けソフトが自動インストールされる――この現象は「勝手に移動」ではなく、端末がメンバー条件を満たした結果です。原因特定の手順と“誰がいつ何を変えたか”の追跡、Roles/Locationsの考え方を整理します。
まず理解しておきたい：コレクションは「所属先」ではなく「条件の集合」
SCCM（Microsoft Endpoint Configuration Manager / ConfigMgr）のデバイスコレクションは、端末を“どこかに移す箱”ではなく、条件に合う端末を自動的に集めるビューに近い仕組みです。多くの環境で「Windows 10 Computers」はOS条件で端末を集める広い母集団、「Music」は部署・教科・教室などの条件で端末を集める運用コレクションとして作られています。
重要なポイントは、端末は複数コレクションに同時所属できることです。端末が「Windows 10 Computersから消えた」のではなく、実際にはWindows 10 Computersにも残ったまま、Musicにも入っただけ、というケースがよくあります（結果として、Musicに紐づくRequired展開が走って“勝手に入った”ように見える）。
コレクションメンバーシップを決める仕組み
- クエリ ルール：端末の属性（OU、ADグループ、OS、命名規則、IPサブネット等）を条件に自動加入
- 直接メンバー（Direct Membership）：管理者が端末を手動で追加
- 包含（Include）/ 除外（Exclude）：他コレクションのメンバーを取り込む/弾く
見た目が「何も変更していないのに別部署向けソフトが入った」でも、実際は次のどれかで説明できることがほとんどです。
- 端末側の属性が変わり、Musicコレクションの条件に一致した
- Musicコレクション側（または包含元）の条件/包含関係が変更された
- 展開（Deployment）が別コレクションに向けて作成・変更された
- そもそもSCCM以外（GPO/手動/別ツール）で入った
| 現場の変化 | SCCMで変わり得るデータ | 起きやすいこと |
|---|---|---|
| 教室・棟の移動（VLAN/SSIDが変わる） | IPアドレス、IPサブネット、ADサイト、境界グループ（Boundary Group） | 場所条件のクエリに一致して部署別コレクションに加入 |
| 端末のOU整理（裏でOU移動） | System OU Name（AD System Discovery） | OU条件のクエリに一致して別コレクションに加入 |
| 端末を別部署のADグループへ追加 | System Group Name（AD Group Discovery） | グループ条件のクエリに一致してアプリが自動配布 |
| 端末名変更/再イメージ | 新規レコード生成、重複レコード、属性更新の遅延 | “同名の別端末”として扱われて意図しない展開が走る |
切り分け：その音楽系ソフトは本当にSCCM配布で入ったのか
まずは「SCCMが実行した」のか「別経路」なのかを確定します。学校環境は、GPO、手動インストール、端末ベンダーのマスター、Microsoft Store、Intune（共同管理）などが混在しやすく、決め打ちは危険です。
SCCMコンソールで“展開が存在するか”を確認する
- Monitoring > Deploymentsで、該当ソフト（アプリ/パッケージ/タスクシーケンス/ベースライン）の展開を探します。
- 見つかったら、目的がRequiredかAvailableか、対象コレクション、締め切り（Deadline）を確認します。RequiredでMusic系コレクションが対象なら、SCCM起因の可能性が高いです。
- 逆に、対象がユーザーコレクションだった場合は「誰がログオンしたか」で動くことがあります。デバイス展開なのかユーザー展開なのかも合わせて見ます。
インストール済みソフト一覧をSCCMで確認する方法
「その端末に何が入っているか」をSCCMで見る方法はいくつかあります。表示されるデータは多くの場合インベントリ（ハードウェア/ソフトウェア）に基づくため、リアルタイムではない点に注意してください。
| 方法 | コンソールの場所 | 強み | 注意点 |
|---|---|---|---|
| Resource Explorer | Assets and Compliance > Devices > 対象端末を右クリック > Start > Resource Explorer | 端末単位で「Installed Applications」「Add/Remove Programs」等を確認しやすい | インベントリ更新が遅いと古い情報が出る |
| レポート（Reporting） | Monitoring > Reporting > Reports（環境によりSSRS連携が必要） | 一覧性が高く、監査・記録向け | レポート名は環境で異なる／権限が必要 |
| Asset Intelligence（有効化している場合） | Monitoring配下の資産系ノード（環境により構成差あり） | 製品名の揺れを吸収して集計しやすい | 無効化されている環境もある |
クライアントログでの確認（端末側：最も確実）
「いつ・どの展開が・何をしたか」は端末側のログが決定打です。SCCMクライアントが入っている端末なら、通常はC:\\Windows\\CCM\\Logs配下にログがあります（閲覧にはCMTraceが便利です）。
| ログ | 主に分かること | 探すキーワード例 |
|---|---|---|
| AppEnforce.log | アプリ（Application）展開の実行・結果 | Application、Install、Exit code、Detection |
| AppDiscovery.log | 検出方法（既に入っているか）の判定 | Detected、Not detected、Discovery |
| ExecMgr.log | パッケージ（Package/Program）展開の実行 | Advertisement、Program、Run |
| CAS.log | コンテンツ取得（配布ポイントからのダウンロード）の要求 | Content、Location、DP |
| ContentTransferManager.log | コンテンツ転送の開始/完了 | CTM、Download、Completed |
| DataTransferService.log | BITS等を使った実際の転送 | BITS、Job、HTTP |
| PolicyAgent.log / PolicyEvaluator.log | 端末が受け取ったポリシーと評価 | Assignment、Policy、Evaluate |
| LocationServices.log | 境界グループ/コンテンツ場所（どのDPを使うか） | Boundary、Assigned、Distribution Point |
| smsts.log | タスクシーケンス実行（OS展開/イメージ適用） | Task Sequence、Step、Failed |
SCCMログに「該当ソフトの展開名」や「インストール開始/完了」が残っていれば、SCCM経由で入ったことがほぼ確定します。逆にログが見当たらない場合は、GPOや手動作業など別経路を疑って切り分けを続けるのが近道です。
原因特定：なぜMusicコレクションに入ったのか（メンバーシップ条件を特定する）
切り分けができたら次は本丸です。Musicコレクションの「メンバーになる条件」が分かれば、「なぜ入ったか」「どう直すか」を論理的に説明できます。
MusicコレクションのMembership Rulesを確認する
コンソールで Assets and Compliance > Device Collections からMusicコレクションを開き、Properties > Membership Rules（メンバーシップ ルール）を確認します。見るべき観点は次のとおりです。
- 直接メンバー（Direct）：対象端末が手動追加されていないか
- クエリルール（Query）：OU、ADグループ、IP/サブネット、命名規則など“移動で変わる要素”が条件に含まれていないか
- 包含（Include）：Windows 10 Computers 等の大きなコレクションを取り込む設定になっていないか
- 除外（Exclude）：本来除外されるべきコレクションが外れていないか（除外の取りこぼし）
- 制限コレクション（Limiting Collection）：意図した母集団に絞れているか（“全部端末”が母集団だと事故が起きやすい）
| ルール種別 | “勝手に入る”原因になりやすい例 | 移動・再配置で変わる？ | 対策の方向性 |
|---|---|---|---|
| クエリ（OU） | OU=MusicLab の端末を全て加入 | OUを移動すると変わる | OU運用が変わるなら、部署/用途を別属性（グループ等）へ |
| クエリ（ADグループ） | Music-Devices グループの端末を加入 | グループ付け替えで変わる | グループ運用を明確化（申請/承認/棚卸し） |
| クエリ（IP/ADサイト） | 10.20.30.0/24 や AD Site=MusicWing を加入 | 場所移動で変わる | 場所＝部署/用途ではない。配布目的と一致するか再検討 |
| Include | Windows 10 Computers を包含している | 端末側では変わらない | 包含チェーンを整理し、展開用コレクションは最小化 |
| Direct | 誰かが端末を手動追加 | 人が操作しない限り変わらない | 監査で操作ユーザーを追い、権限/手順を見直す |
端末を移動しただけで条件一致しやすい“罠”
- IP/サブネット条件：音楽棟のVLANに挿した瞬間、クエリ条件（IPサブネット等）を満たしてMusicに加入
- ADサイト条件：棟ごとにADサイトが分かれていると、端末が自動で別サイト扱いになる
- OU自動振り分け：スクリプトや運用で“接続場所”に応じてOUへ移動され、OU条件で加入
- 複数NIC/仮想NIC：無線/有線/VPNが混在し、インベントリ上は複数サブネットを持つ端末として条件に引っかかる
特に「複数NIC」は盲点になりがちです。一時的に接続したネットワークの情報がインベントリに残り、クエリに一致し続けることがあります。Musicコレクションがネットワーク条件ベースなら、対象端末のインベントリに“Music棟のサブネット”が残っていないかも確認してください。
“いつ入ったか”がズレる理由：Discovery/Inventory/評価のタイミング
端末が条件を満たしても、以下のタイミング次第で「加入時刻」や「インストール時刻」がずれることがあります。
- Active Directory System Discovery / Group Discovery の実行スケジュール
- ハードウェア インベントリの周期（IP/ネットワーク情報を条件にしている場合）
- コレクション評価（フル/増分）の周期
- 端末がオフラインでポリシーを受け取れていない
調査を急ぐ場合は、端末に対してClient Notification（クライアント通知）で「Machine Policy Retrieval」「Hardware Inventory」等を実行し、Musicコレクション側でUpdate Membershipを実行して評価を走らせると、因果関係が掴みやすくなります。
同名端末・重複レコードも疑う（“別端末がMusicに入っている”）
再イメージや端末入れ替えが多い環境では、SCCM上に同じ端末名のレコードが複数存在し、別レコードがMusicコレクションに入っているだけ、という事故も起きます。対象端末名で検索し、ResourceIDが複数ないか、Last Active Timeやクライアントの稼働状況が不自然でないかを確認してください。
監査：誰がいつ何を変えたのかを追跡する
「端末がMusicコレクションに入った」事実と、「誰かがコレクション設定を変えた」事実は別物です。監査で追えるのは主に管理者操作（ルール変更、直接追加、展開作成・変更など）で、クエリ結果として自動でメンバーが変化した場合は“変更者”が存在しないことも多いです。
まず見る場所：Status Message（監査系）
- Monitoring > System Status > Status Message Queriesから監査系のメッセージを検索します。
- 対象期間（端末移動日〜翌日など）で絞り、コレクション名（Music）や展開名、操作ユーザーで追い込みます。
深掘り：サイトサーバーのログで“操作の実体”を掴む
監査メッセージで足りない場合は、サイトサーバーのログも併用します。特にSMSProv.logはコンソール操作の痕跡が残りやすく、「誰が」「どの操作を」行ったかを詰められます。
| 証跡 | 場所 | 分かること | 向いている場面 |
|---|---|---|---|
| 監査ステータスメッセージ | Monitoring > System Status > Status Message Queries | 誰がいつオブジェクトを変更したか（作成/変更/削除など） | コレクションや展開が“いつ変わったか”を素早く知りたい |
| SMSProv.log | サイトサーバー：<ConfigMgrインストール>\\Logs | コンソール操作（WMI Provider経由）と実行ユーザー | 「その時間に誰が何を触った？」を深掘りしたい |
| colleval.log | サイトサーバー：<ConfigMgrインストール>\\Logs | コレクション評価の実行・所要時間・増分/フルの動き | “いつメンバーが再計算されたか”を掴みたい |
| クライアントログ（AppEnforce等） | 端末：C:\\Windows\\CCM\\Logs | いつインストールが走ったか（実行主体がSCCMか） | 「インストールは本当にSCCM？」を確定したい |
なお、OU移動やグループ変更が原因だった場合、SCCM側の監査だけでは「誰がOUを動かしたか」までは追えません。そのときはActive Directory側の監査（OU移動イベント、グループ変更イベント）も合わせて追うと、原因が一段早く特定できます。
Roles と Locations の違いを“誤解が起きない形”で整理する
現場で「Roles」「Locations」という言葉が出てくる場合、次の2つが混在しがちです。
- SCCMの公式用語としてのRole/Location（サイトシステムロール、境界/境界グループなど）
- 運用上の分類としてのRole/Location（端末の用途＝役割、端末の設置場所＝ロケーション）
どちらの意味で話しているかを揃えるだけで、事故の多くは防げます。
| 用語 | よく指すもの | 何が影響を受ける？ | 今回の現象との関係 |
|---|---|---|---|
| Roles（ロール） | （公式）サイトシステムの役割：MP/DP/SUP等 （運用）端末の用途：音楽室PC、職員室PC、授業用PC等 | 配布ポイント/管理ポイント/更新配信、端末の運用ポリシー | 「音楽系ソフトを入れる端末」をRoleで定義すると、場所移動でも影響が出にくい |
| Locations（ロケーション） | （公式）境界（Boundary）/境界グループ、ADサイト、IP範囲 （運用）棟/教室/フロアなどの設置場所 | DP選択、サイト割り当て、場所依存ポリシー | 「場所＝部署/用途」と誤って結び付けると、移動だけで別部署向け配布が走りやすい |
結論として、“部署別ソフト”をLocations（IP/ADサイト等）で配布対象にしてしまうと、端末の物理移動がそのまま配布事故につながります。校内移動が多い環境ほど、Role（用途）とLocation（場所）を分けて設計するほうが安全です。
再発防止：配布事故を起こしにくいコレクション設計と運用
原因が特定できたら、同じ事故が起きないように「仕組み」で潰します。おすすめの考え方は“配布先コレクションは小さく、条件は安定した属性で”です。
よく効く対策パターン
| 対策 | 狙い | 具体例 | 注意点 |
|---|---|---|---|
| 配布用コレクションを分離する | “部署別アプリ”の影響範囲を最小化 | 「Music-Deploy」コレクションを作り、そこにのみRequired展開 | Windows 10 Computers など大集合への展開は避ける |
| 条件をADグループなど安定属性へ寄せる | 場所移動で配布が変わらない | Music端末は「Music-Devices」ADグループで管理 | グループ運用（追加/削除）の責任分界が必要 |
| 除外コレクション（Do Not Install）を用意 | 誤加入しても配布を止める保険 | 「No-Music-Software」コレクションをExcludeに設定 | 除外が効く順序・包含チェーンを定期点検 |
| Requiredの乱用を減らしAvailableを増やす | 自動インストール事故を抑える | 教員が必要なときにSoftware Centerから導入 | 利用者教育とソフト管理ルールが必要 |
| アプリは“不要になったらアンインストール”を検討 | 誤配布時の被害を縮小 | Application展開で「no longer required でアンインストール」を有効化 | 共有端末では影響範囲を十分に検証してから |
「加入した瞬間に走る」を理解して展開設定を見直す
Required展開は、端末がコレクションに加入し、ポリシーを受け取り、コンテンツ取得が可能になると実行されます。校内で端末を持ち運ぶ環境では、次の設定が事故の火種になりやすいので見直し候補です。
- 締め切り（Deadline）が「できるだけ早く」になっている
- メンテナンスウィンドウ無しで昼間に実行される
- ユーザー通知が弱く、いつ入ったか分からない
- 配布先コレクションが場所（IP等）に紐づいている
すでに誤インストールが起きた場合の“後始末”
事故が起きた端末は、原因を直すだけでは元に戻りません。状況に応じて次の手当ても必要です。
- Applicationで配布している：展開設定に「不要になったらアンインストール」が無い場合は、アンインストール用のApplication/展開を用意する
- Packageで配布している：原則は自動アンインストールが無いので、アンインストールコマンドを別プログラムとして配布するか、手動対応を決める
- 端末をMusicコレクションから外したら、Machine Policy Retrievalを実行して不要なポリシーを早めに捨てさせる
すぐ現場で使える：調査フローとチェックリスト
同じ相談が来たときにそのまま使える「調査の順番」をまとめます。ポイントは端末側ログで事実を確定し、コレクション条件で原因を確定し、監査で運用改善につなげることです。
| やること | 成果物（分かったこと） | よくある次の一手 |
|---|---|---|
| 端末のCCMログで「SCCMがインストールした」証拠を掴む | 実行時刻、展開名、成功/失敗、配布ポイント | 該当展開がRequiredなら、配布先コレクションを見直す |
| Monitoring > Deploymentsで展開の対象コレクションを特定 | どのコレクション加入がトリガーか | MusicコレクションのMembership Rulesを精査 |
| MusicコレクションのMembership Rules（Query/Include/Direct）を特定 | “なぜ入るのか”の条件 | 場所条件ならRole条件へ移す、除外コレクションを追加 |
| 監査（Status Message / SMSProv.log）で変更者を確認 | 誰がいつルール/展開を変更したか | 権限設計、変更手順、レビュー運用を整備 |
- 端末移動が頻繁：Locations（IP/ADサイト）で部署別アプリ配布をしていないかを最優先で点検する
- 部署別ソフトが必須：ADグループ等で“対象端末”を明確化し、申請・棚卸しをセットで回す
- 誤配布の後始末が大変：Application化とアンインストール戦略（no longer required）を検討する
「なぜ入ったのか」をコレクション条件から説明できる状態にすると、現場への説明が一気に楽になります。加えて、監査で“誰がいつ何を変えたか”が追える体制を作ると、同じ事故の再発率が大きく下がります。
コメント