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 — 再利用できるパーツを蓄える
料金表の行、機能紹介のグリッド、お客様の声ブロックなど、また使いそうなものはすぐにテンプレートライブラリへ保存してください。いくつかのプロジェクトを重ねるうちにこれがコンポーネントライブラリになり、次の制作がずっと速くなります。その価値は、変換した1ページ分よりもはるかに大きいものです。
プロンプトで特に効く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 プロンプトページにあります。画像を先に用意するワークフロー専用に書かれたものもあります。
ソースごとに実際に得られるもの
「デザインツール」を抽象的に語るより、具体的な名前を挙げるほうが役に立ちます。ソースによって、うまくいかない形が異なり、しかもそれは予測できるからです。
- ChatGPT、ClaudeなどのアシスタントはHTMLを直接出力します。最も扱いやすいソースで、前述のプロンプトのルールもこれを想定して書いています。
- AIアプリビルダー（Lovable、v0、Bolt）。これらが出力するのはReactプロジェクトであり、JSXのソースはHTMLではありません。コンポーネントのコードを貼り付けるのではなく、ビルダーのライブプレビューをブラウザで開き、レンダリングされたページのHTMLをそこから取得してください。レンダリング後のページなら、ほかのページと同じように変換できます。
- Canva。CanvaのウェブサイトはCanvaがホストしており、HTMLとして書き出すことはできません。また埋め込みスニペットはiframeですが、コンバーターは意図的にiframeを動作するフレームとしては引き継ぎません（方針として、残るのはYouTubeとVimeoのiframeだけです）。CanvaからElementorへ直接移す方法はありません。現実的なのは、Canvaのデザインを見た目の参考として扱い、AIアシスタントでそこからHTMLを生成する方法です。
- Figma。標準のHTML書き出し機能はありませんが、HTML書き出しプラグインがあり、その品質はまちまちです。フローレイアウト（flexやgrid）で出力するものはうまく変換できます。絶対配置のdivで出力するものは、後述するキャンバスの問題に突き当たります。
デザインツールの書き出しがAIの出力と違う挙動をする理由
この2つのソースは正反対の方向でつまずきます。どちらを扱っているのかがわかれば、どこを確認すべきかもわかります。
AI生成HTMLは、たいていセマンティクスの面ではまずまずです。ドキュメントで学習しているため、本物の見出しや段落を使います。弱点は、インライン化されたBase64画像、インラインSVGのアイコン、そしてレイアウトに必要な数より多いラッパーdivです。3つともプロンプトを変えて再生成すれば直せて、かかるのは数秒です。
デザインツールの書き出しはその逆です。画像やアセットはたいてい適切に参照されていますが、マークアップは自動生成されたクラス名を持つ絶対配置のdivばかりで、セマンティックな構造がまったくないことがよくあります。ツールが記述しているのがドキュメントではなくキャンバスだからです。見出し要素がどこにもないことも多く、その場合は見出しウィジェットになれるものが何もありません。
この2つ目のケースは、実は変換の問題ではありません。絶対配置のキャンバス出力はどのElementorレイアウトにも対応しておらず、一度も表現されていないドキュメント構造をツールが推測することはできません。書き出し結果がそうなっているなら、正直なところ、変換するより構造を作り直すべきです。あるいは、デザインツールにセマンティックなフローレイアウト版を書き出す機能があれば、そちらで書き出し直してください。
修復するより再生成する
このパイプラインを速くする習慣は、ソースを使い捨てとして扱うことです。構造マップに階層8と赤いHTMLブロック6つが表示されたら、Elementorを開いて修正を始めるのではなく、プロンプトに2行追加して再生成し、もう一度変換してください。このループにかかるのは1分ほどです。
同じ問題をElementorの中で修復すると1時間かかり、しかも次のページでも同じことを繰り返すことになります。プロンプトを直せば、その後に生成するすべてのページが直ります。それこそが、このワークフローを整える価値のある理由です。