公開 2026.09.16

AIエージェントはどこまで任せるべきか｜委任範囲・人の承認・停止条件を設計する実務ガイド

DX推進

生成AIの社内定着・業務効率化のご相談を承っています

戦略策定から現場研修まで、Mojiが一貫して支援します。

AIエージェントを導入するときは、「どのモデルを使うか」と合わせて、AIにどの操作まで任せ、どの操作の直前で人が承認し、異常時に何を止めるかを早い段階で決めることが重要です。

たとえば、議事録を要約することと、顧客台帳を更新すること、顧客へメールを送ること、返金や発注を確定することは、同じ「自動化」ではありません。後者ほど、誤操作が外部へ影響し、取り消しや原因究明も難しくなります。

本記事では、AIエージェントの委任範囲を業務単位で決めるための実務フレームを示します。ここで紹介する4段階の委任レベル、判定スコア、承認・停止条件のテンプレートはMojiによる設計提案です。NISTのAI RMFは、AIリスク管理をGOVERN・MAP・MEASURE・MANAGEの4機能で整理し、ガバナンスを他の機能に横断的に組み込む考え方を示しています。NIST AI RMF 1.0

結論：任せる範囲は「業務名」ではなく「実行される操作」で決める

「営業支援は任せる」「経理は任せない」のように部門名で線を引くと、判断が粗くなります。同じ営業業務でも、商談メモの要約、CRMの候補項目作成、CRMへの確定登録、値引き条件を含む見積送信では、許容できる失敗が異なるためです。

まずは、エージェントの行為を次の4段階に分けます。

委任レベル	エージェントが行うこと	基本方針	例
レベル0：閲覧・整理	読む、検索する、分類する、要約する	原則として自動実行を検討しやすい。ただし閲覧権限と入力データを制限する。	社内規程の検索、会議メモの要約
レベル1：下書き・提案	文案、候補、更新案、実行計画を作る	人が最終判断・送信・確定する。提案の根拠を表示する。	顧客メールの下書き、発注候補の作成
レベル2：可逆な書き込み	内部システムへ登録・更新する	対象範囲、項目、件数を制限し、取り消し・差分確認・承認を設計する。	タスク起票、下書きステータスでのCRM登録
レベル3：外部影響を伴う実行	対外送信、契約、決済、発注、権限変更をする	人の承認を置くことを検討する。金額・宛先・対象件数・時間帯などに上限を設ける。	顧客への送信、返金、発注確定、アカウント権限付与

この区分は、モデルの性能評価ではなく、操作の結果がどこへ残り、誰へ影響するかを見ています。OpenAIの実務ガイドでも、ツールのリスクを読み取り専用か書き込みか、可逆性、必要なアカウント権限、金銭的影響などで評価し、高リスク操作では人へのエスカレーションを検討する考え方が示されています。OpenAI: A practical guide to building agents

委任レベルを決める4つの判定軸

レベルを仮置きしたら、各操作を次の4軸で評価します。点数は絶対的な安全度ではなく、チームが判断理由をそろえるための共通言語です。

判定軸	低リスクの状態	高リスクの状態	確認する質問
不可逆性	容易に取り消せる、下書き保存である	送信・公開・決済・契約など、完全な取消が難しい	誤実行から元の状態へ戻せるか
影響範囲	限定された案件・内部の少人数に留まる	多数の顧客、全社データ、外部取引先へ広がる	一度の実行で何件・誰に影響するか
検知可能性	差分、根拠、実行結果をすぐ確認できる	誤りが後日まで見つからない、結果の正誤が曖昧	誤実行を誰が、いつ、何で検知できるか
復旧可能性	履歴から復元でき、被害が限定的	信用、法的義務、金銭、個人への影響が残る	復旧に必要な担当者・時間・費用は許容範囲か

Mojiによる設計上の目安として、4軸のうち「高リスク」が2つ以上ある操作は、レベル2以下へ分解できないかを先に検討します。分解できない場合はレベル3として、承認ゲートと停止条件を設けます。たとえば「返金を実行する」という操作を、返金候補の抽出、根拠資料の収集、返金案の作成、承認後の決済API実行に分ければ、人は判断が必要な最後の一点に集中できます。

ただし、この目安は一律のルールではありません。結論は、採用モデル、入力データの品質、誤りを測る評価指標、許容できる誤差、既存の業務統制によって変わります。高精度なモデルであっても、誤送信や過大発注の影響が大きい操作を自動承認にしてよいとは限りません。

