AIでWebサイトは簡単に作れるようになった。次に問われるのは「どう公開し、どう運用するか」
AIの進化によって、Webサイトやアプリを作るハードルは急速に下がった。
以前なら制作会社へ依頼し、数週間から数か月かけていたWebサイトも、今ではAIと会話しながら短期間で形にできる。
文章、画像、デザイン、HTML、プログラムまでAIが作ってくれる。非エンジニアでも、自社サイト、ランディングページ、診断ツール、業務アプリ、ECサイトを作れる時代になった。
しかし、実際に複数のサイトやアプリを作るようになると、別の問題が見えてくる。
作ることよりも、どこに公開し、誰が更新し、どう運用管理するかの方が重要になる。
作れるようになるほど、管理するものが増える
AIを使えば、思いついた企画をすぐ形にできる。その一方で、作るたびに管理対象も増えていく。
- ドメインはどこで管理するのか
- サーバーやデプロイ先はどこか
- 誰が記事や情報を更新するのか
- 公開前の確認はどう行うのか
- 間違えたときに元へ戻せるか
- 画像や文章の権利関係を確認できているか
- アクセス状況やコンバージョンを計測できるか
- 数年後も同じ仕組みを使い続けられるか
サイトを1つ作るだけなら、あまり問題にならない。
しかし、自社サイト、商品サイト、オウンドメディア、診断ツール、EC、業務アプリと増えていくと、公開方法がバラバラなこと自体が運用コストになる。
AI時代には、制作コストが下がる一方で「運用負債」が増えやすくなる。
Webサイトの主な公開方法
現在のWebサイト公開方法は、大きく分けると次のように整理できる。
| 公開方法 | 向いているもの | 強み | 注意点 |
|---|---|---|---|
| WordPress | 企業サイト、記事メディア、サービスサイト | 記事管理、カテゴリー、権限、履歴、SEO運用 | 更新、セキュリティ、バックアップが必要 |
| スクラッチ開発＋Vercelなど | アプリ、診断ツール、独自UI、AIサービス | 自由度、表示速度、機能開発 | 更新・管理画面も自分で設計する必要がある |
| note・SNSなど | 情報発信、認知獲得、反応テスト | すぐ公開でき、読者と接点を持ちやすい | デザイン、導線、データ、プラットフォーム依存 |
| MakeShop・Shopifyなど | 商品販売、受注・決済・在庫管理 | 販売機能がまとまっている | 独自機能やコンテンツ設計に制約がある |
| 独自EC＋Stripe | 独自の販売体験や会員サービス | 販売フローを自由に設計できる | 保守、決済周辺、法令対応の責任が大きい |
どれか一つが、すべてにおいて優れているわけではない。重要なのは、作るものの目的に合わせて公開基盤を選ぶことだ。
情報を蓄積するなら、WordPressは依然として強い
企業情報、サービス説明、導入事例、専門記事などを継続的に蓄積する場合、WordPressは今でも非常に合理的だと思う。
WordPressには、記事、固定ページ、カテゴリー、タグ、画像、ユーザー権限など、メディア運用に必要な仕組みが最初から用意されている。
編集者や投稿者などの権限を分けられ、誰がどこまで操作できるかを管理できる。詳しくはWordPress公式の「Roles and Capabilities」に整理されている。
記事を更新した履歴も保存され、変更内容の比較や過去版への復元ができる。リビジョン機能は、複数人やAIがコンテンツを更新する時代に、むしろ重要性が増す。
さらにWordPressには、記事、画像、カテゴリー、ユーザーなどを外部から扱えるREST APIがある。
今回JPWで行ったように、CodexとWPVibeを組み合わせれば、記事作成だけでなく、画像登録、カテゴリー設定、トップページの導線改善、テーマ修正、プレビュー、公開確認までAIと会話しながら進められる。
WordPressは古い仕組みだから残っているのではない。
長年蓄積されてきた「公開・整理・権限・履歴・復元」の仕組みが、AI運用と相性が良い。
ここに、AI時代にWordPressが再評価される理由がある。
独自の機能を作るなら、スクラッチ開発が強い
一方、すべてをWordPressで作る必要はない。
AI診断、会員向けツール、業務アプリ、リアルタイム処理、複雑な検索機能などは、VercelやSupabaseを使ったスクラッチ開発の方が適している場合が多い。
JPWでも、ノートアプリ「noxt」のようなサービスはWordPressではなく、独自アプリとして開発している。
スクラッチ開発の強みは、体験を自由に設計できることだ。画面、データベース、AI機能、認証、決済などを、サービスに合わせて組み立てられる。
VercelではGitリポジトリへの変更を起点にデプロイする運用を構築できるため、コードを中心に管理するサービスと相性が良い。詳しくはVercel公式のGit連携ドキュメントで確認できる。
ただし、自由度が高い分、記事投稿、カテゴリー、編集権限、プレビュー、履歴、検索、バックアップなども自分たちで設計しなければならない。
サイトを作るのは簡単でも、CMSまで含めて作ると一気に複雑になる。
noteやSNSは「入口」として使う
noteやSNSは、素早く情報を公開し、反応を確かめる場所として優れている。
アカウントを作ればすぐ発信でき、既存ユーザーとの接点も持てる。note自身も、記事制作や発信方法に関する活用情報を提供している。
一方で、プラットフォーム上の発信は、自社で完全に管理できる資産ではない。表示方法、推薦アルゴリズム、外部リンクの扱い、利用規約などは、運営会社の方針によって変わる可能性がある。
そのため、noteやSNSだけで完結させるのではなく、外部プラットフォームで知ってもらい、自社サイトで詳しく理解してもらう。
反応を試す場所としてnoteやSNSを使い、長期的に残したい情報はWordPressへ蓄積する。この役割分担が良いと考えている。
ECは「売る仕組み」を中心に選ぶ
ECサイトについては、情報発信以上に運用の現実を見る必要がある。
商品登録、在庫、受注、決済、発送、キャンセル、顧客対応まで含めると、単にきれいな商品ページを作るだけでは足りない。
標準的な商品販売なら、MakeShop、Shopify、楽天市場、Amazonなど、販売運用の仕組みがすでに整っているサービスを活用した方が合理的な場合が多い。
一方、独自の診断結果に合わせて商品を提案する、特殊な会員制度を組み込む、既存ECでは実現できない購入体験を作るといった場合は、スクラッチECとStripeの組み合わせが選択肢になる。
また、WordPressの記事から商品やサービスへ誘導し、決済部分だけを外部サービスへ接続する方法もある。
大切なのは「最新技術で作ったか」ではない。日々の販売業務を、無理なく続けられるか。ここを基準に選ぶ必要がある。
私たちは、目的によって使い分けている
私たちの事業でも、公開方法は一つに統一していない。
DropStoneのホールセールサイト、CBNに特化した情報サイト、GreeusAI血液検査キットなど、検索から継続的に顧客と接点を作るものでは、WordPressやSEOを基盤としている。
企業としての知見や実践記録は、JPW公式サイトのINSIGHTへ蓄積する。
一方、noxtのような独自サービスやAI診断ツールは、VercelやSupabaseを活用したスクラッチ開発が向いている。
ECについても、完全スクラッチEC＋Stripe、WordPress＋決済、MakeShop、Amazonや楽天などのモールを、目的に応じて使い分けている。
大切なのは、すべてを一つの技術で解決しようとしないことだ。
AI時代の公開基盤は、4つの視点で選ぶ
1．誰が更新するのか
経営者、広報担当者、エンジニア、外部制作会社、AIのうち、誰が日常的に更新するのか。
2．何を蓄積するのか
記事、企業情報、商品、顧客データ、診断結果、業務記録など、蓄積する情報によって必要な基盤は変わる。
3．何を成果とするのか
検索表示、AIによる引用、問い合わせ、購入、会員登録、業務効率化など、目的を明確にする。
4．問題が起きたときに戻せるか
バックアップ、変更履歴、権限管理、公開前プレビュー、障害時の復旧方法まで設計する。
この4つが決まっていないままAIで大量にサイトを作ると、公開後に管理できなくなる。
作る技術より、育てる仕組みが重要になる
AIによって、Webサイトを作ること自体は今後さらに簡単になる。
だからこそ差がつくのは、制作技術ではない。
- どこに公開するか
- 誰が責任を持つか
- どの情報を蓄積するか
- どう更新し続けるか
- どう検索やAIから発見されるか
- どう商品購入や問い合わせにつなげるか
これらを一つの運用として設計できるかどうかだ。
WordPressは、企業情報やコンテンツを蓄積する基盤として使う。スクラッチ開発は、独自の機能や体験を作るために使う。noteやSNSは、新しい読者と出会うために使う。ECサービスは、商品を安定して販売するために使う。
AI時代には、一つの公開方法を選ぶのではなく、それぞれの強みを組み合わせることが重要になる。
簡単に作れる時代だからこそ、「どう公開し、どう育てるか」が企業の差になる。
関連記事
その仕事、もっと良くできるかも。
AIで変えたい業務を、ひとつ教えてください。
初回30分のオンライン相談で、一緒に整理します。