承認フローや自動仕訳は「統制」として頼れるのか——ITACの3つの型と、監査で確かめられること ‣ はてなベース株式会社

監査法人のショートレビュー（上場準備の初めに監査法人が行う予備調査）を終えた翌週、経理責任者のもとに質問票が届きます。「仕訳の承認フローと自動登録ルールは、ITACとして整理しますか。設定の変更管理とあわせてご説明ください」。経理の現場では、月に1,200件ほどの仕訳のうち、800件が銀行明細やカード明細から自動で登録され、残りの400件を担当者2人が起票して課長が承認しています（数字は仮のものです）。承認は画面のボタンで済ませています。

経理責任者が迷うのは、この承認や自動登録を「統制」と呼んでよいのか、という点です。人が1件ずつ見ていないなら監査法人は信用しないのではないか、反対にシステムが止めるのだから人の確認は要らないのではないか、と考えが行き来して、質問票に何と書けばよいかが決まりません。

この記事では、基準の定義、統制の3つの型、自動化された統制が少ない件数で評価される理屈、freee会計の仕訳承認フローで外せない設定を、金融庁の実施基準と日本公認会計士協会の報告書に当てて確かめます。SaaS環境のIT全般統制（ITGC）の詳細はSaaSで経理を回す会社に残るITGCの記事、上場までの時間軸はIPO準備のJ-SOXロードマップの記事で扱います。

承認のない仕訳を帳簿に反映させないシステムの制御や自動計算は、実施基準で「ITに係る業務処理統制（ITAC）」と呼ばれ、ITGCが有効なことを前提に、人の確認より少ない件数で評価できます。ただし、承認者が内容を見て判断する部分は人の統制として残ります。統制を「自動化された統制」「人とITが一体の統制」「手作業の統制」に分けると、確かめる場所が変わります。自動化された統制は設定と処理のパターンごとのテスト、人とITが一体の統制は人の確認と、人が見る一覧の正確性・網羅性です。freee会計の仕訳承認フローは、起票した人やAPI連携を許可した人が承認経路の承認者だと承認済みで登録されるため、置き方しだいで承認を素通りします。文書には「どのシステムの、どの設定が、どのリスクをおさえているか」まで書き、設定とテストの結果を記録に残します。
この記事の要約

ITACとは、業務の流れに組み込まれたITの統制のこと

実施基準は、ITACを「ITに係る業務処理統制」と呼び、業務を管理するシステムにおいて、承認された業務がすべて正確に処理、記録されることを確保するために業務プロセスに組み込まれたITに係る内部統制と定義しています（実施基準 I.2(6)②〔ITの統制〕ロb）。ITAC（IT Application Controls）は実務の呼び名です。対になるITGC（ITに係る全般統制）は、ITACが有効に機能する環境を保証する統制で、アクセス管理や変更管理が当たります。

実施基準が挙げる4つの具体例を、クラウド会計に置き換えると次のようになります。

実施基準の例示	クラウド会計での例
入力情報の完全性、正確性、正当性等を確保する統制	貸借が一致しない仕訳は登録できない。承認されるまで決算書に反映されない（試算表も初期表示では除かれる）
例外処理（エラー）の修正と再処理	連携に失敗した明細がエラーの一覧に出て、担当者が直して再登録する
マスタ・データの維持管理	取引先や勘定科目の登録・変更を、決められた人だけができる
システムの利用に関する認証、操作範囲の限定などアクセスの管理	担当者の権限では承認ボタンが表示されない。締めた月を編集できない

表の右列は、経理の担当者が毎日使っている機能です。実施基準も、これらは手作業でも実施できるが、システムに組み込むとより効率的かつ正確になると書いています。ITACの整理は、統制を新しく作るというより、動いている機能のどれに頼るかを選ぶ作業です。

