2026年9月10日

MySQLのユーザー作成と権限設定方法｜CREATE USERとGRANTでWordPress用ユーザーを作る

データベースサーバー

MySQL でユーザーを作るときは、CREATE USER でユーザーを作成し、GRANT で「どのデータベースに」「何をしてよいか」を付ける、という二段階で進めます。WordPress 用であれば、そのサイトのデータベースだけに権限を絞った専用ユーザーを作り、root ユーザーは使わないのが基本です。この記事では、作成から権限の付与・確認・取り消しまでの SQL と、MySQL 8.0 以降で変わった点、WordPress に必要な権限の考え方、接続できないときの確認ポイントを説明します。

作業の前に確認すること

まず、使っているのが MySQL か MariaDB か、そのバージョンを確認します。ユーザー管理の SQL はほぼ共通ですが、認証方式など一部の動作が異なります。

mysql --version

管理者として接続する方法は環境によって異なります。Ubuntu などでパッケージから入れた場合、MySQL の root ユーザーはパスワードではなく OS のユーザーで認証する設定になっていることが多く、sudo mysql で接続します。パスワード認証の場合は mysql -u root -p で接続し、パスワードは対話入力にします。コマンドラインに -pパスワード と直接書くと、シェルの履歴やプロセス一覧に残るためです。

本番のデータベースで権限を変える前には、mysqldump などでバックアップを取っておきます。ユーザーの追加自体はデータを壊しませんが、既存ユーザーの権限やパスワードを変えると、WordPress が接続できなくなることがあります。

ユーザーを作成する

ユーザーは「ユーザー名」と「接続元ホスト」の組み合わせで一つのアカウントになります。

CREATE USER 'wp_example'@'localhost' IDENTIFIED BY 'your-strong-password';

'wp_example'：ユーザー名。サイトごとに分けると、どのサイトの接続か分かりやすくなります。
'localhost'：接続元。WordPress と MySQL が同じサーバーにあるなら localhost にします。
'your-strong-password'：パスワード。実際には、openssl rand -base64 24 などで生成した長いランダムな文字列を使います。

同じユーザー名でも、'wp_example'@'localhost' と 'wp_example'@'%'（どこからでも接続可）は別のアカウントです。パスワードも権限も別々に管理されるため、後で「パスワードを変えたのに接続できない」という混乱の原因になります。必要な接続元だけを作るようにしてください。

MySQL では、localhost を指定するとソケットファイル経由の接続を意味し、127.0.0.1 への TCP 接続とは扱いが異なる場合があります。WordPress の DB_HOST を 127.0.0.1 にしている場合は、アカウントのホスト部分もそれに合わせる必要があるか確認してください。

パスワードの強度を検査する仕組み（validate_password）が有効なサーバーでは、短いパスワードや単純なパスワードは「Your password does not satisfy the current policy requirements」というエラーで拒否されます。その場合は、より長いパスワードに変えます。

なお、WordPress の wp-config.php ではパスワードをシングルクォートで囲んで書くため、パスワードにシングルクォート（'）やバックスラッシュ（\）が含まれていると、書き方を誤って接続エラーになりがちです。生成した文字列にこれらが含まれる場合は作り直すと面倒がありません。

権限を付与する

権限は GRANT 権限 ON 対象 TO アカウント の形で付けます。対象は データベース名.* と書くと、そのデータベースのすべてのテーブルが対象になります。

CREATE DATABASE wp_example DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;

GRANT ALL PRIVILEGES ON wp_example.* TO 'wp_example'@'localhost';

ALL PRIVILEGES と書いていても、範囲は wp_example データベースの中だけです。ほかのデータベースや、ユーザー管理などのサーバー全体の操作はできません。避けたいのは次の二つです。

ON *.*：すべてのデータベースが対象になります。WordPress が乗っ取られたとき、同じサーバーのほかのサイトまで読まれてしまいます。
WITH GRANT OPTION：自分の権限をほかのユーザーに渡せるようになります。WordPress には不要です。

MySQL 8.0 以降の注意点

MySQL 5.7 までの解説では、GRANT ... IDENTIFIED BY 'パスワード' と書いてユーザー作成と権限付与を一度に行う例がよく見られます。MySQL 8.0 ではこの書き方は使えず、構文エラーになります。CREATE USER と GRANT を分けて実行してください。MariaDB では現在も使えますが、分けて書く方が両方で通じます。

また、GRANT や CREATE USER の後に FLUSH PRIVILEGES を実行する例も多いですが、これらの文は権限を即座に反映するため、通常は不要です。FLUSH PRIVILEGES が必要なのは、mysql.user などの権限テーブルを UPDATE で直接書き換えた場合です。権限テーブルの直接編集は誤りの元になるので、ALTER USER や GRANT を使ってください。

