Microsoft Entra ID（Azure AD）Workdayプロビジョニングでmanagerを入社日まで空にできない理由と回避策

Workday から Microsoft Entra ID（旧 Azure AD）のプロビジョニングでオンプレ Active Directory に新入社員を自動作成していると、「入社日前は部署などの属性を空にしたい」という要件がよく出てきます。ところが manager（上長）だけは条件式が使えず、Microsoft 365 の組織図や連絡経路に早期露出してしまうことがあります。本記事では“なぜ起きるか”と“実務で効く回避策”を具体的に整理します。

前提：Workday → Entra プロビジョニング → オンプレ AD の「先行作成」運用で起きる課題

Workday を人事マスタとして、Microsoft Entra のプロビジョニング（Azure AD Provisioning）でオンプレ Active Directory に新入社員アカウントを自動作成できると、入社前の PC キッティング、ライセンス準備、各種システムの事前登録などがスムーズになります。

一方で、先行作成には必ず副作用が出ます。

入社日前に部署・役職・雇用区分などが確定していない（あるいは人事的に見せたくない）
入社日前に Microsoft 365 の検索・組織図・Teams の人検索に出て、周囲が連絡してしまう
上長（manager）が入っていることで、組織図のツリーに“いる前提”で表示されてしまう

このうち「属性を空にしておく」は、Entra の属性マッピングに条件式（式）を入れれば多くの属性で制御できます。しかし manager だけは同じ発想が通りません。

多くの属性は条件式で制御できるのに、manager だけできない理由

例えば「入社日（StatusHireDate）以降なら値を入れ、それ以前は空」を表現する式は、以下のような形で運用されることが多いです。

IIF(DateDiff("d", CDate([StatusHireDate]), Now())>=0, [SupervisoryOrganization], "")

部署・役職・拠点・社員番号のような“文字列や値そのもの”の属性は、上記のような式で「空にする／入れる」を切り替えやすいです。

ところが manager（上長）属性は、一般的な文字列属性とは違い「参照属性（referential attribute）」として扱われます。参照属性は、単に“値を入れる”のではなく、「別のオブジェクト（上長ユーザー）を参照するリンク」を構成する属性です。

分類	例	式で空にできるか	理由
値属性（value attribute）	department、title、office、employeeId など	多くは可能	最終的に「文字列/値」を書き込むだけで成立するため
参照属性（referential attribute）	manager（上長）	原則不可	別オブジェクト参照の解決（検索・紐付け）が必要で、式で空や条件分岐を前提にしていないため

参照属性は、プロビジョニングエンジン側で「この値は誰を指すのか」を解決しにいく設計です。ここに条件式を入れて一時的に空にしたり、タイミングで付け外ししたりすると、参照解決や更新順序、差分計算の整合性が崩れやすくなります。そのため、manager は仕様として“式で条件制御しない前提”で固定されがちです。

結論：manager を式で「空にする／遅延させる」はできない前提で設計する

ここが整理の出発点です。

manager は参照属性のため、属性マッピングの式で「入社日まで空」を作れない
なので「manager を遅延できない」前提で、目的（入社日前の露出抑制）を別の手段で満たす

以降は、現場で採用されやすい回避策を “目的別” に比較しながら紹介します。

回避策	狙い	強い場面	注意点
アドレス帳/GAL 非表示	検索や組織図への露出を抑える	M365 には同期するが「見せたくない」	組織図の出方は利用アプリ/導線で差が出る
クラウド同期の遅延（OU/フィルタ）	そもそも M365 に存在させない	入社前はオンプレだけで十分	入社日当日の自動切替設計が必要
manager を入社日に後追い設定	manager だけ別経路で設定	組織図に manager を出したくない	追加バッチ/自動化の運用コスト
Workday 側で出し分け	ソースで空を作る	Workday カスタムが可能	Workday 側の権限・設計・検証が必要
暫定の上長（窓口）を入れる	連絡先を“意図した先”に寄せる	どうしても manager が必要	暫定運用の説明責任と切替漏れ対策

回避策：入社日までアドレス帳（GAL）や検索導線で露出させない

「manager を空にできない」ことで困る本質が、“組織図に出てしまい、周囲が連絡してしまう”であれば、上長の参照そのものを遅延するのではなく、新入社員側を入社日まで見えにくくする設計が効きます。

