フロントエンド開発では、JavaScriptやTypeScript、CSS、画像など多くのファイルを扱います。

プロジェクト規模が大きくなると、開発サーバーの起動時間やビルド時間が長くなり、修正内容が画面へ反映されるまで待つ時間も増えていきます。

こうした開発体験を改善するために広く利用されているのが、Viteです。

Viteは高速な開発サーバーと効率的なビルド機能を提供するフロントエンド開発ツールです。

本記事では、Viteの基本的な仕組みと、導入するメリットについて紹介します。

Viteとは

Viteは、モダンなWeb開発向けに設計されたビルドツールです。

React、Vue、Svelte、TypeScriptなどと組み合わせて利用でき、開発中の高速な起動や更新反映が特徴です。

従来のビルドツールでは、開発サーバーを起動する前に多くのファイルをまとめてバンドルする必要がありました。

一方、ViteはブラウザのES Modulesを活用し、必要なファイルを必要なタイミングで読み込むことで、開発開始までの待ち時間を短縮します。

開発サーバーの起動が速い理由

従来型のバンドラーでは、プロジェクト全体を解析してから開発サーバーを起動する場合があります。

ファイル数が増えるほど、この処理に時間がかかります。

Viteでは、最初からすべてのアプリケーションコードをまとめるのではなく、ブラウザから要求されたモジュールをオンデマンドで提供します。

そのため、大規模なプロジェクトでも開発サーバーを比較的短時間で起動できます。

ES Modulesを活用する

モダンブラウザでは、JavaScriptのES Modulesを標準で利用できます。

Viteはこの仕組みを活用しています。

例えば、あるページで特定のコンポーネントだけが必要な場合、そのモジュールを必要なタイミングで読み込みます。

これにより、開発中に毎回すべてのJavaScriptをまとめ直す必要がなくなります。

HMRとは

Viteの大きな特徴の一つが、HMR（Hot Module Replacement）です。

HMRは、コードを変更したときにページ全体を再読み込みせず、変更されたモジュールだけを更新する仕組みです。

例えば、ボタンのスタイルを変更した場合、ページ全体の状態を失わずに変更内容だけを反映できます。

フォーム入力やアプリケーション状態を維持したまま開発できるため、作業効率が向上します。

TypeScriptにも対応

ViteはTypeScriptファイルも扱えます。

そのため、

• React + TypeScript

• Vue + TypeScript

• Vanilla TypeScript

などの構成を簡単に始めることができます。

ただし、Vite自体の変換処理とTypeScriptの型チェックは別の役割を持っています。

本格的なプロジェクトでは、ビルドとは別に型チェックをCIなどで実行する構成も検討できます。

CSSも扱いやすい

Viteでは通常のCSSだけでなく、CSS Modulesなども利用できます。

フレームワークや設定によっては、Sassなどのプリプロセッサと組み合わせることも可能です。

開発中はCSS変更も素早く反映されるため、UI調整を効率的に進められます。

静的ファイルの管理

画像やフォントなどの静的ファイルもViteから扱えます。

JavaScriptやCSSから画像を参照すると、ビルド時に適切なパスへ変換されます。

また、ファイル名へハッシュを付けることで、ブラウザキャッシュを効率的に利用できる構成も作りやすくなります。

本番ビルド

開発中は高速なES Modulesベースの仕組みを利用しますが、本番環境では最適化されたファイルを生成します。

本番ビルドでは、

• コードの最小化

• モジュールの統合

• 不要コードの削減

• ファイル名へのハッシュ付与

などが行われます。

これにより、ユーザーへ配信するファイルサイズを小さくしやすくなります。

Code Splittingとの相性

大規模なWebアプリケーションでは、すべてのJavaScriptを一つのファイルへまとめると初回読み込みが重くなる場合があります。

そこで重要になるのがCode Splittingです。

ViteではDynamic Importなどを利用することで、機能ごとにJavaScriptを分割できます。

例えば、

• トップページ

• 管理画面

• 分析画面

• 設定画面

などを別ファイルに分け、必要なページを開いたときだけ読み込む構成が可能です。

環境変数の管理

Web開発では、開発環境と本番環境でAPI URLなどを変更する場合があります。

Viteでは環境変数を利用して設定を切り替えることができます。

例えば、

• 開発用API

• ステージングAPI

• 本番API

などを環境ごとに管理できます。

ただし、フロントエンドへ埋め込まれる環境変数はユーザーから確認できる可能性があります。

そのため、

• API Secret

• 秘密鍵

• パスワード

などの機密情報をフロントエンドの環境変数へ保存してはいけません。

Pluginを利用できる

ViteにはPluginの仕組みがあります。

プロジェクトの要件に応じて、

• フレームワーク対応

• SVG処理

• PWA

• 圧縮

• バンドル分析

などの機能を追加できます。

ただし、Pluginを増やしすぎると設定が複雑になることもあるため、本当に必要なものだけを利用することが重要です。

バンドルサイズを確認する

Viteを利用していても、アプリケーションへ多くのライブラリを追加するとJavaScriptサイズは大きくなります。

そのため、

• 依存関係

• 出力ファイルサイズ

• Code Splitting

• 未使用コード

を定期的に確認することが大切です。

新しいライブラリを追加する前に、ブラウザ標準機能や軽量な代替手段で実現できないかを検討すると、長期的なパフォーマンス維持につながります。

開発速度とユーザー向け速度は別に考える

Viteの大きなメリットは、開発者が快適に作業できることです。

ただし、開発サーバーが速いからといって、本番サイトが自動的に高速になるわけではありません。

本番では、

• 画像最適化

• CDN

• キャッシュ

• JavaScript削減

• API応答速度

• Core Web Vitals

なども確認する必要があります。

開発体験とユーザー体験の両方を最適化することが重要です。

WINMYRのようなサービスで活用する場合

WINMYRのように複数の画面やフロントエンド機能を持つデジタルプラットフォームでは、機能追加が続くにつれてプロジェクト内のJavaScriptやCSSも増えやすくなります。

Viteの高速な開発サーバーやHMRを活用すれば、UIの変更やコンポーネント修正を素早く確認でき、開発サイクルを短縮しやすくなります。

また、ページ単位でCode Splittingを行い、必要な機能だけを読み込む構成にすることで、開発効率だけでなく本番環境の初回表示パフォーマンスにも配慮できます。

