技術選定の考え方 — WordPress vs Next.js vs ノーコード — 一般社団法人社会構想デザイン機構

技術選定で失敗する構造的原因

Web制作プロジェクトの技術選定において、最もよくある失敗パターンが「制作者が慣れているから」という理由で決定してしまうことだ。受託者側の習熟度は重要な要素だが、それを最優先にすると発注者のビジネス要件と乖離したシステムが生まれる。

もう一つの失敗パターンは「最新技術を採用することで先進性を示したい」という動機による選定だ。Next.jsやHeadless CMSといった言葉に魅力を感じた発注者が、運用体制の整備なしに高機能なシステムを発注し、更新すら満足にできない状態になるケースは珍しくない。

技術選定が失敗する根本原因は、「どの技術が優れているか」という問いから始めることにある。正しい問いは「このプロジェクトで誰が何をするのか」だ。具体的には以下の3点を起点に考える必要がある。

誰が更新・運用するのか：エンジニアか、非技術者の担当者か
どの程度の頻度で更新するのか：毎日更新するメディアか、年に数回のコーポレートサイトか
将来どのように拡張する可能性があるのか：EC機能追加、多言語展開、外部API連携など

これらを明確にせずに技術を選ぶことは、住む人を決めずに間取りを設計するのと同じだ。

WordPress — 最も普及した選択肢の実態

世界のWebサイトの約43%がWordPressで構築されている。この圧倒的なシェアの背景には、非エンジニアでも扱えるUIと、豊富なプラグインエコシステムがある。

WordPressが適しているシーン

コーポレートサイト、ブログ・メディア、採用サイト、中小規模のECサイト（WooCommerce）は、WordPressの得意領域だ。特に「更新担当者がエンジニアでない」案件においては、管理画面の使いやすさが生産性に直結する。プラグインを活用すれば、フォーム、SEO設定、多言語対応、会員機能など、多くの要件をコードなしで実装できる。

WordPressが問題になるシーン

一方で、以下のようなシーンではWordPressの選択が後々の問題になりやすい。

プラグイン依存の肥大化：機能追加のたびにプラグインを積み重ねると、更新の競合やセキュリティリスクが増大する。プラグイン数が30を超えるサイトでは、メンテナンスコストが初期構築費用を超えるケースがある。

パフォーマンスの限界：デフォルト状態のWordPressはページ表示速度が遅く、適切なキャッシュ設定とCDN活用なしにはCore Web Vitalsの基準を満たしにくい。大量アクセス時のサーバー負荷対策も別途必要になる。

高度なカスタマイズの難しさ：独自の予約システム、複雑な検索機能、リアルタイムデータ連携などを実装しようとすると、WordPressの構造が制約になることが多い。「WordPressでできるか」より「WordPressらしい実装で要件を満たせるか」を問うべきだ。

技術的な観点から言えば、WordPressはPHP製のモノリシックなCMSであり、フロントエンドとバックエンドが密結合している。この設計は更新のしやすさをもたらす一方で、パフォーマンス最適化や外部システムとの統合において制約となる。

Next.js — 高い自由度と高いコストのトレードオフ

Next.jsはReactをベースにしたJavaScriptフレームワークで、サーバーサイドレンダリング（SSR）、静的サイト生成（SSG）、クライアントサイドレンダリング（CSR）を用途に応じて使い分けられる。Vercelが開発・メンテナンスを行っており、デプロイとホスティングのエコシステムも整っている。

Next.jsが適しているシーン

Next.jsが真価を発揮するのは、以下のような案件だ。

高いパフォーマンス要件がある場合：静的生成による超高速ページ表示が必要なメディアサイト、大量同時アクセスが見込まれるサービス
動的なUI・UXが必要な場合：SPAライクな操作感、リアルタイムデータ表示、複雑なインタラクション
外部APIやデータベースとの密な連携：ECサイトのリアルタイム在庫管理、外部SaaSとのデータ統合
開発チームにReact経験者がいる場合：フロントエンドエンジニアが主体の開発体制

Next.jsが過剰投資になるシーン

問題は、「モダンなWebサイト = Next.js」という短絡的な発想で採用されるケースだ。年に数回しか更新しない小規模なコーポレートサイトや、非エンジニアが日常的に更新するメディアサイトにNext.jsを採用することは、維持コストと運用難易度を不当に高める。

コンテンツ更新のたびに開発者へ依頼が必要になる状況は、WordPressであれば担当者が5分でできる作業が、Next.jsでは数日のリードタイムを要する開発作業になり得ることを意味する。

