ウェブ開発 最新ニュース UPDATES

TikTok ShopがEUと英国の越境販売を開始、9月21日から段階展開

TikTok ShopがEUと英国の越境販売を開始、9月21日から段階展開

TikTok ShopがEU加盟8カ国と英国の間で越境販売を開始する。出品者は自国の外にいる消費者へ直接商品を届けられるようになる。9月21日のパイロット運用を経て、10月19日に本格展開へ移行する流れだ。

越境ECの選択肢が増えることで、中小規模の事業者にも新たな販路が開ける。英国市場では30万以上の小規模事業者がTikTok Shopを利用している。EU側の出品者にとって英国市場へのアクセスは魅力的な拡張機会になるだろう。

本記事では越境販売の仕組み、販売条件、EC事業者への影響を解説する。特にWooCommerceで自社ECを運営する事業者にとっての意味合いも掘り下げる。

TikTok Shopの越境販売、全体像

TikTok Shopの越境販売、全体像
EU8カ国から英国へ
EU8カ国の出品者 商品を出品 TikTok Shop 越境販売を仲介 英国の購入者
英国からEU12カ国へ
英国の出品者 商品を出品 TikTok Shop 越境販売を仲介 EU12カ国の購入者

このデモでは双方向の越境販売フローを示した。9月21日と10月19日の2段階展開がポイントである。EU側と英国側で販売条件が異なる点は後述する。

TikTok Shopは欧州での展開を急速に進めている。6月中旬にはオーストリア、ベルギー、オランダ、ポーランドに進出した。同時に「Sell Across Europe」プログラムを始動し、欧州12カ国をカバーする汎欧州市場へと進化している。今回の越境販売は、この汎欧州市場を英国へ拡張する動きの一環だ。

EU8カ国から英国への販売

対象となるのはベルギー、ドイツ、フランス、アイルランド、イタリア、オランダ、ポーランド、スペインの8カ国だ。まず9月21日に選ばれたEU出品者向けパイロットが始まる。その後10月19日に本格展開に移る。英国ではTikTok Shopが約5年間運営されており、30万以上の小規模事業者が利用する成熟市場だ。

英国からEU12カ国への販売

一方、英国の出品者は欧州大陸の12カ国に販売できるようになる。対象国はSell Across Europeネットワークに参加している国々だ。対象かどうかは、出品者の現在のアカウント状態とパフォーマンスをリアルタイムで評価して決まる。

EC事業者が知るべき販売条件

EC事業者が知るべき販売条件

越境販売に参加するには、いくつかの条件を満たす必要がある。特に英国向け販売では配送方式が重要になる。

Ship by Seller方式の詳細

英国向け販売で使える配送オプションは「Ship by Seller」のみである。これは出品者が自ら配送業者を選び、配送料を支払い、配送トラブルが起きた場合も顧客対応を行う方式だ。TikTok Shop公式の説明でも「配送業者を選び、配送料を支払い、配送がうまくいかなかった場合の顧客対応も行う」とされている。日本で言えば、マーケットプレイスではなく自社発送に近い形態である。フルフィルメントをTikTok側が代行するわけではないため、越境配送の手配とコスト管理は出品者自身の責任になる。

STEP 1 出品者が配送業者を選択
STEP 2 配送料を出品者が負担
STEP 3 トラブル発生時の顧客対応も出品者が担当

この3ステップがShip by Seller方式の全体像だ。配送業者の選択から顧客対応まで、出品者側に責任が集中する。越境販売では関税や返品対応も加わるため、国内発送以上に準備が求められる。

販売対象になるための要件

越境販売の対象になるには、次の要件を満たす必要がある。対象EU市場でTikTok Shopにすでにアクティブであること、アカウントが良好な状態であること、最近の販売実績があること、大きな未払い残高がないこと。英国からEUへの販売では、リアルタイムのアカウント評価が対象判断に使われる。

対象になるための主な要件
要件 1 対象EU市場でTikTok Shopにすでにアクティブ
要件 2 アカウントが良好な状態
要件 3 最近の販売実績がある
要件 4 大きな未払い残高がない
要件1  要件2  要件3  要件4

4つの要件を色分けして示した。英国からEUへの販売は、これらに加えてリアルタイムのパフォーマンス評価が使われる。出品者側は日頃からアカウント状態を良好に保つことが前提になる。

越境ECとしてのTikTok Shopの戦略的意味

越境ECとしてのTikTok Shopの戦略的意味

