Shopify×Vercel、Hydrogenフレームワークを再構築。マルチフレームワーク対応とAIエージェント導入
ShopifyとVercelが、ヘッドレスコマースフレームワーク「Hydrogen」の全面的な再構築に着手した。2026年7月30日にVercel Blogが発表した内容によると、新バージョンはオープンソース化され、Next.js以外のフレームワークでも動作するランタイム非依存型へと生まれ変わる。
この刷新により、開発者は型安全なAPIクライアントやカート状態管理をワンインポートで利用でき、ストアフロントの構築が大幅に効率化される。さらに「Standard Actions」と呼ばれるエージェント型コマース機能が追加され、AIが購入支援や在庫確認などを自律的に処理する仕組みが提供される。
Hydrogenとは何か？
HydrogenはShopifyが提供するヘッドレスコマース専用のフロントエンドフレームワークだ。従来のShopifyストアはテーマで構築するが、Hydrogenを使うとReactコンポーネントで自由にカスタマイズした店舗を開発し、Shopifyのバックエンドとシームレスに連携できる。つまり「自由な画面デザイン」と「Shopifyの堅牢なバックエンド」を両立させる架け橋と言ってよい。
これまでHydrogenはNext.jsに最適化された形で展開されていたため、開発者はReact/Next.jsのエコシステムに縛られていた。NuxtやSvelteなど別のフレームワークを使う場合は、独自にAPI連携や状態管理を実装する必要があり、それが導入障壁になっていた。
何が変わるのか？
今回の再構築では、Hydrogenの根本的な設計が刷新される。具体的には以下の3つの大きな変化がある。
この比較から分かる通り、新しいHydrogenではフレームワークの選択肢が広がり、面倒な共通処理はフレームワークが肩代わりしてくれる。結果として、開発者はビジネスロジックに集中できる。
オープンソース化とランタイム非依存
最大の変更点は、Hydrogenが完全オープンソースになり、ランタイムにも依存しなくなったことだ。旧バージョンは実質的にNext.jsアプリとして動作する設計だったが、新しいHydrogenは@shopify/hydrogenパッケージをブラウザ用JavaScriptで動作するように再実装し、@shopify/storefront-api-clientと共に利用する形になる。
これにより、開発者はNext.jsはもちろん、Nuxt、SvelteKit、あるいは純粋なViteアプリケーションなど、好みのフレームワーク上でHydrogenストアフロントを構築できる。Vercelの発表ブログでは「cart.query()やcart.lineItems()といったAPIをインポートするだけで、カートの操作や状態管理が完了する」と説明されており、従来のようにフレームワークごとに接着コードを書く手間が不要になる。
標準Actionsとエージェントコマース
もうひとつの目玉は「Standard Actions」の導入だ。これはAIエージェントがショッピング行動を自立支援するための統一インターフェースであり、店舗の様々な操作（検索、商品詳細の取得、カート追加、購入）をアクションとして定義する。
ユーザーが自然言語で要望を伝えると、AIエージェントが最適なアクションを選択して結果を返す。この仕組みを利用すれば、「オススメの夏用ジャケットを見せて」「先週買おうとした商品をカートに戻して」といった会話型の購買体験をストアフロントに組み込める。
Standard Actionsは、AIモデルが商品データや在庫情報にアクセスしやすい形で提供されるため、自前で複雑なAIパイプラインを構築する必要がない。ChatGPTやClaudeといった外部AIと統合する場合も、アクション定義を合わせるだけで済む設計だ。
なぜこのパートナーシップが重要なのか
ShopifyとVercelの連携強化は、単なるコードのリファクタリングではない。ここには二つの大きな戦略的意義があると考えられる。
一つは「Shopifyのバックエンドをあらゆるフロントエンドから利用可能にする」という方向性だ。ヘッドレスコマース市場では、各ブランドが独自のデザインシステムや技術スタックを持つことが当たり前になってきた。Hydrogenがランタイム非依存になることで、React以外のスタックを使っている企業も無理なくShopifyに移行できるようになる。
もう一つは「AI時代のコマース体験の標準化」だ。Standard Actionsは、AIエージェントが安全かつ一貫した方法で店舗操作を行えるプロトコルを定義する。これが広く採用されれば、どんなストアフロントでも同じ仕組みでAIアシスタントを動かせるようになるため、エコシステム全体のAI対応速度が上がる。
さらに、オープンソース化によってコミュニティの貢献が期待でき、Hydrogen自体の開発スピードも加速する。プラットフォームに閉じない設計は、長期的なベンダーロックインの回避にもつながる。
実務への影響と開発スピード
Vercel Blogの記事では、ファッションブランド「Paige」の事例が紹介されている。新しいHydrogenを採用した結果、それまで数か月かかっていた新機能の開発が1週間に短縮されたという。これは単にコード量が減っただけでなく、標準化されたAPIクライアントと状態管理によって、チームが細かい実装に悩まなくなり、ビジネスロジックの試行錯誤に集中できるようになった成果だ。
中小規模のECサイト運営者にとっては、これまで「ヘッドレス」と聞くだけで専門のReactエンジニアが必要だと思われていた壁が下がる。HydrogenがNuxtやSvelteでも動くため、社内のフロントエンドチームが使い慣れたフレームワークをそのまま活かせる。さらに型安全なクライアントが用意されているため、APIの仕様変更に伴う不具合もコンパイル時に検出しやすくなる。
パフォーマンス面でも、ランタイムの最適化が進んだことで、ストアフロントの表示速度が向上する。Vercelのエッジネットワークとの組み合わせにより、世界中のユーザーに高速な体験を提供できるのも大きな強みだ。
この記事のポイント
- Hydrogenがオープンソースかつランタイム非依存となり、Next.js以外のフレームワークでも動作する
- 型安全なAPIクライアントとカート状態管理が標準提供され、開発効率が飛躍的に向上する
- Standard Actionsによって、AIエージェントが自然言語でショッピングを支援する仕組みが組み込まれる
- ファッションブランド「Paige」では開発期間が数か月から1週間に短縮された事例が報告されている
- 中小規模のECサイトでも、ヘッドレスコマースの導入ハードルが大きく下がる
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
埋め込みチャットでNS_ERROR_DOM_COEP_FAILEDエラーが出た時の直し方
サイトに埋め込んだ Teams やその他のチャットウィジェットをクリックした時に NS_ERROR_DOM_COEP_FAILED と表示されて開けない場合、サーバーが返している COEP（Cross-Origin Embedder Policy）ヘッダーが原因だ。htaccess で Cross-Origin-Embedder-Policy を credentialless に変更するか、不要なヘッダーであれば削除することで解決する。
NS_ERROR_DOM_COEP_FAILEDとは何か
COEP は「Cross-Origin Embedder Policy」の略で、ページが他オリジン（別ドメイン）のリソースを読み込む際のセキュリティルールを定める HTTP レスポンスヘッダーだ。このヘッダーが require-corp に設定されていると、埋め込む側のリソースすべてに CORP（Cross-Origin Resource Policy）ヘッダーが付与されていることをブラウザが要求する。
Teams のチャットウィジェットをはじめ、多くのサードパーティ製ウィジェットは自社の配信サーバーから JavaScript や画像を読み込むが、それらのリソースに CORP ヘッダーが付与されていないことが多い。結果としてブラウザが読み込みをブロックし、NS_ERROR_DOM_COEP_FAILED というエラーをコンソールに出力する。
このエラーは Firefox や Chrome などのモダンブラウザで発生し、ウィジェットのボタンは表示されるがクリックしてもチャット画面が開かない、または読み込み中のまま固まるといった症状が出る。
COEPヘッダーを require-corp で返している
配信する JS や画像に CORP ヘッダーが付いていない
NS_ERROR_DOM_COEP_FAILED を出力しウィジェットが開かない
この図のとおり、自サイトのサーバー設定と外部ウィジェットの配信仕様が噛み合わず、ブラウザが安全側に倒して読み込みを拒否するのが根本的な原因だ。
自サイトにCOEPヘッダーが設定されているか確認する手順
まずは自サイトが実際に COEP ヘッダーを返しているかどうかを確認する。ブラウザの開発者ツールを使えば数分で特定できる。
Chrome や Firefox の開発者ツールでレスポンスヘッダーを確認する
サイトの任意のページを開き、F12 キーで開発者ツールを起動する。NetWork タブを開いてページを再読み込みし、先頭のドキュメントリクエスト（多くの場合はページURLそのもの）をクリックする。Response Headers セクションに Cross-Origin-Embedder-Policy という項目があれば、その値が現在の設定だ。
値が require-corp になっている場合、厳格な制限がかかっている状態で、これがエラーの直接原因になる。値が credentialless であればクロスオリジンの埋め込みは許可されているため、別の要因を探す必要がある。ヘッダー自体が存在しない場合は、COEP 以外の原因（CORS 設定やウィジェット側のスクリプトエラーなど）を疑う。
セキュリティプラグインやCDNが自動付与しているケース
WordPress サイトの場合、セキュリティ系プラグインが HTTP レスポンスヘッダーを自動で追加していることがある。また Cloudflare などの CDN サービスを経由していると、CDN 側のセキュリティ設定で COEP ヘッダーが付与されるケースもある。
該当しそうなプラグインを一つずつ無効化してヘッダーの変化を確認するか、CDN の管理画面で「ヘッダー設定」や「セキュリティヘッダー」といった項目をチェックすると原因を絞り込める。
htaccessでCOEPヘッダーを修正してエラーを解決する
原因が COEP ヘッダーの require-corp 設定にあると特定できたら、htaccess ファイルを編集して修正する。Apache サーバーを使っている国内レンタルサーバーの大半は htaccess による上書きが可能だ。
上記 STEP 3 で追記するコードは以下のとおりだ。htaccess の末尾にこのブロックを追加する。
<IfModule mod_headers.c>
Header set Cross-Origin-Embedder-Policy "credentialless"
</IfModule>この設定により、COEP ヘッダーが credentialless モードに切り替わる。credentialless はクロスオリジンのリソース読み込みを許可しつつ、認証情報（Cookie や HTTP 認証）を送信しないモードだ。Teams のチャットウィジェットは認証に Cookie を使わず独自のトークンで認証するため、credentialless モードでも問題なく動作する。
COEPヘッダーを完全に削除する方法
セキュリティ上の要件が特にないサイトであれば、COEP ヘッダー自体を削除する選択肢もある。以下のコードを htaccess に追記すればヘッダーが除去される。
<IfModule mod_headers.c>
Header unset Cross-Origin-Embedder-Policy
</IfModule>どちらの方法を選ぶかはサイトのセキュリティポリシー次第だ。COEP ヘッダーが元々セキュリティプラグインや CDN の自動設定で付与されていたのであれば、credentialless への変更が無難だ。手動で require-corp を指定していた場合は、その意図を再確認した上で削除または変更を判断する。
htaccess編集後に変更が反映されない場合の確認ポイント
ファイルをアップロードしてもヘッダーが変わらない場合、mod_headers モジュールがサーバーで有効になっていない可能性がある。また、CDN を経由しているサイトでは CDN のキャッシュをパージしないと変更がすぐに反映されない。WordPress のキャッシュプラグインを使っている場合も、プラグインの設定画面からキャッシュを全削除する。
変更後は必ず開発者ツールの NetWork タブでレスポンスヘッダーを再確認し、Cross-Origin-Embedder-Policy の値が credentialless に変わっているか、ヘッダー自体が消えているかを検証する。
htaccessが使えないサーバー環境での対処法
Nginx を使っている VPS やクラウド環境では htaccess が使えない。また一部の共用サーバーでは mod_headers が無効化されている場合もある。そうしたケースでの対処法をまとめる。
Nginxの場合
Nginx の設定ファイル（nginx.conf またはサイト単位の conf ファイル）の server ブロック内に以下の行を追加する。
add_header Cross-Origin-Embedder-Policy "credentialless";記述後は nginx -t で設定ファイルの文法チェックを行い、問題がなければ nginx -s reload で設定を再読み込みする。sudo 権限が必要な操作のため、レンタルサーバーではサポートに依頼する必要がある。
CDNやWAFでヘッダーを操作する
Cloudflare を使っている場合、ダッシュボードの「ルール」から「HTTP レスポンスヘッダーを変更」ルールを作成し、Cross-Origin-Embedder-Policy を credentialless に上書きできる。サーバー側の設定を一切触らずに済むため、htaccess 編集に不安がある場合の現実的な代替手段になる。
PHPでヘッダーを直接出力する
WordPress のテーマの functions.php に以下のコードを追加する方法もある。テーマ更新時に消えないよう、必ず子テーマを使う。
function my_set_coep_header() {
header('Cross-Origin-Embedder-Policy: credentialless');
}
add_action('send_headers', 'my_set_coep_header');この方法はサーバー設定に依存せず、WordPress の仕組みだけでヘッダーを制御できる。ただし、テーマの functions.php を編集するため、誤った記述があるとサイトが表示できなくなるリスクを伴う。編集前に必ず functions.php のバックアップを取る。
よくある質問
COEPエラーは特定のブラウザだけに出るのか
Firefox と Chrome 系ブラウザ（Chrome、Edge、Brave など）で発生する。Safari は COEP への対応が遅れていたが、Safari 17.2 以降はサポートしている。ブラウザによってエラーメッセージの文言は異なるが、根本原因は同じ COEP ヘッダーだ。
WordPressのセキュリティプラグインが原因になることはあるか
ある。HTTP セキュリティヘッダーを自動付与する機能を持つプラグイン（セキュリティ全般を扱うプラグインやヘッダー専用プラグイン）が、COEP を含むヘッダーを一括で設定しているケースは多い。プラグインの設定画面で「セキュリティヘッダー」や「HTTP ヘッダー」項目を探し、COEP の値を変更または無効化する。
credentiallessとrequire-corpの違いは何か
require-corp は埋め込み先の全リソースに CORP ヘッダーを必須とする厳格モードだ。一方 credentialless は CORP ヘッダーなしでもクロスオリジン読み込みを許可するが、認証情報（Cookie など）は送信しない。Teams チャットのような独自認証を使うウィジェットでは credentialless で十分動作する。
埋め込みウィジェット側の設定で回避できるか
原則として難しい。COEP エラーは「読み込む側（自サイト）」の制限によって発生するため、ウィジェット提供元（Teams など）の設定で回避する手段はない。ウィジェット提供元が自社の全配信リソースに CORP ヘッダーを付与すれば解決するが、それを個別の利用者が依頼して実現するのは現実的ではない。
htaccess編集に自信がない場合はどうすればよいか
サーバーの管理画面からファイルマネージャーで操作する場合は、編集前に必ず htaccess をコピーしてローカルに保存する。ミスでサイトが表示できなくなったら、そのバックアップをアップロードし直せば元に戻る。どうしても不安な場合は、CDN のヘッダー変更機能や PHP の functions.php で対応する方法を検討する。
この記事のポイント
- NS_ERROR_DOM_COEP_FAILED はサーバーの COEP ヘッダーが require-corp の時に発生する
- Teams など多くの外部ウィジェットは CORP ヘッダーを返さないためブロックされる
- htaccess で COEP を credentialless に変更するかヘッダーを削除すれば解決する
- Nginx 環境や CDN 経由の場合は別の設定手順が必要になる
- 修正後は必ず開発者ツールでレスポンスヘッダーが変わったか確認する
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
WordPress 7.1ベータ公開、ノート機能の大幅強化とCSS不要のレスポンシブ編集
WordPress 7.1のベータ版が7月下旬に公開され、編集体験に大きな改善が盛り込まれた。ノート機能がチームでの共同編集に本格対応し、CSSを一行も書かずに端末ごとの見た目を調整できるようになる。正式版はWordCamp USが開催期間中の8月19日にリリースされる予定だ。
今回の目玉は「ノート機能の強化」「レスポンシブスタイリング」「ホバーやフォーカス状態の視覚編集」の3本柱である。さらに、かねてから要望の多かったタブブロックとプレイリストブロックが追加され、管理画面の使い勝手も向上する。テスト段階のため本番環境への適用は避ける必要があるが、正式版までに知っておきたいポイントを詳しく見ていこう。
ノート機能がチーム編集ツールに進化
WordPress 6.9で導入されたノート機能は、ブロック単位の簡素なコメント機能だった。WordPress 7.1ではそれが一変し、複数人でのフィードバックに耐える本格的なツールへと変わる。
@メンションで担当者を直接指名
ノートの入力欄で「@」を打ち込むと、サイトの共同編集者の一覧が検索候補として表示される。目的のメンバーを選択すれば、その人を指名したノートが作成される。これにより「この修正は誰に伝えればいいのか」という迷いがなくなり、チーム内でのやり取りが格段にスムーズになる。
インラインノートで誤解を減らす
これまでのノートはブロック全体に対してしか付けられなかったため、長文の中で「ここを直してほしい」と書いても具体的な箇所が伝わりにくかった。WordPress 7.1では、文章内の特定の語句や文を選択し、その部分だけにノートを付けられる。該当部分はハイライト表示されるため、どの言葉に対する指摘なのかが一目でわかる。WP Beginnerの記事でも「『この部分を言い換えてほしい』という指示が、長い段落の中のどの単語を指すのかを推測する必要がなくなった」と評価されている。
このように、修正箇所と指示がピンポイントで結びつくため、レビューにかかる時間が劇的に短縮される。
その他の改善点
- 同じブロックに対して複数のノートスレッドを立てられる。議題ごとに会話を分離できる
- ノート本文に太字、斜体、コード、リンク、絵文字を使ったリッチテキストが可能
- 長いノートは初期状態で折りたたまれ、サイドバーが散らからない
CSS不要のビジュアルスタイリングが編集画面で完結
WordPress 7.1で最もインパクトが大きいのが、レスポンシブデザインのビジュアル操作である。これまではスマホやタブレット用の見た目を調整するには、CSSメディアクエリを手書きするか、テーマの設定に頼るしかなかった。今回のアップデートで、ブロックエディタ上でプレビューを切り替えながら、直感的にスタイルを設定できるようになる。
端末別のスタイル設定
エディタ上部のプレビュー切り替えで「デスクトップ」「タブレット」「モバイル」を選択すると、以降のブロックスタイルの操作はその画面サイズにだけ適用される。たとえばモバイル表示を選んで見出しのフォントサイズを小さくすれば、実際のスマホでの表示だけが変わる。デスクトップ表示には影響しない。
さらに、ブロック設定パネルには、現在どの画面サイズを編集中かを示す小さなバッジが表示される。意図しない画面用のスタイルを上書きしてしまうミスを防げる。エディタキャンバス自体も、プリセットの3サイズに縛られず、横幅をドラッグして任意の幅での表示をリアルタイムに確認できるようになった。テーマがtheme.jsonで独自のブレイクポイントを定義していれば、その値に合わせたプレビューも可能である。
CSSを書く必要がなくなり、カスタマイズのハードルが大きく下がる。サイト全体に一括適用したい場合は、グローバルスタイルで設定し、変更内容を選択的にグローバルへ反映させることもできる。
ホバーやフォーカス状態も視覚的に編集
ボタンなどのブロックには新たに「状態」ドロップダウンが追加され、ホバー時やフォーカス時、アクティブ時の見た目をエディタ上で直接編集できる。背景色や枠線、テキスト色を状態ごとに変え、その場でプレビュー確認できる。これまではほんの小さな変更であっても、カスタムCSSを追加せざるを得なかったが、今後は組み込みのデザインオプションで完結する。
待望のタブブロックとプレイリストブロック
これまでプラグインで実装していたタブ切り替えのレイアウトが、ついにコアブロックとして導入される。また、音声ファイルをまとめて再生できるプレイリストブロックも新登場する。
タブブロック
商品の仕様、よくある質問、料金プランの比較など、情報をパネルで区切って見せたい場面で重宝する。クリックでパネルを切り替える形式で、長いページを避けたい場合に効果的だ。既存のプラグインで作成したタブは、自動的にはコアブロックに変換されないため、移行の際は手作業が必要になる点に注意しておきたい。
プレイリストブロック
複数の音声ファイルを一つのプレイヤーにまとめ、タイトルやアーティスト名、カバーアート、波形グラフィックとともに表示できる。ミュージシャンや教会、教育機関、ポッドキャスト運営者にとっては、エピソードをまとめて提供するのに理想的なブロックだ。WordPressだけで手軽に音声配信の体裁を整えられるようになる。
加えて、既存のブロックにも多くの改善が加わっている。背景グラデーションと画像の同時適用、テキストシャドウのtheme.json対応、HTMLブロック内でのブロックネストの編集、装飾画像をスクリーンリーダーに読み上げさせない設定、ショートコードのEmbedブロックへの自動変換、ColumnsやGalleryからのグリッドレイアウト変換、アイコンブロックの回転・反転・アイコンセット登録機能など、日常的な制作を後押しするアップデートが多数含まれている。
画像編集とメディア処理の刷新
WordPressに組み込まれている画像編集機能が大幅に変わる。従来の狭いインライン操作から、専用のモーダルウィンドウでの本格的な編集へと進化した。
専用の画像編集モーダル
画像ブロックの「切り抜き」ボタンを押すと、フルスクリーンに近い編集画面が開く。自由トリミング、アスペクト比のプリセット、回転・反転、メタデータの編集を一か所で行える。カバーブロックにも対応しており、背景画像をその場でトリミングできる。本格的な写真編集ソフトには及ばないものの、サイト運営者が日常的に行う作業としては十分な機能を備えている。
ブラウザで画像を前処理しHEICにも対応
WordPress 7.1では、画像のリサイズや圧縮、サムネイル生成の大部分を、アップロード前にブラウザが処理する仕組みが導入される。これにより、サーバーの負荷が大幅に減り、低スペックなホスティング環境でもアップロードエラーが起きにくくなる。
さらに、iPhone標準の画像形式であるHEICをはじめ、UltraHDR、AVIF、WebPといった最新フォーマットへの対応が強化される。これまではサーバー側のImageMagickのバージョンに依存してHEICの変換が失敗することがあったが、ブラウザが変換を担うことで環境を選ばずに済むようになる。なお、ChromeとEdgeではフル機能が利用でき、Safariでは一部がサーバー処理に委ねられ、Firefoxでは従来通りサーバー側で処理される。
アップロードの堅牢性と細かな改善
アップロード中にネットワークが切断されても、キューが自動で一時停止し、再接続後に中断したところから再開される。一括アップロード時には進行状況が表示される。このほか、投稿に添付された画像を自動で引っ張ってくる動的ギャラリーモード、投稿専用の「添付画像」セクションがインサーターに追加され、メディアライブラリは自動読み込みの無限スクロールに対応する。日々のメディア管理のストレスを確実に減らす改良が詰め込まれている。
管理画面と編集体験の快適化
WordPress 7.1では、編集画面と管理画面の連携を改善する数々の小さな改良も施されている。
管理ツールバーが常に表示される
ブロックエディタやサイトエディタで編集しているときも、管理ツールバーが非表示にならず、画面上部に固定される。これにより、作業中でもサイトの管理メニューに素早くアクセスできる。ツールバーそのものもデザインが整理され、戻るボタンがわかりやすい山形アイコンに変更され、サイトアイコンと丸いプロフィールアバターが表示される。アイコン類も旧来のDashiconsからモダンなSVGに置き換わった。もちろん、集中執筆モードではツールバーが隠れるため、文章だけに集中したい場合も安心だ。
コマンドパレットとアイデンティティ設定の進化
コマンドパレット（Ctrl+K / Command+K）は、最近使ったコマンド、一致する候補、おすすめの3つに分類されるようになった。利用履歴はログインをまたいで保存されるため、よく使う操作に素早くたどり着ける。サイトエディタのサイドバーも、ユーザーが選んだ管理画面のカラースキームを反映するようになり、全体的な統一感が増した。
サイトのタイトル、キャッチフレーズ、ロゴ、サイトアイコンといった基本情報は「デザイン」内の「アイデンティティ」セクションにまとめられ、設定画面とテンプレートを行き来する手間がなくなった。
「あの日何を書いたか」ウィジェットとコメント親変更
ダッシュボードに新たに「On This Day」ウィジェットが追加され、過去の同じ日に公開した記事を表示してくれる。長く続けているブログにとっては、更新のネタを見つけるきっかけになる。また、コメント編集画面では「どのコメントへの返信か」を後から変更できるようになり、誤って違うスレッドにぶら下がったコメントを正しい位置に付け替えられる。対象は同一投稿内に限られるが、コメント管理の柔軟性が向上した。
見送られた機能と開発舞台裏
今回のリリースには含まれなかったが、注目すべき開発項目がいくつかある。
リアルタイム共同編集は次期以降に持ち越し
Googleドキュメントのような複数人同時編集は、WordPress 7.1では搭載が見送られた。Gutenbergプラグイン上では既に動作しており、複数人が同じ投稿を同時に編集できる段階にある。しかし、コアチームは協調編集データの保存方法や、完全な機能を提供するか基盤だけを先にリリースするかといった重要な判断を続けている。コミュニティによるテストも継続中で、時期尚早な投入によるデータ消失リスクを避けるための慎重な判断と見られている。WP Beginnerの記事でも「作業内容を失う共同編集機能ほど最悪なものはない」と指摘されており、この慎重さは妥当だろう。
Unicodeメールアドレス対応も見送り
日本語などの非ラテン文字を含むメールアドレスへの対応も、ベータテスト中に課題が見つかり延期された。互換性とセキュリティの検証をコミュニティプラグインで続けた後、改めてコアへの導入を目指す方針だ。
パフォーマンスと開発者向けの内部改善
投稿エディタは常にiframe内で動作するようになり、管理画面のCSSによる表示崩れを根本的に防ぐ。ただし、旧APIで作られたブロックは影響を受ける可能性があるため、プラグイン開発者はBlock API v3への移行が推奨される。アイコンAPIが公開され、プラグインやテーマが独自のSVGアイコンセットを登録・レンダリングできるようになった。そのほか、デザインシステムの成熟や、外部サービス接続の認証方式拡充など、長期的な安定性と拡張性を見据えた改良も進められている。
この記事のポイント
- ノート機能に@メンションとインラインノートが追加され、チームでのフィードバックが格段に正確になった
- レスポンシブスタイリングとホバー・フォーカス状態の編集がCSS不要で行える
- タブブロックとプレイリストブロックがコアに加わり、コンテンツ表現の幅が広がった
- 画像編集モーダルとブラウザベースの画像処理で、メディアまわりの操作性と安定性が向上
- 管理ツールバーの常時表示やアイデンティティ設定の集約など、管理画面の使い勝手が改善された
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験