プロンプトエンジニアリング応用｜目的別に効くプロンプト技法の選び方と組み合わせ方

基本は身についたはずなのに、難しい依頼になると途端にAIが当てにならない——そう感じたことはありませんか。役割・前提・出力形式という3要素を入れて、要約やメールの下書きは安定して出せるようになった。ところが「30ページの競合資料を読んで打ち手を提案して」のような込み入った仕事になると、論理が途中で飛び、聞いてもいない事実が混ざり、同じ依頼でも日によって出来がブレる。ネットの「最強プロンプト」を貼っても自分の案件には合わず、なぜ効くのかも説明できない。

この詰まりの正体は、「うまい呪文」を知らないことではありません。込み入った依頼に対して、目的に応じて使い分ける技法の引き出しが足りないことです。プロンプトエンジニアリングの応用とは、すごい呪文を1つ持つことではなく、目的に応じて効く技法を選んで組み合わせること。基本の3要素を土台に、難しい依頼ほど分けて・示して・点検させて・足していくと、安定して人に渡せる結果になります。

本講座は、この「応用＝目的別の技法選択」だけに絞ります。役割・前提・出力形式といった基礎の3要素や型の保存・再利用はAIプロンプトの基本が正本なので、本講座は「3要素は書ける前提」から始め、再説明はしません。生成AIそのものや各ツールの起動・基本操作はAI入門や各ツールの講座へ、仕上げた応用プロンプトを業務専用AIとして固定・配布する話はカスタムGPT作成へ譲ります。本講座が扱うのは、その手前にある「単発で込み入った依頼を、技法を組み合わせて安定させる設計」です。

この講座を終えると、次の3つができるようになります。基本プロンプトが応用で崩れる理由と、それを補う代表技法（段階分解・例示・自己検証・反復改善）がそれぞれ何のために効くかを自分の言葉で説明できること。ある目的（考えさせる／形を整える／事実を確かめる）に対して効く技法を選び、基本の3要素と組み合わせて1つのプロンプトに設計でき、出力が外れたときはどの技法が欠けていたかを特定して足し直せること。そして込み入った実務課題について、複数の技法を順に組み合わせた応用プロンプトを、根拠の確認と機密情報の扱いを踏まえて人に渡せる形に仕上げられることです。覚えて帰る型は「目的を分ける → 目的ごとに効く技法を当てる → 組み立てる → 出力を見て足す」。本講座では、「30ページほどの競合資料から、自社が取るべき打ち手を3つ提案する」という込み入った依頼を共通の題材として全章で追いかけます。基本依頼では崩れ、応用技法で安定する——その差をこの一つの場面で体感していきましょう。

基本プロンプトが応用で崩れる理由とプロンプトエンジニアリングの全体像

プロンプトエンジニアリングの応用は「うまい呪文探し」ではなく目的別の技法選択

プロンプトエンジニアリングとは、AIから望む出力を一貫して得るために指示を設計することです。ここで大事なのは、それが一発で完成するものではなく、成功の基準を決めて、最初のドラフトを試しながら良くしていく反復的な営みだという点です。Anthropicの公式ガイドも、プロンプト改善の前提として「ユースケースの成功基準が明確に定義されていること」「その基準に対して経験的にテストできること」「改善したい最初のドラフトがあること」の3つを挙げています（出典：Anthropic「Prompt engineering overview」）。

つまり応用とは、誰かの「最強プロンプト」を探して当てることではありません。自分の目的を決め、効く技法を選んで組み合わせ、出力を見て直していく設計の力です。基本の3要素は土台、技法はその上に乗せる道具——この関係を最初に押さえてください。

込み入った依頼が崩れる主因——詰め込みすぎ・根拠なし・曖昧

なぜ難しい依頼だと崩れるのか。生成AIはゼロショット、つまり例も手順も与えない一度の指示でも高い能力を示しますが、より複雑なタスクになると、それだけでは不十分になることがあります（出典：Prompt Engineering Guide「Few-Shotプロンプティング」）。実務で崩れ方を観察すると、原因はおおむね3つに分類できます。

1つ目は詰め込みすぎ。「資料を全部読んで、要点を整理して、競合と比較して、打ち手まで提案して」と一度に投げると、AIはどこかの段で論理が飛びます。2つ目は根拠を求めていないこと。「提案して」とだけ言うと、もっともらしいが資料に書いていない事実が混ざります。3つ目は曖昧さ。粒度や形式を指定しないと、出力が長くなったり短くなったりして毎回ブレます。共通例で「この資料を読んで打ち手を提案して」と一度に投げると、まさにこの3つが同時に起きて、根拠の薄い、要点のずれた提案が返ってきます。

