優れたプロンプトのための主要原則
- 明確かつ具体的にする: 常に_何を_、_どのように_してほしいのかを明確にしてください。曖昧な言葉は避け、「このアプリを良くして」と言う代わりに、「UIや機能を変えずに、未使用のコンポーネントを整理してパフォーマンスを向上させるためにアプリをリファクタリングして」と具体的に指示します。アプリが誰のためのものか、何をすべきか、必須の機能は何かといったコンテキストを提供してください。
- ユーザーのジャーニーに焦点を当てる: ユーザーがアプリで行う一連のアクションを考慮してください。例えば ——
- 「何を」を記述し、「どのように」は記述しない: Lumiがバックエンドの複雑さを処理するため、望ましい結果や外観に焦点を当ててください。例えば ——
- 反復と改良: 最初の出力で満足しないでください。プロンプトはAIとの対話を通じて反復的に改良できます。Lumiは最初から完全に機能する出力を提供しますが、それはさらなる改良のための土台です。
C.L.E.A.R. フレームワーク
- Concise（簡潔）: 要点を率直に伝え、無駄な言葉や曖昧な表現を避けます。正確さと簡潔さを目指してください。
- Logical（論理的）: プロンプトを段階的または構造的に整理し、複雑なリクエストを順序立てたステップに分解します。
- Explicit（明確）: 何を望み、何を望まないかを正確に述べ、可能であればフォーマットや内容の例を提供します。
- Adaptive（適応的）: AIの出力に基づいてプロンプトを改良し、フォローアップのプロンプトで指示を明確にしたり、エラーを指摘したりします。
- Reflective（内省的）: 各インタラクションの後に何がうまくいき、何がうまくいかなかったかを見直し、将来のプロンプトを改善します。
プロンプト作成の4つのレベル
- 構造化された「補助輪付き」プロンプト（明示的なフォーマット）: 初心者や複雑なタスクに役立ちます。ラベル付きのセクションを使用します。
- コンテキスト: AIの背景や役割設定。
- タスク: 具体的な目標。
- ガイドライン: 好ましいアプローチやスタイル。
- 制約: 厳格な制限や禁止事項。
- 例えば ——
- 会話形式のプロンプト（補助輪なし）: 慣れてきたら、同僚にタスクを説明するように、より自然に書くことができます。ただし、正式なラベルなしでも明確さと完全性を維持します。
- メタプロンプト（AIによるプロンプト改善支援）: LumiのAIにプロンプトや計画の改善を手伝ってもらいます。例えば ——
- リバースメタプロンプト（ドキュメンテーションツールとしてのAI）: タスクの後に何が起こったかをAIに要約または文書化させます。これはデバッグや知識の記録に非常に優れています。例えば ——
プロンプトフレームワーク
- 「誰が / 何を / なぜ」プロンプト:
- 誰がこのアプリを使いますか？
- 何をするのに役立ちますか？
- なぜ誰かがこれを使うのですか？
- 「ユーザーストーリー」プロンプト: エンドユーザーの視点からリクエストを組み立てます。例：
- 「機能分解」プロンプト: 追加したい機能をリストアップします。例：
より良い結果を得るための高度なテクニックとヒント
- ゼロショット vs. フューショットプロンプト:
- ゼロショット: モデルに_例なしで_タスクを実行させることで、その一般的なトレーニングに依存します。一般的または明確に記述されたタスクに適しています。
- フューショット: プロンプトにいくつかの_例やデモンストレーション_を提供し、AIに望む正確なフォーマットやスタイルを示します。特定のタスクや珍しいタスクの出力品質を向上させます。
- ハルシネーションの管理と正確性の確保:
- 根拠となるデータを提供する: プロジェクトのナレッジベース（PRD、ユーザーフロー、技術スタック）を活用して、永続的なコンテキストを提供します。
- プロンプト内での参照: 事実に基づいたクエリや外部とのやり取りのために、関連するドキュメントのスニペットやデータを含めます。
- 段階的な推論を求める: AIにその推論過程を示すように促し、エラーを発見したり、不確実性を明らかにしたりします。
- 正直さを指示する: 「もし確信が持てない場合は…捏造せず、代わりに何が必要かを説明するか、明確化を求めてください」といったガイドラインを含めます。
- 反復的な検証: 重要なタスクの後、AIに出力を再確認するように依頼します。
- モデルの洞察を活用する（AIツールを知る）:
- ディスカッションモード vs. デフォルトモード（エージェントモード）: ブレインストーミング、デザインの議論、または即時のコード変更なしでのデバッグにはディスカッションモードを使用します。変更を実行する（コードの記述、コンポーネントの作成）には**デフォルトモード（エージェントモード）**を使用します。
- トークン長: 出力がトークン制限を超える可能性がある場合、大きなタスクを小さなプロンプトに分割します。
- フォーマットとコードの好み: 好み（例：「コードをマークダウン形式で出力する」）を述べて、AIをガイドします。
- アプリを改良するためのテクニック
- 「もっと…にする」/「…を減らす」: トーン、レイアウト、または強調を調整します。
- 「…を追加する」/「…を削除する」: 特定の機能やUIブロックを追加または削除します。
- 「[これ]を[あれ]に変更する」: テキスト、ビジュアル、レイアウト、またはコンポーネントのロジックを調整します。
- 「…のように感じさせる」: 馴染みのあるアプリのスタイルを借用して、レイアウトや動作をガイドします。
- 「…のためのロジックを追加する」: コードを必要とせずに、機能的なルールやフローを追加します。
- 「…をグループ化または整理する」: 明確さやワークフローのためにコンテンツを構造化します。
- 「条件付きの動作を追加する」: スマートな分岐や状態ベースの機能性を導入します。
- 「ユーザーに…させる」というステートメント: エンドユーザーの視点から機能性を組み立てます。
- 複雑なものを構築する際はレイヤーで構築する: シンプルに始め、次に機能を追加し、最後にビジュアルを磨きます。この段階的なアプローチは、システムや自分自身を圧倒するのを防ぎます。
- 制約と要件を含める: 「最大3つのタスクを一度に表示できるシンプルなTo-Doアプリを作成する」など、何を_すべきか_、何を_すべきでないか_を明示的に述べます。
- 曖昧さを避ける: さまざまな解釈が可能な用語を明確にします。
- トーンと礼儀正しさに注意する: 丁寧な表現はコンテキストと詳細を追加し、AIが指示をより明確に理解するのに役立ちます。
- フォーマットを有利に活用する: 特にAIにリストを出力させたり、シーケンスに従わせたい場合に、リストやステップを構造化します。
- 例や参照を活用する: ターゲットとなるデザイン、コードスタイル、または画像を提供して、AIに具体的な参照を与えます。
- フィードバックの統合: AIの出力をレビューし、改良のために具体的なフィードバックを提供します。
- アクセシビリティの強調: ARIAラベルやキーボードナビゲーションを含む、アクセシビリティ基準に準拠したコードをプロンプトで要求します。
- 定義済みのコンポーネントとライブラリ: 一貫性を保つために、UIライブラリ（例：Tailwind CSSを使用した
shadcn/ui）を指定します。 - 多言語プロンプト: コードコメントやドキュメントの希望言語を指定します。
- プロジェクト構造とファイル管理の定義: ファイル名とパスを概説して、整理されたコード生成を保証します。
- 正確な編集指示を提供する（AIに焦点を合わせる）: どこを、_何を_変更するかを具体的に指示するか、Lumiの「選択」機能を使用してコンポーネントをハイライトします。AIに触れてほしくないものを伝えます。
- ファイルのロック（回避策）: すべてのプロンプトで、重要なファイルを変更しないようにAIに一貫して指示します。
- デザインとUIの調整: ビジュアルの変更については、「純粋にビジュアルの変更」と明示的に述べ、レスポンシブ対応の計画をAIにガイドさせます。
- コードのリファクタリングと最適化: リファクタリングを依頼する際は、「動作の変更なし」を強調します。最初にリファクタリング計画を依頼し、その後段階的に実装することもできます。
- AI支援によるデバッグ: エラーログをプロンプト（理想的にはディスカッションモード）にコピーし、原因と解決策を尋ねます。修正がうまくいかない場合は、適応して新しい情報を提供します。
- AIを関与させるべき時（とそうでない時）: 複雑なロジック、ボイラープレートの生成、または複数ステップの操作にはAIを使用します。些細なタスク（例：テキストラベルの変更）には、手動で編集する方が速い場合があります。