複数のWordPressサイトを一元管理─MyKinstaで効率化する方法

Kinstaの制作会社向けサーバープランでは、すべてのクライアントサイトをMyKinsta（Kinstaの専用コントロールパネル）上で一元管理可能です。サイトを柔軟に管理できる一方、多数のサイトをきちんと整理して運用するには、そのための仕組みを整える必要があります。Kinstaでは、その仕組みづくりに必要なツールも提供しています。

これらのツールを組み合わせることで、MyKinstaでのサイト管理をさらに効率化できます。ポイントは、ゼロから環境を作り直すのではなく、すでに運用しているアカウントを整理し、管理しやすい状態に整えることです。そのため、既存のサイトをそのまま活かしながら、段階的に管理体制を整えていくことができます。

サイトが並んでいるだけでは、整理された管理体制とは言えない

MyKinstaアカウント内のサイトには、インストール時に設定されたスラッグがそのまま名前として使われていることも多く、似たようなサイト名が一覧に並びがちです。さらに、複数の社員が企業レベルの権限を持ち、それぞれ複数のクライアントサイトを管理している場合、どのサイトがどのクライアントのものなのか一目では判断しづらくなります。その結果、クライアントから問い合わせがあるたびに、該当するサイトを探して必要な情報を確認する手間が生じます。

これは、サイトの管理方法に問題があるというより、整理するための仕組みが確立されていないことが原因です。少数精鋭で数件のサイトを管理する程度であれば、各サイトの情報を特定の担当者が把握しているだけでも対応できるかもしれませんが、管理するサイトが増えてくると、個人の記憶に頼るやり方では次第に対応しきれなくなります。

Kinstaのお客様である株式会社マネーフォワード様も、Kinstaへの移行前に同様の課題を抱えていました。同社では、複数の部署、ドメイン、サーバー環境にまたがる約30のサイトを管理しており、サイト管理が業務の一工程ではなく、それ自体が大きな業務になっていました。

MyKinstaで複数のWordPressサイトを整理する方法

このような状況では、MyKinstaの既存のツールを活用することができます。具体的には、以下5つのツールが役立ちます。

• 命名ルール：他のツールでも共通して識別できる、一貫した名前を各サイトに付ける
• ラベル：サイトが並ぶだけの一覧を整理し、ワンクリックで必要なサイトだけを絞り込めるようにする
• ユーザー権限：誰がどのサイトを操作できるかを設定し、クライアントごとのアクセスを分離する
• 一括操作とアクティビティログ：複数のサイトにまとめて変更を適用し、その履歴を記録する
• Kinsta API：管理サイトが増え、MyKinstaのフィルターだけでは対応しきれなくなった段階で、管理を自動化・効率化

複数サイトの管理における基本的なポイントを押さえながら、これらのツールを一つずつ活用して、自社の運用に合った管理体制を構築していくことが鍵になります。

まずはすべてのサイトで命名ルールを統一する

最初に始めたいのは、サイト名の統一です。検索、フィルタリング、一括選択、さらにAPIのsite_display_nameフィールドはいずれもサイト名を基準に機能するため、命名ルールが統一されていないと、その上に構築する管理の仕組みも十分に活かせません。

MyKinstaの表示名は本番サイトのドメインとは別に設定されているため、稼働中のサイトでも安全に名前を変更できます。また、SSH/SFTPのユーザー名、MySQLデータベースの認証情報、サイトの公開サーバーフォルダのパスにも影響はありません。

そのため、デプロイスクリプトを再設定することなくサイト名を変更可能です。MyKinstaの「サイト」画面に移動し、対象サイトの横にある3点のアイコンをクリックして、「サイト名の変更」を選択してください。また、「サイト」＞（サイト名）＞「情報」から変更することもできます。

この操作は、企業の所有者、企業の管理者、企業の開発者、サイトの管理者の各権限を持つユーザーが実行できます。

サイト名には、チームの誰が見てもすぐに識別できる、シンプルで一貫した命名ルールを設けましょう。たとえば、クライアント名やサイトの用途など、識別に役立つ情報を一定の形式でサイト名に含めます。命名ルールを統一することで、管理するサイトが増えても目的のサイトを見つけやすくなり、検索や一括操作もスムーズに行えます。

