プロンプトエンジニアリングの手法｜基本のコツと代表的な11手法

母のカレーが、毎回味が違いました。

凄く美味しい日と、普通に美味しい日があります。つまり、実家のカレーっていうのはいつも美味しいのですが、理由を聞いたら「そのときの野菜と肉による」と言われました。

あるとき、レシピを書いてもらおうとしました。書けませんでした。 玉ねぎは「適当」、煮込みは「いい感じになるまで」。本人の中では一貫しているのに、外に出せない。

そして、味が違う日に原因を特定できません。 玉ねぎが少なかったのか、煮込みが短かったのか、そもそも何が変わったのかが記録されていないからです。

先に一行だけ置きます。プロンプトエンジニアリングとは、AIから望む出力を得るために、指示文の書き方や与える情報の構成を設計する技術のことです。

題材は、開発サイクルを自動で回すエージェントです。工程ごとに違う指示を出して、成果物を作らせます。

前置きはさておき、本題に入ります。

今日は、その指示文そのものを、AIに組み立てさせていた話をしていこうと思います。

① 教科書どおりに、上位のAIに指示文を作らせる

先に、プロンプトエンジニアリングの手法を教科書どおりに揃えておきます。基本のコツ、代表的な手法、活用例、そして注意点まで。

プロンプトエンジニアリングとは

プロンプトエンジニアリングとは、生成AIへの指示文（プロンプト）を設計して、欲しい出力が返ってくる確率を上げる作業です。

「うまい聞き方を探すこと」だと理解すると、途中で止まります。実務でやっているのは、同じ仕事を何度も回せる形に、指示を固めていくことです。この違いは、後の注意点のところでもう一度出てきます。

プロンプトの構成要素｜4つの部品

要素	書くこと	抜けると
指示	何をしてほしいか	雑談で終わる
文脈（コンテキスト）	前提、背景、参照させる資料	一般論しか返らない
入力データ	処理してほしい対象そのもの	対象が特定されない
出力形式（出力インジケータ）	項目、順序、文字数、書式	毎回ちがう形で返る

業務に載せるとき、いちばん効くのは4番目です。内容が合っていても形が揺れると、後工程が受け取れません。出力形式を書いていない指示文は、業務では未完成だと考えてください。

プロンプトエンジニアリングの仕組み｜なぜ書き方で出力が変わるのか

LLMは、与えられた文章の続きとしてもっともらしい語の並びを組み立てます。与えた文章が変われば、続きの確からしさの分布も変わります。

だから「知っているのに答えない」のではなく、「その聞き方だと、別の続きのほうが確からしかった」だけです。知識を引き出す作業ではなく、出力の範囲を狭める作業だと考えると、設計しやすくなります。

プロンプトエンジニアリングが重要な理由

• 同じAIでも答えが大きく変わる — モデルを替える前に、指示文で改善できる余地がある
• AIの使用用途が広がる — 分類、抽出、変換のように、対話以外の使い方ができる
• ユーザー体験の向上に繋がる — 製品に組み込む場合、出力の安定が体験そのものになる
• 費用が下がる — 指示を絞ると、無駄に長い出力が減り、単価に効く

4つ目は見落とされがちです。出力側の単価は入力側より高いのが普通なので、「余計なことを書かせない」だけで月額が変わります。

プロンプトエンジニアリングが注目される背景

モデルの性能が上がるほど、差がつく場所が「どのモデルを使うか」から「何をどう渡すか」へ移ってきたためです。

あわせて、業務に組み込む事例が増え、1回だけうまくいく指示ではなく、何百回でも同じ結果を返す指示が求められるようになりました。

基本のコツ①｜具体的な指示を与える

「良い感じにまとめて」ではなく、対象、範囲、目的、読み手を書きます。

具体化の当てどころは、「これを読んだ別の人が、同じ作業をできるか」です。人に頼めない指示は、AIにも頼めません。

基本のコツ②｜役割を与える（ロールプレイ）

「あなたは経理担当です」のように立場を与えると、使う語彙と、確認する観点が寄ります。

効果があるのは、その役割に固有の判断基準があるときだけです。「優秀な」「一流の」といった修飾語には、出力を狭める働きがほとんどありません。

