WordPress とほぼすべての Plugin は設定をサーバー上の固有の場所に保存します。それが「データベース」と呼ばれる場所です。データベースに保存されたデータは「テーブル」と呼ばれる単位で整理されています。この記事では、デフォルトの WordPress データベース構造で利用できるすべてのフィールドの意味を詳しく解説します。
TL;DR: WordPress はサイトデータのほとんどを MySQL または MariaDB のデータベースに保存します。標準的なシングルサイト WordPress のインストールでは現在、設定可能なプレフィックス (一般的には
wp_) を持つ 12 個のデフォルトテーブルが使用されます。これらのテーブルは投稿・固定ページ・ユーザー・設定・コメント・タクソノミー用語・メタデータを保存し、Plugin・Theme・WooCommerce・マルチサイトのインストールではさらに多くのテーブルが追加されることがあります。
注: WordPress データベースを安全に調査するには、まずサイトを Backup するか、WP STAGING で Staging 環境を作成してください。その上で、phpMyAdmin や Adminer などのデータベース管理ツールを使えば、本番サイトに影響を与えずにデータベースへアクセスして変更できます。
Contents
WordPress データベーステーブル一覧
標準的なシングルサイト WordPress のインストールでは現在、12 個のデフォルトデータベーステーブルが使用されます。下の表は、各テーブルが何を保存し、WordPress のどこで使用されているか、欠落・破損するとどんな影響があるかをまとめたものです。
| テーブル | 保存内容 | 用途 | 欠落・破損したときの影響 |
|---|---|---|---|
wp_options | サイト URL、有効な Plugin、Theme 設定、トランジェント、リライトルール、cron データ | WordPress 起動、Plugin 設定、サイト構成 | 誤った URL リダイレクト、設定の欠落、Plugin の障害、cron の不具合、autoload オプションによる遅延 |
wp_posts | 投稿、固定ページ、添付ファイル、リビジョン、メニュー、カスタム投稿タイプ | コンテンツ、メディアライブラリ、ナビゲーションメニュー、多くの Plugin データ | 固定ページ・投稿・メディアの欠落、メニューの不具合、カスタム投稿タイプエントリの欠落 |
wp_postmeta | 投稿・固定ページ・添付ファイル・商品・ページビルダー・SEO Plugin のメタデータ | アイキャッチ画像、商品データ、SEO フィールド、ビルダーレイアウト | 画像の欠落、レイアウトの崩れ、商品データの欠落、SEO メタデータの不完全 |
wp_users | ユーザーアカウント、ログイン情報、パスワードハッシュ、メールアドレス、表示名 | 認証と投稿者管理 | ユーザーがログインできない、投稿者情報が消える |
wp_usermeta | ユーザーロール、権限、プロフィールフィールド、Plugin のユーザー設定 | 権限とユーザー固有の設定 | 管理者の権限喪失、ロールの消失、ユーザー設定の破損 |
wp_comments | コメント、ピンバック、トラックバック、レビュー | コメントとレビュー機能 | コメントやレビューが消える |
wp_commentmeta | コメントとレビューのメタデータ | スパムステータス、評価、Plugin のコメントデータ | レビューのメタデータ、スパムデータ、Plugin のコメントデータが失われる |
wp_terms | 用語名とスラッグ | カテゴリー、タグ、リンクカテゴリー、カスタムタクソノミー用語 | カテゴリー名・タグ名が消える |
wp_termmeta | タクソノミー用語のメタデータ | 用語画像、SEO メタデータ、カスタム用語フィールド | カテゴリー・タグのメタデータが消える |
wp_term_taxonomy | タクソノミー種別、親子関係、用語数 | カテゴリー・タグ・カスタムタクソノミーの区別 | カテゴリーやタグのマッピングが誤る、または階層が失われる |
wp_term_relationships | コンテンツとタクソノミー用語の関連付け | 投稿・商品・固定ページにカテゴリーやタグを割り当てる | 投稿のカテゴリー・タグが失われる、メニューやタクソノミーの関連が壊れる |
wp_links | レガシーのブログロール・リンクマネージャーデータ | 非推奨のリンクマネージャー機能と古い Plugin | 最新サイトでは通常影響なし。古い Plugin がまだ使用している場合を除く |
データベーステーブルはどのように見えるか
1 行のヘッダー行と、その下の行に値があるエクセルシートを想像してください。
例えば wp_options テーブルの一部はこのように見えます:
WordPress サイトのコンテンツを担うテーブルがどれであるかを知ることがなぜ重要なのかを理解するために、これらのテーブルについてもう少し詳しくお話しします。
テーブル構造を理解しておくと、WP STAGING で Staging サイトと本番サイトの間でデータを同期・移動するときに、どのテーブルを含めるべきか、除外すべきかを判断しやすくなります。Staging サイトを更新する予定の場合にも役立ちます。
これは WordPress 7.0 以降ではさらに重要になります。予定されている wp_collaboration テーブルはリアルタイムエディタの共同編集データを保存しますが、これは通常一時的かつ環境固有のものです。Staging サイトを本番サイトへ Push する際、データベース全体を意図的に置き換える場合を除いて、本番サイトのアクティブな共同編集状態を上書きしないようにしてください。
WordPress コアテーブル一覧
上の表は概要を示したものです。以下のセクションでは、開発者・サイト運営者、そして移行・Backup・データベースの問題のデバッグを行う方のために、WordPress コアテーブルをより詳しく説明します。
- wp_options
- wp_users,
- wp_usermeta
- wp_posts
- wp_postmeta
- wp_terms
- wp_term_relationships
- wp_term_taxonomy
- wp_termmeta
- wp_comments
- wp_commentmeta
- wp_links
WordPress はメジャーリリースで新しいコアテーブルを追加することがあります。例えば、WordPress 7.0 ではリアルタイム共同編集データのために `wp_collaboration` の導入が予定されています。
データベース内の他のテーブルは Plugin や Theme によって作成されたものであり、サイトを正常に動作させるために必ず必要というわけではありません。
wp_options
wp_options テーブルは最も重要な WordPress データベーステーブルの 1 つで、URL、タイトル、インストールされた Plugin など、WordPress サイトのすべての設定を保存します。多くの Plugin もこのテーブルに設定を保存します。
WordPress ダッシュボードのすべての設定はこのテーブルに保存されます。
wp_users,
wp_usermeta
wp_users は WordPress サイトに登録されているすべてのユーザーを保存します。ユーザー名と暗号化されたパスワード・メールアドレス・登録日時・表示名・ステータスなど、ユーザーに関する基本情報を含んでいます。
wp_usermeta はユーザーのメタデータ (「追加データ」) を保存します。wp_users テーブルをより多くのデータで拡張します。例えば、ユーザーの名前は wp_users テーブルではなく wp_usermeta テーブルに保存されます。
このテーブルには 2 つの必要なフィールドがあります。Plugin は meta_key フィールドに新しい値を追加するだけで、wp_usermeta にカスタムデータを保存できます。
wp_posts,
wp_postmeta
wp_posts テーブルは WordPress サイトのすべてのコンテンツ関連データを保存します。すべての投稿・固定ページとそれらのリビジョンは wp_posts テーブルにあります。意外かもしれませんが、WordPress はこのテーブルにもっと多くのものを保存しています。
このテーブルにはナビゲーションメニュー項目、メディアファイル、画像などの添付ファイル、Plugin が使用するコンテンツデータも含まれます。
wp_posts には post_type というテーブル列があり、これによって異なる種類のデータが区別され、データベースクエリで特定の種類のデータを取得できます。post_type はこのテーブルで最も重要な列です。
下の画像では、同じ wp_posts テーブルに保存されている 2 種類の post_type である revision と attachment を確認できます:
wp_postmeta テーブルは wp_usermeta と同様に wp_posts テーブルを追加データで拡張し、他の Plugin からも利用できます。
例えば、人気のある Yoast SEO Plugin は、カスタム Open Graph タグ・投稿・URL データをこのテーブルに保存します。
wp_terms,
wp_term_relationships,
wp_term_taxonomy,
wp_termmeta
wp_terms テーブルは投稿・固定ページ・リンクのカテゴリーとタグを保存します。
このテーブルの列の 1 つに「slug」があります。slug は特定の投稿のタグを反映する用語です。WordPress では、タグを使って投稿・固定ページ・リンクを結びつけることができます。
wp_term_relationships は接続テーブルで、これらのタグを投稿・固定ページ・リンクに関連付けます。用語オブジェクトと用語のマッピングのようなものです。
wp_term_taxonomy は wp_terms テーブルを追加データで拡張します。wp_terms のメタデータのようなものですが、Plugin がここにカスタムデータを追加することはできません。このテーブルにはメニューとメニュー項目の関連性も含まれます。
wp_termmeta テーブルはタクソノミー用語のメタデータを保存します。wp_postmeta・wp_usermeta・wp_commentmeta と同様の仕組みですが、対象はカテゴリー・タグ・カスタムタクソノミー用語です。
Plugin や Theme はこのテーブルを使って、カテゴリー画像・SEO メタデータ・カスタムカラー・表示設定・その他のタクソノミー固有のフィールドなど、用語に関する追加データを保存できます。
移行後にこのテーブルが欠落していたり不完全だったりすると、カテゴリーとタグ自体は残っていても、追加のメタデータが失われることがあります。
wp_comments,
wp_commentmeta
wp_comments は投稿と固定ページのコメントを保存します。このテーブルには未承認のコメントや投稿者情報、コメントの階層構造も含まれます。wp_commentmeta テーブルにはコメントに関するさらなるメタデータが含まれます。
wp_links
このテーブルにはサイトに追加されたカスタムリンクに関する情報が含まれます。非推奨となっており、現在は使用されていません。一部の古い Plugin がまだ使用していますが、通常は空のテーブルです。
WordPress 7.0 で導入予定のテーブル: wp_collaboration
`wp_collaboration` は WordPress 7.0 で予定されている新しい WordPress コアデータベーステーブルです。ブロックエディタのリアルタイム共同編集機能の一部であり、複数のユーザーが同じ投稿や固定ページを同時に編集できるようにします。
初期の WordPress 7.0 ベータ版では、共同編集関連の同期データを post および post meta のストレージに保存していました。これによりパフォーマンスの問題が発生していました。リアルタイムのエディタ操作は非常に頻繁にデータを書き込む可能性があるためです。各 post meta の更新は投稿関連のオブジェクトキャッシュを無効化することがあり、エディタセッションが開いている間、永続的なオブジェクトキャッシュの効果が低下する可能性があります。
新しい `wp_collaboration` テーブルは、高頻度の共同編集データを `wp_posts` や `wp_postmeta` のような通常のコンテンツテーブルから分離します。その目的は、共同編集の更新、クライアント / セッション識別子、ルーム情報、クリーンアップ用のタイムスタンプなど、エディタが使用する一時的な同期データを保存することです。
このテーブルは `wp_posts`・`wp_postmeta`・WordPress のリビジョンシステムを**置き換えるものではありません**。投稿・固定ページ・添付ファイル・カスタム投稿タイプ・リビジョンは引き続き `wp_posts` に保存され、投稿固有のメタデータは引き続き `wp_postmeta` に保存されます。
Backup や移行の際は、`wp_collaboration` を永続的なコンテンツテーブルとは異なる扱いをしてください。データベース全体の Backup には含めるべきですが、Staging サイトを本番に Push するときは、このテーブルは通常、本番サイトを上書きする必要はありません。標準のサイトコンテンツではなく短命な共同編集 / セッションデータを保存するためです。WordPress はユーザーがコンテンツを編集する際に共同編集の状態を再生成できます。
重要: データは一時的なものですが、編集中のコンテンツに関連するエディタ同期ペイロードが含まれている可能性があります。プライバシーとセキュリティの観点から、公開可能なものや使い捨てとして扱わないでください。
注: 最終的なスキーマは WordPress 7.0 のリリース前にまだ変更される可能性があります。開発中、`wp_collaboration` の公開提案には、自動増分 ID・ルーム識別子・クライアント / ユーザー識別子・データペイロード・GMT タイムスタンプといったフィールドが含まれていました。最近のテストでは、プレゼンス / アウェアネスデータを別の `wp_presence` テーブルに保存する案も検討されています。正確な列リストを公表する前に、最終的な WordPress 7.0 のデータベーススキーマをご確認ください。
WordPress データベースの図解構造
この図は WordPress テーブルがどのように関連しているかを示しています:
画像を最大解像度で開く: 右クリック → 新しいタブで画像を開く
WordPress データベースのよくある問題と原因となるテーブル
| 問題 | 最も関連性の高いテーブル | 確認すべきこと |
|---|---|---|
| 移行後にサイトが誤ったドメインへリダイレクトする | wp_options | siteurl、home、シリアライズされた Plugin オプションを確認 |
| 管理者ユーザーは存在するが管理者権限がない | wp_usermeta | 特にテーブルプレフィックスを変更した後は、capabilities キーを確認 |
| 投稿は存在するがカテゴリーやタグが欠落している | wp_terms、wp_term_taxonomy、wp_term_relationships | すべてのタクソノミーテーブルが一緒に移行されたかを確認 |
| メディアライブラリのエントリは存在するが画像が壊れている | wp_posts、wp_postmeta、uploads フォルダ | 添付ファイルは wp_posts に保存され、ファイルパスは多くの場合 wp_postmeta の _wp_attached_file に保存される |
| 移行後にメニューが消える | wp_posts、wp_terms、wp_term_relationships、wp_postmeta | ナビゲーションメニューは複数のテーブルにまたがって保存される |
| Plugin 設定が消える | wp_options、場合によっては Plugin 固有のテーブル | Plugin が wp_options に設定を保存しているか、カスタムテーブルに保存しているかを確認 |
| 移行後にサイトが遅くなる | wp_options、wp_postmeta | autoload オプションや大きなメタデータテーブルを確認 |
| コメントやレビューが消える | wp_comments、wp_commentmeta | 両方のテーブルをまとめて移行 |
| WordPress がテーブルが存在しないと表示する | wp-config.php、すべてのプレフィックス付きテーブル | $table_prefix を確認し、すべてのテーブルが同じプレフィックスを使用しているかを確認 |