ラベルを体系化してサイトの分類と絞り込みを行う

Kinstaのサイトラベル機能は以前から提供されていますが、その都度思いついたラベルを付けるのではなく、あらかじめルールを決めて体系的に運用することで、より効率的にサイトを管理できます。

• 「サイト」画面で、ラベルを付けるサイトを選択する
• 「操作」ドロップダウンから「ラベルの変更」を選択する
• 表示されたダイアログで既存のラベルを選択するか、「新規ラベルの追加」をクリックして新しいラベル名を追加・選択する
• 「ラベルを適用する」をクリックして、ラベルを適用

ラベル自体は、「企業の設定」＞「サイトラベル」で管理することができます。サイトにラベルを設定すると、「サイト」画面のラベルフィルターを使って、特定のラベルが付いたサイトだけを表示できるようになります。

ただし、MyKinstaで一度に絞り込みに使用できるラベルは1つだけです。たとえば、woocommerce（種類）または運用中（ステータス）のラベルが付いたサイトをそれぞれ表示することはできますが、この2つの条件を組み合わせて絞り込むことはできません（Kinsta APIを使用すれば可能）。

クライアントとサイトの種類をラベルで分類する

クライアント名とサイトの種類をそれぞれラベルで分類するのがおすすめです。

• クライアント名：クライアント名をラベルに設定しておけば、そのクライアントに属するすべてのサイトを簡単に絞り込める
• サイトの種類または用途：WooCommerce、会員制、メンテナンスなどのラベルを付けることで、サイトの特徴を一目で把握できる

クライアント名とサイトの種類の両方をラベルに設定しておくことで、必要なサイトを見つけやすくなります。

必要に応じてサイトの運用状況も

クライアント名とサイトの種類に加えて、サイトの運用状況もラベルで管理すると便利です。制作会社での一般的な運用であれば、次の4つのステータスでほとんどのケースに対応できます。

• 開発中：まだ公開されていない開発中のサイトに使用。このラベルで絞り込むことで、通常のメンテナンス対象から除外できる
• 運用中：公開済みで、通常の保守・運用を行っているサイトに使用。アップデートやキャッシュクリアなど、日常的なメンテナンスの対象となるサイト
• 運用終了：契約終了などに伴い、運用終了に向けた対応を進めているサイトに使用。引き継ぎや必要な終了作業を行う際の目印に
• アーカイブ：現在は運用しておらず、参照用として残しているサイトに使用。必要になるまでは、アップデートやレポート作成などの対象から除外できる

このラベルは、クライアント名やサイトの種類を示すラベルとあわせて活用すると便利です。たとえば、WooCommerceサイトのリリース作業を行う場合、WooCommerceラベルで対象サイトを確認し、その中にアーカイブのサイトがあればあらかじめ作業対象から外すことで、現在保守していないサイトを誤って更新するのを防げます。

同様に、開発中のラベルが付いたサイトは通常のメンテナンス対象から除外し、運用終了のラベルが付いたサイトは、引き継ぎや契約終了に伴う作業が必要なサイトとして把握できます。ラベルの変更はアクティビティログに記録されるため、各サイトの運用状況がどのように変化してきたかを後から確認することもできます。

こうしたラベルをサイト管理に役立てるには、チーム内で表記や使い方を統一することが重要です。以下のようなルールを決めて社内で共有しておきましょう。

• ラベルの表記を統一する：「運用中」と「稼働中」のように、同じ意味のラベルが複数作成されないようにする
• ラベルの用途を明確にする：クライアント名、サイトの種類、運用状況など、何を分類するためのラベルなのかを決めておく
• 使用するラベルをあらかじめ決めておく：必要に応じて自由にラベルを増やすのではなく、社内で決めたラベルを使用する

こうしたルールを設けておけば、サイトや担当者が増えてもラベルが乱立せず、必要なサイトをスムーズに絞り込めます。

ユーザー権限でアクセス範囲を管理・分離する