代表的な考え方：入社日前は “アドレス帳に出さない” を真にする

Exchange / Microsoft 365 の利用形態によって制御点は変わりますが、実務的には以下のどれかを狙います。

環境	よく使う制御	例	コメント
オンプレ AD の属性で制御できる（ハイブリッド想定）	アドレス帳非表示フラグ	msExchHideFromAddressLists = TRUE	古典的だが分かりやすい。Exchange 運用と整合が必要
Exchange Online 側で制御する	HiddenFromAddressListsEnabled	入社日までは Hidden、入社日以降に Unhide	プロビジョニングとは別系統の自動化が必要になりがち
アプリや検索導線の露出抑制を重視	そもそも M365 に同期しない（次章）	OU/フィルタで遅延	最も確実。ただし “クラウドでの事前準備” とは相性がある

式で作るなら「非表示フラグ」を入社日で切り替える

manager は式にできなくても、非表示フラグは参照属性ではないため、入社日で切り替えが可能です。発想としてはこうです。

入社日前：非表示 = True（見えにくくする）
入社日以降：非表示 = False（通常表示）

入社日判定（StatusHireDate）を使った例：

IIF(DateDiff("d", CDate([StatusHireDate]), Now())>=0, "False", "True")

この式は「今日が入社日以降なら False（表示する）／それ以前は True（非表示）」という意味になります。ターゲット属性が真偽値の場合、環境によっては true/false、True/False、0/1 など期待値が異なるため、まずはテストユーザーでプロビジョニングログの“書き込み結果”を確認するのが安全です。

この回避策が効くポイント／効きにくいポイント

効くポイント：Outlook のアドレス帳検索、配布リスト探索、組織図導線（Outlook/People card）など「GAL 由来の見え方」を抑えられることが多い
効きにくいポイント：管理者や一部の検索導線ではユーザーが見えてしまうことがある（“完全に存在を消す” ではない）

つまりこの手段は、「入社日前の不用意な連絡を減らす」には効果が高い一方、セキュリティ的に“存在を秘匿する”目的には向きません。完全に消したい場合は、次の「同期自体を遅延」する設計が最も確実です。

回避策：入社日までクラウド同期を遅延させる（OU/フィルタで M365 に上げない）

入社日前に困ることの多くは、Microsoft 365 側（Entra ID / Exchange Online / Teams）にユーザーが存在することで起きます。ならば、入社日前は “オンプレ AD には作るが、クラウドには出さない”が王道になります。

最も分かりやすい設計：ステージング OU を作り、同期対象外にする

典型的には以下の構成です。

Workday → Entra プロビジョニングで、まずは ステージング OU（未同期 OU） にユーザーを作成する
Entra Connect（Azure AD Connect）や Cloud Sync の同期スコープから、その OU を外しておく
入社日になったら自動で 本番 OU（同期 OU） に移動する（スクリプト/自動化）

この方式のメリットは明確です。

入社日前は M365 に存在しないため、組織図・Teams・メール宛先などの露出が原理的に発生しにくい
manager 問題を“属性の工夫”ではなく “同期範囲” で解決できる
入社日後は OU 移動という単純操作で一気に同期できる

一方で、入社日前にクラウド側でやりたいこと（例：事前にメールボックスを作る、Teams を事前に触らせる、社外共有を先に組む）が多い場合は不向きです。運用設計で「何をどこまで先行するか」を整理してから採用すると失敗しにくいです。

OU 遅延方式での実装ヒント

プロビジョニング先 OU を固定しない：将来の運用変更に備え、Workday からの値（雇用区分や会社コード）で “作成先 OU” を分岐できる設計にしておくと後が楽です
OU 移動のトリガーを明確に：入社日当日の早朝に実行する、勤務開始の数時間前に実行するなど、社内の実態に合わせる
同期のタイムラグを吸収：OU 移動 → 同期 → Exchange/Teams 反映には時間差があるため、必要なら入社日当日の手順書に“見えるまでの目安”を含める

この方式は、manager の参照属性制約に左右されず、露出抑制として最も安定します。「入社日前に組織図に出て困る」が主訴なら、優先度高く検討する価値があります。

回避策：manager は入社日に“後追い更新”する（別経路でセットする）

