WordPress データベースの構造

標準的なシングルサイト WordPress のインストールは、コンテンツと設定を 12 個のコアデータベーステーブルに保存し、これらはすべて共通のプレフィックス (デフォルトでは wp_) を共有します。WordPress とほぼすべての Plugin は設定をそのデータベース内に保存し、これらのテーブルに整理して格納します。この記事では、デフォルトの WordPress データベーステーブルをそれぞれ解説します。各テーブルが何を保存し、何がそれに依存し、欠落・破損したときに何が壊れるのかを説明します。

TL;DR: WordPress はサイトデータのほとんどを MySQL または MariaDB のデータベースに保存します。標準的なシングルサイト WordPress のインストールでは現在、設定可能なプレフィックス (一般的には wp_) を持つ 12 個のデフォルトテーブルが使用されます。これらのテーブルは投稿・固定ページ・ユーザー・設定・コメント・タクソノミー用語・メタデータを保存し、Plugin・Theme・WooCommerce・マルチサイトのインストールではさらに多くのテーブルが追加されることがあります。

注: WordPress データベースを安全に調査するには、まずサイトを Backup するか、WP STAGING で Staging 環境を作成してください。その上で、phpMyAdmin や Adminer などのデータベース管理ツールを使えば、本番サイトに影響を与えずにデータベースへアクセスして変更できます。

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 Database Header of the table wp_options

WordPress サイトのどの部分をどのテーブルが保持しているのかがなぜ重要なのかを理解するために、これらのテーブルについてもう少し詳しく見ていきましょう。

テーブル構造を理解しておくと、WP STAGING で Staging サイトと本番サイトの間でデータを同期・移動するときに、どのテーブルを含めるべきか、除外すべきかを判断しやすくなります。Staging サイトを更新する予定の場合にも役立ちます。

これは WordPress 7.0 で予定されている wp_collaboration テーブルにより、さらに重要になります。このテーブルはリアルタイムエディタの共同編集データを保存しますが、これは一時的かつ環境固有のものです。Staging サイトを本番サイトへ Push する際は、データベース全体を意図的に置き換えたい場合を除いて、本番サイトのアクティブな共同編集状態を上書きしないようにしてください。

WordPress コアテーブル一覧

上の表は概要を示したものです。以下のセクションでは、開発者・サイト運営者、そして移行・Backup・データベースの問題のデバッグを行う方のために、WordPress コアテーブルをより詳しく説明します。

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 である revisionattachment を確認できます:

Table wp_posts column attachment post_type
Table wp_posts column revision post_type

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_taxonomywp_terms テーブルを追加データで拡張します。wp_terms のメタデータのようなものですが、Plugin がここにカスタムデータを追加することはできません。このテーブルにはメニューとメニュー項目の関連性も含まれます。

wp_termmeta テーブルはタクソノミー用語のメタデータを保存します。wp_postmetawp_usermetawp_commentmeta と同様の仕組みですが、対象はカテゴリー・タグ・カスタムタクソノミー用語です。

Plugin や Theme はこのテーブルを使って、カテゴリー画像・SEO メタデータ・カスタムカラー・表示設定・その他のタクソノミー固有のフィールドなど、用語に関する追加データを保存できます。

移行後にこのテーブルが欠落していたり不完全だったりすると、カテゴリーとタグ自体は残っていても、追加のメタデータが失われることがあります。

wp_comments, wp_commentmeta

wp_comments は投稿と固定ページのコメントを保存します。このテーブルには未承認のコメントや投稿者情報、コメントの階層構造も含まれます。wp_commentmeta テーブルにはコメントに関するさらなるメタデータが含まれます。

このテーブルにはサイトに追加されたカスタムリンクに関する情報が含まれます。非推奨となっており、現在は使用されていません。一部の古い Plugin がまだ使用していますが、通常は空のテーブルです。

WordPress 7.0 で導入予定のテーブル: wp_collaboration

wp_collaboration は WordPress 7.0 で予定されている新しいコアデータベーステーブルです。ブロックエディタのリアルタイム共同編集機能の一部であり、複数のユーザーが同じ投稿や固定ページを同時に編集できるようにします。

このテーブルは、セッション識別子・ルーム情報・クリーンアップ用のタイムスタンプといった高頻度の共同編集データを、通常のコンテンツテーブルである wp_postswp_postmeta から分離します。リアルタイムのエディタ操作は非常に頻繁に書き込みを行うため、これらをコンテンツテーブルの外に置くことで、編集セッション中に投稿関連のオブジェクトキャッシュが無効化されるのを防ぎます。

このテーブルは wp_postswp_postmeta・WordPress のリビジョンシステムを置き換えるものではありません。投稿・固定ページ・添付ファイル・カスタム投稿タイプ・リビジョンは引き続き wp_posts に保存され、投稿固有のメタデータは引き続き wp_postmeta に保存されます。

Backup や移行の際は、wp_collaboration を短命なデータとして扱ってください。データベース全体の Backup には含めるべきですが、Staging サイトを本番へ Push するときは、WordPress がユーザーの編集に応じて共同編集の状態を再生成できるため、通常は本番サイトを上書きする必要はありません。スキーマは WordPress 7.0 のリリース前にまだ変更される可能性があるため、依存する前に最終的な列リストをご確認ください。

WordPress データベースの図解構造

この図は WordPress テーブルがどのように関連しているかを示しています:

WordPress Database Structure and tables - SVG

画像を最大解像度で開く: 右クリック → 新しいタブで画像を開く

WordPress データベースのよくある問題と原因となるテーブル

問題 最も関連性の高いテーブル 確認すべきこと
移行後にサイトが誤ったドメインへリダイレクトする wp_options siteurlhome、シリアライズされた Plugin オプションを確認
管理者ユーザーは存在するが管理者権限がない wp_usermeta 特にテーブルプレフィックスを変更した後は、capabilities キーを確認
投稿は存在するがカテゴリーやタグが欠落している wp_termswp_term_taxonomywp_term_relationships すべてのタクソノミーテーブルが一緒に移行されたかを確認
メディアライブラリのエントリは存在するが画像が壊れている wp_postswp_postmeta、uploads フォルダ 添付ファイルは wp_posts に保存され、ファイルパスは多くの場合 wp_postmeta_wp_attached_file に保存される
移行後にメニューが消える wp_postswp_termswp_term_relationshipswp_postmeta ナビゲーションメニューは複数のテーブルにまたがって保存される
Plugin 設定が消える wp_options、場合によっては Plugin 固有のテーブル Plugin が wp_options に設定を保存しているか、カスタムテーブルに保存しているかを確認
移行後にサイトが遅くなる wp_optionswp_postmeta autoload オプションや大きなメタデータテーブルを確認
コメントやレビューが消える wp_commentswp_commentmeta 両方のテーブルをまとめて移行
WordPress がテーブルが存在しないと表示する wp-config.php、すべてのプレフィックス付きテーブル $table_prefix を確認し、すべてのテーブルが同じプレフィックスを使用しているかを確認

関連記事

Updated on 9月 2, 2026

Rene Hermenau

著者: Rene Hermenau

著者について: René Hermenau は WP STAGING の創設者です。WordPress のバックアップ、ステージング、移行、データベース処理、安全なデプロイメントワークフローに取り組んでいます。