時刻同期というとサーバーを思い浮かべますが、ネットワーク機器、ESXiやvCenter、ストレージや複合機など、サーバー以外の機器の時刻も障害対応を左右します。そして仮想基盤では、ホストの時刻がVMの時刻を引き戻すことがあります。

第4回・第5回でLinuxとWindowsを見ました。第6回では、ネットワーク機器と仮想基盤、アプライアンスの時刻同期を扱います。

ネットワーク機器の時刻同期の考え方

ルーター、スイッチ、ファイアウォール、無線LANコントローラーなどのネットワーク機器も、ほぼすべてがNTPクライアントの機能を持ちます。

• 機器の時刻がずれると、障害のときにサーバーのログと機器のログを突き合わせられず、原因の特定が大きく遅れる。VPNの証明書の検証や、RADIUS・TACACS+のログ（連載「RADIUS入門」第16回「ログと監査」）、SNMPトラップの時刻にも影響する
• 設計の考え方はサーバーと同じで、社内のNTPサーバー（第7回）を2〜3台以上参照し、送信元のインターフェースを管理用のアドレスに固定して、ファイアウォールやアクセスリストの設定を単純にする
• 電源を切ると時刻を失う機器も多いため、起動直後の時刻にも注意する
• ログに記録するタイムゾーンと、ミリ秒まで記録するかどうかを全機器でそろえておくと、突き合わせが楽になる。対称鍵による認証（第8回）に対応した機種なら、有効にすることも検討する

冒頭の「ルーターとサーバーのログの順番がおかしい」は、時刻のずれか、タイムゾーン・精度の違いが原因のことが多いです。

Cisco IOSの設定例と確認

Router(config)# ntp server 192.0.2.123 prefer
Router(config)# ntp server 192.0.2.124
Router(config)# ntp source Loopback0
Router(config)# clock timezone JST 9 0
Router(config)# service timestamps log datetime msec localtime show-timezone

Router# show ntp status
Clock is synchronized, stratum 3, reference is 192.0.2.123
Router# show ntp associations
  address         ref clock       st   when   poll reach  delay  offset   disp
*~192.0.2.123     203.0.113.1      2     35     64   377  1.012   0.254   0.188
+~192.0.2.124     203.0.113.2      2     20     64   377  1.105  -0.132   0.201
 * sys.peer, # selected, + candidate, - outlyer, x falseticker, ~ configured

• 出力は要所だけの抜粋。show ntp statusの1行目がClock is synchronizedか、stratumが期待どおりかを見る
• show ntp associationsの記号は、chronyと似ている：*同期先、+候補、x誤り、~設定したサーバー。reachは8進数（第4回）
• service timestamps log datetime msec …で、ログにミリ秒とタイムゾーンを残す
• 機種・OS（IOS XE、NX-OS、各社のファイアウォール）で書式は異なる。考え方（参照先・送信元・タイムゾーン・確認）を押さえ、書式は機種の手引で確かめる

ログのタイムスタンプの形式をそろえる

時刻が合っていても、ログの書き方がばらばらだと突き合わせに苦労します。syslogには、古い形式と新しい形式があります。

Sep 26 16:20:01 rt01 %LINK-3-UPDOWN: Interface Gi0/1, changed state to down
      ↑ RFC 3164 の形式：年・タイムゾーン・ミリ秒が無い
2026-09-26T16:20:01.123+09:00 rt01 LINK - - - Interface Gi0/1, changed state to down
      ↑ RFC 5424（RFC 3339 の日時）：年・ミリ秒・UTC からのオフセットがある

• 古い形式（RFC 3164）の「Sep 26 16:20:01」には、年もタイムゾーンもミリ秒も無い。年をまたぐ調査や、UTCで記録する機器との突き合わせで迷う
• 機器が対応していれば、RFC 5424の形式（2026-09-26T16:20:01.123+09:00のように年・ミリ秒・オフセット付き）で送る。Ciscoなら前の節のservice timestamps log datetime msec … show-timezoneが近い効果を持つ
• ログの収集基盤では、「機器が記録した時刻」と「受け取った時刻」を両方残す。機器の時計がずれていても、受け取った時刻から、おおよその順序を復元できる

時刻を合わせることと、時刻を読める形で残すことは、セットで考えます。

機器をNTPサーバーにするかどうか

ネットワーク機器の多くは、NTPサーバーとしても動けます。IOSなどでは、NTPを設定して同期すると、ほかの機器からの問い合わせにも応答するのが一般的です。

• 利点：拠点のコアスイッチを拠点内の機器の時刻源にすると、WANが切れても拠点内の時刻がそろう
• 欠点：機器の内蔵時計は品質が高くないことが多く、CPUの負荷が高いと応答の精度が落ちる。また、意図せず利用者のネットワークやインターネットにNTPを公開すると、増幅攻撃の踏み台や情報の漏えい（第8回）につながる

基本の方針は、サーバーや端末は社内のNTPサーバー（第7回）を直接参照し、機器を時刻源にするのは拠点の事情がある場合に限ることです。機器を時刻源にするときは、応答する相手をアクセスリスト（Ciscoではntp access-group）で絞り、参照の関係を構成図に残して、階層が循環しないようにします。

ESXi（ESX）ホストの時刻同期

[root@esx01:~] esxcli system ntp set -s ntp1.corp.example.jp -s ntp2.corp.example.jp -s ntp3.corp.example.jp -e 1
[root@esx01:~] esxcli system ntp get
[root@esx01:~] esxcli system time get

• ESXi（vSphere 9.0からの名称はESX）はUTCで動き、タイムゾーンは変えられない（vSphere Clientでは見る人の現地時刻で表示）
• 7.0 U3以降は設定がConfigStoreで管理され、/etc/ntp.confを直接編集しても正しく反映されない
• NTPサービスの起動ポリシーは「ホストと連動して開始・停止」にする

vCenterの時刻同期

# 管理インターフェース（https://vcenter01.corp.example.jp:5480）の Time でも設定できる
Command> ntp.set --servers ntp1.corp.example.jp,ntp2.corp.example.jp,ntp3.corp.example.jp
Command> ntp.test --servers ntp1.corp.example.jp,ntp2.corp.example.jp,ntp3.corp.example.jp
Command> timesync.set --mode NTP
Command> timesync.get

vCenterとホストの時刻がずれると、SAMLトークンや証明書が有効と認識されず、インストール・アップグレードの失敗や、vCenterのサービス（vpxd）が起動しない原因になります（Broadcom TechDocs）。デプロイや移行の前に、配置先のホストがNTPかPTPで同期していることを確かめます。

ホストの時刻とVMの時刻

冒頭の「vMotionでVMの時刻が3分進んだ」の答えです。

vMotion の後に VM の時刻が飛ぶのはなぜ？

• VMware Toolsの「周期的な時刻同期」（1分ごとにホストに合わせる）は既定で無効で、ゲストOSのNTP（chrony、W32Time）を使うのが推奨
• ただし、VMの起動、一時停止からの再開、vMotion、スナップショットの作成と復元、VMware Toolsの再起動のときの「一回限りの同期」は既定で有効
• ホストの時刻がずれていると、vMotionの後にVMの時刻が突然ずれる。ゲストのNTPが正しくても、ホストの時計がVMを引き戻す
• 対策は、全ホストを同じ時刻源に同期させること。一回限りの同期を止めたいVMは「Synchronize at startup and resume」を外せる
• 高い精度が要るVMには、仮想ハードウェア17以降のPrecision Clock（ホストの時刻をPTPハードウェアクロックとして見せる仮想デバイス）もある

ホスト・vCenter・VM を同じ時刻源にそろえる

vSphereの時刻は、ホスト・vCenter・VMを同じ時刻源にそろえるのが基本です。

vMotion がメモリーをコピーしながらホストを切り替える仕組みと、vSphere Client での実行の手順は、過去の記事「VMware vSphere – ライブマイグレーション (vMotion と Storage vMotion)」で紹介しています。

ストレージ・監視・複合機などのアプライアンス

NTPの設定画面が無い機器や、参照先を1台しか書けない機器もあります。導入時にNTPの対応（台数、DNS名を書けるか、認証やNTS）を確かめ、参照先を台帳に残します。古い機器は、停止した・停止予定の公開NTPサーバー（福岡大学など。第7回）を参照したままのことがあります。

時刻のずれが障害になる例

障害の調査では、まず関係する機器の時刻を並べて比べます。時刻そのものが原因の障害もあれば、時刻のずれのせいで調査を誤る場合もあります。切り分けの手順は第10回で扱います。

参考資料

この回の内容に対応する公式の文書・標準です（2026年11月に確認）。仕様・既定値・利用条件は変わることがあるので、使う前に最新の内容を確かめてください。

• Synchronizing Clocks on the vSphere Network（Broadcom TechDocs、vSphere 8.0）：「ESXi（ESX）ホストの時刻同期」
• Configure the System Time Zone and Time Synchronization Settings（Broadcom TechDocs、vSphere 8.0）：「vCenterの時刻同期」
• Disabling Time Synchronization for virtual machines（Broadcom の技術情報 326306）：「ホストの時刻とVMの時刻」の VMware Tools の時刻同期
• vSAN Health Service – Cluster Health – Time Synchronization Across Hosts and VC（Broadcom の技術情報 326424）：「時刻のずれが障害になる例」の vSAN の健全性チェック

考えてみよう

1. 自分の職場のネットワーク機器、ESXi、vCenter、複合機などは、それぞれどこを時刻源にしていますか。台帳にできますか。
2. 「vMotionの後にVMの時刻が数分ずれた」と報告を受けました。何を疑い、どこから確かめますか。
3. 拠点のコアスイッチをNTPサーバーにしたいと相談されたら、何を確かめ、どんな条件を付けますか。

ヒント：この記事の「機器をNTPサーバーにするかどうか」の方針、ESXi・vCenter・ホストとVMの関係の図、アプライアンスの表と台帳が手がかりです。

まとめ

• ネットワーク機器も社内NTPを複数参照し、送信元を管理用に固定、ログのタイムゾーンとミリ秒をそろえる
• Ciscoはshow ntp status・show ntp associationsで確認。記号はchronyと似ている（~・-などは意味が違う）
• 機器をNTPサーバーにするのは拠点の事情があるときだけ。応答範囲をアクセスリストで絞る
• ESXiはUTC固定、esxcli system ntpで3台以上。vCenterはtimesync.set --mode NTP
• 一回限りの同期は既定で有効。ホストがずれているとvMotionでVMの時刻が飛ぶ
• アプライアンスは設定漏れが多い。時刻源の台帳で棚卸しする

次回は、ここまでの内容をもとに社内の時刻同期の階層を設計し、公開NTPサーバーやクラウドの時刻の使い方を扱います。

連載「NTP入門」全11回

全回の目次と、読む順番・目的別の読み方は、NTP入門の入口のページにまとめています。

1. なぜ時刻同期が必要か
2. 時刻の基礎知識
3. NTPの仕組み
4. Linuxの時刻同期（chrony）
5. Windowsの時刻同期
6. ネットワーク機器・仮想基盤（この記事）
7. 設計と推奨構成
8. NTPのセキュリティ
9. PTPと高精度同期
10. 時刻同期のトラブルシュート
11. 時刻同期の設計演習

連載「証明書入門」も、いよいよ最終回です。第1回から第10回まで、暗号の基礎から証明書の中身、PKI、TLS、発行と自動化、社内PKIとクラウド、トラブルシュートまでを見てきました。最終回は、それらを実際の場面で使うための設計演習です。

5つの問題を用意しました。どれも現場で本当によく出会う状況をもとにしています。解答例を見る前に、ぜひ一度自分で考えてみてください。

▶ この回の内容は、YouTube の動画（約15分）でも見られます（記事の最後にも埋め込んであります）。

演習の進め方

1. 問題を読む：要件に線を引き、書かれていない条件（体制、予算、規程、将来の拡張）は仮定する
2. 5分考える：選ぶ案と理由、確かめるコマンドを書く
3. 比べる：同僚やチームで共有できるなら、ほかの人の案と比べる
4. 解答例と解説を読む：決め手になった要件を確かめる

正解は1つではありません。案の良し悪しより、理由の筋道を比べることが大切です。

問1 Webサーバー2台とロードバランサーの証明書

• 状況：会員向けのサイトを、ロードバランサー（冗長ペア）とWebサーバー2台（web01・web02）で公開します。利用者はhttps://www.example.jp/とhttps://example.jp/の両方でアクセスします
• 要件①：/api/へのアクセスだけを別のサーバー群に振り分けます。ログインした利用者は、Cookieで同じサーバーに届けます
• 要件②：情報セキュリティの規程で「利用者からWebサーバーまで、経路上はすべて暗号化する」と定められています
• 要件③：来年、shop.example.jpを同じロードバランサーで公開する予定です