重要なのは、ビルドツールを導入して終わりにするのではなく、出力されるファイルサイズや依存関係を継続的に確認することです。

まとめ

Viteは、高速な開発サーバーとモダンなフロントエンド開発環境を提供する便利なツールです。

特に、

• 高速な起動

• HMR

• ES Modules

• TypeScript対応

• Code Splitting

• 本番ビルド

などの機能によって、日常的な開発作業を効率化できます。

一方で、本番環境のパフォーマンスはViteだけで決まるものではありません。

画像、JavaScript、キャッシュ、ネットワークなどを含めて継続的に最適化することで、開発者にとってもユーザーにとっても快適なWebサービスを構築できます。

Webアプリケーションでは、ユーザー情報や設定データ、各種コンテンツを保存するためにデータベースが広く利用されています。

その一方で、入力値の扱いを誤ると、SQL Injectionと呼ばれる攻撃につながる可能性があります。

SQL Injectionは古くから知られている攻撃手法ですが、現在でも不適切な実装によって発生することがあります。

本記事では、SQL Injectionの基本的な仕組みと、安全なWebアプリケーションを構築するための対策について解説します。

SQL Injectionとは

SQL Injectionとは、ユーザー入力を利用して不正なSQL文を実行させる攻撃です。

例えば、検索フォームやログインフォームの入力値をそのままSQL文へ組み込むと、攻撃者が意図しないSQL構文を入力することで、データベースの動作を変更できる可能性があります。

その結果、

• 本来閲覧できないデータの取得

• データの改ざん

• データの削除

• 認証処理の回避

などの問題が発生する可能性があります。

なぜ発生するのか

SQL Injectionが発生する大きな原因は、ユーザー入力とSQL構文を同じ文字列として扱ってしまうことです。

例えば、アプリケーション側で文字列を連結してSQL文を作成すると、入力内容がSQLの一部として解釈される可能性があります。

重要なのは、ユーザー入力を「SQLコード」ではなく「単なるデータ」として扱うことです。

1. Prepared Statementを利用する

SQL Injection対策で最も重要なのが、Prepared Statementです。

Prepared Statementでは、SQL文の構造とユーザー入力を分離して処理します。

例えば、

「ユーザーIDが指定されたレコードを検索する」

というSQL構造を先に決め、入力値は後からパラメータとして渡します。

これにより、入力値にSQL構文のような文字列が含まれていても、単なるデータとして扱われます。

多くのプログラミング言語やデータベースライブラリがPrepared Statementをサポートしています。

2. ORMを正しく利用する

近年のWeb開発では、ORM（Object-Relational Mapping）を利用するケースも増えています。

ORMを利用すると、SQLを直接書かずにデータベース操作を行えるため、Prepared Statementが内部的に使用される場合があります。

ただし、ORMを使っているから自動的に安全というわけではありません。

Raw Query機能を利用したり、文字列を直接連結したりすると、SQL Injectionのリスクが再び発生する可能性があります。

ORMでも入力値の扱いを確認することが重要です。

3. 入力値を検証する

Prepared Statementを利用していても、入力値検証は必要です。

例えば、ユーザーIDとして数字だけを受け付ける場合は、数字以外の値を拒否できます。

検証できる項目には、

• データ型

• 最大文字数

• 必須項目

• 許可する文字

• 数値の範囲

などがあります。

入力値検証はSQL Injectionだけでなく、アプリケーション全体のデータ品質向上にも役立ちます。

4. データベース権限を最小限にする

Webアプリケーションからデータベースへ接続するアカウントには、必要以上の権限を与えないことが重要です。

例えば、通常のWebアプリケーションがテーブル作成やユーザー管理を行わないのであれば、それらの権限を持たせる必要はありません。

最小権限の原則を適用することで、万が一SQL Injectionが発生した場合でも被害範囲を抑えやすくなります。

5. 詳細なデータベースエラーを表示しない

開発中はSQLエラーを画面に表示すると便利ですが、本番環境では注意が必要です。

詳細なエラーメッセージには、

• テーブル名

• カラム名

• SQL文

• データベース種類

• 内部構造

などが含まれる場合があります。

こうした情報は攻撃者にシステム構造を推測するヒントを与える可能性があります。

ユーザーには一般的なエラーメッセージを表示し、詳細情報はサーバー側のログへ記録する方法が安全です。

6. 動的なORDER BYにも注意する

Prepared Statementを使っていても、すべてのSQL要素をパラメータ化できるわけではありません。

例えば、並び替えに使用するカラム名をユーザー入力から直接受け取る場合は注意が必要です。

このようなケースでは、

• name

• created_at

• price

など、許可する値をあらかじめ一覧で定義し、その中から選択させる方法が有効です。

ユーザー入力をSQL構造へ直接利用しないことが基本です。

7. LIKE検索でもパラメータ化する

検索機能ではLIKE句を使用することがあります。

この場合も文字列を直接連結せず、検索語をパラメータとして渡す方法を利用します。

また、検索文字列の長さを制限することで、不要に重いクエリが発生することも防ぎやすくなります。

8. ログイン処理では特に慎重にする

ログインフォームはSQL Injectionの標的になりやすい機能の一つです。

ユーザー名やメールアドレス、パスワードをそのままSQL文へ連結する設計は避ける必要があります。

また、パスワードはデータベースへ平文で保存せず、安全なパスワードハッシュを利用することも重要です。

認証処理では、

• Prepared Statement

• パスワードハッシュ

• レートリミット

• 多要素認証

などを組み合わせることで、安全性を高められます。

9. Web Application Firewallに依存しすぎない

WAF（Web Application Firewall）は、不審なリクエストを検知・ブロックするために利用できます。

SQL Injectionのパターンを検知する機能を持つWAFもあります。

ただし、WAFは補助的な防御策です。

アプリケーション自体に脆弱性がある状態をWAFだけで解決するのは適切ではありません。

まずコード側でPrepared Statementなどの基本対策を行い、その上でWAFを追加することが重要です。

10. コードレビューを行う

SQL Injectionは、コードレビューによって発見できるケースも多くあります。

特に次のようなコードは注意が必要です。

• SQL文字列の連結

• Raw Query

• ユーザー入力を使った動的SQL

• 手動で作成した検索条件

データベースアクセス部分を重点的にレビューするルールを作ると、脆弱性の早期発見につながります。

11. 自動テストを活用する

セキュリティテストを開発プロセスへ組み込むことも有効です。

例えば、

• SAST

• DAST

