Web サイト構築の技術選定ガイド：CTS での採用基準フロー

📖 はじめに

Web サイトの技術選定は、運用が始まってから数年にわたってコストと成果を左右する意思決定だ。にもかかわらず「流行っているから Next.js」「制作会社が WordPress だから」という理由で選ばれることが多く、結果として:

更新頻度が低いサイトに重厚なフレームワークを採用し、保守コストが膨らむ
更新頻度が高い LP に静的サイトジェネレーターを採用し、非エンジニアが触れなくなる
SEO 重視のサイトを SPA で作り、検索流入が伸び悩む

といったミスマッチが発生する。

本記事は、CTS グループが内製化支援の顧客提案・自社サイト構築の両面で使っている技術選定基準を公開する。対象読者は「これから Web サイトを作る担当者」と「顧客に技術提案する営業/エンジニア」。

🎯 5 軸の評価マトリクス

技術選定は 5 つの軸で評価する。各軸について、サイト要件を 高 / 中 / 低 のレベル感で捉える。

軸	低	中	高
更新頻度	月 1 回未満	週 1〜月数回	日次以上
更新者スキル	エンジニアのみ	エンジニア + ディレクター	非エンジニア中心
コスト	月 1 万円未満	月 1〜10 万円	月 10 万円超
SEO 要件	社内向け / クローズド	一般公開 / 検索流入あり	検索流入が主要 KPI
内製度合い	外注中心	内製 + 外注	完全内製

これらの組み合わせで、適切な技術スタックが変わる。

🏗️ 比較対象 5 技術の特徴

Astro（静的サイトジェネレーター）

向くサイト: ドキュメント・ブログ・ナレッジベース・コーポレート・マーケティング LP
強み: Islands Architecture による極小 JS、高速配信、構造化データ一元管理、Markdown 執筆
弱み: 動的機能（認証・ユーザー投稿）に別サービス併用が必要、非エンジニアの更新は Markdown 習得が前提
ホスティング: S3 + CloudFront / Cloudflare Pages / Vercel / Netlify

Next.js（SSR/SSG フルスタックフレームワーク）

向くサイト: EC・SaaS・会員制サイト・動的コンテンツ中心の大規模 Web アプリ
強み: React エコシステム、SSR/SSG/ISR/RSC の柔軟な描画モード、API Routes で BFF 統合
弱み: 学習コスト高、JS バンドルが大きくなりがち、Vercel 以外へのデプロイで最適化が複雑
ホスティング: Vercel（推奨）/ AWS Amplify / セルフホスト

microCMS（ヘッドレス CMS）

向くサイト: 非エンジニアが頻繁に更新する構造化コンテンツ（ニュース・事例・FAQ）
強み: 国産で日本語 UI、スキーマ定義が GUI、API 経由で Astro/Next.js から参照可能
弱み: CMS 単体ではサイトを構築できない（フロントエンドが別途必要）、API 呼び出しコスト
位置付け: Astro や Next.js と併用するのが基本

WordPress（従来型 CMS）

向くサイト: 中小企業のコーポレート・ブログ、プラグイン前提の複雑機能サイト
強み: 圧倒的な普及率、豊富なテーマ・プラグイン、非エンジニアの学習コストが低い
弱み: セキュリティリスク（定期アップデート必須）、パフォーマンス最適化が難しい、ホスティング費用
ホスティング: エックスサーバー / KUSANAGI / Amimoto

STUDIO（ノーコード）

向くサイト: 小規模コーポレート・ポートフォリオ・LP（コーディング知識なしで完結）
強み: ブラウザ上で完結、デザイナーが直接公開可能、サーバー管理不要
弱み: カスタマイズ上限、独自ドメイン運用に月額費用、SEO/構造化データの細かい制御が弱い
位置付け: デザイン主導の小規模サイト、MVP 検証

🔀 判定フロー

判定を単純化したフロー。分岐の分岐先にある角丸矩形が推奨技術。

フロー解説

