AIエージェントへ最初から広い権限を渡す必要はありません。閲覧、下書き、承認後実行、自動実行の順に分け、誤りが社外や基幹データへ届く一歩手前に人の承認を置きます。止める条件と記録方法まで決まらなければ、自動実行には進めません。
たとえば、問い合わせメールを読んで担当部署を選ぶ処理と、顧客へ返信する処理は同じではありません。前者が外れても担当者が直せますが、後者で価格や納期を誤れば、そのまま取引先へ届きます。承認者が出張中の午後、AIエージェントが未確認の返信を20件まとめて送る――避けたいのは、モデルの間違いだけでなく、不在時に止まれない運用です。
AIエージェントの四段階の権限と停止。画像を押すと拡大できます
AIエージェントの権限は、何段階に分ければよいか？
閲覧、下書き、承認後実行、自動実行の四段階に分け、業務ごとに開始位置を決めます。
「AIを導入するか」ではなく、どの動作まで許すかを決めます。同じ問い合わせ対応でも、メールを読む、分類候補を出す、返信案を作る、送信する、顧客台帳を更新する、では影響が異なります。
| 権限段階 | AIエージェントができること | 人が行うこと | 最初に向く業務 |
|---|---|---|---|
| 閲覧 | 指定した情報を読み、要点を示す | 情報の採否を判断する | 社内規程の検索、案件要約 |
| 下書き | 分類候補や文案を作る | 修正して実行する | 返信下書き、日報案 |
| 承認後実行 | 承認された操作だけ実行する | 宛先・金額・変更内容を承認する | 定型メール、台帳更新 |
| 自動実行 | 条件内の処理を連続実行する | 例外確認と定期監査を行う | 低リスクな転記、通知 |
権限はシステム全体へ一括で付けません。「顧客台帳を閲覧できるが更新できない」「下書きは作れるが送信できない」のように、対象データと動作を組み合わせます。
AISIのAIセーフティに関する評価観点ガイド第1.20版は、AIエージェントの自律性と外部連携の程度に応じて評価する視点を示しています。社内の個人利用と、外部とのやりとりを代行する利用では、同じ管理にしないという整理です。
人の承認は、どの操作の前に残せばよいか？
社外送信、金銭、契約、権限変更、基幹更新など、取り消しにくい操作の直前に残します。
承認画面には「実行しますか」だけを出しても判断できません。宛先、変更前後、根拠に使った情報、実行後に戻せるかを並べます。見積金額を顧客へ送るなら、金額だけでなく、対象案件、適用した価格表、納期回答の根拠まで同じ画面で確認できるようにします。
承認者も役職名だけでは足りません。通常承認者、代理承認者、保留できる時間、期限切れ後の扱いを決めます。承認待ちを自動承認へ切り替えるのではなく、期限を過ぎたら処理を取り消すか、上位者へ回します。
AI事業者ガイドライン第1.2版は、経営層がAIガバナンスの方針を定め、運用状況をモニタリングする枠組みを示しています。現場担当者だけに「問題が起きないよう見ておいて」と預けず、どのリスクを誰が引き受けるかを経営判断として残します。
どんな条件でAIエージェントを止めるべきか？
権限外の操作、判断材料の不足、件数急増、連続失敗を検知した時点で処理を止めます。
停止条件は「異常があれば止める」では動きません。対象を数えられる条件にします。
- 許可していない顧客データや外部サービスへアクセスしようとした
- 必須項目が欠け、参照元を特定できない
- 同じ処理が連続して失敗した
- 通常の時間帯や件数から外れた一括処理が始まった
- 人が修正した割合が社内で決めた基準を超えた
- 利用するAIモデル、連携先、業務ルールが変更された
止めた後の手順も必要です。未実行の処理を保留し、担当者へ通知し、再開には別の承認を求める。顧客台帳を書き換える処理なら、変更前の値から戻せるようにします。
AISIの同ガイドは、設計書や権限設定の確認だけでなく、実環境に近いテストでログ、異常時の人の介入、停止機能が実際に働くかを確かめるよう示しています。停止ボタンが画面にあるだけでは、確認したことになりません。
監査ログには、何を残せば後から判断できるか？
入力、参照元、判断結果、実行内容、承認者、変更前後を一つの処理IDでつなぎます。
会話全文を保存しても、「なぜこの顧客の住所が変わったか」が追えなければ監査には使えません。最低限、次を残します。
| 残す項目 | 後から確かめること |
|---|---|
| 処理ID・日時 | 一連の操作を同じ案件として追えるか |
| 入力・参照元 | どのメール、文書、マスタを使ったか |
| AIの出力・確信度 | 何を候補として出したか |
| 呼び出した機能 | 送信、更新、検索のどれを行ったか |
| 変更前・変更後 | 元に戻すための値があるか |
| 承認者・承認時刻 | 誰が何を見て許可したか |
| 実行結果・失敗理由 | 完了、保留、取消を区別できるか |
| モデル・ルール版 | 後日の変更と切り分けられるか |
保存期間は一律に決めず、元の業務記録に合わせます。契約、会計、個人情報など既存の保存規程があるなら、AIエージェントのログだけ別扱いにしません。不要なメール本文や個人情報まで無期限に残すのも避けます。
NISTが公表するAI RMF Coreは、人とAIの役割、監督方法、責任、継続監視を文書化する枠組みを示しています。ログは保存することが目的ではなく、人が判断を検証し、改善や停止へつなげる材料です。
現場では、承認者が不在の場面をどう設計するか？
代理者、保留期限、期限後の取消を決め、不在を理由に自動実行へ切り替えない設計にします。
月末最終営業日の16時、営業部長が外出し、値引き回答の下書きが12件たまっている場面を考えます。AIエージェントが止まらない設計では、「承認待ちを解消するため自動送信する」という危ない近道が生まれます。
この場合は、通常5%を超える値引きは営業部長、部長不在時は事業責任者、17時まで承認されなければ翌営業日へ保留、と業務ルールにします。緊急対応が必要なら、AIの権限を広げるのではなく、代理承認の連絡経路を用意します。
社内では、導入前に何を決めておくべきか？
対象業務、禁止操作、承認者、停止条件、ログ保存、事故時の連絡先を導入前に書面で決めます。
初回の社内確認では、次の七つを1枚にまとめます。
- AIエージェントへ任せる一つの業務
- 読めるデータと、読ませないデータ
- 実行できる操作と、禁止する操作
- 通常承認者と代理承認者
- 自動停止する条件
- ログの保存項目と保存期間
- 誤送信や誤更新が起きたときの連絡と復旧
ここで「自動実行にする理由」が、担当者の確認時間をなくしたいだけなら一度止まります。承認をなくした後に誰が例外を見るのか、事故時に戻せるのかが決まらない限り、下書きまたは承認後実行のまま使うほうが安全です。
開発会社へは、どんな情報を渡せばよいか？
業務の実例、権限表、承認経路、停止条件、連携先、復旧方法を一組にして渡してください。
完成した仕様書は不要です。匿名化したメールや台帳を数件、誰が何を判断しているかを書いたメモ、連携したいシステム名を用意します。要件書がなくてもシステム開発を相談できるか？で挙げた7項目に、今回の権限表と停止条件を足せば、相談を始められます。
開発会社には、通常系のデモだけでなく、承認者不在、参照元欠落、連携先停止、一括処理の途中停止を試してもらいます。AIの回答精度だけでなく、誤ったときに止まり、戻せるかを受入条件へ入れてください。
関連記事と相談先は、どこから確認できるか？
発注準備は要件整理の記事、実装範囲はAI開発ページ、個別相談は問い合わせへ進めます。
Heygoodは、自動実行を前提に提案しません。実際のメール、帳票、承認経路を見て、下書きで止める業務と、条件付きで実行まで任せられる業務を分けます。権限表と停止条件を一緒に作るところから相談できます。