WordPress に必要な権限

WordPress の通常の動作（記事の表示・投稿・更新）に使うのは、主に SELECT・INSERT・UPDATE・DELETE です。ただし、WordPress 本体の更新やプラグインの有効化では、テーブルの作成や構造の変更が行われます。そのため、権限を絞る場合も次のような構成にするのが現実的です。

GRANT SELECT, INSERT, UPDATE, DELETE,
      CREATE, ALTER, INDEX, DROP,
      CREATE TEMPORARY TABLES, LOCK TABLES
  ON wp_example.* TO 'wp_example'@'localhost';

CREATE TEMPORARY TABLES と LOCK TABLES は、一部のプラグインやバックアップ処理で使われることがあります。権限を絞りすぎると、更新時に「CREATE command denied」のようなエラーが出たり、プラグインのテーブルが作られずに一部の機能が動かなかったりします。どこまで絞るかは、ステージング環境で WordPress 本体とプラグインの更新を試してから決めてください。

運用の手間を考えると、「そのサイトのデータベースに限った ALL PRIVILEGES」で十分と判断する場合も多いです。権限を細かく削るよりも、データベースをサイトごとに分けること、root を使わないこと、接続元を限定することの方が、守りとしての効果は大きいといえます。

付与した権限を確認する

設定後は、意図どおりの権限になっているかを確認します。

SHOW GRANTS FOR 'wp_example'@'localhost';

SELECT user, host, plugin FROM mysql.user WHERE user = 'wp_example';

SHOW GRANTS の結果に GRANT USAGE ON *.* という行が出ますが、これは「ログインはできるが、何の権限もない」という意味で、問題ありません。その下に wp_example.* への権限が並んでいれば正しく付与されています。

最後に、作ったユーザーで実際に接続してみます。

mysql -u wp_example -p wp_example -e "SHOW TABLES;"

権限の取り消し・パスワード変更・削除

不要になった権限は REVOKE で取り消します。

REVOKE DROP ON wp_example.* FROM 'wp_example'@'localhost';

パスワードの変更は ALTER USER を使います。変更したら、すぐに wp-config.php の DB_PASSWORD も書き換えます。順番が逆になると、その間サイトがデータベースに接続できません。

ALTER USER 'wp_example'@'localhost' IDENTIFIED BY 'your-new-strong-password';

サイトを閉じたときなど、ユーザー自体が不要になったら削除します。削除してもデータベースやテーブルは残ります。

DROP USER 'wp_example'@'localhost';

接続できないときの確認ポイント

WordPress で「データベース接続確立エラー」が出たり、mysql コマンドで「Access denied for user」と表示されたりする場合は、次の順に確認します。

ユーザー名とホストの組み合わせ：SELECT user, host FROM mysql.user; で、接続しようとしている組み合わせのアカウントが存在するかを確認します。DB_HOST が localhost なのに '%' のアカウントしかない、といった食い違いがよくあります。
パスワード：wp-config.php の値と一致しているか。前後の空白やクォートの閉じ忘れも確認します。
権限：SHOW GRANTS で、対象のデータベース名が正しく書かれているか。データベース名の綴り違いや、アンダースコアの有無の違いに注意します。
認証方式：MySQL 8.0 以降の既定の認証方式は caching_sha2_password です。古いクライアントやライブラリは対応していないことがあり、「authentication method unknown」のようなエラーになります。PHP 7.4 以降の標準的な環境では対応していますが、古い管理ツールなどで問題が出ることがあります（2026年10月現在）。従来の mysql_native_password は MySQL 8.4 で既定では無効になり、MySQL 9 系では削除されているため、古い方式に戻すのではなく、クライアント側を更新するのが基本です。

別のサーバーから接続する構成では、MySQL の bind-address やファイアウォールの設定も関係します。外部からの接続を許可する場合は、接続元を特定の IP に限定したアカウントを作り、通信の暗号化も検討してください。

まとめ

ユーザーは CREATE USER で作り、GRANT で権限を付ける。MySQL 8.0 以降は二つを分けて実行する。
アカウントは「ユーザー名＋接続元ホスト」の組で一つ。localhost と % は別物として管理する。
WordPress 用ユーザーには、そのサイトのデータベース（データベース名.*）だけに権限を付け、*.* や WITH GRANT OPTION は使わない。
権限を絞る場合も、更新やプラグインで使う CREATE・ALTER・INDEX・DROP などは残す。ステージングで更新を試してから決める。
GRANT の後の FLUSH PRIVILEGES は通常不要。設定後は SHOW GRANTS と実際の接続で確認する。