Webアーキテクチャ: レンダリング戦略を事前に選択する
Claudeがデフォルトで採用しがちで、通常は誤っている2つの選択肢があります。それは、すべてをブラウザでレンダリングすること、そして、バニラHTML/JSでマルチページアプリを手作りすることです。どちらも事前に意図的に選択すべきであり、ほとんどの実際のサイトでは、サーバーサイドレンダリングHTMLとフレームワークがより良い答えです。ユーザーが尋ねていなくても、これらの点を指摘してください。本番環境前にWAF（Webアプリケーションファイアウォール）を導入するよう促すのと同じように、常に考慮すべきことです。
クライアントレンダリングではなく、サーバーサイドレンダリングHTMLをデフォルトにする
コンテンツ、SEO、または初回描画（First Paint）が重要な場合、コンテンツは初期HTMLレスポンスに含まれている必要があります。クライアント側のJavaScriptで後から描画するのではありません。クライアントサイドレンダリング（空のシェルをブラウザで取得・描画する方式）では、バンドルの読み込みと実行が完了するまで空白画面が表示され、LCP（ Largest Contentful Paint）が遅くなり、多くのクローラーやLLMの検索エンジンはJavaScriptを確実に実行しないため、コンテンツが認識されないリスクがあります。代わりにサーバーサイドレンダリングを行いましょう。
- SSG（静的サイト生成）: ビルド時にレンダリングし、CDNから静的ファイルを配信します。最速、最も低コスト、最もキャッシュしやすいです。リクエストごとに変化しないコンテンツ（マーケティング、ドキュメント、ブログ、一覧・カテゴリページなど、再ビルド可能なもの）のデフォルトです。
- SSR（サーバーサイドレンダリング）: リクエストごとにサーバーでレンダリングします。動的、パーソナライズ、または認証が必要なコンテンツで、ビルド時に固定できないものに適しています。
- CSR / アイランド: 本当にインタラクティブな部分、またはログイン後のダッシュボードのようにSEOが重要でないアプリ的な画面でのみ、ブラウザでレンダリングします。アイランドアプローチ（Astro）では、ページは静的なHTMLとして配信され、インタラクティブなコンポーネントだけがハイドレーションされます。
ページごとに選択可能です。同じサイト内で、静的なマーケティングページ（SSG）、パーソナライズされたアカウントページ（SSR）、インタラクティブなウィジェット（アイランド）を混在させることができます。
複数ページあるならフレームワークを採用する
プロジェクトに複数のページ、共有レイアウト、ルーティング、または本格的なデータフェッチがある場合、バニラJSで手作りすることは保守性とパフォーマンスの罠です。そして、それがClaudeのデフォルトです。しかし、フレームワーク（Next.js、Astro、SvelteKit、Nuxt、Remix）を採用しましょう。これらのフレームワークは、ルーティング、SSRとSSG、コード分割、データ読み込み、画像最適化を標準で提供し、さらに重要なことに、サーバーサイドレンダリングされた初期HTMLの上でSPAスタイルのクライアントナビゲーションを実現します。これにより、初回描画やSEOを損なうクライアント専用の空のSPAを配信することなく、スムーズなマルチページアプリの操作感が得られます。
注意点：純粋なクライアントレンダリングSPAは、コンテンツサイトでは避けるべきものです。一方、SSR/SSGとクライアントサイドナビゲーションを組み合わせたフレームワークは、アプリのような操作性を提供しつつ、コンテンツをHTML内に保持します。
しかし、ツールをプロジェクトに合わせる
過剰に修正しないでください。単一の静的ページ、ランディングページ、または小さな埋め込み可能なウィジェットには、Next.jsは不要です。プレーンなHTMLとCSSで十分であり、軽量な選択です。そこで重いフレームワークを採用するのは、それ自体が誤りです。失敗は両方向にあります。一般的な失敗は過小評価（バニラですべてをブラウザレンダリング）ですが、些細なページを過剰設計することも実際にあり得ます。判断基準は次の通りです：ページ数はいくつか、コンテンツはクロール可能で高速である必要があるか、インタラクティブ性はどの程度か。これらを満たす最も軽量なものを選択してください。
このスキルは拡張可能です。実際のアーキテクチャ上の判断で、安定した防御可能な答えが得られた場合は、ルールを追加してください。