「部署などは式で空にできる。問題は manager だけ。」という場合、manager マッピングを外して、入社日後に別の仕組みで manager をセットするのが、実務上かなり現実的です。

設計のコツ：manager 情報は“どこかに保持”しておく

manager を入社日後に設定するには、入社日前の時点で「本来の上長が誰か」を後から参照できる必要があります。おすすめは以下です。

Workday の ManagerReference（上長の識別子）を、AD の参照属性ではなく 文字列属性（例：extensionAttribute など）に一旦格納する
入社日後のバッチで、その値を使って上長ユーザーを検索し、manager（参照）としてセットする

こうすると、参照属性制約を回避しつつ、Workday を唯一の真実（SSOT）として扱いやすくなります。

日次バッチのイメージ（オンプレ AD を更新する例）

PowerShell（例）としては、次のような流れが分かりやすいです。

入社日を過ぎたのに manager が空のユーザーを検索
extensionAttribute などに保持した “上長の識別子” から上長ユーザーを引く
Set-ADUser -Manager で参照を設定

$today = (Get-Date).Date

# 例：入社日を extensionAttribute10 に yyyy-MM-dd で保持している想定
#     上長のUPNを extensionAttribute11 に保持している想定
$targets = Get-ADUser -LDAPFilter "(&(objectClass=user)(!(manager=*))(extensionAttribute10=*))" `
  -Properties extensionAttribute10, extensionAttribute11

foreach ($u in $targets) {
  try {
    $hireDate = [datetime]::ParseExact($u.extensionAttribute10, 'yyyy-MM-dd', $null).Date
    if ($hireDate -le $today -and $u.extensionAttribute11) {
      $mgr = Get-ADUser -Filter "UserPrincipalName -eq '$($u.extensionAttribute11)'" -ErrorAction Stop
      Set-ADUser -Identity $u.DistinguishedName -Manager $mgr.DistinguishedName
    }
  } catch {
    # ログ出力や通知（例：上長が見つからない/日付形式が違う等）
  }
}

実際には、入社日や上長識別子をどの属性に格納するか、上長検索のキーを何にするか（社員番号、UPN、メール、Workday ID など）を、既存設計に合わせて決めます。

Graph API / Power Automate / Logic Apps で “Entra ID 側の manager” を更新する選択肢

オンプレ AD ではなく Entra ID 側の manager を直接更新したい場合、Graph API を使って上長参照（manager）を設定する運用も組めます。実装パターンとしては、以下が定番です。

入社日後の対象ユーザー一覧を作る（フィルタ条件：入社日、manager 未設定、アカウント有効など）
対象ユーザーの manager を Graph API で設定する
失敗（上長が存在しない、権限不足）をログ化し、差分だけ翌日に再試行

この方式の利点は、プロビジョニングの制約から完全に独立できる点です。欠点は、Graph の権限設計・監査・例外処理を運用として持つ必要がある点です。とはいえ「入社日を迎えたら必ず設定される」という性質を作りやすいので、安定志向の現場では採用されやすいです。

回避策：Workday 側で ManagerReference を入社日まで“出さない”ようにする

Entra 側で参照属性を条件制御できないなら、参照元（Workday）の出力を入社日まで空にするのが、思想として最も自然です。

Workday 側で実現できるかはテナント設計次第ですが、考え方はシンプルです。

入社日前：ManagerReference を空（または連携対象外）にする
入社日以降：ManagerReference を通常通り出力する

Workday は“効果日（Effective Date）”の概念を強く持つため、入社日前後での出し分けは、実装可能なことが多い領域です。ただし、Workday 側の統合仕様（どのフィールドを何の識別子で出すか）や、他システムへの影響（他の連携でも manager を使っている等）を踏まえ、Workday 担当やベンダーと一緒に設計するのが安全です。

最終手段：暫定の上長（オンボーディング窓口）を入れておき、入社日後に差し替える

どうしても参照属性として manager を事前に埋める必要がある（例：社内の承認経路やアプリが manager を必須にしている）場合、暫定対応として「オンボーディング窓口ユーザー」を manager にしておき、入社日後に実上長へ差し替える手があります。

この設計のポイントは、“連絡が発生しても困らない受け口” に寄せることです。現場で起きがちな「上長に入社前連絡が飛んでしまう」を回避しやすくなります。

項目	メリット	デメリット	向いているケース
暫定 manager（窓口）方式	参照属性制約を気にせず “何かしら” を入れられる	差し替え漏れが致命的。運用監視が必須	manager 必須の業務要件がある

差し替え漏れ対策としては、「入社日後なのに manager が窓口のまま」のユーザーを日次で検知し、通知する仕組みを必ず入れます。

実装時にハマりがちな落とし穴と対策

入社日判定の“日付ズレ”

Workday の入社日が日付（Date）で管理され、プロビジョニング側の Now() が時刻（DateTime）として評価される場合、タイムゾーンや日付境界で「想定より早く切り替わった／遅く切り替わった」が起きることがあります。

入社日前日の夜に “入社日扱い” になってしまう
入社日当日の朝なのに “まだ入社日前扱い” になってしまう

対策は、テストユーザーで境界時刻の挙動を確認し、必要なら「判定を日付単位に丸める」「実行スケジュールを早朝に固定する」などで吸収します。

上長がまだ存在しない／参照解決できない

manager は参照解決が必要なので、上長ユーザーがまだ AD 上に存在しない、あるいは検索キーが一致しないと、プロビジョニングエラーの原因になります。

上長を先に同期/作成する順序設計にする
後追い設定方式（別バッチ）に寄せる
上長識別子（メール/UPN/社員番号など）の正規化ルールを統一する

「非表示」にしたつもりが、別の経路で見えてしまう

GAL 非表示は万能ではありません。Outlook/Teams/社内アプリの検索は、参照するディレクトリや権限、検索導線によって見え方が変わります。

「確実に入社日前に見せない」が要件なら、OU/フィルタで同期自体を遅延する設計を第一候補にするのが安全です。

運用監視を入れないと“例外”で崩れる

入社日が変更された、内定辞退で取り消しになった、配属が直前で変わった、再雇用（Rehire）になったなど、人事イベントは例外だらけです。次のような検知を入れておくと、運用が安定します。

入社日を過ぎたのに非表示のままのユーザー
入社日を過ぎたのに manager 未設定のユーザー（後追い方式の場合）
入社日が未来なのに同期 OU にいるユーザー（OU遅延方式の場合）
辞退/取り消しのステータスなのに有効化されているユーザー

要件	おすすめ	理由	補足
入社日前は絶対に M365 に見せたくない	OU/フィルタでクラウド同期を遅延	存在しない状態にでき、最も確実	入社日当日の自動OU移動を必ず設計
入社前にクラウド準備もしたいが、露出は減らしたい	GAL 非表示 + 必要最低限の属性だけ同期	運用負荷を増やさず “連絡が発生しにくい” 状態に寄せられる	検索導線で見える可能性は残る
manager だけが問題で、他は式で制御できている	manager は後追い設定（バッチ/Graph）	参照属性の制約を回避しやすい	上長情報の保持先（extensionAttribute等）を決める
Workday 側の設計変更が可能	Workday 側で ManagerReference を出し分け	ソースで整合が取れ、下流がシンプルになる	他連携への影響を要確認

まとめ

Workday → Microsoft Entra のプロビジョニングで「入社日までは属性を空にしたい」という要件は、式（条件式）で多くの属性に対応できます。しかし manager は参照属性のため、同じやり方で“空にする／遅延させる”ことができません。

この制約を無理に突破しようとするよりも、

入社日までの露出を抑える（GAL 非表示など）
クラウド同期そのものを遅らせる（OU/フィルタ）
manager だけ別経路で入社日に後追い設定する（バッチ/Graph/PowerShell）
Workday 側で出力を出し分ける

といった設計に寄せる方が、結果として安定しやすく、監査や運用も回しやすくなります。自社の「入社前にどこまで準備が必要か」を整理し、最も破綻しにくいパターンを選ぶのが成功の近道です。

この記事を書いた人

佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

Microsoft Entra ID（Azure AD）Workdayプロビジョニングでmanagerを入社日まで空にできない理由と回避策

前提：Workday → Entra プロビジョニング → オンプレ AD の「先行作成」運用で起きる課題

多くの属性は条件式で制御できるのに、manager だけできない理由

結論：manager を式で「空にする／遅延させる」はできない前提で設計する