日本語を含むメールアドレスへの対応が次期WordPressで見送られた

つくば市のホームページ制作会社

WordPressの次のバージョンにあたる7.1のベータ3が7月22日に公開された。71件を超える修正が入った通常のベータ更新だが、告知の中に少し珍しい一文が混ざっていた。いったんコアに取り込まれていた、アルファベット以外の文字を含むメールアドレスへの対応が、7.1には入らないことになったという内容だ。

対象になっていたのは、@より前のローカル部分に日本語や各国の文字が入ったアドレスである。ドメイン側はPunycodeという変換の仕組みで以前から扱えていたが、ローカル部分は長く対象外で、WordPressの検証関数が不正なアドレスとして弾いていた。今回の変更では、データベースの文字コードがutf8mb4であればis_email()やsanitize_email()が非ASCIIのアドレスを受け付けるようになり、アドレスをローカル部とドメイン部に分けて扱えるWP_Email_Addressというクラスも加わっていた。元になったチケットが立てられたのは2015年で、11年越しで前に進んだ案件でもある。

取り込んだあとで外すという判断

その機能が、コアにマージされてから6週間ほどで外された。挙げられている理由は、Unicodeを受け入れることで確認しなければならない範囲が一気に広がることと、それに伴うセキュリティ面の影響だ。Unicodeには見た目がほとんど区別できない別の文字が数多くあり、ログイン用のアカウントや通知メールの宛先が絡む場所では、取り違えやなりすましの入口になりうる。公式の告知では、開発はコミュニティプラグインとして続け、互換性やセキュリティ、データの扱いをより広くテストしていくとされている。

日本の制作現場への直接の影響は、いまのところ小さい。国内で非ASCIIのメールアドレスを実際に運用している取引先はほとんど見かけないし、7.1に入らないのであれば当面の挙動も変わらない。気に留めておきたいのは、問い合わせフォームや会員登録の入力チェックを自前の正規表現で書いているサイトのほうだ。将来コア側が受け入れる文字の範囲が広がったとき、フォーム側だけが古い基準で弾き続ける、という食い違いが起きうる。プラグインとして先に試せる形になるのであれば、その前に手元で挙動を確かめておける。

もうひとつ、この話が示しているのは、メールアドレスの扱いがWordPress単体で完結しないことだ。仮にコア側が受け付けても、その先の送信サーバーやメール配信サービス、受け取る側のメールソフトがそろって対応していなければ、通知が届かないという形で問題が出る。ウェブ側だけを新しい仕様に合わせても意味がない領域で、慎重に進める判断そのものは理解しやすい。

11年動かなかった機能が入り、6週間で外れる。読んでいて印象に残るのはむしろ判断の速さのほうで、世界中のサイトが乗っている土台に何を入れるかという線引きが、機能の完成度とは別の基準で引かれていることがよく分かる。7.1そのものは8月19日の公開予定で、こちらは通常どおりの日程で進んでいる。

カメラとマイクの許可をブラウザに任せるHTMLの新要素

つくば市のホームページ制作会社

ウェブサイトでカメラやマイクを使う場面は、ここ数年で少しずつ増えてきました。オンライン相談の入口、動画で送るお問い合わせ、現場のスタッフが撮影してそのまま投稿する仕組みなど、業種を問わず出てきます。その手前に必ず挟まるのが、ブラウザが表示する「カメラの使用を許可しますか」という確認です。

Chrome 151が2026年7月28日に公開され、この確認の出し方そのものを見直す新しいHTML要素、usermedia要素が使えるようになりました。JavaScriptから許可を求めるのではなく、ブラウザが仲立ちする部品を押してもらう形に変わります。

スクリプトから許可を求める方式のつまずき

これまでカメラやマイクを使うには、JavaScriptでgetUserMediaという命令を呼び、その瞬間にブラウザが許可の確認を出す形が標準でした。書き方としては素直ですが、実際の現場では困りごとがついて回ります。

ひとつは、確認が出るタイミングを利用者が予想しにくいことです。ページを開いた直後に何の脈絡もなく確認が出れば、多くの人はとりあえず拒否します。もうひとつは、拒否したあとの復帰が難しいことです。いったん拒否すると次からは確認すら出ず、ブラウザの設定画面を自力で開いて権限を戻す必要があります。制作側からは、その設定画面への案内文を書き添えるくらいしか打つ手がありませんでした。

迷惑な確認を減らすため、ブラウザ側が自動的に確認を抑え込む挙動も広がっています。まっとうに作ったページが、その網に引っかかって何も起きないという事故も起こり得ます。

ボタンを包むだけの書き方

usermedia要素は、押してもらうボタンをこの要素で包むだけで使えます。中に置いたボタンの見た目はこれまでどおり自由に整えられ、押されたあとの段取りをブラウザが引き受けます。

結果の受け取りは、要素が発火する3種類の出来事を見張る形です。許可されたときのstream、失敗したときのerror、利用者が確認を閉じたときのcancelの3つで、映像や音声の本体はstreamから受け取ります。解像度やエコー除去といった希望は、押される前にsetConstraintsで指定しておきます。従来の書き方で必要だった成功と失敗の分岐や状態管理のコードは、かなり減らせます。

目に見えて変わるのは、確認が出る条件です。従来はスクリプトの都合で確認を出せましたが、この要素ではブラウザが用意した部品が実際に押されるまで確認は出ません。裏を返せば、勝手なタイミングで確認を出す作りが成立しなくなるということでもあり、利用者側から見た予測しやすさは上がります。

拒否されたあとに戻ってこられるかどうか

この要素の効き目がはっきり出ているのが、一度拒否されたあとの復帰です。Chromeの開発者向け情報によると、試験導入に参加したCiscoの計測では、従来の方式で復帰できた人がおよそ1割だったのに対し、新しい要素では6割を超えたとされています。Zoomでは撮影や録音の失敗が約47パーセント減り、Google Meetでは「マイクが動かない」という申告が約17パーセント減ったという数字も挙がっています。

理由は単純で、利用者が自分でボタンを押したという事実をブラウザが確実に把握できるからです。押した本人の意思がはっきりしているぶん、ブラウザは自動的な抑制を回さずに済み、拒否済みの状態からその場で復帰させる専用の流れを出せます。設定画面まで手順を案内しなくてよくなるのは、問い合わせ対応の手間という面でも小さくありません。

今すぐ全面的に置き換えるものではない

現時点で動くのはChrome 151以降で、他のブラウザはこれからです。仕様はW3Cのメディアキャプチャ拡張仕様に載っており、将来はカメラ用、マイク用といった用途別の要素も検討されています。

対応しているかどうかは、HTMLUserMediaElementという名前がブラウザ側に存在するかで判定できます。対応していないブラウザでは要素の中に書いた内容がそのまま表示されるので、中に従来のgetUserMediaを呼ぶボタンを置いておけば、ひとつの記述で両方の環境をまかなえます。新規に組むならこの入れ子の形から始めておくと、対応ブラウザが増えたときに書き直さずに済みます。

カメラやマイクを扱うページは、動くかどうかが問い合わせ件数に直結します。実装の難しさよりも、拒否したまま戻れなくなった利用者をどう救うかが実際の課題だった現場は多いはずで、そこにブラウザ側から手が入ったという意味で、頭の片隅に置いておく価値のある変化です。