追記: 2026年6月9日の最新情報
2026年6月9日時点で、Broadcom Service Status上のHigh-Risk Isolation（HRI）メンテナンスは完了扱いになっています。完了時刻は2026年6月7日18:00 UTC（日本時間では6月8日03:00）です。HRIを利用していた環境では、当日のisolated sessionsの劣化有無を運用ログや問い合わせ状況と照らして確認し、継続影響がある場合は個別テナントの状態を確認してください。
TLS/SSL中間CA置換は、Cloud Services CA – G2からCloud Services CA – G3への置換として案内されています。Cloud Services Root CAは変わらず、推奨どおりroot CAを導入してTLS/SSL inspectionが正常に動いている端末では追加作業なしとされています。ただし、例外端末、独自配布、プロキシ転送、古い端末管理が残る環境では、6月12日の期限前にroot CA導入状況を確認しておくと安全です。
ASMのアプリケーションメンテナンスは、2026年6月15日05:00 UTC（日本時間では6月15日14:00）から最大30分予定です。ASM stationのIP変更を含むため、IPベースのfirewallやallowlistで監視元を制限している環境は、Broadcom Service Statusの対象IPを確認してからメンテナンス時間を迎えるのが実務上のポイントです。
このテーマをもう少し広げて見るなら、Broadcom 重要トピックまとめ と Broadcom 2026年6月重要トピックまとめ も合わせて確認してください。月をまたぐメンテナンスや製品影響を、継続的に確認する入口として使える。
3行まとめ
2026年6月7日17:00から6月8日03:00 JSTは、HRI利用有無とisolated sessionsの劣化可能性を見る。
2026年6月12日09:00から6月13日08:59 JSTは、Cloud Services Root CA導入状況を確認する。
2026年6月15日14:00から18:00 JSTは、ASM station IP、Firewall allowlist、監視欠測の扱いを見る。
最初にUTCをJSTへ直し、対象サービスごとに担当と確認項目を分ける。
- Broadcom Service Statusには、2026年6月7日のCloud Secure Web Gateway High-Risk Isolationメンテ、6月12日のTLS/SSL中間CA置換、6月15日のDX App Synthetic Monitorメンテが掲載されている。日本の運用担当者は、まずUTCをJSTに直して変更管理へ入れるのが第一歩になる。
- Cloud SWG利用者は、HRIを使っているか、Cloud Services Root CAを端末や関連デバイスへ導入しているか、中間CAを独自に固定していないかを確認したい。Dedicated Web Isolation tenantだけの利用は、HRIメンテの直接対象ではない。
- ASM利用者は、IPベースのFirewallルールやallowlistを使っている場合に、公式ステータス上の新しいASM station IPリストを確認する。メンテ中は短時間の監視スケジュール停止やUI停止も想定して、監視欠測の扱いを先に決めておく。
Broadcomの6月ステータス更新は、派手な新製品発表ではない。それでも、Cloud Secure Web Gateway、High-Risk Isolation、TLS/SSL inspection、DX App Synthetic Monitorを使う組織には、かなり現実的な確認事項を残している。証明書、Web Isolation、監視局IP、メンテ時間中のアラート。このあたりは、気づくのが遅いほど問い合わせ対応が面倒になる。
この記事は、2026年6月5日18時台のAsia/Tokyo時点で確認できたBroadcom公式ステータスと公式資料をもとに、6月前半から中旬の3件を利用者影響の順に整理する。Broadcom Watch JapanはBroadcomおよびVMware by Broadcomの公式サイトではなく、同社と非提携の情報整理サイトである。掲載内容は製品・サービス更新の確認メモであり、投資助言ではない。
6月全体の公式更新を追う入口としては、公開済みの<a href="https://avgo-watch.blog.mo-gmo.com/monthly-topics-2026-06/" target="_blank" rel="noopener">2026年6月 重要トピックまとめ</a>も使える。ソース確認の考え方を先に押さえたい場合は、<a href="https://avgo-watch.blog.mo-gmo.com/source-checks/" target="_blank" rel="noopener">資料・確認ログ</a>も合わせて見ておくと、Service Statusと製品資料を分けて読みやすい。
6月のBroadcom Service Statusで確認すべき3件
- 6月7日17:00-6月8日03:00 JST
Cloud SWG High-Risk Isolation service update。Cloud SWGでHRIを使う顧客は、Dedicated Web Isolation tenantとの違いとisolated sessionsの劣化可能性を確認する。
- 6月12日09:00-6月13日08:59 JST
TLS/SSL Intermediate CA Replacement。Cloud SWGのTLS/SSL inspection関連で、Cloud Services Root CA導入状況と中間CA固定の有無を確認する。
- 6月15日14:00-18:00 JST
ASM Application Maintenance。DX App Synthetic Monitorで、IP allowlist、Firewallルール、監視欠測、UI停止の扱いを確認する。
ASMは4時間枠をメンテナンスウィンドウとして登録し、実際の中断やUI停止は短時間で起きうるものとして扱う。
今回見るべき公式ステータスは3本ある。1本目はCloud SWGのHigh-Risk Isolation、2本目はCloud SWGのTLS/SSL中間CA置換、3本目はDX App Synthetic Monitor、通称ASMのメンテナンスだ。どれもBroadcomのクラウド系サービス運用に関わるが、確認する担当は少し違う。
| 項目 | 公式ステータス上のUTC | 日本時間の目安 | 対象 | 先に見ること |
|---|---|---|---|---|
| Cloud SWG High-Risk Isolation service update | 2026年6月7日 08:00-18:00 UTC | 2026年6月7日17:00-6月8日03:00 JST | Cloud SWGでHRIを使う顧客 | HRI利用有無、Dedicated Web Isolation tenantとの違い、isolated sessionsの劣化可能性 |
| TLS/SSL Intermediate CA Replacement | 2026年6月12日 00:00-23:59 UTC | 2026年6月12日09:00-6月13日08:59 JST | Cloud SWGのTLS/SSL inspection関連 | Cloud Services Root CA導入状況、中間CAを固定していないか、APAC POPの利用可能性 |
| ASM Application Maintenance | 2026年6月15日 05:00-09:00 UTC | 2026年6月15日14:00-18:00 JST | DX App Synthetic Monitor | IP allowlist、Firewallルール、監視欠測、UI停止の扱い |
まず日付を日本時間に直す
公式ステータスはUTCで掲載されることが多い。日本の運用カレンダーへ入れるときは、HRIとTLS/SSLのように日付をまたぐものを特に注意したい。HRIは日曜夕方から月曜未明にかけて、TLS/SSL中間CA置換は金曜午前から土曜朝にかけての扱いになる。
ASMは6月15日14時から18時JSTの4時間枠として予定されている。ただし、公式ステータスの説明では実作業による中断は「最大30分程度」と読める書き方になっている。運用上は4時間枠をメンテナンスウィンドウとして登録し、実際の欠測やUI停止は短時間で起きうる、と分けて扱うのが無難だ。
対象がCloud SWGとASMに分かれる
Cloud SWG利用者が見るべきなのは、HRIとTLS/SSL中間CA置換だ。HRIはWeb Isolation系の利用有無に関わり、TLS/SSL中間CA置換は端末や接続方式、証明書配布に関わる。どちらもWebセキュリティ運用と証明書管理チームの接点が出やすい。
一方、ASMメンテは監視運用の話だ。外部視点のsynthetic checksや監視局を使ってWebアプリケーションを見ている環境では、監視局IPの変更がFirewallやallowlistに当たる可能性がある。Cloud SWGとASMを同じ担当が見ているとは限らないので、まとめて読むだけでなく、担当ごとに切り分けておく必要がある。
株価材料ではなく利用者影響として読む
今回の3件は、公式ステータスに掲載されたメンテナンスと変更通知だ。業績、受注、株価、顧客数の話ではない。AVGOを追っている読者にとってはBroadcomの運用品質やクラウドサービスの提供条件を見る材料にはなるが、短期的な市場反応を語るには向いていない。
見るべき中心は、ユーザーがメンテ時間中にどんな挙動を経験しうるか、端末やFirewallに事前作業が必要か、公式ページの更新をどのタイミングで再確認するかだ。未確認の障害拡大やSLA影響は、公式に示されていない限り本文では断定しない。
High-Risk Isolationメンテで見るべきこと
公式ステータスの直接対象。対象ユーザー、対象サイト種別、問い合わせの受け口を確認する。
公式ステータスでは影響しないと説明されている。Web Isolationという名称だけで一括判断しない。
遅延、接続しにくさ、動作の重さが問い合わせとして出る可能性を、HRI対象セッションに絞って見る。
設定変更を急ぐ通知ではなく、影響範囲、対象ユーザー、問い合わせ時の一次切り分けをそろえる通知として読む。
HRI、つまりHigh-Risk Isolationは、Cloud SWGのWeb Isolation文脈で使われる機能だ。BroadcomのKnowledge Baseでは、HRIがRemote Browser Isolationを使い、未分類サイトやrisk level 5以上のサイトなど、高リスク扱いのWebアクセスを分離する仕組みとして説明されている。
6月7日の公式ステータスは、このHRIサービスに対する更新通知として読める。予定時刻は2026年6月7日08:00から18:00 UTC、日本時間では6月7日17:00から6月8日03:00だ。
HRI利用者だけが直接の確認対象になる
公式ステータスで重要なのは、対象の切り分けだ。影響対象はCloud SWGでHigh-Risk Isolationを使う顧客であり、Dedicated Web Isolation tenantには影響しないと説明されている。Web Isolationという名前が似ていても、すべてのWeb Isolation利用者が同じ対象になるわけではない。
運用担当者が最初に見るべきなのは、自社がHRIを有効にしているか、Dedicated tenantだけを使っているのか、または両方の構成を持っているのかだ。ここを曖昧にすると、関係ない部署へ広く告知してしまったり、逆にHRI利用部署を見落としたりする。
根拠として見る資料
HRIの仕組みを確認するなら、Broadcom Knowledge BaseのHigh Risk Isolation説明を補助資料として読むとよい。メンテ日時そのものの根拠はService Statusだが、HRIがどの種類のアクセスを分離する機能なのかはKB側の説明が助けになる。
isolated sessionsの劣化をどう扱うか
6月7日の公式ステータスは、メンテ期間中にisolated sessionsで一時的または断続的な劣化が起きる可能性に触れている。ここでいう劣化を、ただちに全社的なWeb障害と読むのは強すぎる。HRI対象のセッションで、遅延、接続しにくさ、動作の重さが問い合わせとして出る可能性がある、という程度に落として見るほうが実務的だ。
確認項目は次のように分けられる。
| 確認先 | 見ること | メモ |
|---|---|---|
| Cloud SWG設定 | HRIの有効化範囲 | ポリシー名だけで判断せず、対象ユーザーやグループを確認する |
| 利用部門 | HRI対象サイトを使う業務 | 週末から月曜未明の業務があるかを見ておく |
| ヘルプデスク | 問い合わせ時の一次切り分け | 通常のWeb障害、Cloud SWG経路、HRI対象セッションを分ける |
| 変更管理 | メンテ予定の登録 | JSTの日付またぎを明記する |
事前作業は設定変更より影響範囲の棚卸しに置く
公式ステータスは、HRI利用者に設定変更を求める通知としては読めない。したがって、記事を読んだ後にすぐポリシーを変更する、という動きにはしないほうがいい。必要なのは、HRIを使う業務、対象ユーザー、問い合わせの受け口、公式ステータスの再確認タイミングをそろえることだ。
Dedicated Web Isolation tenantが対象外とされている点も、社内通知でははっきり書いておきたい。「Web Isolation関連メンテ」という広い言い方だけだと、対象外の専用テナント利用者まで不安にさせる。公式文言に沿って、HRIとDedicated tenantを分けて説明するのがよい。
TLS/SSL中間CA置換はroot CA導入状況を確認する
- 1Cloud Services Root CAを確認
端末や関連デバイスがCloud Services Root CAを信頼しているかを見る。
- 2Intermediate CAはG2からG3へ
変わるのは中間CAで、root CAはCloud Services Root CAのままと読む。
- 3中間CA固定運用を確認
証明書ピンニング、独自配布、古い手順書、例外的な端末イメージがないかを見る。
- 4APAC POPを確認
対象POP一覧にはOsakaとTokyoが含まれるため、日本拠点も確認対象に入れる。
構成変更不要と読めるのは、Cloud Services Root CAを正しく導入している場合に限られる。
6月12日のTLS/SSL Intermediate CA Replacementは、今回の3件の中で最も誤解しやすい。証明書の話は、root CA、中間CA、端末の信頼ストア、SSL inspection、接続方式が混ざるためだ。
公式ステータスの主旨は、TLS/SSL inspectionで使われる中間CAがCloud Services CA – G2からCloud Services CA – G3へ置き換わる、というものだ。root CAはCloud Services Root CAのままとされている。
変わるのは中間CAで、root CAは変わらない
公式ステータス上の読み方は明確だ。変更されるのは中間CAであり、root CAはCloud Services Root CAのまま。Broadcom推奨どおりCloud Services Root CAを関連デバイスへ導入している場合、追加の構成変更は不要と説明されている。
逆に見ると、中間CAを端末やプロキシ、検査系の独自運用で固定的に扱っている環境は注意が必要になる。証明書ピンニング、独自配布、古い手順書、例外的な端末イメージなどで、root CAではなく中間CAを信頼の前提にしている運用がないかを確認したい。
条件を外して断定しない
「構成変更不要」と言えるのは、Cloud Services Root CAを正しく導入しているという条件がある場合だ。root CAの導入状況が不明なまま「何もしなくてよい」と読むのは危ない。
推奨どおりroot CAを導入済みなら構成変更不要と読む
運用確認では、次の順番で見ると迷いにくい。
| 順番 | 確認項目 | 判断 |
|---|---|---|
| 1 | Cloud Services Root CAを端末や関連デバイスが信頼しているか | 導入済みなら公式説明上は追加構成不要に近い |
| 2 | 中間CAを独自に配布、固定、監視していないか | 固定している場合はG3への切替影響を確認する |
| 3 | WSS Agent、Explicit Proxy、Proxy Forwarding、IPsecなどの接続方式を使っているか | 影響確認の担当と手順を分ける |
| 4 | SSL inspectionの例外や検査対象が業務アプリに当たるか | 問い合わせ時の切り分けに使う |
この変更は、端末側で何かを必ず入れ替える通知ではなく、既存のroot CA導入状態を確認する通知として読むのがよい。とはいえ、証明書配布は社内の端末管理、MDM、プロキシ、セキュリティ例外と絡む。公開ステータスだけで自社固有の影響を断定せず、必要ならBroadcom Supportや社内証明書管理の記録へ戻る。
APAC POPにOsakaとTokyoが含まれる点を明記する
公式ステータスの対象POP一覧には、APACの中にOsakaとTokyoが含まれている。日本拠点だから関係ない、とは考えにくい。Cloud SWGの接続経路、ユーザー所在地、エージェント構成、プロキシ転送の設計によって影響の見え方は変わるが、日本の読者は確認対象に入れてよい。
ここで大事なのは、Osaka/Tokyoがリストにあることを過剰に不安視しないことだ。公式説明では、root CAが導入済みなら構成変更不要という条件も同時に示されている。だから、読む順番は「日本POPが含まれるので確認する」「root CA導入済みか見る」「中間CA固定の独自運用があれば別途確認する」になる。
ASMメンテはIP許可リストと監視欠測を先に見る
- 1monitor locationやstationを確認
ASM設定で利用しているmonitor locationやstationを見て、影響するstationだけを確認する。
- 2Firewall/allowlistを確認
IPベースの許可ルールがある場合は、公式ステータス上の最新IPリストを確認する。
- 3変更管理へ回す
申請、承認、反映、確認のリードタイムを入れて、6月15日前に反映できるかを見る。
- 4監視欠測を切り分ける
メンテ時間中のmonitor checksやUI停止は、アラート抑制やメンテナンスウィンドウ登録で吸収できるか確認する。
IPアドレス一覧は固定再掲せず、変更管理に使う時点で公式ステータス上の最新リストを確認する。
6月15日のApp Synthetic Monitorメンテは、Cloud SWGではなくDX App Synthetic Monitorの運用確認だ。ASMは、外部視点からWebアプリケーションやサービスを継続的にsynthetic checksする文脈で使われる。Broadcom Academyの解説でも、global stationsやon-premises stationsを使った外部からの継続監視が説明されている。
公式ステータスでは、インフラプロバイダー移行に伴い、一部のASM station IPアドレスが変わるとされている。IPベースのFirewallルールやallowlistで監視局からの通信を許可している環境では、この点が主な事前確認になる。
IPベースのFirewallルールを使う環境は更新対象になる
ASMの監視が失敗したとき、アプリケーション自体の障害なのか、監視局からの通信がFirewallで落ちているのかを切り分けるのは意外に面倒だ。今回の公式ステータスは、IPベースのルールを使う顧客に対して、新しいIPアドレスのホワイトリスト登録を求める内容として読める。
ただし、IPアドレス一覧は記事内に固定して写すべきではない。公開後に公式ステータス側で変更される可能性があるからだ。自社の変更管理に入れるときは、Broadcom Service Status上の最新のIPリストを確認し、その時点の値を社内チケットやFirewall申請に転記するほうが安全だ。
Firewall変更で見ること
| 見る場所 | 確認内容 | 注意点 |
|---|---|---|
| ASM設定 | 利用しているmonitor locationやstation | 影響するstationだけを見る |
| Firewall/allowlist | IPベースの許可ルールがあるか | FQDNや別方式で制御している場合は扱いが変わる |
| 変更管理 | 6月15日前に反映できるか | 申請、承認、反映、確認のリードタイムを入れる |
| 監視結果 | 反映後に監視が継続するか | 監視失敗をアプリ障害と誤判定しない |
監視スケジュールとUIの短時間停止を運用に反映する
公式ステータスでは、メンテ中にmonitor checksのスケジューリングやUIが短時間利用できない可能性、一部monitor locationsのassetsが利用できない可能性にも触れられている。これも、障害速報として騒ぐより、監視運用のノイズを減らすための予定情報として扱いたい。
やることは派手ではない。メンテ時間帯に監視欠測が出ても、すぐにアプリケーション障害として扱わない。必要ならアラート抑制やメンテナンスウィンドウ登録を入れる。外部監視と自社監視の両方を使っている場合は、どちらのアラートが先に鳴るかも見ておく。
IPリストは記事内で固定しすぎない
Broadcomのステータスページには、メンテ予定や影響説明が更新されることがある。ASMページも、リスケ履歴を含む形で更新されている。したがって、この記事では「このIPを登録すればよい」と固定的に再掲しない。
読者が行うべきなのは、公式ステータスページを開き、最新のIPリストを確認し、自社のFirewall申請やallowlistに反映することだ。記事の役割は、IP一覧の代替ではなく、どの担当者が何を見るかを迷わないようにすることにある。
3件を運用チェックリストに落とす
3件を同じBroadcom 6月メンテとしてまとめすぎず、担当と作業を分ける。
3件を同じ「Broadcom 6月メンテ」として見てしまうと、担当と作業が混ざる。実務では、Webセキュリティ、証明書管理、監視運用、ヘルプデスク、変更管理に分けたほうが進めやすい。
| 担当 | 確認するサービス | やること | 期限感 |
|---|---|---|---|
| Webセキュリティ | Cloud SWG HRI | HRI利用有無、対象ユーザー、Dedicated tenantとの違いを確認する | 6月7日JST夕方まで |
| 証明書管理 | Cloud SWG TLS/SSL | Cloud Services Root CA導入状況、中間CA固定運用の有無を確認する | 6月12日JST午前まで |
| 監視運用 | DX ASM | ASM station IP、Firewall allowlist、監視欠測の扱いを確認する | 6月15日JST午後まで |
| ヘルプデスク | Cloud SWG/ASM | 問い合わせ時の一次切り分けメモを用意する | 各メンテ前 |
| 変更管理 | 全体 | JSTの日付、公式ステータスURL、担当、戻し条件を記録する | 各メンテ前 |
Webセキュリティ担当が見る項目
HRIでは、対象が「Cloud SWGのHigh-Risk Isolation利用者」に絞られている。Webセキュリティ担当は、HRIポリシー、対象ユーザー、対象サイト種別、Dedicated Web Isolation tenantの有無を確認する。社内告知は、HRIを使う部署や問い合わせが出やすい窓口に絞るとよい。
HRI対象セッションで劣化が起きた場合、ユーザーは「Webが遅い」「ページが開かない」とだけ言うかもしれない。ヘルプデスク側には、通常の回線障害、Cloud SWG経路、HRI対象セッションを分ける簡単なメモがあると切り分けやすい。
証明書管理担当が見る項目
TLS/SSL中間CA置換では、root CAと中間CAを分けて扱う。Cloud Services Root CAが端末や関連デバイスへ導入済みか、古い手順書で中間CAを入れていないか、WSS AgentやProxy Forwardingなど接続方式別の確認が必要かを見ておく。
証明書まわりは、変更の要否を急いで断定しないほうがいい。公式ステータスは、推奨どおりroot CAを導入済みなら構成変更不要と説明している。つまり確認すべきなのは、自社がその推奨状態にあるかどうかだ。
監視運用担当が見る項目
ASMでは、IP allowlistと監視欠測の扱いが中心になる。IPベースのFirewallルールを使っているなら、公式ステータスの最新IPリストを変更管理に回す。メンテ時間中のmonitor checksやUI停止は、アラート抑制やメンテナンスウィンドウ登録で吸収できるかを確認する。
外部監視は、アプリケーションそのものが正常でも、監視局からの到達性が落ちるとアラートになる。今回のように監視局IP変更が絡む場合は、メンテ直後に失敗したチェックをすぐ障害扱いせず、Firewall、allowlist、ASM側ステータスの順に見るとよい。
ヘルプデスクと変更管理に残すメモ
ヘルプデスクに残すメモは、長い説明よりも時刻、対象、一次切り分けで十分だ。たとえば「6月7日17:00から6月8日03:00 JSTはCloud SWG HRIメンテ。HRI対象セッションの劣化可能性あり。Dedicated Web Isolation tenantは対象外と公式に記載」といった形で、問い合わせ時の第一声に使える情報へ落とす。
変更管理には、公式ステータスURLを必ず残したい。Service Statusは更新されることがあるため、社内チケットだけで完結させるより、公開直前とメンテ開始前に公式ページを再確認する導線を残すほうがよい。
公式ステータスを読むときの注意点
時刻、対象、影響、推奨作業に変更が入っていないかをメンテ直前に再確認する。
POP、root CA導入、ASM station利用状況は、社内設定を見ないと分からない。
対象サービス、対象時間、想定される症状、確認先URLをそろえ、対象者を絞って伝える。
公式ステータスは入口として使い、Broadcom Support、管理コンソール、社内変更管理、端末管理、Firewall設定、監視設定と突き合わせる。
Broadcom Service Statusは、運用担当者にとって一次情報に近い入口だが、個別テナントの構成までは代わりに判断してくれない。Cloud SWGの接続方式、TLS/SSL inspectionの設定、ASM stationの使い方、Firewallルールは、組織ごとに違う。
予定変更と文言更新を前提にする
今回のASMページは、リスケ履歴を含む更新が見える。つまり、メンテ通知は公開後に変わることがある。記事作成時点の予定は2026年6月15日05:00から09:00 UTCだが、最終的な運用判断では公式ステータスを再確認する必要がある。
HRIとTLS/SSLも同じだ。時刻、対象、影響、推奨作業に変更が入っていないかを、メンテ直前に見る。特にTLS/SSLは証明書に関わるため、社内手順書へ転記した内容が古くなっていないか注意したい。
個別テナントの判断は公式ページだけで終わらせない
公式ステータスは、全体の予定と影響の種類を示す。だが、自社がどのPOPを使っているか、どの端末にroot CAが入っているか、ASMのどのstationを使っているかまでは、社内設定を見ないと分からない。
したがって、この記事のチェックリストは「Broadcom公式情報をもとに何を確認するか」の入口として使う。最終判断は、Broadcom Support、管理コンソール、社内変更管理、端末管理、Firewall設定、監視設定を突き合わせて行う。
読者向け告知は対象者を絞る
社内告知では、全従業員へ広く出すより、対象サービスを使う部署に絞るほうが実務的なことが多い。HRI利用部署にはHRIの時間帯と問い合わせ方法を、証明書管理チームにはroot CAと中間CAの確認を、ASM運用にはIP allowlistと監視欠測を伝える。
広すぎる告知は、実際には影響しない利用者を不安にさせる。狭すぎる告知は、該当部署を見落とす。対象サービス、対象時間、想定される症状、確認先URLの4点をそろえると、過不足が出にくい。
次に読むなら
Broadcomの公式ステータス、製品更新、月次まとめの更新通知を追いたい場合は、<a href="https://avgo-watch.blog.mo-gmo.com/newsletter/" target="_blank" rel="noopener">ニュースレター</a>も用意している。本文の確認を済ませた後で、継続的な更新導線として使ってほしい。
更新履歴と確認日
変更管理に使う場合は、公式ステータス上の最新情報を再確認する。
- 2026年6月5日18時台 JSTに、Broadcom Service StatusのHRI、TLS/SSL中間CA置換、ASMメンテ通知を確認した。
- 本文中の日本時間は、公式ステータス上のUTC表示をJSTへ換算した。
- ASMのIPアドレス一覧は、公開後に変わる可能性があるため本文では固定再掲していない。変更管理に使う場合は、公式ステータス上の最新リストを確認する。
- Broadcom Watch JapanはBroadcomおよびVMware by Broadcomとは非提携であり、この記事は投資助言ではない。
次に読むなら
参照した主な情報源
- <a href="https://status.broadcom.com/services/cloud-secure-web-gateway/notices/nqrnqfnrvbqo6hb4-high-risk-isolation-service-update-june-07-2026" target="_blank" rel="noopener">Broadcom Service Status: High-Risk Isolation service update – June 07 2026</a>（確認日: 2026年6月5日）
- <a href="https://status.broadcom.com/notices/qcjvefz7mrbbodhu-tls-ssl-intermediate-ca-replacement" target="_blank" rel="noopener">Broadcom Service Status: TLS/SSL Intermediate CA Replacement</a>（確認日: 2026年6月5日）
- <a href="https://status.broadcom.com/notices/acfwbvodg2orjjgs-app-synthetic-monitor-asm-application-maintenance-june-15-2026" target="_blank" rel="noopener">Broadcom Service Status: App Synthetic Monitor (ASM) Application Maintenance – June 15 2026</a>（確認日: 2026年6月5日）
- <a href="https://knowledge.broadcom.com/external/article/242971" target="_blank" rel="noopener">Broadcom Knowledge Base: High Risk Isolation</a>（確認日: 2026年6月5日）
- <a href="https://docs.broadcom.com/doc/web-security-service-at-a-glance-en" target="_blank" rel="noopener">Broadcom: Web Security Service at a Glance</a>（確認日: 2026年6月5日）
- <a href="https://academy.broadcom.com/blog/aiops/dx-app-synthetic-monitor-kubernetes" target="_blank" rel="noopener">Broadcom Academy: Modernizing DX App Synthetic Monitor With Kubernetes</a>（確認日: 2026年6月5日）