監査人の基準である監査基準報告書315には「情報処理統制」という近い言葉があり、データの網羅性、正確性、正当性のリスクに直接対応する内部統制と定義され（第11項(9)）、自動化されている場合と手作業の場合があるとされています（A5項）。質問票の「ITAC」は、情報処理統制のうちITに組み込まれたもの、またはITが出す情報を使うものにおおむね当たります。情報処理統制のほうが範囲は広く、ITを使わない手作業の照合なども含みます。

統制を3つの型に分けると、確かめる場所が変わる

実務では、業務の流れにある統制を、ITへの頼り方で3つの型に分けて整理することがよくあります。図に要点を、表に詳しい中身をまとめます。

統制の3つの型（システムだけの自動化された統制、人とシステムが一体の統制、人だけの手作業の統制）を線画で並べ、それぞれの例、評価で確かめること、件数の考え方を示した図

型	例	評価で確かめること	件数の考え方
自動化された統制	承認されない仕訳は決算書に反映されない（承認の有無による制御）。ワークフロー製品で、金額が一定以上だと承認者が増える	設定の内容、設定を変えられる人、処理のパターンごとに流して設定どおりに動くか	ITGCが有効なら、ITACごとに1つを検証する方針が例示されている
人とITが一体の統制	承認者がシステムの画面で仕訳の内容を見て承認する。システムが出した未承認仕訳の一覧や滞留債権の一覧を、課長が見て判断する	人の確認の証跡と、一覧そのものが正確で漏れがないこと	人の確認は頻度に応じた件数。一覧の正確性は別に確かめる
手作業の統制	請求書と契約書を目で見て照合する	照合の証跡	頻度に応じた件数（日次以上なら25件の例示）

3つの型は実務の整理で、基準の言葉と1対1には対応しません。実施基準は、ITを利用した内部統制に「自動化されている内部統制」と「人手とコンピュータ処理が一体となって機能している内部統制」があると書き（II.3(3)⑤イ）、手作業によるITACもあるとしています（II.3(3)⑤ニb）。表の2行目は、この手作業によるITACと重なります。

この記事では「承認」を2つに分けます。承認がないと帳簿に反映しない制御は自動化された統制、承認者が内容を見て判断する行為は人とITが一体の統制です。315実務ガイダンス第1号も電子承認について、承認なしで次の処理に進めない制御かと、承認が正当な権限者・本人によるものかを分けて書いています（Q16）。

型を分ける意味は、評価の手間と不備の広がり方が違うことにあります。自動化された統制は、設定が変わらない限り同じ動きを続けるので、処理のパターンごとに確かめれば足りる一方、誤った設定は全件に及びます。実施基準も、人とITが一体の統制の不備は原因が人かITかを見分け、ITなら同じ誤りの繰り返しに留意するよう求めています（II.3(4)③ロ）。

実施基準は、自動化されたITACでも過信せず、電子記録に変更の痕跡が残りにくいと無効化の発見が遅れることに留意するよう書いています（II.3(3)⑤ニb）。設定を誰が変えられるか、変えたら記録が残るかが、自動化された統制を頼れるものにする条件です。

人とITが一体の統制は、一覧と人の確認の2か所を確かめる

いちばんつまずきやすいのが人とITが一体の統制です。月末に経理課長が「未承認のまま残っている仕訳の一覧」を出して処理を指示するとします。確認の記録を残していても、それだけでは足りません。一覧から仕訳が漏れていれば、課長は漏れた分を見ないまま確認を終えるからです。下の図のように、確かめる場所は一覧と人の確認の2か所です。

システムが未承認仕訳の一覧を出力し、経理課長が一覧を見て処理を指示し、月次の締めに進む流れと、一覧の正確性・網羅性と確認の記録という2か所の確かめることを示した図

監査人はこの一覧を「企業が作成した情報」と呼び、その正確性と網羅性の証拠を入手します（監査基準報告書500 第8項）。実務ではIPE（Information Produced by the Entity）と呼ばれます。315実務ガイダンス第1号は、延滞債権リストを使う統制を「ITから自動生成される情報を利用して実施される手作業による内部統制の代表例」とし、基になるデータの正確性と、条件に当たるものが漏れなく抽出・集計されていることを評価すると書いています（Q21）。

