Claudeのプロンプトが矛盾するとき：制約の優先順位を設計する

必須と希望を分ける

守れなければ業務上使えない条件を必須にします。たとえば未確認の数値を作らないことは必須で、300字以内は希望かもしれません。文字数を満たすために重要な例外を消すなら、見た目の成功が内容の失敗になります。

条件を並べる際は、衝突時の扱いも指定します。「必要事項が収まらなければ、短い本文と補足を分ける」と決めれば、黙って情報を捨てる以外の経路ができます。

入力の条件と出力の条件を混ぜない

資料の日付や対象部署は判断の前提です。敬語や見出しは提示方法です。二つを同じ箇条書きに埋め込むと、表現の変更が事実の変更に見えることがあります。前提、判断規則、出力欄に分けることで、人も確認しやすくなります。

ただし区切りを作るだけで正しさが保証されるわけではありません。入力が矛盾しているときは、どちらかをモデルに選ばせるのでなく、矛盾として報告させるか確認を求めます。

優先順位を試す入力を用意する

通常例では制約の競合は表れません。長い例外説明、未確認の価格、両立しない締切などを含むケースで評価します。全条件を満たしたと自己申告しても、実際の出力が省略や創作をしていないかを別に点検してください。

満たせない条件を検出する試験を加える

プロンプトの評価では、全条件が両立する普通の入力だけを使わないようにします。「価格は資料にないが、必ず価格を含める」という架空の衝突を入れ、根拠を作らず不足を報告できるかを確認します。条件の優先順位を書いても、実際にどの条件を守ったかは出力を点検する必要があります。違反を文章の長さや丁寧さで相殺しません。

複数の人が指示を追記する場合は、同じ事項を別の言葉で重複させると、優先順位が分かりにくくなります。変更時に既存の条件と衝突していないかを確認し、古い指示を履歴へ移す判断も必要です。強調を増やすより、条件が一つの場所で定義され、実際の業務へどう適用されるかを追える状態を目指します。

具体例で考える

説明用ケース：100字の通知に、五つの重要な例外条件を載せる必要があります。

必須：対象者と例外を正確に伝える。
希望：通知本文100字。
衝突時：本文は概要とし、例外は補足へ分離。
不許可：例外を削除して文字数だけ合わせる。

短さを守れたかだけで採点せず、情報がどこへ移されたかを確認します。本文と補足を分けても読者が補足へ到達できなければ、実際の利用場面では失敗です。出力の構造を画面や運用までつなげて判断します。

確認課題と合格の目安

一つの依頼から必須条件と希望条件を分け、衝突するケースを一つ作ってください。

• 満たせない条件を黙って消していない。
• 事実の条件と表現の条件が分かれている。
• 補足情報へ読者が到達できる。