結論：稼働確認ではなく「ゼロから戻せるか」で保守性を判断する
Broadcomは公式Knowledge Baseで、Automic Download Center、Documentation、Automation Marketplaceなどautomic.com上の旧デジタルplatformをBroadcom側へ集約し、2026年8月24日までに廃止すると案内しています。downloadとMarketplaceはBroadcom Support Portalへ、従来gcr.ioから取得していたDocker imageはpackages.broadcom.comへ移ります。
この案内は、稼働中のAutomic製品やjobが8月24日に一律停止するという意味ではありません。経営上の問題は、障害、host交換、DR切替、増設、patch適用のとき、現在と同じversion、Action Pack、plugin、container image、文書を取得できるかです。
この記事を読むべきなのは、基幹batch、job管理、運用自動化を長年ベンダーへ任せている中堅企業の経営者、CIO、情シス、運用責任者です。「今動いているから大丈夫」という判断をやめ、復旧に必要な証拠を発注側でも持つための再現性台帳を示します。
INSTANT ESTIMATE
計算式より、60秒で概算を出しませんか？
システム種別・規模・連携先を選ぶだけで、開発費用・期間・月額運用費の概算をその場で表示します。
URL変更ではなく、復旧供給網の変更と捉える
横にスクロールして確認できます
| 旧依存 | 公式の移行先・変更 | 自社で壊れる可能性があるもの |
|---|---|---|
| Automic Download Center | Broadcom Support Portal | bookmark、取得手順、権利、version検索 |
| Automic Documentation | Broadcom側の文書導線 | runbook内のlink、構築手順、障害調査 |
| Automation Marketplace | Broadcom Support Portal | Action Pack、integration、依存version |
gcr.ioのDocker image | packages.broadcom.com | CI/CD、pull secret、registry allowlist、proxy |
automic.comの旧URL | content提供終了 | script、wiki、監視、社内portal、vendor手順 |
旧URLがbrowserで開かないことより重大なのは、build script、container platform、firewall、proxy、運用手順が旧取得元を前提としていることです。画面上のbookmarkだけを直しても、夜間の自動buildやDR siteからの取得が失敗する場合があります。
「今は動く」が危険な4場面
1. 障害hostを再構築するとき
稼働serverにbinaryが残っていても、installer、patch、license、設定exportが別保管されていなければ、新hostを同じ状態へ戻せません。担当vendorの個人PCだけにinstallerがある状態も再現性とは呼べません。
2. Action Packやpluginを入れ直すとき
運用automationは本体だけで成立しません。ERP、cloud、database、file transferへ接続するAction Packやpluginと、そのversion組合せが必要です。Marketplace移行後に同名の最新版を入れても、現在のjobと互換とは限りません。
3. containerを再pullするとき
tagだけを記録し、digestを固定していない場合、同じ名前で同じimageを取得できる保証が弱くなります。registry変更に伴い、認証情報、DNS、proxy、firewall allowlist、image scanの取得元も見直します。
4. 保守会社を変更するとき
旧vendorだけがSupport Portalのentitlement、download手順、case履歴を持っていると、契約終了時に発注企業が資産を引き継げません。製品利用権とportal accessを誰の法人accountで保有するかを確認します。
発注側が持つ「復旧再現性台帳」12項目
横にスクロールして確認できます
| 項目 | 記録する内容 | 合格証拠 |
|---|---|---|
| 1. system・業務 | productが支えるjob、締め、連携、停止影響 | 業務ownerとRTO／RPO |
| 2. product | component、edition、version、build | 稼働画面・command出力 |
| 3. installer | file名、size、取得元、取得日 | 保管fileとread権限 |
| 4. 完全性 | hash、signature、vendor照合結果 | SHA-256等の記録 |
| 5. entitlement | 契約番号、support ID、法人account、owner | portalへ実際にloginできる |
| 6. patch | 適用済みpatch、順序、依存条件 | patch履歴とrollback手順 |
| 7. Action Pack／plugin | 名前、version、取得元、互換性 | packageと検証結果 |
| 8. container | registry、repository、tag、digest | 新registryからpullできる |
| 9. 設定・秘密 | 設定export、certificate、鍵、license | 復元手順と権限制御 |
| 10. network | DNS、proxy、allowlist、接続先 | DR環境からの疎通結果 |
| 11. 文書 | install、upgrade、障害、rollback | 社内保管版と公式URL |
| 12. 復旧試験 | 実施日、環境、所要時間、差分、owner | 独立環境での起動・job試験 |
installerを社内へ複製できるか、どの保管が契約上許されるかはlicenseと契約に従います。無断転載や権利回避をせず、再取得手順とentitlementを優先して証拠化します。
停止日当日に行う8手順
- source code、script、wiki、ticketから
automic.comとgcr.ioへの依存を検索する - 稼働product、Action Pack、plugin、containerのversionを現物から取得する
- Broadcom Support Portalへ発注企業の管理accountでloginし、entitlementを確認する
- 必要なdownloadとMarketplace資産を新しい導線で検索できるか確認する
packages.broadcom.comへの認証、DNS、proxy、firewall、image scanを確認する- CI/CD、IaC、runbook、bookmark、監視を新しい取得元へ更新する
- 契約上許可された範囲でhash、digest、文書、設定、取得手順を再現性台帳へ記録する
- productionを壊さない隔離環境で、install、起動、接続、代表jobまで復旧試験する
旧サイトの全pageが記事公開時点ですでに応答しないことをGXOが実測・保証するものではありません。公式案内のdecommission期限を基準に、redirect頼みではなく新しい取得先で復旧できることを確認してください。
100点の復旧再現性監査
以下はBroadcomの公式採点ではなく、移行案内を基にGXOが作成した保守・復旧判断用の診断表です。
横にスクロールして確認できます
| 領域 | 配点 | 満点の条件 |
|---|---|---|
| 業務影響・RTO | 10 | productと締め・売上・顧客影響が結びつく |
| version・依存 | 15 | 本体、patch、Action Pack、pluginを現物確認 |
| 取得権・account | 15 | 自社法人accountでportalとentitlementを確認 |
| artifact完全性 | 15 | file、hash、signature、container digestを記録 |
| 新取得先・network | 10 | registry、proxy、allowlist、認証を検証 |
| 設定・秘密・license | 10 | 安全に復元でき、ownerと期限が分かる |
| 文書・責任分界 | 10 | 最新手順、契約、vendorと自社の担当がある |
| 独立復旧試験 | 15 | clean環境で代表jobまでRTO内に戻せる |
60点未満は「保守契約がある」だけで復旧可能と判断しません。60〜79点は重要systemから取得権とartifactを確定します。80点以上でも、独立環境で復旧試験をしていなければ完全合格にはしません。
次の状態は点数に関係なく停止条件です。
- installer、license、portal accessを退職者やvendor個人だけが持つ
- 本体versionだけを記録し、Action Pack／pluginを把握していない
- container tagだけを記録し、取得元とdigestがない
- DR siteから新registryへ接続できない
- 復旧手順をproductionでしか試せない
- 「旧URLがredirectするはず」を恒久対策にする
ベンダーと保守会社へ確認する10問
- 稼働version、patch、Action Pack、pluginの現物一覧はどこか
- それぞれを新portalで再取得できるか
- portal entitlementは誰の法人accountと契約に紐づくか
- 保守会社変更時にaccount、case履歴、artifact、手順を引き継げるか
- Docker imageの新registry、tag、digestは何か
- CI/CD、proxy、firewall、secretの変更箇所はどこか
- installerと文書の社内保管は契約上どこまで許されるか
- clean環境へ復旧した最終日と所要時間はいつか
- 取得不能・互換性不良時の代替versionとrollbackは何か
- 旧site依存をなくしたことを、どの検索結果と試験で検収するか
90日で「担当者の記憶」を会社の復旧能力に変える
横にスクロールして確認できます
| 期間 | やること | 成果物 |
|---|---|---|
| 当日〜1週 | 旧URL、version、取得権、registryを棚卸し | 復旧再現性台帳、未確認list |
| 2〜4週 | 新portal・registry、CI/CD、文書を更新 | 取得証跡、変更差分、責任分界 |
| 2か月目 | 隔離環境でrebuildと代表jobを試験 | 復旧report、RTO差分、改善backlog |
| 3か月目 | 半期復旧試験とEOL監視を契約へ入れる | 運用KPI、更新calendar、更改判断 |
GXOへ相談する場合の流れ
復旧再現性台帳で自己点検
↓
製品・version・取得権・artifact・文書の棚卸し
↓
DR／再構築の第二意見と限定復旧試験
↓
CI/CD・運用自動化・監視の更新
↓
レガシー刷新、cloud移行、継続運用
再現性台帳と限定復旧試験を有償の前工程にすると、障害後に無制限の調査を始めることや、緊急で高額な代替調達をする事態を減らせます。適合案件をDevOps、DR、運用自動化、レガシー刷新へつなぎ、売上を作りながら緊急対応の赤字原価を抑えます。
今日動くシステムを、明日ゼロから戻せますか
製品、version、Action Pack、container、取得権、network、手順を棚卸しし、保守会社の説明だけでなく復旧証拠で判断できる状態を作ります。
FAQ
8月24日にAutomicのjobがすべて止まるのですか
そのような案内ではありません。Broadcomが案内しているのは旧download、documentation、Marketplaceなどのdecommissionです。稼働影響は自社の取得元、version、連携、network、運用構成で確認します。
vendorが保守していれば台帳は不要ですか
必要です。vendorが取得できることと、契約終了・障害・担当交代後に発注企業が復旧を統制できることは別です。少なくともproduct、version、権利owner、取得手順、復旧試験の証拠を共有します。
最新版へupgradeすれば解決しますか
upgradeは選択肢ですが、既存job、Action Pack、plugin、OS、databaseとの互換性確認が必要です。取得先変更だけを理由に無条件で一括upgradeせず、現状再現と移行を分けて計画します。
関連記事・サービス
参考情報
- Broadcom Knowledge Base 451183: Migration of automic.com Digital Platforms（2026年8月24日確認、一次情報）
本記事はBroadcom公式Knowledge Baseの移行案内を、復旧・保守判断へ翻訳したものです。Automic製品、job、全旧siteの稼働状況をGXOが観測したものではありません。製品version、Support Portal、entitlement、license、artifact保管、registry利用条件は最新のBroadcom公式資料と契約で確認してください。
