実務にて、改修で引き継いだWordPressサイトがローカルで再現できませんでした。

やったことは、いつもどおり All-in-One WP Migration でエクスポートしてローカル環境にインポートしただけです。原因を追うと、そのサイトはMySQLではなくSQLiteで動いていました。

SQLite製のWordPressは、MySQLの常識のまま触ると詰まります。しかも厄介なことに、SQLiteで動いていること自体に気づかないまま迷路に入ります。

この記事では前半で見分け方と再現手順を、後半で新規にローカル環境を立てるときのプラグイン選びとハマりどころをまとめます。

この記事で分かること
  • 「いつもの移行」がSQLiteサイトで詰まる4つの機構
  • 引き継いだWordPressがSQLiteかを見分ける方法
  • SQLiteサイトをローカルで正しく再現する3方式と使い分け
  • 新規に立てるときのプラグイン選び（3世代の整理）と手順ごとのハマりどころ
  • 本番で使っていいのかの線引き
目次
  1. SQLiteとは — MySQLと何が違うのか
  2. なぜ「いつもの移行」でSQLiteサイトは再現できないのか
  3. そもそも引き継いだサイトがSQLiteか、まず見分ける
  4. SQLiteサイトを正しくローカル再現する方法
  5. 新規にSQLiteで立てるなら — プラグイン3世代の交通整理
  6. 新規導入の手順と、各ステップで踏むハマりどころ
  7. これ、本番に使っていい？ — 「本番はMySQL前提」の線引き
  8. よくある質問（FAQ）
  9. まとめ
  10. 関連記事

SQLiteとは — MySQLと何が違うのか

MySQLとSQLiteの違いは、データベースが「サーバー」か「ファイル」かに集約されます。

MySQLはデータベース専用のサーバーを起動して接続します。SQLiteは実体がファイル1個で、そのファイルを読み書きするだけで動きます。

だからSQLiteは手軽です。DockerやMAMPでMySQLを立てるより手数が少なく、学習用のローカル環境に向いています。

ただし、この違いはそのまま落とし穴にもなります。WordPress周りのツールはMySQL前提のものが多く、データベースの管理ツールやWP-CLIなど、使い慣れた道具がそのままでは通じない場面が出ます（移行プラグイン側の対応状況は次の章で整理します）。以降のハマりどころは、ほぼすべてここに行き着きます。

なぜ「いつもの移行」でSQLiteサイトは再現できないのか

詰まる原因は「移行プラグインがSQLiteに対応していないから」ではありません。SQLiteサイトは受け側の下ごしらえが要る、というのが正体です。

先に通説をひとつ訂正させてください。「All-in-One WP Migration はMySQL専用だからSQLiteは扱えない」という説明は、現在では誤りです。v7.82 で「SQLite support」が追加され（2024年5月ごろ）、公式も「MySQL・MariaDB・SQLite 間をシームレスに移行できる」とうたっています。

ただし対応が入ったあとも修正は続いており、v7.106 では「SQLiteのエクスポートが不正なMySQLのCREATETABLE文を出力する」不具合が直っています。「v7.82以降なら万全」ではなく、できるだけ新しいバージョンで試すのが安全です。

それでも実務で詰まるのは、次の4つの機構のどれか（あるいは複数）が原因です。

詰まる機構なぜ起きるかどう避けるか
プラグインが古い世代All-in-One WP Migration が v7.82 未満だと、SQLiteを認識せずMySQL前提の処理として動く送り側・受け側の両方でバージョンを確認し、SQLite対応版に揃える
受け側にSQLite統合が無いインポート先が素のWordPressだと接続先はMySQLのまま。db.php ドロップインが先に入っていない環境は、MySQLとして振る舞うインポート前に受け側へSQLite統合プラグインを入れて有効化しておく
コアのSQLite統合に移行機能がゼロ「SQLite Database Integration」は有効化するとまっさらな新規データベースを作るだけ。公式も「SQLiteの実装にはデータを移行する仕組みは含まれない」と明言している「入れれば既存データも移る」という期待を捨て、別途データを持ち込む手段を用意する
標準エクスポート（WXR）は設定を運べないWXRファイルにはサイト設定（options）が含まれない。テーマ設定・プラグイン設定・パーマリンクなどが欠落する完全再現には使わない。コンテンツ確認だけの限定用途と割り切る

私のケースがどれだったかは、当時の環境情報が残っておらず断定できません。ただ入り口は共通です。まず相手がMySQLなのかSQLiteなのかを確かめるところから始めます。

