Office Deployment Tool で Microsoft 365 Apps を展開している管理者なら、2026年4月20日の更新で最初に押さえるべき結論は一つです。Office Deployment Tool(ODT)16.0.19929.20062 で Tenant Association Key(TAK)対応が追加されたため、今回の確認範囲は setup.exe の差し替えだけでは足りません。TAK の扱い、Cloud Update / Inventory / OneDrive Sync Health との整合、既存ポリシーとの優先順位までまとめて見直す必要があります。(Microsoft Learn)
TAK はライセンスキーではなく、デバイスをテナントに関連付けるためのキーです。ここを曖昧なまま進めると、「管理画面に端末が出ない」「反映が遅い」「キー再生成で既存端末との通信が一時的に切れる」といった運用事故につながります。この記事では、導入前確認、設定差分、周知項目、展開順序を、そのまま使える管理者向けチェックリストとして整理します。(TECHCOMMUNITY.MICROSOFT.COM)
Office Deployment Tool / Microsoft 365 Apps で2026年4月20日に変わったこと
Microsoft の ODT リリース履歴では、2026年4月20日公開の ODT 16.0.19929.20062 に「Tenant Association Key のサポート追加」が記載されています。Download Center でも同バージョンが 2026年4月20日公開として案内されており、配布パッケージは自己展開形式で setup.exe とサンプル XML を含みます。Microsoft は ODT 利用時に最新バージョンの使用を推奨し、構成 XML の作成や更新には Office Customization Tool の利用も案内しています。(Microsoft Learn)
今回の差分確認は、XML の1行だけを探す作業ではありません。実務では、次の5項目をそろえる作業だと考えると整理しやすくなります。
- ODT の実ファイルが最新版か。
configuration.xmlをどのツールで生成しているか。- TAK の現行値と生成責任者が明確か。
- Cloud Update / GPO / ODT のどれが更新設定の正本か。
- 管理画面へ反映されるまでの待ち時間を運用に織り込んでいるか。
影響を受ける環境を先に切り分ける
| あなたの環境 | 優先度 | まず確認すること |
|---|---|---|
| Cloud Update / Inventory をすでに利用中 | 最優先 | TAK の現行値、更新制御の優先順位、pilot 対象端末 |
| OneDrive Sync Health を利用中 | 高 | TAK の有無、EnableSyncAdminReports への統一、反映待ち時間 |
| ODT で配布のみ運用中 | 中 | ODT 更新、XML 再生成、今後の標準手順化 |
| GCC / GCC High / DoD / 21Vianet を含む | 別判定 | commercial tenant 前提の手順をそのまま適用しない |
この切り分けが重要なのは、Cloud Update と Inventory が commercial tenant 向けの対象サービスで、21Vianet / GCC / GCC High / DoD は対象外だからです。一方で OneDrive Sync Health では GCC / GCC High / DoD は TAK 不要とされています。つまり、commercial tenant で Microsoft 365 Apps の管理機能をすでに使っている組織ほど、今回の ODT 差分を急いで確認すべきです。(Microsoft Learn)
権限は Office Apps Administrator を軸に割り当てるのが現実的です。Cloud Update、Inventory、OneDrive Sync Health の各ドキュメントでもこのロール、または Microsoft 365 Administrator / Global Administrator が案内されていますが、日常運用まで Global Administrator に寄せる必要はありません。(Microsoft Learn)
導入前チェックリスト
配布基盤の確認
- ODT を 16.0.19929.20062 以降へ更新します。管理端末の手元だけでなく、共有フォルダの原本、Intune や Configuration Manager のパッケージ原本、VDI やゴールデンイメージ作成スクリプトに入っている
setup.exeの所在も洗い出します。古いsetup.exeが残ると、環境ごとに挙動が割れます。(Microsoft Learn) - 長年使い回した手書き XML があるなら、今回は最新 ODT または Office Customization Tool を起点に構成を再生成し、現行 XML と差分比較します。今回のように ODT 側で新しい対応が入ったタイミングでは、「古い XML は動くが最新の意図を反映していない」状態が起きやすいからです。(Microsoft)
- 切り戻しを考えるなら、旧パッケージをすぐ消さず、pilot 完了までは「旧 ODT」「新 ODT」のどちらで作った配布物か識別できるようにしておきます。運用現場では、このラベル管理があとで効きます。
権限・テナントの確認
- Cloud Update / Inventory を使う予定があるなら、対象テナントとライセンス条件を満たしているかを確認します。対象外環境に commercial tenant 前提の設計を流用しないことが重要です。(Microsoft Learn)
- OneDrive Sync Health を扱う場合は、OneDrive 同期アプリ 22.232 以降かどうか、設定担当者に必要な管理ロールがあるかを確認します。(Microsoft Learn)
- Apps admin center の Setup 画面で TAK を確認・生成できる担当者を決めます。「見られる人はいるが責任者がいない」状態にしないことが、再生成事故の防止につながります。(Microsoft Learn)
ネットワーク到達性の確認
- commercial tenant の Inventory / Cloud Update では
*.office.com、*.office.net、*.config.office.com、*.config.office.net、login.live.comへの到達性が必要です。OneDrive Sync Health ではhttps://clients.config.office.netも確認します。(Microsoft Learn) - pilot 端末だけプロキシや VPN セグメントが違うと、「検証機では成功したのに本番帯では失敗した」という典型的な事故になります。できるだけ本番に近いネットワーク帯で最初の確認を行います。(Microsoft Learn)
既存運用の棚卸し
- Cloud Update を使う、または今後使うなら、既存の GPO、Intune、Configuration Manager、ローカル レジストリ、ODT のどれが更新元になっているかを先に書き出します。Cloud Update 管理下のデバイスでは、他の Microsoft 365 Apps 更新構成を無視する動作があるため、複数の管理方式を重ねたまま pilot すると原因切り分けが難しくなります。(Microsoft Learn)
- Cloud Update の対象設計では、除外グループも先に決めます。Microsoft のガイダンスでも、Remote Desktop Service Hosts や non-persistent VM は除外対象としてよく挙げられています。(Microsoft Learn)
- 過去に Serviceability Manager や ConfigMgr ベースの TAK 補修スクリプトを使ったことがある環境では、そのまま削除しません。まずは「どの端末に残っているか」「何を書き込む設計か」を棚卸しし、pilot で不要と確認できてから段階的に外します。(TECHCOMMUNITY.MICROSOFT.COM)
設定・検証チェックリスト
TAK の確認
- Apps admin center の Setup で TAK の有無を確認します。空欄なら Generate new key で生成でき、初回生成は最大 30 秒ほどかかることがあります。(Microsoft Learn)
- 既存値があるのに安易に再生成しない ことが重要です。Microsoft の onboarding guidance では、すでに関連付け済みのデバイスがある状態で新しい TAK を生成すると、既存端末との通信が一時的に失われる可能性があると説明しています。再生成は、欠落時や計画的なローテーション時だけに絞るべきです。(TECHCOMMUNITY.MICROSOFT.COM)
- 変更管理を重視する組織では、TAK 再生成を通常運用ではなく変更作業として扱います。Microsoft 365 の監査スキーマには Cloud Update の tenant configuration と TAK の項目が定義されています。(Microsoft Learn)
OneDrive Sync Health を使う場合
- Intune では、設定カタログから Enable sync health reporting for OneDrive と Sync Admin Reports を有効にし、TAK を貼り付けます。(Microsoft Learn)
- GPO またはレジストリで設定する場合は、古い
SyncAdminReportsではなくEnableSyncAdminReportsを使います。旧設定は現在のドキュメントで非サポートです。(Microsoft Learn) - 検証は小さく始めます。Microsoft は、最初は少数のテスト端末、その後は 1 日 100 台規模、そこから段階的に 10,000 台まで広げる進め方を案内しています。レポート反映には最大 3 日かかることがあるため、即日で全台判定する前提にしないことが大切です。(Microsoft Learn)
- 「当日見えない = 失敗」ではありません。Sync Health の最終状態は約 36 時間ごと、またはクライアント起動後およそ 1 時間で更新されるため、端末をサインインしたまま稼働させて待つ時間を運用計画に含めます。(Microsoft Learn)
Inventory / Cloud Update を使う場合
- Inventory をまだ有効化していないなら、先に inventory setup を完了させます。ドキュメントでは、サポート対象アプリを起動したデバイスは 1 時間以内に表示されるとされ、Microsoft の onboarding guidance では早ければ 1 分程度で見え始めるものの、初日は活動量に応じて台数が徐々に増えると説明されています。(Microsoft Learn)
- Cloud Update は Microsoft 365 Apps 向けの更新管理で、Current Channel と Monthly Enterprise Channel をサポートします。対象デバイスは Microsoft Entra グループで除外でき、管理下に入った端末では他の更新設定より Cloud Update の評価が優先されます。(Microsoft Learn)
- 大規模環境では、Cloud Update の設定変更や評価結果の反映に数時間かかることがあります。Inventory では Eligible for、Managed by、Not eligible、Onboarding、Excluded などの Cloud Update Status を見ながら、対象判定と管理移行の進み具合を追うと判断しやすくなります。(Microsoft Learn)
更新管理の主導権をそろえる
TAK 対応そのものより、実はここでつまずくケースが多いです。Microsoft 365 Apps の更新制御を複数の仕組みで同時に触っていると、「設定したのに効かない」が起きます。整理の仕方はシンプルで、どの仕組みを正本にするかを先に決める ことです。(Microsoft Learn)
- Cloud Update 管理下の端末 は Cloud Update を正本にします。他の Microsoft 365 Apps 更新構成は無視され得るため、GPO や Intune の古い更新設定を残したまま挙動比較しないほうが安全です。(Microsoft Learn)
- Cloud Update 管理外の端末 では、更新チャネル変更に関してポリシー設定が ODT より優先されます。「ODT で Current Channel にしたのに変わらない」というときは、まず GPO 側を疑います。(Microsoft Learn)
- 共有フォルダや Configuration Manager でチャネルを変える場合は、新しいチャネルの更新ソースが実際に配布されているか確認します。設定だけ変えても、対象チャネルのコンテンツが無ければ更新は進みません。(Microsoft Learn)
- チャネル変更を同時に行うなら、端末に Office Automatic Updates 2.0 スケジュール タスクが存在するかも確認します。(Microsoft Learn)
周知チェックリスト
技術設定と同じくらい大事なのが、誰に何をどう伝えるかです。特にヘルプデスク、展開チーム、変更管理チームの3者で認識がずれると、設定は正しいのに運用が崩れます。
ヘルプデスク向け
- TAK はライセンスキーではなく、テナント関連付け用のキーだと明確に伝えます。表示遅延だけでは障害判定しないよう、問い合わせテンプレートを更新します。(TECHCOMMUNITY.MICROSOFT.COM)
- OneDrive Sync Health は最大 3 日、Inventory は 1 時間程度、Cloud Update の評価は数時間かかることがあるため、「反映待ち」の目安を一次回答に入れます。(Microsoft Learn)
- 14 日以上 Office が使われていない休眠端末は TAK 関連付けが外れ、次回 Office 起動時に再取得される可能性があります。長期未使用端末を「壊れた端末」と即断しない運用にしておくと、無駄なエスカレーションを減らせます。(TECHCOMMUNITY.MICROSOFT.COM)
パッケージ / 展開チーム向け
- 最新 ODT を使ってパッケージを再作成し、どのリポジトリが正本かを一本化します。「部署Aは新
setup.exe、部署Bは旧setup.exe」を防ぐことが最優先です。(Microsoft Learn) - pilot ユーザーには、Microsoft 365 Apps と OneDrive にサインインし、Word や Excel を一度起動してもらう案内を入れます。これを省くと、管理画面に出ない原因が設定なのか、利用条件なのかを切り分けにくくなります。(Microsoft Learn)
変更管理 / セキュリティ向け
- TAK の生成・再生成は担当者、実施日時、理由を残します。監査観点では、Cloud Update の tenant / profile / device configuration に対応するイベント種別が定義されています。(Microsoft Learn)
- 古い TAK 補修スクリプトや baseline は、無断で撤去しません。「新方式の pilot 完了後に撤去」というルールを先に決めておくと安全です。(TECHCOMMUNITY.MICROSOFT.COM)
社内周知文のたたき台
2026年4月20日公開の最新 Office Deployment Tool で Tenant Association Key 対応が追加されました。今後の Microsoft 365 Apps 配布パッケージは最新版 ODT を基準に再作成します。pilot 期間中は TAK の再生成を行わず、対象ユーザーには Microsoft 365 Apps / OneDrive へのサインインと Office アプリ起動を依頼します。Inventory や Sync Health の反映には待ち時間があるため、同日中に管理画面へ表示されなくても直ちに障害扱いしません。
おすすめの展開順序
- まず、組織内にある ODT の所在を洗い出し、どの
setup.exeを正本にするか決めます。ここを曖昧にすると、その後の検証結果が比較できなくなります。(Microsoft Learn) - 次に、Cloud Update、Inventory、OneDrive Sync Health のどれを使っているかを切り分けます。Cloud Update を広げるなら、RDS ホストや non-persistent VM を除外するかもこの段階で決めます。(Microsoft Learn)
- Apps admin center の Setup で現在の TAK を確認し、既存値があるなら pilot 中は再生成しない方針を明文化します。(Microsoft Learn)
- 最新 ODT と最新の構成生成手順を使って pilot パッケージを作り、現行 XML との差分を記録します。配布物の再現性をここで確保します。(Microsoft)
- 少数のテスト端末から始め、問題がなければ段階的に広げます。OneDrive Sync Health のガイダンスでは、少数→100台/日→さらに拡大、という進め方が案内されています。(Microsoft Learn)
- 判定は、Inventory、Cloud Update Status、Sync Health の反映待ち時間を前提に行います。即時反映を前提に合否を出すと、正常な遅延を障害と誤認します。(Microsoft Learn)
- pilot で問題がなければ、本番展開に広げたうえで旧スクリプトや旧手順を整理し、周知文と運用手順書を更新します。先に設定、後から文書、ではなく、同じタイミングで更新するのが失敗しにくい進め方です。(TECHCOMMUNITY.MICROSOFT.COM)
失敗しやすいポイント
- 管理者 PC の ODT だけを更新して満足すること。実際には共有フォルダ、MDM、ConfigMgr、イメージ作成系に古い
setup.exeが残りやすいです。(Microsoft Learn) - 既存の TAK を「念のため」で再生成すること。既存端末との通信が一時的に切れる可能性があるため、最初にやる作業ではありません。(TECHCOMMUNITY.MICROSOFT.COM)
- Cloud Update と GPO と ODT を同時に触り、どれが勝っているかを見失うこと。管理下の端末では Cloud Update、チャネル変更ではポリシーが強く、ODT が常に優先されるわけではありません。(Microsoft Learn)
- OneDrive Sync Health で旧
SyncAdminReportsをそのまま使うこと。現行ドキュメントではEnableSyncAdminReportsが案内されています。(Microsoft Learn) - 反映を待たずに失敗判定すること。Inventory、Cloud Update、Sync Health はそれぞれ反映タイミングが違います。(Microsoft Learn)
- テスト端末にライセンス付きユーザーがサインインしておらず、Office アプリも起動していないこと。これでは関連付けや inventory 表示の確認が成立しません。(Microsoft Learn)
- チャネル変更を同時に進めるのに、更新ソースや Office Automatic Updates 2.0 タスクを見ていないこと。設定値だけでは完結しません。(Microsoft Learn)
- 過去の TAK 補修スクリプトを day 1 で消すこと。履歴のある環境では、撤去前に pilot で不要と確認するのが安全です。(TECHCOMMUNITY.MICROSOFT.COM)
最後に、今日やること
今回の ODT の TAK 対応で本当に大事なのは、配布ツールの更新と、TAK を使う管理プレーンの整理を同時に進めることです。今日やることを3つに絞るなら、次の順が現実的です。(Microsoft Learn)
- ODT を 16.0.19929.20062 以降へ統一し、どの
setup.exeが正本か決める。 - Apps admin center で現在の TAK を確認し、pilot 中は再生成しない方針を決める。
- Cloud Update / Inventory / OneDrive Sync Health のどれを使うかごとに、反映待ち時間を含めた pilot を組む。
ここまで整理できれば、発表直後でも慌てて全社展開する必要はありません。設定差分、周知項目、展開順序を切り分けたうえで進めれば、Office Deployment Tool と Microsoft 365 Apps の TAK 対応は安全に吸収できます。(Microsoft Learn)

コメント