ユーザー権限は主にセキュリティを管理するためのものですが、多数のサイトを扱うアカウントでは、サイトを整理して運用するうえでも役立ちます。ユーザーごとに必要な範囲のアクセス権限を付与することで、それぞれが担当業務に必要なサイトや機能だけにアクセスできる環境を整えられます。

MyKinstaでは、ユーザー権限を企業単位とサイト単位に分けることで、このようなアクセス管理が可能になります。

• 企業の所有者：各企業につき1名のみ付与でき、企業の管理者の権限も持つ。唯一アカウントの閉鎖申請や所有権の譲渡を行えるため、制作会社の責任者に適した役割。
• 企業の管理者：移行を含む、企業およびすべてのサイトのデータを管理でき、プランの変更も行えるため、運用責任者や技術責任者などに適している。
• 企業の開発者：すべてのサイト、DNS、サイト単位のユーザーを管理でき、企業のユーザー一覧を閲覧できる（編集は不可）。また、「企業の設定」でAPIキー、ラベル、ユーザーアクティビティなども管理可能。請求やサイト移行に関する操作は行えない。すべてのクライアントサイトを扱う必要はあるものの、契約や請求に関する権限は不要な開発者に適した役割。
• 企業の経理係：請求情報に加え、請求書や企業の住所など、請求に関連する企業設定のみを確認できる。サイトを操作する必要のない経理担当者に適した役割。

企業単位でユーザーに役割を付与する場合は、「企業の設定」＞「ユーザー管理」から、ユーザーを招待してください。

サイト単位の権限を与えるには、「サイト」＞（サイト名）＞「ユーザー管理」から、ユーザーを招待してください。

• サイトの管理者：割り当てられたサイトのすべての環境を管理でき、ステージング環境から本番環境への反映も行える。また、サイトがDNSゾーンに紐づいている場合は、DNSも管理可能。企業アカウントからのサイト削除、サイト移行、プレミアムステージング環境の作成・削除は行えない。
• サイトの開発者：サイトのステージング環境のみにアクセス可能。ステージング環境の削除と本番環境への反映を除き、ステージング環境内の各種操作を行えます。

これらの権限は、MyKinstaに社員を招待する際に、アクセスを許可するサイトと役割を指定して設定します。いずれの役割を割り当てても、対象のサイト以外は表示されないため、各ユーザーのアクセス範囲を担当サイトのみに限定することができます。

WordPress管理画面への自動ログインでオンボーディングを効率化

サイト単位の役割は、新規メンバーがWordPressを使い始める際にも役立ちます。Kinstaでは、すでにMyKinstaで付与されているアクセス権限を利用して、WordPress管理画面にワンクリックで自動ログインできます。

MyKinstaで対象サイトの「情報」画面を開き、「WordPress管理画面にログイン」をクリックします。MyKinstaアカウントと同じメールアドレスのWordPressユーザーが存在しない場合は、新規ユーザーを作成するよう求められます。

このシンプルな仕組みは、複数のサイトを管理する企業で特に役立ちます。

• サイトごとに設定可能：企業の所有者、企業の管理者、企業の開発者は、「ユーザー管理」画面からサイトごとに自動ログインを有効または無効にできる
• IDプロバイダとの連携：SAML SSOと組み合わせれば、Microsoft Entra ID、Google、Oktaを通じてアクセス権限を一元管理でき、メンバーの追加や削除を一箇所で行える
• スムーズな引き渡し：プロジェクトの終了時には、サイト譲渡ツールを使用して完成したサイトをクライアント自身のMyKinstaアカウントに移し、自社の管理対象から外すことができる

これらを活用することで、MyKinstaとWordPressのアクセス権限を一元的に管理できます。外部の開発者などをプロジェクトに加えたり、プロジェクト終了時にアクセス権限を削除したりする際にも、個別に認証情報を設定し直す必要がなく、スムーズに対応できます。

一括操作で効率よくサイトを管理する

ラベルによる分類は、サイトの情報が正しく整理されていてこそ役立ちます。一括操作を活用すれば、サイトを1つずつ操作することなく、複数のサイトや環境をまとめて管理できます。「サイト」画面で対象のサイトや環境を選択して「操作」ドロップダウンを選択すると、以下のような様々な操作を一括で実行できます。

