効果的なプロンプトを書く
プロンプトは応答の質に最も大きな影響を与えます。 明確で具体的なリクエストは AI アシスタント が手助けするために必要な情報を与えますが、曖昧なリクエストはモデルに意図を推測させてしまいます。 これらのガイドラインは チャットと エージェントの両方に適用されます。
プロンプトを効果的にする要素
強いプロンプトには共通の習慣があります。 下記の各例では、弱いプロンプトとより強いバージョンをペアにして、その違いが分かるようにしています。
- 目標と成果を明確にする
望むものと良い結果がどういうものかを説明してください。
弱い例： 「コードを直して。」
ターゲットや症状がないため、モデルがどこで何が壊れているかを推測します。
より良い例： 「
parseDate関数がDateUtils.ktで+02:00のようなオフセット付きタイムスタンプで例外を投げます。 修正してテストを追加してください。」- 適切なコンテキストを提供する
リクエストが依存するファイル、エラー、シンボルなどは記憶から説明するのではなく必ず添付してください。
弱い例： 「なぜログインできないの？」
モデルはどのファイルやエラーを指しているのか分かりません。
より良い例： 「正常な資格情報でもログインは 401 を返します。 添付の
AuthService.ktとスタックトレースを参照してください。 期待される結果はトークン付きで 200 のレスポンスです。」- １つのリクエストにつき１つのタスクに絞る
大きなタスクは一度に１つずつ見直せるステップに分割してください。
弱い例： 「プロジェクトをリファクタリングして、テストを追加して、バグも直してください。」
スコープが広すぎます。 エージェントの集中力が散漫になり、結果の見直しも困難になります。
より良い例： 「
OrderControllerからバリデーションロジックを新しいOrderValidatorクラスに抽出してください。 動作は変更しないでください。」- 大きなタスクはまず計画する
スコープの広いタスクは、コードを変更する前にまずプランの提案を依頼してください。
弱い例： 「レポートモジュールをリライトして CSV および PDF 書き出しに対応して。」
これは決定事項が多い広範な変更なので、すぐにコードを書き始めると管理しづらくなります。
より良い例： 「コードを変更する前に、レポートモジュールに CSV および PDF 出力を追加するプランの概要を作成してください。 開始前に私がレビューします。」
- 「完了」の定義を明確にする
終了の判定となるメトリクス、テスト、フォーマットなどを明示してください。
弱い例： 「もっと速くして。」
メトリクスやゴールがないため、変更が効果的だったか判断できません。
より良い例： 「
/searchエンドポイントは約 3 秒かかります（10,000 行の場合）。" レスポンスタイムを短縮し、現在の API を維持し、変更点を説明してください。」- 制約を明示する
使用または回避すべきライブラリ、ファイル、規則などを明示してください。
弱い例： 「キャッシュを追加して。」
モデルは、プロジェクトに合わないライブラリや手法を選んでしまう場合があります。
より良い例： 「既存の Caffeine 構成を使って
UserRepository.findByIdをCacheConfig.ktで５分 TTL でキャッシュしてください。 依存関係は追加しないでください。」- エージェントに作業の検証を依頼する
結果の確認方法をエージェントに伝えてください。
弱い例： 「コードを更新したら完了です。」
確認作業を省くと、実際に変更が有効かどうか分かりません。
より良い例： 「変更後に
./gradlew testを実行して、ビルドが通ることを確認してから終了してください。」- 繰り返し
応答を見直して、再度一からやり直すのではなく、重点的なフォローアップを送りましょう。
弱い例： 「違うよ、もう一度やって。」
詳細を伝えずに再試行すると、惜しい部分も失われモデルに新たな情報が伝わりません。
より良い例： 「良いスタートです。｣ 構造はそのまま、ただし空の入力を処理し、例外の代わりに空リストを返してください。」
よくある落とし穴
強いプロンプトも送信方法や応答の扱い方次第で効果が損なわれる場合があります。 よくあるミスとその防ぎ方について紹介します。
不完全なリクエストの送信
リクエストを送信する前に内容を書き終えてください。 １つの質問を複数メッセージに分けると前後の文脈が断片化され、弱い回答につながります。 複数行のプロンプトを作成する際は改行を加えてメッセージを組み立て、完成してから送信してください。 また、 コンテキストを添付することで、モデルが１ターンで必要な情報を全て取得できます。
無関係なタスクで１つのチャットを続ける
チャット内の各メッセージは前の内容を元に積み重なります。 同じ会話で無関係なタスクに移ると、前の文脈が引き継がれて回答が逸れることがあります。 話題が変わったら新しいチャットを始めて、モデルが初期状態で対応できるようにしましょう。
出力を完全に制御できると期待する
プロンプトは応答の方向性を示しますが、結果を完全にコントロールすることはできません。 「文章は２文で」などと指定すると効果はありますが、絶対的な制限にはなりません。 長さやフォーマットが重要な場合は、一度のプロンプトで完璧を期待せず、フォローアップで調整を依頼しましょう。
内容を確認せずに変更を反映する
モデルやエージェントは間違っていても自信ありげに回答することがあります。 生成されたコードやエージェントによる修正は、受け入れたりコミットしたりする前に必ず見直してください。 各応答は確認すべきドラフトと捉え、最終的な成果物とは思わないようにしてください。
効果的なプロンプトを再利用する
プロンプトが一貫して良い結果をもたらし頻繁に利用する場合は、 プロンプトライブラリに保存して書き直しをせず再利用できます。 すべてのリクエストで適用したいガイドラインは、各プロンプトに繰り返すのではなく、 プロジェクトルールや エージェントインストラクションファイルで定義しましょう。