Next.jsはCMS機能を持たないため、コンテンツ管理にはHeadless CMSを別途組み合わせる必要がある。ContentfulやSanityといったサービスを活用することでコンテンツ更新の問題を解決できるが、システム全体の複雑度とコストは増大する。初期構築費用に加え、ランニングコストと技術的負債の管理も考慮した総コスト計算が不可欠だ。

ノーコード — スピードの代償と活用できる領域

ノーコードツールとは、プログラミングなしでWebサイトやアプリケーションを構築できるサービスの総称だ。代表的なものとして、Wix、Webflow、STUDIOなどが挙げられる。

ノーコードが強みを発揮する領域

ノーコードツールの最大のメリットはスピードだ。アイデアを数日でプロトタイプ化し、市場の反応を見ながら改善するリーン開発アプローチとの相性が良い。特に以下のユースケースで有効だ。

ランディングページ・キャンペーンサイト：短期間での立ち上げと柔軟な修正
MVP（最小限実行可能製品）の検証：本格開発前の仮説検証
非エンジニアによる自律的な更新：マーケティング担当者が独立してコンテンツをコントロール
低予算での小規模サイト構築：初期コストを抑えたスモールスタート

ノーコードの限界と落とし穴

一方で、ノーコードには無視できない制約がある。

カスタマイズの壁：ツールが提供する機能の範囲内でしか実装できないため、独自の複雑な機能要件に対応できない場合がある。「あと少しだけカスタマイズしたい」という要求が積み重なるとフラストレーションの原因になる。

ベンダーロック：サービスの仕様変更、価格改定、サービス終了のリスクを常に抱える。サイトのデータをエクスポートしても、別プラットフォームへの完全移行は多くの場合困難だ。

スケールアウト時の限界：アクセス数が増えたとき、機能拡張が必要になったとき、多言語展開が必要になったときに、ノーコードツールの上限に達してフルリビルドを余儀なくされるケースがある。初期に節約したコストを大きく超える移行費用が発生する可能性がある。

SEOの制約：一部のノーコードツールではHTML構造のカスタマイズに制限があり、Googleが推奨する技術的SEO要件を完全に満たせないケースがある。

三択を超えた選定フレームワーク：4つの問い

WordPress・Next.js・ノーコードのどれを選ぶかより重要なのは、「何を基準に選ぶか」だ。以下の4つの問いに答えることで、選定の軸が明確になる。

問い1：「誰が、何年間、どのように運用するのか」

更新担当者のスキルセットと、想定する運用期間を先に定義する。非エンジニアが更新する場合は管理UIの使いやすさが最優先事項になり、Next.jsの選択肢は限定される。一方、エンジニアチームが運用する場合はWordPressの制約が逆に足かせになることもある。

問い2：「3年後の拡張要件は何か」

現在の要件だけで技術を選ぶと、1〜2年後のスケールアップ時にフルリビルドを強いられる。EC機能の追加、会員機能、外部API連携、多言語展開など、将来の拡張シナリオを3つ程度列挙し、それぞれの技術スタックで実現可能かを検証する。

問い3：「月次の運用コストの上限はどこか」

初期構築費用だけでなく、ホスティング費用、セキュリティ対応、定期メンテナンス、機能追加の開発費用を合算した総所有コスト（TCO）で評価する。WordPress+共有サーバーは低コストだが、プラグイン管理やセキュリティ対応の人件費は見えにくい。Next.js+Vercelは初期費用が高いが、インフラ管理のコストが低い。

問い4：「この技術の保守を誰に頼めるか」

制作者が変わったときに別の開発者が引き継げるか。WordPressは開発者プールが広く引き継ぎやすいが、独自カスタマイズが深いサイトは例外だ。独自フレームワークや特殊な実装は、制作者への依存度を高める。市場での開発者確保しやすさは、長期運用において重要な判断基準だ。

発注者にとって、技術選定の妥当性を判断する最も簡単な方法は、制作者に「なぜこの技術を選んだのか」を説明させることだ。「慣れているから」「モダンだから」という理由しか出てこない場合、選定プロセスが不十分である可能性が高い。適切な選定であれば、プロジェクト固有の要件に基づく具体的な理由を挙げられるはずだ。

技術の優劣を語ることは簡単だが、それよりも「このプロジェクトにとって最も適切か」を判断することの方がはるかに難しく、かつ重要だ。その判断軸を持てた時点で、発注者は制作者と対等なパートナーとして技術議論に参加できるようになる。