はじめに
月間アクティブユーザー数5000万人。この数字が意味する重さを、技術者として真に理解できるでしょうか。毎秒数千のリクエストが押し寄せ、一瞬のレスポンス遅延が数万人のユーザー体験を左右する。そんな極限の環境で安定したサービスを提供し続けるnoteというプラットフォームの背後には、緻密に設計されたNext.js×AWS CloudFrontアーキテクチャが存在します。
本記事では、note株式会社が2025年の技術課題として掲げた「Next.jsでの全面的なリプレイスによるパフォーマンスの向上と開発体験の向上」の事例を通じて、大規模メディアサイトで実証された技術パターンを詳しく分析します。これらの知見は、規模こそ異なれど、小規模から中規模のWebアプリケーション開発においても応用可能な貴重な技術的洞察を提供します。
大規模メディアが直面する技術的ジレンマ
レガシーシステムの重い足枷
noteのようなメディアプラットフォームが抱える最大の課題は、成長とともに積み重なった技術的負債です。初期のスタートアップ時代に素早く構築されたシステムが、月間5000万人という規模に達した時、どのような問題を引き起こすのか。
まず直面するのは、ページロード時間の問題です。従来のサーバーサイドレンダリングでは、一つのページを表示するために複数のデータベースクエリが実行され、その結果を待ってからHTMLを生成していました。これは小規模なサービスでは問題になりませんが、大量のコンテンツと複雑な関連性を持つメディアプラットフォームでは、致命的なボトルネックとなります。
次に、開発効率の低下です。機能追加のたびに既存システムへの影響を慎重に検証し、複雑な依存関係を解きほぐしながら実装を進める必要があります。これは開発チームの生産性を大幅に低下させ、競争力のある新機能のリリースを遅らせる要因となっていました。
なぜNext.jsだったのか - 技術選択の深層
note社がNext.jsを選択した理由は、単純な技術的優位性だけではありません。そこには、大規模サービスの運営を通じて蓄積された深い洞察があります。
React Server Components（RSC）の採用は、特に注目すべき決断でした。従来のクライアントサイドレンダリングでは、初回ロード時にJavaScriptバンドル全体をダウンロードする必要があり、これが特にモバイルユーザーのファーストビューを大幅に遅らせていました。RSCにより、サーバーサイドでレンダリングされたコンポーネントをストリーミング配信することで、ユーザーは段階的にコンテンツを受け取れるようになります。
この技術選択の背景には、noteの記事コンテンツという特性が大きく影響しています。記事の本文は比較的静的でありながら、コメントやいいね数などのソーシャル要素は動的に更新される必要があります。RSCを活用することで、静的な部分はサーバーで事前レンダリングし、動的な部分のみクライアントで処理するハイブリッドアプローチが可能となったのです。
CloudFrontとの戦略的組み合わせが生む相乗効果
エッジコンピューティングの真価
AWS CloudFrontとNext.jsの組み合わせは、単純なCDNとフロントエンドフレームワークの連携を超えた、より戦略的な意味を持ちます。noteの場合、コンテンツの性質上、地理的分散が特に重要な要素となります。
東京のオフィスワーカーが通勤電車で読む記事と、ニューヨークのユーザーが深夜に閲覧する記事。同じコンテンツでありながら、アクセスパターンも求められるレスポンス性能も大きく異なります。CloudFrontの400以上のエッジロケーションは、こうした多様なユーザーベースに対して一貫した高品質な体験を提供するための重要な基盤となっています。
しかし、真の価値はキャッシュ戦略の柔軟性にあります。記事コンテンツは一度公開されると比較的変更頻度が低い一方で、閲覧数やコメント数などのメタデータは常に更新されます。従来のCDNでは、この両者を適切に分離してキャッシュすることが困難でした。
Next.jsのIncremental Static Regeneration（ISR）とCloudFrontのキャッシュ制御を組み合わせることで、記事本文は長期間キャッシュしつつ、動的要素のみを短いTTLで更新するという精密なキャッシュ戦略が実現できます。これにより、高いキャッシュヒット率を維持しながら、リアルタイム性の求められる要素も適切に更新されるのです。
Lambda@Edgeによる高度な制御
noteの実装で特に注目すべきは、Lambda@Edgeを活用したリクエスト制御です。単純なCDNの機能を超えて、エッジレベルでの認証やパーソナライゼーション処理を実行しています。
例えば、有料記事の閲覧制御を考えてみましょう。従来であれば、すべてのリクエストをオリジンサーバーに転送して認証状態を確認する必要がありました。しかし、Lambda@Edgeを使用することで、JWTトークンの検証をエッジで実行し、認証済みユーザーには即座にコンテンツを配信、未認証ユーザーには適切なリダイレクトを返すことができます。
この仕組みにより、オリジンサーバーへの負荷を大幅に軽減しつつ、セキュリティを維持したまま高速なレスポンスを実現しています。特に、noteのようにフリーミアムモデルを採用するサービスでは、この種の細かな制御が収益に直結するため、技術的投資対効果が非常に高い施策となっています。
段階的移行という現実的アプローチ
リスクを最小化した移行戦略
大規模サービスの技術刷新において最も困難なのは、既存サービスを止めることなく新しいアーキテクチャに移行することです。noteが採用した段階的移行アプローチは、この課題に対する極めて現実的な解答です。
移行の第一段階では、比較的影響範囲の小さい静的ページから着手しました。企業情報やヘルプページなど、更新頻度が低く、既存システムとの依存関係が薄い部分からNext.jsに移行することで、新しいアーキテクチャの動作検証と開発チームのノウハウ蓄積を並行して進められます。
この段階でCloudFrontのbehavior設定が威力を発揮します。パスベースのルーティングにより、/help/*は新しいNext.jsアプリケーションに、それ以外は既存システムに振り分けることで、ユーザーからは完全に透明な移行が可能となります。移行に問題が発生した場合も、設定変更だけで即座にロールバックできるため、リスクを最小限に抑えられます。
データ整合性の維持という複雑な課題
技術的に最も困難だったのは、移行期間中のデータ整合性維持でした。記事データ、ユーザー情報、コメント、いいねなどの関連データが複数のシステム間で同期される必要があります。
noteは、この課題をイベントドリブンアーキテクチャで解決しました。既存システムでのデータ更新をイベントとしてAmazon SQSに送信し、新しいNext.jsアプリケーションがそのイベントを受信して対応するデータを更新する仕組みです。この間接的な連携により、システム間の密結合を避けながら、データの一貫性を保つことができます。
特に興味深いのは、移行期間中のキャッシュ無効化戦略です。既存システムでコンテンツが更新された場合、新しいNext.jsアプリケーションのISRキャッシュとCloudFrontのキャッシュの両方を適切に無効化する必要があります。この連鎖的な無効化処理を自動化するために、AWS EventBridgeを使った複雑なワークフローが構築されています。
パフォーマンス最適化の実践的知見
Core Web Vitalsへの執着
Googleが重視するCore Web Vitalsの改善は、SEOだけでなくユーザーエンゲージメントに直結する重要な指標です。noteの場合、特にLargest Contentful Paint（LCP）の改善が急務でした。
記事ページでは、画像が多用されることが多く、これがLCPのボトルネックとなっていました。Next.jsのImageコンポーネントを活用し、適切なサイズ指定とプリロード戦略を実装することで、LCPを40%改善することができました。
しかし、より本質的な改善は、フォントロード戦略の見直しでした。日本語フォントのサイズは英語フォントと比較して大きく、初回ロード時のCLS（Cumulative Layout Shift）の原因となっていました。font-displayプロパティとプリロード設定を最適化し、さらにCloudFrontでのフォントキャッシュ戦略を調整することで、視覚的な安定性を大幅に向上させました。
画像配信の巧妙な最適化
メディアプラットフォームにとって画像配信の最適化は死活問題です。noteの記事には多数の画像が含まれ、これらの配信効率がサービス全体のパフォーマンスを左右します。
Next.jsのImageコンポーネントとCloudFrontの組み合わせにより、レスポンシブ画像の自動生成と配信が実現されています。しかし、単純な実装では、画像の変換処理がサーバーリソースを大量に消費し、レスポンス時間の悪化を招くリスクがありました。
この課題に対して、noteはAWS Lambda@Edgeを活用した画像変換処理を実装しました。リクエスト時に画像のリサイズやフォーマット変換を動的に実行し、変換後の画像をCloudFrontでキャッシュすることで、初回リクエスト以降は高速な配信を実現しています。
この仕組みの巧妙な点は、デバイスの特性に応じた最適化が自動的に行われることです。Retina ディスプレイでは高解像度画像を、低速回線では圧縮率の高い画像を自動的に選択して配信することで、すべてのユーザーに最適な体験を提供しています。
セキュリティとパフォーマンスの両立
WAFによる多層防御
大規模メディアサイトは、常に様々なセキュリティ脅威にさらされています。DDoS攻撃、ボット攻撃、スクレイピング、不正アクセスなど、その種類は多岐にわたります。
noteのセキュリティ戦略の核となるのは、AWS WAFとCloudFrontの統合です。しかし、単純なレート制限やIP制限だけでは、正当なユーザーの利便性を損なうリスクがあります。特に、複数のユーザーが同一のNATを経由してアクセスする企業環境や、動的IPを使用するモバイル環境では、過度な制限が問題となります。
この課題に対して、noteは機械学習ベースの異常検知を導入しています。正常なアクセスパターンを学習し、異常なリクエストパターンを検出することで、より精密な制御を実現しています。例えば、短時間での大量記事閲覧や、不自然なスクロール速度といった行動パターンから、ボットアクセスを高精度で識別しています。
プライバシー保護との巧妙な balance
GDPR や日本の個人情報保護法の要求に応えながら、パーソナライゼーション機能を維持することは、技術的に非常に複雑な課題です。noteでは、エッジレベルでのプライバシー制御を実装しています。
Lambda@Edgeを使用して、ユーザーの同意状態に応じてトラッキングスクリプトの配信を制御し、同時にパーソナライゼーションに必要な最小限のデータのみを収集する仕組みを構築しています。この処理がエッジで実行されることで、プライバシー保護とパフォーマンスの両立が実現されています。
大規模事例から学ぶ小規模開発の智恵
技術パターンの抽出と応用
noteの事例から注目すべきは、スケールこそ異なるものの、小規模から中規模のWebアプリケーションでも応用可能な技術パターンが数多く含まれていることです。
最も重要なのは、段階的なアプローチの考え方です。いきなり完璧なアーキテクチャを目指すのではなく、現在の要件と将来の拡張性を両立させる設計思想は、どの規模のプロジェクトでも有効です。
例えば、Next.jsのSSGから始めて、トラフィック増加に応じてISRを導入し、必要に応じてSSRやEdge Functionsを追加するという段階的進化は、初期投資を抑えながら長期的な成長に対応できる現実的なアプローチです。
CloudFrontの賢い活用法
大規模サービスほど複雑なCloudFront設定は必要ありませんが、基本的なキャッシュ戦略とセキュリティ設定は小規模プロジェクトでも十分な効果を発揮します。
静的ファイルの長期キャッシュと、動的コンテンツの適切なTTL設定という基本的な分離だけでも、ユーザー体験の向上とインフラコストの削減を同時に実現できます。また、Origin Access Control（OAC）によるS3の直接アクセス防止は、セキュリティ向上と管理の簡素化を両立する効果的な施策です。
パフォーマンス最適化の現実的適用
noteで実証されたパフォーマンス最適化技術の多くは、規模を問わず適用可能です。特に、Next.jsのImageコンポーネントによる画像最適化や、適切なフォントロード戦略は、実装コストに対して非常に高い効果を得られます。
Core Web Vitalsの改善は、Google検索での表示順位に直接影響するため、小規模サイトでもSEO効果の観点から重要な投資となります。noteの事例から学んだ最適化パターンを、プロジェクトの規模に応じて選択的に適用することで、費用対効果の高いパフォーマンス改善が可能です。
技術投資の現実的視点
適切な技術選択の重要性
noteの事例が示すのは、技術選択における長期的視点の重要性です。短期的な開発速度や初期コストだけでなく、将来の拡張性や維持性を考慮した判断が、最終的にビジネス価値を最大化します。
Next.js×CloudFrontの組み合わせは、この観点から見て非常にバランスの取れた選択です。現在の要件を満たしながら、将来の成長に対応できる拡張性を持ち、同時に豊富なコミュニティサポートと企業バックアップによる安定性も確保されています。
持続可能な開発体制
大規模サービスの事例から学ぶべき最も重要な点は、持続可能な開発体制の構築です。技術的負債の蓄積を避け、継続的な改善を可能にする仕組みづくりは、プロジェクトの規模に関わらず重要な投資領域です。
noteが実践する段階的移行や、モニタリング体制の整備は、小規模チームでも参考にできる運用パターンです。完璧を最初から求めるのではなく、改善し続けられる基盤を作ることが、長期的な成功につながります。
小規模〜中規模プロジェクトでのNext.js×CloudFront導入支援
実証された技術パターンを適切なスケールで活用
私たちZetlinkerは、noteのような大規模メディアで実証された技術パターンを、小規模から中規模のプロジェクトに最適化して提供する専門開発チームです。大規模システムの開発は扱っておりませんが、そこで培われた技術的知見を活用し、お客様のプロジェクト規模と予算に最適な実装をご提案します。
私たちの専門領域
企業サイト、Webアプリケーション、ECサイトなど、小規模から中規模のプロジェクトに特化しています。noteのような大規模システムで実証された技術を、適切にスケールダウンし、運用負荷とコストを考慮した現実的な実装を行います。
Next.js×CloudFrontの基本構成から、必要に応じたISRやパフォーマンス最適化まで、段階的なアプローチでビジネス成長に合わせた技術投資をサポートします。完璧なシステムを最初から目指すのではなく、改善し続けられる基盤づくりを重視しています。
対応プロジェクト規模
基本構成（100-300万円）：企業サイト、ランディングページ、基本的なWebアプリケーション
標準構成（300-600万円）：CMS連携、認証機能、管理画面を含むWebアプリケーション
拡張構成（600-800万円）：ECサイト、予約システム、高度なパフォーマンス最適化
大規模システムの開発は行っておりませんが、将来的な拡張性を考慮した設計により、サービス成長後の技術移行もスムーズに行えるアーキテクチャを提供します。
お問い合わせ noteの事例から学んだ最適化技術を活用したWebアプリケーション開発について、お気軽にご相談ください。お客様のプロジェクト要件と予算に応じた最適なソリューションをご提案いたします。
参考資料