• キャッシュのクリア：サーバー、CDN、エッジキャッシュをまとめてクリア
• プラグインとテーマの更新：更新可能なプラグインやテーマを選択してアップデート
• PHP設定の変更：PHPバージョンやPHPの自動更新などの設定を変更
• エッジキャッシュとCDN設定の変更：複数の環境で有効・無効をまとめて変更
• ボット対策の変更：ボット対策のレベルやAIクローラーに関する設定を変更
• CSV形式でエクスポート：前述のように、サイト情報をCSVに出力して整理や計画に活用

さらに、ラベルによる絞り込みと一括操作を組み合わせることで、日常的な管理作業を効率化できます。たとえば、WooCommerceのリリース後にWooCommerceラベルで対象サイトを絞り込み、まとめてキャッシュをクリアできます。また、クライアントとの契約が終了する際には、運用終了ラベルで対象サイトを絞り込み、バックアップを確認したうえでアクセス権限をまとめて削除できます。

担当者が変わっても運用できる仕組みを整える

サイトの管理方法が特定の担当者の知識や経験に依存していると、その担当者が異動・退職した際に運用が滞ってしまいます。誰が担当しても同じように管理できるよう、次のような仕組みを整えておきましょう。

• 管理責任者を決める：ラベルの管理やラベルの追加を承認する担当者を1名決める。通常は、企業の管理者権限を持つ運用責任者などが適任。これにより、似たようなラベルが無秩序に増えるのを防ぐ。
• ルールを文書化する：サイトの命名ルール、使用するラベルとその用途、担当者ごとに付与する権限などを簡潔にまとめておく。新メンバーが加わった際にも、すぐに既存のルールに沿って作業を始められる。
• 新規サイト作成時の手順に組み込む：サイト名の設定、ラベルの付与、ユーザー権限の設定を、新規サイト作成時のチェックリストに含める。最初から必要な設定を済ませておくことで、後から整理する手間を省ける。

さらに、アクティビティログを利用すれば、過去6か月間の操作履歴を確認できます。企業全体の履歴は「企業の設定」＞「ユーザーの活動」、サイトごとの履歴は「サイト」＞（サイト名）＞「ユーザーの活動」画面から確認できます。

たとえば、クライアントとの契約終了時にバックアップが実行されたか、アクセス権限が削除されたかを履歴から確認できます。また、問題が発生した際には、社員やクライアントによる操作、あるいはMyKinsta上の操作のどれが原因だったのかを特定する手がかりにもなります。

さらに大規模なサイト管理にはKinsta APIを利用

多くの制作会社は、MyKinstaの機能だけで十分にサイトを管理できますが、管理するサイトが増えてくると、Kinsta APIを活用することで、MyKinstaだけでは難しい操作や自動化も可能になります。たとえば、MyKinstaでは複数のラベルを組み合わせた絞り込みはできませんが、APIを使えばより柔軟にサイトを抽出できます。

• アカウント全体のプラグインと脆弱性の確認：専用のエンドポイントを使用すると、アカウント内のすべてのプラグインについて、最新バージョン、脆弱性の有無、使用されている環境などをまとめて取得できる。MyKinstaでは標準で行えない、アカウントを横断した確認が可能。
• 使用量の確認：使用量に関するエンドポイントでは、サイトごとに当月の訪問数や帯域幅を取得できる。プランの上限に近づいているクライアントを事前に把握し、超過が発生する前に対応可能。
• 定期的な操作や一括操作：キャッシュのクリアを夜間に実行したり、WooCommerceやYoastをあらかじめインストールした状態でサイトを作成したりできる。また、ログを取得して自社の監査ツールで活用することも。

処理に時間のかかる操作ではオペレーションIDが返され、このIDを使用して処理の完了状況を確認できます。また、APIリクエストは企業ごとに1分あたり120件までに制限されています。

Kinstaのお客様であるSod（Straight Out Digital）は、Kinsta APIを活用して社内ツールを構築し、数百のサイトのプロビジョニングやメンテナンスを自動化しています。APIを活用するために必ずしも高度な開発技術が必要というわけではなく、スプレッドシートを使った管理から始めることもできます。

MyKinstaでサイト管理を効率化