月別アーカイブ 2026年9月7日

Google広告テック独占訴訟で分割回避。EC事業者が知るべき影響と対策

Google広告テック独占訴訟で分割回避。EC事業者が知るべき影響と対策

Googleの広告テック事業をめぐる独占訴訟で、米連邦地裁は事業分割を命じず、行動制限という形で決着をつけた。裁判所はGoogleがパブリッシャー向け広告サーバーと広告エクスチェンジ市場で違法な独占を築いたと認定したものの、AdXの売却は求めなかった。

この判決は、EC事業者が日々利用しているプログラム広告のインフラに直接関わる。広告費の流れやオークションの透明性が変わる可能性があり、広告運用の見直しが必要になる場面も出てくる。

本記事では、判決の内容を整理し、EC事業者やWooCommerceサイト運営者が知っておくべき影響と対策を解説する。

判決の概要と独占認定のポイント

判決の概要と独占認定のポイント

司法省は2023年、Googleが広告テック事業で複数の市場を支配し、競争を抑圧しているとして提訴した。2025年4月、ブリンケマ判事はGoogleがパブリッシャー向け広告サーバーと広告エクスチェンジ市場で違法な独占を築き、両製品を不当に抱き合わせたと認定した。一方、アドバタイザー向けツールでの独占は認定されなかった。

この区別は重要だ。Googleは広告主とパブリッシャーの間に位置し、パブリッシャー側の在庫管理と、その在庫を広告需要と結びつけるオークションの両方を運用している。つまり、売り手と市場の両方を支配している状態だ。

分割要求が退けられた理由

司法省はGoogleに対し、広告エクスチェンジ「AdX」の売却を要求した。しかしブリンケマ判事は、分割は困難で混乱を招く可能性が高いと判断した。判事は救済措置の審理で、誰がエクスチェンジを買うのか、買った後にどう運営するのかと疑問を呈し、違法行為を止める方が現実的な救済になると述べたという。

判決の完全な内容はまだ一部が封印されており、詳細は明らかになっていない。公開された命令では、提案された行動制限のほとんどが修正付きで受け入れられたとされている。

広告オークションのルールはどう変わるのか

広告オークションのルールはどう変わるのか

裁判所は以前、Googleが「ファーストルック」と「ラストルック」という慣行を使ってAdXを有利にしていたと認定した。ファーストルックは、Googleがパブリッシャーの在庫に最初にアクセスできる仕組みだ。ラストルックは、競合の入札情報を見てから自社の入札額を決められる仕組みだった。

今回の救済措置では、これらの優位性が制限される。パブリッシャーは価格設定の自由度を高め、競合するパブリッシャー向け広告サーバーにはGoogleのAdX入札情報がリアルタイムで提供される見込みだ。

従来の広告オークション(Before)
Google AdX がパブリッシャーの在庫に最初にアクセス(ファーストルック)
Google AdX が競合の入札情報を見てから入札額を決定(ラストルック)
パブリッシャー は需要元ごとに最低価格を設定できず
判決後の広告オークション(After)
Google AdX のファーストルックとラストルックが制限される
競合広告サーバー にもAdXの入札情報がリアルタイムで提供される
パブリッシャー は需要元ごとに最低価格を設定可能になる

この変更により、競合する広告テック企業が在庫獲得で公平な条件で競争できるようになる。広告主にとっては、オークションのダイナミクスやサプライパス、価格設定、パブリッシャーに届く広告費の割合が徐々に変わる可能性がある。

EC事業者が知っておくべき広告費の透明性

EC事業者が知っておくべき広告費の透明性

この判決は、広告費の流れを可視化する重要性を高めている。特にEC事業者は、Googleショッピング広告やディスプレイ広告を通じて商品を宣伝する。広告費がどの経路を通り、どれだけパブリッシャーに届くのかを理解することが、投資対効果の改善につながる。

Googleは依然として広告テックの主要インフラを所有している。行動制限は一部の優位性を取り除くが、パブリッシャーと広告主はGoogleが独占を維持してきたシステムの中で運用を続けることになる。

STEP 1 広告主(EC事業者)が広告予算を設定する
STEP 2 広告エクスチェンジ(Google AdXなど)がオークションを実施
STEP 3 パブリッシャー(ブログ・ニュースサイト)に広告が表示される
広告主(EC事業者)  Google所有の広告テック  パブリッシャー

上図の通り、Googleはパブリッシャー向け広告サーバーとエクスチェンジの両方を所有している。このため、広告主が支払った金額の一部が中間レイヤーで差し引かれ、パブリッシャーに届くまでに目減りしやすい構造だ。判決後のルール変更がこの構造をどこまで変えられるかが焦点になる。

今後の広告運用にどう備えるか

今後の広告運用にどう備えるか

短期的には大きな変化はない

マーケターは来週からプログラム広告キャンペーンが劇的に変わるとは考えない方がよい。オープンウェブ広告の成長はすでに鈍化しており、YouTubeやInstagram、Amazonなどへの支出シフトが進んでいる。Appleのプライバシー変更によるモバイルトラッキング制限もこの流れを加速させた。

それでも、判決はサプライパスの透明性をより重要にする。マーケターは自社の広告費がどのエクスチェンジや中間業者を経由しているか、各広告費のうちどれだけがパブリッシャーに届いているか、Googleのスタック以外の選択肢が現実的になってきたかを注視する必要がある。

サプライパスの見直しと代替手段の検討

EC事業者にとって具体的な対策は、広告配信のログやレポートを定期的に確認し、中間マージンが過大な経路を特定することだ。Googleの広告テック以外にも、競合するエクスチェンジやパブリッシャー向けサーバーが存在する。判決後の環境変化を見極めつつ、複数の選択肢をテストすることが推奨される。

MarTechの記事では、行動制限は「実験」にすぎず、競合がこの機会を利用してGoogleから大きなシェアを奪えなければ独占は続くと指摘している。つまり、他の事業者がGoogleの支配に対抗できるかどうかが、今後の市場の行方を左右する。

この記事のポイント

  • Googleは広告テック独占で違法認定されたが、AdXの売却は命じられず、行動制限のみが課された
  • ファーストルックとラストルックの制限により、競合広告テックが公平に競争できる可能性が出てきた
  • EC事業者は広告費のサプライパスを可視化し、中間マージンの過大な経路を特定することが重要
  • 短期的に広告運用が激変することはないが、代替手段のテストと環境変化の注視が推奨される
WooCommerceのマジックストリング廃止へ、エナムクラス導入で拡張開発が安全に

WooCommerceのマジックストリング廃止へ、エナムクラス導入で拡張開発が安全に

WooCommerceのコードベースで長年使われてきた「マジックストリング」が、人知れず問題を引き起こしていた。注文ステータス、商品タイプ、在庫状態、税金モード。これらの重要な値が、コード中で生の文字列として比較されていたのだ。タイプミス一つでバグになり、プレフィックスの有無で混乱し、コード検索でノイズが大量に混ざる。開発者にとって頭の痛い状況だった。

WooCommerceはこの問題に対処するため、Automattic\WooCommerce\Enumsという名前空間にエナムクラス群を導入した。注文ステータスや商品タイプを表す名前付き定数をパブリックAPIとして公開し、拡張機能開発者に採用を促している。本記事では、この変更の背景、利用可能なクラス、実際の導入方法を整理する。

マジックストリングがもたらす4つの問題

マジックストリングがもたらす4つの問題

WooCommerceは歴史が長い。そのため、注文ステータスや商品タイプといった重要な値が、PHPの近代的な慣習が生まれる前から存在している。コードベースの各所で、次のような生の文字列比較が行われてきた。

if ( 'completed' === $order->get_status() ) {
    // タイプミスがないことを祈るしかない
}

この書き方は一見シンプルに見えるが、WooCommerceのような大規模なコードベースでは深刻な代償を伴う。Developer WooCommerce Blogの記事では、その問題を4つの観点から説明している。

沈黙のエラー

文字列リテラルの最大のリスクは、タイプミスが静かに潜むことだ。'complete'と書くべきところを'completed'と書いても、リンターもオートローダーもテストもエラーを検出しない場合がある。コードは実行時に黙って失敗し、デバッグに時間を奪われる。

プレフィックスの有無による混乱

WordPressのデータベースでは、注文ステータスにwc-というプレフィックスが付く。データベースにはwc-completedとして保存されるが、WooCommerceの多くのAPIはプレフィックスなしのcompletedを期待する。この違いは、開発者が実際にコードを動かして初めて気づく類の落とし穴だ。

検索の非効率さとドキュメントの分散

エージェントやコード検索で'simple'という文字列を探すと、商品タイプのロジックを探しているのに無関係な箇所が大量にヒットする。一方、ProductType::SIMPLEのように名前付き定数で検索すれば、該当箇所を正確に絞り込める。さらに、on-holdのようなステータスの定義は、宣言箇所のdocblockにドキュメントとして残せるようになる。

マジックストリングの問題点(Before)
タイプミス検出困難 実行時まで気づけない
プレフィックス混乱 wc-completed と completed の区別が曖昧
検索ノイズ simple で検索すると無関係な箇所が大量ヒット
ドキュメント分散 値の意味がコード中に散在
エナムクラス導入後(After)
名前付き定数 タイプミスをコンパイル時に検出
意図の明確化 OrderStatus::COMPLETED と OrderInternalStatus::COMPLETED を区別
検索精度向上 ProductType::SIMPLE で該当箇所を正確に絞り込み
ドキュメント統合 docblockに意味を記載

この比較で示したように、エナムクラスは文字列リテラルが抱える問題を構造的に解決する。特に、プレフィックス有無の違いを別々のクラスに分けることで、意図を明確に伝えられる点が重要だ。

ネイティブPHPエナムを採用しなかった理由

ネイティブPHPエナムを採用しなかった理由

PHPにはバージョン8.1からネイティブのエナム型が導入されている。しかしWooCommerceはこの選択肢を取らなかった。主に2つの理由がある。

PHP 7.4のサポート

WooCommerceの最低サポートPHPバージョンは7.4だ。このバージョンにはネイティブエナムが存在しない。PHP 8.1を前提にすると、多くのユーザーを切り捨てることになる。クラス定数として文字列を定義する方式なら、PHP 7.4でも問題なく動作する。

文字列互換性という設計判断

もう一つの理由はアーキテクチャ上の判断だ。注文ステータスや商品タイプの値は、すでに数百万のデータベースにプレーンな文字列として保存されている。数千の拡張機能もその形式を前提にしている。ネイティブPHPエナムを使うと値がオブジェクトに変換され、既存のコードが壊れる可能性がある。

文字列定数を使う方式なら、OrderStatus::COMPLETEDは従来の'completed'と同じ文字列を生成する。開発者はより明確な名前を使いつつ、WooCommerceの動作を変えない。既存コードが動き続け、拡張機能は準備ができた時点で新しい定数に移行できる。

final class OrderStatus {
    /**
     * 注文が完了した状態
     */
    public const COMPLETED = 'completed';
    // ...
}

このコードが示すように、エナムクラスはfinalで宣言され、public constとして定数を公開する。docblockで各定数の意味をドキュメント化できるのが利点だ。クラスを継承させないことで、APIの一貫性を保つ。

利用可能なエナムクラス

利用可能なエナムクラス

現在WooCommerceのsrc/Enumsディレクトリには、4つのカテゴリにまたがるエナムクラスが用意されている。各クラスの一覧を確認しよう。

