INSIGHT
下書きが役立った。そのまま送信・更新の権限をAIに渡してはいけない
回答がよかったことを、送信や更新まで任せる根拠にしていないか。
問い合わせへの返信案がよくできている。担当者は数か所直すだけで送れる。「この品質なら、次は送信まで任せよう」。さらに、顧客台帳の更新や在庫の変更も自動化したいという話が出る。
作った仕組みに送信・更新の接続を足す前に、その権限拡大を止めて確認してください。作成者が接続を設定できることと、会社の情報を送信・変更する許可があることは別です。
下書きの良し悪しと、正しい相手へ、許された操作だけを、正しい時点に実行できるかは別の評価です。回答の品質を、送信・更新・削除を許す根拠へ置き換えてはいけません。
「できること」を四段階へ分ける
一つの業務画面でも、AIが持つ権限の重さは違います。
- 読む：文書、顧客情報、履歴を取得する。
- 作る：返信文、登録内容、変更案を作る。
- 確定する：人が承認した内容を送信・更新する。
- 管理する：権限、連携、削除、設定を変える。
返信案が役立ったという試験で確認できたのは、主に二段階目までです。三段階目へ進むには宛先、添付、時点、重複、取消しを試す必要があります。四段階目は一件の業務を越えて他の利用者や仕組みに影響するため、日常の自動処理から外して考えます。
実行権限とは、AIが外部の仕組みへ要求を出し、相手への連絡や会社の記録を変えられる範囲です。社内の台帳であっても、対象や金額を誤れば影響は残ります。接続先が社内か社外かだけで重さは決まりません。
OWASPのTop 10 for Agentic Applications 2026 は、ツール、権限、依存先、複数のエージェント間連携など、行動できるAIの論点を整理しています。個別事故の頻度や、自社設計の合格を示す資料ではありません。権限の種類を洗い出す補助として参照できます。
権限一覧は、許可より先に上限を書く
「メールを送れる」と書くだけでは広すぎます。誰の依頼で、どの宛先へ、どの種類の本文と添付を、何件まで、いつ送れるのか。台帳更新なら、対象の表、変更できる項目、件数、金額、時間帯を決めます。
一覧には「できないこと」も書きます。新規宛先への送信はしない。指定額を超える更新はしない。削除と権限変更はしない。根拠がない案件は確定しない。上限を越えた結果は、人へ戻します。
そのうえで、実際にAIへ渡す権限も一覧の範囲へ縮めます。文章で禁止するだけで、接続先では実行できる状態を残せば、一覧は希望にとどまります。承認時だけ一時的に許す、対象を一件に絞る、管理操作の接続を分けるといった方法を、採用する仕組みの仕様に合わせて管理担当と選びます。接続に失敗したからといって、自分の判断で強い権限を足してはいけません。
承認画面の約束と、接続先で実際に使える権限を一致させます。
承認者には、判断材料と差し止める力が要る
「人が最後に確認する」と決めても、完成した本文しか見えなければ、誤った宛先や変更対象を見落とします。承認画面には、対象、宛先、内容、添付、変更前後の差分、根拠、例外を、業務時間内に読める形で示します。
承認者は、修正を提案するだけの人ではありません。送信や更新を実行前に差し止め、根拠不足を保留へ戻せる必要があります。処理件数が確認時間を超えるなら、件数や対象を減らします。承認ボタンを置いたという事実だけでは、確認が成立したことになりません。
承認した後に宛先や添付が変わるなら、その承認は変更後の送信には使えません。「確認した内容」と「実際に送る内容」を結び付け、変更時には承認へ戻す。この条件も、画面と接続先の両方で確かめます。
試験は通常の一件だけで終えません。誤った顧客を指定する、同じ依頼が二度来る、接続先の応答がない、途中で停止する、実行後に訂正が必要になる。このとき、実行前に止められるか、実行後の状態を追えるか、取消しや訂正ができるか、誰へ連絡するかを記録します。
公表事例は、禁止文より権限を見る材料にする
Replitは2025年7月21日、開発用と本番用のデータベースを分離する対応を公表 しました。同月29日の公式説明 では、利用者のアプリでエージェントがデータを削除したこと、最終的には復元できたこと、分離前には開発中の変更が本番へ影響し得たことを説明しています。操作の全経緯を立証する資料ではありませんが、開発と本番の境界を確認する材料になります。
この資料だけで、全社のデータベースが失われた、永久に復旧できなかった、現在も同じ仕様である、どのAIも同じ操作をすると結論づけることはできません。利用者による報告の全経緯も、この一資料だけでは確定できません。
ここで持ち帰れるのは、「削除しない」と指示することと、削除できない権限にすることは違う、という確認の視点です。禁止文は方針を伝えます。権限、実行前の承認、履歴、復元が、影響を抑える仕組みになります。
AISI（AIセーフティ・インスティテュート）のAIセーフティに関する評価観点ガイド は、エージェントの観測と制御、権限、実行履歴、介入・停止を評価項目の例に含めます。認可や安全を保証する資料ではありません。自社の用途で、見えること、止められること、追えることを試す観点になります。
次の連携を足す前に、読む権限と実行する権限を分ける
送信や更新をつなぐ前に、次の四点を確認し、業務上の実行範囲と権限付与を認める担当者へ渡します。
- 操作ごとに、読める情報、作れる案、確定できること、禁止することが書かれている。
- 承認者が対象、内容、時点、差分、例外を見て、実行前に止められる。
- 通常時と異常時で、停止、取消し・訂正、履歴、連絡を試している。
- 権限の追加と変更を承認する人、見直す時期、問題時に縮小する人が決まっている。
不足があれば、読む・下書きを作る段階へ戻し、確定操作は既存の手順で行います。確認できた仕事まで捨てる必要はありません。再開は「よく働いた」ではなく、任せる対象、上限、承認、停止を証拠で説明できたときに決めます。
読む権限と実行する権限を分け、付与を決める担当者へ渡す
次の連携を足す前に、読むだけの権限と、書く・送る権限を別々に確認してください。必要な対象、上限、承認、停止方法を書き出し、付与を決められる担当者へ渡します。下書きが役立ったという成果を、そのまま実行権限を増やす理由にしないでください。