• 依存関係スキャン

• APIテスト

などをCI/CDへ組み込むことで、問題を早い段階で発見しやすくなります。

ただし、自動ツールですべての問題を発見できるわけではありません。

コードレビューや設計レビューと組み合わせることが重要です。

12. データベースログを監視する

不審なSQLクエリや異常なアクセスパターンを監視することで、問題の早期発見につながります。

例えば、

• 通常より大量の検索

• 短時間で大量のエラー

• 不自然なクエリパターン

• 管理データへの異常なアクセス

などを監視できます。

アプリケーションログとデータベースログを組み合わせると、原因を調査しやすくなります。

WINMYRのようなサービスで意識したいこと

WINMYRのように複数のコンテンツやユーザー向け機能を持つデジタルプラットフォームでは、検索、ログイン、プロフィール、設定変更など、さまざまな場所でデータベースアクセスが発生します。

そのため、特定の画面だけで対策するのではなく、データアクセス層全体でPrepared StatementやORMの安全な利用方法を統一することが重要です。

また、開発チーム内で「SQLを文字列連結しない」「Raw Queryを利用する場合はレビューを必須にする」といったルールを設けることで、長期運用時のリスクも減らせます。

まとめ

SQL Injectionは古くから知られている攻撃ですが、基本的な設計を守ることで多くのリスクを軽減できます。

特に重要なのは、

• Prepared Statementを利用する

• 入力値を検証する

• SQL文字列を直接連結しない

• データベース権限を最小限にする

• 詳細なエラー情報を公開しない

• ログとコードレビューを活用する

といった対策です。

セキュリティは一つの防御機能だけで実現するものではありません。

安全なコーディング、適切な権限管理、監視、テストを組み合わせることで、より信頼性の高いWebアプリケーションを構築できます。

Webサービスでは、ログイン状態の維持やユーザー設定の保存などにCookieが広く利用されています。

Cookieは便利な仕組みですが、設定を誤るとセッション情報の漏えいや不正リクエストにつながる可能性があります。

そのため、Cookieを利用する際には、Secure、HttpOnly、SameSiteなどの属性を正しく理解し、用途に応じて設定することが重要です。

本記事では、Webセキュリティの観点からCookieを安全に扱うための基本ポイントを紹介します。

Cookieとは

Cookieは、Webサーバーがブラウザへ保存させる小さなデータです。

一般的には、

• セッションID

• ログイン状態

• 言語設定

• 表示設定

• 一部のユーザー識別情報

などを保存するために利用されます。

ブラウザは条件に一致するリクエストを送信するとき、対応するCookieを自動的にサーバーへ送信します。

この仕組みによって、ユーザーがページを移動しても同じ状態を維持できます。

Cookieに重要情報を直接保存しない

Cookieはブラウザ側に保存されるため、機密情報をそのまま保存するのは避けるべきです。

例えば、

• パスワード

• 秘密鍵

• 個人情報

• クレジットカード情報

などを直接Cookieへ保存してはいけません。

ログイン状態を管理する場合は、ランダムで推測困難なセッションIDなどを保存し、実際のユーザー情報はサーバー側で管理する方式が一般的です。

Secure属性

Secure属性を設定すると、CookieはHTTPS通信時のみ送信されます。

HTTPSを利用していても、Secure属性が設定されていない場合、何らかの理由でHTTP通信が発生した際にCookieが送信される可能性があります。

セッションCookieなど重要なCookieには、基本的にSecure属性を付けることが推奨されます。

これにより、暗号化されていない通信経路へCookieが送信されるリスクを減らせます。

HttpOnly属性

HttpOnly属性を設定すると、JavaScriptからCookieへ直接アクセスできなくなります。

通常、JavaScriptではdocument.cookieを利用してCookieを読み取ることができます。

しかし、XSSが発生した場合、攻撃者のスクリプトがセッションCookieを取得する可能性があります。

HttpOnlyを設定しておけば、JavaScriptから重要なCookieを読み取れないため、被害を軽減できます。

ただし、HttpOnlyだけでXSSを防げるわけではありません。

入力値の検証やCSPなど、他の対策と組み合わせる必要があります。

SameSite属性

SameSiteは、他のサイトから送信されたリクエストにCookieを含めるかどうかを制御する属性です。

主にCSRF対策として利用されます。

代表的な値には、

• Strict

• Lax

• None

があります。

SameSite=Strict

Strictでは、基本的に同一サイトからのリクエストでのみCookieが送信されます。

安全性は高いですが、外部サイトのリンクからアクセスした場合にログイン状態が引き継がれないなど、ユーザー体験へ影響する可能性があります。

SameSite=Lax

Laxは、安全性と利便性のバランスを取りやすい設定です。

通常のリンク遷移ではCookieを送信できますが、一部のクロスサイトリクエストでは送信を制限します。

一般的なWebサービスでは利用しやすい設定です。

SameSite=None

Noneを指定すると、クロスサイトリクエストでもCookieを送信できます。

外部ドメインをまたぐ認証や埋め込みコンテンツなどで必要になる場合があります。

ただし、SameSite=Noneを利用する場合は、通常Secure属性も必要です。

クロスサイト送信を許可するため、用途を明確にして使用することが重要です。

Domain属性

Cookieでは、Domain属性を使って送信対象となるドメインを指定できます。

必要以上に広いドメインを指定すると、複数のサブドメインからCookieへアクセスできる可能性があります。

例えば、特定のホストだけで利用するCookieであれば、不要に親ドメイン全体へ共有しない方が安全です。

最小限の範囲で設定することが基本です。

Path属性

Path属性は、Cookieを送信するURLパスの範囲を指定します。

例えば、特定の管理画面だけで使用するCookieであれば、そのパスに限定できます。

ただし、Pathは強力なセキュリティ境界として設計されたものではないため、機密情報保護をPathだけに依存してはいけません。

有効期限を適切に設定する

Cookieには有効期限を設定できます。

ログイン状態を長期間維持すると便利ですが、セッション情報が長く残るほど、不正利用された場合の影響も大きくなります。

そのため、

• 一時的なセッション

• ログイン状態の維持

• 表示設定

など、Cookieの用途に応じて有効期限を変えることが重要です。

不要になったCookieは速やかに削除する設計も必要です。

セッション固定攻撃への対策

ログイン前後で同じセッションIDを使い続けると、セッション固定攻撃のリスクが高まる可能性があります。

