AIエージェントにどこまで任せる？権限・人の承認・監査ログ・停止条件の実務チェックリスト

最初に「何ができるか」ではなく「何を任せるか」を決める

最初に確認したいのは、AIエージェントが利用する製品や接続先ではなく、AIが最終的に行う操作です。同じシステムを利用していても、情報を読むことと、データを変更・送信することでは、業務への影響が異なります。

実務上の見落としは、「メール対応を任せる」「台帳管理を任せる」のように、業務名だけで対象範囲を決めることです。この整理では、検索、下書き、送信、登録、更新のどこまでを許可するのかが分かりません。

参照・下書き・実行に分ける

• 参照：検索、閲覧、情報取得、要約

• 下書き：メール案、回答案、登録候補、報告案の作成

• 実行：送信、登録、更新、公開、削除、設定変更

例えば、過去の問い合わせを検索して回答案を作ることと、その回答を顧客へ送信することは別の操作です。参照と下書きを許可しても、送信まで自動化する必要はありません。対象業務を処理単位へ分解し、AIが行う操作を動詞で書き出します。

誤実行時の影響を確認する

• 社外へ情報が送られるか

• 重要な業務データが変更されるか

• 複数の対象へ連続して影響するか

• 実行後の訂正・復元が難しいか

• 対象業務を止める可能性があるか

「送信だから危険」「参照だから安全」と操作名だけで判断せず、対象データ、送信先、処理範囲、訂正・復元の可能性を組み合わせます。影響範囲を説明できない操作は、確認が終わるまで自動実行の対象から外します。

AIは誰の権限で動くのかを説明できるようにする

AIエージェントを本番環境へ接続する際は、誰の指示で、どのIdentityと権限を使い、何を実行したのかを識別できる状態にします。すべてのAIエージェントに一律に専用Identityを与えることが正解とは限りません。方式の名称だけで選ばず、自社の構成で実際に誰の権限が使われるかを確認します。

利用者・AIエージェント・接続先を対応付ける

• AIエージェントの所有者と利用部門

• 処理を開始する利用者またはシステム

• AIエージェントの識別情報

• 接続先で使用するIdentity

• 参照できるデータ

• 許可する操作と禁止する操作

• 権限を変更・失効する方法

実行主体をログで区別できるか、認められた範囲を超えて動作しないか、利用終了後に権限を失効できるかを確認します。担当者の異動や退職、利用部門の変更、PoCの終了後を想定し、定期的な棚卸しと失効手順まで決めておきます。

操作別に権限と未確認時の扱いを決める

「制限を検討する操作」は固定的なリスク等級ではありません。対象データや処理範囲に応じて、人の承認、接続先の限定、機能制限などを検討するための区分です。

OWASPの「AI Agent Security Cheat Sheet」では、過剰なTool権限、高影響操作、人による監督が不十分な状態などをリスクとして挙げています。対策として、業務に必要なToolだけを付与すること、read-onlyとwriteの権限を分けること、重要な操作には明示的な認可を求めることなどを示しています。 OWASP「AI Agent Security Cheat Sheet」

AI基盤の配置やデータの保存・処理場所、管理者・保守担当者のアクセス条件については、「オンプレAIなら安全、では足りない｜Private AIの配置を決める6つの判断軸」で詳しく整理しています。本記事では、基盤配置ではなく、AIが実行する操作の統制に焦点を当てます。

人の承認を「実行の境界」として設計する

すべての処理へ人の承認を追加する必要はありません。誤実行時の影響が大きい操作について、AIが提案する段階と、実際に処理する段階を分けます。人が処理の途中で確認・承認する設計はHuman-in-the-Loop（HITL）と呼ばれます。ただし、承認ボタンを設けるだけでは、確認作業が形式化する可能性があります。

承認対象を操作の影響から決める

• 社外への送信・公開

• 業務データの更新

• 重要な設定や権限の変更

• データの削除・上書き

• 複数件の連続処理

• 実行後の訂正・復元が難しい処理

すべての操作へ承認を求めると確認作業が増え、AIを利用する効果が薄れる場合があります。AIには下書きまでを任せ、実行は人が担当する方法も検討します。

承認者が判断できる情報を提示する

• 実行しようとしている操作

• 対象となるシステムやデータ

• 変更・送信する内容

• 対象件数

• 実行後に訂正・復元できるか

• 承認後に開始される処理

承認者が不在の場合や内容を判断できない場合には、処理の保留、却下、代理承認者への通知、人による処理への切り替えなどの既定動作も決めます。

ログを残すだけでなく、誰が異常を確認するかを決める

監査ログの保存と運用監視は同じではありません。監査ログは、誰が何を許可・実行したかを後から確認するための記録です。運用監視は、異常を検知し、確認・制限・停止へつなげる活動です。

指示から実行結果まで追跡する

• 処理を開始した利用者またはシステム

• AIエージェントのIdentity

• 指示内容

• 参照した情報

• 呼び出したToolやAPI

• 実行しようとした操作

• 承認・却下の結果と承認者

• 実行結果、エラー、中断、再実行

項目を保存するだけでなく、同じ処理として関連付け、指示から実行結果まで追える状態にします。記録対象、保存方法、保存期間、確認権限は、利用目的、社内規程、契約、監査要件に応じて決めます。

通知後の役割を分ける

• 異常を検知する

• 担当者へ通知する

• 一次確認する

• 対応方針を判断する

• 機能を制限する

• 必要に応じて停止・隔離する

• 影響を確認する

• 利用部門へ連絡する

• 対応結果を記録する

