評価がないと、改善は永遠に“気分”になる

生成AIを使い始めた人がぶつかる壁は、出力が「当たり外れ」になりやすいことです。あるときは驚くほど良い文章が出るのに、別の日は同じ依頼でも薄い、長い、ズレている。こうなると、プロンプト改善は運任せの儀式になりがちです。言い回しを変え、語尾を整え、丁寧に書き直し、それでも直らない。原因は単純で、「何をもって良いとするか」が固定されていないからです。

評価がない状態での改善は、ほぼ確実に感想ベースになります。「なんか違う」「もっと分かりやすく」「刺さらない」「固い」。こうした言葉は人間同士なら会話で補えますが、プロンプトの改善材料としては曖昧すぎます。曖昧な評価は、曖昧な修正を生みます。結果として、プロンプトをいじればいじるほど、何が効いているのか分からなくなり、再現性が失われていきます。

評価がプロンプトにとって重要なのは、出力を採点するためだけではありません。評価は、プロンプトの設計対象を明確にします。たとえば「要点がまとまっている」という評価があるなら、要点とは何か、どの順序か、いくつか、欠けたら不合格かを定義しないといけません。評価基準を作る作業は、目的を分解し、条件に落とし込む作業でもあります。つまり評価を作ること自体が、プロンプト設計の質を上げます。

実務で考えると、評価の効果はさらに大きくなります。チームでAIを使う場合、評価基準がないと「誰の出力が正しいか」の議論が噛み合いません。担当者が変わるたびにプロンプトの癖が変わり、成果物の品質が揺れます。逆に評価基準があると、プロンプトが共有可能な資産になります。改善の議論は「好み」ではなく「基準への適合」で行えるようになり、属人性が下がります。プロンプトを運用するというのは、プロンプトを文章として扱うのではなく、品質基準を持つプロダクトとして扱うことなのです。

また評価がないと、モデルの“もっともらしさ”に引きずられます。生成AIは自然な文章を作るのが得意で、読みやすい文章は出てきます。しかし読みやすいことと正しいこと、役に立つことは別です。見た目の出来が良いほど誤りに気づきにくくなる、という厄介な性質もあります。評価観点を持つことは、この“見た目の良さ”に騙されないための安全装置でもあります。

評価基準の作り方は“採点表”から逆算する

評価を作る、と言うと難しく聞こえますが、やることは採点表を作るのと同じです。採点表は、良い成果物の要素を分解して、点検できる形にするものです。ここでのコツは、評価を「抽象語」から始めないことです。最初から「分かりやすさ」や「説得力」といった言葉を掲げると、結局また曖昧さに戻ってしまいます。まずは観察可能な要素に落とすことから始めます。

たとえば文章生成の評価なら、形式遵守は最初に入ります。指定した構造になっているか、見出し数は合っているか、リードは指定の長さか、箇条書きは禁止なのに使っていないか。これは“ゼロイチ”で判定できるので、基準として強いです。次に目的適合です。対象読者は想定どおりか、用途に合うトーンか、求めるアウトプットになっているか。ここはやや主観が入りますが、読者像や用途を明記しておくとブレが減ります。さらに内容面では、網羅性、具体性、正確性、冗長性の抑制、一貫性などが候補になります。

ここで重要なのは、各観点に「合格条件」と「不合格条件」を用意することです。たとえば具体性なら、合格は「抽象語だけで終わらず、手順・例・判断基準がある」、不合格は「一般論で終わり、何をすればよいかが書かれていない」。網羅性なら、合格は「依頼された論点を漏らさず扱う」、不合格は「中心論点が欠ける／別の話題に逸れる」。正確性なら、合格は「根拠が曖昧な断定がない」、不合格は「断定が多いのに根拠が示されない」。こうして条件を並べると、評価が“気分”ではなく“チェック”になります。

採点表を作るときは、満点主義にしないのもコツです。全部を高水準で満たそうとすると、プロンプトが重くなり、出力が固くなりがちです。評価には優先順位を付けます。たとえば業務文書なら「正確性＞形式遵守＞簡潔性＞表現の美しさ」。アイデア出しなら「新規性＞多様性＞具体性＞形式遵守」。この優先順位があるだけで、モデルが迷いにくくなりますし、改善の方向性もブレません。

