デザインテンプレート vs フルスクラッチ：サイト制作どちらを選ぶ？
統計では、モバイルユーザーの53%がページの読み込みに3秒以上かかると離脱すると報告されています¹。また、スタンフォード大学の研究では、ユーザーはウェブサイトの信頼性をデザイン品質で判断する傾向が強いことが示されました²。つまり、見た目と速さは事業KPIそのものです。ここで多くの現場が直面するのが、デザインテンプレートでスピードを取るか、フルスクラッチで差別化と制御性を取りにいくかという選択です。CTOの視点から、技術負債と機会損失のバランスを数値と設計原則で可視化し、意思決定のブレを減らす考え方を提示します。
テンプレートとフルスクラッチ：定義と選定軸
まず言葉を揃えます。テンプレートとは、既存テーマ（例：一般的なCMSやECのテーマ）、サイトビルダー、UIキットを活用して短期間で体裁と機能を整えるアプローチです。フルスクラッチは、情報設計からデザインシステム、フロントとバックエンドのアーキテクチャまでを要件起点で組み上げる方法です。実務では両者は連続体であり、テンプレートを土台に設計原則（デザイントークン、アクセシビリティ、パフォーマンス予算）を上書きしていく「セミスクラッチ」も現実的な選択肢になります。重要なのは、手段ではなくコア要件に対する制御の度合いです。
選定軸は三つに集約できます。ひとつ目は市場適応速度で、プロダクトの仮説検証やローンチ期限が強い時、テンプレートの価値は大きくなります（例：2〜4週間でのLP量産）。二つ目は差別化必要性で、体験の独自性やブランド一貫性、コンバージョン動線の最適化余地が大きいほど、フルスクラッチの投資対効果が高まります（例：ブランド体験を起点にしたインタラクション設計）。最後が総所有コスト（TCO）で、初期構築費だけでなく、改修速度、運用負荷、依存関係の更新コスト、将来のリプレイス容易性まで含めて比較します。ここで役立つのが、要件の優先度マッピングと、パフォーマンス予算の事前合意です。例えばLCP（主要コンテンツの表示）2.5秒以下³、CLS（レイアウトのずれ）0.1未満、INP（操作から次の描画までの遅延）200ms未満⁴を閾値として、どのアプローチでどれだけの追加工数が発生するかを見積もれば、議論が建設的になります。
「二項対立ではない」ことの意味
テンプレートを採用しても、グローバルナビやフォーム、カードなど頻出UIは設計原則で再定義できます。逆にフルスクラッチでも、アイコンセットやグリッドなど再発明の必要がない部位は既存資産を使うべきです。実務で効くのは、ビジネス価値への寄与が大きい領域に開発リソースを集中させるメリハリです。テンプレート導入を選ぶ場合でも、最初にデザイントークン（色、タイポ、スペーシング）を分離し、ビルダーに閉じない形で管理すれば、将来の移行コストは桁違いに下がります。
選定軸を合意形成に使う
合意形成では、KGI/KPIと各要件の結びつきを文章で明文化することが有効です。例えば、広告投資の効率改善をKGIとするなら、ランディングのテンプレート最適化でまずCPAを下げ、確度が見えた段階でフルスクラッチへ移行してCVRを取り切るという段階戦略が合理的です。逆に、SaaSのコア製品サイトや採用サイトのように、ブランドの独自性が選考や成約率に直結する場合は、ローンチ期からフルスクラッチで体験を作り込む選択がリスクを下げます。
技術面の核：速度、拡張性、セキュリティ
速度は体験の土台です。テンプレートは多様なユースケースを想定するため、CSSとJSが肥大化しがちです。一般に、ビルダー系テンプレートはアイドル時にも複数のイベントリスナーやポリフィルが常駐する設計が見られ、INPやメインスレッドの占有が増える傾向があります。一方フルスクラッチは、コード分割、クリティカルCSS、ネイティブ機能の優先使用、画像パイプラインの自動化など、原則を最初から仕込めます。どちらを選ぶにせよ、パフォーマンス予算を定め、計測（例：LighthouseやWebPageTest）をデプロイごとに行い、予算を超えた変更をリジェクトできる仕組みを用意することが肝心です。
Core Web Vitalsと設計上のトレードオフ
LCP2.5秒、CLS0.1、INP200msの基準を守るには、テンプレート側では不要コンポーネントのパージ、アニメーションやビューアの初期化遅延（遅延初期化）、プラグインの統廃合が効きます。フルスクラッチでは、Fold上のHeroをプリロードし、Webフォントはdisplay:swapでフォールバックを許容し、インタラクションはWeb AnimationsやCSSトランジションでGPUフレンドリーに仕上げるのが効果的です。特にINPは「遅延初期化」の設計に左右されます⁴。イベントハンドラは初回インタラクションまで登録を遅らせ、同時にSSR（サーバーサイドレンダリング）や部分的なハイドレーションを採用すると、初期負荷と体験の両立が見えてきます。
拡張性：ロックインとアーキテクチャ
テンプレートはプラグイン・テーマの生態系に依存します。機能追加や国際化、BFF（Backend for Frontend）の導入などで境界が露呈すると、ロックインの解消が難しくなります。これに対しフルスクラッチは、ヘッドレスCMS、デザインシステム、APIファーストの構えをとりやすく、BFFやエッジキャッシュ、ISR（Incremental Static Regeneration）のような配信戦略を段階的に取り込めます。鍵は設計の分離で、コンテンツ、プレゼンテーション、ビヘイビアの境界を曖昧にしないことです。テンプレートでも、ヘッドレス化やコンポーネント指向の導入が進んだものを選べば、将来のモバイルアプリや他チャネルへの展開が現実的になります。
セキュリティと運用：依存関係の面積を管理する
攻撃面積は依存関係の数と更新遅延に比例します。テンプレートは導入直後の安全性は高い一方で、プラグインの長期メンテ不在や互換性崩壊のリスクがあります。フルスクラッチは選定自由度が高い反面、更新責任も自分たちにあります。どちらでも通用する原則は、SBOM（ソフトウェア部品表）の生成⁵、Dependabot等での自動更新、E2Eとビジュアルリグレッションの常設、そして脆弱性対応のSLAをあらかじめ契約や運用規程に埋め込むことです。特に支払い・会員・個人情報を扱う場合は、第三者のコンポーネントに委ねる領域と内製コアの境界を明確に定義し、監査可能性を確保します。
コスト、期間、ROI：数字で見る現実
初期構築の期間から見ていきます。マーケティングの静的ページ中心で要件がシンプルなら、テンプレートは数週間でのローンチが現実的です。デザインのカスタムとコンテンツ移行の手当てをしても、1ヶ月前後で広告投下に合わせられるケースが多いでしょう。これに対し、フルスクラッチで情報設計、デザインシステム、アクセシビリティ、パフォーマンス最適化まで含めると、8〜16週間のスパンが目安になります。もちろん範囲とチームの成熟度で上下しますが、プロダクトの性格によるオーダーの違いは小さくありません。
運用コストと変更速度の相関
運用局面では、テンプレートはWYSIWYGでの高速編集が強みになります。キャンペーンLPの量産やABテストは、ノーコードで回せるほど単価が下がります。ただし、カスタムのデータ連携や複雑な権限制御、アクセシビリティ要件の厳格な適用になると、テンプレート側での回避策にコストが乗りがちです。フルスクラッチは初期投資が重い代わりに、コンポーネントとトークンを整備しておけば、大規模改修や多言語展開での変更の可逆性が効きます。デザインシステムのバージョニングとStorybook、スナップショットテストが回っている状態なら、破壊的変更のリスクは大きく減ります。
ROIを数式で可視化する
意思決定の透明性を高めるには、ROIを共通言語にするのが早道です。単純化すれば、ROI＝（追加売上−投資）÷投資で捉えられます。追加売上は、CVR向上や直帰率低下、検索流入増から推定します。例えば、月間トラフィック50万、平均注文額8,000円、現在のCVRが1.5%のECを想定します。フルスクラッチで体験を作り込み、CVRが0.3ポイント改善して1.8%になれば、月間で約1,500件の追加成約、売上にして約1,200万円の上振れが見込めます。仮に開発に3,000万円を投じるなら、数ヶ月での回収が期待できる計算です（粗利や運用コストを別途考慮する必要があります）。逆に、キャンペーン中心の獲得型ビジネスでは、テンプレートでの素早い投入により広告の学習を早めるほうが、初期ROIは高くなることが多い。重要なのは、どのKPIを何ポイント動かす仮説かを先に数字で置くことです。
ケース別ガイド：こういう時はこう選ぶ
期限が明確で、仮説検証が目的のローンチでは、テンプレートが堅実です。まずは期待CVRの下限を確認し、運用で勝てるかを短期で見極めます。この段階での最適化は、画像とフォントの最小化、不要スクリプトの停止、折りたたみ下の遅延読み込み（レイジーロード）といった、テンプレートでも実装できる対策が中心になります。ここで原資を作り、二回り目の大規模改修で体験の差別化に投資するほうが、資金繰りと学習の両面で合理的です。
一方、コアプロダクトのサイトや採用サイト、投資家向け情報のように、メッセージの正確さとブランドの独自性が成果に直結する場合は、フルスクラッチが適します。情報設計から一貫した文脈を作り、アクセシビリティを最初から満たし、パフォーマンスを設計の制約として扱う態度が、長期の信頼と可搬性を生みます。多言語・多ドメイン・地域法規への準拠がある場合も、設計上の自由度と監査可能性を優先すべきです。
その中間の現実的な選択として、テンプレートでローンチしながら、裏側ではデザインシステムとヘッドレス基盤を育てる方法があります。最初にブランドのトークンを定義し、テンプレートへ適用して短期の成果を取りつつ、並行してコンポーネントライブラリを整備する。一定の学習が溜まった段階で、テンプレートのページを新アーキテクチャへ順次載せ替える。ページ単位での漸進的移行は、リスクとキャッシュフローを平準化し、チームのスキル移転も自然に進みます。移行の手順や気づきをナレッジ化しておけば、二回目以降の移行は短期化します。
まとめ：迷いを減らすのは、数字と原則
テンプレートか、フルスクラッチか。唯一の正解はありませんが、正しいプロセスはあります。まず、KGIとKPIに結びつく仮説を数字で置き、LCP・CLS・INPの予算とアクセシビリティ要件を合意します。次に、初期費用と運用費を分けたTCOを試算し、テンプレート案とフルスクラッチ案を同じ前提で比較します。最後に、移行シナリオを用意し、テンプレートから設計駆動へ、あるいはその逆への退路を確保します。あなたのサイトが今、何を一番速く学ぶべきなのか。その問いへの答えが、選ぶべき手段を自然に指し示します。今日できる一歩として、要件の重みづけ表とパフォーマンス予算を一枚にまとめ、関係者とすり合わせてみませんか。