はじめに こんにちは。人材プラットフォーム ジョブメドレーアカデミー開発グループの池田です。ジョブメドレーアカデミーは、介護や障がい福祉、在宅医療などの各業種に特化した「オンライン動画研修サービス」と「勤怠・シフト管理サービス」を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

こんにちは、イノベーションセンターのNetwork Analytics for Security（NA4Sec）プロジェクトの山門です。 この記事では、2025年12月18日-19日に開催されたカンファレンスNCA Annual Conference 2025へ登壇してきた模様を紹介します。 組織におけるドメイン名の「終活（廃棄）」に伴うリスクをテーマに、利用終了ドメイン名に対する2.3億件のログ分析結果を説明しました。ECS（EDNS-Client-Subnet）を用いた分析により、「利用終了後も攻撃・スキャンが絶えない」という実態や、観測行為自体が攻撃を誘発する「観察者効果」といった興味深い知見を解説します。 NCA Annual Conferenceとは NA4Secプロジェクトとは 講演内容 ドメイン名の「終活」という課題 ECSの活用 観測・分析環境 分析結果 結論 おわりに NCA Annual Conferenceとは NCA Annual Conferenceは、一般社団法人 日本シーサート協議会が主催する年次カンファレンスです。 本イベントは、企業や組織内でセキュリティインシデントに対応するCSIRT（Computer Security Incident Response Team）のメンバーが一堂に会する、国内でも大規模なコミュニティイベントの1つです。最新のサイバー攻撃動向や技術情報の共有にとどまらず、組織の枠を超えたCSIRT間の連携や、各組織が抱える課題解決のヒントを得ることを目的として開催されています。 特に、現場の実務者による知見の共有やワークショップを通じた「共創」の精神が重視されており、日本のサイバーセキュリティ対応能力の底上げを図る重要な場として位置づけられています。 NA4Secプロジェクトとは 私の所属するNA4Secプロジェクトについて紹介させてください。 NA4Secプロジェクトは、「NTTはインターネットを安心・安全にする社会的責務がある」を理念として、インターネットにおける攻撃インフラの解明・撲滅を目指すプロジェクトです。 NTTドコモビジネスグループにおける脅威インテリジェンスチームとしての側面も持ち合わせており、有事において脅威インテリジェンスを提供し、意思決定を支援することもあります。 イノベーションセンターを中心として、NTTセキュリティ・ジャパンやエヌ・エフ・ラボラトリーズからもメンバーが参画し、日夜攻撃インフラ(攻撃者の管理するマルウェアや C&Cサーバ など)を追跡しています。 講演内容 NA4Secプロジェクトの神田と、私（山門）の2名で、「『君の名は』と聞く君の名は。」というタイトルで、安易なドメイン名放棄に潜むリスク、観測から得られた知見、そして新しい管理アプローチについて講演しました。 登壇資料はこちらにアップロードしておきましたので、よろしければご覧ください。 ドメイン名の「終活」という課題 企業がかつて利用していたドメイン名を悪意を持つ第三者が取得した場合、フィッシングサイトに悪用されたり、ブランドイメージを失墜させたり、Search Engine Optimization（SEO）を悪用したりできるため、攻撃者にとって価値があります。そのためドメイン名の放棄後に第三者によって悪用される「ドロップキャッチ」のリスクが存在します。実際に「ドコモ口座」など複数事例でも問題が顕在化しています。 その対策として、当社ではドメイン名の永年保有ポリシーを策定していますが、「いつまでも持ち続ける」以外の選択肢を探るべく、利用終了ドメイン名に対する「アクセス実態」の観測と分析しています。 ECSの活用 今回発表した中では、「EDNS-Client-Subnet（ECS）」の挙動を調査しました。ECSとはRFC 7871で定義されており、DNS問い合わせにクライアントのIPサブネット情報を付加し、権威DNSサーバがユーザの地理的・ネットワーク的な位置をより正確に把握できるようにする仕組みです。DNSリゾルバの裏に存在する、実際に名前解決しようとしたクライアントのサブネットを意味します。 観測・分析環境 ログ収集環境を下図に示します。 利用終了したドメイン名宛のDNSクエリログ、Webアクセスログ、受信メール・DMARCレポートの3点をAWS上で収集およびJSON化し保管しています。今回はその中のDNSクエリログとWebアクセスログの2点に注目しています。 今回は、NA4Secプロジェクトの利用終了ドメイン名関連の施策の中で、初めてDNSクエリログとWebアクセスログを突合させることでアクセスの正体と目的の分析を試みました。DNSクエリログのECSをキーにWebアクセスログの送信元IPアドレスと突合し、DNSクエリログとWebアクセスログのタイムスタンプの差に着目しました。タイムスタンプの差が小さいと、当該ECSがWebアクセスのためにDNS名前問い合わせをした可能性が高いためです。 分析結果 以下のグラフは、各日付のDNSクエリのカウントをその日調査対象になっていたドメイン名の数で平均した値の遷移です。 以下の事柄が、分析により判明しました。 ログ分析から、利用終了後も大量のクエリが継続している 約2.3億件のDNSクエリログのうちGoogle / Cisco / Akamai など大規模DNSの resolver-ip からのクエリが9割以上を占める DNSで名前問い合わせ直後（24時間以内）に Webへアクセスしてきたものを調査した結果112リクエスト中、90件以上が攻撃またはスキャンである WordPress や Apache の既知脆弱性を狙ったアクセスが多数確認されました。Shellshock（CVE-2014-6271）、WebLogic RCE（CVE-2017-10271）、MobileIron RCE（CVE-2020-15505）、D-Link NAS のバックドア脆弱性（CVE-2024-3272）など、古い脆弱性も依然として集中的に狙われている 今回の分析から明らかになった問題の1つは、観測行為そのものがアクセスを誘発してしまうというジレンマです。 DNSレコードを返すことでサブドメイン探索が行われ、HTTP応答を返すことで脆弱性スキャンが始まるなど、観測行為が攻撃者を誘引し、その行動を変えてしまっている実情が見えてきました。 いわば「観察者効果」です。 その一方で、DNSクエリログ・Webアクセスログ単体だけではアクセスの目的や意図、アクセス元の素性を推し量ることは難しく、適切なアクションに結び付けることは困難です。 より正確に状況を把握し、利用終了ドメイン名に残存するリスクへ効果的に対応するためには、不要な「ノイズ」を除去して、本来残っているアクセスを見分けることが重要となります。 結論 これらの調査から得られた知見として下記のようにまとめられます。 DNSクエリログの一部の送信元のアクセス意図は攻撃やスキャンであることが、今回初めてDNSクエリログとWebアクセスログの2つを突合することで判明した 利用終了ドメイン名であっても攻撃・スキャンは日常的に行われる（今回の調査の対象は24年8月以前に利用終了したドメイン名） 2つのログ突合により、名前問い合わせをしてきた送信元のアクセス意図の理解が高まる（今回の調査では大半がスキャンや攻撃） おわりに 月日が経ってもアクセス数は減らず、「減少＝ドメイン名を安全に手放せる」の単純な判断材料にはならないことがわかりました。 また、現用ドメイン名にも同様の脅威が常に存在するため、サイバーハイジーン（基本的なサイバーセキュリティ対策を平時より実施すること）の徹底が不可欠だと言えます。 講演後の反応として、「同じくドメイン名の終活に悩みを抱えているが、運用・廃止ポリシーはまだ策定していない。今回の講演は、月日が経ってもアクセス数が減らない点や、曖昧な運用が悪意ある第三者によるドロップキャッチの原因になる点など、改めて組織内での運用ポリシーを策定するためのきっかけになった」というご意見もいただきました。 本カンファレンスを通じて、最新の技術動向や脅威情報を習得できたことはもちろんですが、同じ課題を持つ他社CSIRTとの「共創」のネットワークを再確認できたことが最大の収穫でした。一度取得したドメイン名の管理という地味ながらも避けては通れない課題が、いかに多くの実務者の皆さまの共通の悩みとなっているかを痛感しました。 「いつ、どうやってドメインを手放すべきか」という問いに対する最適解はまだありません。しかし、今回ご紹介したログ分析の手法や観測結果が、皆さまの組織における運用ポリシー策定の一助となれば幸いです。 NA4Secプロジェクトでは、今後もこうした観測と分析を継続し、インターネットをより安心・安全なものにするための知見を発信してまいります。 記事を最後までお読みいただきありがとうございました。