- 公開日
AIへ仕事を任せる直前には、依頼文が整っているかだけでなく、使う材料、入力の許可、実行権限、外部への影響、結果の確かめ方を確認します。必要な項目に「いいえ」や「未確認」が残ったら、その項目が関係する処理を止め、照会するか、許可された範囲へ仕事を縮めます。
たとえば顧客メールで、宛先を確認できても、添付ファイルの入力可否や送信権限まで確認できたことにはなりません。使ってよい公開情報だけで下書きを作り、添付と送信は保留する、といった判断が必要です。以下の表は、この判断を項目ごとに残すための実務用のたたき台です。
AIを使う前の安全確認を習慣にする考え方は、AIKY（AI利用における危険予知）で説明しています。
点検する仕事と、四つの判定を固定する
最初に、依頼の対象、使うサービス、参照資料、実行する操作を一つの記録へまとめます。「顧客対応全般」では広すぎるため、「既存顧客への製品更新案内を下書きする」「承認済みメールを指定の宛先へ送る」のように区切ります。下書きと送信は、別の処理として点検します。
表を埋める前に、任せる範囲（下書きまでか、更新・送信までか）、入力してよい情報か、接続するツールの権限、出力を確かめる人と資料の四点で全体をつかむと、どの行に時間がかかりそうかが見えます。ただし、この四点だけで開始してよいと判断するものではありません。
各行の判定は、次の意味で使います。
- はい：その行で定めた資料・方法による照合を終え、確認命題に合っています。
- いいえ：照合を終え、確認命題に合っていないと分かっています。NGとして扱います。
- 未確認：必要な資料がない、閲覧できない、担当者の判断がまだないなど、照合を完了できません。
- 対象外：その確認項目が、現在点検する仕事に関係しません。関係しない理由を残します。
「問題を見つけていない」は、照合済みの「はい」と同じではありません。「たぶん大丈夫」も「未確認」です。後で行う予定の確認を、先に「はい」にすることもしません。また、資料に説明があるかと、その説明が現在の事実に合うかは別の命題です。たとえば古い名簿にメールアドレスがあれば「名簿に記載がある」は「はい」でも、「今回の正しい送信先である」は別途確認が必要です。
表の「判定」欄（「記入」と書いた箇所）には四つから一つを選び、資料の識別情報、確認日、確認者、理由を添えてください。点検前の空欄を一括で「対象外」にせず、確認待ちであることが分かる状態にします。これらの表は安全性や適法性を認証するものではなく、案件固有の条件を確認するための提案です。
目的と入力資料を点検する
入力の可否は、AIへ送る前に確認します。原文を渡してから秘密情報を消すよう頼んでも、その送信を取り消したことにはなりません。OWASPの「LLM02:2025 Sensitive Information Disclosure」は、入力検査、機密情報への最小限のアクセス、データ利用の説明を対策に挙げています。表では、その考え方を実際の資料とサービスへ対応させます。
| 確認命題 | 確認資料・方法 | 判定 | いいえ・未確認の場合の対応 |
|---|---|---|---|
| 1. 目的と任せる作業が、依頼者の意図に合っています | 依頼原文と作業一覧を照合し、作成・検索・更新・送信のどこまで頼まれたかを確認します | 記入 | いいえ：作業範囲を修正します。未確認：結果を変える不明点を依頼者へ確認します |
| 2. 必要な材料と、その対象・版・時点が揃っています | 使用資料一覧を作り、原本の版、対象製品、適用日、必要な添付の有無を確認します | 記入 | いいえ：対象違いや旧版を除き、適切な資料へ置き換えます。未確認：資料の入手まで依存する回答を保留します |
| 3. 答えに使う重要な事実を、資料の該当箇所が裏付けています | 日時、金額、仕様、約束ごとを抜き出し、資料の文章や表へ一件ずつ対応させます | 記入 | いいえ：裏付けのない断定を外します。未確認：該当主張を未確認と表示し、確定情報として使いません |
| 4. 入力する情報を、そのサービス・アカウント・用途で扱う許可があります | 情報区分、契約や社内規程、利用条件、保存・学習の設定を実際の利用経路と照合します | 記入 | いいえ：入力を止め、認められた材料や経路へ変更します。未確認：情報管理者等へ照会し、確認前には送信しません |
| 5. 資料内の命令が、依頼者の指示として扱われない構成です | 依頼と引用資料を分け、資料内の操作要求が権限判断へ流れ込まないか、渡す内容と接続機能を確認します | 記入 | いいえ：資料の区分と操作範囲を修正します。未確認：外部操作を無効にした範囲へ縮め、構成を確認します |
1では「良い感じに対応する」を具体的な作業へ分けます。依頼にない顧客への連絡や資料の共有を、仕事を進める都合で追加しないようにします。目的を確認しても、使用するアカウントや送信先まで決まるわけではないため、後の項目も必要です。
2と3はまとめずに判定します。最新版の資料を持っていることと、書こうとしている主張の裏付けがあることは異なります。資料が「公開日を調整中」と述べているなら、その記載は確認できますが、具体的な公開日が確定しているとは言えません。
4では「機密区分が書かれていないから公開情報」と判断しません。文書の内容、提供元の条件、利用するサービス側の扱いを確かめます。削除や一般化で入力範囲を縮める場合も、その加工を許可された環境で行い、加工後の情報に禁止対象が残らないかを確認します。
5は、区切り記号があれば無条件に合格する項目ではありません。たとえば見積書中に別の宛先への送信要求があっても、それを資料の内容として扱い、依頼者の権限や承認の代わりに使わないことを確認します。構成上の確認と、実際の試験結果があるかも記録では分けます。
権限と外部への影響を点検する
アクセスできることと、今回の仕事で使ってよいことは別です。OWASPの「LLM06:2025 Excessive Agency」は、必要な機能・権限への限定、人による高影響操作の承認、下流システムでの認可を対策として示しています。依頼文に「送信して」とあっても、実行する主体の権限を省略してよいわけではありません。
| 確認命題 | 確認資料・方法 | 判定 | いいえ・未確認の場合の対応 |
|---|---|---|---|
| 6. 実行主体に、予定する操作・対象への権限があります | 実行アカウント、権限設定、対象データの利用範囲、委任記録を照合します。接続できるだけでは合格にしません | 記入 | いいえ：その操作を止め、権限のある担当者へ引き継ぎます。未確認：設定と委任の確認まで実行しません |
| 7. 宛先・対象物・処理する範囲が、今回の依頼と一致しています | 現行の顧客台帳や本人との確認記録、ファイル識別情報、対象件数を照合します | 記入 | いいえ：正しい対象へ修正して再確認します。未確認：似た名前や古い宛先で代用せず、対象の確定を待ちます |
| 8. 外部送信・更新・公開などの影響と、取り消せる範囲が把握されています | 操作仕様、共有範囲、変更前後の差分、通知の発生、取消手段を確認します | 記入 | いいえ：影響範囲を整理し直します。未確認：外部操作を保留し、仕様または管理者へ確認します |
| 9. 必要な承認が、対象・内容・宛先・版に対応しています | 業務の承認ルールと承認記録を読み、承認者の権限、条件、有効範囲、承認後の変更を照合します | 記入 | いいえ：承認対象を揃えて差し戻します。未確認：承認済みと推定せず、必要な判断を依頼します |
6の権限不足を、広い権限のアカウントへ切り替えることで勝手に解消してはいけません。下書きだけを認められているなら、下書きができる範囲で止めます。権限を追加するかどうかは、管理者が必要性と影響を判断する別の作業です。権限の確認は「プロンプトに禁止と書いた」で代用できません。実行側で権限を検証する考え方は、AIの脅威モデリングとは？ データからツールへ届く経路を点検するで扱っています。
7では、宛先の表示名だけでなく、今回の送付先を識別できる情報を確認します。ファイルの場合も似た名前が並ぶことがあるため、版や対象案件を合わせます。確認した対象が後から差し替わったら、その行の以前の「はい」を引き継がず、差分を照合します。
8では、文章の保存だけでも共有フォルダーへの保存なら他者に見える可能性を考えます。外部メールは送信後に回収できると決め付けず、受信者が既に読んだり転送したりする影響も踏まえて扱います。取消機能の有無が不明なら、取り消せる前提で実行しません。
9の承認は、文章が表示されたことや確認画面を開いたことでは判断しません。誰が、どの版と送信先について、何を認めたかを確認します。承認後に添付や金額を変えた場合は、変更部分を含めて必要な判断へ戻します。
完了条件と、止めた後の処理を点検する
着手前には、結果をどう照合するかを決めます。この時点で検査手順が決まっていても、まだ生成していない回答や実行していない操作が合格したことにはなりません。出力を他のシステムへ渡す場合の検証の必要性は、OWASPの「LLM05:2025 Improper Output Handling」でも示されています。
| 確認命題 | 確認資料・方法 | 判定 | いいえ・未確認の場合の対応 |
|---|---|---|---|
| 10. 完了と判断する条件と、結果の照合方法が決まっています | 必要な出力項目、原資料との照合対象、数値・形式の検査、確認担当者を作業票へ記します | 記入 | いいえ：完了条件と検査を具体化します。未確認：判断できる担当者へ確認し、確定版の利用を保留します |
| 11. NG・情報不足・結果不明のときの停止先と照会先が決まっています | 保留する操作、続行可能な部分、照会相手、再開に必要な証拠を作業票で確認します | 記入 | いいえ：停止・照会・範囲縮小の行き先を追加します。未確認：責任者を確認するまで影響のある処理を止めます |
| 12. 外部操作の結果を、実際の状態で確認する方法があります | 対象サービスの処理履歴、受付識別情報、変更後の画面、状態照会の方法を確認します | 記入 | いいえ：結果を追えない操作は保留します。未確認：照会手段を確かめ、応答がないだけで成功・失敗を決めません |
10では、メールの下書きなら「依頼した要点がある」「原資料にない約束を加えていない」「宛先向けに使える文体」「人が未確認点を把握できる」などを定めます。JSONや表へ整形できたことと、内容の正しさや送信の許可は別に確認します。
11では、すべてを止める必要があるのかを考えます。未確認の添付を使わずに、許可済みの情報だけで成立する下書きを作れるなら、その範囲は進められます。ただし、添付の内容が結論に不可欠なら、推測で穴を埋めず、添付の確認を待ちます。
12は、外部操作を行わない下書きだけの仕事なら「対象外」にできます。後から送信まで任せる場合には、改めて対象になります。送信要求への応答が途切れたときは、結果不明として対象サービスの状態を照会する手順を定め、確かめる前に同じ操作を繰り返さないようにします。なお、ツールを接続しない文章作成でも、文章をAIサービスへ入力すること自体の情報の扱いは残ります。送信ツールを使わないことを、外部へ情報が渡らないことと同じ意味にはしません。
顧客メールの依頼を、実際の判定へ落とす
ここからは架空のケースです。担当者が「既存顧客へ製品更新の案内メールを作り、この資料を添付して送ってほしい」と依頼したとします。現在のAI環境で認められているのは、確認済みの情報を使った下書きの作成までで、メール送信の権限はありません。
現行の顧客台帳と今回の依頼から宛先は確認できています。製品の公開案内には「利用ガイドを更新した」「変更点を公開ページで確認できる」と記載されています。この公開案内は、選んだAIサービスへの入力とこの用途での利用が認められていると確認済みです。一方、添付予定の社内資料は機密区分も外部提供の可否も未確認で、AIへまだ入力していません。
この段階では、同じ「メール作成」の中でも結果を分けます。
| 照合する命題 | 確認資料・方法 | この例の判定 | 次にすること |
|---|---|---|---|
| 今回の送付先が特定されています | 現行顧客台帳と今回の依頼を照合済み | はい | 下書きの対象は確定。ただし送信可の判定には使いません |
| 公開案内は利用ガイド更新を裏付けています | 公開案内の該当箇所を確認済み | はい | 記載された範囲を下書きに使います |
| 添付予定資料を選定済みAIサービスへ入力する許可があります | 機密区分と入力条件を示す記録が未入手 | 未確認 | 入力を保留し、資料の管理者へ照会します |
| 添付予定資料を今回の顧客へ提供する許可があります | 外部提供条件を示す記録が未入手 | 未確認 | 添付を保留し、提供先と用途を管理者へ示して確認します |
| AIの実行主体にメール送信権限があります | アカウントの権限設定は下書きのみ | いいえ | AIによる送信を止めます。権限のある担当者へ引き継ぐ条件を整えます |
| 金額と税の計算を確認する必要があります | 依頼と公開案内に金額の記載がありません | 対象外 | 今回の下書きの計算点検には加えません |
| 下書きの内容を公開案内と照合する方法があります | 担当者が主張ごとに該当箇所を対応させる手順を用意 | はい | 作成後に照合します。下書きそのものの合格はまだ未確認です |
添付の入力許可と外部提供許可は別の行で判定しています。実案件で一方だけ確認できた場合も、もう一方の未確認を残します。宛先が正しいという「はい」を使って、未確認の添付や権限不足をまとめて合格にしないことが大切です。
許可された作業を明確にする依頼文は、次のようにできます。
入力可と確認済みの公開案内だけを使い、顧客向け案内メールの本文案を作成してください。
伝えるのは利用ガイドの更新と、公開ページで変更点を確認できることです。
添付予定資料は参照も入力もせず、その内容を推測しないでください。
宛名とリンクは担当者が確認した情報を後で設定します。
送信は行わず、本文案と確認待ち事項を分けて返してください。期待する本文案は「利用ガイドを更新しました。変更点は公開案内をご確認ください」のように、公開情報で裏付けられる範囲です。担当者向けには「添付の利用可否は未確認、送信権限なし、未送信」と別に示します。「資料を添付しました」「送付しました」と、実行していないことを書かせません。
この案は実際の送信結果ではありません。作成後には担当者が公開案内と照合し、宛名、リンク、表現を確認します。添付を使わなくても今回の目的に必要な案内が成立するかを依頼者へ確認し、範囲変更で目的を満たせないなら下書きの確定も保留します。
NGと未確認を、再開できる記録に変える
点検結果は「何項目中何項目が合格したか」だけで集計しません。送信権限がないという一項目は、他がすべて「はい」でも解消しません。次の三つの処理を、影響する項目に割り当てます。
- 停止：権限不足、禁止された入力、無承認の外部操作などが確認された場合は、その操作を行いません。
- 照会：必要な資料や判断が不足する場合は、何を、誰に、どの根拠で確かめるかを記録します。
- 範囲縮小：確認済みの材料と権限だけで意味のある成果が出せる場合は、その範囲を明示して進めます。
判定結果から、続ける・縮める・人に確認する・止めるのどれを選ぶかという考え方は、LLMのガードレールとは？ 効かない原因と対策、拒否・縮小・人間確認の使い分けで整理しています。
再開記録には、対象作業、保留した理由、現時点でできること、確認先、再開条件、未実行の操作を残します。顧客メールなら「本文案のみ作成。添付は資料管理者が入力可否と顧客への提供可否を確認するまで保留。送信は権限のある担当者が本文・宛先・添付を確認後に行う」と整理できます。
再開するときは、新しい資料や承認がどの未確認事項を解消したかを照合します。資料の区分が分かっただけで送信権限が増えるわけではなく、権限が得られても添付の利用許可が不要になるわけではありません。変更された対象や版に合わせて必要な行を再点検します。
この表だけでは判断できない仕事を見分ける
このチェックリストは、業務の着手前に不足を見つけるための共通の入口です。契約上の解釈、個人への重大な影響、大きな金額の確定、取り消せない削除、実機の操作などを含む場合は、対象分野の規程や専門的な確認を追加します。該当する条件を確かめられないまま、表を埋めたことを実行許可にしないでください。
点検の負担を抑えるには、毎回同じサービス条件や手順を確認できる記録へまとめ、今回変わった資料・対象・権限・出力を重点的に照合します。ただし、古い確認を使うときは、有効な版と適用範囲が今回にも合うかを見ます。
最後に、AIの完了報告と実際の状態を対応させます。下書きなら保存された本文、更新なら変更後の対象、送信なら対象サービスの送信状態を確認し、確認できない部分は未確認のまま伝えます。着手前の点検と結果の照合がつながって初めて、何を任せ、どこで止め、何が終わったかを説明できます。
AIを使う前と出力を使う前に確かめる項目を短くまとめた版は、「AIを使う前の安全確認チェックリスト」に掲載しています。記入用のAIKYシート（PDF・Excel）も配布しています。
任せる前に押さえる考え方を5つにまとめた版は「AIに仕事を任せる前に押さえたい5つの原則」で解説しています。