一覧の正確性と網羅性は、次の3つを記録しておくと説明できます。

業務上の定義と、システムの抽出条件が合っていること（例「未承認」とは承認ステータスが申請中のもの。対象期間は当月の全日付）
一覧の件数と合計金額が、元のデータ（仕訳帳や補助元帳）と一致すること
抽出条件を保存し、誰がいつ条件を変えたかが分かること

同ガイダンスは、ITGCが有効でなければ、ある時点で一覧が正しくても継続して正しいという心証は得られないとも書いています（Q20・Q21）。一覧をスプレッドシートで加工しているなら、加工の過程も説明できるようにします。

自動化された統制が少ない件数で済む理屈

手作業の統制の評価でよく聞く「25件」には根拠があります。実施基準は監査人の手続の説明（III.4(2)①ロa）で、日常反復継続する取引について統計上の二項分布を前提とすると、90%の信頼度を得るには統制上の要点ごとに少なくとも25件のサンプルが必要になると書いています（参考図3にも同じ記載があります）。経済産業省の「システム管理基準追補版（財務報告に係るIT統制ガイダンス）」は、全社的な内部統制が適切であることを前提にした例として、頻度ごとのサンプル件数を表にしています（付録図表1-1）。

統制の頻度	サンプル件数	許容逸脱件数
1日につき多数	25件	0件
日次	25件	0件
週次	5件	0件
月次	2件	0件
四半期次	2件	0件
年次	1件	0件

追補版によると、無限大の母集団から25件を無作為に選んで1件も逸脱がなければ、全体で9%以上の逸脱はないと信頼水準90%で説明できます。四則演算で確かめると、9%の割合で承認漏れがある母集団から25件続けて漏れに当たらない確率は、0.91を25回掛けた約0.095で10%を下回り、24件だと約0.104で10%を超えます（筆者の計算）。なお追補版は、週次以下の件数は統計的方法によるものではないと明記しています。

この理屈は、人が判断するので1件ごとに結果がばらつく前提に立っています。実施基準は、ITを利用した内部統制は一貫した処理を反復継続するため、整備状況が有効なら、ITGCの有効性を前提にサンプル件数を減らし、対象期間を短くできるとしています（II.3(3)④ニa）。追補版の付録図表1-2は、関連するITGCが有効に機能していると判断できる場合に「IT業務処理統制ごとに1つのアプリケーションを検証する」方針を例として示しています。

統制の型	冒頭の会社の承認（手入力の仕訳月400件、年4,800件）に対する評価の例	前提
承認者の判断（人の統制）	評価の対象期間全体から25件を選び、承認の証跡と、承認者が内容を確かめた記録を見る	1日に多数行われる統制として付録図表1-1を当てた場合
承認がないと決算書に反映しない制御（自動化された統制）	設定を確認し、承認者でない担当者の起票、承認者の起票、連携アカウントからの登録をそれぞれ流して、申請中で止まるか（承認者の起票は設定どおりの状態になるか）と、申請中の仕訳が決算書に出ないことを見る	ITGCが有効であること

図にすると、同じ「承認」でも見るものと件数の取り方がまったく違うことが分かります。

承認者の判断（人の統制）は対象期間から25件、承認がないと決算書に反映しない制御（自動化された統制）は設定と起票の経路ごとのテストで評価することを左右で比べた図

少ない件数で済むのは、確かめる対象が個々の仕訳ではなく設定だからです。315実務ガイダンス第1号も、処理のパターンが同じであれば、抽出したもの以外も同様の信頼性になると書いています（Q15）。裏返せば、パターンが違えば別に確かめます。仕訳承認フローは起票した人や連携の経路で動きが変わるので、経路ごとに仕訳を流して確かめます。また、制御のテストは承認者の判断までは確かめないので、その評価は人の統制として別に残ります。件数と取り方は、計画の段階で監査法人と合意しておくと手戻りを防げます。

