この3層構造はもともとコード生成のプロンプトを書くために設計されたものです。デザインプロトタイプの生成に適用するのは適していないのではないですか？
このフレームワークの核心的なロジック——「仕様上の制約」「挙動の要件」「エッジケース」を分けて語ること——は、コード生成に特化したテクニックではなく、AIに具体的で機能するものを作らせようとする、どんな状況でも共通して現れる構造だ。コード生成には技術スタック、データ構造、エラー処理が必要であり、デザインプロトタイプの生成にも同様に、ビジュアル仕様、インタラクションの挙動、ハッピーパス以外の状態が必要になる。語彙が変わるだけで、根底にある分類のロジックは完全に対応している。
実際に適用する際に調整が必要なのは、各層に具体的に何を入れるかという点だけだ。第1層は「どのフレームワークを使うか」から「どのデザインシステム、どのコンポーネントライブラリを使うか」へ、第2層は「ユーザーストーリー」から「インタラクションの詳細とユーザーの操作フロー」へ、第3層は「APIのエッジケース」から「空の状態、読み込み中、エラー状態をどう表示するか」へと変わる。階層化のロジックは変わらず、各層に収まる具体的な内容が場面によって変わるだけだ。
生成したいものが単純な場合（例えばボタン1つ）でも、3層構造に従って書く必要があるのですか？かえって大げさすぎませんか？
3層構造の価値は、生成するものの複雑さに比例する。複雑であればあるほど、既存のシステムとの統合が必要であればあるほど、階層化がもたらす効果は明らかになる。逆に、孤立した、単純な、既存の何とも統合する必要のない要素（純粋に装飾用のアイコンなど）を生成するだけであれば、第1層と第3層はほとんど空になるかもしれない。その場合は、無理に3つのセクションを埋める必要はない。
3層構造を真剣に適用すべきかどうかを判断する、より実用的な基準は次の通りだ。このものは後で他の何かと統合されるか、複数の状態（空の状態、読み込み中など）を処理する必要があるか、既存のビジュアル規範に準拠する必要があるか。これらのいずれかに当てはまれば、第3層（統合とエッジケース）と第1層（技術的な文脈）には通常書くべき実質的な内容があり、階層化は明確な効果をもたらす。3つとも当てはまらなければ、それは本当に単純で独立したリクエストであることのシグナルであり、望む結果を直接説明するだけで通常は十分だ。
3層構造の中で、AIではなくユーザー自身によって最も見落とされやすい層はどれですか？
第3層（統合上の考慮事項とエッジケース）が、ユーザー自身によって最も見落とされやすい層だ。理由はユーザーがこの層の重要性を知らないからではなく、この層が求める思考の仕方が最初の2層とは異なるからだ。第1層（技術的な文脈）は通常すでに確定した事実であるため、書き出すのに労力はかからない。第2層（機能要件）はユーザーが最初にそのアイデアを思いついたときに真っ先に思い浮かぶものなので、自然と書き込まれる。しかし第3層は、ユーザーに「このものはどんな状況で問題が起きるかもしれないか」を能動的に考えることを求める。これは予測的で防御的な思考であり、「データが空だったら」「ユーザーが連続で2回クリックしたら」と、意図的に立ち止まって自分に問いかける必要がある。これらの問いは、意図的に探しに行かない限り、自然には浮かんでこない。
実用的なチェック方法は、プロンプトを書き終えた後、さらに10秒だけ時間をかけて自分にこう問いかけることだ。「もしこれがユーザーテストに使われたら、どんな操作方法が最も『壊れている』ように見せてしまう可能性が高いか？」その答えを第3層に書き込めば、通常は最も見落とされやすいエッジケースを捉えられる。
Claude Designのようなツールを使う場合、生成のたびに毎回3層プロンプトを一から書く必要があるのですか？時間がかかりすぎませんか？
毎回ゼロから始める必要はない。3層構造が本当に効果を発揮するのは、再利用可能な「テンプレート思考」を構築する手助けになる点だ。例えばフォーム系のコンポーネントを頻繁に生成する必要があるなら、第1層（自分の技術スタック、デザインシステム）と、第3層の中の汎用的なエッジケース（空白の入力、読み込み中、送信失敗）を、あらかじめ固定の文章としてまとめておける。その後は毎回、第2層（今回具体的にどんな機能を作りたいか）だけを差し替えればよく、他の2層はそのままコピー＆ペーストできる。実際に毎回新しく入力する内容量は、通常思いついたままに打つプロンプトとそれほど変わらない。
毎回本当に考え直す必要があるのは、通常、第2層（今回の機能要件）と、第3層の中の「その機能特有のエッジケース」という小さな部分だけであり、それ以外はプロジェクトレベルの固定設定として扱い、一度書けば以降は再利用できる。
「To-doアイテムのコンポーネントを作って」と「To-doアイテムのコンポーネントを、ReactとTailwindを使って、完了チェックボックス付きで、編集ボタンを押すとインライン編集モードに切り替わり、削除前には確認ダイアログを出し、完了・未完了の項目には視覚的な区別を付け、編集モードへの切り替えには滑らかなトランジションを入れ、空白テキストのエッジケースを処理し、削除と更新の操作にはローディング状態を付けて作って」——この2つのプロンプトが生む結果の差は、通常「少し手直しすればいい」レベルではない。「そのまま使える」か「ゼロから書き直す必要がある」かのレベルだ。違いは文字数ではなく、3種類の異なる性質を持つ情報が明確に分けられているかどうかにある。ここで取り上げる3層プロンプト構造は、もともとエンジニアリング分野でコード生成プロンプトを書くためのフレームワークとして生まれたが、同じ階層化のロジックは、AIデザインツールでインターフェースのプロトタイプを生成する際にも同様に有効だ。
この層で伝えるべきは「これはどんな仕様で作られるべきか」だ——どのフレームワークを使うか、どんなスタイリングシステムを使うか、既存のデザインシステムに合わせる必要があるか、特定のアイコンライブラリやコンポーネントライブラリを流用すべきか。この層が決めるのは、生成結果が「あなたのシステムに元々あったもののように見えるか」であり、単に機能するかどうかではない。この層を省略すると、AIは自分自身のデフォルトのスタイリングロジックに頼るしかなく、機能的には正しくても、視覚的にはあなたの実際の製品と食い違ってしまい、後で既存のスタイルに手動で合わせ直す作業が必要になる。
この層で伝えるべきは「ユーザーの視点から見て、これは何をすべきか」だ——具体的なインタラクションの挙動、ユーザーが実際にどう操作するか、操作した後に何が起きるべきか。第1層との違いは、第1層が技術仕様を語るのに対し、第2層は挙動と体験を語る点にある。まったく同じ技術仕様でも、まったく異なるユーザー体験を支えることができるため、どちらの層も互いに置き換えることはできない。
これは最もよく省略される層であり、同時に後の手戻りを最も引き起こしやすい層でもある——このコンポーネントは既存のシステムとどう統合されるか、データが空のときはどう処理するか、ユーザーが連続で素早くクリックしたときの誤操作防止はどうするか、ローディング中やエラーの状態はどう見えるべきか。この層こそが「デモ用のプロトタイプ」と「実際にエンジニアリングチームに引き渡せる成果物」を分けるものであり、以前の記事で議論した「成果物のギャップ」が最も集中的に現れる場所でもある。この層が明確に語られていなければ、AIが生成したものはデモでは完成しているように見えるが、エンジニアリングチームが引き継いだ後になって、エッジケースがまったく考慮されていなかったことが発覚する。
3層構造が有効なのは、情報量が多いからではなく、プロンプトを書く前に「仕様」「挙動」「エッジケース」という本質的に異なる3種類の問いを、ユーザーに分けて考えさせるからだ。思いついたことをすべて一つの区別のない文章の塊に詰め込むのとは違う。すべてを混ぜて語るプロンプトは、たとえ同じ文字数であっても、AIがある種類の情報を見落としやすくなる。なぜなら、技術仕様とユーザーの挙動が同じ文の中に織り交ぜられていると、AIはどの部分が絶対的な制約で、どの部分に自由な裁量の余地があるのかを明確に判断できないからだ。層に分けることで、各層がそれぞれ完結し、AIも各層を正しい生成ロジックに対応させやすくなる。
現在のAIデザインツールの使い方が、思いついたことをそのままプロンプト欄に打ち込むというもので、結果が使えるレベルになるまでに何度もやり取りを繰り返す必要があるなら、次に生成したいものを送信する前に、この3層構造に沿って一度整理し直してみる価値がある。毎回正式な仕様書のように詳細に書く必要はないが、少なくとも3層すべてに触れているか確認し、第2層（何をしたいか）だけを書いて送信するのはやめよう。この習慣がもたらす時間の節約は、通常、生成そのものにかかる数秒ではなく、後に続く「ここが違う、あそこが抜けている」という何度もの修正のやり取りを避けられる点にある。特に第3層（エッジケース）が明確に語られていない場合、そのギャップは通常、他の人にテストしてもらったり、エンジニアリングチームに引き渡したりして初めて発覚するもので、その時点での修正コストは、最初から明確に語っておく場合よりもはるかに高くつく。