はじめに

この記事は GameWith アドベントカレンダー2025 2日目の記事です。

こんにちは。GameWith サービス開発部のスケールアーキテクトチームです。

GameWith では、昨年頃から GMF (GameWith Micro Frontend) と呼ばれるマイクロフロントエンドベースの開発基盤を試験的に導入していました。運用環境やナレッジが整ってきた今年は、ゲーム攻略ツールや掲示板、社内向け管理画面などの様々なプロジェクトで本格的に活用され、現在では40個以上のフロントエンドアプリケーションがGMF上でリリースされています。

今回はGMFが生まれた背景や技術的な構成について紹介します。

GMF (GameWith Micro Frontend)とは

GMFは、マイクロフロントエンドの要素を部分的に採用し、GameWithのフロントエンド領域を効率的に開発することを目的とした開発・デプロイ基盤です。

マイクロフロントエンドの考え方をベースに、機能を小さく疎結合性を高めて開発するのが目的で、GameWith全体をマイクロフロントエンド化しようとするものではありません。

実際にGMFで開発されている機能の一部を紹介すると、ポケモンZAの対戦掲示板や、英語版を中心に展開しているPosiMakerというツールなどがあります。

これらは後述するGMFの特徴でもある、新しい技術選定や既存機能の安全なアップデート方法として有効に活用できました。

GMFの開発背景

GMFが生まれる前からGDS (GameWith Design System) と呼ばれる、デザインシステムと小規模なフロントエンドアプリケーションを一元管理する開発基盤が存在していました。GDSの詳細に関しては過去記事があるので、こちらをご覧ください。

tech.gamewith.co.jp

GDSは数年に渡ってGameWithの開発スピードを加速させてきた存在ですが、GameWithの開発組織内での需要の変化などにより、新しい開発基盤の必要性が高まっていました。そしてGDSをメインで利用していたチームのメンバーと有志メンバーで、GMFの開発が始まりました。

GDSでの課題

GMF検討メンバーで、GDSに感じている課題などの洗い出しを行った結果、次のような課題が出てきました。

GameWithのサービスの性質上、ゲーム毎に特化したツールなどを開発する場面が多く、デザインシステムとしての利用よりもゲーム専用の小規模アプリケーションの開発需要が高まっていた
GDSではVue.jsをWeb Componentsライブラリとしてビルドしており、初期表示まで時間がかかるケースがある
GDSはVue.js v2 + Vue CLIで実装されており、Vue.js v3への移行の際に影響範囲が広く、アップデートコストが高い
今後はReactなどの他フレームワークの採用も積極的に行いたい

GMFの特徴

先述の課題を踏まえて、GMFでは次のような方針を採用しました。

マイクロフロントエンドの要素を部分採用

マイクロフロントエンドの要素を部分採用し、各アプリケーションを独立して開発・デプロイできる状態を目指しました。これにより、GDSと比較してGameWith内のフロントエンド領域の疎結合性を保ちながら、効率の良いフロントエンド開発が行えるようになったと思います。

マイクロフロントエンドの採用例ではよくiframeやWebComponentsによるカプセル化を行う例を見かけますが、GDSでの課題も踏まえてデフォルトでカプセル化は行わずにアプリケーションを任意のdiv要素にレンダリングしています。createRoot(element).render() などを必要各所で行っているイメージです。もちろん同一ページの中に複数のGMFのアプリケーションが動作することも可能です。

後述しますがGMFではアプリケーションごとにビルド環境レイヤーから柔軟な技術選定が可能なので、担当者やチームの判断でWebComponents化してカプセル化を行うことも可能です。

モノレポで複数のアプリケーションを管理

1つのリポジトリで複数のアプリケーションを管理するモノレポ構成を採用しています。これにより、CI/CD設定の共通化や共通パッケージの再利用が容易になっています。

個別のリポジトリにすると共通パッケージを利用するためにプライベートレジストリ等を使う必要が出てくるので、モノレポ採用は社内共通パッケージ利用の費用を抑えるメリットもあります。

パッケージマネージャーとモノレポの管理にはpnpmを採用しています。pnpmは厳密かつ効率的な依存解決とキャッシュによる高速なパッケージのインストールが特徴的で、現状40個以上のアプリケーションが存在するGMFのCI実行時でも30秒程で全てのパッケージのインストールが終わります。

大まかなディレクトリ構造は下記のようになっています。

apps: フロントエンドアプリ
apis: appsから利用する軽微なAPIなど
packages: appsやapiで利用する共通パッケージ
tools: 開発環境やCI/CDで利用するツール

apps/
  ├─ application-1/
  │  ├─ package.json
  │  └─ ...
  ├─ application-2/
  │  ├─ package.json
  │  └─ ...
  └─ ...
apis/
  ├─ functions-api-1/
  │   ├─ package.json
  │   └─ ...
  ├─ functions-api-2/
  │   ├─ package.json
  │   └─ ...
  └─ ...
packages/
  ├─ eslint-config/
  │  ├─ package.json
  │  └─ ...
  ├─ prettier-config/
  │  ├─ package.json
  │  └─ ...
  └─ ...
tools/
  └─ create-app/
package.json
pnpm-workspace.yaml

アプリケーションごとの柔軟な技術選定

GMFの本質としてはモノレポの開発環境とデプロイ環境を提供することで、最低限のnpm scriptsのルールに沿っていれば、CI/CDによるビルドからデプロイが可能です。

そのため、ビルドシステムやフレームワークの制約はほとんどなく、これまでGDSで使われてきたVue.jsだけでなくReactやその他フロントエンドフレームワークの採用も可能です。これはフレームワークやライブラリに限らずビルドシステムも同様で、現状はviteが採用されていますがそれ以外のビルドツールを使うことも可能です。

ただし毎回自前でビルド環境から自作するのは手間なので、よく使われる vite + Vue.js と vite + React のアプリケーションのテンプレートや、推奨設定を提供するための共通パッケージなどが用意されており、GMF内のcreate-appコマンドで簡単に新規アプリケーションのセットアップが可能です。テンプレートのラインナップや内容は、需要やトレンドに合わせて随時更新予定です。

pnpm create-app <アプリケーション名> --template <テンプレート名>

ビルドシステムごと独立させたことによって疎結合性が高まり、これまで以上にアプリケーションの担当チームがオーナーシップを持って開発やアップデートを進めることが可能になりました。

GDSの機能をGMFに移行しやすく

GDSでは課題にもあがったようにVue.js v2からv3へのアップデートコストが高い状態にありましたが、GMFでは他のアプリケーションへの影響は基本的に無いので、GDSの一部の小規模アプリケーションをGMFの新しいアプリケーションとして移植し、ついでにVue.js v3にアップデートするということも可能で、この方法で他機能に影響を与えずに安全にアップデート作業を進めることが可能になりました。既にGDSからGMFへ移植されている機能もいくつかあります。

GDS自体は現在でも利用可能で、それぞれの性質を把握した上で適したものを使ってくださいというのが現状のスタンスです。