Office LTSC / Project LTSC / Visio LTSC の rollout は、単なるアプリの入れ替えではありません。Excel マクロ、Project の進捗管理、Visio の設計図共有、更新管理、ライセンス設計、監査対応まで、現場のワークフローそのものを見直すタイミングです。
結論から言うと、Office LTSC 2021 / Project LTSC 2021 / Visio LTSC 2021 を使っている組織は、まず利用端末と業務ファイルを棚卸しし、「Microsoft 365へ移行するユーザー」と「LTSC 2024を維持する端末」を分けて rollout 計画を作るべきです。Microsoft は2026年4月20日の案内で、これらの製品が2026年10月13日にサポート終了へ近づいていることを告知しています。サポート終了後は更新、セキュリティ修正、技術サポートを受けられなくなるため、現場任せの延命運用はリスクが高くなります。(Microsoft Learn)
Office LTSC / Project LTSC / Visio LTSC の最新動向
Microsoft の2026年4月20日の発表では、Office LTSC 2021、Project LTSC 2021、Visio LTSC 2021 のサポート終了日が2026年10月13日であることが改めて示されました。対象読者はパートナーだけでなく、実際には企業の情報システム部門、業務部門の power users、ソリューションオーナーにも直結する内容です。(Microsoft Learn)
重要なのは、「サポート終了＝その日に突然使えなくなる」ではなく、「以後、業務で使い続ける根拠を説明しにくくなる」という点です。特に、個人情報、財務データ、設計情報、顧客情報を扱う端末では、セキュリティ修正を受けられない Office アプリを使い続けること自体が監査上の論点になります。
Microsoft は、多くの顧客に対して Microsoft 365 への移行を推奨しています。エンタープライズでは Microsoft 365 E3 が主な推奨先とされ、要件に応じて Office 365 E3 や Microsoft 365 Apps for enterprise も選択肢になります。中小規模の組織では Microsoft 365 Business Premium、Business Standard、Microsoft 365 Apps for business が候補です。Project LTSC と Visio LTSC については、Planner and Project Plan 3 と Visio Plan 2 がクラウドベースの移行先として案内されています。(Microsoft Learn)
一方で、規制、ネットワーク接続、技術的な制約によりクラウド利用が難しい環境では、Office LTSC 2024、Project LTSC 2024、Visio LTSC 2024 のようなサポート対象のオンプレミス製品を検討できます。ただし、Office LTSC 2024 はリリース後に新機能を継続追加する製品ではなく、長期固定運用向けの選択肢です。Office LTSC 2024 は Project と Visio を含めて5年間のメインストリームサポートを受け、その後の延長サポートはありません。(Microsoft Learn)
rollout で変わるのは「インストール作業」ではなく業務の流れ
Office LTSC / Project LTSC / Visio LTSC の rollout を、旧バージョンをアンインストールして新バージョンを入れるだけの作業と捉えると失敗します。実際に変わるのは、次のような現場の流れです。
| 観点 | 従来のLTSC運用で起きがちな状態 | rollout後に見直すべきこと |
|---|---|---|
| 文書作成 | ローカル保存、ファイルサーバー共有、メール添付が中心 | 共同編集、版管理、保存場所、承認フローを再設計する |
| Excel業務 | マクロ、アドイン、古いテンプレートに依存 | 互換性テスト、32bit/64bit、外部データ接続を確認する |
| Project管理 | PMが.mppファイルを更新し、週次会議で共有 | 担当者入力、進捗更新、レポート共有の役割分担を決める |
| Visio図面 | 特定担当者だけが図面を編集 | 図面のオーナー、テンプレート、レビュー手順を整備する |
| 管理運用 | 固定版なので変更が少ない前提 | 更新経路、ライセンス、配布方式、監査ログを設計する |
| セキュリティ | 端末ごとの個別管理になりやすい | サポート期限、脆弱性対応、利用継続の例外承認を管理する |
特に Microsoft 365 へ移行する場合、ユーザーは「新しい Office が入った」と感じるだけでは不十分です。保存先、共有方法、レビュー方法、ファイル名ルールまで変えなければ、結局は古い運用のまま新しいアプリを使うことになります。
シナリオ別に見る rollout の実務インパクト
Excelマクロを多用する財務・経理部門
財務、経理、経営管理の power users は、Office LTSC rollout の影響を最も受けやすい層です。月次決算、予算管理、売上集計、原価計算などで、Excel ブック、VBA、アドイン、外部データ接続が複雑に絡んでいることが多いためです。
この部門で最初にやるべきことは、アプリのバージョン確認ではなく「業務ブックの棚卸し」です。次の観点で、重要ファイルをリスト化します。
| 確認項目 | 見るべきポイント |
|---|---|
| マクロの有無 | VBA、ActiveX、フォーム、外部DLLを使っていないか |
| アドイン | 会計システム、BIツール、帳票ツールのアドインが対応しているか |
| データ接続 | SQL Server、Access、CSV、SharePoint、Web APIなどの接続先 |
| ファイル形式 | .xls、.xlsm、.xlsx、テンプレートファイルの混在 |
| 実行頻度 | 毎日使うのか、月次・四半期・年次だけ使うのか |
| 代替可否 | Power Query、Power BI、業務システム側の帳票で置き換えられるか |
よくある失敗は、全社員に新しい Office を展開した後で「月末にしか使わない決算マクロが動かない」と判明するケースです。月次業務はテスト時期を逃すと、次に検証できるのが翌月になります。財務系の rollout では、通常業務の締め日を基準にして、最低1回は本番に近いデータでリハーサルする必要があります。
判断基準はシンプルです。共同編集、クラウド保存、セキュリティ管理、Copilot 活用を進めたいユーザーは Microsoft 365 側へ寄せる価値があります。一方、外部接続できない端末、固定マクロだけを限定用途で使う端末、規制上クラウド連携できない端末は、Office LTSC 2024 を候補にします。
PMO・プロジェクトマネージャーの Project LTSC 利用
Project LTSC を使っている組織では、rollout によってプロジェクト管理の責任分担が変わります。従来は、PMが Project ファイルを開き、WBS、開始日、終了日、依存関係、進捗率を手作業で更新する運用が多く見られます。
Microsoft が Project LTSC のクラウドベースの移行先として Planner and Project Plan 3 を案内している点を踏まえると、検討すべきなのは「Project の後継ツール」だけではありません。誰がタスクを更新し、誰が進捗を承認し、どの会議でどの画面を見るのかまで再設計することです。(Microsoft Learn)
例えば、次のように業務フローが変わります。
| 従来の流れ | rollout後に目指したい流れ |
|---|---|
| PMが各担当者からメールで進捗を集める | 担当者がタスク単位で進捗を入力する |
| 週次会議前にPMが.mppを手作業更新する | 会議前に進捗状況を確認し、遅延タスクに集中する |
| プロジェクトファイルをメール添付で共有する | 閲覧者、編集者、承認者の権限を分ける |
| ガントチャートがPMだけの管理資料になる | チーム全体が次の作業と期限を把握する |
Project LTSC 2024 を選ぶべきケースもあります。たとえば、外部ネットワークに接続できない開発拠点、顧客指定の環境、長期契約でツール変更が難しいプロジェクトでは、固定版のほうが現実的です。ただし、その場合でも「誰がファイルを保管するか」「最新版はどれか」「バックアップはどこにあるか」を明文化しなければ、属人化は解消されません。
Visio LTSC を使う設計・業務プロセス部門
Visio LTSC は、ネットワーク構成図、業務フロー図、システム構成図、工場レイアウト、組織図などで使われます。Visio の rollout で重要なのは、図面ファイルを単なる成果物ではなく「継続的に更新される業務資産」として扱うことです。
Visio Plan 2 のようなクラウドベースの選択肢を検討する場合、現場では次の変化が起きます。
| 利用シーン | 変化するワークフロー |
|---|---|
| ネットワーク構成図 | インフラ担当だけでなく、セキュリティ担当や運用担当もレビューに参加しやすくなる |
| 業務フロー図 | 業務部門とIT部門が同じ図を見ながら改善点を議論しやすくなる |
| システム構成図 | 変更申請、設計レビュー、障害対応の資料として再利用しやすくなる |
| グローバル拠点の図面 | 言語、拠点名、テンプレート、更新責任者の統一が必要になる |
失敗しやすいのは、旧バージョンの Visio ファイルだけを移行して、テンプレートやステンシルの管理を後回しにすることです。図面作成ルールが統一されていないと、同じ意味のアイコンが拠点ごとに異なり、レビューや監査で説明しにくくなります。
solution owners は、Visio のライセンス数だけでなく、図面のライフサイクルを定義する必要があります。新規作成、レビュー、承認、公開、廃止の流れを決めることで、Visio は「個人の作図ツール」から「組織の設計情報を管理するツール」に変わります。
工場・研究所・医療機器周辺などのオフライン環境
Office LTSC が残りやすいのは、製造ライン、研究所、医療機器周辺、閉域ネットワーク、検査端末などです。これらの環境では、クラウド移行を無理に進めるより、サポート対象の LTSC へ計画的に更新するほうが安全な場合があります。
ただし、オフライン環境だからといって「何もしなくてよい」わけではありません。むしろ、通常の端末より事前設計が重要です。Office LTSC 2024 の展開では Office Deployment Tool を使い、Office CDN から直接インストールする方法、ローカルネットワーク上の共有フォルダーへインストールファイルをダウンロードして配布する方法、Configuration Manager を使う方法などを選べます。(Microsoft Learn)
オフライン端末では、次の点を必ず確認します。
| 確認項目 | 実務上の理由 |
|---|---|
| 更新ファイルの持ち込み手順 | セキュリティ更新をどの経路で適用するかを決める |
| ライセンス認証方式 | KMS、MAK、Active Directoryベース認証などの方針を確認する |
| 業務アプリ連携 | 検査装置、帳票ソフト、古いODBC接続との互換性を検証する |
| 変更可能期間 | 生産停止日、点検日、監査前後を避けて展開する |
| 例外承認 | サポート終了製品を一時的に残す場合の期限と責任者を決める |
特に工場や研究所では、IT部門だけで rollout 日程を決めると現場の停止リスクを見落とします。生産計画、設備保全、品質保証、情報システムを同じ場に集め、どの端末をいつ更新できるかを確認する必要があります。
Microsoft 365へ移行するか、LTSC 2024を選ぶかの判断基準
Office LTSC / Project LTSC / Visio LTSC の rollout では、全員を同じ製品へ移すより、業務特性で分けるほうが現実的です。
| 対象ユーザー・端末 | 推奨される方向性 | 判断基準 |
|---|---|---|
| 一般的な事務職、営業、企画 | Microsoft 365 | 共同編集、モバイル利用、クラウド保存、セキュリティ管理を重視する |
| Excel power users | Microsoft 365またはOffice LTSC 2024 | マクロ互換性、アドイン対応、データ接続、クラウド可否で判断する |
| PMO、プロジェクト管理部門 | Planner and Project Plan 3またはProject LTSC 2024 | チーム全体で進捗更新するならクラウド、固定計画中心ならLTSC |
| 設計、業務改善、ITアーキテクト | Visio Plan 2またはVisio LTSC 2024 | 図面レビューや共有が多いならクラウド、閉域利用ならLTSC |
| 工場、研究所、検査端末 | Office LTSC 2024中心 | ネットワーク制約、装置連携、監査要件を優先する |
| Copilot活用を進める部門 | Microsoft 365 | オンプレミス版 Office は Microsoft 365 Copilot の対象外と案内されている |
Microsoft 365 Copilot を将来的に使いたい組織は、特に注意が必要です。Microsoft は、Microsoft 365 Copilot が Microsoft 365 スイートに含まれるクラウド対応アプリでサポートされ、オンプレミス版 Office は対象外であると案内しています。つまり、Office LTSC 2024 へ移行すればサポート期限の問題は解消できますが、AI活用や継続的な機能追加を前提としたワークフローには向きません。(Microsoft Learn)
管理者が進めるべき rollout 手順
まず利用実態を棚卸しする
最初の作業は、ライセンス購入ではなく棚卸しです。管理者は、Office LTSC 2021、Project LTSC 2021、Visio LTSC 2021 が入っている端末、利用者、用途、重要ファイルを把握します。
棚卸しでは、次の情報を集めます。
| 項目 | 収集内容 |
|---|---|
| 端末情報 | PC名、OS、部門、利用者、設置場所 |
| Office情報 | 製品名、バージョン、32bit/64bit、言語 |
| Project / Visio | インストール有無、利用頻度、ファイル保存場所 |
| 重要ファイル | マクロ付きExcel、Projectファイル、Visio図面 |
| 依存関係 | アドイン、業務システム、外部データ接続 |
| 制約 | オフライン、規制、顧客指定、監査要件 |
この段階で「誰が使っているか分からない Project」「退職者が作った Visio テンプレート」「更新されていないマクロ」が見つかることは珍しくありません。rollout は、こうした見えない負債を整理する機会でもあります。
ユーザーを業務シナリオで分類する
次に、ユーザーを製品名ではなく業務シナリオで分類します。たとえば「Office利用者」という大きな括りではなく、次のように分けます。
| 分類 | 代表例 | rollout方針 |
|---|---|---|
| 標準ユーザー | メール、文書作成、表計算が中心 | Microsoft 365へ移行しやすい |
| 高度Excelユーザー | VBA、Power Query、外部データ接続を利用 | 事前検証を厚くする |
| Project利用者 | PM、PMO、開発リーダー | Project運用そのものを見直す |
| Visio利用者 | 情シス、設計、業務改善担当 | 図面テンプレートとレビュー手順を整備する |
| 固定端末利用者 | 工場、研究所、検査端末 | LTSC 2024や例外運用を検討する |
この分類をせずに一括展開すると、標準ユーザーには過剰な説明が届き、重要ユーザーには必要な検証時間が足りなくなります。
パイロット展開は「部門」ではなく「業務」で選ぶ
パイロット展開は、単に協力的な部門を選ぶのではなく、業務パターンを代表できるユーザーを選ぶべきです。例えば、経理の月次処理、PMOの進捗会議、情シスの構成図更新、工場端末の帳票出力など、失敗すると業務影響が大きい場面を含めます。
パイロットで見るべきポイントは次の通りです。
| 検証項目 | 確認内容 |
|---|---|
| ファイル互換性 | 既存ファイルが開けるか、レイアウト崩れがないか |
| マクロ実行 | エラー、警告、処理時間の変化がないか |
| アドイン | 起動、認証、データ取得、帳票出力が動くか |
| 保存・共有 | 旧来のファイルサーバー運用から変える必要があるか |
| 権限 | 編集者、閲覧者、承認者が適切に分かれているか |
| ユーザー教育 | どの操作で問い合わせが増えるか |
パイロットの結果は、単なる不具合一覧ではなく「本展開前に変えるべき業務ルール」として整理します。
展開方式と更新方式を先に決める
Office LTSC 2024 を展開する場合、Office Deployment Tool を使って構成ファイルを作成し、CDN、ローカル共有、Configuration Manager などから配布できます。更新についても、Office CDN から自動更新するか、内部ネットワーク上の共有フォルダーから更新するか、管理ツールを使うかを決める必要があります。Office LTSC 2024 は通常、月1回更新プログラムを受け取り、更新は累積的に提供されます。(Microsoft Learn)
ここで大切なのは、展開方式と更新方式を別々に考えないことです。インストールは成功したが、その後の更新が止まるというケースは、閉域環境や拠点分散環境で起きやすい失敗です。
グローバル拠点では言語・時差・承認フローを先に揃える
グローバル読者向けに考えると、Office LTSC / Project LTSC / Visio LTSC の rollout は、国ごとのIT事情にも影響されます。日本本社では Microsoft 365 を使えるが、海外工場では閉域ネットワークが前提というケースもあります。
グローバル展開では、次の点を先に決めます。
| 論点 | 決めるべき内容 |
|---|---|
| 言語 | Office表示言語、テンプレート言語、サポート文書の言語 |
| 拠点差 | クラウド接続可否、ネットワーク帯域、ローカル規制 |
| サポート体制 | 問い合わせ窓口、一次切り分け、現地ITの権限 |
| 展開時期 | 各国の休日、決算期、生産停止期間 |
| 承認 | 例外端末を誰が承認し、いつまで許可するか |
グローバル rollout で特に避けたいのは、本社標準を一方的に押し付けて、現地の業務停止を招くことです。標準化すべき部分と、現地事情に合わせる部分を分けて設計します。
Power users、admins、solution owners の役割分担
Office LTSC / Project LTSC / Visio LTSC の rollout は、情報システム部門だけでは完結しません。実務ファイルを理解している power users、配布と更新を担う admins、業務プロセスを決める solution owners が、それぞれの責任を持つ必要があります。
| 役割 | 主な担当 | 成功のポイント |
|---|---|---|
| Power users | マクロ、テンプレート、Project計画、Visio図面の検証 | 「いつも使う操作」だけでなく、月次・年次処理もテストする |
| Admins | 棚卸し、配布、更新、ライセンス、サポート窓口 | インストール完了ではなく、更新継続まで設計する |
| Solution owners | 業務フロー、承認ルール、利用ポリシーの決定 | ツール変更を業務改善につなげる |
この3者が分断されると、rollout は「ITは展開したが現場は使いにくい」「現場は困っているが管理者は原因を把握できない」という状態になります。週次の短いレビュー会議でもよいので、パイロット期間中は3者が同じ課題リストを見る体制を作るべきです。
失敗しやすいポイントと対策
Office LTSC / Project LTSC / Visio LTSC の rollout では、次のような失敗がよく起きます。
| 失敗パターン | 起きる問題 | 対策 |
|---|---|---|
| サポート終了日だけを告知する | 現場が「何をすればよいか」分からない | 部門別に影響と対応手順を示す |
| Officeだけを更新する | Project、Visio、アドインが取り残される | 製品単位ではなく業務フロー単位で棚卸しする |
| ライセンスを単純に1対1で置き換える | 不要なコストや機能不足が発生する | 利用頻度と業務価値で割り当てを見直す |
| マクロ検証を後回しにする | 月末・期末処理で重大な障害が出る | 重要ブックを優先順位付けし、業務サイクルに合わせて検証する |
| オフライン端末を最後に確認する | 展開方式や認証方式が間に合わない | 閉域・規制環境を最初に洗い出す |
| 教育を操作説明だけにする | 古いファイル共有文化が残る | 保存場所、共有、レビュー、承認まで教える |
| 例外端末を無期限に残す | サポート終了後のリスクが固定化する | 期限、責任者、代替案を明記する |
特に注意したいのは、サポート終了対応を「IT資産管理のイベント」としてだけ扱うことです。実際には、ドキュメント作成、進捗管理、設計レビュー、監査対応のやり方を変えるチャンスです。
rollout 後に定着させるための運用設計
展開が終わった後も、運用設計がなければ現場は旧来のやり方に戻ります。定着のためには、次の4点を明確にします。
ファイルの保存場所を標準化する
Microsoft 365へ移行する場合、個人PCのデスクトップやローカルフォルダーに重要ファイルを置く運用は見直すべきです。部門共有、プロジェクト共有、個人作業用を分け、どのファイルをどこへ保存するかをルール化します。
LTSC 2024を使い続ける場合でも、ファイルサーバー上のフォルダー構成、バックアップ、アクセス権、版管理を見直します。アプリだけ新しくしても、保存場所が属人的なままでは改善効果が出ません。
テンプレートと標準ファイルを管理する
Excel、Project、Visio の業務では、テンプレートが実質的な業務ルールになっていることがあります。rollout のタイミングで、古いテンプレートを整理し、最新版だけを配布する仕組みを作ります。
特に Visio のステンシルや Project の標準WBSは、部門ごとにバラバラになりやすい領域です。テンプレートの管理者を決め、更新履歴を残すだけでも、後続プロジェクトの品質が安定します。
問い合わせを分類して改善につなげる
rollout 後の問い合わせは、単なるサポート対応ではなく改善データです。問い合わせを「操作方法」「互換性」「権限」「ライセンス」「業務ルール」に分類すると、次の展開ウェーブで何を直すべきかが見えます。
例えば、操作方法の問い合わせが多い場合はトレーニング不足、権限の問い合わせが多い場合は共有設計の不備、互換性の問い合わせが多い場合はパイロット対象の選定不足が疑われます。
サポート終了後の例外管理を残す
どうしても一部の Office LTSC 2021 / Project LTSC 2021 / Visio LTSC 2021 を残さざるを得ない場合は、例外管理台帳を作ります。台帳には、端末名、利用者、用途、残す理由、リスク、代替予定日、承認者を記載します。
例外を「現場が困るから残す」で終わらせると、サポート終了後も危険な状態が続きます。例外は許可しても、期限と責任者を必ずセットにするべきです。
まず取るべき次のアクション
Office LTSC / Project LTSC / Visio LTSC の rollout で最初にやるべきことは、製品選定ではありません。現場で何が使われ、どのファイルが業務を支えているかを把握することです。
具体的には、次の順序で進めます。
| 順序 | アクション | 成果物 |
|---|---|---|
| 1 | Office LTSC 2021 / Project LTSC 2021 / Visio LTSC 2021 の利用端末を棚卸しする | 対象端末リスト |
| 2 | 重要ファイル、マクロ、アドイン、Project/Visioファイルを洗い出す | 業務影響リスト |
| 3 | Microsoft 365へ移行するユーザーとLTSC 2024を選ぶ端末を分ける | 移行方針表 |
| 4 | power users を含めてパイロットを実施する | 不具合・改善リスト |
| 5 | 部門別に展開ウェーブを作る | rollout計画 |
| 6 | 例外端末を台帳管理する | 例外管理台帳 |
2026年10月13日のサポート終了は、単なる期限ではなく、Office を中心とした現場ワークフローを見直す区切りです。Microsoft 365へ寄せるべき業務、LTSC 2024で固定運用すべき端末、廃止すべき古いファイルを分けることで、rollout はリスク対応だけでなく、業務改善のプロジェクトになります。(Microsoft Learn)
コメント