AI + ウェブ開発に関するほとんどのチュートリアルは、同じパターンを示します。LLMにプロンプトを与え、HTMLを返してどこかに貼り付ける。これはプロトタイプには機能しますが、本番環境では壊れます。
私は、テキスト説明からWordPressの完全なサイトを生成するシステムを構築してきました。初期段階で、当然の選択としてAIにHTMLを生成させることにしました。それがひどいアイデアだと気づくまで約2週間かかりました。
ここで学んだことと、代わりに最終的に採用したアーキテクチャを紹介します。
HTMLを生成することが罠である理由
LLMにウェブページの生成を依頼すると、マークアップが出力されます。こんな感じです:
<div class="hero-section" style="background: #1a1a2e; padding: 80px 40px;">
<h1 style="color: white; font-size: 48px;">Artisan Gelato</h1>
<p style="color: #ccc;">Handcrafted flavors since 1987</p>
<a href="/menu" class="btn" style="background: #e63946;">View Menu</a>
</div>見た感じは大丈夫そうです。では、次のことを試してください。
視覚エディターで編集してみる。 Elementor、Gutenberg、または任意のページビルダーは、インラインスタイルと非標準のクラス名に苦しむでしょう。 ユーザーは、エディターのデータモデルで作成されていないものをドラッグ＆ドロップで編集できません。
テーマを更新する。 テーマが更新されると、生成したHTMLは時間とともに凍結します。 フォントが変わり、間隔が変わり、色が変わる — AIが生成したセクション以外はすべて。
レスポンシブ対応にする。 AIが生成したデスクトップのマークアップ。モバイル？ タブレット？ AIの任意のクラス名を参照するメディアクエリが必要になります。 それを維持するのは大変でしょう。
一貫性を保つ。 5ページを5つの別々のプロンプトで生成します。 各ページは、わずかに異なるクラス名、異なる見出しの階層、異なる間隔の値を使用します。 デザインシステムはなく、5つの独立したHTMLの塊ができるだけです。
HTML生成は一度限りのデモには機能します。 本番サイトで、非技術的なユーザーが維持・編集・更新する必要がある場合には機能しません。
代替案: データを生成し、マークアップを生成しない
AIにHTMLを生成させる代わりに、構造化JSONスキーマを生成させ、それをWordPressの構成要素に対応させます。
