AIエージェントの権限設計|承認フローの決め方と業務別の具体例

DX・デジタル活用

2026.10.05

AIエージェントの権限設計|承認フローの決め方と業務別の具体例

AIエージェントは「提案」だけでなく、外部システムを操作して業務処理を実行できる段階へ広がっています。ただし、AIが法的・最終的責任を負うわけではなく、企業側で権限、承認者、最終責任者を明確にする必要があります。

結論(導入部の直接回答)
AIエージェントの権限は「主体・対象・操作・条件・期限・承認者」の6要素に分解し、影響度(可逆性、外部影響、機密性、金銭・法務影響、件数等)に応じて「自動実行/担当者承認/上長承認/二者承認」を使い分けます。外部送信・金銭処理・削除・特権付与は原則として人間承認か事前厳格ルールを通す運用としてください。

先に決めるべき5項目(要点)

  • 業務目的:提案までか実行までか、KPI(時間削減、エラー低減など)を定義。
  • 参照・更新するデータ:個人情報、財務情報、契約情報などは分類ルールを適用。
  • 許可する操作:Read/Create/Update/Send/Delete/Approve/Grantを明確化。
  • 自動実行の条件と上限:件数、金額、顧客区分、営業時間、本人確認状況など。
  • 停止・復旧・責任体制:緊急停止権限、ロールバックの可否、補償フロー、連絡網。

権限は「主体×対象×操作×条件×期限×承認者」で設計する

基本式:権限=主体 × 対象リソース × 操作 × 条件 × 期限 × 承認者。実務で使える記述例:

例)見積作成AIは担当商談の見積データを参照し、見積書の下書きを作成できる。値引率が10%を超える、または見積金額が500万円を超える場合は営業部長の承認を必要とし、案件終了で権限を失効する。

リスクスコアで承認レベルを決める(実用式)

各評価項目を0〜2点で採点し、合計点で承認レベルを判定します。以下は具体的な採点基準です(初期案)。

評価項目

0点

1点

2点

外部影響

社内処理のみ

限定された外部送付(関係者のみ)

顧客・パブリックへの公開

情報機密度

公開情報

社内限定情報

個人情報・機密情報

金銭・法務

影響なし

軽微(返金候補等)

支払・契約に直結

影響件数

1件・限定的

複数件(部門単位)

大量・全社影響

可逆性

自動復元可能

手動で復元可能

復元困難・不可逆

権限影響

権限変更なし

通常権限の変更

特権付与・権限昇格

根拠の検証性

ルールで検証可能

一部人の判断が必要

根拠不足・例外多数

合計点の目安:0–3点=自動実行または事後レビュー、4–6点=担当者承認、7–9点=上長承認、10点以上=二者承認または自動実行禁止(ハードストップ)。

注:このスコアは初期評価例です。社内規程や法令、業界慣行、過去事故の影響を踏まえて閾値を調整してください。

承認過多を防ぎながら自動化率を高める方法

  • 低リスク処理は事後レビューに回す(読み取り・分類など)。
  • 通常案件と例外案件を分離し、差分だけを承認画面に表示する。
  • 同一条件の複数処理を一括承認できる仕組みを作る(例:1顧客の同一種処理を1画面で承認)。
  • 承認SLA(例:担当者2時間、上長1営業日)と自動エスカレーションを設定する。
  • サンプリング監査を導入し、実績に応じて承認サンプル率を下げる。
  • KPIで「承認待ち時間」「差し戻し率」「自動実行率」「ロールバック率」を監視する。

「高額」「大量」「重要」はどう定義するか

閾値は既存の決裁規程・職務権限規程・情報分類規程を起点に設定します。ポイント:

  1. まずは既存閾値を流用:人間が承認する金額/件数をAIの基準に取り込む。
  2. AIは連続実行リスクがあるため、人間基準より低めの上限から開始し、実績を見て緩和する。
  3. 部門ごとに業務特性で閾値を調整(例:経理の振込は通常より低い開始閾値)。

業務別テンプレート(共通フォーマット)

各部門は以下フォーマットで設計してください:AIの役割/参照可能な情報/自動実行できる処理/承認が必要な条件/承認者/保存するログ/復旧方法

営業(見積)

  • AIの役割:商談要約、見積書下書き、CRMの提案更新
  • 参照可能な情報:商談履歴、価格表、顧客契約情報(社内分類に従う)
  • 自動実行:要約・下書き作成、定型メール案作成(送信は不可)
  • 承認が必要な条件:値引率が社内基準超、見積金額が決裁閾値超
  • 承認者:営業担当(送付)、営業部長(値引き承認)
  • 保存するログ:参照ID、生成文書、差分、承認履歴
  • 復旧方法:CRMの変更前値を保存し差分ロールバック。外部送信時は訂正文の送付手順を定義。

経理・財務

  • AIの役割:請求書OCR、仕訳候補、突合サジェスト
  • 参照可能な情報:請求書原本、過去仕訳、取引先マスタ(機密区分あり)
  • 自動実行:OCR処理、候補提示、重複検出
  • 承認が必要な条件:支払実行・振込先変更・高額振込は承認必須
  • 承認者:担当経理→経理責任者→二者承認(高額)
  • 保存するログ:原票ID、OCR結果、承認者、支払トランザクションID
  • 復旧方法:支払処理は取り消し不可が多いため、誤支払対応(返金、通知、法務対応)を事前定義

人事・採用

  • AIの役割:求人票草案、候補者情報の整理、面接日程調整案
  • 参照可能な情報:履歴書、過去評価、求人要件(個人情報は厳格管理)
  • 自動実行:日程候補の提示、書類分類、面接案内メール(定型で事前承認された場合)
  • 承認が必要な条件:採否決定、給与条件提示、雇用契約締結
  • 承認者:採用担当→部門責任者→人事責任者(重要条件)
  • 保存するログ:候補者ID、案内メール版、承認履歴(個人情報はマスキング)
  • 復旧方法:誤送信時は速やかに訂正メールと説明、必要時法務と連携

