AIエージェントの統制をどう考えるか

AIエージェントが業務を進めるようになると、少し新しいことが起きているように見える。

人が画面を開いて入力する代わりに、AIが情報を読み、分類し、候補を出し、場合によってはツールを呼び出す。

でも、業務として見たときの問いは、実はそれほど変わらない。

人間が処理しても、AIが処理しても、内部統制で見たいことは同じである。

その取引は本当にあるのか。

必要なデータは漏れなく記録されているのか。

金額、日付、人数、宛先は正しいのか。

その人、またはそのAIに処理する権限はあるのか。

正しい期間に記録されているのか。

あとから見たときに、誰が、何を根拠に、どう判断したか説明できるのか。

作業者が人からAIに変わっても、この問いは消えない。

変わるのは、証明の仕方である。

これは、AIを使いすぎてから慌てて統制を足す、という話ではない。

むしろ逆である。

内部統制やEUCを見てきた人間からすると、AIエージェントは最初から「便利なツール」であると同時に「業務プロセスに入り込む新しい処理主体」に見える。だから、画面や会話の体験を軽く作るときほど、その裏で何を記録し、どこで止め、誰が承認するかを先に考えたくなる。

野良マクロと、野良AIプロセス

昔から、現場には小さな自作ツールがあった。

Excelマクロ、スプレッドシート、GAS、個人が作った集計ファイル。

内部統制の文脈では、こうしたものはEUC、つまりエンドユーザーコンピューティングとして扱われることがある。ざっくり言えば、情報システム部門ではなく、業務部門の人が自分たちで作って使うツールである。

大事なのは、誰が作ったかではない。

そのツールが、業務プロセスの中で何に使われているかである。

個人が作ったマクロでも、請求書の発行、売上計上、売掛金の確認に使われていれば、ただの個人メモでは済まない。出力が業務や財務報告に影響するなら、管理の対象になる。

この考え方は、AIにもそのまま当てはまる。

個人がAIチャットで文章を整えるだけなら、影響は小さいかもしれない。

でも、毎月の請求データチェックにAIを使う。問い合わせをAIが分類し、その分類をもとに対応順を決める。GASやSalesforceフローの中に、AIが作ったロジックやプロンプトが埋まる。

そうなると、これはもう単なる個人利用ではない。

業務プロセスの一部である。

AIは、マクロより見えにくい

AIが厄介なのは、見えにくいことだ。

マクロなら、少なくともファイルとして存在する。誰かが作った .xlsm がある。セルがあり、式があり、ボタンがある。

もちろん、それでも管理は難しい。

ただ、存在には気づきやすい。

一方で、AIはもっと静かに入り込む。

GASの中でLLM APIを呼んでいる。Salesforceのフローの途中でAIが分類している。問い合わせの返信案を出すプロンプトが、どこかの設定ファイルに入っている。

コードや設定を読まない限り、後から見た人には「ここでAIが判断している」と分からないことがある。

さらに、AIの出力は自然言語である。

表のセルや計算式のように、ぱっと見て検証しやすい形ではない。もっともらしい文章として混ざる。判断の材料として、会議資料やチャットや台帳に入ってくる。

ここが怖い。

AIが危ないというより、AIが業務に入っていることに気づかないまま、判断だけが進んでしまうことが危ない。

入力統制だけでは足りない

AIエージェントを組織で使うなら、まず入力側を管理する必要がある。

どのAIを使ってよいのか。

どのプロンプトが正式版なのか。

誰が変更してよいのか。

どのツールを呼び出せるのか。

誰の権限で動くのか。

これは、ITGCに近い感覚で見られる。アクセス管理、変更管理、運用管理、ログ管理。つまり、AIが動く土台を管理する話である。

プロンプトやスキルも、野良のまま増えると危ない。

誰かが便利だから作ったものが、いつの間にか複数人に使われ、業務の前提になる。作った本人が異動したあと、誰も中身を説明できない。

これは野良マクロと同じ問題である。

だから、AIにも台帳がいる。

どの業務プロセスにAIが入っているのか。何を読んでいるのか。何を出しているのか。誰が管理者なのか。どこまでが人間確認なのか。

まず見えるようにする。

ここでいう台帳は、手で更新する一覧表だけを意味しない。

