Office LTSC / Azure Information Protection labeling client の移行で最初に押さえるべき結論は、永続版 Office 上の AIP ラベル付けアドインを延命する設計から、Microsoft Purview の秘密度ラベルを中心にした実装へ切り替えることです。2026年4月20日の Microsoft Partner Center 更新では、Office LTSC 2021 のサポート終了が近いことに加え、永続版 Office 向けの Azure Information Protection labeling client が廃止済みであることが明示されました。Office 上のユーザー操作は Microsoft 365 Apps の組み込みラベル、ファイル共有・オンプレミス・バッチ処理は Microsoft Purview Information Protection client、独自アプリは MIP SDK へ分けると、実装・移行・自動化の見通しが大きくよくなります。(Microsoft Learn)
開発者、platform engineer、DevOps team にとって重要なのは、「Office LTSC をどう更新するか」だけではありません。COM アドイン、GPO、端末配布、ファイルサーバーの一括ラベル付け、CI/CD でのラベル適用、既存 AIP スキャナーの移行まで、設計面の判断が変わります。この記事では、Office LTSC / Azure Information Protection labeling client の最新動向を踏まえ、実務で使える移行判断、実装手順、自動化例、失敗しやすいポイントを整理します。
2026年4月20日の更新で何が変わったのか
Microsoft の 2026年4月20日付けアナウンスでは、Office LTSC 2021、Project LTSC 2021、Visio LTSC 2021 のサポートが 2026年10月13日に終了し、以後は更新、セキュリティ修正、技術サポートを受けられなくなると案内されています。併せて、Microsoft 365 Copilot は Microsoft 365 スイートに含まれるクラウドバック型アプリでのみサポートされ、オンプレミス版 Office は対象外であること、さらに Azure Information Protection labeling client for perpetual Office が retired であることが示されています。(Microsoft Learn)
この更新は、単なるサポート期限の告知ではありません。Office LTSC で AIP labeling client を使い続ける前提の運用に対し、Microsoft が「移行判断をやり直すタイミング」を示したものと捉えるべきです。
特に影響が大きいのは、次のような環境です。
| 環境 | 影響 | 取るべき方向 |
|---|---|---|
| Office LTSC 2021 + AIP Office アドイン | サポート終了と retired クライアントの二重リスク | Microsoft 365 Apps への移行を優先 |
| Office LTSC 2024 を検討中 | 永続版 Office を選ぶ理由を明確にする必要がある | 規制・閉域・オフライン要件がある場合のみ慎重に採用 |
| ファイルサーバー上の既存文書を分類したい | Office UI ではなくバッチ処理が主役になる | Purview Information Protection client / scanner を使う |
| 独自アプリやDLP製品でラベルを扱いたい | AIP アドイン依存は避けるべき | MIP SDK でラベル読み書き・保護処理を実装 |
AIP labeling client 廃止の意味を正しく理解する
ここでいう廃止は、「既存ファイルのラベルが消える」という意味ではありません。Microsoft Purview の秘密度ラベルはコンテンツにメタデータとして保持され、暗号化やコンテンツマーキングなどの保護設定と組み合わせて使われます。ラベルを削除した場合でも、すでにコンテンツに適用された保護が自動的に消えるわけではありません。(Microsoft Learn)
問題になるのは、Office アプリ上でラベルを表示・変更するための旧 AIP Office アドインを、今後の標準実装として使えないことです。Microsoft のドキュメントでは、AIP unified labeling client の Windows Office add-in は retired でサポートされず、Office アプリに組み込まれた秘密度ラベルに置き換えられると説明されています。また、Office ポリシーの「Use the Azure Information Protection add-in for sensitivity labeling」を Enabled にしていると、Office アプリで秘密度ラベルを使えない可能性があるため、Not configured または Disabled にする必要があります。(Microsoft Learn)
つまり、開発者目線では次のように整理できます。
| 旧来の考え方 | 今後の考え方 |
|---|---|
| Office LTSC に AIP アドインを入れてラベル UI を提供する | Microsoft 365 Apps の組み込み秘密度ラベルを使う |
| Office COM アドインや端末依存の動作を前提にする | Purview のラベルポリシーを中心に設計する |
| Office アプリを自動操作してラベル付けする | PowerShell、scanner、MIP SDK で処理する |
| AIP client を単一の万能ツールとして扱う | Office UI、ファイルサーバー、独自アプリで実装面を分ける |
Office LTSC と Microsoft 365 Apps の移行判断
Office LTSC は、機能更新を継続的に受ける Microsoft 365 Apps とは目的が違います。規制、閉域、ネットワーク制約、長期固定環境などがある場合には LTSC が選択肢になりますが、秘密度ラベル、Copilot、クラウド連携、継続的なセキュリティ改善を重視するなら、Microsoft 365 Apps を優先して検討すべきです。
Microsoft は、Office LTSC 2021 からの推奨アップグレード先として、エンタープライズでは Microsoft 365 E3 を中心に、Office 365 E3 や Microsoft 365 Apps for enterprise を代替候補として示しています。中小規模では Microsoft 365 Business Premium、Business Standard、Microsoft 365 Apps for business が候補です。一方、クラウド利用が難しい場合のオンプレミス代替として Office LTSC 2024 も示されています。(Microsoft Learn)
判断基準は、次の表で切り分けると実務に落とし込みやすくなります。
| 要件 | 推奨方針 | 理由 |
|---|---|---|
| Word / Excel / PowerPoint / Outlook 上でラベルを自然に使いたい | Microsoft 365 Apps | 組み込み秘密度ラベルを使える |
| Microsoft 365 Copilot を使う予定がある | Microsoft 365 Apps を含む Microsoft 365 スイート | オンプレミス版 Office は Copilot の対象外 |
| ファイル共有上の既存文書を一括分類したい | Purview Information Protection scanner | ユーザー操作ではなくサーバー側処理に向く |
| CI/CD やバッチでファイルにラベルを付けたい | PurviewInformationProtection PowerShell module | Set-FileLabel などで自動化できる |
| SaaS、DLP、CASB、独自アプリにラベル処理を組み込みたい | MIP SDK | ラベルの読み書きや保護処理をアプリに実装できる |
| ネットワーク制約で Microsoft 365 Apps が使えない | Office LTSC 2024 + 別経路でラベル処理 | Office UI と保護処理を分離する |
実装面で楽になるポイント
AIP Office アドインをやめると、最初は移行作業が増えたように見えます。しかし、開発・運用の観点では、むしろ責任範囲が整理されます。
Office アドイン配布の複雑さが減る
旧 AIP アドイン運用では、Office のビット数、COM アドインの有効・無効、Outlook アドイン競合、GPO、端末ごとの差分、アップデート時の挙動確認が問題になりがちでした。Microsoft Purview Information Protection client には Office Add-in がなく、Office 側のラベル付けは組み込みの秘密度ラベルに置き換えられています。(Microsoft Learn)
これにより、端末展開の設計は次のように単純化できます。
| 対象 | 配布するもの | 主な管理ポイント |
|---|---|---|
| Microsoft 365 Apps 利用端末 | Office アプリ本体とラベルポリシー | 更新チャネル、ポリシー、サインイン状態 |
| ファイル共有操作端末 | Purview Information Protection client | File Explorer ラベル付け、viewer、PowerShell |
| スキャナーサーバー | Purview Information Protection client + scanner | SQL、サービスアカウント、スキャンジョブ |
| 独自アプリ基盤 | MIP SDK | 認証、ラベルID、ファイル処理、監査 |
自動化が「Office 操作」から「ファイル操作」に変わる
AIP アドインに依存した自動化では、Office アプリを起動して UI や COM 経由で処理しようとする設計が発生しがちです。しかし、サーバーやCI/CDでOfficeを自動操作する設計は、安定性・ライセンス・同時実行・エラーハンドリングの面で扱いづらくなります。
PurviewInformationProtection PowerShell module を使えば、ファイルのラベル状態確認、ラベル付け、保護の解除などをファイル単位で処理できます。Get-FileStatus はファイルのラベル名、適用者、適用日時、保護状態などを返し、Set-FileLabel は指定したラベルIDをファイルに適用できます。(Microsoft Learn)
Import-Module PurviewInformationProtection
# 初回実行時またはトークン更新時に実行
# 非対話実行では AppId / AppSecret / TenantId / DelegatedUser などを使う
Set-Authentication
$targetPath = "\\fileserver01\Finance"
$labelId = "d9f23ae3-1234-1234-1234-f515f824c57b"
Get-ChildItem $targetPath -Recurse -File -Include *.docx,*.xlsx,*.pptx,*.pdf |
Get-FileStatus |
Where-Object { $_.IsLabeled -eq $False } |
Set-FileLabel -LabelId $labelIdこの例では、未ラベルの Office ファイルや PDF を検出して、指定した秘密度ラベルを適用します。実運用では、まず Export-Csv で対象ファイルを棚卸しし、テストフォルダーで Set-FileLabel を実行してから本番共有へ展開してください。
ファイルサーバー移行がスキャナー中心にできる
オンプレミスのファイル共有や SharePoint Server ライブラリを扱う場合は、Microsoft Purview Information Protection scanner が有効です。スキャナーは Windows Server 上のサービスとして動作し、UNC パスや SharePoint Server のドキュメントライブラリをクロールして、機密情報の検出、分類、ラベル適用、必要に応じた保護を実行できます。リアルタイム処理ではなく、指定したデータストアを周期的にスキャンする仕組みです。(Microsoft Learn)
旧 AIP scanner から Microsoft Purview Information Protection scanner へ移行する場合は、バージョン 2.x から 3.x への移行でサービス名やコンポーネント名が変わるため、単純な上書き更新ではなく、停止、アンインストール、再インストール、データベース更新の順序を守る必要があります。(Microsoft Learn)
# 旧 AIP scanner の構成確認
Get-AIPScannerConfiguration
# 旧サービス停止
Net Stop AIPScanner
# 旧 scanner のアンインストール
Uninstall-AIPScanner
# Purview Information Protection client 3.x をインストール後、
# 新しい scanner を同じクラスター名で構成
Install-Scanner -SqlServerInstance SQLSERVER1\SCANNER -Cluster EU
# scanner データベース更新
Net Stop MIPScanner
Update-ScannerDatabase
Net Start MIPScanner本番では、スキャナーサーバーを1台だけでなく複数ノードのクラスターにして、対象共有ごとにスキャン時間帯を分けると安定します。特に大量の Office ファイル、PDF、古いファイル形式、アクセス権の複雑な共有では、最初から「ラベル適用」ではなく「検出のみ」のモードでレポートを取り、対象範囲を絞ってから自動ラベル付けに進むのが安全です。
開発者向けの移行設計パターン
Office LTSC / Azure Information Protection labeling client の移行では、すべてを一つのツールで処理しようとしないことが重要です。実装パターンを分けると、設計レビューもしやすくなります。
パターンA: ユーザーが Office で編集する文書
ユーザーが Word、Excel、PowerPoint、Outlook で日常的に文書を作成・編集する場合は、Microsoft 365 Apps の組み込み秘密度ラベルを使う構成が基本です。Microsoft Purview ポータルでラベルを作成・発行すると、ユーザーは Office アプリ上で分類・保護のためのラベルを選択できます。ラベル利用には、ユーザーが Microsoft 365 の職場または学校アカウントでサインインしている必要があります。(Microsoft Learn)
このパターンでは、開発者が独自に Office アドインを作ってラベルUIを再現するのではなく、Purview のラベルポリシー、既定ラベル、必須ラベル、ダウングレード時の理由入力、監査ログを活用する方が保守しやすくなります。
パターンB: 既存ファイルをまとめて分類する
ファイルサーバーや移行前データの棚卸しでは、ユーザー操作を待つのではなく、PowerShell または scanner を使います。
小規模なら PowerShell、大規模で継続スキャンが必要なら scanner が向いています。
| 規模・用途 | 推奨 |
|---|---|
| 数百〜数千ファイルの一時処理 | PowerShell |
| 部門共有の定期スキャン | Information Protection scanner |
| 移行前のラベル付けレポート作成 | scanner の検出モード |
| DLP製品が検出したファイルだけ処理 | PowerShell または MIP SDK |
| SharePoint Online 上のファイル状態確認 | SharePoint Online PowerShell の専用コマンドを検討 |
Get-FileStatus はローカルパス、ネットワークパス、SharePoint Server URL を扱えますが、SharePoint Online 上のファイルでは SharePointOnlinePowerShell module の Get-FileSensitivityLabelInfo を使うよう案内されています。クラウド上のファイルをローカル共有のように扱う設計は避けてください。(Microsoft Learn)
パターンC: 独自アプリやサービスでラベルを扱う
SaaS、CASB、DLP、文書変換サービス、移行ツールなどで秘密度ラベルを読み書きする場合は、Microsoft Information Protection SDK を使います。MIP SDK は、Microsoft Purview のラベル付けと保護サービスをサードパーティアプリやサービスへ公開し、ファイルへのラベル適用、保護、ラベル検出に対応します。(Microsoft Learn)
代表的なユースケースは次のとおりです。
| ユースケース | 実装方針 |
|---|---|
| 文書アップロード時に分類を付与 | アップロード後に MIP SDK でラベル適用 |
| 既存分類タグを Purview ラベルに変換 | 旧メタデータを読み、ラベルIDへマッピング |
| DLP検出結果に応じて保護を追加 | DLP判定後に MIP SDK または PowerShell で適用 |
| 暗号化済みファイルを読み取り処理したい | 権限設計、super user、監査を含めて設計 |
| 複数OS対応アプリに組み込みたい | MIP SDK を使い、端末の Office 依存を避ける |
ラベルは表示名ではなく GUID で扱うのが安全です。表示名は言語、組織改定、階層変更で変わる可能性がありますが、ラベルIDを設定値として持てば、自動化コードやCI/CD変数の安定性が上がります。
移行手順の実務フロー
Office LTSC / Azure Information Protection labeling client の移行は、端末、ポリシー、ファイル、アプリを分けて進めると失敗しにくくなります。
現状を棚卸しする
最初に確認すべきものは、Office のバージョンだけではありません。AIP client、COM アドイン、GPO、既存ラベル、ファイル共有、scanner、独自アプリの依存関係を洗い出します。
$uninstallPaths = @(
"HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*",
"HKLM:\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\*"
)
Get-ItemProperty $uninstallPaths -ErrorAction SilentlyContinue |
Where-Object {
$_.DisplayName -match "Azure Information Protection|Purview Information Protection|Microsoft 365 Apps|Office LTSC"
} |
Select-Object DisplayName, DisplayVersion, Publisher, InstallDate |
Sort-Object DisplayNameこの棚卸しで、次の4分類に分けます。
| 分類 | 例 | 判断 |
|---|---|---|
| 移行優先 | Office LTSC 2021 + AIP Office アドイン | Microsoft 365 Apps へ移行 |
| 継続利用候補 | 規制・閉域端末の Office LTSC | ラベル処理を別経路へ分離 |
| サーバー処理 | ファイル共有、SharePoint Server | scanner / PowerShell へ移行 |
| 開発対応 | 独自DLP、文書変換、移行ツール | MIP SDK へ移行 |
AIP Office アドイン依存を外す
次に、AIP Office アドインを前提にした設定を外します。特に、Office ポリシーの「Use the Azure Information Protection add-in for sensitivity labeling」が Enabled のままだと、Office アプリ側の秘密度ラベル利用に支障が出る可能性があります。Not configured または Disabled にして、Microsoft 365 Apps の組み込みラベルへ切り替える方針を取ります。(Microsoft Learn)
この段階で確認する項目は次のとおりです。
| 確認項目 | 失敗例 | 対策 |
|---|---|---|
| GPO / Cloud Policy | AIP アドイン強制有効化が残る | Disabled または Not configured |
| Office 更新チャネル | 必要なラベル機能がまだ入っていない | Current / Monthly / Semi-Annual の差を確認 |
| ユーザーサインイン | ラベルが表示されない | Microsoft 365 職場・学校アカウントでサインイン |
| ラベル発行範囲 | 一部ユーザーだけラベルが見えない | ラベルポリシーの対象グループを確認 |
| 既存アドイン | Outlook / Office が不安定 | COM アドイン競合を整理 |
Office アプリの秘密度ラベル機能は、更新チャネルによって利用可能になる時期や最小バージョンが異なります。Windows では Current Channel や Monthly Enterprise Channel の方が Semi-Annual Enterprise Channel より新機能を早く受け取るため、検証端末と本番端末のチャネル差に注意してください。(Microsoft Learn)
ラベルポリシーを再設計する
移行時は、旧ラベルをそのまま機械的に引き継ぐより、分類体系を見直す好機です。
実務では、次のようなシンプルな階層から始めると運用しやすくなります。
| ラベル例 | 用途 | 自動化時の扱い |
|---|---|---|
| Public | 外部公開可能 | 自動付与は慎重に |
| Internal | 社内文書の標準 | 既定ラベル候補 |
| Confidential | 部門内・関係者限定 | DLPやscannerと相性がよい |
| Highly Confidential | 経営、法務、人事、財務 | 暗号化・アクセス制限を検討 |
Microsoft Purview では、ラベルの順序が優先度に影響します。一般に、より厳格なラベルを一覧の下側に配置し、ユーザーがラベルを削除したり低い秘密度へ変更したりする場合に理由を求める設定を組み合わせます。(Microsoft Learn)
開発・自動化では、ラベル表示名ではなくラベルIDを設定値として持ちます。
{
"labels": {
"internal": "11111111-1111-1111-1111-111111111111",
"confidential": "22222222-2222-2222-2222-222222222222",
"highlyConfidential": "33333333-3333-3333-3333-333333333333"
},
"defaultLabel": "internal"
}このように外部設定化しておくと、環境ごとのラベルID差分を吸収できます。グローバル企業では、開発、検証、本番、リージョン別テナントでラベルIDが異なることがあるため、コードにラベルIDを直書きしない方が安全です。
DevOps での自動化例
CI/CD や移行バッチに組み込む場合は、「何をラベル付けするか」「誰の権限で実行するか」「失敗時にどう戻すか」を明確にします。
Windows self-hosted runner でラベル付けする
PurviewInformationProtection PowerShell module は Windows 上のクライアントを前提にするため、Azure DevOps や GitHub Actions で使う場合は Windows の self-hosted runner を用意するのが現実的です。
Import-Module PurviewInformationProtection
$labelId = $env:PURVIEW_LABEL_ID
$artifactPath = "D:\build-output"
Set-Authentication `
-AppId $env:PURVIEW_APP_ID `
-AppSecret $env:PURVIEW_APP_SECRET `
-TenantId $env:PURVIEW_TENANT_ID `
-DelegatedUser $env:PURVIEW_DELEGATED_USER
Get-ChildItem $artifactPath -Recurse -File -Include *.docx,*.xlsx,*.pptx |
Get-FileStatus |
Where-Object { $_.IsLabeled -eq $False } |
Set-FileLabel -LabelId $labelId
Get-FileStatus -Path $artifactPath |
Export-Csv "$artifactPath\label-report.csv" -NoTypeInformationSet-Authentication は非対話実行にも対応し、スケジュールされた PowerShell スクリプトや scanner、DLP連携などの用途で使えます。ただし、委任ユーザーにはラベルポリシーが割り当てられている必要があり、保護解除や再保護が必要な場合は権限設計を別途確認します。(Microsoft Learn)
独自サービスでは MIP SDK を選ぶ
クロスプラットフォームのサービス、SaaS、DLP、文書変換基盤では、PowerShell より MIP SDK が適しています。MIP SDK では、File SDK を使ってラベル一覧の取得、ラベルの設定・取得、保護されたファイルの処理などを実装できます。C# や C++ のクイックスタートも提供されています。(Microsoft Learn)
設計時は、次の点を最初に決めてください。
| 設計項目 | 判断基準 |
|---|---|
| 認証方式 | ユーザー委任か、サービスとして処理するか |
| ラベルマッピング | 旧分類、部署、ファイル属性をどのラベルIDに対応させるか |
| ファイル処理 | 元ファイル上書きか、出力ファイルを別管理するか |
| 監査 | 誰が、いつ、どの分類を適用したか記録するか |
| エラー処理 | 暗号化済み、署名済み、ロック中ファイルをどう扱うか |
| SDK バージョン | サポートされる GA バージョンを追跡するか |
MIP SDK は GA バージョンのサポート期間やプレビュー版の扱いが定義されています。開発チームはライブラリを固定したまま放置せず、定期的にサポート状況を確認する運用を入れてください。(Microsoft Learn)
移行で失敗しやすいポイント
Office LTSC / Azure Information Protection labeling client の移行でよくある失敗は、技術的なエラーよりも「前提のズレ」です。
| 失敗しやすいポイント | なぜ問題か | 対策 |
|---|---|---|
| Office LTSC に AIP アドインを入れればよいと考える | retired クライアント前提の設計になる | Microsoft 365 Apps の組み込みラベルへ移行 |
| AIP アドイン有効化ポリシーが残る | Office の秘密度ラベルが使えない可能性 | GPO / Cloud Policy を見直す |
| ラベル名で自動化する | 表示名変更・多言語化で壊れる | ラベルIDを使う |
| いきなり本番共有にラベル適用する | 誤分類・暗号化で業務影響が大きい | 検出モード、CSV出力、小範囲テストから始める |
| 保護解除を簡単に考える | 権限不足で失敗する | owner / super user / 監査要件を確認 |
| SharePoint Online をファイル共有扱いする | コマンドや取得方式が異なる | 専用PowerShellやPurview機能を使う |
| SDK を入れたら終わりにする | サポート切れや脆弱性対応が遅れる | SDK更新を定期タスク化する |
特に暗号化を伴うラベルでは、誤適用の影響が大きくなります。最初の自動化では、暗号化なしの分類ラベル、または限定されたテスト共有で検証し、対象部署の業務フローを確認してから保護設定を強める方が安全です。
Office LTSC を残す場合の現実的な設計
すべての環境を Microsoft 365 Apps に移行できるとは限りません。工場端末、閉域ネットワーク、規制環境、検証固定端末などでは Office LTSC を残す判断もあります。
その場合でも、「Office LTSC 上で AIP アドインを使い続ける」ではなく、次のように分離して設計します。
| 領域 | 設計 |
|---|---|
| Office 文書の編集 | Office LTSC で継続 |
| ラベル付けUI | 期待しすぎない。必要なら運用ルールで補完 |
| ファイル共有上の分類 | scanner / PowerShell で実施 |
| 移行時の一括ラベル | PowerShell または MIP SDK |
| 保護付きファイル閲覧 | Purview Information Protection viewer などを検討 |
| 監査・ポリシー | Purview 側で一元管理 |
この設計なら、Office LTSC を「編集アプリ」として限定し、情報保護は Purview 側の仕組みに寄せられます。将来 Microsoft 365 Apps へ移行する場合も、ラベル体系や自動化基盤を再利用しやすくなります。
まず着手すべきアクション
Office LTSC / Azure Information Protection labeling client の対応は、次の順で進めると実務に乗せやすくなります。
| 優先度 | アクション | 成果物 |
|---|---|---|
| 高 | Office LTSC 2021 と AIP client の利用端末を棚卸し | 移行対象一覧 |
| 高 | AIP Office アドイン依存のGPO・ポリシーを確認 | 設定変更計画 |
| 高 | Microsoft 365 Apps へ移行できる部署を特定 | パイロット計画 |
| 中 | ラベル体系とラベルIDマッピングを整理 | 自動化設定ファイル |
| 中 | ファイル共有を検出モードでスキャン | ラベル適用候補CSV |
| 中 | PowerShell または MIP SDK のPoCを作る | バッチ処理・API検証 |
| 低 | Office LTSC 継続端末の例外管理を定義 | 例外台帳・更新計画 |
結論として、今回の更新で楽になるのは、「AIP アドインをどう延命するか」を考えなくてよくなる点です。Office のラベル体験は Microsoft 365 Apps の組み込み機能へ、ファイルサーバーやバッチは Purview Information Protection client / scanner へ、独自アプリは MIP SDK へ分ければ、開発・移行・自動化の責任範囲が明確になります。
まずは、Office LTSC 2021 と AIP client の利用実態を棚卸しし、AIP Office アドイン依存のポリシーを外せるか確認してください。そのうえで、小さな部門またはテスト共有を対象に、Microsoft 365 Apps の組み込み秘密度ラベルと PowerShell による一括ラベル付けを検証するのが、最もリスクの低い第一歩です。
コメント