記事公開日
【Microsoft Entra】Cloud Syncの3つの設定メニュー ― スコープ フィルター・属性マッピング・式ビルダーの役割と設定手順
1. 本記事の目的とできること
オンプレのActive Directory（以下、AD）からMicrosoft Entra ID（以下、Entra ID）へユーザーやグループを同期するMicrosoft Entra Cloud Sync（以下、Cloud Sync）では、構成を作成すると、同期の動作を決める設定メニューがMicrosoft Entra管理センターに並びます。
ただし、既定のままでよいものと、自社の環境に合わせて設定しないと期待どおりに動かないものが混在しており、どこまで設定し、どう確かめればよいのかは画面を見ただけでは分かりません。
そこで、中心となるスコープ フィルター・属性マッピング・式ビルダーについて、判断から設定、反映の確認までを順に解説します。
読み終えたあとに分かるのは、次の3点です。
- 自社の要件に照らして、3つの設定メニューのうちどれを既定から変える必要があるかを判断できる
- 同期する範囲と、同期する属性の値を、自社の要件に合わせて設定できる
- 設定した内容が意図どおりに同期されるかを、自分で確認できる
掲載している画面と設定値は、2026年8月時点のMicrosoft Entra管理センターで確認したものです。
Cloud Syncの概要や、オンプレ側に配置するプロビジョニングエージェントの導入から構成の作成までは、別記事で画面つきで解説しています。構成をまだ作成していない場合は、先にこちらをご覧ください。
2. どの設定を変えるかを判断する：3つの設定メニューの役割
Microsoft Entra管理センターで「Entra ID」→「Entra Connect」→「クラウド同期」と開き、「構成」の一覧から対象の構成を選択すると、その構成の設定画面が表示されます。
3つの項目は、構成の設定画面の左メニュー「管理」配下に並んでいます。
やりたいことが「誰を」「どの属性へ」「どんな値で」のどれに当たるかで、開くメニューが決まります。
| 設定メニュー | 決めること | 設定が必要になる場面 |
|---|---|---|
| スコープ フィルター | 誰を同期するか（対象範囲） | 特定の組織単位（以下、OU）配下だけを同期したい／一部の部署で試したい／特定のOUだけをCloud Syncで扱う段階移行 |
| 属性マッピング | AD側のどの属性をEntra ID側のどの属性へ同期するか（対応づけ） | ADスキーマを拡張して追加した属性をEntra IDでも使いたい／全ユーザーに固定値を入れたい（例：usageLocation を JP）／Entra ID側で管理する属性を同期で更新させたくない |
| 式ビルダー | 同期する値をどう決めるか（加工・条件による振り分け） | AD側の値をそのままの形では同期できない／値に応じて同期する内容を変えたい |
このうちスコープ フィルターは同期の範囲そのものを決める設定のため、対象を絞る必要があるなら必ず設定します。残りの2つは、既定の設定で足りるなら変更する必要はありません。
なお、Microsoftが同期対象の既定属性を追加しても、既存環境には自動追加されません（属性マッピングに関する公式ドキュメント）。ターゲット属性のドロップダウンに出ている属性が、マッピングの一覧にもあるかを見て、ない場合は手動で追加します。
3. 同期する範囲を指定する：スコープ フィルター
既定では対象を絞り込まないため、範囲を絞る場合は、フィルターの種類を選んでから範囲を設定します。
3-1. フィルターの種類を選ぶ
フィルターの種類は次の3つです。1つの構成で選べるのはこのうち1つだけで、グループとOUを併用することはできません。
| 種類 | 対象範囲 | 主な用途 |
|---|---|---|
| すべてのオブジェクト | 対象を絞り込まない（既定値） | 対象を絞り込む必要がない環境 |
| 選択したセキュリティ グループ | 指定したグループの直接メンバー（入れ子のメンバーは含まない） | パイロット検証 （本番は非推奨） |
| 選択した組織単位（OU） | 指定したOU配下のオブジェクト | 本番運用の標準・段階移行 |
以下、セキュリティ グループで指定する方式をグループスコープ、OUで指定する方式をOUスコープと呼びます。グループスコープを本番で勧めない理由は、次の検証で確かめられます。
3-2. 検証：グループスコープでは入れ子のメンバーは同期されない
3階層のグループを用意して確かめました。
親グループ（TEST_GRP_SALES）には直接のメンバーと子グループ（TEST_GRP_SALES_1）を持たせ、子グループにはさらに孫グループ（TEST_GRP_SALES_1A）を持たせて、それぞれに1人ずつユーザーを所属させています。
検証に使ったAD側のグループ構成です。
親グループをスコープに指定して同期したあとの、Entra ID側のユーザー一覧です。作成されたのは、親グループの直接メンバーだけでした。
子グループのメンバーも、孫グループのメンバーも作成されません。「営業部」グループの中に「営業一課」グループが入っている構造では一課のメンバーは同期されず、グループの階層が深い組織ほど、意図せず同期から漏れる人が出ます。
⚠ 本番運用ではグループスコープを使わないこと：
入れ子のメンバーが同期されないうえ、大規模グループの同期にも制限があるため、公式ドキュメントでもグループスコープはパイロットシナリオ限定とされています。
本番運用ではOUスコープを使用してください。OUスコープであれば、グループの入れ子構造とは関係なく、指定したOU配下のオブジェクトが同期の対象になります。
3-3. 範囲を設定し、反映を確認する
- 「作業の開始」画面の「スコープ フィルターの追加」、または左メニュー「管理」配下の「スコープ フィルター」を選択します。
- フィルターの種類を選択します（「すべてのオブジェクト」／「選択したセキュリティ グループ」／「選択した組織単位」。違いは3-1の表を参照）。
- セキュリティ グループまたはOUを選んだ場合は、「オブジェクトの識別名」の欄に対象の識別名（以下、DN）を入力し、「追加」をクリックします。
- DNは、AD管理ツールで対象のOUまたはグループを右クリックし、「プロパティ」→「属性エディター」タブの distinguishedName で確認できます（例：OU=Sales,DC=contoso,DC=com）。
- 「保存」をクリックします。
- すぐに反映させたい場合は、構成の「概要」画面上部にある「プロビジョニングの再起動」（同期の再開）を実行します。
- 保存しただけでは即時反映されず、次回のスケジュール実行で反映されます。変更をその場で確認したい場面で実行します。
- 進行状況は、左メニュー「モニター」配下の「プロビジョニング ログ」で確認できます。
「選択した組織単位」を選び、OUのDNを入力した状態です。
手順5の「プロビジョニングの再起動」ボタンの位置です。
「プロビジョニング ログ」は、左メニューの「モニター」配下にあります。
なお、4-5で使う「オンデマンドでプロビジョニング」にはスコープ フィルターが適用されず、スコープ外のユーザーでも実行できます。スコープの設定が正しいかどうかの確認には使えない点にご注意ください（オンデマンド プロビジョニングに関する公式ドキュメント）。
4. 属性の値を組み立てて同期する：協力会社の要員をゲストとして扱う
この章では、次の例に沿って、属性マッピングと式ビルダーの設定から反映の確認までを追います。
協力会社の要員のアカウントも自社のADで管理し、雇用区分をAD側の employeeType 属性に持たせている（協力会社の要員には Contractor が入っている）とします。この区分をもとに、Entra ID側のユーザーの種類（UserType）を Member と Guest に振り分け、ゲスト向けのポリシーの適用対象を分けたい、という場面です。
この UserType は、AD側に対応する属性が存在しないため、既定では同期の対象になっていません（UserTypeのマッピングに関する公式ドキュメント）。マッピングを追加しないかぎり、同期で作成されたユーザーはすべて Member として扱われます。
4-1. 属性マッピングを追加する
構成を作成した時点で一覧に入っている既定のマッピングに、新しいマッピングを追加します。
⚠ AD側に拡張属性を追加したら、エージェントを再起動すること：
AD側に新しい拡張属性を追加した場合は、プロビジョニングエージェントの再起動が必要です。再起動しないと新しい属性が検出されません（カスタム属性のマッピングに関する公式ドキュメント）。Entra ID側の拡張属性の場合は再起動は不要です。
- 左メニュー「管理」配下の「属性マッピング」を選択します。
- 画面上部で対象のオブジェクトの種類（「ユーザーまたは InetOrgPersons」／「グループ」／「連絡先」）が正しいか確認します。
- 「属性マッピングの追加」をクリックし、「マッピングの種類」を選択します（違いは次の表を参照）。
- 種類に応じた入力欄を埋め、「このマッピングを適用」で適用タイミングを選択します（「常に」＝作成時と更新時の両方／「作成時のみ」＝ユーザー作成時だけ）。
画面上部のタブで、対象のオブジェクトの種類を切り替えます。
マッピングの種類とターゲット属性を指定する画面です（設定例を入力した状態）。
マッピングの種類は次の4つです。
| 種類 | 動作 |
|---|---|
| 直接 | AD側の属性値をそのまま入れる |
| 定数 | 指定した固定文字列を入れる |
| 式 | 式の結果を入れる（値は式ビルダーで組み立てる） |
| なし | Entra ID側の属性を更新しない |
値を加工せずにそのまま同期するだけなら「直接」を選び、ソース属性とターゲット属性を指定します（例：AD側の department をEntra ID側の department へ）。
今回の設定例では、次のように入力します。
| 入力欄 | 設定値 |
|---|---|
| マッピングの種類 | 式 |
| ターゲット属性 | UserType |
| このマッピングを適用 | 常に（作成時だけ振り分けるなら「作成時のみ」） |
既存ユーザーを途中からゲストに変えると、ゲスト向けの制限やポリシーの適用対象が変わります。既存ユーザーを含めて適用する場合は、影響範囲を確認してから「常に」を選んでください。
4-2. 式ビルダーで値を組み立てる
式ビルダーは、関数の構文をGUIで組み立て、適用前にテストできるツールです（式ビルダーに関する公式ドキュメント）。
⚠ UserTypeに Member と Guest 以外の値を渡さないこと：
UserType が受け付けるのは Member と Guest の2つだけです。それ以外の文字列を渡すと反映されないため、値の組み立てはこの2つに収まるようにします。
今回は、employeeType が Contractor のユーザーだけを Guest、それ以外を Member にするため、値が複数の候補に分かれる場合に使う Switch 関数を選びます。
- マッピングの編集画面で「式ビルダーを使用する」をクリックします。
- ドロップダウンから関数（今回は Switch）を選択します。
- 引数に対応した入力欄が表示されるので、次の表のとおりに埋めます。
- 「式の追加」をクリックします。
関数を選ぶと、「関数シグネチャ」に引数の並びが表示されます。
値を入れる欄には個別のラベルが付かないため、関数シグネチャの並びを見て、どの欄が何に当たるかを判断します。
| 入力欄 | 設定値 |
|---|---|
| ソース属性 | employeeType |
| default Value （一致しなかった場合の値） |
Member |
| key（比較する値） | Contractor |
| value（一致したときの値） | Guest |
Switchは2番目の引数が既定値で、そのあとにキーと値の組が続きます。区分が増えた場合は「別の値を追加」で組を足します（式と関数に関する公式ドキュメント）。
「式の追加」をクリックすると、入力欄に次の構文が組み立てられます。
Switch([employeeType], "Member", "Contractor", "Guest")
4-3. 式をテストして適用する
- 属性とテスト値を入力して「式のテスト」を実行し、「式の出力の表示」で期待どおりの値が返ることを確かめます。
- 問題なければ「式の適用」をクリックして、エージェント構成（クラウド側に保持されている構成）に反映します。
属性に employeeType、値に Contractor を入れて「式のテスト」を実行した結果です。「式の出力の表示」に Guest が返っています（値を空にすれば Member が返ります）。
4-4. スキーマを保存する
「適用」をクリックして属性マッピングの一覧に戻り、「スキーマの保存」を実行します。スキーマの保存を忘れると設定が反映されません。
保存すると、ターゲット属性 UserType の行に、組み立てた式がソース属性として表示されます。
4-5. 反映を確認する
今すぐ反映を確かめたい場合は、「オンデマンドでプロビジョニング」で対象ユーザーを1人指定して即時にテストします。緑のチェックマークが表示されれば、そのユーザーへの反映は成功です。保存直後はスケジュール実行による反映がまだのことがあるため、運用同期に進む前にこの方法で確かめておくと確実です。
反映されたかどうかは、Microsoft Entra管理センターのユーザー一覧にある「ユーザーの種類」列で確認できます。
employeeType に Contractor が入っていたユーザーがゲスト、値のないユーザーがメンバーになっていれば成功です。
なお、同じ振り分けはUPNのドメイン部分を見る方法でも実現できますが、ドメインの統合や社名変更で判定が崩れます。AD側に区分を持たせているのであれば、その属性を見るほうが安定します。
5. まとめ
Cloud Syncの構成を作成したあとに設定する、スコープ フィルター・属性マッピング・式ビルダーの3つのメニューについて、設定が必要かどうかの判断から反映の確認までを見てきました。
同期する範囲はスコープ フィルター、値の加工や振り分けは属性マッピングと式ビルダー、と役割で分けて考えることで、既定のままでよい部分と手を入れるべき部分を見極めやすくなります。とくにグループで範囲を指定する場合は、入れ子のメンバーが同期されない点にご注意ください。
設定に慣れてきたら、式ビルダーでSwitch以外の関数を試してみるのもおすすめです。文字列の置換や複数属性の連結を使えば、AD側に残っている表記ゆれを整えてから同期することもできます。
ADスキーマを拡張して追加した独自の属性も、同期しておけば動的メンバーシップグループの条件として活用できます。
自社の要件に合わせて、少しずつ設定を広げてみてください。
弊社では、ID管理に関する他の記事も公開しています。
ご興味のある方は、ぜひこちらもあわせてご覧ください！
QUICK E-Solutionsでは、各種Microsoftソリューションを活用した業務効率化・システム導入のお手伝いをしております。
それ以外でも 様々なアプリケーションの開発・導入を行っております。提供するサービス・ソリューションにつきましては こちら に掲載しております。
システム開発・構築でお困りの問題や弊社が提供するサービス・ソリューションにご興味を抱かれましたら、ぜひ一度 お問い合わせ ください。
※このブログで参照されている、Microsoft、Microsoft Entra、Microsoft Entra ID、Microsoft Entra Cloud Sync、Active Directoryは、米国Microsoft Corporationの米国およびその他の国における商標または登録商標です。