応用で使う4つの技法の地図

これら3つの崩れを補うのが、本講座で扱う4つの技法です。地図として先に全体像を示します。

第一に、段階的に考えさせる技法（chain of thought）。最終回答の前に中間の推論ステップを出させることで、各ステップが明示され、論理エラーが起きにくくなります（出典：AWS「What Is Chain-of-Thought Prompting?」）。詰め込みすぎへの対処です。第二に、例を見せる技法（few-shot / multishot）。良い例を見せると出力の形式・トーン・構造が揃います（出典：Anthropic「Prompting best practices」）。曖昧さへの対処です。第三に、出力を自己点検させる技法（self-criticism）。モデル自身に出力を批評・検証させると、応答の洗練・改善につながります（出典：Learn Prompting「Self-Criticism Prompting」）。根拠なしへの対処です。そして第四に、反復改善（iterative）。一発で決めず、出力を見て指示を足していく仕上げの考え方です。

基礎を飛ばして技法に走る／長く書けば良いという誤解

ここでのつまずきは2つあります。1つは、基礎の3要素があやふやなまま技法に走ること。役割・前提・出力形式という土台が抜けていると、技法を乗せても安定しません。心当たりがあれば、AIプロンプトの基本で土台を固めてから戻ってきてください。もう1つは「長く凝ったプロンプトほど良い」という誤解です。応用は文字数の勝負ではなく、目的に合う技法を選んで組み合わせる設計の勝負。長く書くほど詰め込みすぎに近づくこともあります。

この章の確認（演習）

自分が最近AIで「難しくて満足に出せなかった依頼」を1つ思い出してください。その依頼の出力が崩れた原因が、①詰め込みすぎ（論理が飛んだ）、②根拠なし（事実が混ざった）、③曖昧（出来がブレた）のどれだったかを分類し、一言で書き出してみましょう。次章以降で、その依頼を技法で立て直していきます。

段階的に考えさせる技法——手順分解と思考の明示

難しいタスクは「一発」より「段に分けて順に考えさせる」と安定する

込み入った依頼を立て直す最初の技法が、段階的に考えさせる技法、いわゆるchain of thought（CoT）です。これは、最終回答を出す前にAIに中間の推論ステップを出させる手法で、複雑な問題を順序立てたロジックに分解させることで、算術・常識推論・論理など多段のタスクの性能を高めます（出典：AWS「What Is Chain-of-Thought Prompting?」）。なぜ効くのか。各ステップを言葉にさせる（明示させる）ことを強制すると、論理エラーが起きにくくなり、複数の段をまたぐ推論の精度が上がるからです（出典：AWS）。人が複雑な問題を一気に解かず、紙に書き出して分けて考えるのと同じ理屈です。

最も手軽な形は、指示に「ステップバイステップで考えてください（Let's think step by step）」という一文を添えることです。例を見せなくても、この短いフレーズだけで中間の推論を促せます（出典：AWS）。これを足すだけでも、いきなり結論に飛びつく出力が、過程の見える出力に変わります。

段階分解プロンプトの組み立て方——ゴール・段・各段の途中結論

もう一歩進めて、段を自分で設計しましょう。AWSの解説によれば、CoTの進み方は、まず問題を再記述し、次に課題をサブステップに分解し、各サブ結果を明示的に計算・正当化し、最後にそれらを統合して最終回答にまとめる、という構造をとります。この分解によって、AIは結論に飛びつく代わりに、問題の各要素へ注意を割り当てられるようになります（出典：AWS）。

実務に落とすと、組み立ては3手です。①最終成果（ゴール）を先に書く。②そこに至る段を指定する。③各段で「ここまでの結論」を一度出させてから次へ進ませる。途中結論を一度出させるのが、論理の飛びを防ぐコツです。

共通例を「論点抽出→比較→提案」の段に割る

共通例で組み立ててみましょう。「この資料を読んで打ち手を提案して」と一度に投げる代わりに、こう段に分けます。「①まず資料から論点を箇条書きで抽出してください。②次に、抽出した論点について自社と競合を比較表にまとめてください。③最後に、その比較を踏まえて自社が取るべき打ち手を3つ提案してください。各段はいったん出力を止めて、私の確認を待ってください」。こうすると、論点抽出の段で漏れがないかを確認でき、比較の段で観点を足せ、提案の段では前の2段が土台になるため根拠が地に足のついたものになります。なお、②の比較表づくりそのものをもっと深めたい場合は、AIで競合調査をする講座が個別タスクの正本です。本章は段に割る型の方を担います。

