コーディング向けプロンプト実践：目的・前提・期待出力の分け方

コーディングを依頼するプロンプトは、次の3要素に分けて書くと意図が伝わりやすくなります。

• 目的：何を達成したいか（新機能の実装／不具合の修正／可読性の改善 など）
• 前提：現在の状態、使用している技術、変更してよい範囲
• 期待出力：差分だけでよいか、説明も欲しいか、対象ファイルはどこまでか

この3要素のどれかが欠けると、AIは不足分を推測で補います。推測が意図とずれると、想定より広い範囲を書き換えられたり、逆に必要な変更が漏れたりする原因になります。

実装依頼の型

「〔目的〕を実装したい。前提は〔現状の構成・制約〕。〔対象ファイル・関数〕の範囲内で、〔期待する出力形式〕で答えてください。」という順番で書くと、AIが着手前に前提を踏まえやすくなります。

修正依頼の型

修正依頼では「再現手順」と「影響範囲の指定」を必ず含めます。エラーメッセージや期待する挙動との差分を具体的に伝える方法はエラーをAIに直させる手順で詳しく扱っています。

レビュー依頼の型

レビューを依頼する場合は、見てほしい観点（セキュリティ・可読性・パフォーマンスなど）を先に指定すると精度が上がります。観点別の依頼文例はAIへのレビュー依頼文例集にまとめています。

悪い例

「ログイン画面を直して」だけでは、何が問題で、どこまでの変更が許容されるかが伝わりません。AIは推測で全体を書き換える可能性があります。

良い例

「ログイン画面で、メールアドレス未入力のまま送信するとエラーメッセージが出ずに何も起きない。src/pages/login.tsxのバリデーション処理だけを対象に、未入力時にエラーメッセージを表示するよう修正してほしい。差分だけを出力してください。」のように、目的・前提・期待出力がそろっていると、意図した範囲だけを直しやすくなります。

公式のプロンプト設計の考え方は、AnthropicのPrompt engineering overview（新しいタブで開きます）でも、タスクを明確に分解して指示することの重要性が解説されています。

プロンプトの基本とこの記事はどう違いますか？

基本編はAIに伝わる指示全般の型を扱うのに対し、この記事はコーディング特有の要素、たとえば再現手順や影響範囲の指定、差分の出力範囲の指定などに絞った実践的な組み立て方を扱います。

1回のプロンプトに詰め込みすぎるとどうなりますか？

実装・修正・レビューなど複数の目的を1つのプロンプトに詰め込むと、AIがどこまでを優先すべきか判断できず、意図と違う範囲まで変更されることがあります。目的ごとにプロンプトを分けるほうが結果を確認しやすくなります。

期待する出力形式はどう指定すればいいですか？

「差分だけを出力してほしい」「変更したファイルを一覧で示してほしい」など、欲しい出力の形をプロンプトの最後に明示します。形式を指定しないと、AIが説明文を長く付けたり、不要な部分まで書き直したりすることがあります。