2025年のプロンプトエンジニアリング ｜ 不要論、無意味な手法、今も有効な手法など

こんにちは、株式会社Renewerの堀内です。

アメリカで人気のポッドキャストに『Lenny’s Podcast』があります。
Airbnbの元プロダクトリードであるLenny氏がホストを担当し、OpenAIやAnthropicのCPOなど第一線で活躍するゲストを迎えることで知られる、シリコンバレーの起業家やプロダクト開発者が必聴のポッドキャストです。

2025/6/19の回は「AI prompt engineering in 2025: What works and what doesn’t」というタイトルで、プロンプトエンジニアリングがテーマでした。
内容はタイトルのとおり、「2025年においてプロンプトエンジニアリングで効果的な方法と、そうでない方法は何か」というものです。

ここ最近、「プロンプトエンジニアリング」の立ち位置は揺れています。

LLMの性能が向上した今、「もはや不要だ」と”プロンプトエンジニアリング不要論”を耳にすることがあります。その一方で、「いや、むしろ重要度は増している」という反論もまた、根強く存在します。

この分野が今後も重要性を増すのか、それとも価値を失って廃れていくのか。

私たちのプロダクトはプロンプトエンジニアリングと密接に関わっており、このテーマについては高い関心を持っています。
なので今回のポッドキャストもたいへんに興味深く聞きました。

そこで本記事では、ポッドキャストの内容を紹介しながら、2025年現在のプロンプトエンジニアリングについて考えてみたいと思います。

サンプルプロンプトなど、本記事の詳細版はスライド集にまとめています。
以下から無料でダウンロードできます。ぜひ見てみてください。
（ダウンロードの際、いくつかの情報入力が必要です。）

1.ゲストの紹介（Sander Schulhoff）

はじめに、本エピソードのゲストであるSander Schulhoff（サンダー・シュルホフ）を紹介しておきます。

彼は ChatGPT 登場前の2022年10月に世界で初めての本格的プロンプトエンジニアリング教材「Learn Prompting」を公開した、プロンプトエンジニアリングの先駆者の一人です。

また最近では、OpenAI・Microsoft・Google・スタンフォード大などと共同で 1500以上の論文を分析して200ものプロンプト技術をまとめた「Prompt Report」の作成チームを率いています。

2.プロンプトエンジニアリングは不要なのか

「プロンプトエンジニアリングはもう不要だ」「次のLLMが出れば、こんな技術は不要になる」といった声を聞くことがあります。

例えば、私も投資家や見込み顧客の方に

という質問・意見を頂いたことがあります。

「プロンプトエンジニアリング不要論」の背景には、AIモデルの進化があります。

かつて、ChatGPTの登場当初は状況が違いました。ユーザーの指示が曖昧だと、欲しい答えが返ってこない。その対処法として、プロンプトエンジニアリングは注目され、普及しました。

しかし、GPT-oシリーズやGemini 2.5シリーズといった現在の推論モデルは、多少曖昧な指示や質問であっても、驚くほど正確に意図を読み取り、精度の高い回答を生成できるようになっています。

実際、最近のモデルを使っていて、「たったこれだけの指示で、ここまで意図を理解してくれるのか！」と驚くことはありますよね。

一方で、サンダー・シュルホフ氏はプロンプトエンジニアリングの重要性はむしろ増していると話しています。

シュホルフ氏が調査した1500件の研究の中には、プロンプトの質が悪い場合には正答率が0％だった問題でも、優れたプロンプトを使うことで正答率を90％にまで向上させられたというケースもあったそうです。

ポッドキャストでは引用として、LinkedInの創業者であるリード・ホフマン氏のポストを上げています。

「人間の脳はほんの数％しか使えていない」という言い伝えと同様に、プロンプトの質やスキルのせいで、AIのポテンシャルのほんの一部しか活かせていないのでは？という指摘です。

3.プロンプトの2つの潮流「会話型」と「プロダクト実装型」

サンダー・シュルホフ氏は、現在のプロンプトは2つの潮流に分類できると述べています。

1.会話型（Conversational）

