3行まとめ
DLS 3.4.1と3.1.x LTSは、同じ月にEOLを迎える前提で棚卸しする。
2026年4月のProduction releaseとして、設定自動化、ヘルスチェック、セキュリティ更新を見る。
CLS/DLSの配置、vGPU release、node-locked licensing、旧License Serverの残存を分けて確認する。
EOLは即停止の日付ではなく、サポート、セキュリティ修正、更新入手性、運用説明の境界として扱う。
NVIDIA License SystemのDLSリリース表では、DLS 3.4.1がProduction branchとして2026年6月EOL、DLS 3.1.0から3.1.9のLTS系も2026年6月EOLとして並んでいる。
2026年4月のNVIDIA License System 3.6.1は、DLS Appliance Setup Automation tool、DLS Appliance health check endpoint、セキュリティ更新、不具合修正を含む運用保守寄りの更新として読むのが自然だ。
vGPU、RTX Virtual Workstation、Virtual Compute Serverを使う環境では、DLSだけでなく、CLS/DLSの配置、vGPU software release 13.0以降の対応、node-locked licensingの15.0以降条件、旧vGPU Software License Serverの残存まで棚卸ししたい。
NVIDIAの大型発表やGPU価格の話題は目立ちやすい。一方で、ライセンス基盤のEOLは静かに近づき、見落とすと本番運用の変更申請、保守、監視、切り戻しに響く。2026年6月15日時点でNVIDIA公式ドキュメントを確認すると、NVIDIA License SystemのDelegated License Service、以下DLSで、3.4.1と3.1.x LTSの期限が2026年6月に集中している。
この記事では、NVIDIA License System v3.6.1の公式ドキュメント、3.6.1 Release Notes、DLS Software Lifecycle、User Guide、旧NVIDIA vGPU Software License Server EOL Noticeを確認し、管理者が見る順番を整理する。NVIDIA Watch JapanはNVIDIA Corporationおよび関係会社とは非提携の独立ブログであり、実際の契約、サポート可否、ダウンロード権限、更新手順は公式ドキュメント、NVIDIA Licensing Portal、販売パートナー、NVIDIAサポート窓口で再確認してほしい。
DLS 3.4.1と3.1.x LTSの2026年6月EOLをまず固定する
- DLS 3.6.1
2026年4月のProduction release。EOLは2027年10月で、更新候補として確認する。
- DLS 3.6.0
2026年1月のProduction release。EOLは2027年6月で、3.6系の位置づけを比較する。
- DLS 3.4.1
2025年1月のProduction release。EOLは2026年6月で、残る理由と更新計画を確認する。
- DLS 3.4.0
EOLは2026年5月。3.4系に残っている環境は、台帳と実機の表記をそろえる。
- DLS 3.1.x LTS
3.1.0から3.1.9までのLTS系も、EOLは2026年6月として確認する。
LTSという名称だけで余裕を見ず、2026年6月時点で残す理由、更新できない理由、次回判断日を説明できる状態にする。
最初に見るべきなのは、3.6.1の新機能ではなく、いま動いているDLSのバージョンだ。NVIDIA License System v3.6.1のトップページにはDLSのリリース表があり、Production branchとLong-Term SupportのEOL Dateが並んでいる。
そこでは、DLS 3.6.1は2026年4月リリース、Production、EOL Dateが2027年10月と示されている。DLS 3.6.0は2026年1月、Production、EOL Dateが2027年6月だ。一方で、DLS 3.4.1は2025年1月、Production、EOL Dateが2026年6月になっている。ひとつ前の3.4.0は2026年5月EOLなので、3.4系に残っている環境は、少なくとも運用台帳上で理由を説明できる状態にしておきたい。
3.4.1はProduction branchの期限として見る
根拠
DLS 3.4.1のEOLが2026年6月と出ているからといって、その月にすべての環境が突然止まると書くのは乱暴だ。EOLは、サポート、セキュリティ修正、更新入手性、将来の障害調査、監査説明に関わる境界として読むのが実務的だ。
注意点
特にDLSは、GPUそのものではなくライセンスを配る基盤だ。普段は目立たないが、止まると仮想ワークステーションや仮想コンピュート環境の利用体験に直結する。更新作業も、単にファイルを置き換えるだけでなく、NVIDIA Licensing Portal、ライセンスサーバー、DLSインスタンス、クライアント設定、監視、バックアップ、メンテナンス時間をまたぐ。
3.1.0から3.1.9のLTSも同じ月で見る
確認項目
見落としやすいのは、3.1.x LTSだ。NVIDIA License System v3.6.1のLong-Term Support表では、DLS 3.1.0から3.1.9までがLong-Term Supportとして並び、EOL Dateはいずれも2026年6月になっている。
LTSという言葉だけを見ると、まだ余裕があるように感じやすい。しかし2026年6月時点では、3.1.xに残る理由、更新できない理由、切り替え計画、保守窓口への確認状況を持っていなければ、運用リスクを説明しづらい。DLSのログイン画面左側にあるSupportページでNVIDIA Delegated License Systemのバージョンを確認できるため、まずは実機と運用台帳の表記をそろえるところから始めたい。
3.6.1へ上げるか、CLSへ寄せるかを同時に考える
評価基準
DLSを使い続ける理由が明確なら、3.6.1を含む新しいサポート対象リリースへの更新を検討する。一方で、NVIDIA Licensing Portal側にホストされるCloud License Service、つまりCLSで運用できる環境なら、DLSアプライアンスを持ち続ける必要があるかも同時に見る。
ここで大事なのは、DLS更新とCLS移行を「どちらが上位か」という単純な話にしないことだ。閉域網、拠点ごとの分離、クライアントのインターネット到達性、運用担当、監視要件、契約管理、変更申請の重さで答えは変わる。オンプレAIやRTX PRO Serverのような自社内GPU基盤を考える読者は、<a href="https://nvda-watch.blog.mo-gmo.com/nvda-34-rtx-pro-server-blackwell-onprem-ai/" rel="noopener">RTX PRO ServerのオンプレAI導入チェック</a>と合わせて、ライセンス配布をどこで持つのかも見ておくとよい。
NVIDIA License System 3.6.1は何が変わったリリースなのか
DLSアプライアンスの設定作業を標準化する入口になる。ポータル準備とAPI key管理は別に必要。
サービス、データベース、リソース、HAノードなどを監視へ組み込む候補になる。
Docker、PostgreSQL、Python、Nginxなどの部品更新を、自社の脆弱性管理台帳と照合する。
既知の不具合修正は、対象環境の構成、運用影響、切り戻し方針と合わせて確認する。
VM型と同じ前提で見ず、ログ、NTP、IP設定、オンライン移行、HAノード停止の制約を確認する。
3.6.1はライセンス体系を読み替える材料ではなく、DLSアプライアンスの導入、監視、保守を標準化しやすくする更新として扱う。
NVIDIA License System 3.6.1は、派手なGPUローンチではない。NVIDIAのRelease Notesでは、現在の状態、対応プラットフォーム、既知の問題をまとめる文書として位置づけられている。読者が見るべき中心は、DLSアプライアンスの設定自動化、ヘルスチェック、セキュリティ更新、不具合修正だ。
3.6.1は2026年4月のProduction releaseとして読む
根拠
NVIDIA License System v3.6.1のリリース表では、3.6.1は2026年4月のProduction releaseで、EOL Dateは2027年10月と示されている。3.4.1や3.1.xから見ると、期限面では明らかに先のリリースになる。
注意点
ただし、ここで「3.6.1に上げれば解決」と急がないほうがいい。DLSはライセンス基盤なので、更新前には、バックアップ、サービスインスタンス、ライセンスサーバー、NVIDIA Licensing Portalの登録、クライアントの到達性、証明書、時刻同期、HA構成、切り戻し方針を確認する必要がある。
新機能は運用自動化とヘルスチェックに寄っている
根拠
3.6.1 Release NotesのNew Featuresには、DLS Appliance Setup Automation tool、DLS Appliance health check endpoint、Security Updates、Miscellaneous bug fixesが挙がっている。これを製品機能の大幅拡張として読むより、DLSの導入、監視、保守を標準化しやすくする更新として読むほうが実務に近い。
条件
DLS Appliance Setup Automation toolは、DLSアプライアンスの設定作業を標準化したい組織に効く。User Guideでは前提として、DLSアプライアンスとNVIDIA Licensing Portalの両方にネットワーク到達できるUnix system、事前に作成したlicense server、DlsInstallAutomationタイプのNLP API keyが必要とされている。つまり、ツールがあるからといって、ポータル準備や権限管理が消えるわけではない。
health check endpointは、監視に組み込む入口になる。ライセンス配布基盤は、問題が起きてから気づくより、サービス、データベース、リソース、アプリケーション失敗、HAノードの状態を継続して見るほうがよい。更新の目的を「新しいものへ上げる」ではなく、「監視可能な状態へ寄せる」と置くと、変更申請の説明もしやすい。
セキュリティ更新は部品名まで見る
確認項目
Release NotesのSecurity Updatesでは、DLS 3.6.1の範囲としてDocker 28.0.1、PostgreSQL 15.17、Python 3.13.12、Nginx 1.29.7が示されている。ここはセキュリティ担当や基盤担当が読みたい箇所だ。
ただし、部品名とバージョンが載っていることは、自社環境の脆弱性評価が完了したことを意味しない。DLSがVM型かコンテナ型か、周辺OSをどこまで管理しているか、ネットワーク上の露出、ログ収集、監視、証明書、管理者権限の扱いでリスクは変わる。自社の脆弱性管理台帳に、DLS 3.6.1の部品更新がどう映るかを照合する必要がある。
コンテナ型DLSの制約も読み飛ばさない
注意点
3.6.1 Release Notesには、containerized DLS software imageの制約も出ている。コンテナオーケストレーション基盤は基盤OSへのアクセスを制御できないため、VM型DLS virtual applianceに依存する一部機能をそのまま持てない。Log archive settings、NTP configuration、Static IP address configuration、DLS diagnostics user configuration、Disk expansionなどは、標準OS側の機能で代替する扱いになる。
さらに、VM-based DLS virtual applianceからcontainerized DLS software imageへのonline migrationはサポートされない。移行先コンテナがデータ移行後もIPアドレスを保持するため、VM型からコンテナ型へ移る場合はoffline migrationを使うと説明されている。HA clusterからsecondary nodeを外した場合も、該当するDLS containerは自動停止しないため、手動で止める必要がある。
この制約は地味だが重要だ。コンテナ化すれば保守が軽くなる、という一般論だけでDLSを動かすと、移行時の停止計画やHA運用でつまずく。
CLSとDLSを同じライセンス基盤として混同しない
- 1クライアントの到達性
ライセンスクライアントがNVIDIA Licensing Portal側へ到達できるかを確認する。
- 2ポータル側で運用できるか
契約、組織管理、ポータル権限、クライアント設定が整うならCLSを検討する。
- 3閉域や拠点分離が必要か
外部へ出にくい環境や拠点内で完結したい環境では、DLSを置く理由を整理する。
- 4DLSを持つ責任
アプライアンス更新、バックアップ、HA、監視、証明書、EOL管理を自社で持てるかを見る。
- 5クライアント設定を別確認
CLSかDLSかを決めた後も、vGPUドライバ、FeatureType、到達性確認は別に残る。
CLSはNVIDIA Licensing Portal側にホストされ、DLSはオンプレミスに置く選択肢。HA clusterではCLSとDLSを混在できない点も先に確認する。
NVIDIA License Systemでは、ライセンスを提供するservice instanceが必要になる。User Guideでは、Cloud License Service instanceとDelegated License Service instanceの2種類が説明されている。CLSはNVIDIA Licensing Portalにホストされる。DLSは、プライベートネットワークからアクセスできるオンプレミスの場所、たとえばデータセンター内にホストされる。
CLSはNVIDIA Licensing Portal側にホストされる
条件
CLSの利点は、DLSアプライアンスを自前で保守しないことだ。NVIDIA Licensing Portal側でホストされるため、DLSのVMやコンテナ、HA、バックアップ、アプライアンスEOLを自社で抱える必要は小さくなる。
ただし、CLSにすればすべてが自動で解決するわけではない。クライアントがNVIDIA Licensing Portal側のサービスへ到達できるか、社内ネットワークやプロキシの条件を満たせるか、契約と組織/virtual groupの管理が整っているか、障害時の切り分けを誰が行うかは別の確認事項だ。
DLSはプライベートネットワーク内に置くオンプレミスの選択肢
評価基準
DLSは、ライセンスクライアントが外部へ出にくい環境、閉域網で運用したい環境、拠点ごとにライセンス配布を完結したい環境で候補になる。User Guideでは、DLS instanceはNVIDIA Licensing Portalから完全に切り離された状態で動作し、ライセンスをポータルからダウンロードしてDLS instanceへ手動でアップロードする必要があると説明されている。
この「完全に切り離せる」性質は、強みであると同時に運用責任でもある。DLSを選ぶなら、アプライアンス更新、バックアップ、HA、監視、証明書、ネットワーク到達性、EOL管理を自社で持つことになる。
HA clusterではCLSとDLSを混ぜられない
注意点
User Guideには、service instanceのHA clusterではCLSとDLSを混在できず、各ノードはDLS instanceでなければならないという注意がある。これも設計上の落とし穴になりやすい。
たとえば「通常はDLS、障害時だけCLS」といった感覚で設計すると、公式ドキュメントのHAモデルとずれる。CLSとDLSの使い分けは、可用性設計、ネットワーク設計、運用手順として最初から分けて考えるべきだ。
どちらを選んでもクライアント設定は別に確認する
確認項目
CLSかDLSかを決めても、vGPUドライバ、ライセンスクライアント設定、ライセンス種別、FeatureType、到達性確認は別に残る。ライセンス基盤側の更新と、クライアント側の設定確認を混ぜないことが大切だ。
自己ホストNIMやAI Enterpriseとの境界を考える場合は、<a href="https://nvda-watch.blog.mo-gmo.com/nvda-37-nim-api-selfhost-ai-enterprise-checklist/" rel="noopener">NVIDIA NIMアクセス確認の記事</a>も合わせて読むと、API、自己ホスト、AI Enterpriseの分岐と、ライセンス/サポート確認の位置づけを分けやすい。
vGPU、RTX Virtual Workstation、Virtual Compute Server側の棚卸しを入れる
DLSのバージョンを上げても、クライアント側の対応範囲、設定、実機のライセンス状態を確認しなければ運用判断は完了しない。
DLSのEOLだけを見て更新しても、クライアント側が条件外なら安心できない。NVIDIA License System 3.6.1 Release Notesでは、licensed client supportとして、NVIDIA vGPU software graphics driversはrelease 13.0以降が対応範囲として示されている。また、node-locked licensingはNVIDIA vGPU software 15.0で導入され、それ以前のリリースではサポートされない。
vGPU software release 13.0以降かを確認する
まず確認したいのは、手元のvGPU software releaseだ。release 13.0以降ならNVIDIA License Systemの対応範囲に入るが、どのブランチで、どのハイパーバイザーで、どのゲストOSで、どのGPUプロファイルを使っているかは環境ごとに違う。
特に古いvGPU環境では、ライセンスサーバーだけでなく、ハイパーバイザー、vGPU Manager、ゲストドライバ、CUDA、アプリケーション、ユーザーへの提供形態が絡む。DLSのバージョンだけ新しくしても、クライアント側のライセンス状態を確認しないまま本番へ入れるのは避けたい。
node-locked licensingは15.0以降として分ける
node-locked licensingは、ネットワークに接続されていない、またはエアギャップ環境にあるクライアントが、ローカルに置いたファイルからNVIDIA vGPU software licenseを取得する仕組みとして説明されている。User Guideでも、node-locked licensingはvGPU software 15.0で導入され、それ以前ではサポートされないと明記されている。
ここは、DLS/CLSの話と混ぜないほうがよい。DLSはネットワーク上のライセンス配布基盤であり、node-locked licensingはクライアント側でファイルを使う別の考え方だ。閉域だからDLS、エアギャップだからnode-locked、と短絡せず、対象リリース、契約、運用手順、ライセンスファイルの有効期限、監査方法を確認する必要がある。
RTX Virtual WorkstationとVirtual Compute ServerはFeatureTypeも見る
User GuideのLinux licensed client設定では、物理GPUで使うFeatureTypeの例として、NVIDIA Virtual Applications、NVIDIA RTX Virtual Workstation、NVIDIA Virtual Compute Serverが示されている。つまり、製品名だけでなく、クライアントがどのライセンス機能を要求しているのかも見る必要がある。
RTX Virtual Workstationは、ユーザーが仮想ワークステーションとして使う体験に近い。Virtual Compute Serverは、GPU計算やサーバー側ワークロードに寄る。どちらも同じDLSやCLSにぶら下がる可能性があるが、利用者、担当部署、SLA、監視指標は違う。更新前の棚卸しでは、GPU、vGPU release、ライセンス種別、FeatureType、クライアント設定、確認担当を表にしておくと、抜けが減る。
DLS 3.4以上の前提が出る箇所は対象vGPUリリースと合わせて読む
User Guideには、DLSを使う場合、少なくともDLS virtual appliance 3.4が必要という注意が出る箇所がある。これは、対象のvGPU software releaseやNVIDIA License Systemの世代と合わせて読むべき条件だ。
2026年6月にDLS 3.4.1がEOLへ向かう一方で、vGPU側の手順にはDLS 3.4以上という前提が残る。ここを「3.4でよい」と読んでしまうと、EOL管理と導入要件を混同する。導入要件を満たすことと、サポート期限内で運用することは別だ。
旧NVIDIA vGPU Software License Serverが残っていないかを見る
- 1現行構成を確認
名前ではなく、実際に旧License Server、DLS、CLSのどれでライセンスを配っているかを見る。
- 2旧License Server
2023年7月31日にEOL済み。新機能、修正、セキュリティ更新、技術サポート、ダウンロードの制約を確認する。
- 3read-onlyと変換経路
残存環境はread-onlyの扱いと、NVIDIA License Systemへの変換手順を確認する。
- 4DLSの場合
DLS 3.4.1や3.1.x LTSの2026年6月EOLと、更新計画を別作業として管理する。
- 5CLSの場合
ポータル到達性、契約、組織管理、クライアント設定が整っているかを確認する。
旧NVIDIA vGPU Software License Serverの2023年EOLと、DLS 3.4.1/3.1.xの2026年6月EOLは、根拠文書も対処も別の問題として扱う。
もうひとつ分けておきたいのが、旧NVIDIA vGPU Software License Serverだ。これはDLS 3.4.1や3.1.xの2026年6月EOLとは別の問題で、すでに2023年7月31日にEOLを迎えている。
旧License Serverは2023年7月31日にEOL済み
NVIDIA Virtual GPU Software License Server EOL Noticeでは、旧NVIDIA vGPU Software License Serverが2023年7月31日にEnd of Lifeとなり、その後は新機能、性能改善、不具合修正、セキュリティ更新、技術サポート、ソフトウェアダウンロードがなくなると説明されている。
この通知は、DLS 3.4.1の2026年6月EOLとは根拠文書も対象も違う。旧License Serverの問題は、NVIDIA License System以前の古いライセンス基盤が残っていないかを見る話だ。
既存環境が残る場合は読み取り専用と変換経路を確認する
EOL Noticeでは、既存のlegacy NVIDIA vGPU software license serverがデータセンター内に展開済みであれば、それ自体は変わらず残り、read-only modeで機能し続けることも説明されている。また、NVIDIA License System documentationにある手順でNLS serverへ変換できることも案内されている。
つまり、旧License Serverが残っているから即障害と決めつけるべきではない。ただし、管理、ダウンロード、サポート、セキュリティ更新、将来の変更に制約がある。いま旧License Server、DLS、CLSのどれでライセンスを配っているのかを、名前ではなく実構成で確認する必要がある。
3.4.1/3.1.x EOLと旧License Server EOLを混ぜない
社内説明では、ここが混ざりやすい。「ライセンスサーバーがEOL」という言葉だけだと、旧vGPU Software License Serverの2023年EOLなのか、DLS 3.4.1や3.1.xの2026年6月EOLなのか分からない。
整理するなら、次の3分類で見るとよい。
- 旧NVIDIA vGPU Software License Serverが残っているか。
- NVIDIA License SystemのDLSを使っており、そのDLSバージョンが何か。
- CLSを使っており、クライアントとNVIDIA Licensing Portalの到達性、契約、組織管理が整っているか。
この分類ができていれば、旧構成の移行、DLS更新、CLS利用の検討を別々の作業として管理できる。
更新前チェックリストはポータル、DLS、クライアント、監視に分ける
更新可能、要追加確認、延期のどれに置くかは、権限、バックアップ、クライアント検証、監視、切り戻しが説明できるかで決める。
ライセンス基盤の更新は、ひとつの作業に見えて、実際には複数の担当領域に分かれる。だからこそ、更新前チェックリストは、ポータル、DLS、クライアント、監視、切り戻しに分けたい。
ポータルと契約状態を先に確認する
最初はNVIDIA Licensing Portalだ。組織またはvirtual groupへアクセスできるか、対象ライセンスが見えるか、license serverやservice instanceの管理権限があるか、必要なダウンロード権限やSUMSの状態に問題がないかを確認する。
DLS Appliance Setup Automation toolを使う場合も、事前にlicense serverを作成しておく必要があり、DlsInstallAutomationタイプのNLP API keyも必要になる。ポータル準備が曖昧なままDLS更新を始めると、アプライアンス側ではなく権限側で止まる。
DLSアプライアンスは更新前後で証跡を残す
DLS側では、現行バージョン、インストール形態、VM型かコンテナ型か、HA構成、バックアップ、ライセンスプール、証明書、時刻同期、IPアドレス、DNS、管理者アカウント、ログ収集、メンテナンス時間を記録する。
更新後は、Supportページでバージョンを確認し、ライセンスが配れること、クライアントがライセンスを取得できること、監視が正常に戻ることを確認する。3.6.1のhealth check endpointは、更新後の監視項目として候補になるが、監視設計そのものは自社の運用に合わせる必要がある。
クライアント側はライセンス状態を実機で確認する
クライアント側では、vGPU software release、ゲストドライバ、ライセンス種別、FeatureType、CLS/DLSへの到達性を確認する。User Guideでは、licensed client上でnvidia-smi -qまたはqueryオプションを使い、License StatusやLicensed Product Nameを確認する手順が示されている。
ここで重要なのは、ハイパーバイザホストだけを見て終わらないことだ。実際にライセンスを消費するクライアントで、ライセンス取得、返却、再起動後の状態、ネットワーク断後の挙動を確認する。
本番前に小さな検証枠を作る
本番全体を一気に更新する前に、代表的なVM、代表的なGPUプロファイル、RTX Virtual Workstation、Virtual Compute Server、管理者端末、監視経路を含む小さな検証枠を作る。そこで、DLS更新、クライアント起動、ライセンス取得、再起動、ネットワーク断、ライセンス返却、ログ確認を一通り見る。
Go/No-Goの判断は、次のように分けると会議に持ち込みやすい。
- 更新可能: ポータル権限、DLSバックアップ、クライアント検証、監視、切り戻しが揃っている。
- 要追加確認: バージョンは対象内だが、契約、権限、HA、クライアント設定、監視に未確認がある。
- 延期: EOL対象の把握が未完了、旧License Serverが残る、クライアントがNLS対応範囲外、切り戻しが説明できない。
最後は2026年6月中に決める3つに絞る
オンプレにDLSを置く理由があり、EOL対象に残っているなら、3.6.1を含むサポート対象リリースへの計画を作る。
クライアント到達性、契約、ポータル管理、組織運用が整うなら、DLSを持ち続ける必要を見直す。
すぐ更新できない場合は、DLSバージョン、EOL、残るリスク、期限、次回判断日、承認者を残す。
現行維持は失敗ではないが、理由、期限、承認がないまま動いている状態を続けるのが一番危ない。
この記事の結論は、全員がすぐ3.6.1へ上げるべき、という話ではない。2026年6月時点で放置しないために、次の3つを決めることだ。
DLSを更新する
オンプレにDLSを置く理由があり、3.4.1や3.1.x LTSに残っているなら、3.6.1を含むサポート対象リリースへの更新計画を作る。更新理由は、期限延長だけでなく、DLS Appliance Setup Automation tool、health check endpoint、セキュリティ更新、既知影響のある不具合修正も含めて説明できる。
CLSを検討する
クライアントのネットワーク到達性、契約、ポータル管理、組織運用が整うなら、CLSへ寄せる選択肢もある。DLSアプライアンスを持ち続ける理由が弱い環境では、DLS更新の前にCLSで運用できないかを一度見る価値がある。
現行維持にはリスク承認を残す
すぐ更新できない環境もある。閉域網、古いvGPUブランチ、旧アプリケーション、変更凍結期間、契約更新待ちなど、理由はさまざまだ。その場合は、現行維持を曖昧にせず、DLSバージョン、EOL、残るリスク、期限、次回判断日、承認者を残す。何となく動いているから放置するのが一番危ない。
NVIDIAの公式ドキュメント更新やライフサイクル変更を追いたい場合は、<a href="https://nvda-watch.blog.mo-gmo.com/newsletter/" rel="noopener">ニュースレター</a>で更新通知を受け取れる。月次の流れを確認したい場合は、<a href="https://nvda-watch.blog.mo-gmo.com/monthly-topics-2026-06/" rel="noopener">2026年6月の重要トピックまとめ</a>にも戻れる。
次に読むなら
参照した主な情報源
- NVIDIA License System v3.6.1: https://docs.nvidia.com/license-system/latest/index.html
- License System Release Notes v3.6.1: https://docs.nvidia.com/license-system/latest/nvidia-license-system-release-notes/index.html
- NVIDIA Delegated License Service Software Lifecycle: https://docs.nvidia.com/license-system/latest/nvidia-dls-software-lifecycle-policy/index.html
- License System User Guide: https://docs.nvidia.com/license-system/latest/nvidia-license-system-user-guide/index.html
- NVIDIA Virtual GPU Software License Server End of Life Notice: https://docs.nvidia.com/vgpu/news/vgpu-software-license-server-eol-notice/index.html
更新履歴
- 2026年6月15日: NVIDIA公式ドキュメントでDLS 3.4.1、3.1.x LTS、3.6.1 Release Notes、CLS/DLS、旧vGPU Software License Server EOLを確認して初稿を作成。