TikTok Shopの越境販売は、欧州市場を一つの商圏として統合する動きだ。従来のECモールは国ごとにアカウントや出品設定が必要だったが、Sell Across Europeと英国への拡張により、一つのアカウントで複数国にリーチできるようになる。特に英国市場は購買力が高く、EU側の事業者にとって有望な販売先である。越境ECの障壁だった言語や通貨、配送の問題をTikTokがどこまで解決できるかが、今後の成長を左右する。

本サイトの見方として、TikTok Shopの越境販売はソーシャルコマースの越境展開という新しい段階に入ったことを示す。InstagramやFacebookと異なり、TikTokのショート動画とECが一体になった体験が、国境を越えた購入を後押しする可能性がある。一方で、Ship by Seller方式による出品者負担の配送は、越境ならではの関税や返品対応の複雑さを考慮すると、小規模事業者にとっては高いハードルになり得る。ここが普及の鍵になるだろう。

WooCommerce事業者への示唆

WooCommerce事業者への示唆

WooCommerceで自社ECを運営する事業者にとって、TikTok Shopの越境販売は販路拡大の新たな選択肢になる。自社ECサイトを持ちながら、TikTok Shopをフロントエンドの集客チャネルとして使う形だ。商品データの同期や注文管理の連携ができれば、在庫管理を一元化しながら越境販売を試せる。現時点では公式なプラグインによる深い統合は限定的だが、今後のAPI公開や連携強化に注目したい。まずは自社の商品が越境販売に適しているか、配送コストと販売価格のバランスを見極めることを推奨する。

EC制作の現場から見ると、越境販売への対応はテーマやカートの複数通貨対応、配送業者との連携、関税計算など、技術的な準備が増える。TikTok Shopのようなプラットフォームを活用すれば、これらの複雑さを一部肩代わりできる。WooCommerce事業者は「自社ECで深く最適化する」か「プラットフォームで手早く展開する」かの使い分けが重要になる。

この記事のポイント

  • TikTok ShopがEU8カ国と英国の間で越境販売を開始する
  • 9月21日にパイロット、10月19日に本格展開へ移行する
  • 英国向け販売はShip by Seller方式のみで、出品者が配送の全責任を負う
  • 販売対象にはEU市場でのアクティブな実績と良好なアカウント状態が求められる
  • WooCommerce事業者は自社ECとの併用で越境販売の機会を探れる
42モデル比較で判明!AIモデル選択がもたらす推論コスト86倍差の実態

42モデル比較で判明!AIモデル選択がもたらす推論コスト86倍差の実態

Neonが42のAIモデルを対象に、サポートチケット100件の処理コストと品質を同時検証した。結果として、同じタスクでもモデル選択だけで単位作業あたりの推論コストが約86倍変わる実態が明らかになった。

実験では合成サポートチケットを各モデルに処理させ、合計コスト・合格率・処理時間の3軸でスコアを付けた。最安のGPT-5 Nanoは3分程度で処理を終え、コストパフォーマンスで突出した。一方、最高額のGPT-5.5 Proは100件の処理に8.34ドル、57分を要した。

AIエージェントが企業で本格稼働する時代、モデル選びはもはや精度だけで決める時代ではない。トークン消費量と推論コストを意識したトークンエコノミクスの視点が不可欠になる。この記事ではNeonの公開ベンチマークを基に、主要な発見とコスト試算を解説する。

AIエージェント時代に浮上するトークンエコノミクス

AIエージェント時代に浮上するトークンエコノミクス

トークンとは、LLM(大規模言語モデル)がテキストを処理する際の最小単位だ。英語でおおよそ4文字、日本語では1文字から数文字が1トークンに相当する。AIのAPI料金はこのトークン数に応じて決まるため、同じタスクでもモデルによってトークン消費量が大きく異なる。

Neonの検証によると、エージェントが企業で担う業務が増えるほど、トークン消費は人件費に次ぐコスト項目に成長する見込みだ。Neonはこのコスト管理の概念を「トークンエコノミクス」と呼び、モデル選定の重要性を強調している。ソフトウェア企業ではエンジニアがコーディングエージェントを日常的に使うため、モデルの効率差がそのまま大きな費用差として顕在化する。

Neonの見解では、大企業ほどこの差は深刻になる。数百人のエンジニアを抱える企業では、月間の推論コスト差が数十万円から数百万円規模に達する。モデル選びを「カタログ価格だけで判断する」ことは、もはや現実的な選択ではなくなっている。

42モデルを同一タスクで検証した実験設計

42モデルを同一タスクで検証した実験設計

サポートチケット100件という選定理由

