- 公開日
AIへの依頼で安全性・正確性・速度が衝突したら、まず権限や情報の扱いなど、守るべき条件を確かめます。その範囲で、誤りが誰にどんな影響を与え、後からどこまで直せるかを基準に、確認へかける手間を決めます。優先順位だけでなく、条件を満たせないときにどこを保留し、誰へ確認するかまで伝えると、判断の境目が明確になります。
ここで扱うのは、同じ依頼者が「早く」「正確に」「安全に」と同時に求め、その正当な指示同士がぶつかる場面です。開発者と利用者のように出所の異なる指示のどちらを採るかは、命令階層と信頼境界とは？ AIへの指示と外部資料を分ける基本で扱っています。
たとえば社内文章の言い回しを整える作業と、顧客へ料金を案内する作業では、同じ「急いで」でも省ける確認が違います。短時間で案を出すことは共通の目標にできますが、金額の根拠がないまま送信まで進めることは別の判断です。
優先順位を決める前に、目的と条件を分ける
「正確に、分かりやすく、安全に、早く」と並べるだけでは、両立しない場面での扱いが残ります。正確さを確かめるための資料が入手できず、提出時刻が近づいているとき、AIは推測で空欄を埋めるべきでしょうか。それとも回答全体を止めるべきでしょうか。どちらを選ぶかは、業務で許される範囲によります。
ここでは、三つの言葉を次のように使います。安全性は、情報の漏えいや許可されていない操作などによる害を避けるための条件です。正確性は、記述や数値が原資料と対象の条件に合っていること。速度は、回答生成だけでなく、確認と修正を終えて使える状態になるまでの速さを指します。
この三つは、いつも対立するわけではありません。料金表から必要な項目だけを抽出すれば、確認対象が減り、速さと確かさを同時に改善できる可能性があります。一方、未確認の料金を即答するよう求めれば、時間と根拠の確保が衝突します。漠然と「安全と効率のバランス」を考える前に、この依頼で実際に両立しないのは何かを特定します。
NISTのAI Risk Management Framework（AI RMF 1.0）は、第3節で、信頼性に関わる特性の間の取捨は判断の文脈を踏まえて扱う必要があり、特性を一つずつ満たすだけでは信頼性全体を確保できないと説明しています。1.2.2節では、このフレームワーク自体はリスクの許容度を定めないとしています。
したがって、「安全性、正確性、速度の順」と書くだけで全業務の判断を済ませるより、要求を次の三つに分ける方が実務へ落とし込みやすくなります。
- 守る条件：入力できる情報の範囲、操作権限、事実を作らないことなど、今回の都合だけでは変えられない条件
- 改善する目標：速さ、読みやすさ、説明の詳しさなど、守る条件の範囲内で調整するもの
- 満たせない場合の対応：未確認の明示、部分的な回答、確認依頼、外部操作の保留など、不足の内容に合わせた行動
この三分類は業務設計のための整理案です。AI RMF CoreのGOVERN 1.3・1.4も、組織のリスク許容度に基づいてリスク管理活動の程度を決めることや、組織のリスク上の優先事項を反映した方針・手順を定めることを扱っていますが、「安全・正確性・速度」という唯一の序列を定めているわけではありません。
同じ文章作成でも、誤りの影響が違う
架空の小さな制作会社で、担当者が二つの文章をAIに整えてもらう場面を考えます。どちらも同じ担当者が確認し、AIの役割は下書きの作成までとします。使うサービスと資料の利用は、社内で許可済みという前提です。
一つ目は、社内勉強会の案内です。原文には「10月20日15時開始、会議室B。参加希望者は前日までに担当部署へ連絡」とあります。目的は、内容を変えずに読みやすくすることです。語尾が少し硬くても、担当者が共有前に直せます。日時、場所、連絡期限を保持できていれば、表現案を何度も比較する必要はありません。
二つ目は、顧客向けの料金案内です。手元の料金表には「基本プラン：月額12,000円、税別、2026年10月1日以降の新規契約に適用」とあります。しかし、案内する顧客が新規契約か既存契約か、契約日がいつかは、提供された資料では確認できません。ここで12,000円と書けたとしても、その顧客に適用できる料金を確かめたことにはなりません。
この二つで変わるのは、文章の宛先だけではありません。料金案内には、数値の正しさに加えて適用条件の照合が必要です。社内向けでも給与や契約条件などを扱う文章なら、同様に重い確認が必要になります。「社内だから軽く、社外だから厳しく」という分類だけでは足りません。
判断に使うのは、誤りの結果と修正の範囲です。表現の好みは共有前に直せますが、誤った料金を顧客が前提にして判断すれば、文章の差し替えだけでは解消しない影響が生じます。共有後も訂正できることと、影響を完全に戻せることは分けて考えます。
依頼には、優先するものと保留条件を一緒に書く
二つの作業を、どちらも「急いで、正確で分かりやすい案内にして」と頼むと、変更してよい範囲が明確ではありません。社内勉強会の案内なら、次のように絞れます。
次の案内を、社内向けの読みやすい文章に整えてください。
日時、場所、連絡期限は原文どおりに保ち、表現だけを変更してください。
案は一つで構いません。
情報を追加する必要がある場合は補わず、確認事項として分けてください。
共有は行わず、下書きだけを返してください。この依頼では、変更できるのは表現、保持するのは業務上の事実です。差し替えるのは案内の原文で、回答後は日時・場所・期限と意味の保持を確認します。細かな言い回しの比較は減らせても、原文との照合まで省くわけではありません。
料金案内では、照合できないときの扱いを具体的にします。
提供した料金表と顧客の契約情報に基づき、料金案内の下書きを作ってください。
金額、税の扱い、適用開始日、対象契約を照合できた場合だけ、顧客へ適用する料金として記してください。
必要な契約情報がない、または資料同士が矛盾する場合は、料金の確定を保留し、足りない情報を示してください。
急ぎでも条件を省略せず、担当者の確認用の案まで作成してください。
送信は行わないでください。ここで差し替えるのは、料金表と当該顧客の契約情報です。例の資料だけなら、期待する出力は「料金表では、2026年10月1日以降の新規契約に月額12,000円（税別）が適用される。この顧客の契約区分と契約日は資料にないため、適用は未確認」という確認用の記述になります。適用開始日と対象契約の条件を落として「月額12,000円です」とだけ書くと、確認できていない適用まで断定したことになります。顧客へ送る完成案として扱わず、契約区分と契約日を確かめてから料金部分を確定します。
これらは説明用の依頼例であり、特定モデルで効果を測定した結果ではありません。プロンプトに条件を書いた後も、出力がその条件を守ったかを人が確かめます。
「間に合わないから例外」はAIに決めさせない
保留条件があっても、「できる限り対応する」「臨機応変に判断する」とだけ付け加えると、例外の範囲が曖昧になります。料金を確認できないときに許されるのが、確認事項を整理することなのか、仮料金で案内することなのかは同じではありません。
例外を扱うなら、対象、理由、判断する人、適用する期間を明示します。たとえば担当責任者が「今回は料金を記載せず、見積もりを別途案内する文面に変更する」と決めたなら、料金確定を省略して同じ約束をするのではなく、案内内容そのものを変更したことになります。その変更が業務上許されるかも、責任者が判断します。AIに例外案を整理させることはできますが、その提案を承認として扱わず、判断する人の承認を別に得ます。また、組織内で承認を得ても、法令や契約上の要件まで変えられるわけではありません。
一方、「急ぎなので未確認の金額を確定額として書く」は、確認条件を外しています。AIが期限を理由にこの例外を作らないよう、条件を満たせないときは何を出せるかまで決めておきます。全体を止める必要がなければ、あいさつ文や問い合わせ先など、確認済みの部分の下書きは進められます。
追加資料が届いた後も、保留を機械的に解除するのではなく、不足していた点が本当に確認できたかを見ます。顧客名のある資料が届いても、契約区分や契約日が記されていなければ、今回の不足は解消していません。
文章で頼むことと、仕組みで止めること
優先順位の指示は、判断の方針を伝えるものです。実際に参照できる資料を制限するのはアクセス制御、送信できるかを決めるのは権限と承認の仕組み、数字が正しいかを確かめるのは原資料との照合で、それぞれ別に動いているかを確かめます。
「送信しない」と依頼することと、AIが送信できない設定にすることも役割が違います。下書きだけを任せる業務なら、不要な送信機能を渡さない設計を検討します。送信まで扱う仕組みでは、送信先と本文を確認し、承認した内容と実際に送る内容が一致するようにします。
OWASPのLLM06:2025 Excessive Agencyも、対策として、LLMが呼び出せる機能と権限を必要最小限に絞ること、影響の大きい操作に人の承認を求めること、認可をLLMに頼らず下流システムで行うことを挙げています。操作してよいかどうかを、LLMの判断だけに預けないための対策です。
確認を増やせば、その担当者の負担も増えます。料金案内であれば、毎回すべてを読み直すだけでなく、金額・税・適用日・契約区分を一緒に確認できる資料を用意する方法があります。ただし、資料を整理したことを、内容の正しさや利用許可の確認の代わりにはしません。
依頼文を運用に載せる前には、資料がそろった場合、契約情報が欠けた場合、期限だけが短くなった場合の三通りで出力を比べてみます。確認できる部分は進み、不足は隠れず、期限を理由に許可範囲が広がっていなければ、優先順位の方針が実際の判断に結び付いていると確かめられます。
最初に決めたいのは、抽象的な優先順位の標語ではなく、この仕事で保持する事実、変更してよい部分、確かめられなければ保留する点です。短時間で直せる表現には軽い確認を使い、顧客の判断を変える金額には適用条件までの照合を加える。その違いを依頼と作業の仕組みの両方へ反映させます。同じ作業でも影響や機密性によって確認の厳しさをどう変えるかは、AIの確認をどこまで厳しくする？ 同じ作業でも変わるリスクの見方で詳しく扱っています。
追加指示による会話の状態変更と競合の解決は「追加指示で何を変えるか 会話の状態管理と競合解決の基本」で解説しています。
急ぐ仕事で確認をどこまで省けるかは「AI業務の安全性・正確性・速度の使い分け――確認を省ける作業と省けない作業」、「一語で」などの形式指定と正確さが衝突した場合は「安全性・正確性・形式指定が衝突したら、AIにどう答えさせるか」で解説しています。
基本から確認する：この記事の前提になる考え方は、「プロンプトの書き方ガイド（依頼文の基本6項目と例文）」にまとめています。