ユーザーがログインに成功したタイミングで、新しいセッションIDを発行する方法が一般的です。

また、

• ログアウト時にセッションを無効化する

• 一定時間操作がない場合に期限切れにする

• 重要操作時に再認証を求める

といった対策も有効です。

CSRFとの関係

Cookieはブラウザが自動的に送信するため、この仕組みを利用したCSRF攻撃に注意が必要です。

SameSite属性は有効な防御策の一つですが、それだけで十分とは限りません。

重要な操作では、

• CSRFトークン

• Originチェック

• Refererチェック

• 再認証

などを組み合わせることがあります。

特にデータ変更を伴う操作では、複数の対策を検討することが重要です。

Cookie名にもセキュリティを追加できる

Cookieには、特定のプレフィックスを利用する方法があります。

例えば、

__Secure-

や

__Host-

といった名前を利用すると、ブラウザ側で追加の条件を要求できます。

__Host-では、Secure属性やPathなどに一定の制約があるため、重要なCookieの設定ミスを減らすのに役立ちます。

認証Cookieと設定Cookieを分ける

すべての情報を一つのCookieへまとめる必要はありません。

例えば、

• 認証用Cookie

• 言語設定

• テーマ設定

• UI設定

を分けて管理すると、それぞれに適したセキュリティ設定を適用できます。

認証Cookieには厳しい条件を設定し、表示設定には必要な範囲だけを設定することで、管理しやすくなります。

開発環境と本番環境の違いに注意する

開発中はlocalhostを利用するため、本番環境とCookieの挙動が異なる場合があります。

特に、

• HTTPS

• Secure

• SameSite

• Domain

などの設定は、本番環境で初めて問題が見つかることがあります。

そのため、ステージング環境などを利用して、本番に近い条件で認証フローを確認することが重要です。

WINMYRのようなサービスで意識したいこと

WINMYRのようにログイン機能や複数のWebコンテンツを扱うデジタルプラットフォームでは、Cookieの用途を明確に分けて管理することが重要です。

特にセッション情報を扱うCookieでは、Secure、HttpOnly、SameSiteなどを適切に組み合わせ、必要以上に広いDomainや長い有効期限を設定しないことが安全な運用につながります。

また、新しい機能や外部サービスを追加するときには、Cookieの送信範囲が意図せず広がっていないかを確認することも大切です。

ブラウザの開発者ツールを利用すれば、各Cookieの属性や送信条件を確認できます。

まとめ

Cookieは、ログイン状態やユーザー設定を管理するために便利な仕組みですが、セキュリティ設定を適切に行う必要があります。

特に重要なのは、

• SecureでHTTPS通信に限定する

• HttpOnlyでJavaScriptからの読み取りを制限する

• SameSiteでクロスサイト送信を管理する

• DomainとPathを必要最小限にする

• 有効期限を適切に設定する

• ログイン時にセッションIDを更新する

といったポイントです。

Cookie単体で安全性を確保するのではなく、HTTPS、CSP、CSRF対策、適切なセッション管理などと組み合わせることで、より安全で安定したWebサービスを構築できます。

Webサイトのセキュリティ対策では、サーバー側の防御だけでなく、ブラウザ上で実行されるコンテンツを適切に制御することも重要です。

そのために利用される仕組みの一つが、CSP（Content Security Policy）です。

CSPを設定すると、どのスクリプトや画像、スタイルを読み込んでよいかをブラウザへ明示できるため、XSSなどの攻撃リスクを軽減できます。

本記事では、CSPの基本的な仕組みと、導入時に押さえておきたいポイントを紹介します。

CSPとは

CSPは、Webページで読み込み可能なコンテンツの出所を制限するためのセキュリティ機能です。

通常、ブラウザはHTML内で指定されたJavaScriptやCSS、画像などを読み込みます。

しかし、攻撃者がページ内へ悪意のあるスクリプトを挿入した場合、そのコードまで実行される可能性があります。

CSPを設定すると、

• JavaScript

• CSS

• 画像

• フォント

• iframe

• API通信先

などについて、許可するドメインや条件を指定できます。

XSS対策としてのCSP

CSPが特に有効なのは、XSS（Cross-Site Scripting）への対策です。

XSSが発生すると、攻撃者がページ内でJavaScriptを実行し、

• Cookieの取得

• 画面内容の改ざん

• 不正なフォームの表示

• 外部サイトへのリダイレクト

などを行う可能性があります。

CSPを設定して外部スクリプトの読み込み元を限定しておけば、不正なスクリプトが実行される可能性を減らせます。

ただし、CSPだけでXSSを完全に防げるわけではありません。

入力値の検証や出力時のエスケープなど、基本的な対策と組み合わせて利用することが重要です。

CSPの基本的な設定方法

CSPはHTTPレスポンスヘッダーで指定する方法が一般的です。

例えば、

Content-Security-Policy: default-src 'self'

という設定では、基本的に同一オリジンからのリソースだけを許可します。

'self'は現在のWebサイトと同じオリジンを意味します。

非常にシンプルな設定ですが、実際のサービスでは画像CDNや外部フォント、分析サービスなどを利用するため、用途に応じてルールを追加します。

default-srcの役割

default-srcは、他のルールが指定されていない場合に利用される基本ポリシーです。

例えば、

default-src 'self'

を設定しておけば、特別に許可されていない外部リソースは原則として読み込まれません。

CSPを設計するときは、まず厳しめのdefault-srcを設定し、必要なリソースだけ個別に許可する考え方が分かりやすいです。

script-src

script-srcはJavaScriptの読み込み元を指定します。

例えば、

script-src 'self' https://example-cdn.com

と設定すると、自分のサイトと指定したCDNからのJavaScriptだけを許可できます。

セキュリティ上、'unsafe-inline'や'unsafe-eval'は可能な限り避けることが推奨されます。

これらを許可すると、CSPによるスクリプト制御の効果が弱くなる場合があります。

style-src

style-srcでは、CSSの読み込み元を制御できます。

外部スタイルシートを利用している場合は、そのドメインを明示的に許可します。

インラインCSSを大量に利用している既存サイトでは、CSPを厳しくすると表示が崩れる場合があります。

そのため、導入前に現在の実装を確認し、必要に応じてCSS構造を整理することが重要です。

img-src

img-srcは画像の読み込み元を指定します。

例えば、画像を専用CDNから配信している場合は、そのCDNを許可します。

サイトによっては、

