プロンプトエンジニアリングとは、AI モデルに渡す指示を書き、試し、磨いていくことで、必要な出力を安定して得られるようにする作業です。プロンプトに何を入れるか（タスク、コンテキスト、例、入力）と、それをどう並べるか（順序、形式、区切り）の両方を扱います。技術的に聞こえる言葉ですが、中身の大部分は丁寧に書くことと結果を確かめることです。
このページは Coddy のプロンプトエンジニアリング ガイドの目次です。なぜこの作業が効くのかを説明し、主要なテクニックとそれを教えるページを対応づけ、何気ないプロンプトと設計されたプロンプトの違いを示します。
プロンプトエンジニアリングが効く理由
言語モデルは、目の前にあるすべてのテキストをもとに、次に来るものを小さな断片ずつ予測してテキストを生成します。あなたの意図やプロジェクト、過去のチャットには、そのテキストが入力に含まれていない限りアクセスできません。つまりプロンプトは、すでにあなたを理解している相手への依頼ではなく、モデルが応答している状況そのものです。
ここから直接導かれることがあります。プロンプトが決めずに残した点を、モデルはいちばんありがちな選択で埋めがちです。いちばんよく使われる言語、いちばんよくある長さ、いちばんよくある読み手です。ありがちな選択が望みどおりのこともあります。そうでないときは、プロンプトの中でその点を決めてしまえば直ります。良いプロンプトは、ありえる返答の幅を狭めて、残ったものの大半が役に立つ状態にします。
この技術を形づくる事実がさらに2つあります。返答はサンプリングで生成されるため、同じプロンプトでも実行するたびに違う答えが出ることがあります。1回うまくいったプロンプトではなく、ほとんどの場合にうまくいくプロンプトだけが良いプロンプトです。また、モデルはプロンプト内のすべてのテキストを意味のあるものとして扱う可能性があるので、貼り付けたメールや紛れ込んだ一文が、素材だとはっきり示していない限り指示として読まれることがあります。
何気ないプロンプトと設計されたプロンプト
どちらのタブも同じことを頼んでいます。顧客のレビューを肯定的か否定的かに分けることです。それぞれ何が返ってくるかを比べてみてください。
内訳は次のとおりです。
- 賛否両論。速さは評価していますが、ログアウトされることに不満を感じています。
- 肯定的。ランニングの記録という目的に合っています。
- 否定的。サポートから返事がないことに不満を持っています。
全体としては、肯定的が1件、否定的が1件、賛否両論が1件で、評価は分かれています。
何気ないプロンプトへの返答は、人が読むには妥当な答えですが、プログラムでは使えません。ラベルが説明に混ざり、質問になかった3つ目の分類が現れ、最後に要約まで付いています。設計されたプロンプトは、すべてのラベルを定義し、出力の形を例で固定し、レビューをタグで囲んで指示と取り違えられにくくしています。1000件のレビューで実行しても、プログラムが解析できる出力がはるかに安定して得られます。確実さが必要なら、API の構造化出力機能とコード側の検証ステップで残りの差を埋めます。
主要なテクニック
下の各テクニックは、あなたの意図とモデルが受け取った内容のあいだの、それぞれ違う種類のずれを埋めます。実際のプロンプトの多くは複数を組み合わせています。
| テクニック | 何をするか | 使いどき |
|---|---|---|
| Zero-shot プロンプティング | 例なしで指示だけを与える | よくあるタスクを明確に説明できるとき |
| Few-shot プロンプティング | 入力と出力の例をいくつか見せる | 形式や判断基準を説明するより見せるほうが早いとき |
| Chain-of-Thought プロンプティング | 答えの前に推論を書かせる | 数学や論理のように手順が複数ある問題 |
| ロールプロンプティング | 誰の視点と基準で答えるかを決める | 読み手やレベルが重要なとき |
| 構造化出力 | 答えを JSON、表、テンプレートに固定する | 結果をプログラムや表計算ソフトが読むとき |
| 区切り文字と XML タグ | 指示と貼り付けた素材を分ける | プロンプトに文書、コード、ユーザーの文章が入るとき |
| プロンプトテンプレート | 良いプロンプトを穴埋め式にする | 同じ種類の依頼を繰り返すとき |
| プロンプトチェーン | 仕事を、結果を受け渡すステップに分ける | 1つのプロンプトに詰め込みすぎているとき |
| Self-Consistency | 答えを複数サンプリングして多数決をとる | 1本の推論では信頼できないとき |
| Tree of Thought | 複数の推論の筋を探索して評価する | 計画や探索が必要な問題 |
| ReAct | 推論とツール呼び出しを交互に行う | モデルが調べものや操作をする必要があるとき |
| メタプロンプト | モデルにプロンプトを書かせる、改善させる | プロンプトの書き方で行き詰まったとき |
| コンテキストエンジニアリング | 指示だけでなく、モデルが目にするものすべてを設計する | モデルを使ったアプリやエージェントを作るとき |
初めてなら、まずプロンプトの書き方で1つのプロンプトの構成要素を学び、次に Few-shot プロンプティングと構造化出力に進んでください。この3つで日常の問題の大半に対応できます。
プログラム向けに作られたプロンプト
ソフトウェアに組み込まれたプロンプトは、まだ誰も見ていない入力に対して何千回も実行されるので、チャットのメッセージよりも多くのことを明記します。下のプロンプトは、コードの差分からコミットメッセージを書きます。各パートをオフにして、それぞれが何を防いでいるかを確かめてください。例がないと書き方がぶれ、制約がないと perf や style のように、チームが使っていない種類をモデルが使うことがあります。
function validatePassword(password) {
- if (password.length > 8) {
+ if (password.length >= 8) {
return null;
}
return 'Password must be at least 8 characters';
}fix(auth): ちょうど8文字のパスワードを受け付けるよう修正
- 判定が > 8 だったため、8文字のパスワードが拒否されていた
- エラーメッセージの「at least 8」と判定条件が一致するようにした
プロンプトエンジニアリングの学び方
プロンプトを実行し、返ってきたものをよく見ることで身につきます。実践的な進め方は次のとおりです。
- プロンプトの構成要素を覚える。タスク、コンテキスト、入力、形式、制約です。失敗の多くは、このどれかが欠けていることに行き着きます。
- 繰り返している実際のタスクを1つ選ぶ。チケットの要約、エラーの説明、メールの下書きなどです。そのためのプロンプトを書きます。
- テスト用の入力を5〜10個集める。扱いにくいものも含めます。空の入力、とても長い入力、別の言語の入力などです。
- 一度に1か所だけ変える。そしてすべての入力で実行し直します。3か所変えて出力が良くなっても、どの変更が効いたのかはわかりません。このループはプロンプトの反復改善で詳しく扱っています。
- 特定の失敗が起きたときにテクニックを足す。形式がぶれるなら例を、複数ステップの答えが間違うなら段階的な推論を、貼り付けた文章が指示に混ざるなら区切り文字を使います。
主要なモデル提供元も自社モデル向けのプロンプトガイドを公開しており、読む価値があります。それぞれのモデルファミリーが何に最もよく反応するかが書かれているからです。
プロンプトエンジニアは職業か
「プロンプトエンジニア」という肩書きで採用した企業もあり、チャットモデルが広く使われはじめた時期には特に目立ちました。ただ、多くの場合このスキルは別の仕事の一部です。開発者は自分が作る AI 機能のためにプロンプトを書き、サポートチームは顧客対応アシスタントのために書き、アナリストやライターは毎日使っています。
AI プロダクトを作るチームでは、仕事の範囲が広がりました。モデルの入力に何を入れるか（検索で取ってきた文書、ツールの結果、会話履歴、メモリ）を選ぶことは、指示の言い回しと同じくらい重要で、この広い仕事はコンテキストエンジニアリングと呼ばれることが多くなっています。もう半分は、プロンプトが多くの入力で機能するかを測る作業で、一般に評価（エバリュエーション）と呼ばれます。
新しいモデルで変わること
初期のプロンプトエンジニアリングは小手先の技に頼っていました。魔法のフレーズ、凝ったペルソナ、同じ指示を何度も繰り返すことなどです。現在のモデルは素直な指示にずっとよく従い、推論モデルは答える前に内部で問題を解いているので、「ステップごとに考えて」と頼んでも以前ほど効果はありません。
変わっていないのは、もともと小手先の技ではなかった部分です。あなたが伝えない限り、モデルは読み手も、データも、制約も、良い結果とはどういうものかも知りえません。明確に仕様を伝えることは長く使えるスキルで、このガイドが大半のページを割いているのもその部分です。
よくある質問
プロンプトエンジニアリングとは、簡単に言うと何ですか？
プロンプトエンジニアリングとは、AI モデルが必要な答えを返すように指示を丁寧に書き、安定してその答えが出るまで試して調整することです。モデルに何を伝えるか（タスク、コンテキスト、例）と、それをどう並べるか（順序、形式、区切り）の両方を扱います。
プログラミングができなくてもプロンプトエンジニアリングは学べますか？
学べます。中心となるスキル、つまりタスクを明確に伝える、コンテキストを与える、例を示す、出力形式を指定するといったことは、すべてチャットアプリの中で使えます。プログラミングが役立つのは、同じプロンプトを何度も実行したいとき、たくさんの入力で試したいとき、出力をプログラムに渡したいときです。
プロンプトエンジニアリングを身につけるにはどれくらいかかりますか？
基本なら半日で身につきます。良いプロンプトの構成要素と、Few-shot の例示や構造化出力といったいくつかのテクニックです。実際のタスクで安定した結果を出すにはもっと時間がかかります。多くの入力でプロンプトを試し、失敗するケースを直していく中で身につくものだからです。
プロンプトエンジニアは本当に職業として存在しますか？
「プロンプトエンジニア」のような肩書きで採用した企業もありますが、多くの場合このスキルは別の職種の一部です。AI 機能を作る開発者、ライター、アナリスト、サポートチームなどです。AI プロダクトを作るチームでは、評価の仕事や、モデルが目にするものすべてを設計する仕事と重なっていて、後者は今ではコンテキストエンジニアリングと呼ばれることが多くなっています。
新しい AI モデルでもプロンプトエンジニアリングは役に立ちますか？
新しいモデルほど小手先の技は必要なくなります。素直な指示によく従い、推論モデルは「ステップごとに考えて」と言われなくても問題を順に解いていきます。役に立ち続けるのは、もともと小手先の技ではなかった部分です。タスクを伝えること、モデルが知りえない事実を渡すこと、良い答えとはどういうものかを定義することです。
