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

by KAKEHASHI

Slide 1

Slide 1 text

©KAKEHASHI inc. 爆速でプロダクトをリリースしようと思ったらマイクロフロントエンドを選んでいた 2025/09/21 Nokogiri@株式会社カケハシフロントエンドカンファレンス東京

Slide 2

Slide 2 text

©KAKEHASHI inc. 自己紹介 2 Nokogiri（@nkgrnkgr） X | Bluesky | Github 株式会社カケハシ（ヘルステックスタートアップ）生成AI研究開発チームソフトウェアエンジニア React / TypeScript / フロントエンド大好き！二児の父👶 ポケモン対戦大好き！

Slide 3

Slide 3 text

©KAKEHASHI inc. マイクロフロントエンドとは 1 3

Slide 4

Slide 4 text

©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

Slide 5

Slide 5 text

©KAKEHASHI inc. 2. なぜ自分たちのプロダクトでマイクロフロントエンドを採用したか 5 独立して開発、デプロイ、テスト、保守できるアーキテクチャ・組織戦略として解釈

Slide 6

Slide 6 text

©KAKEHASHI inc. なぜ自分たちのプロダクトでマイクロフロントエンドを採用したか 2 6

Slide 7

Slide 7 text

©KAKEHASHI inc. 2. なぜ自分たちのプロダクトでマイクロフロントエンドを採用したか ● クラウド型電子薬歴システム ● リリースして約10年 ● 全国の薬局の約20%で利用 Musubiの紹介 7

Slide 8

Slide 8 text

©KAKEHASHI inc. 2. なぜ自分たちのプロダクトでマイクロフロントエンドを採用したか ● 薬局の業務を支えている ○ ミッションクリティカル ○ 高い品質が求められる ● プロダクトの安定性が重要 ○ 丁寧な検証 ○ 月次の計画的なリリースサイクル Musubiの特徴 8 薬局業務システムとしての安定性が重要

Slide 9

Slide 9 text

©KAKEHASHI inc. 2. なぜ自分たちのプロダクトでマイクロフロントエンドを採用したか 9 そんなMusubiにも生成AIを搭載した新機能を作りたい！！

Slide 10

Slide 10 text

©KAKEHASHI inc. 2. なぜ自分たちのプロダクトでマイクロフロントエンドを採用したか ● ユーザーの価値検証をすばやく繰り返したい ● 技術的な不確実性が高い ● 必要なスキルセットが既存と大きく異なる → 生成AI用の専門チームを組成今回開発する生成AI機能は 10 小さく試して小さく失敗するトライを繰り返したい

Slide 11

Slide 11 text

©KAKEHASHI inc. 2. なぜ自分たちのプロダクトでマイクロフロントエンドを採用したか 11 安定性を重視するMusubiに試行錯誤をしたい生成AI機能を搭載するには？

Slide 12

Slide 12 text

©KAKEHASHI inc. 2. なぜ自分たちのプロダクトでマイクロフロントエンドを採用したか 12 両者を独立して開発、デプロイ、テスト、保守できるアーキテクチャ・組織戦略が必要

Slide 13

Slide 13 text

©KAKEHASHI inc. 2. なぜ自分たちのプロダクトでマイクロフロントエンドを採用したか 13 選択した戦略・アーキテクチャ戦略内容体制 Musubiと生成AI機能は開発チームを別にするデリバリーリリースをMusubiと別にし、生成AI機能単体でリリース可能 UI Musubi非依存のUIとし開発し影響を受けにくくする実装 Angularではなく、Reactに⻑けたメンバーがReactで開発するチーム・アーキテクチャの独立性を重視した結果

Slide 14

Slide 14 text

Slide 15

Slide 15 text

©KAKEHASHI inc. 設計編：マイクロフロントエンドを支える技術 Angular×Reactの共存 / Musubi非依存UI / アプリ間通信 3 15

Slide 16

Slide 16 text

©KAKEHASHI inc. 3. 設計編：マイクロフロントエンドを支える技術 Vite でビルドした Reactアプリの JS と CSS を事前にホスティング Angular アプリにあらかじめ

を用意し、JS、CSS ファイルをロード divタグに対してReactのJSがレンダリングすることでAngularとReactを共存させている AngularとReactアプリを共存させるアーキテクチャ 16

Slide 17

Slide 17 text

©KAKEHASHI inc. 3. 設計編：マイクロフロントエンドを支える技術 MusubiのUIの中に組み込むのではなく、”上” に配置して動作するアプリをめざす Musubi非依存UI 17