注文と商品のエナム

  • OrderStatus(プレフィックスなしの値。例としてcompleted
  • OrderInternalStatus(データベースに保存されるwc-プレフィックス付きの値)
  • OrderItemType(注文アイテムのタイプ)
  • ProductType(商品タイプ。例としてsimple
  • ProductStatus(商品ステータス)
  • ProductStockStatus(在庫状態)
  • ProductTaxStatus(税金状態)
  • CatalogVisibility(カタログの表示設定)

支払いと設定値のエナム

  • PaymentGatewayFeature(ゲートウェイがsupports配列で宣言する文字列)
  • WeightUnit(重量単位)
  • DimensionUnit(寸法単位)
  • CurrencyPosition(通貨位置)
  • TaxBasedOn(課税基準)
  • TaxDisplayMode(税表示モード)
  • DefaultCustomerAddress(デフォルト顧客住所)
  • StockDisplayFormat(在庫表示形式)
  • CatalogSortOrder(カタログ並び順)

各クラスの完全な一覧は、WooCommerceのGitHubリポジトリにあるsrc/EnumsディレクトリとREADMEで確認できる。このディレクトリが権威ある情報源として公開されている。

注文関連 OrderStatus / OrderInternalStatus / OrderItemType
商品関連 ProductType / ProductStatus / ProductStockStatus 他
支払い関連 PaymentGatewayFeature
設定値関連 WeightUnit / DimensionUnit / CurrencyPosition 他

以上の4カテゴリが、現在WooCommerceで利用可能なエナムクラスの全体像だ。注文関連と商品関連が特に充実している。

拡張機能での採用方法

拡張機能での採用方法

エナムクラスは公的に発見可能なAPIとして設計されており、publicの可視性、docblock、開発者向けドキュメントを備えている。拡張機能開発者は安心して利用できる。

基本的な使い方

使い方はシンプルだ。use文で必要なクラスをインポートし、定数を参照する。例えば注文ステータスをチェックする場合、次のように書ける。

use Automattic\WooCommerce\Enums\OrderStatus;
use Automattic\WooCommerce\Enums\ProductType;

if ( OrderStatus::COMPLETED === $order->get_status() ) {
    // 注文が完了した場合の処理
}

$products = wc_get_products( array( 'type' => ProductType::SIMPLE ) );

採用前に確認すべき2つのポイント

エナムクラスを拡張機能に導入する前に、確認しておくべきことが2つある。

1. 最小サポートWooCommerceバージョン。エナムクラスは段階的に追加されてきた。OrderStatusはWooCommerce 9.5で導入され、商品関連クラスは9.7〜9.8頃、設定値クラスは10.xシリーズで追加された。古いバージョンもサポートする場合は、文字列リテラルを使い続けるか、class_exists()でガードする必要がある。

2. WooCommerceが期待する文字列OrderStatus::COMPLETEDcompletedを返すが、OrderInternalStatus::COMPLETEDwc-completedを返す。ほとんどのWooCommerce関数はプレフィックスなしの形式を取るが、データベースレベルやpost_statusコンテキストではプレフィックス付きを使う必要がある。どちらの形式を使うべきかを意識するのが重要だ。

商品検索と注文検索の公式ドキュメントには、文字列リテラルとエナムクラスの両方の形式が併記されている。移行時の参考になる。

プレフィックスなし(API用)
OrderStatus::COMPLETED completed を返す
使用場面 wc_get_orders() などの API
プレフィックスあり(DB用)
OrderInternalStatus::COMPLETED wc-completed を返す
使用場面 post_status やデータベース操作

このデモで示したように、2つの定数は同じ注文完了状態を表すが、使用するコンテキストが異なる。混同すると期待通りに動作しない。

今後の展開

今後の展開

Developer WooCommerce Blogの記事によれば、コアに新しい語彙(文字列値の集合)を追加する場合、エナムクラスをデフォルトで付ける方針が示されている。WooCommerceコアにはまだ名前の付いていない文字列値が多数残っており、コミュニティからの貢献も歓迎している。

この変更は拡張機能開発者にとって歓迎すべき動きだ。タイプミスのリスクが減り、コードの意図が読みやすくなり、IDEの補完機能も効きやすくなる。長期的にはWooCommerceエコシステム全体のコード品質向上につながる。

一方で、移行には段階的な対応が必要だ。既存の拡張機能は古いWooCommerceバージョンとの互換性を維持しながら、徐々にエナムクラスへ移行していくことになる。一括で全置換するのではなく、新規コードから採用していくのが現実的なアプローチだろう。

この記事のポイント

  • WooCommerceがマジックストリング(生の文字列リテラル)をエナムクラスに置き換える動きを進めている
  • エナムクラスはタイプミス防止、プレフィックス区別、検索精度向上、ドキュメント統合の4つの利点を持つ
  • ネイティブPHPエナムではなく文字列定数クラスを採用した理由は、PHP 7.4互換性と既存データベースの文字列互換性
  • 注文・商品・支払い・設定値の4カテゴリにエナムクラスが用意されている
  • 採用時は最小サポートWooCommerceバージョンと、プレフィックス有無のどちらの定数を使うかを確認する
CSS random()関数を全ブラウザで動かす。polyfillの仕組みと活用法

CSS random()関数を全ブラウザで動かす。polyfillの仕組みと活用法

CSSのrandom()関数がSafariで先行実装されてから約半年。ChromeやFirefoxではまだ使えないが、そのギャップを埋めるpolyfillがnpmで公開された。この記事ではrandom()の基本構文からpolyfillの仕組みまでを解説する。

random()は要素のサイズや色、配置などをランダムに決めるCSS関数だ。これまでJavaScriptで行っていた演出を宣言的に書けるため、紙吹雪や星野のようなビジュアルエフェクトを純粋なCSSで実現できる。

ただし現時点ではSafariでしかネイティブ動作しない。そこで役立つのが、CSS-Tricksの著者が開発したcss-random-polyfillだ。この記事ではその使い方と内部動作をデモ付きで紹介する。

CSSのrandom()関数とは?Safariが先行対応した新機能

CSSのrandom()関数とは?Safariが先行対応した新機能

CSS Values and Units Module Level 5のエディタードラフトで定義されているrandom()関数は、calc()min()と同じように、プロパティの値の一部として利用できる。乱数を生成して、要素のサイズや色、角度、アニメーションの遅延時間などをランダムに設定できるのが特徴だ。

2025年後半、Safari 26.2で最初にサポートされた。WebKitチームは「一般的なユースケースをHTMLとCSSだけで解決できるようにする」という方針を掲げており、JavaScriptやサードパーティフレームワークへの依存を減らす狙いがある。

random()の基本構文

random()関数は最小値と最大値を指定する。オプションで第3引数にステップ間隔を指定できる。たとえば以下のコードは、1pxから7pxの間で1px刻みのランダムな値を生成する。

--random-star-size: random(1px, 7px, 1px);
random() 関数の引数
第1引数(最小値)
ランダム値の下限を指定する
1px
第2引数(最大値)
ランダム値の上限を指定する
7px
第3引数(ステップ間隔)
値の刻み幅を指定する。省略すると連続値になる
1px

このように、random()calc()と同じく値の一部として使える。ステップ間隔を指定すると、指定した範囲内の離散的な値(この例では1px、2px、3px…7px)だけが選ばれる。

キャッシュとキーの概念

random()には値のキャッシュを制御する仕組みがある。element-sharedfixedなどのベース値を指定すると、同じ値を複数の要素やプロパティで共有できる。たとえば、以下のコードでは4つの尖った星すべてに同じ乱数を適用する。

.star.fourpointed {
  --random-rotation: random(element-shared, -45deg, 45deg);
  rotate: var(--random-rotation);
}

element-sharedを指定すると、同じ要素に適用されるrandom()呼び出しが同じ結果を返す。これにより、複数の要素で共通のランダム値を保つことができる。

他ブラウザで使うためのpolyfillが登場

他ブラウザで使うためのpolyfillが登場

Safariが先行したrandom()だが、ChromeとFirefoxでも開発の兆しはあるものの、正式リリースの時期は未定だ。Chromeには関連する課題が報告されており、Firefoxもバグジラで進捗が追跡されている。ただし、フラグ付きでさえ使える状態にはなっていない。

この状況を受けて、CSS-Tricksの著者がcss-random-polyfillというnpmパッケージを公開した。このpolyfillを使うと、Safari以外のブラウザでもrandom()関数を利用できる。polyfillはネイティブサポートを検出し、未対応ブラウザでのみ動作する設計だ。

polyfillの使い方

polyfillを利用するには、HTMLのhead内にスクリプトを読み込み、ランダムにしたい要素にrandomizedクラスを追加する。CSSでは--randomで始まるカスタムプロパティにrandom()関数の値を格納する。


<script src="https://unpkg.com/css-random-polyfill@latest/dist/css-random-polyfill.js"></script>


<div class="randomized star"></div>
<div class="randomized star fourpointed"></div>
/* CSS */
.star {
  --random-star-size: random(1px, 7px, 1px);
  width: var(--random-star-size);
  aspect-ratio: 1/1;
  /* その他のプロパティ */
}
polyfill の処理フロー
STEP 1 ブラウザがネイティブ対応しているか判定する
STEP 2 未対応なら randomized クラスを一時的に非表示にする
STEP 3 --random で始まるプロパティを探して乱数を計算する
STEP 4 インラインスタイルに値を設定して表示を戻す

polyfillの処理はシンプルで、ネイティブサポートがある場合は何もせず、未対応の場合のみJavaScriptで乱数を計算してインラインスタイルに反映する。randomizedクラスを付けた要素だけが対象になるため、ページ全体のパフォーマンスへの影響は最小限に抑えられる。

実践デモで見るrandom()の活用例

実践デモで見るrandom()の活用例

polyfillの動作を確認するために、いくつかのデモが用意されている。ここでは代表的な例を紹介する。

ランダムな正方形デモ

最もシンプルな例として、ランダムな色とサイズの正方形を3つ配置するデモがある。CSSではrandom()を使ってカスタムプロパティを定義し、それを幅や高さ、背景色に反映する。

/* ランダムなサイズを共有する例 */
--random-height: random(--side, 40px, 100px);
--random-width: random(--side, 40px, 100px);

width: var(--random-height);
height: var(--random-width);
ランダム正方形の生成
固定値(Before)
すべて同じサイズと固定色
ランダム値(After)
サイズと色がランダムに変化。カスタムキーで幅と高さが同じ値になる

--random-height--random-widthにカスタムキー--sideを指定することで、幅と高さが同じ乱数を共有する。これにより正方形の形状を保ったままサイズだけがランダムに変化する。

星野デモと運命の車輪

より視覚的な例として、ランダムに散らばる星野デモや、回転角度がランダムになる運命の車輪デモも公開されている。星野デモでは200個の星がランダムな位置に配置され、それぞれ異なるタイミングで明滅する。

運命の車輪デモでは、回転角度をrandom(2turn, 10turn, 20deg)のように指定している。最小値と最大値はturn単位、ステップはdeg単位という異なる単位の組み合わせも可能だ。これはcalc()と同じく、同じデータ型に解決できる単位同士であれば混在できるためだ。

@keyframes spin {
  from {
    rotate: 0deg;
  }
  to {
    rotate: var(--random-rotation);
  }
}

#wheel {
  --random-rotation: random(2turn, 10turn, 20deg);
}

このコードでは、車輪が2回転から10回転の間でランダムな角度だけ回転する。ステップ間隔が20度なので、結果は20度刻みの値になる。random()を使うことで、ユーザーがページを開くたびに異なる結果になる。

polyfillの内部動作を理解する

polyfillの内部動作を理解する

このpolyfillは独自のCSSパーサーを実装しておらず、既存のオープンソースライブラリを利用している。具体的には、PostCSSプラグインとして知られる@csstools/css-calcの内部実装を活用している。このライブラリはCSSのcalc()関数を計算するために作られたもので、依存関係がなく、random()の最新仕様にも対応済みだ。

カスタムプロパティの許容性を活用

polyfillの鍵となるのは、CSSカスタムプロパティの値が「非常に許容度が高い」という仕様だ。ブラウザがrandom()関数を理解できなくても、カスタムプロパティの値としては文字列として保持される。たとえば以下のような式は、未対応ブラウザでもエラーにならず、JavaScriptから読み出せる。

/* ブラウザが解釈できなくてもエラーにならない */
--random-grid-area: random(1, var(--rows), 1) / random(1, var(--columns), 1);

ブラウザはvar()参照を解決してから値を文字列として保持するため、polyfillはgetComputedStyle()で値を読み取り、乱数を計算してインラインスタイルとして書き戻す。この手法は、スタイルシートを書き換えたり再取得したりする必要がないため、従来のCSS polyfillにありがちな副作用を回避できる。

処理の流れ

polyfillの動作は以下のJavaScriptコードに要約されている。ネイティブサポートを判定し、未対応の場合のみ--randomプレフィックスの付いたプロパティを収集して乱数を計算する。

import { calc } from "@csstools/css-calc";
const calcFn = calc;

if (!CSS.supports("width", "random(0px, 100px)")) {
  // 要素を一時的に非表示にしてフリッカーを防ぐ
  // --random プレフィックスのプロパティを収集
  // @csstools/css-calc で乱数を計算
  // インラインスタイルに反映
}

注意点として、random()のキャッシュ制御に関わる部分がある。仕様ではelement-sharedfixedなどのベース値を指定できるが、未指定の場合にライブラリが均等な分布で乱数を生成しないことがある。この問題を回避するため、polyfillでは乱数値を明示的に注入するパッチを適用している。

random-item()を模倣する実験と今後の展望

random-item()を模倣する実験と今後の展望

CSS Values and Units Module Level 5には、random()と似たrandom-item()という関数が定義されている。これは与えられたリストからランダムに1つの値を選ぶ関数だ。しかし、現時点ではどのブラウザも実装していない。

Chromiumベースのブラウザでは、CSSカスタム関数とインライン条件分岐を組み合わせることで、random-item()に近い機能を実現できる。たとえば、以下のコードはリストからランダムに1つの色を選ぶ。

--random-index: random(element-shared, 1, 5, 1);
--random-color: --item(var(--random-index), aqua, purple, pink, grey, green);

これを実現するカスタム関数--itemは、インデックス番号に応じて対応する引数を返す。CSSカスタム関数は可変長引数をサポートしないため、事前に想定される最大数だけ引数を定義しておく必要がある。

@function --item(--index,
  --arg-1: ,
  --arg-2: ,
  --arg-3: ,
  --arg-4: ,
  --arg-5: ) {
  result: if(
    style(--index: 1): var(--arg-1);
    style(--index: 2): var(--arg-2);
    style(--index: 3): var(--arg-3);
    style(--index: 4): var(--arg-4);
    else: var(--arg-5);
  );
}

この手法は、CSS-Tricksの著者が「ハックではなく、意図された標準機能の使い方」と述べている。かつてTemani Afif氏が行った色リストの実装はハックに近いものだったが、カスタム関数を使えば任意のデータ型で動作する汎用的な解決になる。ただし、CSSカスタム関数もまだすべてのブラウザで利用できるわけではないため、現時点ではChromium限定の実験的な機能だ。

この記事のポイント

  • CSS random()関数はSafariが先行対応。ChromeとFirefoxは対応時期が未定
  • polyfillを使えば他ブラウザでもrandom()を利用できる
  • 使い方は--randomプレフィックスのカスタムプロパティとrandomizedクラスを設定するだけ
  • polyfillはカスタムプロパティの許容性を利用し、@csstools/css-calcで乱数を計算する
  • Chromiumではカスタム関数と組み合わせてrandom-item()を模倣可能
Bun v1.4.1リリース。アイドル時メモリ削減とバンドルサイズ最大85%減の全容

Bun v1.4.1リリース。アイドル時メモリ削減とバンドルサイズ最大85%減の全容

Bun v1.4.1が2026年9月4日にリリースされた。202件の問題を修正し、236件のリアクションに対応したメンテナンスリリースだ。アイドル時のメモリ削減、HTTP/2対応、バンドルサイズの大幅な最適化が含まれている。

特にNext.js SSRのアイドル時RSSは222MBから142MBへ削減された。bun buildではzod 4.5のバンドルサイズが375.3KBから77.3KBへ79%減っている。長期稼働するサーバーや大きなモノレポを扱う開発者にとって、実務に直結する変更だ。

この記事では、実務に影響する主要な変更点をランタイム、bun install、bun build、bun testの順に解説する。

Bun v1.4.1の概要と導入

Bun v1.4.1の概要と導入

BunはNode.js互換のJavaScriptランタイムであり、パッケージマネージャやバンドラー、テストランナーも備える。v1.4.1ではアイドル時のメモリ使用量の削減、Bun.serveのHTTP/2対応、bun buildのバンドル最適化が目玉だ。

インストールとアップグレード

Bunのインストール方法は複数用意されている。macOSやLinuxではcurlコマンド、npmを使う方法、Windowsではpowershellやscoop、macOSではbrew、Dockerイメージも提供される。既存環境のアップグレードは bun upgrade で完了する。

curl -fsSL https://bun.sh/install | bash
npm install -g bun
bun upgrade

このリリースの位置づけ

v1.4.1は202件の問題を修正した。前バージョンv1.4.0で入った回帰の修正も多い。新機能として、ランタイムのメモリ削減、bun installのオフライン対応、bun buildのコード分割改善、bun testの分離実行の修正が盛り込まれた。

ランタイムのメモリ削減と高速化

ランタイムのメモリ削減と高速化

アイドル時のメモリ使用量を大幅削減

BunのJavaScriptエンジンであるJavaScriptCoreが、長時間のアイドル期間後にJIT生成コードを破棄するようになった。これにより、長期稼働するプロセスのメモリ使用量が大きく減る。負荷を60秒かけた後、3分間アイドル状態にしたLinux x64環境のRSSは、Next.js SSRで142MB、vite devで111MB、Expressで53MBだった。前バージョンではそれぞれ222MB、142MB、65MBである。

従来のBun v1.4.0(Before)
Next.js SSR 222 MB
vite dev 142 MB
Express 65 MB
Bun v1.4.1(After)
Next.js SSR 142 MB
vite dev 111 MB
Express 53 MB

上記は60秒の負荷後、3分間アイドル状態にしたときのRSSをLinux x64で比較した結果だ。アイドル時にJITコードを消す仕組みにより、常駐プロセスのメモリコストが抑えられている。

AsyncLocalStorageとBufferの高速化

AsyncLocalStorage.run() が約2倍高速になった。アクティブなストアがあるとき、await.then().finally() のたびに余分なメモリ確保が発生しなくなったためだ。Node.js 26との比較では、als.run() が15.9ns/op、Node.jsの410ns/opに対して大幅に速い。

Bufferの読み書きも高速化された。writeFloatLE() は2.85nsから0.31nsへ9.2倍、writeUInt8() は2.24nsから0.31nsへ7.2倍、readUInt32BE() は0.76nsから0.42nsへ1.8倍速くなった。macOS arm64の計測だ。

モジュール読み込みと表示処理の高速化

組込みNode.jsモジュールの require() が遅延初期化になった。node:assert は6.22msから0.64msへ、node:fs は2.75msから0.87msへ短縮されている。テストやCLIツールの起動時間に効く変更だ。

オブジェクト表示も高速化した。1万6,000個のキーを持つオブジェクトの Bun.inspect() は140msから3.2msへ43倍速くなった。テキストの色付けや console.log()util.inspect() にも同じコードが使われる。

HTTPSの初回接続も最大3倍速くなった。ルート証明書をDER形式で埋め込み、必要になった時だけ解析する方式へ変更したためだ。--use-system-ca を使う場合は46.3msから15.3msへ短縮された。

Bun.serveとWeb APIの強化

Bun.serveとWeb APIの強化

HTTP/2対応とTLS検証の変更

Bun.serve() がHTTP/2を同一ポートでサポートした。TLS接続ではALPNでプロトコルを自動ネゴシエーションし、平文接続ではHTTP/2 prefaceを送ってきたクライアントにHTTP/2で応答する。http1 オプションをfalseにすればHTTP/1.xクライアントを拒否できる。WebSocketとレスポンストレーラーはHTTP/2では未対応だ。

セキュリティ面では、fetch() のTLS検証がURLのホスト名を基準に変更された。従来はカスタム Host ヘッダーをTLSサーバー名として使っていた。プロキシなどでユーザー入力のHostヘッダーを渡す場合があるため、この変更は重要だ。IPアドレスに接続して別名で証明書を検証したい場合は tls.servername を指定する。

WebSocketのpauseとresume

BunのWebSocketクライアントに pause()resume() が追加された。メッセージの処理速度が受信速度に追いつかないとき、TCPソケットからの読み取りを停止できる。停止中はメモリにメッセージが溜まらず、送信側にはTCPバックプレッシャーが伝わる。

const socket = new WebSocket("wss://example.com/feed");

socket.addEventListener("message", (event) => {
  if (!file.write(event.data)) {
    socket.pause();
    file.once("drain", () => socket.resume());
  }
});

これはBun独自の拡張であり、ブラウザでは利用できない。pause中のソケットは socket.isPaused で状態を確認できる。bufferedAmount も送信待ちバイト数を正しく報告するようになった。

Bun.writeのストリーミング書き込み

Bun.write()ResponseReadableStream の本文を、いったんメモリに読み込まずにファイルへストリーミングするようになった。128MiBのダウンロードを書き込むケースでは、ピークRSSの増加が161MBから13MBへ減った。

bun installのオフライン対応とワークスペース改善

bun installのオフライン対応とワークスペース改善

–offlineと–prefer-offline

bun install --offline はネットワーク要求を一切行わない。すべてのパッケージがキャッシュに存在する必要があり、CIでキャッシュを復元するケースやネットワークに接続できないマシン向けだ。キャッシュに無いパッケージがあると、その名前を明示したエラーになる。

bun install --prefer-offline はキャッシュを優先する。期限切れでもキャッシュのコピーを使い、キャッシュに無いパッケージだけダウンロードする。どちらも bunfig.toml に設定すればデフォルトにできる。

通常の bun install
キャッシュの有効期限が切れると、新しいバージョンを確認するためメタデータを再取得する
bun install –prefer-offline
期限切れでもキャッシュを優先する。キャッシュにないパッケージだけダウンロードする
bun install –offline
ネットワーク要求を一切行わない。キャッシュに無いパッケージがあればエラーになる

self-contained node_modules

ワークスペースのpackage.jsonに "selfContained" を指定すると、そのパッケージ専用の node_modules が作られる。Electronのように特定の node_modules レイアウトを期待するツール向けだ。Yarnの hoistingLimits 設定も利用できる。

bun buildのバンドル最適化とコンパイル改善

bun buildのバンドル最適化とコンパイル改善

export * asによるバンドルサイズ削減

zodやEffectのように export * as でエクスポートをまとめるライブラリで、未使用エクスポートのツリーシェイクが効くようになった。v1.4.0では z.object() を呼んだ場合でもグループの全エクスポートを保持していた。v1.4.1では直接参照にコンパイルされ、不要なエクスポートが削除される。

Bun v1.4.0(Before)
zod 4.5 375.3 KB
fp-ts 2.16 21.8 KB
effect 3.22 369.1 KB
Bun v1.4.1(After)
zod 4.5 77.3 KB (79%削減)
fp-ts 2.16 3.2 KB (85%削減)
effect 3.22 163.6 KB (56%削減)

各ライブラリから2〜3個の関数だけを呼ぶ小規模なプログラムを、bun build --minify でビルドした結果だ。zodでは252個のエントリを持つ名前空間オブジェクトが生成されていたが、v1.4.1ではすべて削除された。

動的importのtree-shakingとコード分割

import() で読み込むモジュールでも、未使用のエクスポートが削除されるようになった。const { z } = await import("zod") は静的な import { z } from "zod" と同じコードにバンドルされる。zod 4.5では377.9KBから78.2KBへ縮む。

--splitting も改善された。40個の遅延ルートを持つテストアプリでは、出力ファイルが219個から151個に、出力サイズが124KBから75KBに減った。さらに --min-chunk-size オプションで小さなチャンクを統合できる。ブラウザ向けビルドでは link rel="modulepreload" が自動追加され、チャンクのフェッチが並列化される。

–compileの起動高速化とバイトコード削減

コンパイル済み実行ファイルの起動も速くなった。BunでコンパイルされたClaude Codeでは、入力ボックスが表示されるまでの時間が397msから318msへ20%短縮された。バイトコードのサイズも最適化され、これまで元ソースの約9倍だったものが約3倍になった。Claude Codeのインストールサイズは376MBから207MBへ45%減っている。

--bytecode-depth で事前コンパイルする関数のネスト深度を制限できる。--bytecode を付けたクロスコンパイルもmacOSやLinuxからWindows x64へ対応した。テキストインポートは1回だけ埋め込まれ、実行時の解析とコピーが不要になった。

この記事のポイント

  • Bun v1.4.1は202件の問題を修正し、アイドル時のメモリ使用量を大幅に削減した
  • Bun.serveがHTTP/2に対応し、WebSocketにpauseとresumeが追加された
  • bun installにオフラインモードが加わり、CIやネットワーク遮断環境で使いやすくなった
  • bun buildはzodやEffectのバンドルサイズを最大85%削減し、コード分割も改善した
  • bun build –compileは起動時間とバイトコードサイズを最適化した
WooCommerce 11.1.0リリース。バリエーション画像ギャラリーが標準機能に

WooCommerce 11.1.0リリース。バリエーション画像ギャラリーが標準機能に

WooCommerce 11.1.0が2026年9月1日にリリースされた。今回のアップデートでは商品バリエーション画像ギャラリーが標準機能となり、専用プラグインが不要になった。Store APIとREST APIの応答速度も最大42%改善している。

今回のリリースは後方互換性を保っており、データベース更新を伴う。561件のプルリクエストがマージされ、77人のコントリビューターが参加した。WooCommerceを運用しているECサイトでは更新前に変更点を把握しておきたい。

この記事ではWooCommerce 11.1.0の主要な変更点を、店舗運営者向けと開発者向けに分けて解説する。更新作業の前に確認すべき注意点もまとめた。

WooCommerce 11.1.0の主な変更点

WooCommerce 11.1.0の主な変更点

WooCommerce 11.1.0では店舗運営者に直接影響する機能追加と、開発者向けの内部改善が同時に行われた。本番サイトへの適用前には公式の更新ガイドとチェンジログを確認することが推奨されている。

店舗運営者に影響する変更は3つある。1つ目は商品バリエーション画像ギャラリーの標準搭載、2つ目はEU顧客向け注文撤回フォームの追加、3つ目は仮想商品の管理画面表示の改善だ。これに加えて商品ギャラリーへの動画対応がベータ機能として導入された。

開発者向けにはブロックエディタアセットの統合、ブロック登録処理の最適化、注文アイテム削除ロジックの修正などが含まれる。特にStore APIとREST APIの応答速度は30%から42%改善しており、ヘッドレス構成や外部連携を運用している場合に効果が大きい。

WooCommerce 11.1.0の変更分類
店舗運営者向け バリエーション画像ギャラリーの標準化
店舗運営者向け EU顧客向け注文撤回フォームの追加
パフォーマンス Store APIとREST APIを最大42%高速化
ベータ機能 商品ギャラリーへの動画対応
店舗運営者向け  パフォーマンス改善  ベータ機能

上記デモはWooCommerce 11.1.0の変更点を影響範囲ごとに分類したものだ。青と緑が店舗運営者向け、オレンジがパフォーマンス改善、紫が実験的ベータ機能に該当する。

商品バリエーション画像ギャラリーが標準機能に

商品バリエーション画像ギャラリーが標準機能に

WooCommerce 11.1.0で、商品バリエーションごとに複数の画像を持たせる「バリエーション画像ギャラリー」が全ストアで標準機能として有効化された。これまでこの機能は「WooCommerce Additional Variation Images」という別プラグインで提供されていたが、今回のリリースをもって公式の専用プラグインは提供終了となる。

バリエーション画像ギャラリーとは、商品のサイズやカラーといったバリエーションごとに、複数の商品写真や画像を登録できる仕組みだ。たとえばサイズ違いのTシャツ商品で、MサイズにはMサイズの着用写真を複数枚登録し、LサイズにはLサイズの写真を複数枚登録できる。購入希望者が自分に合ったサイズの写真だけを確認できるため、購入決定の精度が上がる。

今回の標準化では設定画面の実験的機能フラグが削除された。データベース更新(11.1.0-1)により、過去に実験的フラグをオフにしていたストアでも自動的に有効化される。個別に切り替える必要はなく、WooCommerceを11.1.0に更新すれば全ストアで利用できる。

11.1.0以前(Before)
追加プラグイン 必須 プラグイン終了予定
バリエーション画像ギャラリーを利用するには専用プラグインの導入が必要だった。設定も個別のプラグイン管理画面から行う必要がある。
11.1.0以降(After)
WooCommerce標準機能 追加費用なし 全ストアで自動有効化
WooCommerce 11.1.0に更新するだけで全ストアで利用できる。実験的フラグは削除され、データベース更新で自動的に有効化される。

専用プラグインが不要になり、バリエーション画像ギャラリーはWooCommerceの標準仕様となった。既存の専用プラグインユーザーも移行作業なしでそのまま利用できる。

Store APIとREST APIのパフォーマンス改善

Store APIとREST APIのパフォーマンス改善

WooCommerce 11.1.0ではStore APIとREST APIの応答速度が大幅に改善された。ブロックタイプとパターンの登録処理が、ブロックを描画できないリクエストではスキップされるようになったことが主な要因だ。

Store APIとは、WooCommerceの商品データや注文データを外部から利用するためのAPIだ。ヘッドレス構成でフロントエンドとWooCommerceを接続する場合や、モバイルアプリから商品情報を取得する場合に使われる。REST APIも同様に外部連携の窓口となる。

今回の変更により、ブロックタイプ(block types)とパターン(patterns)の登録が、ブロックを描画・編集できないリクエストでは実行されなくなった。これまではAPIリクエストでも無駄にブロック関連の処理が走っていたため、応答時間が長くなっていた。変更後はStore APIとRESTリクエストの速度が30%から42%向上した。

11.1.0以前のAPIリクエスト(Before)
APIリクエスト ブロック登録処理 無駄に実行
ブロックを描画できないAPIリクエストでも、ブロックタイプとパターンの登録処理が実行されていた。これが応答時間を長くする要因になっていた。
11.1.0以降のAPIリクエスト(After)
APIリクエスト ブロック登録をスキップ 30〜42%高速化
ブロックを描画・編集できないリクエストでは登録処理がスキップされる。Store APIとREST APIの応答速度が最大42%改善した。

このデモはAPIリクエスト時の処理フロー変化を示している。ブロック登録の最適化は店内回遊の速度向上ではなく、外部連携やヘッドレス構成での応答性能に直接効く変更だ。

EU顧客向け注文撤回フォームの追加

EU顧客向け注文撤回フォームの追加

WooCommerce 11.1.0ではEU圏の規制に準拠するための「注文撤回フォーム」が追加された。デフォルトでは無効になっており、EUガイドラインへの準拠が必要なストアが手動で有効化する形だ。

注文撤回とはEUの消費者保護規則に基づく権利で、消費者が商品を受け取ってから一定期間内に購入をキャンセルできる仕組みだ。ストア側はこの権利に応じた返金・返品プロセスを用意する必要がある。今回追加されたフォームは、その撤回申請を顧客自身がオンラインで提出するための画面をマイアカウントページに作成する。

撤回申請が提出されるとシステムに記録され、ストア運営者にはメール通知と管理画面のダッシュボード通知が送られる。ただし実際の注文撤回処理と返金作業は手動で行う必要がある。各ストアのポリシーや商品特性によって処理手順が異なるためだ。

STEP 1 顧客がマイアカウントページで注文撤回フォームを開く
STEP 2 顧客が注文撤回リクエストをオンラインで提出
STEP 3 システムに記録され運営者へメールとダッシュボードで通知
STEP 4 運営者が返金・返品処理を手動で実行

注文撤回フォームはデフォルト無効のため、通常の国内向けストアでは追加設定は不要だ。EU向け販売を行うストアはWooCommerceの設定画面から有効化できる。

商品ギャラリーの動画対応と仮想商品の表示改善

商品ギャラリーの動画対応と仮想商品の表示改善

WooCommerce 11.1.0では商品ギャラリーへの動画対応がベータ機能として追加された。クラシックテーマとブロックテーマの両方の商品ギャラリーで動画を表示できる。

初期リリースではローカルにアップロードした動画のみが対応する。外部ホスティングの動画URL(YouTubeやVimeoなど)は現時点ではサポートされていない。実験的機能のため、今後のリリースで仕様が変更される可能性がある。

この機能はデフォルトでは無効になっている。有効化するにはWooCommerceの設定画面から「設定 → 詳細 → 機能」と進み、「商品ギャラリー動画」をオンにする必要がある。商品の見せ方を動画で強化したいストアはテスト環境での検証を推奨する。

仮想商品の管理画面表示が整理された

発送処理が不要な仮想商品のみの注文では、管理画面の注文サマリーに配送先住所が表示されないようになった。これまでStore APIのチェックアウト処理が互換性維持のために請求先住所から配送先住所を生成していたため、仮想商品のみの注文でも意味のない住所が表示されていた。

この変更により、仮想商品のみの注文画面がすっきりと整理される。実際の住所データが削除されるわけではなく、表示されなくなるだけだ。物理商品を含む注文や、配送情報が未確定の注文では従来どおり住所が表示される。

開発者向けの変更点

開発者向けの変更点

WooCommerce 11.1.0には複数の開発者向け変更が含まれる。ブロックエディタアセットの統合、注文アイテム削除ロジックの修正、WooCommerce Adminの安定済みフィーチャーフラグ廃止などだ。

統合ブロックエディタアセット(実験的)

実験的な新機能として、ブロックエディタ向けのJavaScriptとCSSファイルが統合された。これまでWooCommerceのブロックはそれぞれ個別のスクリプトとスタイルを読み込んでいたが、共有バンドルにまとめることでエディタ画面でのリクエスト数と総サイズが削減される。

デフォルトでは無効になっており、11.1.0では影響が出ない。有効化した場合もフロントエンド側のアセットは変更されず、既存のブロックハンドルは従来どおり動作する。管理画面の編集速度を改善したいストアは検討の余地がある。

注文アイテム削除ロジックの修正

WooCommerceの注文アイテム削除処理に含まれていた潜在的なバグが修正された。更新前は、拡張プラグインが注文保存前に差し込んだ置換用アイテムが、削除処理によって誤って消される可能性があった。

具体的にはWC_Abstract_Orderクラスのremove_order_itemsメソッドが、削除要求時に存在していたアイテムIDを記録するようになった。これにより拡張プラグインが追加したアイテムが誤って削除されるのを防ぐ。9割以上の拡張プラグインではコード変更は不要だが、カスタム注文データストアを実装している場合はget_item_idsとdelete_items_by_idsの実装を確認する必要がある。

安定済みフィーチャーフラグの廃止

WooCommerce Adminの安定機能として採用済みのフィーチャーフラグの一部が、設定パイプラインを介さず直接読み込まれるようになった。機能自体は削除されておらず、互換性維持のための互換レイヤーも残されている。

互換レイヤーはFeatures::is_enabled()とwindow.wcAdminFeaturesに対して従来の値を返し続けるが、非推奨警告を出力するようになった。自作の拡張プラグインでフィーチャーフラグに依存している場合は、互換レイヤーが撤去される前に対応を進めておきたい。

この記事のポイント

  • バリエーション画像ギャラリーがWooCommerce標準機能として全ストアで有効化された
  • 専用プラグイン「WooCommerce Additional Variation Images」は提供終了となる
  • Store APIとREST APIの応答速度が最大42%向上した
  • EU顧客向け注文撤回フォームが追加された(デフォルトでは無効)
  • 商品ギャラリーの動画対応はベータ機能としてデフォルト無効で提供される
  • 仮想商品のみの注文では管理画面に配送先住所が表示されなくなった
Google DeepMindがWeatherNext 3を発表、5km解像度で毎時更新する気象AIモデル

Google DeepMindがWeatherNext 3を発表、5km解像度で毎時更新する気象AIモデル

Google DeepMindとGoogle Researchが2026年9月3日、気象予測AIの最新モデル「WeatherNext 3」を発表した。解像度は従来比約5倍の5kmに達し、予測更新も6時間間隔から1時間間隔へ大幅に短縮されている。

独立評価機関Brightbandのライブ評価によると、現時点で最も高精度な全球気象モデルとされている。降水予測の精度指標CRPSは最大60%改善し、Google検索やGeminiアプリなど主要サービスへの統合も始まった。

この記事ではWeatherNext 3の技術的な進化、予測精度の具体的な数値、再生可能エネルギー分野への応用、そしてGoogleエコシステムへの展開を解説する。気象AIの最前線がどこまで来たのかを俯瞰できる内容だ。

WeatherNext 3の概要と従来モデルからの進化

WeatherNext 3の概要と従来モデルからの進化

WeatherNext 3は、WeatherNext 2の後継として開発された全球気象予測モデルだ。最大の特徴は、従来の数値予報モデル(NWP)の出力データではなく、衛星や地上観測所から得られるリアルタイムの観測データを直接学習することにある。

NWPモデルとは、スーパーコンピュータ上で物理方程式を解いて大気の状態をシミュレーションする仕組みのこと。精度は高いものの計算コストが膨大で、データ生成に6時間程度の遅延が生じる。この遅延が雨や地表温度など変化の速い変数の予測にバイアスを生んでいた。

WeatherNext 2から何が変わったのか

WeatherNext 2は25kmグリッド、6時間間隔の予測だった。WeatherNext 3では地表の気温や湿度を5km解像度、その他の地表変数を10km、風速などの大気変数を25kmで出力する。予測頻度も1時間ごとに大幅改善した。

解像度が5倍になったことで、海岸線や谷、山脈といった複雑な地形に起因する局地的な気象変化を捉えられるようになった。従来モデルではピクセル化されて平滑化されていた気温分布が、WeatherNext 3では実際の地形に沿った精緻な表示になる。

FGNメッシュトランスフォーマーとは

WeatherNext 3の中核には、FGN(Functional Generative Network)メッシュトランスフォーマーと呼ぶ単一の柔軟なモデルが採用されている。1時間ごとの静止衛星モザイク画像と従来の解析データを取り込み、高密度のグリッド予測、サイクロン進路の離散的な追跡、観測所レベルの座標予測を同時に出力する設計だ。

「単一のモデルで複数の出力形式を扱える」という点が実用上重要になる。従来は目的ごとに別モデルを用意する必要があったが、WeatherNext 3は1つのモデルで全球予測から地点予測までをカバーする。インフラの複雑さが減り、運用コストも抑えられる。

5km解像度と毎時更新の実現

5km解像度と毎時更新の実現

天気予報の実用性は、時間と空間をどれだけ細かく解像できるかで大きく変わる。WeatherNext 3は全球規模で5kmグリッドの予測を毎時生成する。これはWeatherNext 2の約5倍の鮮明さだ。

5km解像度という数字の意味を具体的に考えると、都市の区単位、郊外の町単位での気温や湿度の違いを表現できるレベルになる。25kmでは県単位の大まかな傾向しか見えなかったものが、より生活に密着した予測になる。

WeatherNext 2(従来モデル)
25kmグリッド・6時間間隔
地形が粗く、気温分布がのっぺりした表示になる。急な天候変化への対応も遅れる
WeatherNext 3(新モデル)
5kmグリッド・1時間間隔
複雑な地形や局地的な気象変化を細かく捉え、最新の衛星観測に基づいて毎時更新する

上の比較は解像度と更新頻度の差を概念的に示したものだ。実際の予測では、WeatherNext 3は英国上空の2m気温分布で、海岸線や丘陵地の起伏に沿った精緻な温度勾配を描き出す。従来モデルで見られたピクセル状の平滑化は解消された。

毎時更新が可能にした迅速な対応

気象現象の中でも、嵐や前線、降水システムは突発的に発生し急速に発達する。6時間間隔の更新では、こうした急変を捉えきれず、警報や避難判断の遅れにつながる可能性があった。

WeatherNext 3は最新の衛星観測データを毎時取り込み、その都度新しい予測を生成する。気象災害への早期警戒という観点で、更新頻度の短縮は解像度向上と同等かそれ以上の実用的価値を持つ。防災担当者にとって、1時間でも早く精度の高い情報を得られることは意思決定の質を直接左右する。

衛星データと地上観測データの直接学習

衛星データと地上観測データの直接学習

WeatherNext 3の技術的なブレークスルーは、学習データの質的転換にある。従来のAI気象モデルはNWPモデルの出力を訓練データとして使っていたが、WeatherNext 3は観測データそのものを学習する。

静止衛星モザイクデータの取り込み

WeatherNext 3は、全球をカバーする静止衛星のモザイク画像をリアルタイムで取り込む。静止衛星とは赤道上空の特定位置に固定され、地球の同じ領域を継続的に観測する衛星のこと。このデータにより、大気の状態を途切れることなく最新の状態で把握できる。

NWPモデルの出力には6時間の遅延があるのに対し、衛星観測データはほぼリアルタイムに近い。変化の速い雨や地表温度などの変数で、この遅延が予測バイアスを生むことは前述のとおりだ。衛星データ直接学習は、この遅延問題を根本から解消する。

WeatherNext 3のデータフロー
静止衛星データ 1時間ごとの全球モザイク画像をリアルタイムで取得
WeatherNext 3 FGNメッシュトランスフォーマーが学習・推論
予測出力 5km解像度の全球予測・サイクロン進路・観測所別予測
入力データ  AIモデル  出力結果

このデータフロー図はWeatherNext 3の処理の流れを簡略化したものだ。衛星観測データがモデルに直接入力され、多様な形式の予測が単一モデルから出力される。

地上観測所データによる局地予測の改善

衛星データに加えて、WeatherNext 3は地上気象観測所のスパースな観測データも直接学習する。「スパース」とは観測点がまばらに分布している状態を指す。従来モデルは大気の表現が粗く、海岸線や谷、山脈付近の極端な局地変化を見逃していた。

観測所データを直接学習することで、WeatherNext 3は地形の影響を受けた局地的な気温・湿度の変動を5kmグリッドで表現できるようになった。この改善は、従来はスーパーコンピュータによる地域モデルの運用コストが高く、高解像度予測の提供が難しかった中南米・アフリカ・アジア太平洋地域で特に大きな意味を持つ。数十億人規模の人々とビジネスに、局地化された高精度予測をもたらす可能性がある。

降水予測精度のブレークスルー

降水予測精度のブレークスルー

全球気象モデルが最も苦手とするのが降水予測だ。雨や雪は雲内部の微細なプロセスに駆動され、物理シミュレーションでは正確なモデル化が困難だった。AI予測でも、降水域がぼやけたり暴風雨の境界を捉え損ねたりする問題が残っていた。

降水予測が難しい理由

降水は大気の状態が局所的に急変することで発生する。数百メートル単位の雲の動きが数キロ先の降水の有無を決めることもあり、全球モデルのグリッドでは捉えきれない微細な現象だ。さらに降水データ自体の品質も重要になる。観測網が密な地域と疎な地域で、モデルの学習に使えるデータ量に差が生じる。

WeatherNext 3はこの問題に対処するため、2つの高品質な降水データソースを学習に使っている。1つはNASAの衛星降水観測システムIMERG、もう1つは衛星レーダーに基づくGoogle独自の全球降水再解析データだ。再解析とは、観測データとモデルを組み合わせて過去の大気状態を統一的に再構築する手法を指す。

精度評価の具体的な数値

WeatherNext 3の降水予測精度は、複数の基準データに対して大幅な改善を示している。CRPS(連続ランク確率スコア)と呼ぶ予測精度の指標で、IMERG比で最大60%、MRMS比で30%、雨量計測定比で10%の改善が確認された。CRPSは予測分布と実際の観測値のずれを測る指標で、値が小さいほど予測が正確であることを意味する。

WeatherNext 2(従来モデル)
降水域がぼやけて広がり、豪雨の境界線が不鮮明。暴風雨の範囲を過大または過小に評価する
WeatherNext 3(新モデル)
実際の衛星観測に近い鋭い降水バンドを捉え、対流性の気象システムの境界を正確に再現する

上の比較は降水予測の質の違いを概念的に示したものだ。実際の評価では、WeatherNext 3は11km解像度でWeatherNext 2の25km解像度を大きく上回り、衛星観測の真値に近い降水分布を再現している。

再生可能エネルギーとGoogleエコシステムへの展開

再生可能エネルギーとGoogleエコシステムへの展開

WeatherNext 3の進化は予測精度の向上にとどまらない。再生可能エネルギー生産に特化した予測機能を備え、Googleの主要サービスへの統合も始まっている。

風力・太陽光発電向けの専用予測

WeatherNext 3は風力発電のタービン高さに相当する100mの風速を予測する。太陽光発電向けには、高解像度の雲量と日射量の予測を提供する。これにより、発電事業者は太陽光パネルが地上で受け取る光量を事前に把握できる。

再生可能エネルギーは天候に発電量が直接左右される。電力網の運用者は、風力・太陽光の発電量を正確に予測できれば、需要とのマッチングを最適化できる。天気予報の精度向上は、クリーンエネルギーの経済性と安定供給に直結する。この分野での高精度予測の価値は、今後さらに高まると見られている。

Googleサービスとデベロッパー向け提供

WeatherNext 3は発表当日から、Google検索、Geminiアプリ、Google Maps、Google Maps Platform Weather API、Google Earth Engineで気象体験を強化し始めた。特に降水予測では、1日以上先の計画時に最大50%の精度向上が見込まれる。予測精度の改善幅は、従来予測の信頼性が低かった地域ほど大きい。

デベロッパーや研究者向けには、BigQueryとEarth Engineでデータ照会が可能になり、Google Cloud Storageからのバルクダウンロードにも対応する。モデル設定不要で、毎時更新される全球予測データを自社のワークフローに組み込める。

なお、公式の気象警報や防災情報については、各国の気象機関や国家気象サービスを参照する必要がある。WeatherNext 3はあくまで研究開発段階のAIモデルであり、公的な警報システムを代替するものではない。

この記事のポイント

  • WeatherNext 3は解像度5kmで毎時更新する全球気象AIモデル。WeatherNext 2比で約5倍の鮮明さ
  • NWPモデルの出力ではなく衛星・地上観測所のリアルタイムデータを直接学習する設計に転換
  • 降水予測のCRPSがIMERG比で最大60%改善し、暴風雨の境界線を正確に捉える
  • 風力・太陽光発電向けの専用予測を実装し、再生可能エネルギーの需給マッチングを支援
  • Google検索、Geminiアプリ、Mapsなど主要サービスへの統合とBigQueryやEarth Engineでのデータ提供を開始
Astro 7.2が登場、増分静的ビルドを実験導入。大規模サイトのビルド時間短縮に道

Astro 7.2が登場、増分静的ビルドを実験導入。大規模サイトのビルド時間短縮に道

Astro 7.2が2026年8月末にリリースされた。今回のマイナーアップデートでは、実験的な増分静的ビルド機能が追加されている。変更したページだけを再ビルドする仕組みで、大規模サイトのビルド時間を大幅に短縮できる可能性がある。あわせて、開発プレビューのバックグラウンドモードや相対ロガーエントリポイントも導入された。

Astroはコンテンツ中心のWebサイトを高速に構築するためのフレームワークだ。ビルド時に静的HTMLを生成し、必要な部分にだけJavaScriptを追加するアイランドアーキテクチャを採用している。今回の増分静的ビルドは、数千ページ規模のサイトで毎回フルビルドする非効率を解消する一手となる。

プロジェクト体制にも動きがあった。AstroのプロジェクトスチュワードがMatthew Phillips氏に交代している。Microsoftが公式ドキュメントサイトにAstroを採用するなど、エコシステムの広がりも加速している。本記事では、Astro 7.2の技術的な中身と、開発者コミュニティの最新動向を整理して伝える。

増分静的ビルドとは何か。Astro 7.2が示すビルド高速化の方向性

増分静的ビルドとは何か。Astro 7.2が示すビルド高速化の方向性
従来のフルビルド(Before)
全ページ ビルド実行 全HTML再生成
1ページの編集でも全ページを再処理するため、数千ページ規模ではビルド時間が膨らむ
増分静的ビルド(After)
変更ページのみ 差分検出 該当HTMLのみ再生成
変更の影響範囲だけを再ビルドするため、ビルド時間がページ数に依存しにくくなる

このデモは増分静的ビルドの概念を視覚化したイメージだ。静的サイトジェネレーターの多くは、1ページでも更新すると全ページを再ビルドする。増分ビルドはその常識を覆す。

増分静的ビルドとは、前回のビルド結果と現在のソースコードを比較し、変更の影響を受けたページだけを再生成する仕組みだ。たとえばブログ記事を1本追加した場合、カテゴリ一覧やタグページ、RSSフィードなど関連するページは再生成が必要だが、無関係な過去記事や固定ページはそのまま流用できる。この差分検出によって、ビルド全体の処理量を大幅に削減できる。

なぜ増分ビルドが重要なのか

静的サイトのビルド時間は、ページ数が増えるほど長くなる傾向がある。1,000ページを超える規模になると、フルビルドに数分から数十分かかることも珍しくない。開発中にプレビューを確認するたびに待たされるのは、開発体験を大きく損なう。

増分ビルドが実用化すれば、ビルド時間は変更の影響範囲に比例するようになる。1ページの記事を追加しただけで全ページを再処理する必要がなくなるため、大規模サイトほど恩恵が大きい。とくに企業ブログやドキュメントサイト、ECサイトの商品ページ一覧など、ページ数の多いコンテンツサイトで効果を発揮する。

実験段階の注意点と将来性

Astro 7.2の増分静的ビルドは実験的な機能として提供されている。プロダクション環境での利用はまだ推奨されておらず、今後のリリースで挙動が変わる可能性がある。ただし、Astroチームがこの機能を前面に押し出してきたことは、静的サイト生成のボトルネック解消に本腰を入れるという明確なシグナルだ。

実験的機能を使うには、設定ファイルで明示的に有効化する必要がある。安定版になるまでは、開発環境でのビルド時間短縮を試す用途に留めておくのが安全だろう。

Astro 7.2の追加機能。開発プレビューとログ出力が改善

Astro 7.2の追加機能。開発プレビューとログ出力が改善
新機能 1 astro preview のバックグラウンドモード
ビルド済みサイトをプレビューしつつ、ターミナルを他の作業に使える
新機能 2 相対ロガーエントリポイント
ログ出力のファイルパスが相対表示になり、読みやすさが向上

増分静的ビルド以外にも、開発者の日常作業を改善する機能が2つ追加された。

1つ目は astro preview コマンドのバックグラウンドモードだ。ビルド済みのサイトをローカルで確認する際、従来はターミナルが占有されて他のコマンドを実行できなかった。バックグラウンドモードを使えば、プレビューサーバーを起動したまま別の作業に移れる。

2つ目は相対ロガーエントリポイントである。Astroのログ出力では、ファイルパスが絶対パスで表示されることがあった。相対表示に変わったことで、複数人での開発やCI環境のログ確認がしやすくなっている。

プロジェクトスチュワード交代。Astroの舵取り役が新体制に

プロジェクトスチュワード交代。Astroの舵取り役が新体制に

2026年8月、AstroのプロジェクトスチュワードがMatthew Phillips氏に交代した。プロジェクトスチュワードは技術的な方向性やコミュニティ運営の最終責任者にあたる役割だ。前職のFred K. Schott氏からバトンが引き継がれた。

Matthew Phillips氏はAstroのコアメンテナーとして長く活動してきた人物で、公式ブログでも「これまで通りコミュニティとともにAstroを育てていく」という趣旨のコメントを発表している。オープンソースプロジェクトにおいて、ガバナンスの透明な引き継ぎは健全性の証でもある。

Astroのイベント展開も活発だ。日本では10月開催のVue Fes JapanにAstroメンテナーのKenji氏が登壇する。また、ドイツのヴィースバーデンでは9月5日にパートナー企業Seibertとの共同イベントが開催される。グローバルなコミュニティ拡大が続いている。

Microsoftも採用。エコシステムとパートナー連携の広がり

Microsoftも採用。エコシステムとパートナー連携の広がり
Evil Martians 開発者ツール専門のコンサルティング企業。自社サイトにAstroを採用
Microsoft TypeSpec Azure AzureのAPI仕様書ドキュメントをAstroで構築
Microsoft Orleans 分散システムフレームワークの公式ドキュメントにAstroを活用

Astroの導入事例として、Microsoft関連のドキュメントサイトが2件確認された。TypeSpec AzureはAzureサービスのAPI仕様を記述するためのドキュメントで、Orleansは.NET向け分散システムフレームワークである。いずれも公式ドキュメントとしてAstroが採用されており、技術文書分野での信頼性が高まっている。

パートナー企業の動きも注目に値する。画像最適化サービスのImageKitがAstro統合を正式に提供開始した。Astroで構築したサイトから画像や動画をImageKitのグローバルCDN経由で配信でき、デバイスに応じたフォーマット変換も自動化される。画像の多いメディアサイトでは表示速度の改善に直結する連携だ。

また、CloudCannonがAstro向けの多言語スターターテンプレートを公開した。英語、フランス語、ドイツ語が初期設定済みで、静的サイトの翻訳ワークフローをOSSとして提供する。グローバル展開を視野に入れたサイト構築の敷居を下げる取り組みといえる。

開発者向けツールの充実。Astro Playgroundと注目の統合群

開発者向けツールの充実。Astro Playgroundと注目の統合群

2026年8月は開発者向けツールの発表も相次いだ。中でも注目はAstro Playgroundだ。ブラウザ上でAstroコンポーネントを試せる公式プレイグラウンドで、新規プロジェクトを作らずに単一コンポーネントの動作確認ができる。内部では動的Worker上で実際のAstroコンパイラが動作しており、ローカル環境と同一の結果を得られる設計になっている。

Astro Playgroundは、Astroの学習コストを下げるうえで重要な役割を果たす。これまでAstroコンポーネントを試すには、プロジェクトの初期化が必要だった。ブラウザで開くだけで実験できる環境は、初学者の入り口としても、経験者の素早いプロトタイピング用途としても有用だ。

コミュニティ製の統合も多数リリースされている。AWS Architecture Iconsをビルド時にSVGインライン化する @aws-icons/astro、最終レンダリング結果から目次を生成する astro-toc-smol、サイトマップを自動出力する @datadeft/astro-sitemap など、実務で即戦力になるものばかりだ。

SEO関連では、JSON-LD構造化データの生成を支援する @miyamo2/astro-jsonld や、ビルドごとにSEOスコアを監査する astro-seo-audit が登場している。Google検索の「優先ソース」ボタンに対応する統合も2種類リリースされており、AI Overviewsを見据えたSEO対策の関心の高さがうかがえる。

テーマカタログも大幅に拡充された。Astro公式テーマカタログには8月だけで80以上のテーマが追加または更新されている。SaaS向けランディングページ、ポートフォリオ、ECサイト、ドキュメントサイトなど、用途別のテンプレートが揃ってきた。Astroでの新規プロジェクト立ち上げがますます手軽になっている。

この記事のポイント

  • Astro 7.2が2026年8月末にリリース。実験的な増分静的ビルドが最大のトピックだ
  • 増分静的ビルドは変更の影響範囲だけを再生成する仕組みで、大規模サイトほどビルド時間短縮の恩恵が大きい
  • astro previewのバックグラウンドモードと相対ロガーエントリポイントも追加され、開発体験が改善した
  • プロジェクトスチュワードがMatthew Phillips氏に交代し、プロジェクト体制に変化があった
  • Microsoft公式ドキュメントでの採用やImageKit連携など、エコシステムの信頼性と実用性が向上している
Rank MathでWooCommerceモジュールが開けない時の原因と対処法

Rank MathでWooCommerceモジュールが開けない時の原因と対処法

Rank MathのWooCommerceモジュールがグレーアウトして切り替えられない場合、原因はプラグインのデータベースマイグレーションが完了していないことにある。管理画面に表示されるデータベースバージョンが初期値の1のままなら、まずキャッシュの全削除とメモリ上限の確認を行い、その上で不要オプションを削除して再マイグレーションを発生させる。

なぜWooCommerceモジュールだけがロックされるのか

なぜWooCommerceモジュールだけがロックされるのか

Rank Mathは各機能をモジュール単位で管理している。WooCommerceモジュールもその一つで、商品の構造化データや詳細設定をまとめて扱う。ところがこのモジュールは、プラグインのデータベーススキーマが特定のバージョン以上になった時だけ有効化できる仕組みだ。

管理画面のステータス情報で「database_version」がいつまでも初期値の1のままだと、WooCommerceモジュールを含む一部の機能が「未導入」と判断されたままになる。トグルにマウスを重ねると「Please activate WooCommerce to use this module」という趣旨のツールチップが表示されるが、WooCommerce本体が有効化されていてもこのエラーは出る。

つまり、WooCommerceの有効・無効が問題なのではなく、Rank Math側のデータベース情報が古いまま更新されていないことが本質のトラブルだ。

database_versionが1のまま進まない主な原因

database_versionが1のまま進まない主な原因

Rank Mathのインストール時やセットアップウィザード実行時、プラグイン内部でデータベーステーブルの作成とデータ移行が走る。この処理が最後まで到達しないと、バージョン情報が初期値の1から更新されない。具体的な原因は大きく三つに分けられる。

キャッシュプラグインが古いオプションを保持している

WP Super Cacheに代表されるキャッシュプラグインは、ページ表示を高速化するために一時データを保持する。まれにデータベースのオプション情報まで古い状態のまま配信することがあり、これが原因でRank Mathのバージョン情報が更新されないケースがある。

PHPメモリ上限が低くマイグレーションが途中で止まる

WooCommerceサイトは通常のWordPressサイトより管理画面のメモリ消費が大きい。Elementorや高機能テーマも動いている場合、PHPのメモリ上限を超えてRank Mathのデータベース処理が途中で終了してしまうことがある。具体的にはwp-config.phpで定義されたWP_MEMORY_LIMITが40M程度だと、重い環境では不足しやすい。

rank_math_db_versionオプションが破損している

WordPressのオプションテーブル(wp_options)には、Rank Mathが利用する複数のオプションが保存されている。このうち「rank_math_db_version」という値が破損したり、不正な状態で固定されたりすると、セットアップウィザードを再実行しても値が更新されない。

モジュールロックを解除する具体的な手順

モジュールロックを解除する具体的な手順

以下の手順は、データベースバージョンが初期値から更新されない場合に有効だ。順に実行することで、Rank Mathのマイグレーションが正常に走り、WooCommerceモジュールのロックが外れる。

STEP 1 キャッシュプラグインを停止し全キャッシュを削除する
STEP 2 wp-config.phpでWP_MEMORY_LIMITを128M以上へ引き上げる
STEP 3 rank_math_db_versionオプションをデータベースから削除する
STEP 4 Rank Mathのセットアップウィザードを再度実行してWooCommerceモジュールを確認する
STEP 1  STEP 2  STEP 3  STEP 4

このデモは、Rank Mathのデータベースバージョンを固定している原因を取り除き、マイグレーションを再実行させる流れを示している。

キャッシュを完全に無害化する

管理画面のプラグインページでWP Super Cacheを一時的に無効化する。次に「設定」→「WP Super Cache」からキャッシュの削除を実行し、サーバー上のwp-contentディレクトリにあるcacheディレクトリ内のファイルも手動で削除しておく。

共有サーバーで管理画面から操作できない場合は、FTPソフトでwp-content/cacheに入り、中身を空にする。キャッシュを消した後は、ブラウザのキャッシュも混ざらないようシークレットウィンドウで確認すると確実だ。

WP_MEMORY_LIMITを引き上げる

FTPまたはサーバーのファイルマネージャーでwp-config.phpを開き、WP_MEMORY_LIMITの定義を探す。設定されていなければ「/* That’s all, stop editing! */」の直前に以下の行を追加する。

define( 'WP_MEMORY_LIMIT', '128M' );

すでに40Mなど低い値が指定されている場合は、128Mまたは256Mに書き換える。変更後にWordPress管理画面の「ツール」→「サイトヘルス」からPHPのメモリ上限が更新されているか確認できる。

rank_math_db_versionオプションを直接削除する

サーバーのphpMyAdminにアクセスし、該当サイトのデータベースを選択する。wp_optionsテーブルを開き、option_nameが「rank_math_db_version」の行を探して削除する。

SQLを直接実行できる環境なら、次のようにしても同じ結果になる。

DELETE FROM wp_options WHERE option_name = 'rank_math_db_version';

テーブルの接頭辞がwp_以外の場合は、実際の接頭辞に置き換える。削除後、Rank Mathの管理画面を開くとマイグレーションが自動的に再実行され、正常ならデータベースバージョンが初期値より大きい値に更新される。

rank_math_modulesオプションも削除する

rank_math_db_versionを削除してもWooCommerceモジュールがロックされたままの場合、rank_math_modulesというオプションも同様に削除する。この値には有効化済みモジュールのリストが保存されており、破損しているとモジュールの出し分けが正常に機能しない。

DELETE FROM wp_options WHERE option_name IN ('rank_math_db_version', 'rank_math_modules');

この二つを削除した後、Rank Mathのセットアップウィザードを「詳細モード」で最後まで実行する。WooCommerceモジュールのトグルが青くなり、切り替え可能になっていれば成功だ。

それでも直らない場合の最終確認

それでも直らない場合の最終確認

データベースユーザーにテーブル作成権限があるか

Rank Mathのマイグレーションは、専用のテーブル(rank_math_analytics_objectsなど)を作成してデータを保存する。データベースユーザーに「CREATE TABLE」権限がないと、処理が裏側で失敗し続ける。レンタルサーバーの管理画面からデータベースユーザーの権限を確認し、不足していれば付与する。

重いプラグインを停止してからもう一度

ElementorやSlider Revolutionなど、管理画面の動作を重くするプラグインがマイグレーションを妨げている可能性がある。Health Check & Troubleshootingプラグインのトラブルシューティングモードを使い、Rank MathとWooCommerceだけを有効化した状態で手順をもう一度試す。

Rank Mathのデータベースツールでテーブルを作り直す

Rank Mathの管理画面から「ステータスとツール」→「データベースツール」を開く。「テーブルを作り直す」や「データベースを修復」といったボタンが用意されているので、順に実行してテーブルの再作成とデータの再構築を行う。

その後、もう一度セットアップウィザードを完了させ、データベースバージョンの値が更新されるかを確認する。それでも値が1のままなら、プラグインのアップデート待ちか、サーバー環境固有の制約が残っている可能性が高い。

よくある質問

トグルをクリックしても何も反応しないのはなぜ?

WooCommerceモジュールがロックされていると、トグル自体がグレーアウトした状態になる。クリックしても切り替わらず、ツールチップだけが表示される。これは操作ミスではなく、Rank Math内部でモジュールが使えない状態として認識されているためだ。

WooCommerce本体が壊れている可能性はある?

WooCommerceがプラグインページで有効化されており、商品管理やカートなど通常機能が動いているなら本体は正常だ。今回の問題はRank Math側のデータベース情報が古いことが原因なので、WooCommerceを再インストールしても解決しない。

Rank Mathを削除して入れ直しても直らないのはなぜ?

プラグインを削除しても、wp_optionsテーブルに保存されたオプションは残る。再インストール時に古いオプションを読み込んでしまい、同じ状態が再現される。必ずデータベースからrank_math_db_versionを削除してから再インストールする必要がある。

キャッシュプラグインは原因になりうる?

WP Super Cacheなどのキャッシュプラグインはページキャッシュが主体だが、環境によってはデータベースの一時情報も保持することがある。Rank Mathのバージョン情報が更新されない状態が続くなら、キャッシュプラグインを停止して切り分けるのが有効だ。

セットアップウィザードは毎回完了しているのに直らない

ウィザード自体は設定画面を進めるだけで、データベースのマイグレーションは別プロセスで走る。マイグレーションが裏側で失敗していると、ウィザード完了後もdatabase_versionが1のままになる。オプション削除とメモリ上限の引き上げを先に行うことが重要だ。

この記事のポイント

  • WooCommerceモジュールのロックはRank Mathのデータベースバージョンが原因
  • database_versionが1のままならマイグレーションが未完了
  • キャッシュ削除とWP_MEMORY_LIMITの引き上げを先に行う
  • rank_math_db_versionとrank_math_modulesオプションを直接削除して再実行
  • テーブル作成権限の確認と重いプラグインの停止も有効
AWS Graviton5搭載のEC2 R9gが一般提供開始。R8g比で最大25%の性能向上

AWS Graviton5搭載のEC2 R9gが一般提供開始。R8g比で最大25%の性能向上

AWSがGraviton5プロセッサを搭載したEC2 R9gとR9gdインスタンスを一般提供開始した。メモリ最適化インスタンスの新世代で、R8gと比較してコンピュート性能が最大25%向上している。

Graviton5はDDR5メモリの高速化、L3キャッシュの5倍拡大、ネットワーク帯域幅の最大2倍化など、複数のハードウェア改良を備える。データベースやインメモリキャッシュなどメモリ集約型のワークロードで効果が大きい。

この記事ではR9gの技術的な変更点、インスタンススペック、移行手順、利用可能リージョンを解説する。

Graviton5がもたらす性能向上の全容

Graviton5がもたらす性能向上の全容

Graviton5プロセッサはGraviton4から複数のハードウェア改良が加えられた。まずコンピュート性能がvCPUあたり最大25%向上している。これは命令処理の効率化と高クロック動作によるものだ。またAWSがこれまでに構築した中で最もエネルギー効率の高いプロセッサでもある。

従来のR8gインスタンス(Graviton4)
コンピュート性能 基準値
メモリ DDR5 5600 MT/s
L3キャッシュ 標準サイズ
ネットワーク帯域幅 最大50 Gbps
EBS帯域幅 最大36 Gbps
新しいR9gインスタンス(Graviton5)
コンピュート性能 最大25%向上
メモリ DDR5 8800 MT/s
L3キャッシュ 5倍拡大
ネットワーク帯域幅 最大100 Gbps
EBS帯域幅 最大72 Gbps
※48xlargeサイズでの比較。ネットワークとEBS帯域幅は最大値。

このデモはGraviton4(R8g)とGraviton5(R9g)の主要スペックを比較している。特にL3キャッシュの5倍拡大とメモリ帯域の高速化がデータ処理の遅延低減に効く。

メモリとキャッシュの大幅強化

メモリはDDR5 8800 MT/sに対応した。Graviton4の5600 MT/sから大幅に高速化されており、AWSのクラウド上で利用可能な最速のメモリ帯域を実現している。これは大量のデータを扱うインメモリキャッシュ・データベースにとって応答時間の短縮に直結する。

L3キャッシュも5倍に拡大された。L3キャッシュとはCPU内部にある高速なメモリ領域で、頻繁にアクセスするデータを一時的に保持する役割を持つ。この容量が増えると、主メモリへのアクセス回数が減り、データ処理の遅延が小さくなる。データ局所性が高いワークロードほど恩恵を受けやすい。

ネットワーク帯域幅とパケット処理の改善

ネットワーク帯域幅とAmazon EBSの帯域幅は、最大サイズのインスタンスで最大2倍に向上した。48xlargeではネットワークが最大100 Gbps、EBSが最大72 Gbpsに達する。またパケット処理性能は最大3倍に改善されている。

さらにR9gとR9gdはInstance Bandwidth Configuration(IBC)に対応している。これはEBSとネットワークの帯域配分を25%単位で調整できる機能だ。データベースやキャッシュなど、帯域要件が特定方向に偏るワークロードで性能を最適化できる。例えばネットワーク処理が少なくディスクI/Oが多いワークロードでは、帯域をEBS側に寄せるといった調整が可能になる。

Nitro Isolation Engineによるセキュリティ強化

Nitro Isolation Engineによるセキュリティ強化

すべてのR9gとR9gdインスタンスはAWS Nitro System上で動作する。Nitro Systemは仮想化、ストレージ、ネットワークを専用ハードウェアにオフロードする仕組みだ。これにより仮想マシンのオーバーヘッドが減り、ベアメタルに近い性能と強固なセキュリティ分離を両立できる。

R9gとR9gdにはNitro Isolation Engine(NIE)が搭載されている。NIEはC9gとM9gで今年前半に導入されたコンポーネントで、仮想マシン間の分離を強制する役割を担う。仮想マシンのメモリ、CPUレジスタ状態、I/Oデバイスへのすべてのアクセスを最小限のAPIセットで仲介する。

仮想マシンA 独立して動作
仮想マシンB 独立して動作
Nitro Isolation Engine メモリ・CPU・I/Oアクセスを仲介
Nitro System 専用ハードウェア 仮想化・ストレージ・ネットワークを処理
※NIEがすべてのアクセスを仲介することで、仮想マシン間の分離を保証する。

このデモはNIEが仮想マシンとハードウェアの間に位置し、すべてのアクセスを仲介する関係を示している。分離の保証はソフトウェア的な工夫ではなく、形式的な数学証明によって裏付けられている点が特徴だ。

NIEの特徴は形式検証(formal verification)という手法を活用している点にある。これはハードウェアやソフトウェアが意図通りに動作することを数学的に証明する手法だ。特定のテストケースだけでなく、あらゆる条件下で正しく動作することを保証する。この取り組みにより、Nitroはクラウドハイパーバイザーとして初めて形式検証を受けた存在になった。

形式検証の対象範囲や前提条件などの詳細はAWSのテクニカルホワイトペーパーで公開されている。セキュリティ要件が厳しい金融系ワークロードやマルチテナント環境を扱う場合には、このホワイトペーパーを参照してリスク評価に役立てるとよい。

R9gとR9gdのインスタンススペック

R9gとR9gdのインスタンススペック

R9gとR9gdはそれぞれ11サイズで提供される。最小のmediumから最大のmetal-48xlまで、幅広い要件に対応する。以下では2つの違いを中心に説明する。

R9gインスタンス
EBSストレージのみ使用
データベースやキャッシュに最適
最大192 vCPU / 1536 GiBメモリ
R9gdインスタンス
ローカルNVMe SSDを搭載
低レイテンシの一時ストレージが必要な用途に最適
最大192 vCPU / 1536 GiBメモリ / 11.4 TB NVMe
※どちらも同じコンピュート性能とネットワーク性能を持つ。ストレージ構成のみ異なる。

このデモはR9gとR9gdの違いを整理している。NVMe SSDの有無が唯一の差で、用途に応じて選べる。

R9gのスペック

R9gはEBSストレージのみを使用する構成だ。最小のr9g.mediumは1 vCPUと8 GiBメモリ、最大のr9g.48xlargeとr9g.metal-48xlは192 vCPUと1536 GiBメモリを搭載する。ネットワーク帯域幅はmediumから2xlargeまで最大15 Gbps、8xlargeで17 Gbps、12xlargeで25 Gbps、16xlargeで34 Gbps、24xlargeで50 Gbps、48xlargeで100 Gbpsに達する。

EBS帯域幅はmediumから4xlargeまで最大12 Gbps、8xlargeで12 Gbps、12xlargeで18 Gbps、16xlargeで24 Gbps、24xlargeで36 Gbps、48xlargeで72 Gbpsとなっている。データベース用途ではEBS帯域幅が性能のボトルネックになりやすいため、サイズ選定の際はこの値にも注目したい。

R9gdのNVMeストレージ

R9gdはR9gと同じコンピュート性能とネットワーク性能を持ちながら、ローカルNVMe SSDを搭載している。mediumでは59 GB、largeで118 GB、xlargeで237 GBとサイズに応じて容量が増える。最大のr9gd.48xlargeでは3台の3800 GB NVMe SSD(合計11.4 TB)を備える。

ローカルNVMe SSDはEBSと比べてレイテンシが低く、一時的なスクラッチ領域やキャッシュ用途に向いている。オープンソースデータベース、分散リアルタイムビッグデータ分析、大規模インメモリデータベース、大容量キャッシュワークロードで効果を発揮する。

R8gからの移行と始め方

R8gからの移行と始め方

R8gで運用中のワークロードがある場合、R9gへの移行はシンプルだ。多くのアプリケーションでコード変更は不要。同等サイズのR9gインスタンスを選択すれば、そのままより高い性能を得られる。

STEP 1 R8gインスタンスを運行中か確認
STEP 2 同等サイズのR9gインスタンスを選択
STEP 3 Arm64対応のAMIから起動
STEP 4 アプリケーションを実行して性能を確認
※多くのアプリケーションではコード変更不要。Arm64対応イメージを使えばそのまま動作する。

このデモはR8gからR9gへの移行手順を4ステップで示している。インスタンスタイプを変更するだけで性能が向上するケースが多い。

対応OSとコンテナ環境

R9gはAmazon Linux 2023、Amazon Linux 2、Ubuntu 22.04以降、RHEL 8.4以降、SUSE Linux Enterprise Server 15 SP3以降、Debian 12以降など主要なLinuxディストリビューションに対応する。EC2コンソールからArmベースのAMIを選択すれば、すぐに起動できる。

コンテナワークロードではAmazon EKS、Amazon ECS、標準的なKubernetes環境で動作する。Arm64向けにビルドされたマルチアーキテクチャのコンテナイメージなら変更なしで動く。Dockerイメージをマルチアーキテクチャ対応にしておくと、x86からArmへの移行がスムーズになる。

移行を支援するツール

AWSはGravitonへの移行を支援する複数のリソースを提供している。Graviton Getting Started Guideは構築、実行、最適化の方法をまとめたガイドだ。Graviton Savings Dashboardではコスト削減効果を追跡できる。AWS TransformはJavaアプリケーションをx86からGraviton向けに変換するコード変換を自動化するツールだ。

Javaアプリケーションの場合、依存ライブラリにネイティブコードが含まれているとArm64への移行が難しいことがある。AWS Transformはこうしたコード変換を自動化して移行の手間を減らす。まず小規模なワークロードで試し、問題がないことを確認してから本番移行に進むのが現実的な進め方だ。

料金と利用可能リージョン

料金と利用可能リージョン

R9gとR9gdは米国東部(バージニア北部、オハイオ)、米国西部(オレゴン)、欧州(フランクフルト)の各リージョンで利用できる。日本国内のリージョン(アジアパシフィック東京)では現時点で提供されておらず、今後の展開が待たれる。

購入オプションはSavings Plans、On-Demand、Spot Instances、Dedicated Instances、Dedicated Hostsから選択可能だ。長期運用する場合はSavings Plans、一時的なバッチ処理やテスト用途ではSpot Instancesがコスト効率に優れる。料金の詳細はAmazon EC2の料金ページで確認できる。

インスタンスサイズや購入オプションによって価格が異なるため、ワークロードに合わせて最適な組み合わせを選ぶことが重要だ。特にR8gと比較した場合、同じサイズでも性能が向上しているため、より小さなサイズに移行してコストを削減できる可能性もある。

この記事のポイント

  • AWS Graviton5搭載のEC2 R9gとR9gdが一般提供を開始した
  • R8g比でコンピュート性能が最大25%向上し、エネルギー効率も改善
  • DDR5 8800 MT/sメモリとL3キャッシュ5倍拡大でデータ処理が高速化
  • Nitro Isolation Engineにより形式検証されたセキュリティ分離を実現
  • R9gはEBSのみ、R9gdはローカルNVMe SSDを搭載した構成
  • R8gからの移行はコード変更不要のケースが多く、Arm64対応イメージでそのまま動作
WPLP Cookie Consent脆弱性を狙った攻撃からWordPressを守る3つの対策

WPLP Cookie Consent脆弱性を狙った攻撃からWordPressを守る3つの対策

Cookie同意プラグイン「WPLP Cookie Consent(スラッグ gdpr-cookie-consent)」のバージョン4.4.1以前には、未認証の攻撃者に任意のファイルをアップロードされる脆弱性がある。サイトを守るには、プラグインを4.4.2以上へ更新し、アップロードディレクトリ内でのPHP実行をサーバー側で拒否し、不正な管理者アカウントが作られていないか確認することが最優先だ。

なぜWPLP Cookie Consent 4.4.1が危険なのか

なぜWPLP Cookie Consent 4.4.1が危険なのか

この脆弱性は、プラグインのREST APIエンドポイントに認可の不備があることから発生する。攻撃者は誰でもアクセスできる2つのエンドポイントを悪用し、WordPressのオプション設定を書き換えたうえで、任意のファイルをサーバーに保存できる。特に問題なのが、保存先が通常のアップロードフォルダ(wp-content/uploads)であり、ファイル名や拡張子の検証がまったく行われていなかった点だ。

つまり攻撃者は「画像ファイルに見せかけたPHPプログラム」をサイトに置くだけで、その後の実行に成功すれば管理者権限を奪取できる。バージョン4.4.1は攻撃が確認された時点で最新版だったため、更新を怠っていたサイトだけでなく、常に最新にしていたサイトも危険にさらされた。修正版の4.4.2が公開されてからは、この経路は塞がれているが、攻撃キャンペーンがすでに自動化されて動いている以上、更新前のサイトは今も標的になる。

攻撃の流れと侵入の仕組み

攻撃の流れと侵入の仕組み

実際に確認された攻撃は、わずか20秒足らずで4段階のプロセスが自動実行される。最初にユーザー一覧を取得して管理者のユーザー名を特定し、次にプラグイン固有のオプションを毒して鍵をすり替え、最後にその鍵を使ってファイルを書き込む。下の図はその一連の流れを表している。

STEP 1 REST APIでユーザー一覧を取得される
STEP 2 store-authエンドポイントでオプションを改ざん
STEP 3 upload-logoエンドポイントでPHPファイルを書き込み
STEP 4 書き込んだPHPを実行しようとするがサーバー側のルールでブロック
攻撃者の操作  防御策が機能した部分

この攻撃チェーンのうち、最初の3段階は特定のプラグインがなければ成立しない。一方で、最後のPHP実行だけはサーバー側の設定次第でどのサイトでも防げる。ここが多層防御の要になる。

まず行う3つの緊急対応

まず行う3つの緊急対応

サイトがこの脆弱性の影響を受けるかどうかに関係なく、次の3つを優先して実行する。順番はプラグインの更新、サーバー設定の確認、不正アカウントの確認が推奨される。

プラグインを4.4.2以上へ更新する

WPLP Cookie Consent(gdpr-cookie-consent)を使っている場合、まず管理画面の「プラグイン」から更新が来ていないか確認する。更新が見つからない場合は、WordPress.orgのプラグインページから最新版を手動でダウンロードし、既存のプラグインを上書きする。バージョン4.4.2では、脆弱性の原因だったアップロード用エンドポイントが削除され、残ったREST APIにもHMAC-SHA256署名によるリクエスト検証が追加されている。

更新後は、キャッシュ系プラグインを使っている場合はキャッシュを削除しておく。古いRESTエンドポイントの応答がキャッシュに残っていると、攻撃者からまだ有効に見えることがあるためだ。

アップロードディレクトリ内でのPHP実行を拒否する

今回の攻撃では、脆弱なプラグインによって「wp-content/uploads」ディレクトリにPHPファイルが書き込まれた。しかし、そのディレクトリ内でのPHP実行がサーバー側で拒否されていたため、攻撃は最終段階で失敗している。この設定は多くのレンタルサーバーで最初から有効になっているが、そうでない環境もある。

Apacheサーバーの場合、wp-content/uploads ディレクトリに以下の内容の .htaccess ファイルを置くことで、PHPファイルの実行を拒否できる。

<FilesMatch "\.(php|php5|phtml)$">
  Require all denied
</FilesMatch>

Nginxの場合は、サーバー設定で該当ディレクトリに対するPHPの処理を除外する。レンタルサーバーを利用しているなら、管理パネルに「PHP実行の無効化」や「セキュリティ設定」が用意されているか確認する。設定を変更できない場合は、サーバー会社に問い合わせて、アップロードディレクトリ内のPHP実行がブロックされているか確認するのが確実だ。

修正前
wp-content/uploads 内で PHP ファイルが実行可能
→ アップロードされたPHPが実行され、サイトが乗っ取られる
修正後
wp-content/uploads 内で PHP ファイルの実行を拒否
→ アップロードされても実行されず、攻撃が失敗する
危険な状態  安全な状態

上の対比のように、ファイルが置かれても実行できなければウェブシェルとして機能しない。プラグインの更新とあわせて、このサーバー側の防御を必ず確認する。

不正な管理者アカウントを探す

今回確認されたマルウェアは、実行に成功すると管理者アカウントを自動生成する。しかも、登録日時を既存ユーザーの日時に合わせて改ざんするため、「新しく作られたユーザー」を探すだけでは見つからない。次の3つの兆候を手がかりに、phpMyAdminやWP-CLIで WordPress の wp_users テーブルを確認する。

  • ユーザー名が「サイトのドメイン名+ランダム3文字」になっている
  • 表示名が「Lucas Hayes」になっている
  • メールアドレスのドメインが ifuqpatr.com になっている

心当たりのない管理者アカウントを見つけたら、そのユーザーを削除し、全ユーザーのパスワードをリセットする。また、登録日時が既存ユーザーと完全に一致するアカウントがないかもあわせて確認する。

侵害を検知する具体的な手順

侵害を検知する具体的な手順

すでに攻撃を受けた形跡がないかは、ログとファイルの両面から確認する。攻撃が失敗していても、ファイルの残骸や不審なアクセスが残っていることが多い。

サーバーのアクセスログを精査する

攻撃者は決まったエンドポイントに順番にアクセスする。アクセスログで次のパターンを検索し、該当するリクエストが記録されていないか確認する。

  • GET /wp-json/wp/v2/users?per_page=100
  • POST /wp-json/wplp-react-gdpr/v1/store-auth
  • POST /wp-json/wplp-react-gdpr/v1/upload-logo

これらのリクエストがすべて記録されていれば、攻撃者がサイトに到達した証拠になる。アクセスログはサーバー会社の管理パネルや、レンタルサーバーのログ保存機能から取得できる。ログの保存期間が短いと痕跡が消えるため、普段から長めに保存する設定にしておくことが重要だ。

マルウェアスキャナーでファイルを検査する

サーバーに導入されているマルウェアスキャナーや、WordPress用のセキュリティプラグインを使って wp-content ディレクトリ全体をスキャンする。特に「*.jpg.php」のような二重拡張子のファイルや、最近改変されたPHPファイルが検出対象になる。

スキャナーは攻撃直後の未知のマルウェアを検出できないこともあるが、時間が経ってから見つかることも多い。複数のスキャナーを併用すると検出率が上がる。手動で確認する場合は、wp-content/uploads 以下のファイルで、画像に見せかけたPHPファイルが残っていないかを調べる。

テーマとプラグインの改ざんを確認する

攻撃者はすでに侵入に成功している場合、バックドアを別の場所に仕込んでいる可能性がある。アクティブなテーマの functions.php や、プラグインのディレクトリに不審なコードが追加されていないかを確認する。特に、難読化されたコードや、外部と通信する関数(file_get_contents、curl、eval など)が含まれている場合は注意が必要だ。

再発を防ぐための設定

再発を防ぐための設定

今回の攻撃は特定のプラグインに依存しているが、同種の攻撃は他のプラグインでも発生する。サイト全体の防御力を上げるために、次の設定を検討する。

REST APIのユーザー一覧取得をブロックする

攻撃の第一段階では、WordPress標準のREST APIからユーザー一覧を取得して管理者のユーザー名を特定している。このエンドポイントを無効化するか、ログイン済みユーザーに限定すれば、攻撃の難易度を上げられる。

子テーマの functions.php に次のコードを追加すると、未認証のユーザー一覧取得を防げる。

add_filter( 'rest_endpoints', function( $endpoints ) {
    if ( isset( $endpoints['/wp/v2/users'] ) ) {
        unset( $endpoints['/wp/v2/users'] );
    }
    return $endpoints;
} );

このコードはユーザー一覧のエンドポイントそのものを削除するため、ログイン中でも一覧を取得できなくなる。一部のプラグインがこの機能を使っている場合は影響を確認してから適用する。

アクセスログを長期間保存する

攻撃の痕跡は時間が経つと消える。サーバーのアクセスログを最低でも数週間、可能なら数ヶ月保存しておくと、侵害の調査や再発防止に役立つ。レンタルサーバーの標準設定では数日しか保存されないこともあるため、管理パネルやサーバー会社に確認して保存期間を延ばす。

プラグインの選定と更新ポリシーを見直す

Cookie同意プラグインに限らず、インストール数が少ないプラグインでも攻撃対象になる。更新が止まっているプラグインや、あまり知られていない開発元のプラグインを使い続ける場合は、代替手段を検討する。定期的にプラグインの更新を確認し、不要なプラグインは削除する。

よくある質問

WPLP Cookie Consentを使っていないが対策は必要か

今回の脆弱性はこのプラグイン固有のものだが、アップロードディレクトリでのPHP実行を拒否する設定や、REST APIのユーザー列挙対策はどのサイトでも有効な防御策になる。プラグインの更新とサーバー設定の見直しは、サイト全体のセキュリティを底上げする。

更新したのに攻撃された兆候が残っている場合はどうすればいいか

更新してもすでに設置されたマルウェアは消えない。不正な管理者アカウントの削除、マルウェアスキャン、テーマやプラグインの改ざん確認を行い、必要ならバックアップから復元する。確実なのは、クリーンなバックアップに置き換えて、全パスワードを再発行することだ。

アップロードディレクトリのPHP実行を拒否すると何か問題はあるか

通常のWordPressサイトでは、wp-content/uploads にPHPファイルを置く運用は推奨されていない。画像や文書の配信には影響しない。一部の特殊なプラグインやテーマがこの場所にPHPを置く場合は、事前に動作確認を行う。

REST APIを完全に無効化したほうがいいのか

完全な無効化は、ブロックエディタや一部の機能が動作しなくなるため現実的ではない。ユーザー一覧だけを狙ったエンドポイントを制限するか、認証を要求する設定が現実的な落とし所になる。

この記事のポイント

  • WPLP Cookie Consent 4.4.1以前には未認証でファイルをアップロードされる脆弱性がある
  • まずプラグインを4.4.2以上へ更新し、古いバージョンのままにしない
  • wp-content/uploads 内のPHP実行をサーバー側で拒否する
  • 不正な管理者アカウントがないか wp_users を確認する
  • アクセスログとマルウェアスキャナーで侵害の痕跡を調査する