こんにちは。皆さま、いかがお過ごしでしょうか？

“室長”こと吉島良平（Microsoft MVP for Business Applications　|　Microsoft Regional Director）です。

ラグビーのトップリーグのシーズンが終わり、いよいよサッカーのワールドカップが始まりました！

日本はグループFですか。オランダ・スウェーデン・チュニジアと同じグループのようです。

初戦の相手はオランダ。キックオフは、月曜日の朝5時。

皆さん、今日は20時には布団に入って、早起きしましょうね♪

直前まで、いろいろとあった代表チームですが、今の実力であれば、何処の国が相手だろうと、勝てなくはありません。

サッカーを見ていると、いつも考えさせられることがあります。

それは、「どこで判断し」「どこに責任を持ち」「どこに価値を出すのか」ということです。

ピッチの上では、一瞬の判断が試合の流れを変えます。

そして、その判断の結果は、誰かが責任を持ち、チーム全体の価値として現れる。

これは、ビジネスにおいても全く同じです。

では、

その判断や責任を、“人ではなくAIエージェント”が担うようになったとき、

私たちは何をもって「責任を果たした」と言えるのでしょうか。

職業病でしょうか。こんなことをよく考えます。

“監査対応という言葉は、あと何年残るのでしょうか”

ちょっと前に、「エージェントを信頼できるか—ログ・監査・コンプライアンスの設計」というブログを書きました。多くの方に読んでいただけたようです。ありがとうございました。

昨日は「請求も、発注も、提案も消えない、それでも“仕事をするのは人ではなくなる” ｜ Dynamics 365が変える企業間取引の新しい当たり前」というブログで、3年‐5年先を見据えて書きました。

本稿は、5年‐10年先の実現をイメージしながら書いていこうと思いますので、最後までお付き合いいただけますと幸いです。

第1章｜監査という“イベント”だった時代

では、少しだけ視点を変えてみましょう。

これまで、私たちは監査というものを、どのように捉えてきたのでしょうか。

多くの企業にとって、監査とは、

日常業務とは切り離された、年に一度、あるいは四半期ごとに訪れる「特別なイベント」だったのではないでしょうか。

その時期になると、業務の優先順位は一気に変わります。

• 監査法人から届く大量の依頼
• 社内に散在する証憑の収集
• ExcelやPDFへの転記
• フォーマットに合わせた整形
• 差戻し、再提出、そして再々提出

本来であれば、ビジネスは日々の取引の中で価値を生み出しているはずです。

しかし監査の期間だけは、その流れが止まる。

あるいは、別の流れが無理やり差し込まれる。

現場の担当者にとっては、通常業務に加えて“もう一つの仕事”が始まる感覚です。

そして、この負荷は企業側だけの話ではありません。

監査法人の側でも、特定の時期に業務が極端に集中します。

決算期が重なる3月から6月にかけては、複数のクライアントから同時に依頼が立ち上がり、

• 限られたリソースでのレビュー
• 対応待ちの案件の滞留
• 品質を維持しながらのスピード要求

こうした状況の中で、監査は“処理すべきタスク”として積み上がっていきます。

結果として、企業側には「対応」の負荷が、監査法人側には「処理」の負荷が、それぞれ蓄積していく。

では、この構造の本質は何なのでしょうか。

一言で言えば、監査はこれまで、“ビジネスプロセスの外側で発生する、割り込みイベント”として設計されていたということです。

取引は日々、ERPやCRMの中で実行されている。

しかしその結果は、監査のタイミングになって初めて、

• 抽出され
• 整形され
• 人間に理解できる形に変換

つまり監査とは、

システムの中に存在している事実を、人間が理解できる形に“翻訳する”ためのプロセス

だったとも言えます。

そしてこの“翻訳コスト”こそが、監査を重くし、時間をかけ、そして属人化させてきた最大の要因です。

• データはある
• 記録もある
• 履歴も残っている

それでもなお、監査が大きな負荷になるのはなぜか。

それは、それらが「監査できる形」になっていないからです。

だからこそ、私たちは毎回、同じことを繰り返すことになります。

集めて、並べて、説明する。

しかし、もし最初から、

• すべての取引が「監査されること」を前提に設計されていたとしたら。
• もしデータが、整形されることなく、そのまま検証可能だったとしたら。
• そしてもし、その検証を人間ではなく、AIエージェント同士が担うようになったとしたら。

監査は、今と同じ姿をしているでしょうか。

第2章｜問題の本質―なぜ監査は重いのか

では、もう一歩踏み込んで考えてみましょう。

なぜ監査は、ここまで重たい業務として存在し続けてきたのでしょうか。

単に作業量が多いからでしょうか。

それとも、監査基準が厳しいからでしょうか。

確かにどちらも一因ではあります。

しかし、本質的な理由はそこではありません。

監査が重たいのは、
“データがないから”ではなく、“データが監査できる形になっていないから”です。

データは存在している

今の企業において、取引データが存在しないということはまずありません。

• ERPには仕訳が記録されている
• CRMには契約や商談の履歴が残っている
• ワークフローには承認のログが残っている

つまり、事実はすでにシステムの中に存在しています。

にもかかわらず、監査の現場ではその事実が、そのまま使われることはありません。

なぜか。

それは、それらのデータが“監査という文脈で理解できる形になっていない”からです。

監査とは「翻訳」の仕事

監査において実際に行われていることを、少し乱暴に言い換えるとこうなります。

• システムの中のデータを抽出
• 人間が理解できる形式に変換
• 意図や背景を説明
• 証拠として再構成

つまり監査とは、

システム内の事実を、人間が納得できる形に翻訳するプロセス

だと言えます。

この「翻訳」にこそ、膨大なコストが発生しています。

なぜ翻訳が必要なのか？

では、なぜこのような翻訳が必要になるのでしょうか。

原因は極めてシンプルです。

ビジネスプロセスと監査プロセスが、最初から分断されているからです。

取引は「業務として成立するように」設計されています。

監査は「後から検証するために」設計されています。

この2つは、前提がまったく異なっています。

その結果、次のような断絶が生まれます。

業務：効率性・スピード重視
監査：証跡・説明可能性重視

このギャップを埋めるために、私たちは毎回「翻訳作業」を繰り返しているのです。

非構造化された証憑の問題

ここに、もう一つの大きな問題があります。

それは、証憑の多くが非構造化データであるということです。