考えるポイント：TLSをどこで終端するか、証明書の枚数と名前（SAN）、秘密鍵を置く場所の数、更新の手間

問1 解答例

要件①②から案Bが有力です。利用者に見える名前は1つのサイトなので、公開証明書は1枚で足ります（台数ではなく名前で数える）。example.jpとwww.example.jpはSANに並べ、ワイルドカードを使わずに済ませます。

問1 解説

証明書の枚数は「利用者が使う名前」で、置き場所は「TLSをどこで終端するか」で決まります（第9回）。

• 案Bでは、利用者向けの公開証明書はLBの1枚だけで、Webサーバーの証明書はLBだけが見る社内向けのもの
• 再暗号化の区間では、LBがWebの証明書を検証するかどうかまで決める。AWSのALBはターゲットの証明書を検証しないため自己署名でも通信できるが、オンプレのLBで検証を有効にするなら、社内CAのルートをLBに登録する（ALB はクラウド入門 第4回、ACM はクラウド入門 第9回）
• 要件③のshop.example.jpは、SNIで証明書を切り替えられるので、同じLBに2枚目を追加するだけ。Webは触らない
• ワイルドカード（*.example.jp）にまとめると、鍵が漏れたときの影響がすべてのサブドメインに及び、example.jp自体も含まれない（第6回）

問2 47日化に向けた運用の見直し

• 状況：社内で管理している公開証明書は約40枚です。台帳は表計算ソフトで、最後に更新した担当者は異動しました。多くはOV証明書を毎年購入し、手作業で入れ替えています
• 内訳：AWSのALB（ACMを使用）8枚、オンプレのWebサーバー（Apache・IIS）15枚、メールサーバー（SMTP・IMAP）3枚、VPN装置・WAF・ロードバランサーなどの機器10枚、用途不明4枚
• 背景：公開証明書の有効期間は、2026年3月から最長200日になり、2027年3月に100日、2029年3月に47日へ短くなります（第6回）
• 要件：期限切れによるサービスの停止をなくし、担当者1人あたりの作業を増やさないこと

考えるポイント：最初に何をするか、自動化できるものとできないものの分け方、期限の監視のしかた

問2 解答例

案Bが有力です。案Cは、社内だけで使う名前にだけ当てはまります（問3）。期限の直前ではなく余裕を持って更新するため、47日のときの実際の更新は年に8回より多くなります。Aは回数に比例して増え、Bは最初に作業を前払いする、という違いです。

問2 解説：移行の進め方

自動化の本当の目的は、更新を「人が思い出して行う作業」から「失敗したときだけ人が呼ばれる仕組み」に変えることです。そして、知らない証明書は自動化できない。だから棚卸しが1段目です。CAAの書き方は、連載「DNS入門」の第6回（リソースレコード 後編）を参照してください。

問3 社内システム用の証明書をどう用意するか

• 状況：ADドメインはcorp.example.jpで、社内のWebシステムが約50あります（app01.corp.example.jpなど）。corp.example.jpは社内のDNSだけで引け、外部には公開していません（連載「DNS入門」第2回）
• 端末：ドメインに参加したWindows PC 800台、Mac 50台とiPhone 300台（MDMで管理）、Linuxサーバー40台
• 現状：各システムは自己署名証明書で、利用者は証明書の警告を「詳細設定 → 進む」で回避しています
• 要件：警告をなくし、今後増えるシステムにも手間をかけずに証明書を出せること。社内のホスト名の一覧は外部に知られたくない

考えるポイント：公開CAか社内CAか、ルート証明書の配り方、更新の自動化、自己署名を続けてはいけない理由

問3 解答例と解説

要件から案Bが有力です。「社内のホスト名を外に知られたくない」という要件が、案Aを外す決め手になります（公開CAの証明書はCTログに載る）。

• ドメイン参加のWindowsは、エンタープライズCAのルートを自動で信頼するが、それ以外の端末には明示的に配る
• 社外からも使うシステムだけ、案Aにする
• 公開CAのワイルドカード（*.corp.example.jp）なら個々の名前はCTに出ないが、50のシステムに同じ鍵を配ることになる

CAを作る手間より、ルートを配る先の数が作業量を決めます。案Cの自己署名を続けると、第1回・第6回で見たとおり、警告を回避する習慣が残り、本物の攻撃を見過ごす原因になります。

問4 「一部の端末だけ証明書エラーが出る」

• 状況：社内ポータルportal.corp.example.jp（IIS、社内CAの証明書）について、月曜の朝に「証明書エラーが出る」と連絡が入りました。先週末、発行CAを新しいサーバーへ移行し、ポータルの証明書も新しい発行CAのものに入れ替えています
• 報告①：新しく導入したMac 10台で、ChromeにNET::ERR_CERT_AUTHORITY_INVALIDが出る
• 報告②：LinuxのバッチサーバーからAPIを呼ぶと、curl: (60) ... unable to get local issuer certificate (20)で失敗する
• 報告③：工場のWindows PC 1台だけNET::ERR_CERT_DATE_INVALIDが出る。ほかのWindows PC（ドメイン参加）は正常に開ける

考えるポイント：報告ごとに原因は同じか、どの順に何を確かめるか、どこを直すか

問4 解答例と解説

答えは案Bです。同じ証明書なのに端末によって結果が分かれるのは、原因が3つ別々だからです（第10回）。

1. 報告を端末の種類で分ける（Mac／Linux／工場のPC）
2. 報告②（Linux）：openssl s_client -showcertsで0番しか無ければ、IISに新しい中間証明書を入れ忘れている（WindowsやChromeはAIAで補うため気づかない）→ IISのCert:\LocalMachine\CAに追加
3. 報告①（Mac）：MDMの構成プロファイルに新しい社内ルートが入っていない → MDMで配る
4. 報告③（工場のPC）：w32tm /query /statusで時刻を確かめる → NTPに合わせる

サーバー側から確かめると、影響の広い原因から片付きます。案Aの「回避」は、第10回で見たとおり、その端末だけを無防備にするので避けます。

問5 vCenter・ESXiの証明書を社内CAのものにする

• 状況：vCenter Server 1台（vcsa01.corp.example.jp、vSphere 8.0 Update 3）とESXi 8台で、ESXiは今後も増える予定です。証明書は構築時のまま（VMCAの既定）です
• 監査の指摘：「管理者がvSphere Clientを開くと証明書の警告が出る。社内CAの証明書にすること」
• PKI担当（AD CSの2層構成）の方針：「発行CAの下にCAを作ることは、原則として認めない（例外は申請と審査が必要）」
• 運用：vSphereの管理者は2名で、ESXiの追加や入れ替えは年に数回あります。ESXiのHost Clientを直接開くのは障害のときだけです

考えるポイント：VMCAをどう使うか、社内CAから何を何枚もらうか、更新の手間と、ホストを増やすときの手間

問5 解答例

方針と台数から、まず案Bが有力です。「発行CAの下にCAを作らない」という方針が案Aを、「ESXiが今後も増える」という運用が案Cを外す決め手になります。ESXiの証明書も社内CAにそろえる必要が出たら、PKI担当と合意して案Aに移ります。案Cは、規程でVMCAを使えない場合の選択肢です（第9回）。

問5 解説：置き換えの注意点

vCenter 8.0 Update 3h以降は、VMCAが発行したMachine SSL証明書を期限の5日前に自動更新します（案Bで社内CAの証明書にした部分は対象外）。手順は版ごとに違うため、Broadcom TechDocsの該当するバージョン（vSphere 8.0／9.0の「vSphere Authentication」）で確認してください。

連載を終えて

5つの問題、いかがでしたか。どの問題も、答えを知っているかどうかより、「どの要件が決め手か」と「誰が、どの名前の、どの鍵を、誰の署名で信じているか」を言えるかどうかが大事でした。

11回にわたって、暗号の基礎から証明書の中身、PKI、TLS、発行と自動化、社内PKIとクラウド、トラブルシュートまでを見てきました。証明書は「期限が来たら更新するもの」と思われがちですが、その裏には、通信の安全を支える仕組みがぎっしり詰まっています。そして有効期間が47日へ短くなる今、証明書の運用は「人が思い出して行う作業」から「仕組み」へと変わろうとしています。

この連載が、証明書のエラーが出たときに「警告を無視して進む」以外の手を打つための、そして自動化へ踏み出すための手がかりになればうれしいです。まずは自分が管理するサイトにopenssl s_client -showcertsを実行して、送られているチェーンと期限を確かめてみてください。

同じ形の設計演習は、連載「DNS入門」第12回と連載「メール入門」第12回にもあります。

最後まで読んでいただき、ありがとうございました。

動画で見る

この回の内容を、YouTube の動画（約15分）でも解説しています。

連載の全回は、YouTube の再生リスト「証明書入門」にまとめています。

連載「証明書入門」全11回

全回の目次と、読む順番・目的別の読み方は、証明書入門の入口のページにまとめています。

1. なぜ証明書が必要か
2. 暗号の基礎
3. openssl・PowerShellで試す
4. X.509証明書の中身
5. PKIと信頼の仕組み
6. 証明書の種類と発行
7. TLSの仕組み
8. ライフサイクルと自動化
9. 社内PKIとクラウド
10. 証明書トラブルシュート
11. 証明書の設計演習（この記事）

社内PKIとクラウドの証明書には、公開CAとは違う落とし穴があります。社内CAは、設定を1つ誤るだけで一般ユーザーがドメイン管理者になれてしまう攻撃の入口になりますし、クラウドのロードバランサーには、証明書を検証しないものもあります。

第8回では、ACMEによる自動化を見ました。第9回では、社内PKI（AD CS）の設計と守り方、クラウドの証明書サービス（ACM・Private CA・Azure）、ロードバランサーでのTLS終端、そしてvSphereの証明書を扱います。

▶ この回の内容は、YouTube の動画（約16分）でも見られます（記事の最後にも埋め込んであります）。

AD CSの設計：2層構成

AD CS（Active Directory 証明書サービス）で社内PKIを作るときの基本形は、オフラインのルートCAとオンラインの発行CAの2層構成です。

• ルートCA：ドメインに参加させないスタンドアロンCAとして構築し、発行CAの証明書に署名したら電源を切って保管する。ルートCAの秘密鍵が漏れると、社内のすべての証明書が信用できなくなり、作り直しと全端末への再配布が必要になるため
• 発行CA：日々の発行は、ドメインに参加したエンタープライズCAに担わせる。エンタープライズCAはADと連携し、証明書テンプレートと自動登録を使える

ルートCAがそのまま発行する1層構成は手軽ですが、ルートの鍵を常にネットワークに置くことになるため、検証環境向けです。3層構成は、拠点や用途ごとに方針を分けたい大規模な組織の選択肢です。

CRL・AIAの公開場所と有効期間

C:\> certutil -setreg CA\CRLPeriodUnits 52       # ルートCA：CRL の有効期間を52週に
C:\> certutil -setreg CA\CRLPeriod "Weeks"
C:\> certutil -setreg CA\CRLDeltaPeriodUnits 0   # デルタCRL を使わない
C:\> net stop certsvc & net start certsvc
C:\> certutil -CRL                               # CRL を発行（CertEnroll フォルダーに出力）

オフラインのルートCAで見落としがちなのが、ルートのCRLの更新です。電源を切って保管しているルートCAのCRLが期限（NextUpdate）を過ぎると、配下のすべての証明書の検証が失敗します。年間の作業予定に必ず入れておきましょう。Microsoftは、オフラインのルートCAではデルタCRLを使わないこと、Windows以外の端末のためにHTTPのCDPを用意することを勧めています。OCSP（オンラインレスポンダー）は任意です（第5回）。

発行CAをDCに立てない理由

冒頭の「社内CAはDCに入れておけばいい」への答えです。発行CAは、ドメインコントローラー（DC）に立てません。Microsoftも、DC上でCAを動かすことを推奨していません。

• 理由① 運用の自由度：CAが入ったDCは降格できず、先にCAの役割を削除する必要がある。DCの入れ替えのたびにCAの移行が必要になり、CAを入れたサーバーの名前は変えられない（変えると発行済みの証明書が使えなくなる）
• 理由② 権限の分離：CAの管理者にDCへのログオン権限を与えることになり、PKIの担当とドメインの管理者を分けられない
• 理由③ 攻撃の的：DCにWeb登録（IIS）を入れると、NTLMの中継攻撃（ESC8、後述）の的がDCそのものになる

ただし、発行CAはDCと同じ重要度で守ります。発行CAを乗っ取られると、ドメイン管理者を含む任意のユーザーの証明書を発行でき、DCを乗っ取られたのと同じだからです。Microsoftの区分ではTier 0（最重要の資産）として扱います。

