ケイパビリティ
ブラウザは、システムの中で最も制御の効かない実行環境です。端末は不明、ネットワークは不安定、入力は信頼できません。私たちはフロントエンドをスタイリングの作業ではなくアーキテクチャの問題として捉え、コードをどこでレンダリングするか、状態をどこに置くか、インターフェースをどのように縮退させるかを設計します。
フロントエンドエンジニアリングとは、チームの誰も制御できないハードウェアとネットワークの上で実行される部分を設計することです。混雑したモバイル回線につながったミドルレンジのAndroid端末は、開発者のノートPCに比べて数倍遅くJavaScriptをパースします。そのため、どれだけのコードを配信するか、HTMLをどこで生成するか、ページがいつ操作可能になるか、クリックから結果までに何往復の通信が挟まるかといったアーキテクチャ上の選択は、すべてユーザーの体感レイテンシに直接跳ね返ります。
同じ選択が、コードベースとチームをどこまで拡大できるかも決めます。モジュール境界も、型付けされたAPIコントラクトも、共有コンポーネントライブラリもないフロントエンドは、単一のデプロイ単位となり、あらゆる変更が別の箇所でのリグレッションを招くおそれを抱え、エンジニアを増やすほどデリバリーは遅くなります。機能間の明示的な境界、バージョン管理されたトークンとコンポーネントを備えたデザインシステム、自動生成されたAPI型があれば、複数のチームがリリースのたびに調整することなく並行して出荷できます。
私たちはTypeScriptを用い、ReactとNext.js、またはVueとNuxtで開発します。レンダリング戦略、状態の所有者、パフォーマンスバジェット、アクセシビリティ、ブラウザセキュリティは、ルート単位・機能単位で下す第一級の設計判断として扱います。それぞれの判断を記録し、パイプラインで計測し、本番環境では実ユーザーのデータで観測します。
エンジニアリング領域
コンポーネントは、表示専用のプリミティブ、それらを組み合わせたパターン、自身のデータアクセスを持つ機能モジュールに分割し、依存は一方向にのみ許可します。色、余白、タイポグラフィ、モーションのデザイントークンを唯一の信頼できる情報源とし、CSSカスタムプロパティとして出力することで、コンポーネントのコードに触れずにテーマやブランドを切り替えられます。インポートパスに対するLintルールで境界を強制するため、チームが拡大しても境界は保たれます。
サーバーステートはバックエンドが所有するデータのキャッシュであり、フェッチ、重複排除、無効化、リトライが必要です。クライアントステートは、開いているパネル、下書き、選択状態といった一時的なUIの状態です。両者を1つのグローバルストアで扱うことが、古いデータの表示や不要な再レンダリングの最も一般的な原因です。私たちはサーバーステートをクエリキャッシュに、共有可能な状態をURLに置き、クライアントストアは残ったものだけに使います。
サーバーサイドレンダリング、静的生成、クライアントサイドレンダリング、ストリーミングは、最初の1バイトまでの時間（TTFB）、操作可能になるまでの時間、キャッシュのしやすさ、インフラコストのトレードオフがそれぞれ異なります。どれを選ぶかは、コンテンツにどの程度のパーソナライズと鮮度が求められるかに応じてルートごとに決めます。ハイドレーションのコストはバジェットとして管理し、サーバーコンポーネント、アイランド、遅延ハイドレーションで削減します。
Core Web Vitalsは、読み込み（Largest Contentful Paint）、応答性（Interaction to Next Paint）、視覚的安定性（Cumulative Layout Shift）を、実ユーザーの75パーセンタイルで計測する指標です。公開されている「良好」のしきい値は、それぞれ2.5秒、200ミリ秒、0.1です。ラボ環境のスコアは低速な端末の実態を表さないため、私たちはバンドルサイズとロングタスクにバジェットを設定してCIで強制し、フィールドデータで検証します。
アクセシビリティは、完成したページを監査して後付けするとコストがかさむため、低コストで対応できるコンポーネントライブラリの段階で組み込みます。目標はWCAG 2.2のレベルAAです。まずセマンティックなHTMLを使い、ARIAはネイティブのセマンティクスで足りない箇所に限定し、キーボードだけで完全に操作できるようにしたうえで、ダイアログやルート遷移ではフォーカスを管理します。レイアウトは固定のデバイス幅の一覧ではなく、コンテナのサイズと入力方式に応じて変化させます。
ブラウザ内にあるものはすべてユーザーから見え、ページ上で実行されるあらゆるスクリプトから到達できます。そのため、フロントエンドが持つ権限は可能な限り小さく設計します。Service Workerは、プロダクトが必要とする場合にオフラインキャッシュ、インストール可能性、バックグラウンド同期を提供します。ライブデータは、流れが一方向であればServer-Sent Eventsで、クライアント側からも低レイテンシで送信する必要があればWebSocketで受け取ります。
レンダリングはアプリケーション全体で1つに決める設定ではありません。同じプロダクトの中でも、マーケティングページ、商品一覧、認証後のダッシュボード、ドキュメントエディタでは、鮮度、パーソナライズ、インタラクティブ性の要件が異なり、Next.jsやNuxtといったフレームワークではルートごとに方式を選べます。判断の軸は2つです。そのHTMLをユーザー間で共有できるか、そしてどの程度古くなることを許容できるかです。
ハイドレーションは、サーバーレンダリングの隠れたコストです。サーバーがHTMLを送信した後、クライアントは同じコンポーネントツリーをダウンロードして実行し、イベントハンドラを接続します。それが完了するまで、ページは準備ができたように見えても反応しません。サーバーコンポーネントは、インタラクティブでないコンポーネントをクライアントバンドルから完全に取り除きます。ストリーミングは、シェルを即座に送信し、遅いデータはSuspense境界の背後で解決するため、1つの遅いクエリがレスポンス全体を遅らせることがなくなります。
アーキテクチャ
ビルド時（SSG）
コンテンツとデータ
ビルド時にCMS、Markdown、APIを読む
静的生成
ページを一度だけHTMLにレンダリング
CDN
キャッシュしてエッジから配信
再検証
変更時または一定間隔で再生成
リクエスト時（SSR）
リクエスト
ユーザー別または最新のデータが必要
サーバーレンダリング
データを取得しコンポーネントを描画
ストリーミング
シェルを先に送り、遅い部分は後続
ハイドレーション
ブラウザでハンドラーをアタッチ
クライアント（SPA）
クライアント状態
UI状態と楽観的更新
API呼び出し
バックエンドへの型付きリクエスト
キャッシュ
重複排除、再検証、無効化
ナビゲーション
プリフェッチ付きクライアントルーティング
アプリケーションが表示するものの大半は、アプリケーション自身の状態ではありません。それはバックエンドのデータのスナップショットであり、いつでも古くなる可能性があり、複数のコンポーネントから同時に要求されることがあり、ミューテーションの後には再取得が必要です。クエリキャッシュはこれをそのままモデル化します。各リソースがキー、鮮度の有効期間、リトライポリシー、無効化ルールを持ち、コンポーネントはデータをストアにコピーする代わりにキーを購読します。
サーバーステートをグローバルストアから切り離すと、残るものは通常わずかです。フォームの下書き、ウィザードの進行状況、UIの設定などです。フィルター、ソート順、ページネーション、選択中のタブはURLに置くべきものです。そうすることで、画面をリンクとして共有でき、リロード時に復元され、戻るボタンも正しく動作します。専用のクライアントストアが正当化されるのは、キャンバスエディタや取引の注文入力画面のように、離れたコンポーネント間で共有され、かつ高頻度で変化する状態です。
フロントエンドがチームとともにスケールするのは、変更が局所にとどまる場合だけです。そのためには、公開インターフェースを持つ機能モジュール、機能同士が互いの内部をインポートしないというルール、そしてバージョン管理され所有者が明確な、デザインシステムのコンポーネントとAPIクライアントからなる共有レイヤーが必要です。モノレポでは、TurborepoやNxといったツールが依存グラフを用いて、変更の影響を受ける部分だけをビルド・テストするため、コードベースが大きくなってもパイプラインの所要時間はほぼ一定に保たれます。
マイクロフロントエンドはこれをさらに推し進め、各チームに独立してデプロイできるスライスを与え、Module Federationやエッジで合成します。これが解決するのは、多数のチームにまたがる独立したリリースサイクルという組織上の問題であり、その代償として依存関係の重複、一貫性の維持の難しさ、ランタイムの複雑化を伴います。ほとんどのプロダクトでは、境界を強制したモジュラーモノリス型のフロントエンドにより、1つのビルドと1つのデプロイで同等の分離が得られます。
スケールを制約するもう1つの要素がAPIコントラクトです。OpenAPIドキュメントやGraphQLスキーマから生成した型は、バックエンドの破壊的変更を本番環境での実行時エラーではなく、パイプライン上のコンパイルエラーに変えます。さらに、あらゆるコンポーネントから防御的なコードの一群を取り除けます。
エンジニアリングの進め方
私たちは、プロダクトを使う人々とそれを保守するチームの制約を起点とし、後から覆すとコストが高くつく判断を、画面を1つも作る前に確定させます。
対象端末、ネットワーク条件、インデックス要件、アクセシビリティ上の義務、ブラウザサポートを特定し、それらをルートごとのJavaScript量、Core Web Vitals、インタラクションのレイテンシに関する数値バジェットへと落とし込みます。
各ルートにレンダリング戦略とキャッシュポリシーを割り当て、各状態にはサーバーキャッシュ、URL、コンポーネント、クライアントストアのいずれかを所有者として割り当てます。セッションモデルとトークンの扱いも、この時点でバックエンドと合意します。
機能開発の前に、トークンとアクセシブルなプリミティブを実装し、Storybookでドキュメント化します。キーボード操作、フォーカス処理、コントラストはコンポーネントレベルで一度検証し、すべての画面がそれを継承するようにします。
機能モジュールは生成されたAPI型とモックサーバーを利用するため、フロントエンドとバックエンドは並行して開発を進められます。ユニットテストでロジックを、コンポーネントテストで振る舞いを、Playwrightで重要なユーザージャーニーをエンドツーエンドで検証します。
すべてのプルリクエストで、プレビューデプロイに対して型チェック、Lint、アクセシビリティチェック、バンドルサイズの比較、Lighthouseのバジェット検証を実行します。バジェットを超える変更は、リリース後に発覚するのではなく、ビルドの失敗として検出されます。
リアルユーザーモニタリングにより、Core Web Vitals、JavaScriptエラー、インタラクションのトレースを、ルート、端末クラス、リリースごとに把握します。リグレッションは特定のデプロイまで遡って原因を特定し、フィールドデータに基づいて修正します。
トレードオフ
アーキテクチャを確定する前に、お客様のチームとともに検討する問いです。
本番対応
nonceベースの厳格なContent Security Policy、フレームワークによる出力エンコーディング、Trusted Typesによってクロスサイトスクリプティングの影響を抑え、セッションの認証情報はスクリプトから届かないHttpOnly Cookieに保持します。依存関係はロックファイルで固定してCIで監査し、サードパーティのオリジンから配信する場合はSubresource Integrityを付けて読み込みます。認可は常にAPI側で強制します。UI上でコントロールを隠すことはユーザビリティ上の措置であり、セキュリティ対策ではありません。
静的アセットはコンテンツハッシュを付与してimmutableとしてキャッシュし、CDNから配信するため、トラフィックの増加の大半はオリジンではなくエッジで吸収されます。サーバーレンダリングするルートはステートレスなプロセスとして水平にスケールし、Cache-Controlとstale-while-revalidateをルートごとに調整します。コードベースの拡大には、モジュール境界、影響範囲のみのビルド、リモートビルドキャッシュで対応します。
リアルユーザーモニタリングでLCP、INP、CLSを記録し、原因となった要素やインタラクションを特定できる形で、ルート、端末、リリースごとに分類します。エラーは非公開でアップロードしたソースマップとともに収集し、ブラウザのスパンはOpenTelemetryを通じてバックエンドのトレースへ伝播させるため、遅いインタラクションをその原因となったAPIまで追跡できます。
すべてのプルリクエストで独立したプレビューデプロイを生成し、その上で自動チェックと手動チェックを実施します。リリースはアトミックかつイミュータブルであるため、ロールバックは直前のビルドへポインタを切り替えるだけで済み、フィーチャーフラグによってデプロイとリリースを分離します。ロールアウト中も旧バージョンのアセットを利用可能な状態に保ち、開いたままのセッションがチャンクの欠落で失敗しないようにします。
フロントエンドは、生成されたクライアントを通じてRESTまたはGraphQLのAPIを利用し、OpenID Connectで認証し、SSEまたはWebSocketでライブデータを受け取ります。汎用APIでは呼び出し回数が多くなりすぎる場合は、BFFが呼び出しを集約し、ペイロードを整形します。アナリティクス、同意管理、フィーチャーフラグ、コンテンツ管理の各サービスは薄いアダプターの背後に統合し、機能のコードに触れずにベンダーを置き換えられるようにします。
ワークロードとお客様の既存環境に合わせて選定します。
ゼロから本番へ
アイデア
ディスカバリー
システムアーキテクチャ
UX・プロダクトデザイン
アプリケーション開発
AI・データレイヤー
クラウドインフラ
セキュリティ
QA・パフォーマンス
デプロイ
オブザーバビリティ
継続的な進化
FAQ
直接影響します。レンダリング戦略はコンテンツが表示されるまでの速さを、JavaScriptの量はページが応答するまでの速さを、状態とデータ取得の構成は操作が即座に感じられるかネットワークを待つことになるかを決めます。レイアウトの安定性、フォーカスの挙動、オフライン時の扱いも、ビジュアルデザインではなくアーキテクチャの帰結です。
Googleが定義する3つのフィールド指標です。読み込みを表すLargest Contentful Paint、応答性を表すInteraction to Next Paint、視覚的安定性を表すCumulative Layout Shiftからなり、いずれも実際のページビューの75パーセンタイルで評価されます。実際の端末でユーザーが体験していることを表す指標であり、検索ランキングに用いられるシグナルの1つでもあるため重要です。
ほとんどの場合は可能です。段階的な移行では、新旧のアプリケーションを1つのルーターまたはリバースプロキシの背後に置き、セッションとデザイントークンを両者で共有しながら、ルートを1つずつ移していきます。これにより、移行の全期間を通じてプロダクトをリリース可能な状態に保ち、移行した各ルートを置き換え前のものと比較して計測できます。
インストール、オフラインアクセス、バックグラウンド同期の恩恵はあるものの、端末との深い統合までは必要としないプロダクトに適しています。PWAはWebサイトとコードベースを共有でき、ストア審査も不要ですが、一部の端末機能へのアクセス、バックグラウンド実行、プッシュ通知の挙動はプラットフォームによって異なり、特にiOSで違いが目立ちます。そうした制約が問題になる場合は、ネイティブまたはクロスプラットフォームのモバイルアプリケーションのほうが適しています。
axe-coreなどの自動ツールで検出できるのは問題全体のうち少数にとどまり、主に名前やロールの欠落、コントラストの不足です。そのため、自動ツールはベースラインとしてCIで実行します。残りは、WCAG 2.2レベルAAの達成基準に照らして、重要なユーザージャーニーをキーボードのみで操作するウォークスルーと、NVDAおよびVoiceOverによるスクリーンリーダーテストで検証します。
