この記事の対象: AIでワイヤーフレーム作成を効率化したい制作者と、AIで設計が済むと聞いた発注者
読了時間: 約14分
「テキストで指示すればワイヤーフレームが出てくる」という触れ込みのツールが一気に増えました。実際に案件で試すと、出てくるものは想像より整っています。ただ、そのままクライアントに出せるかというと話は別です。AIが得意なのは「よくある構成の叩き台を秒で出すこと」で、苦手なのは「この案件でなぜこの順番なのか」を決めることでした。この記事では、実務でAIワイヤーフレーム作成を回した結果として、そのまま使えた場面と、結局人が引き直した場面を切り分けて書きます。
AIワイヤーフレーム作成ツールで何ができるのか
「ワイヤーフレーム」と一口に言っても3段階ある
ツールの実力を評価する前に、そもそもワイヤーフレームという言葉が指す範囲を揃える必要があります。現場では少なくとも3つの段階が混ざったまま同じ名前で呼ばれています。
① 構成メモ（情報の順番だけ）
- セクションの並びと役割
- AIが最も強い領域
② グレースケールワイヤー
- 要素の配置と大きさ
- AIは大枠まで、詰めは人
③ 合意用ワイヤー（クライアント提出）
- 実コピー・実データ量で検証済み
- ほぼ人の仕事
AIの評価が人によって割れるのは、①を見て「使える」、③を見て「使えない」と言っているためです。
「AIでワイヤーが作れる」という話が噛み合わないのは、この3つを区別せずに議論しているからです。①だけを指しているなら、AIはもう十分に実用水準に達しています。③まで含めているなら、現時点で任せきりにはできません。
この記事で「AIでどこまでできるか」を書くときも、①なのか③なのかを毎回明示します。制作者と発注者の会話でも、まずここを揃えるだけで議論の空転がなくなります。
テキストからワイヤーを起こすツールの基本動作
テキスト指示型のツールは、おおむね次の流れで動きます。プロンプトを渡す、構成が返る、画面上で編集する、コードかデザインファイルとして書き出す。ツールによって出口が違い、HTMLで出るもの、Figmaに読み込める形で出るもの、独自エディタの中でしか編集できないものがあります。
出口の違いは実務では決定的です。独自エディタに閉じるタイプは、叩き台としては速いのに、そこから先の作業を全部そのツールの中でやることになります。案件が進むほど、Figmaで管理している他のページとの整合が取れなくなっていきました。
ツールを選ぶときに見るべきなのは、出力の見た目のきれいさではなく、この出口です。具体的には次の3点を確認します。
- 書き出し形式 — HTMLかFigmaファイルか、それとも独自形式のみか。独自形式のみなら、そのツールが案件の終わりまで生き残る前提になります
- 修正の主導権 — 生成後の細かい調整を、AIへの再指示でしかできないのか、要素を直接触れるのか。再指示だけのツールは、細部の詰めで急に遅くなります
- チームでの共有 — URLで共有できるか、アカウント招待が要るか。発注者側にアカウントを作らせる工程が入ると、確認1回のリードタイムが伸びます
実際に投げてみたプロンプトと、返ってきたもの
製造業のコーポレートサイト、トップページのワイヤーを想定して、次のような指示を投げます。
BtoB製造業のコーポレートサイトのトップページのワイヤーフレームを作ってください。
前提:
- 従業員80名、精密部品の受託加工
- 主な訪問者は購買担当者と、新卒・中途の求職者
- サイトの目的は問い合わせ（見積依頼）の獲得
- 求人応募は副次的な目的
出力条件:
- PC版とSP版の両方
- セクションごとに、目的と掲載する情報を明記
- ダミーテキストは日本語で、文字数も実際に近い量で
返ってきたのは、ヒーロー、強み3点、加工事例、設備一覧、選ばれる理由、会社情報、採用バナー、問い合わせCTAという並びでした。BtoB製造業のセオリーとしては妥当です。生成そのものは十数秒で終わり、人が手を動かすより明らかに速い。
問題はこの先にありました。
そのまま使えたケースと、引き直しになったケース
そのまま使えたのは「型が決まっている画面」
実務で手を入れずに通ったのは、次のような画面でした。
| 画面 | AI出力の使えた度合い | 理由 |
|---|---|---|
| 会社概要 | ほぼそのまま | 掲載項目が業界で固まっている |
| プライバシーポリシー | ほぼそのまま | 構成に選択の余地がない |
| よくある質問 | 微修正のみ | アコーディオンの粒度だけ調整 |
| お問い合わせ | 微修正のみ | 項目の必須任意を見直す程度 |
| 採用の募集要項 | 微修正のみ | 労働条件の記載順に定型がある |
共通しているのは、その画面で「何を見せるか」に議論の余地がないことです。判断が要らない画面ほど、AIの出力は素直に使えます。中規模のコーポレートサイトだと、この種類の画面がページ数の相応の割合を占めます。ここが自動化できるだけでも、初期の手数はかなり減りました。
引き直しになったのは「その案件固有の事情がある画面」
一方、必ず引き直しになったのがトップページと、主力サービスの紹介ページです。さきほどの製造業の例で言うと、AIの出したトップページは教科書どおりでしたが、この会社のヒアリングで出ていた「短納期対応が最大の武器で、一般的な納期より大幅に早く出せる」という情報が、強み3点の1つとして他と並列に置かれていました。
現場の判断としては、これはヒーロー直下に単独で置くべき情報です。訪問者が購買担当者で、比較検討の軸が納期にあるなら、スクロールさせる前に見せないと意味がない。AIは「強みは3点セットで並べる」という定型に情報を流し込んだだけで、どの強みが競合比較で効くかは判断していませんでした。
引き直し後（人の判断）
- ヒーローで納期を明言
- 直下に納期比較の1ブロック
- 強みは2点に絞る
- 事例は納期別に並べ替え
AI出力（定型）
- ヒーローは抽象的なコピー
- 強み3点を等価に並列
- 事例は業種別
- 設備一覧を上位に配置
差が出ているのは見た目ではなく、情報の優先順位です。ワイヤーフレームの本体はここなので、ここを外すと「きれいだが効かないワイヤー」になります。
同じことが採用サイトでも起きました。AIは「社員インタビュー→数字で見る当社→福利厚生→募集要項」という定番の順で出してきます。ところがこの会社の採用上の武器は、社員の平均勤続年数が地域の同業より長いことでした。定着率を先に見せてから人の話に入るほうが、応募者の不安を先に潰せます。AIが持っているのは「採用サイトの一般的な並び」で、「この会社の応募者が何を不安に思っているか」ではありません。
判断が要る画面かどうかの見分け方
投げる前に切り分けたほうが速いので、次の3つで判定しています。
- その画面の内容が、競合サイトを5つ見て9割同じか — 同じならAIに任せる
- ヒアリングで出た固有情報が、その画面の主役になるか — なるなら人が引く
- 掲載するデータの量が、まだ確定していないか — 未確定ならAIに投げても手戻りする
3つ目は見落としがちです。「実績が何件あるか」「スタッフ紹介が何人分か」が決まっていない段階でワイヤーを作ると、実データが揃った瞬間にレイアウトが破綻します。AIは指示しない限り、いい感じの件数を勝手に仮定して並べます。
判定は画面単位で行い、サイト単位で「AIを使う／使わない」と決めないことが重要です。同じ案件の中に、丸ごと任せられる画面と一から引く画面が同居しているのが普通です。
AIワイヤー作成で必ずつまずく4つのポイント
1. 日本語の実文字数を無視する
最もよく起きる問題です。AIが出すダミーテキストは短い。「革新的な技術で未来を創る」のような、収まりのいい長さで出てきます。ところが実際のクライアントから上がってくるコピーは「創業以来培ってきた精密加工技術で、お客様の課題解決に貢献します」のような長さです。
ワイヤーの段階でこれを想定していないと、デザイン工程で必ず崩れます。対策は、プロンプトの側で文字数を固定してしまうことです。
ダミーテキストの文字数条件:
- 見出し（H1）: 20〜30文字
- 見出し（H2）: 15〜25文字
- リード文: 60〜90文字
- 本文ブロック: 200〜300文字
- ボタンラベル: 6〜12文字
- 上限ではなく「この文字数ちょうど」で書くこと
「〜文字以内」と書くと短いほうに寄るので、「ちょうど」と指定します。この1ブロックを足すだけで、出力の実用度がはっきり上がりました。
あわせて、崩れやすい箇所には最長のケースを手で入れておきます。全角の社名、役職名込みの氏名、単位付きの数値。この3つはワイヤー段階で最長のものを入れておくと、デザイン工程での差し戻しがほぼ消えます。
2. レスポンシブの分岐を考えていない
PC版とSP版を両方出させると、SP版はPC版の要素を単純に縦積みしたものが返ってきます。人が引く場合は、SPでは順番を入れ替えたり、ある要素を折りたたんだり、そもそも出さない判断をします。この判断はAIからはまず出てきません。
特に厄介なのがテーブルと、横並びのカードです。仕様比較表のように列が多いテーブルは、SPでは横スクロールにするか、1行ずつのカードに組み替えるか、主要な項目だけに絞るかの三択になります。どれを選ぶかで実装量も情報量も変わるので、ワイヤーの段階で決めておく必要があります。
3. 実装コストの重みを持っていない
AIが出すワイヤーには、実装すると重い要素がさらっと混ざります。スクロール連動のアニメーション、多段の絞り込み検索、動的なタブ切り替え。ワイヤー上では1行の指示ですが、実装工数は大きく変わります。
そして発注者がAIで作ったワイヤーを持ち込んだ場合、その重さが伝わっていません。「AIで作ったのでこれで見積もってください」と渡されたワイヤーに、地味に工数のかかる機能がいくつも入っていた、というのは実際に起きます。予算感のすり合わせが後ろにずれる分、案件全体が遅れます。
対策は、ワイヤーの各要素に工数の重みを注記させることです。後述のプロンプトテンプレートで「[要工数確認]」を機械的に付けさせているのはこのためで、見積前に「これは本当に必要か」を1回問える状態になります。
4. CMSで運用することを前提にしていない
WordPressやShopifyで運用するサイトなら、そのワイヤーが「編集画面で再現できるか」が問われます。AIはこの制約を持っていないので、1ページごとに構造が違うワイヤーを平気で出します。人が更新する前提なら、繰り返し使えるブロックの組み合わせに落とし込む作業が別途必要です。
判定基準はシンプルで、「同じ形のブロックが3ページ以上に出てくるか」を見ます。出てくるなら共通ブロックにまとめ、出てこないならその1ページ限りの実装として切り分ける。この整理をワイヤー段階でやっておくと、実装のコンポーネント設計がそのまま決まります。
実務で回している手順とプロンプト
5ステップで回す
工程1に時間をかけるほど、工程2以降が短くなります。AIの出力品質は、ほぼ入力した前提の解像度で決まりました。逆に、工程1を飛ばして「BtoB製造業のトップページを作って」とだけ投げると、どの案件でも同じものが返ってきます。前提が薄いと、AIは業界の平均像で埋めるからです。
そのまま使えるプロンプトのテンプレート
# 役割
あなたは日本のWeb制作会社のディレクターです。
実装可能性と運用のしやすさを優先してワイヤーフレームを設計してください。
# 案件の前提
- 業種:
- 事業内容:
- 規模（従業員数・拠点数）:
- 主要な訪問者（優先順位つきで2〜3種類）:
- サイトの最重要ゴール（1つだけ）:
- 副次的なゴール:
- 競合との明確な差:
- 使用するCMS:
# 掲載データの実数（判明している分）
- 実績・事例の件数:
- スタッフ紹介の人数:
- サービスの種類数:
- ニュース記事の想定更新頻度:
# 出力条件
- セクション単位で、以下を1行ずつ書く
1) セクション名
2) このセクションの目的（訪問者の何を動かすか）
3) 掲載要素の一覧
4) PC時のレイアウト（カラム数・並び）
5) SP時の扱い（縦積み／順序変更／非表示のどれか）
- ダミーテキストは日本語で、指定文字数ちょうどで書く
H1:20〜30字 / H2:15〜25字 / リード:60〜90字 / 本文:200〜300字
- CMSで運用するため、繰り返し利用できるブロックには「[反復]」と付ける
- 実装工数が大きい要素には「[要工数確認]」と付ける
最後の2つの指示が実務的に効きます。「[反復]」と「[要工数確認]」を機械的に付けさせておくと、CMS設計と見積の準備が同時に進みます。
「最重要ゴールを1つだけ」と縛っているのも意図的です。ここを複数書くと、AIはすべてを等価に扱ったワイヤーを出してきます。問い合わせも採用も資料請求も全部大事、という指示からは、優先順位のないワイヤーしか出てきません。
出てきたものをHTMLに落とす
構成が固まったら、確認用のHTMLに落とします。テキストのままクライアントに見せると、必ず解釈のずれが出ます。次のCSSをベースにすると、グレースケールのワイヤーらしい見た目になります。
<!DOCTYPE html>
<html lang="ja">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>ワイヤーフレーム</title>
<style>
:root {
--wf-line: #c9ccd1;
--wf-fill: #eef0f3;
--wf-text: #4a4f57;
}
body {
margin: 0;
font-family: system-ui, -apple-system, "Hiragino Sans", "Noto Sans JP", sans-serif;
color: var(--wf-text);
line-height: 1.8;
}
.wf-section {
border: 1px dashed var(--wf-line);
padding: 32px 24px;
margin: 0 auto 8px;
max-width: 1200px;
}
/* セクションの役割を常に画面上に出しておく。
ワイヤーの確認会で「これは何のブロックか」を毎回聞かれるのを防ぐ */
.wf-section::before {
content: attr(data-role);
display: inline-block;
font-size: 12px;
letter-spacing: .04em;
background: var(--wf-text);
color: #fff;
padding: 2px 10px;
border-radius: 999px;
margin-bottom: 16px;
}
.wf-box {
background: var(--wf-fill);
border: 1px solid var(--wf-line);
display: grid;
place-items: center;
aspect-ratio: 16 / 9;
font-size: 13px;
}
/* カラム数を data 属性で切り替える。
ワイヤー段階では列数を頻繁に変えるので、クラスを増やさずに済ませる */
.wf-cols {
display: grid;
gap: 16px;
grid-template-columns: repeat(var(--n, 3), 1fr);
}
.wf-cols[data-n="2"] { --n: 2; }
.wf-cols[data-n="4"] { --n: 4; }
@media (width < 768px) {
.wf-cols { grid-template-columns: 1fr; }
.wf-section { padding: 24px 16px; }
}
</style>
</head>
<body>
<section class="wf-section" data-role="ヒーロー / 納期の優位性を明言">
<div class="wf-box">メインビジュアル（16:9）</div>
<h1>短納期で応える精密部品の受託加工</h1>
<p>創業以来培ってきた加工技術で、急な設計変更にも対応します。</p>
</section>
<section class="wf-section" data-role="納期比較 / 競合との差を明示 [反復なし]">
<div class="wf-cols" data-n="2">
<div class="wf-box">自社の標準納期</div>
<div class="wf-box">業界の一般的な納期</div>
</div>
</section>
<section class="wf-section" data-role="加工事例 / 納期別に並べる [反復]">
<div class="wf-cols" data-n="3">
<div class="wf-box">事例カード</div>
<div class="wf-box">事例カード</div>
<div class="wf-box">事例カード</div>
</div>
</section>
</body>
</html>
実装のポイント
data-roleにセクションの目的を書き、::beforeで常時表示させています。ワイヤーの確認会では「このブロックは何のためにあるのか」が必ず論点になるので、画面に出しておくと説明の往復が減ります- カラム数を
data-n属性で切り替えているのは、ワイヤー段階で列数の変更が頻発するためです。クラス名を増やすより属性1つを書き換えるほうが速い aspect-ratioを使うと、画像が入る場所の面積が確定します。ワイヤーでこれをやっておかないと、デザイン工程で「思ったより小さい」という話が出ます
つまずきやすい点
@media (width < 768px)はレンジ構文です。対応していない環境も見るならmax-width: 767pxに書き換えてくださいplace-items: centerはグリッドコンテナに効きます。display: gridを外すと無効になります- ダミーテキストを短くしないこと。ワイヤーは崩れて初めて情報が得られるので、実際に来そうな長さで入れます
クライアント確認は必ずブラウザで
出来上がったHTMLは、URLで共有して実ブラウザで見てもらいます。画像で送ると、スクロール量とSPでの見え方が伝わりません。ワイヤー段階での認識ずれは、後工程で全部コストになります。
共有時に添える一文も決めています。「デザインではなく、情報の順番と量を見てください」と書いておくと、色や書体の指摘でレビューが埋まるのを防げます。グレースケールのワイヤーでも、この一文がないと見た目の話に流れます。
AIワイヤーは発注者にとって何の役に立つか
「AIで作ったので安く」は成立しない
発注側がAIでワイヤーを作って持ち込むケースが増えています。制作会社の立場から言うと、これは歓迎です。ただし、それで見積が下がるかというと下がりません。
理由は、ワイヤー作成そのものが制作費に占める割合が小さいからです。工数の大半はデザインの詰めと実装、そして関係者との合意形成に消えます。AIで浮くのは、そのうち最初の一部だけです。
では何の役に立つのか。発注前に社内の意見をまとめる材料として、非常に有効でした。「なんとなくかっこいいサイト」という状態のまま制作会社に来ると、要件を引き出すヒアリングだけで数週間かかります。AIで作った粗いワイヤーが1枚あるだけで、「この順番でいいか」「この情報は要るか」という具体的な議論が社内でできる。制作会社に来た時点で論点が絞れているので、結果として全体の期間が短くなります。
期間が縮めば、担当者の拘束時間も減ります。金額そのものより、社内調整の往復が減ることのほうが発注側の実利は大きい、というのが実感です。
発注者がAIワイヤーを持ち込むときの注意
- 「これで作ってください」ではなく「こういう優先順位で考えています」と伝える — ワイヤーは結論ではなく前提として渡すほうが、いい提案が返ってきます
- 掲載する実データの量を一緒に伝える — 実績が3件なのか300件なのかで設計が変わります
- AIが入れた機能が本当に要るか、社内で1回削る — 削らないまま渡すと見積が膨らみます
- 誰が更新するのかを書き添える — 更新担当が決まっているかどうかで、CMSの作り込み方が変わります
予算の考え方については、条件別に整理した記事があります。
AIワイヤーと相性がいいツール構成
ワイヤーの前後の工程も含めると、次のような分担が現実的でした。
| 工程 | 使うもの | AIの関与度 |
|---|---|---|
| 前提整理 | ドキュメント（手書き） | 低い。人が決める |
| 構成の叩き台 | テキスト生成AI | 高い。ここが本領 |
| ワイヤー清書 | Figma / HTML | 中程度。生成→手直し |
| デザイン | Figma | 低い。判断の連続 |
| 実装 | エディタ + コード生成AI | 中〜高。定型部分は速い |
| 検証 | 実ブラウザ / 解析ツール | 低い。事実の確認 |
Figmaの有料・無料の判断については別記事で条件別に整理しています。
公開後にワイヤーの設計が正しかったかを確かめるには、解析側の設定も要ります。どのセクションまでスクロールされているか、CTAがどれだけ押されているかを見て、次の改修でワイヤーを引き直す。ここまでやって初めて、ワイヤーの良し悪しが検証できます。
よくある質問
AIで作ったワイヤーフレームをそのままクライアントに提出できますか
会社概要やプライバシーポリシーのような、掲載項目が業界で固まっている画面なら提出できます。トップページや主力サービスのページは、その案件固有の強みをどこに置くかという判断が入るため、人が引き直したほうが確実です。判断が要らない画面か要る画面かで切り分けてください。
AIワイヤーフレーム作成ツールを使うと制作費は安くなりますか
ほとんど変わりません。ワイヤー作成が制作費に占める割合は小さく、工数の大半はデザインの詰めと実装、関係者との合意形成に使われるためです。ただし、発注前の社内合意が進んだ状態で相談に来られると、ヒアリング期間が短くなる分、全体のスケジュールは前倒しできます。
AIワイヤーフレーム作成で一番失敗しやすいのはどこですか
ダミーテキストの文字数です。AIは収まりのいい短いコピーを出しますが、実際に上がってくる日本語コピーはもっと長い。ワイヤーの時点で実際に来そうな長さを入れておかないと、デザイン工程でレイアウトが崩れます。プロンプトで「この文字数ちょうど」と指定するのが確実です。
プロンプトに何を書けば出力の質が上がりますか
案件の前提（業種・訪問者・最重要ゴール・競合との差）と、掲載データの実数（事例が何件、スタッフが何人）です。特に実数を書かないと、AIは適当な件数を仮定してレイアウトを組むため、実データが揃った瞬間に破綻します。最重要ゴールは1つだけに絞ってください。複数書くと優先順位のないワイヤーが返ってきます。
スマホ版のワイヤーもAIに任せられますか
任せると、PC版を単純に縦積みしただけのものが返ってきます。順序を入れ替える、折りたたむ、スマホでは出さない、といった判断は人が入れる必要があります。特にテーブルと横並びカードはスマホでの見せ方がレイアウトの根本に関わるので、ワイヤー段階で決めてください。
まとめ
AIワイヤーフレーム作成の実力を、実務の観点で整理すると次のとおりです。
- 使える: 会社概要・ポリシー・FAQ・フォームなど、掲載項目が固まっている画面。全ページの粗い叩き台を一気に出す用途
- 引き直しになる: トップページと主力サービスページ。案件固有の強みをどこに置くかという優先順位の判断が入るため
- 必ず手を入れる: 日本語の実文字数、スマホ版の分岐、実装工数の重み、CMSでの運用可能性
- 発注者にとっての価値: 見積を下げるものではなく、発注前に社内の論点を絞るための材料
ツールの機能が増えても、この線引きはしばらく変わらないと見ています。AIが自動化しているのは「よくある構成を知っていること」であり、ワイヤーフレームの本体である「この案件でなぜこの順番なのか」を決める部分ではないからです。逆に言えば、判断の要らない画面を全部AIに渡してしまえば、人は判断が要る画面に時間を使えます。そこが今いちばん現実的な使い方です。
