爆速でプロダクトをリリースしようと思ったらマイクロフロントエンドを選んでいた

フロントエンドカンファレンス東京 2025
https://fec-tokyo.connpass.com/event/352581/
での登壇資料です

Transcript

1. ©KAKEHASHI inc. 爆速でプロダクトをリリースしようと思ったら マイクロフロントエンドを選んでいた 2025/09/21 Nokogiri@株式会社カケハシ フロントエンドカンファレンス東京
2. ©KAKEHASHI inc. 自己紹介 2 Nokogiri（@nkgrnkgr） X | Bluesky | Github 株式会社カケハシ（ヘルステックスタートアップ） 生成AI研究開発チーム ソフトウェアエンジニア React / TypeScript / フロントエンド大好き！ 二児の父👶 ポケモン対戦大好き！
3. ©KAKEHASHI inc. マイクロフロントエンドとは 1 3
4. ©KAKEHASHI inc. 1.マイクロフロントエンドとは 4 ”An architectural style where independently deliverable frontend applications are composed into a greater whole” 「独立してリリース可能なフロントエンドアプリケーションを より大きな全体に構成するアーキテクチャスタイル」 引用：https://martinfowler.com/articles/micro-frontends.html
5. ©KAKEHASHI inc. 2. なぜ自分たちのプロダクトでマイクロフロントエンドを採用したか 5 独立して開発、デプロイ、テスト、保守できる アーキテクチャ・組織戦略 として解釈
6. ©KAKEHASHI inc. なぜ自分たちのプロダクトで マイクロフロントエンドを採用したか 2 6
7. ©KAKEHASHI inc. 2. なぜ自分たちのプロダクトでマイクロフロントエンドを採用したか • クラウド型電子薬歴システム • リリースして約10年 • 全国の薬局の約20%で利用 Musubiの紹介 7
8. ©KAKEHASHI inc. 2. なぜ自分たちのプロダクトでマイクロフロントエンドを採用したか • 薬局の業務を支えている ◦ ミッションクリティカル ◦ 高い品質が求められる • プロダクトの安定性が重要 ◦ 丁寧な検証 ◦ 月次の計画的なリリースサイクル Musubiの特徴 8 薬局業務システムとしての安定性が重要
9. ©KAKEHASHI inc. 2. なぜ自分たちのプロダクトでマイクロフロントエンドを採用したか 9 そんなMusubiにも 生成AIを搭載した 新機能を作りたい！！
10. ©KAKEHASHI inc. 2. なぜ自分たちのプロダクトでマイクロフロントエンドを採用したか • ユーザーの価値検証をすばやく繰り返したい • 技術的な不確実性が高い • 必要なスキルセットが既存と大きく異なる → 生成AI用の専門チームを組成 今回開発する生成AI機能は 10 小さく試して小さく失敗するトライを繰り返したい
11. ©KAKEHASHI inc. 2. なぜ自分たちのプロダクトでマイクロフロントエンドを採用したか 11 安定性を重視するMusubiに 試行錯誤をしたい生成AI機能を 搭載するには？
12. ©KAKEHASHI inc. 2. なぜ自分たちのプロダクトでマイクロフロントエンドを採用したか 12 両者を 独立して開発、デプロイ、テスト、保守できる アーキテクチャ・組織戦略が必要
13. ©KAKEHASHI inc. 2. なぜ自分たちのプロダクトでマイクロフロントエンドを採用したか 13 選択した戦略・アーキテクチャ 戦略 内容 体制 Musubiと生成AI機能は開発チームを別にする デリバリー リリースをMusubiと別にし、生成AI機能単体でリリース可能 UI Musubi非依存のUIとし開発し影響を受けにくくする 実装 Angularではなく、Reactに⻑けたメンバーがReactで開発する チーム・アーキテクチャの独立性を重視した結果
14. © KAKEHASHI Inc. All Rights Reserved. 小休止
15. ©KAKEHASHI inc. 設計編：マイクロフロントエンドを支える技術 Angular×Reactの共存 / Musubi非依存UI / アプリ間通信 3 15
16. ©KAKEHASHI inc. 3. 設計編：マイクロフロントエンドを支える技術 Vite でビルドした Reactアプリの JS と CSS を 事前にホスティング Angular アプリにあらかじめ <div id="react-component" /> を用意し、JS、CSS ファイルをロード divタグに対してReactのJSがレンダリングするこ とでAngularとReactを共存させている AngularとReactアプリを共存させるアーキテクチャ 16
17. ©KAKEHASHI inc. 3. 設計編：マイクロフロントエンドを支える技術 MusubiのUIの中に組み込むのではなく、”上” に配置して動作するアプリをめざす Musubi非依存UI 17
18. ©KAKEHASHI inc. 3. 設計編：マイクロフロントエンドを支える技術 アプリケーション間通信 18 CustomEventを使った通信 • Angular,Reactに依存しないWeb標準 の技術 • アプリケーション固有のイベントを定義し て情報のやりとりができる • 直接的な依存関係がなくともやりとりが できるので疎結合にできる
19. ©KAKEHASHI inc. 実践編：導入して見えた課題と工夫 マイクロフロントエンドで出てきた課題や、泥臭い対応などを紹介 4 19
20. ©KAKEHASHI inc. CustomEventのキーとペイロードの組 み合わせを定義 Mapped Type を使って型安全に管理 定義内容をチーム間で合意 4. 実践編：導入して見えた課題と工夫 型定義で通信仕様を固める 20
21. ©KAKEHASHI inc. 4. 実践編：導入して見えた課題と工夫 アプリ間のページ遷移の同期 21 Angular（メイン）とReact（サブ）のアプリの両方にページ概念がある 例）メインで患者Aのページを表示するときは、サブも患者Aの情報を出す 必要がある 基本的メインのページ遷移時にサブが追従するルールにしているが、 サブがメインにページ遷移を要求したい場合もある 両方がページ遷移を要求しあっても上手く制御できる機構が必要
22. ©KAKEHASHI inc. 4. 実践編：導入して見えた課題と工夫 ”CustomEventを受領できたか”を確認したい 22 CustomEventは基本「投げっぱなし」。 しかし送信側が「受信側が受け付けたか」 を知りたい場面がある 送信側: 一意なid付きでEventを発火 受信側:イベントを受け取り、結果作成 受信側: 同じidを含む応答イベント（受領 通知）を musubi_ack_${id} で返す 送信側: ackを待ち受け、結果を受け取っ てUIやログに反映
23. ©KAKEHASHI inc. 4. 実践編：導入して見えた課題と工夫 ”CustomEventを受領できたか”を確認したい 23 送信側
24. ©KAKEHASHI inc. 4. 実践編：導入して見えた課題と工夫 ”CustomEventを受領できたか”を確認したい 24 受信側
25. ©KAKEHASHI inc. 4. 実践編：導入して見えた課題と工夫 CustomEventのデバッグ 25 CustomEventのやり取りは、どんなイベントが発生したかを確認しづらい。 流れを可視化する Chrome拡張機能 を作成して、イベントの流れを見える化した。
26. ©KAKEHASHI inc. 4. 実践編：導入して見えた課題と工夫 ローカル開発環境：読み込むJS/CSSを差し替え 26 AngularがReactのJSとCSSを動的に読み込む仕組みにしているため、 URLを切り替えることで任意の環境の組み合わせができる chrome.declarativeNetRequest というAPIを使い、Angularが 読み込むJS/CSSファイルのURLをランタイムで動的に差し替える Chrome拡張機能 を作成 例えば Angularはデプロイされた検証環境、ReactはLocal開発環境という組 み合わせで動かすことができる
27. ©KAKEHASHI inc. 4. 実践編：導入して見えた課題と工夫 その他の泥臭い工夫 27 • 一部でネットワーク通信のような振る舞いが必要 • 生成AI機能チームが自らMusubi側のコードを修正し、PRを投げる • グローバルCSSの影響の影響で意図せずレイアウトが崩れる • z-index の管理が煩雑
28. ©KAKEHASHI inc. 4. 実践編：導入して見えた課題と工夫 さらに詳しく知りたい方へ 28 CustomEventやローカル開発環境の詳細は、以下のブログにも詳しく記載しています。 併せてご確認ください。 型とテストで守るカスタムイベント通信 - 実プロダクトでの実装事例 生成AIで内部ツール開発のジレンマを解決する
29. ©KAKEHASHI inc. 総括 5 29
30. ©KAKEHASHI inc. 5. 総括 おわりに 30 マイクロフロントエンドを選んだ結果: • 多くの苦労はあったものの、開発着手から4か月でリリースできた • ユーザーからのフィードバックを受け、毎週リリースして素早く改善している • 1つのアプリケーションにAngularアプリとReactアプリの共存ができた • 異なるミッションを持ったチームが、独立して開発を継続できる体制が整った 伝えたいこと: • まずビジネスとして達成したいゴールを定め、そこからアーキテクチャ・戦略を選ぶことも大切 • ビジネスの要求に応えるために、このような選択肢もあることを知っておいてほしい
31. © KAKEHASHI Inc. All Rights Reserved. We Are Hiring!!! PM EM エンジニア積極採用中