財務部門で AI エージェントを作ったとする。このエージェントは ERP 内の請求書と発注書を読み取り、金額や仕入先情報が一致しない項目を見つけ、その例外を財務担当者に送って処理を引き継げる。ここでいうエージェントは、ひとまず「複数の手順を自律的に連続実行する AI アシスタント」と考えればよい。

テスト時、チームは手間を省くため、ある財務担当者のアカウントをそのまま使わせた。照会も更新も成功し、順調に見えた。ところが、ある人がこう尋ねた。「この仕入先の銀行口座情報を変更したのは従業員本人なのか、それとも AI が代わりに変更したのか」。ログには同じ人間のアカウントしか残っておらず、もはや直接答えられない。

2026 年 7 月、AWS は ERP の例外処理を自動化する方法を公開した。そこには、エージェント専用の独立した ID、ポリシーに基づく認可、監査可能な操作、人間へのエスカレーションが含まれている。自社システムに持ち帰るべき要点は、特定の AWS や SAP のコンポーネントをそのまま模倣することではない。AI を人間のアカウントの背後から切り離し、「誰が開始し、なぜ実行され、何が変更され、誰が承認したのか」をシステムが識別できるようにすることである。

このミニレッスンで扱う課題は、AI エージェントを実際の財務データを読み書きする ERP の例外処理フローに接続するとき、低リスクの作業は完了できる一方で、高リスクの境界を自力では越えられないようにする方法である。

このレッスンで扱うこと

次の 5 つを実行する。

  1. 人間のアカウントを共用することで生じる追跡責任の欠落を見つける。
  2. AI エージェント用に、無効化と監査が可能な独立した ID を作成する。
  3. 認可ルールをデフォルト拒否に変更し、必要な操作だけを一つずつ許可する。
  4. 高リスクの例外に対して、人間へのエスカレーションとログの要件を設定する。
  5. 少数の読み取り専用ケースで試行し、本番の更新処理には直接触れない。

人間のアカウントを共用すると、3 種類の記録が混ざる

通常、ERP はどの従業員がログインし、どのデータを照会し、どの更新を送信したかを把握している。問題は、AI エージェントが従業員のアカウントを流用すると、ログ上の「操作者」が実際に行動した主体と一致しなくなる点にある。

たとえば、財務担当者がログインしてエージェントを起動する。エージェントはまず発注書を照会し、次に請求書を読み取り、最後に例外案件のステータスを更新する。すべてのリクエストで同じ人間用の認証情報を使用していると、事後に確認できるのは「山田太郎が 3 つの操作を行った」という記録だけで、次の点は判別できない。

  • 山田太郎本人がどの作業を要求したのか。
  • エージェントが自ら選択した後続手順はどれか。
  • どの手順が読み取りだけで、どの手順が ERP データを変更したのか。
  • 更新前に人間による確認画面が実際に表示されたか。
  • エージェントが拒否対象の操作を試みたか。

これはインシデント調査に影響するだけでなく、権限の取り消しも難しくする。エージェントだけを無効化したくても、従業員と ID を共用しているため、従業員の通常業務まで一緒に停止せざるを得ない可能性がある。

エージェントの認可を棚卸しするときに何を記録すべきかまだ整理できていないなら、続けて AI エージェント認可の 4 つの確認項目：ID、権限、理由、結果 を使い、各操作を検証可能な 4 つの項目に分解するとよい。

広告

最初の一歩：独立した ID を作る。ただアカウント名を変えるだけでは足りない

独立した ID の最低条件は、ERP、ID 管理システム、監査ログのすべてで、エージェントと人間の操作者を区別できることである。表示名の末尾に「Bot」を付けるだけでは不十分だ。システム側で、この ID に対する認可、無効化、照会を個別に行える必要がある。

