生成AIプロンプトの応用テクニック｜回答の質を高め、複雑な仕事を仕上げる方法
生成AIへ目的、素材、条件、出力形式まで伝えられるようになると、メールの下書きや短い要約は作りやすくなります。一方、長い資料の分析、複数案の比較、企画の作成では、必要な情報を渡しただけでは一般的な回答にとどまり、期待する品質まで届かないことがあります。 複雑な仕事では、完成形・途中成果・評価基準を設計すると、AIの回答を一段ずつ求める品質へ近づけられます。
プロンプトの応用テクニックというと、Chain of ThoughtやFew-shotなどの専門用語を思い浮かべるかもしれません。しかし、すべての技法を覚え、長いテンプレートへ詰め込む必要はありません。 応用テクニックの目的は、完成形・途中成果・合格条件を見える形にして、AIの回答を求める品質へ近づけることです。 途中で確認しながら進めるため、質を高めるだけでなく、完成後の大きな作り直しも減らせます。
この記事では、良いサンプルの分析、長い入力の区切り、工程分割、評価基準、自己レビュー、複数案比較、プロンプト最適化を解説します。Chain of Thought、Self-consistency、ReAct、Tree of Thoughtsについても、 使える仕事と実際の使い方を、通常のチャットで試せる形まで落とし込みます。
基本的な依頼の作り方から確認したい場合は、先に「生成AIプロンプトの書き方」を読むと、 必要な情報を伝える基本編と、求める品質へ近づける応用編の違いが分かります。
この記事のまとめ
- 応用テクニックは、完成形・途中成果・合格条件を整え、AIの回答を求める品質へ近づける方法です。
- 良いサンプルは、そのまままねさせず、品質を生む共通点をAIに抽出させます。
- 長い入力は役割ごとに区切り、複雑な仕事は人が確認したい途中成果で分けます。
- 評価基準を先に決め、下書き・レビュー・修正を分けると、使える部分を残して直せます。
- 専門技法はすべて使わず、複雑な推論、回答の照合、探索など、仕事の性質に合わせて選びます。
1. 応用テクニックは、回答の質を高め、複雑な仕事を仕上げるために使う
「取引先へ日程変更を知らせるメールを作る」のように、一回の出力を見て直せる仕事は、生成AIプロンプトの基本的な書き方で十分です。応用テクニックが役立つのは、調査、分析、企画、比較のように、 完成までに複数の判断があり、良い成果物の条件を一度の指示だけでは伝えにくい仕事 です。
たとえば、20件の顧客アンケートから改善提案を作る場合、一度に提案書まで作らせると、AIがどの基準で意見を分類したかが見えず、一般的な提案に寄ることがあります。先に意見の分類と論点を作らせ、人が重要度と根拠を確認してから提案へ進めます。 途中成果を整えることで、完成品の具体性と説得力を高められます。
長いプロンプトより、途中成果の確認が回答の質を左右する
条件を増やせば、AIに伝わる情報は増えます。しかし、指示が長くなっても、AIが何を根拠に判断したか、人がどこで品質を確かめるかは見えるようになりません。 複雑な仕事では、指示の詳しさより、途中成果を見て次の工程へ進める流れが品質を左右します。
完成イメージを言葉にしにくい場合はサンプルを使います。資料と指示が混ざる場合は入力を区切ります。途中で方向を確認したい場合は工程を分け、良し悪しを判断できない場合は評価基準を作ります。 品質を高めたい場所に合う方法だけを足せば、プロンプトを必要以上に複雑にせず、回答を改善できます。
完成形・途中成果・合格条件のどこが曖昧かを見分ける
応用テクニックを選ぶときは、「AIの回答が悪い」とまとめず、何が見えないのかを考えます。完成形が見えないなら、良い例から特徴を抽出させます。途中成果が見えないなら、完成前に確認できる工程へ分けます。合格条件が見えないなら、作成前に評価基準を決めます。 完成形・途中成果・合格条件の3つに分けると、品質を高めるために次に試す方法が分かります。
応用テクニックを一度に入れる必要はありません。 一つの変更で何が改善したかを確かめる方が、次の仕事でも使えるルールを残せます。
2. 良いサンプルをAIに分析させると、言葉にしにくい品質をルール化できる
例を渡さずに依頼する方法はZero-shot prompting、いくつかの例を渡す方法はFew-shot promptingと呼ばれます。 まずは例なしで頼み、形式・表現・判断パターンを言葉だけで説明しにくい場合にサンプルを使います。 ただし、完成例をそのまま「まねて」と頼むと、固有の内容や不要な癖まで反映されることがあります。そこで、サンプルを模倣させる前に、品質につながる特徴をAIに分析させます。
Anthropicのプロンプトガイドは、例を実際の用途に近く、多様で、区別しやすい構造にするよう勧めています。 サンプルの数を増やすことより、今回の用途に近い特徴を持っているかが重要です。
テクニック1：複数の良い例から、品質を生む共通点をAIに見つけさせる
たとえば、顧客向けのお知らせメールを安定して作りたいとします。 良いメールを3通渡し、すぐに新しいメールを書かせるのではなく、まずAIへ分析だけを頼みます。
以下の3つは、顧客向けのお知らせメールの良い完成例です。
固有の内容や表面的な言い回しではなく、品質につながっている共通点を分析してください。
次の観点を含めてください。
1. 顧客が最初に知る必要がある情報を、どのように選んでいるか
2. 変更の理由と顧客への影響を、どのような順序で伝えているか
3. 顧客が次に取る行動を、どのように分かりやすくしているか
共通点を、別のお知らせメールにも使える作成ルールへ変えてください。
まだ新しいメールは作成しないでください。
AIが「冒頭で変更内容と対象者を明示する」「理由より先に顧客への影響を伝える」「問い合わせが必要な条件を具体化する」といったルールを出したら、人が内容を確認します。 採用するルールを決めてから新しい成果物を作らせると、分析の誤りや不要な特徴を引き継ぎにくくなります。
この方法はメールに限りません。社内FAQなら、質問の切り分け方や例外の示し方を分析できます。意思決定用の要約なら、根拠、リスク、未確認事項のつなぎ方を抽出できます。 AIに任せるのは共通点を探して言葉にする作業であり、使うルールを選ぶ判断は人が行います。
良い例と避けたい例を比べると、まねてほしくない特徴も伝わる
良い例だけでは、品質を生む特徴と、たまたま含まれている癖を区別しにくいことがあります。 同じ用途の避けたい例も渡し、良い例との違いをAIに分析させます。
「良い例」と「避けたい例」を比較してください。
次の点について、避けたい例が使いにくい理由を説明してください。
- 必要な情報を見つけにくくしている箇所
- 根拠が弱く見える箇所
- 読み手が次の行動を判断できない箇所
違いを「採用するルール」と「避けるルール」に分けてください。
例文固有の内容は再利用しないでください。
「丁寧さが足りない」のような感想ではなく、何が判断を妨げているかまで比べさせます。 良い例と避けたい例の差をルールにすれば、好みを伝えるだけでなく、使えない状態を避ける条件も作れます。
サンプルを増やす前に、今回の目的に合う完成例だけを選ぶ
サンプルを選ぶときは、有名な文章か、見た目が整っているかではなく、実際の用途、読み手、必要な詳しさが近いかを見ます。役員向けの意思決定資料と新入社員向けの説明資料を混ぜると、どちらを重視するか曖昧になります。 用途の違う完成例を増やすより、今回の成功条件がはっきり表れている例を絞る方が使いやすくなります。
例の数に全モデル共通の正解はありません。AIにサンプルの関連性や多様性を評価させることもできますが、最終的には、今回まねてよい成果物かを人が判断します。 AIが抽出したルールを一度確認する工程が、サンプルの量より重要です。
3. 長い入力と複雑な仕事は、区切りと工程分割で混乱を防げる
顧客アンケート、製品仕様、社内ルール、参考例を一つの入力へ貼り付けると、どこまでが指示で、どこからが材料なのか分かりにくくなります。さらに、分析から提案まで一度に頼めば、最初の読み違いが完成版まで引き継がれます。 入力の中を分ける「構造化」と、仕事の進行を分ける「工程分割」は、別の問題を解決する方法です。
テクニック2：指示・素材・サンプルを見出しやタグで区切る
短い依頼なら、Markdownの見出しで十分です。 入力を「依頼」「素材」「条件」「出力形式」に分けると、AIだけでなく、後から使い回す人も内容を確認しやすくなります。
# 依頼
顧客アンケートから、解約につながりそうな不満を整理してください。
# 素材
ここにアンケートを貼り付けます。
# 条件
アンケートに書かれていない原因は推測しないでください。
似た意見をまとめる場合も、元の発言番号を残してください。
# 出力形式
「不満の分類」「具体的な発言」「影響」「確認が必要な点」に分けてください。
資料や完成例が増え、見出しだけでは関係を表しにくい場合は、 XMLタグを使って入力の階層を示せます。
<instructions>
複数の調査資料から、導入判断に必要な情報を抽出してください。
</instructions>
<documents>
<document id="1">資料1の内容</document>
<document id="2">資料2の内容</document>
</documents>
<output_format>
資料ごとに、確認できた事実と未確認事項を分けてください。
</output_format>
タグやMarkdown見出しを使うと、指示、文脈、タスクの境界を示せます。 区切りの目的はプロンプトを高度に見せることではなく、命令と参考情報の混同を減らすことです。 短い依頼までタグで囲む必要はありません。
テクニック3：完成品を頼む前に、人が確認したい途中成果で仕事を分ける
工程分割は、プロンプトチェイニングとも呼ばれます。前の出力を次の入力へつなぎ、複雑な仕事を段階的に進める方法です。 AIの内部思考を細かく指定するのではなく、人が確認したい中間成果物を基準に分けます。
調査メモからサービス導入の判断資料を作るなら、次のように進められます。まず、調査メモから事実、懸念、未確認事項を抽出させます。人が分類を確認した後に、複数サービスを同じ観点で比較させます。その比較を確認してから提案を作らせ、最後に元資料との不一致を探させます。 論点整理、比較、提案、確認を分けることで、どの工程でズレたかが分かります。
最初の依頼では、 この段階で作るものと、まだ作らないものを明示します。
まず、添付した調査メモから次の3点を抽出してください。
1. 確認できた事実
2. 導入判断に影響する懸念
3. 追加確認が必要な情報
この段階では、サービスの比較や導入提案は作らないでください。
私が抽出結果を確認してから次へ進みます。
現在のモデルは、多段階の作業を内部で処理できる場合もあります。それでも、中間出力を検査したい場合や、途中で採用・修正・中止を選びたい場合は、工程を分ける意味があります。 工程分割のメリットは、AIを細かく縛ることではなく、完成前に人が方向を選び直せることです。
前の出力を採用・修正してから次へ渡すと、ズレを引き継がない
工程を分けても、AIの出力を自動的に次へ流せば、最初の誤解も引き継がれます。次へ進む前に、採用する論点、外す論点、追加する情報を人が選びます。 途中確認は、AIの作業を止めるためではなく、誤った前提のまま完成版まで進ませないために入れます。
一方、短い要約や一度で確認できるメールまで細かく分けると、かえって操作が増えます。 完成後に直せる範囲が小さい仕事は一回で頼み、戻る範囲が大きい仕事だけを分割します。
4. 評価基準を先に決めると、使える部分を残して改善できる
「もっと説得力のある提案にして」「厳しくレビューして」と頼むだけでは、AIが何を良いと判断したか分かりません。修正版が大きく変わり、使えた部分まで消えることもあります。 作り始める前に合格条件を決め、作成・レビュー・修正を別の工程にすると、残す部分と直す部分を選べます。
テクニック4：作成前に「良い状態」を確認できる評価基準へ変える
「分かりやすい」「説得力がある」といった言葉は、そのままでは確認できません。導入提案なら、「決めるべき事項が冒頭で分かる」「主張の根拠が調査資料にある」「費用とリスクが同じ条件で比較されている」「未確認事項が分けられている」のように置き換えます。 完成後に満たしたか確認できる条件が、評価基準になります。
評価基準が思いつかない場合は、 利用目的を伝え、AIに確認項目の候補を作らせます。
この資料は、部門責任者が新しいサービスを導入するか判断するために使います。
良い導入判断資料に必要な評価基準を提案してください。
各基準について、次を示してください。
- なぜ判断に必要か
- 完成後に何を確認すればよいか
- 元資料が必要になる項目
まだ資料本文は作成しないでください。
AIが出した基準をすべて採用する必要はありません。人が今回の目的に合うものを選び、必須条件と優先順位を決めます。 評価基準を先に確認すれば、AIが勝手に「良い」を決める範囲を減らせます。
テクニック5：下書き・レビュー・修正を分け、指摘を選んでから直す
自己レビューを使う場合も、「自分で確認して完成させて」と一度に頼みません。 下書き、レビュー、修正を分け、まず問題点だけを出させます。
以下の下書きを、4つの評価基準に沿ってレビューしてください。
この段階では本文を修正しないでください。
各指摘について、次を示してください。
1. 満たしていない評価基準
2. 問題がある箇所
3. 問題だと判断した理由
4. 最小限の修正方針
指摘を見た人が、採用するものを選びます。その後で「指摘2と4だけを反映し、ほかの箇所は変えない」と修正範囲を指定します。 レビューと修正の間に人の判断を置くと、AIの指摘を無条件で反映せず、使える部分を残せます。
使える部分を残し、最も大きなズレから一つずつ変更して前後を比べます。 変更点を絞ると、何が効いたかを次の依頼にも使い回せます。
テクニック6：複数案を同じ基準で比較すると、違いと弱点が見える
一つの案を何度も直すと、最初の方向から離れにくくなります。 別の考え方が必要なら、AIに複数案を出させ、同じ評価基準で比較します。
顧客からの問い合わせを減らす施策を、方向性が重ならないように3案出してください。
各案を次の基準で比較してください。
- 実現しやすさ
- 期待できる効果
- 導入に必要な費用と期間
- 想定されるリスク
- 成立に必要な条件
最終案は決定せず、各案の強み・弱み・改善案を整理してください。
AIの役割は、最終決定ではなく、比較軸をそろえて違いを見えるようにすることです。現場の優先順位や実行可能性は人が判断します。 複数案を出すメリットは案の数ではなく、一案目では見えなかった選択肢と弱点を見つけられることです。
AIのレビューは問題候補を見つけられるが、正しさの保証にはならない
AIは、元資料との不一致、抜け、曖昧な表現、読み手とのズレを探す補助に使えます。しかし、同じAIが自分の回答を見直しても、誤った前提に気づかない可能性があります。 AIによる品質改善と、信用して使えるかを確かめる検証は別の工程です。
Microsoftの検証ガイドも、文章を整えることと、事実や判断を検証することを分けています。数字、日付、固有名詞、重要な判断は、元資料や信頼できる情報源と人の確認を残します。 AIのレビューは問題候補を増やし、最終的な確認は根拠を持つ人が行います。
5. 指示に迷ったら、現在のプロンプトと困った出力から改善案を作らせる
複雑な仕事ほど、どの条件や評価基準を書けばよいか分からないことがあります。その場合は、AIに改善されたプロンプトを作らせるメタプロンプトを使えます。ただし、「このプロンプトを良くして」だけでは、AIも改善の方向を決められません。 目的、現在のプロンプト、期待した結果、実際に困った出力の4つを改善材料として渡します。
テクニック7：メタプロンプトで、期待と実際のズレから改善案を作らせる
# 利用目的
複数サービスの調査結果から、上司が導入候補を絞るための判断材料を作りたい。
# 現在のプロンプト
ここに使用したプロンプトを貼り付けます。
# 期待した結果
各サービスの違い、導入条件、未確認事項が分かる回答。
# 実際の問題
一般的なメリットの説明が多く、元資料にない内容も混ざった。
# 依頼
期待と実際のズレが生じた原因を分析してください。
不足情報、曖昧な指示、不要な指示を分け、改善理由と改善版プロンプトを示してください。
一度にすべてを変えず、効果が大きそうな変更から試す順番も提案してください。
現在の出力を見せることで、「何となく浅い」ではなく、どの指示が不足していたかをAIに分析させられます。 AIに任せるのは改善案と理由の作成であり、どの変更を試すかは人が選びます。
質問は、出力品質に大きく影響する不足情報だけに絞らせる
改善に必要な情報が足りなければ、AIに質問させます。ただし、質問数だけを「3つまで」と制限すると、重要な確認が漏れることがあります。 誤ると全体を戻す情報は先に聞き、仮定して進められる情報は仮案として示すよう指定します。
改善版を作る前に、出力品質へ大きく影響する不足情報があれば質問してください。
重要でない不足情報は、妥当な仮案を示し、仮定した箇所を明記してください。
質問と仮案を分けてください。
これなら、対象サービスや判断期限など外せない条件は確認しつつ、項目名や説明順の候補はAIに出させられます。 質問を減らすのではなく、仕事を止めるべき判断と仮置きできる判断を分けます。
改善前後の出力を比べ、効いた指示だけでプロンプトを最適化する
プロンプト最適化は、文章を長く整える作業ではありません。変更前後の出力を同じ評価基準で比べ、期待した結果へ近づけた指示だけを残します。 一度に多くの条件を変えず、最も大きなズレから試すと、改善した理由を把握できます。
効果のない役割指定、重複した注意書き、モデルがすでに対応できる細かな手順は外します。 短くすること自体が目的ではなく、結果へ影響しない指示を減らし、必要な条件を見つけやすくすることが目的です。
6. Chain of Thoughtなどの専門技法は、使える仕事と条件を見て選ぶ
1〜5章で紹介した7つは、サンプルを分析する、入力を区切る、工程を分ける、評価基準を作るといった、通常のチャットでも直接試しやすい方法です。Few-shot、プロンプトチェイニング、メタプロンプトなどの名称もありますが、 先に具体的な作業を理解し、専門用語はその方法を探したり使い分けたりするために添えています。
ここから扱うChain of Thought、Self-consistency、ReAct、Tree of Thoughtsも、それぞれ使える場面があります。ただし、複雑な推論、複数回答の照合、外部ツールを使う探索、複数経路の検討というように、必要になる仕事と利用条件が異なります。 使える仕事と通常のチャットでの試し方まで分かれば、必要な技法だけを選べます。
Chain of Thoughtは、計算や複数条件の推論を段階化したいときに使う
Chain of Thoughtは、複雑な問題を途中の推論へ分けて考える手法です。 計算過程の確認、複数条件を満たす案の検討、原因候補の切り分けなど、途中の判断が結論へ影響する仕事で使えます。
3つの配送方法から、今回の条件を満たす案を選んでください。
結論だけでなく、次を分けて示してください。
1. 判断に使った前提
2. 各条件を満たすかの確認
3. 条件を満たさない案と理由
4. 推奨案
5. 未確認事項
実務では、内部の思考過程をすべて表示させるより、前提、計算、判断根拠、未確認事項など、人が確かめられる成果を求めます。現在の推論モデルは内部で段階的に処理する場合があり、GoogleのガイドもGemini 2.5・3系では詳細な推論手順を回答に出させる必要は一般にないと説明しています。 Chain of Thoughtは単純な仕事へ付け足す決まり文句ではなく、途中の判断を確認したい問題で使います。
Self-consistencyは、複数の推論経路から一貫する答えを探す
Self-consistencyは、同じ問題に対して複数の推論経路を生成し、一貫して得られる答えを選ぶ手法です。元の研究では、複雑な推論問題には正解へ至る複数の考え方があるという前提で、Chain of Thoughtの複数経路をサンプリングしています。 自由な企画案を比べる方法ではなく、計算や論理問題など、答えの一致を確認できる仕事に向く方法です。
通常のチャットでは、技術的なサンプリングをそのまま再現できるとは限りません。 簡略化するなら、同じ問題を互いに独立した方法で解かせ、最終結果と食い違う箇所を確認します。
次の在庫補充数を、互いに独立した3通りの方法で計算してください。
前の計算結果を前提にせず、それぞれ最初から計算してください。
最後に、次を示してください。
- 3通りの最終結果
- 一致した結果
- 結果が食い違った場合、その原因になった前提や計算
- 人が確認すべき数値
多数決だけで正解とせず、計算過程を再確認してください。
複数の結果が一致しても、共通して同じ前提を誤っている可能性は残ります。 Self-consistencyは正解を保証する多数決ではなく、結論の安定性と、追加確認が必要な箇所を見つけるために使います。 出力回数と確認量が増えるため、一回で検算できる仕事には不要です。
ReActとTree of Thoughtsは、探索や複数経路の検討が必要な仕事で役立つ
ReActは、状況を判断しながら検索、計算、データ取得などの行動を選び、得た結果を受けて次へ進む考え方です。検索や外部ツールを使えるAIへ「必要な情報を調べる→結果を確認する→不足があれば追加で調べる→提案する」と進めさせる調査業務で役立ちます。 ReActは文章上の決まり文句ではなく、AIが実際に使えるツールがあるときに価値が出ます。
Tree of Thoughtsは、複数の解決経路を広げ、途中で評価しながら有望な経路を残す探索手法です。通常のチャットでは、異なる3案を出し、同じ基準で比較し、有望案だけを深掘りする形へ簡略化できます。 難しい計画や原因分析で、一つ目の考えに固定されたくないときに使えます。
この課題を解決する方向性を、前提が重ならないように3つ作ってください。
各方向性について、成立条件、期待効果、リスクを確認してください。
評価基準に合わない方向性は理由を示して外し、有望な方向性を2段階目まで具体化してください。
ReActの自動実行やTree of Thoughtsの厳密な探索は、AIエージェントや開発者向けの範囲になります。ここで示した複数案の比較はTree of Thoughtsそのものではなく、通常のチャットで考え方を利用する簡略版です。 一般的な仕事では、探索結果を確認する、複数案を評価してから深掘りするという流れを取り入れられます。
7. プロンプトで改善しないなら、素材・モデル・ツール・手順を見直す
応用テクニックを使っても回答が改善しない場合、原因がプロンプトにない可能性があります。社内事情や顧客の声が渡されていなければ、AIは固有の根拠を作れません。外部情報へ接続できなければ、最新の事実も確認できません。 プロンプトを直し続ける前に、必要な素材、モデルの能力、使えるツール、業務の正解基準を確認します。
必要な作業手順そのものが見えていない場合は、プロンプトの修正を続ける前に、AIに仕事の進め方から相談する方法へ切り替えます。 AIに工程、不足情報、最初の作業範囲を提案させると、プロンプト以外の原因も見つけやすくなります。
元情報がなければ、プロンプトを工夫しても固有の根拠は増えない
「もっと具体的に」と頼んでも、AIが使える材料がなければ、一般論を詳しくするだけになることがあります。顧客の発言、社内ルール、実績値など、判断材料そのものが不足していないかを確認します。 根拠がないときは、プロンプトを足すより、元資料を用意するか、確認できないと明示する方が安全です。
最新情報や厳密な処理は、検索・元資料・専用ツールを使う
最新情報は検索や公式情報、正確な計算や大量データの処理は適したツールへ切り替えます。AIが検索やファイルを利用できる場合も、参照した情報源と計算結果を確認します。 プロンプトは、存在しない情報や利用できない機能を補うものではありません。
社外へ公開する内容、顧客への回答、経営判断に使う資料は、速く作れることと信用して使えることを分けます。 重要な事実と判断は、人が元情報まで戻って確認します。
繰り返す仕事は、プロンプトを長くせず手順として保存する
同じサンプル、工程、評価基準を毎回使うなら、プロンプトへ貼り直すより、テンプレートやAI Skillとして保存できます。今回だけ変わる目的や素材をプロンプトに残し、固定できる確認手順は別に管理します。 うまく動いた一連の手順を保存すれば、毎回応用プロンプトを組み立てる負担を減らせます。
同じ手順を何度も使う段階になったら、 AI Skill（エージェントスキル）とは？で、手順として再利用する方法を確認できます。
まとめ
応用テクニックは、すべてを一つのプロンプトへ入れるものではありません。完成形をうまく伝えられないなら、複数の良いサンプルから共通点を抽出させます。完成までの判断過程が見えないなら、人が確認したい途中成果で工程を分けます。良し悪しが曖昧なら、作成前に評価基準を決めます。 AIの回答で質を高めたい場所に、対応する方法を一つずつ足します。
AIのレビュー、Self-consistency、ReActなども、人の判断を不要にする方法ではありません。 AIには分析、比較、問題候補の発見を任せ、人は使うルール、採用する案、信用できる根拠を確認します。
まずは、最近AIへ頼んだ仕事の中から、もう一段よくしたい成果物を一つ選んでください。完成形・途中成果・合格条件のどれを明確にすると品質が上がるかを確認します。 高めたい品質が一つ決まれば、最初に試すテクニックも一つに絞れます。