AIエージェントの承認フローは閲覧・提案・実行で分ける 高リスク業務の事故防止
AIに下書きまで任せられると、確認作業はかなり軽くなります。
ただ、送信や削除まで任せる前には、人が止める場所を決めておきたいところです。
どこから線を引けばいいか、一緒に見ていきませんか？
AIエージェント承認フローで最初に決めたいのは、どのツールを入れるかではありません。
閲覧、提案、実行を同じ「利用可」にまとめず、人が止める場所を先に決めることです。
AIエージェントは、チャットで答えるだけでなく、外部ツール、業務システム、ブラウザ、APIなどへつながり、作業を進められる領域へ広がっています。
便利になるほど、誤送信、誤更新、データ削除、支払いの実行も同じ流れに入ってきます。
そこで大切なのは、AIを使うか使わないかの二択ではなく、どこまで許可するかを段階で分けることです。
まず下書きまで、次に社内確認、最後に実行権限という順番なら、現場にも説明しやすくなります。
承認フローは「実行前に止める場所」を決める仕組み
AIエージェントを安全に使うには、閲覧だけ、提案まで、実行までを分けます。特に外部送信、削除、支払い、契約変更、権限変更は、人間承認を前提にします。
AIエージェントの承認フローは閲覧・提案・実行で分ける
承認フローを作る前に、AIエージェントが何をする存在かをそろえておきます。
ここでいうAIエージェントは、生成AIが目的に合わせてタスクを分解し、ツールやデータを使いながら作業を進める仕組みです。
NISTのAI Risk Management Frameworkは、AIリスク管理をGOVERN、MAP、MEASURE、MANAGEの機能で整理しています。
これは大企業だけの話ではなく、責任者を決め、リスクを把握し、運用中に見直すという順番として中小企業にも使えます。
出典: NIST公式「AI Risk Management Framework」(英語)
承認フローも同じです。
誰が責任を持つか、どの操作が危ないか、どう測るか、運用後にどう直すかを分けておかないと、AIの便利さだけが先に進んでしまいます。
| 権限段階 | AIができること | 人間の役割 |
|---|---|---|
| 閲覧 | 社内資料や画面を見る | 見せる範囲を決める |
| 提案 | 候補文や判断材料を作る | 採否を決める |
| 実行 | 送信、更新、削除、支払いをする | 実行前に承認する |
この表を作ると、AIエージェント承認フローを「どこまで任せるか」の議論ではなく、「どこで人が止めるか」の議論に変えられます。
AIエージェントに任せる業務範囲は、AIエージェントに任せられる業務と人が残す仕事の線引きでも扱っています。
本稿の焦点は、そこから一歩進めて承認とログの設計へ落とすことです。
閲覧権限は情報を見せる範囲から決める
閲覧権限は、AIが社内データや業務画面を見る段階です。
実行はしないため被害が小さく見えますが、個人情報、顧客情報、契約情報、未公開資料を見せれば、それだけで情報管理の対象になります。
NISTの生成AI向けプロファイルでも、生成AIシステムの監視、セキュリティ、ガードレールの継続レビューが扱われています。
出力だけでなく、何を入力し、何を参照させたかを管理対象に入れる考え方です。
出典: NIST「Generative AI Profile」PDF(英語)
中小企業では、最初から細かな権限設計を完璧に作ろうとすると、作業が止まりがちです。
まずは見せてよい情報と、見せない情報を3つずつ書き出すだけで十分。
見せる範囲を決めないまま接続しないことが出発点になります。
- 見せやすい情報: 公開済みFAQ、社内マニュアル、商品説明、過去の一般的な問い合わせ
- 慎重に扱う情報: 顧客名、契約内容、見積金額、従業員情報、未公開の経営資料
- 原則見せない情報: パスワード、APIキー、秘密鍵、決済情報、本人確認書類
生成AIを社内データに学習させない設定の考え方とも重なります。
AIが学習するかどうかだけでなく、そもそも何を見せるかを分けることが先です。
注意閲覧だけでもログは必要
AIが実行しなくても、誰の依頼で何を参照したかは残します。あとから「何を見せたのか」が分からない状態は、情報漏洩時の説明責任を重くします。
提案権限は下書きまで許可し送信は止める
提案権限は、AIが候補文、稟議案、返信案、比較表、チェック結果を作る段階です。
業務効率化の効果が出やすい一方で、そのまま外へ出すと会社の判断に見えるため、送信前の確認が必要になります。
たとえば、問い合わせ返信案をAIに作らせること自体は現実的です。
ただし、価格条件、納期、契約可否、謝罪、返金のような会社判断を含む文面は、担当者の確認なしに送らない設計にします。
生成AIの回答には、もっともらしい誤りが混じることがあります。
根拠確認の手順は、生成AIの回答に混じる嘘を見抜く裏取りの手順も参考になります。
| 提案させる内容 | 人が見る点 | そのまま実行しない理由 |
|---|---|---|
| メール案 | 宛先、表現、約束 | 誤送信や過剰約束を防ぐ |
| 稟議案 | 金額、根拠、承認者 | 社内決裁の責任を残す |
| 比較表 | 出典、条件、抜け漏れ | 誤比較を防ぐ |
| FAQ案 | 公開可否、法務表現 | 外部公開前に整える |
提案権限のよい使い方は、AIに判断を渡すことではありません。
判断材料をそろえさせることで、人の確認時間を短くする使い方です。
実務提案権限は「承認しやすい形」を作らせる
AIには候補だけでなく、根拠、参照資料、判断に迷った点も出させます。承認者が一から読み解く状態では、人間承認が形だけになりやすいからです。
実行権限は高リスク業務だけ別ルートにする
実行権限は、AIが業務結果を直接変える段階に入ります。
危険度はここで大きく変化。送信、更新、削除、支払い、契約変更、権限変更は、AI単独で完了させない前提にします。
AIが進めてよい（通常の実行）
下書き保存・テスト環境の処理・社内メモ作成
取り消せて、影響が社内にとどまる操作
必ず人が承認（高リスクの別ルート）
外部送信・更新・削除・支払い・契約変更・権限変更
取り消しにくく、社外や金銭・個人情報に及ぶ操作
OpenAI Agents SDKのhuman-in-the-loopでは、ツール呼び出しを中断し、人が承認または却下してから処理を再開する流れが説明されています。
これは技術者向けの実装例ですが、経営側にとっての要点は実行前に止められる設計です。
出典: OpenAI Agents SDK「Human-in-the-loop」(英語)
Microsoft Copilot Studioのエージェントフローでも、手動承認ステージやAI承認ステージを組み合わせる例が示されています。
ただし、マルチステージ承認はプレビューとして案内されているため、本文では考え方の参考に留めます。
出典: Microsoft Learn「エージェントフローでのマルチステージとAIの承認」
| トリガー | AIの役割 | 承認者 |
|---|---|---|
| 外部送信 | 文案作成まで | 担当者または上長 |
| 支払い | 支払候補の整理 | 経理責任者 |
| 契約変更 | 差分の抽出 | 業務責任者 |
| 個人情報 | 該当箇所の検出 | 管理責任者 |
| 権限変更 | 申請案の作成 | 管理者 |
この表は、実行権限だけを別ルートへ回すための最初の判断表として使えます。
ブラウザ操作を伴うAIでは、AIブラウザ操作のリスクもあわせて見ると線引きがしやすくなります。
画面を見せることと、画面で実行させることは、必ず分けます。
警告高リスク業務はAI承認だけで完結させない
AIによる一次判定は振り分けには使えます。けれども、支払い、法務、人事、顧客対応の最終判断までAI承認だけで終える設計は避けます。
承認者に渡す情報と却下ルールを決める
人間承認を入れても、承認者が内容を見ずに押すなら意味がありません。
承認画面には、AIが何をしようとしているか、なぜそう判断したか、どこがリスクかをまとめて表示する必要があります。
承認者に渡す情報は多すぎても少なすぎても困ります。
実行対象、変更内容、外部影響、参照元、AIの自信が低い点を短くまとめると、確認の質が上がります。
- 実行対象: どの顧客、どの契約、どのデータに触るのか
- 操作内容: 送信、更新、削除、支払い、権限変更のどれか
- 判断材料: AIが参照した資料、画面、過去ログ
- リスク表示: 個人情報、金額、外部影響、戻せない操作の有無
- 選択肢: 承認、却下、差し戻し、保留、手動処理への切り替え
却下や差し戻しの理由も、後から効く記録。
理由が残ると、次に同じ失敗をしたときにプロンプト、参照資料、権限、承認条件のどこを直すべきか見えます。
却下理由を空欄にしないことが改善の材料になります。
接続アプリの権限設計は、ChatGPT接続アプリ権限が細分化したときの社内ルールとも近いテーマです。
読めるだけ、提案まで、実行までを分けると、承認者の負担も説明しやすくなります。
実務承認者には「押す理由」ではなく「止める理由」を見せる
承認画面が実行ボタンだけだと、確認は流れ作業になります。個人情報あり、外部送信あり、戻せない操作ありのように、止める根拠を先に出します。
操作ログと責任分界を先に決める
AIエージェントの事故対応で困るのは、結果だけ見えて原因が追えない状態です。
誰が依頼し、どのAIが、どの権限で、どの資料を見て、どのツールを呼び出し、誰が承認したかを残します。
OWASPのAgentic AIに関する脅威整理では、tool misuse、privilege compromise、memory poisoningなどが扱われています。
実務に置き換えると、最小権限、操作ログ、権限検証、人間承認を一体で見る必要があります。
出典: OWASP「Agentic AI – Threats and Mitigations」(英語)
| ログ項目 | 残す理由 | 見る人 |
|---|---|---|
| 依頼者 | 業務責任を追う | 業務責任者 |
| 参照データ | 根拠を確認する | 担当者 |
| ツール呼び出し | 誤操作を追う | 管理者 |
| 承認者 | 判断の所在を残す | 上長 |
| 却下理由 | 改善点を残す | 運用担当 |
ログの目的は、社員を責めることではありません。
AIの権限が広すぎなかったか、承認条件が曖昧でなかったかを見直すための材料です。
もしログが取れないツールなら、高リスク業務の実行権限は渡さないほうが安全です。
事故後に説明できない自動化は、効率化よりも大きな負債になります。
注意「AIがやった」で終わらせない
AIは責任主体ではありません。業務ごとに依頼者、承認者、管理者を分け、最終責任を人間側に戻せる記録を残します。
小さく始める導入手順
総務省・経済産業省のAI事業者ガイドライン第1.2版では、AIガバナンスやリスクベースアプローチの考え方が示されています。
難しく見えますが、中小企業では1業務、1権限、1承認ルートから始めるのが現実的です。
出典: 総務省・経済産業省「AI事業者ガイドライン(第1.2版)」
最初の対象は、社内文書検索、FAQ下書き、議事録整形、問い合わせ返信案など、戻しやすい業務が向いています。
外部送信やデータ更新は、ログと承認運用が回ってからにします。
- 1週目: 業務を1つ選び、閲覧・提案・実行に分ける
- 2週目: 見せるデータ、見せないデータ、承認者を決める
- 3週目: 提案権限だけで試し、却下理由と修正点を残す
- 4週目: 実行権限を渡すか、下書き運用を続けるか判断する
このチェックリストを月次で見直すだけでも、AIエージェントの権限が知らないうちに広がる状態を防ぎやすくなります。
社内ルールの初版づくりは、AI事業者ガイドライン改定で中小企業がまず対応すべきことと、生成AIを社員が勝手に使う前に決める利用ルールも参考になります。
禁止で止めるより、許可する範囲と止める操作を分けるほうが現場に定着しやすいはずです。
結論最初は実行権限を渡さない運用で十分
AIエージェントの価値は、いきなり全自動にすることだけではありません。下書き、比較、確認材料づくりから始めても、現場の負担は軽くなります。
AIエージェント承認フローの導入前チェック
最後に、実行前の確認項目を1枚にまとめます。
この表を埋められない業務は、AIに実行権限を渡す前に止める判断で問題ありません。
| 確認項目 | 決めること | 未決なら |
|---|---|---|
| 対象業務 | 1つに絞る | 範囲を縮める |
| データ | 見せる範囲 | 閲覧だけにする |
| 提案 | 採否基準 | 人が全文確認 |
| 実行 | 承認条件 | AI単独実行なし |
| ログ | 保存項目 | 高リスク業務は不可 |
| 停止 | 手動復旧 | 試験運用に戻す |
AIエージェントの承認フローは、厚い規程を作るためのものではありません。
現場で止められないルールは、事故防止に使えません。
現場が迷わず止められる線を決めるためのものです。
すでにAIエージェントの自律実行と途中確認を検討している場合も、まずはこの3段階に戻して見直すと安全です。
閲覧、提案、実行のどこにいるかが分かれば、次に足すべき承認も見えます。
よくある質問
QAIエージェントの承認フローは何から決めればよいですか？
A最初に対象業務を閲覧・提案・実行へ分けます。実行権限を持つ業務だけは、承認条件、承認者、ログ、停止手順を別に決めます。
Q閲覧権限だけなら安全ですか？
A安全と言い切ることはできません。読むだけでも個人情報や機密情報が露出するため、AIに見せるデータ範囲と出力の再利用先を決めておきます。
Q提案権限と実行権限の違いは何ですか？
A提案権限は下書きや候補を作るところまでです。実行権限は送信、更新、削除、支払いなど業務結果を変える操作まで含みます。
Q人間承認はどの業務に必要ですか？
A個人情報、外部送信、決済、契約変更、データ削除、人事、法務、セキュリティに関わる業務では、人間承認を残す設計が現実的です。
QAI承認ステージを使えば人間承認は不要ですか？
A不要にはなりません。AIによる一次判定は振り分けに役立ちますが、高リスク業務では最終確認を人間が担う形にします。
Q操作ログには何を残せばよいですか？
A依頼者、エージェント名、権限、参照データ、入力、ツール呼び出し、出力、承認者、承認または却下理由、実行結果を残します。
Q承認フローが形だけにならないコツはありますか？
A承認者に判断材料をまとめて渡し、却下や差し戻しを記録し、月次で例外承認とログ欠損を見直すことです。
まとめ
AIエージェントを安全に使う入口は、閲覧・提案・実行を分けることです。
同じ「AI利用」でも、情報を見るだけの段階と、外部へ送信したりデータを書き換えたりする段階では、会社に残る責任が違います。
高リスク業務では、AIを止める仕組みを弱さではなく運用の前提として置きます。
承認者、ログ、却下理由、停止手順を先に決めるほど、便利さと安全性を両立しやすくなります。
最初の一歩は、1業務だけを選び、AIに読ませる情報、作らせる提案、実行させない操作を表にすることです。
送信、削除、支払い、契約変更、権限変更を止められるなら、AIエージェント活用は落ち着いて進められます。