そして評価基準は、プロンプトの中に“そのまま書く”必要はありません。プロンプトに評価観点を埋め込む方法はいくつかあり、用途によって使い分けます。たとえば出力の最後に「自己チェック項目」を置く方法、生成前に「必ず満たす条件」を宣言させる方法、生成後に「条件を満たしていない場合は修正する」手順を組み込む方法などです。ここでの狙いは、モデルに“採点者の目”を持たせることです。採点者がいないと、モデルは自然さ優先で走ります。採点者がいると、形式や条件の漏れを埋めようとします。

なお、モデルに評価させるときの注意点もあります。モデルの自己評価は万能ではなく、甘くなったり、都合の良い理由を作ったりします。だから評価を任せきりにせず、評価は「形式」「必須項目」「禁止事項」など、客観的なものを中心に置くのが安全です。主観が大きい評価は、人間が最終判断する前提で補助として使う、という距離感が実務的です。

自己チェックと再生成の“安全な回し方”

評価をプロンプトに組み込む上で、もっとも効果が出やすいのが自己チェックと再生成の設計です。人間が書いた文章でも、書きっぱなしより推敲した方が良くなります。生成AIも同じで、最初の出力は“下書き”として扱い、条件に合わせて整える工程を入れると品質が上がります。ただし、やり方を間違えると冗長化し、かえって使いづらくなるので、回し方にはコツがあります。

第一に、自己チェックは「出力を増やすため」ではなく「出力を整えるため」に使います。ありがちな失敗は、チェック結果を長々と出させてしまうことです。チェックの文章が増えるほど、最終成果物が埋もれますし、情報量が増えて読み手の負担になります。実務では、チェックは内部で行わせ、最終版だけを出させるのが基本です。つまりプロンプトとしては「次のチェックを実施し、条件を満たす最終出力のみ提示せよ」という形に寄せます。

第二に、再生成の条件を明確にします。「もし条件を満たしていない場合は修正してから提出する」と書くだけでも効果はありますが、さらに強くするなら「形式違反が一つでもあれば修正」「必須要素が欠けていれば修正」「断定があり根拠が不足していれば表現を修正」といった具合に、修正トリガーを具体化します。これはモデルにとって“何を直せばいいか”が分かるので、結果が安定します。

第三に、テスト入力セットを持ちます。自己チェックを組み込んだプロンプトは強力ですが、万能ではありません。依頼の種類や入力の癖によって、別の失敗が出ることがあります。そこで、よく使うケースを2〜3個、できれば難しめのケースも含めて用意し、そのセットで毎回プロンプトを試します。これにより「一回の当たり」に最適化されるのを防げます。運用としては、改善のたびにこのセットで回し、合格率が上がっているかを見るのが分かりやすいです。

第四に、変更は小さく、ログを残します。プロンプトは一見すると文章ですが、運用上はコードに近いものです。どこを変えたか分からなくなると、改善が止まります。実務でのコツは、プロンプトをブロックごとに分け、変更点を一つずつ試すことです。たとえば「禁止事項を追加した」「出力テンプレートを厳密化した」「評価項目を増やした」といった変更を同時にやらず、差分の効果を観察します。これだけで上達速度が変わります。

最後に、自己チェックを過信しないことも大切です。モデルは自分の出力を完全には検証できません。特に事実性の確認や、外部情報の真偽はモデルだけでは保証できません。だからこそ、自己チェックの中心は「形式遵守」「必須要素の有無」「断定の抑制」「推測と事実の分離」など、モデルが内側で整えられるものに寄せます。必要に応じて「不確かな場合は保留にし、追加情報を求める」といった行動方針も組み込むと、安全性が上がります。 プロンプトに評価を組み込むとは、AIを賢くする魔法ではなく、あなたの目的に合わせて“合格条件”を明確にすることです。評価があると、改善が気分から検証に変わります。まずは一つのタスクで構いません。形式と必須要素と禁止事項だけでも採点表に落とし、それを自己チェックとしてプロンプトに内蔵してみてください。出力の安定性が上がり、直すべきポイントも見えるようになります。

「うまく質問すれば良い答えが返る」という感覚は、検索エンジンの時代にはかなり有効でした。けれど生成AIは、知っている情報を探して提示する存在ではなく、与えられた文脈から“それらしい文章”を作る存在です。つまり、質問が少し曖昧でも返事は返ってきます。ここが便利な反面、品質の面では落とし穴になります。制約が不足したプロンプトは、ほぼ例外なく次のような形で崩れます。