Neonのチームは「現実世界の雑多な状況を反映する」タスクとして、合成サポートチケット100件の返信を各モデルに依頼した。チケットは請求、製品質問、セキュリティインシデント、アカウントアクセス、返金の5つのシナリオを持つ。それぞれに顧客のトーンが5種類(直接表現、緊急、不満、次のステップ要求、非技術者向け)用意され、合計20シナリオを構成する。

各モデルには同じシステムプロンプトとJSONレスポンス形式、アカウントコンテキスト、ポリシー注記が渡された。この設計により、モデル間で条件を完全に揃えたうえで、コストと品質を比較できる。

7項目の合格基準

Neonは「使える回答」と「使えない回答」を区別するため、7つのチェック項目を設定した。JSONが必須4フィールドで正しくパースできること、分類が期待カテゴリと一致すること、選択アクションがポリシーで許可されていること、エスカレーション判断が正しいこと、顧客返信が1語から120語であること、必須ポリシー用語が含まれること、禁止された約束や主張がないこと、である。

例えば請求系チケットでは「請求書を説明しstorageに言及する」ことが合格条件になり、勝手にクレジットを発行すると不合格になる。セキュリティ系では「適切にエスカレーションする」行動が必須で、「心配いりません」と返すだけでは失敗扱いだ。この基準が、LLMの単なる応答速度や流暢さではなく、実務で使える精度を測る分離線になっている。

STEP 1 合成サポートチケット100件を生成する
STEP 2 42モデルに100件を順次処理させる
STEP 3 7項目の合格基準で各回答を判定する
STEP 4 コスト、処理時間、合格率を集計する
実験フロー

実験は合成サポートチケットを使い、全モデルに同一条件でタスクを実行させた。合計コストと合格率、処理時間をそれぞれ計測している。

Neonブランチを活用した技術設計

ベンチマークの実行基盤にはNeonのブランチ機能が用いられた。ブランチとは、DB環境をgitブランチのように瞬間的に複製する仕組みだ。モデルごとに1つのNeonブランチを作成し、それぞれに専用のAI Gatewayホストを割り当てることで、モデルとエンドポイントの対応を明確に保った。

neon branches create \
  --project-id "$PROJECT_ID" \
  --parent "$PARENT_BRANCH" \
  --name "model-gpt-5-nano" \
  --no-compute

--no-compute フラグは不要なPostgresコンピュートを起動せず、AI Gatewayのエンドポイントだけを使うための指定だ。各ブランチにはAI Gatewayホストが自動で付与され、mainブランチで作成したクレデンシャルが子ブランチにも適用される。これにより、42モデル分のインフラを極めて低コストで構築できた。

データ層はLakebase Postgresが担い、ベンチマーク実行記録、モデルスナップショット、推論結果を管理する。WebアプリはNext.js 15、React 19、TypeScriptで構築され、Rechartsで可視化、Tailwind CSSでスタイリング、Zodでスキーマ検証を行った。自動化はGitHub Actionsが担い、Vercelにデプロイされる。集計結果はJSONスナップショットとしてもコミットされ、レビュー可能な形で公開されている。

ベンチマークが明らかにした主要な結果

ベンチマークが明らかにした主要な結果

コストと合格率の対照的な顔ぶれ

Neonの検証で最安を記録したのはGPT-5 Nanoだった。単位あたりの使用可能コストが全モデル中最も低く、処理時間も約3分と高速だった。コストと速度を両立する「バランス型」と言える。最速はLlama 3.1 8B Instructで1分18秒だったが、合格率は100件中34件と低く、速度だけで判断すると実務には耐えない。

一方、最高額はGPT-5.5 Proで、100件の処理に8.34ドルかかり、所要時間も57分と群を抜いて遅かった。トークンを最も消費したのはQwen3.5 122B-A10Bで、合格率も100件中35件と振るわない。合格率の最高はGPT-5.3 Codexで、100件中82件を一発合格した。

最安 GPT-5 Nano 約3分で処理、コスト効率が突出
最速 Llama 3.1 8B Instruct 1分18秒、合格率は34件止まり
最高額 GPT-5.5 Pro 8.34ドル、57分を要する
最高精度 GPT-5.3 Codex 100件中82件合格
最安のGPT-5 Nano 最速のLlama 3.1 8B 最高額のGPT-5.5 Pro 最高精度のGPT-5.3 Codex

主要な結果はコストと合格率の両面で性格が異なる。消費トークンはQwen3.5 122B-A10Bが最多で、合格は100件中35件にとどまった。この組み合わせは「カタログ価格が低くても実際のユニットコストは高い」というトークンエコノミクスの落とし穴をよく示す。

更新で追加された新モデル

