- 公開日
AIがメールを送る、資料を公開する、商品を購入するときは、対象・内容・費用などの条件を揃え、その操作を許可できる人に承認を求めます。承認ゲートとは、承認した対象・内容・条件を満たす操作だけを実行へ進める制御です。画面に確認ボタンを置くだけで終えず、実行前に条件を照合し、実行後も承認した内容と結果を対応させます。
この記事では、送信・公開・購入などに共通する承認の考え方を扱います。メール送信に特有の確認点は「AIによるメール送信を安全に設計する」、送信の役割分担は「AIの送信をどう制御する？ 指示・システムの強制・人間承認の役割」で扱います。
「作る」から「外へ出す」境目を見つける
ここでいう副作用は、AIの回答以外に生じる変更や影響です。送信先への情報開示、公開範囲の変更、料金の発生、予約の確定、既存データの削除などが含まれます。望んだ効果であっても、外部へ作用する点では管理対象になります。
例えば「公開用の紹介資料を作って」という依頼には、文章の作成と外部公開の両方が含まれるように読めます。下書きの内容を承認したことが、誰でも見られる場所への公開まで許可したことになるとは限りません。依頼を受けたら、資料を作る場所、共有先、公開の有無を分け、どこまで任されているかを確かめます。
作業名だけで影響を判定することも避けます。「保存」でも共同フォルダーに入れれば他者が閲覧できることがあり、「確認」でも入力した資料が外部サービスへ送られる場合があります。利用する機能が何を読み、どこへ送り、何を書き換えるのかを、機能仕様と実際の設定から確認します。
OWASPのLLM06:2025 Excessive Agencyは、過剰な機能・権限・自律性を分け、必要な機能と権限に絞ることや、高影響の操作に人の確認を置くことを示しています。これはすべての操作に同じ確認を課す法令ではなく、危険の種類に応じて制御を選ぶためのガイダンスです。
承認前に、対象と影響を一組にする
「この内容でよいですか」だけでは、文章の確認なのか、公開の許可なのかが曖昧です。判断者に示す情報は、その人が許可する操作に合わせてまとめます。
- 対象と版：どの文書、注文、予約を扱うか。名前だけでなく識別子と版も示す
- 内容と操作：何を送る、公開する、変更するか。変更前後がある場合は差分を示す
- 実行先と主体：誰が見られる場所へ、どの組織やアカウントの権限で実行するか
- 費用と制約：金額・通貨、税や手数料、継続課金の有無、実行回数など、判断を左右する条件
- 取り消し範囲：取り下げられる操作と、外部へ渡った後は回収を保証できない情報
費用がないことも、確認できた条件として書きます。未確認の料金をゼロとしないよう、「追加料金なし」と「料金未確認」を区別します。また、文書を見る権限がある人に、外部公開を承認する権限もあるとは限りません。組織の規程や役割に照らし、対象の公開を許可できる人を選びます。
OWASPのTransaction Authorization Cheat Sheetは、利用者が重要な取引データを確認できること、承認と実行の順序を守ること、内容の変更への対策や実行直前の制御を扱っています。主に取引を想定したセキュリティ設計の参考であり、通常の文書公開にも銀行取引と同じ法的要件や認証方式が必要だという意味ではありません。以下は、その考え方を資料公開へ具体化した設計例です。
架空の資料公開で、承認の範囲を確かめる
架空の広報チームが、製品紹介資料を公開するとします。元の依頼は「紹介資料を整え、公開できる状態にしてください」です。AIには社内の非公開作業領域で下書きを作る範囲だけが許可され、外部公開には広報責任者の承認が必要という運用を仮定します。実際のサイト操作は行わない説明用の例です。
資料の内容には未公開の顧客名を含めず、掲載許可を確認した図版を使う前提にします。この確認が欠ければ、体裁が整っていても公開承認へ進めません。資料の正確さや公開可能性の確認と、公開という操作の許可を分けて考えます。
| 承認する事項 | この例で確定する内容 |
|---|---|
| 操作・対象 | 資料D-42の版3を、新規に1回公開する |
| 公開する内容 | 「製品紹介.pdf」全8ページ。本文と図版は版3に固定 |
| 公開先・閲覧者 | 自社の公開資料ページ。ログインなしで閲覧可能 |
| 実行主体・判断者 | 広報用アカウントで実行。公開権限を持つ広報責任者が判断 |
| 費用 | 契約確認済みの既存掲載枠を使い、この公開による追加料金は0円 |
| 取り消し範囲 | 自社ページの掲載を取り下げられるが、閲覧者が保存したコピーの回収は保証しない |
責任者が「版3を記載の公開先へ1回公開してよい」と判断したら、対象と操作を含む承認記録を残します。単なる「確認済み」では、対象も操作も後から分かりません。版3の下書きを読んだ記録と、版3の外部公開を許可した記録を区別します。
次に、資料ID、公開先、費用は同じまま、図版の差し替えで版4になった場合を考えます。版3への承認を流用せず、実行を止め、変更内容を示して版4の公開可否を確認します。修正したのが正当な担当者でも、承認時とは内容が異なります。
版3のままでも、公開先を自社ページから登録者へ自動配信する外部サービスへ変えるなら、掲載に加えて配信が生じるため再確認が必要です。逆に、非公開作業領域で見出し案を並べるだけなら、この例の作業許可の範囲で進められます。外部公開のための費用確認画面を毎回出す必要はありませんが、その作業領域の共有設定や資料の利用権限まで不要になるわけではありません。
承認を軽くできるかは、操作の名称ではなく、影響と既に与えられた許可の範囲で判断します。機密情報を含む、費用が増える、取消不能な配信を伴うといった条件が加わるなら、追加の確認事項や担当者を決めます。前の許可がどこまで有効か分からない場合は、広く解釈して実行せず、曖昧な部分を確認します。
実行結果も、同じ対象へ戻して確認する
承認後は、実行する側で対象・版・公開先を照合します。実行結果に公開ページの識別子が返った場合は、D-42の版3に対応する公開物か、閲覧範囲は承認どおりかを確認して記録します。「完了」という文字だけでは、別の資料を公開した可能性を見分けられません。
この例の記録は、操作ID、承認者と承認時刻、承認した資料IDと版、公開先、実行時刻、返却された公開物ID、照合結果を結び付ける形にします。記録には必要な情報を残し、機密の本文や認証情報を無制限に複写しない設計も必要です。
応答が返らなかった場合は、「公開に失敗した」としてすぐやり直しません。Making retries safe with idempotent APIsが説明するように、応答を受け取れなくても外部の変更が済んでいることがあります。この例では操作IDや対象の公開状態を照会し、公開済み、処理中、未実行の確定、結果不明を分けます。確認できない間は再公開を保留し、担当者へ引き継ぎます。
公開後の取り下げも別の操作です。取り下げを依頼しただけで、掲載が消えた、既に保存されたコピーも消えたと報告してはいけません。どこまで戻せたかを確認し、戻せない影響があればその範囲を伝えます。
人の判断と、システムの制御を組み合わせる
人が内容を承認しても、実行アカウントの権限不足や失効が解消するわけではありません。実行時の認可、つまりその主体がその対象を操作してよいかの判定は、下流サービスでも行います。前掲のOWASP Excessive Agencyも、下流システムでの認可を重視しています。
AIが案と確認材料を整理し、承認者が内容と影響を判断します。実行側は承認内容との照合と権限確認を行い、その結果を記録へつなぎます。承認済みの印や、データの形式を定めるスキーマに合ったことだけで、この役割分担を代替することはできません。
導入時には、普段の一つの業務について「どこで外部へ影響するか」を書き出し、下書きの許可と実行の許可を分けるところから始められます。確認回数を増やすだけでなく、判断に必要な対象・内容・費用・取り消し範囲が見えるか、変更や不明点があれば実行を止められるかまで確かめてください。
AIに購入や決済を代行させるときの金額上限と取消は「AIの購入・決済代行を設計する：金額上限と支払権限、取消の扱い」で解説しています。
AIを使う前に確かめる12項目は「AIを使う前の安全確認チェックリスト」にまとめ、記入用のAIKYシート（PDF・Excel）も配布しています。
基本から確認する：この記事の前提になる考え方は、「AIエージェントの安全設計（権限・外部資料・承認・検証の基本）」にまとめています。