推奨構成は、発行CAを専用のメンバーサーバーに置き、CRLを配るWebサーバーは別にすることです。ルート証明書はGPOで配布し、CAの鍵はHSMか、暗号化したバックアップで保管します。分けるのは運用と権限のため。守る重さはDCと変わりません。

証明書テンプレートと自動登録

テンプレートは、発行する証明書の型です。用途（EKU）、鍵の種類と長さ、有効期間、サブジェクトの作り方、誰が申請できるかを決めます。既定のテンプレートはコピーし、名前を付けて使います。

• サブジェクトは「Active Directoryの情報から構築する」を基本にする。「要求に含まれる」（申請者が名前を指定できる）は、Webサーバー用など必要なものに限り、CA管理者の承認を必須にする（ESC1の対策）
• 自動登録：テンプレートのセキュリティで、対象のグループに「読み取り」「登録」「自動登録」を許可し、GPOで自動登録を有効にする

コンピューターの構成 > ポリシー > Windows の設定 > セキュリティの設定
  > 公開キーのポリシー > 証明書サービス クライアント - 自動登録
  （構成モデル：有効／期限切れの証明書の書き換え・更新にチェック）

PS> certutil -pulse                               # 自動登録をすぐに実行
PS> Get-ChildItem Cert:\LocalMachine\My | Format-Table Subject, NotAfter, Thumbprint
PS> Get-Certificate -Template CorpWebServer -DnsName app01.corp.example.jp `
      -CertStoreLocation Cert:\LocalMachine\My    # 手動で申請する場合

自動登録された証明書は、期限が近づくと自動で更新されるため、期限切れの事故を防げます。人の作業は設定だけで、発行と更新は端末とCAの間で回ります。Linuxや機器は自動登録を使えないため、ACMEなどを検討します（第8回）。

AD CSの脆弱性（ESC1〜ESC8など）

AD CSは、設定の誤りがそのままドメインの乗っ取りにつながることで知られています。

特にESC1は要注意です。「申請者が名前を指定できる」「クライアント認証に使える」「一般ユーザーが登録できる」の3つの条件がそろったテンプレートが1つあれば、一般ユーザーが管理者になれます。

ESCは、SpecterOpsが2021年の論文「Certified Pre-Owned」で整理した攻撃の分類で、その後も番号が増えています。Certipy・Locksmithなどのツールや、Microsoft Defender for Identityで検出できます。点検は、自社が管理し許可を得た環境だけで行ってください。

Certifriedと強力な証明書マッピング

2022年5月に修正されたCertifried（CVE-2022-26923）は、一般ユーザーが作れるコンピューターアカウントのDNS名をDCと同じにし、DC名義の証明書を取れてしまう脆弱性でした。

• 原因は、DCのKDC（Kerberosの認証サービス）が、証明書の名前だけでアカウントを結び付けていた（弱いマッピング）こと
• Microsoftは、証明書に申請者のSIDを入れる拡張と、SIDや明示的な対応付け（発行者とシリアル番号など）で確かめる強力なマッピングを導入した（KB5014754）
• 2025年2月に強制モードが既定になり、2025年9月の更新で互換モードに戻す手段もなくなった

SIDの無い古い証明書や他社CAの証明書に頼る認証（スマートカード、802.1X、VPNなど）は、再発行か明示的な対応付けが必要です。今は、SIDも明示的な対応付けも無い証明書では、認証が通りません。

AD CSを守る運用とWindows Server 2025

定期点検では、CAのフラグ（ESC6）、発行中のテンプレート、テンプレートとCAの権限を確認します。

C:\> certutil -getreg policy\EditFlags     # EDITF_ATTRIBUTESUBJECTALTNAME2 が無いこと
C:\> certutil -setreg policy\EditFlags -EDITF_ATTRIBUTESUBJECTALTNAME2
C:\> certutil -CATemplates                 # 発行中のテンプレートの一覧
C:\> certutil -setreg CA\AuditFilter 127   # CA の監査を有効化（要求 4886・発行 4887 など）

• 使っていないテンプレートは発行の対象から外す。バージョン1のテンプレート（既定の「Webサーバー」など）は、コピーしてバージョン2以上にする（ESC15の対策）
• Web登録（/certsrv）はHTTPSと拡張保護を必須にし、使っていなければ削除する（ESC8の対策）
• CAの鍵とデータベースを定期的にバックアップし、復元の手順を試しておく（certutil -backup、Backup-CARoleService）

設定の点検と、気づく仕組み（監査ログ）と、戻す手段（バックアップ）の3つをそろえるのがポイントです。

Windows Server 2025では、2026年5月のセキュリティ更新（KB5087539）以降、AD CSで耐量子計算機暗号の署名ML-DSA（FIPS 204）のCAとテンプレートを作れるようになりました（第1段階。ML-KEMや複合署名は今後の予定）。クライアントはWindows 11 24H2／25H2の2025年10月以降の更新が必要で、ほかのOSやブラウザーの対応は限られるため、当面は検証用です。また、Windows Server 2025では、TLSのサーバー認証に2048ビット未満のRSAの証明書を使えません。

ACM（AWS Certificate Manager）

ここからはクラウドです。まずはAWSのACMです。

ACMが期限の前に更新できないときは、AWS HealthとEventBridgeに30日前から通知されます（ACM の全体像は連載「クラウド入門」第9回）。置き場所で鍵の扱いが決まります。AWSのサービスに置く方法なら、鍵がAWSの外に出ません。

見落としがちな落とし穴は、DNS検証のCNAMEを消すと自動更新が止まることと、インポートした証明書は自動更新されないことです。

AWS Private CAとAzureの対応

AWSはACMとPrivate CA、AzureはKey Vaultが中心です。社内CAだけは1対1になりません。AWS Private CAは、ルートと下位CAの階層を作れ、証明書ごとにも料金がかかります（汎用モードは月1,000枚まで1枚0.75ドル）。社内のWebサーバー、コンテナー間のmTLS（第7回）、IoT機器の証明書に向いています。AD CSから移る場合は、Connector for ADで自動登録を引き継げます。

ロードバランサーでのTLS終端と再暗号化

• 証明書の枚数は、台数ではなく名前で数えます。パススルーでは、同じ鍵がWebサーバーの台数分に増える
• 再暗号化では、LBがWebサーバーの証明書を検証するかを確認する。AWSのALBはターゲットの証明書を検証しないため、自己署名や期限切れでも通信できる

冒頭の「ALBの裏は自己署名でも動いている」は、まさにこれです。動いているのは、ALBが検証していないからであって、安全だからではありません。鍵の置き場所が増えるほど、漏えいの危険と更新の手間が増えます。

vSphereの証明書の仕組み

最後に、インフラでよく出会うvSphereの証明書です。

• vCenter Serverには、VMCA（VMware Certificate Authority）というCAが組み込まれている。vSphere 7以降はPSCがvCenterに統合されたため、今はvCenterのVMCAのこと
• 利用者のブラウザーに見えるのは、443番で使うMachine SSL証明書
• ESXiはvCenterに追加されると、VMCAが署名した証明書を自動で受け取る。有効期間は既定で1825日（5年）。VMCAのルートは既定で10年で、VMCAが署名する証明書はルートの期限を超えない
• vCenter 8.0 Update 3h以降は、VMCAのMachine SSL証明書を期限の5日前に自動更新する

既定では発行元がすべてVMCAなので、信頼させるにはVMCAのルートを配る必要があります。

VMCAの使い方の選択肢

Broadcomは1つの方式を推奨せず、「小規模はハイブリッド、大規模は中間CAが多く、カスタムは手間に見合わないことが多い」としています。ワイルドカード証明書は使えません。手順はBroadcom TechDocsで版ごとに確認します。社内CAからもらう枚数が、そのまま手作業の量になります。第11回（証明書の設計演習）の演習（問5）で、この選び方を考えます。

考えてみよう

1. 社内のAD CSは何層構成で、ルートCAの秘密鍵はどこにありますか。ルートCAのCRLが次に切れるのはいつですか。
2. 発行中のテンプレートの中に、「申請者が名前を指定できる」「クライアント認証に使える」「一般ユーザーが登録できる」の3つがそろったものはありますか。
3. 社内のロードバランサーの配下で、公開証明書の秘密鍵が置かれている場所はいくつありますか。それを1か所に減らせますか。

ヒント：1問目はcertutil -dump ルートCA.crlのNextUpdate（次の更新）、2問目は「証明書テンプレート」と「ESC1」、3問目は「ロードバランサーでのTLS終端」の3つの方式から考えてみてください。

まとめ

• AD CSはオフラインのルートCA＋エンタープライズの発行CAの2層。ルートのCRL更新を忘れない
• 発行CAはDCに立てないが、Tier 0としてDCと同じ重さで守る
• テンプレートのサブジェクトはADから構築。ESC1の3条件がそろったテンプレートを作らない
• 強力な証明書マッピングは2025年9月に完全に強制。SIDの無い古い証明書に注意
• ACMは198日・45日前に自動更新。DNS検証のCNAMEを消さない。インポートは自動更新されない
• ALBはターゲットの証明書を検証しない。vSphereはハイブリッドか中間CAが現実的

次回は、証明書のエラーが起きたときに、原因を切り分ける手順をまとめます。

動画で見る

この回の内容を、YouTube の動画（約16分）でも解説しています。

連載の全回は、YouTube の再生リスト「証明書入門」にまとめています。

連載「証明書入門」全11回

全回の目次と、読む順番・目的別の読み方は、証明書入門の入口のページにまとめています。

1. なぜ証明書が必要か
2. 暗号の基礎
3. openssl・PowerShellで試す
4. X.509証明書の中身
5. PKIと信頼の仕組み
6. 証明書の種類と発行
7. TLSの仕組み
8. ライフサイクルと自動化
9. 社内PKIとクラウド（この記事）
10. 証明書トラブルシュート
11. 証明書の設計演習

クラウドやコンテナの環境では、DNSの部品が見えにくいところに組み込まれています。仕組みを知らないと、どこで名前が解決されているのかさえ分からず、切り分けに時間がかかります。

でも、安心してください。部品の名前が変わっても、中身は第3回までに見た「キャッシュDNS・権威DNS・条件付きフォワーディング」そのものです。第10回では、Route 53を中心としたAWSのDNS、オンプレとのハイブリッド名前解決、Azureとの対応、そしてAD統合DNS、Kubernetes、vSphereでのDNSを見ていきます。

▶ この回の内容は、YouTube の動画（約14分）でも見られます（記事の最後にも埋め込んであります）。

Route 53の全体像とホストゾーン

Route 53はAWSのDNSサービスで、3つの役割を持ちます。

1. ホストゾーン：権威DNSサーバー
2. ドメイン名の登録：レジストラー
3. VPC Resolver：VPCの中で使うフルサービスリゾルバー

ホストゾーンには2種類あります。

• パブリックホストゾーン：インターネットに公開するゾーン。作成すると4台のネームサーバー（awsdnsのcom・net・org・co.uk）が割り当てられる。レジストラーでこの4台をNSとして登録して、初めて委任が完成する（第2回）
• プライベートホストゾーン：関連付けたVPCの中からだけ引けるゾーン

同じ名前のパブリックとプライベートを作ると、VPCの内と外で違う答えを返すスプリットホライズン（第7回、連載「クラウド入門」第7回）になります。1つのサービスに、役割の違う3つのDNSの機能が入っている、と整理しておくと混乱しません。

エイリアス・ルーティングポリシー・ヘルスチェック

ここで押さえたいのは、どれも「権威DNSが返す答えを変える」仕組みだという点です。すでに答えを持っているキャッシュDNSや端末には、TTLが切れるまで効きません（第3回）。答えを変えるのはRoute 53、古い答えを覚えているのはキャッシュDNSです。ルーティングポリシーの一覧は、連載「クラウド入門」第7回を参照してください。

また、レイテンシーや地理的位置のルーティングは「問い合わせ元」で判定するので、社内のフォワーダー経由だと、その出口の場所で判定される点にも注意しましょう。大阪の社員でも、東京のDMZから問い合わせていれば「東京」と判定されます。

VPCのDNS（Route 53 VPC Resolver）

VPCのEC2は、DHCPオプションセットのAmazonProvidedDNSにより、AWSのフルサービスリゾルバーRoute 53 VPC Resolver（2025年にRoute 53 Resolverから改称）を使います。宛先はCIDRの先頭＋2（10.0.0.0/16なら10.0.0.2）か169.254.169.253です。

• VPCの属性enableDnsSupportとenableDnsHostnamesの両方を有効にしないと、プライベートホストゾーンが使えない
• 名前に最も具体的に一致する転送ルールかプライベートホストゾーンが使われ、同じ名前なら転送ルールが優先
• 一致したゾーンに無い名前は、インターネットに聞かずNXDOMAINになる
• ENIごとに毎秒1024パケットの上限がある（連載「クラウド入門」第7回）

3つ目は、はまりやすいポイントです。たとえばexample.jpのプライベートホストゾーンを作ると、そこに登録していないwww.example.jpは、インターネットに公開されていてもNXDOMAINになります。

Resolverエンドポイントと転送ルール

オンプレとVPCの間で名前を引き合うための部品です。

エンドポイントのIP 1つで、UDPの問い合わせを毎秒最大1万件ほど処理できます（応答の大きさや転送先の遅さで下がります）。料金はIPの数と問い合わせ数で決まります。

新しい部品に見えますが、転送ルールの考え方は、第3回の条件付きフォワーディングそのものです。

クエリーログ・DNS Firewall・Global Resolver

• クエリーログ：VPCからVPC Resolverへの問い合わせ、エンドポイントを通る問い合わせ、DNS Firewallの判定を記録する。送り先はCloudWatch Logs・S3・Firehose。「どのインスタンスが、いつ、何を引いたか」が、障害調査とセキュリティ調査の手がかりになる。ただし、端末やOSのキャッシュで答えた問い合わせと、1024ppsの上限で捨てられた問い合わせはログに残らない
• DNS Firewall：VPCから出ていく問い合わせを、ドメインリストで許可（ALLOW）・遮断（BLOCK）・警告（ALERT）する。遮断したときはNODATA・NXDOMAIN・OVERRIDE（CNAMEで差し替え）のどれで答えるかを選べる。AWSが管理するドメインリスト（マルウェアなど）と、DNS Firewall Advanced（DNSトンネリングやDGAの検知）がある。第9回（DNSのセキュリティ）の保護的DNS・RPZのクラウド版
• Route 53 Global Resolver（2026年3月に一般提供）：オンプレや在宅の端末から、エニーキャストでプライベートホストゾーンとインターネットの名前を引けるリゾルバー。フィルタリングとログも一か所にまとめられる

DNS Firewallは名前だけで判定します。IPアドレスを直接指定した通信や、DoHで外部へ出る通信は止められません。最初はALERTで影響を確かめてからBLOCKにしましょう。

オンプレとのハイブリッド名前解決

では、冒頭の「EC2からオンプレの名前が引けない」を、どう設計すればよいのでしょうか。オンプレとAWSの間では、両方向の条件付きフォワーダーで名前を引き合います。

• オンプレ → AWS：オンプレの端末がapp.aws.corp.example.jpを引くと、社内のDNSはVPNやDirect Connect越しにインバウンドエンドポイントへ転送し、プライベートホストゾーンの答えが返る
• AWS → オンプレ：EC2がdc01.corp.example.jpを引くと、転送ルールに従い、アウトバウンドエンドポイントからオンプレのDNSへ転送される

行きは②インバウンド、帰りは⑥アウトバウンドです。設計の要点は3つです。

1. AWS側をaws.corp.example.jpのようなサブドメインに分け、転送の条件を単純にする
2. 転送が同じVPCとオンプレを行き来するループを作らない
3. AZ・DNSサーバー・回線を2つ以上にする

Azureとの対応

Azureでも、名前は違っても部品の役割は1対1で対応しています。

Azureで多い障害は、プライベートエンドポイント用のprivatelink.*ゾーンを、オンプレのDNSから条件付き転送し忘れ、公開IPが返ってしまうものです。AWSのVPCエンドポイントでも同じことが起きます。「クラウドのストレージに、社内からだけインターネット経由でつながってしまう」ときは、まずここを疑いましょう。

AD統合DNS

社内環境の代表、Active DirectoryのDNSです。

• AD統合ゾーン：ゾーンのデータをADのデータベースに置き、ADのレプリケーションでDCに複製する。どのDCでも書き込めるマルチマスターで、第7回のプライマリ／セカンダリとゾーン転送とは仕組みが違う
• SRVレコード：DCのNetlogonが_ldap._tcp.dc._msdcs.<ドメイン>などを自動で登録し、クライアントはSRVでDCを探す（第6回）
• _msdcsゾーン：_msdcs.<フォレストルート>はフォレスト全体に複製される。子ドメインや別のDNSからDCを探すときにここが引けないと、ドメイン参加や認証が失敗する
• 動的更新：端末が自分のA・PTRを登録する。「セキュリティで保護された動的更新のみ」にすると、登録したコンピューターだけが自分のレコードを書き換えられる
• DCのDNS設定：DCの参照先は他のDCを先に、自分自身を後にする。社外の名前はフォワーダーでキャッシュDNSに集約する（第3回）

$ dig +short SRV _ldap._tcp.dc._msdcs.corp.example.jp
0 100 389 dc01.corp.example.jp.
0 100 389 dc02.corp.example.jp.

PS> Resolve-DnsName _ldap._tcp.dc._msdcs.corp.example.jp -Type SRV
PS> nltest /dsgetdc:corp.example.jp          # 実際に見つかる DC

スカベンジング

もう1つ、AD統合DNSで知っておきたいのがスカベンジング（古いレコードの自動削除）です。

既定は更新禁止7日＋更新7日で、14日更新がないと古いと判定されます。ゾーンとサーバーの両方で有効にしないと動かず、間隔を24時間未満にすると、生きている端末のレコードまで消えます。撤去したサーバーやDCのレコードが残り続けていたら、スカベンジングの設定を確認しましょう。

Windows Server の DNS での手順は、過去の記事で紹介しています。ゾーンの種類（AD 統合・プライマリ・セカンダリ・スタブ）を選んでゾーンを作る手順は「DNS (Domain Name System) – DNS ゾーンの作成」、サーバー全体でエージング・清掃を有効にする手順は「DNS (Domain Name System) – Windows DNS サーバーの設定・オプション」です。

KubernetesのDNS

冒頭の「Kubernetesに載せたら外部APIの呼び出しが遅くなった」の話です。

クラスターの中ではCoreDNSが、Serviceの名前に答える権威DNSと、外部の名前を引くキャッシュDNSを兼ねます。Serviceは<サービス名>.<名前空間>.svc.cluster.localで引けます。

Podの/etc/resolv.conf（既定のdnsPolicy: ClusterFirst、名前空間prodの例）は、次のようになっています。

nameserver 10.96.0.10
search prod.svc.cluster.local svc.cluster.local cluster.local
options ndots:5

ndots:5の意味：ドットが5個未満の名前は、まずsearchのドメインを付けて試します。外部のapi.example.comを引くと、api.example.com.prod.svc.cluster.localなどの3つがNXDOMAINになってから本来の名前を引くため、AとAAAAで最大8回の問い合わせになります（ノードのsearchが加わるとさらに増えます）。

• 影響：CoreDNSと上流のDNSへの問い合わせが増え、名前解決が遅くなる。AWSではENIあたり1024ppsの上限に当たることもある
• 対策：外部の名前は末尾にドットを付けたFQDNで書く、PodのdnsConfigでndotsを下げる（例：2）、NodeLocal DNSCacheで各ノードにキャッシュを置く、CoreDNSのレプリカ数とキャッシュを調整する

第2回・第3回で見た「末尾のドット」と「searchドメイン」の話が、ここで効いてくるわけです。

vSphereなどの製品でDNSが重要な理由

最後に、インフラ製品とDNSの関係です。多くの製品にとって、DNSは構築の前提条件です。

代表例のvSphereでは、vCenter ServerをFQDNで構築するとき、正引き（A）と逆引き（PTR）の両方が登録され、一致していることが要件で、満たさないとデプロイや初回起動が失敗します。vCenterの名前は証明書やシングルサインオンに組み込まれるため、後から変えるのは大きな作業です。

ほかにも、次のような例があります。

• 送信元や宛先のドメインをDNSで解決できないと、vCenterのメール通知が送られない事象（Broadcom KB 321441）
• ESXiでNFS 4.1のKerberos認証を使うときに、KDCをSRVで引けるDNSが必要

Kerberosは名前で相手を確かめ、証明書も名前に対して発行されるため、同じことは多くの製品にいえます。名前は製品の中に焼き込まれるので、後で直すより、構築前に製品のDNS要件を確認し、AとPTRを先に登録しておきましょう。

考えてみよう

1. あなたのAWS（またはAzure）のVPCでは、EC2はどのDNSサーバーを参照していますか。オンプレの名前は、どの経路で引いていますか。
2. ADのDNSで、スカベンジングは有効になっていますか。撤去したサーバーやDCのレコードが残っていないか、確かめる方法を考えてください。
3. KubernetesのPodで、外部のAPIを毎秒100回呼ぶアプリがあります。ndotsとsearchによって、DNSの問い合わせは毎秒何件になりそうですか。

ヒント：1問目はDHCPオプションセットと転送ルール、2問目はタイムスタンプとnetlogon.dns、3問目はsearchの数とA/AAAAから考えてみてください。

まとめ

• Route 53は権威DNS・レジストラー・VPCのリゾルバーの3役。パブリックはNS 4台を親に登録して委任完成
• ルーティングポリシーは権威の答えを変えるだけ。キャッシュにはTTLが切れるまで効かない
• VPC Resolverは一致したゾーンに無い名前をNXDOMAINにする
• ハイブリッドは両方向の条件付きフォワーダー。AWS側はサブドメインに分ける
• AD統合DNSはマルチマスター。SRVと_msdcs、スカベンジングを押さえる
• Kubernetesはndots:5で外部の名前の問い合わせが増える。vSphereは正引きと逆引きの一致が前提

次回は、ここまでの知識を使って、DNSの障害を切り分ける手順をまとめます。

動画で見る

この回の内容を、YouTube の動画（約14分）でも解説しています。

連載の全回は、YouTube の再生リスト「DNS入門」にまとめています。

連載「DNS入門」全12回

全回の目次と、読む順番・目的別の読み方は、DNS入門の入口のページにまとめています。

1. DNSとは？名前解決の全体像と3つの登場人物
2. ドメイン名の階層と委任
3. 名前解決の流れ
4. DNSメッセージとトランスポート
5. リソースレコード 前編
6. リソースレコード 後編
7. 権威DNSサーバーの運用
8. コマンドで調べる
9. DNSのセキュリティ
10. クラウド・社内環境のDNS（この記事）
11. DNSトラブルシュート
12. DNS設計演習

情報のアップデート（2026年11月2日）

この記事は 2024 年に書きました．その後，VMware は Broadcom に買収され（2023年11月22日に完了），vSphere は「VMware by Broadcom」の製品になっています．

• 永続ライセンスの販売とその保守の更新は終わり，サブスクリプション（期間付きのライセンス）だけになりました．vSphere は VMware Cloud Foundation（VCF）や VMware vSphere Foundation（VVF）などの形で提供されています．
• ダウンロード・サポートは Broadcom Support Portal（https://support.broadcom.com/）に，製品の文書は Broadcom TechDocs（https://techdocs.broadcom.com/）に移りました．
• 移行先を考えている方は「VMware代替の候補「Proxmox VE」入門：vSphere/VCF・Nutanixとの違いを整理」もどうぞ．

Lifecycle Manager (旧 Update Manager) を利用してアップデートする方法は「VMware vSphere – ESXi のアップデート・アップグレード – Life Cycle Manager 経由」で紹介しています．

本手順は基本的には Lifecycle Manager を用いたアップデートを行うことを推奨します．インターネットに抜けられず，メーカーがリリースしたバージョンでメンテを行う場合．などのシチュエーションで利用することをお勧めします．

• VMware vSphere に関するお話
  • VMware vSphere – ESXi インストール
  • VMware vSphere – 仮想スイッチ/ポートグループの設定
  • VMware vSphere – NFSデータストアの追加
  • VMware vSphere – vCenter Server のインストール
  • VMware vSphere – vCenter Server の初期設定
  • VMware vSphere – ローカルデータストアの追加
  • VMware vSphere – EVC (Enhanced vMotion Compatibility)
  • VMware vSphere – 分散仮想スイッチ (分散仮想スイッチの説明，作成)
  • VMware vSphere – 分散仮想スイッチ (アップリンクの付け替え，VMkernel インターフェイスの移行)
  • VMware vSphere – 分散仮想スイッチ (仮想マシンポートグループの移行，アップリンクの完全付け替え)
  • VMware vSphere – iSCSI ストレージのマウント (マウントに向けた準備)
  • VMware vSphere – iSCSI ストレージのマウント
  • VMware vSphere – ライブマイグレーション (vMotion と Storage vMotion)
  • VMware vSphere – ライブマイグレーション(vMotion) のトラブルシュート
  • VMware vSphere – vSphere DRS (Distributed Resource Scheduler) 概要
  • VMware vSphere – vSphere DRS 設定 (DRS 手動)
  • VMware vSphere – vSphere DRS 設定 (DRS 一部自動化)
  • VMware vSphere – vSphere DRS 設定 (DRS 完全自動化)
  • VMware vSphere – vSphere DRS 設定 (アフィニティとアンチアフィニティ)
  • VMware vSphere – vSphere DRS 設定 (ホストアフィニティ)
  • VMware vSphere – vSphere HA の説明
  • VMware vSphere – vSphere HA の設定
  • VMware vSphere – vSphere HA の障害時動作の確認
  • VMware vSphere – vCenter Server Appliance のアップデート・アップグレード
  • VMware vSphere – ESXi のアップデート・アップグレード – Life Cycle Manager 経由
  • VMware vSphere – ESXi のアップデート・アップグレード – CD-ROM 経由

VMware vSphere – ESXi のアップデート・アップグレード – CD-ROM 経由

先にも述べましたが通常は Lifecycle Manager を利用したアップデートを推奨します．Lifecycle Manager が利用できないシチュエーションの際に CD-ROM / ISO イメージを用いた vSphere ESXi のアップデートを行います．

メンテナンスモードへの移行，シャットダウン

アップデートする ESXi ホストを選択して右クリックでメニューを表示して「メンテナンスモード」-「メンテナンスモードへの切り替え」をクリックします．

「メンテナンスモードへの切り替え」画面が表示されますので「OK」をクリックします．

メンテナンスモードに移行したら再度該当ホストを右クリックしてメニューを表示して「電源」-「シャットダウン」をクリックします．

「ホストのシャットダウン」画面にてシャットダウンの理由を入力して「OK」をクリックします．

シャットダウンされたことを確認します．

CD-ROM を用いたアップデート

サーバーに CD-ROM を挿入または，ISO イメージをマウントしてサーバーを起動します．

「Loading ESXi installer」と表示されていることで CD-ROM から起動していることが確認できます．

インストーラーが起動しますので「Enter」を押して次へ進みます．

「使用許諾契約書」が表示されますので確認して「F11」キーを押して次へ進みます．

サーバーに搭載されているディスクのスキャンが行われますので待ちましょう．

サーバーに搭載されているディスクの一覧が表示されます．今回は「Local」に1つだけ搭載されています．
ESXi がインストールされているディスクを選択して「Enter」を押して次へ進みます．

選択されたディスクのパーティション情報のスキャンが行われますので待ちましょう．

ESXi がインストールされていることが判明した場合，このように「Upgrade」なのか「Install」なのか選択する画面が表示されます．
「Upgrade」を選択して「Enter」を押します．

「Confirm Upgrade」と表示されたことを確認して「F11」を押して次へ進みます．

アップデートが開始されますので完了するまで待ちます．

「Upgrade Complete」とアップデートが完了したことを示す画面に切り替わります．「Enter」を押して再起動を行いましょう．

「Rebooting Server」と再起動が行われている旨表示されます．

再起動が行われ「Loading VMware ESXi」とローカルディスクから起動されていることを確認します．

起動が完了し，このような画面が表示されることを確認します．

以上でアップデートは完了です．

メンテナンスモードの解除

vCenter Server より，アップデートを行ったホストを選択，右クリックでメニューを表示して「メンテナンスモード」-「メンテナンスモードの終了」をクリックします．

メンテナンスモードが解除され，エラー・アラームが表示されないことを確認しましょう．

以上で CD-ROM を用いたアップデートの解説を終えます．

先にも何度も述べていますが，Lifecycle Manager を用いたアップデートをお勧めします．
Lifecycle Manager の場合，vCenter Server のみで完結できること，アップデート状態をクラスターで統一出来ていることが視覚的にわかりやすいことなどメリットが大きいためです．

更新履歴

• 2026年11月2日：VMware の Broadcom による買収と，ライセンス・サポートの窓口の変更についての「情報のアップデート」を追記しました

情報のアップデート（2026年11月2日）

この記事は 2024 年に書きました．その後，VMware は Broadcom に買収され（2023年11月22日に完了），vSphere は「VMware by Broadcom」の製品になっています．

• 永続ライセンスの販売とその保守の更新は終わり，サブスクリプション（期間付きのライセンス）だけになりました．vSphere は VMware Cloud Foundation（VCF）や VMware vSphere Foundation（VVF）などの形で提供されています．
• ダウンロード・サポートは Broadcom Support Portal（https://support.broadcom.com/）に，製品の文書は Broadcom TechDocs（https://techdocs.broadcom.com/）に移りました．
• 移行先を考えている方は「VMware代替の候補「Proxmox VE」入門：vSphere/VCF・Nutanixとの違いを整理」もどうぞ．

Lifecycle Manager (旧 Update Manager) を利用することで設定状況によりますが自動的に vMotion，メンテナンスモードの移行，アップデート，再起動，メンテナンスモードの解除が行われ，簡単にアップデートを行うことが可能です．

VMware 製品はバグや脆弱性がよく出ますので都度対応して安全な状態に保つようにしましょう．

• VMware vSphere に関するお話
  • VMware vSphere – ESXi インストール
  • VMware vSphere – 仮想スイッチ/ポートグループの設定
  • VMware vSphere – NFSデータストアの追加
  • VMware vSphere – vCenter Server のインストール
  • VMware vSphere – vCenter Server の初期設定
  • VMware vSphere – ローカルデータストアの追加
  • VMware vSphere – EVC (Enhanced vMotion Compatibility)
  • VMware vSphere – 分散仮想スイッチ (分散仮想スイッチの説明，作成)
  • VMware vSphere – 分散仮想スイッチ (アップリンクの付け替え，VMkernel インターフェイスの移行)
  • VMware vSphere – 分散仮想スイッチ (仮想マシンポートグループの移行，アップリンクの完全付け替え)
  • VMware vSphere – iSCSI ストレージのマウント (マウントに向けた準備)
  • VMware vSphere – iSCSI ストレージのマウント
  • VMware vSphere – ライブマイグレーション (vMotion と Storage vMotion)
  • VMware vSphere – ライブマイグレーション(vMotion) のトラブルシュート
  • VMware vSphere – vSphere DRS (Distributed Resource Scheduler) 概要
  • VMware vSphere – vSphere DRS 設定 (DRS 手動)
  • VMware vSphere – vSphere DRS 設定 (DRS 一部自動化)
  • VMware vSphere – vSphere DRS 設定 (DRS 完全自動化)
  • VMware vSphere – vSphere DRS 設定 (アフィニティとアンチアフィニティ)
  • VMware vSphere – vSphere DRS 設定 (ホストアフィニティ)
  • VMware vSphere – vSphere HA の説明
  • VMware vSphere – vSphere HA の設定
  • VMware vSphere – vSphere HA の障害時動作の確認
  • VMware vSphere – vCenter Server Appliance のアップデート・アップグレード
  • VMware vSphere – ESXi のアップデート・アップグレード – Life Cycle Manager 経由
  • VMware vSphere – ESXi のアップデート・アップグレード – CD-ROM 経由

VMware vSphere – ESXi のアップデート・アップグレード – Life Cycle Manager 経由

ESXi のアップデートは ISO イメージでサーバーを起動したアップデートも可能ですが，通常は Lifecycle Manager を利用してアップデートを行います．

Lifecycle Manager を利用することでクラスター内やデータセンター，vCenter 単位で同じパッチレベルであることが保証される状態になりますので是非利用しましょう．

Lifecycle Manager の設定

ブラウザーより vCenter Server にログインします．

画面左の「メニューバー」アイコンをクリックしてメニューを展開して「Lifecycle Manager」をクリックします．

「ベースライン」をクリックしてベースラインの一覧を表示します．

「新規」をクリックしてメニューを表示し「ベースライン」をクリックします．

「ベースラインの作成」にて「名前」に任意のベースライン名を入力します．
内容の箇所は次のとおりです．今回は「パッチ」を選択して「次へ」をクリックします．

• アップグレード
  通常はESXi のメジャーバージョンアップを行うベースラインを作成する際に利用します．
  または，ISO イメージを用いたアップデートを行う際にも利用されます．
• パッチ
  パッチやマイナーアップデートを行う際に利用します．
• 拡張機能
  主にサードパーティ製の追加デバイスドライバーをインストールする際に用いられます．既に導入済みの場合は「パッチ」ベースラインで更新できます．

「パッチの自動選択」ではパッチベンダー，製品，重要度，カテゴリーおよびパッチのリリース日を指定して合致したパッチをベースラインに含めることが可能です．

今回は指定した日付までにリリースされたパッチすべてを対象としたベースラインとするため「指定日またはそれ以前」に日付だけ入れて「次へ」をクリックしています．

「パッチの手動選択」では個別に追加登録したパッチを追加するために利用されます．今回は何もせずに「次へ」をクリックしています．

「サマリ」で設定内容を確認し，問題が無ければ「終了」をクリックします．

以上でパッチベースラインの作成は完了です．

Lifecycle Manager 動作の設定

「設定」-「ホストの修正」-「ベースライン」で「ベースライン修正の設定」画面を表示します．
ここに現在のベースラインによる修正の動作設定が表示されます．変更する場合は「編集」をクリックします．

「編集」をクリックすると現在の設定状態が表示されます．表示されているものはデフォルトの状態です．

今回，次の項目を変更しています．変更が終わったら「保存」をクリックします．

• ホストをメンテナンスモードに切り替える必要がある場合に、パワーオフ状態およびサスペンド状態の仮想マシンをクラスタの他のホストに移行します
  通常はパワーオフ，サスペンド状態の仮想マシンはメンテナンスモード移行時に移動されません．メンテナンス中にも仮想マシンの起動が行われる可能性があることを考慮するとこのオプションを有効にすることをお勧めします．
• ホストをメンテナンスモードに切り替えるのを妨げる可能性があるリムーバブルメディアデバイスを切断にします
  CD/DVD を接続している状態の場合，vMotion が妨げられる場合があります．その際，メディアの接続を切断して vMotion が行えるようになります．これを有効にしていない場合，仮想マシンの移動ができずメンテナンスモードに移行されない状態が継続する可能性があります．
  強制切断となりますので利用可否はよく検討してください．

元の画面に修正した内容が表示されますので，設定内容を確認しましょう．

ベースラインの添付とスキャン

「ホストおよびクラスター」へ移動します．

Lifecycle Manager のベースラインは，vCenter Server，データセンター，クラスター，ホストに設定できます．最初のもの (vCenter Server) 程全体への影響が大きく，最後のもの (ホスト) 程影響が小さくなります．

今回は「クラスター」単位でアップデートを行うようベースラインを添付していきます．

クラスターを選択し「アップデート」をクリックして「ベースライン」をクリックします．

添付されたベースラインの箇所の「添付」をクリックしてメニューを表示し「ベースラインまたはベースライングループの添付」をクリックします．

選択画面が表示されますので，添付するベースラインをチェックして「添付」をクリックします．

デフォルトでは常に最新のパッチが適用できるようなベースラインが vCenter Server に添付されています．
デフォルトで添付されているベースラインをチェックして「分離」をクリックします．

分離する箇所が表示されますので，チェックを入れて「分離」をクリックします．

適用したいベースラインだけになったら，画面上側の「コンプライアンスの確認」をクリックし，コンプライアンス状態をチェックします．

添付したベースラインのパッチレベルと現在のホストのパッチレベルにずれが生じている場合この画面のように「非準拠」と表示されます．

パッチ適用に進むため，画面中央部の「修正の事前チェック」をクリックします．

事前チェックの結果が表示されます．ここで問題が生じている旨の警告が表示された場合はその対処を行います．
今回は問題となるものが無いため「終了」でチェックを完了します．

パッチのステージングと修正の実行

実際にパッチ，アップデートの適用へ進みます．「VMware vSphere – vCenter Server Appliance のアップデート・アップグレード」でもステージングと適用の2段階に分けて実施しましたが，今回も同様に2段階に分けて実施します．

適用するベースラインをチェックして「ステージ」をクリックします．

パッチ，アップデートを適用するホスト一覧が表示されます．今回はクラスターを対象に実施していますのでクラスター内のホストが表示されています．
基本的にクラスター全台のホストを選択して「ステージ」をクリックしてパッチのステージングを実行します．

パッチ，アップデートのステージングが完了すると最近のタスクで「完了」と表示されます．

ステージングが完了したら「修正」をクリックします．

こちらもステージング同様にホストの一覧が表示されます．vSphere DRS が有効の場合は自動で vMotion とメンテナンスモード化，アップデートの実行の一連を Lifecycle Manager が実施してくれますので基本的には全台を選択した状態で「修正」をクリックします．

修正が開始されますので「最近のタスク」で状況を確認しましょう．

ｖSphere DRS が有効の場合，この画面のように vMotion とメンテナンスが自動で行われます．

メンテナンスモードに移行されると，パッチ・アップデートのインストールが開始されます．

インストールが終わると再起動も自動で行われます．

再起動が完了するとメンテナンスモードが解除され，次のホストのパッチ適用に進みます．
今回の場合だと，ESXi #2 が先行して行われ，続いて ESXi #1 が実行されており，ESXi #1 がメンテナンスモードに移行されている状態です．

メンテナンスモードに移行が完了するとパッチ・アップデートのインストールが行われます．

インストールが終わると再起動が行われその後メンテナンスモードの解除に移ります．

メンテナンスモードが終了し，全てのパッチ・アップデートが完了するとこのような画面になります．
本来は一度で準拠になるのですが，バグなどが理由で非準拠のままになってしまう場合があります．その場合は KB を参照してアクションを取ってください．

また，ホストに警告がついたままの状態になる場合があります．このような場合画面上部の「再読み込み」アイコンをクリックしてリフレッシュすることで解消することがありますので試してみてください．

上記で非準拠だったため再度同じアクション (ステージと修正) を行うと次のとおり準拠となりました．

以上で，ESXi のアップデート・アップグレードについて説明を終わります．

更新履歴

• 2026年11月2日：VMware の Broadcom による買収と，ライセンス・サポートの窓口の変更についての「情報のアップデート」を追記しました

情報のアップデート（2026年11月2日）

この記事は 2024 年に書きました．その後，VMware は Broadcom に買収され（2023年11月22日に完了），vSphere は「VMware by Broadcom」の製品になっています．

• 永続ライセンスの販売とその保守の更新は終わり，サブスクリプション（期間付きのライセンス）だけになりました．vSphere は VMware Cloud Foundation（VCF）や VMware vSphere Foundation（VVF）などの形で提供されています．
• ダウンロード・サポートは Broadcom Support Portal（https://support.broadcom.com/）に，製品の文書は Broadcom TechDocs（https://techdocs.broadcom.com/）に移りました．
• 移行先を考えている方は「VMware代替の候補「Proxmox VE」入門：vSphere/VCF・Nutanixとの違いを整理」もどうぞ．

vCenter Server Appliance のアップデートは難しいものではありませんので，脆弱性が出たらなるべくはやく対応しましょう．

• VMware vSphere に関するお話
  • VMware vSphere – ESXi インストール
  • VMware vSphere – 仮想スイッチ/ポートグループの設定
  • VMware vSphere – NFSデータストアの追加
  • VMware vSphere – vCenter Server のインストール
  • VMware vSphere – vCenter Server の初期設定
  • VMware vSphere – ローカルデータストアの追加
  • VMware vSphere – EVC (Enhanced vMotion Compatibility)
  • VMware vSphere – 分散仮想スイッチ (分散仮想スイッチの説明，作成)
  • VMware vSphere – 分散仮想スイッチ (アップリンクの付け替え，VMkernel インターフェイスの移行)
  • VMware vSphere – 分散仮想スイッチ (仮想マシンポートグループの移行，アップリンクの完全付け替え)
  • VMware vSphere – iSCSI ストレージのマウント (マウントに向けた準備)
  • VMware vSphere – iSCSI ストレージのマウント
  • VMware vSphere – ライブマイグレーション (vMotion と Storage vMotion)
  • VMware vSphere – ライブマイグレーション(vMotion) のトラブルシュート
  • VMware vSphere – vSphere DRS (Distributed Resource Scheduler) 概要
  • VMware vSphere – vSphere DRS 設定 (DRS 手動)
  • VMware vSphere – vSphere DRS 設定 (DRS 一部自動化)
  • VMware vSphere – vSphere DRS 設定 (DRS 完全自動化)
  • VMware vSphere – vSphere DRS 設定 (アフィニティとアンチアフィニティ)
  • VMware vSphere – vSphere DRS 設定 (ホストアフィニティ)
  • VMware vSphere – vSphere HA の説明
  • VMware vSphere – vSphere HA の設定
  • VMware vSphere – vSphere HA の障害時動作の確認
  • VMware vSphere – vCenter Server Appliance のアップデート・アップグレード
  • VMware vSphere – ESXi のアップデート・アップグレード – Life Cycle Manager 経由
  • VMware vSphere – ESXi のアップデート・アップグレード – CD-ROM 経由

VMware vSphere – vCenter Server Appliance のアップデート・アップグレード

vCenter Server のアップデート・アップグレードは，Windows からインストーラーを起動したアップグレードを行う方法，もしくは vCenter Server 管理インターフェイス (vCenter Server Management Interface / VAMI) から行う方法の2つがあります．

今回はブラウザーだけあればよいので簡便に行うことができますので，vCenter Server 管理インターフェイス (VAMI) から行う方法を解説します．

管理インターフェイスへログイン

vCenter Server Appliance の URL にポート番号 (5480) を指定してアクセスします．
https://<vCSA-Address>:5480/

管理者アカウント (通常は root) とパスワードを入力して「ログイン」をクリックします．

アップデートの実行 (再起動が不要なターゲットバージョン)

管理画面にログインできたら左メニューの「アップデート」をクリックします．

使用可能なアップデートにすべてリストされるといいのですが，リストされないケースがありますので「更新の確認」をクリックし「CD-ROM + URL の確認」をクリックして更新の確認を行います．

利用可能な一覧が表示されますので，アップデート・アップグレード先のバージョンを選択して「ステージング」をクリックします．
作業時間を纏めて取れる場合は「ステージングしてインストール」でも構いませんが，経験上2つのステップに分けて実施することをお勧めします．

アップデートパッケージのダウンロードが行われます．ステージングが完了するまでこのまま待ちましょう．

ステータスが「ステージング済み」になったことを確認します．

「インストール」をクリックしてアップデート・アップグレードを実行します．

エンドユーザー使用許諾契約書画面が表示されますので内容を確認のうえ「使用許諾契約書の条項に同意します」にチェックを付けて「次へ」をクリックします．

カスタマーエクスペリエンス改善プログラム (CEIP) の参加有無が確認されますので必要に応じてチェックの有無を判断ください．その上で「次へ」をクリックします．

アップデート・アップグレードにあたり，vCenter Server のバックアップが取得されていることの確認が求められます．
バックアップが存在する前提で「vCenter Server と、関連付けられたデータベースをバックアップしている」にチェックを入れて「完了」をクリックします．

アップデート・アップグレードが開始されますので，完了するまで待ちます．

すべての処理が終わったらこのような画面に戻りますので「閉じる」をクリックします．

現在のバージョンの詳細にて，選択・適用したバージョンになっていることを確認します．

以上，再起動が不要なターゲットバージョンの場合の手順になります．

アップデートの実行 (再起動が必要なターゲットバージョン)

管理画面にログインできたら左メニューの「アップデート」をクリックします．

使用可能なアップデートにすべてリストされるといいのですが，リストされないケースがありますので「更新の確認」をクリックし「CD-ROM + URL の確認」をクリックして更新の確認を行います．

利用可能な一覧が表示されますので，アップデート・アップグレード先のバージョンを選択して「ステージング」をクリックします．
作業時間を纏めて取れる場合は「ステージングしてインストール」でも構いませんが，経験上2つのステップに分けて実施することをお勧めします．

アップデートパッケージのダウンロードが行われます．ステージングが完了するまでこのまま待ちましょう．

ステータスが「ステージング済み」になったことを確認します．

「インストール」をクリックしてアップデート・アップグレードを実行します．

エンドユーザー使用許諾契約書画面が表示されますので内容を確認のうえ「使用許諾契約書の条項に同意します」にチェックを付けて「次へ」をクリックします．

カスタマーエクスペリエンス改善プログラム (CEIP) の参加有無が確認されますので必要に応じてチェックの有無を判断ください．その上で「次へ」をクリックします．

アップデート・アップグレードにあたり，vCenter Server のバックアップが取得されていることの確認が求められます．
バックアップが存在する前提で「vCenter Server と、関連付けられたデータベースをバックアップしている」にチェックを入れて「完了」をクリックします．

アップデート・アップグレードが開始されますので，完了するまで待ちます．

途中で再起動が入ります．その際に VMware vCenter Server 管理インターフェイスからログアウトされますので，ログインしなおしてください．

ログインするとインストール(アップデート・アップグレード)が進行中となりますので完了するまで待ちます．

すべての処理が終わったらこのような画面に戻りますので「閉じる」をクリックします．

再度セッションが切断されますのでログインしなおします．

現在のバージョンの詳細にて，選択・適用したバージョンになっていることを確認します．

以上，再起動が必要なターゲットバージョンの場合の手順になります．

vCenter Server Appliance のアップデートについての解説は以上となります．次回は ESXi のアップデートについて解説します．

更新履歴

• 2026年11月2日：VMware の Broadcom による買収と，ライセンス・サポートの窓口の変更についての「情報のアップデート」を追記しました

情報のアップデート（2026年11月2日）

この記事は 2024 年に書きました．その後，VMware は Broadcom に買収され（2023年11月22日に完了），vSphere は「VMware by Broadcom」の製品になっています．

• 永続ライセンスの販売とその保守の更新は終わり，サブスクリプション（期間付きのライセンス）だけになりました．vSphere は VMware Cloud Foundation（VCF）や VMware vSphere Foundation（VVF）などの形で提供されています．
• ダウンロード・サポートは Broadcom Support Portal（https://support.broadcom.com/）に，製品の文書は Broadcom TechDocs（https://techdocs.broadcom.com/）に移りました．
• 移行先を考えている方は「VMware代替の候補「Proxmox VE」入門：vSphere/VCF・Nutanixとの違いを整理」もどうぞ．

• VMware vSphere に関するお話
  • VMware vSphere – ESXi インストール
  • VMware vSphere – 仮想スイッチ/ポートグループの設定
  • VMware vSphere – NFSデータストアの追加
  • VMware vSphere – vCenter Server のインストール
  • VMware vSphere – vCenter Server の初期設定
  • VMware vSphere – ローカルデータストアの追加
  • VMware vSphere – EVC (Enhanced vMotion Compatibility)
  • VMware vSphere – 分散仮想スイッチ (分散仮想スイッチの説明，作成)
  • VMware vSphere – 分散仮想スイッチ (アップリンクの付け替え，VMkernel インターフェイスの移行)
  • VMware vSphere – 分散仮想スイッチ (仮想マシンポートグループの移行，アップリンクの完全付け替え)
  • VMware vSphere – iSCSI ストレージのマウント (マウントに向けた準備)
  • VMware vSphere – iSCSI ストレージのマウント
  • VMware vSphere – ライブマイグレーション (vMotion と Storage vMotion)
  • VMware vSphere – ライブマイグレーション(vMotion) のトラブルシュート
  • VMware vSphere – vSphere DRS (Distributed Resource Scheduler) 概要
  • VMware vSphere – vSphere DRS 設定 (DRS 手動)
  • VMware vSphere – vSphere DRS 設定 (DRS 一部自動化)
  • VMware vSphere – vSphere DRS 設定 (DRS 完全自動化)
  • VMware vSphere – vSphere DRS 設定 (アフィニティとアンチアフィニティ)
  • VMware vSphere – vSphere DRS 設定 (ホストアフィニティ)
  • VMware vSphere – vSphere HA の説明
  • VMware vSphere – vSphere HA の設定
  • VMware vSphere – vSphere HA の障害時動作の確認
  • VMware vSphere – vCenter Server Appliance のアップデート・アップグレード
  • VMware vSphere – ESXi のアップデート・アップグレード – Life Cycle Manager 経由
  • VMware vSphere – ESXi のアップデート・アップグレード – CD-ROM 経由

VMware vSphere – vSphere HA の障害時動作の確認

vSphere HA の動作確認 – ESXi ホストパニック時の動作

今回はデフォルト状態ですので仮想マシンの監視は行っていません．従ってホスト障害のみ vSphere HA による再起動が行われます．
ここでは，疑似的に障害を発生させて vSphere HA の動作を確認する方法を紹介します．

まずは障害を発生させるホストを確認します．今回は「esxi02.lab.seichan.org」を対象にします．

対象のホストの SSH もしくは Shell に入り，次のコマンドを実行します．

コマンドを実行すると ESXi ホストは PSOD (purple screen of death) 状態となり，紫のエラー画面に変わります．

クラスターのステータスを確認すると「vSphere HA フェイルオーバーが進行中です」などの状態が表示されます．

30秒～1分位 (プライマリーなのかセカンダリーなのかで発動タイミングが異なります) 経つとフェイルオーバーが開始され，正常なホストでパワーオンが行われます．

以上，疑似的にホスト障害を発生させて vSphere HA の動作を確認する方法となります．

vSphere HA の動作確認 – 仮想マシンハングアップ時の動作

VMware Tools を介した仮想マシン監視を有効にすることで仮想マシンがハングアップした際に再起動を自動的に行うことが可能になります．

「設定」-「vSphere の可用性」より vSphere HA の「編集」をクリックします．

「障害及び対応」の「仮想マシンの監視」を「無効」以外に設定します．今回は「仮想マシンの監視のみ」を選択しています．

設定が完了できたら「OK」をクリックして設定を反映させます．

クラスタの再設定が完了したことを確認します．

仮想マシンをハングアップさせます．今回はディスクの切断でハングアップ状態を発生させましたが，他の方法があればそれでもかまいません．

しばらくすると「vSphereHA の仮想マシンの監視アクション」アラームが発報され，再起動が開始されます．

イベントを確認すると，この画面のように「vSphere HA によってリセットされました」というイベントが確認できます．

このように，仮想マシンのハングアップに対応できるため，監視の有効化を検討するのは良いアイデアです．
ただ，全体的に仮想基盤が高負荷の状態が続くと，この監視に失敗する場合がありますのでオーバーコミットが当たり前の環境で高負荷な状態が前提の基盤では予期しないリセットが発生することがあります．全体的な負荷状態も考慮に入れる必要がある点に注意してください．

vSphere HA の動作確認 – ストレージアクセス不可 (All Path Down) 時の動作

ESXi – ストレージ間に障害が発生し，APD (All Path Down) 状態になった際の挙動を確認します．

設定値の確認のため「設定」-「vSphere の可用性」より vSphere HA の「編集」をクリックします．

「APD状態のデータストア」の設定を確認します．デフォルトではパワーオフして再起動というポリシーになっています．

ストレージパスを切断してみます．

しばらくすると vSphere HA フェイルオーバーが発生した旨のメッセージが表示されます．

仮想マシンのイベントを確認すると，vSphere HA によって再起動が行われたことが確認できます．

vSphere HA の動作確認 – ホスト隔離時の動作

vSphere HA 構成時，ホストがネットワークから隔離された場合に該当ホスト上の仮想マシンを別の正常なホストに移動 (再起動) させることができます．
この設定はデフォルトでは無効ですので，有効化する必要があります．

「設定」-「vSphere の可用性」より vSphere HA の「編集」をクリックします．

「ホスト隔離への対応」を「無効」以外を選択します．今回は「仮想マシンをシャットダウンして再起動」を選択します．

設定が行われたことを確認して「OK」をクリックします．

ESXi のアップリンクネットワークを全て切断させると，この画面のようにアラームが表示されます．

仮想マシンのイベントを確認すると，別のホストで再起動されていることが確認できます．

以上，vSphere HA のフェイルオーバー動作について幾つかのパターンを紹介しました．

次回は vSphere から離れて Windows Server によるフェイルオーバークラスターについて解説を行います．

更新履歴

• 2026年11月2日：VMware の Broadcom による買収と，ライセンス・サポートの窓口の変更についての「情報のアップデート」を追記しました

情報のアップデート（2026年11月2日）

この記事は 2024 年に書きました．その後，VMware は Broadcom に買収され（2023年11月22日に完了），vSphere は「VMware by Broadcom」の製品になっています．

• 永続ライセンスの販売とその保守の更新は終わり，サブスクリプション（期間付きのライセンス）だけになりました．vSphere は VMware Cloud Foundation（VCF）や VMware vSphere Foundation（VVF）などの形で提供されています．
• ダウンロード・サポートは Broadcom Support Portal（https://support.broadcom.com/）に，製品の文書は Broadcom TechDocs（https://techdocs.broadcom.com/）に移りました．
• 移行先を考えている方は「VMware代替の候補「Proxmox VE」入門：vSphere/VCF・Nutanixとの違いを整理」もどうぞ．

vSphere HA の説明については「VMware vSphere – vSphere HA の説明」で解説していますので合わせてご参照ください．

• VMware vSphere に関するお話
  • VMware vSphere – ESXi インストール
  • VMware vSphere – 仮想スイッチ/ポートグループの設定
  • VMware vSphere – NFSデータストアの追加
  • VMware vSphere – vCenter Server のインストール
  • VMware vSphere – vCenter Server の初期設定
  • VMware vSphere – ローカルデータストアの追加
  • VMware vSphere – EVC (Enhanced vMotion Compatibility)
  • VMware vSphere – 分散仮想スイッチ (分散仮想スイッチの説明，作成)
  • VMware vSphere – 分散仮想スイッチ (アップリンクの付け替え，VMkernel インターフェイスの移行)
  • VMware vSphere – 分散仮想スイッチ (仮想マシンポートグループの移行，アップリンクの完全付け替え)
  • VMware vSphere – iSCSI ストレージのマウント (マウントに向けた準備)
  • VMware vSphere – iSCSI ストレージのマウント
  • VMware vSphere – ライブマイグレーション (vMotion と Storage vMotion)
  • VMware vSphere – ライブマイグレーション(vMotion) のトラブルシュート
  • VMware vSphere – vSphere DRS (Distributed Resource Scheduler) 概要
  • VMware vSphere – vSphere DRS 設定 (DRS 手動)
  • VMware vSphere – vSphere DRS 設定 (DRS 一部自動化)
  • VMware vSphere – vSphere DRS 設定 (DRS 完全自動化)
  • VMware vSphere – vSphere DRS 設定 (アフィニティとアンチアフィニティ)
  • VMware vSphere – vSphere DRS 設定 (ホストアフィニティ)
  • VMware vSphere – vSphere HA の説明
  • VMware vSphere – vSphere HA の設定
  • VMware vSphere – vSphere HA の障害時動作の確認
  • VMware vSphere – vCenter Server Appliance のアップデート・アップグレード
  • VMware vSphere – ESXi のアップデート・アップグレード – Life Cycle Manager 経由
  • VMware vSphere – ESXi のアップデート・アップグレード – CD-ROM 経由

VMware vSphere – vSphere HA の設定

「ホストおよびクラスタ」より vSphere HA を設定するクラスターを選択，画面中央の「設定」をクリック，「サービス」-「vSphere の可用性」を選択して「編集」クリックします．

画面上部の「vSphere HA」のスイッチをクリックして有効にします．そうすると他の項目のグレーアウトが解除されます．

障害及び対応

障害が発生した際の挙動を設定する項目となります．詳細は「VMware vSphere – vSphere HA の説明」を参照してください．

ホストの障害応答

ホストに障害が発生した際の仮想マシンの挙動を設定します．

• 無効
  仮想マシンの再起動は行いません
• 仮想マシンを再起動
  デフォルト値です．ホスト障害が検知された場合，仮想マシンを他のホストで再起動します

ホスト隔離への対応

ホストが隔離と判断された場合の挙動を設定します．

• 無効
  デフォルト値です．隔離と判断された場合に仮想マシン操作は行いません
• 仮想マシンをパワーオフして再起動
  仮想マシンをパワーオフ (強制的に電源切断) を行って他のホストで起動します
• 仮想マシンをシャットダウンして再起動
  仮想マシンをシャットダウンして他のホストで起動します．この動作を行うには対象の仮想マシンで VMware Tools が動作している必要があります

PDL (永続的なデバイスの損失) 状態のデータストア

PDL が発生した際の仮想マシンの挙動を設定します．

• 無効
  何もアクションを起こしません
• イベントの発行
  vCenter Server にイベントを通知します
• 仮想マシンをパワーオフして再起動
  デフォルト値です．仮想マシンをパワーオフ (強制的に電源切断) を行って他のホストで起動します
  

APD 状態のデータストア

APD が発生した際の仮想マシンの挙動を設定します

• 無効
  何もアクションを起こしません
• イベントの発行
  vCenter Server にイベントを通知します
• 仮想マシンをパワーオフして再起動 標準的な再起動ポリシー
  デフォルト値です．他のホストで起動可能と判断した場合に仮想マシンをパワーオフ (強制的に電源切断) を行って他のホストで起動します．
• 仮想マシンをパワーオフして再起動 アグレッシブな再起動ポリシー
  他のホストで起動可能と判断できない場合でも仮想マシンをパワーオフ (強制的に電源切断) を行って他のホストで起動します．

仮想マシンの監視

仮想マシンのハートビートが途絶えた場合の挙動を設定します．

• 無効
  デフォルト値です．何もアクションを起こしません
• 仮想マシンの監視のみ
  ハートビートが途絶えた場合，同じホストの上で再起動を行います
• 仮想マシンとアプリケーションの監視
  ハートビートが途絶えた場合，同じホストの上で再起動を行います

アドミッションコントロール

「アドミッションコントロール」は vSphere HA の挙動を制御するポリシーで，クラスター内のフェイルオーバーキャパシティを確保するために用いられます．
障害が発生すると利用可能なリソースが減るため，障害を前提としてリソースを計算することでリソース不足を起こさないようにすることが目的です．

クラスタで許容するホスト障害

クラスター内で障害を許容する台数を指定します．「1」を設定した場合は1台分の障害を考慮したリソース計算を行います．台数が多い程使用可能なクラスターリソースは減ります．

ホストのフェイルオーバーキャパシティの定義基準

アドミッションコントロールでの障害時のリソース予約のコントロールをどのように行うのかを制御します．

• 無効
  アドミッションコントロールを無効にし，障害発生時のリソース低下を計算しません．仮想マシンを可能な限り立ち上げようとしますが，オーバーコミットが発生する可能性があります．
• スロットポリシー (パワーオン状態の仮想マシン)
  仮想マシンおよびホストの CPU とメモリーを「スロット」に計算してリソースを確保する計算方式です．クラスタリソースの割合や専用フェイルオーバーホストと比べて分かりづらい方式です．
  詳細は「スロット ポリシー アドミッション コントロール」を参照してください．
• クラスタリソースの割合 (%)
  デフォルト値です．クラスターのリソースから障害ホスト分のリソース割合を差し引く計算方式です．3台のクラスターで障害の許容数が「1」の場合は 33% が障害分のリソースとなります．
  4台のクラスターで許容数が「1」の場合は 25% が障害分のリソースとなります．
• 専用フェイルオーバーホスト
  フェイルオーバー専用のホストを用意する方式です．このモードを選択すると通常時フェイルオーバーホストには仮想マシンは一切稼働しません．障害許容数分フェイルオーバーホストが生成されます．

仮想マシンで許容するパフォーマンスの低下

障害が起きた際にクラスター内の仮想マシン群でパフォーマンスの低下を許容できる割合を指定します．
0% の場合，仮想マシンのフェイルオーバーの際にパフォーマンスを保証できない場合は警告を行います．
100% の場合警告を行いません．

ハートビートデータストア

vSpere HA において，ネットワークのハートビート障害が発生した際に，データストアでのハートビートを使用してホストおよび仮想マシンんを監視します．ここではハートビートで使用するデータストアを選択します．
ハートビートデータストアは最低2つ必要で，1つの場合は警告が表示されます．

• ホストからアクセス可能なデータストアを自動的に選択します
  リストに関係なく，vCenter Server が自動的にデータストアを選択します
• 指定したリストからのデータストアのみを使用する
  明示的に指定したデータストアのみを使用します
• 指定したリストからのデータストアを使用し，必要に応じて自動的に補足する
  デフォルト値です．上の二つのいい所どりをした形で指定も可能ですし，不足していれば自動的に追加で選択されます．

今回は上記を全てデフォルト値のままにしている状態で設定を行いました．

vSphere HA の状態確認

設定を完了した後，vSphere HA に必要なエージェントの導入や構成が行われます．完了したら「ホストおよびクラスタ」より vSphere HA を設定するクラスターを選択，画面中央の「監視」をクリック，「vSphere HA」-「サマリ」を選択ステータスを確認することができます．

マスター (プライマリー) に選択されているホストおよび，マスターに接続されたホスト (セカンダリー) の台数を確認しましょう．

vSphere HA に限らず，vSphere の構成では ESXi ホストと vCenter の時刻がそろっていることが前提になります．それぞれの時刻同期の設定と，時刻がずれたときに起きる問題は，「【NTP入門 第6回】ネットワーク機器・仮想基盤の時刻同期 ― Cisco IOS、機器をNTPサーバーにするか、ESXi・vCenter、ホストとVMの時刻、アプライアンス」で解説しています．

同じく，vCenter の構築では正引きと逆引きの DNS レコードが前提になります．vSphere で DNS が重要になる理由は，「【DNS入門 第10回】クラウド・社内環境のDNS ― Route 53、ハイブリッド名前解決、AD統合DNS、Kubernetes」を参照してください．

以上，vSphere HA の設定の解説でした．

次回は vSphere HA を有効にしている際の様々な障害とその際の動作について纏めます．

時刻同期の仕組みを基礎から順に学びたい方は，連載「NTP入門（全11回）の目次」からお読みください．

更新履歴

• 2026年11月2日：VMware の Broadcom による買収と，ライセンス・サポートの窓口の変更についての「情報のアップデート」を追記しました

情報のアップデート（2026年11月2日）

この記事は 2024 年に書きました．その後，VMware は Broadcom に買収され（2023年11月22日に完了），vSphere は「VMware by Broadcom」の製品になっています．

• 永続ライセンスの販売とその保守の更新は終わり，サブスクリプション（期間付きのライセンス）だけになりました．vSphere は VMware Cloud Foundation（VCF）や VMware vSphere Foundation（VVF）などの形で提供されています．
• ダウンロード・サポートは Broadcom Support Portal（https://support.broadcom.com/）に，製品の文書は Broadcom TechDocs（https://techdocs.broadcom.com/）に移りました．
• 移行先を考えている方は「VMware代替の候補「Proxmox VE」入門：vSphere/VCF・Nutanixとの違いを整理」もどうぞ．

• VMware vSphere に関するお話
  • VMware vSphere – ESXi インストール
  • VMware vSphere – 仮想スイッチ/ポートグループの設定
  • VMware vSphere – NFSデータストアの追加
  • VMware vSphere – vCenter Server のインストール
  • VMware vSphere – vCenter Server の初期設定
  • VMware vSphere – ローカルデータストアの追加
  • VMware vSphere – EVC (Enhanced vMotion Compatibility)
  • VMware vSphere – 分散仮想スイッチ (分散仮想スイッチの説明，作成)
  • VMware vSphere – 分散仮想スイッチ (アップリンクの付け替え，VMkernel インターフェイスの移行)
  • VMware vSphere – 分散仮想スイッチ (仮想マシンポートグループの移行，アップリンクの完全付け替え)
  • VMware vSphere – iSCSI ストレージのマウント (マウントに向けた準備)
  • VMware vSphere – iSCSI ストレージのマウント
  • VMware vSphere – ライブマイグレーション (vMotion と Storage vMotion)
  • VMware vSphere – ライブマイグレーション(vMotion) のトラブルシュート
  • VMware vSphere – vSphere DRS (Distributed Resource Scheduler) 概要
  • VMware vSphere – vSphere DRS 設定 (DRS 手動)
  • VMware vSphere – vSphere DRS 設定 (DRS 一部自動化)
  • VMware vSphere – vSphere DRS 設定 (DRS 完全自動化)
  • VMware vSphere – vSphere DRS 設定 (アフィニティとアンチアフィニティ)
  • VMware vSphere – vSphere DRS 設定 (ホストアフィニティ)
  • VMware vSphere – vSphere HA の説明
  • VMware vSphere – vSphere HA の設定
  • VMware vSphere – vSphere HA の障害時動作の確認
  • VMware vSphere – vCenter Server Appliance のアップデート・アップグレード
  • VMware vSphere – ESXi のアップデート・アップグレード – Life Cycle Manager 経由
  • VMware vSphere – ESXi のアップデート・アップグレード – CD-ROM 経由

vSphere HA (High Availability) とは

vSphere HA は ESXi ホストに何らかの問題 (障害) が発生して正常に動作できない状態となった際，クラスター内の他の正常な ESXi ホストに仮想マシンを移動して再起動 (パワーオン) させて再稼働させる仕組みです．

仮想マシンによるサービスを提供している中，vSphere HA が無い場合は ESXi ホスト障害 = サービス障害となってしまいますが，この機能を用いることで他のホストでサービスを再提供できるようになり，サービスダウンタイムを小さくできます．

設定次第では ESXi ホストの障害ではなく，仮想マシン (OS) のハングアップでも vSphere HA による再起動を促してサービスの再提供を行うようにすることもできます．

この例では真ん中の ESXi ホストに障害が発生し，左右のホストに仮想マシンが移動したことをあらわしています．
ただし，注意していただきたいのは仮想マシンは「一度シャットダウンされる」点は理解しておきましょう．

vSphere HA の動作詳細

vSphere HA は，各 ESXi ホスト上で稼働する Failt Domain Manager (FDM) Agent によって機能が提供されます．
FDM はサーバーの死活を監視するため，クラスターに1台のマスターノード，それ以外のスレーブノードの間でハートビートが実行されます．このハートビートが途切れたことをトリガーに vSphere HA による仮想マシンの再起動などの動作に移ります．

図に幾つかコンポーネントを記載していますのでそれぞれのコンポーネントについて説明します．

• FDM (Fault Domain Manager)
  FDM は vSphere HA を構成する上で最も重要な機能で，HA エージェントと呼ばれます．
  クラスター内の ESXi ホストのリソース状態，仮想マシンの状態などを FDM エージェント間で交換したり，ハートビートによる死活監視を行う役目を持っています．
  先にも述べたとおり，HA 発動の条件判定および仮想マシンの再起動の動作も行います．
• hostd
  vSphere HA に関係なく ESXi ホストで重要なエージェントが hostd です．仮想マシンのパワーオン・パワーオフなどの仮想マシンを管理する役割を持っています．
• vCenter Server
  vSphere HA の観点での説明に留めます．vSphere クラスターの重要なコンポーネントであり，あらゆるタスクの管理を行っているのが vCenter Server です．
  vCenter Server が担っている役割に次のものがあります．
  ・HA エージェントのデプロイや構築
  ・クラスター構成を変更するときの通信
  ・仮想マシンの保護
  vCenter Server は vSphere HA の機能が有効になったら FDM エージェントを ESXi ホストに導入する役割も担っています．また，vCenter Server はクラスター内の ESXi ホスト群のうちプライマリーノード，セカンダリーノードを選ぶ決定権も持っています．

HA クラスターを構成する各 ESXi ホストの役割

上で軽く触れていますが vSphere HA はプライマリー/セカンダリーの構成になっています．

プライマリーホストは次の役割を担います．

• すべてのセカンダリーホストを監視，障害が発生した場合は仮想マシンをフェイルオーバーさせます
• 仮想マシンの状態を VMware Tools で監視，障害が発生した場合は仮想マシンをリセットします
• 保護対象の仮想マシンのリストを管理します．仮想マシンのパワーオン/パワーオフの際にリストを更新します
• セカンダリーホストとハートビートを交換します．ハートビートはプライマリーとセカンダリー間で Point to Point で通信が行われます
• HA クラスターの構成管理を行います．構成に変更が発生した際はセカンダリーに通知します

セカンダリーホストは次の役割を担います．

• 自ホストで動作している仮想マシンの状態を監視します．仮想マシンのステータスが変化した際にプライマリーホストへ通知を行います
• プライマリーホストを監視します．プライマリーホストが障害となった場合やネットワークの分断が発生した場合，セカンダリーホストの中からプライマリーホストを選出します

ハートビートネットワークとハートビートデータストア

vSphere HA はネットワーク経由のハートビートとデータストア経由のハートビートの2つを使用して HA クラスターの監視を行います．

ネットワークが切断された場合でも，データストアへのアクセスができる場合はハートビートデータストアにある情報を利用して障害の状態を正確に判断することができます．

ハートビートデータストアは，ネットワークハートビートが利用できなくなった場合のみホスト障害なのかネットワーク障害なのかを識別するために使用されます．

vSphere HA の遷移

ネットワークとデータストアの2つのハートビートを用いることでホスト障害なのか，ネットワーク障害なのかの識別が可能になり，精度の高い障害ポイントの検出とフェイルオーバー動作が可能となりました．

以下のフローチャートのとおり vSphere HA は障害を識別します．

隔離アドレスへの Ping がとおるか．については，プライマリーとセカンダリーの間のハートビートネットワークの疎通が失われ，ネットワーク障害と判断された際にネットワーク隔離なのか，ネットワークパーティションなのかを識別するために使用されます．

デフォルトでは，ESXiホストの管理ネットワークのデフォルトゲートウェイアドレスが隔離アドレスとして使用されます．
隔離アドレスを追加することで，より正確な判断を行うことが可能です．

vSphere HA 発動時の動作

障害が発生し，vSphere HA によるリカバリーを行う必要が生じた際について説明します．

ホスト障害時のリカバリー動作

セカンダリーホストに障害が発生したと判断された場合，障害ホストで動作している仮想マシンを他のホストで再起動させます．

プライマリーホストに障害が発生したと判断された場合は，仮想マシンを他のホストで再起動を行うのですが，その前に正常稼働中のセカンダリーホストの中から新しいプライマリーホストの選出を行い，その後に仮想マシンの再起動を試みます．

そのため，vSphere HA による仮想マシンの再起動はホストの役割によって再起動が開始されるタイミングが違う点を認識しておく必要があります．

ホスト隔離時のリカバリー動作

ホスト隔離状態とは，プライマリーとの通信だけではなく，障害ホストから隔離アドレスへの疎通も取れずに孤立した状態を指します．
このような状態の場合，該当ホストの NIC もしくはスイッチに障害が発生している状態と考えられます．

このような状態の場合，障害ホスト上の仮想マシンをフェイルオーバーさせるかどうかの判断が難しい状態です．障害は物理ホスト側で仮想マシンとしては正常に動作している可能性があるためとなります．

仮想マシンが利用する NIC が管理用ネットワークとは違う場合，仮想マシンは正常に利用できているかもしれません．
仮想マシンが利用する NIC が管理用ネットワークと同じ場合は障害が発生しているかもしれません．

そのため，vSphere HA では「ホスト隔離への対応」を行うためのオプションが用意されています．

ホスト隔離の際の動作として以下があります

• 無効化
  ホストが隔離された場合でも仮想マシンはそのままそのホスト上で稼働します
• 仮想マシンをシャットダウンして再起動
  ホスト隔離が検出された場合，仮想マシンをシャットダウンして他のホスト上で起動させます．
  シャットダウンを行うためには VMware Tools が必要になります
• 仮想マシンをパワーオフして再起動
  ホスト隔離が検出された場合，仮想マシンをパワーオフして他のホスト上で起動させます

データストア障害時のリカバリー動作

データストアに障害が発生した場合も vSphere HA によるフェイルオーバーを行うことが可能です．
ただし，ストレージの障害は2つのパターンがあり，パターンによって動作が異なります．

• PDL (Permanent Device Loss) – ストレージの接続が永続的に失われた状態
  データストアが削除された場合や IO が即失敗するような状態
• APD (All Path Down) – ストレージの接続が一時的に失われた状態
  NFS アクセスの経路が無くなったような状態

いずれの障害の場合も利用できるオプションは次のとおりです．

• 無効化
  PDL および APD が発生しても何も行いません
• イベントの発行
  PDL および APD が発生したら vCenter Server へイベントが通知されます．仮想マシンは自動で復旧することはありません
• 仮想マシンをパワーオフして再起動
  PDL および APD が発生したら仮想マシンをパワーオフし他のホストで起動します

なお「仮想マシンをパワーオフして再起動」において，APD の場合はさらに追加のオプションがあります．

• 標準的
  他のホストで再起動ができると判断でいた場合のみ作動する
• アグレッシブ
  他のホストで再起動ができると判断できなくても作動する

仮想マシン障害時のリカバリー動作

今まではホストの障害やデータストアの障害に起因した仮想マシンのフェイルオーバーを説明していましたが，仮想マシン単体でも障害の監視，再起動を行うことができます．

仮想マシンの監視を行う場合は VMware Tools を利用してホストと仮想マシン間でハートビートによって監視が行われます．
ハートビートが途切れるとそのホスト上で仮想マシンを再起動します．

以上，vSphere HA の解説を終わります．次回は vSphere HA の設定について説明します．

AWS では，障害が起きたインスタンスを Auto Scaling が終了して作り直す「自己修復」の考え方がよく使われます．詳しくは「【クラウド入門 第4回】コンピューティング 後編 ― 停止と課金、RI・Savings Plans・スポット、Auto Scaling、ELB、ECS／EKS／Fargate、Lambda、使い分けとAzureとの対応」で，社内の仮想化基盤とクラウドの違いは「【クラウド入門 第1回】クラウドとは ― NISTの定義と5つの特徴、オンプレとの比較、IaaS・PaaS・SaaS、責任共有モデル、配置モデル、移行の7R、仮想化基盤との違い」で解説しています．

更新履歴

• 2026年11月2日：VMware の Broadcom による買収と，ライセンス・サポートの窓口の変更についての「情報のアップデート」を追記しました