• 自社ドメイン

• CDN

• Data URI

• 外部画像サービス

など、複数の読み込み元が存在します。

不要なドメインを広く許可しないことがポイントです。

connect-src

connect-srcは、JavaScriptから行われる通信先を制御するための設定です。

例えば、

• fetch

• XMLHttpRequest

• WebSocket

• EventSource

などに影響します。

APIサーバーや分析サービスへの通信が必要な場合は、connect-srcへ許可するドメインを追加します。

フロントエンドとAPIが別ドメインになっているサービスでは、特に重要な設定です。

frame-srcとframe-ancestors

iframeを利用する場合は、frame-srcで読み込み可能なページを指定できます。

また、frame-ancestorsを利用すると、自分のWebページをどのサイトのiframe内に表示してよいかを制御できます。

これにより、クリックジャッキング対策としても活用できます。

nonceを利用する方法

インラインJavaScriptを完全に削除できない場合は、nonceを利用できます。

nonceは、ページごとに生成するランダムな値です。

CSPヘッダーと許可するscriptタグの両方に同じnonceを設定することで、正規のインラインスクリプトだけを実行できます。

固定値ではなく、リクエストごとに安全なランダム値を生成することが重要です。

Report-Onlyモードから始める

既存サイトへいきなり厳しいCSPを適用すると、必要なJavaScriptやCSSまでブロックされ、サイト機能が動かなくなる可能性があります。

そこで便利なのが、

Content-Security-Policy-Report-Only

です。

Report-Onlyモードでは、違反を実際にブロックせず、どのリソースがポリシーに違反しているかを確認できます。

まずReport-Onlyでログを収集し、

• 必要な通信

• 不要な外部スクリプト

• 古いインラインコード

などを整理してから本番適用すると安全です。

CSPは段階的に強化する

CSPは一度設定すれば終わりではありません。

新しい機能や外部サービスを追加すると、必要なリソースも変化します。

そのため、

1. 現在利用しているリソースを把握する

2. Report-Onlyで確認する

3. 必要最小限のドメインを許可する

4. 本番へ適用する

5. 違反ログを継続的に監視する

という流れで改善していく方法が現実的です。

外部スクリプトを定期的に見直す

長期間運営されているWebサイトでは、過去に追加された外部スクリプトがそのまま残っている場合があります。

例えば、

• 古い分析タグ

• 使用していないチャット機能

• 廃止されたウィジェット

• 不要な広告タグ

などです。

CSPの導入をきっかけに外部リソースを整理すると、セキュリティだけでなくページ速度の改善にもつながります。

実際のサービス運用で考えること

WINMYRのように複数のフロントエンド機能や外部リソースを利用するデジタルプラットフォームでは、どのドメインからどの種類のコンテンツを読み込んでいるかを把握することが重要です。

CSPを導入することで、必要な通信だけを明確に許可し、不明な外部スクリプトや意図しないリソースの実行を制限しやすくなります。

また、新しい外部サービスを追加するときにCSP設定の変更をレビューする運用を取り入れると、依存関係を把握しやすくなり、長期的なセキュリティ管理にも役立ちます。

まとめ

Content Security Policyは、ブラウザが読み込むコンテンツを制御することで、XSSをはじめとする攻撃リスクを軽減するための重要な仕組みです。

特に、

• default-src

• script-src

• style-src

• img-src

• connect-src

• frame-ancestors

などを適切に設定することで、Webページが利用できるリソースを細かく制御できます。

ただし、最初から厳しい設定を適用するのではなく、Report-Onlyモードを活用しながら段階的に導入することが重要です。

CSPを入力値検証やHTTPS、適切な認証設計などと組み合わせることで、より安全で管理しやすいWebサービスを構築できます。

Webページを開いたとき、ブラウザはHTMLを受け取ってすぐに画面へ表示しているわけではありません。

実際には、HTMLやCSS、JavaScriptを解析し、ページ構造を組み立て、レイアウトを計算し、最後に画面へ描画するという複数の処理が行われています。

この流れを理解すると、表示速度の改善やフロントエンドの最適化を考えやすくなります。

本記事では、ブラウザがWebページを表示するまでの基本的なレンダリングプロセスについて解説します。

ブラウザがページを表示するまでの流れ

大まかな流れは次の通りです。

1. HTMLを取得する

2. HTMLを解析してDOMを作成する

3. CSSを解析してCSSOMを作成する

4. DOMとCSSOMからRender Treeを作る

5. レイアウトを計算する

6. 各要素を描画する

7. 必要に応じて合成処理を行う

これらの処理が短時間で行われることで、ユーザーはページを見ることができます。

DOMとは

DOMは「Document Object Model」の略です。

ブラウザはHTMLを上から順番に読み込み、タグの構造をツリー形式に変換します。

例えば、

• header

• main

• section

• button

• footer

などの要素が、それぞれ親子関係を持った構造として管理されます。

JavaScriptからHTML要素を操作できるのも、DOMという仕組みがあるためです。

CSSOMとは

CSSOMは「CSS Object Model」の略です。

ブラウザはCSSファイルを解析し、どの要素にどのスタイルを適用するかを整理します。

例えば、

• フォントサイズ

• 文字色

• 背景色

• 幅

• 高さ

• 余白

などの情報がCSSOMとして管理されます。

CSSの読み込みが遅れると、ページの描画開始も遅れる可能性があります。

そのため、不要なCSSを減らし、重要なスタイルを効率的に読み込むことが重要です。

Render Treeの作成

DOMとCSSOMが準備されると、ブラウザはRender Treeを作成します。

Render Treeには、実際に画面へ表示される要素だけが含まれます。

例えば、display: noneが設定されている要素は、通常Render Treeには含まれません。

ブラウザはこの情報を使って、どの要素をどこに表示するかを判断します。

Layoutとは

Render Treeが完成すると、ブラウザは各要素の位置とサイズを計算します。

この処理はLayout、またはReflowと呼ばれます。

具体的には、

• 要素の幅

• 高さ

• 上下左右の位置

• 親要素との関係

• 画面サイズ

などが計算されます。

レスポンシブデザインでは、画面幅が変わるたびに再計算が発生することがあります。

Paintとは

Layoutで位置とサイズが決まると、ブラウザは実際に画面へ要素を描画します。

これがPaintです。

Paintでは、

• 文字

• 背景

• 枠線

• 画像

• 影

などが描かれます。

