私はこのレビューのために、2つのWordPressアプリケーションをCloudways Site Manager に登録しました。1つはアプリケーション自体のサイドバー内にあるオンボーディング画面から、もう1つはアカウントレベルにある一括フローからです。
そこから、4つのプラグインに対して実際のSafe Updateを実行し、両方のサイトをカバーする共有の自動更新スケジュールを作成し、アクティビティログを有効にし、アカウントレベルのダッシュボードで同じ情報が複数の場所に表示されることを理解するのに十分な時間を費やしました。そして、それが思った以上に重要である理由も。
Site Managerは、以前のCloudwaysアドオンであるSafeUpdatesに取って代わりました。 SafeUpdatesが何をできなかったのかを理解すると、現在の製品におけるほとんどすべての設計上の判断が説明できます。
SafeUpdatesはすべてをSSH経由で実行していたため、数サイト以上を管理する人にとっては特有の問題が生じていました。
20以上のWordPressインストールを管理するエージェンシーは、要するに、このツールはスケールし始めるまで機能したが、Cloudwaysを使っていた理由そのものがスケールすることだったのだ、とCloudwaysに伝えていました。
Site Managerは、そのフィードバックに対する直接的な答えです。その文脈は、このレビューの残りを読むうえで重要です。なぜなら、まだPublic Previewであるにもかかわらず製品の一部が異常に成熟して感じられる理由、そして初日に直面することになるオンボーディングのような他の部分には、まだ継ぎ目が見える理由を説明しているからです。
この背景を踏まえたうえで、次の問いは範囲です。このツールは実際にどこまで届くのか。オンボーディング、更新、スケジューリングに入る前に、Site Managerが何をカバーし、何をカバーしないのかを正確にしておく価値があります。率直な答えは、単純なイエスかノーよりも複雑だからです。
アカウントレベルのSite Managerに登録できるすべてのアプリケーションは、アプリごとの画面からであれ、Integrationsの下にある一括ウィザードからであれ、すべてすでに自分のCloudwaysアカウント内にあるサーバー上のものでした。
外部ホストにあるインストールの認証情報を貼り付ける欄も、まったく別のホスト上で動作するサイト向けのコネクタもありませんでした。
このレビューで取り上げる完全な機能セット、Safe Updateのステージングクローン、ビジュアル回帰テスト、アクティビティログ、一括スケジューリング、そのすべては、このネイティブなCloudwaysホスト層の中にあります。
Cloudwaysはまた、WP Remoteと共同開発した、同じくCloudways Site Managerという無料のWordPressプラグインも提供しています。
ネイティブダッシュボードとは異なり、このプラグインはホスティング先に関係なくWordPressサイトに直接インストールされるため、同じ中央集約ビューの一種に外部の非Cloudwaysサイトを取り込むことができます。
ただし、これは本当に別の製品であり、その差は重要です。
| 機能 | ネイティブ Site Manager（Cloudwaysホストのアプリ） | Site Managerプラグイン（任意のホスト） |
|---|---|---|
| 中央集約ダッシュボード | Yes | Yes |
| コア、プラグイン、テーマの更新 | Yes | Yes |
| Safe Update（ステージングクローン + ビジュアル回帰） | Yes | No |
| サーバーレベルのキャッシュ（Varnish、Redis、Cloudflare） | Yes | No |
| アクティビティログ | Yes（Pro） | 同等のものはない |
| 料金 | 無料（Basic）/ 有料（Pro） | 無料 |
このプラグインは、WordPress自身の自動更新も有効な間は無効にします。これは、リモート管理中の競合を避けるためのCloudways側の意図的な選択です。
Cloudwaysは、プラグイン経由の利用は最終目的地ではなく足がかりだと明言しています。フルスタック、自動バックアップ、ワンクリックのステージング、Cloudflare連携、管理キャッシュが欲しいなら、推奨されるベストプラクティスは、外部サイトを長期的にリモート管理することではなく、Cloudwaysへ移行することです。
ポートフォリオ全体がCloudways上にあるエージェンシーにとっては、この話は関係ありません。しかし、いくつかのサイトを他所で運用している人、そしてこれまで私が話してきたエージェンシーの多くもそうですが、少なくともいくつかのサイトは別の場所にあります。そうした場合、プラグインは基本的な監視と更新のための現実的な選択肢です。ただし、ネイティブダッシュボードが行うことの代替ではありません。
範囲の問題が片付いたら、実際の作業に入ります。つまり、WordPressアプリケーションを本当に登録することです。CloudwaysはネイティブSite Managerへの入り口を2つ用意しており、同じ仕事に向いているわけではありません。
最初にそこへ行ったときの手順を正確に説明します。Cloudwaysのホームダッシュボードからサーバーをクリックし、その上にあるWordPressアプリケーションを開くと、そのアプリのAccess Detailsページに移動します。
そこの左サイドバーには、Access Details、Staging Management、Monitoring、Application Security、Domain Management、そしてSite Managerが並んでおり、「New」タグが付いていました。それをクリックすると、「Simplify App Management with Site Manager」という画面に直接移動し、そのアプリだけに範囲が限定され、BasicとProの2つのプランカードが並んでいました。
私はGet Proをクリックしました。そこから事態がおかしくなりました。
画面は「Subscribing to the Site Manager Plan…」に変わり、Cloudwaysがプラグインをインストールしてサイトデータを同期しており、アプリケーションのサイズによっては数分かかることがある、というメッセージが表示されました。
約2分間実行された後に失敗し、赤いエラーノーティフィケーションが返ってきました。「Please delete existing plugin and install again.」です。私は事前にインストールしていたプラグインはなかったので、そのメッセージだけでは実際に何が問題だったのかは分かりませんでした。
同じプラン画面で、何も変更せずにGet Proをもう一度クリックしました。2回目は成功しました。約3分間実行され、Site Managerプランのサブスクライブが完了したことを知らせる緑の成功通知が表示され、アプリのSite Manager Overviewページに着地しました。プラグイン数、テーマ数、パフォーマンススコア、Manage Updatesテーブルがすべて埋まっていて、すぐに使える状態でした。
複数のサイトを管理しているようになった瞬間に使うべきなのはこちらの方法です。実際に私が見つけて使った手順を正確に説明します。
Cloudwaysのホームダッシュボードから、左側ナビゲーションにはHome、Flexible、Autonomous、Integrations、Agency Partnersのアイコン列があります。私はIntegrationsをクリックしました。すると、Site Manager（「New」付き）、Application Migration、DNS Made Easy、CookieYes、Equalize Digital Accessibility Checkerなどのカードが並ぶパネルが開きました。
Site Manager カードをクリックすると、パス1とはまったく異なる画面に移動しました。Integrations → Add-Ons → Site Managerというパンくずの下にあり、独自のタブ列、Overview、Manage Updates、Auto Updates、Historyがありました。
このOverviewページが本当のコマンドセンターです。アカウント全体の統計、Total Apps on Site Manager、Apps on Free Plan、Apps on Pro Plan、Apps with Auto Updatesが表示され、その下に登録済みのすべてのアプリを一覧するManage Applicationsテーブルがあります。
さらに追加するには、テーブル右上のAdd Apps to Site Managerをクリックしました。すると2ステップのウィザードが開きました。
リストの上にある注記では、ステージングアプリ、停止中のサーバー上のアプリ、そして旧SafeUpdatesアドオンをすでに実行しているアプリは除外されると説明されていました。私は必要なアプリにチェックを入れ、Select Planをクリックしました。
ウィザード画面に入ってしまえば、全体の流れは1分未満で完了し、ステップ1でチェックしたすべてのアプリに一度に適用されました。サイトごとにプラン選択を繰り返す必要はありませんでした。
両方の経路でアプリを登録した今、この製品の日常運用についての見方を変えた発見があります。同じサーバー上でSite Managerがすでに別のアプリを管理している状態で、そのサーバーに2つ目のWordPressアプリケーションを追加しました。
その隣にある既存のアプリをSite Managerはすでに把握していたので、新しいアプリも自動的に表示されると思っていました。しかしそうはなりませんでした。アカウントレベルのダッシュボードの「Total Apps on Site Manager」カウントは、新しいアプリを手動でオンボードするまで、まったく変わりませんでした。
これは設計上の選択ですが、運用上のコストを伴う設計上の選択でもあります。
Site Managerは、本当に使える無料プランと、エージェンシーが実際にワークフローを構築するために必要な機能を解放するProプランに分かれています。
| 機能 | Basic（無料） | Pro |
|---|---|---|
| Site Overview | Yes | Yes |
| ユーザー、テーマ、プラグインの管理 | Yes | Yes |
| Quick Updates | Yes | Yes |
| WordPress Single Sign-On | Yes | Yes |
| Centralized Dashboard | Yes | Yes |
| Safe Updates（ステージングクローン + 回帰テスト） | No | Yes |
| スケジュールされた自動更新 | No | Yes |
| サイトパフォーマンス監視 | No | Yes |
| アクティビティログ | No | Yes |
| 更新履歴 | No | Yes |
Basicは、機能を削った試用版ではありません。実際のサイト概要、wp-adminに触れずにユーザー、テーマ、プラグインを管理する機能、ワンクリックのWordPressシングルサインオン、Quick Updates、そして注目すべきは中央集約ダッシュボードそのものまで含まれています。
Cloudwaysは、「すべてのサイトを一か所で見る」というコア体験を有料化しませんでした。有料化されているのは、そのダッシュボードを安心して操作できるほど信頼できるものにする要素です。
Proは現在、Public Preview期間中は表示価格にかかわらず無料で使えます。表示価格は1アプリあたり月額$3で、5アプリを超えると1アプリあたり$2に下がります。
その割引のしきい値は、Proが本当に安くスケールすると思い込む前に、計算しておく価値があります。
| 管理サイト数 | Proコスト（表示価格） |
|---|---|
| 3 sites | $9/month |
| 5 sites | $10/month ($2/app) |
| 10 sites | $20/month |
| 25 sites | $50/month |
| 50 sites | $100/month |
これらの数字のどれも、バックアップのない壊れた1回の更新がクライアントの信頼に与えうるコストと比べれば不合理ではありません。しかし、アプリごとの価格設定は、請求額がより高い階層で段階的に安くなる競合ツールのようにはならず、ポートフォリオに対して一直線に増えていきます。
登録と価格については終わりました。残るレビューは、日々の使い方が実際にどう見えるかです。まずは、理解しておく価値のあるアーキテクチャから始めます。
ここが、Site Managerの設計の中で理解するのに最も時間がかかった部分で、インターフェイス自体ではどこにも説明されていません。
これらは同じ部屋への3つの扉です。アプリごとのビューは、すでにその特定のサイト内で作業している誰かが、たまたま保留中の更新に気付いたときのためのものです。アカウントレベルの行アクションは、ポートフォリオ全体を見渡して、1つのサイトに今すぐ対応する必要があると判断した人のためのものです。
スケジューリングタブは、人間をループから外すためのものです。
先ほど説明した3つの扉のうち、このセクションでは最初の2つ、つまりアプリごとのビューとアカウントレベルの行アクションを扱います。どちらも同じ更新メカニズムを開くからです。
すべてのプランでQuick Updateが使えます。適用は数秒で完了し、更新は互換性チェックなし、事前バックアップなしで本番に直接インストールされます。
Cloudways自身のインターフェイス文言はそのトレードオフについて正直で、更新が互換性を持たない場合に「may carry risks if updates aren’t compatible.」と警告しています。
私はこのテストでQuick Updateを実行しませんでした。そのため、失敗した場合に画面上で実際にどう見えるのかは説明できません。これはレビューにおける本当の欠落であり、私や、失敗を起こしたことがない他の誰かのQuick Updateの失敗時の挙動についての主張は、適切な懐疑心をもって扱うべきです。
Safe UpdateこそがProの価格に見合う機能であり、「バックアップしてから更新」よりも手順が複雑なので、全体を確認する価値があります。
実際にどう起動したかを正確に説明します。Integrations → Site Managerの下にあるアカウントレベルのOverviewテーブルから、保留中の更新があるアプリの行を見つけ、その行の末尾にある3点のActions メニューをクリックしました。すると、WP-Admin、App Overview、Manage Updates、Manage Planの4つのオプションが開きました。私はManage Updatesをクリックしました。
すると、保留中の更新があるすべてのプラグインを一覧するモーダルが開きました。私の場合は4つ、Breeze、Elementor、Object Cache Pro、WP ULikeで、それぞれ現在のバージョンと更新先バージョンがチェック済みの項目として表示されていました。
リストの下には2つのラジオオプション、Quick UpdateとSafe Updateがあり、それぞれにトレードオフを説明する1行の説明が付いていました。私はSafe Update を選び、Proceedをクリックしました。
次に開いたモーダルは単一の進行スピナーではなく、リアルタイムで更新される段階的なチェックリストを表示します。
Staging environment:
Production:
私は6:21 pmに実行を開始し、6:27 pmに終了しました。4つのプラグインで、ステージングから本番までの完全なサイクルを含めて6分です。モーダル自体は、通常は1分未満で完了すると予想させますが、私の実行はそれを大きく上回りました。
表示される見積もり時間と実際の所要時間の差は、バッチのプラグインに対してメンテナンス時間帯にSafe Updateを実行するなら、秒ではなく分単位で計画すべきだということを示しています。プラグイン数が増えるほど、その傾向は強まります。
成功通知が結果を確認し、完了した瞬間にアカウントレベルのHistoryタブには「On-Demand Successful: Plugins (4)」と記録され、詳細へのリンクも表示されました。
その一連の流れ、つまり何かが起きるのを見て、その直後に永久的な記録を指し示せることは、まさにエージェンシーがクライアント向けに必要とする証拠です。そして、SafeUpdatesは決してそれを与えてくれませんでした。
この2つはどちらもオンデマンド更新画面ではなくスケジューリングフロー内にあるため、見落としやすいです。
この2つの既定値は、夜間の無人更新が、キューに入った1つのフラグ付きプラグインで起こされるのか、それとも1つの互換性のないテーマがプロセス全体を途中で止めてしまうのかを決めます。スケジュールを無人で信頼する前に、両方確認する価値があります。
ここまでが最初の2つの扉です。このセクションでは3つ目、つまり人間をループから外すことを扱います。アカウントレベルのSite Managerページから入るAuto Updatesタブは、「多数のサイトを1つのように扱う」という訴求が本当に機能するのか、それとも崩れるのかが分かる場所です。私の場合は、機能しました。
実際にどう設定したかを説明します。Integrations → Site Managerから、上部の列にあるAuto Updates タブをクリックしました。
まだ何もスケジュールされていない状態では、ページは空の状態、「No Auto Updates Schedule」を表示し、1つのボタン、Set Auto Update Scheduleだけがありました。
それをクリックすると、「Set Auto Update Schedule」というウィザードが開き、次の項目を一度に案内されました。
次に、「Create Auto Update Schedule」という2番目の画面が開き、次の内容が表示されました。
下部のSet AutoUpdate Scheduleをクリックすると保存され、ステップ2で選択したすべてのアプリに適用されました。サイトごとに設定を繰り返す必要はありませんでした。
3つの扉とその背後にある更新メカニズムは、どのように行うかをカバーしています。この最後の機能は、その証拠、つまり更新プロセスとは別に残る何が起きたかの永続的な記録を扱います。
それを有効化した手順を正確に示します。
そのアプリ自身のSite Manager Overviewページ、つまりパス1から登録したあとにたどり着く同じページに、パフォーマンスリングの隣に「Activity Logs are Disabled」と書かれたカードがあり、短い説明と1つのボタン、Enable Activity Logsがありました。
それをクリックするとカードは即座に更新され、確認モーダルも追加手順もありませんでした。直後にアカウントレベルのManage Applicationsテーブルを確認すると、Integrations → Site Managerの下で、そのアプリのActivity Logs列はすでにDisabledからEnabledへ切り替わっており、ページを再読み込みする必要もありませんでした。
この機能はProの対象であり、エージェンシーが最終的にクライアントから必ず聞かれる質問に答えるために存在します。何を、いつ、誰が変更したのか、です。
これがなければ、その答えは通常、WordPressのロギングプラグインの中にあり、そのサイト自身のデータベースに書き込まれています。そうした方法では、時間とともに肥大化し、改ざんへの防御もありません。WordPressインストールの外側、ホスティング層の内部にその記録を持つことは、クライアント向けサイトにとって、まったく異なるレベルの信頼性です。
機能全体、コスト、そして粗い部分のすべてを踏まえたうえで、最後の問いは、あなたのポートフォリオに本当に合うかどうかです。
最も明確に合うのは、複数、できれば多数のWordPressサイトを運用しているエージェンシーまたはフリーランス開発者で、しかもそれらがすべてCloudways内にある場合です。壊れた更新が、単なる個人的な不便ではなく、クライアントの信頼に実際のコストを与えるような環境です。
Safe Updateのワークフローと一括スケジューリングは、各サイトを個別に確認するのがまだ妥当とは言えなくなる段階で表面化する問題を解決するために、まさに存在しています。
混在ポートフォリオの人には部分的に合います。無料のSite Managerプラグインを使えば外部サイトを基本的な監視と更新に取り込めますが、ネイティブダッシュボードを有料で使う価値を生み出している機能、つまりステージングベースのSafe Update、ビジュアル回帰、アクティビティログは、そのサイトが実際にCloudwaysへ移るまで利用できません。
単一サイト所有者には、単純に不要です。無料プランは技術的には動くでしょうが、この製品全体は、単一サイトでは発生しないポートフォリオ規模の問題を解決するために存在しています。
はい、Site Managerは導入する価値があります。ただし1つ条件があります。サイトがすでにCloudways上にあることです。その範囲内では、Site Managerは約束したものを提供します。つまり、実際のクロスアプリダッシュボード、更新前にバックアップを取るSafe Updateの経路、そして更新をアプリごとのログイン作業ではなくフリート全体のアクションとして扱う一括スケジューリングです。
その境界の外では、明確な移行誘導が付いた軽量ツールにすぎません。最適な用途は、クライアントサイトをCloudwaysに集約していくエージェンシーで、何が、いつ変更されたのかを示す場所を1つ持ちたい場合です。
| Description | Expert Review |
|---|---|
| スピード、安全性、手間いらずのアップデートを備えたマネー�... | Read Wordpress Hosting Review |
| 柔軟かつ高性能で、スケーラブルなリソースと信頼性を備えた�... | Read Cloud Hosting Review |
| ビジネスコミュニケーションのニーズに合わせた、安全かつ効�... | Read Email Hosting Review |
| 高速かつeコマースのパフォーマンスを強化した最適化されたMag... | Read Magento Hosting Review |
| Read WooCommerce hosting Review | |
| Read VPS Hosting Review |
はい。Cloudways Site Manager は、Cloudways アカウント内で既にホストされている WordPress アプリケーションの更新、パフォーマンス監視、アクティビティログを一元管理するネイティブのアドオンです。別途提供される無料のコンパニオンプラグインは、どこにホストされている WordPress サイトにも軽量な監視および更新機能を拡張します。
このレビューでテストしたネイティブのダッシュボードではなく、Cloudways上で既にホストされているアプリケーションに限定されています。Cloudways Site Managerと呼ばれる無料プラグインもあり、WP Remoteと共同開発されていて、外部サイトを取り込み、コア、プラグイン、テーマの監視と更新を行えますが、Safe Updateのステージングクローン、視覚的回帰テスト、サーバーレベルのキャッシングはありません。
Basicプランは無料で、サイトの概要、ユーザーおよびプラグインの管理、Quick Updatesを利用できます。Proでは、Safe Updates、スケジュール設定、パフォーマンス監視、アクティビティログが月額1アプリあたり3ドルで追加され、5つ以上のアプリでは2ドルに下がります。また、現在はPublic Preview期間中は無料で利用できます。
クイックアップデートは、バックアップや互換性チェックなしで変更を数秒で本番環境に直接適用します。セーフアップデートは、ステージングクローンを作成し、互換性を確認し、各パッケージを更新して、視覚的回帰テストを実行し、そのテストに合格した場合にのみ本番環境へ反映します。
はい。新しいアプリケーションは、すでに他の Site Manager アプリが稼働しているサーバーに追加された場合でも、自動的には登録されません。各サイトは、それぞれ個別に、または Integrations の一括ウィザードを通じて、独自のオンボーディング手順を実行する必要があります。
HostAdvice.com は、他のいかなる機関からも完全に独立したプロのウェブホスティングレビューを提供します。当社のレビューは偏らず誠実で、全てのレビューが同じ基準で書かれています。
リストされているレビュー対象の数社からのキックバックはありますが、サービスと製品の報酬はレビューの評価や結論に影響は及ぼしません。報酬がその会社のランキングに影響することもありません。この報酬は、アカウントの購入費用、テスト費用、査定者に支払われるロイヤルティに使われます。