ITGCの整備が間に合わない年には、業務処理統制の運用評価の範囲を広げて、全般統制の運用評価をせずに十分な心証を得る道もあります（実施基準 II.3(3)⑤ニa）。ITACそのものを多めの件数で確かめるやり方で、ITGCの記録がそろう前の年をつなぐ手段として監査法人と相談する価値があります。

ITGCに不備が出たときは、まず補えているかを考える

ITGCに不備が見つかると、ITACまで頼れなくなるのではと心配になります。基準はここを段階を追って考えます。図は、実施基準 II.3(4)③イ、財務報告内部統制監査基準報告書第1号の第64項・第68項・A156項、金融庁の内部統制報告制度に関するQ&A（問14）をもとに、筆者が整理したものです。

ITGCに不備が見つかったとき、代替的・補完的な統制で補えているか、ITACが有効に機能していると検証できるかを順に確かめ、どちらも満たさなければ影響を受けるITACと勘定科目を特定して開示すべき重要な不備かを検討する流れを示した図

実施基準は、ITGCの不備は虚偽記載のリスクに直接つながるものではないため、直ちに開示すべき重要な不備とはならないとしています（II.3(4)③イ）。金融庁のQ&A（問14）は、プログラムの変更管理に不備があっても、事後的に実際のプログラムに変更がないことを確認できたような場合には、そのシステムの内部統制は有効に機能していると位置づけることができると考えられる、と例を挙げています。

ただし問14の例はプログラムの変更管理の不備です。「承認経路の設定を誰でも変えられた」というアクセス管理の不備なら、設定が変わっていないことに加え、設定を変えられた人が代理承認や承認済み仕訳の編集をしていないかも、承認履歴や変更履歴で確かめます。処理結果のデータが簡単に変えられては十分な信頼性が得られないためです（315実務ガイダンス第1号 Q15）。

事後の確認には変更の痕跡が要ります。freee会計の仕訳設定変更履歴（エンタープライズ）の対象は仕訳関連設定で、承認経路や権限の変更がどの履歴に残るかは自社の環境で確かめてください。設定画面を保存しても、示せるのはその時点の状態だけです。ベンダー側のプログラム変更は利用者が確かめられないので、SOC1レポート（SOC1レポートの読み方の記事）で補います。

反対向きの波及もあります。内基報1は、ITACの開示すべき重要な不備がITGCの不備に起因するなら、ITGCの不備もあわせて開示すべき重要な不備になるとし（A156項）、補完統制を考慮するときは、有効に整備・運用されていることを検討するとしています（第68項）。月次レビューで補えていると言うなら、その記録も評価に耐える形で残します。

前年度の評価結果を使える条件と、2つの監査での扱い

変わらない統制に毎年同じテストが要るのか、という疑問も出ます。実施基準は、評価は原則毎期としたうえで、自動化された統制は条件を満たせば過年度の評価結果を継続して利用できるとしています（II.3(3)⑤ニc）。

誰の評価か	前年度の結果を使える条件	年数
経営者（自動化されたITAC）	過年度に不備なく有効と評価された。評価の時点から統制が変更されていない。障害・エラー等の不具合が起きていない。関連するITGCが有効。これらを確認して記録する（実施基準 II.3(3)⑤ニc、追補版付録図表1-2）	特定の年数を機械的に当てはめない
経営者（ITGC）	財務報告の信頼性に特に重要な影響を及ぼす項目を除き、前年度の評価結果が有効で、整備状況に重要な変更がない。その旨を記録すれば、前年度の運用状況の評価結果を継続して使える（実施基準 II.3(3)⑤ニa（注））。整備状況の確認は毎期行う	特定の年数を機械的に当てはめない
監査人（内部統制監査）	自動化された統制は、変更なし・障害エラーなし・関連ITGC有効を検討した結果を記録すれば、過年度の検討結果を継続して使える（内基報1 A138項）。ITGCも同様（A154項(3)③）。経営者の評価結果の妥当性は毎期検証する（A82項）	一律の定めはなく、特定の年数を機械的に当てはめない
監査人（財務諸表監査で統制に依拠する場合）	過年度の監査後に重要な変更がないことの証拠を入手する。変更がなくても少なくとも3年に1回は運用評価を行い、毎期どれか一部は評価する。特別な検討を必要とするリスクに対応する統制は毎期評価する（監査基準報告書330 第13項(2)・第14項）	少なくとも3年に1回