1つ目は「会話型（Conversational）」です。これはほとんどの人が行う日常的な生成AIの使用方法である、ChatGPTやGeminiのようなチャットボットと対話する時のプロンプトです。

例えば、メールの作成を依頼し、その出来が思わしくない場合、会話の中で「もっとフォーマルに」「ジョークを入れて」といった次のプロンプトを調整することで、出力の改善を図るのが会話型です。
期待通りの答えが得られなくても、対話を重ねて修正することで、満足のいく結果を得ることができるという特徴があります。

2.プロダクト実装型（Product-Focused）

2つ目は「プロダクト実装型（Product-Focused）」です。これはアプリケーションや社内システムなどに組み込まれて、裏側で自動実行されるプロンプトです。

そのようなプロンプトは、1日に何千回、何万回も実行されることを想定して設計・作成する必要があり、その出力の精度については高い再現性が求められます。

シュルホフ氏が語っているのは、特に「プロダクト実装型」におけるプロンプトエンジニアリングの重要性です。

このプロンプトは継続的な会話ではなく、単一のプロンプトを繰り返し改善することが必要です。そのためコードのように正確で、最適化されている必要があります。

今後はAIエージェントの普及によって、これまで人間が手作業で行っていた業務や、プログラマーが書いていたコードの一部が、「プロダクト実装型」のプロンプトに置き換わっていくことでしょう。

この役割の拡大こそが、シュルホフ氏が「プロンプトエンジニアリングはますます重要になる」と主張する理由です。

4.生成AIの使い方の違いが論争を生んでいる

この「会話型」と「プロダクト実装型」の話を聞くと、「プロンプトエンジニアリングは重要か、不要か」という論争の構造がクリアになります。
両者が違う意見を持つのは、生成AIの使い方が違うからではないでしょうか。

日常的に生成AIと「会話」している人なら、モデルの進化によって簡単な指示でも十分良い答えが返ってくる、という実感があるはずです。これを以て「プロンプトエンジニアリングが必要なくなっている」という意見を持つことは、自然なことでしょう。

一方で、「プロダクト実装型」のプロンプトを作成したことがある方は、その精度を高めるのに多くの時間をかけ、試行錯誤を重ねた経験が必ずあるでしょう。
そのような方は、「プロンプトエンジニアリングが不要だなんてとんでもない」「むしろ信頼性の高いプロンプトを作成する機会は以前より増えているじゃないか」と感じていると思います。

なので、"プロンプトエンジニアリング不要論"の議論は、この「会話型」と「プロダクト実装型」のどちらの視点で言っているか、というのがあるよね、というのが私の考えです。

私自身にかえりみると、どちらかといえば「プロダクト実装型」の視点で、「プロンプトは今後もますます重要でしょ」という意見でした。

この記事を読んでいる皆さんは、どちらの視点に立って、どうお考えですか？

5.今は無意味なプロンプトエンジニアリング手法

「プロンプトエンジニアリングはますます重要になる」という意見のシュルホフ氏ですが、LLMの進化に伴って意味が無くなった手法もある、と紹介しています。

その代表例が「ロール（役割）プロンプティング」です。

1.「あなたはプロの〇〇です」 ロールプロンプティングは意味がない

これはプロンプトの冒頭に「あなたはプロの◯◯です。」と入力しておくと、AIがその領域のプロフェッショナルとして振る舞うことで、アウトプットの品質が上がるというものです。
プロンプトエンジニアリングの最も有名なテクニックのひとつと言えます。

この手法は役割を与えることでAIの特定の領域が活性化され、より文脈に沿った思考ができるようになるという考え（期待）に基づいています。

しかし、シュルホフ氏曰く、ロールプロンプティングは精度の向上には全く役立たないと断言しています。

実際、ある研究によれば、役割を与えたプロンプトと与えなかったものでは、AIの回答精度に統計的に意味のある差（有意差）が確認できなかったそうです（その差は0.01%程度）。

これは現代のモデルの進化によって、特定の役割を与えなくても文脈を理解し、適切に推論する能力が高まっているためです。

一方で、ロールプロンプティングは、文章のスタイルやトーンを調整するようなタスクには引き続き有効であるとされています。