そもそも引き継いだサイトがSQLiteか、まず見分ける

改修着手の最初のチェックは、データベースの種別確認です。触れる場所に応じて上から確認すれば、数分で判別できます。

判別手段見るものSQLiteのサイン
サイトヘルス管理画面 > ツール > サイトヘルス > 情報 > データベース「データベースタイプ」がSQLiteと表示され、「SQLite バージョン」「データベースファイル」の欄が現れる（MySQL用のホスト名・ユーザー名の欄は消える）
ドロップインの有無wp-content/db.php（管理画面 > プラグイン > ドロップイン タブでも確認できる）db.php が存在する＝標準ではないデータベース層が挟まっている
データベースファイルの実在wp-content/database/.ht.sqlite（既定の場所）このファイルがあれば、実データはSQLiteに入っている
wp-config.php の定数DB_ENGINE 定数define( 'DB_ENGINE', 'sqlite' ); があればSQLite

「無い＝MySQL確定」とは言えない点に注意してください。

DB_ENGINE は db.php ドロップインが「まだ定義されていなければ定義する」作りのため、wp-config.php に書かれていないことがあります。データベースファイルの場所も DB_DIR / DB_FILE 定数で変更できます。

それでも判断できなければ、WP-CLI の反応も確認します。wp db cli がMySQLのCLIを開こうとする・wp db export がMySQL用のダンプを吐こうとする・コマンドが止まらないといった具合に、うまく動かないこと自体が傍証になります（安定版のWP-CLI 2.12.0 が同梱するデータベース系コマンドがSQLiteに対応していないためです）。

ただしこれは上の4点のような直接の証拠ではないため、判断の裏付けとして使う程度に留めてください。

触れる環境別の判別フロー（3ステップ）

  1. 管理画面が触れる場合
    ツール > サイトヘルス > 情報 > データベース を開きます
  2. FTP / SSH が触れる場合
    wp-content/db.php と wp-content/database/.ht.sqlite の有無を見ます。.ht.sqlite はドット始まりの隠しファイルなので、隠しファイル表示をONにしてから確認してください
  3. wp-config.php が読める場合
    DB_ENGINE 定数を検索します

どれかがSQLiteを示したら、移行ツールを叩く前に次のセクションへ切り替えます。

SQLiteサイトを正しくローカル再現する方法

ファイル一式のコピーがいちばん素直です。SQLiteはデータベースがファイル1個で完結するので、その長所をそのまま活かせます。

前提として、WordPressコアのSQLite統合そのものには移行機能がありません。「プラグインを入れれば既存データも一緒に移る」という期待は、先に外しておく必要があります。

方式は3つあります。

A. ファイル一式まるごとコピー方式

もっとも仕組みが単純で、状態を取りこぼしにくい方式です。

  1. 本番からWordPress一式を落とす。SQLite特有の3点（下記）を取りこぼさないよう注意
  2. ローカルに同じ構成で配置する。wp-config.php も本番と同じ内容で置く（DB_ENGINE の記述を落とさないよう注意）
  3. wp-content/database/ フォルダに、Webサーバープロセスからの書き込み権限を確保する。ここが足りないと、表示はできても保存で失敗する
  4. URLを置換する

手順1で取りこぼしてはいけないのは次の3点です。

  • wp-content/db.php（ドロップイン）
  • wp-content/database/（.ht.sqlite 本体を含む）
  • sqlite-database-integration プラグインフォルダ

3つ目のプラグインフォルダは、フォルダ名を変えず wp-content/plugins/sqlite-database-integration の位置に置きます。ここがズレると db.php は実装本体を見つけられません。エラーも出さずに処理を抜けるため、WordPressはMySQLに接続しにいって「データベース接続確立エラー」になります。

最後のURL置換だけは注意が必要です。.ht.sqlite の中の siteurl と home は本番URLのままだからです。

置換ツールは Search-Replace-DB をはじめMySQL前提のものが多く、SQLiteでは動かない場合があります。うまくいかないときは phpLiteAdmin のようなSQLite向けの手段に切り替えてください。

B. All-in-One WP Migration（v7.82以降）方式

公式のクロスDB対応を使う方式です。送り側と受け側の両方を v7.82 以上にし、受け側にSQLite統合を先に入れて有効化した状態でインポートします。

ただし、この手順を踏めば必ず成功するとまでは言えません。実際に詰まった報告も残っています。Aを本命に置きつつBも試す、くらいの温度感が現実的です。