• PDF
• スキャンされた請求書
• メールのやり取り
• 添付ファイル

これらは「存在している」という意味ではデータですが、システムが自動的に検証できる形にはなっていません。

結果として、

• 人が目で確認
• 意図を解釈
• 関連性をつなぐ

というプロセスが必要になります。

ここでもまた、“翻訳”が発生しています。

もう一つの本質/「提出」という文化

さらに見落とされがちですが、監査を重くしている大きな要因がもう一つあります。

それは、「提出する」という文化そのものです。

現在の監査は、基本的に以下の流れで成り立っています。

• 監査法人が依頼
• 企業が資料を提出
• 内容を精査

この構造では、必ず「提出用のデータ」が必要になります。

つまり、

「元データではなく、抽出され、整形され、意図が付加された“監査専用のデータ”を毎回作ることになる」のです。

監査が重たい理由を一言で言うと、ここまでを整理すると、非常にシンプルな構造が見えてきます。

監査が重いのは、事実を確認するためではなく、

“確認できる形に作り直すこと”にコストがかかっているからです。

データはある。証跡も残っている。

それでもなお監査が重いのは、それらが「そのままでは使えない」からです。

もし最初から監査可能だったなら

では、ここで一つ問いを立ててみましょう。

もしすべての取引が、

• 誰が実行し
• どのルールに基づき
• どのプロセスを経て
• どの結果になったのか

最初からこれらが監査可能な形で記録していたとしたら。

さらにそれを、人ではなくAIエージェントが解釈し、検証するとしたら。

私たちは、今と同じように「資料を作り、提出する」必要があるでしょうか。

第3章｜監査対応はなくなる―「提出」から「検証」へ

では、ここまでの話を踏まえて、少し視点を未来に向けてみましょう。

もし、監査の前提そのものを作り直せるとしたら。

私たちは、本当に「資料を作って提出する」というプロセスをこれからも続ける必要があるのでしょうか。

監査の前提はどこにあるのか

従来の監査は、一つの前提の上に成り立っています。

それは、

監査は「後から確認するもの」である

という前提です。

この前提がある限り、業務と監査は分離され続けます。

• 業務は先に進む
• 監査はあとから追いかける
• 必要に応じて証憑を「作る」

この構造があるからこそ、「監査対応」という概念が存在していました。

ERPとCRMの本来の役割

しかし、現代の企業においては、状況が少し変わっています。

業務はすでに、システムの中で完結しています。

• ERPは取引を記録する
• CRMは顧客との関係性を記録する
• ワークフローは意思決定の履歴を残す

つまり、「ビジネスの実態そのものが、すでにデータとして存在している」状態です。

問題は、このデータが「監査可能な形」で扱われていないことでした。

「提出」という文化の終わり

ここで一つの前提を疑ってみます。

なぜ、監査では資料を提出する必要があるのでしょうか。

それは、監査側からデータを直接参照できないからです。

だからこそ、

• 抜き出し
• 整形し
• 文脈を補足し
• 別の形にして渡す

というプロセスが必要でした。

しかしもし、

• 取引データ
• 承認履歴
• 契約情報
• ログ

これらすべてが、最初から構造化され、一貫した形で管理されていたとしたら。

そしてそれを、外部から安全に参照・検証できるとしたら。

「提出」という行為そのものは、本当に必要でしょうか。

監査は「状態」を確認する行為になる

ここで大きな転換が起きます。

監査は、

資料を確認するものではなく、説明を受けるものでもなく

“状態を確認するもの”になります。

• この取引はルール通りか
• この承認フローは一貫しているか
• この契約と売上の関係は整合しているか

それらは、「資料として説明されるもの」ではなく、「そのまま検証できるもの」になります。

イベントから継続へ

この変化は、時間軸にも影響を与えます。

従来の監査は、特定のタイミングで実施されるイベントでした。

しかし「状態を確認する」監査は、違います。

それは

• 日次で
• リアルタイムで
• 継続的に

実行されるものになります。

つまり監査は、「年に一度のイベントではなく、常に維持される状態」へと変わります。

サンプリングという発想の限界

ここで、監査のもう一つの前提にも触れておく必要があります。

それはサンプリングです。

従来の監査では、すべてを確認することは現実的ではないため、

• 一部を抽出し
• 代表性をもたせ
• 検証を行う

という手法が取られてきました。

しかし、もしデータがすべて構造化され、自動的に検証できるとしたらどうでしょうか。

サンプリングそのものの意味が変わります。

• 一部を見る必要がなくなる
• 全体を網羅的に検証できる
• 異常のみを抽出すればよい

つまり監査は、

「見る」作業から「検出する」仕組みへ

と変わります。

では、誰が検証するのか

ここまで来ると、自然に次の疑問が生まれます。

• データはある
• 状態は可視化される
• 継続的に検証できる

では、その検証は誰が行うのでしょうか。

人でしょうか。それとも、別の存在でしょうか。

次の前提へ

もしその検証を、「システム自身が行い、別のシステムがそれを確認し、双方が整合性を取り続ける」ようになったとしたら、

監査はどのような姿になるのでしょうか。

そしてそのとき、「責任はどこに帰属する」のでしょうか。

第4章｜AgentとAgentが監査する時代

ここからは、少しだけ具体的なイメージを持ってみましょう。

監査対応がなくなり、「監査が“状態を確認するもの”へと変わった」とき、実際には何が起きているのでしょうか。

ある監査の一場面

企業側には、業務プロセスを理解し、すべての取引・契約・承認の履歴を把握しているエージェントが存在します。

監査法人側には、監査基準やリスクモデルを持つエージェントが存在します。

人は、そこに直接介在しません。

静かに、次のようなやり取りが始まります。

Audit Agent（監査側）
「当期における売上計上の整合性を検証したい。契約、出荷、請求、入金の間に不整合は存在するか。」

Enterprise Agent（企業側）
「対象期間の全トランザクションを確認。契約から売上計上までの整合性は98.7%で成立。不整合トランザクションは全体の1.3%。詳細を提示する。」

Audit Agent
「不整合1.3%の内訳を分析。原因がプロセス逸脱か、例外処理かを識別したい。」

Enterprise Agent
「分析完了。0.8%は例外処理（特別契約条件）、0.5%は承認プロセスの遅延によるタイミング差異です。」

Audit Agent
「承認プロセス遅延について、統制上の問題有無を評価したい。ルール逸脱は発生しているか。」

