Yoast SEOが原因でWordPress 7.0の編集画面が読み込めない時の対処
WordPress 7.0 の編集画面で、改訂（リビジョン）を視覚的に比較できる新機能が使えなくなったり、iFrame 版エディターの読み込みに問題が出るケースがある。これは、Yoast SEO のクラシックメタボックスが存在すると、WordPress 7.0 が新機能を意図的に無効化する仕様になっているためだ。Yoast SEO の設定を残したまま問題を回避したい場合は、該当の投稿タイプに対して Yoast SEO のメタボックスを設定からオフにすればよい。
なぜ Yoast SEO が有効だと WordPress 7.0 の新エディター機能が使えなくなるのか
WordPress 7.0 では、ブロックエディターが iFrame 版に移行し、改訂の比較画面がこれまでより直感的な UI に変更された。ところが、Yoast SEO に限らず、ひとつでもクラシックメタボックスが有効な状態だと、WordPress はこれらの新機能を自動的にオフにして旧来の改訂画面にフォールバックする。これは WordPress の意図的な挙動であり、Yoast SEO 単体のバグや不具合ではない。
クラシックメタボックス経由で保存された値（SEO タイトルやメタディスクリプションなど）は、現状の仕組みでは改訂を復元する際に正しく戻せない。そのため、互換性を保証できないメタボックスがある場合は、改訂のビジュアル比較のような高度な機能をまるごと制限する方針がとられている。
全メタボックスをコードで削除する対処がおすすめできない理由
一部のユーザーは do_meta_boxes フックを使って投稿画面からメタボックスをすべて除去するコードを導入しているが、この方法には大きな副作用がある。公開ボックスだけを残して他の全メタボックスを削除してしまうため、Yoast SEO の SEO 設定が編集画面から消えるだけでなく、入力した値が保存されなくなる。結果として、検索エンジン向けの重要な情報が失われてしまう。
さらに、他のプラグインが提供するメタボックスも同時に削除されるため、カスタムフィールドや追加の設定パネルが一斉に使えなくなり、サイトの運用に支障をきたす可能性が高い。
Yoast SEO の SEO 設定を残したまま問題を解決する手順
Yoast SEO の開発チームは、特定の投稿タイプでのみ SEO コントロールを無効にする標準的な方法を用意している。この手順を使えば、他の投稿タイプには影響を与えず、該当の編集画面でのみ Yoast SEO メタボックスを非表示にできる。
ただし、現時点ではメタボックスを無効にすると、Yoast SEO の SEO タイトルやメタディスクリプションといった設定欄そのものが編集画面から消える点に注意が必要だ。編集画面のサイドバーにある Yoast SEO のパネルは、内部でメタボックスに依存しているため、メタボックスをオフにするとサイドバーも機能しなくなる。
この設定変更は該当の投稿タイプにのみ適用され、他の投稿タイプでは引き続き Yoast SEO の全機能を利用できる。もし WordPress 7.0 の新エディター機能をどうしても優先したい場合の現実的な手段といえる。
メタボックスを非表示にした後、SEO 設定はどこで操作するのか
この問題について Yoast チームは、現在メタボックスに依存している構造を刷新する作業を進めていると明かしている。将来的には、メタボックスをオフにしてもサイドバーから SEO 設定を操作できるようになる見込みだが、現時点では具体的な対応時期は公表されていない。
また、WordPress 7.1 で導入が検討されているリアルタイム共同編集機能への対応についても、Yoast チームは前向きな姿勢を示している。しかし、多数のアドオンが複雑に連携するエコシステム全体との互換性を保つ必要があるため、拙速なリリースは避け、慎重に開発を進めている段階だ。
一時的な回避策としてメタボックスを残しつつ運用するには
SEO 設定を引き続き編集画面で操作したい場合、現時点では Yoast SEO のメタボックスを有効にしたまま、WordPress 7.0 の新改訂機能を使わずに従来の改訂画面で作業を続けることになる。これは不具合ではなく WordPress の設計上の制限であるため、Yoast SEO 側のアップデートを待つのが最も安全な対応といえる。
よくある質問
Yoast SEO 以外のプラグインでも同じ現象は起きるのか
起きる。クラシックメタボックスを提供しているプラグインであれば、どのプラグインでも同様の理由で WordPress 7.0 の新エディター機能が制限される。特定のプラグインに限った問題ではない。
設定をオフにした投稿タイプの SEO データは消えてしまうのか
保存済みの SEO タイトルやメタディスクリプションなどのデータが削除されることはない。設定を再度オンにすれば、以前のデータはそのまま復帰する。
コードで特定のメタボックスだけを削除することは可能か
技術的には可能だが、公式に推奨されている方法ではない。Yoast SEO の内部構造に依存するため、アップデートで動作しなくなるリスクが高い。どうしてもコードで対処する場合は、上書きした設定が保存されなくなる副作用を十分に理解したうえで行う必要がある。
この問題は Yoast SEO のアップデートで解決されるのか
Yoast チームはメタボックスへの依存を解消する改修を進めている。時期は未定だが、いずれはメタボックスを無効にしてもサイドバーから全機能を利用できるようになる予定だ。
この問題は WordPress 6.7 以前のバージョンでも発生するのか
発生しない。WordPress 7.0 で新たに導入された仕様であり、6.7 以前のバージョンではクラシックメタボックスが存在していても改訂機能が制限されることはない。
この記事のポイント
- WordPress 7.0 で Yoast SEO のメタボックスが原因となり新エディター機能が制限されるのは、WordPress の意図的な仕様である
- 全メタボックスをコードで削除する対処は SEO 設定の消失を招くため推奨されない
- Yoast SEO の設定画面から特定の投稿タイプの SEO コントロールをオフにすることで問題を回避できる
- メタボックスをオフにすると SEO 設定欄そのものが使えなくなる点に注意が必要
- Yoast チームはメタボックス依存の解消を進めており、将来的には問題が根本的に改善される見込み
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
CSS Gap装飾とrandom()関数、select要素のサイズ制御の最新情報
2026年6月末、CSS-Tricksの定期コラム「What’s !important」第14回が更新された。ギャップ装飾、random()関数、select要素のサイズ制御、モダンテーマ構築など、今後のWeb制作に直結するトピックが盛り込まれている。
ブラウザの安定版に大きな機能追加がなかった時期にも関わらず、開発者コミュニティの実験や標準化の進展は目を見張るものがある。本記事では、これらの最新情報を実務の視点で整理し、各機能の具体的な活用法を示す。
ギャップ装飾とランダム関数 ー 隙間を彩るCSSの新表現
CSS Gap装飾でグリッドの隙間をデザインする
FlexboxやGridレイアウトでおなじみのgapプロパティは、要素間に一定の間隔を生み出す。これまではその隙間自体を装飾する手段がなかったが、CSS Gap Decorationの概念によって新たな表現が可能になった。Temani Afif氏がMaster.devで公開した記事では、gap部分に背景色やボーダー、画像を配置する方法が詳しく解説されている。
上記の例では、flexコンテナに背景色を設定することで、gapが作り出すスペースに色が適用されている。Temani Afif氏の記事では、疑似要素やボーダーを用いて、より複雑な装飾を実現する手法が紹介されており、実務での利用価値が高い。
CSS random()がもたらすランダムな表現
CSSのrandom()関数は、スタイルシートに乱数を導入する試験的な機能だ。現時点ではSafariのみが対応しており、他のブラウザでは動作しない。Polypaneのブログでは、この関数を活用した多彩な実験が公開されている。
Polypaneのデモでは、桜の花びらが舞い散るアニメーションやポラロイド写真の不揃いなスタックなどが実装されており、random()の実用性を感じさせる。ブラウザの対応が進めば、よりナチュラルなUI演出に活用されるだろう。
フォーム要素の可変サイズと動的テーマ構築
field-sizing: contentでselectの幅を動的に調整
Manuel Matuzović氏の記事で取り上げられたfield-sizing: contentは、フォームの見た目を柔軟にする新しいCSSプロパティだ。特に<select>要素に適用すると、選択された<option>のテキスト幅に合わせて自動的にサイズが変わる。Firefox 152のリリースにより、この機能はBaselineに加わり、主要ブラウザで使用可能になった。
なお、size属性を併用してスクロール可能なリストボックスにした場合、field-sizing: contentがsizeを上書きし、すべてのオプションを表示するようになる点には注意が必要だ。
モダンCSSテーマ構築の新たなスタンダード
GoogleのUna Kravets氏は、light-dark()関数やcontrast-color()関数、@property、@container style()を組み合わせた新しいテーマ構築手法を解説した。これらの機能はいずれもBaselineに到達しており、モダンブラウザで広く利用できる。
見出しテキスト
本文のテキストがここに入ります。背景は白、テキストは濃い色。
見出しテキスト
本文のテキストがここに入ります。背景は暗色、テキストは明るい色。
contrast-color()を用いれば、背景色に応じて最適な文字色を自動選択でき、アクセシビリティを確保しつつテーマ構築が容易になる。Una氏の記事は、これらの機能を組み合わせた実装パターンとして参考になる。
プラットフォームの多様性を受け入れたウェブデザイン
Bramus氏がブログで提唱した「ウェブサイトはすべてのプラットフォームで同一に動作する必要はない」という考え方は、レスポンシブデザインを超えた新たな視点だ。入力デバイスの違いや、OSごとのAPIの特性を無理に統一せず、それぞれに適した体験を提供することが重要だと説く。
入力モダリティの多様性に対応する
デスクトップではマウスとキーボード、モバイルではタッチが主要な入力手段だが、ユーザーはスタイラスやゲームパッド、音声入力を併用することもある。すべての操作を全デバイスで同一に再現しようとすると、かえって使い勝手が損なわれるケースがある。Bramus氏は、プラットフォーム固有のインタラクションを許容することで、より自然な操作感を実現できると指摘している。
プラットフォーム依存のAPIと設計
同氏は具体例として、interest invokers（興味を示すUI）やoverscroll actions（スクロールオーバー時の挙動）、Document Picture-in-Picture APIなどを挙げた。これらはOSやブラウザによってふるまいが異なるのが自然であり、無理にクロスプラットフォームで統一するよりも、各環境での最適化を優先すべきだという。
この考え方は、Webアプリの設計においても、無理に同一のUIを強制するのではなく、各環境が持つ強みを活かしたコンテキスト適応の重要性を示している。
クリエイティブな実験とコミュニティの熱
CSSの進化は技術仕様だけでなく、開発者コミュニティの創造的な取り組みによっても加速している。今回の!important #14では、いくつかの目を引くプロジェクトとイベントが紹介された。
CSS QuakeとHyperblam ー コードで遊ぶ
Layoutitが公開したCSS Quakeは、1996年の名作FPSゲーム「Quake」をCSSで再現したプロジェクトだ。PolyCSSを活用し、HTMLとCSSだけで3Dグラフィックス風の表現を実現している。この流れは、先日話題になったCSS DOOMに続くもので、CSSの表現力の高さを改めて示している。
また、Heydon Pickering氏が制作したHyperblamは、HTMLのWeb Componentsを用いて音楽を作るというユニークな試みだ。JavaScriptを一切使わず、HTMLタグだけでWeb Audio APIを操作する。CSSとの直接的な関係は薄いが、ウェブ技術の可能性を広げる実験として注目される。
Web Engines Hackfest 2026の熱気
6月にスペインのガリシア地方で開催されたWeb Engines Hackfestでは、ブラウザエンジンやウェブ標準の未来について活発な議論が交わされた。CSS-Tricksの!important #14では、参加者であるMarina Aísa氏のレポートが紹介されており、初日のハイキングから始まり、二日間にわたるトークやクライミング、アクセシビリティ改善に向けたディスカッションの様子が伝えられている。
こうした草の根の開発者会議は、標準仕様の策定やブラウザ実装に直接影響を与える場でもある。Marina Aísa氏のノートは、今後のWeb制作に携わる者にとって貴重な情報源となるだろう。
この記事のポイント
- CSS Gap装飾は、gapプロパティで生じた隙間に背景色やボーダーを適用し、レイアウトに新たなアクセントを加えられる
- random()関数はSafariのみの対応だが、ランダムな表現を実現する強力なツールであり、今後の普及が期待される
- field-sizing: contentにより、select要素の幅を選択肢に応じて動的に変更可能。すでにBaseline入りしており実務利用が進む
- light-dark()やcontrast-color()、@container style()を組み合わせたテーマ構築は、アクセシビリティと効率を両立する
- プラットフォームごとに異なる操作体系やAPIを尊重し、同一性ではなく最適性を追求する設計が重要視されている
- CSS QuakeやHyperblamといった遊び心のあるプロジェクトは、技術の可能性を広げ、コミュニティの活力を象徴している
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
WordPressのAllowed memory size exhaustedエラーの原因と直し方
WordPressの「Allowed memory size exhausted」エラーは、サーバーに十分な物理メモリがあっても発生する。64GBの専用サーバーで起こるのは、PHPのメモリ上限設定が実際の要求量を下回っているか、特定のプラグインやテーマがバグで際限なくメモリを消費し続けているからだ。まずは設定値の引き上げを試み、それで直らなければログから原因箇所を特定し対処する。
十分な物理メモリがあるのにエラーが起こる仕組み
多くのレンタルサーバーはPHPのmemory_limitを128MBや256MBに設定している。WordPress本体や軽量なプラグインだけであればこの値で動作するが、WooCommerceの大規模ショップやページビルダー、画像処理、バックアップ系の処理が走ると一瞬で上限を突破する。コンソールに表示される「PHP Fatal error」の文言は、まさにその設定上限を突破したという意味だ。
さらに問題をややこしくしているのが、専用サーバーやVPSと「PHPの設定」の関係だ。64GBの物理メモリを搭載していても、PHPが使えるメモリ上限はOS全体の値ではなく、あくまでphp.iniやwp-config.phpなどで個別に定義された数値が優先される。ハードウェアとソフトウェアの上限は別物だと理解しておく必要がある。
具体的なメモリ上限の引き上げ手順
最も確実で直接的な方法はwp-config.phpファイルに一行追記することだ。FTPソフトやサーバーのファイルマネージャーでWordPressをインストールしたルートディレクトリにあるwp-config.phpを開き、次のコードを追記する。記述する場所は「/* 編集が必要なのはここまでです ! WordPress でブログをお楽しみください。 */」という行の直前が望ましい。
/** Sets up WordPress vars and included files. */
require_once(ABSPATH . 'wp-settings.php');define('WP_MEMORY_LIMIT', '512M');
/** Sets up WordPress vars and included files. */
require_once(ABSPATH . 'wp-settings.php');ここでは512MBを指定している。256MBで発生したエラーへの対応としては、まず256MBの2倍にあたる512MBを設定するのがセオリーだ。どうしても足りなければ1024M（1GB）や2048M（2GB）といった思い切った値も試して問題ないが、上限を上げすぎるとプログラムの暴走時にサーバー全体が重くなるリスクもある点は覚えておきたい。
サーバー側のphp.iniや.htaccessで設定を上書きする
共用サーバーではwp-config.phpへの追記だけで解決するケースがほとんどだが、VPSや専用サーバーではもっと根本の設定を見直したほうがいい。php.iniファイルを直接編集できる環境なら、memory_limit = 512Mと指定する。編集権限がない場合は.htaccessにphp_value memory_limit 512Mを追記する方法もあるが、最近のPHPハンドラではこの形式が無効化されている場合がある。
メモリ上限を上げても直らない時の根本原因特定
メモリ上限を1GBなど潤沢な値に変更してもなお同じエラーが出るなら、特定のプラグインかテーマが無限ループやメモリリークを引き起こしている可能性が高い。質問の事例のように「worker」プラグイン（管理用バックアップツールの類）が409MBものメモリ割り当てに失敗しているなら、それはプラグインが実質的に処理不可能な大規模データを扱っているか、プラグイン自体のバグだ。
管理画面に入れなくても全プラグインを安全に止める方法
エラーが深刻でWordPress管理画面にアクセスできない時は、FTPやSSHで/wp-content/plugins/ディレクトリのフォルダ名を一時的に変更する。例えば「plugins」を「plugins_deactivate」にリネームすると、全プラグインが強制停止されて管理画面にアクセスできる状態に戻せる。エラーがこのタイミングで消えたのなら、停止したプラグイン群に原因がある。
/wp-content/へ移動するエラーログに記録された具体的なファイル名を手がかりにする
エラーログには「/wp-content/plugins/worker/src/MWP/Http/JsonResponse.php on line 21」のように、エラーを起こしているファイルと行番号が出力される。これはまさに問題のプラグインの内部コードだ。この情報を元に該当プラグインだけを停止し、それでも状況が変わらなければそのプラグインの公式サポートに報告するか、代替のプラグインを検討する。
またWordPressには「サイトヘルス」機能が標準搭載されており、管理画面にアクセスできれば「ツール」→「サイトヘルス」→「情報」タブ内でメモリ上限の現在値が確認できる。FTPで原因プラグインを停止させたら、ここで上限値が意図した通りに変更されているかも併せてチェックしておくと確実だ。
よくある質問
256MBで運用していたが、なぜ急にこのエラーが出たのか
プラグインやテーマのアップデートでコードの処理方式が変わり、消費メモリが増えた可能性が高い。またWooCommerceの商品登録数が増えたり、データベースの肥大化によって1回のクエリで扱うデータ量が閾値を超えたことも原因に挙げられる。
メモリ上限の設定が反映されているか確認する方法は
管理画面の「サイトヘルス」で確認するのが最も簡単だ。あるいは、ルートディレクトリにinfo.phpを作成しphp phpinfo();と記述してブラウザでアクセスする。表示された一覧の中の「memory_limit」の値を見れば、現在の上限が分かる。
プラグイン停止でデータは消えないのか
プラグインのフォルダ名を変更して停止するだけでは、データベースに保存された設定やコンテンツは一切消失しない。単にWordPressがそのプラグインを読み込まなくなるだけなので、フォルダ名を元に戻せば全く同じ状態で再開できる。
512MBまで上げたが足りるか心配だ
一般的なWordPressサイトであれば512MBで十分だが、複数の重量級プラグインが稼働する大規模サイトでは1GBを超える設定が必要になることもある。ただし上限が高すぎるとPHPプロセスがメモリを解放しないまま滞留するリスクもあるため、原因プラグインの特定を優先するのが安全だ。
この記事のポイント
- PHPのメモリ不足エラーは物理メモリとは別の設定値で起こる
- まずはwp-config.phpにWP_MEMORY_LIMITを定義して上限を引き上げる
- 512MBに引き上げても直らないなら、プラグインのバグを疑う
- 管理画面に入れない時はFTPでプラグインフォルダをリネームして強制停止する
- エラーログに書かれたファイルパスから原因のプラグインを狙い撃ちする
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
Amazon FBM配送要件が厳格化、定時配達率90%維持が必須に
Amazon FBM販売者の配送要件が厳格化、定時配達率90%維持が必須に
Amazonが、自社で商品の発送を行うFBM（フルフィルメント・バイ・マーチャント）販売者に対する監視を強化している。ドイツでは定時配達率（OTDR）90%以上の維持が求められ、基準を下回った場合のペナルティも明確化された。イギリスでも同様の厳格化が進む。この動きはフランス、スペイン、イタリアにも波及しており、欧州のAmazonセラーにとって配送品質の向上が待ったなしの課題となっている。
日本国内でAmazon販売を展開する事業者にとっても、この欧州の政策変更は対岸の火事ではない。グローバルで足並みを揃えるAmazonのポリシーは、いずれ日本市場にも適用される可能性が高く、早めの対策が求められる。ここでは変更点の詳細と、販売者が取るべき具体的な対応策を解説する。
配送品質を担保する主体が販売者からAmazonへと移行しつつある状況を示している。FBM販売者は、単に発送するだけでなく、配送プロセス全体のパフォーマンスを数値で証明する責任を負うことになる。
OTDR 90%維持の義務化、その基準とペナルティの詳細
ドイツのAmazonセラー向け公式フォーラムで発表されたポリシー更新によると、FBM販売者は消費者向け注文において、定時配達率を90%以上に保つことが求められる。このOTDR（On-Time Delivery Rate）とは、顧客に約束した配達日までに商品が到着した注文の割合を指す。
消費者向け配送からB2B配送まで、段階的に強化
この要件は2026年9月1日から施行され、基準を満たせない場合、対象となる商品の出品が停止される可能性がある。さらに、FBM商品の新規出品自体ができなくなるリスクも示唆されている。
B2B取引、つまりAmazon Businessの注文についても同様の厳格化が予定されている。9月30日からは、企業向け配送の90%以上が、顧客の営業時間内に時間通り到着することが必須となる。このB2B配送指標が新たに導入され、10月30日からは基準未達の場合、企業向け出品の停止措置が取られる。この変更はイギリスのAmazon.co.ukセラーにもアナウンスされている。
このスケジュールから、Amazonが個人消費者向けと企業向けの両面で配送品質を底上げしようとする意図が明確に読み取れる。特に法人向けは、指定された営業時間内への配達が求められるため、配送業者の選定や在庫管理により一層の正確性が要求される。
イギリス市場でも監視が強化、猶予はここまで
イギリスでは、90%のOTDR要件自体は既に存在していた。しかし、これまでは形骸化していた側面があり、2026年9月からはより厳格に執行されることになる。移行期間は終わり、抜け道は塞がれつつある。
Amazonがドイツとイギリスという欧州最大の2市場で今回のルール変更を同時に進めることは、両市場でより正確な配送約束を表示し、セラーのコンバージョン率を高める狙いがあるというのが、Amazon自身の説明だ。
ハンドリングタイムの自動調整、販売者の甘えは許されない
配送要件の厳格化と並行して、ハンドリングタイムの設定ルールも大きく変わる。ハンドリングタイムとは、注文を受けてから商品を発送するまでの準備期間を指す。昨年も販売者間で議論を呼んだ問題だが、Amazonはここに再度メスを入れた。
デフォルトの2日間設定が1日へ自動短縮
2026年7月15日以降、アカウントのデフォルトのハンドリングタイムが2日間に設定されている場合、自動的に1日に短縮される。これまで多くのセラーが「念のため」と長めに設定していたバッファを、Amazonは認めなくなった。
実績ベースで自動調整される仕組み
さらに踏み込んだ施策として、9月1日からは自動ハンドリングタイム機能が本格的に稼働する。実際の発送実績よりも1日以上長くハンドリングタイムを設定している場合、その設定は30日後に自動的に短縮される。ステータス変更や再設定などの回避策は用をなさない。Amazonの説明を借りるなら「実際のパフォーマンスを反映した、より迅速な配送約束の提示を容易にする」ための仕組みだ。
このルール変更は、良心的なセラーにとっては強力な武器となる。配送品質の低い競合がふるい落とされることで、自社の「迅速な配送」という強みが際立つからだ。逆に、発送業務が属人的で安定しない事業者は、これまで以上に厳しい立場に置かれる。
FBM Ship+ との連動で配送体験はどう変わるか
これらのパフォーマンス要件の厳格化は、Amazonが昨年後半にドイツ、イギリス、フランス、スペイン、イタリアの5カ国で導入したFBM Ship+プログラムと密接に連動している。FBM Ship+は販売者がより迅速な配送オプションを提供するためのプログラムで、高速配送にかかるコストの一部をキャッシュバックする仕組みを備えている。Amazonはこのプログラムを「史上最も速く、かつ手頃な配送」と謳っている。
表面的には「配送の改善」だが、実態はAmazonプライムや企業購買担当者の期待値にFBM販売者を近づけるための構造改革だ。FBA（フルフィルメント・バイ・Amazon）に匹敵する配送スピードと信頼性を、自社発送でも実現せよというプラットフォームからの強い要求と解釈できる。
FBM Ship+のキャッシュバック制度は、こうした厳しい要求に対する飴として機能する。しかし、OTDR 90%維持という厳格な基準をクリアできなければ、そもそもプログラムの恩恵を受ける土台にも乗れない。
販売者が今すぐ取るべき3つの対策
欧州のルール変更を踏まえ、日本のAmazonセラーが準備すべきことを整理する。今のうちに対応を進めておけば、ポリシー変更が日本に上陸した際にスムーズに対応できる。
- 配送キャリアのパフォーマンスを可視化する。OTDR 90%を下回る原因の多くは、配送業者の遅延だ。複数キャリアの配達実績を比較し、信頼性の高いパートナーに絞り込む必要がある。
- ハンドリングタイムの実態を把握し、1日発送を標準化する。現在2日以上に設定している場合、自動調整の対象となる。在庫管理と出荷業務のフローを見直し、遅くとも翌営業日には発送できる体制を整える。
- 自社ECサイトとの二重管理を避ける。Amazonの在庫連動アプリやマルチチャネル管理ツールを活用し、販売機会を逃さず、かつオーバーセリングによる配送遅延を防ぐ仕組みを構築する。
自社ECサイトにおける「配送品質」の捉え方
Amazonだけの話ではない。この厳格化の波は、顧客の配送に対する期待値そのものを引き上げる。Amazonで「翌日配達が当たり前」という体験をした顧客が、あなたの自社ECサイトで買い物をした時、「配送が遅い」と感じれば二度と戻ってこない可能性がある。
WooCommerceなどで自社ECを運営している事業者は、カート落ち対策として配送スピードとコストのバランスを再考すべきだ。具体的には、一定金額以上の購入で送料無料かつ翌日配送を確約する、配送ステータスを自動通知するプラグインを導入するといった施策が有効になる。Amazonの基準は、もはや業界のデファクトスタンダードになりつつある。
この記事のポイント
- FBM販売者の定時配達率（OTDR）が90%以上必須となり、基準未達で出品停止の可能性
- 2026年9月1日から施行、B2B注文へも同様の厳格化が段階的に拡大
- ハンドリングタイムは実績を基に自動調整され、販売者による水増し設定が不可能に
- 配送品質の改善はコンバージョン率向上に直結するが、基準を下回れば販売権を失うリスクも
- 自社ECサイトでもAmazon並の配送体験が求められる時代へ、早急な業務フロー見直しが必要
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
WordPressのアコーディオンブロックが開かない原因と直し方
WordPress 6.9のアコーディオンブロックをクリックしても展開しない場合は、ページ読み込み時にブロックのJavaScriptが正しく初期化されていないことが原因だ。キャッシュを完全に削除し、プラグインの競合を確認することで大半のケースは解決する。改善しない場合はテーマの読み込み順を調整する。
なぜアコーディオンブロックが展開しないのか
この現象は、アコーディオンブロックの内部で使われる view.min.js が、ページの読み込み完了前にクリックイベントを受け取ってしまうことで起きる。具体的には、ブロックの状態（開閉のデータ）がまだ存在しないタイミングで「開く」処理が実行され、「未定義のプロパティを読めない」というTypeErrorが発生するという仕組みだ。
読み込み速度が極端に速い場合も、逆に特定のスクリプトが遅延して遅くなった場合も、内部のタイミングがずれて初期化が完了しないまま操作できてしまう。Twenty Twenty-Fiveテーマに限らず、他のテーマやプラグインがページの読み込み順を変えていると同様の症状が出ることがある。
c が undefined → エラーJavaScriptエラーの原因を開発者ツールで確認する方法
まずエラーが出ているか正確に把握する。ChromeやEdgeのデベロッパーツール（F12キー）を開き、Consoleタブを確認する。該当ページでアコーディオンをクリックした瞬間に赤いエラーメッセージが出ていれば、今回の症状に合致する。
エラー文は日本語環境でも英語で「Uncaught TypeError: Cannot read properties of undefined (reading ‘isOpen’)」と表示される。ファイル名に view.min.js が含まれていれば、WordPress 6.9の標準アコーディオンブロックの初期化問題だと特定できる。
アコーディオンが開かない場合の5つの対処法
以下の手順は、簡単で効果が高いものから順に並べている。1つずつ試し、改善した時点で後続の手順は不要だ。
サイト全体のキャッシュを完全に削除する
キャッシュ系プラグイン（W3 Total CacheやWP Super Cacheなど）を導入している場合は、管理画面から全キャッシュを削除する。加えてサーバー側のキャッシュ（NGINX FastCGI CacheやLiteSpeed Cache）もクリアする。ブラウザキャッシュを個別に消すよりも、プラグインやサーバー管理パネルからの一括削除のほうが確実だ。
全プラグインを無効化して原因を特定する
プラグインのいずれかがJavaScriptの読み込み順やタイミングに干渉している可能性がある。「プラグイン」→「インストール済みプラグイン」からすべてのプラグインを一時的に無効化し、アコーディオンブロックの動作を確認する。問題が解消したら、1つずつ有効に戻していき、再発するプラグインを特定する。
この方法で原因プラグインが判明した場合、そのプラグインの代替を探すか、開発元に修正を依頼するのが現実的だ。特にJavaScriptを多用するページビルダーや最適化系プラグインは干渉しやすいので注意する。
テーマの状態をリセットする
子テーマやカスタマイズを行っている場合は、一時的に親テーマのTwenty Twenty-Fiveに直接切り替える。必要に応じて「外観」→「テーマ」から親テーマを有効化し、カスタマイザーで追加した独自のCSSやJavaScriptが干渉していないか切り分ける。
functions.phpでスクリプト読み込み順を調整する
上記の手順で解決しない場合、テーマやプラグインの読み込み順が影響している可能性が高い。子テーマの functions.php に以下のコードを追加し、WordPress標準のスクリプトをより早い段階で読み込ませる方法が有効だ。
<?php
function force_accordion_script_priority() {
if ( has_block( 'core/accordion' ) ) {
wp_enqueue_script( 'wp-block-library' );
// モジュールスクリプトの読み込みを優先
add_filter( 'script_loader_tag', function( $tag, $handle ) {
if ( false !== strpos( $handle, 'accordion' ) ) {
$tag = str_replace( 'defer', '', $tag );
}
return $tag;
}, 10, 2 );
}
}
add_action( 'wp_enqueue_scripts', 'force_accordion_script_priority', 5 );
このコードは、アコーディオンブロックがページ内に存在する場合にだけ動作し、defer 属性を除去して読み込みの優先度を上げる。極端な遅延読み込みが原因でエラーが起きている場合に効果を発揮する。
そもそもこのエラーが起きる条件とは
このエラーはWordPress 6.9の標準ブロックに含まれる view.min.js のタイミング依存が直接の原因だ。以下のような条件が重なると発生しやすい。
- 高速なサーバー環境やCDNによってHTMLの描画が極端に速い
- 最適化プラグインがスクリプトに
deferやasyncを追加している - ページビルダーが独自の方法でスクリプトを結合・遅延読み込みしている
- カスタムテーマが
wp_head()やwp_footer()を正しく呼び出していない
いずれも、WordPressが想定するスクリプトの読み込み順序が変更されることで、ブロックの状態管理オブジェクトが生成される前にクリックイベントのリスナーが機能し始めてしまう点で共通している。
再発を防ぐための設定ポイント
この問題を恒久的に避けるには、スクリプト最適化の設定を見直すのが最も効果的だ。キャッシュプラグインや高速化プラグインの「JavaScriptの遅延読み込み」「結合」「minify」などの機能を無効化するか、該当ブロックだけ除外設定を追加する。
具体的には、プラグインの設定画面で「遅延読み込みの除外」に view.min.js または accordion を含むパスを指定する。多くの高速化プラグインでは、特定のスクリプトハンドルやファイル名を除外リストに登録できる。
また、WordPressのアップデートによってコア側の修正が入る可能性も高い。そのため、WordPress本体とテーマは常に最新の状態を維持し、修正が公式にリリースされ次第適用することも大切だ。
よくある質問
特定のブラウザだけで起きるのか
いいや、ブラウザの種類よりもページの読み込み速度やスクリプトの実行順序に左右される。Chrome、Edge、Firefox、Safariのいずれでも発生しうる。特定のブラウザだけで再現する場合は、ブラウザ拡張機能の影響も疑うとよい。
プラグインをすべて無効にしても直らない場合は
テーマに原因がある可能性が高い。一度Twenty Twenty-Fiveの親テーマを直接有効化し、それでも改善しなければサーバー側のキャッシュ機構やCDNの設定を見直す。functions.phpに追加したカスタムコードが干渉しているケースもある。
キャッシュをクリアしても改善しないときの次の手順は
ブラウザのシークレットウィンドウでテストし、ブラウザキャッシュを完全に排除した状態で確認する。それでも同じエラーが出るなら、上記のSTEP 4のコード追加を試すか、WordPress本体の再インストールを検討する。
このエラーはWordPressのバグなのか
厳密にはタイミング依存のバグであり、WordPress 6.9に標準で含まれる view.min.js に起因する。今後のアップデートで修正される見込みだが、現時点ではサーバー環境やプラグイン構成によって発生が左右されるため、回避策を講じるのが現実的だ。
テーマ側で何かできることはあるか
ある。先述のfunctions.phpによる defer 属性の除去のほか、テーマが wp_footer() の直前に不要なスクリプトを挿入していないか確認することも有効だ。シンプルなテーマほどこの問題は起こりにくい。
この記事のポイント
- アコーディオンが開かない原因はJavaScript初期化のタイミングずれ
- キャッシュの全削除とプラグイン全無効化でほぼ修正できる
- 改善しなければfunctions.phpでスクリプト優先度を上げる
- 最適化プラグインの設定で
view.min.jsを除外登録する - WordPress本体とテーマは常に最新版を保つ
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
MetaがInstagram埋め込みのトークン要件を撤回、WordPressで復活
Metaは2026年6月15日、約6年前に導入したoEmbed APIのアクセストークン要件を撤回した。Instagram、Facebook、Threadsの投稿URLをWordPressに貼り付けるだけで埋め込み表示が可能になる。2020年10月にそれまで動いていた機能が突然使えなくなって以降、多くのサイト運営者が埋め込み手段を模索してきたが、ようやく以前の手軽さが戻った格好だ。
今回の方針転換に合わせて、Metaは公式WordPressプラグイン「Meta Embeds」も公開している。トークン管理不要で動作し、コードはGitHubで公開されている。本記事では技術的な変更点と実務への影響、そしてこの変更がカバーしない領域についても整理する。
2026年6月15日の変更内容
今回の発表でトークン不要となったのは、以下の4つのエンドポイントだ。
- Threads oEmbed
- Instagram oEmbed
- Facebook oEmbed（投稿）
- Facebook oEmbed（動画）
従来は、これらのエンドポイントを呼び出すためにMetaの開発者アカウント登録、アプリ作成、App Review申請、そして毎回のアクセストークン付与が必要だった。2026年6月15日以降は、URLさえあれば直接APIを叩ける。レスポンスの形式自体は以前と同じで、埋め込みHTML、プロバイダ名、幅、コンテンツタイプが返ってくる。
ただし2つの注意点がある。1つ目はレート制限だ。トークンレスアクセスはトークン付きのルートよりも呼び出し回数が制限される可能性があり、高頻度で埋め込みを行うサイトでは影響が出るかもしれない。2つ目は、エンドポイントがパブリックな投稿にしか対応しない点だ。非公開アカウントや限定公開の投稿は対象外となる。
この比較図からもわかるように、開発者向けの複雑な手続きが不要になった。個人ブログの運営者でも迷わずにMetaの投稿を埋め込めるようになっている。
元の変更が起きた経緯
2020年10月の衝撃
2020年10月、Metaは同社のoEmbedエンドポイントにアクセストークンを必須とする変更を発表した。WordPressにとってInstagramやFacebookのURLを貼るだけで埋め込みが表示される機能は標準装備だったが、この発表で状況は一変する。WordPressのコアチームは、数千万ものサイト運営者にトークン管理を要求することは現実的ではないと判断し、FacebookとInstagramをoEmbedプロバイダーから削除した。
すでに埋め込まれていた投稿は、WordPressがoEmbedレスポンスをデータベースにキャッシュしていたため表示が維持された。しかし新規の埋め込みは一切動作しなくなった。影響はWordPressサイト全体に及び、埋め込み機能を前提にしていたコンテンツ戦略を大きく狂わせた。
プラグイン市場への波及
この混乱に対応するため、JetpackはAutomattic社が保有するトークン経由でリクエストをプロキシする仕組みを急遽導入した。oEmbed Plusのようなサードパーティ製プラグインも登場し、一般のサイト運営者が自前でFacebook App IDとシークレットキーを生成して設定する手順を案内していた。
しかし多くの運営者はこれらの対策を取らず、埋め込み自体を諦めるか、API接続を内部で処理する専用プラグインに移行した。WP Mayorの記事によれば、この一件だけで「壊れたInstagram埋め込みを修正する」ためのコンテンツやツール群が一つのカテゴリを形成するほどだったという。
6年ぶりの方針転換の背景
Metaが2020年に掲げていた理由はプライバシーとセキュリティの強化だった。しかし今回の発表では「パブリックなMetaコンテンツの埋め込みを容易にする」という簡潔な説明にとどまっている。WP Mayorの著者Mark Zahra氏は、このタイミングでの撤回について「各プラットフォームがユーザーの注意を奪い合い、AIによる回答がリファラルトラフィックを侵食する中で、Metaが自社コンテンツを再びオープンウェブ上で流通させたいという意図が透けて見える」と分析している。
Metaが公式WordPressプラグインを公開
APIの方針転換と同時に、Metaは公式のWordPressプラグイン「Meta Embeds」をリリースした。ソースコードはGitHubで公開されており、オープンソースで開発が進められている。
このプラグインは、Threads、Instagram、Facebookの投稿URLをエディタに貼り付けるだけでリッチな埋め込みを表示する。設定画面はなく、トークンも不要。ブロックエディタとクラシックエディタの両方に対応している。Metaが自社製のWordPressプラグインを公式リポジトリに直接公開するのは異例の動きだ。
プラグインのReadmeに含まれるFAQには、今後の展開をうかがわせる記述がある。このプラグインは、WordPressのバージョンがすでにThreadsのoEmbedプロバイダーを登録しているかどうかをチェックし、重複登録を回避する仕様になっている。WP Mayorの記事は、この実装を「Metaの埋め込み機能がWordPressコアに再統合される布石」と見ており、今後のWordPressリリースでInstagramとFacebookのネイティブ埋め込みが復活する可能性に注目すべきだと指摘している。
Meta Embedsプラグインを有効化するだけで、これまで埋め込みが動作しなかった環境でも即座に表示が改善する。WordPressコアへの統合が実現すれば、プラグインすら不要になる可能性もある。
今回の変更が影響しない領域
oEmbedは単一投稿のAPIである
「トークンレスになったならInstagramフィードプラグインは不要では」という見方が一部で出ているが、それは誤解だ。oEmbedはあくまで1つの公開投稿URLを受け取り、その1投稿の埋め込みコードを返すAPIに過ぎない。
アカウントの最新投稿一覧を取得する機能、ハッシュタグフィード、ストーリーズの表示、自動更新といった機能は、oEmbedでは提供されない。これらは従来通りInstagram Graph APIを使い、アクセストークンによる認証が必要となる。
ブログ記事の中に特定のInstagram投稿を1つだけ埋め込みたいケースでは、今回の無料ルートが再び使えるようになった。逆に、サイトのトップページに最新のInstagram投稿を自動表示したい場合、レイアウトやフィルタリング、モデレーション機能も含めて、Instagramフィード専用プラグインの出番は変わらない。
フロントエンドでのスクリプト読み込みとプライバシー
もう1つ理解しておくべき違いは、oEmbedから返される埋め込みHTMLの動作だ。MetaのoEmbedは、投稿をレンダリングするためにMetaのJavaScriptを訪問者のブラウザに読み込む。Meta EmbedsプラグインのReadmeにも、フロントエンドでのレンダリングはMetaのプライバシーポリシーに準拠すると明記されている。
これは、Metaのスクリプトを一切読み込まずにコンテンツをネイティブ表示するソリューションとは性質が異なる。EU圏のクライアント向けにサイトを構築している場合、GDPRの観点からこの違いは重要だ。埋め込みを有効にする前に、プライバシーポリシーとの整合性を確認しておく必要がある。
実務者への実践ガイド
ドキュメントとナレッジベースの更新
Instagram埋め込みにトークンやMetaアプリが必要だと説明しているコンテンツやドキュメントは、2026年6月15日以降は誤りとなった。WP Mayor自身も自社アーカイブの監査を進めていると述べており、チュートリアル記事や社内マニュアルを保有している場合は速やかな見直しが求められる。
クライアントサイトでの対応
クライアント向けにWordPressサイトを構築している場合、単発のMeta投稿埋め込みは開発者向けのセットアップなしで利用可能になった。Meta Embedsプラグインを導入すればすぐに動作する。WordPressコアへの統合が進めば、近い将来プラグインすら不要になる可能性も視野に入れておきたい。
Instagramフィードプラグインの利用者
既存のInstagramフィードプラグインを使用しているサイトには、今回の変更は一切影響しない。フィード機能はInstagram Graph APIに依存しており、oEmbedのトークン要件撤廃とは無関係だ。不安があればプラグインの開発元に確認するのが確実だが、WP Mayorの記事ではRebelCode社が開発するSpotlight Instagram Feeds（6万以上のアクティブインストールを誇る高評価プラグイン）を含め、APIベースのフィードソリューションはすべて影響を受けないと明言されている。
この記事のポイント
- Metaが2026年6月15日、oEmbed APIのトークン必須化を撤回。Instagram、Facebook、Threadsの埋め込みがURL貼り付けだけで動作する
- 併せて公式WordPressプラグイン「Meta Embeds」をリリース。コードはGitHubで公開され、WordPressコアへの統合も視野に入っている
- oEmbedは単一投稿APIであるため、アカウントの最新フィード表示やストーリーズ機能は従来通りAPIトークンが必要。Instagramフィードプラグインの役割は変わらない
- 埋め込み表示にはMetaのJavaScriptが読み込まれるため、GDPR対応が必要なサイトではプライバシーポリシーとの整合性確認が欠かせない
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
GiveWPアップデート後にStripeの寄付が完了しない原因と直し方
Stripeの決済は成功しているのにGiveWPで寄付が「完了」にならない。管理画面に寄付データが作成されず、Webhookだけが延々と失敗し続ける。この症状は、GiveWP 4.16のアップデート後にStripeから送られてくるWebhookの中身が空（null）になっていることが原因だ。PHPの致命的エラー「array_keys(): Argument #1 ($array) must be of type array, null given」が記録されているならなおさらで、GiveWPがイベントデータを正しく読み取れていない。
対処の核心はGiveWPとStripeの接続を完全に再確立し、Webhookの登録から正しくやり直すことにある。加えて、サーバー側のキャッシュがWebhookの受信を阻害しているケースも多いため、キャッシュの全削除とWebhookエンドポイントの除外設定が必要だ。
なぜStripeの決済は成功するのにGiveWPの寄付は未完了になるのか
この問題のややこしい点は、Stripe上では決済が正常に完了して見えることだ。PaymentIntentのステータスは「succeeded」になり、クレジットカードの引き落としも問題なく行われる。しかしGiveWP側では寄付レコードが作成されず、寄付者にも完了メールが届かない。
仕組みをたどると、GiveWPは次の流れで寄付を確定させている。
この流れのうち、手順③の段階でコケているのが今回の症状だ。StripeからのWebhookはGiveWPのエンドポイントに届いているのに、GiveWPがその中身を処理できない。結果として手順④に進めず、寄付は永遠に「処理中」のまま取り残される。
「array_keys null given」エラーが示す根本原因
GiveWPのデバッグログに次のような致命的エラーが記録されている場合、原因の特定はかなり絞り込める。
Uncaught TypeError: array_keys(): Argument #1 ($array) must be of type array, null given
in vendor/stripe/stripe-php/lib/StripeObject.phpこのエラーは、GiveWPがStripeの公式PHPライブラリ（stripe-php）を使ってWebhookイベントのデータを読み取ろうとしたとき、肝心のイベントオブジェクトの中身がnullになっていることを意味する。本来なら配列として渡されるべきデータが空っぽなのだ。
なぜデータが空になるのか。主な原因は次の3つに集約される。
- GiveWPのアップデートで内部のWebhook処理ロジックが変わり、既存の接続設定との整合性が崩れた
- サーバーレベルのキャッシュ（LiteSpeedやホスティング側のキャッシュ）がWebhookリクエストを変形させている
- StripeダッシュボードのWebhook設定とGiveWPが自動管理する署名シークレットとの間にずれが生じている
4.16より前のバージョンではWebhookのデータ取得方法が異なっていた可能性があり、アップデートによって従来の接続状態に不整合が発生したと見るのが自然だ。事実、GiveWP 4.16がリリースされる直前の6月23日までは正常に動作していたという報告は、この仮説を裏付けている。
GiveWPとStripeの接続を完全に再確立する手順
部分的な修正では直らない。GiveWPとStripeの間の信頼関係をゼロから組み直すつもりで、以下の手順を上から順に実行する。
GiveWP管理画面でのStripe接続解除と再接続の落とし穴
接続解除ボタンを押しても、内部的に完全にクリーンアップされるとは限らない。GiveWPは接続情報をデータベースのoptionsテーブルに保存しているため、万が一解除がうまくいかない場合は、データベースを直接確認する方法も検討する。
再接続時は必ず本番モードで認証を通すこと。テストモードで接続したあとに本番モードに切り替えても、Webhookエンドポイントはテスト用のものが残ったままになり、本番決済のWebhookが正しく処理されない原因になる。
Stripe Webhookエンドポイントに必要なイベントを確認する
GiveWPが自動登録するWebhookには、以下の8つのイベントが最低限有効になっている必要がある。Stripeダッシュボードでエンドポイントを開き、「受信イベント」欄を目視で確認する。
- charge.refunded（返金処理）
- checkout.session.completed（チェックアウトセッション完了）
- customer.subscription.created（定期寄付の作成）
- customer.subscription.deleted（定期寄付の削除）
- invoice.payment_failed（請求書の支払い失敗）
- invoice.payment_succeeded（請求書の支払い成功）
- payment_intent.payment_failed（支払い意図の失敗）
- payment_intent.succeeded（支払い意図の成功）
いずれかが欠けている場合は手動で追加する。GiveWPがイベントを自動追加する仕様はバージョンによって変わるため、再接続後に必ず確認する習慣をつけるとよい。
キャッシュがWebhookを壊す仕組みと確実な対処
Webhookはサーバー間のHTTP POSTリクエストだ。ところが一部のキャッシュプラグインやホスティング側のキャッシュ機構は、このPOSTリクエストに対して予期せぬ挙動を示す。具体的には、リクエストボディを空にしたり、ヘッダー情報を削除したり、レスポンスをキャッシュしてしまったりする。
GiveWPが正しく署名を検証し、イベントデータを読み取るためには、StripeからのPOSTリクエストが一切加工されずに届かなければならない。次の対応を必ず実施する。
LiteSpeedキャッシュが原因のケース
LiteSpeedサーバー環境では、LiteSpeed Cacheプラグインの設定画面から「キャッシュ」→「除外」タブを開き、「URLの除外」にGiveWPのWebhookエンドポイントパスを追加する。具体的には「give-listener=stripe」を含むURLパターンを指定する。正規表現が使える場合は次のように記述する。
give-listener=stripeまた、LiteSpeedの「オブジェクトキャッシュ」や「ブラウザキャッシュ」も合わせて無効化した状態でテストすることを推奨する。テストが終わったら再度有効化しても問題はないが、少なくともWebhookエンドポイントだけは常にキャッシュの対象外にしておく。
ホスティング側のキャッシュが原因のケース
一部の共用サーバーやマネージドホスティングでは、サーバーレベルでリバースプロキシキャッシュが動作している。管理パネルからキャッシュを手動でクリアしたあと、一時的にキャッシュ機能を停止してWebhookが正常に処理されるかテストする。
恒常的な解決策としては、ホスティングのサポートに依頼して「https://example.com/?give-listener=stripe」をキャッシュの除外リストに追加してもらう必要がある。
署名シークレットの誤設定が引き起こす症状と修正
GiveWP 4.16以降、署名シークレットの管理方法が変わり、手動での設定が不要になった。GiveWPがStripeに接続する際、自動的にWebhookエンドポイントを作成し、署名シークレットもGiveWP内部で管理する。そのため、Stripeダッシュボードから取得した署名シークレットをGiveWPの設定画面に入力する欄は存在しない。
もし過去に手動でWebhookを作成し、その署名シークレットを何らかの方法でGiveWPに設定していた場合、バージョンアップ後にその情報が無視されるか、あるいは競合を起こす可能性がある。そのため、手順としては次のように徹底する。
- Stripeダッシュボードから古いWebhookをすべて削除する（手動で作成したものも含む）
- GiveWP管理画面でStripeとの接続を完全に解除する
- GiveWP管理画面でStripeに再接続する（このとき新しいWebhookと署名シークレットが自動作成される）
署名シークレットに関するエラーがStripeダッシュボードに表示されている場合、ほぼ間違いなく新旧のWebhookが混在しているか、手動設定の名残が残っている。上記の手順で完全にリセットすれば、署名検証エラーは解消する。
それでも直らないときの最終確認リスト
上記の手順をすべて実行しても症状が改善しない場合、以下のポイントを順に再チェックする。
よくある質問
GiveWPを最新版に更新したあとにStripeのWebhookが失敗し始めた。ロールバックするべきか
ロールバックは推奨しない。4.16系にはWebhook処理まわりの重要な変更が含まれており、古いバージョンに戻すと将来的にStripe APIの更新に追随できず、より深刻な不具合を引き起こす。まずは本記事の再接続手順を試し、それでも解決しない場合はGiveWPのサポートにシステムレポートを送って調査を依頼するほうが安全だ。
StripeのダッシュボードでWebhookが「失敗」と表示されるが、GiveWP側にエラーログが出ない
GiveWPのデバッグモードが有効になっていない可能性が高い。「寄付」→「設定」→「詳細」→「デバッグモード」を有効にすると、Webhook処理のエラーログが記録されるようになる。ログは「寄付」→「ツール」→「ログ」で確認できる。
再接続してもWebhookがStripeダッシュボードに自動作成されない
GiveWPの接続プロセスの中で、WordPressのREST APIが正しく動作していない可能性がある。パーマリンク設定を「基本」以外に変更して保存し直す。また、セキュリティプラグインがREST APIを制限していないか確認する。
WebhookエンドポイントのURLは手動で変更してもよいか
原則として不要であり、変更すべきではない。GiveWPが自動生成するエンドポイントURLは「https://（サイトURL）/?give-listener=stripe」で固定されており、これをStripeに正しく登録している。URLを手動で変更すると、署名の不一致が発生してすべてのWebhookが失敗する。
GiveWPのシステムレポートはどこで確認できるか
WordPress管理画面の「寄付」→「ツール」→「システム情報」タブを開き、「システムレポートを取得」ボタンをクリックすると、サーバー環境やGiveWPの設定情報がテキスト形式で表示される。サポートに問い合わせる際はこのレポートを添付するとスムーズに調査が進む。
この記事のポイント
- Stripe決済成功後に寄付が未完了になるのは、Webhook処理の段階でGiveWPがイベントデータを読み取れていないから
- 致命的エラー「array_keys null given」はWebhookの中身が空であることを示す決定的な手がかり
- GiveWPとStripeの接続解除からWebhook全削除、再接続までを一気に行い、署名シークレットを完全に再生成する
- LiteSpeedやホスティングのキャッシュからWebhookエンドポイントを除外し、POSTリクエストが加工されないようにする
- 署名シークレットはGiveWPが自動管理するため、手動設定は不要であり、むしろ競合の原因になる
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
AWS Graviton5搭載EC2 C9gインスタンスが一般提供開始
計算負荷の高いワークロードを扱う企業にとって、「もう少しだけ処理が速ければ」という場面は多い。AWSが6月30日に発表したEC2 C9g/C9gdインスタンスは、その不満を根本から解決する新世代の計算特化型インスタンスだ。Graviton5プロセッサの投入により、前世代からvCPUあたり最大25%の性能向上を実現した。今回の発表で特に注目すべきは、クラウド最速級となるDDR5-8800MT/sメモリの採用と、正式検証済みのハイパーバイザー分離エンジン「Nitro Isolation Engine」の搭載だ。本記事では、CPU負荷の高いバッチ処理や動画エンコーディングを中心に、新しいインスタンスがどのような場面で威力を発揮するのかを詳しく解説する。
C9g/C9gdインスタンスの位置づけを見極める
AWSのEC2には多様なインスタンスファミリーが存在する。頭文字の「C」はCompute Optimized（計算最適化）を意味し、他のメモリ最適化（Rシリーズ）やストレージ最適化（Iシリーズ）とは設計思想が異なる。計算最適化インスタンスは、vCPUあたりの演算性能を最大化することに特化している。リアルタイム分析、機械学習の推論、動画エンコーディングなど、1秒でも短く計算を終えたい処理に適している。
今回発表されたC9g/C9gdは、2024年秋に登場したGraviton4搭載C8gの後継にあたる。AWS GravitonシリーズはArmベースの独自プロセッサで、x86系のIntel XeonやAMD EPYCと比較して、コストパフォーマンスに優れる点が強みだ。C9gの「g」はGravitonを示し、末尾に「d」がつくC9gdはNVMe SSDによる高速なローカルストレージを内蔵する。
Graviton5プロセッサの進化点を知る
Graviton5の最大の改良点は、メモリ帯域幅の拡張とレイテンシの低減にある。C9gインスタンスはDDR5-8800MT/sのDIMMを採用し、これは現在クラウド上で提供されているプロセッサインスタンスの中で最速のメモリ速度だ。数字だけでは実感しにくいが、これはメモリとCPU間のデータ転送速度が秒間8800メガトランスファー（MT/s）ということを意味する。前世代のC8gがDDR5-5600MT/sだったため、実に57%もの速度向上にあたる。
さらに、CPUのL3キャッシュ容量が5倍に拡張された。キャッシュはCPUとメインメモリの間に位置する超高速なデータ置き場で、容量が大きいほどメモリアクセスの待ち時間を減らせる。AWS News Blogの著者Seb氏によると、これらの改善により、インメモリ分析のスループット向上や、より応答性の高いエージェント型AIループが期待できるという。
ネットワーク面でも強化が施されている。パケット処理性能はGraviton4ベースのインスタンスと比較して最大3倍に向上し、インスタンスサイズ全体の平均でネットワーク帯域が約15%、EBS帯域が約20%増加した。
C9g/C9gdの主要スペック詳細と設計思想
スペック表を見ると、C9g/C9gdは最小のmedium（1vCPU/2GBメモリ）から、最大のmetal-48xl（192vCPU/384GBメモリ）まで11サイズで展開される。48xlargeではネットワーク帯域が100Gbps、EBS帯域が72Gbpsに達し、これは前世代の2倍にあたる。大規模な分散処理やリアルタイム分析基盤において、ネットワークがボトルネックになる状況を回避しやすくなるだろう。
C9gdシリーズには、ローカルのNVMe SSDストレージが追加される。容量は最小のmediumで59GB、最大の48xlargeでは3台合計で11,400GB（3×3,800GB）に達する。NVMe SSDはEBSよりもレイテンシが低いため、以下のような用途に適している。
- HPCシミュレーションのスクラッチスペース（一時的な作業領域）
- 機械学習推論の一時キャッシュ
- アドサーバーのローカルバッファ
ストレージ性能も向上しており、ローカルストレージのパフォーマンスは前世代比で約30%向上した。NVMe経由の詳細なI/Oパフォーマンス統計はCloudWatchやnvme-cli経由で取得可能で、I/Oサイズ別のレイテンシヒストグラムが1秒単位で確認できる。この機能は追加料金なしで利用できる。
Instance Bandwidth Configurationの実用性を測る
C9g/C9gdには、Instance Bandwidth Configuration（IBC）と呼ばれる帯域調整機能が搭載されている。これは、EBSとVPCネットワークの帯域配分を最大25%の範囲で調整できる仕組みだ。例えば、データベースやキャッシュ用途でEBSの帯域を優先したい場合、ネットワーク側を絞ってEBS側に割り当てを寄せることが可能になる。逆に、ネットワーク集約型の分散処理ではVPC側を優先すればよい。固定的な割り当てに縛られない柔軟性は、実運用のチューニングで大きな武器になる。
C9gとC9gdの使い分けフローを整理する
C9gとC9gdはスペックが似ているため、どちらを選ぶべきか迷う場面があるだろう。選択の決め手は「ローカルのNVMe SSDが必要かどうか」に尽きる。AWS News Blogでは、C9gを「バッチジョブ、動画エンコードパイプライン、分散分析」向け、C9gdを「HPCシミュレーションのスクラッチスペース、ML推論の一時キャッシュ、アドサーバーのローカルバッファ」向けとしている。EBSで十分な永続ストレージが足りるならC9g、一時的でも高速なローカルストレージが不可欠ならC9gdを選べばよい。
Graviton5がもたらすエージェント型AIへの適性を読み解く
AWS News Blogの発表では、C9gのワークロード例として「エージェント型AI（agentic AI）」が明記されている。エージェント型AIとは、単なる質問応答を超えて、コードを実行し、複数ステップのタスクを自律的に組み立てて完了させるAIシステムを指す。OpenAIのOperatorやAnthropicのComputer Useが代表例だ。
この種のワークロードでは、大規模言語モデル（LLM）の推論そのものに加えて、Pythonコードの実行、API呼び出し、結果の検証といったCPUバウンドな処理が連続的に発生する。Graviton5のコア数向上と大容量キャッシュは、こうした「思考と行動のループ」を高速化する土台となる。AWSの著者Seb氏によれば、アプリケーションがデータを待つ時間を削減し、結果的にエージェントループの応答性が高まるとのことだ。
AI推論といえばGPUの印象が強いが、実際には前処理、後処理、オーケストレーションの多くがCPU上で動く。ArmベースのGraviton5は、これらの処理を低コストでさばける点が実務的な魅力となる。
Nitro Isolation Engineのセキュリティ強化を理解する
C9g/C9gdは、計算最適化インスタンスとして初めて「Nitro Isolation Engine」を搭載した。これはAWS Nitro Systemの拡張機能で、仮想マシン間のメモリ空間、CPUレジスタ状態、I/Oデバイスへのアクセスを数学的正確さで強制的に分離する仕組みだ。
通常、ハイパーバイザーによる分離はソフトウェアの実装品質に依存する部分があるが、Nitro Isolation Engineは形式検証（formal verification）と呼ばれる数学的手法を用いて分離の正しさを証明している。形式検証とは、仕様を数理論理で記述し、実装がその仕様を厳密に満たすことを機械的に検証する手法だ。テストのように「見つかったバグがない」ではなく、「特定の前提条件下でバグが存在し得ない」ことを保証する。
AWSは2025年にこの技術を発表した際、ハイパーバイザーの分離を形式検証する取り組みについてホワイトペーパーを公開している。今回のC9g/C9gdで初めて、計算最適化インスタンスに実装されたことになる。
セキュリティ要件の厳しい金融サービスや医療データの分析をEC2上で行うケースでは、この正式検証済みの分離機構はインフラ選定の重要な判断材料になる。ソフトウェアレベルではなく、ハードウェア支援と形式検証の組み合わせで隔離を実現している点は、AWSの設計思想として特筆に値する。
利用可能リージョンと料金モデルを確認する
2026年6月30日時点で、C9g/C9gdは米国東部（オハイオ、バージニア北部）、米国西部（オレゴン）、欧州（フランクフルト）の4リージョンで利用可能だ。AWSは追加リージョンへの展開も予定している。
料金モデルはSavings Plans、オンデマンド、スポットインスタンス、Dedicated Instances、Dedicated Hostsに対応する。常時稼働させるワークロードではSavings Plans、短期的なバッチ処理ではスポットインスタンスと使い分けられる。EBSボリュームは仮想インスタンス1台あたり最大128個までアタッチ可能で、大規模データの処理でもストレージ不足に悩むことは少ない。
インスタンスの起動はAWSマネジメントコンソール、AWS CLI、AWS SDKのいずれからでも可能だ。GravitonはArmアーキテクチャのため、AMIやコンテナイメージはArm向けにビルドされたものを選ぶ必要がある。公式のAmazon Linux 2023やUbuntuのArm版AMIはすでに提供されているため、新規導入時の障壁は低い。
この記事のポイント
- C9g/C9gdはGraviton5搭載の計算最適化インスタンス、vCPUあたり25%の性能向上を達成
- DDR5-8800MT/sメモリと5倍のL3キャッシュにより、メモリ待ち時間を大幅に削減
- 48xlargeでは100Gbpsネットワーク帯域と72GbpsのEBS帯域、前世代比2倍に拡張
- Nitro Isolation Engine搭載、形式検証による仮想マシン分離を実現
- エージェント型AIやHPC、動画エンコードなどCPU負荷の高い処理に最適
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
404ページがホームページのキャッシュとして表示される原因と修正方法
ページキャッシュを有効にしたプラグインで、存在しないはずの404ページにアクセスするとホームページの内容がそのまま表示されてしまう不具合は、該当プラグインのバージョン2.5.0で修正された。管理画面からプラグインを最新版に更新し、キャッシュを全削除すれば解決する。
なぜ404ページがホームページのキャッシュになるのか
ページキャッシュの仕組みは、最初の訪問者がサイトにアクセスしたタイミングで、その時点のHTML出力をまるごと静的ファイルとして保存する。以降の訪問者には、WordPress本体やデータベースを毎回通さず、この静的ファイルを返すことで表示速度を大幅に上げている。
正常な動作では、訪問者が存在しないURL（いわゆる404ページ）を開いた場合、プラグインはWordPressが「これは404だ」と判定した結果をそのままキャッシュする。もしくは、404ページはそもそもキャッシュの対象から外す設計になっている。しかし今回の事象では、404ページにアクセスした際にWordPressの判定をスキップして、誤ってホームページのキャッシュを返してしまう欠陥がキャッシュ生成処理に含まれていた。
内部の動きを想像で補うと、リクエストが404だとわかった段階でキャッシュを生成せずにスルーすべきところ、テーマやプラグインがフックする前に「URLに対応するキャッシュがないからホームページのキャッシュで代用する」ような分岐に入ってしまっていた可能性が高い。結果として、アドレスバーには存在しないURLが表示されたまま、画面だけホームページのレイアウトという状態が発生する。
プラグインをアップデートしてキャッシュを削除する手順
アップデートしても直らない場合の追加確認
バージョン2.5.0に更新しキャッシュを全削除したあとも問題が再発するなら、以下の点を順に調べる。
- プラグインのキャッシュとは別に、サーバー側のVarnishキャッシュやCDNキャッシュが残っていないか
- 子テーマのfunctions.phpに古いキャッシュ制御コードが残っていないか
- プラグインの設定で「404ページをキャッシュしない」などの該当オプションが無効になっていないか
アップデート前の一時的な回避策
何らかの事情ですぐにプラグインを最新版にできない場合、手元のfunctions.phpにキャッシュ除外用の定数やフックを追加して、404ページをキャッシュ対象から外す一時しのぎが使える。ただしこれはあくまで応急処置であり、根本対応としては必ずアップデートが必要だ。
// 404ページがキャッシュされないようにする一時的な回避策
add_action( 'template_redirect', function() {
if ( is_404() ) {
if ( ! defined( 'DONOTCACHEPAGE' ) ) {
define( 'DONOTCACHEPAGE', true );
}
}
});上記のコードは、WordPressが「このリクエストは404だ」と判定した直後にDONOTCACHEPAGE定数を定義し、該当プラグインのキャッシュ生成を抑止する。テーマのfunctions.phpの末尾、またはCode Snippets系のプラグインで追加する。追加後に改めてキャッシュを全削除すれば、404ページがキャッシュされることを防げる。
ただし定数名はプラグイン固有のものであり、ほかのキャッシュプラグインでも同じ定数が使えるとは限らない。あくまで該当プラグインの一時回避策としてとらえる必要がある。
よくある質問
404ページのキャッシュ問題は特定のテーマが原因になることもあるのか
テーマが独自の404テンプレートを用意している場合でも、基本的には今回のようなバグはプラグインのキャッシュ生成処理に起因する。ただし、テーマが404のときに誤ってホームページと同じクエリを走らせる設計だと、間接的に似た挙動になるケースがありうるため、プラグイン側の問題解決後も念のためテーマの404.phpを確認しておくと安心だ。
キャッシュを削除したのに404ページでホームページが表示され続けるのはなぜか
プラグイン自体のキャッシュだけでなく、ブラウザキャッシュやサーバーレベルのキャッシュ（Varnishやnginx fastcgi cache）、CDNのキャッシュが残っていることが多い。一度シークレットウィンドウでアクセスし、それでも同じならCDNの管理画面からもキャッシュ削除を試す。ホスティングによっては専用のキャッシュクリアボタンが用意されているので確認する。
アップデート後に404表示が直ったが、今後のために404ページをキャッシュさせない設定は必要か
プラグインが正常に404を区別できるようになれば、404ページがキャッシュされることはなくなるため、追加の設定は原則不要だ。むしろ手動で除外設定を重ねると、あとで別の不具合を引き起こす可能性がある。修正が確認できたら、一時回避用のコードは削除しておくほうがよい。
この記事のポイント
- 404ページがホームページで表示される問題は、該当プラグインのバージョン2.5.0で修正済み
- 修正後は管理画面からプラグインを更新し、キャッシュをすべて削除すれば解決する
- 即時更新が難しい場合はfunctions.phpにキャッシュ除外の定数を仕込むことで一時回避できる
- サーバーやCDNの多段キャッシュが残っていると再発に見えるため、あわせて削除する
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
Prisma Compute vs Vercel、料金比較でわかるコスト差の全容
TypeScriptアプリのホスティング先を選ぶとき、Prisma ComputeとVercelが候補に挙がる。両者とも従量課金でゼロスケールするため、アイドル時のコストはかからない。だが料金単価と課金項目の設計思想が異なり、同じ負荷でも請求額に2倍以上の開きが出るケースがある。Prisma Computeはパブリックベータ中で現在無料、ここで示す料金は将来の本番適用が予定されている参考値だ。
本記事ではPrisma Blogが2026年7月1日に公開した料金比較をもとに、各メーターの単価差、20Mリクエストの実ワークロード試算、そしてなぜ同じ負荷で請求が変わるのかを掘り下げる。Vercelの価格にまつわる開発者の声も紹介し、自社のアプリに当てはめるときの判断材料を提供する。
料金体系の基本比較
両サービスともリクエスト数、メモリ消費、CPU時間、外向き帯域を課金対象とするが、単価には明確な差がある。Prisma Computeの価格はベータ版後の予定値であり、変更の可能性がある点に注意が必要だ。
リクエスト単価ではVercelが優位だが、サーバーワークの大半を占めるメモリとCPU、そして帯域ではPrisma Computeが大幅に低い単価を提示している。さらに開発者シートやエッジリクエストといったワークフローコストがPrismaには存在しない点が、後々の請求に大きく響く。
実ワークロードでのコスト試算
月間2000万リクエスト、常時2GBメモリ使用、実CPU 300vCPU時間、外向きトラフィック2TB、開発者1名という条件で両者を比較する。Vercel Proには1TBの帯域無料枠が含まれる点を織り込んだ試算だ。
メモリ (1460 GB時) $8.76
CPU (300時間) $19.20
外向き帯域 (2TB) $50.00
シート (1名) $0.00
合計 ~$98
メモリ (1460 GB時) $15.48
CPU (300時間) $38.40
外向き帯域 (2TB中1TB無料扱い) $150.00
シート (1名) $20.00
合計 ~$236
この試算ではエッジリクエストを除外し、開発者1名で固定している。実際にはチーム人数が増えるほどVercelのシート料金が積み上がり、格差はさらに拡大する。一方で外向き帯域がごく小さく、リクエスト単価の差が支配的になるシナリオでは両者の総額は接近する。
料金差を生む構造的要因
なぜ同じ負荷でこれほどの差がつくのか。理由は課金モデルの設計思想とアーキテクチャの2軸に集約される。
ワークとワークフローの分離
ホスティング料金は「アプリが稼働中に行う実作業（ワーク）」と「デプロイやプレビューなど開発プロセス（ワークフロー）」に分けられる。Prisma Computeはリクエスト、メモリ、CPU、帯域というワークのみに課金し、開発者シートやエッジリクエストといったワークフロー項目は一切請求しない。Vercelはワークに加え、シート料金とエッジリクエストをワークフローとして課金する。
Prisma Compute 課金
Vercel 課金
Prisma Compute 無料
Vercel 課金
Prisma Blogの著者Martin Janse van Rensburg氏は、AIエージェントがコードの変更→テスト→プレビューを繰り返す開発スタイルでは、Vercelのワークフロー課金が急速に膨らむリスクを指摘している。一方PrismaではデプロイのたびにイミュータブルなバージョンとプレビューURLが作られるが、それらに追加料金は発生しない。
データベース隣接配置によるエグレス抑制
Prisma Computeのアーキテクチャ上の特徴として、Prisma Postgresと同じインフラ上で動作する点が挙げられる。通常、アプリケーションサーバーとデータベースが別ベンダーや別リージョンにある場合、両者間の通信が外向き帯域として課金対象になる。Prisma Computeはデータベースとの通信が同一基盤内で完結するため、こうした隠れエグレスコストが発生しない。
アプリ-DB間通信が外向き帯域として課金
同一基盤内で通信が完結。エグレスコストなし
データベースとの通信量が多いアプリほど、この差は請求額に明確に現れる。大量のクエリを発行するAPIサーバーなどでは、Vercel＋外部DB構成のエグレス費用が無視できなくなる。
開発者の声と注意点
VercelのFluid Computeは適合するワークロードでは大幅な削減効果を発揮する。リンク短縮サービスdub.coの創業者Steven Tey氏は、Xで「Vercelの利用タブが壊れたのかと思った」と述べ、Fluid有効化後に請求が50%減少したと報告している。
しかし、一部の開発者からは予想外の料金跳ね上がりに関する声も上がっている。Redditのr/nextjsスレッドでは、あるCTOがフロントエンドのみのNext.jsアプリの月額請求が「100ドル未満から800ドル超」に急増し、Cloudflare Workersへ移行後は「同じトラフィックで20ドル未満」になったと述べた。同スレッドでは「Vercelのフロントエンドは素晴らしく安いが、バックエンドは高すぎる」という見方や、Deployment Protection Exceptionsで150ドル請求された事例も共有されている。
Fluid Computeを有効化 → 請求が50%減少
フロントエンドのみのNext.jsアプリ → 月$100未満→$800超に急増
Cloudflare Workers移行後 → 同トラフィックで$20未満
Prisma Computeはパブリックベータの段階であり、実際の課金が始まっていないため、利用者からの本格的なフィードバックはまだない。Prisma Blogの著者は、フィードバックが集まり次第、この比較記事を更新する意向を示している。
この記事のポイント
- Vercelはリクエスト単価で優位だが、メモリ、CPU、帯域ではPrisma Computeが大幅に安い予定価格を提示している
- 月間2000万リクエストの試算ではPrisma Computeが約98ドル、Vercel Proが約236ドルと2.4倍の開きがあった
- 請求差の主因はワークフロー課金（シート料金、エッジリクエスト）とデータベース隣接によるエグレス抑制
- VercelのFluid Computeは適切なワークロードで削減効果を発揮する一方、トラフィックに比例しない請求急増の事例も報告されている
- Prisma Computeはまだベータ版であり、本番利用のフィードバックを踏まえた判断が今後必要になる
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験