WordPressのReprintとは？検証用コピーとDB・外部連携の注意点
公開日：更新日：
WordPressの更新やデザイン変更を、いま公開しているサイトの内容で試したい。そのために必要なのが、別の場所で動かせる検証用コピーです。
WordPress公式は2026年11月13日、サイトのファイルとデータベースを複製する無料のオープンソースツール「Reprint」を紹介しました。プラグインやテーマの変更を試すローカル環境、サーバー移転の準備などが用途として挙げられています。 WordPress公式の紹介（外部サイト）
Reprintでデータをコピーできても、メール・決済・定期処理が検証用に切り替わるとは限りません。 また、DBを再取り込みすると、コピー先で変更した内容が元サイトのデータに置き換わり得ます。
この記事では、単一サイトのWordPressを検証用に複製する場合を中心に、事前の準備、起動前の接続確認、再取り込み、複製後の動作確認を説明します。公式資料に基づく解説であり、特定の会社サイトを複製した実施報告ではありません。
Reprintは何をコピーするツール？
Reprintは、元サイトに入れたプラグインと、受け取り側で動かすクライアントを組み合わせて使います。クライアントとは、ターミナルで命令を入力して動かすプログラムです。認証したクライアントがHTTPS経由でファイルとDBを受け取る仕組みで、元サーバーへのSSHログインは必要ありません。 Reprintの仕組み（外部サイト）
DBは投稿、ユーザー、設定などを保存する場所です。サイトを別環境で動かすには、画像やテーマのファイルだけでなく、こうしたデータと、受け取り側の実行環境も必要になります。
- 元サイトファイルとデータベース
- Reprint認証して転送
- 検証用コピー表示・機能を確認
模式図。メール・決済・定期処理などの外部接続は、別に点検します。
Reprintはデータを分割して転送するため、元サーバーにサイト全体の巨大な圧縮ファイルを先に作る方式ではありません。受け取り側には、ファイル・DBと作業に必要な容量を用意します。すべてのファイルを無条件に保存するわけではなく、既知のバックアップアーカイブ、キャッシュ、ログなどは除外されます。 転送するファイルと除外対象（外部サイト）
バックアップと検証用コピーは、目的を分けて考える
検証用コピーは、変更を加えながら使う作業場所です。戻したい時点のデータを保管するバックアップとは、運用上の目的が異なります。
| 目的 | 用意するもの | 確認すること |
|---|---|---|
| 障害や誤操作から戻す | 復旧用のバックアップ | 必要なデータが残っているか、復元できるか |
| 更新や変更を試す | 別環境の検証用コピー | 本番への接続を切り分け、必要な機能を試せるか |
| サーバーを移転する | 移転先のサイトと切替計画 | 最終データ、公開先の切替、切替後の動作を確認できるか |
この表は目的を整理するための編集部の分類です。検証用コピーを作っただけで、バックアップの世代管理や復旧試験まで済んだことにはしません。保全するデータの考え方は、WordPressのバックアップの取り方も参考にしてください。
コピー前に、元サイトと受け取り側の条件を確認する
元サイトでは、Reprintプラグインを導入・設定できる管理権限と、有効なHTTPS接続が必要です。受け取り側では、コマンドラインのPHP、必要な拡張機能、保存容量を確認します。WebサーバーのPHPと、ターミナルで使うPHPの設定が同じとは限らないため、実行担当者がそれぞれ点検してください。
公式の最低要件は、元サイトのプラグインがWordPress 4.7以上・PHP 5.6.20以上、クライアントがPHP 7.4以上です。これはツールの互換性の下限であり、古いPHPを運用し続ける推奨ではありません。コピーしたサイト自身や各プラグインが必要とするPHP・DBの条件も満たす必要があります。 環境・権限・PHP拡張の公式要件（外部サイト）
SQLiteとMySQLは、検証したい内容に合わせて選ぶ
SQLiteは別のDBサーバーを用意せずに試せる選択肢です。一方、MySQLを前提にしたプラグインや、元ホスト独自の機能が動くとは限りません。本番と異なるDBで表示できたことだけで、本番への更新可否を決めないようにします。DBの種類、バージョン、文字照合なども検証条件として控えます。 DBの互換性と取り込み（外部サイト）
Windowsでは、公式の一連の複製手順はWSLを使う案内です。WSLはWindows上でLinux環境を使う機能です。WindowsのPHPで実行できる個別の取り込みコマンドもありますが、生成されるBashの起動スクリプトまで同じように使えるわけではありません。実行担当者は、作業端末と使う手順を先にそろえてください。 Windowsを含む実行環境の違い（外部サイト）
コピーの認証と保存先を決める
元サイトでプラグインを有効化しただけでは、転送は始まりません。クライアントを認証し、そのクライアントからコピーを実行します。認証を許可したクライアントは非公開の内容を含むファイル・DBをダウンロードできるため、誰の端末へ何を渡すかを決めてから進めます。 クライアントを認証する手順（外部サイト）
公開鍵方式では、受け取り側に秘密鍵を保持し、元サイトの管理画面にMigration Tokenを登録します。Migration Tokenに含まれるのは公開鍵で、秘密鍵を貼り付ける手順ではありません。接続トークンを使う環境では、そのトークン自体がダウンロード用の認証情報になります。 認証方式と鍵の扱い（外部サイト）
作業フォルダーには、ダウンロードしたサイトだけでなく、認証情報、転送の進捗、SQLデータなども残ります。コピーと作業状態は、一般公開するディレクトリや公開Gitリポジトリに置かず、アクセスできる人を限定します。実データが不要な検証では、ダミーデータのサイトから始めるのが編集部の提案です。 コピーに含まれ得るデータ（外部サイト）
コピー先を開く前に、メール・決済・定期処理を切り分ける
複製したサイトには、メール配信先、決済アカウント、外部APIなどへの接続設定が残る場合があります。公開サイトと別URLになったことだけでは、外部への送信まで止まりません。
コピー先を起動する前に、送信メール、定期ジョブ、決済などの本番接続を止めるか、テスト用へ変更します。 公式の移転ガイドも、これらをReprintがすべて処理するわけではないと説明しています。 コピー先を開く前の公式確認事項（外部サイト）
- メール実際の宛先へ送信しない設定
- 決済・予約テスト用の接続へ切り替え
- 定期処理自動実行と外部APIを確認
接続先の設定と、必要に応じた通信制限を確認してから、コピー先を開きます。
接続設定の変更方法は、プラグインやホスティングサービスによって異なります。たとえば、フォームの宛先変更だけで予約システムの通知まで止まるとは判断できません。担当者が機能ごとに接続先を確認し、設定だけで分離できない場合は、検証環境からの通信制限も検討します。
自動起動を止めて、点検する時間を確保する
公式の基本的なpull手順は、DBの取り込みとURLの書き換え後に開発サーバーを起動します。起動前に接続を点検するため、実行担当者は--start-runtime=noneを指定できます。--runtime=noneはサーバー設定を生成しないための別の指定です。 起動と設定生成を分けるオプション（外部サイト）
次は、公式のSQLite向け複製例に、自動起動を止める指定を加えた説明用の例です。クライアント導入と認証が済み、空の専用保存先を用意した場合を想定しています。source.exampleは仮のアドレスです。macOS・Linux・WSL向けで、このコマンドによる転送・起動は本稿の制作時点では実行していません。
php reprint.phar pull https://source.example \
--private-key-path=./reprint-key.pem \
--state-dir=./reprint-state --fs-root=./site-files \
--target-engine=sqlite --new-site-url=http://localhost:8881 \
--start-runtime=none
reprint-stateは認証や進捗を保存する場所、site-filesは受け取るサイトの保存先です。両者を分け、作業状態を配信対象のツリーに入れません。完全な導入・認証手順は公式の複製ガイド（外部サイト）で確認してください。
この例の構成で外部連携の切り分けを確認できたら、生成されたreprint-state/runtime/start.shから開発サーバーを起動します。次回開くときも、完成済みのコピーの起動と、元サイトからの再取得を区別します。
DBの再取り込みは、コピー先の変更をマージしない
pullやpull-dbでDBを再取り込みすると、元サイトから出力されたSQLデータに含まれるテーブルを再作成します。コピー先で書き換えた投稿・設定・注文・ユーザー情報などが、元サイト側の内容に置き換わり得ます。元とコピーの両方の変更を、自動で合体する操作ではありません。 再取り込みで置き換わるもの（外部サイト）
たとえば、検証用コピーでフォーム設定を変更した後にDBを再取得すると、その設定が元サイトの内容に戻る場合があります。再取り込み後は、外部サービスを分離した設定も再確認してから起動します。
- 起動・再起動完成したコピーを開く
- DB再取り込み元サイトのデータでテーブルを再作成
DBの再取り込みは変更のマージではありません。コピー先で変更した内容は、再取り込み前に別途保存します。
操作する前に、今回必要なのが「開く」「ファイルを更新する」「DBを更新する」のどれかを決めます。
| 今回の目的 | 操作の考え方 | 操作前後に確認すること |
|---|---|---|
| 完成したコピーをもう一度開く | 生成された起動スクリプトを使う | 起動先と、外部接続を分離した設定 |
| ファイルだけ再取得する | pull-filesを検討する |
対象ファイル、取得モード、コピー先の編集内容 |
| DBだけ再取得する | pull-dbを検討する |
置き換わるテーブル、保存したい編集、接続設定の再確認 |
| 全体を取り込み直す | pullの対象と保存先を再確認する |
既存コピーの変更保存、DBとファイルの両方への影響 |
pull-filesはDBを取り込みません。pull-dbはDBの取得・適用を行い、ファイルや実行用設定は更新しません。未完了の処理がある場合も、別の取り込みを重ねる前に、その処理を完了するか中止する判断が必要です。 ファイルとDBを分けて取得する手順（外部サイト）
ファイルの既定のcatch-upモードは、前回取得後に元側で変わったパスを更新します。同じファイルを両側で編集した場合のマージは行いません。mirrorモードでは、取得対象の範囲で元にないローカルファイルが削除されることもあります。「差分だけ取る」という説明だけでコピー先の変更が守られるとは判断しないようにします。 ファイル再取得のモード（外部サイト）
コピー完了後は、表示と主要機能を確かめる
外部サービスを切り分けた後、コピー先でページを開き、画像、内部リンク、管理画面へのログインを確認します。転送が成功しても、受け取り側のPHP・DBや、元ホストに依存するプラグインがすべて動くとは限りません。 公式の複製後チェック（外部サイト）
次の表は、編集部が提案する確認メモです。使っていない機能を無理に増やさず、そのサイトで必要な項目に絞ってください。
| 確認対象 | コピー先で確かめること | 記録しておくこと |
|---|---|---|
| 表示・画像・内部リンク | 主要ページが開き、コピー先を回遊できるか | URL、端末・ブラウザ、元サイトへ戻るリンクの有無 |
| ログイン・編集 | 必要な権限でログインし、編集・保存できるか | 対象の役割、操作、結果。パスワードは書かない |
| 問い合わせ | 用意したテスト先だけへ届き、通知内容が合うか | 使用フォーム、テスト宛先の管理担当、受信結果 |
| 予約・決済 | テスト環境で必要な一連の操作ができるか | 接続モード、確認した操作、未確認の範囲 |
| 定期処理・外部API | 実行する処理と接続先を区別できているか | 停止中／テスト実行済み／未確認の別 |
URLの書き換えにも範囲があります。ReprintはDB内などのURLを扱いますが、PHPやJavaScript等のコードに直接書かれたアドレスまで一律に直すものではありません。古いURLへ戻る箇所は、テーマ・プラグイン・外部設定も含めて調べます。 書き換えの対象と限界（外部サイト）
サーバー移転へ進む場合は、コピー中に増えた投稿・画像・注文などの扱いも別途決めます。稼働中のサイトのコピーは、すべてのファイルとDB行を同じ瞬間に固定したスナップショットではありません。最終コピーのための書き込み停止、公開先の切替、戻す手段を計画してください。 移転時の最終コピーと切替（外部サイト）
よくある質問
Reprintの導入前に、コピーの目的と操作の範囲を整理しておきましょう。
Reprintを入れるだけで、サイトはコピーされますか？
いいえ。プラグインの有効化、クライアントの認証、クライアントからの実行が別に必要です。管理画面で認証情報を登録できたことと、転送が完了したことも区別します。 認証の公式手順（外部サイト）
コピー先がローカルなら、メールや決済をそのまま試せますか？
ローカルでも、外部サービスへ接続できる場合があります。起動前に本番メール・決済・定期処理等を止めるか、テスト用へ切り替えます。設定だけで分離できない接続も、実行担当者が確認してください。
コピー先のDBを更新すると、両方の変更が合わさりますか？
いいえ。再取り込みはマージではなく、出力データに含まれるテーブルを元サイトの内容で再作成します。コピー先の編集を残したいときは先に保存し、取り込み後に外部接続の設定も再確認します。
コピーで直した内容を、Reprintで本番へ戻せますか？
WordPress.orgで配布されるプラグインは、ダウンロード用です。本番へアップロードするpushには、ホスティング側が用意する対応サーバーが必要で、同じプラグインを入れれば戻せるという意味ではありません。検証した変更を本番へ反映する方法は、保守担当者と別に決めます。 公式プラグインの対応範囲（外部サイト）
認証を解除すると、作ったコピーも消えますか？
消えません。不要になったクライアントの認証を元サイト側で解除しても、ダウンロード済みのコピーは受け取り側に残ります。公式手順ではTools → Reprint Serverで該当のMigration Tokenを削除し、接続トークン方式ではトークンを消去または置き換えます。ホスト管理の認証は管理会社へ依頼します。コピーを残す期間と管理する人も決めておきましょう。 アクセス権の解除（外部サイト）
まずは複製先と外部接続、再取得の目的を決める
Reprintは、既存サイトの内容で更新や変更を試すための選択肢です。最初に、複製元・複製先・データの管理担当を決め、起動前に本番への外部接続を切り分けます。
その後は、コピーを開く操作と、DB・ファイルを取り込み直す操作を区別します。何をコピーしたか、どの接続を分離したか、どの機能を確かめたかを記録することが、検証結果を次の更新判断につなげる出発点になります。
この記事の監修者
青山 忠司 あおやま ただし
WordPressを活用したホームページ制作から、公開後の運用・集客改善まで幅広く携わる。Google AnalyticsやSearch Consoleなどのデータをもとに、企業や店舗のWeb活用を支援している。 詳しいプロフィールはこちら