段に分けず最終成果だけ求める／段が多すぎて目的を見失うつまずき

つまずきは2つ。1つは、結局「最終成果だけ」を求めてしまうこと。段を指定したつもりでも「比較しつつ提案して」と1段に潰すと、CoTの効果は薄れます。もう1つは、段を細かく刻みすぎて目的を見失うこと。段は多ければ良いのではなく、共通例なら「整理→比較→提案」の3段程度で十分です。段の数は、人がその仕事を頭の中で分ける数に合わせるのが目安です。

この章の確認（演習）

第1章で挙げた自分の難依頼を、3つ以内の段に分けたプロンプトに書き直してください。各段の最後に「ここまでの結論を一度出して、私の確認を待つ」という一文を入れます。書けたら実際にAIに投げ、最初の段の出力が想定どおりかを確認してみましょう。

例で示す技法と、答えを点検させる技法——例示と自己検証

望む出力の良い例を見せて型を伝える

段に分けても、各段の出力が「思っていた形」と違うことがあります。ここで効くのが例示、few-shot（またはmultishot）プロンプティングです。例は、AIの出力の形式・トーン・構造を意図どおりに導く、最も信頼できる手段の一つで、よく練られた少数の例は精度と一貫性を大きく高めます（出典：Anthropic「Prompting best practices」）。言葉で「簡潔に、項目ごとに」と説明しきれない型——粒度・トーン・項目立て——も、良い例を1つ見せれば一発で伝わります。

良い例には条件があります。Anthropicは、例を①関連性が高い（実際のユースケースを忠実に反映する）、②多様（エッジケースを含み、AIが意図しないパターンを拾わないよう十分にばらつかせる）、③構造化（指示と例を区別できるように区切る）ものにすべきだとしています。そして、最良の結果には3〜5例を含めるのが目安です（出典：Anthropic「Prompting best practices」）。共通例なら、②比較の段で「良い比較表の見本」を1つ見せてから本番を頼むと、列の取り方や粒度が揃った表が返ってきます。

出した答えに根拠提示と点検をさせる

例示で形が揃っても、中身が正しいとは限りません。そこで使うのが自己検証です。これは、出した答えをAI自身に批評・点検させる技法で、応答の洗練・改善に効くことが知られています（出典：Learn Prompting「Self-Criticism Prompting」）。具体的な指示として、Anthropicは「終える前に、あなたの答えを〔基準〕と照らし合わせて検証してください（Before you finish, verify your answer against ...）」という一文を添える方法を挙げ、これで特にコーディングや数学において確実に誤りを捉えられるとしています（出典：Anthropic「Prompting best practices」）。

共通例なら、提案が出たあとに「各提案の根拠を、資料の該当箇所を示しながら説明してください。そのうえで、根拠が資料にない主張や、矛盾・抜けがあれば挙げてください」と頼みます。検証の質問を投げて答えさせて改善する、という考え方は、出力の点検を体系化した手法（Chain-of-Verification）としても整理されています（出典：Learn Prompting）。

固有名詞・数字・日付は誤りやすいから点検が要る

なぜここまで点検にこだわるのか。生成AIは、事実に基づかない誤った情報をもっともらしく生成することがあります。これをハルシネーションと呼びます。総務省の情報通信白書は、技術的な対策は検討されているものの完全には抑制できないため、生成AIを使うときはハルシネーションが起こりうることを念頭に置き、検索を併用するなどして、ユーザー自身が出力の正しさを確認することが望ましい、としています（出典：総務省「令和6年版 情報通信白書」）。特に固有名詞・数字・日付は、流暢な文章に紛れて誤りが見えにくいので、自己検証で表に出させ、最後は人が事実を確認するのが原則です。

あわせて押さえたいのが機密情報の扱いです。同白書は、個人情報や機密情報がプロンプトとして入力され、AIからの出力等を通じて流出してしまうリスクを指摘しています（出典：総務省「令和6年版 情報通信白書」）。共通例のような競合資料を扱うときも、パブリックな生成AIに機密情報をそのまま入力せず、社内ルールを確認するのが前提です。事実誤りや機密の扱いを基礎から固めたい場合は、AIリテラシー・セキュリティが正本なので、そちらで土台を確認してください。

悪い例を見せて逆効果／流暢な誤りをそのまま採用するつまずき