表の1行目の条件は4つで、追補版も「4つの条件に適合していることを記録し」と書いています。「変更されていない」には注意が要ります。315実務ガイダンス第1号は、パッケージならバージョン情報で変更の有無を確かめられるが、環境設定の変更にも留意するとしています（Q23）。バージョンを確かめにくいSaaSでは、ベンダーの変更管理をSOC1レポートで確かめ、リリース情報で統制に関わる変更がないかを見て、自社の設定変更の記録と組み合わせます（SOC1レポートの読み方の記事）。

「少なくとも3年に1回」は、財務諸表監査で監査人が統制に依拠し、過年度の証拠を使う場合の規定です。内部統制監査には年数の下限はなく、経営者の評価と同じく特定の年数を機械的に当てはめません。ただし2つの監査は原則として同じ業務執行社員のもとで一体として行われ、証拠も相互に使われます（内基報1 第7項・第9項）。経営者が継続利用を選んだ統制でも、財務諸表監査の手続として資料やサンプルを求められる年がありえます。どの年にどの統制をテストするかは、年間の計画の段階で監査法人と擦り合わせておきます。

上場準備の会社には、まだ前年度に有効と評価された実績がないので、継続利用は2年目以降の手段と考えます（期ごとの計画はIPO準備のJ-SOXロードマップの記事）。

freeeの仕訳承認フローは、置き方しだいで承認を素通りする

具体例として、freee会計の仕訳承認フローを取り上げます。以下は2026年10月時点の公式ヘルプ（2026年7月27日更新の「仕訳承認フロー」ページなど）で確かめた内容です。機能やプランは変わるので、評価の前に最新のヘルプを見直してください。

仕訳承認フローは、承認経路の承認者でない人が登録した仕訳を「申請中」にし、承認されるまで帳簿に反映させない機能で、法人の新プランではアドバンスとエンタープライズで使えます。申請中の仕訳は、試算表と総勘定元帳の初期表示から外れ（絞り込めば表示可）、決算書には反映されません。一方、損益レポートや支払管理レポートには常に反映されます。どのレポートを母集団に使うかで、見える仕訳が変わります。

押さえるべきは、仕訳が作られた時点のステータスです。ヘルプの表を抜き出します。

仕訳の作られ方	作成時のステータス
承認経路の承認者でない人が作成	申請中（管理者権限でも、承認経路に入っていなければ申請中）
承認経路の承認者が作成	承認済み
freeeのAPIで取引を作る連携サービスで作成し、連携の利用を許可した人が承認者	承認済み
同上で、連携の利用を許可した人が承認者でない	申請中
他社のAPI等から連携して作成（ヘルプの例示はSquare、スマレジ、Amazon）	申請中

図では、仕訳の作られ方ごとに作成時のステータスへ矢印を引き、承認済みで入る2つの経路に✕を付けています。

freee会計の仕訳承認フローで、仕訳の作られ方5つから作成時のステータス（申請中・承認済み）へ矢印を引き、承認者が作成した仕訳と承認者が許可したAPI連携の仕訳が承認済みで入る落とし穴を示した図

表の2行目と3行目が落とし穴です。承認者が起票すれば、誰の確認も経ずに承認済みで入ります。API連携も、連携の利用を許可したのが承認経路の承認者なら、連携で入る仕訳は承認済みになります。管理者のアカウントで許可しても、承認経路に入っていなければ申請中です。エンタープライズプランでは、自己承認機能を「使用しない」に設定すると、承認者が登録した仕訳や連携サービスの仕訳も申請中で登録されるようになりますが、アドバンスプランでは自己承認を禁止できません。