Enterprise Agent
「ルール逸脱はなし。承認はすべて定義された権限内で実施。遅延は人的リソースに起因しています。」

このやり取りの中に、私たちがこれまで行ってきた監査対応のほぼすべてが含まれています。

しかしそこには、

• 資料の提出
• 説明資料の作成
• メールの往復
• 会議での補足説明

といったプロセスは存在しません。

会話ではなく「検証の連鎖」

ここで起きているのは、人間同士の“会話”ではありません。

あくまで、

「仮説」→「検証」→「追加検証」→「評価」

という流れが、連続的に実行されているだけです。

違いは一つ。

それを担っているのが、人ではなくエージェントであること。

「監査対応」という仕事が消える瞬間

この世界では、「監査対応をする」という仕事はどこにも存在しません。

企業側は、何も準備していません。

監査法人側も、資料を待っていません。

あるのは、

• 常に整備されたデータ
• 一貫したプロセス
• それを前提とした検証

だけです。

つまり、「監査は“対応”ではなく、“常時実行されている確認処理”」になるのです。

しかし残るものがある

ここで、もう一度問いを立てる必要があります。

このやり取りの中で、人は完全に不要になったのでしょうか。

答えは、もちろん違います。

エージェントは、

• データを分析し
• 整合性を確認し
• ルールに基づいた判断を行う

ことはできても、その判断を社会的に説明し、責任を負う存在ではありません

責任はどこにあるのか

この世界で最も重要なのは、「誰が処理したか」ではなく、

「その判断に誰が責任を持つのか」という点です。

エージェント同士の監査が可能になればなるほど、この問いは避けて通れません。

そしてその答えは、システムの中では完結しません。

第5章｜監査とは何か―取引と責任がつながらない理由

監査は帳票を見ていない

監査は帳票を見ているのではありません。

取引と責任がつながっているかを見ています。

ここまで、監査がなぜ重く、非効率になっているのかを見てきました。

そして、AIエージェント同士が監査を行う可能性にも触れてきました。

しかしここで、一度立ち止まる必要があります。

そもそも監査とは、何を検証しているのでしょうか。

帳票、証憑、仕訳。どれも間違いではありません。

ただし、それらはすべて「見えている結果」に過ぎません。

監査が見ているのは、「取引が正しく成立し、正しく処理され、その結果に誰が責任を持つのか」

という構造そのものです。

取引の実在がすべての出発点である

監査はまず、その取引が本当に存在しているかを確認します。

• 発注は実際に行われたのか
• 商品やサービスは提供されたのか
• 顧客はそれを受領しているのか

この確認のために、発注書、契約書、納品書、受領書、検収書といった証跡が使われます。

監査は最初に、「取引が実在しているか」を問います。

取引条件には必ず理由が存在する

次に問われるのは、その取引条件が適切であるかどうかです。

• なぜその価格なのか
• なぜその割引なのか
• その条件は契約と整合しているのか

ここで必要になるのは帳票ではなく、前段の文脈です。

見積、商談履歴、契約条件。

これらがなければ、その金額の正当性を説明することはできません。

監査は、「結果ではなく理由を確認」しています

会計は結果に過ぎない

会計は監査の中心に見えます。

• 売上の計上タイミング
• 収益認識
• 原価
• 仕入の計上タイミング
• 勘定科目

確かに重要な領域です。

しかし本質は明確です。会計は結果に過ぎません。

会計が正しく見えても、その前段の取引プロセスが誤っていれば、その正しさは成立しません。

監査の本質は一貫性の検証である

だからこそ監査は、個別の帳票ではなく取引の流れ全体を見ます。

見積から受注、契約、提供、検収、請求、売上、そして会計仕訳へ。

これらが一つの流れとして矛盾なくつながっているかどうか。

ここに監査の本質があります。

監査とは、「取引の流れに矛盾がないことを検証する行為」です。

権限と責任が統制の前提である

監査においてもう一つ不可欠なのは、誰がその処理を行ったのかです。

どれだけ整合していても、その処理が適切な権限のもとで実行されていなければ統制は成立しません。

• 誰が作成し、誰が承認し、誰が変更したのか
• どのロールで操作されたのか
• その履歴は追跡できるのか

これらが曖昧であれば、その取引は正しいとは言えません。

監査が見ているのは、「結果ではなく責任の分離」です。

取引と責任は現実には分断されている

現実の業務では、これらの情報は分散しています。

発注はメールで行われ、契約はPDFで保管されます。

検収書は紙で管理され、会計は別システムで処理されることもあります。

さらに、ユーザーや権限もシステムごとに分かれています。

この状態では、取引も会計も確かに存在しています。

しかし、それらは自然にはつながりません。

• 結果として
• 証跡を探し
• 情報をつなぎ
• 説明できる形に再構成

する必要が生まれます。それが監査の実態です。

取引は存在しています。しかし、つながっていません

さらに言えば、責任もまた、つながっていません

AI監査はこの構造を前提にできない

この分断は人間であれば補完できます。

しかし、エージェントにはそれができません。

エージェントはデータを読み、ルールを適用することはできます。

しかし、断絶した文脈や曖昧な責任を推測で埋めることはできません。

だからこそ、問いが変わります。

すべての取引が最初からつながり、誰が何をしたかが明確であれば、監査はどう変わるのでしょうか。

その答えは、次の章で明らかになります。

第6章｜監査を成立させる条件—事実が存在する場所を定義する

監査はシステムではなく構造に依存する

前章で明らかになったのは、監査という行為が特定の帳票や仕訳ではなく、取引と責任のつながりを検証しているという点でした。

では次に問うべきは、より具体的な問いです。

その「つながり」はどこに存在するのか

監査はシステム単体では成立しません。

どのシステムに、どの事実が存在し、どこで意味が発生し、どこで結果が確定するのか。

その構造によって、監査の難易度は決定されます。

ERP完結型は結果に最適化された構造である

まず、すべての業務がERP内で完結する構造です。

この場合、見積から受注、提供、請求、売上、仕訳に至るまでが一つのシステム内に存在します。

取引のトレーサビリティは非常に強く、データモデルも一貫しています。

しかし、この構造には明確な特徴があります。

結果は強いが、意思の文脈が弱い

• なぜその条件になったのか
• なぜその顧客とその価格で契約されたのか

その背景となる意思決定プロセスは、必ずしも十分に表現されていません。

