WooCommerceモノレポのビルドが大幅高速化、コールドビルド60%減。メモリ使用量84%削減
WooCommerceのモノレポ（単一リポジトリ）を使った開発において、ビルドにかかる時間とメモリ消費が大幅に改善された。2026年6月5日、Developer WooCommerce Blogで公開された記事によると、コールドビルド時間が60%削減、ウォッチ（ファイル監視）の準備完了時間が75%短縮、開発時ウォッチプロセスのメモリ使用量が84%削減されたという。
計測環境はM4 Maxプロセッサ（48GB RAM、macOS 26）で、ベースラインから顕著な低下を確認している。一連のプルリクエストによってビルドプロセスを再設計し、開発者体験を飛躍的に向上させた内容を解説しよう。
本記事では、実際に実施されたビルド最適化の技術的詳細と、今後のCIスループット向上計画を紹介する。
WooCommerceモノレポのビルドが抱えていた課題
WooCommerceのコードベースは多数のパッケージと連携しており、開発時のwatch:buildコマンドは最大128個のプロセスを起動していた。それぞれがESM（ECMAScript Modules）やCJS（CommonJS）、webpackによる監視を分担し、さらにwireitモニターとPNPMのランチャープロセスが重なり、24.4GBものメモリを消費する状態だった。
このままでは開発マシンのリソースを圧迫し、CI（継続的インテグレーション）実行時にもジョブの待機時間が増大する。ビルド速度の遅延はフィードバックサイクルを長びかせ、生産性に悪影響を及ぼしていた。その根本原因を取り除くため、重複作業の排除とツールチェーンの刷新に着手した。
上記の数値が示す通り、ビルド時間とメモリ消費の両面で大幅な改善が実現された。この結果をもたらした主要な施策は以下の3段階に分けられる。
重複ビルドの排除とTypeScriptコンパイラからの脱却
最初に取り組まれたのは、不必要なモジュール形式のビルド重複の解消だ。WooCommerceはESMとCJSの両方を配布しているが、内部のバンドラ（webpack）ではESMのみが消費されていた。にもかかわらず、開発フローでは常に両方を生成していたため、無駄なビルドコストがかかっていた。
PR #64876では、パブリッシング専用のプリパックビルドコマンドを新設し、普段の開発時にはESMのみを生成するよう分離した。これによりビルドプロセスがスリム化され、コールドビルドの短縮に寄与している。
続いて、TypeScriptのコンパイル基盤をtscからesbuildへ移行するための準備が行われた。型チェックは独立したLintステップに分離し、型定義ファイルの生成はパブリッシュ時のみ実行する方式に切り替えた。こうしてビルド本体からTypeScriptコンパイラを外し、高速なバンドラに置き換える土台が整った。
esbuildへの移行とビルド設定の一元化
型チェックとビルドの分離が完了したあと、全パッケージのビルドをesbuildへ切り替えた。esbuildはGo言語で実装されており、TypeScriptのトランスパイルにおいてtscやBabelよりもはるかに高速だ。この移行だけでウォームビルドの速度は顕著に向上した。
しかし、急いで移行した結果、各パッケージに似たようなbuild.mjsファイルが散在するという新たな課題が生まれた。これに対処するため、PR #65422ではビルド用の内部パッケージ@woocommerce/internal-buildを新設し、従来の設定パッケージ（internal-ts-configやinternal-style-build）を統合した。開発マシン上のスクリプトが整理され、今後の保守性も高まった。
Admin/Blocksによるパッケージビルド統合、メモリ大幅削減の鍵
一連の改善の集大成となったのが、PR #65254で実施されたAdminおよびBlocks向けのビルド統合だ。それまでwatch:buildコマンドが128プロセスも必要だった最大の要因は、Admin用webpackとBlocks用webpackがトランスパイル済みESMを外部パッケージとして消費していたことにある。
このPRでは、各パッケージのソースを直接AdminおよびBlocksのwebpackビルドに含める方式へと変更した。その結果、128プロセスが大幅に削減され、メモリ使用量が24.4GBから3.9GBへと激減した。ウォッチ準備時間も132秒から33秒へと4分の1に短縮されている。
トレードオフとして、パッケージのトランスパイルがesbuildではなくBabelで行われるため、コールドビルドの速度が一部でわずかに後退した（38秒）。しかし、webpackのファイルシステムキャッシュによって日常的な開発では体感されず、E2E（End-to-End）テストのCIジョブが約1分長くなる程度にとどまった。全体のメモリ削減と開発体験の向上に比べれば、十分に許容できる交換だったと言える。
次のターゲットはCIスループットの改善
ビルドプロセス自体の最適化が完了した現在、開発チームはCIのスループット向上に注力する方針だ。WooCommerceのCIはジョブをマトリクスシャーディングで分散実行しているが、GitHub Actionsのワーカーが枯渇しやすく、各ジョブの実行時間が短くなってもワーカー獲得に20分以上待たされる局面がある。
この問題を解消するため、同一ワーカー上で複数のタスクを並列実行する方式への移行が計画されている。ワーカー台数に依存しない設計に切り替えることで、CI全体のスループットを大幅に引き上げる狙いだ。さらに、E2Eテストスイートの高速化として、マルチサイト構成などを活用し、単一環境内でテストスイートを並列実行する手法も検討されている。
これらの施策が実装されれば、コードをプッシュしてからCIが完了するまでの時間がさらに短縮され、開発のスピードは一段と加速するだろう。
この記事のポイント
- WooCommerceモノレポの開発ビルドが全面的に見直され、コールドビルド60%減、メモリ使用量84%減を達成
- 重複ビルドの排除と
esbuild移行により、トランスパイル速度が大幅に向上 - Admin/Blocksへのパッケージ統合で128プロセスを一掃し、メモリ消費を劇的に低減
- 今後のCIスループット改善では、ワーカー枯渇問題の解決と並列化が焦点
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
WordPress開発が劇的に速くなる？次世代ビルドツール「@wordpress/build」の全貌
WordPressのプラグイン開発において、ビルドツールのあり方が大きく変わろうとしている。現在広く使われている @wordpress/scripts の内部エンジンが、より高速でシンプルな @wordpress/build へと移行する計画が進んでいる。この変更は、単なる速度向上にとどまらず、開発者がコードを書く際の手順そのものを効率化するものだ。
2025年10月にプロジェクトが始動し、すでにGutenberg（ブロックエディタ）本体の100以上のパッケージビルドに採用されている。 esbuild（エスビルド）という非常に高速なエンジンを基盤に据えることで、これまでのwebpack（ウェブパック）ベースの環境では数分かかっていた処理が、わずか数秒で完了するようになる。開発の待ち時間がなくなることは、制作現場の生産性に直結する重要な変化だ。
なぜ今、使い慣れたツールを刷新する必要があるのか。それは、WordPress開発における「設定の複雑さ」を解消し、より直感的にコードを書ける環境を整えるためだ。新しいツールが目指すビジョンと、具体的な仕組み、そして今後の開発者がどのように対応すべきかを詳しく解説していく。
WordPressプラグイン開発の新たなスタンダード「@wordpress/build」とは
@wordpress/build は、WordPressコアチームが開発を進めている次世代のビルドツールだ。ビルドツールとは、JavaScriptやCSSなどのソースコードを、ブラウザが読み込める形式にまとめたり、最新の書き方を古いブラウザでも動くように変換したりする道具を指す。
webpack時代の複雑さからの脱却
これまで、WordPressの標準ツールである @wordpress/scripts は、内部でwebpackとBabel（バベル）を使用してきた。これらは非常に多機能で柔軟だが、長年の運用を経て設定が複雑化しすぎている側面があった。特に、依存関係の抽出やPHPファイルの生成など、WordPress特有の処理を組み合わせるために、多くのカスタム設定が必要だった。
結果として、Gutenbergプロジェクト自体が @wordpress/scripts を使わず、独自のカスタムツールでビルドを行うというねじれ現象が起きていた。 @wordpress/build は、この複雑さをツール内部に吸収し、開発者が「設定ファイル」をいじる必要をなくすことを目的としている。
esbuild採用による圧倒的なビルド速度
新しいエンジンの核となるのは esbuild だ。これはGo言語で書かれた非常に高速なバンドラー（ファイルをまとめるツール）で、従来のJavaScript製のツールとは比較にならないほどのパフォーマンスを発揮する。例えるなら、手作業で荷物を仕分けていた倉庫に、最新の高速自動仕分けロボットが導入されるようなものだ。
大規模なプロジェクトでも、フルビルドが数秒で終わる。また、ファイルの変更を監視して自動で再ビルドする「ウォッチモード」では、変更した箇所だけを瞬時に処理するため、修正が即座にブラウザへ反映される。この「待ち時間の消失」こそが、 @wordpress/build を導入する最大のメリットといえるだろう。
「設定」から「規約」へ：新しい開発ワークフロー
@wordpress/build の大きな特徴は、「設定より規約（Convention over Configuration）」という考え方を採用している点にある。これは、あらかじめ決められたルールに従ってフォルダやファイルを配置すれば、ツールが自動的に中身を判断して適切に処理してくれる仕組みだ。
フォルダ構成がそのまま設定になる仕組み
従来のように「どのファイルが入り口（エントリポイント）か」をコードで指定する必要はない。プロジェクト内に特定の名前のフォルダを作るだけで、ツールがビルド対象を自動検知する。
packages/：JavaScriptのパッケージを配置する場所。各サブフォルダが1つのパッケージとして扱われる。routes/：管理画面のルーティング（ページ構成）を定義する場所。blocks/：ブロックのソースコードを置く場所（現在提案中の機能）。
このルールに従うだけで、ツールは各フォルダ内の package.json を読み取り、必要なJavaScriptやスタイルシートを生成する。開発者は「どこに何を書くか」というルールさえ覚えれば、ビルド設定の迷宮に迷い込むことはなくなる。
package.jsonによるシンプルな管理
個別の設定が必要な場合も、webpack.config.jsのような専用ファイルは使わず、 package.json 内に記述する。例えば、あるパッケージをブラウザで読み込むスクリプトとして登録したい場合は、以下のように記述するだけで済む。
{
"name": "@my-plugin/utility",
"wpScript": true
}これだけで、ツールはこのパッケージを「IIFE（即時実行関数式）」形式でビルドし、WordPressの管理画面で適切に読み込めるように準備してくれる。IIFEとは、他のプログラムと名前がぶつからないようにコードをカプセル化する手法のことだ。専門的な知識が必要だった設定が、1行のフラグ指定に集約されている。
PHP登録作業を自動化する革新的な機能
WordPress開発者を悩ませる作業の1つに、JavaScriptファイルを読み込むための wp_enqueue_script() などのPHP記述がある。 @wordpress/build は、このPHP側の登録作業も自動化する道筋を示している。
手動のPHP記述が不要になるメリット
これまでは、ビルドされたファイルのパスを確認し、依存するスクリプト（wp-elementやwp-i18nなど）を手動で配列に書き出す必要があった。新しいツールでは、ビルドプロセスの一環として build/build.php というファイルが生成される。プラグインのメインファイルでこれを1行読み込むだけで、すべての登録が完了する。
require_once plugin_dir_path( __FILE__ ) . 'build/build.php';このファイルには、スクリプト、モジュール、スタイルシートの登録処理がすべて含まれている。開発者がPHP側で「どのファイルを読み込むか」を管理する必要がなくなるため、ファイル名の変更や依存関係の追加に伴うケアレスミスを劇的に減らすことができる。
アセット管理と依存関係の自動解決
JavaScript側で import { __ } from '@wordpress/i18n'; と書けば、ツールは自動的に「このスクリプトはwp-i18nに依存している」と判断し、 .asset.php ファイルを作成する。これは従来も @wordpress/scripts で提供されていた機能だが、 @wordpress/build ではさらに強化されている。
例えば、最新の「スクリプトモジュール（ESM）」と従来のスクリプトの使い分けも、設定一つで切り替え可能だ。さらに、WordPress 6.8で導入された効率的なブロック登録機能（WP_Block_Metadata_Registry）への対応も進められており、最新のコア機能の恩恵を最小限の手間で受けられるようになる。
名前空間と外部依存関係の高度な制御
大規模なプラグインや、複数のプラグインが連携する環境では、「名前空間（Namespace）」の管理が重要になる。 @wordpress/build では、自分のプラグインが提供する機能を他のプラグインからどう参照させるかを、明快に定義できる仕組みが備わっている。
プラグイン間でのスクリプト共有が容易に
例えば、WooCommerceのような他のプラグインが提供するJavaScript機能を利用したい場合、 package.json に外部名前空間として定義する。これにより、コード内で import { Cart } from '@woo/cart'; と書くだけで、実行時には window.woo.cart を参照し、依存関係のリストに自動で追加される。
これは、複数のスクリプトが同じライブラリを二重に読み込んでしまう問題を回避し、サイト全体のパフォーマンス向上に寄与する。開発者は複雑なフックの順序を気にすることなく、モダンなJavaScriptの書き方でプラグイン間の連携を実装できるのだ。
今後のロードマップと開発者が今すべきこと
@wordpress/build は現在も活発に開発が進んでいる段階だ。すぐにすべてのプロジェクトを移行すべきかというと、そうではない。公式のロードマップでは、段階的な統合が予定されている。
@wordpress/scriptsとの統合プロセス
将来的には、 @wordpress/scripts の中身が @wordpress/build に置き換わる予定だ。つまり、開発者は今まで通り npm run build を実行するだけで、内部的に新しい高速エンジンが動くようになる。この際、標準的な設定を使っている開発者は、コードを一切変更することなく、ビルド速度の向上という恩恵を受けられる見込みだ。
一方で、webpackの設定を細かくカスタマイズしている場合は、将来的に移行ガイドを参照しながら調整が必要になる可能性がある。コアチームは、この移行を可能な限りスムーズに進めるためのAPI設計に注力している。
早期導入のメリットと注意点
現在、複数のパッケージを持つ大規模なプラグインを開発しているエンジニアにとって、 @wordpress/build を試す価値は十分にある。モノレポ（複数のパッケージを1つのリポジトリで管理する手法）構成での開発効率が格段に上がるからだ。
ただし、ブロック登録周りなど、まだ手動での作業が必要な箇所も残っている。現時点では実験的な導入にとどめ、GitHubのGutenbergリポジトリで進行中のディスカッションに参加し、フィードバックを送るのが最も賢明な関わり方といえるだろう。特に「blocks/フォルダをルートに置く規約」についての議論は、今後のプラグイン構造の標準を決める重要なポイントだ。
独自の分析：WordPress開発体験（DX）はどう変わるか
今回の @wordpress/build への移行は、WordPressが「独自の進化」から「モダンなWeb標準との融合」へと、さらに一歩踏み出したことを象徴している。 esbuildのような最先端のツールを標準に取り入れることで、WordPress開発特有の「古臭さ」や「設定の煩わしさ」が解消されようとしている。
特に注目すべきは、PHPとJavaScriptの境界線がより曖昧になり、自動化が進む点だ。これまでWordPressエンジニアには、フロントエンドの知識と、それをWordPressに登録するためのPHPの知識の両方が高いレベルで求められてきた。この「登録」という非創造的な作業が自動化されることで、開発者は「ユーザーにどんな機能を提供するか」という本来の目的に集中できるようになる。
また、ビルドが高速化されることは、単に時間の節約になるだけではない。試行錯誤の回数が増え、結果としてコードの品質が向上する。保存した瞬間に画面が変わる「ライブな開発体験」は、開発者のモチベーションを維持する上でも極めて重要だ。 @wordpress/build は、WordPressを「古いブログシステム」から「洗練されたアプリケーションプラットフォーム」へと進化させるための、強力なインフラになるだろう。
この記事のポイント
@wordpress/buildは@wordpress/scriptsの次世代エンジンとして開発されている。- esbuildの採用により、ビルド速度が分単位から秒単位へと劇的に高速化される。
- 「設定より規約」を重視し、フォルダ構成に従うだけで自動ビルドが可能になる。
- PHP側のスクリプト登録処理が自動生成され、手動での記述が不要になる。
- 将来的には既存のツールに統合されるため、標準的な構成なら変更なしで恩恵を受けられる。
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験