基本のコツ③｜回答形式を指定する

項目名、順序、文字数、箇条書きか表か。後工程が機械なら、JSONのような構造で返させます。

形式を例示するのがいちばん確実です。言葉で説明するより、望む形の見本を1つ置いてください。

基本のコツ④｜前提条件と制約条件を指定する

• 使ってよい情報の範囲（渡した資料だけか、一般知識も可か）
• 書いてはいけないこと（推測、断定、社外秘）
• 分からないときにどうするか
• 文字数や語調の上限・下限

3つ目が、誤りをいちばん減らします。「渡した資料に無い場合は、無いと答える」の一文で、作り話の量が変わります。

基本のコツ⑤｜段階的に指示を与える

長い仕事を一度に投げず、手順を番号で示すか、工程を分けて渡します。

分けると、どこで失敗したかが分かるようになります。一度に投げた指示が失敗したとき、原因の切り分けができません。

代表的な手法①｜Zero-shot Prompting

例を与えず、指示だけで答えさせる方法です。いちばん短く、いちばん揺れます。要約や翻訳のように、やることが一意に決まる作業なら十分です。

代表的な手法②｜Few-shot Prompting

入力と出力の例をいくつか添えてから本題を渡します。分類や書式の統一では、これだけで精度が大きく変わります。

例は「正解」ではなく「形」を教えるために置きます。境界の例（迷う入力とその答え）を入れると効果が上がります。

代表的な手法③｜Chain-of-Thought（思考の連鎖）

答えだけでなく、途中の考えを順に書かせてから結論を出させます。計算や条件が絡む判断で効きます。

ただし出力が長くなるため、費用と時間が増えます。業務に載せるときは、途中の考えを表に出さず内部で処理させるか、最後に結論だけ抜き出す指示を足してください。

発展的な手法｜自己一貫性・思考の木・ReAct など

手法	何をするか	効くとき
Self-Consistency（自己一貫性）	同じ問いを何度か答えさせ、多数決を取る	答えが揺れる判断を安定させたい
Tree-of-Thoughts（思考の木）	複数の筋道を枝分かれさせて評価する	探索的な問題
Generate Knowledge（知識生成）	先に前提知識を書かせてから答えさせる	前提が不足しがちな領域
ReAct	考える→道具を使う→観察する、を繰り返す	外部の情報や操作が必要な作業
Prompt Chaining（プロンプト・チェーン）	出力を次の入力に渡して段を分ける	工程ごとに検証したい
RAG（検索拡張生成）	社内文書を検索し、その内容で答えさせる	自社固有の情報を扱う
メタ・プロンプト／自動プロンプト	指示文そのものをAIに作らせる	候補を大量に出したい
PAL・方向性刺激・アクティブ・プロンプト	コード実行や誘導語で出力を寄せる	計算や特定の観点を外したくない
マルチモーダルCoT・グラフ・プロンプティング	画像や関係構造を含めて考えさせる	図表や関係を扱う

実務で最初に効くのは、下から4番目のPrompt Chainingです。1本の長い指示を段に割ると、どの段で崩れたかが見えるようになります。

逆に、メタ・プロンプトで指示文をAIに作らせる手は、扱いに注意が要ります。候補は速く出ますが、作った指示文がどれだったかを残さないと、同じ結果を再現できなくなります。

コンテキストエンジニアリングとの違い

	設計する対象	主眼
プロンプトエンジニアリング	指示文の書き方	1回の応答の質を上げる
コンテキストエンジニアリング	モデルに渡す情報全体（資料・履歴・道具）	長い作業を通して破綻させない

担当範囲が広がった、と読むのが実務的です。エージェントのように何十手も続く処理では、指示文の巧拙より、何を渡して何を渡さないかのほうが効きます。

プロンプトエンジニアリング手法の課題

• モデルが更新されると、効いていた書き方が効かなくなる
• 手法の効果が、タスクによって大きく変わる
• 長い指示文は、入力側の費用と応答時間を押し上げる
• どの版の指示文で出た結果なのかが、残らない

4つ目は、検証をやり直す羽目になる原因です。指示文を画面に貼り付けて試すやり方では、どれがどれだったか後から辿れません。