複雑なデザインや大きな影、頻繁に変化するスタイルが多いと、描画コストが高くなることがあります。

Compositeとは

現代のブラウザでは、ページ全体を一度に描画するのではなく、複数のレイヤーに分けて処理することがあります。

最後に、それぞれのレイヤーを合成して画面へ表示する処理がCompositeです。

例えば、

• アニメーション

• transform

• opacity

などは、適切に使えばLayoutやPaintを減らし、比較的滑らかに動かすことができます。

JavaScriptがレンダリングへ与える影響

JavaScriptはページを動的にするために便利ですが、実行方法によってはレンダリングを遅らせる可能性があります。

特に、HTML解析中に同期的なJavaScriptを読み込むと、ブラウザはスクリプトの取得と実行が終わるまでHTML解析を停止する場合があります。

そのため、

• defer

• async

• Code Splitting

• Lazy Loading

などを適切に利用することが重要です。

ReflowとRepaintを減らす

JavaScriptでDOMやスタイルを頻繁に変更すると、ブラウザはLayoutやPaintを繰り返すことがあります。

例えば、ループ内で何度も要素のサイズを変更すると、再計算が増える可能性があります。

改善するには、

• DOM変更をまとめて行う

• 不要なスタイル変更を減らす

• アニメーションではtransformを活用する

• 大量の要素を一度に更新しない

といった方法が有効です。

Critical Rendering Pathを意識する

ページが最初に表示されるまでの一連の処理は、Critical Rendering Pathと呼ばれます。

この経路を短くすることで、ユーザーがコンテンツを見るまでの時間を短縮できます。

具体的には、

• CSSファイルを小さくする

• 不要なJavaScriptを遅延させる

• Webフォントを最適化する

• 重要な画像を優先的に読み込む

といった施策があります。

Webフォントもレンダリングに影響する

Webフォントの読み込みが遅いと、文字が一時的に表示されなかったり、後からフォントが切り替わってレイアウトが変化したりすることがあります。

そのため、

• 必要なフォントだけを使用する

• 不要なウェイトを削除する

• preloadを検討する

• font-displayを適切に設定する

といった対策が有効です。

画像サイズの指定も重要

画像に幅と高さが設定されていない場合、ブラウザは画像を読み込むまで必要なスペースを正確に判断できません。

画像が読み込まれた後に周囲の要素が移動すると、CLSの悪化につながります。

widthとheightをあらかじめ指定することで、レイアウトを安定させることができます。

実際のサービス運用で考えること

WINMYRのように複数の画像やインタラクティブなコンポーネントを持つデジタルプラットフォームでは、ブラウザがどの順番でリソースを処理しているかを理解することが重要です。

単純にファイルサイズを小さくするだけでなく、どのCSSやJavaScriptを最初に読み込むべきか、どの処理を後回しにできるかを整理することで、体感速度を改善しやすくなります。

また、機能追加後にはChrome DevToolsのPerformance機能などを利用し、LayoutやPaintが頻繁に発生していないか確認することも効果的です。

まとめ

ブラウザレンダリングは、DOM、CSSOM、Render Tree、Layout、Paint、Compositeという複数の処理によって成り立っています。

Webサイトを高速化するためには、単にサーバーの応答時間だけを見るのではなく、ブラウザ側でどのような処理が発生しているかを理解することが重要です。

不要なJavaScriptやCSSを減らし、DOM操作やレイアウト再計算を抑え、重要なリソースを優先的に読み込むことで、より高速で滑らかなWeb体験を実現できます。

Webサイトの表示速度を改善するうえで、キャッシュは非常に重要な仕組みです。

同じ画像やCSS、JavaScriptをユーザーがページを開くたびに毎回ダウンロードしていると、通信量が増え、表示速度も遅くなります。キャッシュを適切に利用すれば、一度取得したデータを再利用できるため、ページ表示を高速化できます。

本記事では、Webサイト運用で押さえておきたいキャッシュ戦略の基本を紹介します。

キャッシュとは

キャッシュとは、一度取得したデータを一時的に保存し、次回以降のアクセス時に再利用する仕組みです。

Web開発では、主に次のような場所でキャッシュが利用されます。

• ブラウザ

• CDN

• Webサーバー

• アプリケーション

• データベース

それぞれ役割が異なるため、どのデータをどこで保存するかを考えることが重要です。

ブラウザキャッシュ

最も身近なのがブラウザキャッシュです。

ユーザーがWebサイトへアクセスすると、画像やCSS、JavaScriptなどのファイルがブラウザに保存されます。

次に同じページを開いたとき、保存済みのファイルを再利用できれば、サーバーから再度ダウンロードする必要がありません。

これにより、

• ページ表示の高速化

• 通信量の削減

• サーバー負荷の軽減

といった効果が期待できます。

Cache-Controlを理解する

HTTPでは、Cache-Controlヘッダーを使ってキャッシュ方法を指定できます。

代表的な設定には次のようなものがあります。

max-age

キャッシュを何秒間利用できるかを指定します。

更新頻度の低い画像やJavaScriptでは、比較的長い期間を設定できます。

no-cache

キャッシュそのものを禁止するわけではなく、利用前にサーバーへ確認を行う設定です。

no-store

データを保存しないように指定します。

機密性の高い情報など、保存すべきでないレスポンスで利用されます。

public / private

publicは共有キャッシュでも保存可能で、privateは基本的にユーザーのブラウザなど個別環境だけで保存されます。

静的ファイルは長期間キャッシュする

画像やCSS、JavaScriptのように頻繁に変わらないファイルは、長めのキャッシュ期間を設定すると効果的です。

ただし、ファイルを更新したときに古いキャッシュが残る問題があります。

その対策としてよく使われるのが、ファイル名にハッシュ値を付ける方法です。

例えば、

main.8f34a2.css

app.c51e97.js

のようにします。

ファイル内容が変わると名前も変わるため、ブラウザは新しいファイルとして認識します。

これにより、長期間キャッシュと確実な更新を両立できます。

CDNキャッシュ

CDNを利用している場合、エッジサーバーにもコンテンツをキャッシュできます。

ユーザーに近い場所からデータを配信できるため、通信距離を短縮できます。

特に、

• 画像

• CSS

• JavaScript

• Webフォント

• 動画サムネイル

などの配信に向いています。

CDNキャッシュを利用すると、オリジンサーバーへのアクセス数も減るため、サーバー負荷の軽減にもつながります。

