サーバーの運用、データベースのバックアップ、障害からの復旧は、SaaSではベンダーに移ります。自社はそれをSOC1報告書・公開情報・契約で確かめます。自社に残るのは、口座の同期やSaaS間の連携でデータが毎回全部入ったかの確認、エラーと障害の記録、自社データの控え、Excelの保全です。これらを運用記録の台帳に残すところから始めます。
この記事の要約
架空のA社（社員30人、経理2人、管理部長が情シスを兼務。会計はfreee会計のアドバンス、経費精算と請求書の受け取りはバクラク）の管理部長は、内部統制の評価の準備で、追補版（後述）の付録2-1にあるIT基盤質問書の例で自社の状況を書き出しました。バックアップの保管場所と世代管理（何回分を残すか）、直近1年間の重要な障害、他のシステムとの連携データと連携形式の欄で手が止まりました。書けたのは「バックアップはfreeeがやっているはず」までです。調べると、銀行口座の明細の同期が3週間前からエラーで止まり、その間の入出金が帳簿に入っていませんでした。
運用・管理の統制が守るのは、日々の処理が正しく動くことと、データが消えないこと
CFO・経理責任者が押さえておくのは、SaaSに替えても運用・管理は評価の対象に残り、自社の受け持ちが処理の結果の確認に変わる点です。
ITGC（IT全般統制）は、金融庁の実施基準では「業務処理統制が有効に機能する環境を保証するための統制活動」です。例として、システムの開発・保守、運用・管理、アクセス管理などの安全性の確保、外部委託に関する契約の管理の4つが挙がっています（4つの全体像はSaaSで経理を回す会社に残るITGCの記事）。この記事はその2つ目、運用・管理を扱います。なお、IDと権限は権限の棚卸の進め方の記事、設定の変更はSaaSの設定変更を記録に残す方法の記事、委託先の管理はSOC1レポートの読み方の記事で扱います。
経済産業省の「システム管理基準 追補版（財務報告に係るIT統制ガイダンス）」（2024年12月25日改訂、以下 追補版）の第IV章は、運用管理について、財務情報の入力から報告までの日常の業務処理の信頼性を確保できるように運用することが望まれる、としています。また、データ管理は、データの更新と保管の過程を管理して、その完全性、正確性、正当性を保証することを統制目標にしています。
つまり守るものは、毎日・毎月の処理が決めたとおりに全部、正しく動くことと、データが消えず、消えても戻せることの2つです。追補版は統制目標の例として、運用ルールと運用計画、例外処理を含む運用、ジョブスケジュール（定期処理をいつ実行するかの予定）に従った運用、運用状況の監視とログの記録・保管を挙げています（3-(2)-①-イ〜ヘ）。データ管理では、財務情報のバックアップとその復旧テストが統制目標に入っています（3-(2)-③-ニ・ホ）。
一方、監査人の側では、日本公認会計士協会の監査基準報告書315（以下 監基報315）が、ITGCの対象のITプロセスの1つに「IT業務の管理」を置いています。付録6は、その中身をジョブ・スケジューリング、ジョブの監視、バックアップと復旧、侵入の検出の4つで例示しています。ジョブは、実務でいう定期処理やバッチです。
ベンダーに移ったサーバーの運用・バックアップ・復旧は、報告書・公開情報・契約で確かめる
CFO・経理責任者が判断するのは、ベンダーに移った部分を確かめる材料です。SOC1報告書（ベンダーの統制を監査人が確かめた報告書）を入手するか、公開情報と契約で足りるとみるかを決めます。
SaaSでは、サーバーの運用、データベースのバックアップ、障害からの復旧、プログラムの変更はベンダーが行います。では、任せた部分は評価の外でしょうか。実は、そうとは限らないんです。経営者の評価では、委託業務が重要な業務プロセスの一部を構成していれば、受託会社の内部統制を評価します。金融庁の内部統制報告制度Q&A 問22は、情報システムの運用・保守等も委託業務に含まれ、財務報告への影響が重要なものが評価の対象になるとしています。なお、会計のSaaSの影響が重要かは、監査法人と協議して決める論点です。
監査人向けの315実務ガイダンス第1号のQ30も、クラウド会計システムを委託業務とし、データのバックアップ体制等が契約内容で十分にリスク対応されているかの検討が重要だとし、タイプ2の報告書（一定の期間の運用まで確かめた報告書）の入手を挙げています。追補版も、受託会社の障害に備えてサービスレベル合意（SLA。サービスの水準の約束）を結び、その状況を評価する、と書いています。とはいえ、Q&Aの問24は、受託会社の評価は自ら行っても受託会社の評価結果を使ってもよく、保証業務実務指針3402に基づく報告書（実務でSOC1報告書と呼ばれるもの）が必ず要るわけではない、としています。
確かめる材料は3つです。1つ目はSOC1報告書です。タイプ2なら、バックアップや障害対応の統制が対象範囲に入っていれば記述書に載り、受託会社の監査人が運用をテストした結果も付きます。どの統制が対象かは、報告書の統制目的の一覧で確かめます。利用する会社の側で整える前提の統制（委託会社の相補的な内部統制。実務ではCUECと呼ばれる）も書かれているので、自社の運用記録がそれを満たすかを見ます（詳しくはSOC1レポートの読み方の記事）。freeeは担当営業かプロダクト内のサポートへの問い合わせで報告書を提供し、バクラクは「SOC1 Type2報告書」の取得をセキュリティページで公表しています。2つ目は公開情報です。freeeはセキュリティページで、災害等でデータベースが毀損した場合に備えて全事業所・全サービスのバックアップデータを保持していると説明し、サービス稼働状況のページで障害とメンテナンスの情報も公開しています（2026年11月4日時点）。3つ目は契約です。障害時の連絡、復旧の目標、解約時のデータの返却の決まりを確かめます。もっとも、公開情報と契約だけで足りるかは実施基準やQ&Aに定めが無く、監査法人と話して決めます。
ここで取り違えやすいのが、自社のデータの控えです。ベンダーのバックアップや更新履歴は、基盤の毀損やシステムの不具合に備えるものです。実際、freeeの公式ヘルプ（2026年10月20日更新）は「freeeでは、削除したデータは復元できません」と書き、一括削除の前に取引・仕訳データ・固定資産台帳などをエクスポートしておくよう勧めています。つまり、操作ミスや一括削除、解約後に備えた控えは、自社でエクスポートして取ります。
決算で使うExcelも同じで、追補版はスプレッドシート等と関連するデータの定期的なバックアップを対策に挙げています。SaaS同士をつなぐ社内スクリプトの控えも、編集部の見立てでは同じように取ります。どのExcelに統制を置くかの線引きはExcelの集計やCSV連携の統制の記事で扱います。A社の質問書のバックアップの欄には、ベンダー側は確かめた資料を、自社側は控えを取る頻度と保管場所を書きます。
自社に残るのは、定期処理と連携が全部動いたかの確認と、エラーの記録
CFO・経理責任者が決めるのは、どの処理と連携を確認の対象にし、誰が日々結果を見て、誰がその記録を月次で承認するかです。
SaaS中心の会社にも、自社で設定して結果を確かめる処理があります。たとえば、自動で動くのは、銀行や法人カードの明細をfreee会計に取り込む口座の同期と、取り込んだ明細から仕訳を登録する自動登録ルールです。一方、人が実行するのは、バクラクで処理した経費精算や請求書のデータをfreee会計に送る連携と、月次の締めです。どれも、止まったまま誰も気づかないと、計上漏れや二重計上がそのまま決算に入ります。冒頭のA社で止まっていた銀行口座の同期が、その例です。
監基報315の付録6の例示表では、「複雑ではない市販ソフトウェア」の列で、ジョブ・スケジューリングは「バッチ処理は発生しない」、ジョブの監視は「ジョブの監視なし」で、どちらも統制は「無」です。しかし、同じ付録6は、中規模の環境では「特定のアプリケーションにおいて」ジョブの監視を「有」としています。また監基報315 付録5 第15項は、ITの利用から生じるリスクの影響を受けやすい特徴に「インターフェース接続のあるアプリケーション」（他のシステムとデータをやり取りするもの）を挙げています。なので、SaaS同士をつなぐ会社では、自社が設定する同期と連携を確認の対象にする、というのが編集部の見立てです。追補版の運用管理の評価手続の例も、運用状況を日誌等で確かめ、例外処理が承認されているか、処理の完全性と正確性が確保されているかを見るとしています。
残す記録は、動いたか、全部入ったか、エラーをどうしたか、の3つと、その月次の承認です。freee会計の口座同期では、エラー時や追加の操作が要るときに、ホーム画面の上部にメッセージが出ます。そこで、経理担当が毎営業日にこのメッセージと明細の件数を見て、確認した日と結果を台帳に1行残します。エラーが出た日は、再同期するか明細をアップロードで取り込み直し、その件数を書きます。freeeのヘルプ（2026年10月20日更新）によると、同期が止まっている間に取引を手で登録すると、再開後に二重登録になるおそれがあります。このため、その間は手で登録せず、再開後に件数を突き合わせます。
クレジットカードの明細は基本的に確定してから取り込まれる仕様なので、カードは毎営業日にエラー表示を見て、明細の件数は確定後に確かめます。バクラクからfreee会計への連携は、両側の件数・金額を月に1回突き合わせます。2022年8月の発表では、バクラク経費精算から連携した仕訳は振替伝票の形式で入るとされています。自社の連携設定で形式を確かめ、どの画面で数えるかを先に決めておきます。自動登録ルールは、設定を変えていないことと、登録された仕訳の勘定科目に異常が無いことを月次で見ます。ルールの追加や変更は設定の変更にあたるので、変更台帳に残します（SaaSの設定変更を記録に残す方法の記事）。
freeeのイベントログ（誰がいつ何を操作したかの記録）はエンタープライズプランだけの機能で、A社のアドバンスでは使えません。エンタープライズなら、連携も記録されるのでしょうか。実は、エンタープライズでも、他製品からのデータ連携と、連携に伴うfreee会計への反映は記録の対象外なんです。つまり、連携元の画面に履歴が残るかは製品ごとに確かめ、確認した結果は自社の台帳に残します。突き合わせに使う一覧の出し方はシステム帳票の正確性と網羅性を確かめる方法の記事で扱います。
障害や停止が起きたら、何が止まり、決算にどう影響したかを記録する
CFO・経理責任者が判断するのは、障害や停止があったときに、決算への影響をどこまで調べて記録に残すかです。
障害の復旧とメンテナンスはベンダーが行いますが、それでも自社に残る仕事があります。実施基準は、監査人が運用・管理で留意する点として、障害や故障等が発生した場合に、状況の把握、分析、解決等の対応が適切に行われていることを挙げています。追補版は、運用の作業ログと障害の内容・原因のログを記録・保管すること（3-(2)-①-ヘ）と、構成管理の中で緊急時を含む障害対応があること（3-(2)-②-ホ）を統制目標の例に挙げています。付録2-1のIT基盤質問書には「直近1年間の重要な障害」の欄があります。その注記には、重大な障害があれば内部統制がデザインどおりに機能していない可能性があるため、障害発生の有無と程度を理解する、とあります。しかも、この欄の記入例には「会計システムへの連携エラー」が挙がっており、連携の停止も障害として記録する対象と考えられます。
記録することは4つで、この順に書きます。まず、気づいた経路と日時、止まった範囲（どのサービスの、どの処理が、いつからいつまで）を書きます。次に、止まっていた間のデータが復旧後に全部入ったか、二重に入っていないかを件数で突き合わせます。最後に、再処理の結果と確認した人を書きます。たとえば、A社の銀行口座の同期なら、止まっていた3週間分の明細の件数を銀行の入出金明細と突き合わせ、取り込み直した件数と、仕訳を登録した日を残します。
障害の記録は、翌年度以降の評価にも関わります。自動化された統制（ITAC。詳しくは承認フローや自動仕訳をITACとして評価する記事）は、過年度に不備なく有効と評価され、その後に変更がなく、障害・エラー等の不具合が発生しておらず、関連するITGCが有効であれば、その結果を記録することで過年度の評価結果を続けて使えます。しかし、その統制の動作に障害が影響した期は、このうち「不具合が発生していない」を満たさないおそれがあります。ただ、その場合も、障害が財務報告に影響しなかったことを記録で示せれば、監査法人との協議の材料になります。追補版の質問書の記入例にも、障害が発生していたが財務報告に影響を及ぼす事項ではないことを確認した、という書き方が載っています。
A社の運用記録の台帳は7行で始め、月次で承認する
CFO・経理責任者が決めるのは台帳の承認者で、確認した人とは別の人が月次で承認する形にします。A社では、経理担当の行は経理責任者が、経理責任者と管理部長の行は取締役が承認します。
追補版の運用管理の統制目標（3-(2)-①-イ〜ヘ）をSaaS中心の会社に当てはめると、処理と連携ごとに、頻度、確認する人、確認の内容、エラー時の対応、記録の場所を1行にした一覧になります。なお、項目はこの統制目標を出典とし、行はA社を想定した編集部の例です。
| 処理・連携の名前 | 頻度 | 確認する人 | 確認の内容 | エラー時の対応 | 記録の場所 |
|---|---|---|---|---|---|
| 銀行口座の明細の同期（freee会計） | 毎営業日 | 経理担当 | ホーム画面にエラー表示が無いこと。前営業日までの明細が取り込まれていること | 再同期する。直らなければ明細を手動でアップロードし、取り込んだ件数を記録する | 日次・月次の記録（日次の行） |
| 法人カードの明細の同期（freee会計） | エラー表示は毎営業日、明細は確定の後 | 経理担当 | ホーム画面にエラー表示が無いこと。確定した明細がカード会社の明細と一致すること | 銀行口座と同じ | 日次・月次の記録（日次・月次の行） |
| バクラクからfreee会計への連携（経費精算・請求書） | 月次（締めの前） | 経理担当 | バクラク側の件数・金額と、freee会計に入った仕訳の件数・金額が一致すること | 差異の取引を特定し、再連携か手入力で登録して、差異の理由を記録する | 連携の突き合わせ表 |
| 自動登録ルールによる仕訳（freee会計） | 月次 | 経理担当 | ルールの設定が変更台帳どおりであること。ルールで登録された仕訳の勘定科目に異常が無いこと | 誤った仕訳を直し、ルールの変更は変更台帳を通して行う | 日次・月次の記録（月次の行）、変更台帳 |
| 月次の締め（仮締め・本締め） | 月次 | 経理責任者 | 締めの前に同期と連携の確認が終わっていること。締めた日と締めた人が記録されていること | 締め後の修正は、社内で締めの解除を申請・承認してから行い、理由を記録する | 日次・月次の記録（月次の行） |
| 取引・仕訳データと決算のExcelの控え | 月次（締めの後） | 経理担当 | ファイルが日付つきで共有フォルダに保存されていること | 出し直す | 共有フォルダの一覧 |
| 障害・停止の記録（freee・バクラク） | 発生の都度 | 管理部長 | 気づいた経路と日時、止まった範囲、決算への影響、再処理の結果 | 復旧後に件数を突き合わせ、取り込み直す | 障害記録 |
Excel のひな形をダウンロードする（シートは「運用記録の台帳」「日次・月次の記録」「障害記録」「記入の手引き」の4枚）。日次・月次の記録には、エラーが無かった日も「エラー無し」と確認者を残します。なぜ、何も無かった日まで書くのでしょうか。理由はシンプルで、何も起きなかった月に確認した事実を示せる記録が、これしかないからなんです。
監査法人には、台帳の中身より、台帳の外にあるものを聞かれやすい、というのが編集部の見立てです。
- 確認の対象から外した処理・連携と、その理由。給与計算のfreee人事労務からの仕訳連携など、一覧に載せていない連携が無いか
- 連携の件数・金額の突き合わせに使った一覧を、どの画面からどの時点で出したか
- 障害や停止があった期に、決算への影響をどう確かめたか
- SOC1報告書に利用会社の統制として書かれたもののうち、運用に関わるものが、台帳のどの行に当たるか
読み違えやすいポイント
| 読み違えやすい読み方 | 原文での扱い |
|---|---|
| 監基報315の付録6で市販ソフトのジョブの監視は「無」なので、SaaSでも定期処理の確認は要らない | 付録6は中規模の環境では特定のアプリケーションでジョブの監視を「有」とし、付録5 第15項はインターフェース接続をリスクの影響を受けやすい特徴に挙げています |
| ベンダーがバックアップしているので、自社の控えは要らない | ベンダーのバックアップは基盤や不具合への備えです。操作ミスや解約に備えた控えと、Excelのバックアップは自社で取ります |
明日からやること
- 会計に関係する定期処理と連携（口座の同期、SaaS間の連携、自動登録ルール、締め、給与からの仕訳連携）を一覧にする
- 運用記録の台帳を作り、処理・連携ごとに頻度・確認する人・確認の内容・エラー時の対応・記録の場所を1行ずつ埋める
- 毎営業日の同期の確認と、月次の連携の件数・金額の突き合わせを今月から始め、エラーが無かった日も確認の行を残す
- 月次の締めのあとに取引と仕訳データをエクスポートし、日付つきで共有フォルダに保管する
- 障害記録の様式と、ベンダーの稼働状況ページを月次で見る担当を決める
- freeeのSOC1報告書は担当営業かプロダクト内のサポートに依頼し、バクラクにも入手方法を問い合わせる。障害時の連絡と解約時のデータの返却は契約で確かめる
IT統制・J-SOX対応の進め方をご相談ください
使っているSaaSの洗い出し、IDと権限・設定変更の記録の始め方、SOC1レポートの読み込み、監査法人との協議に出す案づくりまで、公認会計士とエンジニアが一緒に整理します。