つまずきは2つ。1つは、曖昧な例や悪い例を見せてしまうこと。例はそのままAIが真似る対象なので、見本の質がそのまま出力の質になります。もう1つは、自己検証をさせず、流暢な誤りをそのまま採用すること。読みやすい文章ほど正しく見えますが、点検を一段はさむだけで、根拠のない主張をふるい落とせます。

この章の確認（演習）

第2章で段に分けた自分のプロンプトに、2つを足してください。1つは「望む出力の良い例を1つ見せる」こと。もう1つは、出力に対して「各主張の根拠を示し、矛盾・抜けを挙げる」よう求める自己検証の指示です。改訂したプロンプトで試し、根拠提示によって弱い主張が1つでもあぶり出されるかを確かめましょう。

反復改善で仕上げ、目的別に技法を組み合わせて設計する

一発完成を狙わず「どの技法が欠けたか」を見て足す

ここまでの3技法を、最後に1つの設計へまとめます。鍵になるのが反復改善です。プロンプト設計はそもそも反復的な営みで、最初のドラフトを成功基準に対してテストしながら良くしていくものでした（出典：Anthropic「Prompt engineering overview」）。この考え方は、技法の世界ではSelf-Refineとして整理されています。Self-Refineは、人が下書きを作って見直し、改善するのと同じように、AIが初期出力を生成し、段階的に反復改善して正確性と品質を高めていく手法です（出典：Learn Prompting「Self-Criticism Prompting」）。

実務での反復は、闇雲なやり直しではありません。出力を見て「どの技法が欠けていたか」を特定し、その技法を1つ足すのがコツです。論理が飛んでいたら段を増やす（段階分解）。形が揃っていなければ良い例を見せる（例示）。根拠が薄ければ点検を求める（自己検証）。どこが欠けたかを技法に紐づけて判断できると、次に何を足すかで迷わなくなります。

目的⇔技法の対応で「次に足すもの」を決める

応用プロンプト設計の本体は、目的ごとに効く技法を当てることです。目的と技法を次のように対応づけておきましょう。考えさせたいなら段階分解。形を整えたいなら例示と出力形式の指定。事実を確かめたいなら自己検証。この対応表を持っていると、込み入った依頼でも「いま欠けている目的は何か→だからこの技法を足す」と判断でき、再現性が生まれます。再現性が生まれるということは、後輩に「この目的ならこの技法」と渡せる、つまり人に教えられるということです。

技法は組み合わせて使えます。Anthropicは、例示の中に思考の過程を示して、推論パターンごと真似させるといった、複数技法を併用する設計を示しています（出典：Anthropic「Prompting best practices」）。注意したいのは、目的に紐づかない技法を闇雲に盛らないこと。「効きそうだから全部入れる」と指示が破綻します。足すのは、欠けている目的を埋める技法だけです。

共通例の最終形を1セットに組み立てる

共通例の最終形を組み立てます。目的を「整理・比較・提案」の3つに分け（段階分解）、比較の段で良い比較表の見本を1つ見せ（例示）、出てきた提案に根拠提示と点検を求め（自己検証）、足りない観点があれば追加で指示する（反復改善）——この4つを1セットにします。出てきた提案は根拠付きなので、あとは人が事実だけ確認すれば、そのまま会議のたたき台に出せます。以前なら「読んで提案して」と一度に投げて手直しに追われていた仕事が、目的を分けて技法を当てるだけで、再現可能な形になります。そして、この応用プロンプトを毎回使う「業務専用AI」として固定・配布したくなったら、カスタムGPT作成が次の正本です。本講座は単発の高度プロンプト設計まで、その先の資産化はそちらが担います。

一発完成にこだわる／目的に紐づかない技法を盛るつまずき

つまずきは2つ。1つは、一発完成にこだわって改善をやめること。最初の出力は下書きと割り切り、1回は反復する前提で臨みましょう。もう1つは、技法を盛りすぎること。目的に紐づかない技法を足すと、指示が長く曖昧になり、かえって崩れます。「いま欠けている目的は何か」を起点に、足す技法を1つに絞るのが、応用を破綻させないコツです。

この章の確認（演習）

自分の難依頼について、目的を2〜3に分け、各目的に効く技法を当てた「応用プロンプト1セット」を完成させてください。段階分解・例示・自己検証のうち、その依頼に必要なものを選んで組み立てます。実際に試し、出力を見て欠けていた技法を1つだけ足す——この反復を1回行って仕上げましょう。