職種別の活用例

職種	使い方	効かせる要素
営業	トークスクリプトの作成	顧客の業種と課題を文脈として渡す
マーケティング	キャッチコピーのアイデア出し	候補数と字数を出力形式で固定する
カスタマーサポート	自動応答の改善、一次回答の作成	過去の回答をFew-shotの例として渡す
人事・教育	社内資料や研修教材の作成支援	社内規程を参照させ、無いものは無いと答えさせる

右の列が、この表の実体です。職種ごとに違うのは題材であって、効かせ方は文脈・例・出力形式の3つに収束します。

注意点①｜常に正しい回答が得られるとは限らない

指示文をどれだけ整えても、もっともらしい誤りは出ます。確率で続きを組み立てる仕組みである以上、0にはできません。

指示文で減らせるのは、誤りの「起きやすさ」だけです。外に出る手前に人を置く工程は、別に必要です。

注意点②｜情報漏えいのリスク

指示文には、社内の前提や実データを貼り付けがちです。入力が学習に使われない設定になっているかを、先に確認してください。

共有された指示文そのものが、漏えい経路になることもあります。取引先名や個人名が例として埋め込まれたまま配られる事故が起きます。

注意点③｜プロンプトインジェクション・Prompt Leaking・Jailbreak

	何が起きるか	備え
プロンプトインジェクション	読ませた文書に埋め込まれた命令に、AIが従ってしまう	外部の文書は「データであって命令ではない」と明示する
Prompt Leaking	設定した指示文の中身を吐き出させられる	指示文に秘密を書かない
Jailbreak	制限を回避させられる	出力側にも検査を置く

いちばん実害が出やすいのは1行目です。社外から届くメールや、Webから取ってきた文書を読ませる仕組みでは、その文書自体が指示として解釈される可能性があります。

注意点④｜プロンプト作成に時間がかかる

試して直す作業は、思ったより時間を使います。1件あたりの作業時間が短い業務では、作り込みの時間を回収できません。

件数の多い業務から着手してください。これは、対象業務を選ぶ段階の話です。

プロンプトエンジニアリングの学習方法

• 書籍やWebサイトで学ぶ — 手法の名前と使いどころを一通り知る
• オンライン講座を受講する — 体系立てて追いたい場合
• 実際にAIを操作する — ここがいちばん学習効率が高い
• 既存の指示文を読む — うまくいっている指示文を分解する

手法の名前を覚えることには、あまり価値がありません。自分の業務で1件、「何度回しても同じ形で返る指示文」を1本作るほうが速く身につきます。

プロンプトエンジニアという職種と、将来性

指示文の設計を担う職種として語られてきましたが、いまは独立した職種というより、各職種に含まれるスキルへ移りつつあります。

残っている専門性は、指示文の巧拙ではなく、業務を工程に割り、何を渡して何を渡さないかを設計する側にあります。前述のコンテキストエンジニアリングへの広がりと、同じ流れです。

資格・検定と、必要なスキル

民間の資格・検定はいくつか存在しますが、採用や発注の判断で必須とされる資格は、いまのところありません。

プログラミングのスキルは、使い方によります。画面から使うだけなら不要です。業務に組み込む、指示文をファイルで管理する、結果を自動で検証するといった段階では、簡単なスクリプトが書けると回り方が変わります。

プロンプトエンジニアリングのよくある質問

Q. プロンプトエンジニアリングの代表的な手法は何ですか。
基本はZero-shot、Few-shot、Chain-of-Thoughtの3つです。そのうえに自己一貫性、思考の木、知識生成、ReAct、プロンプト・チェーン、RAG、メタ・プロンプトなどがあります。実務で最初に効くのはプロンプト・チェーンで、長い指示を段に割ると、どこで崩れたかが見えます。

Q. 出力が毎回変わってしまいます。どうすればよいですか。
出力形式を指示に固定し、望む形の見本を1つ置いてください。項目・順序・文字数・書式まで書きます。内容が合っていても形が揺れると、後工程が受け取れません。

Q. プロンプトエンジニアリングにプログラミングスキルは必要ですか。
画面から使うだけなら不要です。ただし業務に組み込む、指示文をファイルで管理する、結果を自動で検証する段階になると、簡単なスクリプトが書けると進み方が変わります。