Slide 18

Slide 18 text

©KAKEHASHI inc. 3. 設計編：マイクロフロントエンドを支える技術アプリケーション間通信 18 CustomEventを使った通信 ● Angular,Reactに依存しないWeb標準の技術 ● アプリケーション固有のイベントを定義して情報のやりとりができる ● 直接的な依存関係がなくともやりとりができるので疎結合にできる

Slide 19

Slide 19 text

©KAKEHASHI inc. 実践編：導入して見えた課題と工夫マイクロフロントエンドで出てきた課題や、泥臭い対応などを紹介 4 19

Slide 20

Slide 20 text

©KAKEHASHI inc. CustomEventのキーとペイロードの組み合わせを定義 Mapped Type を使って型安全に管理定義内容をチーム間で合意 4. 実践編：導入して見えた課題と工夫型定義で通信仕様を固める 20

Slide 21

Slide 21 text

©KAKEHASHI inc. 4. 実践編：導入して見えた課題と工夫アプリ間のページ遷移の同期 21 Angular（メイン）とReact（サブ）のアプリの両方にページ概念がある例）メインで患者Aのページを表示するときは、サブも患者Aの情報を出す必要がある基本的メインのページ遷移時にサブが追従するルールにしているが、サブがメインにページ遷移を要求したい場合もある両方がページ遷移を要求しあっても上手く制御できる機構が必要

Slide 22

Slide 22 text

©KAKEHASHI inc. 4. 実践編：導入して見えた課題と工夫 ”CustomEventを受領できたか”を確認したい 22 CustomEventは基本「投げっぱなし」。しかし送信側が「受信側が受け付けたか」を知りたい場面がある送信側: 一意なid付きでEventを発火受信側:イベントを受け取り、結果作成受信側: 同じidを含む応答イベント（受領通知）を musubi_ack_${id} で返す送信側: ackを待ち受け、結果を受け取ってUIやログに反映

Slide 23

Slide 23 text

Slide 24

Slide 24 text

Slide 25

Slide 25 text

©KAKEHASHI inc. 4. 実践編：導入して見えた課題と工夫 CustomEventのデバッグ 25 CustomEventのやり取りは、どんなイベントが発生したかを確認しづらい。流れを可視化する Chrome拡張機能を作成して、イベントの流れを見える化した。

Slide 26

Slide 26 text

©KAKEHASHI inc. 4. 実践編：導入して見えた課題と工夫ローカル開発環境：読み込むJS/CSSを差し替え 26 AngularがReactのJSとCSSを動的に読み込む仕組みにしているため、 URLを切り替えることで任意の環境の組み合わせができる chrome.declarativeNetRequest というAPIを使い、Angularが読み込むJS/CSSファイルのURLをランタイムで動的に差し替える Chrome拡張機能を作成例えば Angularはデプロイされた検証環境、ReactはLocal開発環境という組み合わせで動かすことができる

Slide 27

Slide 27 text

©KAKEHASHI inc. 4. 実践編：導入して見えた課題と工夫その他の泥臭い工夫 27 ● 一部でネットワーク通信のような振る舞いが必要 ● 生成AI機能チームが自らMusubi側のコードを修正し、PRを投げる ● グローバルCSSの影響の影響で意図せずレイアウトが崩れる ● z-index の管理が煩雑

Slide 28

Slide 28 text

©KAKEHASHI inc. 4. 実践編：導入して見えた課題と工夫さらに詳しく知りたい方へ 28 CustomEventやローカル開発環境の詳細は、以下のブログにも詳しく記載しています。併せてご確認ください。型とテストで守るカスタムイベント通信 - 実プロダクトでの実装事例生成AIで内部ツール開発のジレンマを解決する

Slide 29

Slide 29 text

Slide 30

Slide 30 text

©KAKEHASHI inc. 5. 総括おわりに 30 マイクロフロントエンドを選んだ結果: ● 多くの苦労はあったものの、開発着手から4か月でリリースできた ● ユーザーからのフィードバックを受け、毎週リリースして素早く改善している ● 1つのアプリケーションにAngularアプリとReactアプリの共存ができた ● 異なるミッションを持ったチームが、独立して開発を継続できる体制が整った伝えたいこと: ● まずビジネスとして達成したいゴールを定め、そこからアーキテクチャ・戦略を選ぶことも大切 ● ビジネスの要求に応えるために、このような選択肢もあることを知っておいてほしい