CRMとERPの分離は監査の重心を変える

次に、CRMとERPが分離している構造です。

CRMには商談、見積、契約といった意図と文脈が存在し、ERPには受注、請求、売上、仕訳といった結果が存在します。

この場合、監査は単純な確認では成立しません。

意図と結果の整合性を検証する行為に変わる

CRMの見積とERPの売上。契約条件と請求内容。

それらが一致して初めて、監査は成立します。

ERP内モジュール型は構造を単純化する

ERP内にプロジェクトやサービスモジュールが存在するパターンもあります。

この場合、意図と実行、そして結果の多くがERP内に収まります。

一見すると理想的な構造に見えますが、ここにも特徴があります。

顧客接点の粒度が低い

営業活動や交渉の履歴といった前段の文脈は、限定的にしか保持されません。

結果として、取引の理由部分は弱く、監査の深さには限界が生まれます。

CRM実行型は構造を逆転させる

近年重要になっているのがこのパターンです。

Field Service や Project Operations が業務の実行主体となり、ERPは結果の確定だけを担う構造です。

ここでは明確な転換が起きています。

CRMはフロントではなく、実行レイヤーである

サービス提供やプロジェクト進行、実績の発生そのものがCRM側で起きます。

その結果、ERP単体では取引の実態を理解できなくなります。

監査は、ERPだけでは成立しません。

混在型は定義そのものを曖昧にする

現実の多くの企業は、この混在型に該当します。

一部はERPで完結し、一部はCRMで管理される。

プロジェクトはCRM、保守契約はERP、といったように業務が分散します。

この状態で問題になるのは単なる分断ではありません。

意味と定義が一致しない

• 同じ「売上」でも生成経路が異なる
• 同じ「契約」でも解釈が異なる

この時点で、監査は構造的に困難になります。

会計分離型は監査を人の仕事に戻す

そして最も問題が顕在化するのが、会計が別パッケージで管理されている構造です。

業務はERPやCRMで行われ、会計は別のシステムで処理される。

この場合、仕訳は存在します。

しかし、その根拠は遠くにあります。

原票は別の場所にあり、場合によっては見つかりません。

突合は手作業になります。

現場ではこうした状況が日常的に発生しています。

• 発注はメールで行われます
• 契約書はPDFで保管されます
• 検収書はスキャンデータです
• 納品書は別システムにあります

これらはすべて存在しています。

しかし、プロセスにはつながっていません。

証憑は存在しているが、プロセスに紐づいていない

この状態を一言で表すと、

会計は存在するが、取引は存在しない

ということになります。

監査の難しさは構造によって決まる

ここまで見てきたとおり、監査の難しさは個人のスキルでは決まりません。

どのシステムを使っているかでもありません。

どこに事実が存在し、それがどのように分断されているか

それによって決まります。

そしてここで、次の問いが自然に生まれます。

もしすべての取引が、最初から一つの流れとしてつながっていたとしたら、監査はどのように変わるのでしょうか。

第7章｜なぜ“つながっていること”が必要なのか－トレーサビリティの本質

監査は帳票ではなく流れを見ている

監査は帳票を見る行為ではありません。

取引の一貫性を検証する行為です

この一文に、監査の本質はすべて含まれています。

重要なのは、個々の情報ではありません。

それらがどのようにつながっているかです。

トレーサビリティは単なる参照ではない

多くの場合、トレーサビリティは「紐づいていること」と理解されます。

しかし本質はそこではありません。

意味が連続していること

が重要です。

見積が受注に変わり、契約となり、提供され、売上として認識され、会計仕訳になる。

この流れには因果関係があります。

流れが切れた瞬間に監査は崩れる

この流れが一箇所でも切れると、何が起きるのでしょうか。

• 見積と受注がつながらない
• 契約条件が参照できない
• 提供実績が存在しない
• 検収が確認できない

こうなると、もはやシステムは何も証明できません。

結果として発生するのは、

• 人による確認
• 証跡の探索
• 関係者へのヒアリング

つまり、

監査は再び“人の仕事”に戻ります

自動化の限界はここにある

多くの企業が監査の効率化や自動化に取り組んでいます。

しかし、その多くが十分な効果を出せない理由はシンプルです。

流れがつながっていないからです

どれだけAIを導入しても、どれだけデータを集めても、

取引の一貫性が保証されていなければ、監査は自動化できません。

つながりは結果ではなく前提である

ここで認識を変える必要があります。

多くの人は「データをつなぐ」と言います。

しかし監査において必要なのは、

最初からつながっていることです

事後的な統合では不十分です。

最初の見積から最後の仕訳まで、同じ文脈で処理されている必要があります。

第8章｜監査を“状態”にするアーキテクチャ－Dynamics 365の本質

統合ではなく文脈の一貫性である

ここまで見てきたとおり、監査はデータの有無や帳票の整備では成立しません。

必要なのは、取引が一つの流れとしてつながっていること、そしてその流れに責任が紐づいていることです。

ここでよくある誤解があります。

「システムを統合すれば監査は楽になる」という考え方です。

しかし、本質はそこにはありません。

単にデータをつなぐだけでは不十分です。

重要なのは、同じ取引を、同じ意味で扱えているかどうかです。

必要なのはデータの統合ではありません
意味の一貫性です

この視点に立たなければ、どれだけシステムを連携しても、監査は軽くなりません。

System of Recordは構造で定義する

監査を成立させるためには、まず「どこに事実があるのか」を明確にする必要があります。

ここで重要なのは、システムごとの役割です。

ERPは結果を確定する場所です。

売上、原価、在庫、会計仕訳といった確定事実はここに存在します。

一方で、CRMは取引を成立させる場所です。

顧客とのやり取り、契約条件、作業指示、実績といった文脈はここで生まれます。

そしてその間に必要なのが、文脈を一貫させる基盤です。

ERPは結果を持ち
CRMは意味を持ち
その間の一貫性が監査を成立させます

監査は単一システムではなく、この構造全体で成立します。

トレーサビリティは設計で決まる

多くの企業では、トレーサビリティを「後から紐づけるもの」として扱っています。

しかし、それでは不十分です。

監査が要求するのは、事後的な関連付けではなく、

最初から一貫した流れとして存在することです。

見積から受注、契約、提供、検収、請求、売上、仕訳まで。

この一連の流れが同じ文脈で処理されていなければ、

