プロンプトガイド

プロジェクトチャットから始めましょう。 変更したいプロジェクトのチャットを開き、作業内容に合った役割のエージェントを選ぶか、そのエージェント宛てに依頼してください。どのエージェントが適切かわからない場合は、作業を始める前にチームに確認を求めてください。

このガイドでは、エージェントチームから一貫してより良い結果を引き出すための手法をまとめています。どれも特別な能力は必要ありません。重要なのは、どのように書式設定するかではなく、何を伝えるかです。初めて依頼を書く場合でも、成熟したプロジェクトを磨き上げる場合でも、同じ原則が当てはまります。考え方が明確であれば、結果も明確になります。

作る前にチームに質問してもらう

より良い結果を得るための最も効果的な方法の一つは、依頼が大きい、または曖昧なときに、チームが正しく推測してくれることを期待するのではなく、質問を歓迎することです。やりたいことを伝えたうえで、最後に次の一文を加えてください。

始める前に、私が望んでいることを完全に理解するために必要なことは何でも質問してください。

エッジケース、対象ユーザー、トレードオフなど、自分では答える必要があると気づかなかった質問が返ってくることがよくあります。最初にそれらを整理するのにかかるのは1分ですが、作った後に気づくと手戻りが発生します。その結果、最初の段階から意図にずっと近い成果物になります。

ステップ 1: 入力する前に決める

何を作るのかを把握する

最初に数分考えるだけで、後から何度も再プロンプトする手間を大きく減らせます。始める前に、次の4つの簡単な質問に答えられるようにしておきましょう。何を作るのか、誰のためのものか、なぜその人たちが使うのか、そして取ってほしい主な行動は何か、です。

その主な行動は、しばしば CTA（call to action の略）と呼ばれます。これは、ユーザーに最も選んでほしいボタン、リンク、または次のステップのことで、たとえば Sign Up、Book a Demo、Start Free、Buy Now などがあります。

完全な仕様書を書く必要はありません。目的は、プロジェクトに明確な方向性を与えることです。出発点が具体的であるほど、頭の中のイメージに合った結果を生成しやすくなります。

フリーランサー向けの家計管理アプリの1ページサイトを作成してください。主な CTA は「Start Saving Smarter」です。大きな文字と印象的な色を使った、大胆で表現力のある見た目にしてください。

画面だけでなく導線も描く

優れたデザインは、画面そのものだけでなく、画面と画面の間にも存在します。ユーザーがたどる流れを追ってみましょう。最初に何を見るのか、何が信頼を生むのか、何が行動する自信を与えるのか、その行動の先に何があるのか。hero、根拠、call to action という3段階の簡単な構成だけでも、依頼の効果は大きく高まります。なぜなら、各セクションに存在する理由と、次へつなげる理由が生まれるからです。

早い段階でビジュアルの方向性を決める

スタイルは後から付け足すより、最初に定めるほうがはるかに簡単です。落ち着いていて上品、大胆で破壊的、高級感があり洗練されている、など方向性を選び、最初の依頼でチームが行動に移せるトーンの言葉を使って伝えましょう。たとえば minimal、playful、cinematic、developer focused です。これらの言葉は単なる飾りではありません。最初のコンポーネントから、タイポグラフィ、余白、色、影、角丸の半径にまで影響します。後続の依頼でも同じスタイルの一文を再利用すると、全体の統一感を保てます。

落ち着いたウェルネス志向のデザインにしてください。柔らかなグラデーション、くすんだアースカラー、丸みのある角、ゆったりしたパディング。全体のトーンは穏やかで安心感のあるものにしてください。

ステップ 2: 伝わる依頼を書く

実装ではなく結果を説明する

作り方の手順ではなく、欲しい結果を説明してください。たとえば、「3つの選択肢がある料金セクションを追加し、中央のものを目立たせてください」は、ページをどう構築すべきかを細かく説明するより有用です。何を表示すべきか、そしてそれがなぜ重要なのかに焦点を当てましょう。どう作るかはチームが判断できます。

ページ単位ではなくパーツ単位で進める

hero、機能グリッド、推薦文の行、料金表など、1つのコンポーネントに範囲を絞った依頼は、明確さとコントロールをもたらします。あるパーツが期待どおりでなければ、その部分だけを調整でき、周囲すべてを再生成する必要がありません。ブロックを作り、確認し、改善してから次に進みましょう。ページ全体への依頼はノイズを生み、コンポーネント単位の依頼は本質を生みます。

機能セクションを作成してください。中央揃えの見出しの下に、3枚のカードを横並びで配置し、それぞれにアイコン、タイトル、1行の説明を入れてください。柔らかな影を付け、ホバー時に少し浮き上がるようにしてください。

実際の言葉を使う

ダミーテキストは問題を隠しますが、実際のコピーは問題を明らかにします。実際の見出しは2行必要かもしれませんし、実際の CTA は動詞のほうがうまく機能するかもしれません。たとえ下書きでも、ユーザーが実際に読む言葉を書いてください。コンテンツが実際のものであると、レイアウト、余白、デザイン上の判断はすべて改善されます。

Hero 見出し: 「Design Calmly.」 サブテキスト: 「Turn stress into structure.」 CTA: 「Start Building Free.」 コピーを中心にしたレイアウトで、縦方向の余白をたっぷり取ってください。