Q. プロンプトエンジニアリングに資格や検定はありますか。
民間の資格・検定はありますが、発注や採用の判断で必須とされるものは、いまのところありません。

Q. プロンプトエンジニアリングの将来性はありますか。
独立した職種としてではなく、各職種に含まれるスキルへ移りつつあります。専門性が残るのは、業務を工程に割り、何を渡して何を渡さないかを設計する側です。

Q. コンテキストエンジニアリングとは何が違いますか。
プロンプトエンジニアリングが指示文の書き方を設計するのに対し、コンテキストエンジニアリングはモデルに渡す情報全体（資料・履歴・使える道具）を設計します。長く続く処理では、後者のほうが効きます。

構成は、こうでした。

→ 上位のAIが状況を見る
→ 次に何をやるかを決める
→ その工程に合った指示文を組み立てる
→ 下位のAIに渡して実行させる

うまい設計に見えました。 状況に応じて指示文が変わるので、柔軟です。テンプレートを作り込む手間もありません。

動きました。 成果物も出ます。

ここまでは、教科書どおりです。

ここまでが、プロンプトエンジニアリングの教科書どおりの整理です。4つの部品を揃え、5つのコツで絞り、手法を当てはめる。1回の応答の質は、この手順で上がります。

この記事の後半で扱うのは、その先です。同じ指示文を何度も回して比べようとしたとき、比べている対象そのものが、どこに置かれているのか。

② そのとおりに回して、結果が揺れる

ところが、同じような状況でも、成果物の質が揺れました。

良い回と、そうでもない回があります。母のカレーと同じです。

原因を探そうとして、手が止まりました。

→ モデルが揺れたのか
→ 指示文が変わったのか
→ 状況の読み取りが違ったのか

切り分けられません。

というのも、そのとき実際に渡された指示文が、どこにも残っていなかったからです。会話の中で組み立てられて、そのまま渡されて、消えていました。

③ そして、揺れているのが指示文だと気づく

ログを掘って、実際に渡された文面を復元してみました。

毎回、違いました。

大きくは違いません。言い回しが少し違う。順番が入れ替わっている。ある回だけ一文が抜けている。

その程度の差で、成果物は変わります。

つまり、こうなっていました。

→ モデルの揺れ ＋ 指示文の揺れ
→ 2つの揺れが掛かっている
→ どちらが原因か分からない

カレーのレシピが書けない状態でした。

④ 原因は「再現性を、いちばん揺れる場所に預けていた」こと

原因を一つに絞ると、これでした。

指示文の生成を、確率的な道具に任せていました。

指示文は、実験でいう手順書にあたります。手順書が毎回変わるなら、結果を比較する意味がありません。

そして、柔軟さのために揺らしていたつもりでしたが、必要だったのは柔軟さではありませんでした。 状況によって変えたかったのは中身の値であって、文面そのものではなかった。

⑤ 直してみる — CLIが、全文を出力する

やったことは3つです。

1. 指示文をテンプレートとしてファイルに置いた。
工程ごとに1つ。文面はここにしかありません。

2. コマンドが、変数を埋め込んだ全文を出力するようにした。

プロンプトは組み立てない。コマンドが、変数注入済みの全文を出力する。

状況によって変わるのは、埋め込まれる値だけです。文面は変わりません。

3. どのテンプレートを使うかの解決も、コードに置いた。
工程名からファイルを引く対応表を作り、共有部分を持つ工程や、二重レビューを行う工程も、対応表の中で決定的に解決します。選ぶ判断も、モデルに渡していません。

そして、この方式には副産物がありました。プロンプトが、バージョン管理できる成果物になりました。

→ 差分が読める
→ レビューできる
→ コミットできる
→ 結果が変わったら、プロンプトの差分を見れば分かる

カレーのレシピが、書けるようになりました。
固定した対象を数えると、テンプレートが工程ごとに1つ、対応表が1つ、埋める値だけが可変という構成になりました。

要素	数	可変か
テンプレート	工程ごとに1つ	固定
対応表	1つ	固定
埋め込む値	状況による	可変はここだけ

