AIアシスタントでページを生成するか、デザインツールからHTMLを書き出せば、作業の大部分は完了します。それを保守しやすいElementorページに仕上げるのは、短く再現可能な手順です。
ステップ1 — 最初に画像を整理する
これは多くの人が省略するステップであり、最も多くの手戻りを引き起こします。AIは実際の写真をHTMLに埋め込むことができず、デザインツールの書き出しはローカルパスやデータURLを使用することが多く、どちらもメディアライブラリの添付ファイルにはなりません。
良い選択肢は2つあります。最初に画像をメディアライブラリへアップロードして、HTMLで実際のURLを参照する方法と、空のプレースホルダーを受け入れて後からElementorで埋める方法です。プレースホルダー方式を選ぶ場合は、各画像に意味のあるalt属性を必ず付けてください。そのテキストはスロットのキャプションとして保持されるため、どの画像がどこに入るのかがわかります。
ステップ2 — 変換しやすいマークアップを依頼する
モデルにプロンプトを入力する場合は、必要なものを伝えてください。セマンティックタグ、セクションごとに1つのラッパーを持つ浅いDOM、すべてのCSSを1つのstyleブロックにまとめること、インラインSVGではなくFont Awesomeのアイコンクラスを使用すること、外部スクリプトやフォントを使用しないこと。これらのわずかな制約は、後から行うどんな作業よりも結果に大きな影響を与えます。
ステップ3 — 適切なオプションで変換する
- ネイティブコンポーネントモード。1つのHTMLブロックではなく、編集可能なウィジェットを取得できます。
- アイコン: Elementorアイコンライブラリに一致させる。アイコンが本物の交換可能なアイコンになります。
- 色とフォント: ブランドサイトに載せる場合はサイトの値、デザインを再現する場合は元の値を使用します。
- 画像: 実際のURLが既にある場合を除き、空のプレースホルダーを使用します。
ステップ4 — エクスポート前に構造を確認する
構造マップを開きます。コンポーネント数、最大の入れ子の深さ、信頼度の内訳を確認してください。赤い行はHTMLとして保持されているため、確認する価値があります。深さが大きい場合は、ツリーのより深い場所にコピー起点を設定するか、ソースを簡素化してもう一度変換してください。入力の修正は、出力の修復よりもほとんどの場合高速です。
ステップ5 — 貼り付けて仕上げる
Elementorに貼り付け、標準の仕上げ作業を行います。ボタンのリンクを再設定し、ホバー状態を設定し、フォームやメニューを接続し、プレースホルダー画像をアップロードし、デスクトップ、タブレット、モバイルを順に確認します。
ステップ6 — 再利用可能なパーツを保存する
再度使用するもの（価格表の行、機能グリッド、お客様の声ブロックなど）は、すぐにテンプレートライブラリへ保存してください。いくつかのプロジェクトを経ると、これがコンポーネントライブラリになり、次の構築がはるかに速くなります。これは、変換した単一のページよりも価値があります。
プロンプトで最も重要な4つの指示
結果の大部分はステップ2で決まるため、どの指示が実際に結果を変えるのかを具体的にしておく価値があります。影響が大きい順におおよそ次のとおりです。
- 「画像をBase64データURLとして埋め込まないでください。」 何も指定しない場合、自己完結型ページを依頼されたモデルはすべての画像をインライン化し、12枚の画像があるページは0.5メガバイトを超えて膨れ上がります。これらはメディアライブラリの添付ファイルにはならないため、すべて空のスロットとして届きます。代わりに、実際のホストURLか単純なプレースホルダーパスを要求してください。
- 「アイコンにはインラインSVGではなくFont Awesomeのクラスを使用してください。」 Font Awesomeのクラス名は、そのままElementorのアイコンライブラリに本物の交換可能なアイコンとして対応付けられます。手描きのインラインSVGはそのコントロールに一切入ることができず、生のHTMLのまま残ります。この1行が、編集可能なアイコンと、赤いHTMLブロックだらけのページを分ける違いです。
- 「DOMをフラットに保ち、セクションごとに1つのラッパーにし、冗長な入れ子を作らないでください。」 コンバーターはマークアップを反映するため、入力の入れ子は出力の入れ子になります。モデルはデフォルトで深く入れ子になったラッパーdivを生成しますが、これはほとんどのトレーニングデータがそのような形をしているためです。
- 「セマンティックタグを使用してください。」 実際の
<h1>から<h3>、<p>、<button>、<ul>。セマンティックタグはネイティブウィジェットに対応付けられます。スタイル付きdivだけで構築されたページでは、コンバーターが利用できる材料がはるかに少なくなります。
4つすべてを含む既製のプロンプトは、AIプロンプトページにあります。その中には、画像優先ワークフロー専用に書かれたものも含まれています。
デザインツールのエクスポートがAIの出力と異なる動作をする理由
2つのソースは正反対の方向で失敗します。どちらを扱っているのかを知ることで、どこを確認すべきかがわかります。
AI生成のHTMLは通常、セマンティクスが適切です。ドキュメントでトレーニングされているため、実際の見出しや段落を使用します。弱点は、インライン化されたBase64画像、インラインSVGアイコン、レイアウトに必要な以上のラッパーdivです。これら3つはすべて、プロンプトを変更して再生成することで修正でき、数秒しかかかりません。
デザインツールのエクスポートはその逆です。画像やアセットは通常適切に参照されていますが、マークアップは絶対配置されたdivで、生成されたクラス名を持ち、セマンティック構造がまったくない傾向があります。これはツールがドキュメントではなくキャンバスを記述しているためです。多くの場合、どこにも見出し要素がないため、Headingウィジェットになれるものがありません。
この2番目のケースは、実際には変換の問題ではありません。絶対配置されたキャンバス出力はどのElementorレイアウトにも対応せず、表現されたことのないドキュメント構造を推測できるツールはありません。エクスポートがそのように見える場合は、正直な答えは変換するのではなく構造を再構築することです。あるいは、デザインツールに戻って、セマンティックなフローレイアウト版をエクスポートできる場合はそれを行ってください。
修復するよりも再生成する
このパイプラインを高速にする習慣は、ソースを使い捨てとして扱うことです。構造マップが深さ8と6つの赤いHTMLブロックを示している場合、Elementorを開いて修正を始めないでください。プロンプトに2行追加し、再生成して、もう一度変換します。このループには約1分かかります。
同じ問題をElementor内で修復するには1時間かかり、次のページでも繰り返す必要があります。プロンプトを修正すれば、その後生成するすべてのページが修正されます。これこそが、このワークフローを設定する価値がある理由です。