監査は成立しません。

トレーサビリティはログではありません
設計です

イベントが発生した瞬間から、その意味と責任が記録されている必要があります。

CRMは実行レイヤーである

ここで、最も重要な認識の転換があります。

CRMはフロントオフィスではありません。

CRMは取引の実行レイヤーです

Salesでは、見積や契約条件が確定します。

Customer Serviceでは、対応や補償が決定されます。

これらは単なる記録ではありません。

意思決定そのものです

さらに、Field ServiceやProject Operationsでは、実際にサービスが提供され、工数や部材が消費されます。

ここで起きているのは、

契約の履行そのものです

つまり、

• Sales / Customer Serviceは「意思決定の実行」
• Field Service / Project Operationsは「履行の実行」

です。

そしてERPは、その結果を確定します。

売上はERPで生まれているのではありません
CRMで行われた意思決定と実行の結果です

この構造を理解しなければ、監査は成立しません。

権限と責任は分離されていなければならない

第5章で述べたとおり、監査の本質には責任の問題が含まれます。

そのためには、システム上で明確な統制が必要です。

• 誰が作成したのか
• 誰が承認したのか
• どの権限で変更されたのか

これらが明確に分離され、追跡可能であることが前提になります。

ここで重要になるのが、役割と権限の設計です。

一人のユーザーがすべての処理を完結できる構造では、どれだけデータが整っていても監査は成立しません。

そしてこの概念は、人だけに限りません。

エージェントもまた責任の主体です

これからの時代、エージェントは業務を実行します。

そのとき、エージェントにも明確な権限と責任の境界が必要になります。

証憑を探すという行為そのものが問題である

従来の監査では、証憑を探すことが当たり前でした。

メールを確認し、PDFを探し、紙の書類を参照し、システムごとの情報を突き合わせる。

しかし、この行為自体が問題です。

証憑を探している時点で、構造は破綻しています

本来あるべき姿は、証憑が最初から取引の流れに紐づいている状態です。

発注、契約、実行、検収、請求。

すべてが一つの流れの中で管理されている。

それが実現されていれば、探す必要はありません。

監査は“後から”行うものではなくなる

ここまでの要素がすべて揃うと、監査の位置づけは変わります。

監査は、後から確認する作業ではなくなります。

取引が発生した瞬間から、その正当性と責任が検証可能な状態になります。

監査とは、後から説明する活動ではありません
常に証明されている状態です

この状態に至ったとき、初めて監査は“イベント”ではなくなります。

監査は“状態”になる

これが本章の結論です。

監査は作業ではありません。

作業である限り、必ず人手と時間が必要になります。

監査の本質は、

正しく構造化されたシステムにおいて、常に成立している状態

です。

その状態を実現するために必要なのが、

• 文脈の一貫性
• トレーサビリティの設計
• 実行レイヤーとしてのCRM
• 結果を確定するERP
• 権限と責任の分離

です。

これらが揃ったとき、監査は「対応するもの」ではなく、「常に成立しているもの」へと変わります。

第9章｜AgentとAgentが監査する世界—監査は対話として実行される

内部監査は「異常を見つけ続けるプロセスになる」

ここまで見てきたように、監査が重くなる最大の理由は、取引と責任が分断されていることにあります。

そして、その分断を人が補完し続けてきたことが、「監査対応」という仕事を生み出してきました。

この構造が変わり始める最初の場所は、実は外部監査ではなく、企業内部の監査です。

これまで内部監査は、年次あるいは四半期ごとに監査項目を定め、対象部門にヒアリングし、証跡を集め、最終的に統制の有効性を評価する活動として実施されてきました。

しかし、取引が日々システム上で発生し、その取引に関する意味・履行・結果・責任が構造化されるようになると、内部監査のあり方は大きく変わります。

内部監査は、もはや「定期的に確認しに行く活動」ではありません。

取引が発生したその瞬間から、継続的に異常を検知し、統制の状態を見続けるプロセスになります。

例えば、内部監査Agentは次のような問いを、日常的かつ継続的に発します。

契約条件と異なる価格変更は発生していないか。

承認プロセスの逸脱はないか。

作業実績と請求タイミングに整合性はあるか。

原価と売上の対応関係に不自然なズレはないか。

月次決算で発生した調整仕訳に、通常ルールから外れた処理はないか。

この段階では、まだ外部監査は関与していません。

しかしここで重要なのは、内部監査Agentが単なる異常検知ツールではないということです。

内部監査Agentは、企業内の業務AgentやERP・CRMの取引構造を横断的に理解し、

「この企業は今、説明責任を持てる状態にあるか」を常時確認し続ける主体になります。

つまり、内部監査の役割は消えるのではありません。

むしろ、より前面に出てきます。

これまで内部監査は、外部監査の前に内部統制の整備状況を確認する役割を担ってきました。

これからはそれに加えて、外部監査に対して、企業として何をどう説明できるかを構造的に整える役割を持つことになります。

外部監査は仮説検証プロセスとして実行される

ここからが本題です。

外部監査、すなわち監査法人による監査は、従来のように「依頼を出し、資料を受け取り、レビューする」という流れではなくなります。

その代わりに、監査法人側のAgentと、企業側の内部監査Agentとの間で、仮説検証型の対話が実行されるようになります。

ただし、この「対話」という言葉には注意が必要です。

これは人間同士のような会話ではありません。

本質的には、

• 仮説を立てる
• 必要な論点に分解する
• 構造化されたデータで検証する
• 例外や逸脱を再検証する

というサイクルが、自動的かつ反復的に進んでいるだけです。

つまり、外部監査Agentは「質問する存在」であり、内部監査Agentは「説明責任を持って構造を提示する存在」です。

ここで重要なのは、外部監査AgentがERPやCRMに直接聞きに行くわけではない、ということです。

それをやってしまうと、外部監査は単なるデータ参照になってしまい、企業としての説明責任の所在が曖昧になります。

正しい構造は、

外部監査Agent → 内部監査Agent → 業務Agent（ERP / CRM / Project / Field Service / その他）です。

つまり、内部監査Agentは、企業内部の取引・証跡・権限・責任を理解し、企業としての見解と説明可能な構造をまとめて外部監査Agentに提示するハブになります。

この役割を明確にしないと、内部監査と外部監査の境界が曖昧になり、記事全体の説得力が落ちてしまいます。