判断マトリクス：自動実行、承認付き実行、実行禁止を分ける

次のマトリクスを業務棚卸しに使います。これはMojiによる提案です。

判定	適する条件	必要な統制	代表例
自動実行	読み取り中心、または可逆で影響が限定的。結果を自動検証できる。	最小権限、実行ログ、件数上限、定期サンプリング	文書の分類、定型タスクの起票
条件付き自動実行	定量条件を満たす場合のみ低リスク。条件外は人へ渡せる。	閾値、例外キュー、ロールバック、アラート	定義済み項目だけのデータ補完
承認付き実行	書き込み・対外影響があるが、担当者が内容を判断できる。	実行前プレビュー、根拠、承認者、二者承認が必要な条件	顧客メール送信、CRM確定更新
提案のみ	判断根拠が曖昧、または誤りの検知・復旧が難しい。	根拠表示、反対候補、レビュー手順	採用判断、与信判断、契約条件案
委任しない	許容できない影響があり、承認者も妥当性を確認できない。	エージェントを実行経路から外す。必要なら情報収集に限定する。	本人確認を伴わない送金、無制限の権限変更

Mojiによる承認画面の設計例として、承認者が判断に必要な情報を短時間で確認できるよう、少なくとも実行対象、変更前後の差分、外部への影響、根拠、金額・件数、失敗時の戻し方を表示します。これらを確認しにくい操作は、エージェントに渡す前に業務フローをより小さな単位へ分解できないかを検討します。

人の承認を置くべき地点

承認は、常に「最終ボタンの直前」に置くとは限りません。設計すべきなのは、誤った前提が後続処理へ伝播する前の地点です。

対象の確定前：顧客、案件、データ範囲の取り違えが起きやすい場合
方針の選択時：値引き、優先順位、例外処理など、会社方針の解釈が必要な場合
外部へ出す直前：送信、公開、発注、決済、権限付与など、不可逆性が上がる場合
例外発生時：既定ルールに当てはまらない、入力が不足する、複数の正解があり得る場合

OWASPは、エージェントの過剰な権限付与への対策として、下流システムでも利用者の権限文脈を追跡し、必要最小限の権限で実行すること、高影響の操作には人による承認を要求することを挙げています。OWASP: LLM06 Excessive Agency

つまり、承認はモデル出力の文章チェックだけでは不十分です。誰の権限で、どのシステムの、どの操作を、どの範囲で行うのかを承認対象に含めます。

ケース別：承認・権限・停止条件の設計例

以下は架空の例です。実際の上限額、対象件数、承認者は、業務規程・契約・権限体系に合わせて決めてください。

ケース1：顧客へのメール送信

委任範囲	過去のやり取りと承認済みテンプレートを基に、メール案を作成する。
人の承認	新規顧客、価格・納期・契約条件を含む文面、苦情への回答、添付ファイルがある送信。
権限	初期段階では送信APIを付与せず、下書き保存のみ。送信を許可する場合も、対象ドメインや送信件数を限定する。
停止条件	未承認テンプレートの使用、宛先とCRM担当者の不一致、機密ラベル付き添付、短時間の連続送信。
ログ	参照した情報、生成文、編集差分、承認者、宛先、送信時刻、使用テンプレートの版。

ケース2：CRM・基幹システムのデータ更新

委任範囲	会議メモから、定義済みの項目候補を抽出する。
人の承認	売上見込み、契約ステータス、解約理由、担当変更など、後続の集計や顧客対応を変える項目。
権限	作成と更新を分離する。まずは「提案レコード」または下書き状態へ書き込み、確定テーブルへの更新は別権限にする。
停止条件	必須項目の根拠不足、既存レコードとの矛盾、更新件数が通常範囲を超える、対象IDを一意に特定できない。
ログ	変更前後の値、根拠テキスト、対象ID、実行主体、ロールバック用の履歴。

ケース3：発注・返金・決済を伴う処理

委任範囲	注文・問い合わせ・規程を照合し、実行候補と根拠を提示する。
人の承認	金額の大小だけでなく、返金理由、発注先の変更、分割発注、例外規程への該当を確認する。必要に応じて二者承認にする。
権限	候補抽出用の読み取り権限と、決済実行権限を分離する。エージェントに包括的な管理者権限を渡さない。
停止条件	承認者不在、上限超過、同一取引先への短時間の反復実行、口座・支払先の変更、根拠資料の欠落。
ログ	金額、通貨、支払先、根拠、承認記録、実行結果、取消・返金の参照ID。