監視、通知、一次確認、制限、停止、復旧、報告のうち、自社に残す判断と、外部へ任せる作業を分けることも重要です。 外部支援へ任せる範囲の整理については、「中堅企業の情シス不足をどう補うか｜設計・構築・運用の『どこまで任せるか』を決める判断軸」で詳しく解説しています。

異常時は「確認・制限・停止」の3段階で対応する

異常対応を「止める」「止めない」の二択にしないことが重要です。業務への影響と異常の内容に応じて、確認、機能制限、停止・隔離の3段階を設けます。

第1段階：確認する

異常の可能性を通知し、実行内容とログを確認します。影響が分かるまで処理を一時保留し、担当者へ判断を求めます。

第2段階：機能を制限する

参照機能を残しながら、外部送信、更新、削除などの操作を止めます。必要に応じて接続先や対象データを限定し、人の承認がない処理を保留します。

第3段階：停止・隔離する

AIエージェントの実行停止、接続先へのアクセス遮断、Identityや認証情報の無効化、未完了処理の保留などを検討します。

• 想定外の接続先へのアクセス

• 許可していない操作

• 承認を経ていない処理

• 意図しない処理の繰り返し

• エラー後に続く再実行

• 通常と異なる件数や頻度の処理

これらは一律の停止基準ではありません。対象業務の重要度や影響範囲に応じて、どの段階へ移るのか、その判断者と実行者を本番稼働前に決めます。停止後は、実行済み処理、影響を受けたデータ、外部への送信・公開結果、未完了処理を確認します。

実行済みの処理を必ず元に戻せるとは限りません。訂正・復元できる範囲と方法を確認し、停止中も業務を継続できるように、人が行う手順、担当者、必要なアクセス権、未処理案件の確認方法を用意します。

PoCでは精度だけでなく「統制が機能するか」を確認する

AIの回答精度だけで本番移行を決めることはできません。参照、下書き、承認付き実行の順に範囲を広げ、権限、承認、ログ、機能制限、停止が実際に機能するかを確認します。

1. 参照できるデータの範囲を確認する

2. 下書きの保存先、確認者、修正方法を確認する

3. 承認、却下、保留、代理対応を確認する

4. 限定した実行について、ログ、制限、停止、手動運用を確認する

5. 終了後のIdentity、接続、権限を処理する

PoCの期間や合格点を一律には決められません。対象業務、使用するデータ、接続先、実行する操作に応じて、確認項目と本番移行の条件を決めます。

本番移行を4区分で整理する

判定結果だけでなく、判定根拠、未確認事項、重大な不足、追加対策、確認担当者、再確認時点を記録します。この4区分は、点数によって安全性を認定するものではありません。

本番投入前の実務チェックリスト

業務・操作

☐ AIが行う操作を参照・下書き・実行に分けた

☐ AIに任せる範囲と、人が担当する範囲を決めた

☐ 誤実行時の影響範囲を確認した

☐ 実行後に訂正・復元できるか確認した

Identity・権限

☐ 処理を開始する利用者またはシステムを特定した

☐ 接続先で使用するIdentityを確認した

☐ 許可する操作と禁止する操作を分けた

☐ 権限を変更・失効する方法を決めた

☐ PoC終了後に残る接続や権限を確認した

承認・追跡

☐ 人の承認が必要な操作を決めた

☐ 承認者と代理承認者を決めた

☐ 承認者へ提示する情報を決めた

☐ 指示から実行結果まで追跡できる

☐ ログの確認担当者と異常時の連絡先を決めた

異常対応・業務継続

☐ 確認・制限・停止へ移る条件を決めた

☐ 判断者と停止操作を実行する担当者を決めた

☐ 一部の機能だけを制限できるか確認した

☐ 停止後の影響確認方法を決めた

☐ AIを停止した場合の手動手順を用意した

☐ 再開条件と再確認する担当者を決めた

未確認の項目は「問題なし」とせず、「仕様や契約を確認する」「PoCで実際の動作を確認する」「確認できるまで本番対象から外す」のいずれかへ振り分けます。

まとめ

AIエージェントに任せる範囲は、製品の機能や回答精度だけでは決まりません。対象業務を参照、下書き、実行に分け、実行主体、使用する権限、誤実行時の影響を確認します。その結果に応じて、人の承認、監査ログ、運用監視、機能制限、停止方法を組み合わせます。

PoCでは、回答が正しいかだけでなく、承認前に処理を止められるか、実行内容を追跡できるか、異常時に制限・停止できるか、人による業務へ切り替えられるかを確認してください。

確認できない項目を残したまま自動実行へ進まず、本番候補、条件付き、追加PoC、見送りに分類して、次の行動を決めることが重要です。

AI基盤の配置条件も併せて確認する

AIエージェントの操作権限だけでなく、データの保存・処理場所、管理者・保守担当者のアクセス条件、監査証跡、継続運用も整理する必要があります。

詳しくは、「オンプレAIなら安全、では足りない｜Private AIの配置を決める6つの判断軸」をご覧ください。同記事では、データ、権限、更新、監査、設備、運用の観点から、Private AIの配置条件を整理しています。

AIエージェントの構成・PoC・運用条件を整理する

既存システムとの接続、Identityと権限、人の承認、監査ログ、運用監視、異常時の制限・停止は、個別ではなく、一連の運用として設計する必要があります。

自社だけで確認範囲や責任分界を決めることが難しい場合は、AI基盤の構成検討、PoC、運用設計について横河レンタ・リースへご相談ください。

お問い合わせ (総合) | 法人向けパソコン (PC) ・計測器レンタルなら横河レンタ・リース