AIの回答がずれるのは、指示が足りないからだけではなかった──『生成AIのプロンプトエンジニアリング』を研究して分かったこと
生成AIに仕事を頼んで、返ってきた回答を見た瞬間、
「そうじゃないんだよな」
と思ったことはないでしょうか。
内容は間違っていない。
日本語も不自然ではない。
頼んだことにも、一応は答えている。
それなのに、自分が欲しかったものとは少し違う。
そんなこと、ありませんか?
そんなとき、私たちはつい考えます。
もっと詳しく指示を書けばよかった。
そこで、条件を追加します。
役割を指定し、目的を書き、読者を定義し、文字数や文体を指定する。
それでもずれると、さらに注意事項を増やしていく。
気がつけば、仕事を頼むより、プロンプトを書く方が大変になっている。
でも、今回『生成AIのプロンプトエンジニアリング』と関連資料を調べてみると、少し違う見方が見えてきました。
AIの回答がずれるのは、指示が短いからだけではありません。
むしろ問題は、人間とAIの間で「何を良い回答とするか」が揃っていないことにあるのかもしれません。
長く書いたのに、なぜ伝わらないのか
たとえば、AIにこう頼んだとします。
初心者向けに、分かりやすい記事を書いてください。
短いですが、意味は通じます。
ただし、「初心者向け」や「分かりやすい」の基準は、人によって違います。
専門用語を使わないことなのか。
具体例を増やすことなのか。
結論を先に書くことなのか。
一文を短くすることなのか。
利用者の頭の中には、なんとなく完成形があります。
しかし、その完成形をAIが同じように想像しているとは限りません。
では、指示を増やせば解決するのでしょうか。
必ずしも、そうとは限りません。
長い指示の中に、
絶対に守ってほしい条件
できれば守ってほしい条件
背景として伝えたい情報
出力には直接関係しない説明
が混ざっていると、何が重要なのか分かりにくくなります。
情報が足りないことだけでなく、重要な情報が他の説明に埋もれることも、回答がずれる原因になります。
本書が示す、プロンプトの5つの原則
『生成AIのプロンプトエンジニアリング』では、プロンプトの基本が次の5つに整理されています。
方向性を示す
出力形式を指定する
例を示す
品質を評価する
タスクを分割する
ここで興味深いのは、「できるだけ詳しく書く」という原則がないことです。
必要なのは文章量ではなく、AIが判断するための手がかりです。
何のために作るのか。
どのような形で出してほしいのか。
どんなものを良いと考えているのか。
返ってきたものは基準を満たしているのか。
仕事が大きすぎないか。
これらを順番に合わせていきます。
公式の書籍紹介でも、本書はLLMや画像生成モデルに共通する原則に加え、出力の安定化や評価を扱う実践書として説明されています。
「説明」より、見本の方が伝わることもある
たとえば、文章の雰囲気をAIに伝える場面を考えてみます。
優しく、落ち着いていて、読者に寄り添いながら、断定しすぎない文章にしてください。
これでも方向性は伝わります。
しかし、人間同士でも「優しい文章」のイメージは一致しません。
そんなときは、理想に近い文章を一つ見せた方が、早く伝わる場合があります。
Googleの公式ガイドでも、具体例を含むfew-shot promptingは、形式、言い回し、範囲、回答パターンを整える方法として紹介されています。見本が明確なら、一部の説明を省略できる場合もあるとされています。
つまり、回答がずれたときに必要なのは、注意事項を10個追加することではないかもしれません。
「こういう形に近づけてください」
と、一つの見本を示すだけでよい場合があります。
プロンプトは、最初から完成させるものではなかった
ここが、今回の研究で最も大きな発見でした。
プロンプトは、最初に完璧な文章を書いて、その後は同じ結果が返ってくるのを待つものではありません。
実際の出力を見ながら改善していくものです。
Googleの公式ガイドでも、プロンプトエンジニアリングは反復的な作業であり、ガイドやテンプレートは出発点にすぎないと説明されています。特定の用途と、実際に返ってきた回答をもとに試し、修正することが推奨されています。
これは、人に仕事を頼む場面を考えると分かりやすいかもしれません。
新しく一緒に働く人へ仕事を頼んだとき、最初からすべての判断基準が共有されているわけではありません。
一度作ってもらう。違う部分を伝える。もう一度作ってもらう。
そのやり取りによって、少しずつ完成イメージが揃っていきます。
AIとのやり取りも、それに近いところがあります。
「違う」だけでは、次もずれる
ただし、回答を見て、
なんか違います。もっと良くしてください。
と返すだけでは、改善しないことがあります。
AIには、「何が違ったのか」が分からないからです。
そこで必要になるのが、本書の4番目の原則である「品質を評価する」です。
難しく考える必要はありません。
たとえば、次のように差を一つだけ伝えます。
専門用語が多く、初心者には難しい
結論が出てくるまで長い
具体例が少なく、自分の状況を想像しにくい
丁寧だが、少し他人行儀に感じる
内容はよいが、箇条書きが多すぎる
これなら、AIは次に何を変えるべきか判断できます。
重要なのは、プロンプト全体を書き直すことではありません。
今の回答と、欲しかった回答の差を一つ伝えることです。
一度に頼みすぎている可能性もある
回答がずれるもう一つの原因は、仕事が大きすぎることです。
たとえば、
この本を分析し、外部の研究と比較し、読者向けの記事を書き、タイトルとSNS投稿も作ってください。
という依頼には、複数の仕事が含まれています。
本の主張を整理する
外部情報を探す
情報の信頼性を評価する
記事の構成を決める
本文を書く
タイトルを作る
SNS向けに短くする
一度に実行させれば、どこかが浅くなったり、途中の判断を確認できなかったりします。
本書は、複雑な仕事を分割することを5つ目の原則に挙げています。
たとえば、
まず本の主張だけを整理する
次に外部情報と比較する
調査結果をもとに構成を作る
構成を確認してから本文を書く
と分ければ、途中で方向を修正できます。
これはAIの負担を減らすだけではありません。
人間が「どこからずれたのか」を見つけやすくする方法でもあります。
それでも、プロンプトだけでは解決できない
ここまで読むと、プロンプトを改善すれば、いつでも正しい回答が得られるように思えるかもしれません。
しかし、そこには限界があります。
AIが必要な情報を持っていなければ、指示を詳しくしても正解には近づきません。
最新情報が必要なら、検索や資料の提供が必要です。
社内独自のルールについて尋ねるなら、そのルールをAIに渡す必要があります。
医療、法律、税務などでは、文章が分かりやすいことと、判断が正しいことは別です。
また、生成AIの出力には一定の揺れがあります。
同じ指示でも、完全に同じ回答になるとは限りません。
実際のシステム開発では、プロンプトだけで品質を管理するのではなく、評価用データやテストを用意することも推奨されています。OpenAIも、安定した運用にはモデルバージョンの固定や評価の実装が重要だと説明しています。
つまり、プロンプトは重要です。
しかし、プロンプトだけですべてを解決しようとすると、別の問題を見落としてしまいます。
HAROの暫定評価
今回の調査からは、
AIの回答がずれる原因は、指示が足りないことだけではない
という見方は、おおむね支持できます。
回答のズレには、少なくとも次の要因が関係します。
目的が共有されていない
完成形が共有されていない
良し悪しの基準が曖昧
必要な背景情報がない
仕事が大きすぎる
重要な条件が他の説明に埋もれている
AIが必要な知識を持っていない
モデルの能力や出力の揺れに限界がある
だからこそ、回答がずれたときに、自分の説明能力を責める必要はありません。
実際の回答を見るまで、自分でも求めていたものを言葉にできないことがあります。
一度作ってみたからこそ、
「内容ではなく、順番が違った」
「詳しさではなく、具体例が欲しかった」
と気づけることもあります。
その気づきは失敗ではありません。
次の指示に使える、新しい情報です。
今日、これだけやってみる
次にAIの回答を見て「違う」と感じたら、プロンプトを最初から書き直さないでください。
まず、次の一文だけを続けてみてください。
今の回答で直してほしい点は、〇〇です。そこだけ修正してください。
〇〇には、観察できる違いを一つ入れます。
「結論を先にしてください」
「専門用語を減らしてください」
「具体例を一つ追加してください」
「箇条書きではなく文章で説明してください」
それだけで構いません。
最初から完璧に伝えようとするのではなく、返ってきた回答を見ながら、一つずつ完成形を合わせていく。
プロンプトエンジニアリングとは、難しい命令文を書く技術ではありません。
人間とAIの間にある「少し違う」を見つけ、埋めていく技術なのかもしれません。
次に進みたい方へ
この記事の考え方を、実際の仕事で一度試してみたい方へ。
AIに任せる作業を一つ選び、短く依頼し、一つだけ調整して、次も使える形で残すところまで進められます。
参考資料
James Phoenix、Mike Taylor『生成AIのプロンプトエンジニアリング』
Schulhoff et al. "The Prompt Report: A Systematic Survey of Prompting Techniques"
Sahoo et al. "A Systematic Survey of Prompt Engineering in Large Language Models"
Otten et al. "Prompting in Practice: Investigating Software Developers' Use of Generative AI Tools"
Google AI for Developers "Prompt design strategies"
OpenAI API Documentation "Evals"