もう一つ、実装で判断した点を書いておきます。プロンプトを出力するだけのコマンドでも、排他制御をかけています。 状態は変えませんが、監査記録への追記という副作用があるからです。ロックの要否は、状態を変えるかどうかではなく、副作用があるかどうかで決めました。

⑥ あとで知った — これはプロンプトの話ではなく、実験の話だった

素朴な対処のつもりでしたが、やっていたことを言い換えると、実験の基本でした。

変えるものを1つに絞る。

私は、モデルの調子と指示文の文面という2つの変数を同時に揺らして、結果を見ていました。それでは何も分かりません。理科の実験で最初に習うことです。

そして、この分野では最近、コンテキストエンジニアリングという言い方が使われるようになっています。指示文だけでなく、モデルに渡す文脈全体を設計対象として扱うという考え方です。

呼び名が広がったこと自体が、「渡すものを設計する」側に重心が移った証拠だと思っています。プロンプトを上手に書く技術から、何をどう渡すかを固定する技術へ。

固定できていないものは、設計されていません。毎回違う文面は、設計ではなく即興です。

即興が悪いわけではありません。探索の段階では、即興のほうが速い。 ただ、同じ結果を出したくなった瞬間に、即興は敵になります。
固定したあとの実測です。指示文が成果物としてバージョン管理に載りました。 変更が1行単位で追え、いつ誰が何を変えたかが残ります。載る前は、変更の記録がどこにも残っていませんでした。

新しい理屈は、ひとつも要りませんでした。
運用の規則にはこう書かれています。「プロンプトは組み立てない」「変数注入済みの全文を出力する」。ところで、この2行は指示ではなく仕様です。ただし、書いただけでは守られません。実際に守らせているのは、文面がファイルにしか存在しないという構造のほうです。

記録に残っている実例

2026年2月3日の決定。 指示文を、3段の合成で組み立てる形に変えました。

“`
[見出し] Agent Base Instructions
エージェントの基本指示

---

[見出し] Role Guidelines
役ごとの指針

---

[見出し] Task Instructions
工程ごとの技術的な指示
“`

区切りは `—` で固定し、各段に見出しを付けます。どこまでが誰の責任範囲かが、文字列の上で見えるようにするためです。

同時に、合成したあとの指示文を切り詰めた形でログへ出すようにしています。決定の文書にはこう書かれています。「システムプロンプトを、デバッグ用に記録する」。 出しておかないと、結果が悪かったときに、何を投げたのかが分かりません。

そして、4つの役すべてを、合成済みの指示文を受け取る形に一斉に変更しました。1つでも古い形が残ると、そこだけ再現できなくなるからです。

⑦ 何が変わったか

事故の原因が、特定できるようになりました。

“`
前：結果が悪い → 原因が分からない → プロンプトを書き直す（勘）
後：結果が悪い → プロンプトの差分を見る → 変わっていなければモデル側
“`

「変わっていない」と言い切れることが、いちばん効きました。
原因の切り分けにかかる時間も変わりました。以前は半日、いまは5分です。差分を見て、変わっていなければモデル側だと分かるからです。
固定したことの副産物として、共有できるようになりました。 社内では実際に、指示文の断片が共有されています。「カスタム指示に以下のプロンプトを追加してみてください」という形で、効果が確認できたものが回ってきます。

ところで、これは文面がファイルに存在するからできることです。会話の中で組み立てていたら、共有する対象がありません。 固定は再現性のためだと思っていましたが、共有の単位を作る作業でもありました。

⑧ 現場で使うなら、この2枚

表1：どこを固定し、どこを可変にするか

要素	固定	可変
文面（テンプレート）	固定。ファイルで持つ	—
埋め込む値	—	可変。ここが状況依存
どのテンプレートを使うか	固定。対応表で解決	—
モデルの選択	固定	試すときだけ変える
温度などの設定	固定	—

可変の行が1つだけになっているかを確認してください。 2つ以上あると、原因が切り分けられません。

表2：プロンプトをファイルで持つと得られるもの

得られるもの	どう効くか
差分	結果が変わった原因を特定できる
レビュー	変更前に人が見られる
履歴	いつから悪くなったかが分かる
再現	同じ入力で同じ出力になる

