オンプレミスのActive DirectoryとMicrosoft Entra IDをEntra Connect Syncで同期し、人事システム連携で入退社のアカウント処理を回している数千人規模の企業。そのID基盤担当者にとって、2026年9月30日は業務が止まるかどうかの分かれ目になる。Microsoftはこの日を期限に、AD からEntra IDへ同期するための第一者アプリケーションを導入するセキュリティ強化を実施する[1]。対象はMicrosoft Entra Connect Sync（オンプレADのユーザーやグループをEntra IDへ同期するオンプレ設置型のコンポーネント）で、必要バージョンは v2.5.79.0 以上である[1]。
公式ドキュメントの記述は明快で、期限を過ぎると「All synchronization services in Microsoft Entra Connect Sync will fail」、つまり全同期サービスが失敗するとある[1]。本稿の公開時点で残りは約5週間であり、この期間にバージョン確認、変更申請と停止時間の確保、アップグレード実施を通す必要がある。今回だけ上げるのか、自動アップグレードを有効にするのか、クラウド側の同期方式へ移るのかという中期の判断も同時に発生する。本稿はこの二層の意思決定を、日本企業の変更管理の実態に合わせて整理する。
予備知識
- Entra Connect Sync: オンプレADの利用者情報をEntra IDへ同期する、社内サーバーに入れて動かすソフトウェア。旧称はAzure AD Connect。
- サービスプリンシパル: 人ではなくプログラムがEntra IDにサインインするためのアプリ用アカウント。権限はこの単位で与える。
- 自動アップグレード: Connect Syncが更新版を検知して自動で入れ替える機能。
- Cloud Sync: サーバー設置型に代わり、軽量エージェント経由でクラウド側から同期を制御する新しい同期方式。
オンプレADとの同期を含めてEntra IDの構成要素を一通り確認したいID基盤担当者向け。
Entra Connect Syncの2026年9月30日の変更で何が変わるのか
変更の中身は、AD からEntra IDへの同期に使う認証の主体を、新しく導入される第一者アプリケーションに移すことである[1]。
新しいサービスプリンシパル名は Microsoft Entra AD Synchronization Service、Application ID は 6bf85cfa-ac8a-4be5-b5de-425a0d0dc016 である[1]。これはMicrosoft Entra管理センターのエンタープライズアプリケーションの一覧に表示される[1]。管理者がアプリ登録を行う作業ではなく、テナントに現れる第一者アプリを同期処理が利用する形になる。
旧バージョンが失敗するのは、この同期用アプリケーションを前提とした動作に対応していないためである。v2.5.79.0 以上へ上げることが、公式ドキュメントが示す対応策になっている[1]。
影響範囲はMicrosoft Entra Connect Sync に限られる[1]。ファイアウォール規則、通信先エンドポイント、権限要件の変更についても記載がない[1]。記載がないことと変更がないことは別なので、検証環境での事前確認は段取りに含めておく。
同期元となるオンプレAD側の設計と運用を、引き継ぎ前提で読み直したい担当者向け。
Entra Connect Syncの同期が止まると業務と内部統制に何が起きるか
同期の停止は「クラウドが使えなくなる」ではなく「ADで行った変更がクラウドに届かなくなる」という形で現れる。
もっとも早く表面化するのは入社処理である。人事システムからADにアカウントを作っても、Entra IDに反映されない限り、Microsoft 365もクラウド業務アプリも使えない。初日から端末にサインインできない新入社員が発生する。
次に効くのがパスワード変更である。パスワードハッシュ同期を使っている環境では、オンプレ側で変更した認証情報がクラウドに伝わらず、利用者は古い認証情報のまま取り残される。ヘルプデスクへの問い合わせが個別対応として積み上がる。
統制の観点でより重いのは退職者の無効化である。ADで無効化した退職者アカウントがEntra ID側で有効なまま残れば、クラウドサービスへのアクセスが残存する。これは業務の不便ではなく、アクセス権限管理の不備として監査で指摘される事象になる。
気づきにくい点も見落とせない。利用者からは既存サービスが動き続けるため、障害として通報されにくい。実害が出てから遡って原因を特定する流れになりやすい。
複合機のスキャン送信連携や会議室予約システムなど、Exchange Web Services（EWS、旧来のメール連携API）経由でメール機能を呼び出す社内システムを何年も運用してきた、数千人規模の企業の情報システム部門にとって、2026[…]
残り5週間でEntra Connect Syncのアップグレードを変更管理に通す段取り
最初にやることはバージョン確認であり、これは変更申請なしで今日できる。
Connect Syncサーバーで現行バージョンを確認し、v2.5.79.0 未満であれば対応対象になる[1]。ステージングサーバーを持つ冗長構成なら、そちらも同じ確認が要る。確認結果が対象なしで終われば、以降の稟議は不要になる。
次に前提条件の確認である。公式ドキュメントは .NET Framework 4.7.2 がインストール済みであること、TLS 1.2 が有効であることを求めている[1]。数年前に構築したまま更新していないサーバーでは、この二つが未充足のまま止まる可能性がある。前提条件の充足自体がOS側の変更申請を要する場合、残り5週間に余裕はない。
インストーラの入手経路にも指定がある。Microsoft Entra管理センターのMicrosoft Entra Connectセクションからのみ取得するよう明記されている[1]。社内の共有フォルダに残る過去のインストーラを流用する運用は、この指定に反する。
段取りは、8月中に確認、9月上旬に変更申請と停止時間の確保、9月中旬に検証環境、9月下旬に本番という逆算になる。停止時間そのものは長くないが、承認に要する日数が支配的になる。
数百〜数千人規模で社内向けAIチャットボットやエージェントをAzure OpenAI Assistants API（会話履歴やツール呼び出しの状態管理をAzure側が肩代わりするAPI）上に構築し、内部統制上の変更管理プロセスを経て本番投[…]
今回限りの更新か、自動アップグレードか、Cloud Sync移行か
期限対応と並行して、このサーバーを今後どう扱うかという中期の判断が発生する。
選択肢は三つある。今回だけ手動で上げる、自動アップグレードを有効にする、Cloud Syncへ移行する。v2.3.20.0 以上であれば自動アップグレードを有効化できる。ただし公式の記述は、対応する構成において随時アップグレードを実施するというもので、常に自動で最新版になることを保証してはいない[1]。Microsoftは対象顧客に対し、クラウド側から動作する新しい同期クライアントであるMicrosoft Entra Cloud Syncへの移行を推奨している[1]。
| 選択肢 | 今回の作業量 | 次回以降 | 向く組織 |
|---|---|---|---|
| 今回限りの手動更新 | 最小 | 期限のたびに同じ作業と稟議が発生 | 変更を都度承認する統制を最優先する組織 |
| 自動アップグレード有効化 | 手動更新＋設定変更 | 対応構成なら個別の更新作業が減る（全件保証ではない） | 更新遅延のリスクを人手より仕組みで抑えたい組織 |
| Cloud Syncへ移行 | 最大（適用可否の判定を含む） | サーバー維持とバージョン管理から解放される | オンプレサーバーの塩漬けを解消したい組織 |
Cloud Syncはオンラインで管理でき、将来の移行作業を避けられる[1]。ただし全環境がそのまま移れるわけではなく、適用可否はサポートされる同期シナリオの比較表で判断する[1]。9月30日までにこの判定と移行を終えるのは現実的ではない。
実務上の順序は、まず期限対応としてv2.5.79.0以上へ上げ、Cloud Syncへの移行判断は期限後の課題として別に立てる形になる。自動アップグレードの有効化だけは今回の作業と同時に決められる。
日本企業のID基盤でEntra Connect Sync更新が遅れる構造的な理由
同じ期限が来ても、日本企業では技術作業より前段の手続きが所要時間を決める点が異なる。
第一に、Connect Syncサーバーが構築者不在のまま動き続けている例が多い。導入をSIerに委託し、保守契約が監視と障害対応の範囲にとどまる場合、バージョン更新は契約範囲外の追加作業として見積もり取得から始まる。筆者の経験では、見積もりと発注の往復だけで2〜3週間が消えることが多い。
第二に、停止時間の確保に事前申請が要る。ID基盤は全社サービスの前提であり、短時間でも計画停止として周知期間を求められる。月次のリリース枠が決まっている組織では、9月の枠を逃すと期限に間に合わない。
第三に、自動アップグレードを変更管理の観点で嫌う文化がある。承認を経ない構成変更は統制上の例外とみなされ、有効化そのものが別の稟議になる。
| 論点 | 一般的な想定 | 日本の大企業でよくある実態 |
|---|---|---|
| 更新作業の実施主体 | 社内担当が即日実施 | SIerへの見積もり・発注が先行 |
| 停止時間の確保 | 業務時間外に随時 | 事前申請と月次リリース枠に従う |
| 自動更新の扱い | 有効化が既定の選択 | 無承認の構成変更として敬遠される |
IT部門の判断は、技術作業の所要時間ではなく承認の所要日数から逆算して着手日を決めることである。決裁側の判断は、9月の変更枠を一つこの対応に確保し、必要な追加発注を先に承認しておくことである。
よくある質問（FAQ）
Q. 自社が対象かどうかはどこを見れば分かりますか。
Connect Syncサーバーの現行バージョンです。v2.5.79.0 未満なら対象、それ以上なら今回の期限対応は不要です[1]。
Q. インストーラは手元にある過去のものを使ってよいですか。
Microsoft Entra管理センターのMicrosoft Entra Connectセクションから入手するよう指定されています[1]。旧インストーラの流用は避けてください。
まとめ
押さえるべき点は、期限を過ぎたときに性能が落ちるのではなく全同期サービスが失敗する、という記述の強さである[1]。なお公式は、期限に間に合わなかった場合でも最新版へ上げれば機能は復旧するとしている。ただし9月30日からアップグレード完了までの間は、全同期が失敗したままになる[1]。ID同期の停止は入社・退職・パスワード変更を同時に止め、業務の停滞と統制の不備を並行して発生させる。しかも利用者からは見えにくく、通報されないまま進行する。
IT部門担当者の次の一手は、稟議より先にバージョン確認を済ませることである。v2.5.79.0 以上なら今回の対応は不要、未満なら .NET Framework 4.7.2 と TLS 1.2 の充足確認まで一気に進める[1]。ここまでは変更申請なしで今日から着手できる。
決裁側の判断材料は三点になる。費用は既存サーバーのアップグレードであればSIerへの作業委託費が主になる。リスクは全社のID同期停止で代替手段がなく、時期は9月の変更枠が事実上の最終期限になる。Cloud Syncへの移行は方向として推奨されているが[1]、残り5週間で判断する話ではない。期限対応と中期方針を分けることが、この5週間を乗り切る前提になる。