最初の分岐は「誰が更新するか」。非エンジニアが頻繁に触るなら CMS が必要。
次に「動的機能の有無」。静的で済むなら Astro、動的機能が本質なら Next.js（あるいは CTS で採用実績のある Angular + .NET などの SPA + API 構成）。
CMS が必要な場合、コーディングリソースで分岐。エンジニアがいるならヘッドレス CMS（microCMS）+ Astro の組み合わせが理想。リソースがなければ WordPress か STUDIO。
予算と規模でノーコード vs 従来型 CMS を決定。

🧭 CTS の採用実績

CTS グループでは、自社サイト・顧客案件で以下の実績がある。

サイト種別	採用技術	選定理由
コーポレートサイト (www.cts-g.com)	Astro + Tailwind v4	更新頻度は月数回、SEO 要件高、完全内製 → SSG が最適
ナレッジベース (kb.cts-g.ai)	Astro + Content Collections	Markdown 執筆に特化、記事量が増えても配信コストが線形に増えない
CTS-EC 商品マスタ	Angular + .NET + Gemini API	認可・DB・AI 推論を扱う動的 SaaS、型安全重視
オウンドメディア（顧客案件）	Astro + microCMS	編集部が非エンジニア中心 → ヘッドレス構成で分業

なぜ Astro を第一候補にするか

CTS がコンテンツ中心のサイトで Astro を第一候補にする理由は 4 つ:

内製化支援の思想と合致: Markdown + Git で記事管理 → エンジニア以外も PR で貢献可能
配信コストが最小: S3 + CloudFront の静的ホスティングで月額数百円〜数千円
SEO 標準装備: 構造化データ（JSON-LD）・OGP・sitemap・canonical がレイアウトで一元管理
Claude Code との相性: Claude Code + Claude Design 連携ワークフローのように、AI による実装自動化と親和性が高い

🔒 なぜ AWS (S3 + CloudFront + WAF) で公開するのか

CTS グループの自社サイト（www.cts-g.com / kb.cts-g.ai）は、S3 + CloudFront + WAF + Route 53 + ACM の構成で公開している。

メリット 5 カテゴリ

1. コスト効率

固定費ゼロの従量課金モデル（サーバー常時稼働なし）
月額実績（コーポレートサイト規模）: S3 数十円 + CloudFront 数百円 + WAF 数ドル = 月 500〜1,500 円程度
WordPress + VPS（月 3,000〜10,000 円）と比べて 1/5 〜 1/10 のコスト

2. 高速配信

CloudFront が世界中のエッジロケーションでキャッシュ配信、日本国内で TTFB 数十 ms
Astro の静的出力はキャッシュヒット率が極めて高い（動的コンテンツがほぼない）
HTTP/2・HTTP/3・Brotli 圧縮を標準装備

3. セキュリティ

WAF で OWASP Top 10 / Bot / SQLi / XSS をマネージドルールで防御
S3 は Origin Access Control (OAC) で CloudFront 経由のみに限定 → バケット直接アクセス不可
ACM で HTTPS 証明書が無料・自動更新
AWS Shield Standard で DDoS 対策が標準装備（追加料金なし）

4. 運用負荷の低さ

サーバー OS / ミドルウェアのアップデート不要
WordPress のようなプラグイン・コア更新地獄がない
スケール設計・オートスケール設定不要（S3 は自動スケール）
障害対応はほぼ AWS 側で完結

5. 可用性

S3: 99.999999999%（イレブンナイン）の耐久性
CloudFront: 複数 PoP による冗長化
運用者の手間なしで高可用性を実現

他ホスティングとの比較

コスト・セキュリティ・運用負荷・パフォーマンスの 4 軸で、主要ホスティングを比較。

ホスティング	月額目安	セキュリティ	運用負荷	静的サイト適性	PSI 想定スコア（デスクトップ）
S3 + CloudFront + WAF	500〜1,500 円	WAF・OAC・Shield 標準	低	◎	100 / 100 / 100 / 100（CTS 実績）
Cloudflare Pages	無料〜	WAF・Bot 対策付き	低	◎	95〜100
Vercel	無料〜$20/月〜	SSR 前提の最適化	低	○（Next.js 特化）	90〜100
エックスサーバー (WordPress)	1,000〜3,000 円	プラグイン依存	中	△	60〜85
VPS (自前 WordPress)	500〜5,000 円	自己責任	高	×	40〜80