実際の要素名を挙げる

ページに欲しいものを説明するときは、明確で具体的な言葉を使ってください。デザイン用語を知っている必要はありません。プロフィールカード、ボタン、フォームのように、ユーザーが見たり操作したりするものの名前を挙げれば十分です。

具体的な依頼は、漠然とした依頼よりも作りやすくなります。まず必要な基本要素から始めて、詳細を一つずつ加えていきましょう。

写真、名前、フォローボタンを含むプロフィールカードを作成してください。名前の横に小さな「Verified」ラベルを追加し、その上にホバーしたときに短い説明を表示してください。

ステップ 3: 正確に変更する

すべての変更範囲を明確にする: 何を変え、何を残すか

既存の作業を調整するときは、何を変えるべきか、何を変えてはいけないかの両方を明確に伝えてください。「これをもっと良くして」のような表現ではなく、「置き換える」「更新する」「調整する」といった指示語を使い、気に入っている部分はそのまま残すよう範囲を区切りましょう。反復作業が改悪にならないようにする鍵は、この正確さにあります。

CTA のテキストを「Get Started」に変更し、左右のパディングを増やしてください。現在の色、フォント、このセクション内のその他すべては変更しないでください。

一度に意味のある変更を一つだけ行う

まずコピーを更新し、次にレイアウト、その次にインタラクションを更新し、それぞれの結果を確認してから次の依頼に進んでください。小さく意図的なステップを積み重ねることで、洗練されたプロダクトになります。一方で、1つのメッセージに10個の変更を詰め込むと曖昧さが積み重なり、何か問題が起きても、どの変更が原因かわからなくなります。

作業途中の修正はチャットで行います。 チャットで Prompt Queue が利用可能で、エージェントの作業が進行中の場合、フォローアップメッセージは実行中の作業の後ろにキューとして追加されます。別の内容を送る前に、自分のメッセージがキューに表示されていることを確認してください。キューの操作が表示されていない場合は、再送しないでください。現在の作業が完了するのを待つか、チャットに割り込み操作がある場合はそれを使い、その後でタスクの状態を確認してからフォローアップを送ってください。詳細は プロジェクトチャット を参照してください。

UI の一歩先まで考える

プロジェクトに求めるものが見た目の洗練だけではないなら、見た目とあわせて挙動も定義してください。サインイン時とサインアウト時にユーザーに何を見せるか、動的コンテンツがどこから来るか、空状態・読み込み中・エラー状態をインターフェースがどう扱うかを指定しましょう。こうしたシナリオを考慮して設計するのに、動作するバックエンドは必要ありません。早い段階で計画しておくことで、後から大規模な UI の手戻りを防ぎやすくなります。

ユーザーがログインしている場合は、右上にアバターと名前を表示してください。ログインしていない場合は、認証画面に遷移する「Log In」ボタンを表示してください。

FAQ

AI エージェント向けに効果的なプロンプトを書くにはどうすればよいですか？

プロンプトは次の主要な要素で構成してください。

1. Context — 状況を共有します。何を作っていて、現在どのような状態なのかを説明してください。

2. Goal — 欲しい結果や機能を具体的に示してください。

3. Requirements & Constraints — 何を変更すべきか、何をそのままにすべきかを明確に列挙してください。

4. Expected Result — 成功の状態を定義してください（例: UI の挙動、エラー処理、状態の保持）。

5. References — 可能な限り、スクリーンショット、リンク、ワークフローの手順、コードサンプルを添付してください。共有前に、パスワード、認証コード、API キー、Cookie、個人データ、支払い情報は削除してください。

例: "サイドバー付きのダッシュボードを作っています。サイドバーの下部にログアウトボタンを追加してください。セッションをクリアして /login にリダイレクトする必要があります。サイドバーのレイアウトやナビゲーションリンクは変更しないでください。クリック後、ユーザーには1秒以内にログインページが表示されるようにしてください。"

複数の機能にまたがる複雑な依頼はどのように扱えばよいですか？

複雑な依頼は、より小さなタスクに分割してください。

1. 現在の問題と最終目標を述べる。

2. 各サブタスクを個別に列挙する（タスク 1、タスク 2、タスク 3）。

3. 次に進む前に各タスクを確認する。

4. 最後に完全なフローをテストする。

この方法により、エージェントに一度に多くを求めすぎることで発生する予期しない変更を減らせます。各プロンプトは、単一で検証可能な結果に集中させるべきです。

バグ修正のためのプロンプトはどう書けばよいですか？

有用なバグ修正プロンプトには、次の内容を含める必要があります。

• ページ、機能、環境、影響を受けるユーザー
• 問題を再現するための正確な手順
• 実際の挙動と期待される挙動
• 完全なエラーテキストと、それが発生したタイミング
• 関連するスクリーンショットやログ（パスワード、トークン、Cookie、個人データ、支払い情報を削除したもの）
• 変更してはならないもの
• 修正をどう検証するか、どの回帰チェックを実行するか

例: “Preview のチェックアウトページで 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つのプロンプトで複数の重なった問題を解決しようとするよりも、通常ははるかに早く問題を解消できます。