自社プロダクトに生成AIを組み込んだものの、「同じ入力でも出力が毎回ぶれる」「たまに指示を無視して余計な説明を付ける」「出力形式が安定せず後続の処理でエラーになる」——こうした不安定さの多くは、モデルの問題ではなくプロンプト設計で改善できます。

プロンプト設計というと職人芸のように思われがちですが、実際は押さえるべき基本があります。この記事では、出力を安定させるプロンプト設計の基本と、改善を回す進め方を手順で解説します。プロンプトを渡した文書の範囲で答えさせるRAGの文脈はRAG構築でつまずくポイントと対処、コスト面の設計はLLMの利用コストを最適化する実装の勘所もあわせてご覧ください。

なお筆者・馬込は、生成AIによる自動生成機能やマッチング機能の実装で、プロンプト設計と精度改善に携わってきました。本記事はその実務目線でまとめています。

結論：出力の安定は「役割・制約・出力形式」の明示で作る

出力がぶれるのは、モデルに解釈の余地を与えすぎているからです。安定させる基本は、**何者として（役割）・何を守り（制約）・どんな形で返すか（出力形式）**を曖昧にせず指定すること。この3点を押さえるだけで、出力の再現性は大きく上がります。

手順1：役割・制約・出力形式を明示する

まず、プロンプトに次の3要素を入れます。これは高度なテクニックではなく、安定出力の土台です。

要素 何を指定するか 例
役割 どんな立場で答えるか 「あなたは業務マニュアルに基づく回答者です」
制約 守るべきルール 「渡した文書の範囲で答え、なければ『分からない』」
出力形式 返す形 「JSONで、キーは summary と items」

特に出力形式の指定は、後続のプログラム処理と直結します。形式が毎回ぶれると処理側でエラーになるため、期待する構造を具体的に示します。

手順2：少数の例（Few-shot）で期待を伝える

言葉で説明しづらい期待は、入力と出力の例を数個見せると安定します。これをFew-shot（少数例提示）と呼びます。

  • 「良い出力」の例を1〜3個、入力とセットで示す
  • 例は実際に起きうる典型パターンを選ぶ（極端な例だけを見せない）
  • 例が多すぎるとコストと混乱が増えるため、少数に絞る

抽象的な指示を10行足すより、的確な例を1〜2個見せるほうが、期待する出力に近づくことがよくあります。

手順3：一度に一つずつ変えて改善する

プロンプト改善で失敗しやすいのが、複数の変更を同時に入れて「何が効いたか分からなくなる」ことです。改善は科学実験と同じで、変数を一つずつ動かします。

  • 代表的な入力を固定したテストセットを用意する
  • 変更は一箇所ずつ入れ、テストセットで前後を比較する
  • 良くなった変更だけを残し、悪化したら戻す

このループを回すと、プロンプトが「なんとなく良さそう」ではなく「テストで良くなった」根拠を持って育ちます。改善が再現可能になるのがポイントです。

手順4：それでもぶれる部分は、プロンプト以外で吸収する

役割・制約・出力形式を整え、例を見せ、一つずつ改善した——それでも、生成AIの出力は完全には固定できません。ここを理解しておかないと、プロンプトを無限に磨き続けることになります。プロンプト設計には限界があり、最後の数%は仕組み側で吸収するのが現実的です。

代表的な吸収のしかたは次の3つです。

課題 プロンプト以外の対処
出力形式がまれに崩れる 受け取る側で検証し、崩れていたら再実行する
想定外の値が入る 選択肢を固定し、範囲外なら弾く
長文で指示を見落とす 処理を分割し、1回のリクエストで1つのことだけやらせる

特に3つ目は効きます。1つのプロンプトに「要約して、分類して、整形して」と詰め込むほど、どれかが疎かになります。工程を分けて、それぞれ単純な指示にしたほうが、結果的に安定し、デバッグもしやすくなります。

判断の基準はこうです。プロンプトを2〜3回直しても安定しないなら、それはプロンプトで解く問題ではない。仕組み側で受け止めるか、タスクを分割するかを検討します。ここを見極められると、改善が消耗戦になりません。

よくある落とし穴

  • 役割・制約を書かず期待だけ伝える：解釈の余地が残り出力がぶれます。3要素を明示します。
  • 出力形式を指定しない：後続処理でエラーになります。JSONなど具体的な構造を示します。
  • 例を見せず言葉だけで説明する：伝わりにくい期待は少数例で示します。
  • 複数箇所を同時に変える：何が効いたか不明になります。一つずつ変えて比較します。
  • 1つのプロンプトに複数のタスクを詰め込む：「要約して、分類して、整形して」と重ねるほど、どれかが疎かになります。工程を分けて、1回に1つだけやらせます。
  • プロンプトだけで100%の安定を目指す：最後の数%は構造上ぶれます。検証・再実行など仕組み側で吸収するほうが確実です。

よくある質問

Q. プロンプトを長く詳しく書けば書くほど良くなりますか？ A. 必ずしもそうではありません。指示が長いと、モデルが重要な制約を見落としたり、コストが増えたりします。役割・制約・出力形式を的確に、冗長にならない範囲で書くのが基本です。長さより明確さが効きます。

Q. モデルを上位のものに変えれば安定しますか？ A. 上位モデルで改善することもありますが、プロンプト設計が曖昧なままだと、モデルを変えてもぶれは残ります。まず役割・制約・出力形式を整え、それでも足りなければモデル変更を検討するのが、コスト面でも合理的です。

Q. 出力形式を安定させる確実な方法はありますか？ A. JSONなど構造を明示し、少数例で示すのが基本です。多くのモデルには構造化出力を強制する機能もあり、後続処理が形式に依存する場合はそうした機能の利用が有効です。まずは形式の明示と例示から始めます。

プロンプト設計は、①役割・制約・出力形式を明示する ②少数例で期待を伝える ③一つずつ変えて改善する、という基本を押さえれば、職人芸に頼らず出力を安定させられます。ぶれる出力の多くは、モデルではなく設計で直せます。

自社プロダクトへの生成AIの組み込みや精度改善の相談は、開発支援について相談するからお問い合わせください。