このように特定の人物の表現スタイルで文章を書かせたり、考えさせたりしたい時は引き続き有効なアプローチです。

もし回答の精度アップのために、プロンプトの冒頭に「あなたは◯◯です」と書いているなら、その一文を外して試してみてましょう。それでも十分に満足のいく答えが返ってくるか確かめてみてください。

2.報酬や脅威を与えるのは意味がない

ロールプロンプティングほど有名ではないですが、「良い回答には100ドルのチップを与えます」「良い回答をしないと罰せられます」のように、報酬や脅威を与えると、回答の質が向上する、というテクニックがあります。

こちらもロールプロンプティングと同様に、古いモデルでは機能したかもしれませんが、より新しいモデルでは機能しないと考えられています。「これらの手法が効果があるという大規模な研究は見たことがない」と述べています。

このようにモデルの進化によって、これまで効果があると言われていたプロンプトエンジニアリング手法が再検証され、不要になっています。
特に上記のような「この一文を加えるだけで質が向上する」といった類のおまじないや小手先のテクニックは、AIが賢くなればなるほど、その効力を失っていくのではないでしょうか。

6.今なお有効なプロンプトエンジニアリング手法

ポッドキャストでは2025年現在、LLMが進化した今でもなお有効なプロンプトエンジニアリングの手法を6つ紹介しています。それぞれ解説していきます。

1. Few-Shot Prompting ― “少数例の提示”

Few-Shot プロンプティングは、求めているアウトプットの具体的な「例」をいくつか提示する方法です。
これに対して、例をまったく示さない方法は「Zero-Shot（ゼロショット）」と呼ばれます。

例えば、特定の顧客に送るメールを自分のいつもの書き方でAIに書いてほしいとします。その場合、過去に自分が書いたメールを2〜3通プロンプトに貼り付け、「これを参考にして、以下の要件でメールを作成してください」と指示します。

こうすることで、AIはあなたの文体やトーン、フォーマットを学習し、よりパーソナライズされたアウトプットを生成してくれます。

これは従来からのプロンプトエンジニアリングの代表的な方法ですが、現在でも最もおすすめできる方法だとシュホルフ氏は言っています。
実際に医療分野のユースケースにおいて、完全な失敗状態から精度を70%も向上させた例が挙げられています。

このテクニックは、「プロダクト実装型」はもちろんのこと、「会話型」のプロンプト作成においても、アウトプットの質を向上させる可能性を持っています。

2. Decomposition ― “問題の分解”

AIに複雑な作業をお願いするときには、すぐに最終的なアウトプットを求めるのではなく、まずタスクをより小さな「サブタスク」に分解させ、それらを一つずつ解決させるという方法です。

具体的な例として、自動車販売店のAIチャットの例が挙げられます。
顧客がAIチャットに「この車をこの日に購入したのですが、小さなへこみがあり、返品したいです。返品ポリシーはどうなっていますか？」といった曖昧な問い合わせをしたとします。

モデルがこの問いに一度に回答しようとすると、適切に処理できない可能性があります。そこで、タスク分解を使用します。

まずモデルに「この問題を解決するために実行すべきサブタスクをリストアップしてください」を尋ねます。
モデルは以下のようなサブタスクをリストアップするでしょう。

これらのサブタスクを、一つずつ順番に解決するようAIに指示します。例えば、まずデータベースを確認して顧客の情報を調べたり、購入した車の種類や納車された日付を確かめたりします。

そして、すべての必要な情報が揃ったら、最終的にこのお客様が車を返品できるかどうか、また返品に伴って費用が発生するかどうかを判断することができます。

この例のように、複雑な状況では人間と同じような「考え方の手順」を真似させると効果的です。一つずつ順序立てて考えさせることで、より正確で信頼できる結果を出すことができるようになります。

3. Self-Criticism ― “自己批判”

これは、一度AIが出したアウトプットに対して、AI自身にその内容を「自己評価」させ、「改善できるところ」を考えさせる手法です。そして、その評価と改善点を参考にして、もう一度AIにアウトプットを作り直させます。

