リモートデスクトップ（RDP/RDS）でサーバー（VM）上のWord/Excelを使いたいとき、Office LTSC Professional Plus 2024の「必要ライセンス数」と「プロダクトキー（認証）の扱い」で迷うケースが多いです。10人が3台のサーバー（VM）へ接続する想定を例に、見積もりの考え方と、KMS/MAK/Active Directoryベース認証の違いまでまとめます。
まず押さえる：なぜ「10人なのに3台？」で混乱するのか
サーバー（VM）にOfficeを入れて、ユーザーはRDPなどで接続してWord/Excelを使う運用は、見た目が「サーバー上のアプリを共有」になります。そのため、次の2つがごちゃ混ぜになって混乱しがちです。
- ライセンス（利用権）の数え方：誰（または何台）が使う権利を持つか
- インストール／ライセンス認証（アクティベーション）の数：実際に何台のOSへOfficeを入れて、何回認証するか
結論から言うと、Office LTSCは原則として「デバイス（端末）単位でライセンスを割り当てる」考え方で整理されます。一方、プロダクトキーの入力や認証回数は「インストールした台数」に寄ります。ここがズレるため「10ライセンス買ったらキー10個？」という疑問が生まれます。
前提：Office LTSC Professional Plus 2024 とは（Microsoft 365 Appsとの違い）
Office LTSC 2024は、クラウド機能を前提としないオンプレミス向けのOfficeです。Microsoft Learnの概要でも、Office LTSC 2024はMicrosoft 365のサブスクリプション版（Microsoft 365 Apps）とは別物で、機能追加のアップデートは提供されない点が明確にされています。導入の目的が「機能を固定したい」「ネット接続が制限される」などであれば適合しやすい一方、常に新機能が必要ならMicrosoft 365 Appsの方が自然です。
また、Office LTSC 2024のサポート対象OSとしてWindows Server 2022が挙げられており、サーバー（VM）へインストールして使うなら、まずOS要件を満たしているか確認が必要です。
- Office LTSC 2024 概要：Overview of Office LTSC 2024
結論：必要ライセンス数は「ユーザー数」でも「サーバー数」でもなく、基本は「アクセスするデバイス数」
Microsoftの「Office LTSC licensing guidance」では、Office LTSCがper-device（デバイス単位）でライセンスされること、そしてネットワークサーバーにOffice LTSCを配置してリモート利用する場合でもサーバー自体にライセンスを割り当てるのではなく、リモートでアクセスする各デバイスに同一バージョン／同一エディションのライセンスが必要になる整理が示されています。
つまり、質問にあった「3台のサーバー（VM）上で使う」ケースは、次のように考えます。
| 論点 | 見積もりの軸 | この例（10人・3台VM）での考え方 |
|---|---|---|
| 必要ライセンス数 | アクセスするデバイス数 | 10人が各1台のPCからアクセスするなら10デバイス分が基本 |
| インストール台数 | Officeを入れるOSの数 | サーバー（VM）が3台なら、Officeのインストールは3回が目安 |
| ライセンス認証（アクティベーション）回数 | 認証方式（KMS/AD/MAK）とインストール台数 | サーバー3台分をどう認証するか（キー入力が必要か等）が論点 |
公式ガイダンス（Office LTSC Licensing Guidance）：https://www.microsoft.com/licensing/guidance/Office-LTSC
ケーススタディ：10人が3台のサーバー（VM）にリモート接続してWord/Excelを使う
質問の条件を、現場でよくある2パターンに分けて整理します。
パターンA：10人が「それぞれ会社支給PC 1台」から接続する
この場合、必要なOffice LTSCのライセンス数は基本的に10です（アクセス元デバイスが10台のため）。
ここで重要なのは、サーバー（VM）が3台あっても10×3＝30ライセンスには通常なりません。Office LTSCのリモート利用権は「サーバーに何本入れたか」よりも「どのデバイスがアクセスするか」を軸に整理されるためです。
パターンB：1人が「会社PC＋自宅PC」など複数端末から接続する
Office LTSCは基本がデバイス単位なので、アクセス元が増えると必要本数も増えます。
- 10人がそれぞれ2台の端末からアクセス → 端末は20台 → 基本は20ライセンスが目安
ただし、Software Assurance（SA）を付けている場合は、いわゆるRoaming Rights（ローミング権）などの例外が絡むことがあります。特に「自宅の個人PCからのアクセス」や「第三者デバイス」の扱いは条件が付くため、ガイダンスの該当箇所とProduct Termsで必ず確認してください。
「サーバーにOfficeを置いてリモート利用」でも、サーバー台数でライセンスしない理由
Microsoftの資料では、Office LTSCをネットワークサーバー上にホストしてユーザーがリモートアクセスする形について、サーバーにライセンスを割り当てるのではなく、リモートアクセスする各デバイスに同一バージョン／同一エディションのOffice LTSCライセンスが必要、という整理が明示されています（例外はRoaming Rightsなどの条件付き）。
加えて、Microsoft Licensing FAQsにはRDS環境の「デスクトップアプリ（Officeを含む）」の使い方として、デバイスベースライセンスである以上、アクセスする全デスクトップ（端末）にライセンスが必要、という趣旨のQ&Aがあります。特に「VM側に1ライセンスを割り当てれば誰でも使えるのでは？」という疑問に対しても、端末側が必要という整理が掲載されています。
Microsoft Licensing FAQs（RDSでのデスクトップアプリ利用）：https://www.microsoft.com/licensing/faqs/71
注意：Office以外にも必要になりがちなライセンス（RDS CAL・Windows Server CALなど）
Officeの話だけで見積もってしまうと「買ったのに使えない／監査で指摘される」原因になります。RDP/RDSでサーバーへ接続してアプリを使う運用では、少なくとも次の要素が関係しやすいです（環境により変動）。
| カテゴリ | よく必要になるもの | ざっくりした考え方 |
|---|---|---|
| サーバーOS | Windows Server ライセンス | VMホスト／仮想化形態に応じたライセンス設計が必要 |
| アクセス権 | Windows Server CAL | サーバーへアクセスするユーザー/デバイスに対して必要になることが多い |
| リモートデスクトップ | RDS CAL（User または Device） | RDP/RDSで接続するなら原則検討対象。ユーザー単位で買っても、Officeは別途デバイス単位で必要になる点に注意 |
| Office本体 | Office LTSC Professional Plus 2024 | 基本はアクセス元デバイスに割り当て（サーバー台数ではない） |
「Officeは買ったのにRDS CALがなくて接続できない」「RDS CALはユーザーで揃えたのにOfficeは端末で数えるの？」といったミスマッチが現場では多いので、購入前に全体像で整理しておくのが安全です。
プロダクトキーは何個？結論：ボリュームライセンスなら“人数分のキー”という発想ではない
Office LTSC Professional Plus 2024は、一般的にボリュームライセンス（Commercial Licensing）での取得が前提になりやすい製品です。この場合、プロダクトキーは「10ライセンス＝10キー」という形よりも、組織の認証方式（KMS / Active Directoryベース / MAK）で管理するのが基本です。
ポイント：ライセンス数とアクティベーション数は一致しない
今回の例（サーバー3台にOfficeを入れる）だと、アクティベーションの対象は基本的に3インストールです。必要ライセンスは「アクセス元デバイスが10台なら10」ですが、認証は「インストールした台数（3台）」で動きます。
このズレを理解しておくと、「10ライセンス買ったのに、キー入力は3回しかしていないけど大丈夫？」という不安が解消しやすくなります。
Office LTSCのボリュームライセンス認証：KMS / Active Directory / MAKの違い
Microsoft Learnでは、ボリュームライセンス版Officeの認証方法として、主に次の方式が整理されています。
- KMS（Key Management Service）
- Active Directoryベースのライセンス認証
- MAK（Multiple Activation Key）
参考：Overview of volume activation of Office
| 方式 | キーのイメージ | 向いている規模・特徴 | 今回（サーバー3台）での相性 |
|---|---|---|---|
| KMS | KMSホストに1つのKMSホストキーを入れる。 クライアント側はGVLK（汎用キー）が前提で、基本は個別入力しない。 | 社内にKMS基盤があり、端末が一定数ある環境向け。 DNS/SRVやTCP 1688などインフラ要素が絡む。 | 注意：最小カウント（しきい値）の要件があるため、小規模だとハマりやすい。 ただし既にKMS運用があるなら選択肢。 |
| Active Directoryベース | ADに認証情報（アクティベーションオブジェクト）を登録し、 ドメイン参加端末が自動で認証する。 | ドメイン参加が前提。KMSよりクライアント側の自動化がしやすいこともある。 | サーバーがドメイン参加しているなら検討しやすい。 ただし構成要件は確認が必要。 |
| MAK | 1つのMAKキーで複数台を認証（回数上限は契約に紐づく）。 台数ごとにキーが変わるというより「同じキーを使い、回数が消費される」イメージ。 | 小規模・閉域・インターネット接続が限定的な環境でも扱いやすい。 一度認証すれば、基本は継続利用できる（大きなハード変更がない前提）。 | 3台にだけ入れて認証するなら相性が良いことが多い。 ネット接続がない場合はプロキシ認証など要検討。 |
KMS：Activate volume licensed versions of Office by using KMS
MAK：Activate volume licensed versions of Office by using MAK
ADベース：Activate volume licensed versions of Office by using Active Directory-based activation
「10ライセンス買ったらキーは10個？」への現実的な答え
購入チャネルや契約形態で見え方は変わりますが、ボリュームライセンスを前提にすると次のイメージが近いです。
よくあるパターン：MAKキーは1つ、ただし“認証可能回数”がライセンス数に紐づく
MAKでは、組織に発行されるMAKキーをインストール先に設定して認証します。キーが10個配られるというより、1つのMAKキーで複数回認証できる形になるのが一般的です。
今回の例なら、Officeを入れるのはサーバー3台なので、MAKで認証する場合でも認証回数は基本的に3回（3台）です。購入ライセンスが10であっても、「認証するのは3台」という構図は珍しくありません。
KMS/ADベースの場合：個別にキー入力しない運用になりやすい
KMSやActive Directoryベースの場合、Office側にはGVLK（汎用のボリュームキー）が前提として用意されており、クライアントごとにプロダクトキーを入力する運用にならないことがあります。KMSであれば、KMSホスト側に必要なキーを入れて運用します。
小規模（10人・サーバー3台）で“ハマりやすい”ライセンス認証の注意点
KMSの「しきい値（最小カウント）」問題
KMSは便利ですが、Office製品には一定数の要求が集まるまでクライアントが有効化されないという性質があります。Microsoft LearnのKMS構成ガイドでも、OfficeのKMSクライアントが有効化されるにはカウントが一定以上必要である旨が説明されています。
もし「3台のサーバーにだけOfficeを入れる」構成で、他にKMSへ要求を投げる端末が無い場合、KMSが期待通り動かず、結果として「認証できない」状態になることがあります。こうした構成では、MAKやActive Directoryベースが結果的に手戻りが少ないケースが多いです。
VMのクローン／スナップショット運用
RDSサーバーをテンプレート化して横展開する場合、KMSのカウントが増えない、同一ID扱いで認証が不安定になる、といったトラブルが起きることがあります。OS/Officeの展開設計（一般化・複製の方法）まで含めて、最初に方針を決めておくと安心です。
「リテール版を買えば安いのでは？」に潜む落とし穴
サーバー（RDS）上でOfficeを使う話になると、個人向け・OEM向けのOfficeライセンスを混在させたくなる場面がありますが、Microsoft Licensing FAQsにはOEMのOfficeライセンスはネットワークサーバーからの利用を許可しない趣旨の記載があります。RDS運用前提なら、Commercial Licensing（ボリューム系）で要件を満たすのが基本です。
特に「安価なキーがネット上にある」「Professional Plusのキーが単品で売られている」などは、正規の取得経路かどうかの確認が難しいこともあります。監査・更新・運用まで含めたリスクを考えると、正規チャネルでの調達が無難です。
運用イメージで整理：必要本数の数え方（図解代わりの表）
「誰がどの端末から接続するか」を変えると、必要本数がどう動くかを表にすると理解しやすくなります。
| 利用イメージ | アクセス元デバイス | 必要なOffice LTSC本数（目安） | 補足 |
|---|---|---|---|
| 10人が会社PC 10台からRDSへ接続 | 10台 | 10 | サーバーが1台でも3台でも、アクセス元が10台なら基本は10 |
| 10人が会社PC＋自宅PCで接続（計20台） | 20台 | 20 | SA付きのRoaming Rightsなど例外が絡む可能性あり |
| 10人が交代で共用端末5台から接続 | 5台 | 5 | ユーザー数ではなく端末台数が軸。交代制でも端末が増えれば増える |
| コールセンター等で端末30台から接続（同時利用は10） | 30台 | 30 | 同時接続数ではなく「アクセス可能な端末台数」で考える |
購入前チェックリスト：この順番で確認するとズレにくい
| チェック項目 | 確認ポイント | なぜ重要か |
|---|---|---|
| 利用形態 | RDP/RDS、VDI、Citrix、アプリ配信など接続方式 | 「アクセス元デバイス」の定義と数え方が変わりうる |
| アクセス元デバイス数 | 社員PC、ノート、在宅用端末、共有端末、薄型端末 | Office LTSCは基本がデバイス単位。ここが見積の核 |
| サーバーOS | Windows Server 2022か（Office LTSC 2024の要件） | サポート外OSだとトラブル時の逃げ道がなくなる |
| 調達チャネル | Commercial Licensing（正規）か、契約/証跡は揃うか | RDSで使える権利の有無が大きく変わる |
| 認証方式 | KMS / ADベース / MAK のどれで行くか | 小規模だとKMSのしきい値問題で詰まりやすい |
| 周辺ライセンス | RDS CAL、Windows Server CALなどの整合 | Officeだけ買っても接続できない・監査で指摘される可能性 |
まとめ：このケース（10人・サーバー3台）での最短整理
- 必要ライセンス数は、まず「RDSへアクセスする端末が何台か」で決める。10人が各1台なら10本が基本。
- サーバー3台は「インストール台数」の話。ライセンスが3本になる、という意味ではない。
- プロダクトキーの個数は、ボリュームライセンスなら“人数分のキー”になりにくい。KMS/AD/MAKの方式で管理される。
- アクティベーションはインストールした台数（この例なら3台）に対して行うのが一般的で、ライセンス本数（10）とは一致しないことがある。
- 最終的な適用は契約（Product Terms）に従うため、調達先（Microsoft/販売パートナー）のライセンス窓口で条件を突き合わせて確定する。
参考リンク（公式）
- Office LTSC Licensing Guidance：https://www.microsoft.com/licensing/guidance/Office-LTSC
- Microsoft Licensing FAQs（RDSでのデスクトップアプリ利用）：https://www.microsoft.com/licensing/faqs/71
- Office LTSC 2024 概要：https://learn.microsoft.com/en-us/office/ltsc/2024/overview
- Officeのボリュームライセンス認証 概要：https://learn.microsoft.com/en-us/office/volume-license-activation/plan-volume-activation-of-office
- KMSでのOffice認証：https://learn.microsoft.com/en-us/office/volume-license-activation/activate-office-by-using-kms
- MAKでのOffice認証：https://learn.microsoft.com/en-us/office/volume-license-activation/activate-office-by-using-mak
- Active DirectoryベースのOffice認証：https://learn.microsoft.com/en-us/office/volume-license-activation/activate-office-by-using-active-directory
コメント