AIエージェントに何を任せるか：経理・支払業務の権限表を作る

以前の記事で、経理のどこまで生成AIに任せるかを、判断、検証可能性、可逆性の3つの基準で切り分けました。あの記事は、AIが文章や下書きを作ることを前提にしています。

状況が変わってきました。AIがシステムに接続し、データを参照し、仕訳を登録し、取引先へ連絡し、支払や申告につながる操作を行う構成が現実的になっています。下書きを作るAIと、操作を実行するAIでは、必要な統制が違います。

この記事では、経理と支払の業務について、AIに与える権限をどう設計するかを扱います。製品名に依存しない形で書きます。

導入は進み、統制は追いついていない

デジタル庁の先進的AI利活用アドバイザリーボードに、AIガバナンス協会が2026年7月14日に提出した資料があります。同協会の正会員55社からの回答として、40社でAIエージェントのユースケースが存在するとされています。

一方で、自律性の高いAIへの取組についてのスコアは、開発者・提供者の平均が4点満点で1.73点、利用者の平均が1.64点と、全体平均の2.72点を下回っています。これは提出者による会員企業への調査であり、母集団に偏りがある点は割り引いて読む必要がありますが、導入が先行し統制が後追いになっている構図は、実務の感触と一致します。

同じ資料は、AIエージェントのガバナンスとして、展開の初期段階でリスクを評価しエージェントの行動範囲を設計により制限すること、エージェントが自律的に行動しても最終的な責任は人間と組織が持つこと、開発から運用までの技術的な対策、そしてエンドユーザーが責任を持って利用できるようにするための支援、の4点を挙げています。

このうち、いま各社が手を付けられるのは1つ目の行動範囲の制限です。

業務名ではなく動作で分解する

「経理を任せる」という単位で権限を考えると、設計できません。経理という言葉が指す範囲が広すぎるためです。

代わりに、動作の単位に分けます。経理と支払の業務であれば、次の8つで大半が表現できます。

閲覧、抽出、作成、登録、承認依頼、外部送信、支払実行、申告。

閲覧はデータを見ること、抽出は集計や検索の結果を取り出すこと、作成は仕訳や書類の下書きを作ること、登録は会計システムへ実際に書き込むこと、承認依頼はワークフローを起動すること、外部送信は取引先や金融機関へメールやデータを出すこと、支払実行は振込データの作成と実行、申告は電子申告の送信です。

この8つに対して、AI、担当者、承認者、システム管理者のそれぞれが何をしてよいかを表にします。列が主体、行が動作の表です。埋めていくと、どこが空欄のまま運用されているかが見えます。

線を引く場所

すべての動作を同じ基準で扱う必要はありません。実務上、明確に分けるべき境目が2つあります。

1つ目は、読み取りと書き込みの間です。閲覧、抽出、作成までは、間違えてもやり直せます。登録から先は、記録が残り、後続の処理に影響します。

2つ目は、社内で完結する処理と、社外に影響が出る処理の間です。外部送信、支払実行、申告は、実行された時点で取り消せません。誤った振込データを作れば資金が出ますし、誤った申告を送信すれば修正申告が必要になります。

原則として、まずは閲覧、抽出、下書きに権限を限定し、登録は条件付き、外部送信から先は人の明示的な承認を必須にする、という段階を置きます。

ただし、閲覧と下書きであっても無条件ではありません。AIがアクセスできるデータの範囲、接続先のシステム、入力したデータが保存されるか学習に使われるかという条件を確認したうえで権限を与えます。読み取りだからリスクがない、とは言えません。

特に注意する操作

会計事務所の立場から見て、事故が起きたときの影響が大きいのは次の操作です。権限表を作るときは、この5つを先に埋めることをお勧めします。

取引先マスタの変更。特に振込先の銀行口座情報の変更です。ここを変更できる権限と、支払を実行できる権限を同じ主体に与えると、職務分掌が成立しません。AIエージェントに限らず、人間の担当者についても同じです。

一定金額を超える支払。金額の閾値を決めて、閾値を超えるものは人の承認を必ず経るようにします。閾値は、月次で発生する支払の分布を見て決めます。全体の9割が閾値以下に収まる水準では、統制として機能しません。