高リスク操作やリトライ上限超過を人へ渡す考え方は、OpenAIの実務ガイドでも、敏感・不可逆・高い利害を伴う操作や、失敗しきい値の超過を人の介入トリガーとして示す形で説明されています。OpenAI: A practical guide to building agents

停止条件は「失敗したら止める」ではなく、事前に機械判定できる形にする

停止条件を「不審な場合」「自信がない場合」とだけ書くと、実装者・運用者・モデルで解釈が分かれます。停止条件は、可能な限り観測可能なイベントと閾値にします。

Mojiによる停止条件テンプレートは次のとおりです。

停止または人へエスカレーションする条件

1. 対象の特定
- 対象IDが一意に確定しない
- 宛先、取引先、担当者に矛盾がある

2. 入力・根拠
- 必須の根拠資料が取得できない
- 根拠が古い、または承認済み情報源に含まれない

3. 実行範囲
- 1回の処理件数が上限を超える
- 金額、割引率、権限範囲、時間帯が許容範囲外である

4. 処理挙動
- 同一操作の再試行回数が上限を超える
- 想定外のツール呼び出し、権限要求、データ取得が起きる

5. 結果検証
- 実行結果が期待した状態と一致しない
- 実行後の検証に必要なログまたは参照IDが取得できない

停止後の引き継ぎ情報も重要です。「停止しました」だけでは、担当者が最初から調べ直すことになります。停止イベントには、対象、実行しようとした操作、参照根拠、検知した条件、未実行か一部実行済みか、次に必要な判断を添えます。

最小権限とログを、エージェントの能力と合わせて設計する

エージェントが使うツールの制御を、プロンプト上の指示だけに依存しません。アプリケーション側・API側の権限でも、そもそも実行できない状態を作ります。

読み取りと書き込みを分離する：検索・照合エージェントと、更新エージェントに同じトークンや管理者権限を渡さない。
操作を狭くする：汎用的な「任意SQL実行」ではなく、「指定IDの下書き更新」のように目的を限定したツールを用意する。
対象範囲を絞る：部署、テナント、顧客、データ種別、時間帯、件数をAPI側で制約する。
実行結果を記録する：誰の依頼で、何を根拠に、どのツールを、どの引数で呼び、何が変わったかを追跡できるようにする。
ロールバック経路を検証する：履歴があるだけでなく、実際に復旧可能かをテストする。

AIエージェントの接続先を増やすほど、ツールの認証・認可設計が委任範囲の上限を決めます。API、MCP、A2Aなどの接続方式と「何を任せるか」の関係は、API・MCP・A2Aの違いも併せて確認してください。

また、エージェントのリスクはモデル出力だけでなく、データ、外部ツール、運用プロセス、人の役割をまたぎます。全体のリスク特定・評価・対応・監視の考え方は、AIのリスク管理・マネジメントで整理しています。個人情報や機密情報をツールへ渡す場合は、利用実態を把握できない状態を避けるために、シャドーAIのリスクと対策も確認してください。

導入手順：最初から「完全自律」を目指さない

業務を操作単位に分解する
「問い合わせ対応」ではなく、検索、分類、回答案作成、顧客情報参照、送信、チケット登録に分けます。
失敗シナリオを先に書く
誤った対象、根拠不足、二重実行、権限逸脱、誤送信、取り消せない更新を列挙します。
4つの判定軸で委任レベルを仮決めする
不可逆性、影響範囲、検知可能性、復旧可能性を記録し、判断理由を残します。
承認・停止・権限・ログを操作ごとに決める
「人が見る」ではなく、誰が、何を見て、どの条件なら承認・差し戻し・停止するかを決めます。
提案のみで評価する
まず実行権限を渡さず、現行業務の結果と比較します。正答率だけでなく、根拠不足の検知、不要なエスカレーション、見逃し、処理時間を確認します。
限定条件で書き込みを解放する
対象部署、データ項目、件数、時間帯を限定し、ロールバックを含む運用訓練を行います。
実績に基づいて委任範囲を更新する
失敗事例・停止事例・承認差し戻しを評価データへ戻し、権限や閾値を見直します。

NISTの生成AIプロファイルは、AI RMFの各機能に対応した行動例を示しており、必要なリスク管理活動の水準を組織のリスク許容度に基づいて決める考え方を含みます。したがって、他社の自動化事例をそのまま移植するのではなく、自社の業務・データ・責任分界に合わせてプロファイルを作ることを検討してください。NIST AI 600-1: Generative AI Profile