財務部門が AI agent を作った。何段階もの作業を自分で続けて行う AI の助手だ。購買、請求書、支払いを管理する基幹システムである ERP の請求書と発注書を読み、金額や取引先の情報が合わない項目を見つけ、例外を財務の担当者に渡す。テストのとき、手間を省くため、ある財務担当者のアカウントをそのまま使わせた。照会もできたし、修正もできた。ところが誰かが聞いた。「この取引先の銀行口座の情報は、社員本人が変えたのか、AI が変えたのか」。ログには同じ社員のアカウントしかなく、答えられなかった。

2026 年 7 月、AWS は AI agent で SAP などの ERP の例外を扱うやり方を公開した。その設計の要はモデルではなく ID にある。agent が自分で動くときは自分のサービスアカウントでログインし、人が割って入るときは、システムがその人の確認済みの ID に切り替える。あらゆる操作は既定で拒否され、明示的に許したものだけが通る。金額が基準を超えるか、AI の確信が足りないときは、担当者にメールを送り、案件を人の返事待ちにして止まる。どの手順も、追加はできても書き換えも削除もできないログに記録される。

このやり方はどのシステムにも持ち込める。AI が財務のデータに手を出せるようになったら、自分の ID を持たせる。そうして初めて、ログでどれを AI がやり、どれを人が承認したのかを見分けられる。

社員のアカウントを使い回すと、ログでは誰がやったか分からない

社員のアカウントを流用すると、ログの「操作者」は実際に手を動かした者と一致しなくなる。社員が agent を起動し、agent が発注書を調べ、請求書を読み、案件の状態を更新する。あとから見えるのは「某さんが三つの操作をした」だけで、どれを社員自身が頼んだのか、どの続きの手順を agent が自分で選んだのか、データを変える前に人の確認の画面が出たのか、agent が拒否された操作を試みたのかはわからない。

権限を取り上げるのも難しくなる。agent だけを止めたくても、社員と ID を共有しているので、社員の普段の仕事まで一緒に止めるしかない。

自分の ID、既定で拒否、基準を超えたら人へ

自分の ID： システムがこの ID を単独で認可し、止め、照会できなければならない。表示名に「Bot」を付けるだけでは足りない。ID は一つの用途に結び付ける。たとえば「買掛金の請求書の例外処理」で、財務部全体で共用する AI のアカウントにはしない。権限を承認し、警告に対応し、ID を止められる担当者を一人決める。回して取り消せる機械用の認証情報を使い、社員のパスワードを agent に渡さない。

既定で拒否： まずすべてを禁じ、必要な操作を一つずつ開ける。AWS の例では、どの発注書も読んでよいが、仕訳の計上は 5 万ドル未満に限っている。AWS の公式の文書によれば、その認可の規則は、どの許可にも当てはまらない要求をすべて拒否し、明示的な禁止はいつでも許可より優先される。

基準を超えたら人へ： agent が必ず止まって人に渡す場面をはっきり書く。たとえば金額が重要性の基準を超えるとき、取引先の銀行口座の情報を変えるとき、AI が自分の確信が足りないと判断したとき。人に渡すときは、「確認してください」と投げるだけでなく、根拠と提案を添える。

ID は会話で名乗らせるのではなくシステムで確かめるべき理由は、AI サポートにアカウントを変更させる前に、本人確認は会話ではなくシステムで行うを参考にしてほしい。複数のシステムをまたぐとき、立ち寄る先ごとに権限をどう替えるかは、AI agent がシステムをまたいで動くなら、立ち寄る先ごとに新しい鍵に替えるも参考になる。

広告

まず少数の例外で、読み取りだけの試行をする

最初から agent に本番のデータを変えさせないこと。すでに処理済みの例外を少し選び、agent に自分の ID で読み取りだけで一通り流させ、その判断が財務の担当者の実際の処理と合っているかを比べる。そのうえで、ログが agent の操作と人の操作を分けられているか、拒否された試みが記録に残っているかを確かめる。これがすべて見えるようになってから、修正の権限を一つずつ開ける。

ID を分けても、判断が正しくなるわけではない

自分の ID を持たせれば責任はたどれるが、agent の判断が正しいことまでは保証しない。基準を高くしすぎればリスクがすり抜け、低くしすぎればどの案件も人に回って、自動化の意味がなくなる。基準は財務の責任者が会社の重要性の基準に沿って決め、人に回った案件の割合を定期的に振り返る。

また、この記事が扱っているのはやり方で、特定の製品の推薦ではない。ERP や ID のシステムによって実装は違う。大事なのは「誰がやったか見分けられる」と「許していないことはできない」の二つの原則だ。

AI 整理カード

AI agent に ERP の例外（請求書の不一致、支払いの例外など）を扱わせる予定なので、先にその ID と権限を設計しておきたい。
判断方法はこの記事による：https://boosterminiclass.com/ja/posts/erp-agent-separate-identity-deny-by-default/
記事の見方はこうだ。AI agent に社員のアカウントを流用させてはいけない。そうするとログで人がやったか AI がやったかを見分けられず、AI だけを止めることもできない。agent に自分の ID を持たせ、すべての操作を既定で拒否して一つずつ開け、金額が基準を超えるか確信が足りないときは止まって人に渡すようにする。

まず私に聞いてほしい。agent がどんな種類の例外を扱うか、どのデータを読むか、どのデータを変えうるか、いまどのアカウントでテストしているか。
そのうえで：
1. agent の ID の設計を示す。用途の名前、サービスの範囲、担当者、認証情報の種類と回し方；
2. 既定で拒否する権限の一覧を書く。明示的に許す読み取りと修正の操作、それぞれの条件（金額の上限など）、明示的に禁じる操作（取引先の銀行口座の情報の変更など）；
3. 必ず止まって人に渡す場面と、渡すときに添える情報を挙げる；
4. 読み取りだけの試行を設計する。どの処理済みの案件を使い、何を比べ、ログで何が見えるべきか。
基準の金額は「財務の責任者が決める」とし、自分で数字を決めないこと。
広告

Share

このミニクラスを共有

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

参考資料