税務申告の送信。電子証明書を使う操作をAIに委ねるべきではありません。

なお、他社から受託した申告書等の作成や送信を扱う場合は、権限表の設計だけでは足りません。人の承認を置いても税理士法上の問題は解消しないため、自社の申告であるか、税理士または税理士法人の管理下で行われる業務であることを前提にしてください。

月次締めの解除。締めた後の期間に遡って仕訳を入れられる操作は、記録の信頼性に直結します。

会計期間をまたぐ修正仕訳。決算整理の性質を持つ処理は、判断を伴います。

AI用のIDを分ける

権限表ができても、実行の記録が取れなければ意味がありません。

AIエージェント用のアカウントを、担当者個人のIDと共用しないでください。共用すると、ログ上はその担当者が操作したことになり、誰が指示し、誰が承認し、何が実行されたのかを後から分けられなくなります。

記録しておきたいのは4つです。実行した主体、指示を出した人、承認した人、実行の結果。この4つが揃っていれば、事故が起きたときに経緯をたどれます。

AIエージェントが複数のシステムを横断するようになると、従業員単位の権限棚卸しでは足りなくなります。人ではないIDについて、誰が管理しているか、いつ棚卸しするか、退役させるときにどう権限を失効させるか、緊急時にどう停止するかを決めておく必要があります。この領域はまだ標準的な水準が定まっておらず、製品の仕様と自社の業務リスクに応じて設計することになります。

参考にする枠組みと、その限界

NISTのAI Risk Management Framework 1.0は、人間とAIの構成および監督に関する役割と責任を区別する方針と手順を求めています。生成AI固有のリスクについては、Generative Artificial Intelligence Profileが補足しています。

国内では、デジタル庁が生成AIの調達・利活用に係るガイドラインの第2.0版を2026年6月12日に公表しています。ただしこれは行政機関向けの規範文書であり、民間企業を直接拘束する法令ではありません。

これらをそのまま社内規程に転記しても機能しません。自社の金額的な重要性、法定期限のある手続き、既存の職務分掌、使っているシステムの権限機能に合わせて、先ほどの権限表へ翻訳する作業が要ります。翻訳しない限り、現場は何をしてよいか判断できません。

権限は段階的に広げる

最後に、精度と権限を混同しないことです。

AIの出力精度が高いことと、実行権限を広げてよいことは別の判断です。精度99％の処理でも、100件に1件の誤りが振込であれば、影響は精度の数字では測れません。

権限を広げる判断には、実績の数字を使います。AIが処理した件数のうち、人が差し戻した割合、例外として人が処理した割合、誤りが本番まで通った件数。この3つを月次で見て、安定していることを確認してから次の動作へ広げます。

仕訳の登録をAIに任せる前提として何を決めておくべきかは、AIに仕訳を任せる前に決めておくことで整理しています。権限表を作る前に、判断基準そのものが決まっているかを確認してください。

まとめ

AIエージェントを導入するときは、業務名ではなく、実行できる動作とデータの範囲を一つずつ定義してください。読み取りと下書き、外部送信とマスタ変更と支払と申告では、置くべき統制が違います。

後者には人の明示的な承認と、改変できない記録を置きます。AI用のIDを個人と分け、実行主体、指示者、承認者、結果を追跡できる状態にします。そして権限は、差戻し率と例外率を見ながら段階的に広げます。他社から受託した申告業務が絡む場合は、税理士法上の位置づけを先に確認してください。

自社の業務にどう当てはめるかについては、現在の職務分掌と使用しているシステムの権限機能を前提に検討する必要があります。ご相談ください。

参考

• デジタル庁 先進的AI利活用アドバイザリーボード（AIガバナンス協会提出）「AIエージェントのガバナンスをめぐる動向」（2026年7月14日）
• デジタル庁「行政の進化と革新のための生成AIの調達・利活用に係るガイドライン（第2.0版）」（2026年6月12日）
• NIST「Artificial Intelligence Risk Management Framework (AI RMF 1.0)」
• NIST「Generative Artificial Intelligence Profile (NIST AI 600-1)」