📋 改訂履歴
| 2026年5月21日 | v1.0 | 初版公開。リリース背景・PHP要件・主な新機能・不具合別対処法・強制アップデート防止策・復旧手順を掲載 |
📖 この記事でわかること：
2026年5月20日にリリースされたWordPress 7.0の概要・新機能・変更点と、アップデート後に多発している不具合（ホワイトスクリーン・プラグイン競合・REST APIエラー・管理画面の表示崩れ）の原因と対処法をわかりやすく解説します。「サイトが真っ白になった」「管理画面に入れなくなった」「更新に失敗する」といった症状でお困りの方はぜひご確認ください。
2026年5月20日にリリースされたWordPress 7.0の概要・新機能・変更点と、アップデート後に多発している不具合（ホワイトスクリーン・プラグイン競合・REST APIエラー・管理画面の表示崩れ）の原因と対処法をわかりやすく解説します。「サイトが真っ白になった」「管理画面に入れなくなった」「更新に失敗する」といった症状でお困りの方はぜひご確認ください。
WordPressは2026年5月20日、メジャーアップデートとなるバージョン7.0を正式リリースしました。当初は2026年4月9日のリリースが予定されていましたが、リアルタイム共同編集機能のデータ設計上の問題など技術的な課題が発覚し、約6週間の延期を経ての公開となりました。
新機能としてAIとの連携機能や管理画面の大幅リニューアルが盛り込まれた一方、PHP要件の引き上げによる起動不能・プラグインとの競合によるホワイトスクリーン・ホスティング業者による強制更新など、複数の深刻な不具合も報告されています。本記事では、各問題の原因と対処法を詳しく解説します。
📢 急いでアップデートする必要はありません：
WordPress 7.0はセキュリティ上の緊急修正を主目的としたアップデートではなく、大型の機能追加リリースです。本番サイトをお持ちの方は、この記事で確認事項を把握した上で、ステージング（テスト）環境での検証を経てから更新することを強くお勧めします。
WordPress 7.0はセキュリティ上の緊急修正を主目的としたアップデートではなく、大型の機能追加リリースです。本番サイトをお持ちの方は、この記事で確認事項を把握した上で、ステージング（テスト）環境での検証を経てから更新することを強くお勧めします。
📌 この記事の内容
- WordPress 7.0の概要とリリース背景
- 主な新機能・変更点
- ⚠️ 最重要：PHPバージョン要件の引き上げ
- 不具合①：ホワイトスクリーン（真っ白画面）
- 不具合②：管理画面の表示崩れ・操作不能
- 不具合③：投稿の保存失敗・REST APIエラー
- 不具合④：プラグインの致命的クラッシュ（完全ロックアウト）
- ⚠️ ホスティング業者による強制アップデートへの対策
- アップデート前の確認チェックリスト
- クラッシュ時の復旧手順
- まとめ・対処法一覧
📋 WordPress 7.0の概要とリリース背景
| 項目 | 内容 |
|---|---|
| 正式リリース日 | 2026年5月20日（当初予定：2026年4月9日） |
| リリースリード | Matias Ventura |
| 動作必須PHPバージョン | PHP 7.4以上（推奨：PHP 8.3以上） |
| 動作必須DBバージョン | MySQL 8.0以上 または MariaDB 10.6以上 |
| 主な追加機能 | DataViews（管理画面刷新）・Abilities API（AI連携）・クライアントサイド画像処理・エディタのiframe化 |
| 7.0での見送り機能 | リアルタイム共同編集（RTC）※7.1以降に延期 |
| 延期の主な理由 | RTC機能のデータベース設計上の欠陥による高負荷・キャッシュ無効化問題 |
なぜ6週間も延期されたの？
当初の目玉機能だった「リアルタイム共同編集（RTC）」は、複数のユーザーが同じ記事を同時に編集できる機能です。しかし開発テストの段階で、ユーザーがキーボードを1文字打つたびにデータベースへの書き込みが発生する設計上の欠陥が発覚しました。これによりサーバーへの負荷が急増し、サイト全体の表示速度が著しく低下することが確認されました。
💡 「キャッシュ無効化ストーム」って何？（初心者向け）
ウェブサイトの表示を速くするために、サーバーは一度読み込んだデータを一時保存（キャッシュ）しています。RTCの実装では1文字入力するたびにこの保存データを無効化して書き直す処理が走るため、同時に多くのユーザーが編集するとキャッシュが嵐のように書き換えられ続け、サーバーが処理しきれなくなります。この状態を「キャッシュ無効化ストーム」と呼びます。
このリスクを回避するため、開発チームはRTC機能をWordPress 7.1以降へ延期し、データベース設計の根本的な見直しを行うことを決定しました。安全性を優先した判断です。
✨ 主な新機能・変更点
① DataViews（管理画面の大幅リニューアル）
WordPress 7.0で最も目に見える変化が、投稿一覧・固定ページ一覧・メディア一覧などの管理画面が「DataViews」という新しい仕組みに置き換わったことです。
💡 DataViewsって何が変わるの？（初心者向け）
以前の管理画面は「ページを更新しながらリストを操作する」形式でした。DataViewsではページを再読み込みせずに即座にフィルター・並べ替え・グループ化ができます。また、表示形式を「テーブル」「グリッド（カード）」「リスト」の3つから切り替えられるようになりました。大量の記事を管理しているサイトでは操作が格段に速くなります。
| 変更点 | 以前（6.x系） | WordPress 7.0 |
|---|---|---|
| 一覧画面の操作 | ページ再読み込みが必要 | ページ遷移なしで即時フィルター・並べ替え |
| 表示レイアウト | テーブル形式のみ | テーブル・グリッド・リストの3種類から選択 |
| カラム（列）管理 | 固定カラム＋プラグインによる追加 | ユーザーごとに表示設定が保存される |
| グループ化・絞り込み | 基本的なカテゴリ絞り込みのみ | 複数条件でのグループ化・絞り込みが可能 |
⚠️ 注意：プラグインとの相性問題が発生する場合があります
投稿一覧にカスタムカラムを追加したり、管理画面のデザインを変更したりするプラグインが、DataViewsと競合して表示が崩れたり管理画面が真っ白になることがあります。特に「WooCommerce（旧バージョン）」「WPML 4.9.3以前」「管理画面カスタマイズ系プラグイン」でこの問題が報告されています。
投稿一覧にカスタムカラムを追加したり、管理画面のデザインを変更したりするプラグインが、DataViewsと競合して表示が崩れたり管理画面が真っ白になることがあります。特に「WooCommerce（旧バージョン）」「WPML 4.9.3以前」「管理画面カスタマイズ系プラグイン」でこの問題が報告されています。
② Abilities API（AIとの連携機能）
WordPress 7.0には、ChatGPT（OpenAI）やClaude（Anthropic）など外部AIサービスとWordPressを接続するための標準インターフェース「Abilities API」が組み込まれました。これにより、画像の代替テキスト（alt）の自動生成や、コンテンツ提案といったAI機能をプラグインで利用できるようになります。
💡 初期状態ではAI機能はオフです（初心者向け）
Abilities APIはデフォルトで無効になっています。使用するにはAIサービスのAPIキーを別途取得して設定する必要があります。何も設定しなければ、今まで通りの動作のままで問題ありません。
③ その他の主な改善点
| 機能 | 内容 |
|---|---|
| クライアントサイド画像処理 | 画像のリサイズ・圧縮をサーバーではなくブラウザ側で処理。サーバー負荷が軽減される |
| エディタのiframe化 | 記事編集エリアを独立したフレームで表示し、テーマのスタイルがエディタを壊すことを防ぐ。完全実装は7.1へ延期 |
| 管理画面UIの刷新 | ダッシュボードのカラースキームがモダンなデザインに更新 |
| ビジュアル差分表示 | リビジョン履歴の比較画面が、変更箇所を色分けで表示するビジュアル形式に改善 |
| block.json apiVersion 3 | ブロックプラグインの記述方式が最新化（開発者向け変更） |
⚠️ 最重要：PHPバージョン要件の引き上げ
WordPress 7.0で最も注意すべき変更が、動作に必要なPHPの最小バージョンがPHP 7.4に引き上げられたことです。PHP 7.2・7.3環境のサイトでは、アップデートが自動的にブロックされるか、無理に実行した場合サイトが起動不能になります。
💡 「PHP」って何？（初心者向け）
PHPは、WordPressを動かすためのプログラミング言語です。WordPressサイトはサーバー上のPHPというソフトウェアで動いており、そのバージョンが古すぎると新しいWordPressが動かせなくなります。ちょうど「古いスマホに最新のアプリを入れようとしても動かない」のと同じイメージです。
現在のPHPバージョンを確認する方法
🔧 確認手順（WordPress管理画面から）：
- WordPressの管理画面にログインする
- 左メニューの「ツール」→「サイトヘルス」をクリックする
- 「情報」タブを選択し、「サーバー」の項目を開く
- 「PHPのバージョン」の数字を確認する
PHPバージョン別の影響と対処
| 現在のPHPバージョン | WordPress 7.0での影響 | 対処法 |
|---|---|---|
| PHP 7.1以下 | 起動不能 自動更新がブロックされるか、強制実行でサイトが完全に停止する | ホスティング管理画面からPHPを7.4以上にアップグレードする |
| PHP 7.2 / 7.3 | 起動不能 同上。自動更新が阻止される。強制実行でホワイトスクリーンまたは管理画面ロックアウト | 同上。古いテーマ・プラグインとの互換性確認も必要 |
| PHP 7.4 | 動作可 WordPress 7.0の最小要件を満たす。ただし一部の新機能の恩恵は限定的 | まず7.4に上げてから動作確認。余裕があれば8.3への移行も検討 |
| PHP 8.0 / 8.1 / 8.2 | 動作可 互換性に問題なく動作する | 古いカスタムテーマ・プラグインの非推奨関数警告に注意 |
| PHP 8.3以上 | 推奨環境 最高のパフォーマンスと安全性。Abilities APIのAI連携も最適に動作 | 新規構築・リニューアル時に推奨。古いプラグインの互換性確認を徹底する |
⚠️ PHP 7.x から PHP 8.x への大幅アップグレードを同時に行う場合の注意：
WordPressのアップデートとPHPのメジャーアップグレードを同時に行うと、問題が発生した際の原因特定が非常に難しくなります。先にPHPのみをアップグレードして動作確認を行い、その後WordPressを更新するという順番が推奨されています。特に古いカスタムテーマや長期間更新していないプラグインがある場合は注意が必要です。
WordPressのアップデートとPHPのメジャーアップグレードを同時に行うと、問題が発生した際の原因特定が非常に難しくなります。先にPHPのみをアップグレードして動作確認を行い、その後WordPressを更新するという順番が推奨されています。特に古いカスタムテーマや長期間更新していないプラグインがある場合は注意が必要です。
⚠️ 不具合①：ホワイトスクリーン（真っ白画面）
対象：主に古いテーマ・プラグインを使用しているサイト PHP 7.x → 8.x への同時アップグレード時
💡 「ホワイトスクリーン（WSoD）」って何？（初心者向け）
サイトを開いたときに画面が真っ白になって何も表示されない状態です。「White Screen of Death（WSoD）」とも呼ばれ、WordPressが致命的なエラーで起動できていないことを意味します。エラーメッセージも表示されないため、原因の特定が難しいのが特徴です。
主な原因
| 原因 | 内容 |
|---|---|
| 古いテーマのPHP構文エラー | PHP 8.x以降で廃止された書き方（「ループ外のbreak文」など）を使っている古いテーマがある場合、起動直後にPHPが強制終了する |
| 非推奨関数の呼び出し | WordPress 7.0で廃止になったコア関数を古いプラグインが呼び出し、ページ表示前にエラーが出力されてしまう |
| プラグインの致命的エラー | 特定のプラグインが起動フェーズでクラッシュし、サイト全体を道連れにする |
🔧 ホワイトスクリーンの対処手順：
- プラグインを一時的に全て無効化する：FTPまたはホスティングのファイルマネージャーで
/wp-content/plugins/フォルダを/wp-content/plugins_old/にリネームする。サイトが表示されるようになればプラグインが原因 - テーマをデフォルトに切り替える：管理画面にアクセスできる場合は「外観」→「テーマ」から「Twenty Twenty-Five」などデフォルトテーマに変更する。FTPからは
/wp-content/themes/内の使用中テーマフォルダをリネームして退避させる - デバッグログで原因を特定する：wp-config.php に以下を追加してエラーの内容を記録する（設定後は必ず元に戻すこと）
// wp-config.php に追加（調査後は必ず削除またはfalseに戻す）設定後、
define( ‘WP_DEBUG‘, true );
define( ‘WP_DEBUG_LOG‘, true );
define( ‘WP_DEBUG_DISPLAY‘, false );/wp-content/debug.logにエラーの詳細が記録される - 原因プラグイン・テーマを特定して更新または無効化する：ログに記録されたファイル名と行番号から該当プラグインを特定し、最新版に更新するか使用を中止する
⚠️ 不具合②：管理画面の表示崩れ・操作不能
対象：管理画面をカスタマイズするプラグインを使用しているサイト
どんな症状が起きているの？
確認されている症状：
- 投稿一覧・固定ページ一覧の表示が崩れる、または真っ白になる
- カスタムカラム（独自の列）が一覧画面に表示されなくなる
- 多言語プラグイン「WPML」の設定画面がフリーズする（WPML 4.9.4以降で修正済み）
- 管理画面全体のメニューやナビゲーションが機能しなくなる
なぜ起きているの？
WordPress 7.0で投稿一覧などが新しい「DataViews」に置き換わったことで、従来の方法で管理画面をカスタマイズしていたプラグイン（管理画面に列を追加するプラグイン・テーブルのスタイルを変更するプラグインなど）がDataViewsの新しいJavaScriptの仕組みと競合するケースが出ています。
🔧 対処法：
- 管理画面に関係するプラグインを一つずつ無効化して、問題のあるプラグインを特定する
- 特定できたプラグインを最新バージョンに更新する（WordPress 7.0対応版がリリースされている場合が多い）
- WPMLを使用している場合はWPML 4.9.4以降にアップデートする
- プラグインの更新版がまだない場合は、開発者への問い合わせか代替プラグインへの乗り換えを検討する
⚠️ 不具合③：投稿の保存失敗・REST APIエラー
対象：セキュリティプラグイン・CDN（Cloudflareなど）を利用しているサイト
どんな症状が起きているの？
確認されている症状：
- 記事を編集して「更新」を押すと「更新に失敗しました」というエラーが出る
- ブロックエディタのツールバーや操作ボタンが反応しなくなる
- 管理画面のサイトヘルスに「REST APIが予期しない結果を返しました」という警告が表示される
💡 「REST API」って何？（初心者向け）
REST APIは、WordPressの管理画面とサーバーがデータをやりとりするための「通信ルート」です。記事の保存・取得などの操作はすべてこの経路を通っています。セキュリティソフトや一部のファイアウォールがこの通信を「不審なアクセス」と誤解してブロックしてしまうと、記事の保存などが正常に動作しなくなります。
主な原因と対処法
| 原因 | 対処法 |
|---|---|
CloudflareなどのWAF（ウェブ防護壁）が/wp-json/ への通信をブロックしている |
Cloudflareのダッシュボードの「セキュリティ」→「WAF」→「アクティビティログ」でブロックを確認し、WordPress REST APIへのアクセスを「許可」に設定する |
| サイトのURLとWordPressのURL設定が一致していない（HTTPとHTTPSが混在するなど） | 管理画面の「設定」→「一般」で「WordPressアドレス」と「サイトアドレス」が同じ形式（https://から始まるか確認）になっているか確認する |
| セキュリティプラグインがREST APIを無効化している | 使用しているセキュリティプラグインの設定で「REST APIの無効化」がオンになっていれば、オフに変更する |
🚨 不具合④：プラグインの致命的クラッシュ（完全ロックアウト）
対象：Freemius SDK（ライセンス管理機構）を内包するプラグインを使用しているサイト
🚨 最も深刻なケース：管理画面に一切アクセスできなくなる
2026年5月18日、約40万サイト以上に導入されていた「Shortcodes Ultimate（バージョン7.5.1）」において、プラグイン内のライセンス管理用ファイル（Freemius SDK）が破損した状態で配布されました。このプラグインはWordPressの起動プロセスの極めて早い段階で読み込まれる仕組みのため、ファイル欠損によってWordPress自体が起動できなくなりました。最大の問題は、WordPressの標準的な「回復モード（リカバリーモード）」が作動するよりも前にシステムがクラッシュするため、管理者に送られる修復リンクも機能せず、FTPやサーバー管理画面からの直接操作以外に復旧手段がなかった点です。
🔧 完全ロックアウトからの復旧手順：
- FTPまたはホスティングのファイルマネージャーにアクセスする：WordPressの管理画面が開けない場合は、サーバーに直接ファイル操作でアクセスする方法しかない
- 問題のプラグインフォルダをリネームする：
/wp-content/plugins/内の該当プラグインのフォルダ名を変更する（例：shortcodes-ultimate→shortcodes-ultimate-disabled）。フォルダ名を変えるだけでWordPressは自動的にそのプラグインを無効化する - 全プラグインを一括無効化する（最終手段）：原因プラグインが特定できない場合は、
/wp-content/plugins/フォルダ全体をplugins_oldにリネームしてから、WordPress管理画面にアクセスしてプラグインを一つずつ再有効化して原因を絞り込む - 管理画面に入れるようになったら、問題のプラグインを最新版に更新する：Freemius SDK起因の問題は、多くの場合プラグイン開発者が修正版をリリースしているため、WordPressの「プラグイン」画面で更新を適用する
⚠️ ホスティング業者による強制アップデートへの対策
SiteGround・Kinsta・WP Engineなどのマネージドホスティング（管理型サーバー）では、セキュリティ上の理由からWordPressのメジャーバージョンも強制的に自動更新するポリシーを採用している事業者があります。
⚠️ 注意：wp-config.phpの設定だけでは防げない場合があります：
多くのユーザーは
多くのユーザーは
define( 'WP_AUTO_UPDATE_CORE', false ); を wp-config.php に記述すれば自動更新を止められると思っていますが、ホスティング事業者はサーバー管理者権限でこの設定を上書きして強制更新を実行できます。気づかないうちに本番サイトが7.0に更新されていたというケースが起きています。
強制アップデートを確実に防ぐ方法
🔧 必須プラグイン（mu-plugins）による防止策（上級者・IT担当者向け）：
以下のPHPファイルを作成し、サーバーの
以下のPHPファイルを作成し、サーバーの
/wp-content/mu-plugins/ フォルダ（ない場合は新規作成）に配置することで、ホスティング業者の強制更新命令をWordPress内部でブロックできます。
<?php
/*
Plugin Name: Prevent Host Forced Major Core Updates
Description: ホスト側の強制メジャーアップデートをブロックします。
Version: 1.0
*/
add_filter( ‘auto_update_major‘, ‘__return_false‘ );
このファイルを設置すると、WordPressコアがホスティング側の更新要求に対して内部的に拒否命令を返します。更新の準備ができたら、このファイルを削除してから手動でアップデートしてください。
/*
Plugin Name: Prevent Host Forced Major Core Updates
Description: ホスト側の強制メジャーアップデートをブロックします。
Version: 1.0
*/
add_filter( ‘auto_update_major‘, ‘__return_false‘ );
ℹ️ まずはホスティングの管理パネルを確認してください：
多くのホスティング事業者はコントロールパネル（cPanelやWordPress Toolkitなど）から自動更新のスケジュール変更やオプトアウトができます。mu-pluginsの操作に自信がない場合は、まずホスティング会社のサポートに「WordPress 7.0への自動更新を一時停止したい」と問い合わせるのが安全です。
多くのホスティング事業者はコントロールパネル（cPanelやWordPress Toolkitなど）から自動更新のスケジュール変更やオプトアウトができます。mu-pluginsの操作に自信がない場合は、まずホスティング会社のサポートに「WordPress 7.0への自動更新を一時停止したい」と問い合わせるのが安全です。
✅ アップデート前の確認チェックリスト
| 確認項目 | 確認方法 | 問題があった場合の対処 |
|---|---|---|
| ①PHPバージョンが7.4以上か | 管理画面→ツール→サイトヘルス→情報→サーバー | ホスティングの管理パネルからPHPバージョンを変更する（推奨：8.3以上） |
| ②MySQLが8.0以上・MariaDBが10.6以上か | 同上（「データベースサーバーのバージョン」を確認） | ホスティング会社のサポートへ問い合わせてアップグレードを依頼する |
| ③サイト全体のバックアップを取得済みか | UpdraftPlus等のバックアッププラグイン、またはホスティングの管理画面から取得 | 必ずアップデート前に実行する。バックアップなしでの更新は絶対に避ける |
| ④使用プラグインのWordPress 7.0対応状況を確認済みか | 各プラグインの公式ページや更新ログで「WordPress 7.0 tested」の記載を確認 | 未対応プラグインはステージング環境で動作確認してから更新する |
| ⑤ステージング（テスト）環境で動作確認済みか | ホスティングのステージング機能、またはLocalなどのローカル環境でテスト | 本番環境への適用は、テスト環境で問題がないことを確認してから行う |
| ⑥ホスティングの強制自動更新設定を確認済みか | ホスティングの管理パネルのWordPress設定を確認 | 強制更新が有効な場合は一時停止の設定、またはmu-pluginsで防止策を設置する |
🛠️ クラッシュ時の症状別復旧手順
| 症状 | まず試すこと | それでも解決しない場合 |
|---|---|---|
| サイトが真っ白（WSoD） | FTPでプラグインフォルダを plugins_old にリネーム。表示が戻ればプラグインが原因 |
debug.logでエラー内容を確認し、該当テーマ・プラグインを特定して更新または無効化 |
| 管理画面に入れない（ロックアウト） | FTPまたはファイルマネージャーで問題プラグインのフォルダをリネームして無効化 | バックアップからサイトを復元する |
| 記事の保存が「失敗」する | サイトヘルスでREST API警告を確認。CloudflareのWAFログでブロックを確認 | WAFに例外設定を追加、またはClassic Editorプラグインを一時的に有効化 |
| 「データベースの更新が必要です」画面が出る | 画面に表示されるボタン（「WordPressデータベースを更新する」）をクリックする。これはエラーではなく正常な処理 | ボタンが出ない・更新後もループする場合は、DBアクセス権限をホスティング会社に確認する |
| 特定のページが404エラーになる | 管理画面の「設定」→「パーマリンク設定」を開き、何も変更せず「変更を保存」をクリック。URLルールが再生成される | .htaccess ファイルをFTPで確認し、WordPressのデフォルト内容で上書きする |
📊 まとめ：不具合と対処法一覧
| 不具合・懸念事項 | ステータス | 重要度 | 対処法・推奨アクション |
|---|---|---|---|
| PHP 7.2/7.3環境でのサイト停止 | 要対応 | 最高 | 更新前にPHPを7.4以上（推奨8.3）にアップグレード |
| ホワイトスクリーン（WSoD） | 発生中 | 高 | プラグインを全無効化→原因特定→更新または乗り換え |
| 管理画面の表示崩れ・操作不能 | 発生中 | 高 | 管理画面系プラグインの最新版更新（WPMLは4.9.4へ） |
| 投稿保存失敗・REST APIエラー | 発生中 | 高 | WAFの例外設定・URLの整合性確認 |
| プラグインによる完全ロックアウト | 発生中 | 最高 | FTPでプラグインフォルダをリネームして無効化 |
| ホスティング業者の強制アップデート | 継続中 | 高 | mu-pluginsで強制更新フィルターをブロック、またはホスティング設定で一時停止 |
| リアルタイム共同編集の未実装 | 7.1へ延期 | 低（情報として把握） | WordPress 7.1以降のリリースを待つ |
📝 まとめ：サイト種別ごとの推奨アクション
WordPress 7.0はDataViews・Abilities APIなど将来性のある大型アップデートですが、リリース直後は多くの不具合報告が出ています。以下を参考に、あなたのサイト状況に合った対応をしてください。
- 🏢 収益化・問い合わせフォームが重要なビジネスサイト：リリース直後の更新は推奨しません。ステージング環境での検証を経てから適用してください。少なくとも2〜4週間様子を見て、主要プラグインの7.0対応状況を確認してから更新が安全です
- 📝 個人ブログ・情報サイト：PHP・DBバージョンを確認し、バックアップを取ってから更新可能です。多くの場合は問題なく動作しますが、使用プラグインの対応確認を忘れずに
- 🛒 WooCommerceを使用したECサイト：WooCommerce公式の7.0対応状況を確認してから更新してください。複数の決済プラグインやカスタマイズが絡むサイトは特に慎重に対応を
- 👨💻 IT担当者・制作会社の方：管理しているサイト全体のPHPバージョンを確認し、強制アップデートを防ぐmu-pluginsの設置、コレクション機能廃止への移行案内を先行して実施してください
- 🔒 全サイト共通：アップデート前のバックアップは絶対に怠らないでください。問題発生時に確実に復旧できる手段を確保してから更新することが最も重要です
本記事は公式情報のアップデートに合わせて随時更新予定です。