ほかにも設計に効く仕様があります。管理者と、管理者をコピーして作ったカスタム権限のメンバーは、承認経路に入っていなくても代理で承認できます。承認済みの仕訳を管理者や承認者が編集・削除できるかは、「承認仕訳の編集・削除機能」を「使用しない」にすることで止められます。ただし現在の設定が過去の仕訳にも効くので、一時的に「使用する」へ戻すと承認済み仕訳を書き換えられます。この設定の変更も記録の対象です。また、固定資産の減価償却など自動で作られる仕訳はこの設定の対象外で、承認済みの仕訳を申請中に戻すこともできません。

設定・運用	統制上の意味
起票する人を承認経路に入れない	起票と承認の職務を分ける
API連携を許可するアカウントを、承認者でも管理者でもない専用のメンバーにする	承認者なら承認済みで入る経路を断ち、管理者なら代理承認で登録と確定を1つのアカウントでできる経路を断つ
管理者を最少の人数にする	承認経路の外からの代理承認を絞る
承認者を経路から外すときは、外す前に作られた申請中の仕訳を処理しておく	ヘルプでは、仕訳が作られた時点の経路のメンバーが承認できる
承認仕訳の編集・削除機能を「使用しない」にする	承認後の書き換えを止める
アドバンスプランなら、承認者や管理者のアカウントで起票された仕訳を月次で抽出し、別の人がレビューする	自己承認を禁止できない分を、人とITが一体の統制で補う（抽出に使える項目は自社の環境で確かめる）

表の最後の行は、実際に抽出できるかを確かめてから採用してください。承認者ごとの絞り込みや承認履歴は、ヘルプ上はエンタープライズの機能です。抽出できなければ、エンタープライズの自己承認禁止を検討します。

自動登録ルールには、候補を出すだけの「推測する」と、確認なしで登録する「登録する」があります。「登録する」の仕訳のステータスは、同じヘルプページの本文が「作成者が申請経路の承認者であるか否かによります」、表が「申請中」と一致しません。自社の環境で1件流して確かめてから統制の記述に書いてください。

AIエージェントに起票させるなら「申請中で登録、人が承認」を実際に流して確かめる

AIエージェントに仕訳を起票させる場合も考え方は同じです。AIが起票し、人が内容を確かめて承認する形は人とITが一体の統制で、仕訳承認フローを使えば「AIは申請中で登録するまで、確定は人」という職務の分離を設定で表現できます。

ただし、前の節の表がそのまま効きます。AIエージェントがfreeeのAPIにつながるとき、連携を許可したアカウントが承認経路の承認者なら、AIの仕訳は承認済みで帳簿に入るおそれがあります。管理者のアカウントで許可した場合は申請中になりますが、管理者は承認経路の外から代理承認できるので、AIの登録と確定が同じアカウントでできてしまいます。自社でつないだエージェントが表のどの行に当たるかは明記されていないので、「許可した人が承認経路の承認者だと承認済みで入る」前提で組み、本番の前に必ず流して、申請中で止まることを画面で確かめてください。

AIの起票を統制に組み込むときに決めておくことは、次のとおりです。権限の線引きはAIエージェントの権限・承認・停止の記事、出力の評価は評価設計の記事にも書いています。

AI用のアカウントやAPIの許可を人のアカウントと分け、承認者にも管理者にもしない
AIのアカウントから実際に流して申請中で止まることを確かめ、その画面を保存して整備状況の記録にする
承認する人が、AIの仕訳のどこを見て判断したかを記録に残す（承認ボタンを押しただけでは、人の確認の証跡として弱い）
AIへの指示文や連携の設定を変えたら、設定の変更として申請・承認・記録の対象にする
AIが誤った仕訳を出したときに止める人と手順を決めておく（進め方はAIの誤りへの対応の記事）

