ステージング環境
弊社では、各WordPressサイトに対して、本番サイトとは完全に分離されたWordPressステージング環境を無料で作成することができます。WordPressのバージョン、プラグイン、コード、その他一般的な開発作業をテストするのに有用で、数分で開発環境を作成し、他の人と共有可能です。
ステージング環境のさらなる追加、本番環境に近いステージング環境の利用、またはリソース集約型のサイトにおけるテストや開発をお求めであれば、プレミアムステージング環境アドオンをご利用ください。
標準およびプレミアムステージング環境の比較
プレミアムステージング環境は最大5つまで作成可能で、無料で使用できる標準ステージング環境よりも多くのリソースと機能が搭載されています。標準およびプレミアムステージング環境の違いは以下のとおりです。
| プレミアム | 標準 | |
| PHPスレッド | 本番環境と同数 | 2 |
| PHPメモリ上限 | 本番環境と同量 | 本番環境と同数 |
| スレッドあたりのPHPメモリ | 本番環境と同量 | 最大スレッド数は2、スレッドあたりのPHPメモリは本番環境と同量になります。例えば、本番環境のメモリプールが 2GBでPHPスレッドが4つある場合、各スレッドのメモリ制限は512MBとなります。標準ステージング環境では、PHPスレッド数は2つ、それぞれのメモリ上限は512MBとなります。なお、この例はPHPパフォーマンスアドオンが利用可能なプランにのみ適用されます。 |
| CPU | 12 | 1 |
| RAM | 8 GB | 8 GB |
| CDN | ◯ | ✕ |
| エッジキャッシュ | ◯ | ✕ |
プレミアムステージング環境アドオンの詳細はこちらをご覧ください。
WordPress標準またはプレミアムステージング環境を作成する
WordPressステージング環境の作成は簡単です。MyKinstaにログイン後、左サイドバーから「WordPressサイト」を開くと、WordPressサイト一覧が表示されます。ステージング環境を作成したいサイトを一覧から選択するか、画面上部の「ジャンプまたは検索…」バーで検索して、「新規環境の作成」をクリックします。
表示される「新規環境の作成」ポップアップで「プレミアム環境」または「標準環境」を選択して、「続行」をクリックします。
作成する環境の種類を選択するプロンプトが表示されます。ステージング環境を作成する方法は以下の3つから選択できます。
- 既存の環境を複製：既存の環境（本番またはプレミアムステージング環境）を新しい標準ステージング環境に複製することができます。
- 新たにWordPressをインストール：空の（コンテンツのない状態の）WordPressをインストールし、WordPressサイトがすぐに使用できるようになります。
- 空の環境（WordPress無し）：WordPressサイトの実行に必要なすべてのソフトウェア（ウェブサーバー、PHP、MySQLなど）をインストールしますが、WordPressコアはインストールされません。Duplicatorを使って弊社にサイトを移行したり、特別なファイル構造でBedrock/Trellisを利用したりするのに便利です。
方法1. 既存の環境を複製
「既存の環境を複製」を選択すると、任意の既存環境（本番環境またはプレミアムステージング環境）を新しい標準ステージング環境として複製することができます。
- 環境名：3文字以上12文字以内で任意の名前を設定します。
- 複製対象の環境：ステージング環境に複製する既存の環境を選択します。
方法2. 新たにWordPressをインストール
「新たにWordPressをインストール」を選択すると、サイトの細かな設定を行うことができます。各フィールドの役割は以下の通りです。
- 環境名：3文字以上12文字以内で任意の名前を設定します。
- WordPressサイトタイトル：WordPressサイトの表示名を設定します。使用しているテーマによっては、ブラウザのタブなどで訪問者に表示されることがあります。サイトタイトルは後ほどWordPress管理画面で変更可能です。
- WordPressサイト管理者のユーザー名：WordPressの管理者ユーザー名を設定します。環境作成後、必要に応じて複数のWordPressユーザーを追加可能です。最大限のセキュリティを確保するため、ユーザー名には「admin」以外を使用することが推奨されます。
- WordPressサイト管理者のパスワード：WordPressの管理者パスワードを設定します。セキュリティ上の理由から、強力なパスワードが自動的に適用されます。パスワードを変更するには、「新しいパスワードを生成」（再読み込みアイコン）をクリックしてください。WordPressで後からパスワードを変更する方法はこちらをご覧ください。
- WordPressサイト管理者のメールアドレス：WordPressから重要な通知を受け取るための管理者用メールアドレスを設定します。
- WordPressサイトをマルチサイト化する：WordPressマルチサイトを作成する場合は、このボックスにチェックを入れてください。「サブドメイン」または「サブディレクトリ」のいずれかを選択することができます。
- WooCommerceをインストールする：人気の高いECプラグインWooCommerceを使ってECサイトを作成することができます。このボックスにチェックを入れると、自動でインストールされます。
- Yoast SEOをインストールする：Yoast SEOは、WordPressの数あるSEOプラグインの中でも人気の選択肢です。300万以上のインストール、高評価（5/5）を誇ります。このボックスにチェックを入れると、自動でインストールされます。
- Easy Digital Downloadsをインストールする：デジタル製品に特化したECサイトの構築に便利なEasy Digital Downloadsをインストールすることができます。このボックスにチェックを入れると、自動でインストールされます。
方法3. 空の環境（WordPress無し）
「空の環境（WordPress無し）」は、Duplicatorを利用したサイト移行やBedrock/Trellisを用いたサイト構築に便利な選択肢です。
- 環境名：3文字以上12文字以内で任意の名前を設定します。
ステージング環境の作成
上記いずれかの方法で設定を終えたら、「続行」をクリックします。プレミアムステージング環境を作成する場合は、月額料金とお支払い方法の詳細が表示されます。同意の上、「プレミアム環境の作成」をクリックしてください。
ステージング環境にアクセスする
ステージング環境が生成されるまでお待ちください。表示されるまでに数分かかる可能性があります。環境が完成したら、画面上部の環境の種類（「Live」や「Staging」）をクリックして、ドロップダウンから環境を選択します。または、上部右側にある虫眼鏡のアイコンからも環境の選択が可能です。
または、「WordPressサイト」画面のサイト一覧から選択することも可能です。
各環境の名前の横には丸印が表示されます。環境ごとに色分けされており、本番環境（Live）は緑、標準ステージング環境（Standard Staging）は黒、プレミアムステージング環境（Premium Staging）はオレンジです。また、ステージング環境用の接続情報、DNS、バックアップ、ツール、プラグインといった情報も表示されます。
ステージングサイトにアクセスするには、ステージング環境の「ドメイン」タブで、「URLを開く」をクリックします。また、「WordPressの管理画面を開く」をクリックすると、ステージングサイトのWordPress管理画面が開きます。
URL構造とドメイン
標準ステージング環境のデフォルトのURL構造は、以下のようになっています。
- 標準環境：https://stg-sitename-environmentname.kinsta.cloud
- プレミアム環境：https://env-sitename-environmentname.kinsta.cloud
古いステージングサイトをお持ちの場合、URLは以下のようになることがあります。
- https://staging-sitename-environmentname.kinsta.cloud
- https://staging-sitename.kinsta.cloud
- https://staging-sitename.kinsta.com
また、ステージングサイトに独自ドメインを追加することも可能です。
注意事項
本番サイトでSSLを有効にし、ステージング環境にそのサイトを複製すると、ステージング環境でもSSLが有効になります。
MyKinstaからphpMyAdminを起動できます。「情報」タブで「phpMyAdminを開く」をクリックします。phpMyAdminのステージング環境用URLは、以下のようになります。
https://mysqleditor-stg-sitename-environmentname.kinsta.cloud
ステージング環境を更新する
ステージング環境の作成後に本番サイトに変更を加え、その変更をステージング環境に反映したい場合は、選択的プッシュ機能を使用することができます。これにより、ステージング環境を削除して再度作成する手間がなくなり、作業が効率化され、ステージング環境のバックアップも保持できます。
本番サイトに環境を反映する
ステージング環境の準備が整ったら、本番環境に反映します。この詳細はこちらをご覧ください。任意の本番環境またはステージング環境を他のサイトに反映することも可能です。
ステージング環境を削除または更新する
ステージングサイトを削除するには、「WordPressサイト」＞（サイト名）に移動し、ステージング環境に切り替えます。ページの一番下までスクロールし、「環境の削除」ボタンをクリックします。
表示されるポップアップで、削除の対象をしっかりと確認した上で、サイト名の後にダッシュ（-）と「staging」という単語を加えた文字列（「サイト名-環境名」）を入力し、「環境の削除」ボタンをクリックすると削除が実行されます。
ステージング環境を最新のものに更新するには、それを一度削除した上で、新規環境を作成し、「方法1. 既存の環境を複製」を選択します。このようにしてステージング環境を作成すると、本番環境にある最新のデータベースとファイルが反映されます。
または、本番サイトのバックアップをステージング環境に復元することも可能です。この方法では、独自ドメインを追加していても削除されないため、ステージング環境を更新するたびに追加する必要はありません。
WordPressのバックアップをステージング環境に復元する
WordPressサイトのバックアップデータを既存のステージング環境に直接復元することもできます。WordPressのバックアップをステージング環境に復元する方法をご覧ください。※本番環境のバックアップをステージング環境に復元すると、すべてのステージング環境バックアップデータが存続します。
ステージング環境を再起動する
特定の状況において、サーバーのトラブルシューティングの一環として、ステージング環境が停止されることがあります。サイトへのアクセス時に「501 not implemented」「502エラー」または「521エラー」が表示された場合には、MyKinstaでサイトの「情報」画面移動して「（環境名）環境を開始する」をクリックし再開することができます。
ステージング環境を再開できない場合、またはMyKinstaにボタンが表示されない場合には、チャットにてカスタマーサポートまでご連絡ください。
プレミアムステージング環境を削除する
テストまたは開発が完了したら、プレミアムステージング環境を削除することができます。プレミアムステージング環境アドオンを使用している場合、アドオンの友好時のみご利用料金が発生します。プレミアムステージング環境を削除すると、アドオンも自動的に停止し、課金されることがなくなります。
WordPress専用サーバープランのご利用開始から、30日以内にプレミアムステージング環境アドオンを削除した場合、日割り計算で料金が算出され、翌月のお支払い額に加算されます。WordPress専用サーバープランのご利用開始から30日以上経過している場合は、現在の請求サイクルの残りの日数分の料金がアカウント残高にクレジットとして加算されます。このクレジットは、次回のお支払い料金と相殺されます。詳細については、WordPress専用サーバーの返金保証をご覧ください。
MyKinstaで、「WordPressサイト」画面開き、削除したい環境を選択します。
ページの一番下までスクロールし、「環境の削除」をクリックします。
表示されるポップアップで、削除の対象をしっかりと確認した上で、サイト名の後にダッシュ（-）と「staging」という単語を加えた文字列（「サイト名-環境名」）を入力し、「環境の削除」ボタンをクリックすると削除が実行されます。
プレミアムステージング環境が削除されると、MyKinstaの「企業の設定」＞「ご利用プラン」からアドオンの購読契約が自動的に削除されます。
注意事項
ステージング環境をお使いいただく上で、いくつか重要な注意事項があります。
1. ステージング環境のページキャッシュ設定
ステージング環境は開発、デバッグ、テスト用に存在するため、弊社のフルページキャッシュとOPcacheはデフォルトで無効になっています。ウェブサイトのスピードテストを実行すると、ページがキャッシュから配信されないため、平均よりも表示時間が長くなることが予想されます。ステージング環境でキャッシュを有効にするには、サイトのステージング環境の「ツール」画面で「キャッシュを有効にする」ボタンをクリックしてください。ステージング環境でキャッシュを有効にすると、「キャッシュをクリア」ボタンが表示されるようになり、キャッシュのクリアの際に利用できます。プレミアムステージング環境の場合は、CDNとエッジキャッシュも利用可能です。
2. ステージング環境のログイン情報
ステージング環境が本番サイトの複製である場合、ステージング環境を作成した後に変更しない限り、WordPressの管理者ログイン認証情報は本番環境とステージング環境の両方で同じになります。
3. SEO
デフォルトでは、ステージングサイトのインデックス登録はオフになり、本番サイトのSEOに影響を与えません。これは、WordPressの設定と、弊社の仕様により自動で追加されるHTTPヘッダーを組み合わせることで実現しています。
WordPressの設定は、ステージングサイトのWordPress管理画面で「設定」＞「表示設定」を開いて確認することができます。「検索エンジンでの表示」の横にある「検索エンジンがサイトをインデックスしないようにする」にチェックが入っているはずです。
弊社の一時URL（ステージングURLを含む）には、ボットのアクセスを制限するX-Robots-Tag: noindex, nofollow, nosnippet, noarchive HTTPヘッダーがあり、一時URLが検索エンジンによってインデックスされないことを意味します。このヘッダーは、一時URLまたはステージングURLから削除することはできません。削除が必要な場合は、独自ドメインを追加する必要があります。
4. プラグイン
CoScheduleやSocial Networks Auto Posterなどのソーシャルスケジューリングプラグイン（SNS投稿を自動化するもの）を使用している場合、ステージング環境では無効化することをお勧めします。有効にすると、ステージングURL（例：https://stg-sitename-environmentname.kinsta.cloud）からSNSへコンテンツが投稿され、分析データに歪みが出てしまう可能性があります。
Jetpackなどの特定のプラグインは、弊社のステージング環境を検知し、自動でステージングモードになり「あなたはステージングサーバー上でJetpackを実行しています/You are running Jetpack on a staging server.」というメッセージが表示されます。ステージングモードでは、WordPress.comにデータが渡されず、ステージングサイトを切断できない（本番サイトにつながる問題を防ぐため）ことを除いて、実質的にすべてが本番サイトと同じように動作します。
ドメインに紐付けるかたちでライセンスを獲得したプラグインについては、（弊社のステージングサブドメインではなく）独自ドメインの使用が必要になる場合があります。※ステージングサイトに独自ドメインを追加した後、プラグインライセンスの設定調整やプラグインのカスタマーサポートへの連絡が必要になる場合があります。
5. ログインURLのメモ
ステージング環境にサイトを複製し、デフォルトのログインURLを変更するWordPressプラグインを使用すると、URL中の変更を加えられた部分がステージング環境にコピーされます。例：http://staging-sitename-environmentname.kinsta.cloud/変更した部分
6. 開発およびテストに限定した使用
標準ステージング環境のPHPスレッド数は2つに限定されます。また、Kinsta CDNを有効にすることはできず、24時間使用されないと環境そのものがスリープ状態になることがあります。このような性質から、ステージング環境は開発およびテストにのみご利用ください。ステージング環境では（標準とプレミアムいずれも）本番としての使用は一切想定されていません。ステージング環境を本番サイトにご使用された場合、それに起因するいかなる問題についても弊社は責任を負い兼ねますので、あらかじめご了承ください。
7. プラン合計からのディスク容量の除外
できるだけ多くの容量をご利用いただけるよう、ステージングサイトは、お客様のプランにおけるディスク容量使用状況の計算時には一切加味されません。本番サイトのみがディスク容量のご使用分として考慮されます。
8. cronジョブ
本番環境のサーバーcronジョブはステージング環境では有効にならず（本番サイトをステージング環境に複製した場合でも）、本番サイトのcronジョブはステージング環境では実行されません。ただし、ステージング環境のcrontabを編集した上でステージング環境を本番環境に反映すると、本番環境のcrontabが上書きされます。
9. マルチサイト
WordPressのマルチサイトを運用している場合、マルチサイトの設定によってステージング環境と連動する場合としない場合があります。
- サブディレクトリを使用したマルチサイト（example.com, example.com/subsite1, example.com/subsite2）、またはサブドメインを使用したマルチサイト（example.com, subsite1.example.com, subsite2.example.com）は、弊社のステージング環境で問題なく動作し、すべてのサブドメインに弊社の無料SSL証明書が適用されます。
- ドメインマッピングを使用したマルチサイト（example.com, example1.com, example2.comなど、完全に別のドメインのサブサイトを読み込む構成）は、細かな設定の調整が必要になります。
- 方法1─ドメインマッピングをオフにして、標準的なサブディレクトリ/サブドメインの設定に戻す（手作業でデータベースの検索と置換を実行）。
- 方法2─本番ドメインごとにステージングサブドメインを設定し、それらをすべてステージングサイトに追加する（手動でデータベースの検索と置換を実行）。
10. メール
ステージング環境では、デフォルトでメール送信（トランザクションメール）機能が有効になります。ステージングサイトで発生した注文に対し、ステージングサイトから関連するメールが送信される仕様です。ステージング環境からのトランザクションメール送信を希望しない場合は、Disable Emailsなどのプラグインを使用して、サイトからのメール送信を停止することができます。
よくあるご質問
時間割計算の料金システムについて教えてください。
プレミアムステージング環境アドオンのようなサービスの時間割計算とは、その月の請求サイクルで、プレミアムステージング環境が使用された時間に基づいて費用が計算されることを意味します。
時間割計算の例1
サイトに新たな機能を導入するため、利用しているプランをフル活用して導入テストを行いたい。プレミアムステージング環境を作成し、新機能を追加して、1時間テストを行うことに。問題なく導入ができたため、変更を本番環境に反映して、プレミアムステージング環境を削除した。
- プレミアムステージング環境の利用料金は、20ドル／月です。
- 30日の月の場合、請求サイクルを時間に換算すると合計720時間です。
30日 × 24時間 = 720時間 - つまり、1時間あたりの利用料金は0.03ドルとなります。
20ドル ÷ 720 = 0.03ドル - したがって、次回のご請求には、プレミアムステージング環境1時間分の利用料0.03ドルが加算されます。
時間割計算の例2
毎月の請求サイクルの途中でプレミアムステージング環境を購入し、請求サイクル終了日まで使用する場合には、半月分の使用料が請求されます（日割り計算で約10ドル）。
プレミアムステージング環境の名前は変更できますか？
変更可能です。変更したいステージング環境に切り替えて、「情報」画面の「環境名」フィールドにある鉛筆のアイコン（編集）をクリックしてください。
変更後の名前を入力したら、「環境名の変更」ボタンをクリックします。
この方法で環境セレクタのドロップダウンに表示される環境名は変更されますが、環境作成時に生成された「kinsta.cloud」ドメインは影響を受けません。
ステージング環境にバックアップを復元できますか？
復元可能です。しかし、まずは標準またはプレミアムステージング環境の作成をお願いします。従来は、バックアップを復元する際に自動的にステージング環境を作成することができましたが、プレミアムステージング環境の導入により、現在は、バックアップを復元前にステージング環境の作成が必要になります。
また、本番環境の変更をステージング環境に反映することもできます。特定のファイルやデータベーステーブルだけを更新するには、選択的プッシュ機能を使用します。
プレミアムステージング環境にアクセスできるユーザーは誰ですか？
「サイトの開発者」と「サイトの管理者」は、作成済みのプレミアムステージング環境にアクセスすることができますが、新規作成または削除は行えません。「企業所有者」と「企業の管理者」のみ、プレミアムステージング環境の新規作成と削除が行えます。
ステージング環境はプランのディスク容量を消費しますか？
消費することはありません。できるだけ多くの容量をご利用いただけるように、ステージングサイトは、お客様のプランにおけるディスク容量使用状況の計算時には一切加味されません。本番サイトのみがディスク容量のご使用分として考慮されます。
ステージング環境でプラグインをテストし、ファイルのみを本番環境に反映した場合、プラグインに対応するデータベーステーブルは生成されますか？
本番環境にインストールしたことのないプラグインをステージング環境にインストールした場合、本番環境にファイルだけを反映しても、そのプラグインのデータベーステーブルは生成されません。
これは、プラグインでのいかなる設定も本番環境に反映されないことを意味します（設定が、JSONファイルのようなデータベース外のファイルに保存されている場合を除く）。
実際のプラグインがどのように構築されているかにもよりますが、本番サイトでプラグインを有効化する（必要に応じ、無効化した上で実行）と、データベース構造が作成されることがあります。
ファイルだけを本番環境に反映する場合、（ステージングにある）古いデータベースは本番環境のものを上書きしてしまうことはありませんか？
ファイルのみを反映する場合、データベースが上書きされることはありません。本番環境上のファイルのみが上書きされます。
ステージング環境でサイトのデザイン変更を行い、本番環境に反映しても、本番環境の新規加入者や顧客を失うことはありませんか？
変更がファイルに対してのみ行われる限り（プラグイン、テーマ、カスタマイザーの設定を含め、WordPress管理画面での変更がない場合）、データベースに影響を与えることなく、安全に反映できます。変更を本番環境に反映する際には、「ファイル」を選択し、「データベース」が選択されていないことをご確認ください。
ステージング環境から本番環境への反映時に、WooCommerceの注文やデータを除外したり同期させたりすることはできますか？
可能です。選択的プッシュ機能でステージング環境を本番環境に反映する場合、データベースが上書きされないようにファイルのみを反映することも、データベーステーブルを選択して特定のWooCommerceテーブルを除外することもできます。WooCommerceの各データベーステーブルに含まれているものに関してはこちらをご覧ください。反映すべきテーブルがわからない場合は、開発者に相談することをお勧めします。
マルチサイトを運営している場合、ステージング環境から本番環境に1つのサイトだけを反映できますか？
可能です。選択的プッシュ機能でステージング環境を本番環境に反映する際、サブサイトの1つのデータベーステーブルのみを選択してください。WordPressに含まれるデータベーステーブルの詳細はこちらをご覧ください。ファイルでは、pluginsとthemesフォルダはすべてのサイトで共有されますが、uploadsフォルダはサイトごとに分けることができるため、必要なサブサイトのアップロードだけを反映するように選択できます。反映すべきテーブルやファイルが不明な場合は、開発者に相談することをお勧めします。
サイトのPHPバージョンを変更するために選択的プッシュ機能を使用できますか？
使用可能です。PHPの新しいバージョンをテストするためにステージング環境を使用することはできますが、本番環境にその変更を加える準備を行なった後は、本番環境でその操作を行う必要があります。つまり、ステージング環境から本番環境への反映作業は不要です。以下の手順に従ってください。
- ステージング環境を作成します。
- ステージング環境を作成し、ステージング環境のPHPバージョンを変更します。
- ステージング環境で問題なく動作することを確認した上で（サイトのテストは十分に行なってください）、本番環境でPHPバージョンを変更します。
WordPress管理画面でCSSを変更し、ファイルを反映しました。キャッシュをすべてクリアしても変更が表示されないのはなぜですか？
変更の種類とその情報が保存されている場所によって、データベースを反映するか本番サイト上でその変更をあらためて実施する必要があります。例えば、WordPress管理画面のブロックやウィジェットでCSSを追加または編集した場合、おそらくデータベースに保存されます。
WordPress管理画面で何かを変更した場合、「テーマの編集」（「外観」＞「テーマの編集」）で行った変更を除いて、その情報は通常データベースに保存されます。
※ステージングサイトの作成以降、本番サイトのデータベースに対する変更は、コメント、新しいコンテンツ、ECサイトでの購入、会員制サイトでのサインアップ、フォーラムの投稿などを含むすべてが失われることになります。そのような場合には、データベースを本番サイトに反映するのではなく、本番サイト上で同じ変更を手動で行うことをお勧めします。
選択的プッシュ機能はマルチサイトでも使用できますか？
使用可能です。ファイルのみを選択すれば、マルチサイトの種類に関係なく、本番サイトに反映することができます。データベースのみ、またはデータベースとファイルの両方を選択する場合は、マルチサイトの設定によってはうまくいかない場合があります。
- サブディレクトリのマルチサイト（example.com, example.com/subsite1, example.com/subsite2）であれば、問題なく反映されます。
- サブドメインのマルチサイト（example.com, subsite1.example.com, subsite2.example.com）であれば、サブサイトがHTTPSを必要としない限り、問題なく反映されます。
- ドメインマッピングを利用したマルチサイト（example.com, example1.com, example2.comなどの、まったく異なるドメインに別のサブサイトを持っているもの）の場合、多くの手動での設定が必要になります。
- 方法1─ドメインマッピングをオフにして、標準のサブディレクトリ／サブドメインの設定に戻ります。データベース内の検索と置換を手動で行います。
- 方法2─本番ドメインごとにステージングサブドメインを設定し、すべてをステージングサイトに追加します。ステージング環境を本番環境に反映した後、手動でデータベース内の検索と置換を行い、各ドメインを更新します。