AIに「モダンでプロフェッショナルなヘアデザインサービスの紹介・予約サイトを作って」と依頼すると、メインビジュアル、メニュー、スタイリスト紹介、口コミ、予約フォームまで揃ったページが生成されるかもしれません。しかし、要素が揃っていることと、体験として正しいことは別です。
サービスの違いを理解する前に「今すぐ予約」を迫る。美しい写真の一方で、料金の目安や所要時間、髪の状態による制約を見えにくくする。初めてカラーをする人に専門用語の理解を任せる。これらは単なる見た目の問題ではありません。コンテキストが不足したために、AIがチームに代わって下したプロダクト判断です。
AIが画面を生成するとき、デザイン判断も行われている
これまで、調査レポート、要件、ジャーニーマップ、デザインシステムは人が読み、議論と反復を通じてインターフェースへ変換してきました。生成AIはその流れを短縮します。自然言語による一つの依頼から、情報設計、コンテンツの順序、操作パターン、ビジュアルまで同時に作れます。
ただしAIには、どの判断がブランドの意図で、どれが単に頻出するパターンなのか判別できません。機能一覧だけを渡せば、「ウェブサイトらしく見える」一般的な形で空白を埋めます。その結果、使えて見栄えも良い一方、特定のユーザーやサービスの現実とは結びつかない画面が生まれます。
UX Contextとは何か
UX Context（UXコンテキスト）は、すべての調査資料を巨大なPromptに貼り付けることでも、単に仕様書を長くすることでもありません。ユーザーは誰か、何を達成したいか、何を不安に感じるか、サービスはどう動くか、ブランドはどう語るか、そして許容できない結果は何か。生成結果を実際に左右する情報と判断を選び、構造化したものです。
インタビュー、ワークショップ、サポート履歴、デザイナーの頭の中に散在する暗黙の判断を、AIが使え、チームが検証できる共通基盤へ変えることに価値があります。
AI-ready UX Contextに含めるべきもの
1. ユーザーと利用状況
「18〜45歳で美容に関心がある」だけでは不十分です。どのような場面で訪れ、何を知っていて、何を心配しているのかを記述します。たとえば「初めてカラーをする。髪の傷みと追加料金が不安で、予約前に自分に合う方法と相談の必要性を知りたい」と具体化します。
2. タスク、意思決定、成功条件
ページの目的は、すべての情報を並べることではなく、ユーザーの意思決定を助けることです。適切なサービスを見つける、料金の目安を理解する、スタイリストを選ぶ、予約を完了する、あるいは予約より先に相談すべきだと判断できることが成功になります。
3. コンテンツの優先順位
どの情報を先に見せるか、その理由まで示します。ヘアサロンでは作品写真が信頼につながりますが、料金、時間、対象条件が深い場所に隠れていれば、意思決定に必要な安心感は得られません。
4. フロー、状態、例外
正常系の生成は簡単です。実際の体験には空き枠なし、閉店時間を超える施術、担当者の休暇、写真アップロードの失敗、予約の重複、キャンセル規定などがあります。重要な状態と、そのとき画面が何をすべきかをContextに含めます。
5. ブランド原則と検証可能な制約
「上質でプロフェッショナル」だけでは抽象的です。「説得的なコピーより先に明確な情報を出す」「仕上がりを保証しない」「開始価格だけでなく代表的な追加条件を示す」「主要操作はモバイルで片手でも届きやすくする」のように検証できる表現へ変えます。
| 一般的なPrompt | AI-ready UX Context |
|---|---|
| プロフェッショナルなヘア予約サイトを作る。 | 初めてカラーをする人が予約前に適合性を判断できるよう、料金帯、所要時間、追加料金の条件、事前相談の選択肢を示す。 |
| ミニマルで高級感のあるデザインにする。 | 作品写真で信頼を築きつつ、装飾が料金や予約情報より目立たないようにする。暖色系のニュートラルカラー、明確な階層、控えめな動きを使う。 |
| 予約フォームを追加する。 | サービス、担当者、日付、時間、連絡先、確認の順に進め、戻ったときも入力と選択を保持する。 |
そのままコピーできる例：ヘアサロンのAI-ready UX Context
以下は万能テンプレートではありません。AIが推測しなければならない範囲を減らすための出発点です。コピーしたうえで、実際の調査、サービス情報、ブランド原則に置き換えてください。
# AI-ready UX Context：Afterglow Hair Studio サービス紹介・予約サイト ## 1. プロジェクト目標 プロフェッショナルなヘアサロンのモバイルファーストWebサイトを作成する。 予約へ誘導する前に、サービスの違い、料金、所要時間を理解できることを優先する。 主な成功条件： - ユーザーが2分以内に自分に合うサービスを見つけられる。 - 予約前に料金帯、所要時間、代表的な追加料金を理解できる。 - 予約後に日時、場所、準備事項、キャンセル方法が分かる。 - サービス選択の誤り、料金の誤解、髪の履歴不足による確認連絡を減らす。 ## 2. 主なユーザー ### A. 初めてカラーをする顧客 - ブリーチ、トナー、ボンドケアなどの用語に不慣れ。 - ダメージ、仕上がり、想定外の追加料金を心配している。 - 分かりやすい説明、事例、事前相談の選択肢が必要。 ### B. 定期的に来店する顧客 - サービスと希望担当者をすでに理解している。 - 空き時間をすばやく見つけ、予約を完了したい。 - 前回と同じ内容を選べても、今回の料金と時間は確認したい。 ### C. イベント日が決まっている顧客 - 結婚式、面接、撮影、出演など特定の日のために施術する。 - 完了時間、スタイルの持続、日程変更のリスクを重視する。 - 時間的に難しい場合は、適切な別サービスや問い合わせ方法を示す。 ## 3. 主な利用状況 - 多くのユーザーはSNSの作品投稿からスマートフォンで訪れる。 - 求める仕上がりは分かっていても、サービス名は知らない場合がある。 - 移動中や短い休憩時間に操作する可能性がある。 - サービス比較時には、仕上がり、対象者、所要時間、料金帯を同時に確認できる必要がある。 ## 4. 中心タスクと優先順位 1. 実現したい仕上がり、または解決したい悩みからサービスを探す。 2. 内容、料金帯、所要時間、制約を理解する。 3. スタイリストの得意分野と関連する実例を見る。 4. サービス、担当者、日付、時間を選ぶ。 5. 必要な連絡先と髪の履歴を入力する。 6. 予約内容、規定、来店前の準備を確認する。 予約前の会員登録を必須にしない。 サービスを理解する前に予約へ進ませない。 ## 5. 情報設計 ホーム： - 明確なサービスの約束 - 悩みや目的から探す導線 - 人気サービス - スタイリストと得意分野 - 実際の施術例 - 予約前の案内 - 主要な予約導線 サービス詳細： - どのような人に適しているか - 実現可能なことと保証できないこと - 含まれる内容 - 料金帯と追加料金の条件 - 所要時間の目安 - 事前相談の要否 - アフターケア - 予約ボタン 予約フロー： サービス → 担当者 → 日付 → 時間 → 連絡先・髪の情報 → 確認 ## 6. サービス情報のルール 各サービスには次を含める： - サービス名 - 顧客の言葉で書いた一文説明 - 適している悩みや目的 - 事前相談が必要な条件 - 料金帯 - 髪の長さ、毛量、使用製品など追加料金の理由 - 所要時間 - シャンプー、カット、ケア、スタイリングが含まれるか - 対応可能なスタイリスト区分 - 関連する施術例 「○○円〜」だけを表示し、一般的な金額変更理由を隠さない。 ## 7. 予約フローのルール - 各ステップでは、その時点で必要な情報だけを求める。 - 進捗と現在の選択内容を表示する。 - 前のステップへ戻っても入力を保持する。 - サービス選択後、その施術に対応できる担当者だけを表示する。 - 担当者選択後、その担当者の空き枠だけを表示する。 - 施術時間と必要な準備時間を含め、閉店時刻を超える予約を許可しない。 - 空きがない場合は、別の担当者、別の日、キャンセル待ち通知を提示する。 - 最終確認では、料金帯、所要時間、住所、キャンセル規定を表示する。 - 送信後は成功状態を示し、カレンダー追加と店舗への連絡手段を提供する。 ## 8. 髪の情報とプライバシー サービス判断に影響する情報だけを尋ねる： - 現在の髪の長さ - 過去1年のブリーチ、黒染め、パーマ履歴 - 頭皮の敏感さ、既知のアレルギー - 希望する仕上がりと参考画像（任意） - スタイリストに伝えたい事項（任意） 画像アップロード前に、利用目的、保存方法、閲覧できる人を説明する。 サービスに不要な個人情報は求めない。 ## 9. 重要な状態とエラー対応 次の状態を設計する： - 未選択 - 読み込み中 - 空き枠なし - 選択中の枠が他のユーザーに予約された - 入力内容のエラー - 画像アップロード失敗 - デポジットまたは決済失敗 - 予約成功 - 変更・キャンセル成功 - サービス一時停止 エラーは、何が起きたか、入力内容が保持されているか、次に何ができるかを示す。 「エラーが発生しました。再試行してください」だけで終わらせない。 ## 10. コンテンツとトーン ブランドの人格：プロフェッショナル、率直、温かい、外見を否定しない。 顧客が理解できる言葉を使い、必要な専門用語にはすぐ説明を付ける。 宣伝表現より先に選択肢と制約を説明する。 避ける： - 仕上がりの保証 - 外見への不安を煽る表現 - 曖昧な料金 - 「究極」「完璧」「劇的変身」など中身のない形容 具体的なボタン文言を使う： - 「サービスと料金を見る」 - 「スタイリストを選ぶ」 - 「予約可能な時間を見る」 - 「予約内容を確定する」 「詳しく見る」「次へ」だけの曖昧な表現は避ける。 ## 11. ビジュアルとインタラクション原則 - 装飾ではなく、施術例と意思決定に必要な情報を視覚の中心にする。 - 暖色系ニュートラルカラー、明確な階層、十分な余白を使う。 - 作品写真は自然な肌色を保ち、髪色の判断を妨げるフィルターを使わない。 - 動きは短く機能的にし、prefers-reduced-motionを尊重する。 - 自動再生動画、読書を妨げる視差効果、不要なポップアップを避ける。 - モバイルの主要タップ領域は44 × 44 px以上にする。 ## 12. アクセシビリティ - 文字と背景はWCAG AAのコントラストを満たす。 - すべての機能をキーボードで利用でき、フォーカスを明確にする。 - ラベルは常に表示し、placeholderをlabelの代わりにしない。 - エラーと対象項目を支援技術が理解できる形で関連付ける。 - 情報画像には意味のある代替テキスト、装飾画像には空のaltを設定する。 - 色だけで状態を伝えない。 ## 13. レスポンシブ動作 - モバイルファーストで設計し、内容順序をデスクトップの左右位置に依存させない。 - 小画面のサービス比較は横スクロールを強制せず、順に読める形にする。 - 予約概要はデスクトップではサイドバーにできるが、モバイルでは確定操作の前に置く。 - 画像でヘアスタイルの重要部分を切り取らない。 - 予約ボタンを届きやすい位置に固定する場合も、内容やシステム通知を隠さない。 ## 14. 受け入れ基準 生成結果は次を満たす： - 初めてカラーをする人が専門用語を知らなくてもサービスを見つけられる。 - 各サービスは予約前に料金帯、所要時間、追加料金の条件を示す。 - 空きなし、枠の競合、アップロード失敗、送信失敗に実行可能な次の手段がある。 - 戻る操作で入力内容が失われない。 - 完了画面にサービス、担当者、日時、料金帯、住所、規定が表示される。 - 幅320 pxで意図しない横スクロールがない。 - キーボードだけで予約を完了できる。 - 画像を無効にしてもサービス選択と予約を理解できる。 - すべての画面要素の目的を、このUX Contextから説明できる。 ## 15. 生成時の出力要件 画面を生成する前に、次を出力する： 1. 主要なユーザージャーニー 2. ページとコンテンツの階層 3. 重要な状態一覧 4. 受け入れ基準に対応するデザイン判断 情報が不足している場合は質問を列挙する。 料金、規定、空き時間を勝手に作らない。
PromptとContextの違いは、長さではない
良いPromptは引き続き重要です。今回のタスクと出力形式を定義します。一方、Contextは複数のタスクを一貫させる再利用可能な基盤です。情報設計、サービスページ、予約フロー、エラー状態を別々に生成する場合、その都度の思いつきだけでPromptを書くと原則が揺れます。
UX Contextは、継続的に保守するデザイン資産に近いものです。調査結果、サービス規定、ブランドのトーンが変わったら、まずContextを更新し、その後の生成で共通して利用します。
ハンドオフから継続的なキュレーションへ
AIが画面を生成できても、デザイナーの役割は消えません。完成した画面を渡すだけでなく、生成条件を整える役割へ広がります。有効な根拠を選び、判断を明文化し、仮定を可視化し、受け入れ基準を定義し、出力に繰り返し現れる偏りを評価します。
デザイン成果物も変わります。デザインファイルやコンポーネントライブラリに加え、人とAIが共有できるContext、良い例と反例、状態モデル、品質チェックが必要になります。
Contextはユーザー調査の代わりにはならない
構造化された文書は、仮定を確かな事実のように見せることがあります。形式が整っていても、根拠があるとは限りません。社内の推測だけでContextを作れば、AIはその推測をより一貫して増幅します。重要な記述が調査、運用ルール、分析データ、未検証の仮定のどれに基づくかを示しましょう。
- 調査インサイトに出典と日付を付ける
- 事実、決定、仮定を分ける
- 競合する要件と判断理由を記録する
- Contextの保守担当者を決める
- 現実的なタスクで生成結果を試す
- 回帰を防ぐ反例を保存する
必要なのは長いPromptではなく、より良いContext
最初から巨大な文書システムを作る必要はありません。価値の高いフローを一つ選び、今の目的、最大の不安、判断に必要な情報、重要な例外、検証可能な完了条件の5点を整理します。そのContextから生成し、どの失敗が情報不足に由来するかを観察します。
成熟したAIデザインプロセスは、モデルが一度で正解を当てることに期待しません。何を根拠に判断したかを見えるようにし、その根拠をチームが継続して改善できる仕組みを作ります。
よくある質問
UX Contextとデザインシステムはどう違いますか？
デザインシステムは主にコンポーネント、スタイル、操作パターンを定義します。UX Contextはユーザー、タスク、コンテンツ、業務ルール、判断理由を補います。両方を組み合わせることで、一貫性と状況への適合性を両立できます。
UX Contextは、とても長いPromptのことですか？
いいえ。Promptは現在のタスクを記述し、Contextは再利用・保守できる判断基盤です。構造を明確にし、判断へ影響する情報だけを選びます。
すべての調査データをAIへ渡す必要がありますか？
必要ありません。まず知見、根拠の強さ、例外、デザインへの影響を整理します。無関係な情報や不要な個人情報を除き、組織のプライバシーポリシーに従います。
Contextが十分かどうかは、どう判断しますか？
具体的な生成タスクで使い、受け入れ基準に照らして結果を評価します。同じ誤りが繰り返される場合、ルール、状態、優先順位、反例のいずれかが不足している可能性があります。
小規模なチームにもUX Contextは必要ですか？
必要ですが、簡潔に始められます。中心ユーザー、主要タスク、コンテンツ階層、重要な制約、5〜10個の受け入れ基準を1ページにまとめるだけでも効果があります。