上の3つ目（判断の記録を残す）は、人の確認を統制として評価してもらうための点です。315実務ガイダンス第1号は電子承認について、正当な権限者か、本人か、承認漏れはないかの3点を満たさなければ有効な統制として機能しないとしています（Q16）。承認ボタンの記録はこの3点を示しますが、内容を確かめたことまでは示さないので、判断の記録で補う、というのが筆者の見立てです。AIの出力が正しい月が続くと承認は流し読みになりがちなので、月に一度は、承認者が修正を指示した件数（二段階承認なら差し戻し、一段階ならコメントや修正依頼の記録）を見て、確認が形だけになっていないかを確かめます。経理の月次をAIと人で分担する設計は、経理業務をFDE方式で本番化した記事も参考になります。

文書化は「どのシステムの、どの設定が、どのリスクをおさえているか」まで書く

監査で頼ってもらえるかは、最後は文書と記録で決まります。「システムで承認している」だけでは、評価する人が何を確かめればよいか分かりません。実施基準も、業務の流れ図の右列にシステムの欄を設け、その注記や業務記述書の中で業務処理統制の内容を書くことを例に挙げています（II.3(3)⑤ハ（注））。

リスクと統制の対応表（実務でいうRCM）の1行を、自動化された統制で書くと次のようになります。

項目	書き方の例
リスク	承認されていない仕訳が決算書に反映される
統制	freee会計の仕訳承認フローにより、承認経路の承認者でない者が登録した仕訳は申請中となり、承認されるまで決算書に反映されない（試算表も初期表示では除かれる）。承認者による内容の確認は、別の行（人とITが一体の統制）として書く
型	自動化された統制
システムと設定	freee会計（エンタープライズ）。事業所の詳細設定で仕訳承認フロー「使用する」、自己承認機能「使用しない」、承認仕訳の編集・削除機能「使用しない」。承認経路の承認者は経理課長と経理部長
設定を変えられる人	管理者権限の2名。設定の変更は申請・承認のうえで行い、仕訳関連設定は仕訳設定変更履歴で確認する（承認経路の変更が残る履歴は自社の環境で確認）
関連するITGC	アクセス管理（管理者権限の付与と棚卸）、設定の変更管理（SaaSで経理を回す会社に残るITGCの記事）
整備状況の評価	設定画面の保存。承認者でない担当者・承認者・連携アカウントのそれぞれで起票し、申請中で止まること、申請中の仕訳が決算書に出ないことを確認
運用状況の評価	ITGCが有効であることを前提に、件数を監査法人と合意して期中にテスト。設定の変更履歴を期末まで確認

「システムと設定」と「設定を変えられる人」の2行があれば、評価する人は設定画面と変更履歴を見れば済みます。

様式は自由です。実施基準は、業務の流れ図や業務記述書、リスクと統制の対応表について、企業が別途作っているものがあればそれを使い、必要に応じて補足すれば足り、必ずしも参考の様式による必要はないとしています（II.3(3)①（注）・②ロ（注））。既存の業務マニュアルに上の表の項目を足す進め方でも構いません。

実務用語と基準上の言い方の対応表

ITACまわりの用語は、現場の呼び名と基準の言い方がずれています。評価の文書には基準上の言い方を併記しておくと、根拠をたどりやすくなります。

