- 公開日
AIへの依頼に不明な点があるときは、解釈を間違えた場合の影響と、後から直せる範囲を見て判断します。送る相手や作業の対象が変わる不明点は、その条件に依存する作業の前に確認します。一方、人が読む下書きの語調など、影響が限られ修正しやすい未指定は、仮定を明示して進められます。
ここでいう曖昧性解消は、依頼に複数の解釈があるとき、どれを採るかを確かめることです。分からないことをすべて質問に変える必要はありません。ただし、仮定した内容を後の工程で確定事項に変えないことと、質問への回答を外部操作の許可と取り違えないことが条件になります。
この記事では、不明点があるときに確認するか、仮定して進むかを決める基準を扱います。依頼の中に隠れた前提そのものを見つける方法は「AIが補う暗黙の前提を見つけて確認する方法」、情報が足りない場面でAIに返してほしい内容の指定は「『推測するな』の次を決める」で扱います。
不明点の数よりも間違えた後の影響を見る
「短い案内を作って」という依頼では、文体、長さ、読み手、掲載場所などが省略されています。これらを毎回すべて聞くと、利用者は文章を作り始める前に細かな判断を求められます。かといって、AIが一通り補えばよいとも言えません。送信先の推測を誤れば、案内を受け取る必要のない人に届き、受け取るべき人には届かないからです。
判断するときは、不明点について次の関係を考えます。
- 別の解釈を採ると、文の見た目だけでなく、伝える内容や作業対象まで変わるか
- 誤りを見つけた時点で、誰かがその内容を読んだり、行動したりしていないか
- 作業を限定すれば、不明点を残していても修正可能な成果を作れるか
「語調は軽微、送信先は重大」と項目名だけで固定するわけではありません。語調が未指定でも、謝罪文のように表現が関係者の受け止め方を左右する場面では、先に意図を確かめる理由があります。送信先がまだ決まっていなくても、公開情報だけを使う汎用の案内ひな型なら、宛名を空欄にして作れる場合があります。
Microsoft Researchが2019年に紹介した人とAIの対話設計ガイドラインは、利用者の目的が不確かなときに意味を確かめるか、サービスの範囲を抑えることを指針10に挙げ、誤りを編集・修正しやすくすることを指針9として別に扱っています。これは設計の参考になる指針であり、すべての場面で質問を義務付ける仕様ではありません。
案内文の語調が未指定なら下書きで示す
以下は架空の会社で、総務担当者が経費精算の説明会を案内する例です。担当者は、利用が認められたAI環境へ、案内作成に必要な情報だけを渡すものとします。説明用のメモには次の内容があり、ここでは担当者が最新版と確認したものとします。
- 開催日時：2026年11月12日、15時から15時30分
- 会場：第2会議室
- 内容：経費精算システムの入力方法
最初の依頼は「このメモを使って、営業部向けの案内文を下書きして」です。送信は依頼されておらず、担当者が下書きを読んで直せる状態です。語調は指定されていません。
この場合は、「社内向けの簡潔な敬体を仮定しています」と担当者向けの注記を添え、例えば次の文を出せます。
「営業部の皆さまへ。2026年11月12日15時から15時30分まで、第2会議室で経費精算システムの入力方法について説明会を開催します。」
この文は期待する出力例で、実際のAIによる試験結果ではありません。担当者は、日時、会場、内容がメモと一致するかを確認し、部署内で普段使う言い方に合わせて語調を直します。「必ず参加してください」や「参加は任意です」は、メモにも依頼にもない条件なので追加しません。語調を補うことと、参加条件を決めることは別です。
ここで減らせるのは、下書きの前に行う文体の好みの質問です。原資料との照合や、その情報をAIへ入力してよいかの確認まで省けるわけではありません。最初から自動配信する設定なら人が直す機会がなくなるため、同じ未指定でも扱いを見直します。
送信先が不明なら対象に依存する作業の前に聞く
別の場面として、同じ説明会のメモを使い、送信先を一度も指定していない状態で「案内文を作ってメールで送って」と依頼された場合を考えます。担当者の画面には営業部と全社員の宛先候補があるとします。ここで「説明会だから全社員だろう」と対象を選んではいけません。
先に「送信先は営業部、全社員、または別の範囲のどれですか」と確かめます。答えによって宛名と送信対象が変わり、部署限定の説明会なのか全社向けなのかも確認が必要になるからです。もっともらしい方を選び、「全社員向けと仮定しました」と注記して送っても、相手に届いた影響は注記で取り消せません。
ただし、回答待ちの間にすべての作業を止める必要はありません。対象によらず共通で、利用を許可された日時・会場・説明内容だけなら、未送信の文案として整理できます。「宛先未確認のため、宛名と対象者の記述は保留。共通部分のみ下書き」と示し、送信は保留します。対象者によって日時や参加条件まで変わるなら、それらも確定させず、確認できた部分に範囲を狭めます。
担当者から「営業部だけです」と返ってきたら、その回答を今回の送信対象として記録します。次は、実際の宛先が営業部の対象者に対応しているかを確かめます。部署名が明らかになったことと、宛先一覧の中身が正しいことは同じではありません。確認できなければ、送信せず担当者に対象の指定を求めます。
この二つの例では、案内の素材は同じでも、依頼された作業の範囲と未指定の項目が異なります。下書きで直せる表現と、他の人へ届ける対象を分けて扱うことで、何を聞いてから進めるべきかを判断できます。
仮定は下書きと一緒に引き継ぐ
仮定を置くときは、「おそらく適切です」と曖昧に添えるよりも、何を仮定し、どこに使ったかを具体的に残します。送信先への回答を待っている段階なら、担当者が下書きを確認する場所に、次のような短い記録を置けます。
| 項目 | 現在の扱い | 確認や変更の方法 |
|---|---|---|
| 日時・会場 | 今回のメモに記載された値を使用 | 送信前にメモの最新版と照合 |
| 語調 | 簡潔な敬体を仮定 | 担当者が下書きを読んで修正 |
| 送信先 | 未確認 | 担当者の回答と実際の宛先を照合 |
この記録は作成担当者向けであり、そのまま受信者向けの案内文へ混ぜる必要はありません。ただし、下書きを別の人や別のAIへ渡すなら、未確認の項目が消えないよう一緒に渡します。「案内文は作成済み」という要約だけでは、送信まで進められる状態か分からなくなります。
回答が来た後も、書き換えるのは確認できた項目です。「営業部宛てと確認済み」と更新しても、この返信では語調について確認していないため、語調は仮定のままです。利用者が別の話題へ進んだことや、仮定について訂正しなかったことを、すべての条件の了承とみなさないようにします。
後から対象が全社員へ変われば、宛名だけでなく、部署限定の説明が残っていないかも見直します。以前の回答は、その時の依頼に対する確認として残せますが、新しい送信範囲を正当化する根拠にはなりません。仮定や回答には、どの依頼のどの範囲に適用したものかが分かる短い文脈を添えます。
意味の確認と送信を許可する判断を分ける
確認質問が明らかにするのは、利用者が何を求めているかです。それに対し、権限はその人やAIがどの情報・操作を扱えるか、承認は対象の操作を行ってよいと認められているかに関わります。「誰に送るか」が分かっても、その相手へその内容を送る許可まで自動的に得たとは扱いません。
案内文を作るだけの依頼なら、AIが送信機能を持っていても下書きで止めます。送信まで依頼された場合も、対象・内容・実行条件が依頼や承認の範囲に収まるかを確かめます。すでに有効な承認があるのに毎回聞き直すという意味ではありません。条件が変わったときや、必要な承認を確認できないときに、送信へ進めないようにする考え方です。
運用では、送信前に対象と本文を確認できる画面や、下書き段階で送信機能を使えなくする設定を用意する方法があります。これらは、この案内作成への設計提案です。プロンプトに「不明なら確認して」と書くだけで、誤送信が起きなくなると保証するものではありません。
依頼を受けたら、まず手元の資料で確かめられることを読み取り、残った不明点が次の作業をどう変えるかを見ます。確認が必要な部分を保留しつつ、仮定を見える形にして進められる部分を切り分ければ、担当者は下書きを直しながら、外へ出す判断を別に行えます。
基本から確認する：この記事の前提になる考え方は、「プロンプトの書き方ガイド（依頼文の基本6項目と例文）」にまとめています。