キャッシュヒット率を確認する

キャッシュを導入したら、実際にどの程度使われているかを確認する必要があります。

重要な指標の一つが「キャッシュヒット率」です。

キャッシュヒット率が高いほど、保存済みデータからレスポンスできていることになります。

逆に低い場合は、

• キャッシュ期間が短すぎる

• URLが頻繁に変化している

• 不要なキャッシュ無効化が行われている

などの可能性があります。

APIレスポンスのキャッシュ

APIも内容によってはキャッシュできます。

例えば、

• 公開ニュース一覧

• カテゴリ情報

• 設定データ

• 更新頻度の低いランキング情報

などは、短時間キャッシュすることでバックエンド負荷を軽減できます。

一方で、

• ユーザー個別情報

• リアルタイムデータ

• 認証情報

• 頻繁に変化する状態

などは慎重に扱う必要があります。

誤ったキャッシュ設定を行うと、別のユーザー向けデータが表示されるなど重大な問題につながる可能性があります。

キャッシュしすぎることにも注意する

キャッシュは長く設定すれば良いというものではありません。

更新頻度の高いコンテンツを長期間キャッシュすると、新しい情報が反映されにくくなります。

そのため、

• ほぼ変更されない静的ファイル

• 数時間ごとに変わるデータ

• リアルタイム更新が必要な情報

を分類し、それぞれ異なるキャッシュポリシーを設定することが重要です。

stale-while-revalidateという考え方

ページ速度と情報更新を両立する方法として、stale-while-revalidateという仕組みがあります。

これは、期限切れのキャッシュを一時的にユーザーへ表示しながら、バックグラウンドで新しいデータを取得する方法です。

ユーザーは待たずにコンテンツを見ることができ、次回アクセス時には最新データが利用できます。

更新頻度と表示速度のバランスを取りたい場合に便利です。

キャッシュとCore Web Vitals

キャッシュはCore Web Vitalsの改善にも関係します。

特に再訪問ユーザーでは、CSSやJavaScript、画像をキャッシュから読み込めるため、LCPなどの表示速度指標を改善しやすくなります。

ただし、キャッシュだけですべてが解決するわけではありません。

画像最適化、JavaScript削減、CDNなどと組み合わせることで、より大きな効果を得られます。

実際のサービス運用で考えること

WINMYRのように複数のコンテンツや静的リソースを扱うデジタルサービスでは、すべてを同じキャッシュ設定にするのではなく、データの更新頻度に合わせてポリシーを分けることが重要です。

例えば、ロゴや共通UIのファイルは長期間キャッシュし、更新頻度の高いコンテンツは短時間キャッシュにすることで、表示速度と情報の新鮮さを両立しやすくなります。

また、CDNのキャッシュヒット率やオリジンサーバーへのリクエスト数を定期的に確認することで、設定が実際に効果を発揮しているか判断できます。

まとめ

キャッシュは、Webサイトの高速化とサーバー負荷軽減を実現する基本的な技術です。

重要なのは、すべてのデータを同じように保存するのではなく、コンテンツの性質に応じてキャッシュ期間や保存場所を適切に設定することです。

ブラウザキャッシュ、CDNキャッシュ、APIキャッシュを組み合わせ、キャッシュヒット率を確認しながら継続的に改善することで、より高速で安定したWebサービスを構築できます。

Webサイトやオンラインサービスでは、ページの表示速度がユーザー体験に大きく影響します。画像や動画などのコンテンツが増えるにつれて、サーバーへの負荷や通信時間も増加しやすくなります。

こうした課題を解決するために、多くのWebサービスで採用されているのが**CDN（Content Delivery Network）**です。

本記事では、CDNの基本的な仕組みや導入するメリット、運用時のポイントについて解説します。

CDNとは

CDNとは、世界各地に配置されたサーバー（エッジサーバー）を利用して、ユーザーに最も近い場所からコンテンツを配信するネットワークです。

通常、すべてのリクエストを1台のオリジンサーバーで処理すると、利用者が遠方にいる場合は通信時間が長くなることがあります。

CDNを利用すると、ユーザーは地理的に近いサーバーからデータを受け取るため、ページ表示が速くなります。

CDNの仕組み

CDNの基本的な流れは次のようになります。

1. ユーザーがWebサイトへアクセスする

2. DNSが最寄りのエッジサーバーへ誘導する

3. キャッシュが存在する場合はエッジサーバーから配信する

4. キャッシュがない場合はオリジンサーバーから取得する

5. 取得したデータをキャッシュし、次回以降の配信に利用する

この仕組みにより、同じコンテンツへのアクセスが繰り返されても、毎回オリジンサーバーへ問い合わせる必要がなくなります。

CDNを導入するメリット

表示速度の向上

ユーザーに近いサーバーからデータを配信するため、ネットワーク遅延を抑えられます。

特に画像やCSS、JavaScriptなどの静的ファイルでは効果が大きくなります。

サーバー負荷の軽減

キャッシュされたコンテンツはCDNが配信するため、オリジンサーバーへのアクセス数を減らせます。

アクセスが集中した場合でも、システム全体の安定性を維持しやすくなります。

可用性の向上

複数の拠点にコンテンツを配信することで、一部のサーバーに障害が発生してもサービスを継続しやすくなります。

キャッシュ設計の重要性

CDNの効果を最大限に引き出すためには、適切なキャッシュ設定が欠かせません。

例えば、

• 更新頻度の低い画像

• JavaScript

• CSS

• Webフォント

などは長めのキャッシュ期間を設定できます。

一方で、頻繁に更新されるAPIレスポンスやユーザーごとに内容が異なるページは、キャッシュ対象を慎重に判断する必要があります。

HTTPSとの組み合わせ

現在のCDNサービスはHTTPSにも対応しています。

TLS終端をCDN側で処理する構成を採用することで、暗号化通信を維持しながら高速な配信を実現できます。

また、HTTP/2やHTTP/3に対応したCDNを利用することで、通信効率をさらに向上させることも可能です。

CDN導入時の注意点

CDNを利用する際には、次のような点を確認すると安心です。

• キャッシュの有効期限が適切か

• 更新時のキャッシュ削除（Purge）が容易か

• HTTPS証明書の管理方法

• ログ取得やアクセス解析に対応しているか

• 世界各地域で安定した配信が可能か

導入後もアクセス状況を定期的に確認し、キャッシュヒット率やレスポンス時間を分析することが重要です。