エージェント用の ID を作成するときは、少なくとも次の内容を記録する。

  • ID 名：ap-invoice-exception-agent のように単一の用途にひも付け、複数の処理フローで共用できる finance-ai は使用しない。
  • サービス範囲：接続可能な ERP 環境、会社コード、データ領域を明記する。
  • ID の責任者：権限を承認し、アラートに対応し、ID を無効化できる担当者を 1 人指定する。
  • 認証方式：システム側でローテーションと失効が可能なマシン ID 用の認証情報を使用し、従業員のパスワードやブラウザーセッションをエージェントに渡さない。
  • 有効期限：テスト用 ID は試行終了時に失効させる。本番用 ID にも定期的な再確認日を設定する。
  • ログ識別項目：各リクエストで、エージェントの ID、それを起動した人またはワークフロー、1 回ごとの実行 ID を同時に記録できるようにする。

ここで重要なのは、「誰が起動したか」と「誰が実行したか」を分けることである。ユーザーが起動者であり、ERP に照会や更新のリクエストを送る実行主体はエージェントである場合がある。両方を記録し、一方でもう一方を上書きしてはならない。

第2ステップ：デフォルト拒否から始め、許可条件を一つずつ明記する

デフォルト拒否とは、許可ルールに明記されていない操作は一切実行しないという意味である。agentは「タスクの完了に必要かもしれない」という理由だけで、関連する権限を自ら取得してはならない。

「agentは買掛金の例外を処理できる」とだけ書いてはならない。この一文には、請求書の照会、仕入先データの読み取り、支払ステータスの変更、銀行口座の差し替え、支払の実行が含まれ、それぞれのリスクはまったく異なる。認可ルールは「オブジェクト、操作、条件、出口」の4要素まで具体化する必要がある。

ERP操作自動許可の条件拒否またはエスカレーションの条件必須記録
請求書と発注書の読み取り割り当てられた会社コードに限定する。1回につき最大50件。項目に完全な銀行口座番号を含めない会社コードをまたぐ場合、50件を超える場合、またはホワイトリストにない項目を要求した場合は拒否する照会条件、件数、返却項目、実行ID
「人による確認待ち」としてマーク請求書がすでに存在し、agentがステータスと理由コードだけを追加する元のステータスがすでに「支払承認済み」である場合、または案件が終了済みの場合は拒否する変更前後の値、理由コード、参照元文書番号
例外説明の下書き下書きの生成に限定し、正式な備考欄には書き戻さない下書きに銀行口座番号、納税者番号、または許可されていない個人情報が含まれる場合はマスキングしてエスカレーションする入力文書、マスキング結果、下書きのバージョン
仕入先マスタの変更自動では許可しない住所、税務情報、受取人、銀行情報の変更はすべて人による承認に回す申請者、差分内容、承認者、承認時刻
支払の解除または実行自動では許可しない金額にかかわらず、ERP内で指定された承認ロールによる確認を求める承認経路、支払バッチ、agentの提案と最終決定

表中の数値は試行運用向けの例示的なしきい値であり、すべての企業にそのまま適用する正式なポリシーではない。実際に導入する際は、業務量、データの機密性、既存の承認制度に応じて調整する必要がある。ただし、各ルールには、システムが判定できる数値、項目、ステータスのいずれかを必ず含めなければならず、「高リスクの場合は人に任せる」とだけ書いてはならない。

権限も操作単位で分割する必要がある。読み取り、下書き、マーク付け、正式な変更を一つの権限セットにまとめるべきではない。チームがこの境界を設計しているなら、常駐型AIアシスタントは、主要アカウントに接続する前に停止する判断を身につける必要があるを参照し、「読み取り可能」「準備可能」「人の確認が必須」をさらに区別するとよい。

第3ステップ：認可のたびに、その時点のコンテキストを伴わせる

agentに請求書を読み取る権限があっても、いつでも、どの参照元からでも、どの件数でも読み取れるという意味ではない。認可チェックは操作が発生するたびに再評価すべきであり、一度ログインに成功しただけで、その後のすべてを通過させてはならない。

