- 公開日
指定の形式を守るために、根拠のない結論を作ったり、共有してはいけない情報を出したりしてはいけません。まず守るべき情報・操作の境界と事実の正確さを保ち、その範囲で形式を満たします。両立しないときは、何が足りず、なぜ指定どおりに答えられないのかを短く示し、未確認の表示や部分回答へ切り替える条件を依頼に含めます。
安全性を理由に事実を変える必要はありません。「実行を保留する」という処理上の判断と、「事実として禁止されている」という結論を分ければ、慎重に扱いながら不確実性も正確に伝えられます。
「必ず一語で答える」が、判断を狭める場面
架空の営業担当者が、資料の社外共有についてAIへ確認する例です。使うAIサービスには、提示する情報の入力許可があると仮定します。共有対象の資料そのものを外部へ送らせる作業ではなく、手元の記録から確認事項を整理する場面です。
提供されている記録は、次の三点だけです。
対象は取引先向け製品説明資料の第3版。
社内共有フォルダに保存されている。
資料管理者へ社外共有の確認を依頼しているが、返答の記録はまだ提示されていない。
元の質問を「この資料は社外に送ってよいですか。必ず『可』か『不可』の一語で断定してください」とします。この形式には、確認できない状態の置き場所がありません。
「可」と答えれば、社内フォルダにあることを社外共有の許可へ読み替えています。「不可」と断定すれば、許可を確認できないことを、禁止されている事実へ変えてしまう場合があります。この材料から確認できるのは、確認依頼があることと、提示された記録には返答がないことです。別の場所にも返答が存在しない、という結論までは出せません。
したがって、この例では「共有可否は未確認。確認できるまで送信を保留する」と分けるのが適切です。保留は今回の運用上の対応であり、資料が永久に共有禁止であるという判定ではありません。
優先順位は、何を守るかまで書く
「安全性、正確性、形式の順で優先」とだけ書くと、安全性が何を意味するかが曖昧です。この場面なら、次のように対象へ落とせます。
第一に、共有の許可を確認できないまま、社外へ送信しないことです。第二に、資料や記録にない許可・禁止を作らず、確認できた範囲だけを述べることです。そのうえで、できるだけ短く、読み手が状態を分かる形に整えます。
これは、正確性を二の次にしてよいという意味ではありません。安全性のために止める場合も、止めた理由は事実に即して説明します。「危険な資料です」と評価を付けるのではなく、「この第3版の共有許可を示す記録が提示されていません」と不足の対象を限定します。不足を示すために、資料の中身や取引条件を回答へ書き写す必要はありません。確認の回答そのものが、新しい情報漏えいの経路にならないようにします。
Anthropicのハルシネーション対策資料は、不確実な場合に不明と答えられるようにすることや、主張を根拠へ照合することを紹介しています。この方法も誤りを完全になくすわけではありません。依頼文で未確認を許容しつつ、回答の根拠を人が確かめる余地を残します。
短い回答という目的を残して、依頼を直す
この例で残したいのは、忙しい担当者が素早く判断状態を把握できることです。変えるのは、「可・不可のどちらかへ必ず押し込む」という条件です。改善した依頼は、例えば次のようになります。
提示した記録から、この第3版を社外共有できるか確認してください。
根拠のない許可・禁止は補わず、許可を確認できない間は送信を保留してください。
先頭に「可・不可・未確認」のいずれかを示し、その後に根拠または不足する記録を一文で付けてください。
一語だけでは正確に答えられない場合は、その理由と次に確認するものを短く示してください。
資料の送信は行いません。この依頼では、未確認の場合だけ長文の説明へ切り替える必要はありません。期待する出力は、例えば次のようになります。
未確認。第3版の社外共有許可を示す返答が提示されていないため、可・不可の一語では断定できません。資料管理者の返答と対象版を確認するまで、送信を保留してください。
これは説明用の期待出力で、実際にモデルへ入力して得た結果ではありません。差し替えるのは、対象資料と版、判断に使う記録、確認先です。回答後は、本当に返答が提示されていないかを材料へ戻って確認し、許可がある場合は、その宛先や利用目的まで今回の共有と一致するかを確かめます。
同じ形式でも、根拠が変われば答えは変わる
未確認という答えを固定すると、必要な記録が後から揃っても止まり続けます。同じ資料について追加情報が来た場合は、その内容を照合して判断を更新します。次の表も架空の説明例です。
| 提示された記録の状態 | 期待する回答の扱い | 次に確認すること |
|---|---|---|
| 第3版を、指定の取引先へ製品説明のため共有できると、権限ある管理者が許可している | 記録上の条件を満たす範囲で「可」と説明 | 実際の対象版・宛先・目的が許可と一致するか |
| 第3版は社外共有禁止と、有効な管理記録で確認できる | 対象を限定して「不可」と説明 | 公開用の別資料など、許可された代替があるか |
| 返答が提示されていない、または別の版の許可しかない | 「未確認」とし、今回の送信は保留 | 対象版に適用される許可の有無 |
許可の記録を見つけたことだけで、別の宛先への送信まで認められるわけではありません。反対に、ある相手への送信が許可されていないからといって、資料の社内整理まで止める必要があるとも限りません。何を答えるか、どの操作を止めるかを対象ごとに区切ります。
また、許可を説明する回答と、送信を実行する依頼は別です。AIが「可」と返したという理由だけで送信処理を始める設計にはしません。OWASPの対策資料も、ツール呼出しを利用者の権限や作業の文脈と照合し、必要な範囲へ権限を限定することを挙げています。文章の形式が正しいことは、操作の権限を証明しません。
形式の制約そのものが重要な場合
人が読む短い回答なら、未確認の理由を一文追加できます。一方、別のシステムが「可・不可」の二値だけを受け取る設計なら、AIが勝手に自由文を混ぜると処理が壊れることがあります。その場合は、依頼文だけで解決しようとせず、未確認を受け取る方法や、人へ戻す経路を受け手側と決めます。
例えば、判定結果とは別に「処理保留」を扱えるようにする方法が考えられます。ただし、具体的な出力項目と動作は接続先の契約に合わせて設計する必要があります。「未確認」を「不可」として保存するなら、それが事実上の禁止を意味するのか、今回は実行しないという運用状態なのかを区別しなければなりません。
形式を満たせないときに空欄や既定値へ置き換える運用にも注意が必要です。空欄を受け手が許可と解釈するなら、保留の意味が失われます。出力を短くすることと、判断状態を消すことを同じにしないようにします。
運用を始める前には、架空の記録を使い、実際には送信しない環境で、上の表の三つの状態が受け手側でそれぞれ別の処理へ分かれるかを確かめます。未確認を扱えるようにすると、人が確認する件数は増えることがあります。その負担は、承認記録を最初から入力にそろえる、確認済みの宛先を選択式にするなど、不足が生まれる入口を整えて減らします。未確認を「可」へ寄せて件数を減らせば、確認の意味そのものが失われます。
会話の途中で「もっと短く」と言うときも、条件を残す
改善後の回答に「説明はいらない、一語だけ」と追加すると、最初の衝突が戻ることがあります。短さを優先したい場合は、「先頭は可・不可・未確認の一語にし、未確認なら確認する資料だけを次の行に残す」と、残す意味を明示します。
文字数の指定と必要な説明がぶつかった場合は、まず重複を削ります。それでも収まらず、読み手が人であれば、判定理由のために一文を補うと断って調整できます。安全上の問題がない整形の指定にまで、毎回長い注意書きを付ける必要はありません。
長い会話で形式の指定が何度も変わったときは、今の対象版、有効な根拠、未確認の扱い、送信しない範囲を短くまとめて再提示します。以前の許可を無条件に復活させたり、古い版についての確認を新しい版へ引き継いだりしないようにします。要約の仕組みを作り込む前に、現在の依頼が何を判断するものかを揃えます。
仕上げでは、指定形式に合うかに加え、許可・禁止の根拠があるか、不足を正確に示しているか、次の確認が分かるかを見ます。安全性と正確性を守るための例外を、形式の外へ追い出さず、形式の中で扱えるようにすることが、依頼文を直す中心になります。
形式以外の指示も含めて、安全性・正確性・速度が衝突したときの優先順位は「AIへの指示が衝突したら？ 安全性・正確性・速度の優先順位と例外の決め方」で解説しています。
基本から確認する：この記事の前提になる考え方は、「プロンプトの書き方ガイド（依頼文の基本6項目と例文）」にまとめています。