C. 標準エクスポート（WXR）方式

WXRは投稿などのコンテンツは運べますが、サイト設定（options）は含まれません。テーマ設定やパーマリンクは引き継がれないので、デザインの当たりを見る程度の限定用途と考えてください。

新規にSQLiteで立てるなら — プラグイン3世代の交通整理

ここからは新規にSQLiteでローカル環境を立てる話に切り替えます。使うプラグインは「SQLite Database Integration」の一択です。

手軽さの理由は冒頭で触れたとおりです。データベースがファイル1個で完結するぶん、MySQLを立てる手数が要りません。

ただ、検索すると似た名前のプラグインが3つ出てきて混乱します。整理しておきます。

呼称提供元・状態使う?ひとことメモ
SQLite Integration（旧）有志による実装。長年更新が止まっている使わない検索上位に残っているため踏みやすい
SQLite Database IntegrationWordPressのコアチームが維持する feature plugin。コアへの取り込みを目指す位置づけこれを使うローカル・検証用の実質的な標準
新SQLiteドライバー（AST版）上記プラグインに同梱されている実験的な実装。feature flag で有効化する試したい人だけ将来これが既定になる予定

ここで前提をひとつ握っておきます。「SQLite Database Integration」は feature plugin、つまり公式が「おおむねベータテスト用のプラグイン」と位置づけているものです。この前提は、後半の本番判断にそのまま効いてきます。

なぜ旧・有志版を避けるのか

旧「SQLite Integration」は更新が長く止まっており、現在のWordPressやPHPとの組み合わせで動作が保証されません。検索では今も上位に残っているので、名前が似ている点に注意してください。

新ドライバー（AST版）を試したい人へ

新SQLiteドライバーは、MySQLのSQLをPHPで解析してSQLiteへ変換する実装です。プラグインのバージョン 2.2.1 以降に同梱されており、wp-config.php に次の1行を足すと有効になります。

PHP
define( 'WP_SQLITE_AST_DRIVER', true );

書く位置に注意してください。 この行は require_once ABSPATH . 'wp-settings.php';（直前に「編集が必要なのはここまでです」というコメントがある行）より上に置きます。下に書くと読み込まれるタイミングを過ぎているため、エラーも出ないまま旧ドライバーのままになります。

執筆時点では実験的な機能ですが、v3.0 でこの新ドライバーが既定になる予定とアナウンスされています。存在だけ知っておくと、切り替えの時期に慌てずに済みます。

新規導入の手順と、各ステップで踏むハマりどころ

手順は4ステップで終わります。詰まるのは「db.php が自動でコピーされる仕組み」「データベース設定画面がスキップされる」「作られるデータベースが隠しファイル」を知らないときです。

導入手順（4ステップ）

  1. WordPress本体をローカルに用意する
    ここで「MySQLも先に用意しなきゃ」と身構える必要はありません（手順3の注釈を参照）
  2. 「SQLite Database Integration」をインストールする
    プラグインの新規追加から入れます
  3. 有効化すると db.php が wp-content/ に自動コピーされる
    コピーが済むとインストール画面へ進みます。このとき、データベースの接続情報を入力する画面は現れません
  4. wp-content/database/.ht.sqlite に新しいデータベースが作られる
    ここが実データの置き場所になります

ネット上には「WordPressのインストールにはMySQL/MariaDBが必須」という説明もありますが、それはDockerなどで素のWordPressを先に立てる構成の話です。プラグイン経由なら db.php ドロップインがデータベース層を差し替えるため、設定画面自体がスキップされます。この2つの経路を分けて理解しておくと迷いません。

着手前に読むハマりどころチェックリスト

(1) すでに db.php があると有効化できない

  • 何が起きる: SQLiteを有効化しようとしても進めない
  • なぜ: キャッシュ系プラグインなどが先に db.php を置いていると、ドロップインは1つしか持てないため衝突する
  • どうする: プラグイン > ドロップイン タブで有無を確認する。既にある場合は提供元を確かめてから判断する

(2) データベースが隠しファイルで見つからない

  • 何が起きる: wp-content/database/ を開いても中身が空に見える
  • なぜ: .ht.sqlite はドット始まりのため、Finder・エクスプローラー・FTPクライアントの既定設定では表示されない
  • どうする: 隠しファイルの表示をONにする（macOSのFinderは command + shift + .）。バックアップやコピーのときも、忘れると丸ごと取りこぼす

