プロンプトガイド
入力する前に決め、分けて作り、実際のコンテンツを使い、すべての依頼を適切なエージェントに渡しましょう。こうした習慣によって、一行のアイデアが完成した成果へと変わります。
入力する前に決め、分けて作り、実際のコンテンツを使い、すべての依頼を適切なエージェントに渡しましょう。こうした習慣によって、一行のアイデアが完成した成果へと変わります。
まずはプロジェクトチャットで始めましょう。 変更したいプロジェクトのチャットを開き、作業内容に合った役割のエージェントを選ぶか、そのエージェント宛てに依頼してください。どのエージェントが適切かわからない場合は、作業を始める前にチームに確認を求めましょう。
このガイドでは、エージェントチームから一貫してより良い結果を引き出すためのテクニックをまとめています。どれも特別な能力は必要ありません。重要なのは、どう整形するかではなく、何を伝えるかです。最初の依頼を書く場合でも、成熟したプロジェクトを磨き上げる場合でも、同じ原則が当てはまります。考え方が明確であれば、結果も明確になります。
作る前に、まずチームに質問してもらう
より良い結果を得るための最も効果的な方法のひとつは、依頼が大きかったり曖昧だったりする場合に、チームが正しく推測してくれることを期待するのではなく、質問を歓迎することです。やりたいことを伝えたうえで、最後に次の一文を加えてください。
始める前に、私の望んでいることを完全に理解するために必要なことは何でも質問してください。
そうすることで、エッジケース、対象ユーザー、トレードオフなど、自分では答えるべきだと思いつかなかった質問がよく返ってきます。最初にそれらを整理するのにかかるのは1分ですが、作った後に気づくと手戻りが発生します。その結果、最初の段階から意図にずっと近い成果物になります。
ステップ 1: 入力する前に決める
何を作るのかを把握する
最初に数分考えるだけで、あとで何度もプロンプトを書き直す手間を大きく減らせます。始める前に、4つのシンプルな質問に答えられるようにしておきましょう。何を作るのか、誰のためのものか、なぜその人が使うのか、そしてその人に取ってほしい主な行動は何か、です。
その主な行動は、よく CTA(call to action の略)と呼ばれます。これは、ユーザーに最も選んでほしいボタン、リンク、または次のステップのことで、たとえば Sign Up、Book a Demo、Start Free、Buy Now などがあります。
完全な仕様書を書く必要はありません。目的は、プロジェクトに明確な方向性を与えることです。出発点が具体的であるほど、思い描いているものに合った結果を生成しやすくなります。
フリーランス向けの家計管理アプリのための1ページサイトを作成してください。主な CTA は「Start Saving Smarter」です。大きな文字と印象的な色を使った、大胆で表現力のある見た目にしてください。
画面だけでなく、体験の流れを描く
優れたデザインは、画面そのものだけでなく、画面と画面の間にも存在します。ユーザーがたどる道筋を追ってみましょう。最初に何を見るのか、何が信頼を生むのか、何が行動する自信を与えるのか、そしてその行動はどこにつながるのか。ヒーロー、証拠、行動喚起という3段階の簡単なスケッチだけでも、依頼の効果は大きく高まります。各セクションに存在する理由と、次へつなげる理由が生まれるからです。
早い段階でビジュアルの方向性を決める
スタイルは、後から当てはめるよりも、最初に定めるほうがはるかに簡単です。落ち着いていて上品、大胆で破壊的、高級感があり洗練されている、といった方向性を選び、最初の依頼でチームが行動に移せるトーンの言葉を使って伝えましょう。たとえば minimal、playful、cinematic、developer focused などです。これらの言葉は単なる飾りではありません。最初のコンポーネントから、タイポグラフィ、余白、色、影、角丸の半径にまで影響します。後の依頼でも同じスタイルの一文を再利用すると、全体の一貫性を保てます。
穏やかでウェルネスを感じさせるデザインにしてください。柔らかなグラデーション、落ち着いたアースカラー、丸みのある角、ゆとりのあるパディングを使います。全体のトーンはやさしく安心感のあるものにしてください。
ステップ 2: 伝わる依頼を書く
実装ではなく、成果を説明する
作り方の手順ではなく、欲しい結果を説明しましょう。たとえば、「3つの選択肢がある料金セクションを追加し、中央のものを目立たせてください」は、ページをどう構成すべきかを細かく説明するよりも有用です。何を表示すべきか、そしてそれがなぜ重要なのかに集中してください。どう作るかはチームが判断できます。
ページ単位ではなく、パーツ単位で進める
1つのコンポーネントに範囲を絞った依頼、たとえばヒーロー、機能グリッド、推薦文の行、料金表などは、明確さとコントロールをもたらします。あるパーツが期待どおりでなければ、そのパーツだけを調整すればよく、周囲すべてを再生成する必要はありません。ブロックを作り、確認し、磨き上げてから次へ進みましょう。ページ全体への依頼はノイズを生み、コンポーネント単位の依頼はシグナルを生みます。
機能紹介セクションを作成してください。中央揃えの見出しの下に、3枚のカードを横並びで配置し、それぞれにアイコン、タイトル、1行の説明を入れてください。柔らかな影を付け、ホバー時に少し浮き上がるようにしてください。
実際の言葉を使う
プレースホルダーテキストは問題を隠しますが、実際のコピーは問題を明らかにします。実際の見出しは2行必要かもしれませんし、実際の CTA は動詞のほうがうまく機能するかもしれません。たとえ下書きでも、ユーザーが実際に読む言葉を書いてください。コンテンツが本物であるほど、レイアウト、余白、デザイン上の判断はすべて良くなります。
ヒーロー見出し: 「Design Calmly.」 サブテキスト: 「Turn stress into structure.」 CTA: 「Start Building Free.」 コピーを中心にしたレイアウトで、縦方向の余白をたっぷり取ってください。
実際の要素名を挙げる
ページ上に欲しいものを、明確で具体的な言葉で説明しましょう。デザイン用語を知っている必要はありません。プロフィールカード、ボタン、フォームのように、ユーザーが見たり操作したりするものの名前を挙げるだけで十分です。
具体的な依頼は、漠然とした依頼よりも作りやすくなります。まず必要な基本要素から始めて、詳細をひとつずつ加えていきましょう。
写真、名前、フォローボタンを含むプロフィールカードを作成してください。名前の横に小さな「Verified」ラベルを追加し、その上にカーソルを合わせると短い説明が表示されるようにしてください。
ステップ 3: 正確に変更する
すべての変更範囲を明確にする: 何を変え、何を残すか
既存の作業を調整するときは、変更すべきことと変更してはいけないことの両方を明確に伝えましょう。「これをもっと良くして」ではなく、「置き換える」「更新する」「調整する」といった指示語を使い、気に入っている部分は保護してください。ここでの正確さが、反復作業を後退に変えないための鍵になります。
CTA のテキストを「Get Started」に変更し、水平方向のパディングを増やしてください。このセクションの現在の色、フォント、その他すべては変更しないでください。
意味のある変更は一度にひとつずつ
まずコピーを更新し、次にレイアウト、その次にインタラクションを更新し、次の依頼に進む前に毎回結果を確認してください。小さく意図的なステップを積み重ねることで、洗練されたプロダクトになります。一方、1つのメッセージに10個の変更を詰め込むと曖昧さが積み重なり、何か問題が起きても、どの変更が原因だったのかわからなくなります。
作業途中の修正はチャットで行われます。 チャットで Prompt Queue が利用可能で、エージェントの作業が進行中の場合、追加メッセージは実行中の作業の後ろにキューとして並びます。別のコピーを送信する前に、自分のメッセージがキューに表示されていることを確認してください。キューの操作が表示されていない場合は、再送しないでください。現在の作業が終わるのを待つか、チャットに割り込み操作がある場合はそれを使い、その後でタスクの状態を確認してから追加メッセージを送信してください。詳細は Project chat を参照してください。
UI の一歩先まで考える
プロジェクトに見た目の洗練以上のことが必要なら、見た目とあわせて動作も定義しましょう。サインイン時とサインアウト時にユーザーに何が見えるか、動的コンテンツがどこから来るか、空状態、読み込み中、エラー状態をインターフェースがどう扱うかを指定してください。こうしたシナリオを考慮して設計するのに、動くバックエンドは必要ありません。早い段階で計画しておくことで、後の大きな UI の手戻りを防げます。
ユーザーがログインしている場合は、右上にアバターと名前を表示してください。ログインしていない場合は、認証画面に遷移する「Log In」ボタンを表示してください。
よくある質問
AI エージェント向けに効果的なプロンプトを書くにはどうすればよいですか?
プロンプトは、次の重要な要素で構成してください。
1. Context — 状況を設定します。何を作っていて、現在どのような状態なのかを説明してください。
2. Goal — 欲しい結果や機能を具体的に示してください。
3. Requirements & Constraints — 何を変更すべきか、何をそのままにしておくべきかを明確に列挙してください。
4. Expected Result — 成功の状態を定義してください(例: UI の動作、エラー処理、状態の保持)。
5. References — 可能であれば、スクリーンショット、リンク、ワークフローの手順、コードサンプルを添付してください。共有前に、パスワード、認証コード、API キー、Cookie、個人データ、支払い情報は削除してください。
例: "サイドバー付きのダッシュボードを作っています。サイドバーの下部にログアウトボタンを追加してください。セッションをクリアして /login にリダイレクトする必要があります。サイドバーのレイアウトやナビゲーションリンクは変更しないでください。クリック後、ユーザーには1秒以内にログインページが表示されるようにしてください。"
複数の機能を含む複雑な依頼はどのように扱えばよいですか?
複雑な依頼は、より小さなタスクに分割してください。
1. 現在の問題と最終目標を述べます。
2. 各サブタスクを個別に列挙します(task 1、task 2、task 3)。
3. 次に進む前に、各タスクを確認します。
4. 最後に完全なフローをテストします。
この方法により、エージェントに一度に多くを求めすぎることで起きる予期しない変更を減らせます。各プロンプトは、単一で検証可能な結果に集中すべきです。
バグ修正のためのプロンプトはどう書けばよいですか?
役立つバグ修正プロンプトには、次の内容を含めるべきです。
- ページ、機能、環境、影響を受けるユーザー
- 問題を再現するための正確な手順
- 実際の動作と期待される動作
- 完全なエラーテキストと、それが発生したタイミング
- 関連するスクリーンショットやログ(パスワード、トークン、Cookie、個人データ、支払い情報を削除したもの)
- 変更してはいけないもの
- 修正をどのように確認するか、またどの回帰チェックを実行するか
例: “Preview の checkout ページで Submit を選択すると 500 エラーが返ります。期待される結果: 注文が確定し、ユーザーがサンキューページに到達すること。再現手順: [steps]。カート合計や支払いフローは変更せずに原因を修正し、その後、成功する支払いケースと支払い拒否ケースをそれぞれ1件ずつ確認してください。添付ログからはすべての秘密情報を削除済みです。”
ページのレイアウトやスタイルを変更するためのプロンプトはどう書けばよいですか?
ページ変更を依頼する際は、次の内容を含めてください。
1. 変更する具体的なページ、モジュール、要素。
2. 現在の状態と目標とする結果。
3. 参考リンクまたはスクリーンショット。
4. 変更してはいけない機能。
5. 受け入れ基準(例: デスクトップとモバイルの両方で動作すること)。
例: " /pricing ページで、プランカードのグリッドをデスクトップでは2列から3列に変更してください。モバイルのレイアウトは1列のままにしてください。このスクリーンショットを参考にしてください [attach]。カードの内容やボタンのスタイルは変更しないでください。"
修正を伝えてもエージェントが何度も間違った変更をしてしまう場合はどうすればよいですか?
エージェントが繰り返し意図を外す場合、指示を追加すると、かえって混乱が増すことがあります。代わりに、次のようにしてください。
1. 現在の状態を保つ — 重なり合う修正指示を送るのをやめてください。チャットに Revert コントロールが表示されている場合は、使用前に確認テキストを読み、保持したい後続の変更をメモし、その後プロジェクトを確認してください。範囲が不明確な場合は、続行しないでください。Project chat のガイダンスを使うか、秘匿情報を削除した Chat Link とスクリーンショットを添えてサポートに連絡してください。
2. ノイズを取り除く — その場しのぎで指示を積み増すのではなく、核心となる問題を最初から簡潔に言い直してください。
3. 一度に1つのタスク — 次に進む前に、まず1つの問題の修正に集中してください。
一歩引いて、変更を段階的に進めることで、1つのプロンプトで複数の重なった問題を解決しようとするよりも、通常ははるかに早く問題を解消できます。