カスタマーサポート(CS)

  • AIの役割:問い合わせ分類、回答案作成、FAQ更新案
  • 参照可能な情報:顧客履歴、製品情報、判例(個人情報管理)
  • 自動実行:タグ付け、ワークチケットの自動振り分け
  • 承認が必要な条件:返金、アカウント停止、大きな補償対応
  • 承認者:担当CS→チームリーダー→CSマネージャー
  • 保存するログ:問い合わせ原文、AI案、変更前後、承認履歴
  • 復旧方法:返金や停止は補償手順(返金処理・通知)を定義

法務・契約

  • AIの役割:契約条項抽出、差分比較、リスク候補の提示
  • 参照可能な情報:標準契約テンプレート、過去契約、法務ガイドライン
  • 自動実行:差分抽出・危険表現のハイライト(締結は不可)
  • 承認が必要な条件:例外条項の受け入れ、契約締結、法的意思表示
  • 承認者:法務担当→法務責任者→必要時経営承認
  • 保存するログ:比較結果、法務コメント、承認履歴、締結バージョン
  • 復旧方法:誤締結時は訂正協議、撤回通知、補償手順を準備

情シス(IT・ID管理)

  • AIの役割:チケット分類、アカウント棚卸し、構成情報の抽出
  • 参照可能な情報:アカウントリスト、アクセスログ、構成管理DB
  • 自動実行:未使用アカウント抽出、レポート作成
  • 承認が必要な条件:アカウント作成(特権含む)、削除、全社設定変更
  • 承認者:担当IT→ITマネージャー→二者承認(特権)
  • 保存するログ:操作対象、変更前後、承認履歴、実行APIトランザクションID
  • 復旧方法:アカウント削除はバックアップと復元手順、特権付与は即時取り消しフロー

回答生成と業務実行の分離(推奨フロー)

推奨フロー:1) AIが操作案を生成 → 2) ルールエンジンで条件判定 → 3) 必要時に人間が承認 → 4) 実行専用APIが処理 → 5) 結果・承認履歴を保存。これによりプロンプトインジェクションの影響を緩和し、実行時に再検証が可能になります。

監査ログ設計と情報保護

最低限記録:実行主体(エージェントID・依頼者)、指示内容・AI出力・操作案、参照情報(データソース・取得日時)、操作情報(API・対象・変更前後)、承認情報(承認者・日時・コメント)、結果・影響件数、復旧履歴。

ただしログ自体が情報漏洩の温床とならないよう次を必須にしてください:

  • 個人情報や機密をマスキングして保存
  • ログの暗号化とアクセス権限の分離
  • APIキーや認証情報はログに残さない
  • 保存期間を社内規程に従って設定し自動削除
  • モデル・プロンプト・ポリシーのバージョンを記録
  • ログ改ざん検知(ハッシュやWORMストレージ)を導入

誤操作・例外・緊急時の基本フロー

承認者不在:代理承認→一定時間で自動エスカレーション。外部API障害:再試行回数制限・二重実行防止ID付与・手動切替。誤操作:緊急停止、トークン失効、影響範囲特定、訂正・補償処置(返金・訂正文送付等)を実施。

重要:外部送信や振込など技術的に完全なロールバックが難しい処理については「ロールバック(技術的復元)」と「補償処理(訂正・返金・通知等)」を明確に分けて設計してください。

段階的な導入と見直し

  1. まずは読み取り・検索から開始
  2. 要約・分類→下書き作成→人間承認付き更新→条件限定自動実行→実績に基づく拡大

レビュー頻度は月次または四半期ごと、異動・モデル更新・インシデント発生時は都度見直します。重点チェック項目:未使用権限、期限切れトークン、差し戻し率、承認待ち時間。

テンプレート(簡易権限マトリクス例)

エージェント

対象

操作

自動実行条件

承認条件

承認者

有効期限

見積AI

担当商談の見積データ

下書き作成

全案件

—

—

案件終了まで

見積AI

担当商談の見積データ

本反映

値引率10%以下かつ500万円以下

値引率10%超または500万円超

営業部長

案件終了まで

実践的なワンポイント(弊社PoCの経験)

弊社が支援した匿名PoC(中堅企業3社、期間3ヶ月、合計約2,400件のAI提案を検証)では、初期は承認率を高めに設定し、2ヶ月後に誤処理率が低下した案件は事後レビューに移行する運用で自動化率が約25→55%に向上しました(匿名化・業務条件に依存)。このように段階的な運用とKPI監視が重要です。

よくある質問(FAQ)

Q:AIに恒常的な管理者権限を与えてよいですか?

A:原則として与えません。必要時は限定的実行API、Just-in-Time権限、二者承認、完全な監査ログを組み合わせて対応してください。

Q:AIの確信度だけで自動実行してよいですか?

A:確信度は参考指標として有効ですが、金額・件数・機密性・可逆性など客観条件との併用が必須です。

Q:PoC段階で監査ログは必要ですか?

A:必要です。PoC段階から入出力・参照データ・承認履歴を記録すると本番移行時の根拠になります。ただしログ保存時はマスキング等の情報保護を徹底してください。

参考資料

まとめ・次の一手(CTA)

まずは自社でAIがアクセスするシステムと操作を一覧化し、この記事の権限マトリクスを使って「自動実行/担当者承認/上長承認/二者承認」の4分類を作ってください。PoCではログ取得とロールバック(技術的復元)・補償手順の実地テストを必ず行い、実績に基づき段階的に自動化範囲を拡大しましょう。