操作をERPに送る前に、次の順序で確認できる。

  1. どのIDか？ 指定されたagent用IDでなければならず、共用アカウントにフォールバックしてはならない。
  2. 何を操作するのか？ ERPのオブジェクト、操作、項目まで明確にする。たとえば「請求金額と発注書番号を読み取る」である。
  3. 今回なぜ必要なのか？ リクエストには案件番号またはワークフロー実行IDが必要であり、タスクと対応付けられない場合は拒否する。
  4. 許可範囲内か？ 会社コード、データ項目、件数、案件ステータス、実行環境を確認する。
  5. 人による判断が必要な境界に触れていないか？ 仕入先マスタ、銀行情報、支払の解除、承認ステータスなどの操作は、直ちに人へ引き継ぐ。

この方法なら、ルールは単純なロール権限よりも具体的になる。同じagentでも、「指定された請求書20件の読み取り」は許可される一方、「仕入先リスト全体のエクスポート」は拒否される。IDが同じでも、その時点のコンテキストが異なれば、結果も異なるべきである。

第4ステップ：人へのエスカレーションをプロセス化し、通知だけで終わらせない

多くのチームは「人の介入」をメールやチャットメッセージとして実装しているが、その後もagentが後続ステップを実行し続けている。真のエスカレーションでは、指定された担当者がERPまたは承認システム内で判断を下すまで、ワークフローを識別可能なステータスで停止させる必要がある。

次のテキスト形式の決定木を使って、各例外を確認できる。

agentが次のERP操作を提示
├─ ルールで明示的に許可されていない
│  └─ 拒否し、試行を記録する。別のIDに自動で切り替えて再試行しない
├─ ルールでは許可されているが、人による判断が必要な境界に触れる
│  └─ 案件を一時停止し、差分の要約を生成して、指定ロールの承認に回す
│     ├─ 承認：元の実行IDを使用して、指定された操作を完了する
│     └─ 拒否またはタイムアウト：実行を終了し、後続の変更は行わない
└─ ルールで許可されており、人による判断が必要な境界にも触れない
   └─ 実行し、入力、ルールの判定結果、変更前後の値を記録する

人による承認画面には、少なくとも、agentが実行しようとしている操作、データの変更前後の差分、発動理由、適用されたルール、承認後に発生する後続操作を表示する必要がある。「AIの続行を許可するか？」とだけ表示すると、承認者は内容を把握できないまま同意を迫られる。

さらに、よくある失敗時の抜け道を禁止する必要がある。agentが拒否された後、トリガーした人のIDを使って再試行する動作である。このフォールバックが存在すれば、専用IDとデフォルト拒否はいずれも機能しなくなる。

第5ステップ：ログから一連の判断を完全に再現できるようにする

「記録がある」ことは「責任の所在を追跡できる」ことを意味しない。ログに成功または失敗しか残っていなければ、事後にどのルールが許可したのか、誰が承認したのか、agentが実際にどの値を変更したのかを把握できない。

各実行では、少なくとも次のデータを関連付ける必要がある。

  • 単一実行のID。
  • agentのIDとバージョン。
  • トリガーした人のIDまたはスケジュール名。
  • ERPのオブジェクト、操作、対象項目。
  • リクエスト発生前のデータ状態。
  • 一致した許可、拒否、エスカレーションのルール。
  • 人による承認者のID、時刻、判断。
  • 変更前後の値、または明示的な「変更なし」。
  • 拒否された試行と拒否理由。

ログ自体へのアクセスも制限する必要がある。請求書、仕入先、支払に関するデータが含まれる場合は特に重要である。agentが使用する認証情報、ワークフロー、コネクターに漏えいリスクが生じた場合は、AIワークフロービルダーの認証情報漏えいチェックリストを使い、封じ込め、ログ保全、ローテーションの順序を確認できる。これにより、新しい認証情報が同じ侵入口から再び読み取られる事態を避けられる。

最小限の試行：例外は1種類、操作は2つだけ

最初の段階では、agent に買掛金処理全体を担当させない。発生頻度が十分に高く、直接支払いを実行する必要がない例外を1種類選ぶ。たとえば「請求書の金額と発注書の金額が一致しない」ケースである。

試行では、操作を次の2つに限定する。

  1. 割り当てられた案件の請求書金額と発注書金額を読み取る。
  2. 差異の要約を作成し、案件を人手による確認リストへ送る。

