データベース接頭辞ってそもそも何？
WordPress は、記事やユーザー情報を「データベースのテーブル」に保存しています。
そのテーブル名の先頭についているのが「データベース接頭辞（テーブルプレフィックス）」です。
初期設定のままだと、だいたいこうなっています。
wp_postswp_userswp_options
この wp_ の部分が「接頭辞」です。
インストール時に何も変えなければ、ほぼすべての WordPress サイトが wp_ を使っています。
なぜ「接頭辞を変更」するとセキュリティ的に有利なのか
攻撃者は「テーブル名が分かっている前提」で攻撃してくる
WordPress を狙う攻撃コードの多くは、
テーブル名は wp_users
投稿は wp_posts
オプションは wp_options
という前提で書かれています。
例えば、SQLインジェクションの脆弱性を悪用するとき、
攻撃者はこんなイメージでクエリを投げます。
SELECT * FROM wp_users WHERE ...
でも、あなたのサイトの接頭辞が wp_ ではなく
abc123_
だったとしたら、テーブル名は
abc123_users
になります。
この場合、攻撃者が「テーブル名を知っている前提」で書いた攻撃コードは、そのままでは動きません。
「WordPress ＝ テーブル名はこう」という“お約束”を崩すことで、攻撃の成功率を下げられるわけです。
「隠すだけの対策」だけど、バカにできない
データベース接頭辞の変更は、
パスワードを強くする
2段階認証を入れる
のように「鍵そのものを強くする」対策ではありません。
やっていることは、
攻撃者が当然知っていると思っている情報（テーブル名）を、
「実は違うよ」とズラす
という、いわゆる「オブスキュリティ（隠す系の対策）」です。
これだけで絶対安全にはなりませんが、
自動攻撃ツールがそのままでは通用しなくなる
雑な攻撃の成功率を下げられる
という意味で、「やっておくと地味に効く一枚の防御」になります。
いつ接頭辞を変えるのが現実的か
一番安全なのは「インストール時に変える」
理想を言えば、WordPress をインストールするときに、
接頭辞を wp_ から別のものに変える
のがベストです。
この段階なら、まだテーブルもほとんど空ですし、
後から一括置換したりする必要もありません。
例えば、
wp_ → mywp_wp_ → site2026_
のように、
自分にとって意味が分かるけれど、他人には推測しにくい接頭辞にしておくと良いです。
すでに運用中のサイトで変えるのは「慎重に」
運用中のサイトでも、接頭辞を変えることはできますが、
全テーブル名の変更wp-config.php の設定変更
一部プラグインやメタデータ内の接頭辞参照の置換
など、やることが一気に増えます。
ミスると、
ログインできなくなる
サイトが真っ白になる
一部機能だけ動かなくなる
といった事故が普通に起きます。
なので、運用中サイトでやる場合は、
必ず事前にデータベースのフルバックアップを取る
できればテスト環境で手順をリハーサルする
自信がなければ専用プラグインやプロに任せる
くらいの慎重さが必要です。
接頭辞をどういう名前にすればいいか
推測されにくく、でも自分は分かるもの
接頭辞は、次のような方針で決めるとバランスが良いです。
短すぎない（wp_ や db_ などは避ける）
サイト名やドメインと完全一致は避ける
英数字＋アンダースコアで、3〜8文字程度
例としては、
abc9x2_site24_mywp99_
など。
完璧にランダムである必要はありませんが、
「WordPress ならだいたいこれだよね」とは思われない名前にしておくのがポイントです。
例題：ダメな例と良い例
ダメな例：
wp_（デフォルトのまま）wordpress_（分かりやすすぎる）blog_（ありがちすぎる）
良い例：
wpx9a_site2026_koto01_
「自分が見て何のサイトか分かる」くらいの意味はあっても構いませんが、
「WordPress ならまずこれだろう」と思われる名前は避ける、というイメージです。
プログラミングの感覚で捉える「接頭辞変更」
これは「テーブル名の命名規則をカスタマイズする」話
フレームワークでも、
テーブル名のプレフィックス
スキーマ名
名前空間
などを変えることがありますよね。
WordPress の接頭辞変更も、
それと同じく「データベースの名前空間を少しずらす」行為です。
攻撃者は、
wp_userswp_posts
という“デフォルトの名前空間”を前提に攻撃してきます。
そこを
abc123_usersabc123_posts
にしておくことで、
「デフォルト前提のコード」をそのままでは効かなくする、というイメージです。
「これだけで安心」ではなく「レイヤーの一枚」として考える
大事なのは、
接頭辞を変えたからといって
パスワードが弱くてもいいわけではない
2段階認証や試行回数制限がいらなくなるわけでもない
ということです。
セキュリティは、
強力なパスワード
2段階認証
ログイン試行回数制限
ログインURL変更
wp-config.php 保護
接頭辞変更
といった対策を「レイヤー」として積み重ねることで、
「簡単には破れない状態」を作るものです。
接頭辞変更は、その中の一枚として「やっておくと地味に効く」タイプの対策だと捉えると良いです。
まとめ：接頭辞変更は「攻撃者の前提を崩す小さな一手」
「データベース接頭辞を変更」というテーマの本質は、
攻撃者が当然のように知っていると思っている情報（テーブル名）を
あえてデフォルトからずらしておくことで
自動攻撃や雑な攻撃の成功率を下げる
というところにあります。
特に、
これから新しく WordPress を立ち上げる
まだデータが少ない段階
であれば、インストール時に wp_ を変えておくのは、
コストのわりにリターンが大きい「おいしい設定」です。
すでに運用中のサイトで変える場合は、
バックアップとテストを前提に、慎重に進めること。
そして、接頭辞変更はあくまで「防御レイヤーの一枚」であり、
他のセキュリティ対策とセットで考える——ここだけは、エンジニアとして強く意識しておいてほしいポイントです。
