ユーザー体験を左右するプロンプト設計｜現場で使える工夫と落とし穴

なぜプロンプト設計がUXを左右するのか

LLM開発では、アルゴリズムの優劣よりもプロンプト設計がUXを決める要因になります。
PoCの場では偶然うまくいくこともありますが、本番に移行した途端に「使えない」と烙印を押されるケースは少なくありません。

• 同じモデルでもプロンプト次第で精度が大きく変わる
• 出力の安定性が担保されないと「AIは当てにならない」という評価につながる
• UXが悪化すると、どんなに高機能でも利用が続かない

以下では、筆者が実際に経験した2つのエピソードを紹介し、そこから得られた教訓を整理します。

エピソード1：PoCデモの“再現できない問題”

PoCの場で最も印象的だったのは、初回のデモが想像以上にうまくいったことでした。AIが仕様の要点を的確に拾い上げ、役員からも驚きの声が上がったほどです。ところが翌日、別のメンバーが同じ質問を試したところ、結果は大きく異なり精度も低下しました。ここから一気に「やはりAIは信用できない」という評価に転じてしまったのです。

なぜこうなったのか。
振り返れば、プロンプトが場当たり的で、前提条件を明示していなかったことが原因でした。
「どのシステムを対象にしているのか」「どの粒度で答えるのか」「どんな観点で良し悪しを評価するのか」を一切固定せずに使っていたため、その場限りの“偶然の成功”に依存してしまったのです。さらに致命的だったのは、検証用のログを保存していなかったこと。差分を分析する術がなく、なぜ結果が変わったのかを誰も説明できませんでした。

実際に体験して分かったのは、こんなことでした。

ログを必ず保存すること
→ デモやPoCで一度成功したら終わりではなく、同じ条件で再実行して比較できるようにする。これがなければ「偶然の成功」と「安定した成功」の区別がつかない。
プロンプトを仕様書のように固定化すること
→ 「誰が・どんな役割で・どの形式で・どんな条件で出すか」を明示し、再利用可能な形にする。あいまいな日本語だけの指示は必ずブレを生む。
PoC段階から再現性を評価指標に含めること
→ 「面白い答えが返ってくる」ではなく「同じ答えを安定して返せるか」を評価の基準に据える。これができないPoCは本番で必ず失敗する。
ユーザー体験は“安定性”で決まることを意識する
→ UXの本質は「安心して使えること」。一回のインパクトより、毎回同じ品質で使える安心感を優先する。

こうして並べてみると、どれも派手さはありませんが、現場で実際にUXを守るうえで欠かせない基本動作です。現場でAIを使った人ほど身近に感じられるポイントかもしれません。

エピソード2：レビュー効率を50%改善したプロンプト指定

別の案件では、AIを要件定義書のレビューに活用しようとしました。
ところが「要件定義をレビューしてください」と依頼しただけで返ってきたのは、数千字に及ぶ長大な文章でした。内容自体は間違っていないものの、情報が散漫でレビューに活かせず、むしろ人手で整理する工数が増える結果になりました。

この問題の原因は単純で、出力形式を指定していなかったことに尽きます。人間がレビューに求めるのは「指摘点を一目で把握できること」ですが、AIにはその意図が伝わっていませんでした。UXが悪化するのは当然で、「AIを使った方が余計に遅い」という印象をチームに与えてしまったのです。

この経験を通じて見えてきたポイントは次の通りです。

出力形式を必ず指定すること
→ 「Markdown表」「JSON形式」「箇条書き」など、利用者が扱いやすい形式を明示する。曖昧に任せるとUXは崩れる。
利用者の目的をプロンプトに埋め込むこと
→ 「レビュー会議で共有するため」「一覧比較するため」といった用途を前提にする。これを伝えないと、AIはただ長文を返して終わる。
テンプレート化してチームで共有すること
→ うまくいった形式は属人化せず、NotionやGitHubにまとめて全員が再利用できるようにする。
工数削減の効果を数値で検証すること
→ 「従来比50％削減」のように改善効果を測定・可視化し、導入の説得材料にする。効果を数値で示せなければ継続利用は難しい。

出力形式の指定というシンプルな工夫ですが、現場の体感は大きく変わります。実際にレビュー工数で悩んだ経験がある方なら、その効果を想像しやすいかもしれませんね。

現場で感じたこと：プロンプト設計は非機能要件に近い

プロンプト設計を振り返ると、単なる入力文ではなく、非機能要件と同じくらいシステム品質を左右する性質を持っていると実感します。以下の4つは特に外せない視点です。

性能（精度・一貫性）
一度は正解に近い出力が出ても、再現性がなければユーザー体験は成り立ちません。たとえばFAQ生成で回答が日によってばらつくと、ユーザーはすぐ「信用できない」と判断します。これを避けるには、入力パターンごとの期待値を定義し、出力の揺らぎを許容範囲内に収める設計が必要です。

可用性（標準化・再利用性）
プロンプトが担当者の頭の中にしかないと、引き継ぎのたびにゼロから作り直しになります。実際に「この人が抜けたら誰もプロンプトを再現できない」という属人化を見てきました。チームで再利用できるよう、共通テンプレート化やリポジトリ管理を整えることが不可欠です。

保守性（改修のしやすさ）
運用が進むと業務要件の追加やルール変更に応じてプロンプトも更新が必要になります。ところが長文で複雑に書き連ねたプロンプトは修正のたびに壊れやすい。条件を分割し、役割・形式・制約を分けて管理することで、将来の改修に耐えられる形になります。

信頼性（ユーザー検証による体感の安定性）
技術的には正しい回答でも、ユーザーが「毎回違う」と感じれば信頼は失われます。実際、現場では「モデルの精度よりUXの安定感」で導入可否が決まる場面が多々あります。ユーザーテストで「どの程度のばらつきなら使えると感じるか」を測り、その許容値に合わせてプロンプトを調整することが重要です。