PageSpeed Insights で 90+ を安定して出したいなら、静的サイト + CDN 構成が近道。

CI/CD との親和性

GitLab CI/CD から aws s3 sync でデプロイは 1 コマンド
CloudFront Invalidation で即時反映（デプロイ後の古いキャッシュを破棄）
npm run build → dist/ を S3 に投入する定型パイプラインが組める

# .gitlab-ci.yml（抜粋）
deploy:
  image: node:20
  script:
    - npm ci
    - npm run build
    - apt-get update && apt-get install -y awscli
    - aws s3 sync dist/ s3://$BUCKET --delete
    - aws cloudfront create-invalidation --distribution-id $DIST_ID --paths "/*"
  only:
    - main

PageSpeed Insights 実績（コーポレートサイト）

CTS コーポレートサイトは Astro + S3 + CloudFront + WAF の構成で、PageSpeed Insights デスクトップ評価で4 カテゴリすべて 100 点を達成している（2026-04-20 計測）。

カテゴリ	スコア	補足
パフォーマンス	100	Core Web Vitals（LCP / INP / CLS）すべて Good 水準
ユーザー補助	100	alt 属性・ARIA ラベル・コントラスト比を担保
おすすめの方法	100	HTTPS 強制・最新 HTTP/2-3・安全な JS 実装
SEO	100	構造化データ（JSON-LD）・canonical・meta description 完備

100 点を出せた理由（構成×実装の両輪）

要素	仕組み
Astro の静的ビルド	事前生成 HTML を配信、サーバー処理時間ゼロで LCP が極小
CloudFront キャッシュ	エッジで HTML/画像/CSS をキャッシュ、TTFB 数十 ms
HTTP/2・HTTP/3・Brotli	CloudFront が標準で有効化、並列・圧縮配信
Islands Architecture	Astro が必要な島だけ JS を配信、総バンドル極小
画像 webp / avif	`/image-optimize` で事前変換、`loading="lazy"` 付与
Noto Sans JP の preload	使用頻度の高いサブセットを Layout.astro で事前読込
JSON-LD・OGP	レイアウトで一元管理、クローラビリティ担保

いつこの構成を避けるべきか

万能ではない。以下の場合は別構成を検討する。

リアルタイム機能が本質（チャット・ライブ配信）→ 専用バックエンド + WebSocket
サーバーサイドレンダリング必須（ユーザーごとの動的ページ）→ Vercel / AWS Amplify
運用チームに AWS スキルが皆無で学習コストを払えない → Cloudflare Pages / Netlify

⚖️ 技術選定のアンチパターン

よくある失敗例。判定フローから外れた選択は後で大きな技術負債になる。

アンチパターン	何が起きるか	対策
更新頻度低の LP に Next.js	SSR 不要なのに Vercel 費用発生、ビルド時間も長い	Astro で静的生成
非エンジニア運用サイトに Astro 単体	Markdown を書けない編集者が更新できなくなる	Astro + microCMS のヘッドレス構成
認証・決済機能を WordPress プラグインで実装	セキュリティホール多発、バージョン互換性地獄	Angular + 認証 SaaS (AWS Cognito)
デザイン重視の LP を WordPress テーマ改造	テーマ更新で壊れる、デザイナーが直接触れない	STUDIO か Astro + デザインシステム

📝 まとめ

Web サイトの技術選定は、更新頻度 × 更新者スキル × コスト × SEO 要件 × 内製度合いの 5 軸で判断する。CTS ではコンテンツ中心の静的サイトは Astro、動的・大規模な SaaS は Angular + .NET、編集部運用のメディアは Astro + microCMS を基本形としている。

「何が流行っているか」ではなく「運用フェーズを通じて誰がどう使うか」から逆算して選ぶことで、数年後の保守コストを最小化できる。