WEBサイトWordPress 7.2（予定）は、開発者ノートによると、データベースのSQLモードNO_BACKSLASH_ESCAPESを、WordPressの接続でだけ外す ── サーバー全体の値と接続の値を分けて確認する13項目（2026年10月時点）
WordPress 7.2（予定）は、開発者ノートによると、データベースのSQLモードNO_BACKSLASH_ESCAPESを、WordPressの接続でだけ外す ── サーバー全体の値と接続の値を分けて確認する13項目（2026年10月時点）
目次
- 01 何が書いてあるか — WordPress 7.2は、データベースのSQLモードNO_BACKSLASH_ESCAPESを、WordPressの接続でだけ外す、と開発者ノートは書いている
- 02 なぜ・背景 — バックスラッシュを「特別な文字」と読むか「ただの文字」と読むかで、同じ命令が別の意味になる
- 03 この記事に出てくる用語
- 04 型別 — サーバーの値と、WordPressの接続の値を、別々に読む
- 05 明日、自社のサイトで確認できることチェックリスト
- 06 代替・他の選択肢 — 7.2の既定に従う以外に、4つの選び方がある
- 07 当サイトの場合 — この記事の13項目は、自分のサイトの台帳づくりから使う
- 08 このテーマは、ここまで
- 09 この記事のまとめ
01 何が書いてあるか — WordPress 7.2は、データベースのSQLモードNO_BACKSLASH_ESCAPESを、WordPressの接続でだけ外す、と開発者ノートは書いている
引用について
この記事の「" "」で囲んだ英語の文は、WordPressの開発者ノートと開発者向けの文書、WordPress.orgの告知、MariaDBの文書、WP-CLIの文書からの引用で、日本語訳は記事の筆者が付けたものである。各ページは2026年10月26日に開いて、本文を取り直して確かめた。コードの名前を囲む記号は、引用では省いた。
開発者ノートの日付と、書いてあること
WordPress本体の開発チームのブログ（Make WordPress Core）に、2026年10月9日付で、「NO_BACKSLASH_ESCAPES SQL mode is now turned off by default in WordPress 7.2」（訳: NO_BACKSLASH_ESCAPESというSQLモードは、WordPress 7.2で、既定で外される）という開発者ノートが載っている。書き手はMarin Atanasovで、ページの下には、この記事のレビュー者の名前もある。冒頭の2文は、次のとおりである。
"WordPress 7.2 adds NO_BACKSLASH_ESCAPES to the list of SQL modes that WordPress doesn’t support. WordPress already turns off some modes, such as STRICT_ALL_TABLES, TRADITIONAL and ANSI, when it connects to the database."
（訳: WordPress 7.2は、WordPressが対応しないSQLモードの一覧に、NO_BACKSLASH_ESCAPESを加える。WordPressは、データベースにつなぐときに、STRICT_ALL_TABLES、TRADITIONAL、ANSIなど、いくつかのモードをすでに外している。）
「SQLモード」とは、データベースが、命令の解釈の厳しさや、書き方の扱いを切り替える設定である（03章で説明する）。ノートの要点は、WordPressが前から外してきたモードの一覧に、NO_BACKSLASH_ESCAPESが1つ加わることである。
変わる範囲は、WordPressの接続だけ
ノートは、変わる場所を、次のように書く。
"This affects only the WordPress database connection. It doesn’t change the server’s global settings."
（訳: これが影響するのは、WordPressのデータベースの接続だけである。サーバーの全体の設定は、変えない。）
さらに、ノートは「Most sites won’t notice any difference.」（訳: ほとんどのサイトは、違いに気づかない。）とも書く。つまり、サーバーの設定を触る話ではなく、WordPressがデータベースへつなぐたびに、このモードを外してから使う話である。では、なぜこの記事が必要かというと、サーバーの値と、WordPressの接続で実際に効く値が、7.2から別の値になりうるからである。その見分け方のうち、管理画面と台帳でできる部分が、05章の13項目である。WordPressの接続の値そのものは、管理画面からは読めない（注意1）。
7.2の日付は、確かめられた範囲だけ書く
WordPress 7.2の公開日は、2026年10月6日付のリリースパーティーの予定の記事に、「December 8, 2026」（2026年12月8日）と書かれている。同じ日付は、10月20日付のBeta 1の告知にも書かれている。これらは予定である。Beta 1の告知は、使い方を、次のように書く。
"This beta release is intended for testing and development only."
（訳: このベータ版は、試験と開発のためだけのものである。）
本番のサイトに、Beta 1を入れてはいけない。確かめる場所は、本番の複製の試験環境である（05章の9番目、10番目）。
チケット#66185は、読めなかった
ノートは、詳細の参照先として、変更を管理する窓口（Trac）のチケット番号「#66185」を挙げている。このチケットのページを開こうとしたが、アクセスを断られ、本文は読めなかった。チケットの状態と、議論の中身は、確かめていない。この記事が根拠にするのは、ノートの本文と、開発者向けの文書である。
02 なぜ・背景 — バックスラッシュを「特別な文字」と読むか「ただの文字」と読むかで、同じ命令が別の意味になる
WordPressは、バックスラッシュで特殊な文字を包む
ノートは、この変更の理由を、次のように書く。
"WordPress uses the backslash character (\) to escape special characters in SQL queries. When NO_BACKSLASH_ESCAPES is on, MySQL reads the backslash as a normal character, not as an escape character. Queries with escaped values can then fail or return the wrong data."
（訳: WordPressは、SQLの問い合わせの中の特殊な文字を、バックスラッシュ（\）で逃がして書く。NO_BACKSLASH_ESCAPESが入っていると、MySQLは、バックスラッシュを、逃がす文字ではなく、ふつうの文字として読む。すると、逃がした値を含む問い合わせは、失敗したり、誤ったデータを返したりすることがある。）
MariaDBの文書は、このモードの役割を、次のように書く。
"Disables using the backslash character \ as an escape character within strings, making it equivalent to an ordinary character."
（訳: 文字列の中で、バックスラッシュ（\）を逃がす文字として使うことを無効にして、ふつうの文字と同じにする。）
MySQLとMariaDBで、どちらも同じ意味のモードである、と書かれているわけではない。MySQLの文書のページは、アクセスを断られて読めなかったので、この記事では、MariaDBの文書と、開発者ノートの範囲で書く。
ホスティングが、入れていることがある
ノートは、このモードが入っている理由を、環境の側に置く。
"Some hosts or server setups may turn this mode on. Before this change, sites on those servers could have hard-to-find database problems."
（訳: ホストやサーバーの構成によっては、このモードを入れていることがある。この変更の前は、そうしたサーバーの上のサイトに、見つけにくいデータベースの不具合が起きる可能性があった。）
サイトの持ち主が自分で入れたとは限らない。入れたのは、ホスティングの事業者かもしれない。だから、確かめる先は、サーバーの設定と、事業者への質問になる。
3つの場所を、分けて考える
SQLモードは、サーバー全体の値と、接続ごとの値の、2か所にある。MariaDBの文書は、接続ごとの値を、次のように書く。
"The session value only affects the current client, and can be changed by the client when required."
（訳: 接続ごとの値は、いまのクライアントだけに効き、クライアントが必要なときに変えられる。）
WordPress 7.2は、このうち接続ごとの値から、NO_BACKSLASH_ESCAPESを外す。サーバー全体の値には、触らない。図にすると、次の3つの場所になる。
表で比べる
| 観点 | モードが入っている接続 | 7.2のWordPressの接続 |
|---|---|---|
| バックスラッシュ | ふつうの文字として読む | 逃がす文字として読む |
| 逃がした値を含む問い合わせ | 失敗したり、誤ったデータを返したりすることがある | この点では、そうならない |
| 効く範囲 | サーバー全体、または、接続ごと | WordPressの接続だけ |
03 この記事に出てくる用語
SQLモード（sql_mode）
データベースが、命令の解釈の厳しさや、書き方の扱いを切り替える設定である。MariaDBの文書は、モードの並びを、「コンマで区切った文字列」と書く。
NO_BACKSLASH_ESCAPES
バックスラッシュを、逃がす文字として使わないモードである（02章）。
エスケープ（逃がす）
引用符のように、そのままでは命令の一部と読まれてしまう文字を、バックスラッシュなどを前に付けて、ただの文字として扱わせる書き方である。
グローバルとセッション
サーバー全体に効く値を「グローバル」、1回のつなぎ方（接続）だけに効く値を「セッション」と呼ぶ。MariaDBの文書は、全体の値を変えるには、権限が要ることを書いている。
"To set the global value, the SUPER privilege is required, and the change affects any clients that connect from that point on."
（訳: 全体の値を設定するには、SUPER権限が要り、その変更は、それ以降につなぐすべてのクライアントに効く。）
ドロップイン（db.php）
WordPressの標準の動きの一部を、差し替えるために置くファイルを、ドロップインと呼ぶ。ノートは、データベースにつなぐ前に読み込まれる置き場として、db.phpという名前を挙げる。この名前は、「残す」手順の中で使う（04章）。
フィルター（incompatible_sql_modes）
WordPressが、外すモードの一覧を、設定の前に渡してくる仕組みである。WordPressの開発者向けの文書は、この仕組みを、次のように説明する。
"Filters the list of incompatible SQL modes to exclude."
（訳: 外す、対応しないSQLモードの一覧を、絞り込む。）
用語
この記事で「接続」と書くのは、WordPressなどのプログラムが、データベースへつなぐたびに作る、1回のつなぎ方（セッション）のことである。サイトを訪れる人のブラウザの接続ではない。
04 型別 — サーバーの値と、WordPressの接続の値を、別々に読む
適用範囲: 7.2に上げたWordPressだけ
変わるのは、WordPress 7.2を使うサイトの、WordPressの接続である。WordPressを使っていないサイトや、7.2に上げていないサイトは、この変更の対象ではない。WordPressでない別のプログラムが、同じデータベースを使っていても、その接続は対象ではない。
値の読み方: 2つの命令を並べる
モードの値は、データベースの管理画面や、SQLの入力欄で、命令を実行して読む。MariaDBの文書は、接続の値と全体の値を、SELECT @@SQL_MODE, @@GLOBAL.SQL_MODE;という1つの命令で読む例を載せている。この記事では、見分けやすいように、2つの命令に分ける。
SELECT @@GLOBAL.sql_mode;
SELECT @@SESSION.sql_mode;1行目が、サーバー全体の値、2行目が、いまつないでいる接続の値である。結果は、モードの名前をコンマで並べた文字列で返る。この文字列の中に、NO_BACKSLASH_ESCAPESがあるかを見る。ここで見る接続は、管理画面や入力欄の接続であって、WordPressの接続そのものではない（次の注意）。
注意1: 管理画面で読んだ接続の値は、WordPressの値ではない
WordPressは、つなぐたびに、wpdb::set_sql_mode()という部品で、接続の値を直す。WordPressの開発者向けの文書は、この部品を、次のように説明する。
"Changes the current SQL mode, and ensures its WordPress compatibility."
（訳: いまのSQLモードを変え、WordPressとの互換性を保つ。）
したがって、データベースの管理画面で読んだ接続の値は、WordPressの接続の値とは別である。WordPressの接続で実際に効いている値は、WordPressから読むしかない。この記事では、そのやり方（プラグインの画面やコードの追加）は書かない。環境ごとに違い、確かめていないためである。
注意2: WP-CLIは、既定でモードを直してから実行する
WordPressを操作するコマンドの道具、WP-CLIのwp db queryは、既定で、WordPressが外すモードを外した接続で実行する、と文書は書く。サーバー本来の値を見るための指定も、文書にある。
"Run the query under the server’s own SQL modes instead of adapting them to be WordPress-compatible."
（訳: WordPressと互換になるよう直さず、サーバー自身のSQLモードのまま、問い合わせを実行する。）
この指定は、--skip-sql-mode-compatである。付けない結果と、付けた結果を並べると、WP-CLIが外したモードが分かる。ただし、WP-CLIが、7.2のNO_BACKSLASH_ESCAPESも外すかは、文書に書かれた例（NO_ZERO_DATE、STRICT_TRANS_TABLES）からは、確かめられない。
残したいとき: db.phpとフィルター
ノートは、このモードが本当に必要なサイトのために、残す書き方を示している。
"If your site really needs NO_BACKSLASH_ESCAPES, you can keep it with the existing incompatible_sql_modes filter"
（訳: サイトが、NO_BACKSLASH_ESCAPESを本当に必要とするなら、すでにあるincompatible_sql_modesのフィルターで、残せる。）
ノートが載せているコードは、次のとおりである（原文のまま）。
add_filter( 'incompatible_sql_modes', function ( $modes ) {
return array_diff( $modes, array( 'NO_BACKSLASH_ESCAPES' ) );
} );このフィルターが受け取る一覧は、WordPressが外すモードの一覧である。そこから「NO_BACKSLASH_ESCAPES」を取り除くので、このモードは外されず、残る。「取り除く」と書いてあるのに、残る意味になる点が、読み違えやすい。
落とし穴1: 置く場所は、プラグインでは遅い
"WordPress connects to the database before plugins load, so add this code in a db.php drop-in."
（訳: WordPressは、プラグインが読み込まれる前に、データベースにつなぐので、このコードは、db.phpのドロップインに足す。）
ノートは、通常のプラグインや、必ず読み込まれるプラグイン（must-use plugin）では、遅すぎる、とも書く。サイトにすでにincompatible_sql_modesの記述があっても、置く場所がプラグインなら、7.2でも効かない可能性がある。05章の6番目と7番目で、探す。
落とし穴2: 残すと、動かない場所があるかもしれない
ノートは、残す場合の注意も書いている。
"Please note that WordPress Core may not work correctly with this mode turned on."
（訳: このモードが入っていると、WordPress本体は、正しく動かないことがある、という点に注意してほしい。）
どの機能が、どう動かなくなるかは、ノートに書かれていない。残すと決めたサイトは、試験環境で、ログイン・保存・検索を動かして、確かめる（05章の10番目）。
落とし穴3: 同じデータベースを、別のプログラムも使うとき
1つのデータベースを、WordPressと、会員管理や予約の別のプログラムが、共用していることがある。7.2の変更は、WordPressの接続だけを変えるので、同じデータが、プログラムごとに、違う規則で読み書きされる。どの組み合わせで食い違うかは、この記事では確かめていない。だから、確かめる項目にする（05章の2番目）。
注意
サーバー全体のSQLモードを、確かめずに変えてはいけない。同じサーバーに、ほかのサイトやプログラムが同居していると、その全部に影響する。変更は、事業者と、同居するプログラムの担当者に確かめてから行う。
05 明日、自社のサイトで確認できることチェックリスト
以下は、担当サイトのSQLモードを確かめ、WordPress 7.2に上げる前の準備をするための13項目である。1〜2番目は台帳づくり、3〜8番目は値と上書きの確認、9〜11番目は試験環境、12〜13番目は記録と判断である。1項目は5分以内でできる。3番目と4番目は、データベースを触る権限が要る。権限がなければ、事業者に頼む文を書く。チェックの状態は、ブラウザに保存され、サーバーには送られない。
- 担当サイトのうち、WordPressを使うサイトを選び、サイト名・ホスティング名・データベースの種類（MySQLかMariaDB）・版を、表に1行ずつ書き出す
- 書き出したサイトのそれぞれで、同じデータベースを使うWordPress以外のプログラム（会員管理・予約・集計など）があるかを、制作会社か事業者に聞いて、「有・無・不明」で書く
- データベースの管理画面かSQLの入力欄で、SELECT @@GLOBAL.sql_modeを実行し、結果にNO_BACKSLASH_ESCAPESが含まれるかを、「有・無」で書く
- 同じ画面で、SELECT @@SESSION.sql_modeを実行し、3番目の結果と並べて、違うモードの数を書く（これは管理画面の接続の値で、WordPressの接続の値ではない。WordPressの接続の値は、管理画面からは読めない）
- WP-CLIが使えるサイトでは、wp db queryでSELECT @@SESSION.sql_modeを、そのまま実行した結果と、--skip-sql-mode-compatを付けた結果を、並べて書く。使えないサイトは「使えない」と書く
- サイトのwp-contentフォルダの直下に、db.phpがあるかを確かめ、あれば開いて、incompatible_sql_modesを含む行の数を数える
- 使っているテーマとプラグインのフォルダを、incompatible_sql_modesという名前で検索して、見つかったファイルの数を書く
- ホスティングの管理画面で、SQLモードの項目があるかを見て、あれば現在の値を書き写し、なければ事業者への質問を1行で書く
- 7.2の試験環境を、本番の複製から作る担当者と日付を書く。Beta 1は本番に入れない、と書き添える
- 試験環境で、管理画面へのログイン、記事の保存（バックスラッシュを含む文字列を1つ入れる）、サイト内の検索を、各1回行い、画面にエラーが出たかを「有・無」で書く
- 試験環境のエラーログの直近1日を開き、「SQL」か「syntax」を含む行の数を数える
- 3番目、4番目、6番目、10番目の結果を、日付と担当者の名前を付けて、台帳の1行に書く
- NO_BACKSLASH_ESCAPESが入っていたサイトごとに、「7.2の既定に従う」か「db.phpで残す」かを、理由と担当者の名前を付けて、1行で書く
1番目の版の書き出しでは、WordPress.orgの「必要な環境」のページが、勧める環境を、次のように書く。
"MariaDB version 10.11 or greater OR MySQL version 8.0 or greater."
（訳: MariaDBの10.11以上、またはMySQLの8.0以上。）
同じページは、古い環境（MySQL 5.5.5以上など）でも動くが、公式のサポートが終わっていて、サイトが脆弱性にさらされるおそれがある、とも書く。自分のデータベースの版が、この線より古いかを、1番目の表に書き込む。
11番目のエラーログは、WordPressの設定で、記録を有効にしてあるときに読める。開発者向けの文書は、記録の設定を、次のように説明する。
"WP_DEBUG_LOG is a companion to WP_DEBUG that causes all errors to also be saved to a debug.log log file."
（訳: WP_DEBUG_LOGは、WP_DEBUGの相棒で、すべてのエラーを、debug.logというログのファイルにも保存させる。）
この設定を本番で有効にするかは、事業者や制作会社に確かめてから決める。試験環境で有効にすれば、足りる。
9番目の試験環境で、本番と見た目や応答が違わないかを、ページごとに自動で比べたいときは、🔧 WEBサイトの状況チェック・比較ツールがある。テスト用のサイトと本番の違いを、ページごとに比べる道具である（要ログインのツール）。管理画面の中まで比べられるかは、確かめていない。
画面の崩れを見た目で比べたいときは、🔧 WEBサイトのスクリーンショット、まとめて撮っちゃおツールが使える。データベースの値そのものは、写真には写らないので、3番目から5番目は、SQLの結果で確かめる。
実務のヒント
3番目と4番目の結果は、そのまま貼り付けず、「NO_BACKSLASH_ESCAPESの有無」だけを台帳に書く。モードの文字列には、設定の方針が出るので、社外の共有資料には貼らないほうがよい。
06 代替・他の選択肢 — 7.2の既定に従う以外に、4つの選び方がある
選び方を表にする
表の「出典」の列は、書かれている範囲を示す。「筆者の整理」とあるものは、記事の筆者の考えである。
| 選び方 | できること | 限界 | 出典 |
|---|---|---|---|
| 7.2の既定に従う | WordPressの接続で、このモードが外される | 同じデータベースを使う別のプログラムには、効かない | 開発者ノート |
| db.phpで残す | WordPressの接続でも、このモードを残せる | WordPress本体が、正しく動かないことがある | 開発者ノート |
| サーバー全体の値を変える | 以降につなぐ全部の接続に、効く | SUPER権限が要る。同居するプログラムにも、効く | MariaDBの文書 |
| 7.2に上げる日を遅らせる | 確かめる時間を取る | Beta 1は本番では使えない。公開日は予定 | 告知・予定の記事 |
| データベースを分ける | WordPressと別のプログラムを、別のデータベースにする | 移す手間と費用が出る | 筆者の整理 |
多くのサイトは、何もしないで済む
ノートは、「Most sites won’t notice any difference.」と書く。サーバー全体にも、接続の設定にも、このモードが入っていないサイトは、この変更で、動きが変わらないと考えられる。05章の3番目で、NO_BACKSLASH_ESCAPESが「無」だったサイトは、値と日付を記録して終えてよい。残りの作業は、「有」だったサイトに絞れる。
「有」だったときの順序
「有」だったサイトは、まず、同じデータベースを使う別のプログラムがあるかを確かめる（05章の2番目）。ないなら、7.2の試験環境で、WordPressの動きを見る。あるなら、そのプログラムの担当者に、このモードが要るかを聞く。
07 当サイトの場合 — この記事の13項目は、自分のサイトの台帳づくりから使う
この記事の使い方
この記事の13項目は、担当サイトの台帳（サイト名・ホスティング・データベースの種類と版）を作るところから始める。05章は、WordPressを使うサイトを担当する人が、そのまま台帳に写して使える形で書いた。
本番のデータベースを書き換える作業を、先に試験で確かめる規律は、当サイトのブログ記事「本番DBを1秒で書き換えた日 — WEBディレクターが本番DB恐怖から解放される「8点セット」監査規律」に書いた。この記事の05章の流れ（試験環境で先に動かす）も、同じ考え方である。
確かめていないこと
- 7.2の試験環境での、実際の動き — この記事のために、7.2を動かしていない
- チケット#66185 — アクセスを断られ、本文を確かめていない
- MySQLの文書 — アクセスを断られ、読めなかった。MariaDBの文書の範囲で書いた
- WP-CLIが、7.2のNO_BACKSLASH_ESCAPESも外すか — 文書に書かれていない
- 05章の10番目の、保存と検索の試し方 — 筆者の整理で、公式の手順ではない
- db.phpの置き場（wp-contentの直下） — 開発者ノートには、場所の書き方がない。一般的な構成にもとづく、筆者の整理である
08 このテーマは、ここまで
2026年10月6日 — 7.2の予定の記事
リリースパーティーの予定の記事が、WordPress 7.2の公開日を2026年12月8日と書いた。ベータの予定は、Beta 1が10月20日、Beta 2が10月27日、と並んでいる（予定の記事の表から）。
2026年10月9日 — 開発者ノート
NO_BACKSLASH_ESCAPESを、WordPressが対応しないSQLモードの一覧に加える、と開発者ノートが書いた。
2026年10月20日 — Beta 1
7.2 Beta 1が公開され、告知が、試験と開発のためだけの版だと書いた。
これから
この記事は、2026年10月26日に、10の出典のうち、読めた9ページを確かめた時点のものである。ベータ版の内容は、最終版までに変わりうる。変わったときや、チケットの状態が確かめられたときは、日付つきで、この記事に追記する。
現在の貴方のIPアドレス
このサイトで書いている人