まず起きやすいのは、出力が毎回ブレることです。同じ依頼をしているつもりでも、あるときは短く、あるときは長く、あるときは丁寧で、あるときは砕ける。構造が揺れると、読み手が使う場面で困ります。たとえば社内の文書、顧客向けの文章、テンプレートに流し込む素材などは、形が揃っていないだけで作業コストが跳ね上がります。安定しない出力は「使えるかどうか」が運頼みになり、結局は人が手で直す前提になってしまいます。

次に起きるのが、前提を勝手に補う問題です。制約が薄いと、モデルは“空白を埋める”方向に働きます。依頼に情報が足りないとき、モデルは「多くの場合こうだろう」という一般的な想定を混ぜて文章を完成させます。これは発想支援には役立ちますが、事実性や組織固有の前提が重要な仕事では危険です。特に「断定調」「具体名」「数字」「因果関係」は、もっともらしい嘘を生みやすい領域です。制約がないと、読み手から見ると“自信満々で間違っている”文章が出てしまうことがあります。

さらに、観点が散るという現象も頻出です。たとえば「プロンプト設計について解説して」とだけ依頼すると、定義の話、テクニック集、ツールの紹介、歴史、注意点などが混ざりやすく、焦点がぼやけます。読む人が欲しいのは「この場面ではこれ」という具体的な答えなのに、総花的な説明になり、結局は使えない文章になります。これはモデルが悪いのではなく、依頼側が「何を中心にしてほしいか」を指定していないために起こる当然の結果です。

もう一つは冗長化です。制約がないと、モデルは安全側に倒れて長く説明しがちです。丁寧に見せるために前置きが増え、似た内容を言い換え、結論が遅れます。特にビジネス文脈では、読みやすさは「短さ」そのものではなく「必要な情報がすぐ出てくること」にあります。冗長さは読み手の負担であり、意思決定のスピードを落とします。制約設計とは、こうした“それっぽさ”の膨張を抑えるための装置でもあります。

ここまでの失敗は、すべて「自由度が広すぎる」ことで起きています。生成AIは自由度を与えれば与えるほど、幅広い可能性の中から“もっともらしい一点”を選びます。つまり制約がないプロンプトは、期待値が低いのではなく、分散が大きいのです。たまに神回答が出る代わりに、外れも増える。この性質を理解すると、「うまい質問を探す」のではなく「必要なところを固定して分散を縮める」という発想に切り替わります。

“固定すべき制約”と“固定しないほうが良い制約”

制約は多ければ多いほど良い、というわけではありません。重要なのは、固定すべきところを固定し、固定しないほうが良いところは自由にさせることです。制約設計の要点は、モデルの強みを活かす範囲と、事故を防ぐ範囲を切り分けることにあります。

まず固定すべきなのは、出力形式です。形式が揺れると比較も評価もできません。見出しの数、段落構成、口調、文字量の目安、出力の順序など、最終的に“使う形”に直結する部分はできるだけ指定します。たとえば記事なら「タイトル→リード→見出し3つ→本文」という枠、提案書なら「結論→背景→施策→リスク→次アクション」という枠。形式が固定されると、内容の改善に集中できます。

次に固定すべきなのは、対象範囲です。どこまで話していいのか、どこから先は扱わないのかを決めます。「初心者向け」「専門家向け」「社内メンバー向け」だけでも効果がありますが、さらに「この分野の説明はしない」「この用語は前提とする」「この話題は含めない」といった線引きがあると、出力は締まります。範囲は文章のスケールを決める制約であり、範囲が曖昧だと内容が広がり、結果として薄くなります。

さらに固定すべきは、根拠の扱いです。ここを放置すると断定が増えます。「不明な点は不明と言う」「推測と事実を分ける」「断定する場合は理由を添える」「与えた情報以外に依存しない」など、根拠のルールは品質と安全性に直結します。特に業務で使うなら「勝手に補完しない」制約は強力です。発想支援として使いたい場合は逆に「仮説として提示する」と指定すると、推測が許容範囲に収まります。