逆に言えば、この構造を明確に描くことで、内部監査と外部監査の役割は「消える」のではなく、「進化する」のだと説明できます。

外部監査は売上の「流れ全体」を証明させる

では、実際にどのような対話が行われるのでしょうか。
ここでは、売上監査を例に、より具体的に見ていきます。

外部監査Agentは、いきなり仕訳を見ません。
まずは、取引の流れ全体を提示するよう求めます。

監査法人Agent（外部監査）
「当期売上のうち、主要顧客セグメントについて、完全性および正確性を検証します。契約から売上計上、会計仕訳までのトレーサビリティを提示してください。」

企業側内部監査Agent
「対象トランザクションを統合ビューとして提示します。以下の構造で関連付け済みです。

• Sales：見積、価格条件、契約条項
• Customer Service：例外対応、補償、調整条件
• Field Service / Project Operations：履行実績、工数、使用部材、進捗
• ERP（FO / BC）：受注、請求、売上、仕訳

各エンティティは共通IDにより一連の取引として関連付けられています。」

ここで初めて、「証憑」ではなく「構造」が提示されます。

しかも重要なのは、外部監査Agentが生データを見ているのではなく、内部監査Agentが責任を持って構造化した情報を検証しているという点です。

外部監査は、企業の説明責任を代行するものではありません。

あくまで、企業が提示した内容を独立した立場で検証する主体です。

契約と価格は意思決定として検証される

次に外部監査Agentは、売上金額の妥当性を問い始めます。

監査法人Agent
「売上金額が契約条件と一致しているか確認してください。また、例外処理や補償対応が売上に影響している場合は、その内容も提示してください。」

企業側内部監査Agent
「Salesに登録された見積および契約条件を確認済みです。基本価格、ディスカウント条件、特別契約条件は売上計算ロジックと一致しています。また、Customer Serviceにて1件の補償処理が記録されています。当該補償は売上減額としてERPに反映済みです。」

監査法人Agent
「当該補償について、承認プロセスと権限体系を提示してください。」

企業側内部監査Agent
「補償はCustomer Serviceケースとして記録され、承認者はSales Managerロールです。承認履歴、変更ログ、ロール定義を照合済みであり、権限体系と整合しています。」

この対話では、単に「金額が合っているか」を見ているのではありません。何が通常条件で、何が例外であり、その例外が誰の判断で、どの権限に基づいて承認されたのかまでが検証されています。

つまりここで見ているのは、

• 金額
• 条件
• 例外
• 責任

です。

監査の実態は、最初から数字ではなく意思決定の検証なのだ、ということがここではっきり見えてきます。

履行は「やったかどうか」ではなく「どう履行したか」で検証される

契約や条件が確認された後、外部監査Agentは履行の実在性を確認します。

監査法人Agent
「契約に基づくサービスまたはプロジェクト履行が、事実として存在するか確認してください。」

企業側内部監査Agent
「Field ServiceのWork Orderを確認済みです。作業日時、担当技術者、使用部材、完了ステータスが記録されています。また、Project Operationsでは、該当案件に対する工数実績、原価、仕掛、進捗率を確認可能です。」

監査法人Agent
「履行と請求タイミングの整合性を検証してください。」

企業側内部監査Agent
「履行完了後、検収が行われ、その後に請求処理が実行されています。収益認識ルールと矛盾はありません。」

ここで重要なのは、「やった」という結果だけでは不十分だという点です。

作業が存在し、誰が実施し、何を使い、どのタイミングで完了し、その結果が請求・売上・仕訳につながったのか。

つまり、履行は

“やったかどうか”ではなく、“どうやってやったか”

で証明されます。

会計は仕訳ではなく調整ロジックごとに検証される

売上や履行が確認されたあと、外部監査AgentはERPにおける会計処理の妥当性を検証します。

ただし、ここでも仕訳を眺めるだけでは終わりません。

月次決算、期末調整、為替評価、原価計算など、背後にあるロジックそのものが監査対象になります。

監査法人Agent
「売上計上および関連する調整仕訳を検証します。認識ルール、月次調整、為替評価替えを提示してください。」

企業側内部監査Agent
「ERP Agentから情報を収集しました。
以下を提示します。」

• 売上認識ルール
• 計上タイミング
• 月次決算で発生した調整仕訳
• 為替評価替えによる差損益

監査法人Agent
「期末調整仕訳の根拠と再現可能性を提示してください。」

企業側内部監査Agent
「引当計算ロジック、繰延収益の計算根拠、前年同月比との比較差異を提示可能です。すべて定義済みルールに基づいて算出されています。」

ここでは、会計が単なる“結果”ではなく、どういうルールに基づいてその結果になったのかまでが検証されています。

さらに、サービスやプロジェクトの場合には、月末の仕掛計上や原価計上タイミングも重要な論点になります。
例えば、

• 月末時点で未完了の作業に対する仕掛計上は妥当か
• 原価計上が工数実績と一致しているか
• 売上と原価の対応関係にズレはないか

といった問いが、Project OperationsやERPのデータを横断しながら検証されます。

原価・在庫は「計算構造」が検証される

さらに監査は、製造原価や在庫評価の領域にも及びます。

ここでは単に残高を見るのではなく、どのような計算構造でその数字が作られているかが問われます。

監査法人Agent
「製造原価および間接費配賦の妥当性を確認します。配賦方法と在庫原価構成を提示してください。」

企業側内部監査Agent
「ERP Agentから取得した内容を提示します。製造間接費は階梯式配賦法で配賦されています。コストセンター間の分配ロジック、および諸掛の在庫組み入れルールも提示可能です。輸送費や関税は在庫原価に組み入れられ、配送費は販管費として処理されています。」

監査法人Agent
「架空仕入の兆候を分析してください。」

企業側内部監査Agent
「仕入、入庫、支払の三点照合を実行済みです。部材およびパーツの架空仕入を示す不整合は検出されていません。」

この対話で監査されているのは、数字ではありません。

原価の作られ方そのものです。

同様に、製造間接費の配賦が相互配賦なのか階梯式なのか、諸掛が在庫に組み入れられているのか販管費に落ちているのか、といったことは、製造原価の信頼性に直結します。

現金・銀行・不正リスクは検知対象へ

監査は収益や原価だけで終わりません。
資金と不正の領域も、Agent対話の重要なテーマになります。

監査法人Agent
「銀行残高と帳簿残高の整合性を確認してください。」

