Office LTSC と Azure Information Protection labeling client を使っている現場で、いま最初に確認すべきことは「Office の更新期限」だけではありません。2026年4月20日の Microsoft Partner Center 更新では、Office LTSC 2021 / Project LTSC 2021 / Visio LTSC 2021 のサポート終了が 2026年10月13日であることに加え、永続版 Office 向けの Azure Information Protection labeling client が退役済みである点も明記されました。つまり、LTSC 移行は単なる Office 入れ替えではなく、秘密度ラベル、暗号化、外部共有、承認フローまで含めた業務フローの見直しとして扱う必要があります。(Microsoft Learn)
結論から言えば、日常的に Word、Excel、PowerPoint、Outlook でラベル付けを使うユーザーは、Microsoft 365 Apps と Microsoft Purview の組み込み秘密度ラベルへ寄せるのが現実的です。一方で、規制・ネットワーク制約・固定環境の都合で Office LTSC を残す端末は、ラベル付けの役割を Office アドインに依存させず、ファイル単位の保護、スキャナー、PowerShell、手動運用などに分離して設計する必要があります。
Office LTSC / Azure Information Protection labeling client の最新動向
Microsoft の 2026年4月20日付アナウンスでは、Office LTSC 2021、Project LTSC 2021、Visio LTSC 2021 のサポート終了日が 2026年10月13日であること、終了後は更新プログラム、セキュリティ修正、技術サポートが提供されなくなることが示されています。あわせて、Microsoft 365 Copilot はクラウドに接続された Microsoft 365 スイート内のアプリでサポートされ、オンプレミス版 Office は対象外であること、永続版 Office 向けの Azure Information Protection labeling client は退役済みであることも明記されています。(Microsoft Learn)
この更新が現場に与える影響は、次の3つに分けると整理しやすくなります。
| 影響領域 | これまでの考え方 | これから必要な考え方 |
|---|---|---|
| Office クライアント | LTSC を長く使い続ける | サポート期限とセキュリティ更新の有無を前提に更新計画を作る |
| ラベル付け | AIP アドインで Office 文書にラベルを付ける | Office 組み込みの秘密度ラベル、または Office 外の保護手段に分ける |
| 業務フロー | ユーザー操作を変えずに維持する | 保存、送信、外部共有、監査まで含めて再設計する |
特に注意したいのは、AIP labeling client の話を「古いアドインがなくなるだけ」と軽く見ないことです。Microsoft Learn では、Azure Information Protection 統合ラベル付けクライアントの Office アドインは廃止され、ラベル付けをサポートする Office アプリに組み込まれた秘密度ラベルに置き換えられると説明されています。また、Office アプリで秘密度ラベルを使うには、Microsoft Purview ポータルから発行されたラベルポリシーと、サポートされる Office バージョンが必要です。(Microsoft Learn)
何が変わるのか：現場目線で見る3つの変化
ラベル付けは「アドイン」から「Office 組み込み」へ移る
従来の AIP アドイン運用では、ユーザーは Office のリボンやアドイン UI からラベルを選び、文書を分類・保護していました。今後の中心は、Microsoft Purview Information Protection の秘密度ラベルを Office アプリ側で直接扱う形です。
Microsoft は、Azure Information Protection 統合ラベル付けクライアントが Microsoft Purview Information Protection クライアントに置き換えられ、Word、Excel、PowerPoint、Outlook のラベル付け用 Office アドインは廃止されたと説明しています。(Microsoft Learn)
実務上は、次のような変化が起きます。
| 業務シーン | 旧来の運用 | 移行後の運用イメージ |
|---|---|---|
| Word 文書の作成 | AIP アドインで「社外秘」を選択 | Office 組み込みの秘密度ラベルから選択 |
| Excel の共有 | 保存後にアドインでラベル付け | 作成・保存・共有の流れの中でラベルを適用 |
| Outlook 送信 | メール作成後に AIP アドインで分類 | Outlook の秘密度ラベルでメールと添付ファイルを保護 |
| 既存ファイルの棚卸し | ユーザーの手作業が中心 | Purview Information Protection スキャナーや運用ルールで補完 |
ユーザーにとっては「ボタンの場所が変わる」程度に見えるかもしれません。しかし、管理者側では、ポリシー配布、ラベル名、暗号化設定、外部共有条件、監査ログの確認先が変わるため、事前検証なしに切り替えると問い合わせが増えます。
Office LTSC を残す端末は「例外管理」になる
Office LTSC は、頻繁な機能更新が難しい端末や、ネットワーク接続に制約がある環境で選ばれやすい製品です。たとえば、製造ライン端末、閉域網端末、検査用 PC、規制上クラウド接続を限定している部門などです。
ただし、Microsoft 365 Apps のようなクラウド連携前提の体験とは異なるため、Office LTSC を残す端末では、秘密度ラベルや Copilot、継続的なコンプライアンス機能を同じように扱えると考えない方が安全です。Microsoft は Office アプリの秘密度ラベルについて、Microsoft 365 Apps for enterprise などのサブスクリプション版 Office でサポートされると説明しています。(Microsoft Learn)
判断のポイントは、「その端末で Office 文書を作るのか」「機密文書を外部へ送るのか」「ラベル付き文書を閲覧するだけなのか」です。
| 端末タイプ | 推奨される判断 |
|---|---|
| 一般事務、営業、経理、人事 | Microsoft 365 Apps への移行を優先する |
| 機密文書を作成・送信する部門 | Office 組み込みラベルの動作検証を必須にする |
| 閉域網や製造ラインの固定端末 | Office LTSC 継続可否と代替保護手段を個別判断する |
| 閲覧専用・入力専用端末 | ラベル付け機能よりもファイル持ち出し制御を重視する |
| Project / Visio 利用者 | Project Plan、Visio Plan などクラウド版の適合性も確認する |
Office LTSC を完全に否定する必要はありません。重要なのは、Office LTSC を「標準」ではなく「制約があるため残す例外」として扱うことです。例外端末が増えすぎると、ラベル、DLP、監査、教育、サポートのすべてが複雑になります。
移行対象は Office だけでなく「保存・共有・承認」まで広がる
AIP labeling client の退役がワークフローに影響する理由は、ラベル付けが文書作成の最後に付ける飾りではないからです。
たとえば、次のような業務では、ラベルが後続処理の条件になります。
- 「社外秘」ラベルのファイルは外部共有を禁止する
- 「役員限定」ラベルのメールは転送を制限する
- 「個人情報」ラベルの Excel は透かしを付ける
- 「契約書」ラベルのファイルは承認後のみ共有する
- SharePoint や OneDrive の保存場所に応じて監査する
このような運用をしている場合、Office LTSC の更新計画だけを作っても不十分です。保存先、共有先、メール送信、承認者、監査ログの確認方法まで含めて見直す必要があります。
利用シナリオ別：rollout 後に業務フローはどう変わるか
シナリオ1：営業部門が提案書を外部顧客へ送る
営業部門では、PowerPoint の提案書、Excel の見積書、Word の契約関連文書を顧客へ送る場面が多くあります。AIP アドインに依存していた場合、ユーザーは「送信前にアドインでラベルを付ける」という操作を覚えていたはずです。
移行後は、Microsoft 365 Apps の組み込み秘密度ラベルを使い、文書作成中または保存時にラベルを選ぶ流れに寄せます。
変更前の流れ
- PowerPoint で提案書を作成する
- AIP アドインで「社外秘」ラベルを付ける
- Outlook に添付する
- 顧客へ送信する
変更後の流れ
- PowerPoint で提案書を作成する
- Office 組み込みの秘密度ラベルで「社外秘」などを選ぶ
- ラベルに応じた暗号化、透かし、アクセス制御が適用される
- Outlook 側でもメール本文や添付ファイルのラベルを確認する
- 必要に応じて送信前警告や DLP ルールで誤送信を防ぐ
このシナリオで失敗しやすいのは、営業担当者に「ラベル名だけ」を説明してしまうことです。実際には、どの顧客に送れるのか、社外共有できるラベルはどれか、顧客が開けない場合は誰に連絡するのかまで決めておく必要があります。
| 決めるべき項目 | 具体例 |
|---|---|
| 社外送信できるラベル | 公開可、顧客共有可 |
| 社外送信できないラベル | 社内限定、役員限定、人事機密 |
| 顧客が開けない場合の窓口 | 情シス、営業支援、Microsoft 365 管理者 |
| 例外対応 | 一時的な共有リンク、別ラベルへの変更、承認フロー |
営業現場ではスピードが重視されます。そのため、ラベルの選択肢を増やしすぎると逆効果です。「社外に出せる」「社内だけ」「厳重管理」のように、業務判断と直結する名前にする方が定着しやすくなります。
シナリオ2：経理部門が予算 Excel を部門長へ共有する
経理部門では、Excel ファイルに人件費、売上見込み、取引先情報、予算案などが含まれます。これらは単に暗号化すればよいわけではなく、閲覧者や編集者を絞る必要があります。
AIP アドイン時代は、経理担当者が Excel にラベルを付け、必要に応じてアクセス権を制限していたケースがあります。移行後は、Microsoft Purview の秘密度ラベルと Microsoft 365 の共有設定を組み合わせて、保存場所から見直すことが重要です。
推奨される運用例
| ファイル種別 | 保存場所 | ラベル | 共有範囲 |
|---|---|---|---|
| 月次予算案 | 経理部 SharePoint | 社内機密 | 経理部と部門長のみ |
| 役員会資料 | 役員会用 SharePoint | 役員限定 | 役員、秘書室、経営企画 |
| 取引先別支払一覧 | 経理部 SharePoint | 個人情報・機密 | 経理部の指定メンバー |
| 一般配布用集計表 | 全社ポータル | 社内一般 | 社内ユーザー |
このシナリオでは、「ラベルを付けること」よりも「ファイルがどこに置かれるか」が重要です。ユーザーがローカル PC に保存してからメール添付で回す運用を続けると、ラベルがあっても版管理や監査が難しくなります。
移行時は、次のように業務フローを変えると効果的です。
- ローカル保存ではなく SharePoint / OneDrive 保存を標準にする
- 経理テンプレートには初期ラベルを設定する
- 共有リンクは「組織内の指定ユーザー」に限定する
- ラベル変更は経理責任者または管理者に限定する
- 期末や監査前にラベルなしファイルを棚卸しする
Power users が多い部門では、テンプレート設計が定着の鍵になります。空の Excel から作らせるより、保存場所、ラベル、入力ルールが整ったテンプレートを配布する方がミスを減らせます。
シナリオ3：人事部門が個人情報を含む Word 文書を扱う
人事部門では、雇用契約書、評価資料、異動情報、健康情報など、取り扱いを誤ると大きなリスクになる文書が多くあります。
ここで重要なのは、ユーザーに「個人情報だから気を付けて」と伝えるだけでは不十分な点です。ラベル、アクセス制御、監査、教育をセットで設計する必要があります。
実務で使いやすいラベル設計例
| ラベル | 主な対象 | 保護設定の考え方 |
|---|---|---|
| 社内一般 | 社内通知、規程、マニュアル | 暗号化なし、社外共有は制限 |
| 社内機密 | 部門資料、未公開情報 | 社内限定、必要に応じて透かし |
| 個人情報 | 履歴書、評価、社員情報 | 閲覧・編集者を限定、転送や印刷を制限 |
| 役員・人事限定 | 給与、懲戒、異動案 | 強い暗号化、対象グループを限定 |
移行後のワークフローでは、Word 文書を作成する段階でラベルを選ばせるのではなく、テンプレートにラベルを紐づける運用が有効です。たとえば「雇用契約書テンプレート」を開いた時点で「個人情報」ラベルが推奨または適用されるように設計します。
ただし、自動適用を強くしすぎると、誤判定時に業務が止まります。特に人事部門では、同じ「社員」という言葉が社内報にも評価資料にも出てきます。最初から完全自動化を目指すより、推奨表示、ユーザー教育、監査ログ確認を組み合わせて段階的に強める方が現実的です。
シナリオ4：製造現場や閉域網端末で Office LTSC を残す
製造業、医療、公共、研究機関では、インターネット接続を制限した端末や、検証済み環境を長期間固定する端末があります。このような環境では、Microsoft 365 Apps へ全面移行できない場合があります。
この場合、Office LTSC を残すかどうかは、以下の観点で判断します。
| 判断軸 | 確認する内容 |
|---|---|
| 接続制約 | Microsoft 365 サービスへ常時または定期的に接続できるか |
| 文書作成の有無 | 機密文書を作成する端末か、閲覧・入力だけか |
| 持ち出し経路 | USB、メール、共有フォルダー、業務アプリのどこから出るか |
| 監査要件 | ラベル変更やファイル移動を記録する必要があるか |
| 代替策 | DLP、ファイルサーバー権限、業務アプリ側の制御で補えるか |
Office LTSC を残す端末では、Office アプリ内のラベル操作に期待しすぎないことが重要です。代わりに、次のような設計を検討します。
- 機密ファイルは専用の共有フォルダーや SharePoint ライブラリで管理する
- ファイルサーバー側のアクセス権で閲覧者を限定する
- Microsoft Purview Information Protection スキャナーで既存ファイルを棚卸しする
- USB 持ち出しやメール添付を別のセキュリティ製品や DLP で制御する
- 機密文書の作成は Microsoft 365 Apps 端末に集約する
閉域網端末は「移行しない」ではなく、「どの業務だけを残すか」を決める対象です。機密文書の新規作成や社外送信を閉域端末で続けるほど、運用は複雑になります。
シナリオ5：情シスが既存ファイルを棚卸しする
AIP labeling client の退役対応で見落とされやすいのが、既存ファイルの棚卸しです。新しい Office 環境を整えても、過去に作成されたラベルなし文書や、旧アドインで保護された文書が残っていれば、問い合わせやアクセス不能の原因になります。
管理者は、移行前に次のような棚卸しを行います。
| 棚卸し対象 | 確認ポイント |
|---|---|
| 旧 AIP アドイン利用端末 | インストール有無、Office バージョン、対象ユーザー |
| ラベル付きファイル | ラベル名、暗号化有無、保存場所 |
| ラベルなし機密ファイル | 個人情報、契約情報、財務情報の混在 |
| 共有フォルダー | 部門外から閲覧できるファイルの有無 |
| PowerShell / Scanner 利用 | 自動分類や一括処理の継続可否 |
Microsoft Learn では、古い Azure Information Protection unified labeling client は、File Explorer、PowerShell、オンプレミススキャナー、暗号化ファイル用ビューアーなどへラベル付けを拡張する Microsoft Purview Information Protection client に置き換えられると説明されています。Office アプリ内のアドインと、Office 外のファイル保護機能を混同しないことが重要です。(Microsoft Learn)
棚卸しでは、すべてのファイルを一度に完璧に分類しようとすると失敗します。まずは、外部共有されやすい部門、個人情報を扱う部門、監査対象の部門から優先順位を付けると進めやすくなります。
管理者・Power users・solution owners が今やるべきこと
管理者は「端末単位」ではなく「業務単位」で移行計画を作る
Office LTSC から Microsoft 365 Apps へ移行するかどうかを、端末台数だけで判断すると現場に合わない計画になります。実際には、同じ部門内でも業務によって必要な機能が違います。
管理者は、次のように業務単位で分類します。
| 分類 | 例 | 方針 |
|---|---|---|
| 標準業務 | メール、会議資料、営業資料、社内文書 | Microsoft 365 Apps + 組み込み秘密度ラベルへ移行 |
| 高機密業務 | 人事、法務、経理、役員資料 | ラベル、暗号化、DLP、監査をセットで設計 |
| 固定端末業務 | 製造ライン、検査端末、閉域端末 | Office LTSC 継続可否と代替制御を個別判断 |
| 専門アプリ連携 | Access、VBA、古いアドイン連携 | 互換性検証を先行する |
| 閲覧中心業務 | 受付、倉庫、現場端末 | Office 機能よりアクセス制御を優先 |
この分類を作ると、移行の会話が「Office を入れ替えるかどうか」から「どの業務を安全に継続するか」に変わります。
Power users はテンプレートと手順を先に整える
Power users は、現場に近い立場で移行を成功させる鍵になります。特に、Excel テンプレート、PowerPoint 提案書、Word 契約書ひな形を管理している人は、移行前にラベル設計を反映させる必要があります。
実務で効果が出やすい準備は次の通りです。
| 準備項目 | 実施内容 |
|---|---|
| テンプレート見直し | 文書種別ごとに初期ラベルや推奨ラベルを決める |
| ラベル名の整理 | ユーザーが判断しやすい名称にする |
| 操作手順の作成 | 画面キャプチャ付きで保存・共有・送信の流れを示す |
| 例外パターンの整理 | 顧客が開けない、社外共有したい、ラベルを下げたい場合を定義 |
| 問い合わせ窓口 | 部門内の一次窓口と情シスへのエスカレーションを分ける |
ラベル設計は情報システム部門だけで決めると、現場で使われない可能性があります。たとえば「Confidential」より「社外秘」、「Highly Confidential」より「役員・人事限定」の方が、日本語圏の利用者には判断しやすい場合があります。
Solution owners はアプリ連携と例外フローを洗い出す
solution owners は、業務システム、帳票、ワークフロー、外部連携にラベル付けが影響しないか確認する必要があります。
特に注意すべきなのは、Office ファイルを自動生成するシステムです。
- SFA から提案書を PowerPoint 出力する
- ERP から Excel 帳票を出す
- 人事システムから Word 契約書を生成する
- BI ツールから Excel エクスポートする
- 契約管理システムに Office ファイルを添付する
このような業務では、ユーザーが Office で開いた後にラベルを付けるだけでは不十分な場合があります。ファイル生成時、保存時、共有時のどこで分類するのかを決めておきます。
また、Microsoft Purview の秘密度ラベルは Microsoft 365 Copilot などの AI 利用時のデータ保護にも関係します。Microsoft は、Copilot やエージェントが秘密度ラベルを認識し、ラベルで保護されたデータについてユーザー権限を確認する仕組みを説明しています。(Microsoft Learn)
今後 Copilot 活用を進める組織では、ラベル付けを「コンプライアンス部門の作業」ではなく、「AI に参照させてよいデータを制御する基盤」として扱うべきです。
移行計画の実践ステップ
まずは30日で現状を可視化する
最初の30日でやるべきことは、製品選定ではなく現状把握です。ここを飛ばすと、移行後に「この部門だけ業務が止まった」「顧客がファイルを開けない」「古いアドイン前提の手順書が残っている」といった問題が起きます。
| 作業 | 具体的な確認内容 |
|---|---|
| Office バージョン確認 | Office LTSC 2021、Office LTSC 2024、Microsoft 365 Apps の混在状況 |
| AIP 関連確認 | AIP アドイン、MIP/Purview クライアント、Scanner、PowerShell 利用の有無 |
| ラベル確認 | 既存ラベル名、暗号化設定、発行ポリシー、対象ユーザー |
| 業務確認 | 機密文書を作る部門、外部送信が多い部門、例外端末 |
| リスク確認 | サポート終了後も残る端末、監査対象、規制対象データ |
この段階では、完璧な設計書よりも「どこが危ないか」を見える化することが重要です。
次の60日でパイロットを行う
次に、代表的な部門を選んで Microsoft 365 Apps と組み込み秘密度ラベルのパイロットを行います。おすすめは、一般部門だけでなく、機密情報を扱う部門を含めることです。
| パイロット対象 | 検証する理由 |
|---|---|
| 営業 | 社外送信、顧客共有、添付ファイルの問題を確認できる |
| 経理 | Excel、アクセス権、監査の課題を確認できる |
| 人事 | 個人情報、強い暗号化、限定共有の課題を確認できる |
| 情シス | 展開、ポリシー、問い合わせ対応を確認できる |
| 例外端末部門 | Office LTSC 継続時の制約を確認できる |
パイロットで確認すべき項目は、単に「ラベルが付くか」ではありません。
- ラベル付きファイルを社内ユーザーが開けるか
- 外部ユーザーが想定通り開けるか
- Outlook 送信時に期待した警告が出るか
- SharePoint / OneDrive の共有リンクと矛盾しないか
- ラベル変更の理由を記録できるか
- 既存テンプレートやマクロが壊れないか
- ユーザーがラベル名を正しく判断できるか
特に外部共有は、必ず実際の相手に近い条件で検証します。社内テストアカウントだけで成功しても、顧客テナント、ゲストユーザー、個人メール、制限付きネットワークでは結果が異なることがあります。
90日以降は標準化と例外管理に移る
パイロット後は、全社展開に向けて標準化します。この段階で重要なのは、例外をなくすことではなく、例外を管理できる状態にすることです。
| 項目 | 標準化のポイント |
|---|---|
| 標準 Office | 原則として Microsoft 365 Apps を標準にする |
| 例外 Office | Office LTSC が必要な理由、対象端末、終了予定を記録する |
| ラベル | 全社共通ラベルと部門専用ラベルを分ける |
| 教育 | 職種別に「どのラベルを選ぶか」を説明する |
| 監査 | ラベルなし機密ファイル、ラベル変更、外部共有を定期確認する |
Office LTSC を残す場合は、「誰が承認した例外か」「いつ見直すか」を台帳化します。これをしないと、数年後に同じ問題が繰り返されます。
失敗しやすいポイントと対策
失敗1：Office LTSC 2024 に上げれば解決すると考える
Office LTSC 2021 のサポート終了に対して、Office LTSC 2024 へ更新することは選択肢の一つです。Microsoft も、クラウドソリューションを使えない規制・接続・技術上の制約がある場合、Office LTSC 2024、Project LTSC 2024、Visio LTSC 2024 などのオンプレミス代替を検討できるとしています。(Microsoft Learn)
ただし、AIP labeling client の退役対応まで含めると、Office LTSC 2024 への更新だけで同じ運用を維持できるとは限りません。秘密度ラベルを Office アプリ内で日常的に使う業務では、Microsoft 365 Apps への移行可否を必ず検討すべきです。
失敗2：ラベルを細かく作りすぎる
「公開」「社内」「部外秘」「機密」「極秘」「役員限定」「個人情報」「顧客情報」「契約情報」など、最初から多くのラベルを作ると、ユーザーは判断できなくなります。
ラベルは、情報分類の美しさよりも、利用者が迷わず選べることを優先します。
初期設計の例
| ラベル | 判断基準 |
|---|---|
| 公開可 | Web や外部資料として公開してよい |
| 社内一般 | 社内共有はよいが社外公開はしない |
| 社外秘 | 顧客や委託先に限定して共有する |
| 機密 | 社内の限られた人だけが扱う |
| 個人情報・厳重管理 | 個人情報、給与、評価、法務案件など |
最初は少数で始め、監査結果や問い合わせ内容を見て増やす方が定着します。
失敗3：ユーザー教育を操作説明だけにする
「ここをクリックしてラベルを選びます」という教育だけでは、現場では使われません。必要なのは、業務判断に結びつく説明です。
たとえば、営業向けには次のように説明します。
| NGな説明 | 良い説明 |
|---|---|
| 秘密度ラベルを選んでください | 顧客へ送る提案書は原則「社外秘」を選びます |
| 機密情報は保護してください | 見積、価格表、契約条件を含む資料は「社外秘」以上です |
| 開けない場合は問い合わせてください | 顧客が開けない場合は、ラベルを下げずに営業支援へ連絡します |
ユーザーはセキュリティ用語ではなく、業務場面で判断します。教育資料も「ラベルの説明」ではなく「この場面ではこのラベル」という構成にすると効果的です。
失敗4：外部共有の検証を後回しにする
ラベル付きファイルは、社内では問題なく開けても、外部ユーザーで問題が起きることがあります。顧客側の Microsoft 365 環境、ゲストアクセス設定、メールセキュリティ、端末制限によって結果が変わるためです。
外部共有が多い組織では、以下のテストを必ず行います。
- 顧客ドメインのユーザーが開けるか
- ゲストユーザーが開けるか
- 暗号化付きラベルのファイルを閲覧できるか
- 転送、印刷、コピー制限が想定通りか
- 共有リンクの有効期限が業務に合うか
- 顧客が開けない場合の代替手段があるか
「セキュリティを強めたら顧客がファイルを開けなくなった」は、移行プロジェクトでよくある失敗です。外部共有の検証は、最後ではなくパイロット段階で行うべきです。
rollout を成功させるチェックリスト
Office LTSC / Azure Information Protection labeling client の rollout を進める際は、次のチェックリストを使うと抜け漏れを減らせます。
| チェック項目 | 完了の目安 |
|---|---|
| Office LTSC 2021 の利用端末を把握した | 台数、部門、用途、責任者が分かっている |
| AIP アドイン利用状況を確認した | インストール端末と実利用ユーザーが分かっている |
| Microsoft 365 Apps へ移行する業務を決めた | 標準移行対象と例外対象が分かれている |
| Office LTSC を残す理由を記録した | 規制、接続、互換性など理由が明確 |
| 秘密度ラベルを整理した | ラベル名、説明、保護設定が業務に合っている |
| 外部共有を検証した | 顧客、委託先、ゲストで開封テスト済み |
| テンプレートを更新した | Word、Excel、PowerPoint の主要テンプレートに反映済み |
| ユーザー教育を用意した | 部門別の判断例と問い合わせ先がある |
| 監査方法を決めた | ラベルなしファイル、外部共有、ラベル変更を確認できる |
| 例外端末の見直し日を決めた | 半年または年1回の棚卸し予定がある |
これからの判断基準：LTSC を残すか、Microsoft 365 Apps へ寄せるか
最終的な判断は、コストやライセンスだけではなく、業務リスクで決めるべきです。
| 判断ポイント | Microsoft 365 Apps が向くケース | Office LTSC 継続を検討するケース |
|---|---|---|
| 秘密度ラベル | Office 内で日常的に使う | Office 内ラベル操作が主目的ではない |
| 外部共有 | 顧客・委託先との共有が多い | 外部共有しない、閉域で完結する |
| Copilot / AI 活用 | 今後活用したい | 利用予定がない、または制限される |
| 更新方針 | 継続的な機能・セキュリティ更新を受け入れられる | 検証済み環境を長期間固定したい |
| 業務端末 | 一般業務、情報共有、共同編集 | 製造、検査、特殊端末、閉域網 |
| 管理負荷 | クラウド管理に寄せたい | 個別管理を許容できる |
多くの組織では、すべてを一方に寄せるのではなく、「標準は Microsoft 365 Apps、例外として Office LTSC」という形が現実的です。ポイントは、例外を放置しないことです。
Office LTSC / Azure Information Protection labeling client の更新は、単なる製品ライフサイクル対応ではありません。文書を作る、保存する、共有する、守る、監査するという一連の業務フローを見直すタイミングです。
まずは、Office LTSC 2021 と AIP アドインの利用状況を棚卸しし、機密文書を扱う部門から Microsoft 365 Apps と Microsoft Purview の秘密度ラベルを検証してください。そのうえで、Office LTSC を残す端末は理由と期限を明確にし、Office アプリ内のラベル付けに依存しない代替フローを設計することが、現場に混乱を起こさない移行の近道です。
コメント