そして禁止事項も固定の効果が高い領域です。箇条書きを禁止、専門用語の羅列を禁止、過剰な煽り表現を禁止、断定口調を禁止、など。禁止はモデルの“出しやすい癖”を抑えるために使います。モデルは一般的に、断言、テンプレ表現、抽象的なまとめを好みます。これを抑えるのが禁止事項です。

一方で、固定しないほうが良い制約もあります。代表例が「解法」や「発想の手段」まで縛ることです。たとえば「必ずA→B→Cの順に説明し、例はこの形式で、比喩は使わず、語彙はこの範囲で、さらに…」のように、表現や構成の細部まで締めすぎると、モデルが持つ生成能力が活かせず、窮屈で不自然な文章になりがちです。目的が“安定した型の量産”なら有効な場合もありますが、アイデア出しや多様な視点が必要なタスクでは逆効果です。

また「ふわっとした美意識」だけを制約にするのも危険です。「かっこよく」「エモく」「刺さる感じで」などは、読者の期待とズレたときに修正が難しいからです。こうした要望を入れるなら、「どんな読者に」「どんな行動を促すのか」「避けたい印象は何か」まで具体化して、評価可能な形にしておく必要があります。

制約の設計は、場面によって最適解が変わります。正確性と一貫性が重要なら、形式・範囲・根拠・禁止を厚めにし、自由度を減らします。アイデアや草案が欲しいなら、形式だけ軽く固定し、観点の幅を広げる制約に寄せ、表現手段は縛りません。この切り替えができるようになると、「同じモデルでも別物のように使える」感覚が手に入ります。

制約を“文章”ではなく“構造”で渡す方法

制約は文章で書けば伝わる、と思いがちですが、実務ではそれだけでは足りないことが多いです。理由は単純で、長い文章の中では重要な条件が埋もれたり、条件同士が衝突したりするからです。制約を守らせるコツは、制約を“読み物”として渡すのではなく、“構造”として埋め込むことにあります。

最も効果が高いのは、セクション分けです。役割、目的、入力、制約、出力形式を明確な区切りで分けると、モデルは条件を整理して受け取りやすくなります。人間が読みやすいことは、モデルにとっても概ねプラスに働きます。区切りがない長文依頼は、条件の優先順位が曖昧になり、結果として守られない条件が増えます。

次に効くのは、出力テンプレートを提示することです。たとえば「次の形式で出力せよ」として、見出しの枠や順序をあらかじめ置きます。テンプレートは制約を“形”に変換するので、文章で禁止・推奨を書くより守られやすい傾向があります。たとえば「結論を先に」と書くより、「結論：／理由：／具体例：」という枠を置く方が確実です。モデルは枠に合わせて埋めるのが得意です。

そして、チェック手順を内蔵する方法があります。出力後に「形式が守れているか」「禁止事項に触れていないか」「根拠が曖昧な断定がないか」を自己点検させ、満たしていない場合は修正させます。ここで重要なのは、点検結果を長々と出させないことです。点検の詳細は不要で、最終成果物を改善させるのが目的です。つまり「チェックした上で、条件を満たす最終版だけ出力せよ」といった形にすると、余計な冗長性を増やさずに品質を上げられます。

さらに、制約同士が衝突したときの優先順位を明示するのも構造化の一部です。例えば「簡潔に」と「網羅的に」はしばしば衝突します。どちらを優先するかが書かれていないと、モデルは中途半端な折衷を選びます。優先順位を「最優先は正確性、次に形式遵守、その次に簡潔性」といった形で渡すだけで、迷いが減り、出力の癖も安定します。

最後に、制約は“文章量”で勝負しないという点も強調しておきます。制約を増やすほど良いのではなく、守らせたい条件を少数精鋭で、構造として埋め込むことが効きます。モデルは大量の条件をすべて同じ重みで扱えません。だからこそ、重要条件を上に置き、形式に落とし込み、禁止事項を明確にし、必要なら自己チェックで補強する。この順序で設計すると、短いプロンプトでも強い制御がかかります。 結局のところ、良い出力は「質問が上手い人」の特権ではありません。目的に対して何を固定し、何を自由にするかを決め、制約を構造として渡せる人が、安定して成果を出します。まずは次にAIへ依頼するとき、言い回しを工夫する前に、出力形式と禁止事項と根拠の扱いだけでも固定してみてください。体感できるレベルで、出力のブレが減るはずです。