企業側内部監査Agent
「ERP Agentから銀行照合結果を取得済みです。未達取引の一覧も提示可能です。」

監査法人Agent
「売掛金および資金移動に、カイティングの兆候がないか検出してください。」

企業側内部監査Agent
「複数口座間の入出金タイミングと売掛金消込データを分析しました。カイティングを示唆する異常パターンは検出されていません。」

ここでは、不正の可能性が説明ではなく検出対象になっています。

従来のように、担当者の説明や勘に頼るのではなく、データパターンとして異常を発見し、それを監査法人側が検証できます。

連結決算はグループ全体の整合性として検証される

企業単体の監査だけでなく、連結決算も同様です。

監査法人Agent
「グループ内取引の相殺および未実現利益の処理を確認してください。」

企業側内部監査Agent
「連結Agentから以下を取得しました。

• 社内売上・仕入の消去
• 未実現利益の調整
• 為替換算差異

いずれも連結ルールに基づいて処理されています。」

ここでは、単体企業の整合性ではなく、グループ全体としての一貫性が検証されます。

最後に責任が確定する

このような一連の対話の最後に、必ず確認されるのが責任分離です。

監査法人Agent
「全プロセスにおける責任分離を確認してください。」

企業側内部監査Agent
「以下を提示します。

• ユーザーID
• ロール
• 承認履歴
• 変更ログ
• Agent実行ログ

すべて職務分掌ルールに準拠しています。」

ここで初めて、人の責任、Agentの責任の両方が確定します。

つまり、Agent時代になっても責任が消えるわけではありません。

むしろ、どの処理を誰が定義し、誰が受け入れ、誰が最終責任を持つのかが、より厳密に問われるようになります。

この世界は現実の監査制度とどのように融和していくのか

ここまでの一連の流れを見ると、監査はすでに完成された状態に見えます。

しかし現実の環境は、ここまで単純ではありません。

現在の監査制度、特に日本におけるJ-SOX（内部統制報告制度）や監査法人の監査フレームワークは、

• 証憑の存在
• 文書化された統制
• 人によるレビューと承認

を前提に設計されています。

つまり、

「人が確認できること」
「人が説明できること」

が正しさの基準になっています。

一方で、本章で描いてきた世界は、

「構造として検証可能であること」

を前提にしています。

移行期には必ず葛藤が発生する

この差は、移行期において必ず問題になります。

AIエージェントによる監査は、

• 網羅性
• 一貫性
• 再現性

の観点では、人間を上回る可能性があります。

しかしその一方で、

• その判断をどう説明するのか
• 監査調書として何を残すのか
• 規制当局はどこまでこれを認めるのか

という問いが残ります。

ここで起きるのは、非常にシンプルな問題です。

正しいことと、認められることが一致しない可能性です。

変化は置き換えではなく重ね合わせで進む

では、このギャップは、一気には埋まりません。

現実には、

• 従来の証憑
• 従来の監査調書
• AIによるトレーサビリティ
• AIによる検証ログ

が併存する期間が続きます。

そして徐々に、監査の重心が移っていきます。

次の主戦場は「監査可能なAIログ」

この移行期において、最も重要になるのはログの設計です。

AIによる監査において必要なのは、単なる操作履歴ではありません。

• 誰が（ユーザーまたはAgent）
• 何を入力し
• どのロジックを適用し
• どのデータを参照し
• どの結果を出したのか

という情報です。

つまり、

判断の再現性です

これを満たすログは、単なるログではなく、

監査証跡そのものになります

ベンダーとパートナーの役割が変わる

これから求められるのは、AIを動かすことではありません。

AIの判断を監査可能にすることです。

• Agentの意思決定ログの標準化
• ERP・CRM・Dataverseを横断したトレーサビリティ設計
• Explainabilityの監査対応
• 監査法人が直接検証できるログ設計

ここが設計されなければ、AIは監査に使えません。

逆にここが整えば、

「動くAI」から「監査に耐えるAI」へと進化します。

本当の転換点はここにあります

AIを導入することが変革ではありません
AIの判断を証明できる状態にすることが変革です

監査はなくならない
観測される対象が変わるだけである

では、内部監査と外部監査の関係はどう変わるのか？

ここで、一つ現実的な問いを考える必要があります。

これまで企業の中では、内部監査と外部監査は明確に分かれていました。

内部監査は、統制を維持し、問題を事前に把握し、改善を促す役割を担ってきました。

一方で外部監査は、それを独立した立場から検証し、財務報告の信頼性を保証する役割を担ってきました。

では、内部監査Agentが外部監査Agentと直接対話する構造は、本当に問題ないのでしょうか。

この問いに対しては、単純に「良い」「悪い」と答えるべきではありません。

この構造には明確なメリットがある

まず、企業側の視点で見れば、メリットは非常に大きいです。

資料作成にかかる膨大な時間が削減されます。

証跡の探索や整形が不要になります。

月次決算や年度締めのスピードは上がり、監査に備えるための“別作業”も減ります。

監査法人側にとっても、メリットは明確です。

サンプリング中心だった監査が、全件検証に近づきます。

異常の検知精度が上がり、レビューのばらつきも減ります。

さらに、繁忙期に大量のクライアントを抱えたときでも、一定の品質を保ちやすくなります。

つまりこの構造は、

企業側にとっても、監査法人側にとっても、生産性と品質を同時に高める可能性を持っています

しかし懸念もある

一方で、監査の現場にいる人間の立場から考えると、当然懸念も生まれます。

企業内部の人間から見れば、内部監査Agentが企業を代表して外部監査に答える構造は、

「説明責任の重心が内部監査側に寄り過ぎるのではないか」という不安が出てきます。

監査法人の立場から見れば、さらに本質的な懸念があります。

外部監査は本来、企業から独立しているべきです。

しかし、情報取得の窓口が内部監査Agentに集約されると、

企業側の“整理された見解”を前提に監査してしまうのではないか

という疑問が生まれます。

これは非常に重要な論点です。

なぜなら、監査法人の価値は独立性にあるからです。

本質は「依存」ではなく「検証の深化」

では、この懸念はA2A監査を否定する理由になるのでしょうか。

私は、必ずしもそうではないと思います。

ここで重要なのは、外部監査Agentが内部監査Agentの説明をそのまま受け入れる存在ではない、ということです。