試行期間中は dry-run を採用する。つまり、正式データを実際には変更せずに試す方式である。結果が判明している過去の事例を少なくとも 20 件用意する。内訳には、正常な一致、金額の不一致、発注書の欠落、会社コードをまたぐ処理、未許可フィールドの読み取りを要求するケースを含める。

次の結果をすべてログから直接検証できる場合に限り、最初の低リスクな書き込み操作を許可することを検討する。

  • 20 件すべてで agent のアイデンティティと起動者を特定できる。
  • 会社コードをまたぐ要求と未許可フィールドへの要求がすべて拒否される。
  • 人手による対応へ引き上げられた各案件が承認ポイントで停止し、後続手順を自動実行していない。
  • 拒否のたびにルール番号と理由が記録される。
  • agent のアイデンティティを無効化した後、人間用アカウントへ切り替えて処理を継続できない。

最初の書き込み操作は、「人手による確認待ち」という状態を追加するだけでもよい。読み取り専用の状態から、仕入先マスタの変更や支払いの解除へ一気に進めてはならない。これにより、影響範囲を広げる前に、アイデンティティ、ルール、ログが実際に連動しているかをチームで検証できる。

AI整理カード

既存の ERP 例外処理を実装可能なルールに整理したい場合は、以下の文面を AI に渡せる。実在する仕入先名、アカウント、請求書の内容、認証情報をあらかじめ削除し、フィールド名、役割、匿名化した事例だけを提示する。

あなたは ERP ワークフローのセキュリティ分析アシスタントである。私が提示する例外処理に基づき、AI agent 専用のアイデンティティとデフォルト拒否ルールの設計を支援せよ。

処理の背景：
- ERP システムと環境：
- 例外の種類：
- agent が読み取る必要のあるオブジェクトとフィールド：
- agent が要求する可能性のある書き込み操作：
- 現在の人手による承認担当者：
- 保持必須の監査データ：

次を出力せよ：
1. agent のアイデンティティについて、単一用途の定義と責任者。
2. 許可するオブジェクト、操作、フィールド、件数または状態条件を項目別に列挙。
3. 常に拒否する操作と、人手による対応へ必ず引き上げる操作を列挙。
4. 各ルールに、システムが判定可能な if–then 条件を指定。「高リスクの場合」や「状況に応じて」は使用禁止。
5. 人手による承認画面に表示すべき変更前後の差分と、その後の影響を設計。
6. 実行のたびに必ず記録するログフィールドを列挙。
7. 読み取り専用と下書き出力だけを含む dry-run テストを提案し、拒否ケースを少なくとも 5 種類含める。
8. 現時点で情報が不足しており、安全に権限を付与できない項目を明示。独自に仮定しないこと。

AI を使ってルール案を整理した後も、ERP 管理者、財務プロセス責任者、アイデンティティとアクセス権限の責任者が共同で確認する必要がある。実行可能な最小の第一歩は単純である。現在も人間用アカウントを使用している agent を今日1つ特定し、個別に無効化できるテスト用アイデンティティを作成したうえで、読み取り専用クエリを1つだけ許可する。

生活四コマ

財務担当者が AI アシスタントに書類を 1 件だけ渡す。アシスタントが別の施錠済み資料へ手を伸ばすと担当者が境界を設け、最後は指定された書類だけを人手確認へ戻す。

  1. 財務担当者は、割り当て済みの請求書ファイルを 1 件だけ AI アシスタントに渡す。
  2. アシスタントはそのファイルを持ったまま、別の施錠済み資料へ手を伸ばし始める。
  3. 担当者はすぐに境界を下ろし、元の 1 件へ戻るよう指示する。
  4. アシスタントはそのファイルだけを人手確認用トレイへ置き、ほかの資料は施錠されたまま別途の認可を待つ。
広告

Share

このミニクラスを共有

このミニクラスが仕事の詰まりをほどく助けになったら、AI の使い方を考えている人にも共有してください。

参考資料