UIプロンプトエンジニアリングとは?AI時代のUI設計手法を解説
UIプロンプトエンジニアリングが重要になっている理由は、AIがUI制作やUI改善に直接関わる時代へ移行しているからです。従来のUI設計では、デザイナーやエンジニアが画面構成、コンポーネント、レイアウト、状態、導線を手動で設計し、それを実装していました。しかし生成AIの普及により、AIへ「どのようなUIを生成すべきか」を指示し、AIが条件に応じて画面やコンポーネントを出力する場面が増えています。
生成AIがUI制作に使われるようになると、単に「きれいな画面を作って」と指示するだけでは不十分です。ユーザーの目的、画面の役割、CTAの優先度、デザインシステムの制約、アクセシビリティ、ブランドトーン、レスポンシブ対応などを明確に伝える必要があります。つまり、AIにUIを作らせるためには、UI設計そのものをプロンプトとして構造化する力が求められます。
従来UI設計との違いは、完成画面そのものを直接設計するだけでなく、「AIがUIを生成する条件」を設計する点にあります。たとえば、同じLPでも、初心者向け、比較検討中ユーザー向け、購入直前ユーザー向けでは必要なUIが変わります。UIプロンプトエンジニアリングでは、こうした状況ごとの出力条件を設計し、AIが適切なUIを生成できる状態を作ります。
AI時代のUXでは、固定された画面よりも、ユーザー状態に応じて変化する動的UIの重要性が高まります。そのため、UIプロンプトエンジニアリングは単なるプロンプト作成テクニックではなく、UX設計、デザインシステム、AI制御、フロントエンド実装をつなぐ新しい設計手法として重要になります。
1. UIプロンプトエンジニアリングとは?
UIプロンプトエンジニアリングとは、AIに対してUI生成やUI改善を適切に指示するための設計手法です。単に文章で指示を書くのではなく、目的、対象ユーザー、画面構造、コンポーネント、デザイン制約、UX条件、出力形式を整理し、AIが再現性のあるUIを生成できるようにします。
まず、全体像を整理すると以下のようになります。
| 項目 | 内容 |
|---|---|
| 意味 | AIにUI生成指示を行う設計手法 |
| 対象 | 生成UI・AI UI・LP・管理画面・アプリUI |
| 目的 | AI出力の品質と再現性を高める |
| 必要要素 | 目的・制約・文脈・出力形式 |
| 関係領域 | UX設計・デザインシステム・AI開発 |
| 強み | UI生成を高速化し、改善サイクルを回しやすい |
| 注意点 | 指示が曖昧だとUI品質が不安定になる |
※補足:ここでいう「プロンプト」は、AIへの単なる依頼文ではなく、UIを生成するための設計仕様に近いものです。
1.1 AIへUI生成指示を行う設計手法
UIプロンプトエンジニアリングでは、AIに対して「どのようなUIを作るべきか」を具体的に指示します。たとえば、LPのファーストビューを生成する場合でも、「高級感のあるデザイン」だけでは不十分です。誰向けのLPなのか、何を訴求するのか、CTAは何か、情報量はどれくらいか、配色や余白はどうするのかまで指定する必要があります。
この手法の価値は、AI出力を偶然に頼らず、設計意図に沿って安定させられる点にあります。曖昧な指示では、AIは見た目だけを整えたUIを出すことがありますが、UXやCVRまで考慮されたUIにはなりにくいです。そのため、UIプロンプトでは、見た目だけでなく、ユーザー行動や目的も含めて指示します。
| 指示項目 | 内容 |
|---|---|
| 目的 | 何を達成するUIか |
| 対象ユーザー | 誰が使うUIか |
| 画面種別 | LP・フォーム・ダッシュボードなど |
| 優先行動 | CTA・登録・購入・問い合わせ |
| デザイン条件 | 色・余白・トーン |
| UX条件 | 認知負荷・導線・不安解消 |
| 出力形式 | HTML・React・構成案・JSONなど |
プロンプト例
BtoB SaaSの無料トライアル獲得用LPのファーストビューUIを設計してください。対象ユーザーは中小企業のマーケティング担当者です。目的は「無料トライアル開始」です。CTAは1つに絞り、認知負荷を下げ、信頼感のある落ち着いたデザインにしてください。出力はセクション構成、UI要素、CTA文言、UX意図の順で整理してください。
出力例
ファーストビュー:- 見出し: マーケティング施策を、AIで素早く改善- サブコピー: LP・広告・CVR改善を一つの画面で管理できます- CTA: 無料で試してみる- 補助情報: クレジットカード不要 / 14日間無料- UX意図: 初回ユーザーの不安を減らし、行動負荷を下げる
予測(推測): このように目的、対象、CTA、UX条件を明確にしたプロンプトでは、AIが単なる装飾ではなく、行動導線を意識したUIを生成しやすくなると考えられます。
1.2 UI生成条件を定義する仕組み
UIプロンプトエンジニアリングでは、AIに自由にUIを作らせるのではなく、生成条件を定義します。生成条件とは、使用するコンポーネント、情報の優先順位、禁止表現、表示ルール、デザイントークン、レスポンシブ条件などです。これらを定義することで、AI出力のばらつきを減らし、プロダクト品質を保ちやすくなります。
特に、生成UIやAIエージェントUIでは、同じプロンプトでも文脈によって出力が変わることがあります。そのため、毎回同じ品質でUIを生成するには、条件を明文化する必要があります。これは、デザインシステムをAIが理解できる形に変換する作業とも言えます。
| 生成条件 | 内容 |
|---|---|
| 使用可能部品 | Button・Card・Form・Tableなど |
| 配色条件 | ブランドカラー・アクセントカラー |
| 余白条件 | セクション間隔・カード内余白 |
| CTA条件 | 主要CTAは1つにする |
| 禁止条件 | 過剰な装飾・複数CTA乱立 |
| レスポンシブ条件 | モバイルでは1カラム |
| アクセシビリティ | コントラスト・ラベル・読み上げ |
プロンプト例
以下の条件で、料金比較セクションのUIを生成してください。使用可能コンポーネントは PricingCard, CTAButton, FeatureList のみです。主要CTAは各カードに1つだけ配置してください。色はブランドカラーの青を主CTAにのみ使用し、その他はグレー系で整理してください。モバイルでは1カラム、PCでは3カラムにしてください。
出力例
料金比較セクション:- PC: 3カラムのPricingCard- SP: 1カラムで縦並び- 各カード: プラン名、価格、主要機能、CTA- CTA: 「このプランで始める」- デザイン: 青はCTAのみ、カード背景は白、境界線は薄いグレー
コード例
ファイル名: ui-generation-rules.ts
ファイル機能: AIがUI生成時に守るべき条件を定義する
使用言語: TypeScript
export const uiGenerationRules = { allowedComponents: ["PricingCard", "CTAButton", "FeatureList"], maxPrimaryCtaPerCard: 1, desktopColumns: 3, mobileColumns: 1, primaryColorUsage: "CTA only", avoid: ["too many colors", "multiple primary CTAs", "dense layout"],} as const;
予測(推測): UI生成条件をコード化しておくと、プロンプトだけで管理するよりも再利用性が高まり、AI生成UIを実装側でも制御しやすくなると考えられます。
1.3 AI時代の新しいUI設計アプローチ
AI時代のUI設計では、画面を直接作るだけでなく、AIが画面を作るためのルールや文脈を設計することが重要になります。これまでのUI設計は、デザイナーが完成画面を作り、エンジニアが実装する流れが中心でした。しかしAIを活用する場合、プロンプト、デザインシステム、出力形式、評価指標を組み合わせる必要があります。
このアプローチでは、UIデザイナー、UXリサーチャー、プロンプトエンジニア、フロントエンドエンジニアの役割が重なります。AIが生成したUIをそのまま使うのではなく、なぜそのUIが必要なのか、どの制約を守るべきか、どの指標で評価するかを設計することが重要です。
| 従来型UI設計 | AI時代のUI設計 |
|---|---|
| 完成画面を作る | 生成条件を設計する |
| 手動でUIを修正する | AI出力を制御する |
| 画面単位で管理 | コンテキスト単位で管理 |
| デザイナー中心 | AI・UX・開発の統合 |
| 静的UIが中心 | 動的UIが中心 |
| 見た目重視 | 意図・制約・評価重視 |
| 個別実装 | 再利用可能な生成ルール |
プロンプト例
AI時代のUI設計として、ユーザー状態に応じて変化するオンボーディング画面を提案してください。初心者には説明を多めにし、既存ユーザーにはショートカットを優先してください。出力は「ユーザー状態」「表示UI」「UX意図」「注意点」の表形式にしてください。
出力例
初心者:- 表示UI: チュートリアル、用語説明、次のステップ- UX意図: 初期理解を支援する既存ユーザー:- 表示UI: 最近使った機能、ショートカット、更新情報- UX意図: 操作効率を高める
予測(推測): 今後のUI設計では、画面を1つずつ作るよりも、ユーザー状態ごとにUIを生成・調整できる設計力が重要になると考えられます。
2. 従来UI設計との違い
UIプロンプトエンジニアリングは、従来のUI設計と対立するものではありません。従来のUI設計で重視されてきた情報設計、視線誘導、コンポーネント設計、UX設計はそのまま重要です。ただし、AI時代ではそれらを人間だけが直接設計するのではなく、AIが理解できる指示や条件に変換する必要があります。
違いを整理すると以下のようになります。
| 比較項目 | 従来UI設計 | UIプロンプトエンジニアリング |
|---|---|---|
| 設計対象 | 完成画面 | 生成条件・出力ルール |
| 中心作業 | ワイヤー・デザイン作成 | プロンプト・制約設計 |
| UIの性質 | 固定的 | 動的・文脈依存 |
| 評価軸 | 見た目・操作性 | 出力品質・再現性・UX |
| 関係技術 | Figma・HTML・CSS | 生成AI・LLM・JSON・React |
| 課題 | 修正に時間がかかる | 出力制御が難しい |
| 成功条件 | 良い画面を作る | 良いUIを生成できる条件を作る |
2.1 固定画面設計から生成条件設計へ変化する
従来のUI設計では、画面の完成形を設計することが中心でした。たとえば、LPのファーストビュー、料金表、フォーム、FAQなどをそれぞれ作り込み、ユーザーに表示する形を決めます。一方、UIプロンプトエンジニアリングでは、完成画面そのものよりも、AIが画面を生成する条件を設計します。
これは、UIがユーザーや文脈によって変化する時代に適した考え方です。同じ料金表でも、初心者には説明を多くし、上級者には比較情報を簡潔にし、購入直前のユーザーには保証やFAQを強調する必要があります。固定画面だけではこの変化に対応しにくいため、生成条件を設計することが重要になります。
| 設計対象 | 内容 |
|---|---|
| 固定画面 | 完成した1つのUI |
| 生成条件 | AIがUIを作るための条件 |
| ユーザー条件 | 初心者・上級者・購入直前など |
| 表示条件 | 情報量・CTA・補足説明 |
| 制約条件 | デザインルール・禁止表現 |
| 評価条件 | CVR・離脱率・理解度 |
| 出力形式 | HTML・React・JSON・構成案 |
プロンプト例
ユーザー状態に応じて変化する料金表UIを設計してください。初心者には説明を多めに、上級者には比較しやすさを優先してください。購入直前ユーザーには保証情報とFAQを強調してください。
出力例
初心者向け:- 各プランの説明を長めに表示- 用語補足を追加上級者向け:- 機能比較表を中心に表示- 説明文は短くする購入直前:- 返金保証、導入事例、FAQをCTA近くに配置
予測(推測): 固定画面ではなく生成条件を設計することで、同じUI基盤から複数のユーザー状態に対応した画面を作りやすくなると考えられます。
2.2 UI実装中心から意図設計中心へ変化する
従来のUI設計では、見た目や実装の完成度が重視されることが多くありました。もちろん実装品質は重要ですが、AIがUIを生成する場合は、まず「なぜそのUIが必要なのか」という意図を明確にする必要があります。意図が曖昧なままAIにUI生成を依頼すると、見た目は整っていても、目的に合わないUIが出力される可能性があります。
意図設計では、ユーザーがどの状態にあり、何に困っていて、次にどの行動を取るべきなのかを定義します。たとえば、フォームUIを生成する場合でも、「入力欄を作る」だけではなく、「入力不安を減らす」「エラーを早く修正できるようにする」「送信完了までの負担を下げる」といった意図をプロンプトに含めます。
| 設計観点 | 内容 |
|---|---|
| 画面目的 | 何を達成するUIか |
| ユーザー課題 | 何に迷っているか |
| 行動意図 | 次に何をしてほしいか |
| UX意図 | どの負荷を下げるか |
| 表示優先度 | 何を先に見せるか |
| 制約 | 何を避けるか |
| 成果指標 | 何で評価するか |
プロンプト例
問い合わせフォームUIを設計してください。目的は送信完了率を高めることです。ユーザーの入力不安を減らし、エラーが発生した場合はすぐ修正できるUIにしてください。項目数は最小限にし、入力補助を含めてください。
出力例
フォーム構成:- 名前- メールアドレス- 相談内容- 送信ボタンUX設計:- 必須項目を明示- 入力例をplaceholderで表示- エラーは入力欄の直下に即時表示- 送信前に確認メッセージを表示
予測(推測): AIにUI実装だけでなく設計意図を伝えることで、見た目だけのUIではなく、ユーザー行動を支援するUIが生成されやすくなると考えられます。
2.3 静的UIから動的UIへ変化する
従来のUIは、あらかじめ決められた画面をユーザーに表示する静的UIが中心でした。しかし、AI時代では、ユーザーの行動、文脈、目的、デバイス、環境に応じてUIが変化する動的UIが重要になります。たとえば、同じダッシュボードでも、初心者には重要指標を絞って表示し、上級者には詳細な分析テーブルを表示するような設計が考えられます。
UIプロンプトエンジニアリングでは、この動的変化をAIに指示する必要があります。単に「ダッシュボードを作って」と依頼するのではなく、「ユーザーの習熟度に応じて表示密度を変える」「異常値がある場合はアラートを上部に表示する」「モバイルではカード形式にする」など、動的条件を含めます。
| UI種類 | 特徴 |
|---|---|
| 静的UI | 常に同じ画面を表示 |
| 動的UI | 状況に応じて変化 |
| パーソナライズUI | ユーザーごとに表示変更 |
| 生成UI | AIが構成を生成 |
| リアルタイムUI | 行動データで即時変化 |
| コンテキストUI | 文脈に応じて表示 |
| エージェントUI | AIがタスク中心でUIを組む |
プロンプト例
ユーザー習熟度に応じて変化する分析ダッシュボードUIを設計してください。初心者には主要KPIを3つだけ表示し、上級者には詳細フィルターと比較グラフを表示してください。異常値がある場合は画面上部にアラートを出してください。
出力例
初心者向け:- KPIカード3枚- 簡単な説明文- 推奨アクション上級者向け:- 詳細フィルター- セグメント比較- 時系列グラフ- CSV出力異常値あり:- 上部に警告アラートを表示
予測(推測): 動的UI条件をプロンプトに含めることで、AIは単一画面ではなく、ユーザー状態に応じた複数パターンのUIを提案しやすくなると考えられます。
3. プロンプト設計
プロンプト設計は、UIプロンプトエンジニアリングの中心です。AIにUIを生成させる場合、プロンプトの品質がそのまま出力品質に影響します。曖昧なプロンプトでは、AIは見た目だけを整えたUIを出す可能性がありますが、具体的な目的、制約、文脈、出力形式を含めることで、実務に近いUI案を生成しやすくなります。
プロンプト設計の基本要素は以下の通りです。
| 要素 | 内容 |
|---|---|
| 目的 | UIで達成したいこと |
| 対象ユーザー | 誰向けのUIか |
| 画面種別 | LP・フォーム・管理画面など |
| 制約条件 | デザイン・実装・UXの制約 |
| コンテキスト | ユーザー状態・行動履歴 |
| 出力形式 | 表・JSON・React・HTMLなど |
| 評価条件 | CVR・可読性・操作性など |
3.1 UI生成条件定義
UI生成条件定義では、AIがUIを作るために必要な前提条件を整理します。たとえば、画面の目的、対象ユーザー、必要なコンポーネント、CTA、デザインルール、禁止事項などです。これらが不足していると、AIは一般的なUIを生成するだけになり、プロダクト固有の目的に合わない可能性があります。
生成条件は、なるべく具体的に書くことが重要です。「シンプルなUI」ではなく、「CTAを1つに絞り、余白を広く取り、説明文は2行以内にする」のように、AIが判断しやすい条件に分解します。これにより、出力の再現性が高まります。
| 条件 | 具体例 |
|---|---|
| 画面目的 | 無料登録を増やす |
| 対象 | 初心者ユーザー |
| CTA | 無料で始める |
| 情報量 | 1セクション3要素まで |
| 配色 | 青をCTAのみに使用 |
| 禁止 | 複数CTA・過剰装飾 |
| 出力 | UI構成 + UX意図 |
プロンプト例
初心者向けのタスク管理アプリのオンボーディングUIを生成してください。目的は初回タスク作成率を高めることです。CTAは「最初のタスクを作る」に統一し、説明文は短くしてください。出力は画面構成、コンポーネント、UX意図の順でお願いします。
出力例
画面構成:1. 見出し2. 3ステップ説明3. CTAボタン4. 補足ヘルプUX意図:- 初回ユーザーの迷いを減らす- 最初の行動を明確にする- 操作前の心理的負担を下げる
コード例
ファイル名: ui-prompt-schema.ts
ファイル機能: UI生成プロンプトの基本構造を型として定義する
使用言語: TypeScript
export type UiPromptSchema = { purpose: string; targetUser: string; screenType: string; primaryCTA: string; constraints: string[]; outputFormat: "table" | "json" | "react" | "html";};
予測(推測): UI生成条件を型やテンプレートとして管理すると、チーム内でプロンプト品質を揃えやすくなると考えられます。
3.2 コンテキスト設計
コンテキスト設計では、AIがUIを生成する際に参照すべき背景情報を整理します。ユーザーが初回訪問なのか、再訪なのか、購入直前なのか、離脱しそうなのかによって、最適なUIは変わります。コンテキストが不足すると、AIは一般的なUIを出力しやすくなります。
重要なのは、コンテキストを単なる説明ではなく、UI生成に使える条件として整理することです。たとえば、「ユーザーは初心者です」だけでなく、「専門用語を避け、説明を多めにし、CTAは1つに絞る」といった形で、UIへの影響まで明記します。
| コンテキスト | UIへの影響 |
|---|---|
| 初回訪問 | 説明を増やす |
| 再訪 | 履歴を表示 |
| 比較中 | 比較表を表示 |
| 購入直前 | 保証・FAQを表示 |
| 離脱兆候 | 補足情報を表示 |
| モバイル | 1カラム・固定CTA |
| 上級者 | 詳細設定を表示 |
プロンプト例
以下のコンテキストをもとに、EC商品の購入前LPセクションを生成してください。ユーザーは商品ページを3回閲覧していますが、まだ購入していません。価格への不安がある可能性が高いため、保証、レビュー、送料無料情報をCTA近くに配置してください。
出力例
購入前セクション:- 商品ベネフィット- レビュー抜粋- 返金保証- 送料無料表示- CTA: 安心して購入する
予測(推測): ユーザー行動コンテキストを含めることで、AIは単なる商品紹介ではなく、不安解消を重視したUIを生成しやすくなると考えられます。
3.3 出力制御設計
出力制御設計では、AIにどの形式で出力させるかを指定します。UI案だけが欲しい場合は表形式、実装に使いたい場合はReactやHTML、システム連携したい場合はJSON形式が適しています。出力形式を指定しないと、AIの返答が文章中心になり、実務で使いにくくなることがあります。
特に、生成UIやAIエージェントUIでは、出力をシステムが読み取れる形にすることが重要です。たとえば、UIブロックをJSONで出力させれば、フロントエンド側でコンポーネントとしてレンダリングしやすくなります。
| 出力形式 | 向いている用途 |
|---|---|
| 表形式 | 企画・比較・設計整理 |
| 箇条書き | ラフ案・構成案 |
| JSON | システム連携 |
| React | 実装サンプル |
| HTML | 静的UI生成 |
| CSS | スタイル生成 |
| Markdown | ドキュメント化 |
プロンプト例
料金表UIをJSON形式で出力してください。各ブロックには component, title, description, ctaText, priority を含めてください。使用可能コンポーネントは PricingCard, FeatureList, CTAButton のみです。
出力例
[ { "component": "PricingCard", "title": "Basic", "description": "小規模チーム向け", "ctaText": "Basicで始める", "priority": "medium" }]
コード例
ファイル名: render-ui-blocks.tsx
ファイル機能: AIが出力したJSON UIブロックをReactで描画する
使用言語: TypeScript + React
type UiBlock = { component: "PricingCard" | "CTAButton"; title?: string; description?: string; ctaText?: string;};export function renderUiBlock(block: UiBlock) { if (block.component === "PricingCard") { return <div className="pricing-card">{block.title}</div>; } if (block.component === "CTAButton") { return <button>{block.ctaText}</button>; } return null;}
予測(推測): UI出力をJSON化すると、AI生成UIをフロントエンド実装と接続しやすくなり、動的UI生成の基盤として使いやすくなると考えられます。
4. コンテキスト制御
コンテキスト制御とは、AIがUIを生成するときに参照するユーザー状態や環境情報を管理することです。UIプロンプトエンジニアリングでは、良いプロンプトを書くことだけでなく、どの情報をAIに渡すかも重要になります。不要な情報が多すぎると出力がぶれ、必要な情報が不足すると一般的なUIしか生成されません。
コンテキスト制御の主な対象は以下の通りです。
| コンテキスト | 内容 |
|---|---|
| ユーザー状態 | 初回・再訪・購入直前 |
| 行動履歴 | 閲覧・クリック・離脱 |
| デバイス | PC・スマートフォン |
| 利用環境 | 低速回線・ダークモード |
| 目的 | 登録・購入・比較 |
| セグメント | 初心者・上級者・高LTV |
| リアルタイム情報 | 在庫・エラー・通知 |
4.1 ユーザー状態反映
ユーザー状態反映では、ユーザーが現在どの段階にいるかをAIに渡します。初回訪問、比較検討、購入直前、離脱リスクありなど、状態によって必要なUIは異なります。状態を反映しないプロンプトでは、AIは全ユーザー向けの一般的なUIを出しやすくなります。
ユーザー状態を反映する場合は、状態名だけでなく、UIにどう影響させるかまで指定することが重要です。たとえば、「購入直前ユーザー」だけではなく、「保証、レビュー、FAQをCTA近くに配置する」と指定すると、AIがより実務的なUIを出力しやすくなります。
| ユーザー状態 | UI反映例 |
|---|---|
| 初回訪問 | 説明・ガイドを表示 |
| 再訪 | 履歴・おすすめ表示 |
| 比較中 | 比較表を強調 |
| 購入直前 | 保証・FAQを表示 |
| 離脱リスク | サポート導線を表示 |
| 上級者 | 詳細設定を表示 |
| 休眠ユーザー | 再開導線を表示 |
プロンプト例
ユーザー状態は「購入直前」です。このユーザー向けに、SaaS料金ページの下部CTAセクションを生成してください。保証、導入実績、FAQをCTA近くに配置し、不安を減らす構成にしてください。
出力例
下部CTAセクション:- 導入企業数- 14日間無料- よくある質問3つ- CTA: 無料で始める- 補足: いつでもキャンセル可能
予測(推測): ユーザー状態を明示すると、AIは一般的なCTAではなく、購買不安を下げるためのUIを生成しやすくなると考えられます。
4.2 行動履歴活用
行動履歴活用では、ユーザーが過去にどのページを見たか、どのCTAをクリックしたか、どこで離脱したかをUI生成に反映します。たとえば、料金ページを何度も見ているユーザーには比較表や保証情報、フォーム途中離脱ユーザーには入力補助や安心材料を表示する設計が有効です。
ただし、行動履歴を使う場合は、ユーザーに不自然さを与えないことが重要です。あまりにも露骨に「あなたはこのページを3回見ました」と表示すると、監視されている印象を与える可能性があります。そのため、行動履歴はUIの裏側で使い、自然な補助として表示するのが望ましいです。
| 行動履歴 | UI生成例 |
|---|---|
| 料金ページ閲覧 | 料金FAQを表示 |
| フォーム離脱 | 入力補助を表示 |
| CTA未クリック | 補足情報を追加 |
| レビュー閲覧 | 事例を追加表示 |
| 商品比較 | 比較表を強調 |
| 再訪 | 前回の続き表示 |
| 長時間滞在 | ヘルプ導線表示 |
プロンプト例
ユーザーは料金ページを2回閲覧し、CTAはまだクリックしていません。この行動履歴をもとに、料金ページの改善UIを提案してください。価格不安を減らすため、比較表、FAQ、導入事例を自然に追加してください。
出力例
改善UI:- プラン比較表を上部に移動- FAQ「途中解約できますか?」を追加- 導入事例カードをCTA直前に配置- CTA文言を「無料で試してから判断する」に変更
コード例
ファイル名: context-builder.ts
ファイル機能: 行動履歴からAIへ渡すコンテキストを生成する
使用言語: TypeScript
type Behavior = { viewedPricing: number; clickedCTA: boolean; abandonedForm: boolean;};export function buildUiContext(behavior: Behavior) { return { pricingConcern: behavior.viewedPricing >= 2 && !behavior.clickedCTA, needsFormHelp: behavior.abandonedForm, };}
予測(推測): 行動履歴をコンテキスト化すると、AIはユーザーの迷いや不安を推測し、それに応じたUI改善案を出しやすくなると考えられます。
4.3 状況依存UI生成
状況依存UI生成では、ユーザーの現在の文脈に応じてUIを変えます。たとえば、在庫が少ない、エラーが出ている、キャンペーン中、ユーザーがモバイルで閲覧しているなど、状況によって表示すべきUIは変わります。UIプロンプトでは、この状況をAIに正しく渡す必要があります。
状況依存UIでは、単に情報を追加するのではなく、ユーザーの次の行動を支援することが重要です。在庫が少ない場合は焦らせすぎずに注意喚起し、エラー時は原因と修正方法を表示し、キャンペーン中は期限とメリットを分かりやすく伝える必要があります。
| 状況 | UI生成例 |
|---|---|
| 在庫少 | 在庫注意表示 |
| エラー | 修正案表示 |
| キャンペーン中 | 期限・特典表示 |
| モバイル閲覧 | 固定CTA |
| 低速回線 | 軽量UI |
| 夜間利用 | ダークテーマ |
| 初回操作 | ガイド表示 |
プロンプト例
状況は「モバイル閲覧」「キャンペーン終了まで24時間」「CTA未クリック」です。この条件に合わせて、EC商品の購入促進UIを生成してください。過度に煽らず、期限とメリットを分かりやすく表示してください。
出力例
モバイル購入促進UI:- 上部にキャンペーン期限バナー- 商品メリットを3点で表示- 画面下に固定CTA- CTA文言: キャンペーン価格で購入する- 補足: 返品保証あり
予測(推測): 状況条件を明確にすると、AIはその場に適したUIを生成しやすくなります。ただし、緊急性を強く出しすぎるとUXや信頼性を損なう可能性があります。
5. 生成UIとの関係
UIプロンプトエンジニアリングは、生成UIと非常に深く関係しています。生成UIとは、AIがユーザーの状況や入力内容に応じて、画面構成やコンポーネントを動的に生成するUIです。生成UIの品質は、AIモデルだけでなく、どのようなプロンプトと制約を与えるかによって大きく変わります。
生成UIとの関係を整理すると以下のようになります。
| 項目 | 内容 |
|---|---|
| 目的 | AIによるUI生成を制御する |
| 対象 | 画面・コンポーネント・レイアウト |
| 必要要素 | プロンプト・制約・コンテキスト |
| 強み | ユーザーごとにUIを最適化しやすい |
| 課題 | 出力品質が不安定になりやすい |
| 関係技術 | LLM・React・JSON・Design System |
| 成功条件 | 生成範囲と評価条件を明確にする |
5.1 動的UI生成制御
動的UI生成制御では、AIが生成するUIの範囲や条件をコントロールします。生成UIでは、AIが自由にレイアウトやコンポーネントを提案できますが、自由度が高すぎると品質が不安定になります。ブランドルールやアクセシビリティ、CTAの意味が崩れないように、生成可能な範囲を決める必要があります。
UIプロンプトエンジニアリングでは、「使ってよいコンポーネント」「禁止するレイアウト」「必ず含める情報」「出力形式」を明確に指定します。これにより、AIが生成するUIを実務で使いやすい形に制御できます。
| 制御対象 | 内容 |
|---|---|
| コンポーネント | 使用可能部品を指定 |
| レイアウト | カラム数・余白・順序 |
| CTA | 数・文言・配置 |
| テキスト | 文字量・トーン |
| 色 | トークン使用 |
| アクセシビリティ | ラベル・コントラスト |
| 出力形式 | JSON・React・HTML |
プロンプト例
AIでLPセクションを生成してください。使用可能コンポーネントは Hero, FeatureCard, CTAButton のみです。CTAは1つだけにし、余白を広く取り、情報量を詰め込みすぎないでください。出力はJSON形式にしてください。
出力例
{ "component": "Hero", "title": "AIでLP改善をもっと速く", "description": "分析から改善案生成までを一つの画面で支援します。", "cta": { "component": "CTAButton", "text": "無料で試す" }}
コード例
ファイル名: allowed-ui-components.ts
ファイル機能: AIが生成時に使用できるUIコンポーネントを制限する
使用言語: TypeScript
export const allowedUiComponents = [ "Hero", "FeatureCard", "CTAButton",] as const;export type AllowedUiComponent = typeof allowedUiComponents[number];
予測(推測): 生成可能なコンポーネントを制限すると、AI出力の自由度は下がりますが、UI品質と実装可能性は高まりやすいと考えられます。
5.2 リアルタイムUI最適化
リアルタイムUI最適化では、ユーザーの行動や状況に応じてAIがUIを調整します。たとえば、CTAをクリックしないユーザーに補足情報を表示したり、フォームで迷っているユーザーに入力例を出したり、比較中ユーザーに比較表を提示したりします。こうした最適化は、ユーザー体験をより自然にする可能性があります。
ただし、リアルタイムでUIを変えすぎると、ユーザーが混乱する可能性もあります。UIが突然変わったり、過度に誘導されたりすると、信頼感が下がることがあります。そのため、UIプロンプトでは「変化の条件」「表示タイミング」「変化量」を制御することが重要です。
| 最適化対象 | 例 |
|---|---|
| CTA | 文言変更 |
| FAQ | 不安に応じて表示 |
| フォーム | 入力補助 |
| レイアウト | 情報順序変更 |
| バナー | 状況に応じて表示 |
| レコメンド | 行動履歴で変更 |
| アラート | 異常時のみ表示 |
プロンプト例
ユーザーが30秒以上滞在してCTAをクリックしていない場合に表示する補助UIを提案してください。押し売り感を出さず、ユーザーの不安を解消するトーンにしてください。
出力例
補助UI:- 小さなFAQカードを表示- 見出し: 迷っている方へ- 内容: 無料プランでも主要機能を試せます- CTA: 無料プランを見る
コード例
ファイル名: realtime-ui-rule.ts
ファイル機能: リアルタイムUI表示条件を判定する
使用言語: TypeScript
export function shouldShowAssistCard(timeOnPage: number, clickedCTA: boolean) { return timeOnPage > 30 && !clickedCTA;}
予測(推測): リアルタイム最適化はCVR改善に役立つ可能性がありますが、表示頻度が高すぎるとユーザーに負担を与える可能性があります。
5.3 AIベースレイアウト生成
AIベースレイアウト生成では、AIが目的やコンテンツ量に応じてレイアウトを提案します。たとえば、情報量が少ない場合はミニマルな1カラム、比較要素が多い場合はカードグリッド、データ分析画面ではダッシュボードレイアウトなどを生成できます。
ただし、AIにレイアウトを任せる場合でも、デザインシステムのルールを守らせる必要があります。カラム数、余白、カードサイズ、CTA位置、モバイル対応などを指定しなければ、見た目は良くても実装しにくいレイアウトになる可能性があります。
| レイアウト条件 | 指定例 |
|---|---|
| 情報量少 | 1カラム |
| 比較要素あり | 3カラムカード |
| モバイル | 1カラム |
| CTA重視 | CTAを上部と下部に配置 |
| 高級感 | 余白多め |
| 管理画面 | グリッド + テーブル |
| 分析画面 | KPIカード + グラフ |
プロンプト例
BtoB向け分析ダッシュボードのレイアウトを生成してください。上部にKPIカードを4つ、中央にグラフ、下部に詳細テーブルを配置してください。モバイルではカードを縦並びにし、テーブルは横スクロール対応にしてください。
出力例
レイアウト:- Header- KPI Grid: 4 cards- Main Chart Area- Detail Table- Mobile: 1 column layout- Table: horizontal scroll
コード例
ファイル名: dashboard-layout.css
ファイル機能: AI生成レイアウトを実装しやすい形で定義するCSS
使用言語: CSS
.dashboard-layout { display: grid; gap: 24px;}.kpi-grid { display: grid; grid-template-columns: repeat(4, 1fr); gap: 16px;}@media (max-width: 768px) { .kpi-grid { grid-template-columns: 1fr; }}
予測(推測): AIにレイアウト条件を具体的に渡すことで、実装可能でレスポンシブ対応しやすいUI案が生成されやすくなると考えられます。
6. UX設計との関係
UIプロンプトエンジニアリングは、UX設計と切り離せません。AIにUIを生成させる場合でも、最終的に重要なのはユーザーが迷わず理解し、自然に行動できることです。そのため、プロンプトには見た目の条件だけでなく、認知負荷、行動導線、心理的不安、パーソナライズ条件などを含める必要があります。
UX設計との関係を整理すると以下のようになります。
| UX要素 | UIプロンプトで指定する内容 |
|---|---|
| 認知負荷 | 情報量・優先順位 |
| 行動導線 | CTA・次のステップ |
| 不安解消 | FAQ・保証・レビュー |
| 視線誘導 | 見出し・余白・配置 |
| 操作性 | タップ領域・入力補助 |
| 継続率 | 再訪導線・履歴表示 |
| パーソナライズ | ユーザー別表示 |
6.1 認知負荷最適化
認知負荷最適化では、ユーザーが情報を理解する負担を減らします。AIにUIを生成させる場合、情報を多く入れすぎると、見た目は充実していても読みにくいUIになることがあります。特にLPやフォームでは、情報量を整理し、ユーザーが次に何をすべきか分かる状態を作ることが重要です。
プロンプトでは、「情報を整理してください」だけでは曖昧です。たとえば、「見出しは1つ、補足説明は2行以内、CTAは1つ、カードは3つまで」のように、認知負荷を下げる条件を具体的に指定します。これにより、AIは情報を詰め込みすぎず、読みやすいUIを生成しやすくなります。
| 認知負荷要因 | プロンプト指定例 |
|---|---|
| 情報過多 | 要素数を制限 |
| CTA過多 | CTAを1つにする |
| 専門用語 | 初心者向け表現 |
| 長文 | 2行以内にする |
| 視線分散 | 優先順位を明示 |
| 選択肢過多 | 推奨プランを示す |
| 複雑な導線 | 次の行動を1つにする |
プロンプト例
初心者向けのAI分析ツールLPのファーストビューを生成してください。認知負荷を下げるため、見出しは1つ、説明文は2行以内、CTAは1つにしてください。専門用語は避け、初めて見た人でも価値が分かる表現にしてください。
出力例
見出し:AIで、Web改善をもっと分かりやすく説明文:アクセス解析やCVR改善のポイントを、AIが整理して提案します。専門知識がなくても、次にやるべき改善が分かります。CTA:無料で改善案を見る
予測(推測): 認知負荷条件を具体的に指定すると、AIは情報量を抑えた分かりやすいUIコピーを生成しやすくなると考えられます。
6.2 行動導線最適化
行動導線最適化では、ユーザーが次に何をすればよいかを分かりやすくします。AIが生成したUIでよくある問題は、要素は整っているが、ユーザーの次の行動が明確ではないことです。CTAが複数あったり、説明が長すぎたり、重要な導線が下に埋もれたりすると、行動率は下がります。
UIプロンプトでは、主要CTA、補助CTA、導線順序を明確に指定します。たとえば、「主CTAは無料登録、補助CTAは資料を見る」「CTAはファーストビューとセクション末尾に配置」「フォームへの導線を最短にする」といった条件を入れます。
| 導線要素 | 指定例 |
|---|---|
| 主CTA | 無料で始める |
| 補助CTA | 資料を見る |
| CTA数 | 主要CTAは1つ |
| 配置 | ファーストビュー内 |
| フォーム導線 | 1クリックで遷移 |
| 離脱防止 | FAQをCTA近くに配置 |
| モバイル | 固定CTA |
プロンプト例
資料請求LPの行動導線を最適化してください。主CTAは「資料を無料でダウンロード」に統一してください。補助CTAは使わず、フォームまでの導線を最短にしてください。CTA直前に不安解消の一文を入れてください。
出力例
導線:1. 課題提示2. 資料で分かる内容3. 導入メリット4. 不安解消: 入力は1分で完了します5. CTA: 資料を無料でダウンロード
予測(推測): 行動導線を明確に指定すると、AIが生成するUIはCTA中心に整理され、CVR改善に使いやすくなる可能性があります。
6.3 パーソナライズUX生成
パーソナライズUX生成では、ユーザーごとに異なる体験をAIに生成させます。初心者、上級者、再訪ユーザー、購入直前ユーザーでは、必要な情報や導線が異なります。AIはコンテキストを与えれば、ユーザー状態に応じたUIを提案できます。
ただし、パーソナライズはやりすぎると一貫性を失います。プロンプトでは、「変えてよい部分」と「共通で維持する部分」を指定することが重要です。たとえば、CTA文言は変えてよいが、ボタンデザインは統一する、表示順は変えてよいが、ブランドトーンは維持する、といった条件です。
| ユーザー状態 | 生成UI例 |
|---|---|
| 初心者 | 説明多め |
| 上級者 | 詳細機能 |
| 再訪 | 履歴表示 |
| 購入直前 | 保証・FAQ |
| 離脱リスク | サポート導線 |
| 高LTV | 高度機能提案 |
| モバイル | 簡略UI |
プロンプト例
同じSaaSのLPセクションを、初心者向けと上級者向けに分けて生成してください。共通条件として、ブランドトーンは落ち着いたBtoB向けにし、CTAデザインは統一してください。初心者には説明を多めに、上級者には機能比較を重視してください。
出力例
初心者向け:- 課題説明- 導入メリット- 使い方の簡単な流れ上級者向け:- 機能比較- API連携- 詳細な分析機能
予測(推測): パーソナライズ条件を指定すると、AIはユーザー状態に応じたUIを生成できますが、共通ルールを指定しないと一貫性が崩れる可能性があります。
7. デザインシステムとの関係
UIプロンプトエンジニアリングでは、デザインシステムとの連携が重要です。AIにUIを生成させる場合でも、既存のコンポーネント、デザイントークン、ブランドルール、アクセシビリティ基準を守る必要があります。そうしなければ、AIが出力するUIは毎回異なり、プロダクト全体の一貫性が失われます。
関係性を整理すると以下のようになります。
| デザインシステム要素 | UIプロンプトでの役割 |
|---|---|
| コンポーネント | 使用可能部品を制限 |
| デザイントークン | 色・余白・文字を統一 |
| UIパターン | 標準レイアウトを指定 |
| アクセシビリティ | ラベル・コントラスト指定 |
| ブランドトーン | 文体・見た目を統一 |
| 状態設計 | loading/errorなどを制御 |
| ドキュメント | AIへのルール入力元 |
7.1 コンポーネント制御
コンポーネント制御では、AIが使ってよいUI部品を指定します。AIに自由にUIを作らせると、既存のデザインシステムに存在しない部品や、実装しにくいレイアウトを出すことがあります。そのため、使用可能なコンポーネントを限定し、その組み合わせでUIを生成させることが重要です。
たとえば、LPでは Hero、FeatureCard、CTAButton、FAQ、PricingCard だけを使うように指定できます。こうすることで、AI生成UIをそのまま実装しやすくなり、デザインのばらつきも減らせます。
| コンポーネント | 用途 |
|---|---|
| Hero | ファーストビュー |
| FeatureCard | 機能紹介 |
| CTAButton | 行動誘導 |
| FAQ | 不安解消 |
| PricingCard | 料金表示 |
| Testimonial | レビュー |
| Alert | 注意表示 |
プロンプト例
既存デザインシステムのコンポーネントだけを使ってLP構成を生成してください。使用可能コンポーネントは Hero, FeatureCard, CTAButton, FAQ, Testimonial です。新しいコンポーネントは作らないでください。
出力例
LP構成:1. Hero2. FeatureCard x 33. Testimonial4. FAQ5. CTAButton
コード例
ファイル名: component-allowlist.ts
ファイル機能: AIが使用できるコンポーネントを制御する
使用言語: TypeScript
export const componentAllowlist = [ "Hero", "FeatureCard", "CTAButton", "FAQ", "Testimonial",] as const;
予測(推測): コンポーネントを制限すると、AI出力はやや保守的になりますが、実装しやすく一貫性のあるUIになりやすいと考えられます。
7.2 デザイントークン活用
デザイントークン活用では、AIが色、余白、文字サイズ、角丸、影などを自由に決めないようにします。デザインシステムに定義されたトークンを使わせることで、AI生成UIでもブランド一貫性を保てます。特に、複数のAI生成UIを同じプロダクト内で使う場合、トークン制御は重要です。
プロンプトでは、「青を使って」ではなく、「primary tokenをCTAに使用」「surface tokenをカード背景に使用」のように指定すると、実装に近い出力になります。これにより、AI出力をCSSやReactコンポーネントに接続しやすくなります。
| トークン | 用途 |
|---|---|
| color.primary | CTA |
| color.surface | カード背景 |
| color.text | 本文 |
| space.4 | セクション余白 |
| radius.lg | カード角丸 |
| shadow.card | カード影 |
| font.size.base | 本文サイズ |
プロンプト例
以下のデザイントークンを使用して、CTAカードUIを生成してください。primaryはCTAのみに使用し、surfaceはカード背景、textは本文に使用してください。余白はspace.4、角丸はradius.lgを使ってください。
出力例
CTAカード:- 背景: color.surface- 本文: color.text- CTA: color.primary- 余白: space.4- 角丸: radius.lg
コード例
ファイル名: design-tokens.css
ファイル機能: AI生成UIでも使う基本デザイントークンを定義する
使用言語: CSS
:root { --color-primary: #2563eb; --color-surface: #ffffff; --color-text: #111827; --space-4: 16px; --radius-lg: 16px;}
予測(推測): デザイントークンをプロンプトに含めると、AI生成UIの見た目がプロダクト全体と揃いやすくなると考えられます。
7.3 UI一貫性維持
UI一貫性維持では、AIが生成するUIでも、操作ルールや見た目の意味を統一します。AIが毎回違うボタン配置やCTA文言を出すと、ユーザーは操作に迷いやすくなります。特にSaaSやECのように複数画面をまたいで使うサービスでは、一貫性がUX品質に直結します。
プロンプトでは、守るべきルールを明確にします。たとえば、「主要CTAは常に右下またはセクション末尾に配置」「危険操作は赤」「補助CTAはテキストリンク」「フォームエラーは入力欄直下に表示」といった条件です。
| 一貫性ルール | 内容 |
|---|---|
| CTA位置 | セクション末尾に配置 |
| CTA色 | primaryのみ |
| エラー表示 | 入力欄直下 |
| 危険操作 | danger variant |
| 補助操作 | text link |
| 見出し階層 | H2→H3順 |
| 文体 | 丁寧で簡潔 |
プロンプト例
以下のUI一貫性ルールを守ってフォームUIを生成してください。主要CTAはフォーム下部に1つだけ配置してください。エラーメッセージは入力欄の直下に表示してください。危険操作は赤、補助操作はテキストリンクにしてください。
出力例
フォームUI:- 入力欄- 入力欄直下のエラー表示- 補助リンク: 入力例を見る- 主要CTA: 送信する
予測(推測): UI一貫性ルールを明示すると、AI出力のばらつきが減り、複数画面で統一されたUXを作りやすくなると考えられます。
8. AIエージェントUIとの関係
AIエージェントUIとは、AIがユーザーの意図を理解し、必要なタスクを支援または代行するUIです。従来のUIはユーザーがボタンやフォームを操作する前提でしたが、AIエージェントUIでは、AIがユーザーの目的に応じて画面やアクションを提案します。そのため、UIプロンプトエンジニアリングでは、タスク、意図、確認、実行範囲を設計する必要があります。
関係性を整理すると以下のようになります。
| 項目 | 内容 |
|---|---|
| 目的 | AIがタスク中心にUIを構築する |
| 対象 | チャットUI・操作提案・自動実行 |
| 必要要素 | 意図理解・確認UI・権限制御 |
| 強み | 操作負荷を減らせる |
| 課題 | AIの操作範囲を制御する必要がある |
| 関係領域 | AIエージェント・UX・安全設計 |
| 成功条件 | ユーザーが制御できるUIにする |
8.1 AIによるUI構築
AIによるUI構築では、AIがユーザーの目的に応じて必要なUIを組み立てます。たとえば、「売上を確認したい」と入力すると、AIが売上ダッシュボード、期間フィルター、比較グラフ、改善提案カードを表示するようなUIです。ユーザーが画面を探すのではなく、AIが目的に合ったUIを構成します。
この場合、プロンプトでは、AIがどのコンポーネントを使い、どの順序で表示し、どこまで自動で判断してよいかを指定します。AIが勝手に重要な操作まで行わないように、表示と実行の境界を明確にすることも重要です。
| ユーザー意図 | AIが構築するUI |
|---|---|
| 売上確認 | KPIカード・グラフ |
| 問い合わせ対応 | チケット一覧・返信案 |
| LP改善 | ヒートマップ・改善案 |
| 広告改善 | CTR・CPC・提案 |
| 商品比較 | 比較表・レビュー |
| 予約管理 | カレンダー・確認UI |
| 設定変更 | 差分表示・承認UI |
プロンプト例
ユーザーが「今月の売上状況を確認したい」と入力した場合に表示するAIエージェントUIを設計してください。KPIカード、売上推移グラフ、改善提案カードを含めてください。実行操作はせず、分析結果の表示までにしてください。
出力例
AIエージェントUI:- KPIカード: 売上、CVR、平均注文額- 売上推移グラフ- 改善提案カード- 補助CTA: 詳細レポートを見る
予測(推測): AIエージェントUIでは、ユーザーが画面を探す負担が減り、目的に直結したUIを表示しやすくなると考えられます。
8.2 意図理解型UI生成
意図理解型UI生成では、ユーザーの入力文や行動から目的を推測し、それに合ったUIを生成します。たとえば、「解約が増えている理由を知りたい」という入力に対して、AIはチャーン率、セグメント別解約、解約理由、改善施策を表示するUIを作る必要があります。
このとき、AIが意図を誤解すると、まったく違うUIが出る可能性があります。そのため、プロンプトでは、意図の分類、必要な確認、曖昧な場合の質問方法を設計します。特に業務系UIでは、AIが勝手に判断せず、必要に応じてユーザーに確認する設計が重要です。
| 意図 | UI生成例 |
|---|---|
| 原因を知りたい | 分析UI |
| 比較したい | 比較表 |
| 改善したい | 提案カード |
| 実行したい | 確認UI |
| 設定したい | フォームUI |
| 探したい | 検索UI |
| 要約したい | サマリーUI |
プロンプト例
ユーザー入力「解約が増えている理由を知りたい」から意図を推測し、表示すべきUIを生成してください。原因分析が目的なので、チャーン率推移、セグメント別比較、解約理由、改善提案を表示してください。不明点がある場合は実行せず、確認質問を提示してください。
出力例
推定意図:解約原因の分析表示UI:- チャーン率推移グラフ- セグメント別解約率- 解約理由ランキング- 改善提案カード確認質問:分析期間を指定しますか?
予測(推測): 意図分類を含めたプロンプトにすると、AIはユーザー入力から適切な分析UIを生成しやすくなると考えられます。
8.3 タスク中心UI設計
タスク中心UI設計では、画面単位ではなく、ユーザーが達成したいタスクを中心にUIを設計します。AIエージェントUIでは、ユーザーが「どの画面を開くか」ではなく、「何をしたいか」を伝えることが増えます。そのため、UIはページ構造ではなくタスクフローに沿って生成されます。
タスク中心UIでは、ステップ、確認、実行、完了、次の提案までを設計します。たとえば、広告キャンペーンを改善するタスクであれば、現状分析、問題点表示、改善案、実行前確認、反映後のモニタリングまでがUIに含まれます。
| タスク段階 | UI |
|---|---|
| 意図入力 | チャット・検索 |
| 状況分析 | KPI・グラフ |
| 提案 | 改善カード |
| 確認 | 差分表示 |
| 実行 | 承認ボタン |
| 完了 | 結果表示 |
| 継続 | モニタリング |
プロンプト例
広告キャンペーン改善のAIエージェントUIを設計してください。タスクフローは、現状分析、問題点表示、改善案提示、実行前確認、結果モニタリングです。ユーザー承認なしに変更を実行しないでください。
出力例
タスクUI:1. 現状KPIカード2. 問題点リスト3. 改善案カード4. 変更差分プレビュー5. 承認CTA6. 実行後モニタリング
コード例
ファイル名: agent-task-flow.ts
ファイル機能: AIエージェントUIのタスク段階を定義する
使用言語: TypeScript
export const agentTaskFlow = [ "analyze", "detectIssues", "suggestActions", "confirmChanges", "execute", "monitor",] as const;
予測(推測): タスク中心でUIを設計すると、AIエージェントはユーザー目的に沿った流れを作りやすくなります。ただし、承認設計がないと安全性に問題が出る可能性があります。
9. マルチモーダルUIとの関係
マルチモーダルUIとは、テキスト、音声、画像、動画、ジェスチャーなど複数の入力・出力形式を組み合わせたUIです。AI時代では、ユーザーが文章で指示するだけでなく、画像を見せたり、音声で依頼したり、画面上の要素を指し示したりする場面が増えます。UIプロンプトエンジニアリングでは、こうした複数の入力をどのようにUI生成に反映するかを設計します。
関係性を整理すると以下のようになります。
| 入力形式 | UI生成への影響 |
|---|---|
| テキスト | 意図・条件指定 |
| 音声 | ハンズフリー操作 |
| 画像 | 視覚情報の反映 |
| 動画 | 状況理解 |
| ジェスチャー | 操作意図 |
| 位置情報 | 文脈UI |
| デバイス情報 | 表示最適化 |
9.1 音声UI生成
音声UI生成では、ユーザーが音声で入力した内容をもとにUIを生成します。たとえば、「今月の売上を見せて」と話すと、AIが売上ダッシュボードを表示します。音声UIでは、ユーザーが短く曖昧に話すことが多いため、AIが意図を補完しながらUIを作る必要があります。
ただし、音声入力は誤認識が起こる可能性があります。そのため、重要な操作を行う前には確認UIが必要です。UIプロンプトでは、音声入力から生成するUI、確認が必要な操作、曖昧な場合の質問を指定します。
| 音声入力 | UI例 |
|---|---|
| 売上を見せて | 売上ダッシュボード |
| 予約して | 予約確認UI |
| 問い合わせを確認 | チケット一覧 |
| 改善案を出して | 改善カード |
| 詳細を見せて | 詳細パネル |
| 比較して | 比較表 |
| 送信して | 確認ダイアログ |
プロンプト例
音声入力「今月の広告成果を見せて」に対して表示するUIを生成してください。広告成果の概要、CTR、CPC、CVR、改善提案を表示してください。重要な変更操作は含めず、閲覧専用UIにしてください。
出力例
広告成果UI:- 今月の広告費- CTRカード- CPCカード- CVRカード- 改善提案カード- 詳細を見るCTA
予測(推測): 音声UIでは短い入力から意図を補う必要があるため、確認UIや閲覧専用モードの設計が重要になると考えられます。
9.2 テキスト・画像統合UI
テキスト・画像統合UIでは、ユーザーが文章と画像を組み合わせてAIに指示します。たとえば、参考デザイン画像を見せながら「この雰囲気でLPを作って」と依頼するケースです。この場合、AIは画像の色、余白、構成、トーンを理解しつつ、テキストで指定された目的に合わせてUIを生成する必要があります。
プロンプトでは、画像から抽出してよい要素と、真似してはいけない要素を明確にすることが重要です。たとえば、「配色と余白感は参考にするが、レイアウトは新規に設計する」「ブランドロゴや固有要素は使わない」などの制約を入れます。
| 入力 | UI反映 |
|---|---|
| 参考画像 | トーン・余白感 |
| テキスト条件 | 目的・CTA |
| 商品画像 | ビジュアル配置 |
| 競合LP | 構成参考 |
| 手書きワイヤー | レイアウト化 |
| スクリーンショット | 改善提案 |
| ブランド資料 | 色・文体反映 |
プロンプト例
参考画像のミニマルな余白感と落ち着いた配色を参考にして、BtoB SaaSのLPファーストビューを生成してください。ただし、画像内のロゴや固有のレイアウトは使わないでください。目的は無料トライアル獲得です。
出力例
ファーストビュー:- 大きな余白- 落ち着いたグレー背景- シンプルな見出し- 青いCTAボタン- 補足: クレジットカード不要
予測(推測): 画像とテキストを組み合わせることで、AIはビジュアルトーンとUX目的を同時に反映しやすくなります。ただし、参考画像の模倣範囲を制限することが重要です。
9.3 状況別UI切替
状況別UI切替では、入力形式や利用環境に応じてUIを切り替えます。たとえば、ユーザーが音声入力中なら確認中心のUI、画像をアップロードした場合は分析結果UI、モバイルでは簡略UI、PCでは詳細UIを表示します。マルチモーダル時代では、入力方法そのものがUI生成条件になります。
UIプロンプトでは、どの入力形式に対してどのUIを出すかを指定します。これにより、AIは状況に合わせて適切なUIパターンを選びやすくなります。
| 状況 | UI切替例 |
|---|---|
| 音声入力 | 確認カード |
| 画像入力 | 分析結果パネル |
| テキスト入力 | 通常UI |
| モバイル | 簡略UI |
| PC | 詳細UI |
| 低速回線 | 軽量UI |
| エラー時 | 修正UI |
プロンプト例
入力形式に応じてUIを切り替えるルールを提案してください。音声入力の場合は確認カード、画像入力の場合は分析結果パネル、テキスト入力の場合は通常フォームを表示してください。
出力例
UI切替ルール:- voice: ConfirmationCard- image: AnalysisPanel- text: InputForm- mobile: CompactLayout- error: RecoveryPanel
コード例
ファイル名: multimodal-ui-router.ts
ファイル機能: 入力形式に応じて表示UIを切り替える
使用言語: TypeScript
export function resolveMultimodalUI(inputType: "voice" | "image" | "text") { const map = { voice: "ConfirmationCard", image: "AnalysisPanel", text: "InputForm", }; return map[inputType];}
予測(推測): 入力形式ごとのUI切替ルールを設計すると、マルチモーダルUIでも一貫した体験を提供しやすくなると考えられます。
10. Web開発との関係
UIプロンプトエンジニアリングは、Web開発の構造にも影響します。AIがUIを生成する場合、フロントエンドは固定画面を実装するだけでなく、AI出力を受け取り、コンポーネントとして描画する仕組みが必要になります。そのため、React、JSON、API、デザインシステムの連携が重要になります。
Web開発との関係を整理すると以下のようになります。
| 項目 | 内容 |
|---|---|
| フロントエンド | AI出力をUIに変換 |
| API | コンテキストや生成結果を取得 |
| JSON | UIブロック形式 |
| React | 動的コンポーネント描画 |
| CSS | トークン・レスポンシブ制御 |
| 状態管理 | 生成結果・ユーザー状態管理 |
| 品質管理 | バリデーション・fallback |
10.1 フロントエンド構造変化
フロントエンド構造は、AI生成UIによって変化します。従来は、開発者が画面ごとにReactコンポーネントを書き、静的なルーティングで表示していました。しかしAI生成UIでは、AIが出力したJSONやUIブロックを受け取り、それをフロントエンド側で安全にレンダリングする構造が必要になります。
この場合、フロントエンドは「UIを固定実装する場所」から「UIブロックを解釈して表示する場所」へ変わります。許可されたコンポーネントだけをレンダリングし、不正な出力や未知のコンポーネントはfallbackする設計が重要です。
| 従来 | AI時代 |
|---|---|
| 固定画面実装 | 動的ブロック描画 |
| 手動レイアウト | AI出力レイアウト |
| ページ中心 | コンポーネント中心 |
| 静的props | 生成props |
| 手動分岐 | ルールベース分岐 |
| 固定導線 | 状況別導線 |
| 個別実装 | レンダラー実装 |
プロンプト例
AIが出力したJSON UIブロックをReactで描画する構造を提案してください。未知のコンポーネントは表示せず、fallbackを返す設計にしてください。
出力例
構造:- UIBlock型を定義- component名でレンダリング分岐- 許可されていないcomponentはnull- propsを検証して表示
コード例
ファイル名: ui-renderer.tsx
ファイル機能: AI出力のUIブロックをReactコンポーネントとして描画する
使用言語: TypeScript + React
type UIBlock = { component: "Hero" | "CTAButton"; props: Record<string, string>;};export function renderUIBlock(block: UIBlock) { switch (block.component) { case "Hero": return <section>{block.props.title}</section>; case "CTAButton": return <button>{block.props.text}</button>; default: return null; }}
予測(推測): AI出力を直接HTMLとして描画するより、許可コンポーネントに変換して描画する方が安全性と保守性が高くなると考えられます。
10.2 API連携強化
API連携強化では、AIに渡すコンテキストやAIから受け取るUI出力をAPIで管理します。たとえば、ユーザー状態、行動履歴、セグメント、A/Bテスト条件をAPI経由で取得し、それをAIプロンプトに組み込みます。AIから返ってきたUIブロックもAPI経由で保存・検証・配信できます。
この構造では、フロントエンドだけでなくバックエンド側の設計も重要になります。どのデータをAIに渡すか、個人情報を含めないか、生成結果をキャッシュするか、品質検証を行うかなどを設計する必要があります。
| API役割 | 内容 |
|---|---|
| コンテキスト取得 | ユーザー状態 |
| 行動履歴取得 | 閲覧・クリック |
| AI生成依頼 | プロンプト送信 |
| 結果保存 | UI JSON保存 |
| 検証 | schema validation |
| 配信 | フロントへ返却 |
| ログ | 改善分析 |
プロンプト例
AI生成UIのAPI構造を提案してください。ユーザーコンテキストを取得し、AIに送信し、返ってきたUI JSONを検証してフロントエンドへ返す流れにしてください。
出力例
APIフロー:1. getUserContext2. buildPrompt3. requestAI4. validateUIJson5. returnBlocks6. logGeneration
コード例
ファイル名: generate-ui-api.ts
ファイル機能: AI生成UIのAPI処理フローを表す疑似コード
使用言語: TypeScript
export async function generateUI(userId: string) { const context = await getUserContext(userId); const prompt = buildPrompt(context); const aiResult = await requestAI(prompt); const validated = validateUIJson(aiResult); return validated;}
予測(推測): APIでコンテキストと生成結果を管理すると、AI生成UIをプロダクトに組み込みやすくなります。ただし、データ管理と検証設計が重要になります。
10.3 AI推論統合
AI推論統合では、ユーザーの状態や行動をもとにAIがUI生成や改善提案を行います。たとえば、離脱リスクが高いユーザーには補助情報を表示し、購入直前ユーザーには保証情報を強調するなど、推論結果をUIに反映します。
このとき、AI推論結果をそのままUIに反映するのではなく、ルールや閾値を設けることが重要です。推論はあくまで予測であり、誤る可能性があります。そのため、UIプロンプトでは「推論結果をどう扱うか」「確信度が低い場合はどうするか」を設計します。
| 推論結果 | UI反映 |
|---|---|
| 離脱リスク高 | 補助カード |
| 購入意欲高 | CTA強調 |
| 価格不安 | FAQ表示 |
| 初心者 | ガイド表示 |
| 上級者 | 詳細表示 |
| エラー発生 | 修正UI |
| 確信度低 | 確認質問 |
プロンプト例
AI推論結果をもとにUIを切り替えるルールを提案してください。離脱リスクが高い場合は補助カード、価格不安がある場合はFAQ、確信度が低い場合は確認質問を表示してください。
出力例
推論UIルール:- churnRisk: AssistCard- priceConcern: PricingFAQ- highIntent: StrongCTA- lowConfidence: ClarifyingQuestion
コード例
ファイル名: inference-ui-rule.ts
ファイル機能: AI推論結果に応じて表示UIを決定する
使用言語: TypeScript
type Inference = { churnRisk: boolean; priceConcern: boolean; confidence: number;};export function resolveInferenceUI(inference: Inference) { if (inference.confidence < 0.6) return "ClarifyingQuestion"; if (inference.churnRisk) return "AssistCard"; if (inference.priceConcern) return "PricingFAQ"; return "DefaultUI";}
予測(推測): AI推論をUIに統合するとパーソナライズ精度が高まる可能性がありますが、確信度が低い場合のfallback設計が重要です。
11. UI品質管理
UI品質管理では、AIが生成したUIが実務で使える品質になっているかを確認します。AI出力は便利ですが、毎回正しいとは限りません。見た目が整っていても、CTAが多すぎる、アクセシビリティが不足している、ブランドトーンが合わない、UX導線が不明確といった問題が起こる可能性があります。
品質管理の観点を整理すると以下のようになります。
| 品質観点 | 内容 |
|---|---|
| 一貫性 | デザインシステムに合っているか |
| UX | 迷わず行動できるか |
| アクセシビリティ | 読みやすい・使いやすいか |
| 出力形式 | 実装可能か |
| 安全性 | 危険な出力がないか |
| ブランド | トーンが合っているか |
| 再現性 | 同条件で安定するか |
11.1 UI一貫性管理
UI一貫性管理では、AIが生成するUIがデザインシステムやブランドルールに沿っているかを確認します。AIが毎回異なる色、余白、CTA配置を出すと、プロダクト全体のUXが不安定になります。そのため、プロンプトには一貫性ルールを含める必要があります。
一貫性管理では、使ってよいコンポーネント、使ってよいトークン、CTA配置、エラー表示、フォームラベルなどをチェックします。AI出力後に自動チェックする仕組みを作ると、品質管理がしやすくなります。
| チェック項目 | 内容 |
|---|---|
| 色 | トークン使用 |
| CTA | 数・位置 |
| コンポーネント | allowlist確認 |
| 見出し | 階層確認 |
| エラー | 表示位置 |
| 文体 | ブランドトーン |
| レスポンシブ | SP対応 |
プロンプト例
以下のUI案がデザインシステムに沿っているかチェックしてください。CTA数、色、コンポーネント、見出し階層、フォームラベルの観点で問題点を指摘してください。
出力例
チェック結果:- CTAが2つあり、主要CTAが不明確- primary colorが見出しにも使われている- FormLabelが不足している- 見出し階層は問題なし
予測(推測): AIに生成だけでなくチェックも行わせることで、UI品質管理の初期レビューを効率化できる可能性があります。
11.2 出力品質制御
出力品質制御では、AIが生成した内容が使える形式になっているかを管理します。たとえば、Reactコードとして出力する場合はコンポーネント名、props、型、アクセシビリティ属性が必要です。JSONで出力する場合はschemaに合っている必要があります。
プロンプトでは、出力形式を厳密に指定し、不要な説明を避けることも重要です。システムで利用する場合、文章が混ざるとパースしにくくなります。そのため、「JSONのみで出力」「component, props, priorityを含める」などの条件を入れます。
| 出力品質 | 指定例 |
|---|---|
| JSON形式 | schema指定 |
| React形式 | props型指定 |
| HTML形式 | class指定 |
| 表形式 | 列名指定 |
| Markdown | 見出し指定 |
| 説明量 | 必要最小限 |
| fallback | 未対応時の処理 |
プロンプト例
UIブロックをJSONのみで出力してください。各ブロックには component, props, priority, uxIntent を含めてください。説明文はJSON外に出さないでください。
出力例
[ { "component": "Hero", "props": { "title": "AIでUI改善を高速化", "ctaText": "無料で試す" }, "priority": "high", "uxIntent": "初回行動を促す" }]
コード例
ファイル名: ui-json-validator.ts
ファイル機能: AI出力JSONの最低限の構造を検証する
使用言語: TypeScript
type UIBlock = { component: string; props: Record<string, unknown>; priority: "low" | "medium" | "high"; uxIntent: string;};export function isValidUIBlock(block: UIBlock) { return Boolean(block.component && block.props && block.uxIntent);}
予測(推測): 出力形式を厳密に制御すると、AI生成UIをシステムに接続しやすくなります。ただし、柔軟な発想はやや制限される可能性があります。
11.3 UX品質維持
UX品質維持では、AIが生成したUIがユーザーにとって使いやすいかを確認します。見た目や構造が整っていても、ユーザーが迷う、情報が多すぎる、CTAが分かりにくい、不安が解消されないといった問題があれば、良いUIとは言えません。
UIプロンプトでは、UX評価条件を含めることが重要です。たとえば、「認知負荷を下げる」「CTAを明確にする」「不安解消要素をCTA近くに配置する」「モバイルでも操作しやすくする」といった条件です。
| UX品質 | チェック内容 |
|---|---|
| 分かりやすさ | 価値がすぐ伝わるか |
| 行動しやすさ | CTAが明確か |
| 不安解消 | FAQ・保証があるか |
| 操作性 | モバイル対応 |
| 情報量 | 多すぎないか |
| 視線誘導 | 優先順位が見えるか |
| 継続性 | 次の行動があるか |
プロンプト例
以下のLP UI案をUX品質の観点でレビューしてください。認知負荷、CTA明確性、不安解消、モバイル操作性、情報量の観点で改善点を出してください。
出力例
改善点:- CTAが下部にしかないため、ファーストビューにも配置する- 説明文が長いため、3つの要点に分ける- 料金不安を減らすFAQをCTA前に追加する- モバイルではカードを1列にする
予測(推測): AIをUXレビューにも使うことで、UI生成と改善提案を同じワークフローで回しやすくなると考えられます。
12. UIプロンプト設計で重要な要素
UIプロンプト設計では、意図、制約条件、コンテキストの3つが特に重要です。この3つが不足すると、AIは見た目だけのUIや一般的なUIを出力しやすくなります。逆に、この3つが明確であれば、AIは目的に合ったUIを生成しやすくなります。
重要要素を整理すると以下のようになります。
| 要素 | 内容 |
|---|---|
| 意図定義 | なぜそのUIを作るのか |
| 制約条件 | 何を守るべきか |
| コンテキスト | どの状況で使うか |
| 出力形式 | どう返すか |
| 評価条件 | 何で判断するか |
| 禁止条件 | 何を避けるか |
| fallback | 失敗時どうするか |
12.1 意図定義
意図定義では、UIが何を達成するためのものかを明確にします。たとえば、登録率を上げたいのか、購入不安を減らしたいのか、フォーム完了率を高めたいのかによって、必要なUIは変わります。意図が曖昧だと、AIは表面的に整ったUIを出すだけになります。
プロンプトでは、「目的はCVR改善」「ユーザーの不安を減らす」「初回行動を促す」のように、UIの役割を明示します。さらに、どのユーザー行動を起こしたいのかまで書くと、より精度が上がります。
| 意図 | UI方向性 |
|---|---|
| CVR改善 | CTA明確化 |
| 不安解消 | FAQ・保証 |
| 理解促進 | 図解・説明 |
| 継続率向上 | 次の行動 |
| 離脱防止 | 補助導線 |
| 比較支援 | 比較表 |
| 入力完了 | フォーム補助 |
プロンプト例
目的はフォーム送信完了率を高めることです。ユーザーの入力不安を減らし、必要最小限の項目で送信できるフォームUIを生成してください。
出力例
フォームUI:- 名前- メール- 相談内容- 入力例- 即時エラー表示- CTA: 相談内容を送信する
予測(推測): 意図を明確にすると、AIはUI要素を目的に合わせて選びやすくなると考えられます。
12.2 制約条件設計
制約条件設計では、AIが守るべきルールを定義します。制約がないと、AIは自由にUIを生成しますが、その出力がブランドや実装要件に合うとは限りません。特に、実務で使うUIでは、コンポーネント、色、余白、CTA数、レスポンシブ条件などを指定する必要があります。
制約条件は、AIの創造性を妨げるためではなく、品質を安定させるためにあります。守るべきルールが明確であれば、AIはその範囲内で最適なUIを提案できます。
| 制約 | 例 |
|---|---|
| コンポーネント | Button, Cardのみ |
| CTA | 1つだけ |
| 色 | tokenのみ |
| 文字量 | 2行以内 |
| レイアウト | PC 3カラム、SP 1カラム |
| 禁止 | 過剰装飾 |
| アクセシビリティ | label必須 |
プロンプト例
以下の制約を守って、CTAセクションを生成してください。CTAは1つのみ、色はprimary tokenのみ、説明文は2行以内、モバイルでは1カラムにしてください。
出力例
CTAセクション:- 見出し- 2行説明- CTAボタン1つ- モバイルでは縦並び
コード例
ファイル名: prompt-constraints.ts
ファイル機能: UIプロンプトで使う制約条件を定義する
使用言語: TypeScript
export const promptConstraints = { maxPrimaryCTA: 1, maxDescriptionLines: 2, allowedColors: ["primary", "surface", "text"], mobileLayout: "one-column",};
予測(推測): 制約条件を定義すると、AI出力のばらつきが減り、実装やレビューがしやすくなると考えられます。
12.3 コンテキスト設計
コンテキスト設計では、AIがUIを生成するために必要な背景情報を整理します。対象ユーザー、行動履歴、デバイス、利用目的、現在の状態などを含めることで、AIはより適切なUIを生成できます。コンテキストが不足すると、誰にでも当てはまる一般的なUIになりやすいです。
良いコンテキスト設計では、情報を詰め込みすぎないことも重要です。AIに渡す情報が多すぎると、重要な条件が埋もれる可能性があります。そのため、UI生成に直接関係する情報に絞って渡すことが大切です。
| コンテキスト | 例 |
|---|---|
| ユーザー | 初心者 |
| 目的 | 無料登録 |
| 状態 | 比較中 |
| 行動 | 料金ページ閲覧 |
| デバイス | モバイル |
| 不安 | 価格 |
| 必要UI | FAQ・保証 |
プロンプト例
ユーザーはモバイルで料金ページを閲覧中です。料金への不安があり、まだCTAをクリックしていません。このコンテキストに合わせて、料金ページ下部のUIを生成してください。
出力例
料金ページ下部:- よくある質問- 返金保証- 無料トライアル説明- CTA: 無料で試してから判断する
予測(推測): コンテキストを絞って渡すことで、AIはユーザー状態に合ったUIを生成しやすくなると考えられます。
13. UIプロンプトエンジニアリングでよくある失敗
UIプロンプトエンジニアリングでよくある失敗は、AIに対する指示が曖昧なままUI生成を依頼してしまうことです。AIはそれらしいUIを返すことができますが、目的や制約が不足していると、実務で使いにくい出力になりやすいです。この章では、失敗パターンごとに「良くないプロンプト」と「改善されたプロンプト」を示します。
13.1 出力条件不足
出力条件不足とは、AIに何をどの形式で返してほしいかを指定していない状態です。たとえば、「LPを作ってください」だけでは、AIは文章案を返すのか、構成案を返すのか、HTMLを返すのか判断できません。結果として、実装やレビューに使いにくい出力になります。
良くないプロンプト例
LPを作ってください。
改善されたプロンプト例
BtoB SaaSの無料トライアル獲得用LP構成を作成してください。出力は「セクション名」「UI要素」「CTA」「UX意図」の表形式にしてください。対象ユーザーは中小企業のマーケティング担当者です。
出力例
- Hero: 価値訴求、CTA、補足情報- Feature: 主要機能3つ- Proof: 導入実績- FAQ: 不安解消
予測(推測): 出力形式を指定するだけで、AIの回答は実務で整理しやすい形になりやすいです。
13.2 UX設計不足
UX設計不足とは、見た目や構成だけを指示し、ユーザー行動や心理負荷を考慮していない状態です。AIは見た目の整ったUIを作ることはできますが、UX条件を指定しないと、CTAが弱い、情報量が多すぎる、導線が分かりにくいUIになる可能性があります。
良くないプロンプト例
おしゃれなフォームUIを作ってください。
改善されたプロンプト例
問い合わせ完了率を高めるフォームUIを作ってください。入力項目は最小限にし、入力例、即時エラー表示、送信前の安心文言を含めてください。目的はユーザーの入力不安を減らすことです。
出力例
フォーム:- 名前- メール- 相談内容- 入力例- エラー表示- CTA: 相談する
予測(推測): UX目的を含めることで、AIは見た目だけでなく行動完了率を意識したUIを生成しやすくなります。
13.3 UI一貫性崩壊
UI一貫性崩壊は、AIが毎回異なるデザインやコンポーネントを出してしまう問題です。デザインシステムやコンポーネント制約を指定しない場合、AIは自由にUIを提案するため、プロダクト全体の統一感が崩れる可能性があります。
良くないプロンプト例
自由に良い感じのCTAセクションを作ってください。
改善されたプロンプト例
既存デザインシステムに沿ってCTAセクションを作ってください。使用可能コンポーネントは SectionTitle, TextBlock, CTAButton のみです。CTAButtonはprimary variantを使用し、CTAは1つだけにしてください。
出力例
CTAセクション:- SectionTitle- TextBlock- CTAButton(primary)
予測(推測): コンポーネント制約を入れることで、AI出力の自由度は下がりますが、UI一貫性は維持しやすくなります。
13.4 コンテキスト不足
コンテキスト不足とは、対象ユーザーや利用状況を伝えずにAIへUI生成を依頼することです。たとえば、初心者向けなのか、上級者向けなのか、モバイル向けなのか、購入直前なのかが分からないと、AIは一般的なUIを出しやすくなります。
良くないプロンプト例
料金ページを改善してください。
改善されたプロンプト例
料金ページを改善してください。ユーザーは料金ページを2回閲覧していますが、CTAをクリックしていません。価格への不安がある可能性があるため、FAQ、保証、無料トライアル情報をCTA近くに配置してください。
出力例
改善案:- CTA直前に料金FAQ- 返金保証表示- 無料トライアル説明- CTA文言を「無料で試してから判断する」に変更
予測(推測): コンテキストを追加すると、AIはユーザーの迷いや不安に合わせた改善案を出しやすくなります。
13.5 AI依存だけで設計する
AI依存だけで設計する失敗は、AIが出したUIを検証せずにそのまま使うことです。AIの出力は便利ですが、必ず正しいとは限りません。UX、アクセシビリティ、ブランド、実装可能性、法務リスクなどは人間が確認する必要があります。
良くないプロンプト例
このAIが作ったUIをそのまま使える形にしてください。
改善されたプロンプト例
以下のAI生成UIをレビューしてください。UX、アクセシビリティ、CTA明確性、デザインシステム適合性、実装可能性の観点で問題点と改善案を出してください。
出力例
レビュー:- CTAが複数あり優先度が不明- 色がデザイントークン外- フォームラベルが不足- モバイル時の表示条件が未定義
予測(推測): AI生成UIは初稿として有効ですが、品質レビューと制約チェックを組み合わせることで実務利用しやすくなると考えられます。
14. 今後の進化
UIプロンプトエンジニアリングは、今後さらに重要になると考えられます。AIがUIを提案するだけでなく、リアルタイムで最適化し、ユーザーごとに異なる画面を生成し、AIエージェントがタスク単位でUIを構築する時代に近づいているからです。
今後の進化を整理すると以下のようになります。
| 進化領域 | 内容 |
|---|---|
| AI自動UI生成 | 画面構成をAIが生成 |
| リアルタイム最適化 | 行動に応じてUI変更 |
| 自律型UI | AIが改善案を出す |
| エージェント統合 | タスク中心UI |
| マルチモーダル | 音声・画像連携 |
| デザインシステム連携 | AIがルール参照 |
| UX自動評価 | AIが改善点を検出 |
14.1 AI自動UI生成
AI自動UI生成では、AIがユーザーの目的やデータをもとに画面構成を自動で生成します。たとえば、LP、管理画面、フォーム、ダッシュボードなどを、プロンプトやコンテキストから生成する流れです。今後は、Figmaやコードだけでなく、プロンプトがUI制作の起点になる場面が増える可能性があります。
ただし、自動生成には制約が必要です。AIが自由に生成すると、品質が安定しません。そのため、デザインシステム、コンポーネント制約、出力schemaを組み合わせることが重要になります。
プロンプト例
AI自動UI生成の流れを提案してください。入力はユーザー目的、対象ユーザー、使用可能コンポーネント、デザイントークンです。出力はUI JSONにしてください。
出力例
生成フロー:1. 目的入力2. コンテキスト取得3. UIプロンプト生成4. UI JSON出力5. schema検証6. React描画
予測(推測): 今後は、プロンプトからUI構成を生成し、それをコードに接続する開発フローが増える可能性があります。
14.2 リアルタイムUX最適化
リアルタイムUX最適化では、ユーザー行動に応じてUIが即時に変化します。たとえば、フォームで迷っているユーザーに入力補助を表示したり、CTA未クリックのユーザーにFAQを出したり、購入直前ユーザーに保証を強調したりします。
この仕組みでは、AIがユーザー状態を推測し、適切なUIを選ぶ必要があります。ただし、推測が誤る可能性もあるため、確信度が低い場合は控えめな補助にするなどの設計が重要です。
プロンプト例
リアルタイムUX最適化のUIルールを作成してください。CTA未クリック、フォーム途中離脱、価格不安、確信度低の4条件に対して表示UIを提案してください。
出力例
CTA未クリック: FAQカードフォーム途中離脱: 入力補助価格不安: 料金FAQ確信度低: 確認質問
予測(推測): リアルタイムUX最適化はCVR改善に役立つ可能性がありますが、過度な介入はユーザー体験を悪化させる可能性があります。
14.3 自律型UI生成
自律型UI生成では、AIがユーザー行動を分析し、改善案を出し、UI変更候補を生成するようになります。たとえば、ヒートマップやCVRデータを見て、CTA位置の改善案やフォーム短縮案を自動生成する流れです。
ただし、AIが自律的にUIを変える場合でも、人間の承認やA/Bテストが必要です。AIが良いと判断した変更が、ブランドや長期UXに悪影響を与える可能性もあるからです。
プロンプト例
LPのCVRが低下している場合に、AIが自律的に生成すべき改善UI候補を提案してください。ただし、公開前に人間の承認とA/Bテストを挟む前提にしてください。
出力例
改善候補:- CTA位置変更- ファーストビューコピー短縮- FAQ追加- フォーム項目削減- モバイル固定CTA追加
予測(推測): 自律型UI生成は改善速度を高める可能性がありますが、承認フローと検証設計がなければリスクも高くなります。
14.4 AIエージェント統合UI
AIエージェント統合UIでは、AIがユーザーの代わりにタスクを進め、その過程で必要なUIを生成します。たとえば、広告改善、レポート作成、予約、問い合わせ対応などで、AIが画面を組み立てながら作業を支援します。
この領域では、UIは固定画面ではなく、タスクフローに応じて生成されるものになります。UIプロンプトエンジニアリングでは、AIがどの操作を提案し、どこで確認を取り、どこまで自動実行してよいかを設計する必要があります。
プロンプト例
AIエージェントが広告改善を支援するUIを設計してください。分析、改善案、変更差分、承認、実行後モニタリングの順で表示してください。承認なしに変更を実行しないでください。
出力例
エージェントUI:1. 現状分析2. 問題点3. 改善案4. 差分プレビュー5. 承認CTA6. 実行後レポート
予測(推測): AIエージェント統合UIでは、画面設計よりもタスク設計と確認設計が重要になると考えられます。
15. UIプロンプトエンジニアリングの本質
UIプロンプトエンジニアリングの本質は、AIにUIを作らせることではありません。重要なのは、AIが適切なUIを生成できる条件を設計することです。つまり、UIそのものを直接作るだけでなく、目的、文脈、制約、出力形式、評価条件を設計し、AIが安定して良いUIを生成できる状態を作ることが本質です。
まず、全体像を整理します。
| 観点 | 内容 |
|---|---|
| 本質 | AIがUIを生成できる条件を設計する |
| 対象 | プロンプト・制約・文脈・出力形式 |
| 目的 | UI生成の品質と再現性を高める |
| 重要要素 | UX意図・デザインシステム・コンテキスト |
| 強み | 動的UIや生成UIに対応しやすい |
| 課題 | 出力制御と品質管理が難しい |
| 成功条件 | AI出力を評価・改善できる仕組み |
さらに、実務で判断すべきポイントは以下の通りです。
| 判断軸 | 内容 |
|---|---|
| 目的 | 何のためのUIか |
| ユーザー | 誰に向けたUIか |
| 文脈 | どの状況で使うか |
| 制約 | 何を守るべきか |
| 出力 | どの形式で返すか |
| 評価 | 何をもって良いUIとするか |
| 改善 | 出力をどう検証するか |
15.1 UIそのものではなく「生成条件」を設計することが重要
UIプロンプトエンジニアリングでは、UIそのものだけでなく、AIがUIを生成するための条件を設計することが重要です。どのユーザーに、どの目的で、どの制約の中で、どのような出力を求めるのかを明確にすることで、AIは実務に近いUIを生成しやすくなります。
単に「LPを作ってください」と依頼するのではなく、「BtoB SaaS向け」「無料トライアル獲得」「CTAは1つ」「初心者にも分かる」「表形式で出力」といった条件を含める必要があります。この条件設計こそが、UIプロンプトエンジニアリングの中心です。
| 悪い設計 | 良い設計 |
|---|---|
| UIを作って | 目的を指定 |
| いい感じに | 制約を指定 |
| おしゃれに | トーンを指定 |
| 使いやすく | UX条件を指定 |
| 任せる | 出力形式を指定 |
プロンプト例
BtoB SaaS向けの無料トライアル獲得LPを生成してください。対象はマーケティング担当者です。CTAは1つにし、導入不安を減らすFAQをCTA近くに配置してください。出力はセクション構成、UI要素、UX意図の表形式にしてください。
予測(推測): 生成条件を明確にするほど、AI出力は目的に合いやすくなり、レビューや実装にも使いやすくなると考えられます。
15.2 固定画面ではなく動的体験を設計する必要がある
AI時代のUIでは、固定画面だけでなく、ユーザー状態に応じて変化する動的体験を設計する必要があります。初回ユーザー、再訪ユーザー、比較中ユーザー、購入直前ユーザーでは、必要な情報やCTAが異なります。UIプロンプトでは、こうした変化条件を設計します。
動的体験を設計するには、状態ごとのUIルールが必要です。どの状態で説明を増やすのか、どの状態でCTAを強調するのか、どの状態でFAQを表示するのかを明確にします。
| ユーザー状態 | UI変化 |
|---|---|
| 初回 | 説明多め |
| 再訪 | 履歴表示 |
| 比較中 | 比較表 |
| 購入直前 | 保証・FAQ |
| 離脱リスク | 補助表示 |
| 上級者 | 詳細情報 |
| モバイル | 簡略UI |
プロンプト例
ユーザー状態に応じて変化するLP UIを設計してください。初回ユーザー、比較中ユーザー、購入直前ユーザーの3パターンを出してください。共通CTAは「無料で試す」にしてください。
予測(推測): 状態別UIを設計すると、AIは単一画面ではなく、ユーザー文脈に応じた複数UI案を生成しやすくなります。
15.3 AI出力を制御できる構造が必要
AI出力を制御できる構造がなければ、UI品質は安定しません。プロンプトだけでなく、コンポーネント制約、デザイントークン、JSON schema、バリデーション、fallback設計が必要です。AI出力は便利ですが、常に正しいとは限らないため、制御と検証が欠かせません。
特に実装と接続する場合は、AIに自由なHTMLを出させるよりも、許可されたUIブロックをJSONで出力させ、それをフロントエンド側で描画する方が安全です。
| 制御要素 | 内容 |
|---|---|
| allowlist | 使用可能部品 |
| schema | 出力構造 |
| token | 色・余白 |
| validator | 出力検証 |
| fallback | 失敗時表示 |
| review | 人間確認 |
| logging | 改善分析 |
プロンプト例
UIをJSON形式で出力してください。componentは Hero, FeatureCard, CTAButton のみ使用可能です。schemaに合わない項目は出力しないでください。
コード例
ファイル名: ui-output-schema.ts
ファイル機能: AI出力UIの構造を制御する型定義
使用言語: TypeScript
export type UiOutputBlock = { component: "Hero" | "FeatureCard" | "CTAButton"; props: Record<string, string>; uxIntent: string;};
予測(推測): AI出力を構造化して制御すると、UI生成を安全にプロダクトへ組み込みやすくなると考えられます。
15.4 UX一貫性を維持しながら柔軟性を持たせる必要がある
UIプロンプトエンジニアリングでは、柔軟性と一貫性の両立が重要です。AIによってユーザーごとにUIを変化させられる一方で、変化しすぎるとユーザーが迷います。CTAの意味、色の使い方、エラー表示、フォーム操作などは一貫している必要があります。
そのため、プロンプトでは「変えてよい部分」と「変えてはいけない部分」を明確にします。たとえば、説明文や表示順は変えてよいが、CTAデザインや操作ルールは維持する、といった指定が必要です。
| 変えてよい部分 | 維持すべき部分 |
|---|---|
| 説明量 | CTAの役割 |
| 表示順 | 色の意味 |
| FAQ内容 | エラー表示位置 |
| 補助情報 | フォームルール |
| 推奨表示 | ブランドトーン |
プロンプト例
ユーザー状態に応じてLPセクションを変化させてください。ただし、CTAデザイン、ブランドトーン、フォームルール、色の意味は全パターンで統一してください。
予測(推測): 柔軟性と一貫性の境界を明示すると、AI生成UIでもプロダクト全体のUX品質を保ちやすくなると考えられます。
15.5 「AIが最適UIを生成できる状態」を作ることが本質
UIプロンプトエンジニアリングの最終的な目的は、AIが最適UIを生成できる状態を作ることです。そのためには、プロンプト、コンテキスト、制約、デザインシステム、出力形式、評価指標がつながっている必要があります。AIに依頼するだけではなく、AIが良い判断をできる環境を整えることが本質です。
この状態を作ることで、UI生成、UX改善、A/Bテスト、パーソナライズ、AIエージェントUIがつながります。AIは単なるデザイン補助ではなく、動的なUX設計の一部として機能するようになります。
| 本質要素 | 内容 |
|---|---|
| プロンプト | 意図を伝える |
| コンテキスト | 状況を伝える |
| 制約 | 品質を守る |
| 出力形式 | 実装と接続する |
| 評価 | 改善につなげる |
| デザインシステム | 一貫性を保つ |
| 人間レビュー | 最終品質を担保 |
プロンプト例
以下の条件をもとに、AIが最適UIを生成するためのプロンプトテンプレートを作成してください。目的、対象ユーザー、コンテキスト、制約条件、出力形式、UX評価条件を必ず含めてください。
出力例
プロンプトテンプレート:- 目的:- 対象ユーザー:- ユーザー状態:- 使用可能コンポーネント:- デザイン制約:- UX条件:- 出力形式:- 評価基準:
予測(推測): プロンプトテンプレートを整備すると、チーム内でAIを使ったUI生成の品質を揃えやすくなり、継続的な改善にもつながると考えられます。
おわりに
UIプロンプトエンジニアリングは、AI時代の新しいUI設計手法です。単にAIへ「UIを作って」と依頼するのではなく、目的、ユーザー、文脈、制約、出力形式、UX条件を整理し、AIが適切なUIを生成できる状態を作ることが重要です。
生成UIやAIエージェントが普及するほど、UIは固定画面ではなく、状況に応じて変化するものになります。そのため、プロンプト設計、コンテキスト制御、デザインシステム連携、出力品質管理が必要になります。AIがUIを生成する時代では、人間の役割は画面を一つずつ作ることだけではなく、AIが良いUIを作れる条件を設計することへ広がります。
特に重要なのは、コンテキスト設計と制御設計です。ユーザー状態や行動履歴を正しく反映し、使用可能コンポーネントやデザイントークンを制限することで、AI生成UIの品質を安定させることができます。さらに、出力をJSONやReactに接続できる形で管理すれば、実装との連携もしやすくなります。
一方で、AIに依存しすぎることは避ける必要があります。AIが生成したUIは必ずUX、アクセシビリティ、ブランド、実装可能性の観点で確認する必要があります。UIプロンプトエンジニアリングの本質は、AIに任せることではなく、AIと人間が協力して、ユーザーにとって最適な体験を作れる状態を設計することにあります。
EN
JP
KR