外部監査Agentは、内部監査Agentが提示した構造を前提にしながらも、そこに含まれる整合性、例外、責任分離、ルール逸脱を独立して検証する存在です。

つまり、
内部監査Agentは説明責任の主体であり、
外部監査Agentは検証責任の主体です。

この役割分担は、現在の内部監査と外部監査の関係と本質的には変わっていません。

変わるのは、資料作成と説明のやり方です。

役割は消えません。進化するだけです。

監査は対話として進みますが、「対応」という仕事は消える

この一連のやり取りの中で、監査は完了します。

資料は作られていません。Excelに転記もしていません。

補足説明のための会議もありません。

あるのは、

• データが存在
• 繋がった構造
• 検証が実行

という状態だけです。

その結果として、監査は確かに対話として進みます。

しかし、従来の意味での「監査対応」という仕事は存在しません。

この章で描いたのは単なる未来ではない

この章で描いたのは、単なる空想ではありません。

第5章から第8章で見てきたように、取引と責任がつながり、System of Recordが整理され、トレーサビリティが設計され、ERPとCRMが意味の一貫性を持って結ばれているなら、この世界は十分に現実になり得ます。

そしてそのとき、監査は、イベントでもなく、単なる業務プロセスでもなく、

“状態”になります

第10章｜監査はどこに向かうのか—責任は最後まで人間に残る

判断は常にその場で行われている

サッカーの試合を見ていると、いつも考えさせられることがあります。

一つひとつのプレーは、一見すると偶然の積み重ねのように見えます。

しかし実際には、その瞬間ごとに明確な判断が行われています。

• どこでパスを出すのか
• どこで勝負するのか
• どのリスクを取るのか

その判断は一瞬で行われ、その結果はすぐにチーム全体に影響を与えます。

そして、そのプレーは必ず誰かの責任として残ります。

試合が終わった後に、その内容を言葉で説明することはできます。

しかし本質的には、その場ですでに責任は発生し続けているのです。

監査も同じ構造である

ここまで、本記事では監査について考えてきました。

そして、データが構造化され、トレーサビリティが設計され、Agent同士が検証を行う世界がどのようなものかを見てきました。

そこから見えてきたものは、シンプルです。

監査とは、帳票を確認する活動ではありません
取引と責任が正しくつながっているかを確認する行為です

監査は後から行うものではなくなる

これまでの監査は、「後から確認する」という前提で設計されていました。

取引は先に進み、その結果を後から抽出し、説明し、確認する。

この構造だからこそ、「監査対応」という仕事が存在していました。

しかし、第9章で見てきたように、構造が変わると状況は一変します。

取引が発生した瞬間から

• 意味が記録され
• 履行が記録され
• 結果が確定し
• 責任が紐づく

状態になります。

その結果、監査は

後から説明する活動ではなく、常に検証されている状態

へと変わります。

内部監査と外部監査の関係は再定義される

この変化は、監査の役割にも影響を与えます。

従来、企業の中では内部監査と外部監査は明確に分かれていました。

内部監査は統制を維持し、問題を事前に発見する役割
外部監査は独立した立場でその妥当性を検証する役割

この関係は、Agentの時代になっても消えません。

むしろ、より明確になります。

内部監査は、企業として説明可能な状態を構造的に維持する責任を持ちます。

外部監査は、その構造を独立した立場で検証する責任を持ちます。

しかし、その実行方法が完全に変わっています。

資料を作ることはなくなり、

説明を整形する必要もなくなり、

説明責任と検証責任だけが、本質として残ります

Agentは責任を代替しない

ここで重要な問いに戻ります。

エージェントが業務を実行し、エージェントが検証を行う世界において、

責任はどこにあるのでしょうか。

この問いに対する答えは明確です。

エージェントは責任を持ちません

エージェントは処理を実行します。

ルールに基づいて判断を行います。

整合性を検証します。

しかし、その前提を定義したのは人間です。

その結果を受け入れるのも人間です。

つまり、

処理の主体はAgentに移っても
責任の主体は人間から変わりません

責任はむしろ重くなる

さらに言えば、この構造は責任を軽くするものではありません。

むしろその逆です。

これまでは

• 作業の曖昧さ
• データの欠落
• 説明のばらつき

が、ある意味で責任の分散を生んでいました。

しかし、すべての取引が

• 再現可能で
• 検証可能で
• ログとして残る

状態になると、

どこで誰が何を判断したかが、明確に残ります

その結果、責任はあいまいにできなくなります。

責任の変化は制度に先行する

ここで一つ、見落としてはいけない現実があります。

これまで見てきた監査の変化は、必ずしも制度の変化と同時に起きるわけではありません。

むしろ多くの場合、

実務が先に変わり、制度が後から追いつく

という順序になります。

現在の監査制度は、証憑や文書、そして人による確認を前提に設計されています。

しかし、取引が構造としてつながり、検証可能な状態で存在するようになると、実務における「正しさ」はすでに別の基準に移り始めます。

つまり、ここで起きるのは制度との対立ではありません。

責任の持ち方の変化です

これまで人は

資料を作り、説明することで責任を果たしてきました。

しかしこれからは

判断が再現できること
構造として説明できること

が責任の中心になります。

言い換えれば、

責任は形式から構造へと移る

のです。

そしてこの変化は、制度よりも先に現場から始まります。

「対応」という仕事は消えるが「責任」は残る

ここで、最初の問いに戻ります。

“監査対応という言葉は、あと何年残るのでしょうか”

この問いに対する答えは、もう見えています。

監査対応という「作業」は消えます。

資料を集めることも、Excelを整形することも、会議で説明することもなくなります。

むしろ、より本質的な形で残ります。

そして最後に残るのは、

誰がその判断に責任を持つのか

という問いです。

最初の問いに戻る

「どこで判断し」
「どこに責任を持ち」
「どこに価値を出すのか」

この問いは、サッカーだけのものではありません。

ビジネスでも、そしてこれからのAIとAgentの世界においても、同じです。

技術がどれだけ進化しても、構造がどれだけ洗練されても、この問いそのものが消えることはありません。

監査は状態になる

最後に、この記事全体の結論です。

監査とは、

後から証明する活動ではありません

常に証明されている状態です

その状態を実現するために、

• プロセスを設計し
• データを構造化し
• 責任を明確にする

それこそが、これからのビジネスにおける本質です。

いよいよ、明日。侍ブルー、頑張れよ！

以上、室長でした。