表3：固定した後にやること

手順	内容
1	テンプレートを1件だけ直す
2	同じ入力を3回流す
3	出力の差を見る
4	差が出たらモデル側、出なければ直した箇所が効いていない

4行目が要点です。 固定していないと、この判定ができません。差が出た理由を、いつまでも推測で語ることになります。

補：固定してから測った数字

項目	固定前	固定後
同じ入力3回の一致	0件	3件
原因の切り分け	半日	5分
テンプレート	0件	工程ごとに1件
可変の要素	多数	1件のみ

もう2件、実務の言葉を残しておきます。「テンプレートは工程ごとに1件だけ持つ」「対応表で決定論的に解決する」。ところで、この2件を守ると、指示文がどこにあるかを探す時間がゼロになります。

運用では、次の5件に名前を付けて配りました。名前が付くと、会議の中で指差せるようになります。

1件目、「先に固定するのは、中身ではなく作り方」。 文面を磨く前に、同じ入力から同じ文面が出ることを保証します。ここが揺れていると、以降の比較が全部無効になります。

2件目、「プロンプトは、変数を埋めた全文で出す」。 組み立て途中ではなく、実際に投げた1行までを出力します。あとから原因を追える形はこれだけです。

3件目、「揺れる文面は、原因を隠す」。 結果が悪かったとき、モデルの問題か文面の問題かが切り分けられません。切り分けられない状態で改善はできません。

4件目、「プロンプトを、差分がレビューできる成果物にする」。 バージョン管理に載れば、変更が1行単位で見えます。誰がいつ何を変えたかが残ります。

5件目、「事故の原因が特定できる形にしておく」。 再現できない事故は、直したかどうかも確かめられません。

この5件は、1枚に印刷して配れる分量に収めています。増やすと、誰も覚えません。

⑨ この考え方が効き続ける理由

モデルは、これからも変わります。新しい版が出て、挙動が変わります。 そのとき、自分の側が固定されていないと、変化を検知できません。

→ モデルが変わる → 結果が変わる
→ こちらも揺れている → どちらのせいか分からない
→ 分からない → 対応が勘になる

モデルの更新に備える最良の準備は、自分の側を固定しておくことです。

そして、これはプロンプトに限りません。渡す文脈、選ぶテンプレート、埋める値。渡すもの全部が対象です。 上位のAIに任せた部分が多いほど、モデルが変わったときに何が起きたか分からなくなります。

ただし、正直に書いておきます。固定すると、探索が遅くなります。 テンプレートを直してから試すので、思いついてすぐ試す軽さは失われます。探索の段階では即興のほうが速いのは、いまも変わりません。

どこで即興をやめるかを決めるのが、たぶんいちばん難しいところです。

固定したあとの実測です。同じ入力を3回流して、生成された指示文は3回とも完全に一致しました。固定前は、同じ条件で3回とも別の文面です。原因の切り分けにかかる時間も、半日から5分になりました。

そして、固定には副作用もあります。テンプレートを直すたびに、過去の出力と比較できなくなるという問題です。差分は追えますが、どの版で作った成果物かを記録していないと、後から突き合わせられません。いまは出力側に版を書き込んで対処していますが、きれいな形にはなっていません。

運用の規則から、もう2件引いておきます。「モデルはフォーマット検証をしない」「オーケストレーターに文面を任せない」。ところで、この2件はどちらも「やらせない」という書き方です。ただし、やらせないと決めた範囲は、必ず自分が持つことになります。実は、そこが固定のコストです。

関連して、プロンプトインジェクションをツール層で止める話と、LLMに自分の出力を検証させてはいけない話を別に書いています。AI機能を足しすぎて重くなる話はすでに公開しています。あわせて読むと、同じ判断が別の場所でも効いていることが分かると思います。

この判断を実際の案件で使う場面については、AIワークフロー自動化のページに整理しています。

---

同じ手順で同じ結果、といえば、同じレシピで作ったカレーの味が毎回違います。

理由ははっきりしていて、分量を一度も計っていないからです。揺れているのは腕ではありませんでした。

以上です。

▶ この記事のテーマを実務で相談する: 生成AIコンサルティング