Neonは初期公開後に3モデルを追加し、ベンチマークは45モデルに拡大された。GPT-6 Astra、Claude Fable 5.1、GLM-5.3 Flashである。主要ランキングに大きな変動はなかったが、GPT-6 Astraは100件中67件合格で45モデル中28位、コストは45モデル中40位と、話題の水準からは控えめな結果だった。

モデル選択で推論コストが86倍変わる

モデル選択で推論コストが86倍変わる

GPT-5.6 SolとClaude Fable 5の直接比較

NeonはOpenAIとAnthropicの現行フラッグシップ同士も直接比較した。合格率はGPT-5.6 Solが69件、Claude Fable 5が68件とほぼ互角だった。しかしコストはSolが34,663トークンで0.535ドル、Fableが57,010トークンで1.59ドルと、単位あたり約3倍の差がついた。所要時間もFableが2.3倍長い。

GPT-5.6 Sol(OpenAI)
合格率 69件 / 100件
トークン数 34,663
総コスト 0.535ドル
Claude Fable 5(Anthropic)
合格率 68件 / 100件
トークン数 57,010
総コスト 1.59ドル
結論 合格率はほぼ互角、コストはSolが約3分の1、速度もSolが優位

GPT-5.6 SolとClaude Fable 5は合格率でほぼ並んだが、単位作業あたりのコストではSolが3倍優位という結果になった。モデル選定で精度以外の要素が重要な理由がここにある。

企業規模別のコスト試算

Neonはこの結果を現実の企業規模に当てはめた。エンジニア1人が1日あたり100万トークンのエージェントタスクを1件実行する前提で、月間トークン消費を推計した。入力8割、出力2割、キャッシュや割引なしという保守的条件だ。

その結果、モデルにLlama 3.1 8B Instruct(3番目に安い)を選ぶか、Claude Fable 5(3番目に高い)を選ぶかで、50人のエンジニア規模なら月間1万8千ドルの差が生まれた。500人規模なら18万8千ドル、つまり約86倍の価格差になる。同じ仕事を同じ精度でこなすなら、この差は純粋な利益になる。

ただしNeonはこの試算を「モデル選びだけの話ではない」と補足する。合格率や処理時間、出力品質も含めた総合評価が必要で、単純に安いモデルを選ぶことが正解とは限らないことを認めている。あくまで「選択が巨大なコスト差を生む」という示唆が核心だ。

オープンウェイトとプロプライエタリの比較

オープンウェイトとプロプライエタリの比較

中央値で見たコスト差

オープンウェイトモデルとは、モデルの重みが公開されて誰でも検証・再利用できるタイプを指す。一方、プロプライエタリモデルは重みが非公開で、API経由でのみ利用できる。Neonのベンチマークでは、オープンウェイトモデル11種のコスト中央値が約0.022ドル、プロプライエタリ31種の中央値が約0.281ドルだった。約12.7倍の開きがある。

合格率の中央値はプロプライエタリが69%、オープンウェイトが61%だった。この差は比較的小さく、用途次第ではオープンウェイトの選択が現実的になる場面が多い。使用可能トークンあたりのトークン数も、オープンウェイトが552個(中央値)、プロプライエタリが925個だった。

個別モデルのばらつき

ただし中央値だけ見ると危険だとNeonは警告する。Llama 3.1 8B Instructは高速で安価だが合格率が最低レベル、Qwen3.5 122B-A10Bはカタログ価格が低いのにトークン消費が最多、Gemma 3 12Bは低コストと合格率64%を両立した。個別の特性がまちまちなため、一律に「オープンウェイトが安い」と決めつけるのは誤りだ。

このばらつきこそが、Neonが公開したインタラクティブなベンチマークの価値だ。モデルのカタログ価格ではなく、実際のワークロードで何が起きるかを自分の目で確認できる。Neonはこのベンチマークを最新モデルで継続更新する方針を示している。

この記事のポイント

  • Neonが42から45のAIモデルを対象に、サポートチケット100件の処理コストと品質を同一条件で検証した
  • 最安はGPT-5 Nanoで約3分で処理、最高額はGPT-5.5 Proで8.34ドル、57分を要した
  • 合格率はGPT-5.3 Codexが82件で最高、Llama 3.1 8B Instructは34件で最低だった
  • モデル選択だけで推論コストが約86倍変わり、500人規模なら月間18万8千ドルの差になる
  • カタログ価格が安くてもトークン消費が多いモデルがあり、実測評価が重要である
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オプションを直接削除して再実行
  • テーブル作成権限の確認と重いプラグインの停止も有効