実際のサービス運用

WINMYRのように、多数の画像や静的コンテンツを配信するデジタルサービスでは、CDNを活用することで表示速度の向上とサーバー負荷の分散が期待できます。

さらに、ブラウザキャッシュや画像最適化と組み合わせることで、より快適な閲覧環境を実現しやすくなります。パフォーマンスを継続的に計測し、利用状況に応じてキャッシュポリシーを見直すことが、安定したサービス運用につながります。

まとめ

CDNは、Webサイトの表示速度を改善し、サーバー負荷を軽減するための重要な技術です。

単に導入するだけでなく、キャッシュ戦略やHTTPS対応、配信状況の分析を含めて運用することで、その効果を最大限に活かすことができます。

高速で安定したWebサービスを提供するためには、CDNをはじめとするインフラ技術を適切に活用し、継続的な改善を積み重ねていくことが重要です。

インターネットは私たちの日常生活に欠かせない存在となり、情報収集やオンラインサービスの利用、仕事や学習まで、多くの場面でWebサイトを利用しています。その中で、安全な通信を実現する「HTTPS」は、現在でも非常に重要な技術の一つです。

ブラウザのアドレスバーに表示される鍵のアイコンを見たことがある方も多いでしょう。このマークは、そのWebサイトがHTTPSによる暗号化通信を利用していることを示しています。

HTTPSとは何か

HTTPS（HyperText Transfer Protocol Secure）は、Webブラウザとサーバーの間で送受信されるデータを暗号化する通信方式です。

従来のHTTPと比較すると、HTTPSには次のような特徴があります。

• 通信内容を暗号化できる

• データの改ざんを防ぎやすい

• 接続先の正当性を確認しやすい

• 利用者の安心感につながる

これらの仕組みにより、より安全なWeb利用環境が実現されています。

ユーザー体験にも影響する

HTTPSはセキュリティだけでなく、ユーザー体験にも関係しています。

近年のWebブラウザでは、安全ではない通信を利用するサイトに警告を表示することがあります。そのため、HTTPSに対応しているサイトは利用者に安心感を与えやすく、初めて訪れるサイトでも信頼性を感じてもらいやすくなります。

また、ページ全体の品質向上を考えるうえでも、HTTPSは基本的な要素の一つとなっています。

モバイル時代だからこそ重要

スマートフォンやタブレットからアクセスするユーザーは年々増えています。

公共のWi-Fiなど、さまざまなネットワーク環境を利用する機会も多くなった現在では、安全な通信環境を整えることがこれまで以上に重要です。

HTTPSは、こうした多様な利用環境でも安心してサービスを利用するための基本的な仕組みとして広く採用されています。

開発者にとってのメリット

HTTPSを導入することは、利用者だけでなく開発者にも多くの利点があります。

例えば、

• 最新ブラウザ機能への対応

• Web APIの利用範囲拡大

• 保守性の向上

• 長期的なサイト運営の基盤づくり

などが挙げられます。

現在では、多くの新しいWeb技術がHTTPS環境を前提として設計されています。

実際のデジタルサービスから学べること

多くのデジタルプラットフォームでは、安全性と使いやすさを両立するためにHTTPSを標準的な通信方式として採用しています。

例えば WINMYR のようなデジタルプラットフォームでも、レスポンシブデザインや分かりやすいインターフェースとあわせて、安全な通信環境を重視した設計思想が取り入れられています。こうした基本的な技術への取り組みは、ユーザーが安心してサービスを利用できる環境づくりに役立っています。

まとめ

HTTPSは、特別な機能ではなく、現代のWebサイトに欠かせない基本技術となっています。

安全な通信、快適なユーザー体験、そして将来のWeb技術への対応を考えると、HTTPSの重要性は今後も変わることはないでしょう。

Webサイトやデジタルサービスを設計・運営する際には、デザインや機能だけでなく、安全な通信環境を整えることも重要な品質の一部として考えることが大切です。

Webサービスの品質を評価する際、「どれだけ多くの機能があるか」だけではなく、「どれだけ快適に利用できるか」が重要視されるようになっています。特にモバイル利用が中心となった現在では、表示速度や操作性がサービス全体の印象を左右します。

その改善策の一つとして、多くの開発チームが注目しているのが Progressive Web Apps（PWA） です。

パフォーマンス改善はユーザー満足度につながる

ページの表示が遅いと、ユーザーは目的の情報を見る前に離脱してしまう可能性があります。そのため、Webサイトの最適化では次のような項目が重視されています。

• 初回表示時間の短縮

• 不要なデータ通信の削減

• スムーズな画面遷移

• モバイル環境での安定した動作

PWAはこれらの課題に対応しやすい技術として、多くのWebプロジェクトで検討されています。

キャッシュ設計が重要なポイント

PWAでは、ブラウザのキャッシュを効率的に利用することで、再訪問時の読み込み時間を短縮できます。

ただし、すべてのデータを保存すればよいわけではありません。更新頻度やコンテンツの種類に応じてキャッシュ戦略を設計することが重要です。

適切な設計により、快適な閲覧環境と最新情報の提供を両立できます。

モバイルユーザーを意識した設計

スマートフォンからのアクセスが増えている現在では、画面サイズへの対応だけでなく、指で操作しやすいレイアウトや見やすい文字サイズも重要です。

PWAはレスポンシブデザインと組み合わせることで、デバイスを問わず一貫した操作性を実現できます。

開発効率にもメリットがある

PWAはWeb技術をベースとしているため、既存の開発環境を活用しながら機能を拡張できます。

また、複数の環境に対応しやすく、保守やアップデートの効率化にもつながります。これは長期的な運用を考える企業にとって大きな利点と言えるでしょう。

実際のサービス設計から学べること

近年では、さまざまなデジタルサービスがモバイル環境での快適な利用を重視しています。WINMYR のようなプラットフォームでも、シンプルなナビゲーションやスムーズな画面遷移を意識した設計は、現代のWebサービスに求められるユーザー中心の考え方を理解するうえで参考になる事例の一つです。

まとめ

PWAは新しい機能を追加するためだけの技術ではなく、Webサービス全体の品質を向上させるための実践的なアプローチです。

表示速度、操作性、保守性のバランスを考えながら導入を検討することで、より快適なユーザー体験を提供できる可能性があります。これからのWeb開発では、最新技術を採用するだけでなく、実際の利用シーンを意識した設計がますます重要になるでしょう。