(3) 無効化するとMySQL構成に戻る

  • 何が起きる: 無効化した瞬間、それまで作ったコンテンツが消えたように見える
  • なぜ: SQLite側とMySQL側は別のデータベース。元のMySQL構成に戻るだけで、データが引き継がれるわけではない
  • どうする: 「切り替え＝別のデータベースを見にいく」と理解しておく。試す前に .ht.sqlite を退避しておくと安心

(4) MySQL固有の機能に依存するプラグインやテーマが動かないことがある

  • 何が起きる: 特定のプラグインだけエラーになる・検索や集計がうまく動かない
  • なぜ: MySQL固有のSQLに依存している場合、SQLiteへの変換で無理が出る
  • どうする: 実案件に近い構成で早めに互換テストをする

(5) database/ フォルダの書き込み権限

  • 何が起きる: 表示はできるが、保存や更新でエラーになる
  • なぜ: Webサーバーのプロセスが wp-content/database/ に書き込めないと、データベースを更新できない
  • どうする: フォルダの所有者と権限を確認する。Dockerやレンタルサーバーで構成した場合に起きやすい

これ、本番に使っていい？ — 「本番はMySQL前提」の線引き

学習・ローカル・低トラフィックの検証はOK。商用の本番は避けるのが安全です。

公式プラグインの説明には「おおむねベータテスト用のプラグインと考えられる。ある程度は本番で使っても問題ないはずだが、他のプラグインと同じく自己責任で」という趣旨の記載があります。一方で、日本語の解説記事は「本番非推奨」寄りのトーンが多い印象です。

用途判断
ローカルでの学習・お試し向いている。軽くて速く、後片付けも簡単
低トラフィックの検証・デモ自己責任のうえで可。互換テストを済ませてから
商用の本番・高トラフィック避けたほうが安全。feature plugin という位置づけ・公式サポートの対象外・同時接続に弱い

「絶対に使えない」という話ではありません。ただ、お客様のサイトを預かる場面で迷ったら、本番はMySQLに寄せるのが安全側の選択だと考えています。

よくある質問（FAQ）

SQLiteのサイトをMySQLに変換して引き継ぐことはできますか？

All-in-One WP Migration は v7.82 以降で MySQL・MariaDB・SQLite 間のクロスDB移行に対応しています（対応後もSQLite関連の不具合修正が続いているため、できるだけ新しいバージョンを使ってください）。

ただし受け側の下ごしらえが要る点は本文のとおりです。まずは検証環境で試してから本番の判断をするのが安全です。

.ht.sqlite をそのままバックアップすればいいですか？

データベースの実体は1ファイルなので、コピーするだけでバックアップになります。隠しファイルなので取りこぼしに注意してください。合わせて wp-content/db.php も控えておくと復元が楽になります。

phpMyAdmin のようにデータベースの中身を見る方法はありますか？

phpLiteAdmin など、SQLite向けの管理ツールを使います。URL置換もこちらで行います。MySQL向けのツールは動かない場合があるため、道具を切り替える前提で考えてください。

WP-CLI は使えますか？

データベース系のコマンド（wp db cli / wp db export など）はMySQL前提の作りのため、SQLite環境では期待どおりに動かない報告があります。逆に言えば、この挙動自体がSQLiteかどうかの傍証になります。

まとめ

  • 引き継いだサイトは、まずデータベースの種別を見分ける。サイトヘルス・db.php・.ht.sqlite・DB_ENGINE の4点で数分で判別できる
  • SQLiteサイトの再現はファイル一式のコピーが素直。.ht.sqlite の取りこぼしと、URL置換だけを手当てする
  • All-in-One WP Migration は現在SQLiteに対応している（v7.82以降）。詰まるのはプラグイン世代・受け側の下ごしらえ・コア統合に移行機能がない点・WXRの設定欠落の4つ
  • 新規に立てるならプラグインは「SQLite Database Integration」一択。旧・有志版は使わない
  • 本番はMySQLに寄せる。SQLiteは学習やローカル検証で強みが出る

SQLiteは「手軽に試す・軽く動かす」用途にはとてもいい選択肢です。詰まりどころを先に知っておけば、MySQLの準備に時間を取られずWordPressに触り始められます。

関連記事

関連記事
All-in-One WP Migration でインポートできないときの上限解除の方法【手順つき】
WordPressサイトのバックアップを作ってインポートしようとしたら、「最大アップロードサイズを超えています」というエラーが出…
2026年4月8日 2026年4月20日