ども！最近 .claude/skills/ の中身が増えすぎて整理に追われている龍ちゃんです。 スキルって、増えてくると 狙ったやつが発火しなくなる んですよね。ぼくの .claude/skills/ はいま 15 個くらい。とくにレビュー系が 5 個ほど並んだ頃から、しっかり指示しないと違うレビューが走るようになって、「レビューして」の一言がもう信用できなくなりました。 今日は、その問題を 複数のスキルを 1 つの “ルーター” に集約して、発話で振り分ける ようにして解決した話をします。スキルを消して減らすんじゃなくて、束ねて減らす。このプロジェクトのレビュー系スキルで、実際にやったやつです。 スキルが増えるほど誤発火する：budget は静かに削れていく そもそも、なんでこんなに増えたのか。レビュー観点を思いつくたびに、スキルを 1 個ずつ足していったからです。技術的な正確さ、文章の質、SEO、競合比較……「観点が 1 個 ＝ スキルが 1 個」でやっていたら、レビュー系だけでみるみる膨らみました。 そして、痛みが 2 つ出てきます。 1 つめは、 表に出る痛み＝誤発火 。似た description が並ぶと、Claude Code がどれを動かすか迷うんです。「レビューして」と言っても狙ったのと違うレビューが走る。毎回しっかり指示を足さないと、思ったスキルが発火しない。ただこれは、動いた結果が変だからすぐ気づけます。 2 つめは、 気づけない痛み＝character budget 。スキルの description は常時コンテキストに積まれていて、スキルが増えるほど膨らみます。そして budget を超えると、Claude Code は description を自動で切り詰める。マッチに必要なキーワードごと削られて、 自分は何も変えていないのに、ある日スキルが静かに発火しなくなる （ 公式ドキュメント にも “descriptions are shortened to fit the character budget, which can strip the keywords Claude needs to match your request” と明記された挙動です）。 /doctor を叩けば budget 超過と影響スキルは見えますが、意識しないと気づけません。誤発火と違って「壊れたことにすら気づきにくい」のが、こっちのタチの悪いところです。 budget の文字数や仕組みを深掘りすると長くなるので、ここでは「個数が増えると description が削られて発火が劣化する」という前提だけ。詳しくは 別記事「『Skill listing will be truncated』の正体と直し方」 で。 表の痛みも裏の痛みも、根っこは同じ「スキルの個数」でした。だったら、個数そのものを減らせばいい。冒頭で言った “束ねて減らす” を、ここから具体的に見せていきます。 文脈で束ねる ＝ ルーター Skill ルーター Skill の役割は 自分で処理しないこと 。発話の修飾語を読んで、適切な sub-agent を選び、 Agent tool で起動するだけです。 ポイントは、 スキルの description は常時コンテキストに載り、 character budget を食う ということ。スキルが N 個あれば N 個分が積まれ、似た発火条件どうしが競合して誤発火します。ルーターにすれば、スキルとして登録するのは 1 個です。常時載る description も 1 個分 に減ります。各機能のロジックは呼ばれたときに 別コンテキストで動く agent へ、ナレッジは必要なときだけ読む references へ逃がしてあるので、ルーター本体（＝常時載る description）は薄いまま保てます。 つまり、 発火条件を 1 つに統合したから誤発火が消え、常時載る description が N→1 に減ったから budget が空く 。この 2 つは別々の効果じゃなくて、「発火条件＝description を 1 つにまとめた」ことの裏表なんですよね。 具体例で見てみましょう。僕が束ねたのはブログ記事のレビュー系でしたが、仕組みはどんなレビューでも同じです。なのでここは、エンジニアに一番馴染むであろう コードレビュー で説明します。 セキュリティ・パフォーマンス・フロント・バックエンド……観点ごとに別々のスキルを作る代わりに、1 つの code-review ルーターにまとめて、発話で呼び分ける。こんなイメージです。 --- name: code-review description: | コード (src/**) を編集している文脈で発火するレビュー router。 「レビューして」「セキュリティ見て」「フロントだけ」「バックだけ」 「パフォーマンス見て」「全部見て」等の発話で発火する。 発話の修飾語から起動する sub-agent を選択し、Agent tool で並列起動する。 allowed-tools: Read, Glob, Agent --- 発話に含まれる語 起動する sub-agent （修飾なし）「レビューして」 security + performance + readability（並列） 「セキュリティ見て」 security-review のみ 「フロントだけ」 frontend-review のみ 「バックエンドだけ」「API だけ」 backend-review のみ 「パフォーマンスだけ」 performance-review のみ 「全部見て」 用意したレビュー全部を並列 「レビューして」だけで 3 エージェントが並列で走る！これが Slash Command 単体にはない強みです。スラッシュコマンドは 1 回の呼び出しで 1 つの処理ですが、ルーター Skill は複数 sub-agent を同時に走らせられます。 以前書いた「 Claude Codeのドキュメント検索を極力さぼれるようにした話 」も、サブエージェントに処理を委譲して use_when で呼び出す設計で、考え方が重なります。 ロジックは agent へ、ナレッジは references/ へ ルーター SKILL.md 自体は 薄く保ちます 。そして束ねるのは sub-agent だけじゃありません。 「どう処理するか」のロジックは agent へ、「何を見るか・どう使うか」のナレッジは references/ 」と、役割で 3 層に分けます。 ルーター SKILL.md（薄く）── 発火条件 + 修飾語 → 振り分けだけ ↓ 呼び出す .claude/agents/*.md ──────── 処理のロジック本体 ↓ 必要なときだけ読む skill/references/ ────────── ナレッジ（観点リスト・チェックリスト・使い方手順） たとえば security-review なら、「見るべきセキュリティ観点」のチェックリストを references/ に置いておく。agent はそれを必要なときだけ読みにいきます。観点を足したいときは references を 1 ファイル直すだけです。SKILL.md にも agent 本体にもベタ書きしないから、常時のコンテキストは増えないし、ナレッジの管理も一箇所で済むんですよね。 ちなみに、 処理を全部 agent に渡す必要はありません 。「ここはメインの会話の流れのまま、途中を見ながら進めたい」という処理もありますよね。そういうときは agent に移譲せず、手順を references/ に書いておいてルーター自身（メインコンテキスト）に実行させる。こうすれば、今までメインでやっていた作業を、使用感を変えないままルーターに取り込めます。agent に切り出すか、references の手順としてメインで回すかを処理ごとに選べる、ということですね。 この「使うときだけ読み込まれる」挙動は、公式でいう Progressive Disclosure です。仕組みの詳細は公式に譲りますが、 references をいくら厚くしても、常時のコンテキストは太らない 。だから観点もチェックリストも手順も、遠慮なく references 側に積んでおけるんですね。 で、束ねたら何が変わったか 狙ったスキルがちゃんと発火する。これが当たり前にできるようになりました。スキル発火後にワンアクションが必要になりましたが、面白いのはその先です。 ルーターのほうから提案してくるようになった んですよね。文脈を読んで「これ、レビューしときましょうか？」と向こうから振ってくる。意図どおりならそのまま「お願い」で済むし、こっちが思いついてなかった使い道まで「こういうのにも使えますよ」と教えてくれる。おかげでレビューを頼むときの解像度がぐっと上がりました。雑に「レビューして」と投げても、文脈に合ったやつが返ってくるんです。 あと、これは完全に狙ってなかった副産物なんですが、 メンテも楽になりました 。 束ねる前は、スキルを名前のプレフィックスで分類していました。 review-xxx 、 blog-xxx 、みたいに。でもこれ、いざ「この観点を直して、その知見をあっちにも反映したい」となったとき、関連ファイルがパスのあちこちに散っていて「どれとどれを見ればいいんだっけ」になるんですよね。ルーターにしてからは「レビュー関連はこの 1 か所」と文脈でまとまっているので、直したいものも、関連する作業も、一発で辿れる。情報の在処がはっきりしました。 ルーターにすべきか、独立スキルのまま置くか — 判断軸 集約すべきかどうかは 1 問で判断できます。 発火する文脈と修飾語が共通か？ YES なら集約候補です。 目的が近い（レビュー系・調査系・変換系） 同じファイル文脈で発火する（「ブログ記事を編集中」など） 修飾語で選べる（「ぶった切って」「論理だけ」のように呼び分けられる） NO なら独立スキルのまま置いていいです。 発火する文脈がまったく違う 単独で完結して他と競合しない 過剰集約の罠にも触れておきます。何でも 1 つに詰めると description が「全部入り」で逆に曖昧化して、発火精度が落ちるんですよね。ルーターは「文脈」で束ねるのが基本で、無関係な機能を 1 個に混ぜるのは逆効果です。 判断早見表をまとめると： 条件 判断 発火文脈が同じ（例：ブログ編集中） ルーターに集約 修飾語で呼び分けられる ルーターに集約 目的が近い（レビュー系、調査系…） ルーターに集約 発火文脈がバラバラ 独立スキルのまま 単独で完結、競合しない 独立スキルのまま description が「全部入り」で曖昧になる 過剰集約。文脈で分割 「スキルを消す前に、束ねられないか」まずは /skills で一覧を出して、「これ全部、同じ文脈で呼んでるな」という似たグループを探してみてください。見つかったら、そこがルーターの出番です。 ほなまた〜 関連記事 Claude Code への指示を少しでもさぼりたい！AskUserQuestion ツール — ルーターの原型となった review-article スキル Claude Codeのドキュメント検索を極力さぼれるようにした話 — サブエージェントに検索を委譲し、use_when で呼び出す設計 GitHub Actions 失敗ログ、まだ手動で読む？Copilot Agent Skills で CI デバッグ を自動化する実装ガイド — references/ 参照で 1 SKILL.md に集約した例 Claude Code:「Skill listing will be truncated」の正体と直し方 — スキルを消さず description を「外す／縮める」で character budget を解消する対症療法（ disable-model-invocation ・薄い description） CLAUDE.md 効かない？ドメイン注入を設計思想から見直す Claude Code: 公式 MCP を補完する Skills 設計パターン ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post Claude Code スキルの誤発火を防ぐ「ルーター集約」設計 first appeared on SIOS Tech Lab .

はじめに こんにちは。人材プラットフォーム ジョブメドレーアカデミー開発グループの池田です。ジョブメドレーアカデミーは、介護や障がい福祉、在宅医療などの各業種に特化した「オンライン動画研修サービス」と「勤怠・シフト管理サービス」をWeb・アプリの両方で提供しています。開発グループでは、これら両サービスの開発・運用を担当しています。 これまで、オンライン動画研修サービスのWebフロントエンドは Next.js で構築されていましたが、長期的な運用を見据えて Vite + TanStack Router への移行を行いました。本記事では、移行に至った理由と移行作業を紹介します。 移行理由について Next.jsからViteへの移行を決定した背景は、以下の3つの理由が同時期に重なったことです。 依存関係による開発の制約 当初、デザインシステムの構築を見据え、Tailwind CSSやPanda CSSといったモダンなCSSライブラリの導入を検討していました。 しかし、当時使用していたNext.js v12が内部で保持するPostCSSのバージョンが古いために設定が競合し、導入には複雑な設定が必要であることが判明しました。また、v12自体がすでにサポート終了（EOL）を迎えており、セキュリティやメンテナンスの面でも使い続けるリスクが高まっていたため、バージョンアップまたは別構成への移行が必要な状況にありました。 デプロイツール「serverless-nextjs」のアーカイブ インフラ構築には serverless-nextjs を使用していました。しかし、同ライブラリは現在アーカイブ（開発停止）されています。将来的なバグ修正などが困難になるため、配信基盤構築の手段を別の選択肢へ置き換える必要が生じていました。 プロダクト特性に合わせた技術スタックの見直し Next.js採用時と現在ではフロントエンドのエコシステムが異なり、現在は多様な選択が可能になったと思います。そこで、改めてプロダクト特性などを踏まえて検討した結果、以下の観点からよりシンプルな構成が最適であると判断しました。 to Bサービスであり、ユーザー体験を優先する性質上、SEO観点での数値最適化(Core Web Vitals等)の必要性が比較的低い バックエンドにGraphQLを採用しており、SSRを活用しようとするとキャッシュ管理等の設計が必要であり、実装コストがかかる 検索やページネーション等のユーザー操作に伴う動的データが画面の大半を占めており、RSCを使用する恩恵を十分に享受できない 以上の理由から、Next.js の使用を継続するよりも、今のサービス特性に合わせた構成にするのが適していると考え、バージョンアップではなく Vite + TanStack Router へのリプレイスを決断しました。 移行作業について ここからは、具体的な移行作業について紹介します。多岐にわたる作業の中から、本記事では特に大きな変更点である「ルーティング」と「インフラ」の2点を取り上げます。 TanStack Routerへの移行 next/router と next/link を使用していたルーティングは、 TanStack Router へ移行しました。採用理由は、次の3点です。 パスやクエリパラメータを型安全に扱い、それに関する実装ミスをコンパイル時に検知したいため 勤怠・シフト管理サービスと技術スタックを揃え、グループ内での知見共有をスムーズにしたいため Next.js使用時と同じようにファイルベースルーティングを維持し、移行に伴う認知負荷を最小限に抑えるため 結果、クエリパラメータが型で管理されるようになったことで、これまで手動テストやE2Eテストでしか気付けなかったような不具合を、コードを書いている段階で（型エラーとして）検知できるようになりました。 加えて、どの画面でどのパラメータが使われているかが型から追いやすくなり、長期的な保守性の向上にもつながっています。 CloudFront Continuous Deployment の活用 Viteアプリケーションを配信するために、serverless-nextjs で構築されたCloudFront + S3 + Lambda@Edgeの構成から、CloudFront + S3の構成に移行することを行いました。 インフラ構成を簡素化できる一方で、大規模な刷新となるため、リリースにあたっては以下の要件を重視しました。 万が一の際に、即座に旧構成（Next.js）へロールバックできること ダウンタイムをゼロにすること(本番環境での正常動作を保証すること) まず、これまで serverless-nextjs が構築していたリソース（CloudFront・Lambda@Edge）をTerraformで再定義しました。ライブラリ任せだったインフラ構成が可視化されたことに加え、旧構成に切り戻せる体制も整えることができました。 一方、ダウンタイムなしの切り替えを実現するために、CloudFront Continuous Deployment を活用しました。 出典 : CloudFront の継続的デプロイを使用して CDN 設定の変更を安全にテストする - Amazon CloudFront （Amazon Web Services, Inc.） 具体的には、既存の Next.js 配信用の設定をPrimary distribution(画像参照)におき、新しく構築したViteアプリケーション配信用の設定をStaging distributionとして用意しました。 CloudFront Continuous Deploymentでは、リクエストヘッダーまたはトラフィックレートに基づいてリクエストを振り分けることができます。今回は特定のヘッダーを付与した場合のみ Staging distribution へリクエストが流れるよう設定し、本番ドメインかつ本番環境と同じ条件下でViteアプリケーションの検証を行いました。 検証の結果、問題がないことを確認した上で、Staging distributionの設定を Primary distributionへ上書き(昇格)させました。このプロセスにより、ダウンタイムを発生させることなく、安全に新環境への切り替えを完了できました。 おわりに 今回は、ジョブメドレーアカデミーが提供するオンライン動画研修サービスのWebフロントエンドを Next.js から Vite + TanStack Router へ移行した取り組みを紹介しました。移行理由として挙げていた、プロダクト特性に合った技術スタックの見直しの達成に加え、他2点の課題も以下のように解決されました。 課題 移行後 依存関係による制約 Vite への移行により、PostCSS起因の競合が消え、Panda CSS などのライブラリが容易に導入可能になった。 デプロイツールの アーカイブ Terraform による IaC 管理に移行し、ライブラリに依存していたインフラ構成が可視化され、メンテナンスが容易になった。 また、上記の内容に加え、ビルド速度や画面遷移速度の向上といった改善も見られました。 プロダクトを長期的に提供できるよう、今後も機能開発と並行して技術基盤の見直しや改善に継続的に取り組んでいきます。 We’re hiring! メドレーでは、プロダクトエンジニアをはじめ「医療ヘルスケアの未来」を共に創っていくエンジニアを大募集中です！少しでもご興味をお持ちいただけましたらぜひ、ご応募お待ちしております！ 株式会社メドレー エンジニア の求人一覧 株式会社メドレー エンジニア の求人一覧です。| HRMOS hrmos.co ※カジュアル面談も大歓迎です！ご希望の際は、「その他の項目（希望記入欄）」にてその旨をご記載ください。

はじめに こんにちは、ZOZOTOWN企画開発部 企画フロントエンド2ブロックのパクサンイです。普段はZOZOTOWNにあるCMSベースのLPページのメンテナンスや機能追加、企画LPページ環境のメンテナンスを担当しています。 ZOZOTOWNの複数のWebアプリケーション間で、プロモーション用ランディングページコンポーネントを共有するために、 Lit ベースのWeb Componentsを導入しました。本記事ではその事例を紹介します。 ZOZOTOWNでは多数のLPページが開設・更新されており、従来はiframeを使った埋め込み方式でUIを共有していました。しかし、この方式にはさまざまな課題が存在し、レガシー環境からNext.jsベースの新環境へのリプレイスを進める中で、フレームワークに依存しないUI共有アーキテクチャが必要となりました。 本記事では、iframeベースの共有方式が抱える具体的な課題と、LitベースのWeb Componentsを採用した理由と選定プロセスを解説します。さらに、フレームワーク非依存なコンポーネント共有基盤を設計・実装する中で得た経験を共有します。 対象読者 マルチWebアプリケーション環境でUI共有に課題を感じているフロントエンドエンジニア iframeを使ったUI共有方式の代替手段を探している方 Web Componentsの導入を検討している方 目次 はじめに 対象読者 目次 背景・課題 ZOZOTOWNフロントエンドのマルチWebアプリケーション構成 LPコンポーネントの共有仕様 従来のiframeベース共有方式とその課題 1. レイアウト制御の煩雑さ 2. UI制御の複雑化 3. SEOの制約 アプローチ：Web Componentsの導入 要件整理 技術選定：Lit基盤Web Components Litを選択した理由 npmパッケージ方式を除外した理由 設計・実装 全体アーキテクチャ 1. 利用側アプリケーションによるデータ取得・加工 2. Lit ContextによるProps Drilling防止 3. Scriptローディングによる独立したUI更新 4. Shadow DOMからLight DOMへの切り替え ビルド・配信 全体フロー LPコンポーネント開発側（コンテンツ共有専用リポジトリ） 利用側Webアプリケーション 効果 学んだこと 今後の課題 今後の展望 まとめ 最後に 参考資料 背景・課題 ZOZOTOWNフロントエンドのマルチWebアプリケーション構成 現在、ZOZOTOWNのフロントエンドは3つのマルチWebアプリケーションで運用されています。 リポジトリ 説明 主な役割 リポジトリA（レガシー環境） 統合リポジトリ 既存の全ページを管理 リポジトリB（リプレイス環境） コアメインページ ホーム、カート、検索結果、商品詳細ページなど リポジトリC（リプレイス環境） 企画ページ フルスクラッチLP、CMS活用LP レガシー環境では複数のサービスが単一リポジトリで管理されていたため、共通UI共有に関する課題はありませんでした。しかし、リプレイス後にマルチWebアプリケーションが増えたことで、従来の方式ではUIを再利用できなくなりました。 LPコンポーネントの共有仕様 ZOZOTOWNでは特定のLPコンポーネントを複数のページで表示しています。一部のページでは以下の2つの形態で表示されます。 単独ランディングページ — header/footerを含むフルページ モーダル表示 — 特定ページのバナークリック時に、header/footerなしでコンテンツセクションのみをモーダルで表示 つまり、ほぼ同一のUIでありながら、header/footerの有無、SEOメタタグ、計測用トラッキングスクリプトの有無などで差異がある仕様でした。 従来のiframeベース共有方式とその課題 リプレイス後は以下の方式でUIを共有していました。 環境 運用方式 リポジトリA（レガシー） LPページ配信 + iframe用LPページ（header/footerなし）配信 リポジトリB・C（リプレイス） 特定ページにバナー表示 → クリック時にモーダル内でiframeとしてリポジトリAのLPを埋め込み このiframe方式には以下の課題が存在していました。 1. レイアウト制御の煩雑さ iframeは独立したドキュメントを読み込むため、フレームサイズの調整や使用箇所ごとの非表示領域の処理は対応していたものの、煩雑な部分がありました。 2. UI制御の複雑化 各バリエーションに応じて非表示にすべき子コンポーネントもあり、クエリパラメータや postMessage で解決できるものの、ケースが増えるほど複雑化しました。 3. SEOの制約 検索エンジンはiframe内のコンテンツを src 側の所有として認識するため、SEO上の制約がありました。 アプローチ：Web Componentsの導入 要件整理 上記の課題を解決するために、以下の4つの要件を整理しました。 要件 説明 各アプリのデプロイなしにUI更新 iframe方式の利点であった各マルチWebアプリケーションのデプロイなしにUI変更が反映されることを維持 iframe脱却 各アプリケーションでネイティブにUIをレンダリング フレームワーク非依存 React、Vueなど、どのフレームワークでも使用可能であること 軽量バンドルサイズ 利用側に負担のない最小限のサイズを維持 技術選定：Lit基盤Web Components Web Componentsはブラウザのネイティブコンポーネントモデルであり、特定のフレームワーク（React、Vueなど）に依存せず、ブラウザが直接理解する標準技術です。主に以下の3つの中核技術で構成されています。 Custom Elements ：開発者が独自のHTMLタグを定義できる。タグ名にはハイフン（ - ）を含む規約がある。 Shadow DOM ：コンポーネントのスタイルとマークアップを外部ページから隔離（Encapsulation）する。 HTML Templates ： <template> と <slot> 要素により、再利用可能なマークアップ構造を定義する。 このWeb Componentsをより効率的に開発するため、 Lit ライブラリを採用しました。 Litを選択した理由 選定基準 Litの特徴 バンドルサイズ 約5KB（minified + compressed）で非常に軽量 リアクティブプロパティ Reactive Propertiesにより状態変更時に自動再レンダリング テンプレート Tagged Template Literalsベースで別途コンパイル不要 パフォーマンス Virtual DOM diffingなしに動的部分のみを直接更新 相互運用性 すべてのLitコンポーネントはネイティブWeb Componentであり、HTMLを使うあらゆる場所で動作 npmパッケージ方式を除外した理由 LPページはテキスト更新の頻度が高く、UIも不定期に変更されます。npmパッケージで運用すると、変更のたびに各環境でパッケージ更新＋デプロイが必要となり、運用負荷が大きいため除外しました。 設計・実装 全体アーキテクチャ コンテンツ共有専用リポジトリを新たに構築し、以下の設計原則を適用しました。 1. 利用側アプリケーションによるデータ取得・加工 ZOZOTOWNにはページアクセス時に初期設定すべき値やAPIフェッチのためのロジックが各アプリケーションに存在します。これらのロジックをコンテンツ共有専用リポジトリにも含めると管理が二重になりメンテナンス負荷も大きくなるため、このリポジトリでは UIレンダリングのみ を責任範囲としました。 利用側の親アプリケーションでデータを取得・加工してpropsで渡す形式を採用しています。 2. Lit ContextによるProps Drilling防止 UI内部で必須的に共有すべき情報（デバイス種別、性別など）は、 Lit Context を活用したカスタム要素を設けて処理しました。 Lit ContextはReactのContext APIと同様の概念で、Props Drillingなしに上位から下位コンポーネントへデータを渡すことができます。 3. Scriptローディングによる独立したUI更新 各Webアプリケーションで別途デプロイなしにUI変更が可能なよう、 Scriptローディング を採用しました。各アプリケーションでは <script> タグで必要なコンポーネントのJSファイルを読み込み、クライアントでWeb Componentがレンダリングされます。 4. Shadow DOMからLight DOMへの切り替え Web Componentsの代表的な特徴であるShadow DOMは、スタイルを完全に隔離し、コンポーネント内部のCSSが外部に影響せず、外部CSSも内部に影響しません。 しかし、今回のケースでは、Shadow DOMで隔離して管理するUIではなく、利用側から自由にスタイルだけでなく要素にもアクセスできることが重要でした。そのため、Shadow DOMの代わりに Light DOM を採用しました。 ビルド・配信 Viteを使用してLit基盤Web Componentをビルドし、S3にデプロイしてCDN経由で配信します。 全体フロー LPコンポーネント開発側（コンテンツ共有専用リポジトリ） Lit + Vite dev serverでローカル開発 各テスト環境にてHTML + JSで動作確認 問題なければ各環境（S3）にデプロイして確認 利用側Webアプリケーション SSR時にCMS APIでデータ取得（スケジュールに応じて変更されるテキストなどはCMSで管理） クライアントで <script> タグによるJSファイルローディング、Web Componentのレンダリング カスタムタグへCMS API仕様に合わせたデータをpropsで渡す 効果 この仕組みの導入により、以下の効果が得られました。 マルチWebアプリケーション間でiframeを使わずにUIコンポーネントを共有できるようになった 各アプリケーション側のリリース（デプロイ）なしでコンテンツ更新が可能になった 利用側からスタイルだけでなく要素へのアクセスも自由に可能になった（Light DOM採用） CMS連携により、エンジニア以外でも直接スケジュールベースのデータ管理が可能に 学んだこと Litを通じて開発する中で、Web Componentsのベースとなるウェブ標準技術をより深く理解し、関心を持つようになりました。また、CSS変数などを活用してJavaScriptなしにCSSだけでスタイルを制御する方法も知ることができました。 今後の課題 Web Components公式のSSR対応はまだ限定的ですが、Lit SSRなど複数の解決策がライブラリやコミュニティで共有されています。現在、このプロジェクトで管理しているLPページの仕様ではWeb ComponentのSSRは不要ですが、将来に備えた準備は必要だと考えています。 また、現在の運用方式では、Scriptローディング＋CMSデータ連携という構造上、テストが非常に重要であり補強が必要です。 今後の展望 移行すべきLPページが多数残っており、段階的にマイグレーションを進めていく予定です。より小さな単位の共用コンポーネントもこの基盤で管理できるよう拡張を検討しています。また、可能であれば、ネイティブアプリケーションでの活用も検討したいと考えています。 まとめ 本記事では、ZOZOTOWNのマルチWebアプリケーション環境におけるiframeベースUI共有方式の課題を解説しました。また、LitベースのWeb Componentsを活用したフレームワーク非依存のコンテンツ共有基盤の構築事例を紹介しました。 ReactベースであればReactでもUIを共有する方法はあります。しかし、今後どのフレームワークでも問題なく移植できるWeb Componentsを選択し、メインスタックと共存しながら運用するのもよいのではないでしょうか。同様の課題をお持ちの方の参考になれば幸いです。 最後に ZOZOでは、一緒にサービスを作り上げてくれる方を募集中です。ご興味のある方は、以下のリンクからぜひご応募ください。 corp.zozo.com 参考資料 MDN - Web Components Lit 公式ドキュメント Lit Context MDN - Using Shadow DOM MDN - iframe Vite - Building for Production