架空のA社で考えてみます。社員は30人で、経理は2人です。会計はfreee（アドバンス。仕訳承認フローを使っています）、経費精算と請求書の受け取りはバクラクで回しています。
A社は半年前から、freeeと連携する市販のAIエージェントに仕訳を起票させています。カード明細と請求書のデータを読み、勘定科目と税区分を判定して、freeeに「申請中」の仕訳として登録します。経理担当のBさんが内容を確かめて承認する、という運用です（数字や会社名は仮のものです）。
3か月ほど順調に回ったところで、監査法人の担当者から連絡が入ります。「仕訳テストの準備として、仕訳入力の方法と承認の流れを教えてください。AIを使っている場合はその内容も」
Bさんは「AIが案を作って、私が全件見て承認しています」と答えるつもりです。ただ、指示文（プロンプト）を誰がいつ変えたか、入力データに漏れがないかの確認手順は、まだ整えていません。
この記事では、AIエージェントの仕訳起票で監査法人から聞かれることを、一次資料と実務の見立てを分けて整理します。AIを統制のどこに置くかの全体像は経理や業務にAIを入れたときの監査対応の記事、ITGCの詳細はSaaSで経理を回す会社に残るITGCの記事、承認フローと自動仕訳は承認フローや自動仕訳をITACとして評価する記事で扱っています。
AIエージェントが仕訳を起票しても、監査人による仕訳テスト（監基報240）は省略できません。仕訳テストは、経営者による内部統制の無効化リスクへの対応として、すべての企業に義務づけられています。AIの仕訳起票で問われるのは、指示文と科目マッピングの変更管理、入力の完全性（漏れがないか）と出力の正確性（科目・金額・税区分が正しいか）の検証の仕組み、不正リスクの文脈でAIの仕訳をどう位置づけているかの3点です。仕訳の自動作成は「統制の本体」ではなく「人の統制の前工程」として設計し、検証の記録を残しておくと、説明の土台になります。
この記事の要約
仕訳は監査で必ずテストされる
仕訳テストは、AIを使っているかどうかにかかわらず行われます。
この記事に出てくる用語
| 用語 | ひとことで言うと | 身近な例（架空のA社） |
|---|---|---|
| 仕訳テスト | 監査人が仕訳の入力や修正に不正がないかを検証する手続 | 期末の仕訳を抜き出し、証憑と突き合わせる |
| 内部統制の無効化 | 経営者や権限のある人が統制を迂回すること | 承認なしで仕訳を直接登録する、AIの出力を確認せずに承認する |
| 指示文（プロンプト） | AIに渡す作業の指示 | 「タクシー代は旅費交通費、消費税は課税仕入10%で起票する」と書いた指示と勘定科目の対応表 |
| 科目マッピング | 取引の内容と勘定科目の対応づけ | カード明細の「JR東日本」→ 旅費交通費、「Amazon」→ 消耗品費 |
| 完全性 | 記録した取引に漏れや重複がないこと | カード明細が412件なのに、AIが作った仕訳が409件なら3件の漏れがある |
| 正確性 | 取引が正しい科目・金額・税区分で記録されること | 会議室の利用料を「会議費」でなく「地代家賃」に入れていないか |
| ITAC（ITに係る業務処理統制） | システムに組み込まれた個々のチェック | AIが仕訳を「申請中」で登録し、承認者でない限り確定しない仕組み |
仕訳テストの根拠
監査基準報告書240（不正リスクへの対応）は、経営者による内部統制の無効化リスクを「特別な検討を必要とするリスク」と位置づけています。このリスクは「全ての企業に存在する」とされ、監査人の評価にかかわらず、仕訳入力と修正の検証手続を立案・実施しなければなりません（第30項・第31項）。
仕訳テストで監査人が検証の対象を選ぶとき、不適切な仕訳がもつ特性が手がかりになります。監基報240は、詳細テストを実施する仕訳を識別・抽出する際に関連する特性として、次の5つを挙げています（A41項）。
| 特性 | A社に当てはめると |
|---|---|
| 取引とは無関係な、またはほとんど使用されない勘定を利用した仕訳 | 通常使わない科目への仕訳がAIで生成されていないか |
| 仕訳の入力担当者以外が入力した仕訳 | AIエージェントのIDで登録された仕訳のうち、手動で修正されたもの |
| 期末または締切後の仕訳のうち、摘要欄の説明が不十分なもの | 決算月やその直後にAIが作った仕訳で摘要が空のもの |
| 未登録の勘定科目を用いた仕訳 | AIが科目マッピングにない取引を別の科目に振ったもの |
| 同じ数字が並ぶ金額の仕訳（0000、9999など） | AIがデフォルト値を入れた可能性のある仕訳 |
A社で、Bさんが全件を見て承認しているなら、それ自体は統制です。ただし監基報240は、自動化されたプロセスが誤謬のリスクを減らしても、「自動化されたプロセスを不適切に無効化するリスクに対応しない」としています（A40項）。AIが仕訳を作っていても、仕訳テストの対象から外れません。
指示文と科目マッピングは変更管理の対象にする
AIエージェントの動きを決めているのは指示文と科目マッピングです。この2つが変わると、仕訳の科目や金額が変わります。
監査基準報告書315の実務ガイダンスは、自動化された統制を評価するとき、プログラムのバージョンアップがなくても「環境設定の変更により統制に影響が生じている可能性」に留意するとしています（Q23）。指示文と科目マッピングは、法令上「プログラム」ではありませんが、システムの出力を決める設定という点では同じ性格を持ちます。変更管理の考え方を当てはめておくと、監査での説明がしやすくなります。
A社なら、次の3点を残しておくと説明の材料になります。
- 指示文と科目マッピングの版番号と変更日
- 変更の理由と、誰が変更を承認したかの記録
- 変更前後でAIの出力がどう変わったかの確認記録（テスト用のデータで数件流して比較する）
AI事業者ガイドラインは、AI提供者（AIサービスを提供する事業者）が関係者に提供する情報の例として「AIシステムの更新を行った場合の更新内容及びその理由」を挙げています（第4部 P-6)ii）。これはAI提供者向けの記述ですが、この考え方を参考に、自社の指示文の変更も同じように管理しておくと説明しやすくなります。
入力の完全性と出力の正確性を仕組みで確かめる
AIの仕訳が正しいかだけでなく、元のデータが全件処理されているかも確かめます。
実施基準は、財務報告の信頼性を確保するためのITの統制の目的を「会計上の取引記録の正当性、完全性及び正確性を確保すること」と定義しています。完全性とは「記録した取引に漏れ、重複がないこと」、正確性とは「発生した取引が財務や科目分類などの主要なデータ項目に正しく記録されること」です。ITに係る業務処理統制（ITAC）の具体例の筆頭にも「入力情報の完全性、正確性、正当性等を確保する統制」が挙げられています（実施基準 II.2(6)②）。
AIの仕訳起票では、この2つを次のように確かめると実務で回しやすくなります。
| 確かめること | 具体的なやり方 | A社の例 |
|---|---|---|
| 完全性（漏れ・重複） | 元データの件数・合計金額と、AIが作った仕訳の件数・合計金額を照合する | ある月のカード明細412件・合計186万円に対し、仕訳が412件・合計186万円で一致するかを月次で確かめる |
| 正確性（科目・金額・税区分） | 全件または一定額以上の仕訳を人が確認し、修正した件数と内容を記録する | Bさんが全件を確認し「科目5件・税区分2件を修正」と1行で記録する |
| 処理できなかった取引 | AIがエラーで処理できなかった取引を一覧にし、手動で起票する | 科目マッピングにない取引（新しい取引先など）をエラー一覧で拾う |
テクノロジー委員会研究文書第11号（テク研11号）は、AIの基礎データの正確性や網羅性を検証できる内部統制の整備が重要だとしています（II.5）。上の照合がこれに当たります。
A社で、ある月のカード明細が412件でAIの仕訳が409件だったとします。仕訳の409件をいくら丁寧に見ても、漏れた3件には気づけません。元データとの件数照合は、人の目視とは別に仕組みとして入れておく必要があります。
AIが作った仕訳と不正リスク
監査人は仕訳テストで、AIが作った仕訳も不正リスクの観点から見ます。
監基報240は、ITが情報の自動的な転送に使われている場合、「そのような介入についての可視的な証拠がほとんど又は全くないことがある」としています（A40項）。AIエージェントが仕訳を自動で作って登録する場合も同じです。仕訳の中身だけでなく、仕訳がどのように作られたか（入力、処理、登録の経路）を監査人が追えるようにしておくことが求められます。
A社で説明しやすい形にするには、次の記録を残します。
- AIエージェントのID（freeeのメンバー）を人と分ける。AIのIDを申請経路の承認者にも管理者にもしない（管理者は代理承認ができるため）
- AIが作った仕訳の入出力ログ（いつ、何の明細から、どの指示文の版で、何の仕訳を作ったか）
- 人が修正した仕訳の修正前後の記録
freeeでは、取引を直接作成する連携サービスの仕訳の承認ステータスは、連携方法（freeeのAPIを使う連携か、他社API等からの連携か）と、利用を許可した人が申請経路の承認者であるかによります。freeeのAPIを使う連携サービスで承認者が利用を許可した場合、仕訳は「承認済み」で登録されます（エンタープライズプランで自己承認機能を「使用しない」に設定している場合を除く）。他社API等からの連携はすべて「申請中」です。AIエージェント用のメンバーを別に作り、承認者にも管理者にもしなければ「申請中」で止まるので、Bさんの確認を経てから帳簿に入る形になります。利用するAIエージェントがどの連携方法に当たるかは製品によって異なるため、テスト用の事業所で動きを確かめてから本番で使うと安心です（2026年10月時点のfreee公式ヘルプ）。
監基報315は、仕訳入力に関する内部統制を、アサーション・レベルの重要な虚偽表示リスク（決算書の大きな誤りにつながるリスク）に対応するものとして「全ての監査において識別されることが想定される内部統制」としています（A148項）。AIが仕訳を作る形にしても、この内部統制の識別から外れません。
読み違えやすいポイント
| 読み違えやすい読み方 | 原文では | 根拠 |
|---|---|---|
| AIが仕訳を作れば、人の手が入らないので不正リスクが下がる、と読まれがちです | 監基報240は、自動化されたプロセスが不注意の誤謬を減らしても「自動化されたプロセスを不適切に無効化するリスクに対応しない」としています。AIが作った仕訳も、人による事後修正の余地があれば不正リスクは残ります | 監基報240 A40項 |
| 指示文（プロンプト）はプログラムではないので、プログラム変更管理の対象外、と読まれがちです | 基準は指示文を名指ししていませんが、実務ガイダンスは「バージョンアップがなくても、環境設定の変更により統制に影響が生じている可能性」に留意するとしています。指示文はシステムの出力を変える設定であり、変更管理の考え方が当てはまります | 315実務ガイダンスQ23 |
| 315実務ガイダンスQ18の5つの留意点は、AIの仕訳起票に直接適用できる、と読まれがちです | Q18は「需要予測に基づき商品単価を自動変動させるなど売上計上に関連してＡＩを利用する場合」のQ&Aです。仕訳起票への直接適用を述べたものではありません。参考として読み替えることはできますが、そのまま当てはめるには前提が異なります | 315実務ガイダンスQ18 の5 |
決めておく項目の一覧と、明日からやること
冒頭の質問への答えになるのは、AIエージェントの仕訳起票について次の4項目を整えておくことです。
| 項目 | 内容 | A社の例 |
|---|---|---|
| 権限 | AI用のメンバーを人と分け、承認者・管理者にしない | AIのfreeeメンバーは「申請のみ」の権限 |
| 変更管理 | 指示文と科目マッピングの版・変更理由・承認 | 変更時にGitまたはスプレッドシートで版を管理 |
| 検証 | 件数・金額の照合と、人による確認の記録 | 月次でカード明細の件数・合計と仕訳の件数・合計を照合 |
| ログ | AIの入出力ログと人の修正記録 | いつ・何の明細から・どの版で・何の仕訳を作ったか |
明日から始められることを、手間の小さい順に並べます。
- AIエージェント用のfreeeメンバーを作り、申請経路の承認者と管理者から外す。テスト用の事業所で仕訳が「申請中」で止まることを確かめる
- 現在の指示文と科目マッピングに日付と版番号を付け、変更する前に承認を取る運用を決める
- 月次で、元データの件数・合計金額とAIが作った仕訳の件数・合計金額を照合する手順を決める
- 人が確認した範囲・観点・修正件数を1行で記録する様式を作る
- 監査法人に、AIエージェントで仕訳を起票していることと、上の4項目を伝え、仕訳テストの進め方を協議する
テク研11号は、AIを使っても「経理処理や開示内容の妥当性に関する説明責任は会社が負う」としています（II.5）。仕訳の説明責任がAIに移るわけではありません。AIを統制のどこに置くかの全体像は経理や業務にAIを入れたときの監査対応の記事にまとめています。
IT統制・J-SOX対応の進め方をご相談ください
使っているSaaSの洗い出し、IDと権限・設定変更の記録の始め方、SOC1レポートの読み込み、監査法人との協議に出す案づくりまで、公認会計士とエンジニアが一緒に整理します。