このやり方は「パワハラプロンプト」と呼ばれる方法に似ています。
具体的な手順は次の通りです。

1. まず、通常通りAIにタスクを依頼し、アウトプットさせます。

2. 次に、「今のアウトプットをレビューして、改善できる点を挙げてください」と指示します 。

3. AIが自己批判に基づいた改善点をリストアップしたら、最後に「では、その批判点を踏まえて、最初のアウトプットを修正してください」と指示します。

人間がAIにアドバイスやフィードバックを与えるのと同じように、AI自身にも「どこがよくないか」「どう直せばよいか」を考えさせることで、より完成度の高い答えに近づけることができます。

ただし、この方法で改善を繰り返すのは、2回までにとどめるのがよいです。3回以上繰り返しても、改善幅が飽和して効果がなくなってしまうと言われています。

4. Additional Information ― “追加情報の提供”

これは、タスクに関連すると思われる情報を可能な限り多くプロンプトに含めるという、シンプルながら非常に強力なテクニックです。

同様の手法で、「Context（コンテキスト）をできるだけ多く含める」ことをおすすめするテクニックもあります。
やりたいことは同じですが、コンテキストという言葉は少し抽象的で、人によってはどんな情報を入力すべきか迷うする人もいるでしょう。

そのためシュホルフ氏は、このテクニックを「追加情報（additional information）」と呼ぶことを好んでいます。
とにかくタスクに関連すると思われる情報を、可能な限りプロンプトに含めましょう、ということです。

例えば、AIにメールを書いてもらう場合には、自分自身の仕事内容やこれまでの職歴、メールを送る相手との関係性などを伝えます。
また、AIにデータを分析してもらいたいときには、そのデータがどの会社のもので、その会社がどんな事業をしているのかなど、企業についての詳しい情報を一緒に伝えるようにします。

「会話型」においては、このテクニックは最も簡単でかつ効果の高いものの一つです。アウトプットの質がイマイチだと感じたら、まずは「何か追加できる情報はないか？」と考えてみると良いでしょう。

5. Ensembling ― “アンサンブル”

これは、解決したい一つの問題に対して、複数の異なるプロンプトまたはモデルを使用して同じ問題を解決させ、その結果を統合することです。

例えば、「完全自動運転技術」が社会に広まった場合を考えるとき、「悲観的なアナリスト」とし「楽観的なテクノロジーエバンジェリストの立場で考えさせます。
そして、それぞれの視点で得た結果を最後にまとめることで、メリットとデメリットがバランスよく整理された内容を得ることができます。

これは主に「プロダクト実装型」で使われるテクニックですが、個人で利用する場合でも、例えばGPT-4oとClaude 3 Opusの両方に同じ質問をしてみて、その回答を比較検討する、といった形で応用できるでしょう。

6. Thought Generation ― “思考プロセス生成”

これは、AIにアウトプットだけを提示させるのではなく、そのアウトプットに至るまでの「思考プロセス」や「推論過程」を書き出させるというものです。

最新の推論モデルは、特に指示をしなくても内部で推論を行うようになっています。そのため、以前のように「ステップ・バイ・ステップで考えてください」と明確に指示する必要性は以前より低くなっています。

しかし、モデルはまれに推論プロセスを省略して、いきなり結論だけを出してしまう場合があります。そのようなランダムなAIの動きを防ぐために、このように推論のステップをはっきりと指示する方法が今でも役立つことがあります。

また、「プロダクト実装型」の場合は、AIの思考プロセスを可視化することで、どの段階でAIが間違えたのかを簡単に把握できるようになります。その結果、問題の修正やAIの精度を改善する作業を効率よく進めることが可能になります。

ここまでお読み頂きありがとうございました！

この記事の詳細スライド版はこちらからダウンロードできます↓

「プロダクト実装型」のプロンプトでシステムの精度向上に挑む方。
「会話型」のプロンプトで日々の生産性を高めている方。
本記事がその両者の皆様にとって、有益な知見となれば幸いです。引き続き生成AIをガンガン活用していきましょう！

あわせてこちらもご覧ください。