プロンプトや設定をGitで管理する。変更はレビューを通す。実行ログや承認ログを自動で残す。CIで危ない変更を止める。そうした仕組みも含めて、後から追える状態を作るという意味である。

ただし、入力側を管理するだけでは足りない。

AIは、同じ入力でも出力が揺れることがある。モデルが変わる。プロンプトの効き方が変わる。外部情報の取り方が変わる。人間が読んだときの解釈も変わる。

マクロのように、テストデータを流して同じ結果が返ることだけでは担保しきれない。

だから、出力側の監視が必要になる。

出力は、全部見るのではなく、見る場所を決める

AIの出力を全部人間が見る、という運用は続かない。

最初はできても、件数が増えたら詰まる。人間は承認ボタンを押すだけになり、結局何も見なくなる。

内部統制の考え方は、もともと「全部を目視する」ためのものではない。

リスクの高いところを見る。

例外だけを浮かび上がらせる。

サンプリングする。

キーコントロールを決める。

この考え方は、AIエージェントにも使える。

たとえば、AIが請求書を読み取るなら、全件を同じ重さで見る必要はないかもしれない。

高額なもの、初めての取引先、通常と違う支払条件、過去データとズレるもの、AI自身の確信度が低いもの。

そういうものを人間に戻す。

逆に、低リスクで、ルールに合い、過去パターンとも一致するものは、決まった範囲で流す。

ここで大事なのは、AIを信じるかどうかではない。

どの出力を見れば、業務全体のリスクを下げられるかを設計することである。

AIがやっても、アサーションは同じ

会計や監査で見るアサーションは、AIになっても消えない。

実在性。

網羅性。

正確性。

権利と義務。

期間帰属。

表示と開示。

言葉は少し硬いが、業務の言葉にすると分かりやすい。

その予約は本当に入っているのか。

必要な予約が漏れなく台帳に入っているのか。

人数、日付、連絡先は正しいのか。

その人、またはそのAIに予約を確定する権限はあるのか。

正しい開催日、正しい受付期間に入っているのか。

あとから見たときに、どういう経緯でその状態になったか分かるのか。

これらは、人間が処理しても、AIエージェントが処理しても同じである。

だから、AIエージェントの設計で必要なのは、「AIだから特別にゆるくする」ことではない。

人間作業で見ていた問いを、AI作業でも見えるようにすることだ。

変わるのは、証跡の粒度

人間が作業する場合、証跡は比較的分かりやすい。

誰が入力したか。誰が承認したか。いつ変更したか。どの画面で操作したか。

AIエージェントの場合は、そこにもう少し情報が増える。

誰の代理で動いたのか。

どのエージェントが処理したのか。

どの入力データを読んだのか。

どのプロンプト、どのモデル、どのツールを使ったのか。

どの検証を通ったのか。

どこで人間が承認したのか。

これが残っていないと、あとから説明できない。

「AIがやりました」では、証跡にならない。

「人の代理で、特定の権限を持ったAIが、特定の入力をもとに処理し、検証を通り、この人が承認した」

ここまで言えて、ようやく業務に入れられる。

小さく作ることと、統制を捨てることは違う

AIを使うと、業務改善はかなり小さく始められる。

チャットに通知を流す。予約の文面を作る。問い合わせを分類する。台帳の更新案を出す。

こうした小さな仕組みは、現場に合う形を見つけるうえで役に立つ。

ただし、小さく作ることと、統制を捨てることは違う。

画面は薄くていい。

入口は簡単でいい。

最初は既存のスプレッドシートやチャットの上に乗せてもいい。

でも、権限、承認、台帳、変更履歴、外部送信、請求、公開、削除は軽く扱わない。

そこを軽くすると、便利な実験がそのまま業務事故になる。

AIエージェントを、内部統制の対象として見る

AIエージェントを導入するということは、単に便利なツールを増やすことではない。

業務プロセスの中に、新しい処理主体が入るということである。

だから、見るべき問いは変わらない。

その処理は実在するか。

漏れなく記録されているか。

正確か。

権限はあるか。

承認はあるか。

証跡は残るか。

そして、AIが関わっていることを、後から見つけられるか。

AI活用で本当に必要になるのは、最新ツールをどれだけ知っているかだけではない。

AIが業務に混ざったとき、どこを統制対象として見るべきか。

その目を持てるかどうかだと思う。