実務用語	基準上の言い方と出典
ITAC（IT業務処理統制）	実施基準の「ITに係る業務処理統制」（I.2(6)②〔ITの統制〕ロb）。監査基準報告書315の「情報処理統制」（第11項(9)）が近いが、情報処理統制は手作業の情報処理の統制も含み、範囲が広い
ITGC（IT全般統制）	実施基準の「ITに係る全般統制」（I.2(6)②〔ITの統制〕ロa）。監査基準報告書315の「IT全般統制」（第11項(2)）
IT依存手作業統制（ITDM）	実施基準の「人とITが一体となって機能する統制活動」（II.3(4)③ロ）
IPE	監査基準報告書500の「企業が作成した情報」（第8項）。315実務ガイダンス第1号 Q20・Q21
3点セット	実施基準の参考2「業務の流れ図（例）、業務記述書（例）」と参考3「リスクと統制の対応（例）」
25件ルール	実施基準 III.4(2)①ロa と参考図3。頻度別の例は追補版の付録図表1-1
ベンチマーキング	実施基準の「過年度の評価結果を利用できる場合」（II.3(3)⑤ニc）

なお、古い解説が引くIT委員会実務指針第6号などは2022年10月13日付で廃止されており（日本公認会計士協会「IT委員会実務指針等の廃止について」）、いまは315実務ガイダンス第1号を参照します。クラウドサービスのベンダー側の統制を確かめるSOC1レポートの読み方はSOC1レポートの読み方の記事で扱います。

筆者たちが最初に誤解していたこと、うまくいかない置き方

この記事は、書き上げたあとに一次資料を取り直し、誤りがある前提で読み直しています。とくに承認、件数、年数は、覚えた形のまま書くと誤りになりやすいところでした。

直した点のうち、読者が同じように誤りそうなものを5つ残します。左の列は直す前の筆者たちの理解で、右の列は原文で確かめ直した内容です。

筆者たちが最初に考えていたこと	実際は	根拠
「3年に1回は運用評価が要るという下限が、J-SOXの監査にもある」	この下限は、財務諸表監査で監査人が統制に依拠し、過年度の証拠を使う場合の規定です。内部統制監査では、自動化された統制とITGCの前年度の検討結果の利用に一律の年数の定めがありません	監査基準報告書330 第13項(2)、内基報1 A138項・A154項(3)③
「承認フローを使えば、承認はまとめて自動化された統制になり、少ない件数で評価できる」	少ない件数で済むのは、承認がないと帳簿に反映しない制御のほうです。承認者の判断は人の統制として件数を取り、制御のテストも起票の経路ごとに流します	315実務ガイダンス第1号 Q15・Q16、追補版付録図表1-2
「自動登録ルールなど自動で入る仕訳は必ず申請中になるので、AIの起票と相性がよい」	freeeのAPIで取引を作る連携では、連携を許可した人が承認経路の承認者なら承認済みで入ります（エンタープライズで自己承認機能を「使用しない」にしていれば申請中）。自動登録ルールはヘルプの本文と表で記載が食い違うため、自社で確かめます	freeeヘルプ「仕訳承認フロー」（2026年7月27日更新）の本文、表と※2
「設定が期中に変わっていないと示せれば、設定を誰でも変えられた不備があっても、承認の制御は有効だと説明できる」	金融庁Q&A 問14の例は、プログラムの変更管理の不備です。アクセス管理の不備なら、代理承認や承認済み仕訳の編集がなかったかも履歴で確かめます	金融庁Q&A 問14、315実務ガイダンス第1号 Q15
「承認仕訳の編集・削除を『使用しない』にしておけば、過去の承認済み仕訳は守られ続ける」	仕訳を作った時点ではなく、現在の設定が効きます。一時的に「使用する」へ戻すと、過去の承認済み仕訳も書き換えられます	freeeヘルプ「仕訳承認フロー」

5つとも、基準や機能の名前だけで判断し、どの監査の規定か、どの経路の話か、いつの設定が効くかを確かめていませんでした。ヘルプは表と注記まで読み、自社の環境で流して確かめてください。

明日からやること

質問票の冒頭の問いに戻ると、承認のない仕訳を止めるシステムの制御や自動計算は、設定が勝手に変わらないと言える限り、統制として頼れます。そう言えるかどうかは、設定と、設定を変えられる人と、処理パターンごとのテストの記録で決まります。承認者が内容を見て判断する部分は、人の統制として別に記録します。明日から始められることを、手間の小さい順に並べます。