財務部門は、自分たちがリアルタイムで監視できない主体に権限を委ねる方法を、以前から熟知してきた。ただ、その権限をソフトウェアが従える形で文書化してこなかっただけである。
午前2時13分、あるAIエージェントが重複の疑いがあるサプライヤーの請求書にフラグを立てた。支払処理の実行は午前8時だ。このエージェントには3つのアクションを実行するアクセス権限がある。請求書の担当者にメッセージを送る、支払いを保留にする、調査を開始して自力で注文書（PO）の履歴を取得する、の3つだ。技術的には、3つとも実行可能だ。しかし翌朝、周囲に確認しても、そのうちどれを実行することが認められていたのかを答えられる者は誰もいない。
本シリーズの最初の2本は、経済性をテーマにしていた。すなわち、人々に何を手放してもらうのか、そしてその便益にはどれほどの価値があるのかである。本稿のテーマは許可だ。これは、そうした取り組みが実際に機能し始めた瞬間に突き当たる壁である。
同じ問いを人間について投げかければ、数秒で答えが返ってくる。承認マトリクスがあり、職務分掌があり、重要性の閾値があり、取締役会が承認した権限委譲規程がある。更新を楽しむ人はいなくても、誰かが毎年更新している。
一定規模の企業であれば、その文書は必ず存在する。だがそれはたいていPDFであり、人間向けに文章で書かれ、「適切な管理職レベル」といった文言が並ぶ。エージェントはそれを「読む」ことができず、システムもそれを人間ではない主体に対して強制できない。いま財務領域で自律性に上限をかけているのは、モデルの精度ではなく、この点である。
正しいことと、許されていることは同じではない
財務部門はこれまで、ほとんどのAIプログラムが即座に一体化してしまう2つの問いを、常に切り分けてきた。「これは正しいか」と「この主体はそれに基づいて行動することを許されているか」である。
上級会計担当者が科目振替について完全に正しい判断をしていても、それを仕訳計上する権限を持っていないことはある。それは能力への疑義ではなく、設計上の仕組みである。私たちは人間に対して、正しさを許可と見なしてきたことはない。ソフトウェアに対してだけ、なぜそうし始めるのか私にはわからない。実務上は、ある程度そうしてしまっている。確信に満ちた出力は、承認済みのもののように感じられるからだ。
仕訳を起案するエージェントは、生産性向上ツールである。仕訳を計上するエージェントは、統制環境の内側にいる。あなたがそう判断しているかどうかにかかわらず、監査人はそのように扱う。違いは高度さではない。委譲する権限を持つ人物によって、権限が委譲されたかどうかである。
機械が読めるように権限委譲を書き換える
財務チームに必要なのは、また別のガードレール検討会ではない。すでに存在する権限委譲規程を、エージェントが解析でき、統制が照合検証できるものへと書き換えることだ。
学術的な議論では、自律性を人間の側から捉え、オペレーター、協働者、承認者、観察者と位置づける。その直感は有用だが、視点が違う。コード化され、監査される段階はエージェント側のものだ。すなわち、観察、推奨、準備、承認、実行である。
成果物は地味で、1ページほどで足りる。運用しているすべてのエージェントについて、次を明示できるべきだ。
• 識別子
• 業務オーナー（氏名）
• 統制オーナー（氏名）
• 触れてよい取引タイプ
• それぞれにおける自律性のレベル
• 金額上限
• 可逆性の分類
• エスカレーションを強制する条件
• 残す証跡
すでに自社環境で稼働しているエージェントについて、この1ページを提示できないなら、権限のない能力を与えたことになる。それは、財務部門がしてはならないと学んできた数少ない行為にかなり近い。
すべての権限を同じ大きさにすべきではない
権限の大きさは、4つの要素に照らして調整するべきだ。重要性、可逆性、その行為がどれほど十分に理解されているか、そして社外の誰かの目に触れるかどうかである。
少額の社内向け振替で、可逆的かつ定型的で、社外には見えないものであれば、大きな自律性を持たせられる。不可逆的な外部向け支払い、開示情報の入力、顧客や規制当局に関わるものには、テストでモデルがどれほど優れて見えても、ほとんど自律性を与えるべきではない。エージェントは、私たちがすでに人間に対して行っていることを、コンパイル可能な形式で明言するよう迫っているだけである。
統制は先回りしなければならない
私たちの統制の多くは発見的統制である。起きた後に何が起きたかを点検する。そしてそれが機能するのは、ミスと損害の間に人間の速度に基づく時間差があるからだ。誤った計上は一晩そのまま残る。支払いファイルは処理タイミングを待つ。
エージェントはその時間差をなくす。木曜日に問題を発見する統制は、完璧に設計されていても役に立たないことがある。
だから統制は、行為の前に移動する。エージェントはどのデータを使ってよいのか。どのバージョンのポリシーが有効なのか。どの閾値を超えてよいのか。いつレビューが必須となり、いつワークフローを停止するのか。
証跡も変わる。そして人々が過小評価しているのはこの部分である。どのユーザーが承認をクリックしたかを知っても、もはや多くはわからない。エージェントが何を知っていたのか、どのルールを適用したのか、どの権限を持っていたのか、そしてなぜその行為が権限の範囲内に収まっていたのかを再構成する必要がある。プロンプトのログだけではそこまで到達できない。それは意思決定記録であり、いずれ誰かがサンプリングを求めることになる。
そこから、ほとんど答えられていない問いが生じる。モデルが見積もりを出し、エージェントが仕訳を計上した場合、その周辺の統制環境について誰が証明するのか。経営陣はいまも署名する。そして、その署名は、行為者がソフトウェアだったからといって条件付きにはならない。
原則ではなく、2人の名前を挙げる
ガバナンスの議論は、「人間が引き続き説明責任を負う」という結論に落ち着きがちだ。それはよい。では、どの人間なのか。
プロセスオーナーか、モデルオーナーか、コントローラーか、閾値を設定した経営幹部か、四半期末に例外を認めた人物か。原則上は全員が説明責任を負うとき、運用上は誰も説明責任を負わない。私たちは皆、その展開を見てきた。
重要な財務エージェントにはすべて、結果に対する業務オーナーと、権限の枠組みに対する統制オーナーを、それぞれ氏名で定める必要がある。テクノロジー部門はプラットフォームを構築し、運用する。行為者がソフトウェアであるという理由で、財務上の意思決定まで引き継ぐべきではない。
パイロットの前に問うべきこと
長年にわたり、問われてきたのは、システムが統制を自動化できるかどうかだった。いま、より適切な問いは、ソフトウェアにどの権限を委ねる意思があるのかである。デモが見事なものになる前に、そしてワークフローがいつの間にか支援から実行へと移行する前に問うべきだ。
意思決定権限を定義することはブレーキではない。それこそが拡張を可能にする。チームは、機械がどこで行動でき、後に何が存在していなければならないのかを正確に把握できるからだ。
CFOは説明責任をエージェントに委譲することはできない。だがCFOは、エージェントに何を決めさせるのかを、真に精緻に決めることはできる。
ここで提供される情報は、投資、税務、または財務に関する助言ではない。個別の状況に関する助言については、資格を有する専門家に相談すべきである。
